Human-readable identifiers in NIST documents

[ion-oset]

Ideally element identifiers ¹ in documents from the NIST SP-1500 election standards should follow some clear rules for being generated. Those identifiers should be human-readable and ideally human-comprehensible allowing a reader to recognize the class and properties of the element being defined. Having formal rules (ideally but not necessarily with an algorithm) allows automatic generation. Human-comprehensibility makes it much easier to avoid mistakes and debug problems when composing and using documents.

To do this generally we need a well defined scheme for generating the names that's independent of any particular generator. There are a couple of proposals for rules doing human-readable IDs. None of them are complete in the sense of a reproducible algorithm that can be encoded in whatever library or tool is needed with consistent results.

This discussion is to help gather proposals for those schemes and to elaborate on what constraints are needed to define them.

Footnotes

1. Note: "Identifiers" refers to what the standards call ObjectIds (@ids in the JSON Schema). They should not be confused with ExternalIdentifiers, which are defined by jurisdictions (see NIST SP 1500-100r2, section 5.21, page 63), and other external standards (ibid, section 5.59, p. 107). ↩

[ion-oset]

Known naming schemes

Some proposed naming schemes in various levels of complexity and completeness, Please feel free to add suggestions in the replies.

• VIP scheme

  The Voting Information Project proposes a set of standard short/Hungarian style prefixes.

  • The list of prefixes doesn't all possible elements: the VIP schema is a subset of NIST SP 1500-100 (Election Results Reporting).
  • The elements in the VIP schema have no equivalents for other NIST voting standards like NIST SP 1500-103 (Cast Vote Records)
  • There isn't any real structure defined past the element type.

• TTV scheme (draft)

  The Trust the Vote EDF (draft) Profile proposes longer more detailed IDs.

  • The prefixes match the full element name.
  • Each element attaches further identifiers identifying key properties. For example Person elements include the person's official name. These are not yet described for all elements, though numerous examples are in the draft.
  • Some of this process could apply to CVRs and other NIST standards.

[ion-oset]

Other schemes that have been mentioned but that don't have any written proposal (that I know about):

• The NIST standards constrain the syntax of identifiers in terms of legal characters (NIST SP 1500-100r2, section 6.1.2, p. 116) but don't place any additional constraints. Most of the examples are human-readable, but not all of them.

  Type xsd:ID requires that ObjectId be a unique legal XML value that does not contain a colon, and digits, the hyphen, and the period may not be used as the starting character.

• @trustthevote & @cwulfman have discussed the following:

  [We] had a schema for this a while back, where there was a human readable and usually but not guaranteed to be unique [ID] with an EDF, appended with an ordinal to be unique.

  As I recall contests were like contest-mayor, candidates were like candidate-spacely-contest-mayor and candidate-writein-1-contest-spaceport-board; and question-helium-initiative etc. The ballot section IDs would be directly derived from them like selection-candidate-spacely-contest-mayor and selection-question-helium-initiative-yes

• I have a similar, but not explicit rubric for @ids in the Jetsons EDF and CVR samples.