Re: Review of new HTTPbis text for 303 See Other

On Jul 14, 2009, at 10:20 AM, Xiaoshu Wang wrote:

> Pat Hayes wrote:
>>
>> On Jul 14, 2009, at 9:01 AM, Xiaoshu Wang wrote:
>>
>>> Pat Hayes wrote:
>>>
>>> <snip>
>>>>> on these two counts, you end up ranting against a POV that I do  
>>>>> not hold.
>>>>>
>>>>> I especially continue to maintain that any talk about denotation  
>>>>> is out of place on the HTTP protocol level. There is no such  
>>>>> thing as denotation in the universe of the Hypertext Transfer  
>>>>> Protocol. Yes, people obviously use HTTP URIs to denote all  
>>>>> sorts of things, and a lot can be said about how one should  
>>>>> model resources and representations based on the things one  
>>>>> wants to denote, and what one can or cannot infer about the  
>>>>> denotation of a URI based on HTTP interactions, but none of this  
>>>>> matters one bit for the actual operations of the protocol.
>>>>
>>>> Seems to me that this may have been true before http-range-14,  
>>>> but it is not a stance that can possibly be maintained in the  
>>>> face of that decision. And your final sentence above is, surely  
>>>> you can yourself see, tendentious. If the HTTP 'layer' really  
>>>> were completely unconcerned with denotation, how could one  
>>>> *possibly* infer anything about what a URI denotes from  
>>>> *anything* about HTTP interactions?
>>> The assumption here is that httpRange-14 is the right direction.   
>>> But that is a big *if*. If anything, this debate only shows how  
>>> *bad* that this whole idea of httpRange-14 and information  
>>> resource thing is.
>>
>> As I said in another post, I think http-range-14 is terrible, but  
>> all the alternatives are worse.
> Of course there is no better alternative because there is *not* a  
> problem at the first place. The problem is created by pushing IR  
> into the Web architecture.  But just like the web architecture  
> should not deal with hamburgers, it should not deal with IR as well.
>
>>>>> The protocol is just about pushing representations around.
>>>>
>>>> Well, I would be delighted if this were true. But then the HTTP  
>>>> specs should not claim or even hint at the idea that URIs can  
>>>> "identify" non-computational things, or that such things can have  
>>>> "representations" in its specialized sense. (It would be very  
>>>> good manners, in fact, to clarify just what that highly  
>>>> specialized sense of "representation" is, and state explicitly  
>>>> that it is not intended to cover any wider sense of  
>>>> representation, for example the sense in which it it used in such  
>>>> phrases as "knowledge representation".) And you should be quite  
>>>> open and clear about the fact that this view of HTTP is not  
>>>> compatible with the http-range-14 decision.
>>> The HTTP protocol should be about pushing representation around.   
>>> And it shouldn't careless about if its URI denotes or identifies  
>>> anything.  The latter is up to the one who implements that  
>>> particular URI.   Let's not ignore the existence of such entities  
>>> because it is those who expressed their denotation semantics.
>>>
>>> Also, let's us not play linguistic tricks.  If the owner of "http://example.com/a.hamburger 
>>> " makes it to denote a hamburger. Then HTTP-GET "http://example.com/a.hamburger 
>>> " means "get me an awww:representation" of the hamburger. But it  
>>> does NOT mean the "get" like in "get me that hamburger" as what we  
>>> would say in front of a grill.
>>
>> Of course not. But it also does not mean, "get me an  
>> awww:representation" of the hamburger. Or at least, it had better  
>> not mean that, since hamburgers don't have awww:representations.  
>> Web pages about hamburgers can represent (not awww:represent) a  
>> hamburger, and they of course have awww:representations. But an  
>> awww:repreresentation of a representation of X is not an  
>> awww:representation of X.
> I mentioned that let us not ignore *the existence of an agent* --  
> the one who implements the URI.  I do not know if a hamburger *can  
> or cannot* have an awww:representation because I am not a  
> hamburger.  But I do know that *I can* give a hamburger an  
> awww:representation.  You don't have to believe me, that is none of  
> my business.

True, I don't have to, but I would like to know a little more about  
HOW you would create an awww:representation - or, which I believe to  
be synonymous, a representation in  the sense used in Roy's REST  
thesis - of a hamburger. I will take mine without tomatoes, well done  
and dressed with mayo and mustard.  So, to check our understanding,  
this must be a representation, encoded in a byte stream, which stands  
in the same relation to a hamburger that the html which I get back  
from, say, the Amazon website stands in to that web page.

Maybe we should take this offline if it is annoying others, but I  
actually think it might be quite informative about our various  
clashing intuitions here.

Pat


>  But to say that no one should believe me, you cross the line for  
> being either ignorant (of being me) or arrogant (of being you).
>>> To think otherwise is to hallucinate.
>>
>> Quite.
>>
>>>
>>> httpRange-14 was at first designed to prevent people from episodes  
>>> of this kind of hallucination.  But at the end, it ends up with  
>>> its own one -- the hallucination of the information resource.
>>
>> I don't like the terminology (and I don't think we need it, and  
>> especially do not need to be debating its exact meaning), but the  
>> general idea is clear enough: its the thing that HTTP returns the  
>> awww:representation of. That is certainly not a hallucination,  
>> because you just made HTTP contact with it.
> Then, it is fine with me.  You can call an HTTP server, FTP server,  
> Mailto server or any kind of information server -- an "information  
> resource".  That is denotation semantics of that word's use.  It is  
> fine with me because we might just call it "xyz" -- for the sake of  
> avoiding confusion.  But this denotation semantics should not affect  
> how *I* implement *my* URI.  Most of all, it should not affect how  
> *I* use the Web.
>
> Xiaoshu
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 15 July 2009 14:25:45 UTC