Build a working ontology from defence logistics data

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.

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.

An 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.

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.

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.

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.

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.

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.

Fasina, Sawyerr, and Murainah's 2026 paper combines neural text extraction with symbolic processing in a WebNLG text-to-RDF experiment.¹⁰³ 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.¹⁰⁴ 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.

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.

Start with an empty Python file. By the end of this chapter, that file will create classes, actual equipment records, relationships, validation rules, and a queryable graph. You will see exactly where each statement comes from.

Our first question is deliberately small: Which asset and part type does work order WO-204 refer to, and how many items does it require? We will build three classes for this question. Stock, allocations, inspection evidence, and source provenance enter the fuller model in chapter 3.

Download and extract the ontology lab ZIP. Open a terminal inside the extracted folder, where you can see ontology_lab.py, requirements.txt, and lessons. The verified environment is Python 3.12.10 with the exact dependency versions in requirements.txt.

On Windows, run:

On macOS or Linux, use your installed Python 3.12 interpreter to create the environment and replace .venv/Scripts/python.exe with .venv/bin/python in subsequent commands. Those alternative paths are provided for portability; the included execution record was produced on Windows. Package setup downloads dependencies. The lesson itself reads and writes local files.

Create an empty file called lessons/my_ontology.py in your editor. Add the code below. The imports provide the RDF graph and SHACL validator; M is an identifier namespace. These example.org identifiers are names for things, not addresses the script must fetch.

Run the file:

You should see 01_classes.ttl: 3 triples. Open lessons/my-results/01_classes.ttl. It declares Asset, PartType, and WorkOrder as OWL classes. It does not contain an actual generator yet.

A class describes a kind of thing. An instance identifies one thing of that kind. RDF stores statements as triples: subject, relationship, and value or linked object.²⁰¹ For example, “GEN-17 is an Asset” is one statement. The complete collection of these statements is the graph.

Append this block to the same file, below the previous code. Do not replace the earlier steps.

Run the same command again. The new file 02_schema-and-entities.ttl has 19 triples. Open it and find GEN-17 and PF-9.

We used two kinds of properties. m:asset and m:part point to other graph objects. m:recordId, m:requiredQuantity, and m:unit carry literal values such as a string or integer. A property label gives it a readable name.

Why is PF-9 a PartType instead of an Asset? PF-9 identifies a catalogue type of filter. GEN-17 identifies one physical generator. If individual filters need serial numbers, ownership, or maintenance history, introduce a PartInstance class with its own identity. A catalogue type and one physical item answer different questions.

The range statements describe the kinds of targets those relationships have. They are not an error-handling mechanism. OWL supports logical descriptions and inference; missing information is not automatically false.²⁰² We will explicitly require valid links and values with SHACL in step 4. This lesson does not run an OWL reasoner.

Open lessons/orders.csv. It contains exactly this fictional row:

The source system says GENERATOR_017; our canonical asset ID is GEN-17. We cannot invent that match from spelling similarity. The small reviewed alias dictionary below maps the source identifiers to records we have already created. Its keys include object kind and organization so two different contexts cannot silently share a mapping.

Append the following code. The checks happen before the graph receives the work-order statements.

Run the file again. 03_mapped-order.ttl now has 25 triples. The new order contributed six statements: its class, record ID, asset link, part link, required quantity, and unit.

Find the order's m:asset property in the Turtle file. Its value is GEN-17's full identifier, not a copied generator name. Follow that identifier to the asset's own statements. That link is what allows a later query to join the two records without guessing what the text means.

This is a small, intentional importer. The full lab reads canonical records and aliases from separate CSV files and supports more than one organization. An organization code in a local file is a scope value; it does not authenticate the person opening that file.

Checkpoint: Change GENERATOR_017 to GENERATOR_018 in this lesson CSV and rerun. It must stop with “Unknown alias: review the source mapping.” Restore the original value before continuing. Existing generated files may remain from the earlier successful run, so only a successful current run establishes that the outputs match your source.

A SHACL shape is an executable acceptance rule for the supplied graph.²⁰³ This shape requires one asset link, one part link, one positive integer requirement within the chosen bound, and the unit each.

Append this block. First it validates the real graph. Then it makes a separate copy and changes the quantity to the string "two". The original graph stays valid.

Run the file. In addition to the three graph counts, it should print:

Open 04_valid-report.txt and 05_invalid-report.txt. The second report identifies the affected work order, m:requiredQuantity, and a datatype violation. 05_broken-graph.ttl contains the actual broken graph, so you can inspect the input that failed. No failure message has been hard-coded as a substitute for validation.

Why validate after checking the CSV? The importer catches source-format and identity problems early. SHACL checks the resulting graph's contract. It still catches a wrong value if a different importer or a later graph edit bypasses those source checks. Neither check proves that the warehouse or maintenance record is physically correct.

Append the final block. SPARQL is a query language for RDF graphs. Read the pattern as a connected question: find this order, follow its asset and part links, then return their record IDs and the order's quantity and unit.

Run the file again. The final line should be:

Open 06_order.rq to inspect the query and 06_query-result.json to inspect its result. The query checks graph conformity before returning an answer and binds the requested order as an RDF value. It does not accept arbitrary query text or perform a business action.

You have now created an ontology schema and populated it from a source row. The query result came from the explicit relationships and values in your graph. It was not generated by a language model.

The ZIP includes lessons/build_step_by_step.py, which contains the same construction functions and a runner. Use it to compare against your own file; it writes to lessons/results/, keeping your my-results/ separate. Run the reference and its tests with:

Seven tests were executed successfully. They check the staged graph counts and actual query result, a real SHACL failure, unknown identity, wrong organization, unsupported units, fractional quantity, and refusal to query a graph missing its required asset link. Triple serialization order and blank-node names can differ; those are not changes to the graph's meaning.

Why not add all possible classes now? Introduce a concept when a question needs its identity, properties, relationships, or history. The full baseline adds StockSnapshot because inventory changes over time, Allocation because reserved and quarantined units need separate evidence, and InspectionEvidence because a status has a source and observation time. A Depot can remain a controlled value until you need depot-specific properties or relationships. More classes alone do not produce a more useful ontology.

This lesson deliberately does not calculate availability. Chapter 3 runs the complete baseline, which adds those three classes, dated records, stock rules, and file-and-row provenance. Its populated data graph has 121 triples; do not compare that count with this lesson's 25-triple graph, which includes its small schema. Keep their output folders separate.

Chapter 2 created a small ontology progressively, ending with 25 triples and a relationship query. Now use the complete importer to add stock snapshots, allocations, inspection evidence, and source lineage. The baseline produces 121 instance triples. The smaller lesson and this complete build use separate output directories, so you can compare them.

Keep the original fixture unchanged for this first run. An expected result is useful only if the inputs are known. The reference clock is fixed at 14 September 2026, 08:00 UTC, so the same dated records can produce reproducible freshness checks.

From the lab directory, run the build with the environment created in chapter 2:

The command reads the CSV fixtures and constructs schema/schema.ttl, schema/shapes.ttl, results/instances.ttl, and results/dataset.trig, alongside provenance and build records. Turtle represents the populated statements; TriG carries the dataset's separate named graphs. These files are produced from the functions in ontology_lab.py; they are not the persistent place to edit the model.

Start by following the work-order row. Its fields have specific destinations:

The mapper resolves those aliases through the explicit table before writing the relationships. It must not create a new generator simply because a source uses a different nickname. An unresolved reference is an ingestion problem to fix, not an invitation to invent an entity.

These selected triples show the resulting work order and its typed targets. They are a readable excerpt of the instance graph, with prefixes added for clarity:

Save this complete script as inspect_order.py in the lab directory. It reads the generated RDF and prints the work order's linked records. Using the class and identifier fields makes the example independent of Turtle's formatting or statement order.

Run it using the same environment:

The supplied fixture produced these fields when the script was checked:

You have followed a schema-to-instance relationship using the actual graph. The script inspects just the work order; the full query also checks stock, allocations, and evidence before calculating availability.

Execute the validator explicitly:

The validator applies the supplied shapes and writes results/validation-report.txt and .ttl. For the baseline, its console result is:

A passing report establishes that the data satisfies those selected conditions. It does not certify physical stock, legal authority, or overall maintenance readiness. SHACL evaluates the conditions provided to it; the coverage of those conditions remains an engineering decision.³⁰¹

Read a failure at the level of the record and field. A missing asset relationship needs an identity or mapping correction. An invalid quantity needs the unit and source value checked. Rebuilding from corrected source records preserves the explanation of what changed; editing the generated output merely to remove an error can hide the underlying defect.

The program also checks business invariants beyond simple datatypes. North's six recorded filter units include two quarantined units and three separately reserved units. Those allocation sets must be disjoint and refer to the intended snapshot. Correct integers attached to the wrong snapshot would still produce an unreliable answer.

Run the scoped query:

The supplied fixture produces one available filter and a shortage of one. The result retains the inputs: required two, on hand six, quarantined two, reserved three, and unit each. A bare answer of “no” would prevent the coordinator from seeing whether the problem was stock, stale evidence, or an incorrect mapping.

The command writes results/explanation.json and results/human-review-request.json. The request is marked UNSUBMITTED_LOCAL_DRAFT and changes no inventory. The organization argument selects a local test scope; Chapter 5 collects the implemented and production-required boundaries in one table.

Chapter 4 opens the query itself and examines the calculation. Before moving on, follow results/provenance.ttl back to the source row and file. The build uses PROV entities and activities to record derivation.³⁰² Locators such as orders.csv#record=2 identify CSV records, counting the header as record 1. Hashes in results/manifest.json identify input bytes; they do not prove the supplier was correct. A later source revision requires a new, checked build.

Unstructured maintenance notes would need an additional intake path. A future extractor could read “the two North filters are on hold” and propose an allocation candidate. That phrase alone does not establish which snapshot or individual units it concerns, or whether “on hold” means reservation or quarantine. Preserve the passage and ask for the missing context.

The proposed extension is: source passage → candidate entities and relationships → canonical identity resolution → explicit checks → human review → published facts. It is not implemented in this lab. The current runnable path ingests the structured CSV fixture deterministically. The PDF extraction guide explains the separate document-reading problem.

Fasina, Sawyerr, and Murainah report precision 0.822, recall 0.824, and F1 0.823 for their WebNLG text-to-RDF experiment.³⁰³ Those are the authors' measurements, not results from this maintenance lab. Their approach motivates checking extracted candidates; a high extraction score still does not establish physical stock or operational authority.

An extractor's confidence is a review signal, not a truth label. OWL's open-world semantics also mean missing knowledge is not automatically false; OWL is not a validation firewall.³⁰⁴ Keep uncertainty, contradictions, and unresolved references outside accepted operational facts until the relevant checks and reviewers resolve them.

For a future extraction test, label the expected facts first. If a synthetic trial has 9 correct predictions, 3 incorrect predictions, and 1 missed fact, its illustrative scores are:

That arithmetic is a teaching example, not an executed neural evaluation. Record which kinds of mistakes matter: confusing quarantine with reservation may be more consequential than missing a descriptive nickname.

You have the complete schema, shapes, populated RDF, source lineage, validation report, and one-filter shortage result. Confirm that the inspection script prints GEN-17, PF-9, two, and each. Find orders.csv#record=2 in the provenance and compare its source values with the graph. Chapter 4 provides an interactive viewer of these actual exported records and explains the query and integration contract.

You now have a populated graph and a checked result. This chapter connects the two: follow WO-204 to its asset and part, inspect the stock and allocations, and open the source rows behind those facts. Then define the contract another application would need to use the same model.

The explorer below contains an export of the verified, fictional ORG-TRAIN baseline graph. It is generated from the lab artifacts. It is not a drawing of records that might exist. Selecting a record changes only this page; the viewer makes no model or business-system calls.

Start at WO-204. Follow its asset relationship to GEN-17 and its part relationship to PF-9. Inspect the property requiredQuantity, then open its orders.csv source record. Follow a stock snapshot and its allocations to see which values supplied the shortage calculation.

Notice the difference between a relationship and a literal property: m:part points to another identified record; m:requiredQuantity contains an integer. The source row uses FILTER_PF9, while the graph uses the canonical PF-9 identity. The alias record explains that transformation. File hashes identify the bytes used for this export; their presence does not independently certify the source.

For a small executable inspection, save the following as inspect_graph.py in the lab directory after Chapter 3's build:

Run .\.venv\Scripts\python.exe inspect_graph.py. The supplied fixture returns the GEN-17 asset IRI, PF-9 part IRI, 2, and each. Each ?name is a variable; the patterns find records having all of the stated relationships and values. SELECT chooses the returned columns.⁴⁰¹ An empty result means this pattern found no match, so first inspect the identifiers and mapping.

The inspection query only reads relationships. Run the full business query to apply the availability and evidence checks:

Open queries/order_inventory.rq. It binds the organization and order ID through RDFLib's initBindings, joins the matching asset, part, and stock, then sums allocations by kind. The code requires exactly one matching snapshot. It does not combine depots or identify which work order owns each reservation. The --org argument selects a local demonstration scope; it is not a login.

Establish quantities at their own grain: one stock snapshot and its allocations. Joining every inspection record into that sum could repeat the stock row and inflate it. DISTINCT cannot repair every bad join because two legitimate allocations can have the same quantity. Attach descriptive evidence after calculating the correctly scoped quantities.

A reusable integration needs more than class names. For the baseline, these are actual mappings and cardinalities; “one” means exactly one value on each accepted record. SHACL checks selected cardinalities, while the importer and query supply additional business checks.

The record key is the full IRI built from organization, entity kind, and canonical ID. It is not a display name. A WorkOrder has one asset; an Asset may have several orders. Each Allocation has one snapshot; a snapshot may have several allocations. The baseline's one-part WorkOrder constraint is deliberate and is replaced with requirement-line objects in Chapter 6.

Document who may establish or revise each fact. The following ownership and update rules are a proposed integration contract for a real pilot, rather than services supplied by the local lab:

Object, property, and relationship documentation provides useful implementation concepts, but it does not choose these domain contracts for you.^403404405 The keys, source meanings, cardinalities, and ownership decisions above must be reviewed against the actual organization.

This architecture keeps source interpretation separate from query logic. If you later replace file storage with a graph service, use the same fixture and expected results to check the migration before measuring throughput.

Chapter 6 asks which requirement lines of WO-204 are short, and which stock and allocation records explain each line? Its new PartRequirement object owns a part and quantity together. Adding a seal to the filter requirement then produces two independently inspectable paths.

That distinction matters: two m:part values and two quantities placed directly on one WorkOrder would not say which quantity belongs to which part. Giving each line an identity removes that ambiguity. The extension keeps the existing asset, part, stock, and evidence relationships and changes the portion of the model that the new question requires.

You can trace the actual graph to a CSV record, run a relationship query, explain the aggregation grain, and provide a source-to-model contract. Check that the explorer and results/explanation.json agree on six on hand, two quarantined, three reserved, one available, and one short. Next, preserve that result through an explicit orchestration sequence.

The query is one stage of the application. A reproducible run records which inputs were transformed, whether validation succeeded, what was requested, and where processing stopped. Here, orchestration is a fixed sequence of commands and artifacts. The sequence has no uncertain planning step that needs an autonomous agent.

Run these commands from the extracted lab directory using the environment created in Chapter 2. PowerShell must inspect each external program's exit code so a failed stage prevents the next one from running:

A successful process exit and sufficient stock are different outcomes. The command can successfully explain a shortage. An invalid graph follows the failure path. A nonempty JSON file may contain a diagnostic from a rejected stage, so inspect its status.

build performs the initial SHACL check. validate reopens and checks the generated artifacts. Before a query, load_verified() compares source, importer, query, and generated-artifact hashes with results/manifest.json. Changed inputs require an explicit rebuild.

The dependencies are concrete: declared source rows produce the graph; validation applies to that graph; a scoped query produces the explanation and local review draft. Keep these artifacts together so another engineer can reproduce the result.

The local --org flag is not an access-control boundary: anyone with the downloaded files can inspect all their contents. A deployed service must derive scope from verified identity and policy. ABAC is one policy model using requester, resource, operation, and environment attributes.⁵⁰² A hidden record or property must not silently become a negative business fact.

The baseline's physical unit sets are disjoint: two quarantined units and three other reserved units within six on hand. The calculation therefore yields:

The max means extra usable stock produces zero shortage. It does not justify hiding impossible negative availability. If allocations exceed stock, or the same unit appears in both excluded sets, the inputs require correction.

The query writes results/explanation.json and results/human-review-request.json. These selected review fields come from the baseline run:

The complete draft also includes basisInputFingerprint. It has not been delivered to a reviewer. A coordinator can inspect what was requested, which evidence revision supported it, and why another filter is needed. That is the completed output of the baseline workflow.

A well-typed integer may still be too old to use. fixtures/scenario.json sets a fixed demonstration clock of 14 September 2026, 08:00 UTC, and a 7,200-second freshness allowance. The baseline's stock, two allocations, and inspection were observed at 07:30, giving four fresh records out of four required.

To test the boundary without editing the fixtures, run:

Inspect results/explanation.json: status becomes insufficient_evidence, while available and shortage become null. Rerun the original query to restore the baseline output. The command accepts an explicit clock for repeatable tests; it does not fetch current depot records.

A connector must distinguish observation time from ingestion time. Downloading an old spreadsheet today does not create a new stock observation. SHACL checks graph conditions; the freshness policy and physical meaning of an observation are separate responsibilities.⁵⁰¹

With seven units on hand and the same two quarantined and three reserved, two remain available. That removes the quantity shortage. The exercise lets you change quantity, freshness, scope, and a simulated approval state to see which condition controls the outcome.

The controls are teaching inputs. They do not authenticate a supervisor or change inventory. The equation can be satisfied while a real maintenance process still requires other evidence or authorization.

If a later pilot reserves stock, name a separate operation, for example RequestStockReservation. Agree on the following proposed contract before writing its adapter. This contract is an implementation specification, not an additional command in the download.

Submission conditions need both business criteria and permissions.⁵⁰³ Passing a quantity check alone is insufficient. If another job reserves the last unit after review, the stale proposal must not proceed with its earlier arithmetic.

An external system can succeed while a later local update fails; documented writeback behavior illustrates why these effects cannot simply be assumed to form one transaction.⁵⁰⁴ After a timeout, inspect the operation's recorded outcome before retrying. The adapter and downstream service must agree on operation identity and recovery behavior.

You have an ordered build, validation, and query sequence; a result tied to source revisions; and a local review draft. You can demonstrate that stale evidence withholds the calculation. You also have a concrete specification for a future action service. Chapter 6 now changes the ontology itself and proves the new requirement-line model with data, queries, and failure tests.

The maintenance team changes its question: “WO-204 needs two filters and one replacement seal. Which requirement is blocked, and by which evidence?” The original model cannot express those two part-and-quantity pairs safely. This chapter implements the change, migrates the existing records, and tests the resulting graph.

You will create a PartRequirement class, preserve the original order identity, add three source files, and run a query that keeps each part's evidence and shortage separate. The complete downloadable lab includes the finished extension under extensions/multipart/; its implementation is multipart_lab.py. All steps below run locally with the Python environment prepared in Chapter 2.

The first model has one part and one requiredQuantity directly on a WorkOrder. Adding a second value to both properties would say “this order has PF-9 and SEAL-2, and quantities 2 and 1.” It would not say which quantity belongs to which part. A query could produce the wrong pairings. A comma-separated string such as PF-9:2,SEAL-2:1 would hide that structure inside text.

Give each requirement its own identity. WO-204-R1 owns the filter/count pair; WO-204-R2 owns the seal/count pair. Both belong to the same order. This is why a line item becomes a class: the relationship itself has facts that need to stay together. Later, a requirement could carry its own due date or approved substitute without overloading the WorkOrder.

A relational database can model the same structure with an order-requirement table. The useful ontology lesson is explicit meaning, stable identity, and relationships that several systems can share. Subtracting stock does not, by itself, justify adopting a graph database.

Open extensions/multipart/multipart_lab.py and find model(). It starts from the six-class baseline schema, changes its version to 2.0.0-multipart, and adds these terms. This Turtle fragment describes the same additions; the script generates the complete results/schema.ttl file.

The WorkOrder now needs one or more requirement links. Every PartRequirement needs exactly one order, one part, one positive integer requiredQuantity, and one unit equal to each, plus its organization and record ID. The ordinary part, requiredQuantity, and unit properties remain valid on requirement records.

The migration also forbids those three old properties directly on a WorkOrder. Without that check, old and new consumers could read two conflicting versions of the requirement. These are the actual added work-order constraints from model(); the existing asset, organization and ID constraints are retained. minCount and maxCount constrain the number of values in the data being validated.⁶⁰¹

The extension loads the already verified baseline graph into memory. It does not modify the baseline's CSVs or generated files. For each existing order, build() first creates a requirement whose stable ID is the order ID followed by -R1. It copies the original part, quantity and unit into that record, links the record to its order, and copies the original source-row lineage. Only then does it remove the three old properties from the in-memory WorkOrder. For order IDs longer than 77 characters, migrated_line_id() uses a deterministic shortened ID with a hash suffix to stay within the 80-character identifier limit; the original order identity is unchanged.

The line() helper performs the guarded creation. It rejects unknown or cross-organization references, duplicate requirement IDs, unsupported units, and a repeated part on the same order. The last rule prevents two lines from independently counting the same available stock. Supporting split lines would require an explicit allocation policy, not simply removing that check.

For the supplied dataset, results/migration.json records two migrations: ORG-TRAIN's WO-204 becomes WO-204-R1, and ORG-OTHER's WO-888 becomes WO-888-R1. Their original order, asset and part identifiers are preserved. The additional requirement comes next; it is not invented while migrating old records.

Provenance stays attached to the source records that support each migrated line, and an additional activity identifies the migration. This uses PROV's derivation and activity relationships to describe lineage.⁶⁰² It does not turn the migration into an authenticated audit service. Compare the baseline file hashes before and after if you want to verify that its files were preserved; the test suite makes that comparison automatically.

The extension's three small CSV files are already included. Their paths are relative to the lab directory. Keep the exact headers when creating a fresh copy. First, extensions/multipart/fixtures/parts.csv defines the new part type:

Next, extensions/multipart/fixtures/inventory.csv declares three fictional physical seal identities. The observation uses the same time as the baseline's stock records so the existing freshness policy applies consistently.

Finally, extensions/multipart/fixtures/requirements.csv says that the work order needs one of that part type:

Three seals are an explicit exercise input, not a measured operational count. This closed fixture declares zero reservations and zero quarantined seals; existing filter allocations remain unchanged. A real importer would need a completeness contract for its allocation feed before interpreting an absent row as zero. The extension also checks that the three seal unit IDs are unique and match on_hand.

From the directory containing ontology_lab.py, run these commands. If you have just extracted the archive, the first two rebuild and verify the baseline before migrating it. Each failure stops the sequence so an invalid build is not mistaken for an expected result.

On Linux or macOS, use .venv/bin/python in place of the Windows interpreter path. The recorded execution used Python 3.12.10 on Windows. The extension uses the baseline's pinned dependencies; it installs nothing and calls no remote service during the exercise.

Inspect extensions/multipart/results/schema.ttl, shapes.ttl, and instances.ttl. The supplied inputs produced 168 instance triples, 100 provenance triples, and three PartRequirement records across both organizations. The validation command returned conforms: true. Find WO-204 and confirm it has two requirement links and no direct part or quantity property. This checks the model change, rather than only the program's exit code.

The fixed query is extensions/multipart/requirements_inventory.rq. It follows WorkOrder → PartRequirement → PartType → StockSnapshot, binds the selected organization on every business join, and aggregates existing allocations per stock snapshot. Its key change is that the requirement is mandatory but its stock match is OPTIONAL. SPARQL's optional pattern permits a result to retain a requirement when matching stock information is absent.⁶⁰³

That matters operationally. If a seal snapshot is missing, the requirement must remain visible as unresolved; dropping the entire row could make the order look complete. The Python query handler requires exactly one in-scope stock snapshot per requirement. Missing or multiple snapshots produce a null availability and an explicit issue. It applies the baseline's two-hour freshness rule to stock, existing allocations and inspection evidence.

The actual result in extensions/multipart/results/explanation.json contains these values:

For PF-9, available = 6 on hand − 3 reserved − 2 quarantined = 1. For SEAL-2, available = 3 on hand − 0 reserved − 0 quarantined = 3. All quantities use each.

The whole order's status is shortage_needs_human_review. A surplus of seals cannot cancel a shortage of filters, so there is no summed cross-part shortage field. Each line carries its own source locators, including the original filter rows or the added seal CSV rows. The inspection remains pending, and maintenanceReleaseAllowed remains false.

Use a disposable copy of the lab. In the extension's requirements.csv, change only required_quantity from 1 to 4. The changed data row should read:

Run the query before rebuilding: it must refuse the changed source with an explicit rebuild-required error. Then rerun the extension's build, validate and query commands. PF-9 remains needed 2, available 1, shortage 1. SEAL-2 becomes needed 4, available 3, shortage 1. Restore the original quantity and rebuild before comparing with the shipped output.

This exact exercise is implemented in test_increased_second_requirement_has_its_own_shortage. It demonstrates a useful property of the new model: changing one line's quantity leaves the other line's meaning and arithmetic intact. No code change is needed for this data change because the ontology already represents one-to-many requirements.

The extension suite runs 20 tests against temporary fixture copies. Its reports are extensions/multipart/results/test-summary.json and test-results.txt; the baseline has its separate 24-test suite. These are executable acceptance checks for the local implementation, not claims of load testing or operational accreditation.

What you created: a new ontology class, explicit one-to-many relationships, a versioned migration, additional source mappings, revised constraints, a per-requirement query, and tests that check both preserved behaviour and new failure cases. What to check: both requirement identities exist, source locators resolve, the old WorkOrder fields are absent, and the observed query values match the table.

The remaining deployment work is concrete: authenticated identity, source-feed completeness, authorized reads, live revision/freshness checks, depot selection, allocation across competing orders, and durable approval/action handling. The local --org flag implements none of those services. Keep the reproducible graph and tests as the acceptance baseline when adding them.