Re: Subgroup to handle semantics of HTTP etc?

Tim Berners-Lee wrote:
> But i also agree with David, that if you *do* take off the covers and 
> discuss the HTTP protocol, then RDF is a good tool.  Also, I think it 
> is valuable to check the consistency of the things yu get from HTTP 
> (llike <u> is a document) and the things you get from that or other 
> documents (<u> is a Person or a property, etc).
I think if a client infer anything from the HTTP protocol, it is the 
semantics of the protocol, but not the message that the protocol deal 
with. Just like we can deliver a letter in different ways. But whether 
it is by first class, overnight, Fedex, UPS, is the semantics of the 
*mail delivery* but not the semantics of the letter. Of course, as David 
said, network protocol is a source of information. But its semantics is 
about the envelop but the message contained within.

I think, the root cause for all these is the httpRange-14. The way its 
resolution is written just sounds like a inference.  After some 
thoughts, I start to think that "httpRange-14" gets it wrong.  The issue 
is raised to solve the URI ambiguity.  But what it does is to open more 
issues than it has solved. 

The whole issue, I think relies on how we understand the relationship 
between the following two things.

1) The thing that a URI denotes, let's call it T.
2) The thing that you get back from dereferencing the URI, let's call it R.

The important question is whether T should be R? Most people think so, 
but I think we should not.  First, a protocol, such as HTTP, is just one 
of the many protocol that can be used to "dereference" a URI.  Second, 
the HTTP content negotiation makes it impossible that R is T.  For 
instance, if we normalize all the HTTP GET by moving all the Accept 
header into a query string. Then, given a URI like "http://example.com/foo"

T =  http://example.com/foo

But R can be one of the followings

R1 = http://example.com/foo?Accept=text/html
R2 = http://example.com/foo?Accept=application/rdf+xml
R3 = http://example.com/foo?Accept=anything

And they have completely different URIs.  In other words, what a URI 
identifies will *never* be the same as what the URI is dereferenced 
unless we explicitly assert them.  Thus, with content negotiation, it is 
impossible to assign a URI. (But it does not mean that we cannot talk 
about it. In human language, we refer to them as "arepresentation of 
http://example.com/foo".  In RDF, we must use a B-node.)

The 303 resolution seems proposed based on the an implied assumption 
that T can be R. Now, I start thinking it actually does more harm that 
it has helped.

Xiaoshu

Received on Thursday, 18 October 2007 11:00:59 UTC