You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I can see that using the symbol P in this definition can cause confusion, I don't think there is anything wrong with the current definition per se. Here is why:
Given how any expression of the form Aggregation(exprlist, func, scalarvals, P) is produced by the translation algorithm in Section 18.2.4.1 Grouping and Aggregation, it is guaranteed that P is an expression of the form Group(exprlist, P') where P' is "the algebra translation of the GroupGraphPattern of the query level" (i.e., also an expression). The part that may cause the confusion is that the symbol P here is named G in the translation algorithm in Section 18.2.4.1 Grouping and Aggregation (and our P' is named P in the algorithm).
Then, given such an expression P of the form Group(exprlist, P'), the aforementioned current version of the definition applies the eval function to it, eval(D(G), P). Now, since P is of the form Group(exprlist, P'), the relevant part of the definition of the eval function is given by the Evaluation of Group for which the corresponding Group operator "produc[es] a set of partial functions from keys to solution sequences." Hence, such a set is the result of calling eval(D(G), P) in the aforementioned current version of the definition, and that's exactly what the Aggregation operator expects as its fourth argument.
So, I don't see a need to apply the aforementioned suggested fix.*
Perhaps what should be done instead is to rename the symbol P in the definition, ideally using the same symbol as used by the aforementioned translation algorithm in Section 18.2.4.1 Grouping and Aggregation. What makes this renaming tricky is that, as mentioned above, the translation algorithm uses the symbol G but that is already used for something else here (namely, for the active graph G of the dataset D). Therefore, my proposal is to use the new symbol Grp in both places. That is, in the translation algorithm in Section 18.2.4.1 Grouping and Aggregation, rename G to Grp, and in the current version of the definition of Evaluation of Aggregation, rename P to Grp.
*footnote: In fact, applying the aforementioned suggested fix may be problematic later if we want to fix errata-query-21 in the way as proposed by Andy (which I agree with). That proposal introduces a "dummy key special marker 'group-all'" that "isn’t an exprlist", in which case we cannot always assume P/Grp an expression of the form Group(exprlist, P'); it may then also be of the form Group('group-all', P').
The text was updated successfully, but these errors were encountered:
Sidenote: In addition to the main change suggested addressing for errata-query-11---as discussed in this issue as unnecessary or even problematic---the errata also includes a smaller change suggestion:
In Definition: Aggregation replace "multiset of partial functions" by "set of partial functions".
I am looking at errata-query-11. The suggested fix is that ...
The current version of the definition looks as follows.
While I can see that using the symbol
P
in this definition can cause confusion, I don't think there is anything wrong with the current definition per se. Here is why:Given how any expression of the form
Aggregation(exprlist, func, scalarvals, P)
is produced by the translation algorithm in Section 18.2.4.1 Grouping and Aggregation, it is guaranteed thatP
is an expression of the formGroup(exprlist, P')
whereP'
is "the algebra translation of the GroupGraphPattern of the query level" (i.e., also an expression). The part that may cause the confusion is that the symbolP
here is namedG
in the translation algorithm in Section 18.2.4.1 Grouping and Aggregation (and ourP'
is namedP
in the algorithm).Then, given such an expression
P
of the formGroup(exprlist, P')
, the aforementioned current version of the definition applies theeval
function to it,eval(D(G), P)
. Now, sinceP
is of the formGroup(exprlist, P')
, the relevant part of the definition of theeval
function is given by the Evaluation of Group for which the corresponding Group operator "produc[es] a set of partial functions from keys to solution sequences." Hence, such a set is the result of callingeval(D(G), P)
in the aforementioned current version of the definition, and that's exactly what the Aggregation operator expects as its fourth argument.So, I don't see a need to apply the aforementioned suggested fix.*
Perhaps what should be done instead is to rename the symbol
P
in the definition, ideally using the same symbol as used by the aforementioned translation algorithm in Section 18.2.4.1 Grouping and Aggregation. What makes this renaming tricky is that, as mentioned above, the translation algorithm uses the symbolG
but that is already used for something else here (namely, for the active graphG
of the datasetD
). Therefore, my proposal is to use the new symbolGrp
in both places. That is, in the translation algorithm in Section 18.2.4.1 Grouping and Aggregation, renameG
toGrp
, and in the current version of the definition of Evaluation of Aggregation, renameP
toGrp
.*footnote: In fact, applying the aforementioned suggested fix may be problematic later if we want to fix errata-query-21 in the way as proposed by Andy (which I agree with). That proposal introduces a "dummy key special marker
'group-all'
" that "isn’t an exprlist", in which case we cannot always assumeP
/Grp
an expression of the formGroup(exprlist, P')
; it may then also be of the formGroup('group-all', P')
.The text was updated successfully, but these errors were encountered: