+ SHACL uses the RDF and RDFS vocabularies, but full RDFS inferencing is not required. +
+
+ However, SHACL processors MAY operate on RDF graphs that include entailments [[!sparql12-entailment]],
+ whether pre-computed before being submitted to a SHACL processor or performed on the fly as
+ part of SHACL processing (without modifying either data graph or shapes graph).
+ To support processing of entailments, SHACL includes the property
+ sh:entailment to indicate the inferencing that is required
+ by a given shapes graph.
+
+ The values of the property sh:entailment are IRIs.
+ Common values for this property are covered by [[!sparql12-entailment]].
+
+ SHACL implementations MAY, but are not required to, support entailment regimes.
+ If a shapes graph contains any triple with the predicate sh:entailment and object E
+ and the SHACL processor does not support E as an entailment regime for the given data graph,
+ then the processor MUST signal a failure.
+ Otherwise, the SHACL processor MUST provide the entailments for all of the values of sh:entailment in the shapes graph,
+ and any inferred triples MUST be returned by all queries against the data graph during the validation process.
+
+ In this section, we will walk you through a simple example that introduces the basics of SHACL Core. + You will learn to describe how your data should look, and how a SHACL processor checks whether your data meets that description. +
+
- The following example data graph contains three SHACL instances of the class ex:Person.
+ Imagine you have a set of entities (Alice, Bob, Calvin) and you want explain to a computer or another human that
+ Here is the data we want to describe and validate: +
+ ++ Here is a self-contained example of how to represent our domain of interest. + In SHACL terminology, this is called a shapes graph, but you can also think + of this as a domain model or an ontology. +
+ + +
- We can use the shape declaration above to illustrate some of the key terminology used by SHACL.
- The target for the shape ex:PersonShape is the set of all SHACL instances of the class ex:Person.
- This is specified using the property sh:targetClass.
- During the validation, these target nodes become focus nodes for the shape.
- The shape ex:PersonShape is a node shape, which means that it applies to the focus nodes.
- It declares constraints on the focus nodes, for example using the parameters sh:closed and sh:ignoredProperties.
- The node shape also declares two other constraints with the property sh:property,
- and each of these is backed by a property shape.
- These property shapes declare additional constraints using parameters such as sh:datatype and sh:maxCount.
+ When we run SHACL validation on our data graph using our shapes graph, the validator checks each Person against the constraints that we wrote.
- Some of the property shapes specify parameters from multiple constraint components in order to
- restrict multiple aspects of the property values.
- For example, in the property shape for ex:ssn, parameters from three constraint components are used.
- The parameters of these constraint components are sh:datatype, sh:pattern and sh:maxCount.
- For each focus node the property values of ex:ssn will be validated against all three components.
+ In plain English, here is what it finds:
987-65-432A has a letter where a digit should be).
+ sh:maxCount says only one is allowed).
+ ex:UntypedCompany) that is not declared as a ex:Company.
+ ex:birthDate that is not allowed by the shape.
+ - SHACL validation based on the provided data graph and shapes graph would produce the following validation report. - See the section Validation Report for details on the format. + Here is what a SHACL validation report for this example might look like (simplified for readability):
-
- The validation results are enclosed in a validation report.
- The first validation result is produced because ex:Alice has a value for ex:ssn
- that does not match the regular expression specified by the property sh:pattern.
- The second validation result is produced because ex:Bob has more than the permitted number of values
- for the property ex:ssn as specified by the sh:maxCount of 1.
- The third validation result is produced because ex:Calvin has a value for ex:worksFor
- that does not have an rdf:type triple that makes it a SHACL instance of ex:Company.
- The forth validation result is produced because the shape ex:PersonShape has the property sh:closed set to true
- but ex:Calvin uses the property ex:birthDate which is neither one of the predicates from any of the
- property shapes of the shape, nor one of the properties listed using sh:ignoredProperties.
+ While SHACL is primarily designed to represent shapes, it also borrows terms and concepts such as
+ rdfs:Class and rdfs:subClassOf from the RDF Schema namespace.
+ Some people prefer to keep those concepts separate, as shown in the original example above
+ which had separate entities for ex:Person and ex:PersonShape.
+ However, it is also possible to couple them more closely together, and use sh:ShapeClass
+ to declare both a class and a shape at the same time.
- SHACL uses the RDF and RDFS vocabularies, but full RDFS inferencing is not required. + Furthermore, sometimes you will see property shapes declared as blank nodes instead of IRIs. + This is a more compact notation, but it means that the property shape cannot easily be referenced from + the outside; for example, if some other graph wants to reuse a node shape but deactivate a property shape.
- However, SHACL processors MAY operate on RDF graphs that include entailments [[!sparql12-entailment]] -
- either pre-computed before being submitted to a SHACL processor or performed on the fly as
- part of SHACL processing (without modifying either data graph or shapes graph).
- To support processing of entailments, SHACL includes the property
- sh:entailment to indicate what inferencing is required
- by a given shapes graph.
+ The following Turtle example shows these two syntactic variations in action.
- The values of the property sh:entailment are IRIs.
- Common values for this property are covered by [[!sparql12-entailment]].
+
+
+ We can use the shape declarations above to introduce some of the formal terminology used by SHACL. + This may help you read the remainder of this specification.
- SHACL implementations MAY, but are not required to, support entailment regimes.
- If a shapes graph contains any triple with the predicate sh:entailment and object E
- and the SHACL processor does not support E as an entailment regime for the given data graph
- then the processor MUST signal a failure.
- Otherwise, the SHACL processor MUST provide the entailments for all of the values of sh:entailment in the shapes graph,
- and any inferred triples MUST be returned by all queries against the data graph during the validation process.
+ The target for the shape ex:PersonShape is the set of all SHACL instances of the class ex:Person.
+ This is specified using the property sh:targetClass.
+ During the validation, these target nodes become focus nodes for the shape.
+ The shape ex:PersonShape is a node shape, which means that it applies to the focus nodes.
+ It declares constraints on the focus nodes, for example using the parameters sh:closed and sh:ignoredProperties.
+ The node shape also declares two other constraints with the property sh:property,
+ and each of these is backed by a property shape.
+ These property shapes declare additional constraints using parameters such as sh:datatype and sh:maxCount.
+ Some of the property shapes specify parameters from multiple constraint components in order to
+ restrict multiple aspects of the property values.
+ For example, in the property shape for ex:ssn, parameters from three constraint components are used.
+ The parameters of these constraint components are sh:datatype, sh:pattern and sh:maxCount.
+ For each focus node the property values of ex:ssn will be validated against all three components.
+