We’ve recently been working with a number of government departments to help them turn their lists into registers.
Back in July we started working with the Department for Communities and Local Government (DCLG) on a local authority register. Having progressed through the backlog and discovery phases on the road to creating a register, we have released the register of local authorities in England.
Getting to alpha is the result of some brilliant collaboration between DCLG and GDS. We can now share the register for feedback and reflect on all of the progress we’ve made so far.
Local authority data is important
Previously we’ve emphasised the importance of registers as the foundations of products and services. Only the other day Councillor Theo Blackwell wrote a blog post about the digital transformation underway at Camden Council, in which he highlights the value of good, clean data to enable local authorities to run public services effectively.
Local authorities are responsible for managing and delivering a range of services to their communities, such as the provision of health, housing and social services, local road maintenance, and running public libraries.
An authoritative list of local authorities underpins all of this. A number of existing services, such as checking your rubbish collection day and paying your council tax, segment data according to local authority or signpost users to the relevant part of their local authority’s website when provided with their address.
We know that service teams and other consumers of registers need to be able to trust the data they contain. It’s vital to the creation process that every potential register is owned and maintained by a custodian. For the local authority England register this was Stephen McAllister at DCLG.
The role of the custodian
It’s essential that custodians have domain expertise and valuable experience of working with the information to be contained in their register. However, a key requirement for custodians is their direct role in the value stream of the data that makes up a particular register as dictated by legislation or integral to their recognised public task. This aligned perfectly to Stephen McAllister’s role at DCLG.
These criteria mean that custodians are best placed to define and shape their registers in 2 important ways: modelling the information in the register based on a realistic understanding of its current state and having the authority to work feedback from users back into the value stream of the register data.
The shape of the data
Firstly, registers should be modelled to capture the information as it exists and is understood in the ‘real world’, rather than seeking to promote a desired end state or conforming to misconceptions.
For example, in his role as custodian, Stephen McAllister recognised that the name used to refer to a local authority in official documents and legislation is not what people call it on a day-to-day basis.
An end user is certainly more likely to refer to ‘Wakefield’ than ‘Wakefield Metropolitan District Council’ so the register contains both a ‘name’ and an ‘official-name’ field which can be used by services to link the colloquial version displayed to users to the name required for official purposes.
Similarly, as with the country register, we included start and end dates for local authorities to allow services to specify the correct information for a particular time period. For example, a service which visualises change over time in the turnout for local elections may need to reference local authorities which have since been merged.
A separate local authority type register was created to allow for systemic changes to local government without the need for a bulk update of the entries for individual local authorities.
Closing the feedback loop
Early on in the process DCLG confirmed that they’re responsible for maintaining the relationship with local authorities in England only. Therefore, rather than attempt to manage a register of information about the local authorities that fall outside of DCLG’s remit, Stephen McAllister need only look to own a register of English local authorities.
Working with a custodian clarified the need for UK local authorities to be categorised into four registers, with Stephen responsible for England and GDS beginning to work with the Welsh Assembly, the Scottish Government and the Northern Ireland Assembly on registers containing information about their respective local authorities.
This means that when feedback comes in on the content of the local authority England register, Stephen can act upon it accordingly because he owns, and can adapt, both the data within the register and the process around the collection and maintenance of that information. So if in months' or years' time there is valuable feedback from users of the register requesting some additional information which falls within DCLG’s remit, as the custodian Stephen can ensure that the relevant process is updated to capture this information in the register.
The GDS registers team support this by ensuring that the registers a custodian owns only contain information they are empowered to collect and maintain. A register shouldn’t contain anything that a custodian can’t ensure the accuracy of, but it can and should link to relevant information from other registers.
Next steps for the register
While we’re obviously celebrating getting the local authority England register into alpha, we’re not going to rest on our laurels. Registers are valuable in themselves as canonical data sources, but it’s only when a register enters beta that teams from inside and outside government can have the confidence to incorporate them into their products and services. These teams can then make full use of the API to use a live feed of the data, so that any updates to the registers are incorporated automatically.
Since the local authority England register is being hosted on the registers platform we know it meets the requirement to conform to the technical spec. That means only two steps remain to getting this particular register into beta. The first is ensuring that it meets the operational standard which exists to build rigour into the updating and maintenance of the register - so it can continue to serve as the authoritative, trustworthy source of information on local authorities in England. The second step is reviewing and incorporating any appropriate feedback from alpha, which is where you come in.
We need you
One of the best things about getting a register into alpha is that we can share it to get feedback. When looking at the register, you’ll notice there’s a link to provide feedback in the header and this will be directed to the appropriate person:
- Any feedback on the accuracy, clarity and structure of the information contained in the register will go to the custodian for consideration.
- Any thoughts you have on the registers platform as a whole will be fed back to GDS.
Even better, if like Parliament’s e-petitions service and GOV.UK Pay you think you have a service that would benefit from the use of registers then please get in touch.
4 comments
Comment by Robert Whittaker posted on
A few thoughts on http://local-authority-eng.alpha.openregister.org/ for you...
1/ Are the three-letter local-authority-eng values made up for this register, or are they an existing ID system? It would be better to use an existing system if possible.
2/ It's a shame the register only covers England. Data users may want dataset for whole of UK, and it would be annoying if local-authority-ni etc had different structures. I guess this is a problem with the single custodian idea. It's not too bad if it's one register per country, but what
happens for something like Public Rights of Way or Highways (List of Streets), where the same dataset is maintained in locally by a different custodian for each County Council? I don't think we'd want a separate register for each County. Perhaps you need a concept of a super-register that combines multiple identically-schema'd but differently custodian'd registers together for the benefit of users.
3/ There's no hierarchy information in the register. As a data user, I'd like to be able to find out which District level authorities fall within a given County-level authority. Perhaps this could be achieved with a "parent" field.
4/ There's no (links to) boundary GIS data. That boundary data might not belong in this register, but there needs to be a way to get said data using the local-authority-eng key. Perhaps a separate register is needed for this (different custodian). (But I don't think you have a geographic boundary data field type yet.)
5/ It's a shame parish and town councils are not also included, either in this register or as a separate register.
6/ In the display at http://local-authority-eng.alpha.openregister.org/records the records seem to be sorted in reverse alphabetical order by name -- which is odd.
Comment by Paul Downey posted on
Thanks Robert, this is excellent feedback. I'll try to answer these issues, point by point:
1/ we took the key field value from ISO 3166-2;GB values. Unfortunately these didn’t cover all of the local authorities in England, so our custodian generated the additional codes we needed for the purposes of alpha. We’re working on how this can be fed back to the ISO standardisation process, in a similar way to how our country custodian already engages with ISO 3166-2 process.
2/ it’s the role of the Registers Design Authority to ensure registers such as local-authority-wls, local-authority-sct, local-authority-nir have consistent structures. It might be a little more complicated having four separate registers, but it’s how government is organised. We don’t so much see this as a problem, rather an advantage as we’re moving data closer to where it’s actually made. Part of the criteria for becoming a custodian is an ability to demonstrate how maintaining the register is part of a business as usual process in which the custodian has authority, e.g. the people drawing up Statutory Instruments to create new local authorities or change their name change the register ahead of the changes being enacted.
This distributed model doesn’t necessarily apply to every register, for example there are a number of business processes across government where legislation instructs a central government department or agency to keep and maintain a national register sourced from multiple sources, divided by geography or some other jurisdiction. We envisage indexes to help search across “multiple identically-schema'd but differently custodian'd registers together for the benefit of users”.
3/ you’re definitely not alone, we proposed having a "parent" field in this register during our discovery, but this was something our custodian was very opposed to, in part because we were unable to find a name which didn’t imply some kind of hierarchy between authorities (in terms of power), which he explained very clearly and far better than I could, does not exist. We don’t want to perpetuate a misnomer, so left the parent field out of the alpha.
Looking ahead other registers will emerge which will meet the needs around which authorities apply to given a location.
4/ we’re looking into the process by which local authority boundaries are kept and maintained. A key part of this process are ONS who publish data against the geography of local authorities, using the widely adopted GSS code which changes when the local authority’s boundary changes.
One thing we do know for sure is boundaries are managed by a different authority and business process to they way the names and roles of local government organisations are managed, so boundaries will have a different custodian and therefore be a separate register, linking to the local-authority-eng register.
5/ parishes and town councils fall outside of the authority of this register, but noted it’s a need.
6/ The order of entries in a register is the order they were added or updated, collating records by their key is something you’d expect from an index, and something we’re considering for the register API.
Comment by M posted on
Why is Birmingham's start date 1st July 1996? If you want the date it changed name from Birmingham District Council to City Council, that was 1st July 1986 (and Birmingham District Council existed since 1974).
Comment by exstat posted on
"The GDS registers team support this by ensuring that the registers a custodian owns only contain information they are empowered to collect and maintain. A register shouldn’t contain anything that a custodian can’t ensure the accuracy of, but it can and should link to relevant information from other registers. "
I wonder how realistic this statement is. I am several years out-of-date now but when I was a user of the ONS Interdepartmental Business Register (IDBR) it used data from the VAT and PAYE systems. This was partly to enable the construction of the statistical units held on the IDBR but it was essential to have data immediately to hand because the size of a business influenced its probability of being selected for a statistical inquiry (the largest get the lot; the smallest see one every few years). It was also valuable information for use in validation of the data received and for the estimation process that transformed the raw data into statistics.
I doubt that it could be argued that the ONS data custodian is able to ensure the accuracy of all the data received from HMRC and they are certainly not responsible for collecting it! The idea of linking to HMRC data each of the millions of times a year a data item is required is (or at any rate was) somewhat fanciful.
So does that mean that the Interdepartmental Business Register is not a register in the eyes of today's data scientists, despite its name?
I'd say that it is a very large register, but one that is so tied to particular business processes (statistical data collection) that it has to be very complex and has to break the rule that I have quoted from the blog. I'm reminded of all those laws of data normalisation for databases, most of which happily break at least one of those laws without the world ending!
Without wishing to belittle what is clearly a valuable piece of work, a register of local authorities is surely a heck of a lot simpler. A project to turn lists into registers is fine, as long as we don't redefine a register as something that can be created from a list!