W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2002

Re: specifying literals

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Mon, 16 Dec 2002 10:10:23 +0000
Message-ID: <3DFDA68F.6090809@hpl.hp.com>
To: w3c-rdfcore-wg@w3.org

Ho, hum,

this relates to a number of messages over the weekend (from DanC, Graham 
and Pat).


The WG has *not* decided whether or not plain literals without language 
tags are or are not xsd:string's.

I believe that the plan is to resolve all problematic datatyping 
equivalences after last call, working with XML Schema WG. It would be 
stupid if xsd:anyURI was the same as an RDF plain literal, an xsd:string 
was the same as an RDF plain literal but that they were not the same.

I don't believe the WG should be pushed into a premature decision on this 

As the exchange between Graham and Dan has shown, the statement in the LCC 
This set of blank nodes, the set of all RDF URI references and the set of 
all literals are pairwise disjoint.
is crucial, and currently there is no other text in concepts that 
contradicts that.
Dan is proposing text that would contradict that, and hence his proposals 
on changing the literal definition must be rejected.
Without this, it is impossible to tell the difference between triples

I see this as completely orthogonal to whether or not the literal value 
denoted by a plain literal with no language component is or is not a 
string, and whether such a string is or is not an xsd:string which seems to 
be the heart of the issue.

The quoted sentence is crucial because given a triple we need to known 
whether the subject is a bnode or a URIref, and whether the object is a 
literal, a bnode or a URIref. Hence concepts distinuishes syntactically 
between a plain literal with no language tag and a URI reference by being 
clear that the former is not just a string, but is a structure with named 
components. Without this, there would also be potential confusion between a 
typed literal with no language tag, and a plain literal with a language tag.

Received on Monday, 16 December 2002 06:51:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:19 UTC