W3C home > Mailing lists > Public > semantic-web@w3.org > June 2007

Re: What if an URI also is a URL

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 11 Jun 2007 16:02:19 -0400
To: "John Black" <JohnBlack@kashori.com>
Cc: semantic-web@w3.org
Message-ID: <18040.1181592139@ubuhebe>


"John Black" <JohnBlack@kashori.com> writes:
> 
> Tim Berners-Lee wrote
> >
> >
> > On 2007-06 -09, at 21:22, M. David Peterson wrote:
> >
> >> On Sat, 09 Jun 2007 07:13:52 -0600, Tim Berners-Lee <timbl@w3.org>
> >> wrote:
> >>
> >>> No. It cannot identify both a document and a person.
> >>
> >> Tim: Will all due respect... WTF?
> >
> >
> > I am using the 'identify' in the strict sense of 'denote'.
> > The semantic web is like a logic language in which URIs are symbols.
> 
> Do you believe that by claiming to use the strict, logical sense of the word 
> 'denote' you thereby cause or require such denotations to be absolute and 
> unambiguous? Where do think denotations (or identifications) come from?

No, I think he just means that we're talking formal logic here, not
natural language.

> In my opinion to denote (or to identify) is a verb, something that is done 
> by the users of a symbol. After all, symbols (URI) are not agents, they 
> don't wake up and choose to denote this or that. Nor do I think denotation 
> is an attribute or property of a symbol, somehow built in or attached when 
> the symbol is first conceived. It is more like a dance. I use a symbol to 
> denote something expecting you to interpret it to denote the same thing. And 
> this coordination, this synchrony of interpretation by both sender and 
> receiver, is not always easy. It requires real effort to sustain it. The 
> minter of a URI cannot make it happen by declaration, nor can a research 
> group or a standards body just decree it so.
>
> The reason this matters is that since it requires this effort to create a 
> denotation/identification in the first place, it is far more sensible, to me 
> at least, to expect that the final disambiguation of a symbol be 
> accomplished in the same way, by coordinated effort of the parties using the 
> symbol, not by declaration of the W3C specifications that all URIs be 
> absolutely unambiguous. This seems to me to be, as my grandfather used to 
> say, a vain task.

You're misrepresenting what W3C does and what the specs say.  The most
clear and authoritative spec says:

    2.2.1. URI collision

    By design, a URI identifies one resource. Using the same URI to
    directly identify different resources produces a URI
    collision. Collision often imposes a cost in communication due to
    the effort required to resolve ambiguities. 

    Suppose, for example, that one organization makes use of a URI to
    refer to the movie The Sting, and another organization uses the same
    URI to refer to a discussion forum about The Sting. To a third
    party, aware of both organizations, this collision creates confusion
    about what the URI identifies, undermining the value of the URI. If
    one wanted to talk about the creation date of the resource
    identified by the URI, for instance, it would not be clear whether
    this meant "when the movie was created" or "when the discussion
    forum about the movie was created." 

    Social and technical solutions have been devised to help avoid URI
    collision. However, the success or failure of these different
    approaches depends on the extent to which there is consensus in the
    Internet community on abiding by the defining specifications. 

             - Architecture of the World Wide Web, Volume One
               W3C Recommendation 15 December 2004
               http://www.w3.org/TR/2004/REC-webarch-20041215/

So no one is outlawing ambiguous URIs.  I would argue, philosophically,
there's *some* ambiguity in all URIs.  But for lots of reasons (which
vary depending on your deployment context) it's a good practice to avoid
unnecessary ambiguity.

       -- Sandro
Received on Monday, 11 June 2007 20:02:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:57 UTC