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
