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

RE: We don't need no stinkin' identity

From: pat hayes <phayes@ai.uwf.edu>
Date: Mon, 28 Apr 2003 11:47:30 -0500
Message-Id: <p05210601bad305dce5e3@[10.0.100.12]>
To: <Patrick.Stickler@nokia.com>
Cc: <LMM@acm.org>, <uri@w3c.org>

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

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

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

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 Monday, 28 April 2003 12:47:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:31 GMT