In SPARQL, one keyword ('Union') is used for two very different things. Specifically, it allows (i) the specification of alternatives for matching, and (ii) it changes the execution order (inside-out behavior).
For example, the following query does not allow any variables to be shared between the 'Ai'-s and the 'Bj'-s:
select * {
{ A1 } union { ... } union { Am }
{ B1 } union { ... } union { Bn }
}The only known workaround is to write out the Cartesian product, multiplying the 'Ai'-s with the 'Bj'-s:
select * {
{ A1 B1 } union { ... } union { A1 Bn } union { ... } union { Am B1 } union { ... } union { Am Bn }
}Notice that this results in 'm * n' Union components, i.o. the ideal 'm + n' components.
Why?
Overall, SPARQL allows efficient expression of graph-data needs. However, specifically for Unions, this efficiency is lost when we have to write a Cartesian product of Union components.
For example, I have a use case for a customer where 'm=6' and 'n=18', resulting in 108 (!) union components. Due to the high degree of repetition in these 108 Union components, it is practically impossible for me to write this query in SPARQL (without immediately violating regular deduplication checks employed by IT production systems).
Previous work
The only known workaround is to write the query in some other language (not SPARQL) that allows efficient 'm + n' specification, and generate a SPARQL query that contains the Cartesian 'm * n' product by automated means (some kind of permutation algorithm).
Proposed solution
A new keyword, e.g. 'Alt', that only allows alternative matching patterns to be specified, and that does not (also) change the execution order (inside-out behavior).
select * {
{ A1 } alt { ... } alt { Am }
{ B1 } alt { ... } alt { Bn }
}Considerations for backward compatibility
This feature request is fully backwards compatible, because the Union keyword remains available in the SPARQL language with its current meaning.
Users who want to specify alternatives and also nest scope at the same time can continue to use Union. Users who only want to express alternatives can start to use Alt.
In SPARQL, one keyword ('Union') is used for two very different things. Specifically, it allows (i) the specification of alternatives for matching, and (ii) it changes the execution order (inside-out behavior).
For example, the following query does not allow any variables to be shared between the 'Ai'-s and the 'Bj'-s:
select * { { A1 } union { ... } union { Am } { B1 } union { ... } union { Bn } }The only known workaround is to write out the Cartesian product, multiplying the 'Ai'-s with the 'Bj'-s:
select * { { A1 B1 } union { ... } union { A1 Bn } union { ... } union { Am B1 } union { ... } union { Am Bn } }Notice that this results in 'm * n' Union components, i.o. the ideal 'm + n' components.
Why?
Overall, SPARQL allows efficient expression of graph-data needs. However, specifically for Unions, this efficiency is lost when we have to write a Cartesian product of Union components.
For example, I have a use case for a customer where 'm=6' and 'n=18', resulting in 108 (!) union components. Due to the high degree of repetition in these 108 Union components, it is practically impossible for me to write this query in SPARQL (without immediately violating regular deduplication checks employed by IT production systems).
Previous work
The only known workaround is to write the query in some other language (not SPARQL) that allows efficient 'm + n' specification, and generate a SPARQL query that contains the Cartesian 'm * n' product by automated means (some kind of permutation algorithm).
Proposed solution
A new keyword, e.g. 'Alt', that only allows alternative matching patterns to be specified, and that does not (also) change the execution order (inside-out behavior).
select * { { A1 } alt { ... } alt { Am } { B1 } alt { ... } alt { Bn } }Considerations for backward compatibility
This feature request is fully backwards compatible, because the Union keyword remains available in the SPARQL language with its current meaning.
Users who want to specify alternatives and also nest scope at the same time can continue to use Union. Users who only want to express alternatives can start to use Alt.