Jump to Table of Contents Collapse Sidebar
Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
This document defines the Core of SHACL.
SHACL, the Shapes Constraint Language, is a language for describing the structure of RDF graphs. SHACL can be used to define classes and the properties that instances of these classes can have. More general than classes and instances, SHACL introduces the notion of shapes that can formally specify constraints on the structure of RDF nodes and edges. SHACL shapes are themselves represented in RDF graphs called shapes graphs. The RDF graphs that are described by a shapes graph are called data 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 section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.
This document was published by the Data Shapes Working Group as a Working Draft using the Recommendation track.
Publication as a Working Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 18 August 2025 W3C Process Document.
This specification is part of the SHACL 1.2 family of specifications. See the SHACL 1.2 Overview for a more detailed introduction to them.
The specifications are as follows:
Working Drafts:
Working Group Note Drafts:
Implementers can partially check their level of conformance with the above specifications by successfully passing the test cases of the SHACL 1.2 test suite. Note, however, that passing all the tests in the test suite does not imply complete conformance to the specifications. It only implies that the implementation conforms to the aspects tested by the test suite.
The introduction includes a Terminology section.
Sections 2 and 3 cover SHACL shapes and constraints, as well as property paths.
Section 4 introduces node expressions, while section 5 defines validation in SHACL.
Section 6 defines the built-in SHACL Core constraint components, and section 7 discusses non-validating properties.
The syntax of SHACL is RDF. The examples in this document use Turtle [rdf12-turtle] and JSON-LD [json-ld]. Other RDF serializations such as RDF/XML may be used in practice. The reader should be familiar with basic RDF concepts [rdf12-concepts] such as triples.
This document specifies the Core of SHACL (Shapes Constraint Language), a language for describing and validating RDF graphs. This section introduces SHACL with an overview of the key terminology and an example to illustrate basic concepts.
Throughout this document, the following terminology is used.
Terminology that is linked to portions of RDF 1.2 Concepts and Abstract Syntax is used in SHACL as defined there. Terminology that is linked to portions of SPARQL 1.2 Query Language is used in SHACL as defined there. A single linkage is sufficient to provide a definition for all occurences of a particular term in this document.
Definitions are complete within this document, i.e., if there is no rule to make some situation true in this document then the situation is false.
n has a value v
for property p in an RDF graph if there is an RDF triple in the graph
with subject n, predicate p, and object v.
The phrase "Every value of P in graph G ..." means "Every object of a triple in G with predicate P ...".
(In this document, the verbs specify or declare are sometimes used to express the fact that an RDF term has values for a given predicate in a graph.)
n has value v for SPARQL property path expression
p in an RDF graph G if there is a
solution mapping in the result of the SPARQL query
SELECT ?s ?o WHERE { ?s p' ?o } on G that binds ?s to
n and ?o to v, where p' is SPARQL surface syntax for p.
G is an IRI or a blank node
that is either rdf:nil (provided that rdf:nil has no value
for either rdf:first or rdf:rest), or has exactly one value
for the property rdf:first in G and exactly one value
for the property rdf:rest in G that is also a SHACL list in G,
and the list does not have itself as a value of the property path rdf:rest+ in G.
rdf:nil in an RDF
graph G consist of its value for rdf:first in G followed by
the members in G of its value for rdf:rest in G.
The SHACL list rdf:nil has no members in any RDF graph.
Sub in an RDF graph is a SHACL subclass of another node Super
in the graph if there is a sequence of triples in the graph each with predicate rdfs:subClassOf such that the subject of the first triple is Sub,
the object of the last triple is Super, and the object of each triple except the last is the subject of the next.
If Sub is a SHACL subclass of Super in an RDF graph then Super
is a SHACL superclass of Sub in the graph.
rdf:type in the
graph as well as the SHACL superclasses of these values in the graph.
Note that some SHACL implementations can be parameterized so that the rdfs:subClassOf triples
that determine the SHACL subclasses may be queried from the shapes graph in addition to the data graph.
See 6.3 Graph for rdfs:subClassOf Triples.
n in an RDF graph G is a SHACL instance of a SHACL class C in G
if one of the SHACL types of n in G is C.
n in a graph sourceGraph,
the deep copy of n in a graph targetGraph
is n in targetGraph plus, if n is a blank node,
any triples from sourceGraph that can be reached by transitively traversing
the blank nodes that appear in the object position of a triple that can be reached
starting with n as the subject. This is similar to
the Concise Bounded Description, but without reification.
Within this document, the following namespace prefix definitions are used:
| Prefix | Namespace |
|---|---|
owl: |
http://www.w3.org/2002/07/owl# |
rdf: |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: |
http://www.w3.org/2000/01/rdf-schema# |
sh: |
http://www.w3.org/ns/shacl# |
xsd: |
http://www.w3.org/2001/XMLSchema# |
ex: |
http://example.com/ns# |
Within this document, the following JSON-LD context is used:
{
"@context": {
"owl": "http://www.w3.org/2002/07/owl#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"sh": "http://www.w3.org/ns/shacl#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"ex": "http://example.com/ns#"
}
}
Note that the URI of the graph defining the SHACL vocabulary itself is equivalent to
the namespace above, i.e., it includes the #.
References to the SHACL vocabulary, e.g., via owl:imports should include the #.
Throughout the document, color-coded boxes containing RDF graphs in Turtle, JSON-LD and SHACL-C will appear. These fragments of Turtle documents use the prefix bindings given above. The JSON-LD document fragments use the context given above. Only the Turtle documents may highlight certain parts. The SHACL-C specification is unstable - SHACL-C document fragments in this document are informative
Grey boxes such as this include syntax rules that apply to the shapes graph.
true denotes the RDF term "true"^^xsd:boolean.
false denotes the RDF term "false"^^xsd:boolean.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This document defines the SHACL Core language, also referred to as just SHACL. This specification describes conformance criteria for:
This document includes syntactic rules that shapes and other nodes need to fulfill in the shapes graph. These rules are typically of the form A shape must have... or The values of X are literals or All objects of triples with predicate P must be IRIs. The complete list of these rules can be found in the appendix. Nodes that violate any of these rules are called ill-formed. Nodes that violate none of these rules are called well-formed.
A shapes graph is well-formed if all of the following conditions hold:
owl:imports statements)
satisfies the constraints defined by Section 3.4 of the OWL 2 syntax specification [owl2-syntax], namely that it does not contain two shapes graphs where:
owl:versionIRI values), or
owl:incompatibleWith annotation whose value is equal to
either the shapes graph IRI or the owl:versionIRI of the other.
A shapes graph that is not well-formed is ill-formed.
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.
This section is non-normative.
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.
Imagine you have a set of entities (Alice, Bob, Calvin) and you want explain to a computer or another human that
ex:Person that is the type of these entities
ex:Person has at most one Social Security Number (SSN), and that SSN needs to be a properly formatted text (like 123-45-6789)
ex:Person can work for one or more companies, but those companies must be typed as a ex:Company in your data
ex:Person, other than the SSN (ex:worksFor), and the mandatory typing (rdf:type)
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.
When we run SHACL validation on our data graph using our shapes graph, the validator checks each Person against the constraints that we wrote.
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.
Here is what a SHACL validation report for this example might look like (simplified for readability):
How to read the report:
sh:ValidationReport is the overall report, with sh:conforms false meaning that there was at least one violation.
sh:ValidationResult is one problem found:
sh:resultSeverity — tells you how serious the problem is. In this example, all issues are sh:Violation (the highest and default severity).
sh:focusNode — the data node that failed.
sh:resultPath — the property involved.
sh:value — the actual value that triggered the failure.
sh:sourceConstraintComponent — which kind of constraint was broken (max count, pattern, class, etc.).
sh:sourceShape — the shape that defined the constraint.
sh:resultMessage — a human-readable explanation.
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.
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.
The following Turtle example shows these two syntactic variations in action.
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.
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.
The following introduction is non-normative.
The following informal diagram provides an overview of some of the key classes in the SHACL vocabulary.
Each box represents a class.
The boxes under the class name list a small subset of the frequently used properties
that instances of these classes may have, together with their value types.
The arrows indicate rdfs:subClassOf triples.
The Turtle serialization of the SHACL vocabulary contains the complete SHACL vocabulary.
s
that fulfills at least one of the following conditions in the shapes graph:
s is a SHACL instance of sh:NodeShape or sh:PropertyShape.
s is subject of a triple that has sh:targetClass, sh:targetNode,
sh:targetObjectsOf or sh:targetSubjectsOf as predicate.
s is subject of a triple that has a parameter as predicate.
s is a value of a shape-expecting, non-list-taking parameter such as sh:node,
or a member of a SHACL list that is a value of a shape-expecting and list-taking parameter such as sh:or.
Note that the definition above does not include all of the syntax rules of well-formed shapes.
Those are found throughout the document and summarized in Appendix A. Summary of SHACL Syntax Rules.
For example, shapes that have literals as values for sh:targetClass are ill-formed.
Informally, a shape determines how to validate a focus node based on the values of properties and other characteristics of the focus node. For example, shapes can declare the condition that a focus node be an IRI or that a focus node has a particular value for a property and also a minimum number of values for the property.
The SHACL Core language defines two types of shapes:
sh:Shape is the SHACL superclass of those two shape types in the SHACL vocabulary.
Its subclasses sh:NodeShape and sh:PropertyShape can be used as SHACL type of node and property shapes, respectively.
Shapes can declare constraints using the parameters of constraint components.
A constraint component is an IRI. Each constraint component has one or more mandatory parameters, each of which is a property. Each constraint component has zero or more optional parameters, each of which is a property. The parameters of a constraint component are its mandatory parameters plus its optional parameters.
For example, the component sh:MinCountConstraintComponent declares the parameter sh:minCount to represent the restriction
that a node has at least a minimum number of values for a particular property.
For a constraint component C with mandatory parameters p1, ... pn,
a shape s in a shapes graph SG declares a constraint
that has kind C with mandatory parameter values <p1,v1>, ... <pn,vn>
in SG when s has vi as a value for pi in SG.
For constraint components with optional parameters, the constraint declaration consists of the values that the shape has for all mandatory and optional parameters of that component.
Some constraint components declare only a single parameter.
For example sh:ClassConstraintComponent has the single parameter sh:class.
These parameters may be used multiple times in the same shape,
and each value of such a parameter declares an individual constraint.
The interpretation of such declarations is conjunction, i.e. all constraints apply.
The following example specifies that the values of ex:customer have to be SHACL instances of both
ex:Customer and ex:Person.
Some constraint components such as sh:PatternConstraintComponent declare more than one parameter.
Shapes that have more than one value for any of the parameters of such components are ill-formed.
One way to bypass this syntax rule is to spread the constraints across multiple (property) shapes, as illustrated in the following example.
Constraint components are associated with validators, which provide instructions (for example expressed via SPARQL queries) on how the parameters are used to validate data. Validating an RDF term against a shape involves validating the term against each constraint where the shape has values for all mandatory parameters of the component of the constraint, using the validators associated with the respective component.
The list of constraint components included in SHACL Core is described in section 4. SHACL-SPARQL can be used to declare additional constraint components based on SPARQL.
An RDF term that is validated against a shape using the triples from a data graph is called a focus node.
The remainder of this section is non-normative.
The set of focus nodes for a shape may be identified as follows:
sh:node)
Target declarations of a shape in a shapes graph are
triples with the shape as the subject and certain properties described in this document
(e.g., sh:targetClass) as predicates.
Furthermore, sh:shape triples can declare targets in the data graph.
Target declarations can be used to produce focus nodes for a shape.
The target of a target declaration is the set of RDF terms produced
by applying the rules described in the remainder of this section to the data graph.
The target of a shape is the union of all RDF terms produced by the individual
targets that are declared for the shape.
SHACL Core includes the following kinds of targets:
The remainder of this introduction is non-normative.
RDF terms produced by targets are not required to exist as nodes in the data graph.
Targets of a shape are ignored whenever a focus node is provided directly as input to the validation process for that shape.
This includes the cases where the shape is a value of one of the
shape-expecting constraint parameters (such as sh:node) and
a focus node is determined during the validation of the corresponding constraint component (such as sh:NodeConstraintComponent).
In such cases, the provided focus node does not need to be in the target of the shape.
A node target is specified using the sh:targetNode predicate.
Each value of sh:targetNode in a shape is a well-formed node expression.
s is a shape in a shapes graph SG and s has
value expr for sh:targetNode in SG,
then the output nodes of evalExpr(expr, data graph, s, {}) are targets
for the data graph DG as focus graph.
The remainder of this section is non-normative.
With the example data below, only ex:Alice is the target of the provided shape:
A class target is specified with the sh:targetClass predicate.
Each value of sh:targetClass in a shape is an IRI.
s is a shape in a shapes graph SG and s has value c for
sh:targetClass in SG then the set of SHACL instances of c in a data graph
DG is a target from DG for s in SG.
The remainder of this section is non-normative.
In this example, only ex:Alice and ex:Bob are focus nodes.
Note that, according to the SHACL instance definition, all the rdfs:subClassOf declarations needed to walk the class hierarchy need to exist in the data graph.
However, the ex:Person a rdfs:Class triple is not required to exist in either graphs.
In the following example, the selected focus node is only ex:Who.
Note that the rdfs:subClassOf triples may be queried from the shapes graph
(see 6.3 Graph for rdfs:subClassOf Triples) in which case the rdfs:subClassOf triple
from the example above would not be required to be in the data graph.
Informally, if a shape is also declared to be a class in the shapes graph then all SHACL instances of this class are a target for the shape.
If s is a SHACL instance of sh:NodeShape or sh:PropertyShape
in an RDF graph G and s is also a SHACL instance of
rdfs:Class in G and s is not an IRI then s is an ill-formed shape in G.
s is a SHACL instance of sh:NodeShape or sh:PropertyShape
in a shapes graph SG and s is also a SHACL instance of rdfs:Class
in SG then the set of SHACL instances of s in a data graph DG is a target from DG for s in SG.
The SHACL namespace includes a dedicated class sh:ShapeClass that can serve as a syntactic shortcut for the implicit class targets pattern.
sh:ShapeClass is an rdfs:subClassOf of both sh:NodeShape and rdfs:Class.
If s is a SHACL instance of sh:ShapeClass in a shapes graph SG
then the set of SHACL instances of s in a data graph DG is a target from DG for s in SG.
Please keep in mind that sh:ShapeClass may not be understood to be a subclass of rdfs:Class by some SHACL-unaware implementations.
It is therefore recommended (but not required) that graphs that use sh:ShapeClass include an owl:imports sh: statement.
The remainder of this section is non-normative.
In the following example, ex:Alice is a focus node, because it is a SHACL instance of
ex:Person which is both a class and a shape in the shapes graph.
In the following variation of the example above, ex:Person is declared as an instance of sh:ShapeClass,
with the same interpretation.
A subjects-of target is specified with the predicate sh:targetSubjectsOf.
The values of sh:targetSubjectsOf in a shape are IRIs.
s is a shape in a shapes graph SG and s has value
p for sh:targetSubjectsOf in SG then the set of nodes in a
data graph DG that are subjects of triples in DG with predicate
p is a target from DG for s in SG.
The remainder of this section is non-normative.
In the example above, only ex:Alice is validated against the given shape,
because it is the subject of a triple that has ex:knows as its predicate.
An objects-of target is specified with the predicate sh:targetObjectsOf.
The values of sh:targetObjectsOf in a shape are IRIs.
s is a shape in a shapes graph SG and s has value
p for sh:targetObjectsOf in SG then the set of nodes in a
data graph DG that are objects of triples in DG with predicate
p is a target from DG for s in SG.
The remainder of this section is non-normative.
In the example above, only ex:Bob is validated against the given shape,
because it is the object of a triple that has ex:knows as its predicate.
A where target is specified with the sh:targetWhere predicate.
Each value of sh:targetWhere in a shape is a well-formed shape.
s is a shape in a shapes graph SG and s has value w for
sh:targetWhere in SG then the set of nodes in a data graph
DG that conform to w is a target from DG for s in SG.
The remainder of this section is non-normative.
In this example, only ex:Bob is a focus node of ex:AdultPerson
because he conforms to the two constraints defined by the sh:targetWhere shape.
Based on the sh:class constraint, he is a SHACL instance of ex:Person
and his ex:age is 18 or greater.
However, as the ex:AdultPerson shape states that all adults must have one value for ex:votedFor,
ex:Bob does not conform to ex:AdultPerson.
Note that sh:targetWhere can be interpreted as a "definition" providing
necessary and sufficient conditions for a shape.
It can therefore potentially be used for "classification" tasks, e.g., to collect all nodes
that fulfill a given set of conditions.
As a word of caution, performance of the computation of where targets can differ between implementations. In the worst case, an engine will need to iterate over all nodes in the data graph to filter them one-by-one.
An explicit shape target is specified using the sh:shape predicate.
Each value of sh:shape is an IRI.
s is a shape in a shapes graph and
n is a node in the data graph.
If n has value s for sh:shape in the data graph,
then n is a target for s.
The remainder of this section is non-normative.
sh:shape is different from sh:targetNode, although both can be used to
link individual nodes with shapes.
sh:shape points from a specific subject node to an object shape.
Furthermore, while the sh:targetNode triples are queried from the shapes graph,
the sh:shape triples are expected in the data graph.
With the example data below, only ex:Alice is the target of the provided shape:
Shapes can specify one value for the property sh:severity in the shapes graph.
Each value of sh:severity is an IRI.
In addition to declaring severities per shape, the property sh:severity can also be used
on a reifier for a triple where the shape is the subject and one of the parameters
of the constraint is the predicate.
Let T be the set of triples that represent a constraint in a shape.
A shapes graph can specify at most one value for the property sh:severity
in the reifiers of the triples in T.
A value of sh:severity is called a severity.
SHACL includes the IRIs listed in the table below to represent severities.
These are declared in the SHACL vocabulary as SHACL instances of sh:Severity.
| Severity | Description |
|---|---|
sh:Trace |
A trace message that is not a constraint violation. |
sh:Debug |
A debug message that is not a constraint violation. |
sh:Info |
A non-critical constraint violation indicating an informative message. |
sh:Warning |
A non-critical constraint violation indicating a warning. |
sh:Violation |
A constraint violation. |
The remainder of this section is non-normative.
The validation process handles the values of sh:severity according to conformance checking.
Additionally, user interface tools may use the values to categorize validation results.
The values of sh:severity are used by SHACL processors to populate the sh:resultSeverity field of
validation results, see section on severity in validation results.
Any IRI can be used as a severity.
For every shape and constraint, sh:Violation is the default if sh:severity is unspecified.
The following example illustrates this.
The following example is a variation of the shapes graph above, but using reification to specify the severity of individual constraints:
Shapes can have values for the property sh:message.
The values of sh:message are literals with datatype
xsd:string, rdf:dirLangString, rdf:langString, or rdf:HTML.
A subject should neither have more than one value for sh:message with the same language tag,
nor multiple values with datatype xsd:string.
If a shape has at least one value for sh:message in the shapes graph, then
all validation results produced as a result of the shape will have exactly these messages
as their value of sh:resultMessage, i.e. the values will be copied from the shapes graph
into the results graph.
In addition to declaring messages per shape, the property sh:message can also be used
on a reifier for a triple where the shape is the subject and one of the parameters
of the constraint is the predicate.
Let T be the set of triples that represent a constraint in a shape.
A shapes graph can specify at most one value for the property sh:message
in the reifiers of the triples in T.
The remainder of this section is non-normative.
See the section on sh:resultMessage in the validation results
on further details on how the values of sh:resultMessage are populated.
The example from the previous section uses this mechanism to supply the second validation result with two messages. The following example is a variation where the message is declared using reification.
Shapes can have at most one value for the property sh:deactivated.
The value of sh:deactivated is a node expression
that must have either true or false as the (only) output node.
Let expr be the value of sh:deactivated in a shape.
If evalExpr(expr, data graph, focus node, {}) produces true as its only
output node, the shape is called deactivated.
Deactivated shapes are ignored during validation.
In addition to deactivating all constraints for a shape, it is also possible to deactivate individual constraints. This is done using reification.
A triple that has a shape as subject,
a parameter (such as sh:minCount) as predicate can have at most one
reifier with a value for the property sh:deactivated.
Let expr be the value of sh:deactivated in a reifier on a triple
that has shape subject and a parameter as predicate.
If evalExpr(expr, data graph, focus node, {}) produces true as its only
output node, the constraints that use the triple are called deactivated constraints.
Deactivated constraints are ignored during validation.
The remainder of this section is non-normative.
In SHACL Core, the only valid values for sh:deactivated are the
constant literal node expressions
true and false.
Use cases of this feature include shape reuse and debugging.
In scenarios where shapes from other graphs or files are imported into a given shapes graph,
sh:deactivated can be set to true in the local shapes graph for imported shapes
to exclude shapes that do not apply in the current application context.
This makes it possible to reuse SHACL graphs developed by others even if you disagree with certain assumptions made by the original authors.
If a shape author anticipates that a shape may need to be disabled or modified by others, it is a good practice to use IRIs instead of blank nodes
for the actual shapes. For example, a property shape for the property ex:name at the shape ex:PersonShape may have the IRI ex:PersonShape-name.
Another typical use case of sh:deactivated is during the development and testing of shapes, to (temporarily) disable certain shapes.
The following example illustrates the use of sh:deactivated to deactivate a shape.
In cases where shapes are imported from other graphs, the sh:deactivated true triple would be in the importing graph.
The following variation uses reification to deactivate just the sh:minCount
constraint without affecting other constraints at the same property shape.
A node shape is a shape in the shapes graph that
is not the subject of a triple with sh:path as its predicate.
It is recommended, but not required, for a node shape to be declared as a SHACL instance of sh:NodeShape.
SHACL instances of sh:NodeShape cannot have a value for the property sh:path.
Informally, node shapes specify constraints that need to be met with respect to focus nodes. In contrast to property shapes they primarily apply to the focus node itself, not to its property values.
A property shape is a shape in the shapes graph
that is the subject of a triple that has sh:path as its predicate.
A shape has at most one value for sh:path.
The value of sh:path in a property shape is a well-formed
SHACL property path.
It is recommended, but not required, for a property shape to be declared as a SHACL instance of sh:PropertyShape.
SHACL instances of sh:PropertyShape have one value for the property sh:path.
A property shape has at most one value for the property sh:values and this value is a well-formed node expression.
A property shape has at most one value for the property sh:defaultValue and this value is a well-formed node expression.
A property shape can only have values for sh:values and/or sh:defaultValue when its value for sh:path is a Predicate Path.
Informally, property shapes specify constraints that need to be met with respect to nodes that can be reached from the
focus node by
(a) directly following a given property (specified as an IRI using sh:path),
(b) directly following any other SHACL property path (specified using sh:path),
(c) evaluating the node expression specified using sh:values, or,
(d) if no other values exist, evaluating the node expression specified using sh:defaultValue.
Note that support for sh:values and sh:defaultValue is not required by SHACL Core,
but is necessary for extensions such as [shacl12-sparql].
Note that the definitions of well-formed property shapes and node shapes make these two sets of nodes disjoint.
The following example illustrates some syntax variations of property shapes.
Property paths can be used at sh:path to derive the value nodes of a property shape.
SHACL includes RDF terms to represent the following subset of SPARQL property paths:
PredicatePath, InversePath, SequencePath, AlternativePath,
ZeroOrMorePath, OneOrMorePath and ZeroOrOnePath.
The following sub-sections provide syntax rules of well-formed SHACL property paths
together with mapping rules to SPARQL 1.2 property paths.
These rules define the path mapping path(p,G) in an RDF graph G of an RDF term p that is a SHACL property path in G.
Two SHACL property paths are considered equivalent paths when they map to the exact same SPARQL property paths.
A node in an RDF graph is a well-formed SHACL property path p if it satisfies exactly one of the syntax rules in the following sub-sections.
A node p is not a well-formed SHACL property path if p is a blank node and any path mappings of p directly or transitively reference p.
The following example illustrates some valid SHACL property paths, together with their SPARQL 1.2 equivalents.
A predicate path is an IRI.
If p is a predicate path, then path(p,G) is
a SPARQL PredicatePath with p as iri.
A sequence path is a blank node that is a SHACL list with at least two members and each member is a well-formed SHACL property path.
If p is a sequence path in G with list members
v1, v2, ..., vn,
then path(p,G) is a SPARQL SequencePath of
path(v1,G) as elt1, and the results of the path mapping
of the list node of v2 as elt2.
Informal note: the nodes in such a SHACL list should not have values for
other properties beside rdf:first and rdf:rest.
An alternative path is a blank node that is the subject of exactly one triple in G.
This triple has sh:alternativePath as predicate, L as object,
and L is a SHACL list with at least two members
and each member of L is a well-formed SHACL property path.
If p is an alternative path in G,
then, for the members of its SHACL list L:
v1, v2, ..., vn,
path(p,G) is a SPARQL AlternativePath with
path(v1,G) as elt1 followed by an AlternativePath
for v2 as elt2, ..., up to path(vn,G).
An inverse path is a blank node that is the subject of exactly one triple in G.
This triple has sh:inversePath as predicate, and the object v is a well-formed SHACL property path.
If p is an inverse path in G, then path(p,G) is a
SPARQL InversePath with path(v,G) as its elt.
A zero-or-more path is a blank node that is the subject of exactly one triple in G.
This triple has sh:zeroOrMorePath as