W3C home > Mailing lists > Public > public-lod@w3.org > June 2010

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

From: Nathan <nathan@webr3.org>
Date: Thu, 10 Jun 2010 13:24:12 +0100
Message-ID: <4C10D96C.5040706@webr3.org>
To: Christoph LANGE <ch.lange@jacobs-university.de>
CC: public-lod@w3.org
Christoph LANGE wrote:
> Hi all,
>   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.
> But what should an RDF-aware client do?  I guess it should still look out for
> triples with the originally requested subject http://example.org/foo#bar, e.g. 
> <rdf:Description rdf:about="http://example.org/foo#bar">, or (assuming
> xml:base="http://example.org/foo") for <rdf:Description rdf:ID="bar">.  Is my
> assumption right?

Hi Christoph,

short: Yes

I've asked this question and several related a few times over the past 
few months (hence responding).

 From what I can tell what URI Identifier and dereferencing process (+ 
Request Response chain which follows) are entirely orthogonal issues.

To illustrate, if you dereference http://dbpedia.org/resource/London 
then the final RDF representation you get will be courtesy of 
http://dbpedia.org/data/London.[n3/rdf/ttl], but the RDF will still 
describe http://dbpedia.org/resource/London.

If you consider from a client / code standpoint in a setup where you 
have two modules abstracted from each other, an HTTP Client and an RDF 
Parser, the RDF Parser will request something like:
   rdf = HTTP->get( uri );
What the HTTP Client does, the deferencing process, the request response 
chain which follows, the values in the HTTP Header fields, is completely 
abstracted, transparent to the RDF Parser and indeed of no concern.

Thus regardless of how the HTTP request chain works out, if you try to 
get a RDF description for http://example.org/foo#bar then you'll still 
be looking for http://example.org/foo#bar in the RDF that you get back.


Received on Thursday, 10 June 2010 12:25:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:06 UTC