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

Re: [Virtuoso-users] [Fwd: How to serve hash URIs from a (Virtuoso) SPARQL endpoint?]

From: Christoph LANGE <ch.lange@jacobs-university.de>
Date: Wed, 19 May 2010 15:41:47 +0200
To: Hugh Williams <hwilliams@openlinksw.com>
Cc: 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>
Message-Id: <201005191541.53776.ch.lange@jacobs-university.de>
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

In our situation, we have many entities of interest, with the following URIs:

http://.../document (without fragment)

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 Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

Received on Wednesday, 19 May 2010 13:41:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:48 UTC