RE: Datatype proposal G (oh no!)

> -----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