How to Scope an Ontology So It Actually Ships
Key takeaways
- Start from one decision the business already argues about. A domain has no edge; an argument does.
- The competency questions are the scope. Anything they do not require stays out.
- Ship against one real consumer and let it tell you what is missing. Completeness will not.
- Both failure modes are real: modelling everything kills the project, and modelling too little produces something nobody can extend.
Knowing how to scope an ontology is the difference between something that actually ships in six weeks and a modelling project quietly wound down in its second year. The scoping decision gets made early, usually without much deliberation. Almost everything else follows from it.
The instinct that kills these projects is easy to state: before we can use AI, we need to model the enterprise. That turns business context into a multiyear documentation exercise, and a competing vendor put it almost exactly that way in print. They are right. This is the rare argument where the loudest opposing position and ours describe the same failure. That makes the method below harder to dismiss than any capability claim would be.
Why do ontology projects die in year two?
Four things are worth conceding before any method. A reader who has lived through one of these will not take advice from a page that pretends they do not happen.
Teams model everything before shipping anything. Because the model describes reality, the temptation is to describe all of it. Those projects tend to die after a year. The practitioners documenting this are inside the discipline, writing about their own field.
The translation gap is real. Ontology engineers know the formalism but not your business. Subject matter experts know the business but not formal modelling. Nothing in the tooling closes that, and it is a genuine structural cost of the consulting-led shape this work usually takes. TopQuadrant sells into exactly that motion, so there is no point pretending otherwise.
The organizational incentive is to freeze definitions. Changing one in production hurts, so nobody changes it, and the model slides into documentation. Keeping it current is a discipline in its own right for this reason.
Precision and universality cannot live in the same artefact. As one practitioner put it, the physics will not allow it. Every attempt at a model that is both computationally precise and universally applicable has failed, or survived by becoming so general that each domain has to do the real work anyway.
None of that is an argument for not building one. It is an argument about size.
How do you scope an ontology? Six steps
1. Start from one decision the business already argues about. A domain is the wrong starting point, because a domain has no edge. Customer data could mean nine things, and it will expand to fill whatever time you give it. An argument has an edge. If two teams have spent this year disagreeing about which accounts count as active, that disagreement names the concepts worth formalising and tells you when you are done. Pick the argument that has already cost two meetings.
2. Write the competency questions first. The questions the model must answer are the scope. Which accounts were active in Q3 under the revenue definition? Which trials used a site that later failed inspection? Write ten or fifteen of them, get them agreed, and treat them as the boundary. Anything the questions do not require is out, and stays out, including things that are obviously related and would only take an afternoon.
3. Model only the entities those questions traverse. This is the step where projects quietly triple in size. You model account, and then it seems negligent not to model contract, and contracts have terms, and terms reference products. Each addition is individually reasonable and collectively fatal. If a competency question does not walk through an entity, it does not go in this iteration.
4. Constrain before you extend. A small model with SHACL shapes on it is usable by another system. A large model without them is a diagram with good intentions. Constraints are also what surface the disagreements you thought you had settled, which is cheaper to discover at twenty classes than at two hundred.
5. Ship it against one real consumer. An application, an agent, a report. Something with users who will complain. Then let that consumer tell you what is missing, because extension driven by a real consumer is bounded and extension driven by completeness is not. This is also the only reliable test of whether the agreement in step 1 was genuine or merely polite.
6. Add the second decision only once the first is in production. One at a time. No rip and replace. No parallel track. No retrofitting a general structure over the first one now that you can see how it should have been done.
Which practices keep scope from growing back?
Name an owner for the scope before naming an owner for the model. These are different jobs. The scope owner's entire function is to say no to reasonable additions. That is much harder when the same person is responsible for the model being good.
Reuse a published model where one fits. Most domains have had their core concepts modelled competently by somebody already, in standards bodies, industry consortia or open vocabularies. TopQuadrant ships 300+ prebuilt models for this reason. Starting from an existing one and cutting it down is usually faster than authoring from nothing. It also moves the argument from what should the concepts be to which of these do we need. That is a much more tractable conversation.
Set a ship date in weeks and treat scope as the variable, never the date. A date that moves is not a constraint, and without a constraint step 3 reasserts itself. Six weeks with a smaller model beats six months with a better one, because the smaller model generates the feedback that tells you what better would even mean.
Record what was decided, as well as what was modelled. The class definitions capture the outcome. What gets lost is who agreed, what the alternative was, and why it was rejected. That is exactly what you will need the first time somebody reopens it.
What are the failure modes on the other side?
Scoping advice usually stops at "start small", and that is incomplete to the point of being misleading.
Start too small and you build something nobody can extend without redoing it. Both failure modes sit in the same practitioner account. On the one side: "I tried to design the perfect ontology before touching any real data, and I froze. Every solution I started stayed on my laptop and was never used. I was deadlocked, bringing 0 value." And the reply that gets it right: "starting ugly and patching the ontology from real data beats designing the perfect graph in a vacuum."
The resolution has nothing to do with size. The base has to be extensible in the direction you will actually extend. That is why steps 1 and 2 are about the decision and its questions, and never about a count of classes. A model scoped to a real argument extends toward adjacent arguments. A model scoped to an arbitrary subset of a domain extends toward nothing in particular.
A starter kit can cost more than it saves. Pre-canned templates that reduce an ontology to a handful of generic node labels will get you running quickly, and in an organization that already uses formal ontologies they add a classification system that may conflict with the upper ontologies already in place. A graph vendor shipping one of these names that conflict in its own documentation. It is worth taking seriously: a starter kit is a good way to begin and a poor thing to inherit.
Beware the completeness review. The request to "make sure we have not missed anything" before shipping is reasonable, well-intentioned, and the mechanism by which step 3 happens after you thought you had prevented it. The answer is that you have certainly missed things, that the consumer in step 5 will identify which of them matter, and that the ones nobody notices were never in scope.
| Failure mode | What it looks like | The scoping move that prevents it |
|---|---|---|
| Model everything first | Two years in, a complete model and nothing in production | Scope to one contested decision, not one domain |
| Model too little | A base nobody can extend without redoing it | Extensibility in the direction you will actually extend, set by the competency questions |
| Generic starter kit | An ontology reduced to a handful of node labels, conflicting with models already in use | Extend a published standards-based model instead |
| The completeness review | A reasonable request to check nothing is missing, which reopens scope | Agree before you start that the questions define done |
| No owner for the scope | Everyone adds, nobody removes | Name the scope owner before the model owner |
What a shipped scope has to stay connected to
- The consumer that justified it. If no application or agent resolves against the model, the scope was theoretical.
- The data it constrains, through SHACL shapes, so the model is checkable.
- The people who agreed it. Each definition carries who proposed it, who approved it and when. That review trail is what makes the next extension an amendment.
- The models it overlaps. Two domain ontologies disagreeing about a shared concept is worse than one that is incomplete.
Those connections are also the argument for open standards over a modelling tool's native format. A model expressed in RDF, OWL, SKOS and SHACL can be read by the next system and the next team, so a scoping decision taken this quarter does not become a re-authoring project after a platform change. Reuse works for the same reason: TopQuadrant's 300+ reusable models exist because standards-based models can be loaded and extended.
Scope is not a compromise on ambition. It is the only version of this work that reaches production, and what happens after it ships is ontology management, run on a platform built for it.
