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

Re: question regarding SERVICE extension

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 04 Aug 2010 19:40:08 +0100
Message-ID: <4C59B408.2060006@epimorphics.com>
To: Carlos Buil Aranda <cbuil@fi.upm.es>
CC: public-rdf-dawg@w3.org

On 03/08/2010 8:11 PM, Carlos Buil Aranda wrote:
> Dear all,
> Iíve been working in a SPARQL 1.1 federation extension. I have
> implemented the SERVICE part but a couple of questions came to my mind
> and I need a bit of help. First thing is the results of a SERVICE
> clause. I suppose, if I understood correctly
> http://www.w3.org/2009/sparql/docs/fed/service#defn_service that SERVICE
> returns as results all the variables in it. In the following example I
> suppose that first the SERVICE clauses are processed, and then, using
> all the variables from the two services in the query the OPTIONAL would
> be done. The first service output would be ?gene and the second one
> would be ?gene, ?taxon and ?xGI, righ?
> SELECT ?gene ?taxon
> {
> SERVICE <http://iproclass.bio2rdf.org/sparql>
> { <http://bio2rdf.org/iproclass:Q8KKD2>
> <http://bio2rdf.org/ns/iproclass#xGeneid> ?gene .}
> SERVICE <http://geneid.bio2rdf.org/sparql> {
> ?gene <http://bio2rdf.org/ns/bio2rdf#xTaxon> ?taxon .
> ?taxon <http://bio2rdf.org/ontology/bio2rdf:xGI> ?xGI . }
> }
> }

Yes - SERVICE is a remote "SELECT *"
Your question is also  about general SPARQL execution.

OPTIONAL maps to a LeftJoin operator, so the left and right (LHS, RHS) 
get evaluated to produce intermediate multisets of bindings, which are 
then left joined.  There are various optimizations possible.

> My second question is regarding the possibility of having nested SERVICE
> operators in a query. Is that possible?

No reason why not but note that SERVICE <s> { pattern } ships pattern 
off to the far end, so the nested service is executed on the remote 
machine.  The far end may not support SERVICE in which case it isn't 
going to work.

> The grammar allows that, but in
> the specification I think I have not seen anything explicit. Whould this
> be possible? which would be the semantics of the query? is it allowed to
> have variables instead of URIs pointing to an endpoint? which would be
> the semantics?

The authoritative text is whatever is in the document so it's always 
good to go back to the espec text (editor's working draft) and see what 
it says.  Then we can improve/fix/whatever the text.

See http://www.w3.org/2009/sparql/docs/fed/service.xml#varService

A variable may be used in place of a service IRI indicating that the 
service call for any solution depends on that variable's binding in that 

which is tricky in talking about the variable's binding because the 
SERVICE element is joined (or leftJoined) with other elements in bottom 
up evaluation.  See the "Editorial note" at the end of sec 2.1.

In GRAPH ?g { ...} ?g ranges over the IRIs of pairs of named graphs in 
the dataset.  This does not apply when "SERVICE ?service" is of 
unbounded range.

One possibility is to define the way the SERVICE combines with other 
elements to be specific kinds of join.  Evaluate the pattern up to that 
point and define SERVICE to be the result of looping on the intermediate 
results, then ?service can be substitued for whatever it is in a 
particular solution.

This also works well with SERVICE+BINDINGS as then the BINDINGS are the 
earlier results, and can be streamed naturally.  BINDINGS are now very 
like values for parameterized queries (c.f. SQL), just using naming for 
the parameters, not positions.

> SELECT ?gene ?taxon
> {
> SERVICE <http://iproclass.bio2rdf.org/sparql>
> { ?prot <http://bio2rdf.org/ns/iproclass#xGeneid> ?gene .}
> SERVICE <http://geneid.bio2rdf.org/sparql> {
> ?gene <http://bio2rdf.org/ns/bio2rdf#xTaxon> ?taxon .
> ?taxon <http://bio2rdf.org/ontology/bio2rdf:xGI> ?xGI . }
> }
> Thanks a lot :)
> Carlos

Received on Wednesday, 4 August 2010 18:40:43 UTC

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