W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > September 2009

Re: RDF dataset/SPARQL endpoint descriptions

From: Andreas Langegger <al@jku.at>
Date: Tue, 08 Sep 2009 20:21:35 +0200
Message-ID: <4AA6A0AF.104@jku.at>
To: public-rdf-dawg-comments@w3.org, jena-dev@yahoogroups.com
Hi there,

I've implemented several features for ARQ/Joseki which I require for 
query federation with SemWIQ [1]. Feel free to try it out and comment.

http://ramses.faw.uni-linz.ac.at:8900

As I suggested before I would separate service and dataset descriptions 
(e.g. provide DESCRIBE DATASET and DESCRIBE SERVICE and sub queries such 
as SELECT * FROM { DESCRIBE DATASET } WHERE ... later on)

In order to benefit from HTTP caching, the endpoint should not only 
provide dataset descriptions (possibly including statistics) as SPARQL 
results, it should allow to retrieve them via HTTP and check the 
Last-modified header, etc. That's what I'm doing when monitoring 
datasources for SemWIQ => exec DESCRIBE SERVICE and follow the 
void:Dataset link.

For query federation, it would be very useful if the future SPARQL REC 
supports BINDINGS such as introduced by Eric [2] before. My proposal 
works with a set of bindings with a special "null" keyword for unbound 
variables, e.g.:

SELECT * WHERE {
   ?s :p ?a ; :p ?b ; ...
} BINDINGS ?a ?b {
   bsbm:Product "34"^^xsd:int .
   null "23"^^xsd:int .
   foaf:Person . // remaining slots are interpreted as empty (null)
}

It is not much effort for implementers and a federated query processor 
can then process pipelined blocks of queries more efficiently.

Regards,
AndyL

[1] http://semwiq.sourceforge.net - available soon
[2] http://www.w3.org/2007/05/SPARQLfed/

> 
> Hi Andy,
> 
> Thanks for sharing the experience. Separating the service from the
> dataset makes a lot of sense, I like that idea.
> 
> Cheers,
> Benji 
Received on Tuesday, 8 September 2009 18:22:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 September 2009 18:22:19 GMT