- 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