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 rules and 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 that we have developed to push a working ontology over the line.
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 this approach enables you to familiarise your team with the basic concept of structuring knowledge, and demonstrate its usefulness.
The best ontologies start small, then grow organically. Getting your team actively involved in its design from the outset, helps give them a sense of ownership that will spur 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 – or kinds of things – you need to reach your objective. In a business, they can be categories such as ‘supplier’, or ‘invoice’, or ‘raw material’ – but not the actual names of the individual suppliers or raw materials yet.
We just need to agree that the notion of a supplier exists, say, and that they matter in the delivery of the objective. In traditional ontology language, which can feel intentionally confusing sometimes, these categories are called classes or objects, while the things that go into each category are called instances.
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 concept of customer might be defined by the finance department as someone who pays an invoice, whereas the marketing department might use the same word to identify 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 in case your experts depart and take that valuable knowledge with them. 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, far beyond a simple hierarchy. 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. The AI 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.
Structured knowledge does not walk out the door.
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 a large language model (LLM) or AI in verified enterprise meaning in this way, is sometimes referred to as grounding.
Enabling natural language queries of your company’s knowledge store, and receiving explainable answers that don’t change every time you ask them, 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 measurable value.
By taking baby-steps, one small objective at a time, you can organically structure, verify and grow your organisation’s knowledge store, so that it becomes a powerful asset, driving human productivity and enabling automation at scale.