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

The Peter paradox isn't.

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Fri, 15 Feb 2002 16:37:26 -0500
Message-Id: <p0510144eb8932390f82b@[]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, Dieter Fensel <dieter@cs.vu.nl>
Cc: webont <www-webont-wg@w3.org>
Peter's ingenious paradoxical example isn't really a paradox. It 
still has some bite, but the conclusion isn't as pessimistic as the 
dreaded p-word suggests.

Here's why, as comments inserted into an excerpt from
(section 4.2)

To cut to the chase, go to ****

>As this layering of OWL on top of RDF(S) is a same-syntax layering, 
>all OWL syntax is also RDF syntax, which is also the same as the RDF 
>Schema syntax. Therefore every syntactic construct has to be either 
>a URI, an anonymous node ID, a literal, or a triple. As the 
>semantics of OWL in this layering is an extension of the semantics 
>of RDF(S) the denotation of these constructs has to be the same as 
>their denotation in RDF(S) and the semantic constraints on them have 
>to include the semantic constraints on them in RDF Schema.


>  Further, as OWL classes are an extension of RDF Schema classes, the 
>OWL relationship from resources to their OWL classes must 
>incorporate the RDF Schema relationship between resources and RDF 
>Schema classes, namely rdf:type, and OWL classes must include RDF 
>Schema classes.

Not necessarily *all* of them. It would be perfectly fine for OWL 
classes to be an rdfs:subClassOf rdfs:Class. That is the case with 
RDFS and DAML, for example; one expects that the 'higher' language 
can place more restrictions on what is allowed to be a class, since 
it has more extensive descriptive powers.

>Let us call the property that is the OWL relationship from resources 
>to their types, owl:type, which can either be rdf:type or some 
>super-property of rdf:type.

It should not be a superproperty. It might be a subproperty (and its 
range might be an rdfs:subClassOf the range of rdf:type)

>Now consider entailment in this version of OWL. Suppose we have an 
>OWL interpretation that contains an RDF Schema class C, a property 
>P, and an object O that has no outgoing P relationships. OWL 
>contains the notion of a restriction of a property to a type, i.e., 
>given a property, say P, and a class, say C, it is possible to 
>create the restriction corresponding to those resources whose P's 
>all belong to C. Well O belongs to this restriction in this 
>interpretation because it has no P's and thus all its P's belong to 
>C. Therefore we need that any interpretation like the one above is a 
>model for O belonging to this restriction.

OK, but don't make the mistake of going from this to the claim that 
all models of the restriction must be like the above.

>However, restrictions are resources and thus this can only happen if 
>there is a resource that corresponds to the restriction, and that 
>includes O as a member. So, this simple interpretation will not be 
>correct unless it includes such a resource and the appropriate 
>owl:type relationships to it. Some of these restrictions can refer 
>to themselves, as there are self-referential loops in RDF Schema 
>classes and thus this cannot be ruled out in restrictions.

That last claim is technically wrong (self-membership is not 
self-application) but in any case irrelevant to your point. You don't 
use nonwellfoundedness in your example below.

>Thus OWL interpretations must include resources for many 
>restrictions, essentially all the restrictions that can be built out 
>of the classes and properties that are in the interpretation. As 
>well, OWL interpretations must have the correct owl:type 
>relationships to these resources. In this way, each OWL 
>interpretation must have a theory of restrictions, including 
>self-referential restrictions, and also other OWL constructs. We are 
>now in the same situation that the original formalization of set 
>theory was, as the following shows. Consider the restriction that 
>states it is precisely those resources that have at most zero values 
>for the property owl:type that belong to the class that consists of 
>the restriction itself. In the N-triples syntax for RDF,this is
>    _:1 a owl:Restriction .
>    _:1 owl:onProperty owl:type .
>    _:1 owl:maxCardinalityQ 0 .
>    _:1 owl:hasClassQ _:2 .
>    _:2 oneOf _:3 .
>    _:3 owl:first _:1 .
>    _:3 owl:rest owl:nil .
>This restriction, read slightly differently, is the restriction that 
>consists of those resources that do not belong to it. This is not 
>the paradoxical Russell set, but is paradoxical.
No it's not. What this IS, to be achingly precise for a second, is an 
RDF graph. The bnodes are interpreted in RDF as existentials, so what 
this says is that three things exist which satisfy some conditions 
involving the OWL vocabulary. The things in question are, in 
numerical order, an Owl restriction, an Owl class, and an RDF list. 
You have cleverly constructed this so as to guarantee that it must be 
false; those three things cannot all exist, in fact. I would be 
inclined to say that the owl:Restriction doesn't exist, since I'd 
rather let lists always exist, and the owl:Class seems harmless in 
itself.  You could resolve it other ways; but this isn't 
*paradoxical*, its just plain false (in OWL). So asserting it is like 
asserting (p and not p), which is kind of a dumb thing to do, but 
doesn't amount to a paradox.

I note, by the way, that this is perfectly consistent *as RDF*. That 
is, there are satisfying rdf-interpretations of it. (See Herbrand 
lemma in the RDF MT.) However, they apparently don't make the grade 
for being OWL interpretations. But we must be ready for this; this 
kind of thing is inevitable when we do any kind of layering of a more 
expressive language on a less expressive one.

>Consider any resource. If it belongs to the restriction then it does 
>not, but if it does not then it does. Just as with the Russell set, 
>if this restriction is in an interpretation then the class 
>membership relationship is ill-defined.

Just as with the Russell set, this is a contradiction which only 
becomes paradoxical if you give it the force of a definition rather 
than of a simple assertion. (You did that when you said "if it does 
not then it does". Why does it? Because the assertion says so? No, 
because *if you take the assertion as a definition of the 
restriction* then it would say so. ) But you should not give it such 
force, because RDF has no way to claim definitional status for its 
assertions. That is placing more of an expressive burden on it than 
it could possibly bear, and more than is justified by its model 
theory. You cannot even express 'iff' in RDF, let alone state a 
definition (which implicitly claims categoricity of its 
interpretations.)  RDF graphs cannot be taken to be *definitions* of 
OWL categories, or indeed of anything else.

>However, this restriction is in all OWL interpretations, because it 
>is constructed only from resources that must be in all OWL 
>interpretations. Therefore all OWL interpretations have an 
>ill-defined class membership relationship and thus this layering of 
>OWL is paradoxical.

The proper moral is that one cannot assume that just because an 
RDF-consistent RDF description of some OWL syntactic categories can 
be constructed, that therefore any actual OWL syntax satisfying that 
description is guaranteed to exist. It is possible to say 
OWL-nonsense in RDF-sensible RDF. Who would have thought otherwise?? 
The moral is that OWL needs to impose its own discipline on 
RDF-encoding of OWL syntax; it cannot give up the job to an RDF 
description of its syntax. However, this does not by any means imply 
that OWL syntax cannot possibly be *encoded* in RDF triples, 
transmitted as RDF, etc.  etc.; only that in order to reconstruct the 
OWL content from the RDF, you gotta have some knowledge of OWL syntax 
and OWL-to-RDF encoding techniques.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Friday, 15 February 2002 16:37:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:27 UTC