The Shapes Constraint Language, "SHACL", is a language for validating RDF graphs against a set of conditions. SHACL has a core specification, extensions for related query languages, User Interface generation, rule-based reasoning and a data profiling mechanism. This document overviews all these parts of SHACL and serves as an introduction to all of them and related on-going work such as libraries of examples.
This documentation is published by the Data Shapes Working Group.
This document provides a non-normative, high-level, overview of the various Shapes Constraint Language (SHACL) specifications.
The second iteration of the World Wide Web Consortium's Data Shapes Working Group aimed to "...update data shapes standards in line with the versions of core Semantic Web standards that cater for RDF-star and to extend the applications of data shapes with new packaging and use specifications". The outcome of the Working Group's operations was a set of specifications - W3C 'Recommendations' - that cover core SHACL elements, extended elements for advanced validation and SHACL functions beyond validation, such as User Interface generation.
The What's new in SHACL 1.2 section below describes the changes between SHACL, as published in 2017 and SHACL 1.2, including all the new SHACL elements such as SHACL for User Interface generation.
The Specifications section below lists all the Data Shapes Working Group's specifications which are also listed in each specification's Introduction.
The appendixes below contain material supporting the set of SHACL specifications and provide SHACL users with additional support, such as validators for shapes graphs.
SHACL 1.2 covers new developments in RDF 1.2 and new developments in SPARQL 1.2. It formalizes versions of original SHACL documents published only as Notes, and takes SHACL into new areas such as rules for inferencing and profile definition.
While SHACL 1.2 does aim to cater for all aspects of [[[rdf12-concepts]]] and [[[sparql12-query]]], those specifications are not finalised while this note remains here, so coverage may not yet be complete.
The original SHACL specifications were published in 2017 and were aligned with [[[rdf11-concepts]]] and [[[sparql11-query]]]. They are listed in the SHACL Original section below. The SHACL 1.2 specifications are also listed below, in the SHACL 1.2 section.
Following are the major new things in SHACL 1.2 and the specifications in which they appear.
| New Feature | Description | SHACL 1.2 Specification |
|---|---|---|
| Derived Properties | In the original SHACL specifications, shapes and constraints could only operate on asserted triples in a graph, and inferencing was left as an optional pre-processing step using languages like RDF Schema and OWL. SHACL 1.2 introduces its own inferencing and reasoning capabilities, which make SHACL more self-contained and cover different use cases than RDFS/OWL. |
Core, Node Expr |
| Flexible Target Nodes |
In SHACL 1.2, node expressions can be used in more places than derived properties, to which they were limited in the original SHACL specifications. Particularly, they can now also be used to compute the target nodes of a shape. This provides greater flexibility than the built-in target types such as sh:targetClass and sh:targetSubjectsOf.
|
Node Expr |
| Inference Rules |
The new Inferencing Rules specification allows the representation and execution of Datalog-like inference rules which have a straight-forward mapping to SPARQL This work was inspired by the SPARQL-based rules introduced by the SHACL Advanced Features note (commonly referred to as "SHACL-AF") and older technologies such as SPIN. |
Inf Rules |
| Better Syntax for Unions of Datatypes and Classes |
In the original SHACL specifications, when you wanted to express that the datatype of a property was either xsd:string, rdf:langString, or rdf:HTML, you needed to use a verbose, repetitive construct. In SHACL 1.2, this can be written as a single list.
|
Core |
| Constraints on RDF 1.2 Reification |
The major new feature in RDF 1.2 is reification, enabling RDF statements to be easily made about other RDF statements. SHACL 1.2 introduces new constraint properties (sh:reifierShape and sh:reificationRequired) which allow a shape targeting a triple to be chained to another shape targeting reification elements.
|
Core |
| Use of Reification in Constraint Definitions | In the original SHACL specifications, the severity and messages of a constraint had to be declared for the surrounding shape, sometimes requiring artificial intermediate shapes to be introduced to change only the severity or a message. SHACL 1.2 syntax is more flexible, allowing severity and messages to be directly attached to individual constraint triples. | Core |
The sh:ShapeClass Metaclass
|
A new class, sh:ShapeClass, comparable to owl:Class, is used to define classes that can declare constraints that apply to all instances of the class. It is equivalent to OWL syntax for declaring a class that may hold OWL axioms. This allows SHACL to be a more self-contained ontology modeling language.
|
Core |
| Cleaner Separation between Core and SPARQL | We now have a cleaner separation of Core and SPARQL concerns into separate specifications. This helps indicate SHACL Core is not dependent on SPARQL, clarify other dependencies, and make some implementations easier. |
Core, SPARQL |
| A formal Compact Syntax |
The SHACL Community Group, which formed after the publication of the original SHACL specifications, produced an informal SHACL Compact Syntax Report which defines a compact syntax (sometimes referred to as SHACL-C) for core elements of the original SHACL specifications. We now have a formalization of that syntax with updates to aline with the other SHACL 1.2 specifications. |
Compact Syntax |
| A formal SHACL UI | Industry has used the original SHACL specifications for user interface generation since publication, with non-W3C extensions such as DASH. This is now formalized in a new specification. | UI |
| Profiling mechanisms defined with SHACL | SHACL has always been used to profile RDF graphs, and there are now profiles of SHACL — Core, SPARQL, UI, etc. — so a new specification has been published to define profiling mechanisms for use with SHACL, and to align with other W3C specifications, particularly the Profiles Vocabulary [[DX-PROF]]. | Profiling |
The current version of SHACL is 1.2.
The original SHACL specifications published in 2017 are listed below. They are now deprecated in favor of the SHACL 1.2 specifications, listed above.
TODO: This section will describe the governance arrangements in place for the continued maintenance of SHACL-SHACL resources, i.e., handling updates beyond the time frame of the Working Group's Charter.
The Data Shapes Working Group maintains SHACL graphs known as "SHACL-SHACL", which are used to validate other SHACL Shapes graphs. Multiple graphs exist to enable the validation of subsets within the complete body of SHACL elemenmts defined in the various SHACL specifications.
Each SHACL-SHACL graph corresponds to the scope of individual SHACL specifications and are available as RDF resources:
There is no SHACL-SHACL graph for SHACL Compact Syntax since the specification defines an RDF syntax specialised for describing SHACL concepts - and does not introduce any new concepts itself.
Additionally, the union of the above shapes graphs is also provided:
The SHACL-SHACL shapes graphs listed above can be retrieved from their namespace IRIs and are also available within the W3C SHACL Resources repository which also contains other community-generated SHACL resources.
The SHACL-SHACL Shapes graphs do not import or modify the data they evaluate, ensuring that they do not impact an organization's information when applied to it. They only report on the data's validity according to the vocabulary-subset of SHACL corresponding to the utilized Shapes graph and any imports of other SHACL-SHACL Shapes graphs (e.g., all SHACL-SHACL shapes graphs will import SHACL-SHACL Core). Additionally, they do not automatically export results anywhere beyond a SHACL processor's standard output channel.
For these reasons, this content is expected to present minimal security and privacy concerns.
Many people contributed to this document, including members of the RDF Data Shapes Working Group.