Re: HTTP URIs and authority

>noah_mendelsohn@us.ibm.com 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.
>>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.  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.  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, they are not my impressions of it.
>>
>Yes, I agree with all that.  I am perfectly clear about that.
>
>The problem is that at least someone does not 
>think that 
>http://www.ihmc.us/users/phayes/PatHayes can be 
>used to refer Pat Hayes? They will say 
>httpRange-14 dictates that 
>"http://example.org/nonRhymingPoem" can emit 200 
>but http://www.ihmc.us/users/phayes/PatHayes 
>must emit 303?

Yes. That page violates httpRange-14 (deliberately, I might add :-)

>I cannot see there is anything, at least 
>anything objective, to judge that position. 
>The reason people think that Pat's URI is wrong 
>because when they dereference the URI with HTTP 
>they gets back an HTML page.  They say, nah, Pat 
>cannot be an HTML page, so that URI is wrong. 
>But the truth is: it is not that Pat becomes a 
>HTML page, it is a representation of Pat becomes 
>page. What I want to say in the past few days is 
>let's clarify the difference between *a 
>resource* identified by a URI and *a 
>representation* of that resource once 
>dereferenced via the HTTP protocol.  You can 
>know something about the resource from its 
>representation but how much depends on the 
>content of the representation and your ability 
>to handle the representation.
>
>If we understand URI dereference from this point 
>of view, there is no ground for httpRange-14 
>anymore. And there is no point to distinguish 
>what is information resource and what is not.

There is a real issue, however. You or I can read 
what that page says and understand it. But 
programs can't. The Semantic Web needs a way for 
a program to reliably infer whether the URI 
denotes me or some HTML. If there were some 
universally agreed way to do this (say, a 
world-standard, universally accepted, OWL person 
ontology) then the page could use this. But there 
is no such way for it to say this in a 
machine-readable fashion, and so we are left with 
an ambiguity.

One view on this, which I have espoused 
elsewhere, is to simply accept that URI 
denotations are ambiguous and learn to live with 
it, by using the context to disambiguate the 
meaning. But I have to admit that as a short-term 
solution this creates more problems than it 
solves, since the SWeb apparatus has not evolved 
to the point where it can reliably handle the 
contextual inferences required for such 
disambiguation. So it seems we need a work-around 
for this particular difficulty, to resolve these 
ambiguities in some uniform way. And httpRange-14 
is about the simplest work-around that anyone can 
think of. I still think its a hack, but (a) we 
need a hack and (b) it does seem to work.

Pat

>Regards,
>
>Xiaoshu


-- 
---------------------------------------------------------------------
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 23:22:28 UTC