Linking Precinct object to BallotStyle

[Josh-LACRRCC]

Since the restructuring of the schema to better follow 1622.2, I no longer see a method of connecting a Precinct to a BallotStyle.

The Precinct's "BallotStyleImageUrl" function appears be taken care of by the BallotStyle's "InfoUrl".
The "BallotStyleImageUrl" element could then be replaced by

<xs:element name="BallotStyleID" type="xs:IDREF" minOccurs="1" maxOccurs="1" />

or be added following if the image url needs to remain in that location.

Other ideas?

[jungshadow]

@Josh-LACRRCC Did this question get answered yesterday at the spec clean-up session? I want to make sure this didn't fall through the cracks. /cc @pstenbjorn @jdmgoogle

[Josh-LACRRCC]

@jungshadow Yes. Revisit after further 1622.2 integration.

[jdmgoogle]

I sat down and discussed this with @jktomer, and here's the situation: right now we (Google) figure out the ballot contests by (a) getting the list of electoral districts associated with a precinct from the Precinct object, (b) getting the list of contests associated with an electoral district from the Contest object, and (c) doing a join on those two lists. These linkages are all still present in the most recent draft of VIP 5. However there are also BallotStyle objects in the VIP 5 spec, but currently they are not referenced by anything. There are four options we considered:

1. Leaving this as-is;
2. Removing the BallotStyle (and OrderedContest) objects, and continuing to get the ballot contents by joining on ElectoralDistrict (the current method);
3. Keep ElectoralDistrict in Precinct, and add a reference to a BallotStyleId to Precinct as well; or
4. Remove ElectoralDistrict from Precinct, and add BallotStyleId to Precinct.

We shot down (1) as being pointless since BallotStyle and OrderedContest would be of no use and just take up space in the feed.

We would prefer to not remove ElectoralDistrict from Precincts, since this information is useful in many ways and improves the search experience (this removes option (4)).

We suspect that removing BallotStyle and OrderedContest from the schema would be less-than-desirable since it's a superior and more direct way to indicate ballot layout than our join-through-ElectoralDistrict heuristic (this removes option (2)).

Now we're left with option 3) Keep ElectoralDistrict in Precinct and add a BallotStyleId field. If such a field is present then we'd use the referenced BallotStyle, but if it isn't then we can fall back on our joining heuristic.

Comments?

[pstenbjorn]

@jdmgoogle let me see if I can trace the chain of data in your suggestion 3

[data entry - valid address] -> StreetSegment-> PrecinctId ->
Precinct->
[ElectoralDistrict ->Contest(s)->BallotSelection/CandidateSelection]
OR
Precinct->
[BallotStyle->OrderedContest->Contest(s)->BallotSelection/CandidateSelection]

If this is what you are proposing, I think it provides reasonable options and enough reverse compatibility with existing csv structures.

[Josh-LACRRCC]

@pstenbjorn, that is how I envision it chaining as well.

Option 3 offers the least amount of design changes, with existing compatibility, while providing the increased ability to support "candidate rotation" between Precincts.
Two Precincts may contain the same collection of Contests (through the ElectoralDistrict linkage), and an optional BallotStyle allows the Candidates to be defined in different orders.

[cjerdonek]

Option (3) strikes me as the right choice.

[jdmgoogle]

@pstenbjorn and @Josh-LACRRCC
Yes, that's correct. The proposed model using ballot styles is:

Address
~> Street segment
~> Precinct
~> BallotStyle
~> OrderedContests

but if there is no BallotStyleId present in the Precinct object, we'll fall back on the current model, which is

(Preprocessing)
Build a multimap of
ElectoralDistrict ~> Contest
using the Contest.ElectoralDistrictId field

(Serving)
Address
~> Street segment
~> Precinct
~> Set of ElectoralDistrictIds
~> Set of contests resulting from lookups in the ElectoralDistrict ~> Contest multimap

I'll put together the PR for the schema change.

[afsmythe]

Reopening this based on conversations with Louisiana during the 5.2 discussion on April 16.

[jdmgoogle]

Acknowledged. I'd still like to better understand the hurdles to regular 5.x implementation.