Christoph LANGE wrote:
Hi Hugh,
[@Nathan, thanks for forwarding it to the Virtuoso list; I subscribed there
now, but I thought the question might also be of a more general interest
w.r.t. deploying hash URIs.]
2010-05-19 14:51 Hugh Williams <[email protected]>:
The following Virtuoso Linked Data Deployment Guide details how hash URIs can
be handled by the server using transparent content negotiation:
http://www.openlinksw.com/virtuoso/Whitepapers/html/vdld_html/VirtDeployingLinkedDataGuide.html
Which would also apply to the data you are attempting to publish ...
Thanks, I had looked there before, but got the impression that that guide only
deals with the very special case of the "this" pseudo fragment ID, i.e. a
workaround of introducing hash URIs to facilitate content negotiation. I got
that impression because the guide talks about http://.../ALFKI#this, where
"ALFKI" is the entity of interest. Please let me know if I got something
wrong.
In our situation, we have many entities of interest, with the following URIs:
http://.../document (without fragment)
http://.../document#fragment1
http://.../document#fragment2
...
and when a client requests RDF/XML from http://.../document, the client should
get a document that contains all triples for http://.../document,
http://.../document#fragment1, http://.../document#fragment2, etc.
(Note that we were not free to choose this URI format; it was given before we
went "linked data".)
Cheers, and thanks,
Christoph
Christoph,
Whatever the SPARQL query required to return all triples of the form
http://.../document[#fragment] in response to a request for
http://.../document,
- be it Mischa's suggestion (if you're able to load all triples with
subject http://.../document[#fragment] into graph http://.../data/document):
construct {?s ?p ?o} where
{graph <http://our.server/data/document> {?s ?p ?o}}
- or the original query (if you're not):
construct { ?s ?p ?o }
where { ?s ?p ?o .
filter(
?s = "http://our.server/data/document";
||
regex(?s,"^http://our.server/data/document#";))
}
you should be able to hide either behind a Virtuoso rewrite rule for
http://.../document.
Regards,
Carl Blakeley
OpenLink Software
