Data models & ontologies: the shared vocabulary your data is missing

Most data problems aren't technical. They're semantic. Two systems both have a field called “customer,” but one means “the company that signed the contract” and the other means “the person who logged in yesterday.” Nobody notices until a report is wrong, an integration silently drops half the records it should have matched, or a migration takes twice as long as planned because nobody agreed what a “property,” a “policy,” or a “patient” actually is.

Ontologies and industry data models exist to fix exactly this. They're the difference between a data platform that scales across systems and one that needs a bespoke translation layer every time you add a new source.

Two different tools, often confused

Ontologies are formal, machine-readable definitions of concepts and how they relate to each other — built for semantic interoperability, classification, and inference. They're the layer that lets a system reason about your data, not just store it.

Industry data models are structured reference models — usually UML, relational, API, XML, JSON, or RDF-based — that standardise the entities, attributes, and processes specific to a sector. They're built for exchange and integration between systems.

There's no single objective ranking of “most important” here — it depends on adoption, standards-body backing, and how directly a standard maps to your own systems. In practice, most organisations need both, layered: an industry model for operational exchange, a canonical model for internal integration, and an ontology layer for shared meaning across the two.

Widely reusable, across any sector

A handful of general-purpose vocabularies are worth knowing regardless of industry:

• Schema.org — the default vocabulary for describing organisations, products, and content on the web
• SKOS — the standard for taxonomies, classifications, and controlled vocabularies
• Dublin Core — general-purpose metadata for digital resources
• DCAT — data catalogue and dataset metadata
• PROV-O — provenance and lineage, increasingly relevant for AI and data governance
• RDF / RDFS / OWL — the foundational languages for knowledge graphs and semantic modelling
• GeoSPARQL and SOSA/SSN — spatial data and sensor/IoT observations

The shortlist by sector

This is a starting point, not an exhaustive list — most sectors have several overlapping standards at different levels (a formal ontology, an operational exchange model, and a messaging standard), and the right combination depends on the integration problem you're actually solving.

Why this matters more than it looks like it should

A standard doesn't need to be adopted wholesale to be useful. Most of the value comes from using it as a reference point: a way to check whether your own data model is missing an entity, conflating two concepts, or reinventing something a whole industry has already agreed on. That's often the fastest way to find the gaps a migration or integration project would otherwise discover the hard way, mid-project — inconsistent identifiers, a key term defined three different ways across three systems, an entity type nobody modelled because it fell between departments.

How we'd help you choose

Before recommending any standard to a client, we look at:

• Scope — does it cover your business concepts, or just a narrow exchange?
• Authority and adoption — is it governed credibly, and are your partners and vendors already using it?
• Implementation reality — are there RDF, API, or schema artefacts you can actually build against, or is it a PDF and a promise?
• Mapping effort — how far is it from the systems and identifiers you already run on?
• Governance and licensing — are versions and deprecations tracked clearly, and can you use and redistribute it commercially?

This is exactly the kind of gap analysis we do in a Data Management Maturity Assessment — not adopting a standard for its own sake, but working out which layer of your data estate actually needs one, and which one fits.