- 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