RE: designating datatypes

> -----Original Message-----
> From: ext pat hayes [mailto:phayes@ai.uwf.edu]
> Sent: 25 February, 2003 00:18
> To: Stickler Patrick (NMP/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: RE: designating datatypes
> 
> 
> >  > -----Original Message-----
> >>  From: ext pat hayes [mailto:phayes@ai.uwf.edu]
> >>  Sent: 21 February, 2003 20:09
> >>  To: Dave Beckett
> >>  Cc: w3c-rdfcore-wg@w3.org
> >>  Subject: designating datatypes
> >>
> >>
> >>
> >>  Dave, you might be interested in a change Im proposing to the
> >>  datatypes section in the semantics document, as follows, 
> in response
> >>  to a comment by Peter. It introduces the 'name' as an 
> integral part
> >>  of a datatype. This is a patch and if you can think of a better
> >>  terminology and a pointer to a suitable spec I  would be 
> delighted.
> >>
> >>  -Pat
> >>
> >>  ------
> >>  3.4 Dattayped interpretations
> >>
> >>  A datatype is an entity named by a uriref and 
> characterized by a set
> >>  of character strings called lexical forms and a mapping 
> from that set
> >>  to a set of values. (The built-in datatype rdf:XMLLiteral,
> >>  exceptionally, allows pairs in its lexical space.) 
> Exactly how these
> >>  sets and mapping are defined is a matter external to RDF.
> >>
> >>  Formally, we will describe a datatype d as a 4-tuple consisting of
> >>
> >>  1. A uriref called the name of d
> >>
> >>  2. A set of character strings called the lexical space of d
> >>
> >>  3. A set called the value space of d
> >>
> >>  4. A mapping L2V(d) from the lexical space of d to the 
> value space of
> >>  d, called the lexical-to-value mapping of d
> >
> >So you're telling me that
> >
> >    ex:foo daml:equivalentTo xsd:integer .
> >
> >is then semantically invalid,
> 
> No, its fine. The conditions don't say that you HAVE to use the name, 
> only that it is there to be used if you want to be sure of getting 
> that very datatype.

So, why don't we posit that e.g. all RDF resources are N-tuples
with the uriref denoting them as part of their definition?

I.e., an rdfs:Property is a tuple consisting of a uriref and
a term.

I find the manditory inclusion of the actual URIrefs denoting
datatype resources as part of the datatype definition both
a kludge and walking all over everyone elses lawn.

We're now saying that XSD datatypes actually contain/include
the URIrefs used to denote them, but the XML Schema spec says
nothing of the sort. It says they have a lexical space, a value
space, a mapping and they are *named* with particular URIrefs.

I've yet to see any convincing argument of the need for this.

> >  since the "name" in the formal
> >definition of xsd:integer is *xsd:integer* and I can't say
> >"10"^^ex:foo and given the above statement mean the same
> >thing as "10"^^xsd:integer?!!!
> 
> No, you can say that. And then normal DAML reasoning ought to let you 
> come to that conclusion, since it presumably should allow a reasoner 
> to substitute names known to be 'equal'. But it is asking rather a 
> lot of a DAML (or OWL) reasoner, to get inside RDF literal syntax, 
> and I bet that some of them wouldn't be able to handle it, in fact.
> 
> >If so, then I am adamantly opposed to this change.
> >
> >I've yet to understand Peter's need for this change, even after
> >a good deal of private interchange with him, and remain completely
> >unconvinced that this is necessary.
> 
> Well, I tend to agree, but he is most adamant that he wants it, and 
> it seems harmless to let him have what he wants. Nothing else breaks, 
> as far as I can see.

Well, there are all kinds of stuff *I* want in RDF, but I won't
get them.

Sorry, but I consider the proposed change to violate the very
basis of using URIs to *denote* resources and IMO Peter has failed
to demonstrate that this is needed.

I and others have asked for specific use cases which demonstrate
where something breaks. He has provided none.

So no matter how loudly he is shouting, it should not justify
this change.

> >It seems to me to be in direct conflict with the very core of RDF,
> >that URIs denote resources without any requirement that the URI
> >be an inherent part of those resources in any way.
> 
> The trouble is that datatyping uses the datatype URIs in a special 
> way: it needs them to be proper names, not just symbols that denote, 
> like logical constants. Logical names can be reinterpreted 
> differently, but proper names refer 'rigidly'. They need to have the 
> same denotation in ALL D-interpretations. (What these conditions do 
> is make this 'same in all D-interps' condition absolutely explicit 
> instead of its being implicit in the statement of the interpretation 
> mapping.)  And that does raise a legitimate concern about how one 
> gets a particular thing (a dataytpe in this case) so firmly attached 
> to a URI.  Ultimately I agree with you that this goes beyond our 
> remit to solve, but having the thing say what it's 'official'  URI 
> is, is just a kind of semantic handle for doing this. It doesn't stop 
> you or anyone else using another URI to refer to the thing, just like 
> you all call me "Pat" even though it says "Patrick John" on my birth 
> certificate.

Well Kriminy! who gets to say which URI is more official than another?!

How do you know how "en"^^xsd:lang denotes the English language?! Is
the typed literal part of the English language?

The authority that mints a URIref denoting a datatype says which 
datatype it denotes, and that's that. The URI doesn't need to be
part of the datatype for it to denote the very same datatype
for every D-interpretation. You seem to be suggesting that what
a given URI might denote can differ between different D-interpretations.
I thought one key quality of RDF was that the denotation of a given
URI never changes. It always means the same thing. And if the
creators of a datatype give it a certain URI, then that's final.
That URI always denotes that specific datatype, whatever that datatype
is. Period. End of story. 

The relationship between a given URI and the resource denoted by
that URI is something that should be expressed *IN* RDF, not buried 
in the semantics of the resource.

I consider the proposed solution a nasty kludge, and we should
not do it. If there is a need to express 'official' URIrefs denoting
particular resources (and I honestly don't see that there is any
such need), then whatever mechanism is adopted should be
global and generic, applied to *all* resources. Not just datatypes.

This need is IMO completely out of scope of RDF datatyping specifically, 
and I don't want to see datatyping cluttered with hacks to solve it
in that very narrow scope.

Perhaps OWL could address this issue. That seems a more appropriate
layer to express such things.
 
I even have a URI scheme you could use:

   uri:{someURI} rdf:type owl:OfficialURI .

I.e. the URI {someURI} is the official URI for denoting the resource
denoted by {someURI}.

Or one could simply define the authority controlling a given resource,
and if that authority is also the web authority for the URI denoting
that resource, then that URI is the 'official' URI, since that is
the URI specified by the authority.

So

   xsd:integer x:authority "www.w3.org" .

There. Now we know that xsd:integer is the 'official' URI since
the defined authority for the datatype and that of the URI are
the same.

> So is that OK, with that understanding that allowing an 'official' 
> name does not exclude the use of other names?

Fine if you can use other names, but I see no reason to posit
that the URIref is part of the datatype resource in order to
assert a particular URIref as being 'official'.

I am not the least motivated that this change is justified
and I am opposed to it because I consider it to needlessly
complicate RDF datatyping and because I do not feel that any
convincing arguments or use cases have been provided to demonstrate
any need for it. If 'official' URIrefs are needed for datatypes,
or other resourcs, fine, but this is not the way to do it, and 
whatever solution is chosen should not be limited only to datatypes
but work for every possible resource.

Patrick

Received on Tuesday, 25 February 2003 05:01:44 UTC