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

ACTION-490 (review outcome of ACTION-462)

From: Polleres, Axel <axel.polleres@deri.org>
Date: Tue, 12 Jul 2011 15:03:20 +0100
Message-ID: <316ADBDBFE4F4D4AA4FEEF7496ECAEF903E8C57C@EVS1.ac.nuigalway.ie>
To: "Polleres, Axel" <axel.polleres@deri.org>, "Carlos Buil Aranda" <cbuil@fi.upm.es>, "SPARQL Working Group" <public-rdf-dawg@w3.org>

Dr. Axel Polleres
axel.polleres@deri.org    http://www.polleres.net/

-----Original Message-----
From: public-rdf-dawg-request@w3.org on behalf of Polleres, Axel
Sent: Tue 7/12/2011 2:28 PM
To: Carlos Buil Aranda; SPARQL Working Group
Subject: RE: regrets and completed action (ACTION-462 & ACTION-487)
jsut added action labels understandable for the tracker in the subject...

@all : If you complete actions label the mails announcing completions with "ACTION-XYZ" in subject or message body, such that our tracker recognises them.

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?




-----Original Message-----
From: public-rdf-dawg-request@w3.org on behalf of Carlos Buil Aranda
Sent: Mon 7/11/2011 7:27 PM
To: SPARQL Working Group
Subject: regrets and completed action
Hello all,

regrets for tomorrow. I won't be able to join the call. I have completed actions 462 and 487. Regarding ACTION 487 I wrote a small readme file which is in the tests folder. I do not know if it is enough with it.


Received on Tuesday, 12 July 2011 14:03:57 UTC

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