W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

Re: datatypes and MT

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Sat, 03 Nov 2001 16:04:04 +0000
Message-ID: <3BE41574.1050300@hplb.hpl.hp.com>
To: Pat Hayes <phayes@ai.uwf.edu>
CC: w3c-rdfcore-wg@w3.org


Pat Hayes wrote:

[...]


>> But that is not how Sergey would write it.  He is proposing:
>>
>>   _:1 xxd:octal   "32" .
>>   _:1 xxd:decimal "26" .
> 
> 
> Oh, I see. That does indeed avoid this problem, but it also throws away 
> the advantages of the bnode way of doing things, since now it is 
> impossible to be neutral about datatypes. This forces the datatyping 
> information to be attached directly to the literal; the only place 
> literals can occur in an RDF graph is at the object end of links 
> labelled with a datatype.


I'm finding the terminology very confusing and may be using it incorrectly.

When we say literal what do we mean.  I've been happy to talk about an integer 
literal, e.g. the number 5.

> This seems to me to be simply a variation on 
> the idea of incorporating the datatype label into the literal itself, eg 
> by having literals be pairs of a datatype and a string. Like that 
> proposal, it forces datatype information to be given explictly and 
> locally, and makes it impossible to infer datatyping information from 
> other information in the graph, eg range information.


Ahh.  I see what you mean.  Here is a concrete difference between the two 
proposals; just what I've been looking for.

In Pat's proposal:

   <rdf:Description>
     <eg:size>16</eg:size>
   </rdf:Description>

Given an appropriate schema, we can infer that "16" is in decimal and denotes 
the integer 16.  However to do this, we need to process the schema information. 
  The schema would fix the lexical representation of the value of the property, 
so given the schema we could not choose to represent the number in hex:

   <rdf:Description>
      <eg:size>10</eg:size>  <!-- bad -->
   </rdf:Description>

In Sergey's proposal, we could write:

   <rdf:Description>
     <eg:size eg:hexint="10"/>
   </rdf:Description>

or

   <rdf:Description>
     <eg:size eg:decint="16"/>
   </rdf:Description>

or


   <rdf:Description>
     <eg:size eg:decint="16" eg:hexint="10"/>
   </rdf:Description>


Schema could still tell us that the value of the property eg:size was an 
integer, but would not tell us what lexical representation was used.  And we 
could have:

   <rdf:Description>
     <eg:size rdf:type="http://example/integer" eg:hexint="10"/>
   <rdf:Description>

which allows us to represent everything we need in RDF/XML without any schema 
processing at all.

Hmmm, some pro's, con's and features:

Pat's Proposal:

   pros:  o using schema can add datatyping to existing RDF idiom

   cons:  o requires change to RDF/XML to explicitly represent datatyping
            in the RDF/XML without schema processing

          o does not allow alternative lexical representations of a datatype
            for a given property

   feat:  o a hexint is a different datatype from a decint.  Values of type
            hexint are in a different class from those of type decint, though
            there could be a common super class Integer.

Sergey's Proposal:

   pros:  o can fully represent datatyping info in current RDF/XML syntax
            without schema processing

          o different lexical representations can be used to describe the same
            data value

   cons:  o requires use of a new idiom to represent datatyped values

   feat:  o the lexical representation used must be explicitly coded in the RDF;
            it can't be inferred from a schema.

Any more?

Brian









> 
> Pat
Received on Saturday, 3 November 2001 11:09:05 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:42:28 EDT