Re: [EM] Ballot Data Format
After creating two native formats for a Vote Counting program (both
designed to be the minimum that could implement the ballots I needed at
the moment, not suitable as a standard), what I would propose is an
expressive format that can be implemented identically in either JSON or
YAML.
A record would need two top level keys HEADER and BALLOTS.
The HEADER would contain fields used to describe the election. These
might include an alphanumeric identifier for the ballot set itself, keys
for date and location of the election, division (if a partial) and a
candidate key that would allow assigning a short identifier to each
choice. If a Choice is "Maine Blueberry Sorbet, Maggie's Ice Cream and
Confectionery, Collinsport, Maine, USA" or
"抹茶アイスクリーム、京都ナンバーワンアイスクリーム、京都、日本" a shorter
Numeric or ASCII Alpha-Numeric identifier is desirable for the BALLOTS
section, the long field could default to the short one when the long was
omitted.
The BALLOTS section would have several different structures defined.
regular RCV ballots are easily represented with a simple array, Range
Ballots need to be key value pairs, RCV ballots allowing equal
preferences are different, etc. The ballot format would be indicated in
the HEADER. This would also help future proof the format, permitting
revision to add new ballot structures if they are ever needed.
If anyone on this list has experience with the procedures of bodies
(like ietf) that set standards is willing to volunteer to help organize
a working group, I would be eager to participate.
ABIF is a good acronym / short name for such a standard.
----------------------------------------------------------------------
Date: Sun, 6 Jun 2021 13:29:46 +0200
From: Jan ?imbera <simbera.jan@gmail.com>
Subject: Re: [EM] Ballot Data Format
Hi Rob and all,
I like the simultaneous readability, versatility and robustness of ABIF.
If the multiplier separator is made variant (asterisk / colon / both),
I think the only difference between Pivot and ABIF would be the
significance of whitespace in candidate tokens, something that the
parser could also be liberal in accepting - I see the [] bracketed form
as more readable (and thus default) but no problem in making
the non-bracketed form acceptable.
Also, if leaving out the scores for the unordered variant is allowed,
the format will be able to record approval votes in a very readable
form, which I would support.
If the community eventually arrives at some sort of consensus,
I'll put the ABIF read/write implementation into the backlog of
votelib (which can already read BLT and STV formats) so that
it has an interchange format for ordinal ballots as well.
The implementation would benefit from a formal parsing definition
(BNF or similar); if not, I might create it in the process.
All the best,
Jan