- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 21 Jan 2004 14:42:56 +0200
- To: "ext Sandro Hawke" <sandro@w3.org>
- Cc: www-rdf-interest@w3.org, "Thomas B. Passin" <tpassin@comcast.net>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>
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 UTC