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

Re: datatypes and MT

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Thu, 8 Nov 2001 20:51:46 -0600
Message-Id: <p05101023b810f14f8025@[65.212.118.147]>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org
(Sorry reply is late, this slid off the top of my screen.)

>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 wish I knew, Brian. :-)

>  I've been happy to talk about an integer literal, e.g. the number 5.

Me too. I've been using double quotes because that is required in 
Ntriples syntax, but unlike Dan C., I wasn't interpreting them to 
really be quotation marks..

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

No, we just need to know that (for example) the range of eg:size is 
xsd:decimal. We don't need to do any other 'processing' in RDF. Of 
course, if something on the other side of an API wanted to know the 
actual *value*, we ought to tell it both the literal and the 
datatype; but as long as we do that, RDF has done all it can. I see 
any actual processing of schema information as being outside RDF 
itself. All RDF deals with are literals (not literal values) and 
names of datatype schemas (URIs like <xsd:integer>)

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

That is true, because the datatypes would have to be upward 
consistent if we use range information to fix the datatype.

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

True, that is one benefit of local typing in general: since it 
doesn't use any RDF reasoning about types, it needs to make no 
coherency assumptions. Datatypes are just labels, in effect, with no 
semantics in RDFS itself.

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

I confess I don't follow this point. Both schemes can represent 
everything in RDF/XML, I think. (If we only use range to specify 
datatyping, at any rate.)

>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

I don't think it does.

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

Not mutually inconsistent ones, eg hex and decimal, for the same 
property. (Because you have to choose one of them to be the range 
datatype.) However, if we could have literals as subjects we could do 
this using rdf:type on the literal itself. In fact, if I can have 
literals as subjects then I can systematically translate the S scheme 
into the P scheme (Anything you can do/ I can do shorter;/ I can do 
anything/ with less nodes than you.). But those literal subjects do 
break RDF/XML, I concede.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Thursday, 8 November 2001 21:51:43 EST

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