afs commented on issue #1615: URL: https://github.com/apache/jena/issues/1615#issuecomment-1315212658
> Does it mean that "SPARQL is evaluated bottom-up" would not be true anymore? Have to be careful here. It's the operator that determines the evaluation, there isn't some policy for the whole expression. Just most current algebra operators are depth first evaluation (AKA functions) and we all say "evaluated bottom-up". `(join A B)` is bottom up because `join` says "evaluate the arguments separately then join the resulting tables". It is the "evaluate the arguments then ..." which makes it a well-behaved function; it is doing a depth first walk "bottom-up". `(lateral A B)` says "eval A, then loop on its rows, evaluating B such that the row from A is available for variables". Defining the "row being available to A" as careful injection means eval `A[row]` is normal SPARQL evaluation, not a special case for inside LATERAL. The proposal is that the row is `inject`ed (by the [corrected `substitute`](https://afs.github.io/substitute.html) operation) - the variable name is still there but it's binding is fixed by having a `BIND` just before it. There are places that require a variable work e.g. `SELECT ?var` or `FILTER(bound(?var))` where replacing a variable by it's value fails. ---- There is a discussion point about whether "eval B with row from A" should or should not use the in-scope rules for variables: ``` SELECT * { ?s ?p ?o LATERAL { SELECT ?label { ?s rdfs:label ?label } LIMIT 1 } } ``` Does the `?s` in `{ ?s rdfs:label ?label }` connect to the `?s` before the `LATERAL`? From a SPARQL POV, that sub-query can otherwise be `SELECT ?label { ?z rdfs:label ?label } LIMIT 1` or `SELECT ?label { [] rdfs:label ?label } LIMIT 1` for the same results. `?label` is unrelated to the LHS triple because `?s` isn't in the `SELECT`. `SELECT ?s ?label { ?s rdfs:label ?label } LIMIT 1` does make the `?s` see the `?s` of `?s ?p ?o`. Ditto `SELECT * { ?s rdfs:label ?label } LIMIT 1`. Just for `LATERAL`, it could be "no scope rules" and the inner `?s` does see the LHS `?s`. At the moment, I'm more inclined to the scoping version so that there isn't a eval special case of "inside LATERAL" and making developing big queries piece-by-piece more predicable (arguably), but it does cause a "surprise" case. Another reason is that special cases tend to have complicated consequences. When/if we have query template and parameterization, unconditionally replacing `?s` by an RDF term makes sense and easier for users to comprehend. -- 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]
