W3C home > Mailing lists > Public > semantic-web@w3.org > December 2006

Re: Semantic Web Statement Contexts (was: Can there be a URI for the concepts "I", "you",...)

From: Richard Cyganiak <richard@cyganiak.de>
Date: Thu, 28 Dec 2006 17:48:47 +0100
Message-Id: <393176E8-C782-43BC-98D2-4E69A8C55AC3@cyganiak.de>
Cc: "Sandro Hawke" <sandro@w3.org>, "Joshua Tauberer" <jt@occams.info>, <semantic-web@w3.org>
To: John Black <JohnBlack@kashori.com>

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 Thursday, 28 December 2006 17:15:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:13 GMT