- From: <Patrick.Stickler@nokia.com>
- Date: Wed, 26 Feb 2003 10:29:33 +0200
- To: <phayes@ai.uwf.edu>, <jjc@hplb.hpl.hp.com>
- Cc: <w3c-rdfcore-wg@w3.org>
> -----Original Message----- > From: ext pat hayes [mailto:phayes@ai.uwf.edu] > Sent: 25 February, 2003 18:53 > To: Jeremy Carroll > Cc: w3c-rdfcore-wg@w3.org > Subject: RE: designating datatypes > > > > >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. And why would this be stated in any manner that is not opaque to RDF? If a URIref denotes an rdfs:Datatype, then we trust that that URIref always denotes the *same* rdfs:Datatype and the D-interpretation for a given lexical form per that rdfs:Datatype will be consistent. There is no need to know *how* the denotation is assigned. > 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? If you assert that xsd:integer rdf:type rdfs:Datatype . and the URIref xsd:integer denotes your Granny then either your Granny is an rdfs:Datatype or you have a semantically invalid rdf:type assertion. But the MT cannot *know* that your Granny is not in fact an rdfs:Datatype even though it may assume that if a resource is asserted to be an rdfs:Datatype, it is, and if it is not, then all bets are off. I.e., there is a basic premise for all D-interpretations that the URIref being used to denote an rdfs:Datatype actually *does* denote an rdfs:Datatype. If it doesn't, then that's not the MT's problem. D-intepretations are only valid IFF the datatype URIref actually does denote an rdfs:Datatype. And what if the URIref xsd:integer actually *was* part of the reality of your Granny (in some bizarre parallel universe ;-) how does that make the D-interpretation any more valid, since your Granny still is not in reality an rdfs:Datatype? I.e., if you can't *ensure* that what is denoted by a URIref is actually an rdfs:Datatype, having a lexical space, value space, L2V mapping, etc. then how does requiring it to also have an official URIref help? D-interpretations must presume that what is denoted is a valid rdfs:Datatype, and adding the URIref to the datatype does not help ensure that the URIref denotes an actual rdfs:Datatype one bit. > 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 > properly. > > 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; Then that is, I agree, a problem with the MT, but adding the URIref to the datatype resource itself is not going to fix that. > 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. I see this as a more fundamental problem. After all, how do you know that a URIref denoting an rdf:Property *actually* denotes a property? You don't. You just assume that an "P rdf:type rdf:Property" assertion is semantically valid. What about any other class assertion? It's the same. Either the assertion is true or it's false. If it's false, well, then any interpretations which have as a premise it's being true are of course also false. Surely this should be somewhere in the foundation of the RDF MT. > >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. See above ;-) I still don't see any reason to add URIrefs as part of the *definition* of rdfs:Datatype's. If the reliability of the denotation of a given URIref to an actual datatype is the problem, then I assert that the problem is general for all URIref denotations, and that the MT needs to be revised to address the problem globally. It may simply be a matter of defining specific premises for particular interpretations, based on the truth of certain rdf:type assertions, as outlined above. Patrick
Received on Wednesday, 26 February 2003 03:29:38 UTC