ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Heterarchy & Hierarchy, oh my my

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ron Wheeler <rwheeler@xxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 03 May 2008 11:45:54 -0400
Message-id: <481C88B2.5050501@xxxxxxxxxxxxxxxxxxxxx>
Wacek Kusnierczyk wrote:
> Pat Hayes wrote:
>   
>> At 9:08 PM -0400 5/1/08, ZENG, MARCIA wrote:
>>   
>>     
>>> Check: http://sig.biostr.washington.edu/projects/fm/FAQs.html
>>>
>>> Foundational Model of Anatomy (FMA) ontology
>>> Modeling questions...
>>> 4) What does a merged hierarchy mean and why use one?
>>>     
>>>       
>> Here's a toy example. Suppose you classify people 
>> as male vs. female and married vs. single. You 
>> can make this into a two-level hierarchy tree in 
>> two ways, depending which distinction you make 
>> 'higher' than the other. But this choice is 
>> arbitrary; and arbitrary decisions like this are 
>> bad for interoperation, since they tend to be 
>> made essentially at random, producing 
>> incommensurate classification systems. Moreover, 
>> if you make the male/female division nearest the 
>> root, then there is no place in the tree for the 
>> class 'married people (regardless of gender)'. A 
>> merged hierarchy would have these two divisions 
>> of the root class represented independently, so 
>> that there would be two routes back from 'married 
>> men' to 'people', one representing the selection 
>> of male (not-female) and the other representing 
>> the selection of married (not-single). 
>> Inheritance works as usual within each hierarchy 
>> tree, and they may be independent, although more 
>> complex schemes can be used.
>> The chief advantages are already noted, but 
>> others include increased efficiency of reasoning 
>> and greater 'naturalness' in connecting 
>> classifications with associated properties and 
>> facts. And, contrary to initial expectations, 
>> multiple-hierarchy schemes are almost as easy to 
>> implement as single-tree taxonomies.
>>
>>   
>>     
> That's an interesting point.  I was repeatedly complaining on the OBO- 
> and BFO-related lists about the insistence, within that framework, on 
> single inheritance.  Illustrative cases of the arbitrariness of choice 
> which distinction is to be prioritized over others (i.e., placed higher 
> in the taxonomic tree) can be found in virtually any OBO ontology; for 
> example, PATO starts at quality, distinguishes qualities of occurrents 
> from qualitites of continuants, and then within each of these 
> distinguishes, independently, monadic and relational qualities.  It 
> could well have been the other way round.
>
> I mention this because the answer to my complaints, if any, was 
> invariably that single inheritance a) increases efficiency of reasoning, 
> b) is more natural and easier to use, and c) is good for interoperability.
> To my simple mind, these claims do not correspond well to yours above.  
> It would be interesting to see a discussion on this issue, though the 
> argumentation provided by proponents of the other view typically did not 
> go beyond rather vague handwaving.
>
>
>   
>> Hope this helps. There is a lot more on this 
>> general topic (including a foundational 
>> mathematical theory based on lattice theory) on 
>> John Sowa's excellent website, which I commend to 
>> your attention.
>>
>>   
>>     
>
> Is there a precise pointer to precise results which say that it is (or 
> is NOT) the case that:
> a) single inheritance is more natural than multiple inheritance;
> b) single inheritance is less problematic for reasoning than multiple 
> inheritance;
> c) single inheritance improves,  wrt multiple inheritance, interoprability?
>
> vQ
>  
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/ 
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>  
>
>   
Life does not always give us problems that are designed to be less
problematic for reasoning.
The origin of this discussion was a BOM (bill of materials) problem
which is well known to require a multiple inheritance model of arbitrary
depth.
The originator of this stream had suddenly found the reason why single
inheritance (his original model) , in spite of all of its simplicity and
natural appeal, would fail to represent the real world and would lead to
chaos and great complexity and eventual failure of the resulting system.
Can you imagine the stockroom at an automotive plant if every part was
constrained to belong to a single inheritance. The same screw would be
identified by hundreds of names and the stockroom would be full of bins
with the same part in each one or a bin with a thousand part numbers on
its label. The purchasing department would have a nightmare trying to
consolidate orders to suppliers and the receiving office would be up to
their necks in screws being carefully counted out into bins with the
individual BOM names..
Sure, single inheritance works for the steering wheel and used to work
for right and left, front and back brake assemblies (until they figured
out that mounting one side upside-down made them almost identical so
that most of the parts work on both and that you could use disc brakes
on the rear wheels too) but the further down in the hierarchy you get,
the more problems you find with single inheritance.
"Parts explosions" and "where used" reports are an essential part of a
multiple inheritance solution.    (01)

The sooner that you recognize that there is a possibility of the real
world that you are going to have to model,  including multiple
inheritance, the less costly (however you measure this) it is to move to
a multiple inheritance model and tools that will handle this. If you try
to force single inheritance on a multiple inheritance problem, you will
eventually be forced to change models or add an unacceptable amount of
complexity or operational restrictions into the system.    (02)


Ron    (03)






_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (04)

<Prev in Thread] Current Thread [Next in Thread>