- From: Carl Blakeley <cblakeley@openlinksw.co.uk>
- Date: Wed, 19 May 2010 17:49:44 +0100
- To: Christoph LANGE <ch.lange@jacobs-university.de>
- CC: Hugh Williams <hwilliams@openlinksw.com>, Virtuoso Users List <virtuoso-users@lists.sourceforge.net>, "public-lod@w3.org" <public-lod@w3.org>, "nikita.zhiltsov@gmail.com" <nikita.zhiltsov@gmail.com>, "Zholudev, Vyacheslav V." <v.zholudev@jacobs-university.de>
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 <hwilliams@openlinksw.com>: > >> 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
Received on Wednesday, 19 May 2010 20:35:15 UTC