SHACL Constraints

SHACL defines constraints through shapes—templates that describe the expected structure of data nodes. A shape specifies which properties a node must have, their cardinality, and their data types. For example, a shape for a manufacturing asset might require exactly one hasSerialNumber property with an xsd:string value, ensuring every asset record is identifiable before it enters a predictive maintenance pipeline.

Node constraints validate the intrinsic properties of a single RDF node without considering its relationships. These include:

• Datatype constraints: Ensuring a temperature reading is an xsd:decimal, not a string
• Value range constraints: Requiring sh:minInclusive and sh:maxInclusive to bound sensor values
• Pattern constraints: Using sh:pattern with regular expressions to validate part numbers or batch codes
• Enumeration constraints: Restricting a failure mode to a controlled vocabulary via sh:in

SHACL can validate not just direct properties but also indirect relationships through property paths. Using sh:path, constraints can traverse chains of predicates. In manufacturing, this validates that a Bill of Materials component ultimately connects to an approved supplier—traversing multiple hasSubComponent and sourcedFrom edges—without materializing intermediate results. This enables deep structural validation of complex assemblies.

Cardinality constraints enforce the minimum and maximum number of values for a property. Critical for manufacturing data integrity:

• sh:minCount 1 ensures a machine has at least one maintenance schedule
• sh:maxCount 1 prevents duplicate serial number assignments
• sh:qualifiedValueShape applies cardinality to filtered subsets, such as requiring exactly one primary temperature sensor per zone while allowing multiple secondary sensors

SHACL supports if-then logic through sh:condition. A shape can declare that if a certain pattern holds, then additional constraints must apply. For example: IF a machine's operationalStatus is Active, THEN it must have a lastCalibrationDate within the past 90 days. This enables context-sensitive validation that adapts to the state of each asset in the knowledge graph.

SHACL defines three severity levels for constraint violations:

• sh:Violation: A hard error that must be fixed
• sh:Warning: An anomaly that should be reviewed
• sh:Info: A notification for audit purposes Validation engines produce a validation report conforming to the SHACL ontology, listing each violation with its focus node, violated shape, and human-readable message. This structured output integrates directly into data quality dashboards.

The formal conceptual model that SHACL shapes reference. A manufacturing ontology defines the vocabulary—classes like Pump, Valve, and FailureMode—and their permissible relationships. SHACL then enforces that actual instance data respects these definitions. Without a well-engineered ontology, SHACL constraints lack semantic grounding; without SHACL, ontologies lack an enforcement mechanism for data quality.

The process of deduplicating and linking records that refer to the same physical asset. SHACL constraints can enforce uniqueness rules—for example, ensuring that no two nodes share the same serialNumber property. After entity resolution merges duplicate records, SHACL re-validates the graph to confirm that the unified golden record satisfies all integrity constraints, preventing corrupted merges from propagating downstream.

A knowledge graph that explicitly models time-annotated facts. SHACL can validate temporal constraints such as 'a MaintenanceTask must have a completionTime that occurs after its startTime.' In manufacturing root cause analysis, SHACL ensures that the chronological sequence of sensor readings and failure events is logically consistent before causal algorithms process the timeline.