search

votinginfoproject / vip-specification

The Voting Information Project XML specification.
http://vip-specification.readthedocs.io/en/release/
Other
75 stars 30 forks source link

Expand use of `Label` to all objects to support data lineage #385

Closed afsmythe closed 4 years ago

afsmythe commented 5 years ago

It is noted in the documentation that the optional Label attribute may be used on some objects to allow the VIP record to refer back to the source information.

ContactInformation has an optional attribute label, which allows the feed to refer back to the original label for the information (e.g. if the contact information came from a CSV, label may refer to a row ID).

Is there any merit to expanding this optional attribute to the other classes? There are a couple of ongoing projects in VIP to support conversions of NIST 1500-100 (pre election files) and VIP 3.0 feeds in to VIP 5.x versions and having the ability to use Label to link the VIP feed to the source (either NIST feed or 3.0) sounds like a good win, especially when those source feeds don't have their ID's conforming to Hungarian notation.

If there is another method of describing data lineage in the VIP feed than I'd like to hear any and all options. Thanks!

jdmgoogle commented 5 years ago

I see Hungarian notation as a nice-to-have but it doesn't have to be a hard requirement. If a state/provider would like to use a source feed (e.g., v3.0) identifier as an XML object ID, I think that's fine. The conversion tool could even prepend something to the identifier to indicate that it was something that came from a difference source feed (E.g., "v30_" to create object IDs like "v30_charlottesville_va").