RE: larry's position on URIs as names

re inline comment:
JAR
>> 2) http: URIs make reliable names only when HTTP exchanges with the
>> URI as request-URI play no role in determining what they name.


LM:
> I don't understand what you mean in "determining what they name".
> I think of the act of party A sending party B a URI as a speech
> act. Party A has some idea of what they want party B to understand,
> sends a URI  X to party B, and party B interprets the URI X
> in some context.  Something is 'reliable', I guess, if it's
> useful for communication and the two parties are interoperable.
>
> If I send you "http://larry.masinter.net" and you *don't* actually
> use the HTTP protocol to retrieve the web page there, well, what
> *do* you use? The DNS WHOIS database?

> How about a web cache?  Or maybe the 'representation' was bundled as
> part of a software installation, and never sent over HTTP.  Or maybe a
> different protocol such as some fancy high-performance successor to
> HTTP was used. Or maybe the URI is being used for coreference and not
> in relation to 'representations' at all - e.g. a namespace URI.

> I think this is a theme that Roy has been pounding on for years now,
> so you are probably familiar with it. If you haven't bought into it so
> far, well OK, I'll accept that as being your position, as this is a
> matter of judgment, not fact. But there are consequences to the
> position that are sort of inconvenient.

URIs are not uttered completely without context. Just as the
context of a word in natural language can determine its meaning
in that context, the same can be true of URIs.

While was a design goal of URIs to be "uniform"--to carry the same
meaning in all contexts--  meeting this design goal depends on the
designers of URI contexts to share and meet that design goal.

The hypermedia context (as a hyperlink in HTML, PDF, installed 
software) includes the possibility of web caches, and web caches
are expected to be (relatively) transparent, the purpose of the
cache is to optimize the transaction without changing the meaning
or results. 

The XML namespace design creates a context where the meaning of
a URI in an xmlns is different than the meaning if the URI were 
to appear in a@href or img@src.  This part of the XML namespace
design is not without controversy, detractors, and negative
consequences.

The URIs in

<img xmlns="http://image.example.com/jar"> and
<img src="http://image.example.com/jar"> 

have different meaning, "identify" different things (the former
a namespace, the latter an image). It is definitely inconvenient.
It's inconvenient that the lifetime of reliability for
URIs-as-hyperlinks doesn't always meet the requirements for 
reliability lifetime of XML namespace designations; it is
inconvenient that URIs-as-hyperlinks are intended to be
accessed, while URIs-as-namespaces are not. It is convenient
that the process of obtaining a namespace name is usually
well understood. It's inconvenient that there is still no 
general agreement about good operational practice for what,
if anything, to put as the retrieved resource for a namespace
URI. 

I'm not sure what I'm not buying into, though. I agree that
a "http" URI doesn't always imply using the HTTP protocol to
access the data from the origin, but I also think that the
variation in meaning is mainly disambiguated by the context
of use.

Does that help?

Larry
--
http://larry.masinter.net

Received on Tuesday, 18 May 2010 15:59:56 UTC