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

RE: designating datatypes

From: pat hayes <phayes@ai.uwf.edu>
Date: Tue, 25 Feb 2003 10:52:51 -0600
Message-Id: <p05111b05ba814cc8684c@[]>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org

>I think I agree with Patrick on this one.
>The last call WDs show a URI denoting a datatype but not part of the
>datatype denoted.

Lets forget about 'part of'. I don't even know what it means, 
exactly. All I want to be able to do is to refer in the formal 
semantic conditions to that URI that denotes the datatype, in order 
to say explicitly that a D-interpretation is required to make it 
indeed denote the datatype.

There is a real technical issue here.

Look, consider the URI "xsd:integer"  on the one hand, and the actual 
datatype xsd:integer on the other. Right now (in the LC MT) the 
datatype is defined to be a thingie consisting of two sets and a 
mapping between them. OK, but *what requires that that particular URI 
refers to that particular thingie??* There is no such condition in 
the LC MT, in fact: it is kind of hinted at, but not actually stated 
formally.  Consider the interpretation I which uses 'ex:damsillyname' 
to denote that datatype thingie, but interprets 'xsd:integer' as 
denoting my Granny. Is that an XSD-interpretation? I don't think it 
should be, but there isn't any actual semantic condition which 
excludes it in the LC MT. So all our datatyping test cases and 
closure rules are in fact broken, if we take the LC MT seriously: you 
can't rely on the datatype URI denoting the datatype; just being in D 
isn't enough to make sure the official name picks something out 

That is why the MT is indeed slightly broken. All I want to do is to 
fix it, and to do that I need a way of referring to 'the name' of a 
datatype; and to do that, I need to assume that datatypes come with 
names attached. And they DO come with names attached, in fact: if 
they didn't have a URI as a name, we couldn't use them in RDF. So Im 
not changing anything, just using what is already there.

>This appears to be in conformance with XSD.
>In the absence of a compelling example showing how that is broken, we should
>not change it.

See above.


IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam
Received on Tuesday, 25 February 2003 11:52:56 UTC

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