Re: viewpoints and multiple inheritance.
At 5:43 PM +0200 8/6/2000, Markus Pilzecker wrote:
>Nicola Guarino writes:
> > 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.
>1. I think, a single example cannot be sufficient to have an argument for
My argument was not an argument for multiple inheritance. I gave the
utility of multiple inheritance (or whatever we want to call it,
multiple subsumption, multiple generalization, multiple IS-A
links...) for granted, I just pointed out that some apparently
obvious multiple inheritance schemes may be inconsistent. So my
argument was just a warning.
>With focus on a single entity, you never have
>[technical] problems to inherit one feature after the other, while walking
>down the inheritance tree. Order doesn't matter. The interesting point for
>multiple inheritence comes in, when you want to raise reusability of your
>model parts by making them freely combinable. Near to your example, if you
>have concepts of ``window'', ``brick'' and ``concrete_wall'', a client may
>combine some of them to construct concepts like
I am not sure I understand this example. What does the plus sign
mean? Intuitively, however, if a "concrete-wall-window-building" is
intended to be both a "concrete-wall" and a "window", it may be
important to observe that there is a common interpretation of
"concrete-wall" such that you can't see through it, while exactly the
contrary holds for "window". At least under this interpretation, this
example of multiple inheritance is inconsistent. I just wanted to
point out that many examples of multiple inheritance appearing in
well-known ontologies risk to be inconsistent as well.
> > 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.
>Here lingual looseness is about to catch you. It's a bit strange to think of
>a separate entity ``shape'' as something, you can grasp. A shape is not
>something you can ``assign'' to an entity, which ``has'' a shape. It's more,
>that a shape is something computable in dependence on other ``owned''
>properties. In this example this would mean, that, if bricks can be ``asked''
>for their outline /*=shape??*/ and location in [physical] space, you can
>compute something, which you take as a representation of shape for the castle
>[, e.g. a collection of triangles].
The ontological status of shapes is a different issue (which I am
happy to discuss under a different subject line). For the sake of my
argument, the only point is that castles have certain "essential"
properties that bunches of bricks don't have.
>Can you give us a pointer?!
I am sorry, the list exploder ignored the hyperlink I put in my
original message. The pointer is the following:
National Research Council phone: +39 O49 8295751
LADSEB-CNR fax: +39 O49 8295763
Corso Stati Uniti, 4 email: Nicola.Guarino@ladseb.pd.cnr.it