multiple inheritance
To clarify my point on multiple inheritance:
Nicola Guarino wrote:
<< -------------------------------
. . .I definitely agree on allowing multiple inheritance in general, but
some caution is needed with different viewpoints. I am not sure what Pat had
in mind here, but
suppose that a castle, for instance, is seen as a kind of building under a
certain viewpoint and as a bunch of bricks under a different viewpoint. A
possible way of
modeling this situation is by admitting that the concept "castle"
specializes both "building" and "bunch of bricks". Using IS-A links to
represent multiple views is
indeed a common habit. The problem however is that the concept "building"
has some properties that are incompatible with those of "bunch of bricks".
For
instance, we usually admit that a castle must possess a particular shape
(more or less) in order to exist, while there is no similar requirement for
the bunch of bricks.
In other words, having a certain shape is "essential" for the castle and
not essential for the bunch. In this case, modeling multiple views by means
of mutiple IS-A
links is simply *wrong*, because it leads to an inconsistent theory.
Rather, two different (micro)theories may be built, reflecting the different
assumptions.
------------------------------------------------------------------>>
Certainly any multiple inheritance links used must be consistent, and
anyone who
uses them will have to check carefully for consistency. One of the
important uses of
multiple inheritance will be to allow aggregates of concepts which are
useful for
particular purposes. A manufacturer of pocketbooks, for instance, may
want to create a class of "hide-bearing animals" which includes both
alligators
and cattle. One might want to classify a "bayonet" as both a "cutting
instrument"
and a "weapon". These two categories would have many members which are not
in common. Similarly, military watercraft may be categorized as both
"watercraft"
and "weapons systems". The same ends can be accomplished without
multiple inheritance, but it will be more complicated. The point of an
ontology
is to create a compact and easily maintainable representation of knowledge,
and multiple inheritance is a means to make the representation more compact
then
it would be with single inheritance.
The other main reason for multiple inheritance is to make it easier to
generate agreement on a standard upper ontology. In merging existing
ontologies, it will probably be necessary for some groups to give up
some features that they consider useful, but if using multiple inheritance
can allow different *consistent* views to be include in the same
ontology, it will ease the pain of transition and increase the likelihood
of being able to create a standard that can be widely used.
Does anyone actually classify a castle under "bunch of bricks"? ;-)
Pat
cassidy@micra.com