Turn the input to Group(..) and to Aggregation(..) into solution sequences

[hartig]

... as suggested by @kasei in #95 (comment)

---

Preview | Diff

[hartig]

Currently, this change uses Option 1 of #95 (comment) to convert the input to the Group operator from a multiset of solution mappings into a sequence of solution mappings.

Following this change, this PR changes the definitions of both the Group operator and the Aggregation operator.

In particular, the definition of the Group operator now captures explicitly that the operator produces partial functions from keys to solution sequences.

Similarly, the definition of the Aggregation operator now captures that:

1. such partial functions from keys to solution sequences are the input to this operator,
2. the operator internally produces lists of tuples rather than sets of tuples (see, in particular, the change to the function M),
3. the given "set function" is invoked with such a list of tuples rather than with a set of tuples.

Additionally, I have adapted the example below the definition of the Aggregation operator according to these changes.

However, that's only a part of the changes that are needed to implement @kasei 's proposal. The next step is to adapt the definitions of the set functions. For instance, in Section 18.5.1.1 Set Functions, the symbol M must now denote a lists of lists rather than a multiset of lists, and the same holds for M in Section 18.5.1.2 Count and also in the next sections. As another consequence, the definition of the Flatten function (as used in Section 18.5.1.2 Count) needs to be changed as well.

@kasei any comments so far?

[kasei]

Other than the comment about needing to define Distinct(sequence), I think this looks good.

[hartig]

I now have changed the definitions of the set functions such that they are defined over sequences of lists, rather than over multisets of lists.

With this change, the PR is ready to be reviewed.

[TallTed]

(tangent... could be moved to a new issue)

I'm probably in the minority, and it certainly would require a chunk of work by editors and other contributors, but I find myself wishing that a lot more content were <code> (or `) tagged, especially all the logical expressions. I find such text a good deal more comprehensible with such typographical adjustments, than with most everything being in the main "body" typeface. I'll cheerfully do a lot if not all of the necessary tag additions, if others are OK with it happening.

[gkellogg]

(tangent... could be moved to a new issue)

I'm probably in the minority, and it certainly would require a chunk of work by editors and other contributors, but I find myself wishing that a lot more content were <code> (or `) tagged, especially all the logical expressions. I find such text a good deal more comprehensible with such typographical adjustments, than with most everything being in the main "body" typeface. I'll cheerfully do a lot if not all of the necessary tag additions, if others are OK with it happening.

var (or synonym |) is also useful markup for things like μ in Ψ

[hartig]

I have created two issues related to the two markup suggestions, see #101 and #102.

[hartig]

I have pushed a new commit to this PR (see d808fb8). This commit addresses Andy's concerns about my changes to the definition of Distinct by implementing his suggestion to separate the definitions; that is, with this new commit, the definition of Distinct is now back to how it always was and there is a new function called Dedup that is used in the definition of the Aggregation operator. Additionally, this commit addresses the following comments:

Comment by @kasei

This wording seems confusing to me. If there are duplicated elements in Ψ, I would not think of the distinct sequence as "containing every element in Ψ" (since some of them will be omitted because they are duplicates).

Addressed by changing "Every element" to "Every unique element" as suggested by @TallTed .

Comment by @afs

s/≠/is not the same term as/

I kept the ≠ in the condition for the indexes i and j but integrated "is not the same term as" into the text of the corresponding bullet point.

Comment by @afs

s/every/any/ because the text names the chosen as e1 and e2.

Done.

[Tpt]

Thank you! I allowed myself some questions I had while reviewing this MR but they are not directly related with it.

[hartig]

@afs @rubensworks are you still planning to review this PR?
Otherwise, I would merge it so that we can make progress on a number of related issues (#94 #99 #105 #106 #107, and eventually also #101 #102 #103).

[afs]

Yes, I am hoping to review it.

Sorry for the delay.

Reviewing changes in RDF docs has also taken up time.

[hartig]

No worries. Take your time! I just wanted to quickly check.

[rubensworks]

Apologies for the delay, I lost track of this one.

[afs]

This makes sense to me. Solution sequences are easier to think about.