Build a working ontology from defence logistics data
Build an ontology from an empty Python file, inspect actual graph records and their sources, and extend a maintenance example to multiple required parts. Six chapters combine plain-language explanations with a downloadable, locally tested implementation.
The question: How do we actually create, validate and use an ontology from operational source records?
You’ll learn: Construct an ontology step by step, trace RDF facts to CSV records, validate and query them, and migrate the model to support several required parts per order.
For: Domain experts, analysts and engineers; concepts are explained before the runnable commands.
Executed teaching prototype · AI-assisted source check . This is not a human expert endorsement.
Chapter 1: Start with a decision and a model you can build
1. Start with a decision and a model you can build#
A maintenance coordinator opens WO-204 for generator GEN-17. The job needs two PF-9 filters. North depot reports six on hand. Two are quarantined and three others are reserved, leaving one available. The job is one filter short.
This guide uses invented records from routine generator maintenance in a defence support organization. You will create the ontology, populate it from those records, validate the graph, and query it. The companion implementation runs on your computer using Python, RDFLib, and pySHACL. Its outputs are inspectable files, and its tests include inputs that must be rejected.
Step 1: Specify the question and its accounting rules#
Write the question before choosing software: Can North supply the two filters requested by WO-204, and which records explain the answer? The maintenance coordinator prepares the evidence; an authorized supervisor would own any later operational decision.
For this fixture, “on hand” includes every physically recorded filter, including reserved and quarantined units. The reservations belong to other work; the baseline does not represent their owning orders. All quantities use the same part, depot, observation, and unit. Reserved and quarantined units must not overlap.
Available = On hand − Quarantined − Reserved
Available = 6 − 2 − 3 = 1 filter
Shortage = max(0, Required − Available)
Shortage = max(0, 2 − 1) = 1 filterAn inventory system that already subtracts reservations from “on hand” needs a different mapping. Reusing this formula unchanged would subtract them twice. Agreeing on each input's meaning is a modelling task, even when the final arithmetic is simple.
Record three expected outcomes: the supplied fixture yields one available and one short; stale evidence withholds the calculation; an unresolved source identity rejects the build. These become acceptance checks throughout the guide.
Step 2: Decide whether an ontology is useful here#
The shortage calculation can also be implemented with SQL. If one application owns consistent tables and only needs this report, documented keys, joins, and constraints may be sufficient. RDF is not required to subtract quantities.
The ontology becomes useful when several applications must share the meaning of an asset, a requirement, a stock observation, and its evidence. It makes those definitions and relationships explicit, so a new question can reuse them. It does not automatically reconcile source systems or make their records correct.
Chapter 6 demonstrates that reuse with an executable change: WO-204 requires both filters and a seal. Each requirement receives its own identity, quantity, and part relationship. A query then follows work order → requirement → part → stock → allocations to explain each line. A relational model can support the same design; choose the representation according to interoperability, query, and operating requirements.
| Situation | Reasonable starting point |
|---|---|
| One stable source and one shortage report | Relational tables, reviewed joins, and explicit accounting rules |
| Several producers use different names for the same equipment | Canonical identity mappings and a shared vocabulary |
| New questions repeatedly follow relationships across those producers | Evaluate an ontology and graph alongside the relational alternative |
| A reader needs passages from service instructions | Retrieval with document versions and citations; combine it with current structured facts when needed |
Step 3: Choose the smallest useful set of things#
The baseline uses six classes. A class is a kind of thing; GEN-17 is one instance of the Asset class. Each choice should preserve a distinction that matters to the question.
| Class | Why it is separate | What would justify a richer model? |
|---|---|---|
| Asset | One generator has its own identity and maintenance history | Components with independent serial numbers or lifecycles |
| WorkOrder | A request is different from the equipment it concerns | Multiple requested parts, introduced in Chapter 6 |
| PartType | PF-9 is a catalogue kind, rather than one physical filter | A PhysicalPart class when individual service histories matter |
| StockSnapshot | Six units is an observation at a depot and time | Multiple observations with a defined current-state policy |
| Allocation | A reservation or quarantine has its own quantity and unit set | Owning job, expiry, reason, and lifecycle relationships |
| InspectionEvidence | An observed status needs a date and source version | Separate checklist and document revision objects |
An Allocation is not just a number on a stock record: keeping it separate lets the lab check the units behind quarantine and reservations. A PartType is not a physical filter: the baseline keeps physical unit IDs as values for disjointness checks. A Depot remains a controlled text value here; give it a class when location, ownership, capacity, or depot relationships become query requirements.
Original diagram of the reference lab. A class describes a kind of record; GEN-17 and WO-204 are individual records. Select a box to see what is represented.
Select a box to inspect its role. On a small screen, scroll the diagram sideways.A request to maintain a particular asset. Its required part and quantity are explicit facts; a request does not by itself authorize a stock allocation or maintenance release.
Read the complete diagram as text
- WorkOrder · WO-204: A request to maintain a particular asset. Its required part and quantity are explicit facts; a request does not by itself authorize a stock allocation or maintenance release.
- Asset · GEN-17: The support generator being maintained. Approved source aliases map to one canonical identity. Similar names are not sufficient evidence of identity.
- InspectionEvidence: A dated inspection record connected to the asset, with provenance. A missing or stale inspection remains a visible reason to stop a proposal.
- PartType · PF-9: The type of filter required. Quantities are comparable only when part identity and unit agree.
- StockSnapshot: An observation of the physical count at a depot and time. The teaching input has six PF-9 filters; this observation must not be mistaken for a continuously live stock service.
- Allocation: A record marking units as reserved or quarantined. The lab checks that these allocations belong to the same stock snapshot and do not overlap.
- WorkOrder · WO-204 → for → Asset · GEN-17
- InspectionEvidence → checks → Asset · GEN-17
- WorkOrder · WO-204 → needs → PartType · PF-9
- StockSnapshot → counts → PartType · PF-9
- Allocation → reduces → StockSnapshot
Read an arrow as a relationship you can inspect. WO-204 concerns GEN-17 and requires PF-9. The stock snapshot concerns PF-9. Allocations refer to that snapshot. Inspection evidence concerns GEN-17. Every relationship has a direction and identified endpoints.
Step 4: Learn the vocabulary through the files#
| Term | Plain meaning | Where you will see it |
|---|---|---|
| Ontology | Shared definitions of kinds of things and their relationships | schema/schema.ttl |
| Knowledge graph | Particular records connected using those definitions | results/instances.ttl |
| RDF triple | One subject–relationship–value statement | WO-204 — asset — GEN-17101 |
| IRI | A full identifier that gives a term or record an unambiguous name | https://example.org/maintenance/id/ORG-TRAIN/asset/GEN-17 |
| OWL | A language for formal ontology descriptions | Class and property declarations102 |
| SHACL | Conditions used to validate a graph | schema/shapes.ttl |
| SPARQL | A query language for matching graph patterns | queries/order_inventory.rq |
| Provenance | Recorded derivation from source records | results/provenance.ttl |
A retrieval assistant can find an approved instruction; it still needs relevant, current stock records to establish availability. The enterprise RAG guide covers retrieval. Here, identities and quantities become explicit graph statements before an explanation is produced.
Step 5: Understand the evidence behind this guide#
Fasina, Sawyerr, and Murainah's 2026 paper combines neural text extraction with symbolic processing in a WebNLG text-to-RDF experiment.103 It motivates checking extracted candidates. Our runnable path starts with structured CSV records, so the complete construction process can be inspected without a model API or an unverified extraction stage.
Operational model documentation also describes connecting objects, properties, relationships, and permitted actions.104 Chapter 4 turns that idea into a concrete source-to-model contract. The implementation and maintenance scenario here are our own; no commercial platform configuration or operational deployment is claimed.
Checkpoint: what you have specified#
You have a question, source meanings, six classes, relationship directions, and expected success and failure outcomes. You should be able to explain why a stock observation is different from a catalogue part, and why two allocations need separate identities. Next, create a small ontology progressively before running the complete importer.
W3C, RDF 1.1 Concepts and Abstract Syntax — triples and IRIs; checked 14 September 2026.
W3C, OWL 2 Web Ontology Language Primer — formal descriptions and semantics; checked 14 September 2026.
E. P. Fasina, B. A. Sawyerr, and A. Murainah, On the Construction of Knowledge Graphs from Unstructured Text using Neuro-Symbolic Networks, UIJSLICTR 17(1), 121–145 (2026) — full text checked 14 September 2026. Journal publication: 7 September 2026; PDF issue imprint: June 2026.
Operational ontology overview — object, relationship, and action concepts; checked 14 September 2026. This reference does not establish deployment of the example.