Unique identifiers for each election

[Tim-Adams-LGA]

One of the areas we have been considering in the proposed elections data open standard here: http://e-sd.org/vgTJ3 is a property that is included to uniquely define each election. We would have preferred to use the uri (uniform resource identifier) approach but currently there is no organisation at the centre that uniquely identifiers every type of election. These can be obvious ones like a general Election for the Parliamentary Constituency of Bradford East or more granular such as a council by-election for the ward of North Cosford in Babergh District Council.

Electoral Commission currently does not provide this service. I have approached them to seek their views and also those from the Association of Electoral Administrators.

Civic Society group, Democracy Club, has made the following suggestion. What do readers think? I worry about the use of free text names in the hierarchy. we probably need to enforce the use of official area short names.

Democracy Club suggested this. We've designed a process that means no individual organisation issues the IDs but we do need structure and hierarchy and persistence. At a high level, the creator of "the thing" should be the person or organisation that makes "the thing".

This means that anyone should be able to work out the ID of any election in future or historically. Of course it's not perfect and it needs more testing, but that's the idea.

Of course the other option is for each authority to issue a numerical ID for each election, but I think using a date to form the ID is really useful, and it's a good example of data in an ID that's both machine and human understandable.

We've been working with people in Parliament on this, and we wrote a blog post with more explanation here:

https://democracyclub.org.uk/blog/2017/01/20/making-every-election/

You can also create your own IDs for elections at https://elections.democracyclub.org.uk/

[MikeThacker1]

I believe this is the democracy club election identifier reference and this is the LGA elections schema page with a link to draft guidance.

The LGA draft schema relies on individual fields, which, when combined, uniquely define an election. I can see a single field giving an election identifier as being extremely useful and Demo Club are the most experienced at referencing elections. Such a field probably shouldn't rely on a central organisation having created the identifier in advance.

With the four part election id of which the middle two parts are optional, it is not immediately obvious which part is which, but can be worked out I think.

The parts are:

• election type - for which the LGA schema uses an encoded list
• election sub-type - presumably an extension of the encoded list
• area - for which the LGA schema uses a URI from statistics.data.gov.uk
• date in ISO format

My initial thoughts are that it would be good to follow the DemoClub proposal but try hard to remove any ambiguity in the election type and area parts.

Election type could become a controlled list (a URI set) with a property for the short code to be used in the election id. Alternatively an encoded list with mechanism for frequent update is needed.

Area can be a slugified version of the ONS official name (or the Natural neighbourhoods area label when a pre-operative area has yet to be published by ONS). So, to use a DemoClub example, the area whose URI is http://statistics.data.gov.uk/id/statistical-geography/E14000871 has an area part of the election id of "oldham-west-and-royton".

[Tim-Adams-LGA]

Well the current version of the proposed schema already has each of the separate fields to which you all refer. Cannot the unique election ID be drawn from combining these together in the way suggested?

The four fields are:

• Election Date
• Type of Election - I suggest at this stage we do not need a controlled list/URIs as the standard defines supported election types as a list already
• Election Body (in URI or label form)
• Election Area (in TRI or label form)

Does this resolve this issue and should we introduce another field for unique election ID which is based on a hierarchical combination of the above four fields?

We are keen to keep these fields also separate so that (when aggregated nationally) we can filter by election type, or date or electoral areas......

Tim

[MikeThacker1]

A purist would say that those fields individually form a "composite key". So an extra single field identifier is simply for convenience in easily linking records (via just one field) to an election.

It's a question of weighing the extra effort needed by publishers versus the convenience to data consumers. If the publishers are Election Management System (EMS) vendors, the id should not present them too much trouble.

It would be useful for others to comment.

[Tim-Adams-LGA]

I have been in conversation with senior members of the UK Association of Electoral Administrators (AEA). These people are the returning officers and electoral administrative officers in local authorities that run elections, maintain records, conform to legislation and publish data. They are critical to the success of implementing any UK-based open data standard for elections data - candidates (in advance of elections) and results (after elections).

We have been discussing the interest/new requirement to uniquely identify and record each election within the proposed open published data to come. Peter Stanyon is the Deputy Chief Executive of AEA and a key spokesman/adviser for members of this organisation. See http://www.aea-elections.co.uk/

He has been considering the proposal for uniquely identifying elections along the lines discussed above. He is not a GitHub user and asked me to post his views which he sent to me by email yesterday. I post them verbatim below. ........... My apologies for not responding sooner but I’ve been struggling to get my head around what all this means! I’ve re-read the DC blog and I think I get it, but in many ways, the issues identified will not go away so there needs to be some acceptance that whatever solution evolves will not be 100% accurate … just an awful lot better than before!

It makes sense to me to have reporting functions built into the EMS systems using standard parameters that are already there, something like:

Election date Election area Election type Election constituency

So, for example, 04052017 – ENFIELD – DISTRICT – BOWES Or, 04052017 – HAMPSHIRE – PCC – EASTHANTS

I am probably oversimplifying things but at the same time, if it becomes too complicated, and you permit free form text, then confusion may reign.

[symroe]

Here are the latest docs:

https://elections.democracyclub.org.uk/reference_definition

We also also an (alpha) python package for creating the IDs:

https://github.com/DemocracyClub/uk-election-ids