- From: <Patrick.Stickler@nokia.com>
- Date: Fri, 30 Nov 2001 16:47:35 +0200
- To: GK@NineByNine.org, w3c-rdfcore-wg@w3.org
> -----Original Message----- > From: ext Graham Klyne [mailto:GK@NineByNine.org] > Sent: 30 November, 2001 07:20 > To: RDF core WG > Subject: Datatype proposal G (oh no!) > > > This isn't really a new proposal, so much as some extra > definitions that I > see as allowing proposal S to work with some naive usage of > RDF. It is my > attempt to pull together comments from other messages into a > single place > for consideration. Thanks Graham. Your examples here were very useful for me, to reenforce that I was actually understanding the S proposal correctly, which it seems that I was, fortunately ;-) In my comments below, I'm using the shorter 'PDU' to refer to the P+DAML+U (and future P++) related idioms, all defining the pairing of lexical form to data type. > ... > Thus, in N3, we might have: > > @prefix xsd-lex: <http://www.w3.org/2001/XMLSchema-datatypes#> . > @prefix xsd-val: <http://www.w3.org/2001/XMLSchema-values#> . > @prefix xsd-map: <http://www.w3.org/2001/XMLSchema-mappings#> . > @prefix ex: <http://example.org/> . > > xsd-lex:integer a rdfs:Class . > xsd-val:integer a rdfs:Class . > xsd-map:integer a rdf:property . > xsd-map:integer rdfs:domain xsd-val:integer . > xsd-map:integer rdfs:range xsd-lex:integer . In contrast to (PDU): xsd:integer a rdfs:Class . where the differentation between lexical space and value space is determined by context. RDFS rdfs:range and rdfs:subPropertyOf pertain only to the value space and a literal that is bound to a data type constitutes a member of the lexical space (a lexical form). Thus, separate URIs are not necessary to differentiate the two spaces. The bNode denotes the member of the value space. The literal denotes the member of the lexical space. The data type defines the lexical and value spaces. > _:number0 rdf:type xsd-val:integer . > _:number0 rdf:xsd-map "0" . > _:number1 rdf:type xsd-val:integer . > _:number1 rdf:xsd-map "1" . > : > (etc.) In contrast to: _:number0 rdf:type xsd:integer . _:number0 rdf:value "0" . _:number1 rdf:type xsd:integer . _:number1 rdf:value "1" . (etc.) > ex:person ex:age_in_years_as_string "10" . > ex:age rdfs:range xsd-lex:integer . > > ex:person ex:age_in_years > [ a xsd-val:integer ; xsd-map:integer "10" ] . In contrast to: ex:person ex:age_in_years_as_string "10" . ex:age rdfs:range xsd:integer . ex:person ex:age_in_years [ a xsd:integer ; rdf:value "10" ] . > What all this means is that there's nothing new to define for > RDF. But there *is* something new to define -- those separate URIs for lexical and value spaces and the mapping properties. Plus the new RDF property rdf:xsd-map. The PDU approach actually requires nothing new than already exists, i.e. the existing single URI for the data type, and the existing RDF/S vocabularies. Thus, for each data type, the S approach requires alot more work to accomplish the same results as the PDU approach, and requires new mechanisms. And who is going to be the authority for those new specialized data type URIs? Certainly we need a reliable authority to define them, and they should be grounded in the same namespace(s) as the existing URIs. Do we then set up another WG to revise/extend XML Schema to define them? What about other data type schemes? The one-data-type-one-URI view of the PDU approach seems far more economical to me and requires less change/action from existing vendors and RDF-related standards groups. Again, it's not that S couldn't be made to work, or that it doesn't have interesting and even attractive characteristics, but the key question is whether it is sufficiently superior to the other (more economical) alternatives to be worth the extra burden of use. Cheers, Patrick
Received on Friday, 30 November 2001 09:48:14 UTC