W3C home > Mailing lists > Public > www-webont-wg@w3.org > February 2002

Re: Still no paradox (was: Re: The Peter paradox isn't.)

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 25 Feb 2002 19:00:27 -0600
Message-Id: <p0510147ab8a08b422083@[]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: dieter@cs.vu.nl, www-webont-wg@w3.org
>Here is, I think, a major point of difference between our views of how OWL
>has to work.
>From: Pat Hayes <phayes@ai.uwf.edu>
>Subject: Still no paradox (was: Re: The Peter paradox isn't.)
>Date: Thu, 21 Feb 2002 20:23:32 -0600
>>  >3/ Next consider DAML+OIL restrictions.
>>  >
>>  >    If John has a child that is a Person, then John belongs to the
>>  >    Restriction that requires that its members have a child that is a
>>  >    Person.
>>  >
>>  >    <John, child, Joe>, <Joe, rdf:type, Person>
>>  >    |= <John, rdf:type, :_1>, <:_1, rdf:type, owl:Restriction>,
>>  >       <:_1, owl:onProperty, child>, <:_1, owl:hasClass, Person>
>>  >
>>  >    This is only a valid entailment if all satisfying OWL 
>>interpretations of
>>  >    the first two statements contain a restriction of the above form.
>>  True, but this does not capture the intuitive meaning of your
>>  example. What this says in RDF is that If John has a child that is a
>>  Person, then a Restriction *exists* such that John belongs to....
>>  There is however no reason why it has to make that claim in OWL.  Why
>>  would OWL want to assert the *existence* of restrictions? Thats like
>>  having FOL assert the existence of its own formulae.
>I claim that this precisely captures the intuitive meaning of my example.

Be that as it may, intuitive meanings do not produce formal 
paradoxes, was my primary point.

But I think you are right, we do fundamentally disagree about 
intuitions here. If I read things like this as RDF, they have a clear 
meaning as existential assertions, but very weak assertions. In 
particular, there is no way to impose an intended meaning on the RDF 
which restricts its universe of discourse to be the recursively 
defined computational closure of a syntax definition. That is asking 
too much of any descriptive language, let alone one as weak as RDF.

>Given an OWL KB, I need to be able to determine if an object in that KB
>satisfies a restriction that is not necessarily mentioned in the KB.
>I would be prepared to do this somewhat indirectly, as in
>     <John, child, Joe>, <Joe, rdf:type, Person>
>     |= <John, rdf:type, :_2>, <:2, owl:sameAs?, :_1>,
>        <:_1, owl:onProperty, child>, <:_1, owl:hasClass, Person>
>However, I view any approach that does not come up with some way of doing
>the above as fundamentally broken.

Then you have broken it before you even begin.

Is that turnstile supposed to be in RDF?? Then obviously that is not 
valid. What could possibly support such a conclusion in RDF?

If it is supposed to be in OWL, then we need to be clear about which 
parts of the conclusion are OWL syntax and which are OWL assertions. 
Seems to me to be insane to require that OWL syntax be 
self-describing *in OWL*, so I wouldn't expect it to be valid in OWL 

What might be reasonable is that it is valid in what might be called 
OWL-in-RDF, ie the special language gotten by imposing the special 
OWL-in-RDF semantic conditions on the RDF rendering of OWL syntax; 
but then it would simply be the inference of a piece of OWL from a 
synonymous piece of RDF.

It seems to me that you are asking the 'layering' of OWL onto RDF to 
be impossibly ambitious: you want it to be an *implementation* of the 
syntax of OWL in RDF. If you want to impose that kind of condition, 
then ALL layering is broken, because RDF (or even FOL, for that 
matter) doesn't have the semantic moxie to support recursive 
evaluation processes. Moral: don't impose impossible conditions.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 25 February 2002 20:09:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:42 UTC