Why “address” is the hardest word in government data

Ask three public bodies for someone’s address and you may get three correct answers that don’t match. The council holds the property they pay tax on, the health service holds where they usually live, and the tax office holds where they want letters sent. Each field is called “address”. Each is right for its own purpose. Put them side by side in a data-sharing project and they look like errors.

That is why addresses are the classic example of a semantic interoperability problem. Two systems can exchange the field perfectly and still disagree about what it means.

Four things an address field can mean

Before anyone cleans a single record, it helps to name which idea a system actually holds. Most address fields in public services are one of these:

• A place. A building, a flat, a plot of land or a piece of infrastructure, whether or not post is delivered there.
• A residence. Where a person lives, usually or at a given date, which matters for entitlement and registration.
• A correspondence address. Where someone wants letters sent, which may be a relative’s home, a solicitor or a PO box.
• A registered address. For businesses, the official address on a register, which may be an accountant’s office rather than where the work happens.

Mixing these is how a benefit gets refused because the “address doesn’t match”, or how a company’s inspections go to the wrong town. The data is fine. The meaning was never written down.

Why matching on the text fails

Even when two systems mean the same thing, the text rarely lines up. “Flat 2, 14 High Street”, “14a High Street” and “2/14 High St” may all be the same front door. Fuzzy matching helps, but every rule that catches one variation creates a false match somewhere else, and the cost of a wrong match in public services can be a wrongly stopped payment.

The deeper problem is that text describes a place; it doesn’t identify it. Two flats in a converted house can share a street number. A substation has no postal address at all. A text field can’t tell you which object it points to, only what someone typed.

Three fixes that work

1. Give places an identifier

Great Britain’s approach is a useful model. Government systems, services and applications that store or publish property and street information must use the Unique Property Reference Number (UPRN) and the Unique Street Reference Number (USRN).¹ A UPRN identifies every addressable location, including things with no postal address such as an electrical substation or a public toilet, and a block of flats that shares one grid reference still has a separate UPRN for each flat.¹

Crucially, the identifier doesn’t replace the address. It is stored alongside it as an extra field, so records held by different bodies can be linked to the same place without anyone agreeing on spelling.¹

2. Use a shared model for the parts

Where data crosses organisations or borders, a shared model stops each team inventing its own address structure. The European Commission’s Core Location Vocabulary is one of its Core Vocabularies: simplified, reusable data models meant as a starting point for new systems and a common basis for exchanges between existing ones.² It describes a location as an address, a geographic name or a geometry.² The guide to ontologies and core vocabularies explains how these models are used and extended.

3. Check against one authoritative register

The European Interoperability Framework (EIF) treats base registries, including those for locations, buildings and roads, as trusted, authoritative sources that one organisation is accountable for and others can reuse.³ An address register is useful precisely because services check against it rather than keeping copies that drift apart. More on how registers and secure exchange fit together is in base registries and data exchange.

Where to start in your own service

1. Label the meaning. For every address field, write one sentence saying which of the four ideas it holds, and rename the field if it helps (“correspondence address”, not “address 2”).
2. Add the identifier. Where a national identifier exists, store it next to the text from the point of capture, not in a clean-up later.
3. Capture from the register. Let people pick from the authoritative list where you can, and keep free text for genuine exceptions.
4. Record dates. Residence changes. A start date on each address avoids treating last year’s home as today’s.
5. Agree before you exchange. When two services share data, agree which meaning travels in which field before the first test file is sent.

Addresses won’t ever be simple, because people’s lives aren’t. But the difference between a field that is merely filled in and one that is understood is mostly a matter of writing down what it means, and that is where joined-up services start.