ontolog-forum
[Top] [All Lists]

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

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Patrick Cassidy" <pat@xxxxxxxxx>
Date: Tue, 13 May 2008 00:29:07 -0400
Message-id: <01c901c8b4b1$e21c5da0$a65518e0$@com>
Alan,
   I would be interested in seeing what kind of errors are encouraged by
multiple inheritance that would not occur with single inheritance.  Some
kinds of multiple inheritance are logically equivalent to assigning multiple
necessary and sufficient attributes to entities, and it seems to me that the
same kinds of errors could occur whichever way one chose to represent the
types.
    For example, one might want to say that a U-clamp is a metal fastener in
the shape of a U with threads at both ends.  One could do that by first
representing "Fastener", "U-shapedObject", "MetalObject" and
"DoubleThreadedLongThinObject", and then specifying that a U-clamp is a
subtype of all four types.  Or One could decide that being a Fastener is the
type one wants to emphasize and make it a subtype of "Fastener" and give it
attributes "Metallic", "U-shaped" and "DoubleThreadedLongThin".  But then
why isn't U-shaped or Metallic the primary characteristic?  I see no obvious
principle for preferring some primary inheritable type, and no advantage to
the single-inheritance method.  The multiple-inheritance method provides not
only a more compact and readable representation in OWL (and other
languages), it also allows inheriting multiple necessary attributes in a
single line of 'code' and also allows inheriting the domain restriction of
multiple relations without requiring domain restrictions that are unions of
a large number of types.  So single-inheritance is so clumsy for
representing seriously interesting things that the 'advantage' would have to
be very large to outweigh the disadvantage.    (01)

   But I haven't seen examples of the problem you refer.  Can you provide
examples that were actually caused by multiple inheritance rather than
simple errors in some instance of assigning subtype per se?    (02)

Pat    (03)

Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx    (04)


> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Alan Ruttenberg
> Sent: Monday, May 12, 2008 11:16 PM
> To: bfo-discuss@xxxxxxxxxxxxxxxx; Phillip Lord
> Cc: [ontolog-forum] ; obo-relations@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] [bfo-discuss] Re: Heterarchy & Hierarchy,
> oh my my
> 
> On May 6, 2008, at 11:54 AM, Phillip Lord wrote:
> >>>>>> "Alan" == Alan Ruttenberg <alanruttenberg@xxxxxxxxx> writes:
> >
> >   Alan> I've seen the disadvantages of multiple asserted
> > inheritance when
> >   Alan> reviewing, e.g. the Cell ontology in OBO, where it was
> > demonstrated
> >   Alan> (by the authors) that it was quite easy to find mistakes of
> > the sort
> >   Alan> where all of the properties described in the definition of
> > (multiple,
> >   Alan> and transitive) superclasses were not true of instances of
> > the class
> >   Alan> in question. Regarding (c) what is perhaps being referred
> > to is that
> >   Alan> if one practices "normalization" in the sense that Alan
> Rector
> >   Alan> proposes [1] then the component single inheritance
> > ontologies from
> >   Alan> which more complex terms are constructed are more likely to
> > be able to
> >   Alan> be reused by other projects. Certainly that's the intention
> of
> >   Alan> creating and using PATO. I've found the exercise of factoring
> >   Alan> definitions in this manner is often helpful and is
> > conducive to
> >   Alan> helping the sorts of people I work with think carefully when
> >   Alan> constructing ontologies.
> >
> > I think that we need to be clear here; there is a fundamental
> > distinction
> > between normalisation as according to Alan Rector and to the idea
> > of single
> > inheritance is a correct reflection of reality.
> 
> I think I've been clear on this. What I consider interesting is that
> the same conclusions about the pragmatics of ontology construction
> arise from two different approaches. For me, since I have respect for
> the purveyors of these two approaches, this strengthens the case that
> this is a good way to go about doing things.
> 
> > While you are correct that allowing multiple inheritance increases
> > the risk of
> > some common errors, it also allows modelling that is not possible
> > otherwise;
> > in particular it can be used to avoid a combinatorial explosion of
> > terms.
> 
> Example?
> 
> > My take; single inheritance can be easier and simpler sometimes,
> > but not always;
> 
> Curious about the not always. And not sure about the easier or
> simpler either. "I would have written a shorter letter if I had
> time", etc. But I think it leads to better quality results.
> 
> > using a computationally amenable languages and normalisation allows
> > you to get some of the advantages of both.
> 
> +1 on that one.
> 
> -Alan
> 
> (the *other* Alan R ;-)
> 
> > Phil
> >
> >
> >
> > ps, I started of writing this email referring to Alan Rector as
> > "Alan". Then I
> > had to correct it to "Alan R" to disambiguate from you. Then again.
> > Eech.
> 
> _________________________________________________________________
> 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
>     (05)


_________________________________________________________________
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    (06)

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