fed query BINDINGs

Just talked to Lee about the BINDINGS section again.

First, I had suggested to rename the section to something like 

"Using SERVICE in combination with BINDINGS"

or maybe even better 

"Using BINDING to implement SERVICE"

I also realised that the following comment was probably confusing (or better I wrote it like that because I was confused...

> 21) Section 2.2 BINDINGS
> 
> "In order to efficiently communicate constraints to sparql endpoints, the queryier may follow the WHERE clause with BINDINGS. In order to efficiently address the constraints, the query on 
> http://people.example/data
>  could be expressed as follows:"
> 
> I don't understand entirely, as in case BINDINGS doesn't appear in the SERVICE clause, the "constraints" don't even reach the remote endpoint... shouldn't we reformulate the example to actually have the BINDINGS *within* the SERVICE pattern?
> 
> That would make more sense to me.
> 
> Accordingly, I would suggest to rephrase:
> 
> "In order to efficiently communicate constraints to sparql endpoints, the requester may use SERVICE in combination with a BINDINGS clause (see [SPARQL 1.1 Query], Section 18.2.5.6 BINDINGS). In order to efficiently address the constraints, the query on 
> http://people.example/data
>  could be expressed as follows:"
> 
> Also, note that the advantage of BINDINGS only comes across if you use several bindings, since a single binding can be written directly into the query. So, I would suggest to think of a better example or drop the BINDINGS section alltogether.


So, what I rather think is that this section should show, is an example how BINDINGS queries are used by an implementation to implement SERVICE, i.e. given the original SERVICE query and what it boils down to when the non-SERVICE part has been evaluated and is rewritten to a BINDINGS query... makes sense?

HTH,
Axel

Received on Tuesday, 26 April 2011 13:06:37 UTC