Comment/Wish 5: Communicating aggregated cast votes in Contests where multiple Candidates are ranked

[David-Rosenberg@earthlink.net]

Comment/Wish 5: Provide a straightforward way to communicate partially
aggregated cast votes in Contests where multiple Candidates are ranked
on a single voter's 440-castvote in a single Contest

[NOTE: The kind of aggregation for rankings (proposed in this comment)
is different from the kind of aggregation for ratings and assignment
of points (proposed in a following comment).]

There are Contests where the "Value" attribute of the selection
element is used to rank multiple Candidates in a single Contest on a
single voter's 440-castvote. I envision these 440s being partially
aggregated at one jurisdictional level and those partially aggregated
ballots being communicated up to the next higher jurisdictional level
- where the election might be counted or where the partially
aggregated ballots from multiple lower jurisdictional levels might be
further aggregated and communicated up to a still higher
jurisdictional level.

For example, in a race with five candidates, there are 326 ways those
candidates could be ranked (including not ranking any of them, ranking
just one candidate, up through ranking all five candidates). In a
jurisdiction with 10,000 voters, all 10,000 individual ballots could
be communicating. However, it would be more efficient to only
communicate each of the 326 ranking orders that was actually used on
at least one cast ballot, along with the number of ballots that were
cast with that ranking order. That is, instead of communicating 10,000
individual ballots, we would communicate a maximum of 326 aggregated
ballots such that the sum of the occurrence counts is 10,000. I would
like a straightforward way to communicate partially aggregated cast
ballots for these voting methods.

There are probably many ways that EML could be extended to support
this. The 460-votes is described as "This schema is used to define a
message comprising a set of votes being transferred for counting." So
extending the 460-votes seems the approach most in line with what
seems to be the spirit of EML. I'll describe that approach. (There
might be better ways that are already available in EML V6, that I've
failed to see.)

The partial aggregation is just conveying the cast ballots in a
somewhat condensed fashion (without identifying the voters). If we
have 1,000 ballots and we noticed 350 of the ballots ranked the
candidates in order A, 320 of the ballots ranked the candidates in
order B, 329 of the ballots ranked the candidates in order C, and one
ballot ranked the candidates in order D, we could send each of the
1,000 ballots separately or we could send one ballot A with an
instruction to repeat it 350 times, one ballot B with an instruction
to repeat it 320 times, one ballot C with an instruction to repeat it
329 times, and one ballot D. The recipient is getting the same
information in either case. If we sent the four unique ballots and the
recipient wants all 1,000 ballots, he can manufacture them by just
making the additional copies according to the instructions. The result
is going to be like multiple 440 documents, so the easiest way to
communicate them might be to use the 460 document with a multiplier
associated with the Contest element, to show how many voters cast the
set of rankings shown by the Selections in that Contest.

The minimum required change would be to have an optional integer count
attribute (possible named "Occurrences") associated with the 460
document "Contest" element

In this case, if 10,000 voters ranked the candidates in 300 different
ways, the 460 Votes element would only have to contain 300 Election
elements (one for each ranking order) with the "Occurrences" count
attribute indicating how many voters used each of those ranking
orders. The Selection element contains one Candidate and his ranking.
The Contest element can contain multiple Selections - hence multiple
Candidates and the Ranking for each. The Occurrences attribute (that
I'm proposing be an optional attribute of the Contest element) would
indicate the number of voters who had chosen this set of rankings of
the candidates.

Doing as described above we would be using multiple Election elements
to represent the different ranking orders in what is in reality a
single contest, but in this XML is multiple Contest elements. This
seems both forced and misleading. A further refinement would be to
introduce an intermediate level element between a Contest and a
Selection. Let me call this intermediate level element a
SetOfRankedSelections. The "Occurrences" attribute would be associated
with the SetOfRankedSelections element, rather than with the Contest
element. As before, a single Selection element describes a Candidate
and the Value attribute gives the rank for that Candidate. Multiple
Selections (each describing a Candidate and his rank) are part of the
new SetOfRankedSelections element. The optional Occurrences attribute
indicates how many voters selected that set of rankings. The multiple
SetOfRankedSelections elements within a Contest expresses each set of
rankings that voters used and how many voters used each one.

This seems (to me) to make the XML more descriptive of the actual
data, rather than warping things to use a schema that doesn't really
fit the data.