Aklakan commented on issue #1314:
URL: https://github.com/apache/jena/issues/1314#issuecomment-1148717089
The advantage of extra LOOP syntax would be that the loop variables can be
easily specified.
With the SERVICE approach I was thinking about the rule that any variable
*visible* on the lhs and *mentioned* in the rhs would be implicit loop
variables.
With regard to caching and bulk retrieval, I think those would remain as
options on the SERVICE clause:
The LOOP yields a QueryIterator of input bindings and the service extension
would then take care of grouping as many input bindings as it sees fit into
batch requests (as it is done right now) - so all options (except for
correlate) would still be at the level of the service clause:
```
LOOP (?x) { SERVICE <cache:bulk+20:http://dbpedia.org/sparql> { }
```
(The options may also be represented using your proposed extension syntax
extension - something along the lines of `SERVICE <http://dbpedia.org/sparql>
ARGS bulk=20 cache`)
Note, that IMHO a clean solution would require making TransformScopeRename
aware of correlated joins and scoping of the loop variables. So this feature
actually has implications on the core of ARQ. Of course, I'd favor the clean
solution :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
