SHACL Validation

A SHACL Shape is the core building block that defines a set of constraints to validate against a group of nodes. Shapes are themselves defined as RDF resources. Key types include:

• Node Shapes: Apply constraints directly to a focus node.
• Property Shapes: Define constraints on the values of a specific property of a focus node.

For example, a shape can declare that all instances of a class ex:Person must have exactly one ex:ssn property.

A Target specifies which nodes in the RDF graph a shape applies to, defining the scope of validation. SHACL supports several target types:

• Target Class: All instances of a specified RDFS/OWL class.
• Target Node: Specific, individual nodes identified by their IRI.
• Target SubjectsOf: All nodes that are subjects of a specific predicate.
• Target ObjectsOf: All nodes that are objects of a specific predicate.

Targets enable precise, declarative selection of the data to be validated without procedural code.

Constraints are the specific rules within a shape that a focus node must satisfy. SHACL provides a rich vocabulary of constraint types:

• Datatype Constraints: e.g., sh:datatype xsd:string.
• Cardinality Constraints: e.g., sh:minCount 1, sh:maxCount 1.
• Value Range Constraints: e.g., sh:minInclusive 18.
• Logical Constraints: e.g., sh:not, sh:and, sh:or.
• Pattern Matching: e.g., sh:pattern with a regular expression.
• Closed Shapes: sh:closed true prohibits properties not explicitly listed.

Each violation generates a detailed validation result.

For complex business rules beyond core constraints, SHACL allows the definition of SPARQL Constraints. These use a sh:sparql property to embed a SPARQL query that must return no results for the data to be valid.

Key Components:

• SPARQL Query: The SELECT or ASK query that detects violations.
• Message: A human-readable failure message using sh:message.
• Prefixes: Defined via sh:prefixes.

This provides ultimate flexibility, enabling validation against external data, complex path traversals, and dynamic value comparisons.

SHACL defines three levels of Severity for constraint violations, allowing for differentiated reporting and handling:

• sh:Violation (Default): Indicates the data does not conform to the constraint. This is a critical failure.
• sh:Warning: Indicates a potential issue that may not invalidate the data but should be reviewed.
• sh:Info: Provides an informational message about the data.

Severity is set per-constraint using sh:severity. Validation reports aggregate results by severity, enabling data quality dashboards and tiered governance workflows.

The output of SHACL validation is a machine-readable Validation Report, an RDF graph conforming to the SHACL results vocabulary. It provides a complete audit trail.

Report Structure:

• sh:ValidationReport: The root node of the report.
• sh:conforms: A boolean (true/false) indicating overall success.
• sh:result: Links to individual sh:ValidationResult instances for each violation.

Each sh:ValidationResult details the focusNode, sourceShape, resultPath (property), resultMessage, and sourceConstraintComponent. This structured output is essential for automated data quality pipelines.