- From: Graham Klyne <GK@NineByNine.org>
- Date: Fri, 30 Nov 2001 16:41:00 +0000
- To: Patrick.Stickler@nokia.com
- Cc: w3c-rdfcore-wg@w3.org
At 04:47 PM 11/30/01 +0200, Patrick.Stickler@nokia.com wrote: >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 ;-) That's if *I'm* understanding it correctly ;-) >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. I'm not sure that I follow this -- if it works it seems like a very complex approach. What's wrong with having separate URIs? It certainly seems much simpler to me, and as far as I can tell depends on just the model theory that is already specified. What's the value of overloading a single URI to serve these different purposes? [...] >In contrast to: > > _:number0 rdf:type xsd:integer . > _:number0 rdf:value "0" . > _:number1 rdf:type xsd:integer . > _:number1 rdf:value "1" . > (etc.) This overloads the property rdf:value ... if I follow your intent correctly, it would be used with a subject of any data type. For example, consider just decimal and octal representations of integers: then the relational extension of rdf:value must contain: { <1,"1">, <2,"2">, ... ... <8,"8">, <9,"9">, <10,"10">, <11,"11">, ... (for decimals) ... <8,"10">, <9,"11">, <10,"12">, <11,"13">, ... } (for octals) (where unquoted numerals here denote the corresponding numbers per decimal representation) This completely fails to capture the distinction between octal and decimal representations. Anything else requires a fundamental rework of the model theory for RDF properties (or at least for rdf:value) which is not something we have on the table. Also, it's not how I understand the P approach would work. > > 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. That's no more that one has to do when constructing any vocabulary for use with RDF. It does not, in any way, affect the basic syntax and semantics of RDF as currently proposed. >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. But it does: it requires revised semantics for rdf:value to work the way you want it to. Maybe that's possible, but I suspect it would be really tough to get the formal semantics just right. It might also require some extension to the fundamental abstract syntax of RDF, to recognize the special role of rdf:value. >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. Allocating an additional RDF class and an additional RDF property doesn't seem to me like a lot of extra work in the overall scheme of things. The really hard work -- defining the lexical representation and how it maps to the value space -- has to be done in any case. >And who is going to be the authority >for those new specialized data type URIs? Anyone who wants to. > Certainly we need >a reliable authority to define them, We do? Whatever happened to anyone can say anything about anything? >and they should be grounded >in the same namespace(s) as the existing URIs. Absolutely not -- they're just classes and properties like any other, and can be grounded an any suitably defined namespace. > Do we then set >up another WG to revise/extend XML Schema to define them? I see no cause for that (unless W3C so chooses for reasons nothing to do with RDF). >What >about other data type schemes? Anyone can define them. It's just RDF vocabulary. >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. What price a URI (or two, or three) ?-) I can't speak for existing vendors, but I disagree that PDU is less change for existing RDF standards. >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. From where I sit, the burden is on the other foot. #g ------------------------- __ /\ \ Graham Klyne / \ \ (GK@ACM.ORG) / /\ \ \ / / /\ \ \ / / /__\_\ \ / / /________\ \/___________/
Received on Friday, 30 November 2001 16:20:03 UTC