- From: Niklas Lindström <lindstream@gmail.com>
- Date: Sun, 7 Nov 2010 12:11:27 +0100
- To: nathan@webr3.org
- Cc: Mike Kelly <mike@mykanjo.co.uk>, Ian Davis <me@iandavis.com>, public-lod@w3.org
+1 indeed. Content-Location has definitely been overlooked. During conneg, it is used to differ between a resource and its representation(s), which are obviously different resources (well, not necessarily the same). This distinction could certainly be enough to remove the fundamental need for 303:ing on NIR:s (provided consensus and some formal resolution). (I pondered on a similar issue in <http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2010Feb/0007.html>, regarding the identity of fragments. Perhaps that discussion would be worth revisiting again in light of this?) Best regards, Niklas On Fri, Nov 5, 2010 at 5:55 PM, Nathan <nathan@webr3.org> wrote: > Mike Kelly wrote: >> >> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14 > > snipped and fuller version inserted: > > 4. If the response has a Content-Location header field, and that URI > is not the same as the effective request URI, then the response > asserts that its payload is a representation of the resource > identified by the Content-Location URI. However, such an > assertion cannot be trusted unless it can be verified by other > means (not defined by HTTP). > >> If a client wants to make a statement about the specific document >> then a response that includes a content-location is giving you the >> information necessary to do that correctly. It's complemented and >> further clarified in the entity body itself through something like >> isDescribedBy. > > I stand corrected, think there's something in this, and it could maybe > possibly provide the semantic indirection needed when Content-Location is > there, and different to the effective request uri, and complimented by some > statements (perhaps RDF in the body, or Link header, or html link element) > to assert the same. > > Covers a few use-cases, might have legs (once HTTP-bis is a standard?). > > Nicely caught Mike! > > Best, > > Nathan > >
Received on Sunday, 7 November 2010 11:12:16 UTC