- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Sat, 30 Dec 2006 11:57:55 +0100
- To: Frank Manola <fmanola@acm.org>
- Cc: SWIG <semantic-web@w3.org>
Hi Frank, On 29 Dec 2006, at 18:15, Frank Manola wrote: > 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). Yes, the 303 approach encodes useful metadata (the "information resource flag") in the HTTP interaction, rather than in RDF/OWL. But ... First, your claim that this is non-declarative is silly. I'm sure you know this and were just sloppy in your choice of terms. Second, arguably this bit of metadata is exactly where it should be. It is transfer metadata after all. The distinction between information resources and non-information resources is not relevant to most application domains, but is relevant to the question of moving representations over the network. On the higher-up RDF/OWL data layer, this question should ideally "already have been dealt with". After all, I usually don't want to know how a particular triple was encoded (N3 or RDF/XML? utf-8 or iso-8859-1?). And for the same reason, I usually don't want to know details about how the triple was sent over the network. All I want on the data layer is the triples, and simple provenance information. Ideally, everything else should be transparent. > 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. Yes, you are right, there are scenarios where having the information available in RDF would be useful. But in general I think it detracts from a clean layering. HTTP is the transfer layer. The transfer layer's job is to deal with questions of how RDF payloads are sent over the network. RDF is the data layer. I think in general it's better to not let transfer concerns seep up into the data layer. (Of course the real world is messy and there can always be good reasons to deviate from a clean layering etc etc.) Richard > > --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 Saturday, 30 December 2006 10:58:11 UTC