RE: designating datatypes

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

Well, how do you talk about e.g. rdf:type or rdfs:subClassOf
or rdf:_43 ?

By the URIref, no?

Why do we need to posit any other name than the URIref denoting
the datatype.

Sorry, this must be a "math thing" that is outside the scope
of my understanding (or maybe not ;-)

I'm presuming that the MT would say

  I(uriref(x)) = x

How is a URIref different from a name? Aren't the names of RDF URIrefs?

Surely the MT is not saying that datatypes have both names *and* URIrefs
denoting them. Surely the name and URIref are one and the same.

Eh?

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

I consider it to break the consistent model of URIrefs denoting
resources without any requirement that the URIref be an inherent
part of the resouce denoted. I consider it to break the very
fabric of URIref denotation used by RDF.

And not making the change does not break anything. And we are at
last call, so it's pretty late to start changing the structure of
datatypes simply to give one single person a nice warm feeling...

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

IMO, it is most definitely not an editorial change. It is a change
to the very definition of what an rdfs:Datatype is. And as such
requires the agreement of the WG.

And I don't consider it any small issue (as my postings I'm sure
reflect ;-)

And I'm honestly a bit miffed that you would propose this as
an editorial change since I had previously expressed my strong
opposition to this in previous discussions on the list(s). It
should have been clear from those posts made a week or two ago
that it was not a small issue nor simple editorial change.

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

But that is *already* provided for! That's the way RDF works. Someone
says "the URI x denotes the resource y" and if that someone is the
"owner" of both the URI and the resource, then that URI is an
'official' URI for that resource. We don't need to posit that URI
as being *part of* the resource to infer that it is an 'official' URI.

There is no need for this change, and I consider the change to be
a mistake regardless. That's two reasons not to make it.

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

Sorry, I've yet to see any explicit use case or test case that
demonstrates there is any problem whatsoever, and until I do,
I am very unlikely to accept that there is one.

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

Exactly. But saying that xsd:integer is the official URI denoting
the XML Schema integer datatype doesn't need that URI to be part
of the datatype definition.

Naming a resource is completely orthogonal to its nature.

There is not, nor ever should be, any requirement for the naming
of a resource by a URI to affect the nature of that resource.

This seems such a fundamental principle that I'm boggled we are
even discussing this proposed change as reasonable!

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

EXACTLY!

The mechanisms for associating a given URIref with a particular
resource are *bootstrapping* mechanisms outside the scope of RDF,
or any layer based on RDF (including OWL).

We might be able to infer some of those mechanisms based on e.g.
examination of individual URIs (violating the opaqueness of those
URIs) but exactly *how* a given URIref is defined as denoting a
given resource is outside the scope of RDF.

URIrefs are atomic. They just *are*. And they denote what they denote.
How they denote what they denote is not visible to the RDF layer.

Come one. This is pretty fundamental stuff, no?

If Peter want's to extend RDF to deal with sub-atomic particles, fine,
but that's not our job and certainly not something to do at the last
minute.

Sorry, too late, not sufficient justification, no demonstrated problem,
no time to consider ramifications (technical, practical, or philosophical).

The answer to Peter's proposal should be a solid 'no'.

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

You can't because it happens outside the scope of RDF. 

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

But it's not part of the datatype *definition*. The XML Schema
specification defines a set of datatypes, and in addition, gives
specific URIrefs to be used to denote those datatypes. 

It does *NOT* define those URIrefs are being *PART OF* those datatypes.

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

The name is the URIref, no?

I just don't see why the MT needs some other name but the URIref.

I think your foot has fallen through the floor of the atomic
foundation of RDF ;-)

URIrefs are the only names you have, and the only names you need.

Whether a given datatype (or any resource) has an 'official' URIref
to denote it should not affect the MT. If a URIref denotes a given
datatype, then that is the datatype you have. And the URIref denoting
it is the only name you need -- whether or not it is an 'official'
name.

All D-interpretations dealing with the same datatype will have
the same interpretation. And whether a given datatype has one or
more names, the D-interpretation should be based on the datatype,
not the name denoting the datatype.

What you seem to be suggesting really worries me.

If I have ten different URIs denoting some person 'Bob', I would
expect that asking about the ex:father of Bob to have a consistent
interpretation, regardless of which URI I used to denote Bob in
the given query. And the MT shouldn't care about whether I used
an 'official' URI to denote Bob. All it should care about is that
I denoted Bob and Bob has a certain property ex:father. And of
course, likewise the 'FATHER' property could itself be denoted
by numerous URIs, and again, all that matters is that I am dealing
with a person resource Bob and a property resource FATHER and
interpretations are based on those resources, not the URIrefs
denoting them.

Right?

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

Well, try to say it without having to embed the URIref as part
of the Datatype. It seems to me that if this is a problem with
D-intepretations, then the same problem must exist for all
interpretations.

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

Eh? What? I hope you're talking about some theoretical mathematical
possibility and not the reality of RDF.

In RDF, a given URI always denotes the same thing. You could have
different Model Theories that had those URIs denoting different
things, sure, but I'm presuming that the official RDF MT is supposed
to ensure that in a valid RDF interpretation, a given URI always
denotes 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.
> 
> No, which is why we need to say this explicitly.

Then it needs to be sated explicitly for all resources, not just
Datatypes.

Surely there is some foundational statement in the MT that expresses
the constraint that in RDF interpretations, a given URI always denotes
the same thing.

???

If not, then I would consider that a bug in the MT.

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

If that goes beyond RDF, then so does this proposed change.

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

Uh. Are you saying that OWL can't extend RDF?

OWL already includes machinery for expressing things that cannot
be expressed in RDF -- heck that's the whole point of OWL.

RDF lets you say "X is a property". OWL let's you say further
"X is a unique property", etc.

RDF lets you refer to a resource by URIref "X". OWL *could* let
you say "X owl:authority Y" and by URIref inspection, IF Y
is the web authority of the uri:X, THEN "X rdf:type owl:OfficialURI"

I hardly see how that violates RDF in any way.

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

But we always assume that *ALL* resources we talk about with RDF
have a URIref to name them!

How are datatype resources any different?!

I am presuming that the MT treatment of D-intepretations is
based on the datatype resources themselves, not on the URIref
being used to denote them. If it is based on the URIrefs, then
something is not 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.

But this is fundamental to RDF, not specific to datatyping, and the
proposed change is positing that those URIrefs are *part of* the
actual definition of the datatype -- and they are not, nor should
they be required to be.

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

IMO, of the MT does not provide globally and generically for the
consistent and immutable denotation of URIrefs, then it is not
complete. So if the MT is not saying that a given URIref always
denotes the same thing in all RDF (and higher) interpretations
then I raise this as a last call issue to be corrected/added in 
the MT, or Peter's issue can be expanded to indicate this broader
fundamental omission in the MT.

Cheers,

Patrick

--
Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com

Received on Wednesday, 26 February 2003 03:13:00 UTC