Validating a Graph with SHACL

A nightly load adds 2.1 million triples to a clinical graph. Forty thousand of the new :Patient nodes arrive with no :birthDate, because one upstream extractor changed a column name. The ontology declares that a patient has exactly one birth date, the reasoner is running, and nothing anywhere reports a problem: under open-world semantics the missing value is simply a value not yet named. The graph is now quietly wrong, and will stay that way until a downstream query produces a number somebody doubts.

SHACL is the W3C answer to that class of failure, a Recommendation since 20 July 2017 (W3C, 2017, Shapes Constraint Language (SHACL)). It is not an ontology language and it is not trying to be.

Shapes, targets and a report that is itself data

A SHACL document is RDF. A node shape states constraints on the nodes it targets and groups property shapes, each of which constrains the values reachable along one path. Targeting is explicit: sh:targetClass for all instances of a class, sh:targetNode for named nodes, sh:targetSubjectsOf and sh:targetObjectsOf for everything on one end of a predicate. Constraint components are the familiar vocabulary of data contracts, expressed as RDF properties: sh:minCount, sh:maxCount, sh:datatype, sh:pattern, sh:in, sh:class, and sh:node to require that a value itself conforms to another shape.

:PatientShape a sh:NodeShape ;
    sh:targetClass :Patient ;
    sh:property [
        sh:path :birthDate ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:datatype xsd:date ;
        sh:severity sh:Violation ;
    ] .

The output is the part practitioners underrate. A validation run returns a sh:ValidationReport whose sh:conforms is a boolean and whose results are RDF nodes carrying the focus node, the path, the offending value, the source shape and a severity. Because the report is a graph, it can be queried, diffed against yesterday's report, joined back against provenance to find which source produced the violations, and stored as a time series. A validator that printed strings would give you none of that.

The specification splits into SHACL Core, the built-in constraint components, and SHACL-SPARQL, which lets a constraint be an arbitrary SPARQL query for the cases Core cannot express.

The closed-world turn

This is the whole point of the language and the thing that distinguishes it from OWL.

"Every patient has exactly one birth date" has two readings. OWL reads it as a licence to conclude: the birth date exists, and if two are asserted they must be equal. SHACL reads it as a test against the triples actually present: zero values is a violation, two values is a violation. SHACL's validation semantics are deliberately non-monotonic, so adding data can turn a conforming graph into a non-conforming one, which is exactly what you want from a check and exactly what a logic cannot give you.

sh:closed true makes the stance explicit: any predicate on a focus node that is not declared in the shape becomes a violation. There is no way to say that in OWL, because in OWL there is always the possibility of more being true than you wrote down.

ShEx, and when it is the better fit

ShEx is the other serious option and came out of the same W3C Data Shapes effort, though it remained a Community Group deliverable rather than entering the Recommendation track (W3C Data Shapes WG, SHACL and ShEx comparison). The practical differences: ShEx is grammar-shaped, describing the permitted structure of a node the way a schema describes a document, and it has a compact non-RDF syntax that is pleasant to write by hand. SHACL is constraint-shaped, a list of independent checks, with RDF as its only syntax. ShEx defines recursion and negation in its semantics; SHACL leaves the behaviour of recursive shapes to implementations, which is a portability hazard if you need it.

Wikidata's entity schemas are written in ShEx, which is a reasonable signal of where the compact syntax wins.

When it breaks

It is a batch job, not a type system. No mainstream store enforces shapes on write by default, so validation is something you run after the bad data has already landed. Treating SHACL as a load gate requires building that gate yourself, usually by validating a staging graph before promoting it.

sh:closed fights open vocabularies. Closed shapes are the right call for data you own and the wrong call for data you ingest, because a harmless extra predicate from an upstream source becomes a hard violation. Mixed graphs usually need closed shapes on the curated subset only.

Recursion is implementation-defined. A shape that refers to itself through sh:node may terminate, may loop, or may be rejected, depending on the engine. Portable SHACL avoids it.

Validation costs a scan per shape. sh:targetClass over a ten-billion-triple graph means enumerating every instance of that class, and a SHACL-SPARQL constraint naively evaluated runs one query per focus node. Engines that batch constraints into set-at-a-time queries are dramatically faster, and engines that do not will make you discover the difference on production volumes.

Reports need aggregation to be actionable. Forty thousand identical sh:minCount violations is one defect, not forty thousand, and nothing in the spec groups them for you. Severity levels plus a grouping query are the difference between a report somebody reads and a report somebody mutes.

Inference order changes the answer. Validating before materialisation and validating after it give different results, because entailment adds triples that shapes can see. The specification does not decide this for you, so it has to be a deliberate, documented choice in the pipeline.