Re: viewpoints and multiple inheritance.
At 13:31 2000-06-08 -0400, Tim Finin wrote:
> ...
> Multiple inheritance works just fine if you have reasonable semantics
> for inheritance (e.g., no exceptions) and moreover, the semantics can
> be easily defined.
The point that I'm making is that those people who worked on multiple
inheritance themselves felt they had reasonable semantics (they weren't
stupid either). Unfortunately, there were many detailed cases that
constrained the approach. One needs a good definition of "multiple
inheritance" that also translates into a reliable computation model ... this
is where the problems usually occur.
The problem is not that there weren't reasonable semantics, the problem is
that "multiple inheritance" doesn't map well to a computation model ... if
one is going to process an SUO in an automated way, there must be a
computation model. Regarding "multiple inheritance", my sense is that
either you may either (1) map the concept into a poorly defined computation
model; (2) weaken the concept to get to a workable computation model; or (3)
base the concept on a computation model.
As I listen to people discussion "multiple inheritance" on this E-mail
reflector, I think most people have a sense of what is means ... can we see
I definition? I want to make sure we are talking about the same term.
Chris Welty has stated:
Multiple inheritance therefore really means a class/property/concept
(I'm being a bit sloppy here) that is subsumed by more than one c/p/c...
When one property is subsumed by another, say Q subsumes P, it means
only this:
FORALL x P(x) -> Q(x)
Is "multiple inheritance" merely two FORALLs with a bunch of ANDs in the
middle? If so, then with is there to "support"?
> In your example, do you really intend Class_3 to
> be those things which are both a square and a triangle? And if it
> is, wouldn't you expect the definition to be incoherent. A reasonable
> ontology language would, of course, be able to detect and report this
> incoherence since the attached attributes would be declarative.
Your approach towards "incoherence" doesn't scale up in a practical way.
While there might be pockets of information that have this sense of
"coherence", it is very difficult to handle in a distributed, disconnected
fashion. In other words, once you've create an SUO, you'll never be able to
change it again because you won't know all the dependencies that introduce
"incoherence". Even in communities that have complete control over their
"pocket" of information, subtle changes create lots of engineering problems
... ask anyone that has done a large engineering project with "deep
inheritance" (i.e., many levels of derivation).
You might not care about the engineering issues on something that is
theoretical, but they must be addressed if one wants a useful computational
model that is widely adopted (<== standards and interopability issues).
-FF
-----------------------------------------------------------------------
Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
mailto:frank@farance.com http://farance.com
Standards, products, services for the Global Information Infrastructure