[EM] Ballot Data Format

[John Karr]

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20210606/ee18a283/attachment.html>