Re: 303 redirect to a fragment – what should a linked data client do?

Christoph LANGE wrote:
> 2010-06-10 13:40 Christoph LANGE <ch.lange@jacobs-university.de>:
>>   in our setup we are still somehow fighting with ill-conceived legacy URIs
>> from the pre-LOD age.  We heavily make use of hash URIs there, so it could
>> happen that a client, requesting http://example.org/foo#bar (thus actually
>> requesting http://example.org/foo) gets redirected to
>> http://example.org/baz#grr (note that I don't mean
>> http://example.org/baz%23grr here, but really the un-escaped hash).  I
>> observed that when serving such a result as XHTML, the browser (at least
>> Firefox) scrolls to the #grr fragment of the resulting page.
> 
> Update for those who are interested (all tested on Linux, test with
> http://kwarc.info/lodtest#misc --303-->
> http://kwarc.info/clange/publications.html#inproc for yourself):
> 
> * Firefox: #inproc
> * Chromium: #inproc
> * Konqueror: #inproc
> * Opera: #misc
> 
> That given, what would an _RDFa_-compliant client have to do?  I guess it
> would have to do the same as an RDF client, i.e. look into @about attributes
> if in doubt.

As Michael pointed out, there's an open ticket related to this on HTTPBis.

First, I'd suggest that we don't need to worry about what's displayed by 
the User Agents, it doesn't really have any bearing on the RDF contained 
in the response (even with RDFa).

Second, as with my previous reply, what happens with the dereferencing 
process is entirely orthogonal and abstracted from the RDF side of 
things, thus I'd suggest that in all cases when you want to find the 
description for a URI, you dereference it and consult the RDF 
description you get back.

If you get no RDF then you don't have a description, if you do then 
check the subject and object values of the triples to see if you can get 
a description. Everything that happens between is of no concern to us :)

Best,

Nathan

Received on Thursday, 10 June 2010 12:35:29 UTC