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

Resolving semantics issues (pfps-01,-03,-05,-09,horst-01)

From: Graham Klyne <gk@ninebynine.org>
Date: Thu, 15 May 2003 14:31:16 +0100
Message-Id: <>
To: pat hayes <phayes@ai.uwf.edu>, w3c-rdfcore-wg@w3.org
Cc: Brian_McBride <bwm@hplb.hpl.hp.com>

[Brian, as requested...]

Summary:  modulo a very small suggested wording change, I agree that Pat's 
comments do address the issues raised.

I've added some links to the issues and other material in my commentary below.

At 16:45 14/05/03 -0500, pat hayes wrote:
>re. issue pfps-01, I propose that we accept it, and note that it has been 
>addressed by the following text (between **-**):
>The datatype map which also contains the set of all pairs of the form
>< http://www.w3.org/2001/XMLSchema#sss , sss>, where sss is a built-in
>datatype **which has well-defined lexical and value spaces and a
>lexical-to-value mapping and** is named sss in XML Schema Part 2: Datatypes
>[XML-SCHEMA2], eg decimal, string, is referred to here as XSD.


I suggest a minor change to emphasize what I think is the intent here:
"... where sss is a built-in datatype that has well-defined lexical and 
value spaces and a lexical-to-value mapping,  and is named sss in ..."

(i.e. use "that" rather than "which", indicating that the following phrase 
is part of the defining expression rather than just additional informnation.)

>re. issue pfps-03, I propose that we not accept it and note that the 
>purpose of the appendix is informative (for a certain class of readers) 
>rather than definitive. The document states:
>"The editor believes that both of these descriptions, and also the closure
>rules described in section 4, are all in exact correspondence, but only the
>directly described model theory in sections 1- 3 should be taken as


Agree.  (Hopefully, in time, others will do more work that will allow 
developers to use this with greater confidence.  Meanwhile I agree that 
without it an important class of readers may be excluded.)

>re. issue pfps-05, I propose that we accept it and note that it is 
>addressed by rule rdfs1 in section 4.2 of the editor's draft.
>(Jeremy, the cases you mention
>rdfs:Literal rdfs:subClassOf rdfs:Resource
>rdfs:Class rdfs:subClassOf rdfs:Resource
>follow from the range constraints on subClassOf, which require 
>rdfs:Literal and rdfs:Class both to be of type class, then rule rdfs7a.)



I agree, though I had to dig to find the full closure, using:
   rdfs1 +  rdfs3 + rdfs7a + rdfs9

   rdfs:subClassOf rdfs:range rdfs:Class .       (sect 3.3 axiom)
   rdf:XMLLiteral rdfs:subClassOf rdfs:Literal . (sect 3.3 axiom)
   rdfs:Literal rdf:type rdfs:Class .            (by rdfs3)
   rdfs:Literal rdfs:subClassOf rdfs:Resource .  (by rdfs7a)

then, from rdfs1, we have:
   _:nnn rdf:type rdfs:Literal
   _:nnn rdf:type rdfs:Resource                  (by rdfs9)

which completes the closure Peter noted was missing.

>re. issue pfps-09, I propose that we accept it and address it with the 
>text in section 3.4 of the editor's draft, viz.
>"RDF provides for the use of externally defined datatypes identified by a
>particular URIref.
>Formally, let D be a set of pairs consisting of a URIref and a datatype such
>that no URIref appears twice in the set, so that D can be regarded as a
>function from a set of URIrefs to a set of datatypes: call this a datatype



I don't understand the second paragraph of Peter's comment, but from the 
first I think the issue is to formalize the idea that a datatype must 
provide a URI by which it may be referenced.

I agree that the text addresses this issue.

>re. issue horst-01, I propose that we accept it and address it by 
>reference to the rule rdfs12 in the current editor's draft, together with 
>a note that the proof of the rdfs entailment lemma will discuss issues 
>arising in the subsequent email trail following this comment, with details 
>to be given in a later response.



I sketched a derivation of the missing closure in a previous message to 


and hence agree that adding closure rdfs12 provides a closure for the 
entailment noted.


Graham Klyne
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
Received on Thursday, 15 May 2003 09:40:27 UTC

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