RDF datatyping

Sergey,

I've just looked through your 14-Dec datatyping document, and think this is 
a very useful basis for discussion, and even as a proposal.

I have a few comments...

..

As a discussion document, likely to evolve, I think it would be useful if a 
document revision and/or date was clearly stated (I had to cite the CVS 
modification date, which isn't so obvious).

..

Section 2.1

I think XML schema's use of 'facets' is more an artefact of it's style of 
defining data types than anything fundamental about the datatype value 
space, lexical space or mapping.  As such, I think that (apart from 
possibly a passing nod) discussion of facets is not needed in this document.

..

Section 2.1, 2.2

Unless we really need to (and I don't see that we do) I'd prefer not to get 
drawn into discussions of canonical datatype mappings and 
representations.  The fact that we have a way to talk about the denoted 
values directly seems to make this less of an issue for RDF than it is for 
XML in general.

I would also prefer that the datatype mapping is not required to be "onto" 
the value space.  This would make it easier to talk about datatypes whose 
value spaces are, say, all real numbers (for which no lexical space can 
have a mapping that is onto it), but for which we may wish to express as 
the solutions of certain classes of equation (e.g. x=sqrt(2), y=exp(1), 
z=arctan(1)*4 to describe a few popular irrational reals);  more 
immediately, I would like to have the option of using rational numbers as 
the underlying value space for numeric values -- something that I 
increasingly feel is a mistake in the way XML schema datatype numbers are 
defined.

..

Section 3

Drop canonical datatype mappings bullet point?

..

Section 4.0

"(a tidy graph ... the same URI-reference label)" -- insert URI-reference.

..

Section 4.2

I'm uneasy that you say a mapping is "named" with an "RDF property" -- it 
seems to me that that the property's URI reference is the name of the 
mapping.  A minimal change might be:
   after "using RDF properties", insert "(i.e. URI-references)".

..

Section 4.4

I think this section contains two assumptions that should be highlighted or 
stated more clearly:

(a) 1st paragraphs assumes that graph nodes labeled with literal strings 
denote the literal string itself (I think).  How else do the nodes thus 
labelled refer to members of the lexical space of datatypes?

(b) I think it is an assumption (with which I agree) that the semantics of 
literals and xsd:boolean.map are fixed, and this should be clearly 
stated.  Maybe at the start of section 4.

..

Section 4.5

2nd paragraph, "that is defines" -> "that it defines".

I think that the proposed naming structure is great;  it certainly makes it 
clear what one is talking about.  Referring to one of the open issues 
(section 4.10) I would also like to suggest:

For backwards compatibility with existing RDF, the base schema datatype URI 
can be used to denote the lexical space of the datatype (even though such 
use may be deprecated).  I.e. ICEXT(I(xsd:type)) contains the lexical space 
of the named datatype.

..

Section 4.9

(I think this captures the idioms and their relationship just nicely.)

In the penultimate paragraph:  supercede --> supersede (unless that's a US 
spelling I haven't encountered before).

....

For the rest of the group, my question is this:  do we just tidy up the "S" 
proposal and go with it, or do we need to discuss the alternatives?  I 
think proposal "S" works pretty well.  (If the latter, we would need 
descriptions of the alternatives to match Sergey's section 4, in particular 
showing how they work with the model theory.)

#g



--------------------------
        __
       /\ \    Graham Klyne
      /  \ \   (GK@ACM.ORG)
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/

Received on Monday, 7 January 2002 13:56:09 UTC