Re: Is 303 really necessary?

On 11/18/10 5:10 PM, David Booth wrote:
> Hi Ian,
>
> Although I applaud your efforts at finding a simpler solution, upon
> reflection I think I would vote against the "200 + Content-location"
> proposal,
> http://iand.posterous.com/a-guide-to-publishing-linked-data-without-red
> for these reasons:
>
> 1. I think adding a third option to the "use either hash URIs or 303
> redirects" guidance will cause more harm then good to the LOD community.
> There is already enough confusion over "Should I use a hash URI or a 303
> and why?" question.  A third option is likely to create even more
> confusion.
>
> 2. I don't see the extra network access of 303 as being such a big deal
> -- though YMMV -- since even though the 303 response itself is not
> supposed to be cached (per RDF 2616), the toucan description document
> returned in the following 200 response can (and should) be cached.  In
> fact, if you have n slash URIs U1, U2, ... Un etc. that share the same
> description document, then with the 200+CL approach the entire
> description document would have to be returned n times, whereas with the
> 303 approach the description document would only be retrieved once: the
> rest of the n network access would be short 303 responses.
>
> 3. The proposed use of the Content-location header is not aligned with
> the RFC 2616 or HTTPbis definitions of its purpose:
> http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#page-24
> That header does not indicate that the returned representation is *not*
> a representation corresponding to the effective request URI.  Rather, it
> says that it is *also* a representation corresponding to the
> Content-location URI.  I.e., the returned representation is *both* a
> representation of a generic *and* a more specific resource.
>
> Best wishes,
>
>
David,

What about the aspect of this idea that's based on the content of the 
self-describing description document? Basically, that a Linked Data 
aware user agent interprets the world view expressed in the content?

I still believe there is a common ground here that isn't coming through 
i.e., nothing is broken, and people can drop description documents into 
data spaces on HTTP networks (e.g., WWW)  where Subjects are identified 
using slash URIs, without any Linked Data aware user agent confusion re. 
Subject Name and Description Document Address confusion.

Developers of Linked Data aware solutions (e.g. user agents and user 
agent extensions) are the ones that need to make a decision about 
semantic-fidelity i.e., do they stick with HTTP response codes, our use 
a combination of HTTP response codes, HTTP session metadata,  and 
description document content, to disambiguate Names and Addresses.

To conclude, I am saying:

1. No new HTTP response codes
2. Web Servers continue to return 200 OK for Document URLs
3. Linked Data Servers have option handle Name or Address disambiguation 
using 303 redirection for slash URIs
4. Linked Data Servers have option to be like Web Servers i.e. do no 
Name or Address disambiguation leaving Linked Data aware user agents to 
understand the content of Description Documents
5. Linked Data aware User Agents handle Name or Address disambiguation.

IMHO: when the dust settles, this is what it boils down to. On our side, 
we're done re. 1-5 across our Linked Data server and client 
functionality, as delivered by our products :-)

-- 

Regards,

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