[QUANTIT] Use-cases, role in larger scheme (Was: Re: [QUANTITY] Quantity "arguments")

[Ed Shaya]

DIDELON Pierre wrote:

>just one more argument in favor of my favorite Quantity model (pat's one),
>but let's try to be more complete and explicit.
>
>I prefer VERY SIMPLE object instead of complex ones, 
>mainly considering a bottom-up approach, because :
>  
>
The architecture should result in an class hierarchy (ontology really) 
that captures the full population of objects (instances) in a sensible 
way.  Classes are usually built top down with care that each subclass 
has instances that are contained within the classes above.  In zoology 
one naturally starts at Kingdom and works ones way down through Order, 
Family, Species, Subspecies. 

In developing complex structures, one goes the other way.  In geometry, 
one can start by
describing a point, then a line is composed of an infinite number of 
points, a geometric figure is composed of line segments etc.   Or, in 
physics, start with the atom, then these can be combined into molecules, 
then to polymers or bricks, then to buildings or cells, etc.   But one 
must note that in each step of the construction by containment of a 
complex structure from atomic parts that the class of the object changes 
quite radically.  Eg,  the properties assigned to bricks has nothing to 
do with the properties assigned to molecules.  Eg, the functions applied 
to line segments are quite different than the functions applied to points. 

As a critical aid in developing a class system, ontologies have a well 
developed concept of restrictions.  This useful to ensure that the 
population of instances of a subclass to be a subset of the class.  UML, 
unfortunately, does not provide well for restrictions, and I believe 
that this weakness can lead to a poor class system.

An example of this is that, using UML,  one can have an arrayQuantity be 
a subclass of atomicQuantity even though they are meant to be considered 
the same thing except that an atomicQuantity is the special case with 
size="1".  Since it does not need that attibute size, it has one fewer 
properties and is therefore higher on class diagram.  In ontology work 
you would never make this mistake.
If we classify a zebra we would have:
Animal <-- AnimalWithLegs <--- AnimalWith4Legs <-- Zebra.
It must go this way because each subclass restricts the population of 
the previous class.
It does not matter if you say, nearly all animals have 4 legs so lets 
make that the default and then most animal classes will not need to have 
the numberOfLegs attribute.  And it does not matter if you make the 
default 1.  Yes, in UML you could twist this around and have 
AnimalWith4Legs <-- AnimalWithNLegs because the subclass added one more 
attribute.

If you want to say a quantity can contain atomicQuantities, that is 
fine.  AtomicQuantity is still a subclass of quantity, and quantity  
contains atomicQuantity(s) is valid.  Now, we probably don't want to do 
this for the practical reason that an object composed of thousands of 
smaller objects is trouble, and in this case, unnecessary trouble.

Likewise, it is inappropriate to have a separate class for the quantity 
with no error because it is unknown or so precisely measured that it is 
zero, as in the case of knowing that there are exactly 2 planets closer 
to the sun than Earth.  It is fair to say that there is a special class 
for a number with units that the user sets as a parameter in a query or 
a directive to an application, that *logically* has no error.  But, do 
you really want this to be a direct subclass of Thing so that it is 
totally unrelated ontologically to quantity?  Afterall, its main purpose 
is to be directly compared with quantity objects.  In OWL the expedient 
thing to do was to slightly broaden the definition of quantity by making 
Error an optional property.  Then if you want to one can subclass these 
into two, one with an Error required and one without.  And, of course 
you can give these three classes totally different names, but the  
principle remains the same.  But, it will remain that the thing with no 
Error is a fairly rare beast because it absolutely can not take an 
Error.  Perhaps a Range though.

Bottom line, ambiguities caused by using UML can be circumvented by 
using OWL and  Venn diagrams.