Re: viewpoints and multiple inheritance.
Markus Pilzecker wrote:
> > 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".
>
> Sorry, that I didn't have been more precise in my first posting.
> As you can see now, I understood a concrete-wall-window-building to be
> a building, which has [at least one] concrete_walls and [at least one]
> windows.
>
> > 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.
> >
> So, as having been pointed out in other postings as well, it is desirable to
> search for an answer to the question, if an automatic consistency check is
> achievable in principle. Oh, yes: what _is_ consistency??
>
> > 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.
> >
> Of course. A castle is generally considered not only to be a ``bunch of
> bricks''.
If I may add my two cents, and add a different flavour as well, I'd like to point
out that we should not intermingle issues of formalisms (eg. multiple inheritance,
MI) with issues of using it (eg. modeling some part of the world appropriately). In
my view it doesn't make sense at all to view a castle as a bunch of bricks. And
sure, building is not a specialization of window. These are modeling issues. An
appropriate model would have window as a part of building, not as a superclass.
These issues do not address the usefulness of MI.
In my view there is no doubt that MI is needed if we want to model a domain, ie.
some part of the world. And there is no doubt that the modeling task becomes more
complex. We always model part of it and need to have powerful formalisms to make
progress. Actually, ingheritance is not only needed, but it is still insufficient.
The problems of MI have to do with the logics of (simple) monotonous inheritance in
general. Intuitively we'd account things as superconcepts (subconsepts) that,
strictly speaking, aren't. Take for instance the infamous example of birds, which
are specialisations of animals that can fly. Everyone around you, and you yourself,
would classify a penguin as a bird. However, penguins can't fly. To model this
correctly you have to get rid of the concept of birds as animals that can fly which
is counterintuitive. Or you have to assume that penguins are no birds, which is
strange as well.
This is why people came up with (multiple) default inheritance, expanding the
expressive power of their formalisms. So birds can normally fly (some can't, and
for those, we state that explicitly). That's intuitive. But the underlying logics
don't always match up to intutive expectations. The whole field of non-monotonic
reasoning is about defining formalisms that allow intuitive modelling. I've got the
impression that it is both notoriously difficult and computationally expensive.
I wonder whether people's intuitions can in principle be captured by some logics.
During life we get acquainted with lots of theorems that have extensions not
predicted by some logics. We usually are not aware of this. Humans seem, by
convention or experience, to apply the theorems in a useful way, avoiding the
putfalls of inconsistency or contradiction. The penguin/bird thing came only up as
a problem when people wanted to model it using inheritance.
Regards,
Stephan Busemann
begin:vcard
n:Busemann;Stephan
tel;fax:+49 681 302 5338
tel;work:+49 681 302 5286
x-mozilla-html:FALSE
url:http://www.dfki.de/~busemann/
org:DFKI GmbH;Language Technology Lab
adr:;;Stuhlsatzenhausweg 3;Saarbruecken;;66123;Germany
version:2.1
email;internet:busemann@dfki.de
title:Senior Researcher
x-mozilla-cpt:;20616
fn:Stephan Busemann
end:vcard