Re: Review of new HTTPbis text for 303 See Other

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.

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

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.

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

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).  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?

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

Xiaoshu

Received on Wednesday, 15 July 2009 16:16:41 UTC