On Thu, Oct 27, 2011 at 10:11:42AM +0100, John Borras wrote:
> Neal
>
> Just seen your comment in the ballot and noted that you made the same point in
> the NIST workshop. The answer to your concern is that in v7 we have
> consolidated the ballot status; before we had two indicators which lacked
> clarity. See the following extract from the Specification document.
Ahh - that is helpful. Sorry for the confusion. I had taken it, based on the brief conversation at the NIST workshop, that there just wasn't a standard way to represent them. But it still seems a bit murky.
> Undervotes and Overvotes would now be recorded as ReasonCodes.
It seems that we would want to list undervotes as "Abstentions" (which don't take a ReasonCode) not as e.g. "UncountedVotes" (which do take a ReasonCode).
E.g. for a RejectedVote I wonder how implementations will interoperate with respect to what ReasonCode to use given that it is "Required" but I see no enumeration of the possible codes. They would seem to include "overvote" and "rejected-provisional" (for UncountedVotes - see below).
What would help the most is an canonical example for a typical US election, e.g. a "vote-for-one" contest in which a 50% majority is required to avoid a runoff, so it is important to properly categorize undervotes and overvotes and calculate the total. I'd assume that some central-count paper ballots are used so overvotes are a possibility.
We could start from the example I was asking about last year, which has some questions listed in the comments:
http://bcn.boulder.co.us/~neal/electionaudits/eml510-example.xml
> ?Each contest indicates its identifier, and optionally the counting system and
> the maximum number of votes that each voter could cast. The key information is
> that about the votes cast for each of the choices available and the numbers of
> abstentions and rejected and uncounted votes. If a vote is rejected, for
> example, because a voter has chosen to spoil a ballot paper, many authorities
> will want to count that vote as having been cast. The UncountedVotes element is
> reserved for those cases where that record is not required, for example when
> the result is thought to be fraudulent. Both the UncountedVotes and
> RejectedVotes elements have Reason (optional) and ReasonCode (mandatory)
> attributes to indicate why the votes were treated as they have been. The former
> is a textual description, and the latter a code.?
I don't understand this part:
"The UncountedVotes element is reserved for those cases where that record is not required, for example when the result is thought to be fraudulent"
Does "record" refer to the ballot? And is "result" the result of the election, or the interpretation of that ballot?
And re: the other options at that level: Cast, Read, TotalCounted, Provisionals, I note
the comment there that says "added counters for cast, read, provisional and totalcounted - (need per NIST)".
I guess those should be interpreted per the VVSG, e.g. from November 2007:
http://vote.nist.gov/VVSG-0807/appendixa.htm#glossreadballot
During the discussion in P1622 on auditing and election night reporting we'll want to flesh out some more specific guidelines for their use. I note this one:
counted ballot: "Read ballot whose votes are included in the vote totals. Discussion: A provisional or challenged ballot that is not accepted may be read, but it is not counted."
That probably mostly applies to DREs. With scanners, in my experience, provisionals are assessed BEFORE being put into a tabulator. Otherwise it is typically very hard to cause them to not actually be counted. So it would be more likely that the number of "Read" would be less than the number "Cast" due to "Provisionals" that are not accepted, and e.g. mail-in ballots that don't have acceptable signatures on the envelopes.
I'd think UncountedVotes would be useful for reporting provisional ballots that are read but aren't accepted. In some cases (e.g. if they can be cast on DREs while being marked as provisional) provisional cast votes are read, but in others (e.g. scanners) they aren't. And when possible it would indeed be good to know how many votes on a particular contest are known to be uncounted, e.g. if an audit of the provisional acceptance status might make a difference in a close election.
Would UncountedVotes be included in the denominator for a 50% majority calculation? I guess not. I realize that some of this will vary by jurisdiction, but I'm looking for how they have been used in other elections, or what the intended usage is.
I also just noted another helpful interpretation from NIST in David Flater's paper "A VVSG-derived model of election data":
http://www.nist.gov/itl/vote/upload/flater.pdf
In section 5.6 he notes that undervotes and overvotes are considered "Counted", and that
"the Overvotes and Undervotes values are defined in the VVSG as reporting the number of votes, as opposed to simply the number of Ballots that exhibited the relevant voting behavior, as is sometimes done."
So a "vote for 3" contest with a single ballot with a vote for just one option would result in a report of two undervotes.
> Hope this helps and mitigates your concern?
I think this at least provides a framework that we can build on in P1622 to get to an interoperable spec without it being too ugly. But I think more specificity and clarity on the terms is important for EML also.
Thanks,
Neal McBurnett
http://neal.mcburnett.org/
> Regards
>
> John Borras
>
> Chair OASIS E&VS Technical Committee
>
> m. +(0)44 7976 157745
> Skype: gov3john