Election Standards – Part Two

Last time I reported on the first segment of the annual meeting of the Voting Systems Standards Group (VSSC) of the IEEE. Most of that segment was about the soon-to-be-standard for election definition and election results (called VSSC.2). I recapped some of the benefits of data standards, using that as an example.  Much of the rest of day one was related to that standard in a number of ways. First, we got an update on the handful of major comments submitted during the earlier review periods, and provided input on how to resolve these finalize the standard document. Second, we reviewed suggestions for other standards that might be good follow-on efforts.

What’s in a Name?

One example of the comments concerned the issue that I mentioned previously (concerning aggregation), that the object identifiers in one VSSC.2 dataset might have no resemblance to identifiers in another dataset, even though the two datasets were referring to some of the same real-world items described by the objects. We discussed a couple existing object naming standards for election data, FIPS and OCD-IDs. FIPs is a federal standard for numeric identification for states, counties, townships, municipalities, and related minor civil divisions (as well as many other things not related to elections).

That’s useful because those types of real-world entities are important objects in election definitions, and it’s very handy to have standard identifiers for them. However, FIPS is not so useful because there loads of other kinds of real-world entities that are electoral districts, but not covered by FIPS. In fact, there are so many of them and in such variety, that no one really knows all of the types districts in use in the U.S. So we really don’t have a finished standard naming scheme for U.S. electoral districts. We also discussed the work of the Open Civic Data project, specifically their identifier scheme and repository, abbreviated as OCD-IDs.

More on that in the report from Day 2, but to make a long story short, the consensus was that the VSSC.2 standard was just fine without a unique ID scheme, and that a new standard specifically for standardized IDs was not a large need now.

Supporting Audits

That’s one possible new standard, related to the .2 standard, that we considered and deferred. Two others got the thumbs up, at least at the level of agreement to form a study group, which is the first step. One case was pretty limited: a standard for cast-vote records (CVRs) to support ballot audits with an interoperable data standard. To only slightly simplify, one common definition of a CVR is a record of exactly what a ballot-counting device recorded from a specific ballot, the votes of which are included in a vote tally created by the device. Particularly helpful is the inclusion of a recorded image of the ballot. With that, a person who is part of a typical ballot audit can go though a batch of ballots (typically all from the same precinct) and decide whether their human judgment agrees with the machine’s interpretation, based on the human’s understanding of relevant state election law.

Support for audits with CVRs is a fundamental requirement for voting systems, so this standard is pretty important. It’s scope is limited enough that I hope we can get it done relatively quickly.

More to Come

The other study group will be looking at the rather large issue of standardizing an election definition, beyond the level of the .2 standard. That standard is very useful for a number of purposes (including election result reporting) but intentionally limited to not try to be a comprehensive standard. The study group will be looking at some use cases that might guide the definition of a smaller scope, that could be a timely a right-sized step from .2 toward a truly comprehensive standard. My personal goal, which I think many share, is to look at the question of what else, besides what we already have in .2, is needed for an election definition that could support ballot layout at least at the level of sample ballots. I like that of course, because we already documented the TrustTheVote requirements for that when we developed the sample-ballot feature of the Voter Services Portal.

Onward to day 2!

— EJS

PS: For more on the Voter Services Portal …  production version of VSP in Virginia is at https://www.vote.virginia.gov and the demo version is described at PCEA’s web site http://www.supportthevoter.gov and http://web.mit.edu/vtp/ovr3.html with an interactive version at http://va-demo.voterportal.trustthevote.org