Re: Review of new HTTPbis text for 303 See Other

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

That is my point of argument.  What is this "close-to-identical" (the 
fidelity as in this Sotomayor's defense) is non-sense.  The "fidelity" 
is always be interpreted by some one or some group.  There is no escape 
of this "personal" context.   Take your "high resolution"as an example, 
how do you know if I am not wanting the high resolution in terms of the 
molecular structure of that book, instead of its content or image? You 
must define your 'resolution' before making it high.  You cannot say 
compare two things without setting the criteria of comparison.  In other 
word, you cannot say which thing is a better awww:representation better 
than the other.  There is only one thing that is certain.

There is a awww:representation.  In the web, it is usually carried in 
(or is ) a byte-stream.  You work with representation in the Web, which 
HTTP is part of.  Just like you work with photons in your daily life, 
which SEE is part of.  This is the only common ground.

>>
>> 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://
Thus, the protocol SEE is defined as a bunch of photons bombarded on my 
retina over a time period.   And the representation of SEE is defined as 
a collection of photons over my retina. This is *my* definition of SEE, 
just as how HTTP is defined by its HTTP protocol of saying if and how to 
fire off a bunch of bytes.  I am not talking about cognition.  I am 
talking about protocol.
>>
>> 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.
Nope.  The "document" is what is delivered to you.  Applying HTTP to 
"//xiaoshu.wang/a.humburger" returns a document, not a hamburger.   I 
don't know what "http://xiaoshu.wang/a.humburger" (the URL but not the 
URN) denotes and I don't care.  Just like if you ask me what does "see a 
hamburger" denotes, I don't know and I don't care.  I got an visual 
image of (aka, SEE) a hamburger, that is all.

You can call whatever the referent of "http://xiaoshu.wang/a.humburger" 
a document or IR.  That is fine.  But the difference is.  An IR exists  
-- not because of some a priori character that HTTP can apply to.  But 
an IR exists as a posteriori -- only because an HTTP protocol is applied 
to. A digitized file sitting in your hard-drive is not an IR.  It 
becomes an IR only when you mapped your web server 's directory to it.  
Thus, it is *you* who made someone or something an information 
resource.  Not the thing itself.
>>
>> 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*)
I will skip the truth part since it is not your concern.  (I thought it 
is because Stuart has this concern before.)

My point with the URL/URN is.  Then, if we have a URN/URL distinction.  
Then, we will say

The URN of "http://exmaple.com/a.hamburger" denotes the hamburger.
The URL of "http://example.com/a.hamburger" denotes an information 
resource, or whatever you want to call it.

Would you still have concern?  Would you still need to care if the URL 
200 or not?

This is in the same essence of TBL's suggestion to use hash-URI as names 
because the problem can only be solved through syntax because there 
isn't a priori nature for something to be IR. (But the hash-URI has its 
problem with existing use of slash URI and it still need to clarify its 
meaning when conneg is considered).

Xiaoshu

Received on Wednesday, 15 July 2009 22:02:19 UTC