Ontologies without the academic fog

At the Blouberg Infrastructure Programme, a fictional public infrastructure programme with about forty construction sites, three teams use the phrase "milestone complete" every week. The site engineer means the works are physically finished. The contracts team means a payment certificate has been issued. Finance means the money has been paid. All three are right within their own work, and for years the difference only caused the occasional awkward meeting. (The programme's people, systems and figures are illustrative.)

Then the programme's assistant began answering "Is milestone 3 on Site 14 complete?" It drew on all three teams' documents and blended them. On one day it said yes because a site diary recorded completion; on another it said no because the payment had not cleared. Both answers were defensible, and neither told the user which meaning it had used.

When Lindiwe Mokoena's team proposed fixing this with an ontology, the first workshop went badly. Someone presented a slide on description logics, someone else asked whether a milestone is an event or a state, and after two hours the group had agreed on nothing. The problem was not the idea. It was the fog around it.

What an ontology is, in one paragraph

For a delivery team, an ontology is a written agreement, readable by people and machines, about five things: the kinds of thing that exist in a domain (contractor, site, milestone, payment certificate), the relationships between them (a certificate certifies a milestone), the definitions that tell you what each term means and does not mean, the identifiers that name each thing uniquely, and the rules that valid data must satisfy (on Blouberg's milestone-based contracts, a certificate certifies exactly one milestone). That is all. The academic literature is large because the general problem is hard. The problem of agreeing what a milestone is at one programme is much smaller.

The semantic layer is your hallucination control makes the case that definitions are runtime infrastructure for AI. This article is about how to write them in a form an assistant can use, without starting a research project. It sits on the second rung of the ladder in No AI without information architecture, the one that decides whether answers can be trusted.

Five levels, adopted one at a time

The fog clears when you see that an ontology is the top of a ladder, and most of the value comes from the lower rungs.

1. Glossary. Terms with plain-language definitions and an owner. A spreadsheet is fine.

2. Controlled vocabulary. Each concept has one preferred label, its accepted alternative labels and a stable identifier. The W3C's SKOS (a Recommendation of August 2009) is the standard way to publish this, and it covers level 3 as well: concepts with prefLabel and altLabel here, broader and narrower for the taxonomy below, and mappings such as exactMatch and closeMatch to other vocabularies. SKOS itself says it is "not a formal knowledge representation language", which is precisely why it is a comfortable place to start.

3. Taxonomy. Concepts arranged in broader and narrower relationships, expressed with SKOS broader and narrower: a culvert is a kind of drainage structure, which is a kind of civil structure. Useful for search and for rolling up reports.

4. Ontology. Classes, properties and relationships with formally defined meaning, typically in the W3C's OWL 2 (Second Edition, December 2012). This is where you say that a payment certificate certifies a milestone, which belongs to a contract, which is held by a contractor.

5. Shapes and constraints. Rules that data must satisfy, checked automatically. The W3C's SHACL (a Recommendation of July 2017) is "a language for validating RDF graphs against a set of conditions". If your data is not in RDF, the same rules can live in database constraints or validation code.

You do not need RDF for levels 1 to 3. A well-kept table of concepts, labels, identifiers and parents gives most of the benefit. Move up only when a question requires it, which is the same discipline as the graph ladder in Part 2.

Start from questions, not from the domain

The workshop failed because it started from the domain: what exists in infrastructure delivery? That question has no end. Ontology engineers have long recommended starting instead from competency questions, the specific questions the ontology must be able to answer, an approach set out by Michael Grüninger and Mark Fox in a 1995 paper from the University of Toronto's Enterprise Integration Laboratory.

Blouberg's second workshop began with ten questions taken from the assistant's logs and the regional manager's inbox:

1. Is milestone 3 on Site 14 complete, in each sense?
2. Which milestones have certificates but no verification inspection?
3. Which contractor holds the contract for a site, including joint-venture partners?
4. Which variation orders changed a milestone's scope, and when?
5. Which inspections recorded defects that are still open?
6. Which drawings are current for a structure?
7. What was paid against a contract in a financial year?
8. Which sites are behind their current programme date?
9. Which inspectors are qualified to verify which kinds of work?
10. Which payment certificates were issued before verification?

Every term in the ontology had to earn its place by appearing in an answer to one of these. Anything else waited. The result was nine classes and fourteen relationships, which fitted on one page.

Define states, not just words

The "milestone complete" argument dissolved when the team stopped trying to agree on one meaning and modelled the milestone's lifecycle instead. A milestone passes through distinct states, each recorded by a different team in a different system:

• Works complete: the site engineer records it in the site diary.
• Verified: an inspection confirms the works meet the specification.
• Certified: the engineer issues a payment certificate.
• Paid: finance records the payment.

"Complete" became an alternative label that the assistant must not resolve silently. When a user asks whether a milestone is complete, the assistant now answers with the state it has reached, the date of each state change and the system that recorded it, and says which meaning the user is likely to need if the question makes it clear. The definitions sit in the controlled vocabulary; the states and the transitions between them sit in the ontology; and three rules sit in the constraints:

• on Blouberg's milestone-based contracts, a payment certificate certifies exactly one milestone on exactly one contract;
• a milestone cannot be certified before it is verified, unless a recorded exception exists; and
• a verification inspection must be carried out by an inspector qualified for that kind of work.

The second rule found eleven historical certificates issued before verification. Most had documented exceptions. Three did not, and they went to the contracts manager. That is a typical result: writing the rules down finds problems the data already had.

Who owns a definition

Definitions change, and an ontology without owners decays as fast as any other document. Blouberg assigned ownership by concept, not by system:

• The contracts manager owns milestone states, certificates and variation orders.
• The finance lead owns payment terms.
• The chief engineer owns structure types and inspection classes.
• The programme management office owns the ontology as a whole: its versioning, publication and change process.

Changes go through a short request: what is changing, which competency questions it affects, and from which date it applies. Each version of the ontology is kept, because answers given under an old definition must remain explainable. Part 5 shows how the version is recorded with each answer.

How the assistant uses it

An ontology that sits in a repository does nothing. Blouberg's assistant uses it in four places:

• Query planning. Identifiers and terms in a question are resolved against the vocabulary, so "the Site 14 culvert" and "structure CV-14-02" are recognised as the same thing.
• Search expansion. Alternative labels feed lexical search, so a question using a contractor's informal abbreviation still matches documents using its full name, complementing the techniques in Hybrid search in plain language.
• Answer structure. Answers use preferred labels and state which definition or state they report.
• Validation. Before facts extracted from documents are used, they are checked against the constraints. An extracted claim that a certificate certifies two milestones is rejected and routed for review.

Failure modes

• Boiling the ocean. Modelling the whole domain before answering any question. Start from competency questions.
• Importing a giant upper ontology. Adopting a general-purpose model with thousands of classes that nobody on the team understands. Reuse small, well-known vocabularies where they fit, and map to larger ones later with exactMatch or closeMatch if you need to.
• Letting a model write it unreviewed. Language models can draft definitions and suggest relationships quickly, and that is a reasonable use. The owner still decides, because a definition is a governance decision, a point also made in AI projects expose weak data ownership.
• No versions. Changing a definition in place, so past answers can no longer be explained.
• No path into the assistant. An ontology that the assistant does not read at run time is documentation, not infrastructure.

A checklist

1. Collect ten competency questions from real users and logs.
2. Write a glossary for every term those questions use, with an owner per term.
3. Turn ambiguous terms into states with transitions, and record which system holds each state.
4. Publish a controlled vocabulary with identifiers and alternative labels.
5. Add classes, relationships and constraints only where the questions need them.
6. Version every change and record the effective date.
7. Wire the vocabulary into query planning, search, answers and validation.

Key points

• An ontology is a written, machine-readable agreement about things, relationships, definitions, identifiers and rules.
• Most of the value sits in the lower levels: glossary, controlled vocabulary and taxonomy. Move up only when questions require it.
• Start from competency questions, and let every term earn its place.
• When teams disagree about a word, model the states and say which one an answer reports.
• Owners, versions and a path into the assistant at run time are what make an ontology useful.

Next: Part 5, Data lineage for AI answers. All parts are on the series page.

How CloudNala can help

CloudNala runs short, question-led ontology sprints. We gather competency questions from your users and logs, facilitate the definition and ownership decisions with the teams who hold each fact, model the states behind your most ambiguous terms, and deliver a versioned vocabulary and constraint set that your assistant reads at run time, sized to the questions you have rather than to the whole domain.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book a Knowledge Architecture Review or write to us at consult@cloudnala.co.za