semantic modelling

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.