W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

RE: Question on the boundaries of content negotiation in the context of the Web of Data

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Fri, 13 Feb 2009 16:46:26 +0000
To: "wangxiao@musc.edu" <wangxiao@musc.edu>
CC: Michael Hausenblas <michael.hausenblas@deri.org>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <233101CD2D78D64E8C6691E90030E5C8293C5895C0@GVW1120EXC.americas.hpqcorp.net>

Hello Xiaoshu,

<snip/>

Just on one small thing and then I really must do other 'stuff'...

> >> Then,> "png" and "ttl" are awww:representations of "the:house" -- 
> >> as you said - a set of ephemeral set of bits and some metadata.
> >>     
> >
> > Be careful with the prescription of this particular example 
> > in that "the:house" as in "http://sw_app.org/sandbox/house" 
> > has never been claimed anywhere as designating a house 
> > (conceptual, actual, class or otherwise)- that priviledge was 
> > afford to "http://sw_app.org/sandbox/house.ttl#my".
> >   
> Does it matter with a fragment identifier or not? I don't think so.

The HTTP protocol strips the #frag from the URI transferred in the request line. 
It is not seen by the orgin server or the caches. I understand this to be an essentail 
part of the protocol design and not a bug. So although you might ask for:

	http://sw_app.org/sandbox/home#my

what the server see's is
	
	http://sw_app.org/sandbox/home

It is that truncated reference that gets conneg'd, not the full reference. I believe you will find that documented on the syntax of an HTTP request in RFC 2616 (for those demanding citation).

See also http://www.w3.org/DesignIssues/Model.html (Michael that's another that you might like to add to your list if you haven't tuned out).


>  All URI should work in the same way, fragmented or not.

Well operationally, when presented in HTTP requests, they don't. 

> The difference of a 
> fragment URI and a non-fragmented one is the path to the representation 
> (either awww or pol one, it doesn't matter).  How we obtain the 
> information of something should have nothing to do with the semantics of 
> that thing.

Yes... but it is critical that we know what thing we are getting information for/about. In asking for 

	http://sw_app.org/sandbox/home#my

we (hope to) get a awww:representation of:
	
	http://sw_app.org/sandbox/home (not of http://sw_app.org/sandbox/home#my)

which (we hope) has something to say about:

	http://sw_app.org/sandbox/home#my

but apriori there are no guarantees that those hopes will be met.

> This is, in fact, the critical mistake of httpRange-14.
>
> > Neither, the PNG serialisation of the image or the ttl 
> > serialisation of the graph are claimed as representations of 
> > whatever is designated by "http://sw_app.org/sandbox/house.ttl#my". 
> >
> I am a bit confused by the wording "Neither".  Do you mean 
> that the PNG serialization of the image can NOT be the representation of 
> "http://www.sw-app.org/sandbox/house.ttl#my"? Or you mean it 
> can?  I opt for the "can" because I don't see any reason for me NOT to accept 
> other's claim.  And from the picture, it seems that that image is 
> intended for "http://www.sw-app.org/sandbox/house.ttl#my".

See above... the representations in general are not *of* the thing referred to by the full URI, but of the things referenced by that URI minus #frag.

> > At best one might claim them as equivlent representations 
> > of "http://sw_app.org/sandbox/house" but I have no idea what 
> > resource Michael intended that to be.

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Friday, 13 February 2009 16:50:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:12 GMT