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

> 
> John,
> 
> In defense of the current web architecture:

I'm not against current web architecture. If my prior comments 
seemed to imply that then let this here now retract that implied 
negativity. The 303 solution *is* an inspired bit of hackery. I 
understand its motivation completely. I have marveled at the magic 
in the idea that a URI as a name reference could also be a key 
in an information retrieval network that returned a copy of the 
exact thing that it referred to as a name. And I have spent a lot 
of time for the last several years thinking about how that same 
magic and power could be achieved when the URI ref refers to 
something that can not be copied over an http network directly. 

My motivation is that of a hacker. I see an opportunity to maybe 
add an application that I think would be cool. I am amused by the 
effort. I don't know of a single technology which could not be 
enhanced, extended, recombined, etc. in exciting new ways. That 
is all I want to do.

> 
> 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
> 

As I understand it, using a name to refer to a thing is not the 
same as using a key to retrieve representations from a server. 
Names are interpreted. URI's are used in an HTTP network to 
access information. These are not the same. And the difference 
matters. When the same name reference might be interpreted 
differently depending on the context of its use, it is ambiguous. 
This is different, for example, from the situation where a server 
has suffered an internal error that prevents it from returning 
the  representation requested. A "500 Internal Server Error" 
message is not one of several possible interpretations of what 
the URI refers to. So it does not disambiguate a name reference.
Instead, it reports the result of an operation. And that 
operation is fundamentally different from interpreting the 
reference of a name. Likewise with all the other HTTP operation 
return codes. None of them are alternative interpretations of 
what the URI refers to. 

In the classic example of what led to the httpRange-14 
solution, http://kashori.com/JohnBlack could, and probably 
has been used in RDF to refer to me, the person, and also, 
to my home web page. As a name, then, it is ambiguous, as it 
might reasonably be interpreted to refer to either one. 

I have never heard it suggested, however, that 
http://kashori.com/JohnBlack was ambiguous because it could 
be interpreted to refer either to the web page, on the one hand, or 
to a "500 Internal Server Error" message on the other hand. 
Nor are any of the other HTTP operation result code messages 
possible interpretations of what that URI refers to when used as 
a name. 


>> 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 15:37:38 UTC