Node targets (sh:targetNode)

A node target is specified using the sh:targetNode predicate. Each value of sh:targetNode is either an IRI or a literal. Each value of a node target identifies an RDF term to be validated against the shape that is the subject of the sh:targetNode triple.

With the example data below, only ex:Alice is the target of the provided shape:

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

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

The following SPARQL query specifies the semantics of node targets. The variable targetNode is assumed to be pre-bound to the given value of sh:targetNode. All bindings of the variable this from the solution become focus nodes.

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

Class-based Targets (sh:targetClass)

A class target is specified with the sh:targetClass predicate. Each value of sh:targetClass is an IRI. For every value c of a class target, all SHACL instances of c in the data graph are validated against the subject of the sh:targetClass triple.

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

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

In this example, only ex:Alice and ex:Bob are focus nodes. Note that, according to the SHACL instance definition, all the rdfs:subClassOf declarations needed to walk the class hierarchy need to exist in the data graph. However, the ex:Person a rdfs:Class triple is not required to exist in either graphs.

In the following example, the selected focus node is only ex:Who.

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

The following SPARQL query specifies the semantics of class targets. The variable targetClass is assumed to be pre-bound to the given value of sh:targetClass. All bindings of the variable this from the solution become focus nodes.

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:Shape .

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

Subjects-of targets (sh:targetSubjectsOf)

A subjects-of target is specified with the predicate sh:targetSubjectsOf, the values of which are IRIs. For every value p of such a target, the focus nodes are defined as the set of subjects in the data graph that appear in a triple with p as a predicate.

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

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

In the example above, only ex:Alice is validated against the given shape, because it is the subject of a triple that has ex:knows as its predicate.

The following SPARQL query specifies the semantics of subjects-of targets. The variable targetSubjectsOf is assumed to be pre-bound to the given value of sh:targetSubjectsOf. All bindings of the variable this from the solution become focus nodes.

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

Objects-of targets (sh:targetObjectsOf)

An objects-of target is specified with the predicate sh:targetObjectsOf, the values of which are IRIs. For every value p of such a target, the focus nodes are defined as the set of objects in the data graph that appear in a triple with p as a predicate.

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

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

In the example above, only ex:Bob is validated against the given shape, because it is the object of a triple that has ex:knows as its predicate.

The following SPARQL query specifies the semantics of objects-of targets. The variable targetObjectsOf is assumed to be pre-bound to the given value of sh:targetObjectsOf. All bindings of the variable this from the solution become focus nodes.

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

Property Constraints (sh:predicate or sh:path)

Property constraints specify conditions that need to be met with respect to nodes that can be reached from the focus node either by directly following a given property (specified using sh:predicate) or a given property path (specified using sh:path).

Property constraints are associated with a shape with the property sh:property. Each value of sh:property is an IRI or a blank node that is the subject of precisely one triple with either predicate sh:predicate or sh:path. Each value of sh:predicate is an IRI. Each value of sh:path is a SHACL property path.

The following example illustrates the two syntax variations of property constraints.

ex:ExampleShapeWithPropertyConstraints
	a sh:Shape ;
	sh:property [
		sh:predicate ex:email ;
		sh:name "e-mail" ;
		sh:description "We need at least one email value" ;
		sh:minCount 1 ;
	] ;
	sh:property [
		sh:path (ex:knows ex:email) ;
		sh:name "Friend's e-mail" ;
		sh:description "We need at least one email for everyone you know" ;
		sh:minCount 1 ;
	] .

sh:PropertyConstraint is the class of property constraints. The objects of triples with sh:property as predicate have sh:PropertyConstraint as expected type.

Multiple Parameters

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 constraint node. 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:Shape ;
	sh:property [
		sh:predicate ex:customer ;
		sh:class ex:Customer ;
		sh:class ex:Person ;
	] .

Some constraint components such as sh:PatternConstaintComponent declare more than one parameter. Constraints are not allowed to have more than one value for any of the parameters of such components.

Property Paths

SHACL includes an RDF vocabulary to represent property paths equivalent to a subset of SPARQL 1.1 property paths. SHACL supports the following SPARQL 1.1 property path constructs: PredicatePath, InversePath, SequencePath, AlternativePath, ZeroOrMorePath, OneOrMorePath and ZeroOrOnePath.

A SHACL property path p is a node in an RDF graph when it satisfies the antecedent of one of the following rules. For each rule, the mapping from a SHACL property to a SPARQL property paths is provided.

1. If p is an IRI then the property path is mapped to a PredicatePath with p as predicate.
2. If p is a blank node that is the subject of exactly one triple with rdf:first as predicate and p as object, and p is a SHACL list L with at least two members and each member of L is a SHACL property path then, for the members of L: v1, v2, ..., vn, p is mapped to a SequencePath of v1 followed by v2, ..., followed by vn.
3. If p is a blank node that is the subject of exactly one triple with sh:alternativePath as predicate, L as object and no other triples, and L is a SHACL list with at least two members and each member of L is a SHACL property path then, for the members of L: v1, v2, ..., vn, p is mapped to a AlternativePath of v1 followed by v2, ..., followed by vn.
4. If p is a blank node that is the subject of exactly one triple with sh:inversePath as predicate, v as object and no other triples, then p is mapped to an InversePath of v.
5. If p is a blank node that is the subject of exactly one triple with sh:zeroOrMorePath as predicate, v as object and no other triples, then p is mapped to a ZeroOrMorePath of v.
6. If p is a blank node that is the subject of exactly one triple with sh:oneOrMorePath as predicate, v as object and no other triples, then p is mapped to an OneOrMorePath of v.
7. If p is a blank node that is the subject of exactly one triple with sh:zeroOrOnePath as predicate, v as object and no other triples, then p is mapped to a ZeroOrOnePath of v.

A node p is not a SHACL property path if p is a blank node and any path constructs of p directly or transitively reference p.

Two SHACL property paths are considered equivalent when they produce the exact same SPARQL 1.1 property path syntax.

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  ) ]

Declaring the Severity of a Constraint

Constraints can specify one value for the property sh:severity in the shapes graph. Each value of this property is an IRI. 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 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. For every constraint, sh:Violation is the default if sh:severity is unspecified. The following example illustrates this.

ex:MyShape
	a sh:Shape ;
	sh:targetNode ex:MyInstance ;
	sh:property [
		# Violations of sh:minCount and sh:datatype are produced as warnings
		sh:predicate ex:myProperty ;
		sh:minCount 1 ;
		sh:datatype xsd:string ;
		sh:severity sh:Warning ;
	] ;
	sh:property [
		# The default severity here is sh:Violation
		sh:predicate 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"^^xsd:boolean ;
	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 ;
	] ,
	[	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 ;
	] .

Declaring Messages for a Constraint

Constraints can have values for the property sh:message, and these values are either xsd:string literals or literals with a language tag. If a constraint has at least one value for sh:message in the shapes graph, then all validation results produced as a result of the constraint 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. A constraint should not have more than one value for sh:message with the same language tag.

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.

Deactivating a Constraint or Shape

SHACL includes a mechanism to deactivate a constraint or shape: If the constraint or shape has the value true for the property sh:deactivated then all focus nodes conform to it and the validation of the constraint or shape will never produce any validation results.

Use cases of this feature include shape reuse and debugging. In scenarios where constraints 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 constraints to exclude constraints 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 constraint may need to be disabled or modified by others, it is a good practice to use IRIs instead of blank nodes for the actual constraints. For example, a constraint on the property ex:name at the shape ex:Person may have the IRI ex:Person-name. Another typical use case of sh:deactivated is during the development and testing of shapes, to (temporarily) disable certain constraints.

The following example illustrates the use of sh:deactivated to deactivate a constraint. In cases where shapes are imported from other graphs, the sh:deactivated true triple would be in the importing graph.

ex:PersonShape
	a sh:Shape ;
	sh:targetClass ex:Person ;
	sh:property ex:PersonShape-name .

ex:PersonShape-name
	a sh:PropertyConstraint ;
	sh:predicate 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 .

Recursive shapes

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

• sh:and
• sh:or
• sh:not
• sh:shape
• sh:qualifiedValueShape
• sh:partition

A shape directly uses another shape when that other shape is the value of any of the shape-expecting constraint parameters of the shape itself or one of the property constraints of the shape. In the cases of sh:and, sh:or and sh:partition this includes the members of the lists that are the parameter values. The uses relationship between shapes is the transitive closure of the directly uses relationship. A shape is recursive if it uses itself.

The handling of recursive shapes is not defined in SHACL and is left to SHACL processor implementations. For example, SHACL processors may support recursion scenarios or produce an error when they detect recursion.

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 can contain additional information related to the validation report or the validation results, for example, provenance metadata.

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 and sh:resultSeverity are the only properties that are mandatory for all validation results. The property sh:sourceConstraintComponent is mandatory for validation results produced by violations of constraint components.

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

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

ex:ClassExampleShape
	a sh:Shape ;
	sh:targetNode ex:Bob, ex:Alice, ex:Carol ;
	sh:property [
		sh:predicate ex:knows ;
		sh:class ex:Person ;
	] .

ex:Alice a ex:Person .
ex:Bob ex:knows ex:Alice .
ex:Carol ex:knows ex:Bob .

sh:datatype

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

Constraint Component IRI: sh:DatatypeConstraintComponent

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

sh:nodeKind

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

Constraint Component IRI: sh:NodeKindConstraintComponent

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 ) )) .
}

ex:NodeKindExampleShape
	a sh:Shape ;
	sh:targetNode ex:Bob, ex:Alice ;
	sh:property [
		sh:predicate ex:knows ;
		sh:nodeKind ex:IRI ;
	] .

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

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

SELECT $this
WHERE {
	OPTIONAL {
		$this $PATH ?value .
	}
} 
GROUP BY $this
HAVING (COUNT(DISTINCT ?value) < $minCount)

ex:MinCountExampleShape
	a sh:Shape ;
	sh:targetNode ex:Alice, ex:Bob ;
	sh:property [
		sh:predicate 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. If this parameter is omitted then there is no limit on the number of triples.

Constraint Component IRI: sh:MaxCountConstraintComponent

SELECT $this
WHERE {
	$this $PATH ?value .
}
GROUP BY $this
HAVING (COUNT(DISTINCT ?value) > $maxCount)

ex:MaxCountExampleShape
	a sh:Shape ;
	sh:targetNode ex:Bob ;
	sh:property [
		sh:predicate ex:birthDate ;
		sh:maxCount 1 ;
	] .

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

sh:minExclusive, sh:minInclusive, sh:maxExclusive, sh:maxInclusive

The properties from the following table specify conditions to be satisfied by the range of value nodes. The supported datatypes of these value nodes are xsd:string, xsd:boolean, xsd:dateTime and all numeric datatypes such as xsd:integer.

Constraint Component IRIs: sh:MinExclusiveConstraintComponent, sh:MinInclusiveConstraintComponent, sh:MaxExclusiveConstraintComponent, sh:MaxInclusiveConstraintComponent

Note that if the comparison cannot be performed, for example when someone compares a string with an integer, then the SHACL processor will produce a validation result. This is different from, say, a plain SPARQL query, in which such failures would silently not lead to any results.

The following SPARQL definition covers sh:minExclusive - the other variations can be derived by replacing the < operator and the minExclusive variable.

ASK {
	FILTER ($minExclusive < $value)
}

ex:NumericRangeExampleShape
	a sh:Shape ;
	sh:targetNode ex:Bob, ex:Alice, ex:Ted ;
	sh:property [
		sh:predicate 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:minLength

sh:minLength specifies the minimum string length of each value node that satisfy the condition. This can be applied to any literals and IRIs, but not to blank nodes.

Constraint Component IRI: sh:MinLengthConstraintComponent

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

sh:maxLength

sh:maxLength specifies the maximum string length of each value node that satisfy the condition. This can be applied to any literals and IRIs, but not to blank nodes.

Constraint Component IRI: sh:MaxLengthConstraintComponent

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

ex:PasswordExampleShape
	a sh:Shape ;
	sh:targetNode ex:Bob, ex:Alice ;
	sh:property [
		sh:predicate 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

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

ex:PatternExampleShape
	a sh:Shape ;
	sh:targetNode ex:Bob, ex:Alice, ex:Carol ;
	sh:property [
		sh:predicate 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:stem

sh:stem specifies the condition that each value node is an IRI and the IRI starts with a given string value.

Constraint Component IRI: sh:StemConstraintComponent

ASK {
	FILTER (isIRI($value) && STRSTARTS(str($value), $stem))
}

ex:StemExampleShape
	a sh:Shape ;
	sh:targetNode ex:Bob, ex:Alice, ex:Carol ;
	sh:property [
		sh:predicate ex:w3cHomepage ;
		sh:stem "https://www.w3.org/People/" ;
	] .

ex:Alice ex:w3cHomepage <https://www.w3.org/People/Alice> .
ex:Bob ex:w3cHomepage <https://example.com/People/Bob> .
ex:Carol ex:w3cHomepage "https://www.w3.org/People/Carol" .

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

ASK {
	BIND (lang($value) AS ?valueLang) .
	FILTER EXISTS {
			GRAPH $shapesGraph {
				$languageIn (rdf:rest*)/rdf:first ?lang .
				FILTER (langMatches(?valueLang, ?lang))
			} 
		}
}

The following example shape states that all values of ex:prefLabel can be either in English or Māori.

ex:NewZealandLanguagesShape
	a sh:Shape ;
	sh:targetNode ex:Mountain, ex:Berg ;
	sh:property [
		sh:predicate 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. The values of sh:uniqueLang are of datatype xsd:booleans.

Constraint Component IRI: sh:UniqueLangConstraintComponent

SELECT DISTINCT $this ?lang
WHERE {
	{
		FILTER ($uniqueLang) .
	}
	$this $PATH ?value .
	BIND (lang(?value) AS ?lang) .
	FILTER (bound(?lang) && ?lang != "") . 
	FILTER EXISTS {
		$this $PATH ?otherValue .
		FILTER (?otherValue != ?value && ?lang = lang(?otherValue)) .
	}
}

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

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

SELECT DISTINCT $this ?value
WHERE {
	{
		$this $PATH ?value .
		MINUS {
			$this $equals ?value .
		}
	}
	UNION
	{
		$this $equals ?value .
		MINUS {
			$this $PATH ?value .
		}
	}
}

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:Shape ;
	sh:targetNode ex:Bob ;
	sh:property [
		sh:predicate 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 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:DisjointConstraintComponent

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:Shape ;
	sh:targetNode ex:USA, ex:Germany ;
	sh:property [
		sh:predicate 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

SELECT DISTINCT $this ?value
WHERE {
	$this $PATH ?value .
	$this $lessThan ?otherValue .
	FILTER (!(?value < ?otherValue)) .
}

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:Shape ;
	sh:property [
		sh:predicate ex:startDate ;
		sh:lessThan 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

SELECT DISTINCT $this ?value
WHERE {
	$this $PATH ?value .
	$this $lessThan ?otherValue .
	FILTER (!(?value <= ?otherValue)) .
}

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 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:Shape ;
	sh:targetNode ex:InvalidInstance1 ;
	sh:not [
		a sh:Shape ;
		sh:property [
			sh:predicate ex:property ;
			sh:minCount 1 ;
		] ;
	] .

ex:InvalidInstance1 ex:property "Some value" .

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

Note that although sh:and has an rdf: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:Shape ;
	sh:property [
		sh:predicate ex:property ;
		sh:minCount 1 ;
	] .

ex:ExampleAndShape
	a sh:Shape ;
	sh:targetNode ex:ValidInstance, ex:InvalidInstance ;
	sh:and (
		ex:SuperShape
		[
			a sh:Shape ;
			sh:property [
				sh:predicate 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

Note that although sh:or has an rdf: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:Shape ;
	sh:targetNode ex:Bob ;
	sh:or (
		[
			sh:property [
				sh:predicate ex:firstName ;
				sh:minCount 1 ;
			]
		]
		[
			sh:property [
				sh:predicate ex:givenName ;
				sh:minCount 1 ;
			]
		]
	) .

ex:Bob ex:firstName "Robert" .

The next example shows how sh:or can be used in a property constraint 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:Shape ;
	sh:targetClass ex:Person ;
	sh:property [
		sh:predicate ex:address ;
		sh:or (
			[
				sh:datatype xsd:string ;
			]
			[
				sh:class ex:Address ;
			]
		)
	] .

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

sh:shape

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

Constraint Component IRI: sh:ShapeConstraintComponent

In the following example, all values of the property ex:someProperty will validate with no results for the shape specified by a blank node that ensures that the property ex:nestedProperty has at least one value.

ex:ShapeExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:shape [
			a sh:Shape ;   # Optional
			sh:property [
				sh:predicate ex:nestedProperty ;
				sh:minCount 1 ;
			]
		]
	] .

ex:ShapeExampleValidResource
	ex:someProperty [
		ex:nestedProperty 42 ;
	] .

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.

Constraint Component IRI: sh:QualifiedValueShapeConstraintComponent

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:Shape ;
	sh:targetNode ex:QualifiedValueShapeExampleValidResource ;
	sh:property [
		sh:predicate ex:parent ;
		sh:minCount 2 ;
		sh:maxCount 2 ;
		sh:qualifiedValueShape [
			a sh:Shape ;   # Optional
			sh:property [
				sh:predicate 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 .

sh:partition

In some cases a given property may be multi-valued and it may be required that the set of values be partitioned into two or more subsets, each of which satisfies certain constraints.

For example, suppose that in the Library of Congress BIBFRAME (bf:) Cultural Heritage vocabulary each person (bf:Person) needs to be identified by (bf:identifiedBy) exactly one identifier from id.loc.gov and may have another identifier from viaf.org. No other identifiers are allowed. Thus the set of all identifiers is partitioned into two subsets, the first of which contains exactly one member and the second of which contains zero or one members. The following example shows a snippet of some valid BIBFRAME data.

<bf_Person1>
  	bf:identifiedBy <http://id.loc.gov/authorities/names/n80103961#RWO> ;
 	bf:identifiedBy <https://viaf.org/viaf/268367832/#Knape,_Joachim> .

The following example shows a snippet of some invalid BIBFRAME data.

<bf_Person1>
  	bf:identifiedBy <http://id.loc.gov/authorities/names/n80103961#RWO> ;
 	bf:identifiedBy <https://viaf.org/viaf/268367832/#Knape,_Joachim> ;
	bf:identifiedBy "this is a mistake" . # error

Qualified cardinality constraints provide a basis for expressing this type of partitioning requirement, but using them imposes a burden on the shapes author. In the BIBFRAME example the author would need to express the requirement that the set of all identifiers that are from neither id.loc.gov nor viaf.org is empty, i.e. it has a maximum cardinality of 0. Clearly, as more subsets of values are involved, the burden on the author increases. The sh:partition constraint makes it easier to express this type of requirement than it would be to use multiple qualified cardinality constraints. In effect, sh:partition chains together a sequence of qualified cardinality constraints and removes the set of value nodes matched by each from further consideration. If every value node gets matched in this process, then the sh:partition constraint reports no violations. Otherwise, any value nodes remaining are reported as violations of the constraint. The BIBFRAME example constraint is expressed as follows.

ex:BibframeShape a sh:Shape ;
	sh:property [
		sh:predicate bf:identifiedBy ;
		sh:partition (
			[sh:minCount 1; sh:maxCount 1; sh:pattern "^http://id.loc.gov/"]
			[sh:maxCount 1; sh:pattern "^https://viaf.org/"]
		)
] .

The value of the sh:partition constraint parameter is a SHACL list that has zero or more members. Each member of the list specifies conditions on a subset of the value nodes and may contain the following parameters:

• zero or one sh:minCount. This specifies the minimum cardinality of the corresponding subset.
• zero or one sh:maxCount. This specifies the maximum cardinality of the corresponding subset.
• any combination of parameters associated with node validation constraints. A node validation constraint is any constraint defined by a boolean function on nodes. These include the built-in constraints defined by sh:nodeKind, sh:partition, sh:minExclusive, etc. The corresponding subset consists of those remaining nodes for which the boolean function is true.

Note that a node that contains no parameters matches all nodes. Such a node is useful as the last member of the list where it acts as a default matching rule in the case where nodes that do not match any of the preceeding constraints are allowed. Note also that a qualified cardinality constraint declared using sh:qualifiedValueShape, sh:qualifiedMinCount, and sh:qualifiedMaxCount is equivalent to a sh:partition constraint that contains two nodes with the first one containing the corresponding parameters and the last one being the default matching rule that matches any set of nodes.

Each member of the list is used by the SHACL processor to match a subset of the value nodes. The SHACL processor matches as many nodes as possible and then compares the result with the specified minimum and maximum cardinalities if specified. This is referred to as a greedy matching algorithm. Greedy pattern matching is commonly used with textual regular expressions. Nodes that match are removed from further matching. Thus the set of all value nodes becomes partitioned by the matching algorithm. The following paragraphs define this algorithm more precisely.

Let D be a data graph and let F be a focus node in D. Let S be a shapes graph, let T be a shape in S, and let C be a sh:partition constraint in T. Let N be the set of value nodes for C in D at F. Recall that N depends on how C is related to T.

• If (T, sh:constraint, C) is in S then N consists of just the node F.
• If (T, sh:property, C) and (C, sh:predicate, P) are in S then N consists of all the nodes X such that (F, P, X) is in D.

Let the value of the sh:partition parameter be the SHACL list with members (Q₁, ..., Q_n). The SHACL processor MUST perform the following steps to validate the constraint C at F.

1. Let R denote the set of remaining value nodes. Initialize R to N.
2. Repeat the following for Q = Q₁, ..., Q_n
   1. Let P be the conjunction of all the node validation constraints in Q.
   2. Compute R' to be the set of all nodes in R that satisfy P, i.e. R' = {X in R | P(X) = true}
   3. If Q contains a minimum cardinality m_min and the number of nodes in R' is less than m_min, i.e. m_min > #R', then report a constraint violation and exit the loop.
   4. If Q contains a maximum cardinality m_max and the number of nodes in R' is greater then m_max, i.e. m_max < #R', then report a constraint violation and exit the loop.
   5. Remove R' from R, i.e. set R = R \ R'.
3. If R is non-empty and no violations have been reported yet then report a violation.

Note that the order of nodes within the SHACL list is significant. TODO: This currently violates our definition of rdf:List members. In general, if the members of the SHACL list are reordered then different value node sets will be matched and different violation results will be reported.

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 focus node has values only for those properties that have been explicitly enumerated via sh:property.

Constraint Component IRI: sh:ClosedConstraintComponent

SELECT $this (?predicate AS ?path) ?value
WHERE {
	{
		FILTER ($closed) .
	}
	$this ?predicate ?value .
	FILTER (NOT EXISTS {
		GRAPH $shapesGraph {
			$currentShape sh:property/sh:predicate ?predicate .
		}
	} && (!bound($ignoredProperties) || NOT EXISTS {
		GRAPH $shapesGraph {
			$ignoredProperties rdf:rest*/rdf:first ?predicate .
		}
	}))
}

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:exampleProperty1 and ex:exampleProperty2. The "ignored" property rdf:type would also be allowed.

ex:ClosedShapeExampleShape
	a sh:Shape ;
	sh:targetNode ex:Alice, ex:Bob ;
	sh:closed true ;
	sh:ignoredProperties (rdf:type) ;
	sh:property [
		sh:predicate ex:firstName ;
	] ;
	sh:property [
		sh:predicate ex:lastName ;
	] .

ex:Alice
	ex:firstName "Alice" .

ex:Bob
	ex:firstName "Bob" ;
	ex:middleInitial "J" .

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

SELECT $this
WHERE {
	FILTER NOT EXISTS { $this $PATH $hasValue }
}

ex:StanfordGraduate
	a sh:Shape ;
	sh:targetNode ex:Alice ;
	sh:property [
		sh:predicate 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

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

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

ex:RainbowPony ex:color ex:Pink .

Parameter pre-binding

Every parameter name is used as the name of a pre-bound variable for the constraint component the parameter belongs to. This variable can be used in the SPARQL queries of the constraint component and a SHACL Full processor MUST pre-bind it to the parameter value.

Validators based on SPARQL SELECT Queries

Validators that are SHACL instances of sh:SPARQLSelectValidator have exactly one string representation of a SPARQL SELECT query via the property sh:select. The value of sh:select is a valid SPARQL query using the aforementioned prefix handling rules. The query returns the result variable this in its SELECT clause. This type of validator can be used as values of sh:shapeValidator or sh:propertyValidator.

The following example illustrates the declaration of a constraint component based on a SPARQL SELECT query. It is a generalized variation of the SPARQL-based example constraint from the section on SPARQL-based constraints. That SPARQL query included two constants: the specific property ex:germanLabel and the language tag de. Constraint components make it possible to generalize such scenarios, so that constants get pre-bound with parameters. This allows the query logic to be reused in multiple places, without having to write any new SPARQL.

ex:LanguageConstraintComponentUsingSELECT
	a sh:ConstraintComponent ;
	rdfs:label "Language constraint component" ;
	sh:parameter [
		sh:predicate 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))
			}
			"""
	] .

Once a constraint component has been declared (in a shapes graph), its parameters can be used as illustrated in the following example.

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

The example shape above specifies the condition that all values of ex:germanLabel carry the language tag de while all values of ex:englishLabel have en as their language. These details are specified via two property constraints that have values for the ex:lang parameter required by the constraint component.

SELECT queries used in the context of property constraints use a special variable named PATH as a placeholder for the predicate or path used by the constraint. The only legal use of this variable is in the predicate position of a triple pattern. A query that uses the variable PATH in any other position is invalid.

A SHACL Full processor executes the provided SPARQL query on the data graph to produce validation results. In the context of property constraints, the SHACL Full processor will first substitute all occurrences of the variable PATH with the provided property path derived from the value of either sh:predicate or sh:path in the constraint. The resulting SPARQL query is then evaluated with the same pre-bound variables as outlined in the section for SPARQL-based Constraints ($this etc). Additionally, the value of each declared parameter of the constraint component needs to be pre-bound for the variable derived by the local name of the parameter's sh:predicate. For example, if a non-optional parameter declares sh:predicate ex:lang then the variable lang needs to be pre-bound. The result set of the SELECT query is turned into validation results using the same rules as outlined in the section for SPARQL-based Constraints. In addition to the result properties listed in that section, the property sh:sourceConstraintComponent MUST point at the IRI of the constraint component that has been evaluated. Furthermore, a SHACL Full processor MUST use any additional annotation properties that are associated with a SPARQL select validator via sh:resultAnnotation.

Validators based on SPARQL ASK Queries

Many constraint components are of the form in which all value nodes are tested individually against some boolean condition. Writing SELECT queries for these becomes burdensome, especially if a constraint component can be used for both property constraints and shapes. SHACL Full provides an alternative, more compact syntax for validators based on ASK queries. This type of validators can be used as values of the property sh:validator.

Validators that are SHACL instances of sh:SPARQLAskValidator point at exactly one string representation of a SPARQL ASK query via the property sh:ask. The value of sh:ask is a valid SPARQL query using the aforementioned prefix handling rules. The ASK queries return true if and only if a given value node (represented by the pre-bound variable value) conforms to the constraint.

Prior to evaluation, a SHACL Full processor transforms the provided ASK query into a SELECT query using the following templates. The resulting SELECT query can then be evaluated using the same algorithm as for SELECT-based validators. The processor drops the ASK keyword, any top-level dataset clauses and solution modifiers, leaving only the GroupGraphPattern including the outermost {...} pair. This block then substitutes ... in the template.

Template for sh:Shape context:

	SELECT $this ?value
	WHERE {
		BIND ($this AS ?value) .
		FILTER NOT EXISTS ...
	}

Template for sh:PropertyConstraint context:

	SELECT DISTINCT $this ?value
	WHERE {
		$this $PATH ?value .
		FILTER NOT EXISTS ...
	}

Note that the template above includes a DISTINCT keyword because a SPARQL path expression may return the same ?value multiple times, yet each value node is only validated once.

Once the corresponding template has been applied, the resulting SELECT query will be evaluated using the same approach as outlined above. Actual SHACL implementations may of course use a different approach internally, as long as the results are equivalent to the described approach.

The following example declares a constraint component using an ASK query.

ex:LanguageConstraintComponentUsingASK
	a sh:ConstraintComponent ;
	rdfs:label "Language constraint component" ;
	sh:parameter [
		sh:predicate 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))
		}
		""" .

Note that the validation condition implemented by an ASK query is "in the inverse direction" from its SELECT counterpart: ASK queries return true for value nodes that conform to the constraint, while SELECT queries return those value nodes that do not conform.