W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2004

Re: RDF Semantics: corrections

From: pat hayes <phayes@ihmc.us>
Date: Tue, 13 Jan 2004 22:07:10 -0600
Message-Id: <p06001f19bc2a637530f8@[]>
To: Herman terHorst <herman.ter.horst@philips.com>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: jjc@hpl.hp.com, hendler@cs.umd.edu, schreiber@swi.psy.uva.nl, connolly@w3.org, sandro@w3.org, www-rdf-comments@w3.org, bwm@hplb.hpl.hp.com

Gentlemen, in trying to satisfy both of you I find myself in a 
dilemma, one which must be resolved in the very near future.  Let me 
try to put the technical case as clearly as I can, in order to 
resolve this in time in a rational way.

The issue concerns how to specify the class extension of a datatype 
name. Suppose x is a datatype, ie x=I(ddd) for some datatype name 
ddd.  Clearly all well-typed literals "sss"^^ddd in the vocabulary  V 
must denote something in the class extension.  Herman wants this to 
be the only requirement. This handles literal checking, but it does 
not handle datatype clashes, since this does not rule out, say, the 
class extension of xsd:string from overlapping with that of xsd:int; 
so, as Peter pointed out,

_:aaa rdf:type xsd:string .
_:aaa rdf:type xsd:int .

would be XSD-consistent; and this is not acceptable.  So we need to 
extend this condition in some way so as to rule this kind of case 
out: in other words, if the value spaces are disjoint, then the class 
extensions must be disjoint also.  (Peter's other examples involve 
subset relationships between value spaces, and in my view are more 
controversial: but the disjointness conditions must be retained.)

One way to extend this is to require that the class extension of x be 
a *subset* of the value space of x.  This seems to be the minimal 
extension which would handle datatype clashes appropriately.  But 
now, the finite-value class examples give difficulties for 
completeness arguments, since now the 'boolean' example is 

a p "true"^^boolean
a p "false"^^boolean
c type boolean
a p c

In order to block this, we would need to allow ICEXT(I(boolean)) to 
be a proper superset of the boolean value space.

It can't be both a subset and a proper superset.

Certainly, to abandon the datatype clash notion at this stage is not 
acceptable; and there seems to be little utility in requiring the 
subset condition without the identity condition (?); so my 
(reluctant) conclusion is that we should retain the semantic 
condition that  ICEXT(I(ddd))= the value space of x, when <ddd,x> is 
in D.  The other wording changes suggested by Herman can be retained, 
of course.

The apparent mismatch between the treatment of rdf:XMLLiteral in RDF 
itself and as part of a D-interpretation can be accounted for by the 
observation that the difference is only visible when there is more 
than one datatype present, which can only happen in D-interpretations.

Herman, do you agree with this decision? I can see no way around it. 
I know it hurts, but you are to consider that it may still be 
possible to state a general 'finite datatype' rule in order to 
achieve completeness; and that having 'extra' values in an 
interpretation is admittedly an inelegance, but does not of itself 
invalidate completeness (only make it more complicated to prove).

Peter, thanks for being so stubborn.

With this modification|2, no changes are now needed to any OWL documents.

The revised RDF document can be seen at


I have restored the elided text from section 7.4, amended the change 
log, and by the way fixed a couple of typos I noticed in the glossary.

Brian, I will give you a decision on whether to ask the WG about 2004 
or 2004a tomorrow at the latest, but I think 2004 a is the likely 

Comments by tomorrow, please. After tomorrow, discussion has to be 
closed on this.

IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 13 January 2004 23:07:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:22 UTC