Hybrid PartyContest/CandidateContest systems

[Nicholas Roberts]

So my own country (Australia) allows for voting either for parties ('above the line', preferentially for at least 6 parties) or individually for candidates ('below the line', preferentially for at least 12 candidates) for senate elections.

Situations like this can still be modelled by just creating a PartyContest and linking the candidacies to that (leaving it to documentation to explain how the contest works), however this could lead the consumer to assume the contest was a party-list one. The inclusion of parties in the contest object actually breaks the requirement (whether official or just implied through the style of the other models) of zero-knowledge - to build the contest object, you have to know about the participant parties, rather than embedding that information in a linking object (as with Candidacy, which refers to both the contest and the person).

So shifting the parties list into something like a set of PartyCandidacy (example below) should resolve this problem by requiring the consumer to explicitly seek out any objects with a matching contest_id:

{

    "id": "ocd-candidacy/{{uuid}}",

    "organisation_id": "ocd-organisation/{{uuid}}",

    "contest_id": "ocd-contest/{{uuid}}",

    "is_incumbent": true

}

That still leaves the potential for API consumers to assume you can vote for both parties and candidates simultaneously (a good assumption given the popularity of that kind of system), but resolving that is a separate issue, probably best handled in the Organisation type.

[jamespete...@gmail.com]

Hi Nicholas,

This group isn't actively curated, so you may want to raise your suggestion on GitHub, where it won't be forgotten.

Best,

James