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,

Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.