Node targets (sh:targetNode)

A node target is defined with the sh:targetNode predicate. Each value of sh:targetNode can be an IRI or a literal. Each value of a node target defines a node to validate in the data graph.

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 target 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 defined with the sh:targetClass predicate. Each value of sh:targetClass must be 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 must 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 target 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 target 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 defined with the predicate sh:targetSubjectsOf, the values of which must be IRIs. For every value p of such a target, the validated 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 target 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 defined with the predicate sh:targetObjectsOf, the values of which must be IRIs. For every value p of such a target, the validated 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 target 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 must 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 defined in a shape with the property sh:property. Each value of sh:property must be an IRI or a blank node that is the subject of precisely one triple with either predicate sh:predicate or sh:path. The values of sh:predicate must be IRIs. The values of sh:path must be well-formed property paths following the SHACL property path syntax rules.

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.

Focus Node Constraints

Focus node constraints specify conditions that must be met by the focus node itself. Since focus node constraints operate directly on the input focus nodes they impose some limitations in comparison to property constraints. In particular, constraint parameters that operate on value sets, such as sh:hasValue and sh:equals, are not applicable to focus node constraints.

The class sh:Shape is defined as rdfs:subClassOf sh:Constraint. Every shape is also a focus node constraint.

ex:ExampleShapeWithFocusNodeConstraint
	a sh:Shape ;
	sh:targetClass ex:Person ;
	sh:stem "https://www.w3.org/People/" .

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. In the following example this technique is used to restrict the values of ex:customer 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 that is equivalent to a subset of SPARQL 1.1 property paths. In particular, SHACL supports the following SPARQL 1.1 property path constructs: PredicatePath, InversePath, SequencePath, AlternativePath, ZeroOrMorePath, OneOrMorePath and ZeroOrOnePath. A valid SHACL property path p is an IRI or a blank node that can be correctly traversed recursively using the following rules.

1. If the graph contains a triple of the form p sh:inversePath elt then the path becomes an InversePath element of elt and elt must be a valid SHACL property path. Corresponding rules apply for sh:zeroOrMorePath (ZeroOrMorePath), sh:zeroOrOnePath (ZeroOrOnePath) and sh:oneOrMorePath (OneOrMorePath).
2. If the graph contains a triple of the form p rdf:first elt, the path must be an RDF list with a at least two members. Each member must be valid SHACL property path that is converted into a sequence of either SequencePath or AlternativePath elements.
3. If the graph contains a triple of the form p sh:alternativePath elt, the value of path must be an RDF list with a at least two members. All members must be valid SHACL property paths that become a series of AlternativePath elements.
4. If p is an IRI then it is turned into a PredicatePath with value p.

A SHACL property path is invalid if:

• p is a blank node that is not handled by any of the above rules.
• During the path traversal the same node is reached more than once.
• There is a value for p with a predicate different from: sh:inversePath, sh:alternativePath, sh:zeroOrMorePath, sh:zeroOrOnePath, sh:oneOrMorePath or rdf:first.
• There are two or more triples with p as a subject.

The following example illustrates some valid SHACL property paths, together with their SPARQL 1.1 equivalents.

# ex:parent
[] sh:path ex:parent .

# ^ex:parent
[] sh:path [ sh:inversePath ex:parent ] .

# ex:parent/ex:firstName
[] sh:path ( ex:parent ex:firstName ) .
					
# rdf:type/rdfs:subClassOf*
[] sh:path ( rdf:type [ sh:zeroOrMorePath rdfs:subClassOf ] ) .

# ex:father|ex:mother
[] sh:path [ sh:alternativePath ( ex:father ex:mother  ) ] .

sh:path and sh:predicate

sh:predicate is a convention for declaring a simple predicate path of length one. In almost all cases, sh:path can be used in place of sh:predicate without changing the semantics of the property constraint. There are exceptions in cases when the value is a valid SHACL property path.

ex:ShapeWithIdenticalPath
	a sh:Shape ;
	sh:property [
		sh:predicate ex:mother .
	]
	sh:property [
		sh:path ex:mother .
	] .

ex:ShapeWithDifferentPath
	a sh:Shape ;
	sh:property [
		sh:predicate ex:parent .
	]
	sh:property [
		sh:path ex:parent .
	] .

ex:parent sh:alternativePath ( ex:father ex:mother  ) .

In the above example, both property constraints of ex:ShapeWithIdenticalPath declare an identical path to ex:mother. The property constraints in ex:ShapeWithDifferentPath denote different paths. The property constraint with sh:predicate denotes ex:parent while the property constraint with sh:path denotes the property path (ex:father|ex:mother).

Declaring the Severity of a Constraint

Constraints may specify a value for the property sh:severity in the shapes graph. The values of this property must be IRIs. SHACL includes the three pre-defined IRIs to represent severities listed in the table below. These are defined 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:severity 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:ValidationResult ;
	sh:focusNode ex:MyInstance ;
	sh:path ex:myProperty ;
	sh:severity sh:Warning ;
	sh:sourceConstraintComponent sh:DatatypeConstraintComponent ;
	sh:sourceShape ex:MyShape ;
	sh:value "http://toomanycharacters"^^xsd:anyURI ;
] .
[
	a sh:ValidationResult ;
	sh:focusNode ex:MyInstance ;
	sh:message "Too many characters"@en ;
	sh:message "Zu viele Zeichen"@de ;
	sh:path ex:myProperty ;
	sh:severity sh:Violation ;
	sh:sourceConstraintComponent sh:MaxLengthConstraintComponent ;
	sh:sourceShape ex:MyShape ;
	sh:value "http://toomanycharacters"^^xsd:anyURI ;
] .

Defining Messages for a Constraint

Constraints may have values for the property sh:message, and these values must be 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:message, 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:message in the validation results on further details on how the values of sh:message are populated.

Recursive shapes

A recursive shape is a shape whose constraints refer to the shape directly or transitively via the parameters of shape-based constraint components (e.g. sh:shape), logical constraint components (e.g. sh:or) or filter shapes (sh:filterShape). The handling of recursive shapes is not defined in SHACL and is left to SHACL processor implementations.

Focus node (sh:focusNode)

Validation results must have a single value for the property sh:focusNode to point to a node that has caused the result. This is the focus node that was validated when the validation result was produced.

Path (sh:path)

Validation results may have a value for the property sh:path pointing at a well-formed property path starting with the given sh:focusNode. For results produced by a property constraint, this path is always identical to either the sh:predicate or sh:path of the constraint.

Value (sh:value)

Validation results may include, as a value of the property sh:value, a specific node that has caused the result. The values of sh:value are populated by a SHACL processor based on the rules outlined in the section on Core Constraint Components. In most of these cases, the values of sh:value are the value nodes that have violated a constraint. For SPARQL-based constraints, the values of sh:value are derived using a Mapping of SPARQL Result Variables.

Source (sh:sourceConstraint, sh:sourceShape)

Validation results may link to the IRI of the constraint that has caused the result, specified via the property sh:sourceConstraint, and at the IRI of the shape defining the constraint, via sh:sourceShape.

Constraint Component (sh:sourceConstraintComponent)

For validation results produced as a result of a constraint component, the property sh:sourceConstraintComponent must have as its object value 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 value sh:MinCountConstraintComponent.

Detail (sh:detail)

The property sh:detail may link a (parent) result with one or more other (child) results that provide further details about the cause of the (parent) result. Depending on the capabilities of the SHACL processor, this may include violations of nested constraints that have been evaluated via sh:shape.

Message (sh:message)

Validation results may have values for the property sh:message to communicate additional textual details to humans. While sh:message 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 Defining Messages for a Constraint. In cases where a constraint does not define any values of sh:message in the shapes graph the following policy applies:

• For validation results produced as a result of SPARQL-based constraints and constraint components, the messages are derived from a Mapping of SPARQL Result Variables.
• For validation results produced as a result of constraint components from the SHACL Core, a SHACL processor MAY automatically generate other values for sh:message.

Severity (sh:severity)

Each validation result must have exactly one value for the property sh:severity, and this value must be a IRI. The values are derived from the shapes graph as described in the section Declaring the Severity of a Constraint.

sh:class

The property sh:class can be used to verify 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

The property sh:datatype can be used to restrict the datatype of all value nodes.

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

The property sh:nodeKind is used to restrict 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

The property sh:minCount restricts the minimum number of value nodes. 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

The property sh:maxCount restricts the maximum number of value nodes. 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:Alice ex:birthDate "May 5th 1990" .
ex:Bob ex:birthDate "May 5th 1990", "1990-05-05"^^xsd:date .

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

The properties from the following table restrict the range of value nodes. The supported datatypes of these 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

The property sh:minLength restricts the string length of value nodes. 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

The property sh:maxLength restricts the string length of value nodes 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

The property sh:pattern can be used to verify that every value nodes matches a given regular expression.

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

The property sh:stem can be used to verify that every value node in an IRIs 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://w3.org/People/Carol" .

sh:languageIn

The property sh:languageIn can be used to enumerate language tags that all value nodes must have.

Constraint Component IRI: sh:LanguageInConstraintComponent

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

The following example shape states that all values of ex:prefLabel must 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 must be 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 can be used to verify that the set of value nodes is equal to the set of nodes 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 verify that certain nodes must 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:Alice
	ex:firstName "Alice" ;
	ex:givenName "Alice" .

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

sh:disjoint

sh:disjoint can be used to verify that the set of value nodes is disjoint with the the set of nodes 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 verify that certain nodes must not 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 can be used to verify that every value node is smaller than all the nodes 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)) .
}

TODO: Decide what should happen if values are not comparable, i.e. < fails, similar to minExclusive etc.

The following example illustrates the use of sh:lessThan in a shape to verify that all values of ex:startDate must be "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 can be used to verify that every value node is smaller than or equal to all the nodes 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

SHACL supports a negation constraint component that can be used to verify that a value node does not validate against a shape. This is comparable to a logical "not" operator.

Constraint Component IRI: sh:NotConstraintComponent

The following example illustrates the use of sh:not in a shape to verify that certain 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:property1 ;
			sh:minCount 1 ;
		] ;
	] .

ex:InvalidInstance ex:property1 "Some value" .
ex:ValidInstance ex:property2 "Some value" .

sh:and

SHACL supports a conjunctive constraint component that can be used to test whether a value node validates against all provided shapes. This is comparable to a 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 verify that certain nodes have exactly one value of ex:property. This is achieved via the conjunction of a separate named shape (ex:SuperShape) which defines the minimum count, and a blank node shape that additionally defines 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

SHACL supports a high-level syntax for disjunctive constraints that can be used to test whether a value node validates against at least one out of several provided shapes. This is comparable to a 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 verify that certain 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:Alice ex:givenName "Alice" .
ex:Bob ex:firstName "Robert" .
ex:Clair ex:name "Clair" .

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:Alice ex:address [ a ex:Address ;
  ex:street "1-14-19" ;
  ex:city "湘南台" ;
  ex:country "日本" ] .
ex:Bob ex:address "123 Prinzengasse, Vaduz, Liechtenstein" .
ex:Claire ex:address [
  ex:street "улитса Декабристов, 55" ;
  ex:city "Санкт-Петербург" ;
  ex:country "Руссиа" ] .

sh:shape

sh:shape can be used verify that all value nodes validate against 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:node1
	ex:someProperty [
		ex:nestedProperty 42 ;
	] .

ex:node2
	ex:someProperty [
		ex:otherProperty 43 ;
	] .

sh:qualifiedValueShape, sh:qualifiedMinCount, sh:qualifiedMaxCount

The property sh:qualifiedValueShape can be used verify that a specified number of value nodes validate against the given shape. For each sh:qualifiedValueShape there must be either one sh:qualifiedMinCount or one sh:qualifiedMaxCount, or one of each, at the same subject.

Constraint Component IRI: sh:QualifiedValueShapeConstraintComponent

In the following example, the property ex:parent must have exactly two values, and at least one of them needs to be 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:node1
	ex:parent ex:John ;
	ex:parent ex:Jane .

ex:John
	ex:gender ex:male .

ex:Jane
	ex:gender ex:female .

ex:node2
	ex:parent ex:John .

ex:node3
	ex:parent ex:John ;
	ex:parent ex:June .

ex:June
	ex:sex ex:male .

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) must 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" . # should be an 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 MUST be an RDF list that has zero or more members. Each member of the list defines conditions on a subset of the value nodes and may contain the following parameters:

• zero or one sh:minCount. This defines the minimum cardinality of the corresponding subset.
• zero or one sh:maxCount. This defines 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 defined 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 RDF 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 RDF list is significant. TODO: This currently violates our definition of rdf:List members. In general, if the members of the RDF 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 restrict which properties can be applied to nodes. The SHACL Core language includes a property called sh:closed that can be assigned to a shape via the property sh:constraint to indicate that valid nodes must only have values for those properties that have been explicitly declared 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 verify that certain 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

The property sh:hasValue can be used to verify that one of the value nodes is a given RDF node.

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:alumnusOf ;
		sh:hasValue ex:Stanford ;
	] .

ex:Alice
	ex:alumnusOf ex:Stanford .

ex:Bob
	ex:alumnusOf ex:Harvard ;
	ex:alumnusOf ex:Stanford .

ex:Claire
	ex:alumnusOf ex:Harvard .

sh:in

The property sh:in exclusively enumerates the permitted value nodes. For example when specified as part of a property constraint, then each value of the given property must be a member of the specified RDF 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:pony1 ex:color ex:Pink .
ex:pony2 ex:color ex:Blue .
ex:pony3 ex:color ex:Pink, ex:Blue .

Parameter pre-binding

Every parameter name defines a pre-bound variable for the constraint component the parameter belongs to. This variable can be used in the SPARQL definition 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 must point at exactly one string representation of a SPARQL SELECT query via the property sh:select. The value of sh:select must be a valid SPARQL query using the aforementioned prefix handling rules. This type of validator can be used as values of sh:shapeValidator or sh:propertyValidator.

The following example illustrates the definition 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 must be literals with language \"{$lang}\"" ;
	sh:propertyValidator [
		a sh:SPARQLSelectValidator ;
		sh:message "Values must be 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 defined, 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 that all values of ex:germanLabel must carry the language tag de while all values of ex:englishLabel must have en as their language. These details are specified via two property constraints that provide values for the ex:lang parameter required by the constraint component.

SELECT queries used in the context of property constraints must 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. Furthermore, any query that uses the variable this as part of the Expression used in a SPARQL 1.1 Aggregate 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 SPARQL select validator may declare additional annotation properties 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 must point at exactly one string representation of a SPARQL ASK query via the property sh:ask. The value of sh:ask must be a valid SPARQL query using the aforementioned prefix handling rules. The ASK queries are expected to return true if a given value node (represented by the pre-bound variable value) is valid.

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 defines 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 must be literals with language \"{$lang}\"" ;
	sh:validator ex:hasLang .
	
ex:hasLang
	a sh:SPARQLAskValidator ;
	sh:message "Values must be 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 valid value nodes, while SELECT queries return the invalid value nodes.

TODO: The TopBraid SHACL API uses such ASK constraint declarations to install new SPARQL functions. Time permitting we could standardize that too, so that people can reuse the same business logic in the queries.