- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Tue, 14 Jul 2009 02:01:57 -0400
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Pat Hayes <phayes@ihmc.us>, "Roy T. Fielding" <fielding@gbiv.com>, Jonathan Rees <jar@creativecommons.org>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
On Sat, Jul 11, 2009 at 6:27 AM, Richard Cyganiak<richard@cyganiak.de> wrote: > Not as far as HTTP is concerned. HTTP is just a transfer protocol. The HTTP > world is really simple: > > 1. There are URIs. URIs are thought to identify things called resources. As > far as HTTP is concerned, it does not matter much what the resource actually > is -- a document, a file on a server, a person, whatever. > > 2. Resources (whatever they are) are thought to have things called > representations. As far as HTTP is concerned, it is totally up to the server > owner to decide what's a representation of what. After the server owner has > made their decision, a resource either has a representation or not. > > 3. If a resource has a representation, then a GET to its URI should be > answered by 200. If not, then 303, 404 or 410 would be fine choices. > > I repeat: For the operation of the HTTP protocol, IT DOES NOT MATTER what > exactly a resource is and what the exact relationship between resources and > representations is. All these matters of denotation, information resources > and so on are introduced by higher layers of the architecture. This is a nice simple story, but as far as I can tell it just isn't correct. There are many places in HTTP which address issues of semantics or otherwise go beyond transport. e.g Content negotiation: Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable to supply the user with the "best available" entity corresponding to the request. Unfortunately for servers and caches, not all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the best representation for a given response when there are multiple representations available. Note: This is not called "format negotiation" because the alternate representations may be of the same media type, but use different capabilities of that type, be in different languages, etc. or: 10.2.4 203 Non-Authoritative Information ........................59 or: 10.4.3 402 Payment Required ....................................66 or: 14.11 Content-Encoding .........................................118 14.12 Content-Language .........................................118 or any of the caching stuff. --- TCP is a transport protocol. HTTP is concerned with more than just transport of opaque bit strings. In my view, your presentation of HTTP's view of resources and representations as a kind of mathematical abstraction doesn't do justice to the intellectual work that preceded and led to the development of HTTP (H = Hypertext, for example). It is certainly true that there are additional layerings that are added by, e.g. AWWW and RDF, but to suggest that HTTP did not bring to the table anything more than shipping certain kinds of packets called representations which are in grouped in buckets called resources doesn't seem accurate. It may very well be the case that whatever HTTP brings to the table in these areas is underspecified, ambiguous, inconsistent, and unhelpful, and that a retrenchment to a view of HTTP along the lines you suggest might be a useful advance towards a more coherent overall infrastructure for a Semantic Web. Let's have that discussion, then, rather than one over who's account of history is right. (my suspicion is that the older folks will win that one ;-) -Alan
Received on Tuesday, 14 July 2009 06:04:04 UTC