Shapes Constraint Language (SHACL)

SHACL constraints are defined declaratively as shapes graphs, separate from the data they validate. A shape specifies the structure that data must conform to, using a high-level vocabulary of constraint components. This separation of validation logic from application code promotes reusability and maintainability. A shape can target specific nodes in a data graph based on their class (sh:targetClass), a specific subject (sh:targetSubjectsOf), or even all nodes with a particular property (sh:targetObjectsOf).

The SHACL Core vocabulary provides a standardized set of constraint components for common validation needs:

• Cardinality: sh:minCount, sh:maxCount to restrict the number of values for a property.
• Value Type: sh:datatype, sh:class to enforce that property values are literals of a specific type or IRIs of a specific class.
• Value Range: sh:minInclusive, sh:maxExclusive for numeric or date comparisons.
• String Patterns: sh:pattern to validate against regular expressions.
• Logical Operators: sh:not, sh:or, sh:xone to combine shapes into complex Boolean conditions.
• Property Pair Constraints: sh:equals, sh:lessThan to compare two properties on the same subject, e.g., ex:startDate must be less than ex:endDate.

A SHACL validation engine produces a standardized, machine-readable validation report as an RDF graph. This report details every constraint violation, specifying:

• The focus node that failed validation.
• The result path (the property that caused the violation).
• The value that was invalid.
• The specific constraint component that was violated.
• A human-readable sh:message or a structured sh:resultMessage. This structured output allows for seamless integration into automated data pipelines, enabling programmatic error handling and data quality dashboards.

For validation logic that goes beyond the built-in vocabulary, SHACL-SPARQL allows constraints to be defined using SPARQL queries. A sh:sparql constraint uses an ASK query (for a simple true/false violation) or a SELECT query (to generate multiple result messages). This provides an escape hatch for implementing highly customized, domain-specific validation rules, such as checking for compliance with complex business logic or cross-referencing data against external authoritative sources that cannot be expressed with the core vocabulary alone.

SHACL operates with a closed-world assumption by default, meaning that if a shape specifies a property, the validator checks that the property conforms. However, it also supports open-world scenarios. Using sh:closed set to true on a shape, you can assert that a node must have only the properties explicitly allowed by that shape, and no others. This is critical for validating API payloads or ensuring strict data schemas where extraneous properties are considered an error, providing fine-grained control over the strictness of validation.

SHACL shapes are RDF resources and can be composed and reused like any other RDF data. A shape can extend another using sh:and or include it via sh:node. This enables the creation of modular shape libraries. For example, a base shape ex:PersonShape can define core properties like name and birthdate, while a more specific shape ex:PatientShape can extend it to add medical record number and insurance provider constraints. This modularity prevents duplication and simplifies the maintenance of complex validation schemas across large ontologies.

The standardized machine-readable output produced by a SHACL validation engine. Each report conforms to the SHACL ontology and contains:

• sh:conforms — a boolean indicating overall pass/fail
• sh:result — individual validation result nodes
• sh:focusNode — the specific RDF node that violated a constraint
• sh:resultPath — the property path where the violation occurred
• sh:resultMessage — human-readable error descriptions This structure enables automated data quality dashboards and CI/CD pipeline integration.

Beyond basic cardinality and datatype constraints, SHACL supports sophisticated validation patterns:

• sh:targetClass — apply shapes to all instances of a specific OWL class
• sh:targetSubjectsOf — target nodes based on outgoing predicates
• sh:targetObjectsOf — target nodes based on incoming predicates
• sh:or / sh:and / sh:not — Boolean combinations of constraint shapes
• sh:qualifiedValueShape — validate a subset of property values against a shape
• sh:closed — disallow any properties not explicitly declared in the shape