Re: viewpoints and multiple inheritance.
Nicola Guarino writes:
> Hi all,
>
> I have just finished reading the recent messages (it took a
> while, and I haven't attacked the huge discussion on PSL yet...), and
> I'd like to post some comments. I'll try to use ONE message per
> topic, with a clear subject line. I encourage everybody to do the
> same, going through this mass of messages was not easy...
>
> At 1:06 AM -0400 20/5/2000, Patrick Cassidy wrote:
> >(2) Will multiple inheritance be allowed? Although it may be
> >avoidable in theory,
I'm interested in that question. Does anybody have a reference to a
clear argument?!
> >it seems to conform to the intuitive notions
> >most people have about class membershiop, and it may be the only
> >way that different groups with different viewpoints will agree on
> >a single upper ontology. I vote for multiple inheritance.
>
> 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
multiple inheritance. 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
brick_building=(brick+)
brick_window_building=(brick+,window+)
concrete_wall_building=(concrete_wall+)
concrete_wall_window_building=(concrete_wall+,window+)
brick_concrete_wall_window_building=(brick+,concrete_wall+,window+)
...
2. Your example unfortunately won't become a strong argument [for ...?] as
long as you do not specify more explicitly, which properties you expect a
``building'' to have.
> 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].
> 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.
>
I don't see that argument.
The problem is, that there is a concept of things, which have a collection of
bricks and can be asked for their shape. And dependent on the [much more
precisely to be specified] outcome of the shape calculation, on the
surface-level of some representation language, you want to associate the
string ``castle'' with that brick-collection.
> Some years ago, I remember a discussion about this issue with CYC
> people. As far as I remember, a wooden table in CYC is seen at the
> same time as a piece of wood and an artifact.
>
> I have been working hard on this problem in the recent years, and,
> together with Chris Welty, I have just finished a paper which offers
> some principled tools for addressing modeling problems like this:
>
Can you give us a pointer?!
All in all [, besides having the feeling not to have understood every facet],
I didn't want to say: ``you are wrong''. I just wanted to demonstrate, that
in my opinion, the example isn't sufficient.
Bye,
Markus