Fix GROUP BY definition when no GROUP BY clause is present

[Tpt]

Currently the "group step" is defined as Let G := Group((1), ToList(P)). This is wrong because the specification states that "in case of implicit grouping the single group must exist and might be empty". Indeed, Group does not associate keys with empty groups leading to no group existing when P is empty.

I believe it might be rewritten as Let G := { (1) -> ToList(P) }, skipping the Group call entirely and always ensuring the existence of a single group.

[afs]

See also

• https://www.w3.org/2013/sparql-errata#errata-query-21
• https://afs.github.io/sparql-agg-group-empty.html#no-group

[hartig]

I agree that this is an issue that needs to be fixed, but I don't think the proposed solution ("skipping the Group call entirely" by rewriting Let G := Group((1), ToList(P)) to Let G := { (1) -> ToList(P) } ) is going to work.

The issue with this proposed solution is that G needs to be an expression that can be evaluated (i.e., the eval function can be applied to it), which is not the case for G := { (1) -> ToList(P) }.

In contrast to this proposed solution, I think the correct way to fix the issue is to i) keep the translation algorithm as is (i.e., in particular, keep Let G := Group((1), ToList(P))) and, then, ii) extend the definition of the Group operator such that it handles this edge case differently.

[Tpt]

The issue with this proposed solution is that G needs to be an expression that can be evaluated (i.e., the eval function can be applied to it), which is not the case for G := { (1) -> ToList(P) }.

That's a good point. My bad. Thank you!

In contrast to this proposed solution, I think the correct way to fix the issue is to i) keep the translation algorithm as is (i.e., in particular, keep Let G := Group((1), ToList(P))) and, then, ii) extend the definition of the Group operator such that it handles this edge case differently.

I am not sure it's a great idea because I believe SELECT (COUNT(*) AS ?c) WHERE { FILTER(false) } and SELECT (COUNT(*) AS ?c) WHERE { FILTER(false) } GROUP BY (1) translation will both contain Group((1), ToList(P)) but must exhibit different behaviors (the first should return 0 and the second nothing).

What about introducing a new algebra operator instead?

[hartig]

In contrast to this proposed solution, I think the correct way to fix the issue is to i) keep the translation algorithm as is (i.e., in particular, keep Let G := Group((1), ToList(P))) and, then, ii) extend the definition of the Group operator such that it handles this edge case differently.

I am not sure it's a great idea because I believe SELECT (COUNT(*) AS ?c) WHERE { FILTER(false) } and SELECT (COUNT(*) AS ?c) WHERE { FILTER(false) } GROUP BY (1) translation will both contain Group((1), ToList(P)) but must exhibit different behaviors (the first should return 0 and the second nothing).

What about introducing a new algebra operator instead?

I don't think that's necessary.

Note that @afs has proposed a fix for errata-query-21 which includes introducing a "dummy key special marker 'group-all'". Once this is implemented, we will have

• Group('group-all', ToList(P)) in the case of SELECT (COUNT(*) AS ?c) WHERE { FILTER(false) } and
• Group((1), ToList(P)) in the case of SELECT (COUNT(*) AS ?c) WHERE { FILTER(false) } GROUP BY (1).

Hence, there will be a clear way to distinguish the special case from the regular cases: all that needs to be done in the definition is to check whether the first argument of the Group operator is the dummy key.