Building Shared Meaning - Get the Skills

Connect your people, your systems, your numbers and your AI

Every organisation I work with has the same problem wearing different clothes. The business means one thing, the systems mean another, the dashboards a third, and now the AI is confidently improvising a fourth. Shared meaning is the fix, and it is a learnable skill. Our course, Building Shared Meaning, runs in four weeks.

Training starts in just under four weeks, and deep discounts are available for early bookings. Details at the end of this article.

In earlier newsletters I set out what it takes to build shared meaning, and what it takes to turn that foundation into an ontology that AI agents can rely on. Several readers asked the obvious question: where do I, or my team, learn to do this? Building Shared Meaning is the first of our two courses and the one most people start with. It is five days, hands-on, and built for people who work between the business and solutions rather than deep in the technology.

Rather than walk through the timetable, let me show you where the skill pays off. There are five places, and you probably recognise all of them.

1. People and group communication

Most project failures are not technical. A business owner says "customer", an analyst hears one thing, a designer models another, the implementer builds a third, and the vendor's product assumes a fourth. Everyone is competent, everyone is using the same word, and nobody is talking about the same thing.

The course gives that conversation a discipline. You learn to:

• Start from the questions the business needs answered (competency questions), so the model is scoped by purpose rather than by argument

• Elicit, agree and record meaning in workshops with domain experts, in a form the business can read and the technologists can build from

• Build a governed vocabulary using SKOS, the Simple Knowledge Organization System: preferred terms, synonyms, broader and narrower concepts, agreed definitions

• Hold the line with vendors. When you can state precisely what your terms mean, you can test a vendor's model against yours, instead of adopting theirs by default

This is the part people undervalue until they have done it. A shared vocabulary does more for a programme than another round of requirements documents. It essentially provides the nouns for all the requirements and specifications that follow.

2. Communication across business silos

Finance, sales, operations, risk and compliance each have good reasons for their own definitions. The trouble starts when the numbers have to meet: "active customer", "revenue", "incident", "product".

Participants learn to map those differences rather than argue them away. You identify where concepts genuinely coincide, where they overlap, and where they only share a name. You then record the result as a model each silo can recognise itself in. Two techniques do the heavy lifting: conceptual modelling that stakeholders can read, and a canonical model with global identity, so that "the same thing" is the same thing wherever it appears.

It builds on the tools you already know. Entity-relationship modelling, UML, Relational Schemas and the patterns literature all come with us. We change the assumptions underneath them so the model can span silos instead of describing one.

3. Integration across applications

Legacy systems, in-house applications, web services, and packaged ERP each carry their own schema and  idea of what a record means. Point-to-point integration multiplies the translation problem with every connection you add.

A shared model changes the economics. Each system maps once to the common meaning, instead of to every other system. On the course you work through:

• How tabular and services data becomes a graph, including the mapping languages R2RML and RML and the thinking about identifiers and entity resolution behind them

• RDF (Resource Description Framework) and property graphs side by side, and how to choose between them. How to work with them using the query languages SPARQL and Cypher, and the new ISO standard GQL

• Reuse of existing standards, such as schema.org, Financial Industry Business Ontology (FIBO), gist Enterprise Ontology (Semantic Arts) and QUDT (Quantities, Units, Dimensions, Data Types), before you build anything yourself

You do not need to replace anything. The point is a layer of meaning that your existing estate can be mapped to.

4. Reliable business intelligence in real time, and support for compliance

This is the part of the course where analysts and BI practitioners get real value, and it is a deep session rather than an overview. The semantic layer is where governed metrics live: each measure defined once, tied to the model, and served consistently to every dashboard, report, query and application. When a metric is defined in one governed place, the argument about whose number is right stops being a weekly event.

You learn to define a governed metric, connect it to your BI tooling (the dbt Semantic Layer and Cube are the examples we use), and manage metric drift as the business changes. The same discipline serves real-time use: once the meaning is separated from the plumbing, a live feed and a monthly extract answer to the same definitions.

For regulated industries there is a second benefit. Banking, insurance, healthcare and pharmaceuticals are asked to show where a number came from, what it means and who owns it. Clear definitions, ownership, versioning and lineage are the raw material of that evidence, whether the driver is BCBS 239 on risk data aggregation, privacy law such as POPIA or the GDPR, or an auditor's questions. The course covers governance basics (naming, versioning, ownership), lineage and data products, and introduces SHACL, the Shapes Constraint Language, for validating data against agreed rules. A shared model does not make you compliant by itself, but it is hard to achieve compliance without one.

5. AI and agentic deployment at scale, with reliability

Large language models are fluent and, used alone, unreliable about your business. Retrieval over flat documents finds text that looks relevant. It cannot tell the model what your terms mean or how your entities relate. Ground the model in a governed graph and the picture changes: answers can be traced, terms are unambiguous, and an agent acts on definitions rather than guesses.

Course 1 gives you the foundation: why agents fail on flat data, how GraphRAG differs from vector retrieval in plain terms, and what a good ontology adds. It is an awareness-level introduction, deliberately. Building and proving the production ontology, enforcing rules and engineering the agent are the subject of Course 2, Engineering Reliable Agentic Automation. What Course 1 gives you is the thing Course 2 cannot do without: a domain you have scoped, a vocabulary you have governed and a model other people can trust.

One honest note. Most enterprises need a lot of vocabulary, canonical modelling and governed metrics, and only a small, careful amount of formal ontology. We teach it that way. The course also treats LLM-drafted ontologies for what they are: useful as an assistant, dangerous as an unreviewed author.

What you will leave with

Five days, about 36 contact hours, interactive throughout. No logic or programming background is needed, only comfort with data and business analysis. Over the week you move from why semantics matter and how graphs represent knowledge, through eliciting meaning and building a vocabulary, to reading ontologies, writing basic SPARQL, defining governed metrics and seeing how AI uses all of it.

You finish with your own semantic starter pack for a domain you care about: competency questions, a conceptual model, a governed SKOS vocabulary, a governed metric tied to the model, and a clean hand-off to the specialists who take it further. You also leave able to do what most organisations are short of: act as the semantic translator between the business and the technical teams.

The course is suitable for business and systems analysts, BI and data practitioners, architects, designers, domain experts, and anyone on the vendor or implementation side who has to make several parties mean the same thing.

Booking

The course starts in just under four weeks.

Deep discounts are available for early bookings, so if you are keen to join us, now is the time to act. Places are limited to keep the work hands-on.

Full details (coverage, timing, format, pricing, booking) here: https://www.inspired.org/course-1-build-shared-meaning

To ask whether it fits your team, or about special arrangements, contact us through inspired.org or message me directly. If several people in your organisation would benefit, we can talk about group arrangements.

References and standards

1. W3C, SKOS Simple Knowledge Organization System Reference, Recommendation, 2009 — https://www.w3.org/TR/skos-reference/

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

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

4. W3C, Shapes Constraint Language (SHACL), Recommendation, 2017 — https://www.w3.org/TR/shacl/

5. Basel Committee on Banking Supervision (2013), Principles for effective risk data aggregation and risk reporting (BCBS 239) — https://www.bis.org/publ/bcbs239.htm

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

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

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.

Closing the shared-meaning gap: what it actually takes

Last week's piece was about the problem: your data has structure but not meaning, and AI now acts on that gap at machine scale. This one is about the work. What should an organisation build, what skills does a data architect or analyst need, and which techniques, languages and standards should they use, in what order?

Start with a diagnosis, not a purchase

The most common failure in this field happens before any modelling starts. Someone says "we need a semantic layer", a vendor demonstrates one, and the budget goes on a tool aimed at a different layer from the actual problem.

Last week I described five senses of "semantic layer": a shared vocabulary, a canonical domain model, the analytics or metrics layer, the operational or integration layer, and formal ontology. The first skill is to tell them apart under pressure. When two dashboards disagree, is that a vocabulary problem (people mean different things), an identity problem (the same customer is four records), or a derivation problem (the same result calculated twice)? Each has a different fix and a different owner.

Two techniques make the diagnosis concrete.

• Map the domain as a graph. Sketch the ten to twenty things that matter as nodes and their relationships as named edges. Then mark where the current models let you down: meaning that lives only in a column label, identity that is local to one system, a missing row treated as "false", and schemas that are siloed or brittle

• Write competency questions. Before modelling, write down the questions the model must be able to answer, in business language, and agree them with the people who will ask them (Grüninger & Fox, 1995). They set the scope, they are your acceptance tests, and they stop the model growing to cover everything

None of this needs a tool. It needs someone who can facilitate a room full of people who each think their definition is the obvious one.

1. A governed shared vocabulary

This is the cheapest semantics that pays, and the step most often skipped because it looks too simple. Most "data quality" disputes are vocabulary disputes in a technical costume.

A governed vocabulary means every business term has a preferred label, a written definition, a named owner, its synonyms, and its place in a hierarchy. The skill is writing definitions that settle arguments ("a customer is a natural or legal person who holds at least one live product") rather than restating the word, and then running a change process that people actually use.

• SKOS — the Simple Knowledge Organization System (W3C Recommendation, 2009) is the standard way to publish it: concept schemes, prefLabel and altLabel, broaderand narrower, and mapping properties (exactMatch, closeMatch) for aligning two vocabularies that grew up apart.

• ISO 25964 covers thesaurus construction and interoperability; ISO/IEC 11179 covers metadata registries and how to name and define a data element properly.

• Tools range from a well-governed glossary in your data catalogue to dedicated vocabulary managers such as VocBench, PoolParty or TopBraid EDG.

One confusion is worth dealing with early: SKOS broader is not subclass of. "Espresso machines" can sensibly sit under "Coffee" in a navigation hierarchy, but a machine is not a kind of coffee. Vocabularies organise terms; ontologies make logical claims about things. Mixing them up causes trouble further on.

2. Thinking in graphs

This is the skill shift, and in my experience it is harder for excellent data modellers than for beginners, because their relational instincts are so practiced.

Entity-relationship modelling, UML and Information Engineering remain a solid foundation, and nearly all of it carries over. What changes is a small set of assumptions:

• Relationships are first-class. A relationship can carry its own properties, be queried directly and be followed across many hops

• Open world, not closed. In SQL a missing row means "no". In semantic systems a missing fact means "unknown". Queries, validation and reasoning all behave differently as a result

• No unique-name assumption. Two identifiers might denote the same thing unless you say otherwise. That is exactly the situation integration puts you in

The labelled property graph is the most accessible way to build this skill. It is close enough to relational thinking that a modeller is productive within a day, and it answers the questions relational databases handle worst, such as "every customer who bought a product made from this contaminated lot". Learn a repeatable recipe for translating an ER model into a graph, and the patterns that separate a good graph from a relational schema with arrows on it: model facts as relationships rather than string properties; promote a property to a node when you need to query or relate it; use intermediate nodes for facts involving more than two things.

The languages are Cypher (openCypher, as in Neo4j and others) and now GQL — the Graph Query Language (ISO/IEC 39075:2024), the first new ISO database query language since SQL. SQL/PGQ (part of ISO/IEC 9075:2023) brings graph pattern matching into SQL itself.

3. A canonical model on global identity

A property graph fixes connection. It does not, on its own, fix meaning across systems, because its node identifiers are still local to one database. The step that turns a data model into an interoperability layer is global identity.

• RDF — the Resource Description Framework reduces everything to the triple (subject, predicate, object) and names things with IRIs — Internationalized Resource Identifiers. Two systems that use the same IRI are making the same claim about the same thing, and their graphs merge without any mapping code. RDF 1.1 (2014) is the current Recommendation; RDF 1.2 reached Candidate Recommendation in April 2026.

• RDFS — RDF Schema adds classes, properties and hierarchy. The classic trap: rdfs:domain and rdfs:range infer types; they do not constrain data. A modeller who expects them to behave like foreign keys will be surprised

• Reuse before you invent. schema.org, FIBO (the Financial Industry Business Ontology), SNOMED CT, QUDT for units, DCAT for datasets and PROV-O for provenance already cover much of what enterprises model from scratch. Evaluating a standard is its own skill: is it good as a vocabulary, as logic, or both?

• Lift the estate you already have. R2RML (W3C, 2012) and RML map relational and file-based sources into the canonical model declaratively, without rewriting the sources

• SPARQL queries the result and, with SERVICE, runs one query across graphs held by different organisations without copying the data

The architectural pay-off is a hub. n systems integrated point to point need up to n(n−1)/2mappings, each with its own quiet assumptions. With a canonical model, each system maps once, to the hub.

Should it be RDF or a property graph? Increasingly the answer is both, with a bridge between them: property graphs for connected operational workloads, RDF where identity, reuse and meaning have to travel. The skill is choosing per use case rather than per ideology.

4. Formal meaning, in proportion

OWL 2 — the Web Ontology Language (W3C, 2012) lets you say what terms necessarily mean, in a form a reasoner can check and draw conclusions from. It is powerful and, as I argued last week, often the most over-applied technique on the map.

For most practitioners the skill needed is reading, not engineering: understand classes, properties and restrictions; know the difference between a primitive class (necessary conditions only) and a defined class (necessary and sufficient, so a reasoner can classify into it); and predict what a reasoner will and will not infer

Visual notations help analysts here. G-OWL (Héon & Paquette) is a complete visual syntax for OWL 2, so a diagram round-trips to Turtle (RDF serialisation) and back, and VOWL offers a lighter-weight view. Both let a domain expert check a formal model as easily as an ER diagram.

The warning from last week still applies. A language model will draft you an ontology in minutes. Without competency questions, analysis and validation, you get a vibe ontology: fluent, plausible and unverifiable. We can use LLMs to do the grunt work, but we need to validate and then verify.

5. Governed metrics: the analytics semantic layer

Everyone agrees what a customer is, but two dashboards still disagree on the count, because the calculation lives in two places. This is metric drift, and it has a boardroom cost.

The fix is to treat a metric as a contract: defined once, with its entities, dimensions, measures, time grain, owner and version, and then served headlessly, so the dashboard, the notebook and the agent all call the same definition instead of reimplementing it. The tools include the dbt Semantic Layer (MetricFlow), Cube, AtScale and LookML.

The link to the earlier steps is what makes this work. A metric's dimensions should come from the governed vocabulary, and its grain from the canonical model. A metrics layer over four unreconciled customer records computes flawlessly and is still wrong.

6. Data products, contracts and governance

Meaning does not stay shared on its own. In a decentralised estate it needs structure:

• Data products with semantic contracts. Data mesh's four principles (domain ownership, data as a product, self-serve platform, federated governance) depend on semantics as their connective tissue. A product's "order" should be the canonical model's Order, with its real relationships intact

• Naming, versioning and stewardship. Conventions people can follow; deprecation rather than deletion; and distinct roles for who defines a term, who owns the data and who approves change

• Lineage and provenance. Metric-level impact analysis ("what breaks if we change active customer?"), recorded in a standard way with PROV-O — the PROV Ontology

• Validation at the boundary. The model can stay open-world while data entering a product is checked closed-world. SHACL — the Shapes Constraint Language (W3C, 2017; 1.2 in draft) is the standard for that. OWL says what things are; SHACL says what a valid record looks like

The human side matters as much as the apparatus. A lightweight change process that people use beats a thorough one they avoid.

7. Grounding AI

An agent working over raw tables has no stable notion of an entity, invents joins, and delivers wrong answers with full confidence. Everything above gives it something firmer to stand on: entities with global identity, governed definitions it can call, and paths it can follow and explain.

Practitioners need to understand the retrieval options well enough to choose between them. RAG retrieves text chunks by similarity. GraphRAG retrieves over a knowledge graph, so the answer follows real relationships. KAG (knowledge-augmented generation) goes further, reasoning over the graph's structure and logic. A graph earns its place over a vector index when the question depends on relationships, identity or rules rather than on finding similar text.

Shared meaning is the prerequisite for reliable AI, not the polish on it.

Putting it together: a minimum viable kit

An organisation does not need all of this at once. It needs a small, coherent starting point that the next team can build on. In practice that is five artefacts for one domain, each of which feeds another:

• A governed vocabulary, which names the model's entities and supplies the metric's dimensions

• A canonical model, which sets the metric's grain and supplies the data product's entities

• One governed metric, wired to the model

• One data product with a stated contract

• A one-page governance note that gives each an owner, a version and a change process

Add the competency questions the kit can now answer, so whoever picks it up knows what it is for and can test it. That is a defensible first rung, not a half-built system. The next rungs are formal rigour on the model, SHACL validation against real data, and agents that act on the graph. They cost more, and each stands on the one below.

The skills, in one place

Taken together, this describes a role many organisations already need but rarely name: a semantic translator between the business and the data and AI teams. The profile is:

• Diagnosis: placing a problem on the right layer, and saying so to a sponsor

• Elicitation: competency questions, and definitions that settle arguments

• Modelling: ER and UML fluency, plus graph thinking and the open-world gear-change

• Standards literacy: SKOS, RDF, RDFS, SPARQL, Cypher and GQL at working level; OWL and SHACL at reading level

• Analytics: governed metrics and a headless semantic layer

• Governance: ownership, versioning, lineage and data contracts

• AI literacy: why grounding matters and which retrieval pattern fits which question

Most of it needs no formal logic at all, and it returns most of the value.

How we're approaching it

This is the ground we built our training pathway around. It has two courses, under one line: Build Shared Meaning Today to Engineer Reliable Agentic Automation Tomorrow.

Course 1 — Building Shared Meaning is for analysts, BI practitioners, data modellers and domain experts, and needs no programming or logic background. Over four and a half days it works through capabilities 0 to 6 above at hands-on depth and 7 at awareness level: diagnosis and domain mapping; property graphs with Cypher and GQL; a governed SKOS vocabulary; RDF, RDFS, reading OWL through G-OWL, and SPARQL; governed metrics in dbt and Cube; data products, governance and lineage; and the connection to AI. Each day produces one artefact of the minimum viable kit, and participants leave with the whole kit built for a domain of their own.

Full details here: https://www.inspired.org/course-1-build-shared-meaning

Course 2 — Engineering Reliable Agentic Automation takes the upper rungs: formal rigour, SHACL validation, the operational layer and grounded agents. More on that in the next post.

References and standards

1. W3C, SKOS Simple Knowledge Organization System Reference, Recommendation, 2009 — https://www.w3.org/TR/skos-reference/

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

3. ISO/IEC 39075:2024, Information technology — Database languages — GQL; ISO/IEC 9075-16:2023, SQL/PGQ

4. W3C, RDF 1.1 Concepts and Abstract Syntax, Recommendation, 2014 — https://www.w3.org/TR/rdf11-concepts/ · RDF 1.2 Concepts and Abstract Data Model, Candidate Recommendation, April 2026 — https://www.w3.org/TR/rdf12-concepts/

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

6. W3C, SPARQL 1.1 Query Language and Federated Query, Recommendations, 2013 — https://www.w3.org/TR/sparql11-query/ (SPARQL 1.2 in Working Draft)

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

8. Héon, M. & Paquette, G., "G-OWL: A Complete Visual Syntax for OWL 2 Ontology Modeling and Communication", Semantic Web journal — semantic-web-journal.net

9. W3C, Shapes Constraint Language (SHACL), Recommendation, 2017 — https://www.w3.org/TR/shacl/ (SHACL 1.2 in Working Draft)

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

11. dbt Labs, dbt Semantic Layer / MetricFlow — docs.getdbt.com · Cube — cube.dev/docs

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

13. Dehghani, Z. (2022), Data Mesh: Delivering Data-Driven Value at Scale, O'Reilly.

14. Robinson, I., Webber, J. & Eifrem, E. (2015), Graph Databases, 2nd edition, O'Reilly.

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

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

17. Liang, L. et al. (2024), "KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation" — arXiv:2409.13731