- From: Frank Manola <fmanola@acm.org>
- Date: Fri, 29 Dec 2006 12:15:05 -0500
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: SWIG <semantic-web@w3.org>
It seems to me that whether or not one feels that httpRange-14 adequately addresses the general disambiguation issue, this approach encodes useful metadata about the resource (an opinion as to whether all the essential characteristics of this resource can be encoded in a message that we can send over the network) in a server response, rather than declaratively (e.g., in OWL). It seems to me it would also be useful to have some RDF/OWL vocabulary (which I believe was some of what Sandro was getting at in some of the earlier work he mentioned) for "introspectively reasoning" in a declarative language about the nature of Web resources, in parallel with whatever gets encoded in http responses. --Frank On Dec 28, 2006, at 11:48 AM, Richard Cyganiak wrote: > > John, > > In defense of the current web architecture: > > On 28 Dec 2006, at 14:36, John Black wrote: >> Tracing back through the steps that led me here, one major >> user problem I am trying to solve is to avoid programming my >> web server to return different http responses based on how I >> classify the referent of my URI names. > > There is an existing solution to this problem for those who don't > like httpRange-14, it requires no web server configuration, is > theoretically sound, is widely deployed, and quite universally > accepted: hash URIs. > >> I agree with Pat Hayes, the editor of RDF Semantics [1], >> who said of the http-range-14 solution in his >> presentation at IRW2006 [2], "In Defense of Ambiguity": > > Well, it's kind of hard to argue with what Pat said on that > infamous slide, because it is quite disconnected from the rest of > his presentation, and some of the statements are presented without > any justification, and it's hard to know how he comes to his > conclusions. (But the rest of the presentation is great and > contains some of the most insightful stuff I've read on the subject.) > > So, Pat said: > >> [...snip...] >> It uses a distinction in how a text is delivered (an http code) to >> disambiguate the text itself; a category mistake analogous to >> requiring the postman dance a jig when delivering an official >> letter. Since the text bears no trace of its delivery, no >> disambiguation is achieved by this." [3] > > I would say that there is plenty of prior art on using HTTP status > codes to disambiguate delivered texts. In fact, almost all HTTP > status codes serve that purpose. Whenever your web browser receives > a "500 Internal Server Error", for example, the postman does indeed > dance a little jig to tell your browser that the text is just an > error message, and not a representation of the requested resource. > The error page doesn't bear any trace of it's delivery either. Pat > doesn't really present an argument as to why this is supposed to be > a problem. (I'm sure he has good and valid reasons for his > criticism, he just chose not to present them. I'd love to hear him > expand on that though.) > > To me it looks like the 303 solution fits nicely into the existing > use of HTTP status codes. > > 200 OK -- Here's a representation of the requested resource > 301 Moved -- A representation of the requested resource can be > found over there > 404 Not Found -- I don't have any representations of such a resource > 500 Internal Server Error -- Something's broken, I can't serve a > representation right now > 303 See Other -- I won't give you a representation of that > resource, but some information about it may be available over there > >> I came up with the following suggestions that I >> hope further illustrate Pat's point about this being a category >> mistake. >> >> 1. For distinguishing URI that refer to things that do not actually >> exist, dead presidents, extinct species, and unicorns, for example, >> first return a "404 Not Found" code, then if the client requests the >> same URI within 0.5 seconds, return a document describing the >> non-existent thing. >> >> 2. For URI that refer to things that are bad for you, such as >> cigarettes and high fat foods, return a "403 Forbidden" code and >> then if they repeat the request, a document about that thing. > > The examples are entertaining (May I suggest the addition of a "207 > Sarcasm" status code to HTTP?), but are different from the > httpRange-14 case in an important way: They do not deal with a > distinction that is relevant to the problem at hand -- the transfer > of representations of resources over a network. > > The "303 for non-information resources" practice deals with a > question that *is* somewhat relevant to the problem: Can all the > essential characteristics of this resource be encoded in a message > that we can send over the network? > > Your suggested "404 for unicorns" practice deals with a question > that is *not* relevant to the problem. For the problem of > transferring resource representations over a network, unicorns are > no different from horses. > > (Is the distinction between information resources and non- > information resources *important* for the problem of transferring > representations? That's another question altogether, and I'm not > convinced either way. I'm just saying that the 303 distinction is > in the problem domain, while your suggested distinctions are not, > and therefore I feel they don't back up Pat's point.) > > And anyway it should be 410 for dead presidents, not 404. Please be > precise in your jokes. > > ;-) > > Richard > > >> 1. http://www.w3.org/TR/rdf-mt/ >> 2. http://www.ibiblio.org/hhalpin/irw2006/ >> 3. http://www.ibiblio.org/hhalpin/irw2006/presentations/ >> HayesSlides.pdf >> >> >> John Black >> www.kashori.com >> >> >>> >>> -- Sandro >>> >>> >>> >> >> >> >> > >
Received on Friday, 29 December 2006 17:15:19 UTC