ex:Alice a ex:Person .
ex:Bob a ex:Person ;
ex:age 21 .
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.
Explicit shape targets (sh:shape)
An explicit shape target is specified using the sh:shape predicate.
Each value of sh:shape is an IRI .
The remainder of this section is informative.
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:
Declaring the Severity of a Shape or Constraint
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:TraceA trace message that is not a constraint violation.
sh:DebugA debug message that is not a constraint violation.
sh:InfoA non-critical constraint violation indicating an informative message.
sh:WarningA non-critical constraint violation indicating a warning.
sh:ViolationA constraint violation.
The remainder of this section is informative.
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.
ex:MyShape
a sh:NodeShape ;
sh:targetNode ex:MyInstance ;
sh:property ex:MyShape-myProperty1 ;
sh:property ex:MyShape-myProperty2 ;
.
ex:MyShape-myProperty1
# Violations of sh:minCount and sh:datatype are produced as warnings
a sh:PropertyShape ;
sh:path ex:myProperty ;
sh:minCount 1 ;
sh:datatype xsd:string ;
sh:severity sh:Warning ;
.
ex:MyShape-myProperty2
# The default severity here is sh:Violation
a sh:PropertyShape ;
sh:path ex:myProperty ;
sh:maxLength 10 ;
sh:message "Too many characters"@en ;
sh:message "Zu viele Zeichen"@de ;
.
ex:MyInstance
ex:myProperty "http://toomanycharacters"^^xsd:anyURI .
[
a sh:ValidationReport ;
sh:conforms false ;
sh:result [
a sh:ValidationResult ;
sh:resultSeverity sh:Warning ;
sh:focusNode ex:MyInstance ;
sh:resultPath ex:myProperty ;
sh:value "http://toomanycharacters"^^xsd:anyURI ;
sh:sourceConstraintComponent sh:DatatypeConstraintComponent ;
sh:sourceShape ex:MyShape-myProperty1 ;
] ,
[
a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:MyInstance ;
sh:resultPath ex:myProperty ;
sh:value "http://toomanycharacters"^^xsd:anyURI ;
sh:resultMessage "Too many characters"@en ;
sh:resultMessage "Zu viele Zeichen"@de ;
sh:sourceConstraintComponent sh:MaxLengthConstraintComponent ;
sh:sourceShape ex:MyShape-myProperty2 ;
]
] .
The following example is a variation of the shapes graph above, but using reification to
specify the severity of individual constraints:
Declaring Messages for a Shape or Constraint
Shapes can have values for the property sh:message.
The values of sh:message are either xsd:string literals or literals with a language tag.
A subject should not have more than one value for sh:message with the same language tag.
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 informative.
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.
Deactivating Shapes and Constraints
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 informative.
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.
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:PersonShape-name .
ex:PersonShape-name
a sh:PropertyShape ;
sh:path ex:name ;
sh:minCount 1 ;
sh:deactivated true .
With the following data, no constraint violation will be reported even though the instance does not have any value for ex:name.
The following variation uses reification to deactivate just the sh:minCount
constraint without affecting other constraints at the same property shape.
SHACL Property Paths
Property paths can be used at sh:pathvalue 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.
Predicate Paths
A predicate path is an IRI .
If p is a predicate path , then path(p,G) is
a SPARQL PredicatePath with p as iri.
Sequence Paths
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.
Alternative Paths
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).
Inverse Paths
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.
Node Expressions
This section introduces the concept of node expressions .
SHACL Core supports node expressions in the following features:
Readers who are only interested in SHACL Core can typically skip this section.
Given that Core only supports constant IRIs and literals as node expressions, the use cases of node expressions
are identical to traditional use of SHACL Core.
A
node expression is a
node that follows the syntax rules of exactly one
node expression function .
Each
node expression function has an
IRI as its
function name .
The
evaluation of a node expression is defined as a function
evalExpr(expr, focusGraph, focusNode, scope) -> outputNodes
where
expr is a node expression in a shapes graph .
During evaluation, the engine can access triples related to expr in the shapes graph .focusGraph is a graph , called the focus graph . This is the default query graph for the evaluation of the node expression.focusNode is a node , called the input focus node . This variable may have no value.scope is a map from (key) terms to individual (value) terms .
The empty map is written as {}.
The result of the evaluation of a node expression is a list of
nodes (possibly empty and with duplicates) called the
output nodes .
The evaluation may also result in an
evaluation failure .
The SHACL Core specification only exactly defines the node expression functions based on the next two subsections.
Other specifications such as [[shacl12-sparql]] introduce additional functions, using blank nodes .
Therefore node expressions serve as an extension point of SHACL.
TODO: Add link to shacl12-node-expr once that is stable.
Validation and Graphs
Validation takes a data graph and a shapes graph as input and produces
a validation report containing the results of the validation.
Conformance checking is a simplified version of validation, producing a boolean result.
A system that is capable of performing validation is called a processor ,
and the verb processing is sometimes used to refer to the validation process.
SHACL defines an RDF Validation Report Vocabulary that can be used by processors that produce validation reports as RDF results graphs.
This specification uses the SHACL results vocabulary for the normative definitions of the validators
associated with the constraint components .
Only SHACL implementations that can produce all of the mandatory properties of the Validation Report Vocabulary are standards-compliant.
Shapes Graph
A shapes graph is an RDF graph containing zero or more shapes
that is passed into a SHACL validation process so that a data graph can be validated against the shapes.
The remainder of this section is informative.
Shapes graphs can be reusable validation modules that can be cross-referenced with the predicate owl:importsshapes graph by transitively following and importing all referenced shapes graphs
through the owl:importsshapes graph for validation and MUST NOT be further modified during the validation process.
In addition to shape declarations, the shapes graph may contain additional information for the SHACL processor such as sh:entailment statements.
Data Graph
Any RDF graph can be a data graph .
The remainder of this section is informative.
A data graph is one of the inputs to the SHACL processor for validation .
SHACL processors treat it as a general RDF graph and makes no assumption about its nature.
For example, it can be an in-memory graph or a named graph from an RDF dataset or a SPARQL endpoint.
SHACL can be used with RDF graphs that are obtained by any means, e.g. from the file system, HTTP requests, or RDF datasets .
SHACL makes no assumptions about whether a graph contains triples that are entailed from the graph under any RDF entailment regime.
The data graph is expected to include all the ontology axioms related to the data and especially all the
rdfs:subClassOf triples in order for SHACL to correctly identify class targets and validate Core SHACL constraints.
owl:imports in the data graph is not enacted, in order to avoid uncontrolled increase of validation work. If you want to validate
several related ontologies, pass all of them to the SHACL processor (together or one by one), do not rely on owl:imports links.
Graph for rdfs:subClassOf Triples
Some features of SHACL (such as
SHACL type to determine whether a node is a SHACL instance of a given class.
By default, this is determined by looking up rdfs:subClassOf and rdf:type triples
in the data graph .
However, this is insufficient in some cases, as rdfs:subClassOf triples are often stored as part
of the class and/or shape definitions and not the instance data.
SHACL processors SHOULD offer a parameter subClassOfInShapesGraph that, if set to true,
should alter the definition of SHACL Type so that the rdfs:subClassOf triples are queried
from the shapes graph in addition to the data graph .
The rdf:type triples are always expected to be in the data graph .
Linking to shapes graphs (sh:shapesGraph)
A data graph can include triples used to suggest one or more graphs to a SHACL processor with the predicate sh:shapesGraph.
Every value of sh:shapesGraph is an IRI representing a graph that SHOULD be included into the shapes graph used to validate the data graph .
In the following example, a SHACL processor SHOULD use the union of ex:graph-shapes1 and ex:graph-shapes2 graphs (and their owl:imports) as the shapes graph when validating the given graph.
Validation
Validation is a mapping from some input
to validation results , as defined in the following paragraphs.
Validation of a data graph against a shapes graph:
Given a data graph and a shapes graph ,
the validation results are the union of results of the validation of the data graph against all
shapes in the shapes graph .
Validation of a data graph against a shape:
Given a data graph and a shape in the shapes graph ,
the validation results are the union of the results of the validation of all
focus nodes that are in the target of the shape in the data graph .
Validation of a focus node against a shape:
Given a focus node in the data graph and a shape in the shapes graph ,
the validation results are the union of the results of the validation of the focus node against all
constraints declared by the shape , unless the shape has been deactivated ,
in which case the validation results are empty.
Validation of a focus node against a constraint:
Given a focus node in the data graph and a constraint of kind C in the shapes graph ,
the validation results are defined by the validators of the constraint component C.
These validators typically take as input the focus node , the specific values of the parameters of C
of the constraint in the shapes graph , and the value nodes of the shape that declares the constraint.
During validation, the data graph and the shapes graph MUST remain immutable, i.e. both graphs at the end of the validation MUST be identical to the graph at the beginning of validation.
SHACL processors MUST NOT change the graphs that they use to construct the shapes graph or the data graph,
even if these graphs are part of an RDF store that allows changes to its stored graphs.
SHACL processors MAY store the graphs that they create, such as a graph containing validation results,
and this operation MAY change existing graphs in an RDF store, but not any of the graphs that were used to construct the shapes graph or the data graph.
SHACL processing is thus idempotent.
Failures
Validation and conformance checking can result in a failure .
For example, a particular SHACL processor might allow recursive shapes but report a failure
if it detects a loop within the data.
Failures can also be reported due to resource exhaustion.
Failures are signalled through implementation-specific channels.
Handling of Recursive Shapes
The following properties are the so-called shape-expecting constraint parameters in SHACL Core:
The following properties are the so-called list-taking constraint parameters in SHACL Core:
A shape s1 in an RDF graph G refers to shape s2
in G if it has s2 as value for some non-list-taking,
shape-expecting parameter of some constraint component or s2 as a member of
the value for some list-taking, shape-expecting parameter of some constraint component.
A shape in an RDF graph G is a recursive shape in G if it is related to
itself by the transitive closure of the refers relationship in G.
The validation with recursive shapes is not defined in SHACL and is left to SHACL processor implementations.
For example, SHACL processors may support recursion scenarios or produce a failure when they detect recursion.
The remainder of this section is informative.
The recursion policy above has been selected to support a large variety of implementation strategies.
By leaving recursion undefined, implementations may chose to not support recursion so that they
can issue a static set of SPARQL queries (against SPARQL end points) without having to support cycles.
The Working Group is aware that other implementations may support recursion and that some shapes graphs may
rely on these specific characteristics.
The expectation is that future work, for example in W3C Community Groups, will lead to the definition
of specific dialects of SHACL where recursion is well-defined.
Validation Report
The validation report is the result of the validation process that reports the conformance and the set of all validation results .
The validation report is described with the SHACL Validation Report Vocabulary as defined in this section.
This vocabulary defines the RDF properties to represent structural information that may provide guidance on how to identify or fix violations in the data graph.
SHACL-compliant processors MUST be capable of returning a validation report with all required validation results
described in this specification.
SHACL-compliant processors MAY support optional arguments that make it possible to limit the number of returned results.
This flexibility is for example needed in some large-scale dataset validation use cases.
The following graph represents an example of a validation report for the validation of a data graph that conforms to a shapes graph.
The following graph represents an example of a validation report for the validation of a data graph that does not conform to a shapes graph.
Note that the specific value of sh:resultMessage is not mandated by SHACL and considered implementation-specific.
Validation Report (sh:ValidationReport)
The result of a validation process is an RDF graph with exactly one SHACL instance of sh:ValidationReport.
The RDF graph MAY contain additional information such as provenance metadata.
Result (sh:result)
For every validation result that is produced by a validation process
(except those mentioned in the context of conformance checking ),
the SHACL instance of sh:ValidationReport in the results graph has a value for the property sh:result.
Each value of sh:result is a SHACL instance of the class sh:ValidationResult.
Validation Result (sh:ValidationResult)
SHACL defines sh:ValidationResult as a subclass of sh:AbstractResult to report individual SHACL validation results .
SHACL implementations may use other SHACL subclasses of sh:AbstractResult, for example,
to report successfully completed constraint checks or accumulated results.
All the properties described in the remaining sub-sections of this section can be specified in a sh:ValidationResult.
The properties sh:focusNode, sh:resultSeverity and sh:sourceConstraintComponent
are the only properties that are mandatory for all validation results.
Focus node (sh:focusNode)
Each validation result has exactly one value for the property sh:focusNode
that is equal to the focus node that has caused the result.
This is the focus node that was validated when the validation result was produced.
Value (sh:value)
Validation results may include, as a value of the property sh:value,
at most one RDF term that has caused the result.
The textual definitions of the validators of the SHACL Core components specify how this
value is constructed - often they are the value nodes that have violated a constraint.
Source (sh:sourceShape)
Validation results may include, as the only value of the property sh:sourceShape,
the shape that the given sh:focusNode was validated against.
Constraint Component (sh:sourceConstraintComponent)
Validation results have exactly one value for the property sh:sourceConstraintComponent
and this value is the IRI of the constraint component that caused the result.
For example, results produced due to a violation of a constraint based on a value of sh:minCount
would have the source constraint component sh:MinCountConstraintComponent.
Details (sh:detail)
The property sh:detail may link a (parent) result with one or more SHACL instances of
sh:AbstractResult that can provide further details about the cause of the (parent) result.
Depending on the capabilities of the SHACL processor, this may for example include violations of
constraints that have been evaluated as part of conformance checking via sh:node.
Message (sh:resultMessage)
Validation results may have values for the property sh:resultMessage,
for example to communicate additional textual details to humans.
While sh:resultMessage may have multiple values, there should not be two values with the same language tag.
These values are produced by a validation engine based on the values of sh:message of the constraints
in the shapes graph, see Declaring Messages for a Shape .
Messages declared using reification have precedence over those declared at the surrounding shape.
In cases where a constraint does not have any values for sh:message in the shapes graph the
SHACL processor MAY automatically generate other values for sh:resultMessage.
Severity (sh:resultSeverity)
Each validation result has exactly one value for the property sh:resultSeverity, and this value is an IRI .
The value is determined by the following rules (in order):
the value of sh:severityreifier of any of the triples containing the parameters of the constraint that caused the result
the value of sh:severityshape in the shapes graph that caused the result
defaulting to sh:Violation if no sh:severity has been specified for the shape or constraint.
Value Nodes
The validators of most constraint components use the concept of value nodes , which is defined by the following two sub-sections.
Core Constraint Components
This section defines the built-in SHACL Core constraint components that MUST be supported by all SHACL Core processors.
The definition of each constraint component contains its IRI as well as a table of its parameters .
Unless stated otherwise, all these parameters are mandatory parameters .
Shapes that violate any of the syntax rules enumerated in those parameter tables are ill-formed .
Each constraint component also includes a textual definition, which describes the validator associated with the component.
These textual definitions refer to the values of the parameters in the constraint by variables of the form
$paramName where paramName is the part of the parameter's IRI after the sh: namespace.
For example, the textual definition of sh:ClassConstraintComponent refers to the value of
sh:class using the variable $class.
In SHACL Core, the term parameter value means the value of a parameter,
i.e. the object of the triple in the shapes graph where the subject is the shape
and the predicate is the parameter (such as sh:class).
At the time of writing, the intent of the WG is to define a dialect of SHACL outside of SHACL Core in which the term
parameter value also allows node expressions .
Note that not all constraint components use the term parameter value but instead refer to the term value .
For example, the values of sh:node cannot ever be node expressions , because this would complicate
the handling of blank nodes.
TODO: Add link to Node Expression spec in case it's ready, or clarify the sentences above otherwise.
Note that these validators define the only validation results that are being produced by the component.
Furthermore, the validators always produce new result nodes, i.e. when the textual definition states that
"...there is a validation result..." then this refers to a distinct new node in a results graph.
The remainder of this section is informative.
The choice of constraint components that were included into the SHACL Core was made based on
the requirements collected by the [[shacl-ucr]] document.
Special attention was paid to the balance between trying to cover as many common use cases as possible
and keeping the size of the Core language manageable.
Not all use cases can be expressed by the Core language alone.
Instead, SHACL-SPARQL provides an extension mechanism, described in the second part of this specification.
It is expected that additional reusable libraries of constraint components will be maintained by third parties.
Unless stated otherwise, the Core constraint components can be used both in property shapes and node shapes .
Some constraint parameters have syntax rules attached to them that would make node shapes that use these parameters ill-formed .
Examples of this include sh:minCount which is only supported for property shapes .
Value Type Constraint Components
The constraint components in this section have in common that they can be used to restrict the type of value nodes.
Note that it is possible to represent multiple value type alternatives using sh:or .
sh:class
The condition specified by sh:class is that each value node is a SHACL instance of the given type(s).
Constraint Component IRI : sh:ClassConstraintComponent
Parameters:
Let
$class be a
parameter value for
sh:class.
Let
classes be a set of
IRIs so that
when
$class is an
IRI then the set only consists of exactly that IRI,
and when
$class is a
blank node SHACL list then the set consists of
exactly the members of the list.
For each
value node
that is either a
literal , or a non-literal that is not a
SHACL instance of any of the
classes in the
data graph ,
there is a
validation result with the
value node as
sh:value.
The remainder of this section is informative.
Note that multiple values for sh:class are interpreted as a conjunction,
i.e., the values need to be SHACL instances of all of them.
Use lists for union semantics.
ex:ClassExampleShape
a sh:NodeShape ;
sh:targetNode ex:Bob, ex:Alice, ex:Carol ;
sh:property ex:ClassExampleShape-address ;
.
ex:ClassExampleShape-address
a sh:PropertyShape ;
sh:path ex:address ;
sh:class ex:PostalAddress ;
.
ex:Alice a ex:Person .
ex:Bob ex:address [ a ex:PostalAddress ; ex:city ex:Berlin ] .
ex:Carol ex:address [ ex:city ex:Cairo ] .
The following example illustrates the list-based syntax for sh:class,
meaning that the values of the property ex:pet must be either cats or dogs.
ex:ClassListExampleShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:ClassListExampleShape-pet ;
.
ex:ClassListExampleShape-pet
a sh:PropertyShape ;
sh:path ex:pet ;
sh:class ( ex:Cat ex:Dog ) ;
.
ex:Tessie a ex:Cat .
ex:Rusty a ex:Dog .
ex:Fluffy a ex:Unicorn .
ex:Alice a ex:Person ; ex:pet ex:Tessie, ex:Rusty .
ex:Bob a ex:Person ; ex:pet ex:Fluffy .
sh:datatype
sh:datatype specifies a condition to be satisfied with regards to the datatype of each value node .
Constraint Component IRI : sh:DatatypeConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:datatype
The allowed datatype(s) of all value nodes (e.g., xsd:integer).
A shape has at most one value for sh:datatype.
The value of sh:datatype in a shape is either an IRI
or a blank node that is a well-formed SHACL list where all members are IRIs .
Let
$datatype be a
parameter value for
sh:datatype.
Let
datatypes be a set of
IRIs so that
when
$datatype is an
IRI then the set only consists of exactly that IRI,
and when
$datatype is a
blank node SHACL list then the set consists of
exactly the members of the list.
For each
value node
that is not a
literal , or is a
literal with a datatype that matches none of the
datatypes,
there is a
validation result with the
value node as
sh:value.
The datatype of a literal is determined following the
datatype function of SPARQL 1.2.
A
literal matches a datatype if the
literal 's datatype has the same
IRI
and, for the datatypes supported by SPARQL 1.2, is not an
ill-typed literal.
The remainder of this section is informative.
The values of sh:datatype are typically datatypes , such as xsd:string.
ex:DatatypeExampleShape
a sh:NodeShape ;
sh:targetNode ex:Alice, ex:Bob, ex:Carol ;
sh:property ex:DatatypeExampleShape-age ;
.
ex:DatatypeExampleShape-age
a sh:PropertyShape ;
sh:path ex:age ;
sh:datatype xsd:integer ;
.
ex:Alice ex:age "23"^^xsd:integer .
ex:Bob ex:age "twenty two" .
ex:Carol ex:age "23"^^xsd:int .
The following example illustrates the list-based syntax, meaning that all values of
rdfs:label must be either xsd:string or rdf:langString.
Note that using rdf:langString as value of sh:datatype can be used to test if value nodes have a language tag.
ex:TextExampleShape
a sh:NodeShape ;
sh:targetNode ex:Estonia, ex:GreatBritain ;
sh:property ex:TextExampleShape-label ;
.
ex:TextExampleShape-label
a sh:PropertyShape ;
sh:path rdfs:label ;
sh:datatype ( xsd:string rdf:langString ) ;
.
ex:Estonia rdfs:label "Estonia", "Estland"@de .
ex:GreatBritain rdfs:label "Great Britain", "<b>Great</b> Britain"^^rdf:HTML .
sh:nodeKind
sh:nodeKind specifies a condition to be satisfied by the RDF node kind of each value node .
Constraint Component IRI : sh:NodeKindConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:nodeKind
The node kind (IRI, blank node, literal, triple term, or combination of these) of all value nodes.
A shape has at most one value for sh:nodeKind.
The value of sh:nodeKind in a shape is either an IRI or a blank node that is a well-formed SHACL list where all members are IRIs.
If the values of sh:nodeKind are IRIs, then the values of sh:nodeKind in a shape are one of the following seven instances of the class sh:NodeKind:
sh:BlankNode, sh:IRI, sh:Literal
sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral, sh:IRIOrLiteral, and sh:TripleTerm.
sh:nodeKind are well-formed SHACL lists, then members of those lists in a shape are one of the following four instances of the class sh:NodeKind:
sh:BlankNode, sh:IRI, sh:Literal, and sh:TripleTerm.
Let
$nodeKind be a
parameter value for
sh:nodeKind.
Let
$nodeKinds be a set of
IRIs so that
when
$nodeKind is an
IRI then the set only consists of exactly that IRI,
and when
$nodeKind is a
blank node SHACL list then the set consists of
exactly the members of the list.
For each
value node
that matches none of the
$nodeKinds,
there is a
validation result with the
value node as
sh:value.
Any
IRI matches only
sh:IRI,
sh:BlankNodeOrIRI and
sh:IRIOrLiteral.
Any
blank node matches only
sh:BlankNode,
sh:BlankNodeOrIRI and
sh:BlankNodeOrLiteral.
Any
literal matches only
sh:Literal,
sh:BlankNodeOrLiteral and
sh:IRIOrLiteral.
Any
triple term matches only
sh:TripleTerm.
The remainder of this section is informative.
The following example states that all values of ex:knows need to be IRIs, at any subject.
The following example illustrates the list-based syntax, meaning that all values of ex:knows
need to be IRIs or blank nodes, at any subject.
Cardinality Constraint Components
The following constraint components represent restrictions on the number of value nodes for the given focus node .
sh:minCount
sh:minCount specifies the minimum number of value nodes that satisfy the condition.
If the minimum cardinality value is 0 then this constraint is always satisfied and so may be omitted.
Constraint Component IRI : sh:MinCountConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:minCount
The minimum cardinality.
Node shapes cannot have any value for sh:minCount.A property shape has at most one value for sh:minCount.
The values of sh:minCount in a property shape are literals with datatype xsd:integer.
Let
$minCount be a
parameter value for
sh:minCount.
If the number of
value nodes is less than
$minCount,
there is a
validation result .
The remainder of this section is informative.
ex:MinCountExampleShape
a sh:PropertyShape ;
sh:targetNode ex:Alice, ex:Bob ;
sh:path ex:name ;
sh:minCount 1 .
ex:Alice ex:name "Alice" .
ex:Bob ex:givenName "Bob"@en .
sh:maxCount
sh:maxCount specifies the maximum number of value nodes that satisfy the condition.
Constraint Component IRI : sh:MaxCountConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:maxCount
The maximum cardinality.
Node shapes cannot have any value for sh:maxCount.A property shape has at most one value for sh:maxCount.
The values of sh:maxCount in a property shape are literals with datatype xsd:integer.
Let
$maxCount be a
parameter value for
sh:maxCount.
If the number of
value nodes is greater than
$maxCount,
there is a
validation result .
The remainder of this section is informative.
ex:MaxCountExampleShape
a sh:NodeShape ;
sh:targetNode ex:Bob ;
sh:property ex:MaxCountExampleShape-birthDate ;
.
ex:MaxCountExampleShape-birthDate
a sh:PropertyShape ;
sh:path ex:birthDate ;
sh:maxCount 1 ;
.
ex:Bob ex:birthDate "May 5th 1990" .
Value Range Constraint Components
The following constraint components specify value range conditions to be satisfied by value nodes that are comparable
via operators such as <, <=, > and >=.
The following example illustrates a typical use case of these constraint components.
ex:NumericRangeExampleShape
a sh:NodeShape ;
sh:targetNode ex:Bob, ex:Alice, ex:Ted ;
sh:property ex:NumericRangeExampleShape-age ;
.
ex:NumericRangeExampleShape-age
a sh:PropertyShape ;
sh:path ex:age ;
sh:minInclusive 0 ;
sh:maxInclusive 150 ;
.
ex:Bob ex:age 23 .
ex:Alice ex:age 220 .
ex:Ted ex:age "twenty one" .
sh:minExclusive
Constraint Component IRI: sh:MinExclusiveConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:minExclusive
The minimum exclusive value.
The values of sh:minExclusive in a shape are literals .
A shape has at most one value for sh:minExclusive.
Let
$minExclusive be a
parameter value for
sh:minExclusive.
For each
value node v
where the SPARQL expression
$minExclusive < v does not return
true,
there is a
validation result with
v as
sh:value.
The remainder of this section is informative.
There is a validation result if the value node cannot be compared to the specified range,
for example when someone compares a string with an integer.
sh:minInclusive
Constraint Component IRI: sh:MinInclusiveConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:minInclusive
The minimum inclusive value.
The values of sh:minInclusive in a shape are literals .
A shape has at most one value for sh:minInclusive.
Let
$minInclusive be a
parameter value for
sh:minInclusive.
For each
value node v
where the SPARQL expression
$minInclusive <= v does not return
true,
there is a
validation result with
v as
sh:value.
sh:maxExclusive
Constraint Component IRI: sh:MaxExclusiveConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:maxExclusive
The maximum exclusive value.
The values of sh:maxExclusive in a shape are literals .
A shape has at most one value for sh:maxExclusive.
Let
$maxExclusive be a
parameter value for
sh:maxExclusive.
For each
value node v
where the SPARQL expression
$maxExclusive > v does not return
true,
there is a
validation result with
v as
sh:value.
sh:maxInclusive
Constraint Component IRI: sh:MaxInclusiveConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:maxInclusive
The maximum inclusive value.
The values of sh:maxInclusive in a shape are literals .
A shape has at most one value for sh:maxInclusive.
Let
$maxInclusive be a
parameter value for
sh:maxInclusive.
For each
value node v
where the SPARQL expression
$maxInclusive >= v does not return
true,
there is a
validation result with
v as
sh:value.
String-based Constraint Components
The constraint components in this section have in common that they specify conditions
on the string representation of value nodes .
sh:minLength
sh:minLength specifies the minimum string length of each value node that satisfies the condition.
This can be applied to any literals and IRIs , but not to blank nodes .
Constraint Component IRI : sh:MinLengthConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:minLength
The minimum length.
The values of sh:minLength in a shape are literals with datatype xsd:integer.
A shape has at most one value for sh:minLength.
Let
$minLength be a
parameter value for
sh:minLength.
For each
value node v
where the length (as defined by the
SPARQL STRLEN function )
of the string representation of
v (as defined by the
SPARQL str function )
is less than
$minLength, or where
v is a
blank node ,
there is a
validation result with
v as
sh:value.
The remainder of this section is informative.
Note that if the value of sh:minLength is 0 then there is no restriction on the
string length but the constraint is still violated if the value node is a blank node.
sh:maxLength
sh:maxLength specifies the maximum string length of each value node that satisfies the condition.
This can be applied to any literals and IRIs , but not to blank nodes .
Constraint Component IRI : sh:MaxLengthConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:maxLength
The maximum length.
The values of sh:maxLength in a shape are literals with datatype xsd:integer.
A shape has at most one value for sh:maxLength.
Let
$maxLength be a
parameter value for
sh:maxLength.
For each
value node v
where the length (as defined by the
SPARQL STRLEN function )
of the string representation of
v (as defined by the
SPARQL str function )
is greater than
$maxLength, or where
v is a
blank node ,
there is a
validation result with
v as
sh:value.
The remainder of this section is informative.
ex:PasswordExampleShape
a sh:NodeShape ;
sh:targetNode ex:Bob, ex:Alice ;
sh:property ex:PasswordExampleShape-password ;
.
ex:PasswordExampleShape-password
a sh:PropertyShape ;
sh:path ex:password ;
sh:minLength 8 ;
sh:maxLength 10 ;
.
ex:Bob ex:password "123456789" .
ex:Alice ex:password "1234567890ABC" .
sh:pattern
sh:pattern specifies a regular expression that each value node matches to satisfy the condition.
Constraint Component IRI : sh:PatternConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:pattern
A regular expression that all value nodes need to match.
The values of sh:pattern in a shape are literals with datatype xsd:string.
The values of sh:pattern in a shape are valid pattern arguments for the SPARQL REGEX function .
sh:flags
An optional string of flags, interpreted as in SPARQL 1.2 REGEX .
The values of sh:flags in a shape are literals with datatype xsd:string.
Let
$pattern be a
parameter value for
sh:pattern.
Let
$flags be a
parameter value for
sh:flags.
For each
value node
that is a blank node or
where the string representation (as defined by the
SPARQL str function )
does not match the regular expression
$pattern (as defined by the
SPARQL REGEX function ),
there is a
validation result with the
value node as
sh:value.
If
$flags has a value then the matching MUST follow the definition of the 3-argument variant of the SPARQL REGEX function, using
$flags as third argument.
The remainder of this section is informative.
ex:PatternExampleShape
a sh:NodeShape ;
sh:targetNode ex:Bob, ex:Alice, ex:Carol ;
sh:property ex:PatternExampleShape-bCode ;
.
ex:PatternExampleShape-bCode
a sh:PropertyShape ;
sh:path ex:bCode ;
sh:pattern "^B" ; # starts with 'B'
sh:flags "i" ; # Ignore case
.
ex:Bob ex:bCode "b101" .
ex:Alice ex:bCode "B102" .
ex:Carol ex:bCode "C103" .
sh:singleLine
This feature is "at risk" pending a WG resolution on this (and similar) convenience features.
The WG is not sure yet where to draw the lines between features that should go into Core versus some other document.
Originally discussed as Issue 177 .
When set to true, sh:singleLine specifies that the value nodes must not contain line breaks.
In addition to constraint validation, this information can be exploited by user interface builders to select between (single-lined) text fields and (multi-lined) text areas.
Constraint Component IRI : sh:SingleLineConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:singleLine
true to activate this constraint.
The values of sh:singleLine in a shape are literals with datatype xsd:boolean.
A shape has at most one value for sh:singleLine.
Let
$singleLine be a
parameter value for
sh:singleLine.
If
$singleLine is
true, then, for each
value node that is a literal where the lexical form matches the
regular expression (as defined by the
SPARQL REGEX function )
[\f\r\n\v], there is a validation result.
The remainder of this section is informative.
In this example, the valid target nodes of the shape can only contain single-lined values for rdfs:label.
The values of rdfs:comment are explicitly allowed to contain line breaks, indicating to form builders that
those values should be edited in a multi-line (text area) input widget.
ex:SingleLineExampleShape
a sh:NodeShape ;
sh:property ex:SingleLineExampleShape-label ;
sh:property ex:SingleLineExampleShape-comment ;
.
ex:SingleLineExampleShape-label
a sh:PropertyShape ;
sh:path rdfs:label ;
sh:datatype xsd:string ;
sh:singleLine true ;
.
ex:SingleLineExampleShape-comment
a sh:PropertyShape ;
sh:path rdfs:comment ;
sh:datatype ( xsd:string rdf:langString ) ;
sh:singleLine false ;
.
sh:languageIn
The condition specified by sh:languageIn is that the allowed language tags for each value node are limited by a given list of language tags.
Constraint Component IRI : sh:LanguageInConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:languageIn
A list of basic language ranges as per [[!BCP47]].
Each value of sh:languageIn in a shape is a SHACL list .
Each member of such a list is a literal with datatype xsd:string.
A shape has at most one value for sh:languageIn.
Let
$languageIn be a
value of
sh:languageIn.
For each
value node
that is either not a
literal or that does not have a language tag
matching any of the basic language ranges that are the
members of
$languageIn
following the filtering schema defined by the
SPARQL langMatches function,
there is a
validation result with the
value node as
sh:value.
The remainder of this section is informative.
The following example shape states that all values of ex:prefLabel
can be either in English or Māori.
ex:NewZealandLanguagesShape
a sh:NodeShape ;
sh:targetNode ex:Mountain, ex:Berg ;
sh:property ex:NewZealandLanguagesShape-prefLabel ;
.
ex:NewZealandLanguagesShape-prefLabel
a sh:PropertyShape ;
sh:path ex:prefLabel ;
sh:languageIn ( "en" "mi" ) ;
.
From the example instances, ex:Berg will lead to constraint violations for all
of its labels.
ex:Mountain
ex:prefLabel "Mountain"@en ;
ex:prefLabel "Hill"@en-nz ;
ex:prefLabel "Maunga"@mi .
ex:Berg
ex:prefLabel "Berg" ;
ex:prefLabel "Berg"@de ;
ex:prefLabel ex:BergLabel .
sh:uniqueLang
The property sh:uniqueLang can be set to true to specify that no pair of value nodes may use the same language tag.
Constraint Component IRI : sh:UniqueLangConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:uniqueLang
true to activate this constraint.
The values of sh:uniqueLang in a shape are literals with datatype xsd:boolean.
A property shape has at most one value for sh:uniqueLang.
Node shapes cannot have any value for sh:uniqueLang.
Let
$uniqueLang be a
parameter value for
sh:uniqueLang.
If
$uniqueLang is
true
then for each non-empty language tag that is used by at least two
value nodes ,
there is a
validation result .
The remainder of this section is informative.
ex:UniqueLangExampleShape
a sh:NodeShape ;
sh:targetNode ex:Alice, ex:Bob ;
sh:property ex:UniqueLangExampleShape-label ;
.
ex:UniqueLangExampleShape-label
a sh:PropertyShape ;
sh:path ex:label ;
sh:uniqueLang true ;
.
ex:Alice
ex:label "Alice" ;
ex:label "Alice"@en ;
ex:label "Alice"@fr .
ex:Bob
ex:label "Bob"@en ;
ex:label "Bobby"@en .
List Constraint Components
The constraint components in this section apply to value nodes that are SHACL lists .
They specify conditions on the structure, length, and members of SHACL lists.
sh:memberShape
sh:memberShape specifies that all members of SHACL list value nodes must conform to the given node shape .
Constraint Component IRI : sh:MemberShapeConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:memberShape
The shape that all members of the SHACL list must conform to.
The value of sh:memberShape must be a well-formed node shape .
Let
$memberShape be a
parameter value for
sh:memberShape.
Each
value node v must be a
SHACL list - if
v is not a SHACL list there is a
validation result .
If any member
m of the
SHACL list v does not
conform to
$memberShape, there is a
validation result .
The remainder of this section is informative.
Each member m of a value node v that does not conform to the $memberShape should be reported as a separate sh:detail in the validation result for v.
If v is not a valid SHACL list , this should be reported as a top-level validation result and validation of individual members should not be attempted.
Examples of how to generate sh:details in validation results can be found in the test cases for sh:memberShape in the SHACL test suite: memberShape-001.ttl .
In the following example, all values of the property ex:speakerOrder must be SHACL lists with members that are IRIs.
ex:AgendaShape
a sh:NodeShape ;
sh:targetClass ex:Agenda ;
sh:property ex:AgendaShape-speakerOrder ;
.
ex:AgendaShape-speakerOrder
a sh:PropertyShape ;
sh:path ex:speakerOrder ;
sh:memberShape [
sh:nodeKind sh:IRI ;
] ;
.
ex:agenda1 a ex:Agenda ;
ex:speakerOrder ( ex:Alice ex:Bob ex:Charlie ) .
ex:agenda2 a ex:Agenda ;
ex:speakerOrder ( ex:Alice ex:Bob "Charlie" ) .
sh:minListLength
sh:minListLength specifies the minimum number of members that SHACL list value nodes must have.
Constraint Component IRI : sh:MinListLengthConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:minListLength
The minimum number of members in the SHACL list .
The values of sh:minListLength in a shape are literals with datatype xsd:integer.
The values of sh:minListLength in a shape are integers greater than or equal to 0.
Let
$minListLength be a
parameter value for
sh:minListLength.
Each
value node v must be a
SHACL list - if
v is not a SHACL list there is a
validation result .
If the number of members in a list
v is less than
$minListLength,
there is a
validation result .
The remainder of this section is informative.
In the following example, all values of the property ex:skills must be SHACL lists with at least 1 member.
Additional test cases for sh:minListLength can be found in the SHACL test suite: minListLength-001.ttl .
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:PersonShape-skills ;
.
ex:PersonShape-skills
a sh:PropertyShape ;
sh:path ex:skills ;
sh:minListLength 1 ;
.
ex:person1 a ex:Person ;
ex:skills ( "programming" "design" ) .
ex:person2 a ex:Person ;
ex:skills () .
sh:maxListLength
sh:maxListLength specifies the maximum number of members that SHACL list value nodes must have.
Constraint Component IRI : sh:MaxListLengthConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:maxListLength
The maximum number of members in the SHACL list .
The values of sh:maxListLength in a shape are literals with datatype xsd:integer.
The values of sh:maxListLength in a shape are integers greater than or equal to 0.
Let
$maxListLength be a
parameter value for
sh:maxListLength.
Each
value node v must be a
SHACL list - if
v is not a SHACL list there is a
validation result .
If the number of members in the list
v is greater than
$maxListLength,
there is a
validation result .
The remainder of this section is informative.
In the following example, all values of the property ex:hobbies must be SHACL lists with at most 2 members.
Additional test cases for sh:maxListLength can be found in the SHACL test suite: maxListLength-001.ttl .
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:PersonShape-hobbies ;
.
ex:PersonShape-hobbies
a sh:PropertyShape ;
sh:path ex:hobbies ;
sh:maxListLength 2 ;
.
ex:person1 a ex:Person ;
ex:hobbies ( "reading" "writing" ) .
ex:person2 a ex:Person ;
ex:hobbies ( "reading" "writing" "swimming" ) .
sh:uniqueMembers
sh:uniqueMembers specifies whether SHACL list value nodes must have unique members.
Constraint Component IRI : sh:UniqueMembersConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:uniqueMembers
A boolean that specifies whether the members of the SHACL list must be unique.
The values of sh:uniqueMembers in a shape are literals with datatype xsd:boolean.
Let
$uniqueMembers be a
parameter value for
sh:uniqueMembers.
Each
value node v must be a
SHACL list - if
v is not a SHACL list there is a
validation result .
If
$uniqueMembers is
true and the list
v has duplicate members,
there is a
validation result .
The remainder of this section is informative.
Each duplicate member m of a list v should be reported as a separate sh:detail in the validation result for v. If the list v is not a valid SHACL list , this should be reported as a top-level validation result and validation of unique membership should not be attempted.
Examples of how to generate sh:details in validation results can be found in the test cases for sh:uniqueMembers in the SHACL test suite: uniqueMembers-001.ttl .
In the following example, all values of the property ex:preferences must be SHACL lists with members that have unique values within each SHACL list.
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:PersonShape-preferences ;
.
ex:PersonShape-preferences
a sh:PropertyShape ;
sh:path ex:preferences ;
sh:uniqueMembers true ;
.
ex:person1 a ex:Person ;
ex:preferences ( "coffee" "tea" ) .
ex:person2 a ex:Person ;
ex:preferences ( "coffee" "tea" "coffee" "tea" "tea" ) .
Property Pair Constraint Components
The constraint components in this section specify conditions on the sets of value nodes in relation to other properties.
These constraint components can only be used by property shapes .
sh:equals
sh:equals specifies the condition that the set of all value nodes is equal to the set of objects of the triples that have the focus node as subject and the value of sh:equals as predicate .
Constraint Component IRI : sh:EqualsConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:equals
The property to compare with.
The values of sh:equals in a shape are IRIs .
Let
$equals be a
value of
sh:equals.
For each
value node
that does not exist as a
value of the property
$equals at the
focus node ,
there is a
validation result with the
value node as
sh:value.
For each
value of the property
$equals at the
focus node
that is not one of the
value nodes ,
there is a
validation result with the
value as
sh:value.
The remainder of this section is informative.
The following example illustrates the use of sh:equals in a shape to specify
that certain focus nodes need to have the same set of values for ex:firstName and ex:givenName.
ex:EqualExampleShape
a sh:NodeShape ;
sh:targetNode ex:Bob ;
sh:property ex:EqualExampleShape-firstName ;
.
ex:EqualExampleShape-firstName
a sh:PropertyShape ;
sh:path ex:firstName ;
sh:equals ex:givenName ;
.
ex:Bob
ex:firstName "Bob" ;
ex:givenName "Bob" .
sh:disjoint
sh:disjoint specifies the condition that the set of value nodes
is disjoint with the set of objects of the triples
that have the focus node as subject
and the value of sh:disjoint as predicate .
Constraint Component IRI : sh:DisjointConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:disjoint
The property to compare the values with.
The values of sh:disjoint in a shape are IRIs .
Let
$disjoint be a
parameter value of
sh:disjoint.
For each
value node
that also exists as a
value of the property
$disjoint at the
focus node ,
there is a
validation result with the
value node as
sh:value.
The remainder of this section is informative.
The following example illustrates the use of sh:disjoint in a shape to specify
that certain focus nodes cannot share any values for ex:prefLabel and ex:altLabel.
ex:DisjointExampleShape
a sh:NodeShape ;
sh:targetNode ex:USA, ex:Germany ;
sh:property ex:DisjointExampleShape ;
.
ex:DisjointExampleShape
a sh:PropertyShape ;
sh:path ex:prefLabel ;
sh:disjoint ex:altLabel ;
.
ex:USA
ex:prefLabel "USA" ;
ex:altLabel "United States" .
ex:Germany
ex:prefLabel "Germany" ;
ex:altLabel "Germany" .
sh:lessThan
sh:lessThan specifies the condition that each value node is smaller than all the objects of the triples that have the focus node as subject and the value of sh:lessThan as predicate .
Constraint Component IRI : sh:LessThanConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:lessThan
The property to compare the values with.
The values of sh:lessThan in a shape are IRIs .
Node shapes cannot have any value for sh:lessThan.
Let
$lessThan be a
value of
sh:lessThan.
For each pair of
value nodes and the values of the property
$lessThan at the given
focus node
where the first
value is not less than the second
value (based on SPARQL's
< operator)
or where the two values cannot be compared,
there is a
validation result with the
value node as
sh:value.
The remainder of this section is informative.
The following example illustrates the use of sh:lessThan in a shape to specify
that all values of ex:startDate are "before" the values of ex:endDate.
sh:lessThanOrEquals
sh:lessThanOrEquals specifies the condition that each value node is smaller than or equal to all the objects of the triples that have the focus node as subject and the value of sh:lessThanOrEquals as predicate .
Constraint Component IRI : sh:LessThanOrEqualsConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:lessThanOrEquals
The property to compare the values with.
The values of sh:lessThanOrEquals in a shape are IRIs .
Node shapes cannot have any value for sh:lessThanOrEquals.
Let
$lessThanOrEquals be a
value of
sh:lessThanOrEquals.
For each pair of
value nodes and the values of the property
$lessThanOrEquals at the given
focus node
where the first
value is not less than or equal to the second
value (based on SPARQL's
<= operator)
or where the two values cannot be compared,
there is a
validation result with the
value node as
sh:value.
Logical Constraint Components
The constraint components in this section implement the common logical operators
and , or and not , as well as a variation of exclusive or .
sh:not
sh:not specifies the condition that each value node cannot conform to a given shape .
This is comparable to negation and the logical "not" operator.
Constraint Component IRI : sh:NotConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:not
The shape to negate.
The values of sh:not in a shape must be well-formed shapes .
Let
$not be a
value of
sh:not.
For each
value node v:
A
failure MUST be reported if the
conformance checking of
v against
the shape
$not produces a
failure .
Otherwise, if
v conforms to the shape
$not,
there is
validation result with
v as
sh:value.
The remainder of this section is informative.
The following example illustrates the use of sh:not in a shape to specify the condition
that certain focus nodes cannot have any value of ex:property.
sh:and
sh:and specifies the condition that each value node conforms to all provided shapes.
This is comparable to conjunction and the logical "and" operator.
Constraint Component IRI : sh:AndConstraintComponent
Parameters:
Let
$and be a
value of
sh:and.
For each
value node v:
A
failure MUST be produced if the
conformance checking of
v against any of the
members of
$and produces a
failure .
Otherwise, if
v does not
conform to each
member of
$and,
there is a
validation result with
v as
sh:value.
The remainder of this section is informative.
Note that although sh:and has a SHACL list of shapes as its value,
the order of those shapes does not impact the validation results.
For implementations that use shortcut evaluation semantics, the order may impact the efficiency of validation.
It is recommended to put earlier in the list constraints that are easier to evaluate, or are more likely to fail.
The following example illustrates the use of sh:and in a shape to specify the condition
that certain focus nodes have exactly one value of ex:property.
This is achieved via the conjunction of a separate named shape (ex:SuperShape) which specifies
the minimum count, and a property shape that additionally specifies the maximum count.
As shown here, sh:and can be used to implement a specialization mechanism between shapes.
ex:SuperShape
a sh:NodeShape ;
sh:property [
sh:path ex:property ;
sh:minCount 1 ;
] ;
.
ex:ExampleAndShape
a sh:NodeShape ;
sh:targetNode ex:ValidInstance, ex:InvalidInstance ;
sh:and (
ex:SuperShape
[
sh:path ex:property ;
sh:maxCount 1 ;
]
) ;
.
ex:ValidInstance
ex:property "One" .
# Invalid: more than one property
ex:InvalidInstance
ex:property "One" ;
ex:property "Two" .
sh:or
sh:or specifies the condition that each value node conforms to at least one of the provided shapes.
This is comparable to disjunction and the logical "or" operator.
Constraint Component IRI : sh:OrConstraintComponent
Parameters:
Let
$or be a
value of
sh:or.
For each
value node v:
A
failure MUST be produced if the
conformance checking of
v against any of the
members produces a
failure .
Otherwise, if
v conforms to none of the
members of
$or
there is a
validation result with
v as
sh:value.
The remainder of this section is informative.
Note that although sh:or has a SHACL list of shapes as its value,
the order of those shapes does not impact the validation results.
For implementations that use shortcut evaluation semantics, the order may impact the efficiency of validation.
It is recommended to put earlier in the list constraints that are easier to evaluate, or are more likely to succeed.
The following example illustrates the use of sh:or in a shape to specify the condition
that certain focus nodes have at least one value of ex:firstName
or at least one value of ex:givenName.
The next example shows how sh:or can be used in a property shape to state that the values of
the given property ex:address may be either literals with datatype xsd:string
or SHACL instances of the class ex:Address.
ex:PersonAddressShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:PersonAddressShape-address ;
.
ex:PersonAddressShape-address
a sh:PropertyShape ;
sh:path ex:address ;
sh:or (
[
sh:datatype xsd:string ;
]
[
sh:class ex:Address ;
]
)
.
ex:Bob ex:address "123 Prinzengasse, Vaduz, Liechtenstein" .
Note that all constraints in SHACL get ANDed for execution. Consider the following example:
The correct interpretation is (shapeA OR shapeB) AND (shapeC OR shapeD).
The target nodes need to conform to shapeA or shapeB, and then also shapeC or shapeD.
sh:xone
sh:xone specifies the condition that each value node conforms to exactly one of the provided shapes.
Constraint Component IRI : sh:XoneConstraintComponent
Parameters:
Let
$xone be a
value of
sh:xone.
For each
value node v
let
N be the number of the
shapes that are
members of
$xone
where
v conforms to the shape.
A
failure MUST be produced if the
conformance checking of
v against any of the
members produces a
failure .
Otherwise, if
N is not exactly
1,
there is a
validation result with
v as
sh:value.
The remainder of this section is informative.
Note that although sh:xone has a SHACL list of shapes as its value,
the order of those shapes does not impact the validation results.
The following example illustrates the use of sh:xone in a shape to specify the condition
that certain focus nodes must either have a value for ex:fullName or values for
ex:firstName and ex:lastName, but not both.
ex:XoneConstraintExampleShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:xone (
[
sh:property [
sh:path ex:fullName ;
sh:minCount 1 ;
]
]
[
sh:property [
sh:path ex:firstName ;
sh:minCount 1 ;
] ;
sh:property [
sh:path ex:lastName ;
sh:minCount 1 ;
]
]
) ;
.
ex:Bob a ex:Person ;
ex:firstName "Robert" ;
ex:lastName "Coin" .
ex:Carla a ex:Person ;
ex:fullName "Carla Miller" .
ex:Dory a ex:Person ;
ex:firstName "Dory" ;
ex:lastName "Dunce" ;
ex:fullName "Dory Dunce" .
Shape-based Constraint Components
The constraint components in this section can be used to specify complex conditions
by validating the value nodes against certain shapes.
sh:node
sh:node specifies the condition that each value node conforms to the given node shape .
Constraint Component IRI : sh:NodeConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:node
The node shape that all value nodes need to conform to.
The values of sh:node in a shape must be well-formed node shapes .
Let
$node be a
value of
sh:node.
For each
value node v:
A
failure MUST be produced if the
conformance checking of
v against
$node produces a
failure .
Otherwise, if
v does not
conform to
$node,
there is a
validation result with
v as
sh:value.
The remainder of this section is informative.
In the following example, all values of the property ex:address must fulfill the
constraints expressed by the shape ex:AddressShape.
ex:AddressShape
a sh:NodeShape ;
sh:property ex:AddressShape-postalCode ;
.
ex:AddressShape-postalCode
a sh:PropertyShape ;
sh:path ex:postalCode ;
sh:datatype xsd:string ;
sh:maxCount 1 ;
.
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:PersonShape-address ;
.
ex:PersonShape-address
a sh:PropertyShape ;
sh:path ex:address ;
sh:minCount 1 ;
sh:node ex:AddressShape ;
.
ex:Bob a ex:Person ;
ex:address ex:BobsAddress .
ex:BobsAddress
ex:postalCode "1234" .
ex:Reto a ex:Person ;
ex:address ex:RetosAddress .
ex:RetosAddress
ex:postalCode 5678 .
[
a sh:ValidationReport ;
sh:conforms false ;
sh:result [
a sh:ValidationResult ;
sh:resultSeverity sh:Violation ;
sh:focusNode ex:Reto ;
sh:resultPath ex:address ;
sh:value ex:RetosAddress ;
sh:resultMessage "Value does not conform to shape ex:AddressShape." ;
sh:sourceConstraintComponent sh:NodeConstraintComponent ;
sh:sourceShape ex:PersonShape-address ;
] ;
] .
sh:property
sh:property can be used to specify that each value node has a given property shape .
Constraint Component IRI : sh:PropertyConstraintComponent
Parameters:
Let
$property be a
value of
sh:property.
For each
value node v:
A
failure MUST be produced if the validation of
v as
focus node against the property shape
$property produces a
failure .
Otherwise, the validation results are the results of
validating v as
focus node against the property shape
$property.
The remainder of this section is informative.
Note that there is an important difference between sh:property and sh:node:
If a value node is violating the constraint, then there is only a single validation result for sh:node for this value node,
with sh:NodeConstraintComponent as its sh:sourceConstraintComponent.
On the other hand side, there may be any number of validation results for sh:property, and these
will have the individual constraint components of the constraints in the property shape as their values of sh:sourceConstraintComponent.
Like with all other validation results, each time a property shape is reached via sh:property,
a validation engine MUST produce fresh validation result nodes.
This includes cases where the same focus node is validated against the same property shape
although it is reached via different paths in the shapes graph .
sh:someValue
sh:someValue specifies the condition that at least one value node conforms to the given shape .
Constraint Component IRI : sh:SomeValueConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:someValue
The shape that at least one of the value nodes needs to conform to.
The values of sh:someValue in a shape must be well-formed shapes .
Let
$someValue be a
value of
sh:someValue.
A
failure MUST be produced if the
conformance checking of any
value node against
$someValue produces a
failure , unless at least one of the
value nodes conforms to
$someValue.
Otherwise, if none of the
value nodes conforms to
$someValue,
there is a
validation result .
The remainder of this section is informative.
Note that implementations may stop processing value nodes once one of the value nodes has conformed.
Since the order of nodes in the set of value nodes is undefined, there is no guarantee that any node is
reached that would cause a failure.
Therefore, to make processing predictable, failures are silently ignored unless all value nodes have been visited without success.
In the following example, any nodes that conform to ex:DuckFarmerShape need to have at least one value
for ex:tendsAnimal that is a SHACL instance of ex:Duck.
sh:someValue can be regarded as syntactic sugar for a combination of
sh:qualifiedValueShape and sh:qualifiedMinCount 1.
Also note that sh:someValue mostly makes sense when used in property shapes .
In node shapes , sh:someValue is equivalent to using sh:node or sh:property.
sh:qualifiedValueShape, sh:qualifiedMinCount, sh:qualifiedMaxCount
sh:qualifiedValueShape specifies the condition that a specified number of value nodes conforms to the given shape.
Each sh:qualifiedValueShape can have: one value for sh:qualifiedMinCount, one value for sh:qualifiedMaxCount or, one value for each, at the same subject .
Parameters:
Property
Summary and Syntax Rules
sh:qualifiedValueShape
The shape that the specified number of value nodes needs to conform to.
The values of sh:qualifiedValueShape in a shape must be well-formed shapes .
Node shapes cannot have any value for sh:qualifiedValueShape.mandatory parameter of sh:QualifiedMinCountConstraintComponent and sh:QualifiedMaxCountConstraintComponent.
sh:qualifiedValueShapesDisjoint
This is an optional parameter of sh:QualifiedMinCountConstraintComponent and sh:QualifiedMaxCountConstraintComponent.
If set to true then (for the counting) the value nodes must not conform to any of the sibling shapes .
The values of sh:qualifiedValueShapesDisjoint in a shape are literals with datatype xsd:boolean.
sh:qualifiedMinCount
The minimum number of value nodes that conform to the shape.
The values of sh:qualifiedMinCount in a shape are literals with datatype xsd:integer.
This is a mandatory parameter of sh:QualifiedMinCountConstraintComponent.
sh:qualifiedMaxCount
The maximum number of value nodes that can conform to the shape.
The values of sh:qualifiedMaxCount in a shape are literals with datatype xsd:integer.
This is a mandatory parameter of sh:QualifiedMaxCountConstraintComponent.
Let
Q be a
shape in
shapes graph G that declares a qualified cardinality constraint
(by having values for
sh:qualifiedValueShape and at least one of
sh:qualifiedMinCount or
sh:qualifiedMaxCount).
Let
ps be the set of
shapes in
G that have
Q as a
value of
sh:property.
If
Q has
true as a
value for
sh:qualifiedValueShapesDisjoint then
the set of
sibling shapes for
Q is defined as the set of all
values of the
SPARQL property path sh:property/sh:qualifiedValueShape for any
shape in
ps
minus the
value of
sh:qualifiedValueShape of
Q itself.
The set of sibling shapes is empty otherwise.
Let
$qualifiedValueShape be a
value of
sh:qualifiedValueShape.
Let
$qualifiedMinCount be a
parameter value for
sh:qualifiedMinCount.
Let
C be the number of
value nodes v where
v conforms to
$qualifiedValueShape
and where
v does not
conform to any of the
sibling shapes for the
current shape,
i.e. the shape that
v is validated against and which has
$qualifiedValueShape as its value for
sh:qualifiedValueShape.
A
failure MUST be produced if any of the said conformance checks produces a
failure .
Otherwise, there is a
validation result if
C is less than
$qualifiedMinCount.
The
constraint component for
sh:qualifiedMinCount is
sh:QualifiedMinCountConstraintComponent.
Let
$qualifiedMaxCount be a
parameter value for
sh:qualifiedMaxCount.
Let
C be as defined for
sh:qualifiedMinCount above.
A
failure MUST be produced if any of the said conformance checks produces a
failure .
Otherwise, there is a
validation result if
C is greater than
$qualifiedMaxCount.
The
constraint component for
sh:qualifiedMaxCount is
sh:QualifiedMaxCountConstraintComponent.
The remainder of this section is informative.
In the following example shape can be used to specify the condition that the property ex:parent has exactly two values,
and at least one of them is female.
ex:QualifiedValueShapeExampleShape
a sh:NodeShape ;
sh:targetNode ex:QualifiedValueShapeExampleValidResource ;
sh:property ex:QualifiedValueShapeExampleShape-parent ;
.
ex:QualifiedValueShapeExampleShape-parent
a sh:PropertyShape ;
sh:path ex:parent ;
sh:minCount 2 ;
sh:maxCount 2 ;
sh:qualifiedValueShape [
sh:path ex:gender ;
sh:hasValue ex:female ;
] ;
sh:qualifiedMinCount 1 ;
.
ex:QualifiedValueShapeExampleValidResource
ex:parent ex:John ;
ex:parent ex:Jane .
ex:John
ex:gender ex:male .
ex:Jane
ex:gender ex:female .
The following example illustrates the use of sh:qualifiedValueShapesDisjoint
to express that a hand must have at most 5 values of ex:digit (expressed using sh:maxCount),
and exactly one of them must be an instance of ex:Thumb while exactly 4 of them must be an instance of ex:Finger
but thumbs and fingers must be disjoint.
In other words, on a hand, none of the fingers can also be counted as the thumb.
sh:reifierShape, sh:reificationRequired
sh:reifierShape can be used to link a property shape with one or more node shapes .
Any reifier must conform to these node shapes.
Constraint Component IRI : sh:ReifierShapeConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:reifierShape
The node shape that a reifier for this triple must conform to.
The values of sh:reifierShape must be well-formed node shapes .
If a value for sh:reifierShape is given, sh:path values are constrained to IRIs.
sh:reificationRequired
This is an optional parameter of sh:ReifierShapeConstraintComponent.
If set to true, there must be at least one reification value for the focus node/path combination in the data graph .
The values of sh:reificationRequired in a shape are literals with datatype xsd:boolean.
Let
t be the
triple term (
focus node ,
$path,
value node ).
For each
reifier for the
triple term t, a failure MUST be produced if validating the
reifier against the
node shape $reifierShape with the
reifier as
focus node produces a
failure .
For each
reifier t that does not conform to
$reifierShape, there is a validation result with
t as
sh:value.
If
$reificationRequired is set to
true and there is no reified statement for the
triple term t in the
data graph , there is a validation result with
t as
sh:value.
ex:ProvenanceShape
a sh:NodeShape ;
sh:property ex:ProvenanceShape-date ;
sh:property ex:ProvenanceShape-author ;
.
ex:ProvenanceShape-date
a sh:PropertyShape ;
sh:path ex:date ;
sh:datatype xsd:date ;
sh:maxCount 1 ;
.
ex:ProvenanceShape-author
a sh:PropertyShape ;
sh:path ex:author ;
sh:nodeKind sh:IRI ;
sh:maxCount 1 ;
.
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:property ex:PersonShape-age ;
.
ex:PersonShape-age
a sh:PropertyShape ;
sh:path ex:age ;
sh:datatype xsd:integer ;
sh:maxCount 1 ;
sh:reifierShape ex:ProvenanceShape ;
sh:reificationRequired true ;
.
ex:Bob ex:age 23 {|
ex:date "2019-12-05"^^xsd:date .
ex:author ex:Claire
|}.
Other Constraint Components
This section enumerates Core constraint components that do not fit into the other categories.
sh:closed, sh:ignoredProperties
The RDF data model offers a huge amount of flexibility.
Any node can in principle have values for any property.
However, in some cases it makes sense to specify conditions on which properties can be applied to nodes.
The SHACL Core language includes a property called sh:closed that can be used to
specify the condition that each value node has values only for those properties that have been explicitly enumerated via the
property shapes specified for the shape via sh:property.
Constraint Component IRI : sh:ClosedConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:closed
Set to true to close the shape.
The values of sh:closed in a shape are literals with datatype xsd:boolean
or the IRI sh:ByTypes.
sh:ignoredProperties
Optional SHACL list of properties that are also permitted in addition to those explicitly enumerated via sh:property.
The values of sh:ignoredProperties in a shape must be SHACL lists .
Each member of such a list must be a IRI .
Let
$closed be a
parameter value for
sh:closed.
Let
$ignoredProperties be a
value for
sh:ignoredProperties.
If
$closed is
true or
sh:ByTypes and
P
is the set of properties defined below,
then there is a
validation result for each
triple that has a
value node as its
subject and a
predicate that is not in
P.
If
$ignoredProperties has a value then the properties enumerated as
members of this
SHACL list
are also permitted for the
value node .
The
validation result MUST have the
predicate of the triple as its
sh:resultPath,
and the
object of the triple as its
sh:value.
If
$closed is
true, then
P is the set of
IRI properties
that can be reached from the current shape via the SPARQL path
sh:property/sh:path.
If
$closed is
sh:ByTypes, then
P is the set of
IRI properties
that can be reached from the value node via the following algorithm, plus
rdf:type:
function collectProperties(S)
add all IRI properties that can be reached from S via the SPARQL path
sh:property/sh:path
if S is a SHACL instance of rdfs:Class in the shapes graph {
for each triple in the shapes graph matching (S rdfs:subClassOf ?o)
collectProperties(?o)
for each triple in the shapes graph matching (?s sh:targetClass S)
collectProperties(?s)
}
if S is a SHACL instance of sh:NodeShape in the shapes graph
for each triple in the shapes graph matching (S sh:node ?o)
collectProperties(?o)
for each rdf:type T of the value node in the data graph
collectProperties(T)
Note that implementations need to avoid infinite loops in the algorithm above by preventing
it from visiting the same `S` twice.
The remainder of this section is informative.
The following example illustrates the use of sh:closed in a shape to specify the condition
that certain focus nodes only have values for ex:firstName and ex:lastName.
The "ignored" property rdf:type would also be allowed.
ex:ClosedShapeExampleShape
a sh:NodeShape ;
sh:targetNode ex:Alice, ex:Bob ;
sh:closed true ;
sh:ignoredProperties (rdf:type) ;
sh:property [
sh:path ex:firstName ;
] ;
sh:property [
sh:path ex:lastName ;
] ;
.
ex:Alice
ex:firstName "Alice" .
ex:Bob
ex:firstName "Bob" ;
ex:middleInitial "J" .
The use case for sh:closed sh:ByTypes includes properties that are declared
in superclasses of the types of the current value node (via rdfs:subClassOf),
as well as other shapes that are linked to those types via sh:targetClass and
the shapes that can be reached from one node shape to the other via sh:node.
Examples for sh:ByTypes can be found in the test case library:
closed-003.ttl ,
closed-004.ttl .
sh:hasValue
sh:hasValue specifies the condition that at least one value node is equal to the given RDF term.
Constraint Component IRI : sh:HasValueConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:hasValue
A specific required value.
Let
$hasValue be a
parameter value for
sh:hasValue.
If the RDF term
$hasValue is not among the
value nodes ,
there is a
validation result .
The remainder of this section is informative.
ex:StanfordGraduate
a sh:NodeShape ;
sh:targetNode ex:Alice ;
sh:property ex:StanfordGraduate-alumniOf ;
.
ex:StanfordGraduate-alumniOf
a sh:PropertyShape ;
sh:path ex:alumniOf ;
sh:hasValue ex:Stanford ;
.
ex:Alice
ex:alumniOf ex:Harvard ;
ex:alumniOf ex:Stanford .
sh:in
sh:in specifies the condition that each value node is a member of a provided SHACL list .
Constraint Component IRI : sh:InConstraintComponent
Parameters:
Property
Summary and Syntax Rules
sh:in
A SHACL list that has the allowed values as members .
Each value of sh:in in a shape is a SHACL list .
A shape has at most one value for sh:in.
Let
$in be a
value of
sh:in.
For each
value node
that is not a
member of
$in,
there is a
validation result with the
value node as
sh:value.
The remainder of this section is informative.
Note that matching of literals needs to be exact, e.g. "04"^^xsd:byte does not match "4"^^xsd:integer.
ex:InExampleShape
a sh:NodeShape ;
sh:targetNode ex:RainbowPony ;
sh:property ex:InExampleShape-color ;
.
ex:InExampleShape-color
a sh:PropertyShape ;
sh:path ex:color ;
sh:in ( ex:Pink ex:Purple ) ;
.
ex:RainbowPony ex:color ex:Pink .
Non-Validating Shape Characteristics
While the previous sections introduced properties that represent validation conditions,
this section covers properties that are ignored by SHACL processors.
The use of these so-called non-validating properties
is entirely optional and is not subject to formal interpretation contracts.
They MAY be used for purposes such as form building, code generation or predictable printing of RDF files.
sh:name and sh:description
Property shapes may have one or more values for sh:name
to provide human-readable labels for the property in the target where it appears.
If present, tools SHOULD prefer such locally specified labels
over globally specified labels at the rdf:Property itself.
For example, if a form displays a node that is in the target of a given property shape
with an sh:name, then the tool SHOULD use the provided name.
Similarly, property shapes may have values for sh:description
to provide descriptions of the property in the given context.
Both sh:name and sh:description may have
multiple values , but should only have one value per language tag.
Note that sh:name and sh:description SHOULD NOT be used for node shapes .
For those, the properties rdfs:label and rdfs:comment are well-established
and already used for class definitions.
sh:intent
Shapes may have values for sh:intent and those values should be literals
with datatype `xsd:string`, `rdf:langString` or `rdf:dirLangString`.
The lexical form of sh:intent MAY use CommonMark-compatible Markdown.
The property sh:intent provides a human-readable description of one or more intended
rules, assumptions, or constraints associated with a shape.
A typical use case of sh:intent is to send additional instructions to a software agent
that is able to process natural text.
Unlike rdfs:comment, which may include general documentation or editorial text,
and unlike sh:description, which describes the meaning of a property value,
sh:intent is specifically intended to capture individual rule-like statements that express
the intended semantics of a shape.
Multiple values of sh:intent MAY be provided to represent distinct intended rules.
Some of these rules MAY overlap with constraints that are already expressed formally using SHACL constraint components.
However, the presence or content of sh:intent MUST NOT affect SHACL validation or conformance.
ex:ParentShape
a sh:NodeShape ;
sh:targetClass ex:Parent ;
rdfs:comment "Represents individuals who have one or more children." ;
sh:intent "A parent must be strictly older than each of their children." ;
sh:intent "If the age of either the parent or child is unknown, the data should be treated as incomplete rather than valid." ;
sh:intent "Age values are compared in years using the same reference date." ;
.
ex:Person-birthDate
a sh:PropertyShape ;
sh:path ex:birthDate ;
sh:datatype xsd:date ;
sh:maxCount 1 ;
sh:description "The date on which the person was born." ;
sh:intent "Each person has at most one birth date." ;
sh:intent "The birth date must not be in the future." ;
sh:intent "The birth date should reflect the legal date of birth, not an estimated or approximate value." ;
.
In this example, the second sh:intent is difficult to express
formally in SHACL (without, for example, using the SPARQL function NOW).
The third sh:intent is impossible to verify for a SHACL engine.
However, the first sh:intent is already captured using sh:maxCount
in which case the textual description may have been created by a someone with less technical
knowledge, or intentionally left as duplicate for agents that do not understand SHACL.
sh:codeIdentifier
Shapes may have one value for sh:codeIdentifier
to suggest a name that can be used for a representation of the shape in APIs, query languages
and similar programmatic access.
The value of sh:codeIdentifier is a literal with datatype xsd:string
where the string matches the regular expression ^[a-zA-Z_][a-zA-Z0-9_]*$.
A typical use case would be to generate GraphQL query
schemas from shapes, mapping property shapes to GraphQL fields.
By default such schema generators could use the local name of the
sh:path, but it should use the sh:codeIdentifier if present.
In the case of complex path expressions an explicit sh:codeIdentifier is strongly recommended.
Similar requirements exist for API generators, for example in Java, JavaScript or Python.
sh:unit
Shapes may have values for the property sh:unit to indicate a unit of
measure, currency or similar information about the value nodes .
The values of sh:unit can be either literals with datatype `xsd:string`
or `rdf:langString` or `rdf:dirLangString`, or IRIs .
SHACL 1.2 does not prescribe specific values for sh:unit because, at the time of writing (2026),
there was no official W3C standard to represent them uniformly, and multiple standards exist outside of the W3C.
For SHACL 1.2, the following recommendations are given:
For units of measure a value of sh:unit may be an xsd:string
literal that exactly matches a code defined in UCUM ;
for example, sh:unit "cm".
For currencies, a value of sh:unit may be an xsd:string literal
that exactly matches a code defined in ISO 4217 ;
for example, sh:unit "AUD".
A value of sh:unit may be an IRI defined by the
QUDT or a similar units vocabulary;
for example sh:unit qudt:CentiM.
In addition to these canonical values, there may be additional language-tagged literals
with abbreviations or display names that are commonly used in the selected language(s);
for example, "Zoll"@de in addition to "in" for inches.
While these syntax rules are intentionally left flexible, specific applications may enforce more specific rules;
for example, by declaring a sh:class qudt:Unit constraint on the sh:unit property.
User interface tools based on SHACL can use the values of sh:unit to render values.
Depending on a user's locale such tools may even automatically convert between units,
or even allow data entry in units different than those that the actual values will be stored as.
ex:Fridge
a sh:ShapeClass ;
sh:property ex:Fridge-height ;
sh:property ex:Fridge-price ;
.
ex:Fridge-height
a sh:PropertyShape ;
sh:path ex:height ;
sh:datatype xsd:decimal ;
sh:unit "cm" ;
.
ex:Fridge-price
a sh:PropertyShape ;
sh:path ex:price ;
sh:datatype xsd:decimal ;
sh:unit "EUR" ;
.
ex:SomeFridge
a ex:Fridge ;
ex:height 180.5 ;
ex:price 999.95 ;
.
For this example, a user interface may render the height as
180.5 cm
or, for US-based visitors, as
180.5 cm (71 in)
While SHACL Core does not specify specific semantics for sh:unit, some
SHACL-based extensions may use units for other purposes, including validation.
For example, a shape could be defined that enforces a sh:minInclusive 0
constraint on any literal for which the property declares sh:unit "K".
The following variation of the example above uses a node shape to encapsulate
a reusable definition of "price in Euros" that includes the unit but also constraints
such as the minimum value.
sh:order
Property shapes may have one value for the property sh:order
to indicate the relative order of the property shape for purposes such as form building.
The values of sh:order are literals with datatype xsd:decimal or xsd:integer.
sh:order is not used for validation purposes
and may be used with any type of subjects.
If present at property shapes, the recommended use of sh:order is to sort the
property shapes in an ascending order, for example so that properties with smaller order are
placed above or to the start (left in left-to-right languages) of properties with larger order.
sh:group
Property shapes may link to a SHACL instance of the class sh:PropertyGroup
using the property sh:group to indicate that
the shape belongs to a group of related property shapes.
Each group may have additional triples that serve application purposes,
such as an rdfs:label for form building.
Groups may also have an sh:order property to indicate
the relative ordering of groups within the same form.
The following example illustrates the use of these various features together.
A form building application MAY use the information above to display information as follows:
Note that the same information would be generated by the following example,
which changes the order of the triples but not the sh:order values:
Appendix
Summary of SHACL Syntax Rules
This section enumerates all normative syntax rules of SHACL.
This section is automatically generated from other parts of this spec and hyperlinks are provided back
into the prose if the context of the rule in unclear.
Nodes that violate these rules in a shapes graph are ill-formed .
Syntax Rule Id
Syntax Rule Text
Summary of SHACL Core Validators
This section enumerates all normative validators of SHACL Core.
This section is automatically generated from other parts of this spec and hyperlinks are provided back
into the prose if the context of the validator in unclear.
Validators by Constraint Component
