Re: RDF Semantics: corrections

From: pat hayes <phayes@ihmc.us>
Subject: Re: RDF Semantics: corrections
Date: Tue, 13 Jan 2004 22:07:10 -0600

> 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 
> rejuvenated:
> 
> a p "true"^^boolean
> a p "false"^^boolean
> c type boolean
> |=
> a p c

Ummm, what ``difficulty'' is this?  I am not aware of any completeness
argument(s) for RDF datatyping.  

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

Why would one even WANT to block this?  It seems like an eminently
reasonable inference to make.  If one wanted to block this argument why not
just require that the denotation of URI references is disjoint from LV?
Problem solved!  

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

Sounds about right.  But I still don't see why it shouldn't be the set
itself. 

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

Good.  I haven't seen any reason to abandon it.

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

Well, I suppose you could have several infinite datatypes that only
differed on values that had no literal form.

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

Good.

> The revised RDF document can be seen at
> 
> http://www.ihmc.us/users/phayes/RDF_Semantics_2004a.html
> http://www.ihmc.us/users/phayes/RDF_Semantics_2004a.html#defDinterp

I hope that there are no noticable changes to RDF here.

> 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 
> contender.
> 
> Comments by tomorrow, please. After tomorrow, discussion has to be 
> closed on this.
> 
> Pat
> -- 
> ---------------------------------------------------------------------
> 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


Peter F. Patel-Schneider
Bell Labs Research

Received on Wednesday, 14 January 2004 04:56:11 UTC