How do I build an ontology for AI?

Connecting up your organisation’s knowledge to a reliable AI service usually requires the design and implementation of an ontology. An ontology is a way of mapping and organising your knowledge so it becomes something that a machine can ingest. It sets out what the things that matter in your business mean precisely, and how they relate to one another, enabling AI to reason within the constraints you set.

While ontology-as-a-service platforms can now automate much of the technical development work, humans in the loop are still needed to agree on the definitions, rules and boundaries that structure the data and govern what the AI does. So get started by following 5 essential steps.

1) What is your objective?

You might dream of building an ontology for your entire organisation in one swoop – but you need to start small. Choose an objective that is very narrow, achievable in the timeframe of a pilot, and valuable in a measurable way. Think low-hanging fruit. Using approach enables you to familiarise your team with the basic concept of structuring knowledge, and demonstrating to them that it is worthwhile by having it deliver them something that they find helpful.

The best ontologies start small, then grow organically. Getting your team involved in the design and implementation of your ontology from the outset helps to give them a sense of ownership that spurs adoption. It also deters you from making poor assumptions about what your team wants or needs.

2) What are the things that deliver the objective?

The second step is to identify the things you need to reach your objective. In other words, these words are concepts, or kinds of things. In a business, they can be anything from ‘supplier’, to ‘invoice’, to ‘raw material’. To be clear, we don’t need to know who the individual suppliers are at this point, for example, just that the notion of a supplier exists and that they matter in the delivery of the objective.

In traditional ontology language, which can feel intentionally confusing sometimes, these things are often referred to as classes, sub-classes, or objects. Ontologies usually include synonyms, meaning words that mean the same thing.

Traditional ontology language can feel intentionally confusing sometimes.

3) Agreeing on meanings

Once you’ve got all the things you think you need, it’s time to define precisely what the things mean. Precision is key here because AI trips up on semantics all the time. It gets confused by the subtle ways in which the meanings of words are affected by their context, otherwise known as polysemy.

It’s perfectly okay for an important word like customer to mean two different things in your organisation, for example, but those multiple meanings do need to be recorded. The classic example is the concept of ‘customer’, which might be defined by the finance department as someone who pays an invoice, but which to the marketing department might refer people who sign up to a free app, and who therefore do not necessarily pay an invoice.

This sort of unrecorded tacit knowledge living in your experts’ heads is extremely valuable to your business, so it’s worth getting it written down in digital form because it retains that value should your experts depart. Making implicit knowledge explicit, and therefore machine-readable, enables AI to eventually automate a whole range of tasks at scale.

4) Rules and relationships

The big difference between a simple taxonomy or controlled vocabulary, and an ontology, is that the ontology captures how things in the domain relate to one another. In ontology-speak these connections are sometimes called object properties.

For example, if you had a healthcare domain, your ontology might connect up two different concepts – doctors and cardiologists – and set a rule that all cardiologists are doctors. So if someone queries whether Bob is a doctor, the AI can answer that yes he is, even though he is on the cardiologist database and not listed explicitly as a doctor. It can also set out how it inferred the answer, should the user (or perhaps an auditor) wants to verify the steps by which the answer was reached.

Formally defining the relationships between things in a domain is crucial because – as illustrated above – it enables AI to infer new knowledge from existing documentation according to rules set by you, thereby making its outputs more insightful and reliable. Anchoring an LLM or AI in verified enterprise meaning is sometimes referred to as grounding.

Enabling natural language queries of your company’s knowledge store, and receiving explainable answers that can be verified, is a powerful benefit of the ontological approach that a simple LLM alone cannot deliver in high-stakes domains.

5) Ontology software

Building an ontology might sound daunting and technically complex. But it can be made significantly easier and faster by using a modern ontology-as-a-service platform. They can provide consensus-building techniques to get agreement within your organisation on the rules and definitions that matter most. They can also enable that knowledge to be operationalised and put to work delivering value.

By taking baby-steps, one small objective at a time, you can organically structure and verify your organisation’s knowledge store, so that it becomes a powerful asset to drive human productivity and enable automation at scale.