A few weeks ago, the Department for Communities and Local Government’s local authority England register was released to alpha. Hot on the heels of that, the Foreign and Commonwealth Office’s (FCO) second register - the territory register - is now in alpha too.
The territory register’s custodian, Tony Worron, has kindly shared his experience of going through the register creation process.
How the register came to be
Early on in discussions with GDS about the country register, it became clear that there are some government services provided to people in places that don’t exist in that register. These are places that aren’t recognised by the UK government as independent countries, but either have populations who use government services or are referred to in legislation as distinct entities.
For example, somebody who lives on the island of Wallis and Futuna can use the online petitions service, even though the island is a French territory as opposed to a part of France itself.
This is where the territory register comes in. This is a list of approved British English-language names and descriptive terms for political, administrative and geographical entities that the UK government would describe as territories rather than countries. Because of their sometimes ambiguous status, there can be more sensitivities around some of the entries in the territory register.
Collaborating to create the register
We began with a couple of workshops. The FCO worked with GDS, HM Passport Office, the Department for Business, Energy and Industrial Strategy, and other departments to define the scope of the register. Together we clarified the design principles that came to light in the production of the register’s draft dataset.
Most of the work was in producing this initial draft, checking the status and correct names of the entries, and understanding the relationships between some territories and countries. This involved discussions with FCO colleagues and drawing on the expertise of the Permanent Committee of Geographical Names (PCGN).
GDS have been supportive throughout the process and recognise our authority in this area. In addition to working with me on the shape of the data in the register, the registers team helped us think through and map processes where FCO had slightly less formal models. These more rigorous processes will be critical to ensuring that the new territory register remains accurate and up to date.
Designing the dataset
Working on geographical information policy in our Knowledge Management Department enables me to draw on the policy knowledge of the country desks, as well as the naming expertise of the PCGN - who have knowledge and an active role in international standards in this area.
I started by collating data on the overseas territories of various countries, using the widely adopted ISO 3166-2 code as the unique identifier. Surprisingly, not all of the territories in the register had these codes, so we provided a unique code for the register’s consumers to use where these codes were absent.
I was then able to model the data and provide the requisite information using the practical knowledge of PCGN, colleagues within my team who work on the FCO’s map service and colleagues in our Communication Directorate working on digital transformation and transparency. A useful byproduct of the register was a better understanding of how the various teams can work better together.
Benefits to FCO and users of territories data
The register is a means for the FCO to share our knowledge more widely - not least for our usual audience of subject matter experts, but also with other government partners and stakeholders. We can now think in more detail about what colleagues across government actually need from such a product.
It’s also helped us draw together connections between existing FCO and PCGN information sources, such as the Geographical Names Index and to think about how we might link with others, such as the FCO Treaty database.
Perhaps most importantly, the register is a useful tool for standardising the use of territory names. The increased visibility of the data contained in the register will encourage a consistent naming approach for territories.
I’m really looking forward to the country and territory registers being used together in the FCO, across other government departments, and externally by private organisations so it will widen the scope of our work. It will be a great example of how FCO continues to add value for a wider range of government and non-government users.
We know lots of people will have suggestions on how it could be improved and we’re keen to hear their thoughts! Getting your feedback will help us maximise the benefits of both the country and territory registers. It may be a challenge in dealing with conflicting requirements but it does emphasise the need for an authoritative policy lead.
5 comments
Comment by Stephen posted on
So how/where do you store the relationship between territories in the territories register and (if appropriate) countries in the countries register? Using your example, storing the relationship between Wallis and Futuna and France.
Comment by Tony Worron posted on
Hi Stephen, we do have information on the status of entities in the text field in the register. So in the case of Wallis and Futuna it is identified as “Overseas Collectivity of France”. But I realise that some services might need a data link between “France” and “Wallis and Futuna” if we are proposing that the Country and Territory registers could be used in conjunction.
Comment by Jake posted on
Thanks Tony. Really interesting blog post and great to see this moving forward. You say in it that you've used the ISO 3166-2 codes where available, but created alternative codes where they're not. What will happen if an ISO 3166-2 code is created for a territory after it's been entered into the register? Will the code change to the ISO one, or will it remain as the code that's been created?
Comment by Tony Worron posted on
A good question. Our policy is to use ISO codes where possible, as that does reflect requirements and link to existing standards. So I would say that we would update the register to include the ISO code. I am aware though that will have an impact on services using the register so it would be good to hear more on the issues that might create for users. Interestingly we are planning to do exactly this with the Territory register – the alpha version includes codes for Akrotiri and Dhekelia which we plan to update with ISO “user-assigned codes.
Comment by Jake posted on
Thanks for the reply Tony. I guess, though I'm not sure about this, that if we're using the code as a key to link data, changing the key after it's been publish would cause problems, though it might be that there is a different key that can be used to link to? However, each entry has a separate entry number and hash so those can't be used as a key to link to a record and I can't see anything else that could remain consistent across changes?