Re: HTTP URIs and authority

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

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

Pat

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

Received on Tuesday, 23 October 2007 22:56:26 UTC