You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by GitBox <gi...@apache.org> on 2022/11/21 20:33:47 UTC
[GitHub] [jena-site] afs opened a new pull request, #132: Documentation for LATERAL
afs opened a new pull request, #132:
URL: https://github.com/apache/jena-site/pull/132
Documentation for https://github.com/apache/jena/pull/1631
--
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: dev-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [jena-site] afs closed pull request #132: Documentation for LATERAL
Posted by GitBox <gi...@apache.org>.
afs closed pull request #132: Documentation for LATERAL
URL: https://github.com/apache/jena-site/pull/132
--
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: dev-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [jena-site] afs commented on a diff in pull request #132: Documentation for LATERAL
Posted by GitBox <gi...@apache.org>.
afs commented on code in PR #132:
URL: https://github.com/apache/jena-site/pull/132#discussion_r1030641717
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
Review Comment:
Eventually!
It is a better/fixed way to do EXISTS and LATERAL but Jena does not currently have a specific implementation.
It's on my ToDo list.
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
Review Comment:
Done
--
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: dev-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [jena-site] rvesse commented on a diff in pull request #132: Documentation for LATERAL
Posted by GitBox <gi...@apache.org>.
rvesse commented on code in PR #132:
URL: https://github.com/apache/jena-site/pull/132#discussion_r1030195581
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
+
+#### Variable assignment
+
+There needs to be a new syntax restriction: there can no variable introduced by
+`AS` (`BIND`, or sub-query) or `VALUES` in-scope at the top level of the
+`LATERAL` RHS, that is the same name as any
+[in-scope](https://www.w3.org/TR/sparql11-query/#variableScope) variable from
+the LHS.
+
+Such a variable assignment would conflict with the variable being set in
+variables of the row being joined.
+
+```
+## ** Illegal **
+SELECT * {
+ ?s ?p ?o
+ LATERAL { BIND( 123 AS ?o) }
+}
+```
+
+See [SPARQL Grammar note 12](https://www.w3.org/TR/sparql11-query/#sparqlGrammar).
+
+In ARQ, [LET](assignment.html) would work.
+`LET` for a variable that is bound acts like a filter.
+
+#### Variable Scopes
+
+In looping on the input, a lateral join makes the bindings of variables in the current row
+available to the right hand side pattern, settign their value from the top down.
+
+In SPARQL, it is possible to have variables of the same name which are not
+exposed within a sub-select. These are not lateral-joined to a variable of the
+same name from the LHS.
+
+This is not speciifc to lateral joins. In
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?s rdfs:label ?label } }
+```
+the inner `?s` can be replaced by `?z` without changing the results because the
+inner `?s` is not joined to the outer `?s` but instead is hidden by the `SELECT ?label`.
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?z rdfs:label ?label } }
+```
+
+The same rule applies to lateral joins.
+```
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT ?label { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+The inner `?s` in the `SELECT ?label` is not the outer `?s` because the `SELECT
+?label` does not pass out `?s`. As a sub-query the `?s` could be any name except
+`?label` for the same results.
+
+### Notes
+
+There is a similarity to filter `NOT EXISTS`/`EXISTS` expressed as the not-legal `FILTER ( ASK { pattern } )` where the variables of the row being filtered are available to "pattern". This is similar to ab SQL [correlated subquery](https://en.wikipedia.org/wiki/Correlated_subquery).
Review Comment:
```suggestion
There is a similarity to filter `NOT EXISTS`/`EXISTS` expressed as the non-legal `FILTER ( ASK { pattern } )` where the variables of the row being filtered are available to "pattern". This is similar to a SQL [correlated subquery](https://en.wikipedia.org/wiki/Correlated_subquery).
```
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
+
+#### Variable assignment
+
+There needs to be a new syntax restriction: there can no variable introduced by
+`AS` (`BIND`, or sub-query) or `VALUES` in-scope at the top level of the
+`LATERAL` RHS, that is the same name as any
+[in-scope](https://www.w3.org/TR/sparql11-query/#variableScope) variable from
+the LHS.
+
+Such a variable assignment would conflict with the variable being set in
+variables of the row being joined.
+
+```
+## ** Illegal **
+SELECT * {
+ ?s ?p ?o
+ LATERAL { BIND( 123 AS ?o) }
+}
+```
+
+See [SPARQL Grammar note 12](https://www.w3.org/TR/sparql11-query/#sparqlGrammar).
+
+In ARQ, [LET](assignment.html) would work.
+`LET` for a variable that is bound acts like a filter.
+
+#### Variable Scopes
+
+In looping on the input, a lateral join makes the bindings of variables in the current row
+available to the right hand side pattern, settign their value from the top down.
Review Comment:
```suggestion
available to the right hand side pattern, setting their value from the top down.
```
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
+
+#### Variable assignment
+
+There needs to be a new syntax restriction: there can no variable introduced by
+`AS` (`BIND`, or sub-query) or `VALUES` in-scope at the top level of the
+`LATERAL` RHS, that is the same name as any
+[in-scope](https://www.w3.org/TR/sparql11-query/#variableScope) variable from
+the LHS.
+
+Such a variable assignment would conflict with the variable being set in
+variables of the row being joined.
+
+```
+## ** Illegal **
+SELECT * {
+ ?s ?p ?o
+ LATERAL { BIND( 123 AS ?o) }
+}
+```
+
+See [SPARQL Grammar note 12](https://www.w3.org/TR/sparql11-query/#sparqlGrammar).
+
+In ARQ, [LET](assignment.html) would work.
+`LET` for a variable that is bound acts like a filter.
+
+#### Variable Scopes
+
+In looping on the input, a lateral join makes the bindings of variables in the current row
+available to the right hand side pattern, settign their value from the top down.
+
+In SPARQL, it is possible to have variables of the same name which are not
+exposed within a sub-select. These are not lateral-joined to a variable of the
+same name from the LHS.
+
+This is not speciifc to lateral joins. In
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?s rdfs:label ?label } }
+```
+the inner `?s` can be replaced by `?z` without changing the results because the
+inner `?s` is not joined to the outer `?s` but instead is hidden by the `SELECT ?label`.
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?z rdfs:label ?label } }
+```
+
+The same rule applies to lateral joins.
+```
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT ?label { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+The inner `?s` in the `SELECT ?label` is not the outer `?s` because the `SELECT
+?label` does not pass out `?s`. As a sub-query the `?s` could be any name except
+`?label` for the same results.
+
+### Notes
+
+There is a similarity to filter `NOT EXISTS`/`EXISTS` expressed as the not-legal `FILTER ( ASK { pattern } )` where the variables of the row being filtered are available to "pattern". This is similar to ab SQL [correlated subquery](https://en.wikipedia.org/wiki/Correlated_subquery).
+
+## SPARQL Specification Additional Material
+
+### Syntax
+
+`LATERAL` is added to the SPARQL grammar at rule `[[56] GraphPatternNotTriples](https://www.w3.org/TR/sparql11-query/#rGraphPatternNotTriples)`. As a syntax form, it is similar to `OPTIONAL`.
+
+```
+[56] GraphPatternNotTriples ::= GroupOrUnionGraphPattern | OptionalGraphPattern | LateralGraphPattern | ...
+[57] OptionalGraphPattern ::= 'OPTIONAL' GroupGraphPattern
+[ ] LateralGraphPattern ::= 'LATERAL' GroupGraphPattern
+```
+
+### Algebra
+
+The new algebra is operator is `lateral` which takes two expressions
Review Comment:
```suggestion
The new algebra operator is `lateral` which takes two expressions
```
--
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: dev-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [jena-site] afs commented on pull request #132: Documentation for LATERAL
Posted by GitBox <gi...@apache.org>.
afs commented on PR #132:
URL: https://github.com/apache/jena-site/pull/132#issuecomment-1369596211
Done via website update for 4.7.0.
--
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: dev-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [jena-site] kinow commented on a diff in pull request #132: Documentation for LATERAL
Posted by GitBox <gi...@apache.org>.
kinow commented on code in PR #132:
URL: https://github.com/apache/jena-site/pull/132#discussion_r1028512381
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
Review Comment:
s/jena/Jena
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
Review Comment:
Period? `.` :grimacing:
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
+
+#### Variable assignment
+
+There needs to be a new syntax restriction: there can no variable introduced by
+`AS` (`BIND`, or sub-query) or `VALUES` in-scope at the top level of the
+`LATERAL` RHS, that is the same name as any
+[in-scope](https://www.w3.org/TR/sparql11-query/#variableScope) variable from
+the LHS.
+
+Such a variable assignment would conflict with the variable being set in
+variables of the row being joined.
+
+```
+## ** Illegal **
+SELECT * {
+ ?s ?p ?o
+ LATERAL { BIND( 123 AS ?o) }
+}
+```
+
+See [SPARQL Grammar note 12](https://www.w3.org/TR/sparql11-query/#sparqlGrammar).
+
+In ARQ, [LET](assignment.html) would work.
+`LET` for a variable that is bound acts like a filter.
+
+#### Variable Scopes
+
+In looping on the input, a lateral join makes the bindings of variables in the current row
+available to the right hand side pattern, settign their value from the top down.
+
+In SPARQL, it is possible to have variables of the same name which are not
+exposed within a sub-select. These are not lateral-joined to a variable of the
+same name from the LHS.
+
+This is not speciifc to lateral joins. In
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?s rdfs:label ?label } }
+```
+the inner `?s` can be replaced by `?z` without changing the results because the
+inner `?s` is not joined to the outer `?s` but instead is hidden by the `SELECT ?label`.
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?z rdfs:label ?label } }
+```
+
+The same rule applies to lateral joins.
+```
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT ?label { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+The inner `?s` in the `SELECT ?label` is not the outer `?s` because the `SELECT
+?label` does not pass out `?s`. As a sub-query the `?s` could be any name except
+`?label` for the same results.
+
+### Notes
+
+There is a similarity to filter `NOT EXISTS`/`EXISTS` expressed as the not-legal `FILTER ( ASK { pattern } )` where the variables of the row being filtered are available to "pattern". This is similar to ab SQL [correlated subquery](https://en.wikipedia.org/wiki/Correlated_subquery).
+
+## SPARQL Specification Additional Material
+
+### Syntax
+
+`LATERAL` is added to the SPARQL grammar at rule `[[56] GraphPatternNotTriples](https://www.w3.org/TR/sparql11-query/#rGraphPatternNotTriples)`. As a syntax form, it is similar to `OPTIONAL`.
+
+```
+[56] GraphPatternNotTriples ::= GroupOrUnionGraphPattern | OptionalGraphPattern | LateralGraphPattern | ...
+[57] OptionalGraphPattern ::= 'OPTIONAL' GroupGraphPattern
+[ ] LateralGraphPattern ::= 'LATERAL' GroupGraphPattern
+```
+
+### Algebra
+
+The new algebra is operator is `lateral` which takes two expressions
Review Comment:
Drop the first `is` ?
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
Review Comment:
Looks useful to Jena users, should it be moved to jena.apache.org too?
##########
source/documentation/query/lateral-join.md:
##########
@@ -0,0 +1,174 @@
+---
+title: ARQ - Lateral Join
+---
+
+Lateral joins using the keyword `LATERAL` were introduced in Apache jena 4.7.0.
+
+A `LATERAL` join is like a foreach loop, looping on the results from the
+left-hand side (LHS), the pattern before the `LATERAL` keyword, and executing
+the right-hand side (RHS) query pattern once for each row, with the variables
+from the input LHS in-scope during each RHS evaluation.
+
+A regular join only executes the RHS once, and the variables from the LHS are
+used for the join condition after evaluation of the left and right
+sub-patterns.
+
+Another way to think of a lateral join is as a `flatmap`.
+
+Examples:
+```
+## Get exactly one label for each subject with type `:T`
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT * { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+```
+## Get zero or one labels for each subject.
+SELECT * {
+ ?s ?p ?o
+ LATERAL { OPTIONAL { SELECT * ?s rdfs:label ?label } LIMIT 1}
+ }
+}
+```
+
+#### Syntax
+
+The `LATERAL` keyword which takes the graph pattern so far in the group, from
+the `{` starting of the current block, and a `{ }` block afterwards.
+
+#### Evaluation
+
+[Substituting variables](https://afs.github.io/substitute.html) from the LHS into the RHS (with the same restrictions), then executing the pattern, gives the evaluation of `LATERAL`
+
+#### Variable assignment
+
+There needs to be a new syntax restriction: there can no variable introduced by
+`AS` (`BIND`, or sub-query) or `VALUES` in-scope at the top level of the
+`LATERAL` RHS, that is the same name as any
+[in-scope](https://www.w3.org/TR/sparql11-query/#variableScope) variable from
+the LHS.
+
+Such a variable assignment would conflict with the variable being set in
+variables of the row being joined.
+
+```
+## ** Illegal **
+SELECT * {
+ ?s ?p ?o
+ LATERAL { BIND( 123 AS ?o) }
+}
+```
+
+See [SPARQL Grammar note 12](https://www.w3.org/TR/sparql11-query/#sparqlGrammar).
+
+In ARQ, [LET](assignment.html) would work.
+`LET` for a variable that is bound acts like a filter.
+
+#### Variable Scopes
+
+In looping on the input, a lateral join makes the bindings of variables in the current row
+available to the right hand side pattern, settign their value from the top down.
+
+In SPARQL, it is possible to have variables of the same name which are not
+exposed within a sub-select. These are not lateral-joined to a variable of the
+same name from the LHS.
+
+This is not speciifc to lateral joins. In
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?s rdfs:label ?label } }
+```
+the inner `?s` can be replaced by `?z` without changing the results because the
+inner `?s` is not joined to the outer `?s` but instead is hidden by the `SELECT ?label`.
+```
+SELECT * {
+ ?s rdf:type :T
+ { SELECT ?label { ?z rdfs:label ?label } }
+```
+
+The same rule applies to lateral joins.
+```
+SELECT * {
+ ?s rdf:type :T
+ LATERAL {
+ SELECT ?label { ?s rdfs:label ?label } LIMIT 1
+ }
+}
+```
+
+The inner `?s` in the `SELECT ?label` is not the outer `?s` because the `SELECT
+?label` does not pass out `?s`. As a sub-query the `?s` could be any name except
+`?label` for the same results.
+
+### Notes
+
+There is a similarity to filter `NOT EXISTS`/`EXISTS` expressed as the not-legal `FILTER ( ASK { pattern } )` where the variables of the row being filtered are available to "pattern". This is similar to ab SQL [correlated subquery](https://en.wikipedia.org/wiki/Correlated_subquery).
Review Comment:
s/ab/an ?
--
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: dev-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [jena-site] afs commented on pull request #132: Documentation for LATERAL
Posted by GitBox <gi...@apache.org>.
afs commented on PR #132:
URL: https://github.com/apache/jena-site/pull/132#issuecomment-1325337964
Thank you both. Fixed done and fixed commit pushed.
--
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: dev-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org