Re: Review of new HTTPbis text for 303 See Other

On Jul 15, 2009, at 11:15 AM, Xiaoshu Wang wrote:

> Pat Hayes wrote:
>>
>> 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.
> [I will make this public as if our discussion were desired as Ray  
> has expressed.]
>
> To answer your HOW-to question, allow me to use my proposed scheme- 
> less URI convention.
>
> Assume that I own the domain name "xiaoshu.wang" and I designated  
> the (scheme-less) URI:  "//xiaoshu.wang/a.hamburger" to denote the  
> hamburger burning on the grill of my backyard on a sunny day.
> In our traditional web jargon, the URI -- "//xiaoshu.wang/ 
> a.hamburger" -- is an absolute URN, hence its semantics is only  
> about denotation.

Hmmm... I guess I was presupposing that we were talking about HTTP  
URIs in this forum. But as I don't think it makes any real difference,  
let us proceed:

>
> There are many ways that we can get a representation (in the most  
> general philosophical sense) of "//xiaoshu.wang/a.hamburger".

Oh, no disagreement there. But I didn't ask about getting a  
representation in a broad sense, but in the very narrow sense used in  
awww debates, where it means the kind of 'representation' which Roy  
talks about in his thesis REST model, and which HTTP talks about when  
it refers to representations of resources. This much narrower sense  
refers to a byte stream which is a sufficiently detailed and precise  
representation as to allow a close-to-identical copy of the resource  
to be assembled by the recipient of the message. For example, this  
kind of representation of a page of a book might be a high-resolution  
image of the page, or it might be a PDF file which can be  
reconstructed into an accurate digital rendering of the original page.  
But a mere description in RDF, for example, would not meet these very  
tight requirements on awww:representations. Seems to me that to do  
this with hamburgers requires a matter transporter or telekinesis.

>
> We can *see* it, i.e., by turning our head and opening our eyes so  
> light rays can bounce off the hamburger into our eyes.  Let's denote  
> this particular kind of representation retrieval with a URI scheme  
> -- see, as follows:
>
> "see://xiaoshu.wang/a.hamburger"
>
> In our web jargon, the above URI is a URL because it is bound with  
> the transportation protocol "SEE".  By this URL, we can get back a  
> representation, in the form of a bunch of photons delivered to our  
> retina.

But (1) we cannot send photons in a byte stream, and (2) I don't think  
that the light reflected back from a thing is a 'representation' of  
that thing in any useful sense. When we see things, our brains  
construct representations of them which constitute our visual  
awareness, but thats not done by the photons themselves and its not in  
any way isomorphic to the photons. Still, this is a philosophical  
quibble in  the context of this discussion, as you could run your  
point with a URI prefix of cognizes://

>
> Similarly, we can
>
> hear://xiaoshu.wang/a.hamburger (with air pressures as  
> representations delivered to our eardrum)
> get://xiaoshu.wang/a.hamburger (some heat, pressure, as  
> representations delivered to our hand)
> eat://xiaoshu.wang/a.hamburger (some fat, carbo, salt, as  
> representations shuffled down to our throat)
> ....
> http://xiaoshu.wang/a.hamburger (some document packed in bits as  
> representations delivered to our laptop or desktop or your  
> palmtop....)

They key is that its a DOCUMENT in this case, and the document  (not  
the hamburger) is the resource which is represented by the bits. And a  
representation of a representation of X is not a representation of X.  
Even denotation isn't transitive in this way: the Hollywood sign is  
called "Hollywood sign", and that phrase does not refer to Hollywood.

>
> So, what is the HOW that you want to know?  Is it "how do we see,  
> hear, eat, and HTTP"?  Then, take a biology class or in the latter  
> case, read the HTTP spec.  But here is the point: we don't need to  
> know how we see in order to see (i.e., to perceive the photons)  
> because our body just *can*.  By the same token, we don't need to  
> know how the Web delivers an awww:representation in order to use  
> the  awww:representation because the Web just *can*.

>
> So, I do not think that is the reason for you to ask the know-HOW.   
> The reason that you want to ask the KNOW-how is that you want to  
> feel confident in taking the content carried in a representation to  
> be true (or false).

Im not arguing here for boolean descriptive representations. Quite the  
contrary, in fact: I don't think that awww:representations can  
possibly be false (they can be *wrong*, but not *false*)

>  This is a valid concern.  But the only way to increase that  
> confidence is to gather more information.  There is no other way  
> around.  For instance, even if you see the hamburger, don't you  
> still need some additional information to make sure what you see is  
> not a reflection from a mirror or simply not a mirage?  Does knowing  
> how human see helps you any more than not-knowing it? It is the same  
> with IR/httpRange-14.  Even if we all complied, don't you still need  
> to know if someone gets it right or wrong before committing to your  
> truth?

I am not going along this line of thought here. Im not concerned about  
certitude or confidence in knowing the representation is correct or  
complete. (I actually don't agree with you about the only way being to  
get more information, BTW, but that really is a philosophical debate  
unsuited to this forum.) My only point is that there is genuine, if  
narrow, sense of representation in which the payload of a 200-coded  
HTTP reply is one of them, but things like descriptions, pictures,  
smells and sights are not; and are such that things that cannot be  
stored digitally in Web servers and given a http interface cannot have  
these representations. This is the sense of awww:representation used  
in the REST literature and often by Timbl in his writings and which  
the HTTP specs are presuming, I believe. And in this narrow sense of  
'representation', I am still quite convinced that a hamburger cannot  
have one of them. It cannot be awww:represented in the sense that,  
say, a Word document or a JPG image can be.

>
> For instance, if I take "http://xiaoshu.wang/a.hamburger" to denote  
> a hamburger.  When you de-reference that URI, you get back a 200.   
> But after reading my awww:representation

Of what? Not of the hamburger, surely.

> , you may say "No, you cannot do that because ....".  But the real  
> cause is that our interpretation about HTTP could be different in  
> the same way that our interpretation about hamburger, dog, or IR  
> could be different.  But aren't we taking about a hamburger, what  
> the heck does it has anything to do with dog, IR, or HTTP?
>
> The cause of all these mess is either our confusion with messing up  
> representation with resource, or, the duality of HTTP-URI as both a  
> name and a locator.  If we separate "[http:]//xiaoshu.wang/ 
> a.hamburger" -- the URN -- from "http://xiaoshu.wang/a.hamburger" --  
> the URL, I don't think you will have much concerns.  Do you?

Maybe not, but I fail to see how to make the URL/N distinction if they  
are indistinguishable textually. And I am still left wondering how to  
refer to a locatable thing like a Web page, if I have to use a URN to  
refer to it. Why not just use the name everyone else uses?

Pat

>
> 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 20:39:30 UTC