W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Fed query ... more comments

From: Polleres, Axel <axel.polleres@deri.org>
Date: Tue, 26 Jul 2011 13:28:07 +0100
Message-ID: <316ADBDBFE4F4D4AA4FEEF7496ECAEF903E8C5A5@EVS1.ac.nuigalway.ie>
To: <public-rdf-dawg@w3.org>
Hi Carlos, all,
I wonder whether my comments in 
were potentially overlooked?
For convenience I post them again:
I looked at the example in Section 2.6 of 

I assume that's the new part.


1) Firstly, I would suggest to rename the section from 


 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?

Dr. Axel Polleres
axel.polleres@deri.org    http://www.polleres.net/
Received on Tuesday, 26 July 2011 12:28:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:04 UTC