2.1.1 Constraints, Parameters and Constraint Components

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.

ex:InvoiceShape
	a sh:NodeShape ;
	sh:property [
		sh:path ex:customer ;
		sh:class ex:Customer ;
		sh:class 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.

ex:MultiplePatternsShape
	a sh:NodeShape ;
	sh:property [
		sh:path ex:name ;
		sh:pattern "^Start" ;
		sh:flags "i" ;
	] ;
	sh:property [
		sh:path ex:name ;
		sh:pattern "End$" ;
	] .

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.

2.1.2 Focus Nodes

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 informative.

The set of focus nodes for a shape may be identified as follows:

• specified in a shape using target declarations
• specified in any constraint that references a shape in parameters of shape-expecting constraint parameters (e.g. sh:node)
• specified as explicit input to the SHACL processor for validating a specific RDF term against a shape

2.1.3 Targets

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. 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 by the shape in the shapes graph.

SHACL Core includes the following kinds of targets: node targets, class-based targets (including implicit class-based targets), subjects-of targets, and objects-of targets.

The remainder of this introduction is informative.

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.

ex:PersonShape
	a sh:NodeShape ;
	sh:targetNode ex:Alice .

ex:Alice a ex:Person .
ex:Bob a ex:Person .

SELECT DISTINCT ?this    # ?this is the focus node
WHERE {
	BIND ($targetNode AS ?this)    # $targetNode is pre-bound to ex:Alice
}

ex:PersonShape
	a sh:NodeShape ;
	sh:targetClass ex:Person .

ex:Alice a ex:Person .
ex:Bob a ex:Person .
ex:NewYork a ex:Place .

ex:Doctor rdfs:subClassOf ex:Person .
ex:Who a ex:Doctor .
ex:House a ex:Nephrologist .

SELECT DISTINCT ?this    # ?this is the focus node
WHERE {
	?this rdf:type/rdfs:subClassOf* $targetClass .    # $targetClass is pre-bound to ex:Person
}

ex:Person
	a rdfs:Class, sh:NodeShape .

ex:Alice a ex:Person .
ex:NewYork a ex:Place .

ex:TargetSubjectsOfExampleShape
	a sh:NodeShape ;
	sh:targetSubjectsOf ex:knows .

ex:Alice ex:knows ex:Bob .
ex:Bob ex:livesIn ex:NewYork .

SELECT DISTINCT ?this    # ?this is the focus node
WHERE {
	?this $targetSubjectsOf ?any .    # $targetSubjectsOf is pre-bound to ex:knows
}

ex:TargetObjectsOfExampleShape
	a sh:NodeShape ;
	sh:targetObjectsOf ex:knows .

ex:Alice ex:knows ex:Bob .
ex:Bob ex:livesIn ex:NewYork .

SELECT DISTINCT ?this    # ?this is the focus node
WHERE {
	?any $targetObjectsOf ?this .    # $targetObjectsOf is pre-bound to ex:knows
}

2.1.4 Declaring the Severity of a Shape

Shapes can specify one value for the property sh:severity in the shapes graph. Each value of sh:severity in a shape is an IRI.

The values of sh:severity are called severities. SHACL includes the three IRIs listed in the table below to represent severities. These are declared in the SHACL vocabulary as SHACL instances of sh:Severity.

The remainder of this section is informative.

The specific values of sh:severity have no impact on the validation, but MAY be used by user interface tools 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, 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 [    # _:b1
		# Violations of sh:minCount and sh:datatype are produced as warnings
		sh:path ex:myProperty ;
		sh:minCount 1 ;
		sh:datatype xsd:string ;
		sh:severity sh:Warning ;
	] ;
	sh:property [    # _:b2
		# The default severity here is sh:Violation
		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 _:b1 ;
	] ,
	[	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 _:b2 ;
	]
] .

2.1.5 Declaring Messages for a Shape

Shapes can have values for the property sh:message. The values of sh:message in a shape are either xsd:string literals or literals with a language tag. A shape 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. (Note that in SHACL-SPARQL, SPARQL-based constraints and SPARQL-based constraint components provide additional means to declare such messages.)

The remainder of this section is informative.

The example from the previous section uses this mechanism to supply the second validation result with two messages. See the section on sh:resultMessage in the validation results on further details on how the values of sh:resultMessage are populated.

2.1.6 Deactivating a Shape

Shapes can have at most one value for the property sh:deactivated. The value of sh:deactivated in a shape must be either true or false.

A shape that has the value true for the property sh:deactivated is called deactivated. All RDF terms conform to a deactivated shape.

The remainder of this section is informative.

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.

ex:JohnDoe a ex:Person .

2.3.1 SHACL Property Paths

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.1 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.1 equivalents.

SPARQL Property path: ex:parent
SHACL Property path: ex:parent

SPARQL Property path: ^ex:parent
SHACL Property path: [ sh:inversePath ex:parent ]

SPARQL Property path: ex:parent/ex:firstName
SHACL Property path: ( ex:parent ex:firstName )

SPARQL Property path: rdf:type/rdfs:subClassOf*
SHACL Property path: ( rdf:type [ sh:zeroOrMorePath rdfs:subClassOf ] )

SPARQL Property path: ex:father|ex:mother
SHACL Property path: [ sh:alternativePath ( ex:father ex:mother  ) ]

3.4.1 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.

3.4.2 Handling of Ill-formed Shapes Graphs

If the shapes graph contains ill-formed nodes, then the result of the validation process is undefined. A SHACL processor SHOULD produce a failure in this case. See also 3.6.1.3 Syntax Checking of Shapes Graph (sh:shapesGraphWellFormed).

3.4.3 Handling of Recursive Shapes

The following properties are the so-called shape-expecting constraint parameters in SHACL Core:

• sh:and
• sh:not
• sh:or
• sh:property
• sh:qualifiedValueShape
• sh:node
• sh:xone

The following properties are the so-called list-taking constraint parameters in SHACL Core:

• sh:and
• sh:in
• sh:languageIn
• sh:or
• sh:xone

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.

3.6.1 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.

3.6.2 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.

4.1.1 sh:class

The condition specified by sh:class is that each value node is a SHACL instance of a given type.

Constraint Component IRI: sh:ClassConstraintComponent

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.

ASK {
	$value rdf:type/rdfs:subClassOf* $class .
}

ex:ClassExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:Bob, ex:Alice, ex:Carol ;
	sh:property [
		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 ] .

4.1.2 sh:datatype

sh:datatype specifies a condition to be satisfied with regards to the datatype of each value node.

Constraint Component IRI: sh:DatatypeConstraintComponent

The remainder of this section is informative.

The values of sh:datatype are typically datatypes, such as xsd:string. Note that using rdf:langString as value of sh:datatype can be used to test if value nodes have a language tag.

ex:DatatypeExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:Alice, ex:Bob, ex:Carol ;
	sh:property [
		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 .

4.1.3 sh:nodeKind

sh:nodeKind specifies a condition to be satisfied by the RDF node kind of each value node.

Constraint Component IRI: sh:NodeKindConstraintComponent

The remainder of this section is informative.

ASK {
	FILTER ((isIRI($value) && $nodeKind IN ( sh:IRI, sh:BlankNodeOrIRI, sh:IRIOrLiteral ) ) ||
		(isLiteral($value) && $nodeKind IN ( sh:Literal, sh:BlankNodeOrLiteral, sh:IRIOrLiteral ) ) ||
		(isBlank($value)   && $nodeKind IN ( sh:BlankNode, sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral ) )) .
}

The following example states that all values of ex:knows need to be IRIs, at any subject.

ex:NodeKindExampleShape
	a sh:NodeShape ;
	sh:targetObjectsOf ex:knows ;
	sh:nodeKind sh:IRI .

ex:Bob ex:knows ex:Alice .
	ex:Alice ex:knows "Bob" .

4.2.1 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

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 .

4.2.2 sh:maxCount

sh:maxCount specifies the maximum number of value nodes that satisfy the condition.

Constraint Component IRI: sh:MaxCountConstraintComponent

The remainder of this section is informative.

ex:MaxCountExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:Bob ;
	sh:property [
		sh:path ex:birthDate ;
		sh:maxCount 1 ;
	] .

ex:Bob ex:birthDate "May 5th 1990" .

4.3.1 sh:minExclusive

Constraint Component IRI: sh:MinExclusiveConstraintComponent

The remainder of this section is informative.

The SPARQL expression produces an error if the value node cannot be compared to the specified range, for example when someone compares a string with an integer. If the comparison cannot be performed, then there is a validation result. This is different from, say, a plain SPARQL query, in which such errors would silently not lead to any results.

ASK {
	FILTER ($minExclusive < $value)
}

4.3.2 sh:minInclusive

Constraint Component IRI: sh:MinInclusiveConstraintComponent

The remainder of this section is informative.

ASK {
	FILTER ($minInclusive <= $value)
}

4.3.3 sh:maxExclusive

Constraint Component IRI: sh:MaxExclusiveConstraintComponent

The remainder of this section is informative.

ASK {
	FILTER ($maxExclusive > $value)
}

4.3.4 sh:maxInclusive

Constraint Component IRI: sh:MaxInclusiveConstraintComponent

The remainder of this section is informative.

ASK {
	FILTER ($maxInclusive >= $value)
}

4.4.1 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

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.

ASK {
	FILTER (STRLEN(str($value)) >= $minLength) .
}

4.4.2 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

The remainder of this section is informative.

ASK {
	FILTER (STRLEN(str($value)) <= $maxLength) .
}

ex:PasswordExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:Bob, ex:Alice ;
	sh:property [
		sh:path ex:password ;
		sh:minLength 8 ;
		sh:maxLength 10 ;
	] .

ex:Bob ex:password "123456789" .
ex:Alice ex:password "1234567890ABC" .

4.4.3 sh:pattern

sh:pattern specifies a regular expression that each value node matches to satisfy the condition.

Constraint Component IRI: sh:PatternConstraintComponent

The remainder of this section is informative.

ASK {
	FILTER (!isBlank($value) && IF(bound($flags), regex(str($value), $pattern, $flags), regex(str($value), $pattern)))
}

ex:PatternExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:Bob, ex:Alice, ex:Carol ;
	sh:property [
		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" .

4.4.4 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

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 [
		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 .

4.4.5 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

The remainder of this section is informative.

ex:UniqueLangExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:Alice, ex:Bob ;
	sh:property [
		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 .

4.5.1 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

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 [
		sh:path ex:firstName ;
		sh:equals ex:givenName ;
	] .

ex:Bob
	ex:firstName "Bob" ;
	ex:givenName "Bob" .

4.5.2 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

The remainder of this section is informative.

SELECT DISTINCT $this ?value
WHERE {
	$this $PATH ?value .
	$this $disjoint ?value .
}

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 [
		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" .

4.5.3 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

The remainder of this section is informative.

SELECT $this ?value
WHERE {
	$this $PATH ?value .
	$this $lessThan ?otherValue .
	BIND (?value < ?otherValue AS ?result) .
	FILTER (!bound(?result) || !(?result)) .
}

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.

ex:LessThanExampleShape
	a sh:NodeShape ;
	sh:property [
		sh:path ex:startDate ;
		sh:lessThan ex:endDate ;
	] .

4.5.4 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

The remainder of this section is informative.

SELECT $this ?value
WHERE {
	$this $PATH ?value .
	$this $lessThan ?otherValue .
	BIND (?value <= ?otherValue AS ?result) .
	FILTER (!bound(?result) || !(?result)) .
}

4.6.1 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

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.

ex:NotExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:InvalidInstance1 ;
	sh:not [
		a sh:PropertyShape ;
		sh:path ex:property ;
		sh:minCount 1 ;
	] .

ex:InvalidInstance1 ex:property "Some value" .

4.6.2 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

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.

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 blank node 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" .

4.6.3 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

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.

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.

ex:OrConstraintExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:Bob ;
	sh:or (
		[
			sh:path ex:firstName ;
			sh:minCount 1 ;
		]
		[
			sh:path ex:givenName ;
			sh:minCount 1 ;
		]
	) .

ex:Bob ex:firstName "Robert" .

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 [
		sh:path ex:address ;
		sh:or (
			[
				sh:datatype xsd:string ;
			]
			[
				sh:class ex:Address ;
			]
		)
	] .

ex:Bob ex:address "123 Prinzengasse, Vaduz, Liechtenstein" .

4.6.4 sh:xone

sh:xone specifies the condition that each value node conforms to exactly one of the provided shapes.

Constraint Component IRI: sh:XoneConstraintComponent

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" .

4.7.1 sh:node

sh:node specifies the condition that each value node conforms to the given node shape.

Constraint Component IRI: sh:NodeConstraintComponent

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 [
		sh:path ex:postalCode ;
		sh:datatype xsd:string ;
		sh:maxCount 1 ;
	] .

ex:PersonShape
	a sh:NodeShape ;
	sh:targetClass ex:Person ;
	sh:property [   # _:b1
		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 _:b1 ;
	]
] .

4.7.2 sh:property

sh:property can be used to specify that each value node has a given property shape.

Constraint Component IRI: sh:PropertyShapeComponent

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.

4.7.3 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.

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 [
		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:property (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.

ex:HandShape
	a sh:NodeShape ;
	sh:targetClass ex:Hand ;
	sh:property [
		sh:path ex:digit ;
		sh:maxCount 5 ;
	] ;
	sh:property [
		sh:path ex:digit ;
		sh:qualifiedValueShape [ sh:class ex:Thumb ] ;
		sh:qualifiedValueShapesDisjoint true ;
		sh:qualifiedMinCount 1 ;
		sh:qualifiedMaxCount 1 ;
	] ;
	sh:property [
		sh:path ex:digit ;
		sh:qualifiedValueShape [ sh:class ex:Finger ] ;
		sh:qualifiedValueShapesDisjoint true ;
		sh:qualifiedMinCount 4 ;
		sh:qualifiedMaxCount 4 ;
	] .

4.8.1 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

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" .

4.8.2 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

The remainder of this section is informative.

ex:StanfordGraduate
	a sh:NodeShape ;
	sh:targetNode ex:Alice ;
	sh:property [
		sh:path ex:alumniOf ;
		sh:hasValue ex:Stanford ;
	] .

ex:Alice
	ex:alumniOf ex:Harvard ;
	ex:alumniOf ex:Stanford .

4.8.3 sh:in

sh:in specifies the condition that each value node is a member of a provided SHACL list.

Constraint Component IRI: sh:InConstraintComponent

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.

ASK {
	GRAPH $shapesGraph {
		$in (rdf:rest*)/rdf:first $value .
	}
}

ex:InExampleShape
	a sh:NodeShape ;
	sh:targetNode ex:RainbowPony ;
	sh:property [
		sh:path ex:color ;
		sh:in ( ex:Pink ex:Purple ) ;
	] .

ex:RainbowPony ex:color ex:Pink .

5.2.1 Prefix Declarations for SPARQL Queries

A shapes graph may include declarations of namespace prefixes so that these prefixes can be used to abbreviate the SPARQL queries derived from the same shapes graph. The syntax of such prefix declarations is illustrated by the following example.

ex:
	a owl:Ontology ;
	owl:imports sh: ;
	sh:declare [
		sh:prefix "ex" ;
		sh:namespace "http://example.com/ns#"^^xsd:anyURI ;
	] ;
	sh:declare [
		sh:prefix "schema" ;
		sh:namespace "http://schema.org/"^^xsd:anyURI ;
	] .

The values of the property sh:declare are IRIs or blank nodes, and these values are called prefix declarations. The SHACL vocabulary includes the class sh:PrefixDeclaration as type for such prefix declarations although no rdf:type triple is required for them. Prefix declarations have exactly one value for the property sh:prefix. The values of sh:prefix are literals of datatype xsd:string. Prefix declarations have exactly one value for the property sh:namespace. The values of sh:namespace are literals of datatype xsd:anyURI. Such a pair of values specifies a single mapping of a prefix to a namespace.

The recommended subject for values of sh:declare is the IRI of the named graph containing the shapes that use the prefixes. These IRIs are often declared as an instance of owl:Ontology, but this is not required.

Prefix declarations can be used by SPARQL-based constraints, the validators of SPARQL-based constraint components, and by similar features defined by SHACL extensions. These nodes can use the property sh:prefixes to specify a set of prefix mappings. An example use of the sh:prefixes property can be found in the example above.

The values of sh:prefixes are either IRIs or blank nodes. A SHACL processor collects a set of prefix mappings as the union of all individual prefix mappings that are values of the SPARQL property path sh:prefixes/owl:imports*/sh:declare of the SPARQL-based constraint or validator. If such a collection of prefix declarations contains multiple namespaces for the same value of sh:prefix, then the shapes graph is ill-formed. (Note that SHACL processors MAY ignore prefix declarations that are never reached).

A SHACL processor transforms the values of sh:select (and similar properties such as sh:ask) into SPARQL by prepending PREFIX declarations for all prefix mappings. Each value of sh:prefix is turned into the PNAME_NS, while each value of sh:namespace is turned into the IRIREF in the PREFIX declaration. For the example shapes graph above, a SHACL-SPARQL processor would produce lines such as PREFIX ex: <http://example.com/ns#>. The SHACL-SPARQL processor MUST produce a failure if the resulting query string cannot be parsed into a valid SPARQL 1.1 query.

In the rest of this document, the sh:prefixes statements may have been omitted for brevity.

5.3.1 Pre-bound Variables in SPARQL Constraints ($this, $shapesGraph, $currentShape)

When the SPARQL queries of SPARQL-based constraints and the validators of SPARQL-based constraint components are processed, the SHACL-SPARQL processor pre-binds values for the variables in the following table.

5.3.2 Mapping of Solution Bindings to Result Properties

The property values of the validation result nodes are derived by the following rules, through a combination of result solutions and the values of the constraint itself. The rules are meant to be executed from top to bottom, so that the first bound value will be used.

6.2.1 Parameter Declarations (sh:parameter)

The parameters of a constraint component are declared via the property sh:parameter. The values of sh:parameter are called parameter declarations. The class sh:Parameter may be used as type of parameter declarations but no such triple is required. Each parameter declaration has exactly one value for the property sh:path. At parameter declarations, the value of sh:path is an IRI.

The local name of an IRI is defined as the longest NCNAME at the end of the IRI, not immediately preceded by the first colon in the IRI. The parameter name of a parameter declaration is defined as the local name of the value of sh:path. To ensure that a correct mapping from parameters into SPARQL variables is possible, the following syntax rules apply:

Every parameter name is a valid SPARQL VARNAME. Parameter names must not be one of the following: this, shapesGraph, currentShape, path, PATH, value. A constraint component where two or more parameter declarations use the same parameter names is ill-formed.

The values of sh:optional must be literals with datatype xsd:boolean. A parameter declaration can have at most one value for the property sh:optional. If set to true then the parameter declaration declares an optional parameter. Every constraint component has at least one non-optional parameter.

The class sh:Parameter is defined as a SHACL subclass of sh:PropertyShape, and all properties that are applicable to property shapes may also be used for parameters. This includes descriptive properties such as sh:name and sh:description but also constraint parameters such as sh:class. Shapes that do not conform with the constraints declared for the parameters are ill-formed. Some implementations MAY use these constraint parameters to prevent the execution of constraint components with invalid parameter values.

6.2.2 Label Templates (sh:labelTemplate)

The property sh:labelTemplate can be used at any constraint component to suggest how constraints could be rendered to humans. The values of sh:labelTemplate are strings (possibly with language tag) and are called label templates.

The remainder of this section is informative.

Label templates can include the names of the parameters that are declared for the constraint component using the syntaxes {?varName} or {$varName}, where varName is the name of the parameter name. At display time, these {?varName} and {$varName} blocks SHOULD be replaced with the actual parameter values. There may be multiple label templates for the same subject, but they should not have the same language tags.

6.2.3 Validators

For every supported shape type (i.e., property shape or node shape) the constraint component declares a suitable validator. For a given constraint, a validator is selected from the constraint component using the following rules, in order:

1. For node shapes, use one of the values of sh:nodeValidator, if present.
2. For property shapes, use one of the values of sh:propertyValidator, if present.
3. Otherwise, use one of the values of sh:validator.

If no suitable validator can be found, a SHACL-SPARQL processor ignores the constraint.

SHACL-SPARQL includes two types of validators, based on SPARQL SELECT (for sh:nodeValidator and sh:propertyValidator) or SPARQL ASK queries (for sh:validator).

ex:LanguageConstraintComponentUsingSELECT
	a sh:ConstraintComponent ;
	rdfs:label "Language constraint component" ;
	sh:parameter [
		sh:path ex:lang ;
		sh:datatype xsd:string ;
		sh:minLength 2 ;
		sh:name "language" ;
		sh:description "The language tag, e.g. \"de\"." ;
	] ;
	sh:labelTemplate "Values are literals with language \"{$lang}\"" ;
	sh:propertyValidator [
		a sh:SPARQLSelectValidator ;
		sh:message "Values are literals with language \"{?lang}\"" ;
		sh:select """
			SELECT DISTINCT $this ?value
			WHERE {
				$this $PATH ?value .
				FILTER (!isLiteral(?value) || !langMatches(lang(?value), $lang))
			}
			"""
	] .

ex:LanguageExampleShape
	a sh:NodeShape ;
	sh:targetClass ex:Country ;
	sh:property [
		sh:path ex:germanLabel ;
		ex:lang "de" ;
	] ;
	sh:property [
		sh:path ex:englishLabel ;
		ex:lang "en" ;
	] .

ex:LanguageConstraintComponentUsingASK
	a sh:ConstraintComponent ;
	rdfs:label "Language constraint component" ;
	sh:parameter [
		sh:path ex:lang ;
		sh:datatype xsd:string ;
		sh:minLength 2 ;
		sh:name "language" ;
		sh:description "The language tag, e.g. \"de\"." ;
	] ;
	sh:labelTemplate "Values are literals with language \"{$lang}\"" ;
	sh:validator ex:hasLang .
	
ex:hasLang
	a sh:SPARQLAskValidator ;
	sh:message "Values are literals with language \"{$lang}\"" ;
	sh:ask """
		ASK {
			FILTER (isLiteral($value) && langMatches(lang($value), $lang))
		}
		""" .