The classification problem is the problem that for many real-world objects and systems; coming up with an iron-clad classification system (to determine if an object is a member of a set or not, or which of several sets) is a difficult problem. As put on the page NobodyAgreesOnWhatOoIs:
"Try to come up with a definition of a chair. For any definition you can provide, I can come up with an example of an object that either meets the definition but is not a chair (a false positive) or fails to meet the definition but is (a false negative).''
(And yet, it is noted, we can still have meaningful discussion of chairs despite this failing).
Also note that definitions may not be agreed upon by all observers--see LaynesLaw--or may change over time. SchemaEvolution, necessary to reflect changes in a company's policies and procedures, is a known difficulty in modelling business processes.
Many real-world objects have this problem; the taxonomical system used by biologists is a prime example. Some claim that this proves ThereAreNoTypes--a common argument is that if we cannot come up with an iron-clad classification system; we shouldn't come up with one at all.
On the other hand, classification is still useful despite these shortcomings.
- Depending on the application; a first-order approximation may be more than adequate. If the problem domain is furniture construction, then a detailed chair model is highly appropriate. On the other hand, if one is constructing an inventory system for, say, a restaurant; than little needs to be known about chairs other than make and model (and other relevant details for inventory). Questions about "if you saw three legs off of a barstool and attach a gyroscope to balance it on its remaining leg, and hammer nails through the seat such that anyone who sits on it will surely get stabbed in the buttocks, and then set it on fire and paint the charred remains purple with pink spots--is it still a chair?" are simply not relevant.
- By restricting the universe of discourse, it is often possibile to construct a valid definition. If one tries to come up with a definition for a "manager" (a person who has other people reporting to him?) that is universal, one will encounter problems. If we restrict our attention to "managers at company X", on the other hand, a precise definition is possible. For many problems, use of restricted subsets like this is entirely feasible and appropriate.
- When detailed higher-order models are needed; frequently the limiting factor is not the computer's ability to reason and compute, but our inability to describe with specifity the necessary criteria--computer or no. The chair problem given above is a problem even without a computer involved. That said, coming up with a way to communicate a "chair" model to a computer and then querying example chairs against it can itself be a problem--one that the typing systems of many programming languages (which insist on assigning discrete types to everything rather than using SetsAndPolymorphism) don't handle very well.
One problem with classifications, any classifications, not just hierarchies, is that EverythingIsRelative. There is no universal classification for everything. Here is a typical scenario:
- A retail store system has a way to classify some products as "discounted". This is called the "Discounted list". (Technically, it may be a flag in a table instead of a list, but for illustration purposes it can be viewed as a list.)
- Department A does not like the Discounted group because some items are not actual discounts because they are always sold at the discount rate. However, department B wants to keep it that way because they are tracking nominal discounts instead of actual discounts.
- Department A creates a Discount_Exceptions group that is combined with the existing Discount group. It has product ID, and an "include" or "exclude" marker.
- Departments A and B have problems maintaining the Discounted group because sometimes one or the other is slow to add changes to it, or one wants to review changes first. If department A needs something quick, they may have to wait for department B to mark the discount if a given product is being evaluated by them. The Discount_Exceptions usually works, but it requires first checking with the Discount list. Plus, sometimes department B adds something to the Discount list without A being immediately aware of it and a "discount" that does not satifsy A's requirements slips by. They would like to review the "discount" classification first. (Assume the system assigns product catalog change responsility to one and only one department per product to avoid responsibility squabbles.)
- Department A desides to keep their own list of discounts and let department B manage the Discounts (caps) group. Under this approach, department A no longer needs to maintain 2 lists (original plus Discount_Exceptions), and no longer needs to coordinate changes with department B.
- They end up maintianing their own lists for their own needs. It is a case of the EightyTwentyRule wagging the dog. The lists are similar, but not identical. DeltaIsolation management is sometimes more work than "clone-and-change", also called CopyAndPaste in some cases.
--top
CategoryInfoPackaging, CategoryReuse
Classification Problem