RE: Subgroup to handle semantics of HTTP etc?

Hello Xiaoshu,

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Xiaoshu Wang
> Sent: 18 October 2007 12:00
> To: Tim Berners-Lee
> Cc: Booth, David (HP Software - Boston); W3C-TAG Group WG; 
> Alan Ruttenberg; Jonathan A Rees; Dan Connolly
> Subject: 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. 

Would you care to enumerate some of those please? 
I'm particularly interested in those problems that youattribute to the
'resolution' rather than those that exist independent of it.

The question pose by the httpRange-14 question is:
	"What is the range of the HTTP dereference function?" 

Which has generally been taken as wteo:
	"Are there constraints on what can be referred to using an http:
scheme URI?"

and a particular question over whether the presense of a '#' in a given
http: scheme URI has any bearing on that answer.

After much email and debate, the TAG resolved the question such that Web
Architecture places no constraints on what can be referred to using http
scheme URIs, with or without a '#' in a given URI.

A consequence of following the TAG's advice at [1]
webarch:Representations should not be deployed for resources that are
non-information resources. This occurs naturally with '#'ed URI and
requires a little care with '#'-less URI - ie. the deployment of a
redirection rather than a webarch:Representation (there may be other
ways to accomplish a similar effect - ie. a protocol level mechanism to
direct an enquiry elsewhere - that at least in part is the topic of
httpRedirections-57). Pat Hayes has recently offered a restatement of
the TAG advice in manner that I can certainly support [2]; likewise:

"Pat's rewrite of the httpRange-14 resolution, improving an earlier one
by JAR's: 

- If a network resource responds to a GET request with a 2xx response,
then that URI refers to that network resource; 
- If ... with a 303 response, then that URI refers to something (and the
response should be helpful in determining what it refers to); 
- If ... with a 4xx response, then nothing is known about whether the
URI refers to anything, or what it refers to. "
http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/
Recommendations/StatusOfHttpScheme

[1] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039
[2] http://lists.w3.org/Archives/Public/www-tag/2007Sep/0017.html

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

That would be what AWWW calls a resource, right?

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

That would be what AWWW calls a representaion, right?

> The important question is whether T should be R? Most people 
> think so, but I think we should not. 

In which case I think you and AWWW are in agreement.

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

Hmmm.... this seems to confuse resources with representations. T can be
taken as a reference to a generic resource while R1,R2 and R3 can be
taken as references to more specific resources which give access to a
narrower set of representations than T (a some given instant).

> In other words, 
> what a URI identifies will *never* be the same as what the 
> URI is dereferenced unless we explicitly assert them.

? don't understand the claim. 

>  Thus, 
> with content negotiation, it is impossible to assign a URI. 

? ditto... don't understand.

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

I don't think so... but I may now be confused about what you are trying
to say.

> Now, I start thinking it actually 
> does more harm that it has helped.
> 
> Xiaoshu 

Regard

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
RG12 1HN
Registered No: 690597 England

Received on Monday, 22 October 2007 11:44:51 UTC