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.

Well, in a sense we do: we say that I(rdfs:Property) = <whatever>, so 
we associate the uriref with the thing it denotes.

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

Thats exactly what Im saying, down to the choice of wording. But the 
point is that in the case of datatypes, something EXTERNAL to RDF 
gets to say what the 'name' is, and our interpretations ought to be 
sensitive to that: we require that all our D-interpretations give the 
appropriate meaning to those 'datatype name' URIs, is all. Heres the 
current condition on D-interps (in the editors draft:)

if x is a datatype in D, then in any D-interpretation

I(name(x)) = x

Unless I am able to talk about  "the name" of a datatype, I can't 
even state this condition. If we don't say something like this then 
theres nothing to stop a D-interpretation treating 'xsd:integer' as 
referring to my grandma, and using some other URI to refer to the 
actual datatype. But we don't want that kind of freedom to re-name 
other people's datatype URIs, right?

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

:-)  BUt seriously, this is only because other folk thought they 
would break something. Whereas I don't see this as breaking anything. 
In fact, its such a small issue that I was going to treat it as 
editorial. I think you are seeing something much larger than is 
really being talked about.

>
>Sorry, but I consider the proposed change to violate the very
>basis of using URIs to *denote* resources

No, really, it doesn't. It just says that whoever invents the 
datatype also gets to say that some URI denotes (refers to) it, and 
we agree to go along with that.

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

I think that all our present use cases in fact use this convention, 
and always have done, but we never noticed the need to make it 
explicit before.

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

Whoever invented the datatype. Who gets to say what 'xsd:integer' means?

>How do you know how "en"^^xsd:lang denotes the English language?!

Because, presumably, some standards body has published a list of 
language tags and defined "en" to mean English, and we agree to go 
along with that.

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

Right, and that's all Im wanting to make explicit here. But without 
referring to that 'name' somehow, I can't make it explicit.

>The URI doesn't need to be
>part of the datatype

Its part of the datatype *specification*: its in the list of things 
that RDF needs to assume about a datatype. If there was a datatype 
with no URI to name it, RDF wouldnt be able to use it.

>for it to denote the very same datatype
>for every D-interpretation.

Unless I can refer to "the name" of a datatype, I can't state this 
semantic condition. (I could do it separately for each datatype, of 
course, but I can't state it as a *general* condition.)

>You seem to be suggesting that what
>a given URI might denote can differ between different D-interpretations.

Right, it can unless we say it can't. That's what I want to say.

>I thought one key quality of RDF was that the denotation of a given
>URI never changes. It always means the same thing.

Not at all: it can vary from interpretation to interpretation.

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

No, which is why we need to say this explicitly.

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

That would be a lot better, in a perfect world; but I don't see this 
as something that we can do. It goes way beyond just RDF.

>
>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 don't agree. OWL is obliged by charter to conform to RDF, and 
this is an issue that is incorporated into the very syntax of RDF.

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

OK, don't call it 'part of'. Call it 'the URI of', or 'the name of', 
will that be better?

>  the datatype resource in order to
>assert a particular URIref as being 'official'.
>
>I am not the least motivated that this change is justified

I can't write the MT properly without it, is my justification; and 
also it doesn't seem to me to be a change, only a clarification of 
existing intent. We have always assumed that datatypes came with a 
URIref to name them, right?

>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

? But this does not set out to PROVIDE a way to attach names, only to 
acknowledge that when it is done, somehow by somebody, that RDF is 
required to go along with it.

>, and
>whatever solution is chosen should not be limited only to datatypes
>but work for every possible resource.

Well, I guess we COULD make a larger change and introduce the idea of 
a 'name' in basic RDF, require RDF to treat 'names' properly, and put 
in a new batch of test cases and suitable prose into Concepts and 
Primer. Now, someone call an ambulance to attend to Brian, and then 
lets get started....

>
>Patrick

Pat
-- 
---------------------------------------------------------------------
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:26:34 UTC