No Way to relate an ExternalIdentifier with an Election Authority

[carl3]

Organization Name: Carl Hage

Organization Type: 4

Document: SP1500-100 ElectionResultsReporting

Reference: 4.3.10 IdentifierType Enumeration

Comment: The ExternalIdentifiers.Type doesn't meet the requirements to define the ID system. In particular, IDs are assigned by an EA and need to be preserved and represented in export files. For a district that crosses the EA jurisdiction, e.g. a school district crossing county lines, the result file might have reported totals and IDs for multiple EAs that report results independently in separate files (and have election definitions in separate files).

The IDs in official filings by an EA need to be related to IDs in SP1500 files, and tied to that EA.

The enumerated type doesn't fit the existing IDs commonly in use, e.g. codes under authority of NIST. Census files use ANSI, FIPS, GNIS, CE (Census-Assigned), and state submitted codes, "Local Education Agency". For Voting districts (precincts), the Census-assigned IDs don't always match the state or EA assigned IDs. There are different code systems within FIPS. For example fips-place is different than fips-school (IDs from nces.ed.gov), and specific codes are assigned to legislative districts (which sometimes have names not numbers). The coding system shouldn't need to be derived from context.

A given Election Admin might have more than one EMS. It is possible, for example, a DFM-EMS has different contest IDs than a GEMS balloting and ballot counting system. The IDs are specific to a kind of object, e.g. precinct ID is different than district ID. Thus "local-level" does not indicate which EA is using the system, and doesn't indicate which EMS or object-specific system is used.

A note in the Federal Register: "As of January 1, 2006 the GNIS ID and its associated fixed-length representation will become the official standard code."

Suggested Change: Option 1:

• Add a GpUnitRef attribute (or element) to relate the ID system to a particular GpUnit and it's Election Admin element, if present, or instead a EAref attribute with the ID of an Election Admin. The OtherType field could indicate a domain, e.g. EMS and/or object type (field name for the ID).

• Extend the IdentifierType enumeration to include the IDs officially used by the US government, indicate which coding domain is referenced (not just the agency).

Suggested expanded IdentifierType codes: "incits446-2008" (GNIS), "fips55-3" (place codes), "nces" (Defined by nces.ed.gov, used in census files as a "local education agency code"), "ansi-aia, ansi-cou, ansi-place, ansi-schdist (Mostly, same as nces), ansi-vtd [See https://www.census.gov/geo/reference/ansi.html for distinct coding systems], census-place, census-sldl, census-sldu (codes assigned by Census).

Option 2: (preferred) Make <ExternalIdentifier> be a simple, repeatable string type, with one required attribute, "identifierType", an IDREF to a new <IdentifierType> element. The <IdentifierType> could have several fields to define a coding system, e.g. Name (descriptive name), URI (reference to the coding system home page or controlling organization, e.g. an Election Admin web site), Domain (a string ID or name representing one of several coding systems, e.g. a field name representing an object type. IDs are unique within a coding domain), GpUnitId (an IDREF of a GpUnit and election admin). A code type (us-level, state-level, local-level, standards-org, org) indicating what kind of organization, e.g. to relate state-specific educational codes.

Rather than providing a collection of external organization coding definitions with every external ID and instead of free-form otherType strings that are specific to a locality or software application (not machine readable), a simple IDREF in an attribute can tag an ID. Only one element is required to create and define the code type, with a more specific reference (full name, and URI), plus a reference to the county, locality, etc. the coding applies (managed by the EA of the locality.

[jdmgoogle]

Add a GpUnitRef attribute (or element) to relate the ID system to a particular GpUnit and it's Election Admin element, if present, or instead a EAref attribute with the ID of an Election Admin. The OtherType field could indicate a domain, e.g. EMS and/or object type (field name for the ID).

This assumes a certain use case of ExternalIdentifiers which, in our experience, rarely is true. Even for simple cases this could be impractical. For example, here are some sample pieces of information we've received using the ExternalIdentifiers fields:

• OCD-IDs;
• The PersonId of the leader of a political party;
• Secondary abbreviations for a political party as used by the data provider;
• The list of counties (outside of the provider of the current report) which also include this contest.

These have all been valuable uses and side-channels for information which cannot fit into the current spec, but will not fit easily into the system as you describe it.

Also, if the goal is to enable cross-referencing between data files coming from multiple data providers (e.g., multiple counties in the same state) there's absolutely nothing that (a) assures all counties even have access to the same data within their EMS, or (b) will structure the data in the same format. For example, some counties code their cities as "municipalities" and others as "cities"; this means when attempting to aggregate data across multiple counties it was difficult for us to get a clear definition the set of ReportingUnit objects which were cities, and this was for data within a single state.

In my opinion this proposal adds complexity for a false sense of improved uniformity.