SHACL for knowledge graphs: a practical validation checklist

OWL and SHACL do different jobs

OWL reasons under an open-world assumption: a missing fact is unknown, not false, and the language is built to infer new facts from the ones you have. SHACL validates the data graph as it stands, so a missing required property is a violation⁵. The W3C Recommendation describes this as checking "data graphs" against conditions in "shapes graphs"¹.

Combining the two is not trivial. Research from TU Wien describes the semantic gap between OWL reasoning and SHACL validation as a major challenge, and notes conflicts, for example between reasoning and closed shapes⁵. In practice I keep them in separate stages and decide explicitly whether validation runs before or after inference.

The checklist

1. Write shapes for the entities that matter first. Customer, product, patient, supplier: whatever your use cases depend on. Cardinality, datatypes, allowed values and required relationships cover most real problems.
2. Validate at the boundary. Run SHACL on each source's data before it joins the main graph, so bad data is quarantined with a report rather than merged.
3. Use severities deliberately. Not every failure should block a load. Separate hard violations from warnings, and route warnings to the data owner instead of the pipeline.
4. Decide where inference sits. If you validate after reasoning, test that inferred facts don't create spurious violations, particularly with closed shapes⁵.
5. Keep shapes in version control next to the ontology, reviewed like code and changed through the same process. A shape change can reject yesterday's valid data.
6. Track validation results over time. Violation counts per source and per shape are a data quality metric the business can understand.
7. Validate what AI writes. When an LLM extracts entities into the graph, as in GraphRAG, run its output through the same shapes. Extraction errors are cheap to catch at the door and expensive to find later.
8. Pair with entity resolution. Shapes catch malformed records; they don't catch two records for the same customer. That needs entity resolution.

Where the standard is going

SHACL became a W3C Recommendation in July 2017, with Core constraints and SPARQL-based extensions¹². The W3C Data Shapes Working Group is now developing SHACL 1.2, with 2026 Working Drafts for Core and for Node Expressions among others³⁴. They are drafts and may change, so I build on the 2017 Recommendation and track 1.2 for features worth adopting once they settle.

Why this matters for AI

Knowledge graphs are increasingly the grounding layer for LLM applications. A graph that answers confidently with malformed or contradictory data is worse than no graph, because the model will present it fluently. Validation is what makes a graph trustworthy enough to ground AI, and it fits the layered model in ontology vs knowledge graph vs semantic layer.

How I can help

I design ontologies, shapes and validation pipelines for enterprise knowledge graphs, so they stay trustworthy as sources and AI extraction grow. See ontology and knowledge graphs, or analyse your challenge and bring the result to a call.