Re: 303 redirect to a fragment – what should a linked data client do?
Hi, Am 10.06.2010 14:34, schrieb Nathan: Christoph LANGE wrote: 2010-06-10 13:40 Christoph LANGE ch.la...@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 :) However, I think this is still the important gap we have to bridge between 'the old' existing web and 'the new' forthcoming web, which will hopefully provide a semantic graph knowledge/information representation behind every dereferencable URI. Cheers, Bob
303 redirect to a fragment – what should a linked data client do?
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? Thanks in advance for any help, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701 signature.asc Description: This is a digitally signed message part.
Re: 303 redirect to a fragment – what should a linked data client do?
2010-06-10 13:40 Christoph LANGE ch.la...@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. Cheers, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701 signature.asc Description: This is a digitally signed message part.
Re: 303 redirect to a fragment what should a linked data client do?
Christoph, Are you aware of the respective HTTPbis ticket [1]? Cheers, Michael [1] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43 -- Dr. Michael Hausenblas LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html From: Christoph LANGE ch.la...@jacobs-university.de Organization: Jacobs University Bremen Date: Thu, 10 Jun 2010 13:40:42 +0200 To: Linked Data community public-lod@w3.org Subject: 303 redirect to a fragment what should a linked data client do? Resent-From: Linked Data community public-lod@w3.org Resent-Date: Thu, 10 Jun 2010 11:40:31 + 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? Thanks in advance for any help, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
Re: 303 redirect to a fragment – what should a linked data client do?
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 long: 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. Best, Nathan
Re: 303 redirect to a fragment – what should a linked data client do?
Christoph LANGE wrote: 2010-06-10 13:40 Christoph LANGE ch.la...@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
Re: 303 redirect to a fragment – what should a linked data client do?
Hi Nathan, thanks for your clarifying reply! That gave me the confirmation that we were on the right track. Indeed I should not judge such issues from the behavior of browsers that are not even RDF-aware. Cheers, Christoph 2010-06-10 14:24 Nathan nat...@webr3.org: ... long: 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. -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701 signature.asc Description: This is a digitally signed message part.
Re: 303 redirect to a fragment – what should a linked data client do?
于 2010/6/11 5:41, Christoph LANGE 写道: Hi Nathan, thanks for your clarifying reply! That gave me the confirmation that we were on the right track. Indeed I should not judge such issues from the behavior of browsers that are not even RDF-aware. During I was developing a PIM tool, I realized that the only useful part of URI is its uniqueness. URI has nothing to the representation of content and the semantic meaning of content).URI organize things in a tree model, but information/Knowledge is networked, so URI isn't suitable for organizing information/knowledge. This fact let me think about how to organize information/knowledge by itself, and then I found a way to search by 'knowledge'. regards Peng Cheers, Christoph 2010-06-10 14:24 Nathannat...@webr3.org: ... long: 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.
Re: 303 redirect to a fragment what should a linked data client do?
2010-06-10 14:01 Michael Hausenblas michael.hausenb...@deri.org: Are you aware of the respective HTTPbis ticket [1]? [1] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43 Thanks, good to know – no, I didn't know that. Cheers, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701 signature.asc Description: This is a digitally signed message part.
