1.1 Terminology

Throughout this document, the following terminology is used.

1.2 Document Conventions

Within this document, the following namespace prefix bindings are used:

Note that the URI of the graph defining the SHACL vocabulary itself is equivalent to the namespace above, i.e. it includes the #. References to the SHACL vocabulary, e.g. via owl:imports SHOULD include the #.

Throughout the document, color-coded boxes containing RDF graphs in Turtle will appear. These fragments of Turtle documents use the prefix bindings given above.

# This box represents an input shapes graph

# Triples that can be ommitted are marked as grey e.g.
<s> <p> <o> .

# This box represents an input data graph.
# When highlighting is used in the examples:

# Elements highlighted in blue are focus nodes that are
# selected by some scope of a shape under discussion
# and validate against the shape's filters, if any.
ex:Bob a ex:Person .

# Elements highlighted in red are focus nodes that fail validation
ex:Alice a ex:Person .

# This box represents an output results graph

SHACL Definitions appear in blue boxes:

# This box contains SPARQL or textual definitions. 

1.3 SHACL Example

The following example data graph contains three nodes that are SHACL instances of the class ex:Person.

ex:Alice
	a ex:Person ;
	ex:child ex:Calvin ;
	ex:ssn "987-65-432A" .
  
ex:Bob
	a ex:Person ;
	ex:child ex:Calvin ;
	ex:ssn "123-45-6789" ;
	ex:ssn "124-35-6789" .
  
ex:Calvin
	a ex:Person ;
	ex:school ex:TrinityAnglicanSchool .

This example uses SHACL to define the following constraints:

• A SHACL instance of ex:Person may have at most one value for the property ex:ssn, and this value must be a literal with the datatype xsd:string that matches a specified regular expression.
• A SHACL instance of ex:Person may have unlimited values for the property ex:child, and these values must be IRIs and they must be SHACL instances of ex:Person.
• A person's parents are represented using the property ex:child in the inverse direction. A SHACL instance of ex:Person may have at most 2 parents, i.e. may be the object of at most two triples where the predicate is ex:child.
• A SHACL instance of ex:Person may not have values for any other property apart from ex:ssn, ex:child and rdf:type.

The constraints above can be represented using the following shapes graph:

ex:PersonShape
	a sh:Shape ;
	sh:scopeClass ex:Person ;    # Applies to all persons
	sh:property [
		sh:predicate ex:ssn ;
		sh:maxCount 1 ;
		sh:datatype xsd:string ;
		sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ;
	] ;
	sh:property [
		sh:predicate ex:child ;
		sh:class ex:Person ;
		sh:nodeKind sh:IRI ;
	] ;
	sh:inverseProperty [
		rdfs:comment "A person's parents are represented via ex:child used in the inverse direction." ;
		sh:predicate ex:child ;
		sh:name "parent" ;
		sh:maxCount 2 ;
	] ;
	sh:constraint [
		sh:closed true ;
		sh:ignoredProperties ( rdf:type ) ;
	] .

We can use the shape definition above to skim through some of the key terminology used by SHACL. The focus nodes for the shape ex:PersonShape are all SHACL instances of the class ex:Person. These focus nodes are the scope of the shape and are defined using the property sh:scopeClass. The shape has two property constraints, linked to the shape using the property sh:property, one inverse property constraint represented as value of sh:inverseProperty, and one node constraint linked to the shape using sh:constraint.

Some of the constraints specify multiple constraint components in order to restrict multiple aspects of the property values. For example, in the property constraint for ex:ssn, three constraint components are used. These constraint components are identified by their parameters sh:datatype, sh:pattern and sh:maxCount. For each focus node, property values of ex:ssn will be validated against all three components. The constraint on the inverse property values of sh:child has only one constraint component identified by the sh:maxCount parameter. Note that this constraint uses the non-validating property sh:name to suggest a human-readable name for the property when used in the inverse direction.

SHACL validation based on the provided data graph and shapes graph would produce the following validation results:

[	a sh:ValidationResult ;
	sh:sourceConstraintComponent sh:RegexConstraintComponent ;
	sh:focusNode ex:Alice ;
	sh:subject ex:Alice ;
	sh:predicate ex:ssn ;
	sh:object "987-65-432A" ;
	sh:severity sh:Violation ;
] ;
[	a sh:ValidationResult ;
	sh:sourceConstraintComponent sh:MaxCountConstraintComponent ;
	sh:focusNode ex:Bob ;
	sh:subject ex:Bob ;
	sh:predicate ex:ssn ;
	sh:severity sh:Violation ;
] ;
[	a sh:ValidationResult ;
	sh:sourceConstraintComponent sh:ClosedConstraintComponent ;
	sh:focusNode ex:Calvin ;
	sh:subject ex:Calvin ;
	sh:predicate ex:school ;
	sh:object ex:TrinityAnglicanSchool ;
	sh:severity sh:Violation ;
] .

The first validation result is produced because ex:Alice has a value for ex:ssn that does not match the regular expression specified by the property sh:regex. The second validation result is produced because ex:Bob has more than the permitted number of values for the property ex:ssn as specified by the sh:maxCount of 1. The third validation result is produced because the shape ex:PersonShape has a node constraint using the property sh:closed but ex:Calvin uses the property ex:school which is neither one of the predicates from any of the property constraints at the shape, nor one of the properties listed using sh:ignoredProperties.

1.4 Relationship between SHACL and RDFS inferencing

SHACL uses the RDF and RDFS vocabularies, but full RDFS inferencing is not required. However, SHACL processors MUST identify SHACL instances of a class both in the data graph and the shapes graph without mutating either graph during the validation process. Furthermore, SHACL processors may operate on RDF graphs that include entailments - either pre-computed before being submitted to a SHACL processor or performed on the fly as part of SHACL processing. To support processing of entailments, SHACL includes the property sh:entailment to indicate what inferencing is required by a given shapes graph. SHACL implementations may, but are not required to, support entailment regimes.

1.5 Relationship between SHACL and SPARQL

This specification uses parts of SPARQL 1.1 in the normative definition of the semantics of the SHACL Core constraints and scopes. However, SPARQL is not required for the implementation of the SHACL Core language.

SPARQL variables using $ marker represent external values that must be pre-bound in the SPARQL query before execution.

In some places, the specification assumes that the provided SPARQL engines are preserving the identity of blank nodes, so that repeated invocations of queries consistently identify and communicate the same blank nodes.

The definition of some constraints requires or is simplified through access to the shapes graph during query execution. SHACL validation engines MAY pre-bind the variable $shapesGraph to provide access to the shapes graph. Access to the shapes graph is not a requirement for supporting the SHACL core language. The variable $shapesGraph can also be used in user-defined SPARQL constraints and SPARQL-based constraint components. However, such constraints may not be interoperable across different SHACL validation engines or not applicable to remote RDF datasets.

Some SHACL constraints are defined with the use of the sh:hasShape function. SHACL additionally introduces mechanisms to define constraints, scopes and new functions in SPARQL. Implementations that cover only the the SHACL Core features are not required to implement these mechanisms or the sh:hasShape function.

1.6 Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, and SHOULD are to be interpreted as described in [RFC2119].

TODO: We still need to mark non-normative sections.

2.1 Scopes

Scopes specify which nodes in the data graph are considered in-scope for a shape and SHACL includes six core scope types: node scopes, class-based scopes, property scopes, inverse property scopes, all subjects scopes and all objects scopes.

The SHACL language additionally defines a general scoping mechanism based on SPARQL.

When multiple scopes are provided in a shape, the scope of a shape is the union of all in-scope nodes produced by these scopes. In addition to the explicit scoping mechanism, a shape may get an implicit scope when it is mentioned from other shapes (e.g. in shape-based constraint components). Nodes specified by scopes are not required to exist in the data graph.

SELECT DISTINCT ?this
WHERE {
	BIND ($scopeNode AS ?this)
}

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

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

SELECT DISTINCT ?this
WHERE {
	?this rdf:type/rdfs:subClassOf* $scopeClass
}

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

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

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

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

ex:Alice a ex:Person .

SELECT DISTINCT ?this
WHERE {
	?this $scopeProperty ?any .
}

ex:PropertyScopeExampleShape
	a sh:Shape ;
	sh:scopeProperty ex:knows .

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

SELECT DISTINCT ?this
WHERE {
	?any $scopeInverseProperty ?this .
}

ex:InversePropertyScopeExampleShape
	a sh:Shape ;
	sh:scopeInverseProperty ex:knows .

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

SELECT DISTINCT ?this
WHERE {
	?this ?anyPredicate ?anyObject .
}

ex:AllSubjectsScopeExampleShape
	a sh:Shape ;
	sh:scope [
		a sh:AllSubjectsScope ;
	] .

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

SELECT DISTINCT ?this
WHERE {
	?anySubject ?anyPredicate ?this .
}

ex:AllObjectsScopeExampleShape
	a sh:Shape ;
	sh:scope [
		a sh:AllObjectsScope ;
	] .

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

2.2 Filter Shapes

A filter is a shape in a shapes graph that can be used to limit the in-scope nodes that are validated against the constraints of another shape. Only those nodes that validate against all the filters of a shape are validated against its constraints. A filter is specified with the sh:filterShape predicate. When the filter is specified in a shape, the filter applies for all the shape constraints. When the filter is specified in a specific constraint, the filter applies for that specific constraint only.

The following example states that the sh:minCount constraint on ex:email is filtered to include only SHACL instances of ex:Person that are ex:members of ex:W3c.

ex:ExampleFilteredShape
	a sh:Shape ;
	sh:scopeClass ex:Person ;
	sh:filterShape [
		a sh:Shape ; # Optional triple
		sh:property [
			sh:predicate ex:member ;
			sh:hasValue ex:W3c ;
		]
	] ;
	sh:property [
		sh:predicate ex:email ;
		sh:minCount 1 ;
	] .

ex:Alice a ex:Person ;
	ex:member ex:W3c ;
	ex:email <mailto:alice@example.org> .
ex:John a ex:Person ;
	ex:member ex:W3c .
ex:Bob a ex:Person ;
	ex:member ex:Acme .

[  a sh:ValidationResult ;
	sh:severity sh:Violation ;
	sh:focusNode ex:John ;
	sh:subject ex:John ;
	sh:predicate ex:email ;
	sh:message "sh:minCount for ex:email is '1'." ;
	sh:sourceConstraintComponent sh:MinCountConstraintComponent ; 
] . 

The following example shows a sh:filterShape that is defined on a specific constraint, instead of the whole shape.

ex:FilteredExampleShape
	a sh:Shape ;
	sh:scopeClass ex:Person ;
	sh:property [
		sh:predicate ex:email ;
		sh:minCount 1 ;
		sh:filterShape [
			sh:property [
				sh:predicate ex:member ;
				sh:hasValue ex:W3c ;
			]
		] ;
	] .

Note that filter shapes are always validated prior to applying their associated shape or constraint. This includes scenarios such as sh:shape where a shape is explicitly referenced by another constraint. However, during the validation of a shape referenced via sh:shape, the declared scopes of these shapes are not used to limit the set of focus nodes.

2.3 Constraints

A shape defines constraints and sh:Constraint is the SHACL superclass of all constraint types. The SHACL core language defines the following three constraint types:

• sh:PropertyConstraint is the class of constraints that specify conditions that must be met with respect to triples with the focus node as a subject and a particular property as a predicate.
• sh:InversePropertyConstraint is the class of constraints that specify conditions that must be met with respect to triples with the focus node as an object and a particular property as a predicate.
• sh:NodeConstraint is the class of constraints that specify arbitrary conditions that must be met with respect to the focus node.

Additional types of constraints can be added using the extension mechanism, either SPARQL-based constraints or SPARQL-based constraint components.

Shapes link to their constraints via the following properties:

• sh:property links shapes to property constraints. The default value type of sh:property is sh:PropertyConstraint.
• sh:inverseProperty links shapes to inverse property constraints. The default value type of sh:inverseProperty is sh:InversePropertyConstraint.
• sh:constraint links shapes to node constraints. The default value type of sh:constraint is sh:NodeConstraint.

The values of sh:property, sh:inverseProperty, and sh:constraint must be IRIs or blank nodes. The values of sh:property and sh:inverseProperty must be the subject of precisely one triple with predicate sh:predicate, and the object of this triple must be an IRI.

All three properties have a default value type and thus, the rdf:type triple can be omitted. Instances of constraint types can be reused across different shapes. However, all constraint types are pairwise disjoint and no more than one property of sh:property, sh:inverseProperty and sh:constraint can link to the same RDF node within the same shapes graph.

Constraints may contain non-validating properties (such as sh:description) or parameters of constraint components (e.g. sh:minCount). Constraint components define one or more parameter properties and validation instructions (such as those implemented as SPARQL queries) that can be used to perform the validation for the given focus node and parameter values. The relationship between a constraint component and the constraint types that it can be used with is called the context of the component. For example, the context of the component defining the sh:closed property is sh:NodeConstraint. This means that the property sh:closed can only be used in SHACL instances of sh:NodeConstraint. The catalog of constraint components in the Core of SHACL is defined in section 4.

The following examples illustrate two ways of using (property) constraints. The first example uses a blank node:

ex:InlinePropertyConstraintExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:name "some property" ;
		sh:description "Description of the role of ex:someProperty (in the context of the constraint)" ;
		sh:minCount 1 ;
		sh:class ex:SomeClass ;
	] .

The second example defines a constraint as an IRI node, allowing it to be more easily referenced and shared across multiple shapes:

ex:StandAlonePropertyConstraintExampleShape
	a sh:Shape ;
	sh:property ex:StandAlonePropertyConstraintExampleShape_someProperty .

ex:StandAlonePropertyConstraintExampleShape_someProperty
	a sh:PropertyConstraint ;
	sh:predicate ex:someProperty ;
	sh:defaultValue ex:SomeInstance ;
	sh:minCount 1 ;
	sh:class ex:SomeClass .

Parameters of constraint components that only declare one parameter (such as sh:class) may be used multiple times within the same constraint node. In the following example this technique is used to restrict the values of a property to be SHACL instances of both ex:Customer and ex:MalePerson.

ex:ShapeWithTwoClasses
	a sh:Shape ;
	sh:property [
		sh:predicate ex:someProperty ;
		sh:class ex:Customer ;
		sh:class ex:MalePerson ;
	] .

3.1 Shapes Graph

The shapes graph contains shape definitions that a data graph can be tested against. Shape definitions can be reusable validation components. Importing multiple shapes graphs can be achieved with the predicate owl:imports. SHACL validation engines SHOULD transitively follow all values of owl:imports to other graphs and use the resulting union graph as shapes graph to the validation process.

In addition to shape definitions, the shapes graph may contain additional information for the validation engine such as entailment directives.

3.2 Data Graph

The data graph contains the RDF data that a SHACL engine can validate. SHACL treats it as a general RDF graph and makes no assumption if it is e.g. an RDF dataset, an in-memory graph or a named graph in a remote SPARQL endpoint.

The data graph SHOULD include all the ontology axioms related to the data and especially all the rdfs:subClassOf triples in order for SHACL to correctly identify class scopes and validate core SHACL constraints. If such triples are missing, the validation could report false violations or miss to report some violations.

A data graph can include triples used to suggest one or more shapes graphs to a SHACL validation engine with the predicate sh:shapesGraph. Every value of this property is an IRI representing a shapes graph that should be used to validate the data graph. A SHACL validation engine MAY use such suggestions to determine which shapes graph to use for validating a data graph.

In the following example, a tool may use the union of ex:graph-shapes1 and ex:graph-shapes2 graphs (and their owl:imports) as the shapes graph when validating the given graph.

[] sh:shapesGraph ex:graph-shapes1 ;
	sh:shapesGraph ex:graph-shapes2 .

3.3 Validation report

The validation report is the result of the validation process and includes a set of zero or more validation results. Each validation result is assigned a severity that can be informative, non-critical (warning) or violation. A validation process is considered successful when the validation report contains only informative or non-critical results. In addition to severities, each validation results contains a set of required or optional values that are described in the SHACL Validation Results Vocabulary.

The validation results produced by a SHACL validation engine MUST be the product of validation of the data graph only. Some engines MAY also report errors in the shapes graph, but those errors MUST NOT be mixed with the data validation results using the same results vocabulary.

ex:ExampleConstraintViolation
	a sh:ValidationResult ;
	sh:severity sh:Violation ;
	sh:focusNode ex:Bob ;
	sh:subject ex:Bob ;
	sh:predicate ex:age ;
	sh:object "twenty two" ;
	sh:message "ex:age expects a literal of datatype xsd:integer." ;
	sh:sourceConstraintComponent sh:DatatypeConstraintComponent .

ex:MyShape
	a sh:Shape ;
	sh:property [
		# Violations of either minCount and 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 for sh:maxCount is sh:Violation
		sh:predicate ex:myProperty ;
		sh:maxCount 1 ;
	] .

4.1 Value Type Constraint Components

The constraint components in this section have in common that they define restrictions on the type of the nodes.

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* $class } .
}

ex:ClassExampleShape
	a sh:Shape ;
	sh:scopeNode 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 .

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER NOT EXISTS {
			GRAPH $shapesGraph {
				$classIn (rdf:rest*)/rdf:first ?class .
			}
			FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* ?class }
		}
}

ex:ClassInExampleShape
	a sh:Shape ;
	sh:scopeNode ex:Bob, ex:Alice, ex:Carol ;
	sh:property [
		sh:predicate ex:affiliatedWith ;
		sh:classIn ( ex:University ex:Organisation ) ;
	] .

ex:MIT a ex:University .
ex:W3c a ex:Organisation .

ex:Bob ex:affiliatedWith ex:MIT .
ex:Alice ex:affiliatedWith ex:W3c .
ex:Carol ex:affiliatedWith ex:ABC .

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER (!isLiteral(?value) || datatype(?value) != $datatype) .
}

ex:DatatypeExampleShape
	a sh:Shape ;
	sh:scopeNode ex:Alice, ex:Bob ;
	sh:property [
		sh:predicate ex:age ;
		sh:datatype xsd:integer ;
	] .

ex:Alice ex:age "23"^^xsd:integer .
ex:Bob ex:age "twenty two" .

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER (!isLiteral(?value) || NOT EXISTS {
			GRAPH $shapesGraph {
				$datatypeIn (rdf:rest*)/rdf:first ?datatype .
			} 
			BIND (datatype(?value) AS ?valueDatatype) .
			FILTER (?valueDatatype = $datatype) .
		})
	}
}

ex:DatatypeInExampleShape
	a sh:Shape ;
	sh:scopeNode ex:Bob, ex:Alice, ex:Ted ;
	sh:property [
		sh:predicate ex:name ;
		sh:datatypeIn ( xsd:string rdf:langString ) ;
	] .

ex:Bob ex:name "Bob"@en .
ex:Alice ex:name "Alice" .
ex:Ted ex:name 23 .

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER NOT EXISTS {
		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:scopeNode 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" .

4.2 Cardinality Constraint Components

The constraint components in this section can be applied to either a property constraint or an inverse property constraint, to represent restrictions on the number of values that the focus node may have for these properties.

SELECT $this ($this AS ?subject) $predicate
WHERE {
	{
		SELECT (COUNT(?value) AS ?count)
		WHERE {
			$this $predicate ?value .
		}
	}
	FILTER (?count < $minCount)
}

ex:MinCountExampleShape
	a sh:Shape ;
	sh:scopeNode ex:Alice, ex:Bob ;
	sh:property [
		sh:predicate ex:name ;
		sh:minCount 1 ;
	] .

ex:Alice ex:name "Alice" .
ex:Bob ex:givenName "Bob"@en .

SELECT $this ($this AS ?subject) $predicate
WHERE {
	{
		SELECT (COUNT(?value) AS ?count)
		WHERE {
			$this $predicate ?value .
		}
	}
	FILTER (?count > $maxCount))
}

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

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

4.3 Value Range Constraint Components

The following constraint components represent range restrictions on nodes that are comparable via operators such as < and >.

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	BIND (?value > $minExclusive AS ?result) .
	FILTER (!?result || !bound(?result)) .
}

ex:NumericRangeExampleShape
	a sh:Shape ;
	sh:scopeNode 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" .

4.4 String-based Constraint Components

The constraint components in this section have in common that they are representing restrictions on the string representation of certain nodes.

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER (isBlank(?value) || STRLEN(str(?value)) < $minLength) .
}

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER (isBlank(?value) || STRLEN(str(?value)) > $maxLength) .
}

ex:PasswordExampleShape
	a sh:Shape ;
	sh:scopeNode 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" .

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER (isBlank(?value) || IF(bound($flags), !regex(str(?value), $pattern, $flags), !regex(str(?value), $pattern))) .
}

ex:PatternExampleShape
	a sh:Shape ;
	sh:scopeNode 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" .

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER (!isIRI(?value) || !STRSTARTS(str(?value), $stem) ) .
}

ex:StemExampleShape
	a sh:Shape ;
	sh:scopeNode 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" .

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

ex:UniqueLangExampleShape
	a sh:Shape ;
	sh:scopeNode 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 .

4.5 Property Pair Constraint Components

The constraint components in this section restrict the sets of values represented by the sh:predicate used in the property constraint, and another property that is specified as the value of the respective parameter such as sh:equals.

SELECT $this ($this AS ?subject) $predicate ?object
WHERE {
	{
		$this $predicate ?object .
		FILTER NOT EXISTS {
			$this $equals ?object .
		}
	}
	UNION
	{
		$this $equals ?object .
		FILTER NOT EXISTS {
			$this $predicate ?object .
		}
	}
}

ex:EqualExampleShape
	a sh:Shape ;
	sh:scopeNode ex:Bob ;
	sh:property [
		sh:predicate ex:firstName ;
		sh:equals ex:givenName ;
	] .

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

SELECT $this ($this AS ?subject) $predicate ?object
WHERE {
	$this $predicate ?object .
	$this $disjoint ?object .
}

ex:DisjointExampleShape
	a sh:Shape ;
	sh:scopeNode 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" .

SELECT $this ($this AS ?subject) $predicate ?object
WHERE {
	$this $predicate ?object .
	$this $lessThan ?object2 .
	FILTER (!(?object < ?object2)) .
}

ex:LessThanExampleShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:startDate ;
		sh:lessThan ex:endDate ;
	] .

SELECT $this ($this AS ?subject) $predicate ?object
WHERE {
	$this $predicate ?object .
	$this $lessThanOrEquals ?object2 .
	FILTER (!(?object <= ?object2)) .
}

4.6 Logical Constraint Components

The constraint components in this section implement the common logical operators and, or and not.

SELECT $this ?failure
WHERE {
	BIND (sh:hasShape($this, $not, $shapesGraph) AS ?hasShape) .
	BIND (!bound(?hasShape) AS ?failure) .
	FILTER (?failure || ?hasShape) .
}

ex:NotExampleShape
	a sh:Shape ;
	sh:scopeNode ex:InvalidInstance1 ;
	sh:constraint [
		sh:not [
			a sh:Shape ;
			sh:property [
				sh:predicate ex:property ;
				sh:minCount 1 ;
			] ;
		]
	] .

ex:InvalidInstance1 ex:property "Some value" .

SELECT $this ?failure
WHERE {
	{
		SELECT (SUM(?s) AS ?count)
		WHERE {
			GRAPH $shapesGraph {
				$and rdf:rest*/rdf:first ?shape .
			}
			BIND (sh:hasShape($this, ?shape, $shapesGraph) AS ?hasShape) .
			BIND (IF(bound(?hasShape), IF(!?hasShape, 1, 0), 'error') AS ?s) .
		}
	}
	BIND (!bound(?count) AS ?failure) .
	FILTER IF(?failure, true, ?count > 0) .
}

ex:SuperShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:property ;
		sh:minCount 1 ;
	] .

ex:ExampleAndShape
	a sh:Shape ;
	sh:scopeNode ex:ValidInstance, InvalidInstance ;
	sh:constraint [
		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" .

SELECT $this ?failure
WHERE {
	{
		SELECT (SUM(?s) AS ?count)
		WHERE {
			GRAPH $shapesGraph {
				$or rdf:rest*/rdf:first ?shape .
			}
			BIND (sh:hasShape($this, ?shape, $shapesGraph) AS ?hasShape) .
			BIND (IF(bound(?hasShape), IF(?hasShape, 1, 0), 'error') AS ?s) .
		}
	}
	BIND (!bound(?count) AS ?failure) .
	FILTER IF(?failure, true, ?count = 0) .
}

ex:OrConstraintExampleShape
	a sh:Shape ;
	sh:scopeNode ex:Bob ;
	sh:constraint [
		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" .

4.7 Shape-based Constraint Components

The constraint components in this section can be used to represent complex restrictions based on applying shape definitions on the property values.

SELECT $this ($this AS ?subject) $predicate ?object ?failure
WHERE {
	$this $predicate ?object .
	BIND (sh:hasShape(?object, $shape, $shapesGraph) AS ?hasShape) .
	BIND (!bound(?hasShape) AS ?failure) .
	FILTER (?failure || !?hasShape) .
}

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

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

SELECT $this ($this AS ?subject) $predicate ?failure
WHERE {
	{
		SELECT (SUM(?s) AS ?count)
		WHERE {
			{
				FILTER NOT EXISTS { $this $predicate ?value } .
				BIND (0 AS ?s) .
			}
			UNION
			{
				$this $predicate ?value .
				BIND (sh:hasShape(?value, $qualifiedValueShape, $shapesGraph) AS ?hasShape) .
				BIND (IF(bound(?hasShape), IF(?hasShape, 1, 0), 'error') AS ?s) .
			}
		}
	}
	BIND (!bound(?count) AS ?failure) .
	FILTER IF(?failure, true, ?count < $qualifiedMinCount) .
}

SELECT $this ($this AS ?subject) $predicate ?failure
WHERE {
	{
		SELECT (SUM(?s) AS ?count)
		WHERE {
			{
				FILTER NOT EXISTS { $this $predicate ?value } .
				BIND (0 AS ?s) .
			}
			UNION
			{
				$this $predicate ?value .
				BIND (sh:hasShape(?value, $qualifiedValueShape, $shapesGraph) AS ?hasShape) .
				BIND (IF(bound(?hasShape), IF(?hasShape, 1, 0), 'error') AS ?s) .
			}
		}
	}
	BIND (!bound(?count) AS ?failure) .
	FILTER IF(?failure, true, ?count > $qualifiedMaxCount) .
}

ex:QualifiedValueShapeExampleShape
	a sh:Shape ;
	sh:scopeNode 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 .

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

<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

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/"]
		)
] .

4.8 Other Constraint Components

This section enumerates core constraint components that did not fit into the other categories.

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

ex:ClosedShapeExampleShape
	a sh:Shape ;
	sh:scopeNode ex:Alice, ex:Bob ;
	sh:constraint [
		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" .

ex:ClosedShapeExampleShape
	a sh:Shape ;
	sh:constraint sh:Closed ;
	sh:property [
		sh:predicate ex:firstName ;
	] ;
	sh:property [
		sh:predicate ex:lastName ;
	] .

SELECT $this ($this AS ?subject) $predicate
WHERE {
	FILTER NOT EXISTS {
		$this $predicate $hasValue .
	}
}

ex:StanfordGraduate
	a sh:Shape ;
	sh:scopeNode ex:Alice ;
	sh:property [
		sh:predicate ex:alumniOf ;
		sh:hasValue ex:Stanford ;
	] .

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

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
	$this $predicate ?value .
	FILTER NOT EXISTS {
		GRAPH $shapesGraph {
			$in (rdf:rest*)/rdf:first ?value .
		}
	}
}

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

ex:RainbowPony ex:color ex:Pink .

4.9 Non-Validating Constraint Characteristics

While the previous sections introduced properties that represent validation conditions, this section covers properties that are ignored by SHACL validation engines. The use of these properties is entirely optional and not subject to formal interpretation contracts. They may be used for purposes such as form building or predictable printing of RDF files.

Property constraints may have one or more values for sh:name to provide human-readable labels for the property in the scope where it appears. If present, tools SHOULD prefer those locally defined labels over globally defined labels at the rdf:Property itself. For example, if a form displays a resource that is in the scope of a given shape, and the shape defines a sh:property constraint with an sh:name, then the tool SHOULD use the provided name. Similarly, property constraints may have an sh:description to provide a description of the property in the given context. Both sh:name and sh:description may have multiple values, but SHOULD only have one value per language tag.

Property constraints may have one value for the property sh:order to indicate the relative order of the property constraint for purposes such as form building. The values of sh:order must be decimals. sh:order is not used for validation purposes. If present, the recommended use of sh:order is to sort the property constraints in an ascending order, for example so that properties with smaller order are placed above (or to the left) of properties with larger order.

Property constraints may link to an SHACL instance of the class sh:PropertyGroup using the property sh:group to indicate that the constraint belongs to a group of related property constraints. Each group may have additional triples that serve application purposes, such as an rdfs:label for form building. Groups may also have an sh:order property to indicate the relative ordering of groups within the same form.

Property constraints may have a single value for sh:defaultValue. The default value does not have fixed semantics in SHACL, but MAY be used by user interface tools to pre-populate input widgets. The value type of the sh:defaultValue SHOULD align with the specified sh:datatype or sh:class of the same constraint.

The following example illustrates the use of these various features together.

ex:PersonFormShape
	a sh:Shape ;
	sh:property [
		sh:predicate ex:firstName ;
		sh:name "first name" ;
		sh:description "The person's given name(s)" ;
		sh:order 0 ;
		sh:group ex:NameGroup ;
	] ;
	sh:property [
		sh:predicate ex:lastName ;
		sh:name "last name" ;
		sh:description "The person's last name" ;
		sh:order 1 ;
		sh:group ex:NameGroup ;
	] ;
	sh:property [
		sh:predicate ex:streetAddress ;
		sh:name "street address" ;
		sh:description "The street address including number" ;
		sh:order 11 ;
		sh:group ex:AddressGroup ;
	] ;
	sh:property [
		sh:predicate ex:locality ;
		sh:name "locality" ;
		sh:description "The suburb, city or town of the address" ;
		sh:order 12 ;
		sh:group ex:AddressGroup ;
	] ;
	sh:property [
		sh:predicate ex:postalCode ;
		sh:name "postal code" ;
		sh:name "zip code"@en-US ;
		sh:description "The postal code of the locality" ;
		sh:order 13 ;
		sh:group ex:AddressGroup ;
	] .

ex:NameGroup
	a sh:PropertyGroup ;
	sh:order 0 ;
	rdfs:label "Name" .

ex:AddressGroup
	a sh:PropertyGroup ;
	sh:order 1 ;
	rdfs:label "Address" .

A form building application may use the information above to display information as follows:

5.1 Syntax of SPARQL-based Constraints

sh:SPARQLConstraint is a SHACL subclass of sh:Constraint and is the class of all SPARQL-based constraints. SPARQL-based constraints must have exactly one value for the property sh:select. The SPARQL queries linked to a constraint via sh:select must be string literals that can be parsed into legal SPARQL 1.1 queries of the query form SELECT.

Before parsing the values of sh:select, a SHACL processor must prepend PREFIX declarations for all namespace prefixes declared via the property sh:prefix in the current shapes graph. The subjects of sh:prefix triples must be IRIs, which become the IRIREF in the PREFIX declaration. The objects of sh:prefix triples must be string literals, which become the PNAME_NS in the PREFIX declaration. For the example shapes graph below, a SHACL processor would produce the line PREFIX ex: <http://example.com/ns#>. No such PREFIX must be generated if the SPARQL string already contains a PREFIX statement for the same prefix at the top-level query (ignoring prefixes from nested SELECT queries). The SHACL processor must produce an failure if the shapes graph contains multiple sh:prefix triples with the same object. Since the use of sh:prefix triples may lead to conflicts, it is recommended to only use them in closed and controlled environments or for well-established prefixes. In the rest of this document, the sh:prefix statements may have been omitted for brevity.

The following example illustrates the definition of a SPARQL-based constraint.

ex:ValidCountry a ex:Country ;
	ex:germanLabel "Spanien"@de .
  
ex:InvalidCountry a ex:Country ;
	ex:germanLabel "Spain"@en .

<http://example.com/ns#> sh:prefix "ex" .

ex:LanguageExampleShape
	a sh:Shape ;
	sh:scopeClass ex:Country ;
	sh:sparql [
		a sh:SPARQLConstraint ;
		sh:message "Values must be literals with German language tag." ;
		sh:select """
			SELECT $this ($this AS ?subject) (ex:germanLabel AS ?predicate) (?value AS ?object)
			WHERE {
				$this ex:germanLabel ?value .
				FILTER (!isLiteral(?value) || !langMatches(lang(?value), "de"))
			}
			""" ;
	] .

The scope of the shape above includes all SHACL instances of ex:Country. For those RDF nodes (represented by the variable $this), the SPARQL query walks through the values of ex:germanLabel and verifies that they are literals with a German language code. The validation results for the aforementioned data graph is shown below:

[
	a sh:ValidationResult ;
	sh:severity sh:Violation ;
	sh:focusNode ex:InvalidCountry ;
	sh:subject ex:InvalidCountry ;
	sh:predicate ex:germanLabel ;
	sh:object "Spain"@en ;
	sh:sourceShape ex:LanguageExampleShape ;
	...
]

The SPARQL query returns result set rows for all bindings of ?value that violate the constraint. A validation result is produced for each row in that result set, following the mapping rules explained later: Each validation result will have $this as the sh:focusNode and sh:subject, ex:germanLabel as sh:predicate and the violating value as sh:object.

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

The following table enumerates variables that have special meaning in SPARQL constraints. When SPARQL constraints are executed, the validation engine should pre-bind values for these variables.

5.3 Mapping of Result Variables to Validation Results

If one of the rows of the result set produced by a SELECT query contains the binding true for the variable ?failure, then the validation engine must signal an error.

Otherwise, each row of the result set produced by a SELECT query must be converted into one validation result resource. The properties of those resources are derived by the following rules, through a combination of result variables and the properties linked to the constraint itself. The production rules are meant to be executed from top to bottom, so that the first bound value will be used.

5.4 Injecting Annotation Properties into Validation Results

It is possible to inject additional annotation properties into the validation result resources created for each row of the SELECT result sets. Any such property needs to be declared via a value of sh:resultAnnotation at the subject holding the sh:select or sh:ask triple. The values of sh:resultAnnotation must be IRIs or blank nodes with the following properties:

For each row of a SELECT result set, a SHACL processor must walk through the declared result annotations. The mapping from result annotations to SPARQL variables uses the following rules:

1. If a sh:resultAnnotation defines a sh:annotationVarName then the validation engine must look for the variable named after the sh:annotationVarName
2. Otherwise, the validation engine must derive a variable name from the value of sh:annotationProperty using the same local name mechanism as described earlier

If a variable name could be determined, then the validation engine must copy the bindings for the given variable into the constructed validation results for the current row. If the variable has no binding in the result set row, then the value of sh:annotationValue must be used, if present.

The values of sh:annotationProperty must not be from the SHACL namespace, to avoid clashes with variables that are already produced by other means.

Here is a slightly complex example, illustrating the use of result annotations.

ex:ShapeWithPathViolationExample
	a sh:Shape ;
	sh:scopeNode ex:ExampleRootResource ;
	sh:sparql [
		sh:resultAnnotation [
			sh:annotationProperty ex:time ;
			sh:annotationVarName "time"
		] ;
		sh:select """
			SELECT $this ?subject (ex:property2 AS ?predicate) (?first AS ?object) ?message ?time
			WHERE {
				$this ex:property1 ?first .
				?subject ex:property2 ?first .
				FILTER isBlank(?value) .
				BIND (CONCAT("The ", "message.") AS ?message) .
				BIND (NOW() AS ?time) .
			}
			""" ;
	] .

ex:ExampleRootResource
	ex:property1 ex:ExampleIntermediateResource .

ex:ExampleValueResource
	ex:property2 ex:ExampleIntermediateResource .

Which produces the following validation result resource:

[
	a sh:ValidationResult ;
	sh:severity sh:Violation ;
	sh:focusNode ex:ExampleRootResource ;
	sh:subject ex:ExampleValueResource ;
	sh:predicate ex:property2 ;
	sh:object ex:ExampleIntermediateResource ;
	sh:message "The message." ;
	sh:sourceConstraint [ the blank node of the sh:constraint above ] ;
	sh:sourceShape ex:ShapeWithPathViolationExample ;
	ex:time "2015-03-27T10:58:00"^^xsd:dateTime ;  # Example
] .

6.2 Parameters Declaration (sh:parameter)

The parameters of a constraint component are declared via the property sh:parameter. Each parameter must be a SHACL instance of sh:Parameter, but the rdf:type triples can be omitted.

Each sh:Parameter must have exactly one value p for the property sh:predicate and the value must be an IRI. The local name of an IRI is defined as the longest NCNAME at the end of the IRI, not immediately preceded by the first colon in the IRI. The local names of the values of sh:predicate must fulfill the following conditions (to ensure that a correct mapping from parameters into SPARQL variables is possible):

• The local name must be a valid SPARQL VARNAME
• There must not be any other declared parameter for the same constraint component that has a sh:predicate with the same local name
• The local name must not be this, shapesGraph or currentShape.
• The local name must not be subject, predicate or object.

An sh:Parameter may have its property sh:optional set to true to indicate that the parameter is not mandatory. Every sh:ConstraintComponent must have at least one non-optional parameter.

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

6.3 Label Templates (sh:labelTemplate)

The property sh:labelTemplate can be used at any constraint component to suggest how they could be rendered to humans. The values of sh:labelTemplate must be strings (possibly with language tag) that can reference the values of the declared parameters using the syntax {?varName} or {$varName}, where varName is the name of the SPARQL variable that corresponds to the parameter. At display time, these {...} blocks SHOULD be substituted with the actual parameter values. There may be multiple label templates for the same subject, assuming they do not have the same language tags.

6.4 Constraint Component Context (sh:context)

Each sh:ConstraintComponent can define one or more contexts with the sh:context predicate. The values of sh:Context are restricted to:

• sh:PropertyConstraint, to allow the constraint component parameters in sh:property definitions.
• sh:InversePropertyConstraint, to allow the constraint component parameters in sh:inverseProperty definitions.
• sh:NodeConstraint, to allow the constraint component parameters in sh:constraint definitions.

6.5 Validators

For every provided context in the constraint component, a suitable validator must be declared. Each context defines a dedicated property that links to a validator according to the following table.

SHACL includes two types of validators, based on SPARQL SELECT or SPARQL ASK queries. For each provided context, one validator must be defined in the shapes graph.

ex:LanguageConstraintComponentUsingSELECT
	a sh:ConstraintComponent ;
	rdfs:label "Language constraint component" ;
	sh:context sh:PropertyConstraint ;
	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 $this ($this AS ?subject) $predicate (?value AS ?object)
			WHERE {
				$this $predicate ?value .
				FILTER (!isLiteral(?value) || !langMatches(lang(?value), $lang))
			}
			"""
	] .

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

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

	SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
	WHERE {
		$this $predicate ?value .
		FILTER NOT EXISTS ...
	}

	SELECT $this ($this AS ?object) $predicate (?value AS ?subject)
	WHERE {
		?value $predicate $this .
		FILTER NOT EXISTS ...
	}

ex:LanguageConstraintComponentUsingASK
	a sh:ConstraintComponent ;
	rdfs:label "Language constraint component" ;
	sh:context sh:NodeConstraint, sh:PropertyConstraint ;
	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:nodeValidator ex:hasLang ;
	sh:propertyValidator 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))
		}
		""" .

6.6 Evaluation

7.1 Scopes using sh:SPARQLScope

SPARQL-based scopes must be SHACL instances of sh:SPARQLScope, which is a SHACL subclass of sh:Scope. The SPARQL queries linked to a scope via sh:select must be of the query form SELECT. The SELECT queries must project to the result variable ?this. The resulting scope consists of all distinct bindings for the variable ?this.

The SELECT queries must also be executable when converted to an ASK query and with a pre-bound value for ?this. The set of bindings for ?this that return true for such ASK queries must be identical to the set produced by the SELECT query. This design makes sure that validation engines can validate whether a given shape applies to a given individual focus node.

The following example illustrates a well-formed SPARQL-based scope that produces all persons born in the USA:

ex:USCitizenShape
	a sh:Shape ;
	sh:scope [
		a sh:SPARQLScope ;
		sh:select """
			SELECT ?this
			WHERE {
				?this a ex:Person .
				?this ex:bornIn ex:USA .
			}
			""" ;
	] ;
	sh:constraint ...

7.2 SPARQL-based Scope Types

The class sh:ScopeType can be used to define high-level vocabularies for scopes. Similar to constraint components, such scopes take parameters that are interpreted when the scope is evaluated. The class sh:SPARQLScopeType is a SHACL subclass of sh:ScopeType for scope types that define a SPARQL SELECT query via the property sh:select. Similar to constraint components, the parameter values become pre-bound variables in such SPARQL queries. The parameter values of such scopes must not be blank nodes. All parameters of scope types are expected to have sh:maxCount 1. Similar to constraint components, scope types may also have values for the property sh:labelTemplate.

The following example defines a new SPARQL-based parameterizable scope class that takes one parameter ex:country that gets mapped into the variable $country in the corresponding SPARQL query to determine the resulting focus nodes.

ex:PeopleBornInCountryScope
	a sh:SPARQLScopeType ;
	rdfs:subClassOf sh:Scope ;
	sh:labelTemplate "All persons born in {$country}" ;
	sh:parameter [
		sh:predicate ex:country ;
		sh:name "country" ;
		sh:description "The country that the focus nodes must be born in." ;
		sh:class ex:Country ;
		sh:minCount 1 ;
		sh:maxCount 1 ;
		sh:nodeKind sh:IRI ;
	] ;
	sh:select """
		SELECT ?this
		WHERE {
			?this a ex:Person .
			?this ex:bornIn $country .
		}
		""" .

ex:USCitizenShape
	a sh:Shape ;
	sh:scope [
		a ex:BornInCountryScope ;
		ex:country ex:USA ;
	] ;
	sh:constraint ...

The set of scope nodes produced by such a scope type consists of all bindings of the variable ?this in the result set, when the SPARQL SELECT query has been executed with the pre-bound parameter values.

9.1 Syntax of SPARQL Functions

Functions that encapsulate a SPARQL query must be SHACL instances of sh:SPARQLFunction, which is a SHACL subclass of the more general class sh:Function. Such functions must provide exactly one value for either sh:ask or sh:select, linking to a SPARQL query.

The following example illustrates the definition of a function based on a simple mathematical SPARQL query.

ex:exampleFunction
	a sh:SPARQLFunction ;
	rdfs:comment "Computes the sum of its two parameters ?op1 and ?op2." ;
	sh:parameter [
		sh:predicate ex:op1 ;
		sh:datatype xsd:integer ;
		sh:description "The first operand" ;
	] ;
	sh:parameter [
		sh:predicate ex:op2 ;
		sh:datatype xsd:integer ;
		sh:description "The second operand" ;
	] ;
	sh:returnType xsd:integer ;
	sh:select """
		SELECT ($op1 + $op2 AS ?result)
		WHERE {
		}
		""" .

Using the declaration above, SPARQL engines with full SHACL support can install a new SPARQL function based on the SPARQL 1.1 Extensible Value Testing mechanism. Such engines are then able to handle expressions such as ex:exampleFunction(40, 2), producing 42, as illustrated in the following SPARQL query.

SELECT ?subject
WHERE {
	?subject ex:myProperty ?value .
	FILTER (ex:exampleFunction(?value, 2) = 42) .
}

The following sections introduce the properties that such functions may have.

9.2 Function Parameters

The parameters of a function are linked to its sh:Function via the property sh:parameter. Each parameter must be a SHACL instance of sh:Parameter, but their rdf:type triple can be omitted.

Each sh:Parameter must have exactly one value for the property sh:predicate. The values of sh:predicate must be IRIs, and follow the following restrictions:

• The local name must be a valid SPARQL VARNAME
• There must not be any other declared sh:Parameter for the same function that has a sh:predicate with the same local name

Parameters are ordered, corresponding to the notation of function calls in SPARQL such as ex:exampleFunction(?param1, ?param2). The ordering of function parameters is determined as follows:

1. Parameters are ordered in ascending order by the numeric values of sh:order.
2. Parameters that do not declare an sh:order are placed after those that have.
3. Parameters that do not declare an sh:order are ordered by the local names of their declared sh:predicates.

Each sh:Parameter may have its property sh:optional set to true to indicate that the parameter is not mandatory.

9.3 sh:returnType

A function may declare a single return type via sh:returnType. This information may serve for documentation purposes, only. However, in some execution languages such as JavaScript, the declared sh:returnType may inform a processor how to cast a native value into an RDF term.

9.4 Evaluation of Functions

SHACL instances of sh:SPARQLFunction must have exactly one value for either sh:ask or sh:select. The values of this property must be strings that can be parsed into SPARQL queries of type ASK (for sh:ask) or SELECT (for sh:select). SELECT queries must project exactly one result variable and SHOULD not use the SELECT * syntax. In the SPARQL query, the SPARQL processor needs to pre-bind variables based on the provided parameters of the function call. For ASK queries, the function's return value is the result of the ASK query execution, i.e. true or false. For SELECT queries, the function's return value is the binding of the (single) result variable of the first row in the result set. Since all other bindings will be ignored, such SELECT queries SHOULD only return a single result variable and at most one row. Also note that the result variable may be unbound, making the return value of the function undefined.

Recursive use of functions is undefined: If a SPARQL-based function contains calls to other functions so that the same function with the same combination of parameters would be visited twice then the result of the function call is undefined. An implementation may either return no result (unbound) or terminate the surrounding SPARQL query with an error.

Some processors may ignore the specified SPARQL query and rely on an alternative (possibly native) implementation instead, as long as the functions return the same values as the specified SPARQL query. This can be used to optimize frequently needed functions. Some processors may even use the SPARQL query to rewrite other SPARQL queries via inlining techniques.