This document provides an overview of SHACL.
SHACL, the Shapes Constraint Language, is a language for describing the structure of RDF graphs. SHACL may be used for a variety of purposes such as validating, inferencing, modeling domains, generating ontologies to inform other agents, building user interfaces, generating code, and integrating data.
This document provides a non-normative, high-level, overview of the various SHACL specifications and how SHACL has changed between its original and 1.2 releases. It also describes and lists some SHACL resources not found in the specification documents.
This documentation is published by the Data Shapes Working Group.
The current version of SHACL is 1.2.
Working Drafts:
Working Group Note Drafts:
The original SHACL specifications published in 2017 are listed below. They are now deprecated in favor of the SHACL 1.2 specifications, listed above.
Working Drafts:
Working Group Note Drafts:
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 rule evaluation, User Interface generation and the packaging of SHACL.
Section [[[#specifications]]] above lists the Data Shapes Working Group's original and current (1.2) specifications.
Section [[[#whatsnew]]] below describes the changes between SHACL, as published in 2017 and SHACL 1.2.
Section [[[#community-resources]]] below describes SHACL resources managed by W3C groups following on from the Data Shapes Working Group.
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 SHACL Rules specification allows the representation and execution of Datalog-based 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. |
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 |
| SHACL profiling mechanisms defined |
SHACL has always been used to profile RDF graphs and there are now known profiles of SHACL, so a new specification, [[[shacl12-profiling]]], has been published to define profiling mechanisms to ensure future profiling consistency. [[[shacl12-profiling]]] also aligns profiling of and with SHACL to other W3C specifications, in particular the [[[dx-prof]]]. |
Profiling |
| SHACL community resources | Since the original SHACL, the using community has created distributed resources. As of SHACL 1.2, the W3C has designated a central storage place for community-managed resources to assist with discovery and reuse. The SHACL Resources repository: https://github.com/w3c/shacl-resources. | All |
Since the initial publication of the original SHACL specifications, the SHACL user community has generated a lot of resources, some of which would benefit everyone by being shared for reuse.
A version control repository has been established by the W3C for shared SHACL resources:
The SHACL community is encouraged to use that repository by improving the existing resources there, submitting new useful resources and by providing references to other interesting resources.
The Data Shapes Working Group maintains SHACL Shapes Graphs known as "SHACL-SHACL", which are used to validate other SHACL Shapes Graphs. Multiple graphs exist to enable the validation of subsets of the complete body of SHACL elements. The subsets are based on the scopes of the various SHACL specifications.
Each SHACL-SHACL Shapes Graph corresponds to the scope of an individual SHACL specification and is available as an RDF resource:
There is no shapes 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.
In addition, the union of the above shapes graphs is provided:
The SHACL-SHACL Shapes Graphs listed above can be retrieved from their namespace IRIs and are also available as described in Section [[[#community-resources]]].
The Data Shapes Working Group maintains a SHACL graph known as "SHACL-OWL", which is used to cast SHACL concepts as OWL classes and properties, conformant to typing constraints of OWL 2 DL. This graph enables OWL 2 DL validation for ontologies that use SHACL and OWL modeling concepts together within ontology graphs.
SHACL concepts appear undefined from the perspective of an OWL syntax validator, unless OWL type assertions have been inlined somehow in the OWL validator's inputs. Definitions for SHACL rdfs:Classes are straightforward, but property types face potential decision points. Typing constraints of OWL 2 DL require that exactly one of owl:ObjectProperty, owl:DatatypeProperty, or owl:AnnotationProperty be the type of any property used in an OWL ontology but SHACL does not specify typing like this. SHACL-OWL provides these types, designating most SHACL properties as owl:AnnotationProperty unless a reason was found by the Data Shapes Working Group to use another type.
SHACL-OWL is available as an RDF resource:
The SHACL-OWL Shapes Graph listed above can be retrieved from its namespace IRIs and also as described in Section [[[#community-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.