RE: designating datatypes

> -----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