Christoph LANGE wrote:
2010-06-10 13:40 Christoph LANGE <[email protected]>:
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
