Inducing SHACL Shapes From Engineering Data

The problem with hand-written shapes

SHACL lets you state what a valid graph looks like — which properties a class must carry, their datatypes, their cardinality. That is exactly what you want on an engineering model that several tools write into. The difficulty is that on a real programme nobody knows the schema. The model accreted from a Cameo export, a DOORS sync and three CSV imports, and the rules live in the heads of the people who did the imports.

Hand-writing shapes in that situation means guessing, and guesses are usually too strict. You declare sh:minCount 1 on a property that four hundred legacy elements happen to lack, the validation run produces four hundred violations, and the team turns validation off.

Deriving shapes from what the data supports

The alternative is to invert it: observe the instances, and emit only the constraints the data already satisfies. For every class appearing as an rdf:type object, emit one sh:NodeShape targeting it. For every predicate observed on that class's instances, emit a sh:property shape carrying the tightest constraints the observed data actually supports:

• sh:minCount 1 — only when the predicate occurs on every instance of the class
• sh:maxCount 1 — only when no instance uses it more than once
• sh:datatype — only when all objects are literals of a single datatype
• sh:nodeKind — when all objects are consistently IRIs, literals or blank nodes
• sh:class — when all IRI objects are typed and share one class

This is deliberately evidence-based. A shape derived this way starts green by construction: run it against the graph it came from and you get zero violations. That is the point. It is a baseline, not an aspiration.

Why a green baseline is the useful artefact

A validation suite that starts green is a drift detector. Commit the derived shapes, run them in CI, and any future import that introduces a new datatype on an existing property, drops a property that was previously universal, or starts pointing a relation at a second class will fail the run. You are not asserting what the model should look like. You are asserting that it should not silently change shape — which, on a model several tools write into, is the failure that actually bites.

The derived shapes are also a readable description of a model nobody documented. Reading two hundred lines of generated SHACL is a faster way to understand an inherited model than clicking through it.

Tightening deliberately

The derived baseline is the starting point, not the destination. Once it is committed and green, tightening is a deliberate, reviewable act:

1. Promote constraints you know are real. If a component genuinely must have an owner, add sh:minCount 1 even though eleven legacy elements violate it — and fix the eleven.
2. Add value constraints the data cannot imply. Observation gives you datatype, not range; sh:minInclusive on a mass or a voltage comes from engineering knowledge.
3. Add cross-property rules. "Every requirement with a safety level must link to a hazard" is a sh:sparql constraint, and it is the kind that catches real defects.

Each tightening step is a commit with a failing-then-passing validation run attached, which is a far better review artefact than a schema document.

Where this sits alongside OWL and SPARQL

These three do different jobs and it is worth keeping them straight, because conflating them is the usual source of confusion.

Layer	Question it answers	Behaviour on missing data
OWL	What can be inferred?	Open world: absence proves nothing
SHACL	Is this graph well-formed?	Closed world: absence is a violation
SPARQL	What is in the graph?	Returns what is there

The open-world/closed-world split is the important one. OWL will not tell you a component is missing its owner, because OWL assumes the fact might simply be stated elsewhere. SHACL exists precisely to say "not stated here is a defect." A model that needs both — inference for classification, validation for completeness — needs both engines, which is why VectorMBE runs them together rather than picking one.