RE: Datatype proposal G (oh no!)

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