Re: 200 OK with Content-Location might work

Niklas,

In general I am supportive of Ian's thinking and 200 OK with
Content-Location might work...

However, three points from my perspective:

1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).

2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD. Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.

3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s. If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.

Hope these thoughts help,

John.

On Sun, 2010-11-07 at 12:11 +0100, Niklas Lindström wrote:
> +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 Monday, 8 November 2010 08:12:50 UTC