What a good ontology project leaves behind

An ontology project has one end state that is very easy to accept: a diagram, a glossary of terms and a well-argued document. It looks like a result, it gets through the steering committee and it matches the acceptance criteria.

Six months later nothing uses it, the definitions have drifted away from reality, and the next project starts from the beginning — often with the same diagram attached.

Why a document passes acceptance so easily

Acceptance criteria are usually written as a list of deliverables: model, glossary, documentation. Each can be checked by opening a file. Whether something runs on the model, and whether somebody will maintain it, is harder to check, so those criteria are usually missing from the contract.

Yet they are the ones that decide whether an ontology lives. A model nothing consumes is a document, and it decays like a document: quietly and without a date.

What should remain

Something that uses the model. The most important criterion: retrieval, an agent or a report running on the model before the project ends. It is the only proof that the definitions survived contact with real data.

Identity rules. How to recognise the same customer across three systems. Usually the hardest and most valuable part; if it is not in the acceptance, you have bought a glossary, not an ontology.

Mappings, gaps included. How each source system maps onto the model, including where it cannot and what is lost. A mapping without a single gap is suspicious.

A portable form. The model expressed in a standard form — for ontologies that means, for example, the W3C standards RDF and OWL — rather than trapped in one product. The store is a separate engineering decision and may still change.

Governance. An owner for every definition and a described path for proposing changes. Without it the model is accurate for one quarter.

Infographic

What a good ontology project leaves behind

1. 01Something that uses itRetrieval, an agent or a report running on the model within weeks.
2. 02GovernanceAn owner for every definition and a path for proposing changes.
3. 03Mappings and gapsHow each system maps onto the model, and what is lost.
4. 04Implemented modelEntities, relationships, constraints and identity rules in a portable form.
5. 05Agreed definitionsThe concepts the business runs on, disputes settled rather than averaged.

Warning signs in the proposal

A scope of “the whole enterprise”. A complete enterprise ontology takes years and usually never finishes. A proposal that promises one is selling a well-known failure mode.

The tool before the model. If the first line item is buying a graph database or a platform, an engineering decision has been made before the problem was understood. Plenty of ontologies are well served by a relational store with a semantic layer.

No use case. Without one or two concrete applications there is no way to know which concepts to model, so everything gets modelled.

Nobody on your side named. A proposal that does not ask who will settle disputes and who will own the definitions assumes the supplier can do both. It cannot.

Acceptance based on a document. If the acceptance criterion is an approved diagram, that is exactly what you will get. Acceptance criteria are written at the start of a project, not at the end, while they can still be changed without renegotiation.

What stays on your side

A good ontology project does not end in dependence on the supplier, but it does not end without work on your side either. It is worth knowing in advance what that work is.

Change requests. The business changes: a new product line, an acquisition, a new sales channel. Each change touches definitions, and the definition owner needs time to consider the request before the systems start drifting apart.

New systems. Every system being introduced should be mapped onto the model before it starts producing data. That is far cheaper than mapping it a year later, once its conventions have spread.

A review of the gaps. Every so often it is worth returning to the list of things lost in mapping and checking whether any of them has started to cost money.

It is a small effort, but it has to be somebody’s job. A model without a custodian reverts to being a document within a few quarters.

The acceptance question

Ask for two things. Show me how the system recognises that these two records from different systems are the same customer. And tell me who changes that rule if it turns out to be wrong.

If both answers come quickly and concretely — with a working example and a name — the project has left something alive. If the first requires opening a document and the second requires calling a meeting, you have bought a description.

A useful core model for one or two use cases in ontology design and engineering is typically four to eight weeks including implementation — and it ends with something already using the model, not with the model alone.