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

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