W3C home > Mailing lists > Public > uri@w3.org > April 2003

RE: We don't need no stinkin' identity

From: <Patrick.Stickler@nokia.com>
Date: Tue, 29 Apr 2003 09:35:32 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBBA3@trebe006.europe.nokia.com>
To: <phayes@ai.uwf.edu>
Cc: <LMM@acm.org>, <uri@w3c.org>

> -----Original Message-----
> From: ext pat hayes [mailto:phayes@ai.uwf.edu]
> Sent: 28 April, 2003 19:48
> To: Stickler Patrick (NMP/Tampere)
> Cc: LMM@acm.org; uri@w3c.org
> Subject: RE: We don't need no stinkin' identity
> >  > ...the reason Im howling so loud about this issue is that this
> >>  assumption (that URIrefs *must* by some magical process always be
> >>  uniquely grounded)...
> >>  ...
> >>  Again, the problem is not that the logic requires 
> unambiguity; quite
> >>  the reverse, in fact: it is that imposing unambiguity as 
> a defining
> >>  characteristic of URIs is logically incoherent.
> >
> >Pat, I just want to try to clarify one thing. When you are speaking
> >of ambiguity here, is it so that you are not speaking of overloading
> >of denotation, where the same URI is explicitly used to denote more
> >than one thing?
> Well, a symbol (URI) denotes one thing in one interpretation and 
> another thing, likely, in another interpretation. The referent is 
> unique *in each interpretation*, of course: no overloading there (as 
> when people want to say that '+' denotes both integer and real 
> addition at the same time, say.)  But if you just ask, what does it 
> denote IN FACT, independently of the interpretation, then I think you 
> do have to say that it denotes more than one thing at the same time. 
> It all depends on how you interpret it.

Well, why couldn't you just say that '+' denotes the abstraction
of "addition" and its realization (within the bounds of the generic
abstraction) depends on its operands?

I.e., there is no contextual interpretation, even if there might
be context-specific applications of that interpretation.

> (BTW, even overloading can be useful in its place, eg many strongly 
> typed programming languages use it, and there are ontologies which do 
> as well. In general, I think its a bad move to make very grand, 
> sweeping generalizations about the way that URIs *must* be used. 

Well, generalizations that are based on style, preference, and
the current weather, no. But generalizations that are IMO necessary
for reliable and consistent global consumption of knowledge, yes.

> There's a good chance that people somewhere will find a good use for 
> them that goes beyond what anyone can think of right now, and we 
> shouldn't be trying to prevent the world from being creative; and if 
> we aren't in the preventing game, but only trying to be descriptive, 
> then what we say will just be flat wrong.  Either way its a bad idea. 
> But I won't go the mat over this.)

I fully agree that saying less is better than saying more, when that
more is not absolutely essential. But I think that having a presumed
single globally consistent interpretation of URIs by all SW agents
is crucial to any semblance of global knowledge interchange. I just
can't see how it could be otherwise.

> >Rather, by ambiguity, you simply mean that a SW agent need not know
> >what the actual mapping from URI to thing is in order to use that URI
> >productively?
> Well, almost. I think that it is more accurate to say that in many 
> cases there is no single, unique such mapping. Its not a question of 
> knowledge, its a question of fact. (And to put the point more 
> strongly, its up to anyone who claims that there IS such a unique 
> map, to say how it is defined.)  But see below.

I disagree. Again, we are talking about presumptions, not garuntees.

My SW agents can presume that anytime they encounter a given URI, it
will always mean the same thing -- even if there is no explicit 
machinery, technical or social, either as part of the SW or external 
to the SW, which can either prove or garuntee that such a presumption
is in fact satisfied by any given set of uses of a given URI.

What is simply defined, as part of the SW architecture, is this
presumption. Not any machinery to enforce, prove, or garuntee it.

If users willingly or accidentally violate this presumption, then
SW agents will be negatively impacted. It's really that simple.

Overloading of URI denotations is simply bad, not impossible or
preventable -- and because it is bad, there should be clear and
unambiguous warnings and strong recommendations against it.

> >I myself fully agree with the latter case, that such ambiguity of
> >*which* thing is denoted is necessary. However (and feel free to
> >either agree or disagree) I feel that the former case, of overloading
> >of denotation, is highly undesirable and ultimately detrimental to
> >the SW.
> I think we agree, in fact. Let me say your thing my way and 
> see if it is OK.
> An interpretation maps a name to a (unique) thing. Interpretations 
> which map the same name to 2 or more things are bad(?? well, OK). 

Yes. And further, SW agents can presume that there is only one 
interpretation of a given URI (even if they don't know what the
URI means, or even if they get that interpretation wrong).

> URIs may have a single intended interpretation, but we might not know 
> what it is. In some cases it may be impossible to fully determine 
> what it is, and it might not matter what it is for some purposes.


> >I would like to see the URI specs capture both of the above in some
> >clear manner. I.e. (a) it is not always clear what thing a URI
> >denotes but that doesn't prevent the URI from being used effectively,
> >and
> Right
> >(b) using a URI to denote more than one thing is bad. These
> >are two different kinds of ambiguity, one being good/necessary, and
> >the other being bad/detrimental.
> If I follow you, than I kind of agree.

I think you do follow me, and I'm very happy that we seem to agree.



Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com
Received on Tuesday, 29 April 2003 02:36:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC