W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > May 2003

Re: Semantics Spanner

From: pat hayes <phayes@ai.uwf.edu>
Date: Mon, 19 May 2003 10:46:25 -0500
Message-Id: <p05210602baed6051e218@[]>
To: Jeremy Carroll <jjc@hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>

>On another list, it has been claimed that the current RDF MT editors draft has
>non-monotonic datatyping.

I presume you mean 
I am sending this to both lists in order to facilitate communication.

>If this is the case then it should be fixed.

Yes. I have (just) discovered this trail (thanks, guys, for not CCing 
me with any of these messages) and there is indeed a bug. There are 
two fixes, the short fix and the longer one.

The short fix is simply to correct an editorial slip-up in section 
3.5 (vocabulary entailment); the first line reads:

S rdf-entails E (S rdfs-entails E, S D-entails E) when every 
rdf-interpretation (every rdfs-interpretation, every interpretation 
datatyped with respect to D) which satisfies every member of S also 
satisfies E.


S rdf-entails E (S rdfs-entails E, S D-entails E) when every 
rdf-interpretation (every rdfs-interpretation, every 
D-interpretation) which satisfies every member of S also satisfies E.

That is, the condition on rdfs:Datatype is not included in the 
entailment truth conditions.

(This is why that particular condition (on rdfs:Datatype) was 
isolated from the rest in the current account, BTW. The distinction 
between D-interpretations (no reference to rdfs:Datatype) and 
interpretations "datatyped with respect to D" was made in order to 
remove this problem from the older formulation.)

HOWEVER....reading the email trails that this message has produced 
has made me realize that even with this fix, the intentions of this 
section are not sufficiently clear, and that I was trying to be too 
cute/clever by making this distinction, so I have rewritten the 
section so as to remove it. This is the longer fix, now incorporated 


Summary.  (1) The definition of D-interpretation now contains the 
'necessary' half of the rdfs:Datatype condition. (Omitting that was 
clearly a mistake, in retrospect, as it was an unnecessary change to 
the old design and would have violated some of the test cases.)
This means that various assertions about datatypes being in 
rdfs:Datatype are indeed true in all satisfying D-interpretations (eg 
if you interpret with respect to XSD, then
xsd:integer rdf:type rdfs:Datatype .
is always true) as you would expect; but the reverse is not the case, 
ie it is not the case that if you interpret this not with respect to 
XSD, then that assertion must be false (it might be, but might also 
not be; it depends on the interpretation.)

(2) I have abandoned the term  'datatyped with respect to' and the 
associated semantic condition - the other half - since I think that 
to give this idea such an appealing name is probably more likely to 
be misleading than useful.

(3) As a replacement, I have rewritten the text which described the 
idea of using rdfs:Datatype to 'declare' a datatype. This was 
intended to convey an intuition which is useful but may be been the 
root cause of the trouble, so I have presented this differently, in 
terms of a 'natural' transition from rdfs- to D-interpretations.

Comments are welcome on this new text, which uses "MAY".
(see http://www.coginst.uwf.edu/~phayes/RDF_Semantics_Editors.html#lcc22l1 )

>Thus, supporting an additional datatype foo, negates previously valid
>entailments, and hence causes a datatyped system to layer non-monotonically
>on top of a datatyped system.

That was not the intention; I hope that the corrections make things clearer.

>I personally find this a credible critique that should be taken seriously.
>We may need to leave open any semantics issues affected :(
>The (cryptic) examples given in
>concern the minimal datatype system consisting of only rdf:XMLLiteral, and so
>xsd:int plays the role of foo above.
>I note that this comment is based on the shadow space draft rather than Pat's
>master copy - we may hope that magic has happened.

The master copy (dated May 18) now has the corrections noted above, 
which I think fix the problem, though maybe not by magic.


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@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam
Received on Monday, 19 May 2003 11:46:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:22 UTC