RE: viewpoints and multiple inheritance.
Multiple inheritance (worked out bottom up rather than top down) is a matter
of the discovery of common factors with a certain structure. These either
exist (are found) or do not exist (are not found). I'm not sure a decision
on the matter is either relevant or useful.
Operations & Asset Management
Shell Services International
H3229, Shell Centre, London, SE1 7NA, UK.
Tel: +44 207 934 4490 Fax: 7929
Exchange e-mail: Matthew.R.West@is.shell.com
Compuserve e-mail: Matthew_West@compuserve.com
> -----Original Message-----
> From: Christopher A. Welty [mailto:email@example.com]
> Sent: 19 June 2000 18:23
> To: firstname.lastname@example.org
> Subject: Re: viewpoints and multiple inheritance.
> I apologize for sending a hasty message a few minutes before leaving
> for vacation. For the simpler folk who are just reading up to the
> point where I disagree with them: I ADVOCATE MULTIPLE INHERITANCE.
> I hastily said:
> >It is because of this almost universal lack of discipline
> >that we should consider not having multiple inheritance.
> Bill Andersen replied:
> > (x):Equiangular(x) -> Polygon(x)
> > (x):Equilateral(x) -> Polygon(x)
> > (x):RegularPolygon(x) -> Equiangular(x) and Equilateral(x)
> > All these are "necessary" definitions, assuming the conventional
> >definitions of these terms. This ought to be an example of the
> >legitimate use of "multiple inheritance".
> > My point is if you can think of one principled example, you can
> >probably come up with others. It would be unfortunate if we were
> >to "throw out the baby with the bathwater" by failing to allow
> >this. All we need to do is to apply a framework, such as the one
> >you and Nicola have developed to weed out the silly cases (the C++
> >example comes to mind)
> Right. Despite my actual words, I do not propose that we completely
> abandon multiple inheritance just because most people don't know how
> to use it.
> Most of the email-avalanche following Nicola's first message were
> advocating the ultimate need, in general, for multiple inheritance in
> an ontology. THIS I GRANT (in my power to do so), even though most
> of the examples were actually bad (or silly) ones.
> HOWEVER, "designing a top-level ontology" is much different from
> "designing an ontology" in general for some concrete and
> domain-specific purpose. While it should be clear that for the
> latter, MI is often needed, for the former I believe it is not. In
> other words, and I may seem to be changing directions here, I'm not
> completely sure multiple inheritance should be allowed in our TOP
> LEVEL ontology. At the very least, I believe it should be avoided.
> The top level should attempt to carve up the world into discrete
> categories as much as possible.
> Can we avoid MI completely in the top-level? Perhaps not completely,
> but we should try.
> Does this mean top-level categories should be disjoint? No.
> Disjointness is a different notion. Even if we manage to have a
> top-level without MI the top level categories may be overlapping.
> Can domain-specific extensions specialize multiple top-level
> categories? Yes, the top level categories are not disjoint.
> Christopher A. Welty Professore Visitatore
> LADSEB-CNR email@example.com
> Corso Stati Uniti, 4 Voice: +39 049 8295783
> I-35127 Padova Fax: +39 049 8295763
> Italy http://www.cs.vassar.edu/faculty/welty/