Re: Good and Bad IS-A hierarchies (Pat Hayes)
Message-id: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 29 Jul 1995 19:49:52 -0500
To: (Peter Clark),
From: (Pat Hayes)
Subject: Re: Good and Bad IS-A hierarchies
Precedence: bulk
At 12:09 PM 7/27/95 -0600, Peter Clark wrote:
>> [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
>to work. 
>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.

But theres something odd about this idea of 'assumption'. Any two sets of
axioms (which arent interderivable) make different assumptions, dont they?
They have different models. If so, this argument is specious. In my
example, no changes need to be made to all but one of the axioms in the
theory, and only a tiny change (deleing one supposition in an implication)
needs to be made to one. But the translation between one set of relations
and another then has to be quite vividly rewritten. If this kind of change
is a change of "assumptions" , then just about every subset of the temporal
axioms is a different "assumption". Which is more or less my point. I think
this is will be the norm, not the exception.

>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.

Nah, this is much too simple. As soon as you have more than one 'possibly
abnormal' relation, things get out of hand since you have no way to tell
the closed-world machinery which ones have priority. 

 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.

Oh, I agree. And I agree that we need ways of taking theories and fixing
them to reflect changing assumptions (it often amounts to ways of restoring
consistency, as with "ab"). My only point was that we probably wont be able
to just take axioms off the shelf and drop them together in various
combinations to construct alternative theories. Call it plug-FIX-and-play.


Until September: 
1916 Ivy Lane, Palo Alto, Ca. 94303               phone (415)855 9043