W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: 200 OK with Content-Location might work

From: Niklas Lindström <lindstream@gmail.com>
Date: Sun, 7 Nov 2010 12:11:27 +0100
Message-ID: <AANLkTinVknTyj8Nb0cDHv=+O+dXyABEXJU4W9HDYSDsV@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:30 UTC