Production ontologies do not evolve like private database schemas. Once another system has stored your identifiers, inferred over your axioms, or validated data against your shapes, the ontology is no longer only your model.
That changes the engineering rule. Add freely, deprecate explicitly, migrate deliberately, and version the contract that consumers actually depend on.
The hard part is not naming a new class. The hard part is keeping old data intelligible while the meaning gets sharper.
The identifier is the promise
In a private application schema, a bad column name can be hidden behind a migration and a release note. In an ontology, a class or property IRI can leak into stored data, dashboards, validation rules, notebooks, exported files, and integration code. Once that happens, deleting the term or reusing it for a sharper meaning breaks more than a query.
This is why stable identifiers are the hardest promise in ontology work. The IRI is not just a lookup key. It is the thing other systems use to say, "this is the concept I meant."
OWL makes that promise more formal. The OWL 2 structural specification separates an ontology IRI from a version IRI, so an ontology series can have a current identity and exact version identities. That distinction is practical, not academic. Most consumers want the current ontology most of the time. Reproducible systems need to say exactly which ontology they built against.
The OBO Foundry versioning principle puts the same point in operational terms: users need to specify which ontology files encoded their data or applications, and they need unchanged copies to remain available. In production, version history is not a courtesy to future readers. It is part of the dependency contract.
Additions are not always harmless
The cheap evolution path is additive. Add a new class. Add a narrower property. Add a shape for a newly supported producer. Avoid breaking old data.
That instinct is right, but it is incomplete. An additive OWL axiom can change inferred classifications. A new domain or range statement can alter what a reasoner concludes about existing data. A new SHACL requirement can make producers fail even when the RDF vocabulary still looks backward compatible.
SHACL is worth treating as a first-class part of the contract for exactly this reason. It validates RDF data graphs against shapes graphs. If an old producer submitted conforming data yesterday and fails today, the production contract changed, even if no class IRI was removed.
I think this is where ontology-backed systems inherit the worst habits from both schema management and knowledge modelling. The schema side can underestimate meaning because the diff is syntactically small. The modelling side can underestimate operations because the new term is more correct. Production cares about both.
Deprecation is not deletion
A production ontology needs a graveyard that is still readable.
If a term is wrong, obsolete it. Do not make it disappear. Mark it deprecated, remove or weaken the logical axioms that would keep driving new conclusions, and point consumers toward the replacement or the caveat. The OBO obsoletion guidance describes this pattern with owl:deprecated and structured metadata such as replacement or consideration links.
That trail matters for humans and machines. A migration tool can follow it. A curator can explain why old data says approvedBy when the current model distinguishes technicallyApprovedBy, riskAcceptedBy, and legallySignedBy. A dashboard owner can decide whether an obsolete term should still count in a historical chart.
Deletion gives future systems a mystery. Deprecation gives them a map.
Test the questions, not only the files
Version IRIs and deprecation metadata are necessary, but they do not prove compatibility. The release has to be tested against the things downstream systems do.
For an ontology-backed production system, I would want a change review to include at least five fixtures:
- representative stored data from the previous release
- inference output before and after the change
- SHACL validation results for existing producers
- important SPARQL queries or application queries
- dashboards or integrations that bind to specific terms
This catches the failures that a vocabulary diff misses. A class can still exist while a dashboard goes empty because a query expected the old inferred type. A shape can be technically clearer while an integration loses the field it knew how to send. A property can be renamed for good reasons while old evidence graphs lose their operational meaning.
The adjacent standards world has useful language here. FHIR's versioning guidance distinguishes breaking changes that make previously conformant instances no longer conformant from non-breaking changes that add capability without invalidating unchanged applications. Ontology teams need the same discipline, even if the release labels are dated instead of semantic version numbers.
Where this gets uncomfortable
Backward compatibility can preserve bad abstractions for too long. A team can end up defending a weak term because too many consumers depend on it. That is not maturity. It is fear with a process around it.
Sometimes the honest move is a breaking change. Split the concept. Rename the property. Tighten the shape. But say that it is breaking, ship migration notes, keep the old terms legible, and give consumers a version they can stay on while they move.
The goal is not to freeze the ontology. The goal is to make change observable enough that old data still speaks.