From shared meaning to reliable agents: engineering an ontology you can trust in production

Last time I set out what it takes to build shared meaning: a governed vocabulary, a canonical model on global identity, governed metrics and data products. This piece picks up where that stopped. How do you turn that foundation into a formal ontology, prove it, and deploy it as production infrastructure that enforces your business rules, protects your data, and lets AI agents act without improvising?

Why agents raise the bar

A wrong number on a dashboard gets noticed by a person, usually before it does much harm. An agent that books, approves, reorders or escalates acts on what it believes, at machine speed, and nobody reads the reasoning first. The cost of an ambiguous definition, a duplicated customer or an unstated rule goes up sharply.

The foundation from last time answers "what do we mean?" Production agents also need four further answers:

• Is the model right? Does it say what we intend, and nothing we do not?

• Is it consistent, and can we show it? Not "it looked fine in review", but evidence

• Are the rules enforced where it matters? At ingest, at write, at the moment an agent acts

• Will it run at scale, securely? With the load, the access controls and the audit trail a production system needs

An LLM cannot supply these on its own, however fluent it is. They have to be engineered into the infrastructure the agent runs on, and the ontology is the place where they are written down once.

1. Formalise, in proportion

We do not start from a blank page. The SKOS vocabulary and canonical model from last time are the raw material, and the competency questions you wrote then become the specification: every question the ontology must answer is a test it must pass.

Formalising means moving from "these terms are related" to "this is what these terms necessarily mean", in OWL 2 — the Web Ontology Language. The skills go well beyond reading it:

• Modelling with restrictions and property characteristics. Transitive, functional, inverse and disjoint constraints are the difference between a diagram and a model a machine can check

• Choosing the profile deliberately. OWL 2 comes in profiles that trade expressivity for tractability. Existential Language (EL) and Rule Language (RL) reason in polynomial time and suit large data. Query Language (QL) is designed so that queries can be rewritten into SQL over the source databases. Full Description Logic (DL) is the most expressive and can be very expensive. This is a deployment decision as much as a modelling one, and it is the first one that determines whether the result will scale

• Ontology design patterns and reuse. Content patterns, the eXtreme Design method and modularisation let you model faster and more soundly than inventing every structure afresh

• Visual design for stakeholders. G-OWL, the complete visual syntax for OWL 2 that I mentioned last time, keeps the domain experts in the review loop, which is where most formal ontologies quietly lose them

The point I made from last time stands. Most of an enterprise value comes from the earlier layers, and a small, careful amount of formal ontology goes where it earns its keep: the core concepts that agents will reason over and act on.

2. Analyse before you assert

Formal languages let you say things that are wrong with great precision. The usual failures are not syntax errors. They are modelling errors: a role treated as a kind of thing, a part-whole relation mistaken for subclassing, a class that mixes things with different identity criteria.

OntoClean (Guarino & Welty) is the established method for catching these. You tag each class with four meta-properties (rigidity, identity, unity, dependence) and the rules show you where a taxonomy is unsound. E.g.: "Student" is a role a person plays, not a subclass of "Person", and a model that makes it one will misbehave the first time someone graduates.

Then anchor the model. A foundational (upper) ontology such as BFO — the Basic Formal Ontology (ISO/IEC 21838-2:2021), DOLCE or the business-oriented gist gives your concepts a consistent footing and makes your model easier to align with others. And reuse what already exists: FIBO in finance, SNOMED CT in health, QUDT for units. Reuse is cheaper than invention and makes you interoperable by default.

3. Prove it

"Prove" covers three levels of assurance, each stronger and narrower than the one before. A sensible programme uses all three, in proportion.

• Test. Treat the ontology like software. Competency questions become executable tests that run on every change, and pitfall scanners such as OOPS! catch common design errors. This level is cheap and catches a great deal

• Reason. A description-logic reasoner (HermiT for full OWL 2 DL, ELK for the EL profile) checks consistency and satisfiability, classifies the model, and, when something is wrong, produces justifications: the minimal set of axioms responsible. That turns "the reasoner says it is inconsistent" into a fixable defect

• Prove. OWL cannot express everything an enterprise cares about: relationships between more than two things, rules that cut across properties, general constraints. For those you move to first-order logic and Common Logic (ISO/IEC 24707:2018), written in its CLIF — Common Logic Interchange Format dialect. A theorem prover (Prover9, Vampire) shows that an intended consequence really follows from your axioms. A model finder (Mace4) searches for a counter-example, and finding one shows the axioms permit something you did not intend. Together they let you check consistency, intended entailments and whether each axiom pulls its weight. Repositories such as COLORE hold verified ontologies you can learn from and reuse

Be realistic about the third level. First-order proof can be slow and is not guaranteed to terminate, and it takes specialist skill. Apply it to the small core where a flaw would be expensive: the definitions that gate payments, safety decisions or regulated outcomes. For everything else, testing, reasoning and runtime constraints give you strong assurance at a fraction of the cost.

4. Enforce the rules

This is where business rules, structural constraints and integrity constraints stop being documentation. The key point is that different rules live in different places, and mixing them up is a common source of surprises:

• OWL says what things are, under the open-world assumption. A missing fact is unknown, not false, so OWL will not reject a record for being incomplete

• SHACL — the Shapes Constraint Language says what a valid record or action looks like, checked closed-world against the data in front of it: required properties, cardinalities, datatypes, value ranges, allowed value sets, relationships that must exist. These are your structural and integrity constraints, and SHACL reports each violation in a standard, machine-readable form. SHACL 1.2 is still a Working Draft at the W3C, so check which engine supports what

• Rules beyond OWL. Derivations and constraints that exceed description logic go in Semantic Web Rule Language (SWRL), Rule Interchange Format (RIF) or Common Logic, or in executable SHACL rules, depending on the engine you will run them on

• Transactional integrity still belongs in the systems of record. The semantic layer adds cross-system rules; it does not replace the database's own guarantees. We may need to express cross system reversal by compensating transactions at the business process level

The discipline is to write each rule once, in the ontology and its constraint set, under version control, and then enforce it at every point where it could be broken (figure 2 below). A rule copied into five applications will drift. A rule referenced from one governed source will not.

5. Build the graph

An ontology with no data is a diagram. The production graph is built with the techniques that connect your estate to the model:

• Declarative mapping. RDB to RDF Mapping Language (R2RML) and RDF Mapping Language (RML) describe how source tables, files and APIs map to the ontology, so the mapping is itself a governed, reviewable artefact rather than buried pipeline code

• Materialise or virtualise. Load the data into the graph, or leave it in place and let ontology-based data access (OBDA) tools such as Ontop answer queries by rewriting them to the source databases. Materialising is faster to query and simpler to reason over; virtualising avoids copies and stays fresh. Most estates end up using both

• Identity. A deliberate IRI strategy, and entity resolution (blocking, matching, probabilistic linkage, with tools such as Splink) so that four records for one customer become one. A governed ontology over duplicated entities is still wrong

• Pipelines with quality gates. Orchestration (Airflow, NiFi) with SHACL validation as a gate, so bad data is stopped and reported before it reaches the graph

6. Serve and act

Agents and applications need a governed way in. That means a serving layer: SPARQL (with property paths and federation), GQL and Cypher for property graphs, and GraphQL for application developers who want an API rather than a query language. Design it API-first, with caching and access control as part of the design, not afterthoughts.

The more interesting step is the operational semantic layer. Once the ontology describes your entities and how they relate across systems, you can describe actions on them too: approve this order, reassign this case, escalate this claim. An action has a type, parameters, preconditions and effects, all expressed in terms of the ontology. Systems that follow this pattern, Palantir Foundry being the best-known commercial example, can drive workflows across the whole estate without moving the data first.

This is what makes an agent's action safe to permit. The preconditions are the rules from capability 4, so an action that would break an integrity constraint is refused before it commits, whichever agent or person attempted it.

7. Scale and secure

Production brings the questions prototypes avoid.

Scale is largely won or lost through earlier decisions:

• The OWL profile you chose in capability 1 sets the ceiling on reasoning cost. Materialising inferences once at load time, rather than reasoning at every query, is a common and effective trade

• Modularise the ontology, so that each application loads what it needs, not everything

• Index and tune the graph (Cypher query optimisation, the right indexes, avoiding supernodes), use graph algorithms where they add insight, and choose between RDF and property graph per workload, with a bridge between them

• Cache the serving layer, and test with realistic volumes before a rollout, not after

Security needs to be designed into the same layers, not bolted on:

• Access control at the serving layer. Who may see which graph, entity type or property, and who may invoke which action. Enforce it where the query or action is executed, and keep the policy under version control with the ontology

• Least privilege for agents. Expose an agent to a narrow, explicit set of tools, authenticated and authorised in their own right. The Model Context Protocol (MCP) is becoming the common way to offer tools to agents, and its authorisation model builds on OAuth. Treat each tool as an API with a security review

• Do not rely on the model to police itself. A prompt that says "never do X" is a request, not a control. Prompt injection means an agent can be talked out of an instruction. The constraint has to sit in the infrastructure, where the agent cannot argue with it

• Provenance and audit. Record what was asked, which facts were used, which rules fired and what was done, using a standard such as PROV-O — the PROV Ontology. That is how you answer a regulator, or a customer, who asks why the system did what it did

Platform security (identity management, network, secrets, encryption) is a discipline in its own right and belongs with your enterprise security architects. The semantic layer's job is to make sure the access rules are expressed against meaningful entities and enforced at the point of use.

8. Ground and guard the agents

Now the agent. Grounding means it works over the governed graph rather than raw tables or a pile of text chunks.

• Retrieval that follows relationships. Vector RAG finds similar passages. GraphRAG and KAG (knowledge-augmented generation) retrieve over the graph, which suits multi-hop questions, identity-dependent questions and anything that turns on a rule. Evaluate them rather than assume: DeepEval and RAGAS measure whether answers are faithful to the retrieved facts

• Context as an engineered asset. A context graph gives the agent memory and a stable picture of the entities it is dealing with, rather than whatever fits in the prompt

• A neuro-symbolic loop. The model proposes, the ontology disposes. The agent drafts a plan or an answer, and the symbolic layer checks it against the constraints and the facts before anything happens. A rejected proposal returns to the agent with the reason, so it can try again

• Guardrails and an evaluation harness. SHACL and reasoner checks at run time, an automated test suite of realistic scenarios, monitoring in production and a record of every run. This is where "reliable" is earned. It is measured, not asserted

One more thing about speed. An LLM can draft candidate classes and axioms in minutes, and used properly it is a real accelerator. Used carelessly it produces a vibe ontology: plausible, fluent and unverified. The safe pattern is the one from last time, assisted then verified: LLM drafts, then competency questions, OntoClean, reasoner and SHACL as gates, with a human reviewing and the provenance recorded.

Governing it as software

An ontology that drives production systems is a production artefact. It needs the lifecycle you would give any critical software: an owner, versioning, a change process, automated tests on every change, a release process, and a way to deprecate rather than delete. Methodologies such as NeOn give you a full ontology-engineering lifecycle. The practical rule is simple: nothing reaches production that has not passed the tests.

A minimum viable production kit

As before, you do not need all of it at once. For one domain and one agentic use case, a defensible first production release is:

• A verified ontology core with its competency-question test suite, and a reasoner consistency report

• A SHACL constraint set covering the structural, integrity and business rules for that use case

• A source-to-graph mapping and a populated graph with entity resolution and quality gates

• A governed serving layer with access control, and one typed action with its preconditions

• One grounded agent with run-time guardrails, an evaluation harness and an audit trace

• A governance pack: owners, versions, change process and release gates

That is a small system, but it is complete: it can be run, tested, secured, audited and extended. The next domain reuses most of it.

The skills, in one place

Last time the role was the semantic translator. The role here is the person who turns that translation into infrastructure, an ontology and knowledge engineer for agentic systems:

• Formal modelling: OWL 2 with deliberate profile choice, design patterns, and ontological analysis with OntoClean and upper ontologies

• Verification: competency-question testing, DL reasoning, and first-order proof and model finding for the critical core

• Constraint engineering: SHACL and rule languages, and the judgement to put each rule in the right place

• Data engineering for graphs: declarative mapping, OBDA, identity and entity resolution, pipelines with quality gates

• Serving and action design: SPARQL, GQL, GraphQL, access control and action modelling

• AI engineering: GraphRAG and KAG, context engineering, agent guardrails, evaluation and monitoring

• Governance: ontology lifecycle, versioning, provenance and audit

It is a demanding profile, but it is learnable. Most of the people who can learn it are already in your organisation, working as modellers, data engineers and architects.

How we're approaching it

This is the ground the second course of our pathway covers, under the same line as the first: Build Shared Meaning Today to Engineer Reliable Agentic Automation Tomorrow.

Course 2 — Engineering Reliable Agentic Automation is for modellers and ontologists, data, ML and AI engineers, and solution architects. It builds on Course 1 (or equivalent: RDF and OWL basics, SPARQL and property graphs) and expects some programming familiarity, for example in Python. Over four and a half days it works through capabilities 1 to 8 at working-to-deep level:

• rigorous modelling: OWL 2 in depth, design patterns, OntoClean and upper-ontology alignment

• constraints, validation and formal reasoning: SHACL, DL reasoners, Common Logic and CLIF, and verification with a theorem prover and a model finder

• engineering the knowledge graph: mappings and OBDA, entity resolution and pipelines, graph performance and algorithms, and the serving layer in SPARQL, GQL and GraphQL

• the operational semantic layer and agentic AI: virtual knowledge graphs, the action layer, GraphRAG and KAG, and grounding agents with context engineering

• reliability, safe acceleration and a capstone: guardrails, evaluation and governance, LLM-assisted construction done safely, and an end-to-end system presented to peers

Every skill is taught on open standards, with the mainstream tools named for each topic. Access control and auditability are built into the serving, agent and reliability sessions. Wider platform security remains the job of your security architecture, and we say so. Participants leave with a working system for a domain of their own: a verified ontology, its constraint suite, a populated graph, a serving layer and a grounded agent with its guardrails and evaluation harness. More on both courses in the posts that follow.

Details of our two course path →

If you would like to discuss the implications of the above for your specific organisation or situation, please book a slot with me:

References and standards

1. W3C, OWL 2 Web Ontology Language Primer, 2nd edition, 2012 — https://www.w3.org/TR/owl2-primer/ · OWL 2 Profiles, 2nd edition, 2012 — https://www.w3.org/TR/owl2-profiles/

2. Guarino, N. & Welty, C. (2009), "An Overview of OntoClean", in Handbook on Ontologies, 2nd edition, Springer.

3. ISO/IEC 21838-2:2021, Top-level ontologies — Basic Formal Ontology (BFO). Arp, R., Smith, B. & Spear, A. (2015), Building Ontologies with Basic Formal Ontology, MIT Press.

4. Presutti, V. et al. (2009), "eXtreme Design with Content Ontology Design Patterns"; Gangemi, A. & Presutti, V. (2009), "Ontology Design Patterns", in Handbook on Ontologies.

5. Glimm, B. et al. (2014), "HermiT: An OWL 2 Reasoner", Journal of Automated Reasoning; Kazakov, Krötzsch & Simančík (2014), "The Incredible ELK", Journal of Automated Reasoning.

6. Poveda-Villalón, M., Gómez-Pérez, A. & Suárez-Figueroa, M. C. (2014), "OOPS! (OntOlogy Pitfall Scanner!)", International Journal on Semantic Web and Information Systems.

7. ISO/IEC 24707:2018, Information technology — Common Logic (CL). Grüninger, M. et al., COLORE: Common Logic Ontology Repository.

8. W3C, Shapes Constraint Language (SHACL), Recommendation, 2017 — https://www.w3.org/TR/shacl/ (SHACL 1.2 in Working Draft). Labra Gayo, J. E. et al. (2018), Validating RDF Data, Morgan & Claypool.

9. W3C, R2RML: RDB to RDF Mapping Language, Recommendation, 2012 — https://www.w3.org/TR/r2rml/. Dimou, A. et al. (2014), "RML: A Generic Language for Integrated RDF Mappings of Heterogeneous Data".

10. Xiao, G. et al. (2018), "Ontology-Based Data Access: A Survey", IJCAI. Calvanese, D. et al. (2017), "Ontop: Answering SPARQL queries over relational databases", Semantic Web.

11. W3C, SPARQL 1.1 Query Language and Federated Query, Recommendations, 2013 — https://www.w3.org/TR/sparql11-query/. ISO/IEC 39075:2024, GQL.

12. W3C, PROV-O: The PROV Ontology, Recommendation, 2013 — https://www.w3.org/TR/prov-o/

13. Model Context Protocol — https://modelcontextprotocol.io/ (check the current specification and its authorisation section).

14. Edge, D. et al. (2024), "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" — arXiv:2404.16130. Liang, L. et al. (2024), "KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation" — arXiv:2409.13731.

15. Pan, S. et al. (2024), "Unifying Large Language Models and Knowledge Graphs: A Roadmap", IEEE TKDE.

16. Suárez-Figueroa, M. C., Gómez-Pérez, A. & Fernández-López, M. (2012), "The NeOn Methodology for Ontology Engineering", in Ontology Engineering in a Networked World, Springer. Kendall, E. & McGuinness, D. (2019), Ontology Engineering, Morgan & Claypool.

17. Grüninger, M. & Fox, M. (1995), "Methodology for the Design and Evaluation of Ontologies", IJCAI Workshop on Basic Ontological Issues in Knowledge Sharing.

Your data has structure. It doesn't have meaning

Why enterprise AI has made a thirty-year-old question urgent — and what the move from Information Engineering, UML and relational modelling to graph, semantic and ontology-driven execution actually demands of practitioners.

The problem is not the model. It's the ground truth.

Shared meaning is not a new problem. Warehouse teams have been fighting "whose definition of revenue?" for thirty years. What changed is who is now reading the data.

A traditional report was read by an analyst who knew that "active customers" in the marketing dashboard was not the "active" the risk team used. She carried the caveat in her head, applied it, and moved on. The ambiguity was real but bounded — it lived in a few expert skulls and travelled no further than a meeting.

Put an agent in that seat. Ask it "how many active customers do we have in the North region, and what is their total exposure?" It will join the marketing table's active flag to the risk system's exposure column, sum the result, and return a confident number in fluent prose. It does not know the two systems mean different things by customer. It has no caveat. And its output looks exactly as authoritative as a correct answer would.

Three properties of AI-mediated work turn latent ambiguity into active cost:

• Amplification. A human analyst makes one join an hour. An agent makes thousands, unsupervised. Every wrong assumption about what a field means is now executed at machine scale

• Composition. Agents chain steps. A subtly wrong definition at step one propagates, and by step five the provenance of the error is gone. The answer is wrong and unexplainable at once

• Opacity of confidence. The failure mode is not a crash or a NULL. It is a plausible, wrong, actionable answer - the expensive kind

The instinct, when the agent gets it wrong, is to reach for a bigger model or better prompts. But the error is not in the model's reasoning. It is in the ground truth the model reasoned over. If customer denotes four different things in four systems, no amount of model capability recovers the one you meant — because that thing was never written down anywhere a machine could read it.

Semantics is the missing input, not a missing capability.

"Semantic" means five different things

Here is where most programmes go wrong before they start. "Semantic layer" is the most overloaded phrase in enterprise data. Serious people use it to mean at least five distinct things that live in different places, are owned by different people, cost different amounts and solve different problems.

They are not rival definitions. They are a stack:

Read one word — customer — down that stack and the point becomes clear. Each reading is legitimate. Each is owned by a different team. Each fails in a different way.

Why this matters commercially: a retail bank funds a "Single View of Customer" programme. The deck talks about AI. The budget goes on a layer-3 analytics semantic layer, because that is what the vendor demonstrated. Eighteen months later the executive dashboard still shows three different customer counts — because the actual problem was layer 2. The same person exists as four unreconciled records in four systems, and no metrics layer reconciles identities it was never given. The programme built a precise calculator on top of an unresolved question.

Buying layer 3 to fix a layer-1 or layer-2 problem is the single most expensive mistake in this field.

Four demands, and the standards that answer them

1. Shared meaning — a common controlled vocabulary

Before anything else: do people agree what the words denote? "A customer is a natural or legal person who holds at least one live product with the bank." Plain language, agreed by humans, no code.

Most "data quality" disputes are vocabulary disputes wearing a technical costume. The formalisation is cheap and unglamorous: SKOS — the Simple Knowledge Organization System (W3C Recommendation, 2009) gives you concepts, preferred and alternative labels, broader/narrower hierarchies and mappings between schemes. ISO 25964 covers thesaurus construction and interoperability; ISO/IEC 11179 covers metadata registries and the discipline of naming and defining a data element properly.

This is the twenty per cent of the stack that needs no logic at all and returns most of the value. Skip it and everything above inherits the ambiguity.

2. Agreed derivation — the semantic layer for BI

Everyone agrees what a customer is, and two dashboards still disagree on the count, because the calculation lives in two places. The answer is a governed metric definition — active customer = at least one transaction in the last 90 days — written once, over the warehouse, and resolved identically by the dashboard, the notebook and the agent.

This is the sense most vendors mean today: the dbt Semantic Layer, Cube, AtScale, LookML. It is genuinely valuable, and it is also where the confusion concentrates, because it is the layer with the biggest marketing budget. A metrics layer computes flawlessly over whichever records you feed it. If those are four unreconciled customers, the metric is precise and wrong.

The real prize here is not the dashboard. It is that an agent can call a governed metric instead of misjoining raw tables.

3. Integration and interoperability — semantic expression

Point-to-point mapping does not survive past a handful of systems: n systems need n(n−1)/2 mappings, each with its own quiet assumptions. Meaning that travels needs to be expressed in a form that is not owned by any one system.

• Semantic data is best expressed in graphs. A graph is a connected set of statements, conceptually nodes and edges. e.g. John -worksFor-> Enron -sells-> Oil

• Graphs can be stored in simple fact statements (see RDF) or Labelled Property Graphs (see LPG)

• RDF — the Resource Description Framework (W3C; RDF 1.1 in 2014, with RDF 1.2 reaching Candidate Recommendation in April 2026) reduces everything to the triple: subject, predicate, object. e.g. John worksFor Enron; Enron sells Oil. RDFS — RDF Schema adds classes, properties and subsumption (class subtyping)

• IRIs — Internationalized Resource Identifiers replace local primary keys with globally resolvable names, so "the same customer" is a claim two systems can actually make

• SPARQL — the SPARQL Protocol and RDF Query Language (1.1, 2013; 1.2 in draft) provides queries and updates across a graph of triples

• RDF vs LPG — RDF data stores (otherwise known as Triple Stores) can accommodate data without schema (or with) and can expand easily to accommodate new data without structure change. They are best for integrating data from heterogeneous sources. Labelled Property Graphs are more efficient and best for transactional and operational data

• R2RML — the Relational DB to RDF Mapping Language (W3C, 2012) and RML — the RDF Mapping Language lift the relational and file-based estate you already have into RDF form, declaratively, without rewriting the sources

• JSON-LD — JavaScript Object Notation for Linked Data (1.1, W3C, 2020) carries the same meaning inside ordinary API payloads, which is how layer 4 gets done in practice

• On the property-graph side, GQL — the Graph Query Language (ISO/IEC 39075:2024) is now an ISO standard in its own right, and SQL/PGQ (part of ISO/IEC 9075:2023) brings graph pattern matching into SQL. The RDF-versus-LPG argument is largely over: mature programmes run both and bridge between them

• Reuse beats invention: There are many sources of well defined models addressing generic requirements as well as specific disciplines. Consult schema.org, FIBO — the Financial Industry Business Ontology, SNOMED CT — Systematized Nomenclature of Medicine, Clinical Terms, QUDT — Quantities, Units, Dimensions and Data Types, PROV-O — the PROV Ontology for provenance, DCAT — the Data Catalog Vocabulary for datasets

Using these technologies allows merging and reaching consensus on definition and holding that stable and shared in a standard format.

4. Reliability and agentic automation — formal ontology backed by logic

Here the stakes change. If an agent acts on your model, "roughly right" stops being a documentation problem and becomes an operational risk. That demands semantics formal enough for a machine to check.

• OWL 2 — the Web Ontology Language (W3C Recommendation, 2012) sits on description logics, a decidable fragment of first-order logic. Its profiles — EL, QL, RL and the full DL — are deliberate trade-offs between what you can say and what a reasoner can compute in reasonable time. Choosing the profile is an architectural decision, not a detail

• SHACL — the Shapes Constraint Language (W3C Recommendation, 2017; 1.2 drafts in progress) does the job OWL was never designed for: validating that actual data conforms to a stated shape. OWL says what things are; SHACL says what a valid record looks like. Conflating them is the most common beginner error in the field

• Common Logic (ISO/IEC 24707:2018), and its CLIF — Common Logic Interchange Format syntax, expresses the constraints description logic deliberately cannot: n-ary relations, multi-property rules, conditions over time. Paired with a theorem prover and a model finder, it also lets you verify an ontology — state the intended models, prove the entailments you expect, and check that your axioms are independent and consistent. This is the discipline that separates an engineered ontology from a plausible-looking one

• Top-level ontologies give your concepts somewhere to stand: BFO — the Basic Formal Ontology (ISO/IEC 21838-2:2021), DOLCE — the Descriptive Ontology for Linguistic and Cognitive Engineering, and gist (Semantic Arts small business high level ontology). OntoClean (Guarino & Welty) supplies the analytical tests — identity, rigidity, unity, dependence — that catch the taxonomy errors everyone else ships

Only at this rung does an agent get something it can be held to: classifications it can derive, constraints it can be blocked by, and an audit trail explaining why it concluded what it concluded.

The transition practitioners actually have to make

To be fair to the tools we already use, they carried us a very long way and none of this asks you to throw them out.

Codd's relational model (1970) gave data a rigorous mathematical foundation and the normalisation theory that removes update anomalies — arguably the most successful idea in applied computing. Chen's entity-relationship modelling (1976) gave us the picture: entities, attributes, cardinalities, drawn so a business person can read it and a database can be generated from it. UML class diagrams and the wider Information Engineering tradition added object structure and the discipline of conceptual → logical → physical design. The patterns literature — Hay, Simsion & Witt — is full of hard-won wisdom that remains correct: the Party pattern, role versus thing, resolving many-to-many relationships properly.

All of it comes with you. Graph modelling is not a rejection of data modelling. It is data modelling with the assumptions resolved.

The hard part is not the standards. It is the unlearning — and in my experience excellent data modellers find this transition harder than beginners do, precisely because the old instincts are so good. Thirty years of closed-world reflexes ("if there's no row, it didn't happen") do not switch off because you read the OWL primer. Training has to be designed around that, not around the specification.

Where to start

Most enterprises need a great deal of layers 1 to 3 and a careful, small amount of layer 5. Formal ontology is the most powerful and the most over-applied technique on the map. Reaching for OWL when a governed glossary and a resolved identity would have done is how semantic programmes acquire their reputation for cost and delay.

There is a newer failure mode too. Large language models will happily draft you an ontology in minutes. Without competency questions, OntoClean analysis, SHACL validation and reasoner checks, what you get is a vibe ontology: fluent, plausible, and unverifiable — the same failure as the confident wrong answer, one level further up the stack. Assisted, then verified. In that order.

What we're doing about it

These threads — shared vocabulary, the canonical model, the semantic layer, integration, formal ontology, and the bridge into agentic AI — are what we have spent this year building a training path around.

We're introducing it as two courses: a transition course for commercial analysts, BI practitioners and domain experts who need to become the bridge to semantic work; and an advanced engineering course for modellers, ontologists and AI implementors who have to build the solution and put it into production.

Ready to make this shift on your own data estate?

Course 1: Building Shared Meaning starts 19–23 October.

References and standards

Standards

1. W3C, RDF 1.1 Concepts and Abstract Syntax, Recommendation, 2014 — w3.org/TR/rdf11-concepts; RDF 1.2 Concepts and Abstract Data Model, Candidate Recommendation, 2026 — w3.org/TR/rdf12-concepts

2. W3C, SKOS Simple Knowledge Organization System Reference, Recommendation, 2009 — w3.org/TR/skos-reference

3. W3C, OWL 2 Web Ontology Language Primer, 2nd edition, 2012 — w3.org/TR/owl2-primer

4. W3C, Shapes Constraint Language (SHACL), Recommendation, 2017 — w3.org/TR/shacl; SHACL 1.2 Core, Working Draft — w3.org/TR/shacl12-core

5. W3C, SPARQL 1.1 Query Language, Recommendation, 2013 — w3.org/TR/sparql11-query

6. W3C, R2RML: RDB to RDF Mapping Language, Recommendation, 2012 — w3.org/TR/r2rml

7. W3C, JSON-LD 1.1, Recommendation, 2020 — w3.org/TR/json-ld11

8. ISO/IEC 39075:2024, Information technology — Database languages — GQL

9. ISO/IEC 24707:2018, Information technology — Common Logic (CL)

10. ISO/IEC 21838-2:2021, Top-level ontologies — Basic Formal Ontology (BFO)

11. ISO 25964, Thesauri and interoperability with other vocabularies; ISO/IEC 11179, Metadata registries

Literature

1. Codd, E.F. (1970), "A Relational Model of Data for Large Shared Data Banks", Communications of the ACM 13(6).

2. Chen, P. (1976), "The Entity-Relationship Model — Toward a Unified View of Data", ACM TODS 1(1).

3. Berners-Lee, T., Hendler, J. & Lassila, O. (2001), "The Semantic Web", Scientific American.

4. Guarino, N. & Welty, C. (2009), "An Overview of OntoClean", in Handbook on Ontologies, Springer.

5. Allemang, D., Hendler, J. & Gandon, F. (2020), Semantic Web for the Working Ontologist, 3rd edition, ACM Books.

6. Hogan, A. et al. (2021), "Knowledge Graphs", ACM Computing Surveys 54(4).

7. Noy, N. et al. (2019), "Industry-scale Knowledge Graphs: Lessons and Challenges", Communications of the ACM 62(8).

8. Suárez-Figueroa, M.C. et al. (2012), Ontology Engineering in a Networked World (the NeOn methodology), Springer.

9. Grüninger, M. & Fox, M. (1995), "Methodology for the Design and Evaluation of Ontologies", IJCAI Workshop on Basic Ontological Issues in Knowledge Sharing.

10. Lewis, P. et al. (2020), "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS — arXiv:2005.11401

11. Edge, D. et al. (2024), "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" — arXiv:2404.16130

Graham McLeod · Inspired.org