Re: 200 OK with Content-Location might work

On 11/6/10 9:05 AM, Nathan wrote:
> Ian Davis wrote:
>> On Fri, Nov 5, 2010 at 4: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!
>>
>> +1 This is precisely what we need.
>
> The jury's still you on this one though, see:
>
>   http://markmail.org/message/u4yctkaj2i3pms2o
>
>
Nathan,

Aren't juries about peers? In this case, aren't the peers those that 
publish and consume Linked Data?

I think practitioners make this call :-)

Leigh: yes, indeed, "Linked Data Practitioners" :-)

-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Saturday, 6 November 2010 16:31:25 UTC