- From: Andreas Langegger <al@jku.at>
- Date: Tue, 08 Sep 2009 20:21:35 +0200
- 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 UTC