Re: Good and Bad IS-A email@example.com (Peter Clark)
From: firstname.lastname@example.org (Peter Clark)
Date: Thu, 27 Jul 1995 12:09:39 -0600
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
Subject: Re: Good and Bad IS-A hierarchies
Cc: email@example.com, firstname.lastname@example.org
>>> [Pat Hayes wrote]
>>> There is no way to organize the concepts, or even the axioms, into neat
>>> little packets so that the various alternatives can be assembled by
>>> choosing some and ignoring others.
>> [Peter Clark wrote]
>> Well, the above paragraph ignores the idea of being able to
>> compose representations from components.
> [Pat Hayes wrote]
> It doesnt ignore it, it reports a sober conclusion that that is impossible.
> Here's an example....
That's a good example. Essentially, you describe (if I understand correctly):
Start with axiom A1
Add axiom A2
Now axiom A1 needs to be modified in some non-trivial way (to
preserve the intended meaning)
Yes, I agree you're in trouble if that happens. It's (essentially) the classic
extensible software problem, that if you add feature N to your system, then
the code for features 1...(N-1) need to be rewritten for the system still
The problem is that your axioms make different assumptions about what
"interval" means: A1 assumes its non-reversible, whereas A2 assumes
(or even asserts) that it's reversible. (I would say they don't share
the same ontology despite your statement that they do -- though I'm
now getting fuzzy on what ontology means anyway). If we add A2, then A1
must change as you've formulated it.
There's two (not mutually exclusive) alternatives:
(1) rise to the axiom transformation challenge: Yes, if I modify my
assumptions then I'll have to modify some axioms, so let's write down
what those transformation rules are. If my understanding's correct, this
is exactly what the lifting axioms in CYC are meant to do.
(2) reformulate the representation, so that modifying an assumption doesn't
involve modifying existing axioms. This is a hot area in s/w reuse
problem; how to rewrite code so that you can perform "extension by
addition" ("Adding new code is good, whereas modifying existing code
is bad.") The challenge is to find such reformulations.
The use of abnormality predicates can be seen as an example of (2). I write:
A1: bird(X) -> flies(X)
where bird() means "living birds". Later I decide I want to modify my
interpretation of bird() to mean "all (alive or dead) birds", so that
I can introduce other axioms about all (alive or dead) birds. The
problem is I have to modify A1 to do this:
A1': bird(X) & not dead(X) -> flies(X)
(This seems analogous to your temporal example, where "interval" changes
from meaning non-reversible interval to reversible interval). However,
(as you know) there is a reformulation which avoids this "axiom modification"
problem, namely (along with a closed world assumption somewhere) we
use a different A1:
A1: bird(X) & not abnormal1(X) -> flies(X)
Now we can (at least) later generalize what we mean by bird() without having
to modify axioms, and instead just add axioms, eg.
A3: dead(X) -> abnormal1(X).
I'm not sure whether such a syntactic reformulation would be possible
for your temporal example. My comment is that it might be possible, and
that looking for such reformulations is going to be essential to build
component-based knowledge libraries. It's precisely these sort of issues
which are at the heart of building plug-and-play knowledge bases.
I remain cautiously optimistic (partly because I see s/w engineering making
some headway in these issues)... I take your counter-example as a
good illustration of the challenges, rather than a reason to give up.
Peter Clark (email@example.com) Department of Computer Science
tel: (512) 471-9565 University of Texas at Austin
fax: (512) 471-8885 Austin, Texas, 78712, USA.
Some WWW pointers to KBS labs: http://www.cs.utexas.edu/users/mfkb/related.html