Guides to interoperability, linked data and digital public servicesAbout Semantic Gov
Semantic GovJoined-up public services, explained. 12 guides · sourced · plain English

Article ·

Five questions to ask before you build a new public register

A new register can become the trusted source other services rely on, or one more copy that slowly drifts out of date. Five questions made early decide which.

Public bodies build registers all the time: of licences, of premises, of providers, of people eligible for a scheme. Some become the source that every other service checks against. Others turn into one more list that needs reconciling every quarter. The difference is rarely the technology. It is a handful of decisions made before the first table is designed.

The European Interoperability Framework (EIF) calls base registries the cornerstone of European public service delivery: trusted, authoritative sources of basic information that can and should be reused by others, with one organisation responsible for each.1 These five questions turn that idea into a project checklist. The full background is in base registries and data exchange.

1. Does an authoritative source already exist?

The cheapest register is the one you don’t build. Before starting, check whether another body already keeps the facts you need, and whether you could reuse them under an agreement instead of collecting them again. The EIF suggests administrations keep a high-level overview of their registries and what they hold, a “registry of registries”, precisely so this question can be answered.1

If part of the information exists elsewhere, the new register may only need to hold what is genuinely new, such as a licence number and its conditions, and point to the existing records for the person, business or address.

2. Who is accountable for it?

A register that “belongs to the programme” belongs to no one once the programme ends. The EIF expects one organisation to be responsible and accountable for collecting, using, updating and preserving each registry, or each part of a distributed one, with one body coordinating the whole.1

In practice that means naming an owner, a budget line for upkeep and a process for corrections before launch, not after the first complaint.

3. What identifies each record?

Every record needs an identifier that other systems can store and trust: a licence number, a company number, a property reference. Matching on names and addresses is fragile, and an identifier that changes when a record is edited is not an identifier at all.

If the register will be published or linked to, think about web identifiers too. W3C’s Data on the Web Best Practices asks publishers to identify data with carefully chosen, persistent web addresses, and warns against building in the name of the department that happens to run the service today, because organisations are merged and renamed while the job carries on.2

4. What does each field mean?

Two registers can both hold “start date” and mean different things: the date of application, of approval or of first trading. The EIF recommends that registries publish their interfaces and metadata, including a glossary of terms, so that others know what each field means.1

Starting from a shared model saves a great deal of that work. The Commission’s Core Vocabularies, for people, businesses, locations and public organisations among others, are meant to be the starting point for a new system’s data model and a common export format for base registries.3 The guide to ontologies and core vocabularies explains how to use and extend them.

5. Who can see it, and how do people correct it?

Access rules belong in the design, not the privacy notice. The EIF expects access to registries to be regulated in line with privacy and other law, with security and control mechanisms in place.1 Decide early which bodies will query the register, for which purposes, and how each query is logged.

Correction is the other half. The EIF recommends a data quality assurance plan, and says citizens and businesses should be able to check the accuracy and completeness of their own data.1 A register that people can see and correct gets better over time; one they can’t see accumulates errors that every connected service then repeats.

Example

A council plans a register of licensed short-term lets. Working through the questions, it finds the property and owner details already exist in other registers, so it stores only the licence number, conditions and dates, linked to the national property identifier and an owner reference. The licensing team is named as owner, a glossary defines “start date” as the date the licence takes effect, and owners can view and challenge their own entry online.

The common thread

All five questions come back to the same idea in the European Interoperability Framework: a register is valuable when others can rely on it. That needs a clear owner, stable identifiers, written-down meaning, sensible access and a way for the people it describes to keep it right. None of those is expensive at the start. All of them are expensive to add later.

Sources

  1. European Interoperability Framework: Implementation Strategy (COM(2017) 134 final), European Commission (EUR-Lex). Accessed 17 October 2026.
  2. Data on the Web Best Practices, W3C. Accessed 17 October 2026.
  3. Core Vocabularies, European Commission, Interoperable Europe Portal (SEMIC). Accessed 17 October 2026.