- From: Polleres, Axel <axel.polleres@deri.org>
- Date: Tue, 26 Jul 2011 13:28:07 +0100
- To: <public-rdf-dawg@w3.org>
Hi Carlos, all,
I wonder whether my comments in
http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JulSep/0025.html
were potentially overlooked?
For convenience I post them again:
I looked at the example in Section 2.6 of
http://www.w3.org/2009/sparql/docs/fed/service.xml
i.e.
http://www.w3.org/2009/sparql/docs/fed/service.xml#bindings
I assume that's the new part.
Comments:
1) Firstly, I would suggest to rename the section from
2.6 BINDINGS
to
2.6 Interplay of SERVICE and BINDINGS
2) Frankly, I am not sure the example is covers the intuition. In that example, I guess one would just write
PREFIX : <http://example.org/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?s ?o1 ?o2
{
?s ?p1 ?o1
OPTIONAL { SERVICE <http://example.org/sparql> {?s foaf:knows :b }}
} }
So, maybe it's just me who doesn't get BINDINGS, but I'd suggest, that the example is modified is follows:
I would first add information in the default graph, stating that
these are foaf:person. (just to avoid duplicate rows and make the result table simpler
Data in default graph:
<http://example.org/a> a <http://xmlns.com/foaf/0.1/Person> ;
<http://xmlns.com/foaf/0.1/name> "Alan" ;
<http://xmlns.com/foaf/0.1/mbox> "alan@example.org" .
<http://example.org/b> a <http://xmlns.com/foaf/0.1/Person> ;
<http://xmlns.com/foaf/0.1/name> "Bob" ;
<http://xmlns.com/foaf/0.1/mbox> "bob@example.org" .
<http://example.org/c> a <http://xmlns.com/foaf/0.1/Person> ;
<http://xmlns.com/foaf/0.1/name> "Alice" ;
<http://xmlns.com/foaf/0.1/mbox> "alice@example.org" .
and then
"The following example shows how SERVICE and BINDINGS are combined. The query asks for all foaf:Persons in the default graph and optionally obtaining their known people in the remote endpoint <http://example.org/sparql>.
When the original query
PREFIX : <http://example.org/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?s ?o
{
?s a foaf:Person
OPTIONAL { SERVICE <http://example.org/sparql> {?s foaf:knows ?o }}
} }
is executed naively, with an unconstrained service call
SELECT * {?s foaf:knows ?o }
to <http://example.org/sparql>, the endpoint may not return all results: many existing SPARQL endpoints have restrictions in the number of results they return and may miss the ones matching subjects ?s from the default graph.
Thus, an implementation of a query planner for federated queries, may decide to decompose the query into two queries instead, where first the bindings from the default graph are evaluated:
PREFIX : <http://example.org/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?s ?o1 ?o2
{
?s a foaf:Person
}
obtaining results for ?s :
+------+
| ?s |
+------+
| :a |
| :b |
| :c |
+------+
and then, instead of issuing an unconstrained Query, dispatch the constrained query
SELECT * {?s foaf:knows ?o } BINDINGS ?s { (:a) (:b) (:c) }
to <http://example.org/sparql> .
Does that make sense?
Axel
--
Dr. Axel Polleres
axel.polleres@deri.org http://www.polleres.net/
Received on Tuesday, 26 July 2011 12:28:36 UTC