Re: How to serve hash URIs from a (Virtuoso) SPARQL endpoint?

Hi Christoph, 

Caveat: I know nothing about Virtuoso. But the most sensible way of doing this is to add all of the triples which are said to be contained in the given document http://our.server/data/document to the named graph <http://our.server/data/document> when uploading the RDF to your triplestore (quadstore am guessing).

This should allow you to write a query similar to : 

construct {?s ?p ?o} where 
{graph <http://our.server/data/document> {?s ?p ?o}}

which in turn should give you the desired outcome. The SPARQL optimiser should in turn do something cleverer than selecting all of the subject URIs and then regexing them as per the query you emailed round. 

In short, if you are hosting a linked data app from a sparql endpoint it makes sense to use meaningful graph URIs, ones which mimic the document structure which you intend to be making constructs of. 

I hope this helps, 

Mischa

On 19 May 2010, at 09:50, Christoph LANGE wrote:

> Dear all,
> 
>  the data we would like to publish have hash URIs.  We have translated them
> to RDF and store the RDF in a Virtuoso triple store with a SPARQL endpoint.
> 
> Now, when a client requests application/rdf+xml from a cool URI like
> http://our.server/data/document#fragment, it actually makes a request for
> http://our.server/data/document.  In the resulting RDF/XML it expects to find
> the desired information unter rdf:ID="fragment" or
> rdf:about="http://...#fragment", i.e. resolving everything behind the # is up
> to the client.  That is, the RDF/XML document the server returns for
> http://our.server/data/document must contain all triples relevant for
> <http://our.server/data/document> and for any
> <http://our.server/data/document#whatever> – i.e. we would essentially like
> our SPARQL endpoint to emulate the behavior of a stupid web server serving a
> static http://.../document.rdf file, which contains all those triples.
> 
> So far, our solution is that we rewrite the cool URI into the following query
> to the SPARQL endpoint:
> 
> construct { ?s ?p ?o }
> where { ?s ?p ?o .
>    filter(
>        ?s = "http://our.server/data/document"
>            ||
>        regex(?s,"^http://our.server/data/document#"))
> }
> 
> That works, it's even efficient – but I wonder whether there is any better way
> of doing it.
> 
> Thanks for your feedback,
> 
> Christoph
> 
> -- 
> Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

Received on Wednesday, 19 May 2010 12:07:36 UTC