W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2003

RE: attempting to remove confusion RE: designating datatypes

From: <Patrick.Stickler@nokia.com>
Date: Thu, 27 Feb 2003 12:20:48 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBB42@trebe006.europe.nokia.com>
To: <phayes@ai.uwf.edu>, <bwm@hplb.hpl.hp.com>
Cc: <w3c-rdfcore-wg@w3.org>

> I'm happy to say that a datatype IS whatever 
> it always has been, but I also want to say that it HAS a name 
> (provided by its external maker) and that we are obliged to treat 
> that name as denoting that triple-thingie.
> ... We have consistently 
> obeyed this convention ourselves, of course, from day one: there's 
> never been any doubt that the URIref 'xsd:integer' really does refer 
> to the datatype xsd:integer, right?

My point has been that if the MT does not already say this, for
*every* resource, not just datatypes, then there is something
essential missing from the MT.

A URIref's denotation is immutable. It always denotes the same thing.

So if someone has said that xsd:integer denotes the XML Schema
integer datatype, then it always will, and the RDF MT should
account for that, without having to speak of datatypes in 

The denotation of xsd:integer is no different than the denotation
of rdf:type or dc:title or foo:bar. A typed literal "10"^^foo:bar
is semantically valid if "10" is a valid lexical form of the
datatype denoted by foo:bar, regardless of what the denoting URI
is, since it may be that

   foo:bar owl:sameAs xsd:integer .

If both foo:bar and xsd:integer denote the same datatype, then
both "10"^^foo:bar and "10"^^xsd:integer denote the same value.

But that has nothing to do with the URIref used to denote the datatype.

Surely the D-interpretation cannot and should not depend on the
particular URI used to denote the datatype in question. 

If the MT does not provide for the immutability of URIref
denotation, then it needs to be fixed, and that fix should
also fix the issue Peter seems to be raising about datatyping.
Received on Thursday, 27 February 2003 05:20:54 UTC

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