Ontology Engineering That Ships: From Requirements to OWL

July 19, 2026 · 20 min read

Most ontology projects fail before a single triple is written.

Not because the modelers lack skill. Because there is no agreed specification of what the ontology must answer, who will use it, and what counts as done. Teams open Protégé, start drawing class hierarchies, and iterate on names and shapes for weeks. Six months later, they have a model nobody agrees on, stakeholders who have lost confidence, and a codebase of SPARQL queries that do not return useful answers.

The discipline that prevents this has a name: ontology engineering - not just modeling, but the full software-engineering lifecycle applied to knowledge representation: requirements, specification, iterative development against testable acceptance criteria, and principled tooling.

This series applies that discipline across three posts. This first one runs end to end through a single build - from requirements to a validated OWL model - with one non-negotiable lesson: the specification comes first. Part 2 builds the continuous SHACL validation that guards the model in CI/CD; Part 3 treats the finished ontology as a versioned public API.

The single biggest predictor of ontology project failure is the absence of a written, agreed specification of what the ontology must answer. Talent alone does not save projects that skip this step.

Why Specification Comes Before Modeling

There is a seductive pull toward jumping straight to the model. Ontology tools are visual, domain experts are in the room, and it feels productive to draw boxes and arrows together. The problem is that boxes and arrows do not capture requirements: they capture one team’s current best guess at a model.

When the requirements are implicit and undocumented, every design decision becomes a negotiation between whatever the developers assumed and whatever the stakeholders actually needed. These negotiations happen at the worst possible time: during integration testing, when data is already flowing, when changing a property name or restructuring a hierarchy means updating three SPARQL endpoints, two ETL pipelines, and a dozen SHACL shapes.

Writing requirements first forces clarity that diagramming does not. It forces you to answer: what exact questions must this ontology enable? Who asks them? What counts as a correct answer? What is explicitly outside scope? These questions sound obvious, but teams routinely skip them, and they pay for it.

The LOT Methodology (Poveda-Villalón et al., 2020, Journal of Web Semantics) formalized this for industrial settings after studying why ontology projects succeeded or failed in practice. The answer was consistent: projects that invested in requirements specification before modeling produced ontologies that got used. Projects that modeled first produced ontologies that got abandoned.

The Specification Contract: What Is an ORSD and Why Does It Exist?

The Ontology Requirements Specification Document is the ontology equivalent of a product requirements document. It is not a technical document in the usual sense: it contains no Turtle, no SPARQL, no class hierarchies. It is a business and engineering contract that defines the problem before anyone touches a tool.

The ORSD serves three purposes. First, it gives stakeholders a document they can actually review and sign off on: non-technical stakeholders cannot review OWL, but they can review a list of questions the ontology must answer and agree or disagree. Second, it anchors every modeling decision to a requirement, so when debates arise about how to model something, you can resolve them by asking which requirement is served. Third, it creates the acceptance criteria that later become your automated test suite.

Seven Sections That Save Projects

A well-formed ORSD has seven sections, each solving a different class of project failure.

Writing the Purpose Statement

The purpose statement in §1 is deceptively hard to write well. Teams instinctively reach for domain descriptions: “This ontology covers procurement, supplier relationships, and commodity management.” That is not a purpose: it is a subject area. A purpose statement names the problem and the value of solving it.

A weak purpose statement: “This ontology models procurement data.”

A strong purpose statement: “Enable cross-system querying of supplier-commodity-plant relationships with embedded business constraints, so that demand planning can identify supply risks without custom ETL jobs for every new query.”

The difference is that the strong version defines who benefits, what they need, and why the ontology (rather than some other solution) is the right tool. If the purpose statement does not answer those three things, it is not done.

Defining Scope: The Art of Saying No

The scope section (§2) is where projects are saved or destroyed. Every domain has more structure than any single ontology should capture. A procurement ontology that tries to model supplier financials, logistics routing, and HR org structure alongside commodity relationships will be enormous, slow to reason over, and owned by nobody.

Good scope definitions are explicit about what is excluded and why. The discipline of writing the exclusions out forces conversations that otherwise happen implicitly: someone on the team was assuming the ontology would cover logistics, and finding out via the scope document is much cheaper than finding out via a failed integration test.

For a procurement ontology, a scope section might read: In scope: direct procurement, tier-1 and tier-2 supplier relationships, commodity specifications, minimum order quantities, lead times. Out of scope: logistics routing, warehouse management, supplier financial data, HR organization.

This level of precision looks excessive until the first time a stakeholder asks “can we add the shipping carrier to this?” and you can point to the document instead of having a three-meeting debate.

Stakeholder Mapping

The stakeholder section (§3) matters because different roles place conflicting requirements on an ontology. Demand planning needs query performance and simple vocabulary. SAP integration needs stable, predictable IRIs they can map ETL fields to. Compliance needs validation rules that enforce tier constraints. If only one role is represented in the room when decisions are made, the other roles will hit problems in production.

Mapping stakeholders also reveals who needs to sign off on the ORSD - and getting those signatures before modeling starts is what transforms the ORSD from a document into a contract.

A Concrete Example

Here is what §1 through §4 look like for a procurement ontology:

§1 Purpose: Enable cross-system querying of supplier-commodity-plant
   relationships with embedded business constraints (tier, lead time, MOQ),
   so demand planning can assess supply risks without per-query ETL.

§2 In scope:  direct procurement, tier-1 and tier-2 suppliers, commodity specs
   Out of scope: logistics, finance, HR

§3 Stakeholders:
   - Demand Planning (consumer: SPARQL queries, read-only)
   - SAP Integration (producer: writes RDF from ERP events)
   - Compliance (validator: checks tier-1 constraints)
   - Procurement Engineering (owner: maintains ontology)

§4 FR-001: System must identify all tier-1 suppliers for a commodity
   FR-002: System must flag suppliers below minimum order quantity
   FR-003: System must show lead time for any supplier-plant pair
   FR-004: System must support querying by commodity category hierarchy

Competency Questions: Turning Requirements Into Tests

Competency Questions (CQs) are the bridge between the ORSD and the actual ontology model. They translate the functional requirements in §4 into natural-language questions that the ontology must be able to answer. Crucially, each CQ also maps to a SPARQL query: which means CQs are not just documentation, they are executable acceptance tests.

The key insight: a failing CQ against a populated graph is data, not failure. It tells you exactly what the model is missing. This transforms the development loop from “is this model correct?” (unanswerable) to “does CQ-003 return results?” (immediately testable).

Anatomy of a Well-Formed CQ

A CQ is not just a question: it is a structured specification with four parts that must all be present:

For FR-001 (“System must identify all tier-1 suppliers for a commodity”):

# CQ-PROC-001: Which suppliers provide commodity X to plant Y at tier 1?
SELECT ?supplier WHERE {
  ?sr a proc:SupplyRelationship ;
      proc:commodity :CommodityX ;
      proc:suppliesPlant :PlantMunich ;
      proc:tier proc:Tier1 ;
      proc:supplier ?supplier .
}

If this query returns an empty result against a graph containing known tier-1 supply relationships, the ontology is not done: the sprint is not done, no matter how polished the class hierarchy looks.

From Business Question to SPARQL Assertion

The translation from business question to SPARQL query is where you discover what the model actually needs to contain. Writing CQ-PROC-001 tells you: you need a SupplyRelationship class (not a plain property between Supplier and Commodity), you need proc:tier as an attribute of the relationship, and you need a proc:supplier property pointing from the relationship to the supplier entity.

This is not obvious from the domain description alone. Without writing the CQ first, you might model a direct proc:suppliesCommodity property: which cannot carry the tier, volume, or lead time attributes that other CQs require. The CQs drive the model toward what it actually needs to be, not what looks elegant in a diagram.

CQ Anti-Patterns to Avoid

Questions that are too vague. “What are the properties of a supplier?” is not a CQ: it has no expected result shape and no link to a business requirement. Every good CQ names specific entities and specific relationships.

Questions that exceed the scope. If §2 excluded logistics, writing a CQ that asks about shipping routes is a scope violation that will create modeling pressure in the wrong direction. CQs must stay within the ORSD scope.

Too few CQs. Five to ten CQs for a focused domain module is a reasonable minimum. Less than five, and the test coverage is too thin to catch structural gaps. More than thirty for a single module, and the module is probably doing too much.

CQs without FR links. Every CQ must trace back to a functional requirement. Unlinked CQs are requirements that were never agreed by stakeholders: they represent unilateral decisions by the modeling team.

From Whiteboard to Formal Model: UML and OWL Together

With the ORSD signed off and CQs written, you have everything you need to build the conceptual model. The standard practice is to start in UML: not because UML is a prerequisite to OWL, but because UML is the language domain experts can actually read and critique. You model in UML to get expert validation of the structure, then translate mechanically to OWL.

The Translation Rules

The translation from UML to OWL is rule-based, not creative. Every UML construct has a deterministic OWL equivalent. Understanding the mapping - and its limits - is essential:

The right column is critical to understand. OWL operates under the Open World Assumption: the absence of a triple does not mean it is false: it means it is unknown. This is the correct assumption for a knowledge representation system reasoning over incomplete information. But it means that owl:minCardinality 1 does not enforce that an instance actually has a value: it is a hint to the reasoner, not a validation rule.

When you need to enforce that every proc:Supplier actually has a proc:supplierCode, you need SHACL. Specifically sh:minCount 1 on a SHACL NodeShape targeting proc:Supplier. Part 2 of this series covers the full SHACL validation layer.

When to Use the N-ary Pattern

The most common modeling mistake newcomers make is trying to put relationship attributes on a direct OWL property. OWL properties are binary: they connect exactly two resources. A proc:suppliesCommodity property between a supplier and a commodity cannot also carry volume, lead time, tier level, or effective date. This is not a design choice: it is a fundamental constraint of RDF’s triple structure.

When a real-world relationship carries its own attributes, or when more than two entities participate, you need to reify the relationship as an intermediate class:

# Naive - cannot carry volume, lead-time, or tier
proc:Supplier1  proc:suppliesCommodity  proc:Steel .

# N-ary reification - the relationship is a first-class resource
proc:SR-001  a                  proc:SupplyRelationship ;
             proc:supplier      proc:Supplier1 ;
             proc:commodity     proc:Steel ;
             proc:suppliesPlant proc:PlantMunich ;
             proc:monthlyVolume "5000"^^xsd:decimal ;
             proc:leadTimeDays  "14"^^xsd:integer ;
             proc:tier          proc:Tier1 .

The N-ary node proc:SR-001 is now a first-class resource in the graph. It is queryable, versionable, and extensible: you can add a new attribute to the supply relationship without touching the Supplier or Commodity classes.

Use the N-ary pattern when:

• The relationship has attributes of its own (volume, date, status, tier)
• More than two entities participate in the relationship
• The relationship is time-bounded or can change state
• The CQs ask questions about the relationship itself, not just its participants

Use a plain object property when none of the above apply. The N-ary pattern adds a class that must be maintained; use it only when the alternative (losing attributes) is worse.

What OWL Cannot Do

There are things OWL is genuinely not designed for, and trying to force them into OWL creates expensive, fragile models. Understanding these limits early saves significant pain:

OWL cannot enforce closed-world constraints. It cannot say “this supplier must have a country: if it does not, it is invalid.” Under the open world assumption, a supplier without a country is simply one about which the country is not yet known. For operational validation, you need SHACL.

OWL reasoning cost scales with hierarchy depth and with the number of existential restrictions. A deeply nested subclass hierarchy with many owl:someValuesFrom restrictions will make an OWL DL reasoner slow. If you need reasoning, prefer OWL 2 EL or RL profiles (more on profile selection below). If you need fast validation, SHACL with sh:sparql shapes is your tool.

OWL cannot express the assertion “there is no supplier for commodity X”: negation-as-failure is a closed-world concept. This matters when building compliance reports that need to flag absence of data.

Building on Shoulders: The ODP Reuse Hierarchy

Before creating any custom class or property, the question should always be: does this already exist in a well-maintained vocabulary? The answer is “yes” more often than ontology engineers expect, and reusing existing vocabulary has compounding benefits: your ontology is automatically interoperable with other systems using the same terms, you get free documentation, and you carry zero maintenance burden for the terms you import.

Start from the bottom: reach for W3C standards first, then domain ontologies, then structural patterns. Only create Level 4 terms when nothing above fits. Every custom term is yours to maintain forever.

Level 1: The W3C Foundation

These are the terms you should reach for first, before anything else. They are maintained by the W3C, have stable, well-documented IRIs, and are already understood by semantic tooling.

PROV-O for provenance: any entity with a source, any activity with an agent, any derivation relationship. If your ontology captures where data came from, PROV-O has the vocabulary.

SKOS for controlled vocabularies: concept schemes, broader/narrower relationships, preferred and alternate labels. Use SKOS whenever you are representing a taxonomy that humans browse: commodity hierarchies, geographic classifications, regulatory categories. Using rdfs:subClassOf for a taxonomy that should be a vocabulary is a common antipattern; SKOS is the right tool.

OWL Time for temporal facts: time intervals, instants, durations. If your data has an effective date, a validity period, or a temporal sequence, OWL Time has the vocabulary.

QUDT for quantities and units: measurements with units. qudt:Quantity for a measurement, qudt:unit to specify the unit. Never represent "5000 kg" as a plain string when QUDT gives you proper semantics.

Level 2: Domain Ontologies Worth Knowing

At this level, you are looking for ontologies that cover parts of your domain specifically.

schema.org has extensive coverage of organizations, products, places, and events. Before creating your own proc:Organization, check whether schema:Organization is close enough: it often is, and alignment gives you immediate interoperability with the web of data.

SSN/SOSA (Sensor, Observation, Sample, Actuator) covers IoT and observation patterns. If your domain involves sensors, measurements, or observations of physical phenomena, these ontologies handle the structural complexity for you.

GoodRelations covers e-commerce and B2B supply chain semantics: offerings, price specifications, delivery terms. For procurement ontologies, GoodRelations has vocabulary that maps directly to many ORSD functional requirements.

DCAT (Data Catalog Vocabulary) for dataset metadata. If your ontology is part of a data lake or catalog, DCAT terms make your datasets discoverable by standard tooling.

Level 3: Structural Patterns

Ontology Design Patterns (ODPs) are not full ontologies: they are reusable modeling solutions to recurring structural problems, published at the ODP Repository (ontologydesignpatterns.org).

The N-ary pattern described earlier in this post is Level 3. Others worth knowing:

Observation pattern: models the act of observing a quality of an entity at a particular time. Essential for temporal data where the same entity has different values at different times (a supplier’s tier status changes, a commodity’s price changes).

Sequence pattern: models ordered lists of resources when RDF’s set semantics are insufficient. Use when event sequences or processing steps need order preservation.

Situation pattern: reifies a context: a set of facts that hold under specific conditions. Useful for scenarios where relationship attributes depend on context (a supplier’s tier level differs by geography or product line).

Level 4: Your Custom Terms

Custom terms are necessary: no general vocabulary covers every domain. But they carry a cost that is easy to underestimate: every custom class and property is a term your team must document, maintain, version, and keep aligned with upstream systems.

Before creating a Level 4 term, run through this checklist: search LOV (Linked Open Vocabularies, lov.linkeddata.es), search schema.org, check BioPortal if you are in a life sciences context. If you find a term that is 80% right, alignment via owl:equivalentClass or rdfs:subClassOf is almost always better than a new custom term.

When you do create custom terms, name them to survive organizational change. Avoid naming classes after internal project codenames or team names. Names like proc:SupplyRelationship survive; names like DigitalProcurementInitiativeRelationship do not.

The Five Anti-Patterns That Kill Ontology Projects

These are not theoretical concerns: each of these failure modes is documented in post-mortems of real ontology projects.

Modelling Before Specifying

The most common failure. Teams open Protégé, draw class hierarchies based on gut instinct and domain intuition, and spend weeks polishing a model nobody has validated against actual requirements. Six months later, stakeholders see the model for the first time and have contradictory opinions about fundamental design decisions. The model gets rebuilt from scratch.

The fix is structural: the ORSD must exist and be signed off before any modeling tool is opened. This is not a suggestion: it is the gate between requirements and design.

Deep Inheritance Hierarchies

OWL reasoning cost scales with taxonomy depth. A hierarchy like proc:Tier1GermanAutomotiveSteelSupplier rdfs:subClassOf proc:Tier1SteelSupplier rdfs:subClassOf proc:MetalSupplier rdfs:subClassOf proc:Supplier causes exponential work for an OWL DL reasoner to classify.

The better approach: keep the class hierarchy flat (two or three levels maximum) and use properties to capture distinctions. proc:tier proc:Tier1 and proc:country :Germany and proc:commodity :Steel can express the same distinctions without creating an explosion of named subclasses.

For reference taxonomies that humans browse (commodity categories, geographic hierarchies, supplier classifications), use SKOS concept schemes with skos:broader/skos:narrower instead of OWL subclassing.

Using owl:minCardinality for Validation

This is a seductive mistake because OWL cardinality axioms look exactly like validation rules. owl:minCardinality 1 on a property looks like “every instance must have at least one value.” Under OWL’s open world assumption, it means “if an instance has zero values, the reasoner may infer the existence of an unknown value”: not the same thing.

For operational validation (the kind that runs in CI and blocks bad data from reaching production), you need SHACL. sh:minCount 1 on a SHACL shape genuinely fails when the count is zero.

One Ontology, One File

Monolithic ontologies cannot be independently versioned. They cannot be loaded selectively by systems that only need part of the vocabulary. They create merge conflicts when multiple engineers work on different domains concurrently.

The right structure is modular: a core namespace for stable, shared concepts, domain extension modules for specific subject areas, and application profiles that express operational constraints for specific use cases. These are separate files linked with owl:imports. Part 3 of this series covers the versioning discipline that makes this manageable.

No CQs, No Acceptance Criteria

Without executable CQs, “done” is undefined. Stakeholders sign off on diagrams that look reasonable but do not answer their actual business questions. The ontology ships, the first real query returns unexpected results, and everyone discovers the model made different assumptions than the requirements implied.

The fix requires discipline: every sprint story that modifies the ontology must specify which CQ it addresses, and the sprint is not done until the SPARQL assertion for that CQ passes against a populated test graph.

A Sprint Workflow That Actually Works

The four phases of ontology engineering - specify, model, encode, validate - map cleanly onto a single sprint when the scope is appropriately bounded. Here is what that looks like in practice.

The sprint begins with the ORSD in a shared document. The first activity is drafting §1 through §5 with stakeholders in the room: not asynchronously. Purpose, scope, stakeholders, functional requirements, and non-functional requirements all need live discussion to surface the conflicts and assumptions that written drafts miss.

From the functional requirements, enumerate five to ten CQs. Write each in natural language, link it to its FR, write the SPARQL query, and define the expected result. This activity often reveals ambiguities in the FRs themselves: a FR that looked clear becomes ambiguous when you try to write a testable assertion for it. Resolve those ambiguities before proceeding.

With CQs signed off, build the UML conceptual model with domain experts. The CQs tell you exactly what entities and relationships the model must contain: use them as a checklist. Mark N-ary candidates during this session: anywhere a relationship carries attributes, anywhere more than two entities participate. Get explicit domain expert review of the UML before proceeding.

The OWL encoding follows directly from the UML, using the translation rules described above. Apply the ODP reuse hierarchy: reach for W3C standards first, then domain ontologies, then structural patterns, then custom terms only where necessary. Encode in Turtle, using ROBOT for syntax validation.

The final activity of the sprint is writing SHACL shapes for each CQ and running the CI gate: syntax check, OWL consistency check with a reasoner, SHACL validation against test instance data, SPARQL CQ assertions against the populated graph. A passing CI gate means the sprint is done: not “the model looks good,” but “the model answers the questions it was specified to answer.”

The next part of this series covers what comes after the sprint passes: building the SHACL validation layer that runs in CI on every pull request, writing shapes at the right level of specificity, and wiring the quality gate into GitHub Actions.