W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2004

Re: URI: Name or Network Location?

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 21 Jan 2004 14:42:56 +0200
Message-Id: <56ADA99A-4C0F-11D8-88B7-000A95EAFCEA@nokia.com>
Cc: www-rdf-interest@w3.org, "Thomas B. Passin" <tpassin@comcast.net>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>
To: "ext Sandro Hawke" <sandro@w3.org>


On Jan 21, 2004, at 13:10, ext Sandro Hawke wrote:

>
>
>> It may very well be that a URL can be used to denote a 'location'
>> (since a URI can denote anything) and that dereferencing it provides
>> a representation of that location (which may very well be the thing
>> located at that location), but a URL does not inherently (and I
>> think rarely does in actual practice) denote an actual web
>> "location", per se. I'd argue that from a REST perspective, there is
>> no such thing as a "web location". To posit such a thing is to
>> violate the essential principle of URI opacity.
>
> (ooops, httpRange-14 filter not properly engaged; rant leaking
> out....)
>

Err... well, I hadn't really wanted to spark off yet another
long running debate about name vs. location...

> I think "a location" is exactly what an HTTP URI returing "200 OK"
> directly identifies.

Then we disagree about something very fundamental. Pity.

> Indirectly, it can identify what's at that
> location, or even more indirectly what you see when you observe that
> location, or what you learn about from what you observe at that
> location.
>
> location == communications end-point, response point [1], etc.
>
> Such a URI is "a web address".

Now, that is a very coherent and self-consistent view. But I
find it to be far less useful than the view that most/all those
URIs denote things other than "locations" and that protocols
like HTTP provide a means to indirectly access the storage
locations of their representations.

Per your view, most URIs do not denote web pages, images,
video streams, services, etc. but all denote "locations" and
if we ever want to describe all those web-accessible resources,
we need an entirely different set of URIs for them if we wish
to talk about them.

I don't think I'm in a minority when I say that I have alot
more to say about the resources themselves rather than the
location in which their representations are stored (about
which, in fact, I typically have nothing to say whatsoever).

And the fact that most web servers treat URI resolution in
terms of a function rather than a simple access call (even
if an actual filesystem is employed) suggests that the
address/location metaphor is really just residue from the
earliest web servers which were strictly filesystem based.

>
> Strictly speaking, these notions of "location" and "address" are
> metaphors, but they are extremely good ones.  A physical mailing
> address like "77 Massachusetts Avenue, Cambridge, MA, 02139, USA" is
> useful in very much the same way as the web address "http://mit.edu"
> is useful.  (Try to imagine if one day a different building were
> located at that street address.  Yep, the experience would be a lot
> like if a different web site where located at that web address.)


Like I said, this view of URL == address/location is coherent,
and in some cases useful, but IMO of marginal utility when
taking into account the diversity of the web and its integration
with the SW.

I used to suscribe to your view. But real world implementational
experience has tought me that the alternative view is far, far
more practical, scalable, flexible, modular, and resilient to
change and evolution of systems.

Given the amount of autogenerated content and behind-the-scenes
processing going on within web servers, I find the "location"
metaphor to be too simplistic. Resolution of an http: URI is
more like a function than a "visit" to a physical location,
and the nature of that function is up to the web authority.

>
> I think any attempt to go against this natural, comfortable, and
> common idea (that URIs are web addresses) is doomed to failure, or at
> least enormous pain.


Well, I personally find the idea that URIs denote resources
which (by some protocol) may be resolved to representations of
those resources to be the most natural, confortable idea and
it's my impression that it is a far more common view than you
seem to suggest.

As for pain, can you outline a use case where e.g. not treating
all http: URIs as denoting locations causes solutions to break
or models to become more complex?


> Actually, I think the by-fiat imagined name
> change from "URL" to "URI" is simarly foolish.

I was myself skeptical at first, but am now convinced that neither
URN nor URL have any actual utility.

It really comes down to what it's most useful to talk about,
the things or the "locations" where they might be found.

>
> The question is how to finesse identifying people, stars, coffee
> makers, etc, into the same address space.  The HashURI approach [2]
> involves a sort of second step once you find a location.  "Go to
> <address>; then ask for <thing-name>".

As long as (a) interpretation of fragment identifiers is MIME type
specific and (b) web tools discard them at will, this will never be
a satisfactory solution. I.e., since the chances of either, much
less both, of the above changing are next to nil, the HashURI
approach IMO will never be satisfactory.

> The SlashRedirection approach
> [3] involves going to a location which turns out to be non-existent
> while pointing you at useful information.  "Try to reach <address> and
> you'll wind up somewhere else (<address2>) being told about the thing
> in question."

I like to think of redirection as amounting to asking the web
authority of a URI to resolve the URI to a representation, and
that web authority responding by saying that the resource in
question has an alias which is another URI (i.e. owl:sameAs)
and if you ask the web authority of that other URI, you will
get your representation.

A key benefit of URI opacity is that we don't *have* to worry
about where representations are located or how they are stored,
managed, constructed, syndicated, etc.

URIs name things. Various protocols allow us to resolve those
names to representations of those things. Some/most protocols
need the URIs to conform to particular schemes, but that
doesn't limit the use of any URI of any scheme to name any
particular thing (it only limits the use of particular
protocols to resolve particular URIs to representations of
the things they name).

This generalized view of the web (and SW) architecture works
equally well with any kind of resource, not just "web documents"
which might be "located" somewhere. But also web services,
content generators, abstract concepts, physical objects,
imaginary beings, etc, etc, etc.  And regardless of the thing
named by the URI, one has a consistent model for referring
to that thing by its URI, accessing that thing via its
representations (if the URI is resolvable by some protocol),
accessing a formal description of that thing (if the URI
is meaningful to such a protocol) and yes, even specifying
in its description the location of that thing, if that is
desirable/useful.

Back when all we had were HTTP servers sitting atop filesystems,
and representations were limited to "files", the location/address
metaphor was reasonable and workable. But IMO it's just not
sufficient for modelling the present-day web, much less the
web and SW of the future.

We need to simply let URLs and URNs REST in peace ;-)

Cheers,

Patrick


>
>     -- sandro
>
> [1] http://esw.w3.org/topic/ResponsePoint
> [2] http://esw.w3.org/topic/HashURI
> [3] http://esw.w3.org/topic/SlashRedirection
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com
Received on Wednesday, 21 January 2004 07:48:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:04 GMT