Re: HTTP URIs and authority

Pat Hayes wrote:
>> Xiaoshu Wang writes:
>>
>>>  - The URI identifies the city.
>>>
>>>  - The *representation* that people gets back by dereferencing the
>>>  URI with HTTP protocol is your *impression*.
>>
>> I don't think the word impression is really appropriate here.  Let's say
>> that I assign resource http://example.org/nonRhymingPoem to the poem 
>> that
>> is popular with American school children:
>>
>>         Roses are red,
>>         Violets are blue,
>>         Some poems rhyme,
>>         Some don't.
>>
>> If you do an HTTP GET to that URI I send you back an HTML page.  The 
>> text
>> of the poem is more or less centered.  It's set out in some font of my
>> choosing, in 25 point italic.  The background is purple.  I don't think
>> the most appropriate way to describe that in English is to say that it's
>> my impression of the poem.  It's the way I choose to render the poem for
>> your perusal.  In fact, it's quite appropriate to say that the HTML page
>> is the way that I choose to represent the program.
>
> ...represent the poem?
>
> But look, we now have at least three senses of 'represent' in play in 
> this discussion.
>
> 1. The sense used in "knowledge representation". This is the sense in 
> which some (HTML-embedded) text, or an OWL ontology, or even a Jpeg 
> image, might represent Paris, the city (a 'non-information resource'; 
> a thing).
This is the content of - representation (2).
> 2. The REST/TAG sense,  in which whatever comes back from a GET 
> request accompanying a 200 code represents the web page (or whatever: 
> the 'information resource') that is at the http endpoint. To me this 
> is rather like the relationship between a page printed on an 
> old-fashioned Franklin press and the metal platen that the paper was 
> pressed against: it might be called a 'rendering'. (Of course its more 
> complicated because of content negotiation, yadda yadda, but you get 
> the analogy.)
This is the message/response of a server. As you said, this is the 
REST/TAG sense.
> 3. The sense used above in which a particular layout/font design of a 
> poem represents the abstract poem, or a particular book I hold in my 
> hand represents the (single) novel called 'Moby Dick'. This is 
> traditionally called the type/token distinction. In this case the 
> represented thing is always some kind of abstraction, the kind of 
> thing you can copyright.
Yes, this is what is actually denoted by the URI.  You never get it back 
no matter what kind of de-reference protocol you use. 
> None of these three meanings are much like the other, so it might be 
> best to use different words for them.
>
>> Furthermore, I don't think we need to insist that this particular URI is
>> only for the poem rendered in those fonts, unless that's what I say the
>> URI is for.
>
> Well now, that raises an interesting issue. Seems to me that if we 
> follow the REST model, we *do* have to say this. Any change to the 
> HTML is a change to the resource and hence a change to the 
> representation-2.
>
>>  If I say that it's for the poem, and in a year or so someone
>> comes up with a font I like better, I see no problem with my changing 
>> the
>> page to use that.
>
> Neither do I: but that doesn't mean that the URI denotes anything 
> font-less, like the 'real' poem. It just means that your resource here 
> has a changing font. Information resources can be dynamic in this way, 
> right?
>
>> The URI still identifies the poem, since I say it does
>> (presuming I've registered example.com).  The HTML pages are still
>> representations of the poem
>
> Yes. The actual HTML page is a representation-3's of the poem. But 
> then what I GET back from that HTML page is a representation-2 of a 
> representation-3 of the poem, not a representation-2 of the poem. The 
> poem itself is an abstraction, existing only in some Platonic space of 
> Pure Texts. 
Exactly.
> Those aren't the kind of thing one can put at an http endpoint. If you 
> want to denote the *actual poem*, you should use 303 or #.
But here I disagree.  what is at the end of HTTP endpoint is 
representation-2 of that URI that finally emit 200.  As you just said, 
representation-2 is never the same representation-3.  It doesn't matter 
how you chain it, you never get the (3).

Regards,

Xiaoshu

Received on Tuesday, 23 October 2007 23:16:16 UTC