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