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

Re: datatypes and MT

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Fri, 2 Nov 2001 11:22:33 -0600
Message-Id: <p05101013b808854da914@[65.212.118.166]>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org
>Pat Hayes wrote:
>
>[...]
>
>>2. Bnodes as literal values.
>>
>>Let me put together here under one heading a variety of variations 
>>of the following theme: that occurrences of literals in value 
>>position in a triple should be understood as an abbreviation of a 
>>pair of triples with an 'intermediate' bnode, where the bnode 
>>denotes the triple value and the literal label itself is relegated 
>>to a minor role of somehow 'illustrating' how that value could be 
>>written in some notation. For example: rewrite
>>
>>aaa bbb lit .
>>
>>as
>>aaa bbb _:1 .
>>_:1 rdf:value lit .
>>
>>Before analyzing this, I note that it has the advantage of putting 
>>a node that denotes the literal value in subject position, where 
>>other properties (such as rdf:type) can be asserted of it. This is 
>>indeed a major advantage - I think the *only* advantage - of this 
>>proposal, but we could render this moot simply by declaring that 
>>RDF shall allow literals in subject position. I will return to this 
>>point later.
>>
>>The first of these triples seems easy to interpret: it means 
>>exactly what the original triple meant, in fact. It's the second 
>>triple that seems rather odd. Since _:1 is supposed to denote the 
>>literal value, it would seem to have the same value at both ends.
>
>
>That is not how I would read it.  The blunt end denotes a value from 
>the value space of whatever type of literal we have, e.g. an 
>integer.  The sharp end denotes a string.  The range of rdf:value 
>would be xsd:string or some such, and this fact would likely be 
>built into processors.

OK. that is another way to understand it, I agree.

>
>
>>
>>Another way is to insist that the literal label in the second 
>>triple is treated in a nonstandard way: rather than denoting a 
>>literal value, it is being mentioned rather than used; it simply 
>>indicates the literal itself. (Or, equivalently, all literals are 
>>treated as strings.) The intuitive meaning of rdf:value is then a 
>>kind of inversion of the denotation mapping itself: it assigns a 
>>literal label to the literal value that is the semantic value of 
>>that label in the given interpretation. This seems to be what 
>>Sergey has in mind, and it is also I think what Dan C. suggested a 
>>while back as the best way to handle literals.
>>
>>Now, this seems to me to have a fatal flaw, which arises from the 
>>fact that the value spaces of two different datatypes might 
>>overlap. For example, suppose that there are datatypes xxd:octal 
>>and xxd:decimal, then the following would seem to be perfectly true:
>>
>>_:1 rdf:type xxd:octal
>>_:1 rdf:type xxd:decimal
>>_:1 rdf:value "32"
>>_:1 rdf:value "26"
>
>
>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. 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.

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 Friday, 2 November 2001 12:22:36 EST

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