Skip to content

Library · Data Practice OS

Ontology, vocabularies and entity resolution

Reference guide · Published · Source reviewed

Short answer. Most the organisation decisions need three things in the meaning layer of the From data to decisions - the decision stack: a glossary everyone agrees on, controlled vocabularies for the code lists that cross systems, and shared identifiers so the same vehicle, person or road segment is recognised in each system. A formal Ontology comes later, and only where relationships carry rules.

Status. Proposed practice for this guide. Not an agreed decision. Standards named here are stable, but verify tool support before you choose a product.

Four levels, cheapest first

Level What it is Good for Lives in
Business glossary Agreed terms with a definition, owner and examples People and AI agreeing on what "active licence" means The Catalog, with descriptions on columns
Semantic layer Metrics and dimensions defined once, in code Correct numbers in BI and text-to-SQL The semantic layer
Controlled vocabulary A managed code list with preferred labels, synonyms and broader/narrower links Defect types, vehicle body types, offence categories, document types A versioned reference table, or SKOS
Ontology Classes, relationships and constraints that a machine can reason over Questions where relationships carry rules: "a B-double is a combination vehicle, so these route rules apply" OWL or a property graph schema, often behind a Knowledge graph

Each level builds on the one before it. An ontology without an agreed glossary encodes the disagreement in a more expensive form.

Glossary vs ontology

A glossary says what a word means. An ontology says how things relate and what follows from that. "Registered operator" in the glossary is a definition. In an ontology it is a relationship between a person or organisation and a vehicle, valid over a period, and it implies obligations.

Use the glossary for definitions people read. Use an ontology when software must follow the relationships to reach an answer, and the relationships are too many or too changeable to write as joins in each query.

SKOS for shared code lists

SKOS (Simple Knowledge Organization System, a W3C recommendation) is the lightest standard way to publish a vocabulary. Each concept has:

  • a stable identifier (a URI, or a code the organisation controls);
  • prefLabel and altLabel, the preferred name and its synonyms, which also feed search and RAG;
  • broader and narrower, so "pothole" sits under "pavement surface defect";
  • exactMatch and closeMatch to the same concept in another scheme, such as a national classification or a partner agency's list.

You do not need a triple store to use SKOS. A dbt seed or reference table with these columns, under version control with an owner, gets most of the value. Publish it as SKOS only when another system or agency needs to consume it in that form.

# seeds/defect_type.yml (illustrative)
- id: dt-pothole
  pref_label: Pothole
  alt_labels: [pot hole, pavement hole]
  broader: dt-pavement-surface
  effective_from: 2025-07-01
  owner: Maintenance standards

Entity resolution: one thing is one thing

Entity resolution decides whether two records refer to the same real-world entity. The organisation has this problem everywhere: a customer in licensing and in the contact centre, a vehicle by VIN and by plate over time, a road defect reported by three members of the public and an inspector.

Practical rules:

  1. Prefer a shared identifier to matching. If a system of record issues an identifier, carry it everywhere. Match only where no shared key exists.
  2. Keep the match, not just the merge. Store the link (record A ↔ record B, the method, the score, the date, who confirmed it) as data. A silent merge cannot be reviewed or undone.
  3. Deterministic first, probabilistic second. Exact keys, then rules (same licence number and date of birth), then scored matching with a threshold and a human review queue for the uncertain band.
  4. Separate the person from the role. The same person can be a licence holder, a registered operator and a complainant. Resolve the person once; model the roles as relationships.
  5. Record the effect on decisions. A wrong merge can attach another person's history to a licence decision. Matches that feed decisions about people need a confirmed status, and the Decision record should cite the resolved identifier it used (Decision provenance).

Where the organisation already runs Master data management, the Golden record is the output of this work. Where it does not, start with the links table and a review queue. That is enough to make decisions consistent.

Ownership

Each vocabulary and identifier scheme needs an owner who can say no. Without one, code lists fork across systems within a year. Put the owner in the catalog, and put changes through the same pull request flow as code (Data as code).

Not when

  • Do not build an ontology for a single dashboard. A glossary and the semantic layer are enough.
  • Do not publish SKOS or RDF until a consumer needs it. A versioned table with the same columns is easier to govern.
  • Do not run probabilistic matching on personal records without a privacy impact assessment and a review queue (Privacy impact assessment).
  • Do not let a model invent relationships and store them as fact. Model-proposed links stay proposals until an owner confirms them (Rule authority).

Related: When a knowledge graph earns its place, The semantic layer, Naming conventions.

Source links: Data Practice reading list.