Throughout this document, the following terminology is used.

The SHACL SPARQL Extensions defined in this document are sometimes called SHACL-SPARQL.

Terminology that is linked to portions of RDF 1.2 Concepts and Abstract Syntax is used in SHACL-SPARQL as defined there.Terminology that is linked to portions of SPARQL 1.2 Query Language is used in SHACL-SPARQL as defined there. Terminology that is linked to portions of SHACL 1.2 Core is used in SHACL-SPARQL as defined there. A single linkage is sufficient to provide a definition for all occurences of a particular term in this document.

Definitions are complete within this document, i.e., if there is no rule tomake some situation true in this document then the situation is false.

The syntax of SHACL is RDF.The examples in this document use Turtle [rdf12-turtle].Other RDF serializations such as RDF/XML may be used in practice.The reader should be familiar with basic RDF concepts [rdf12-concepts] such as triples and with SPARQL [sparql12-query].

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

Note that the URI of the graph defining the SHACL vocabulary itself is equivalent tothe namespace above, i.e. it includes the#.References to the SHACL vocabulary, e.g. viaowl: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.

SHACL Definitions appear in blue boxes:

# This box contains SPARQL or textual definitions.

Grey boxes such as this include syntax rules that apply to theshapes graph.

SPARQL variables using the$ marker represent externalbindings that arepre-bound or, in the case of$PATH,substituted in the SPARQL query before execution (as explained in3.3Validation with SPARQL-based Constraint Components).

true denotes the RDF term"true"^^xsd:boolean.false denotes the RDF term"false"^^xsd:boolean.

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 wordsMAY,MUST, andSHOULD in this document are to be interpreted as described inBCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document defines theSHACL-SPARQL language that extends SHACL Core.This specification describes conformance criteria for:

• SHACL-SPARQL processors as processors that support validation with the SHACL-SPARQL Language

This document includes syntactic rules that shapes and other nodes need to fulfill in theshapes graph.These rules are typically of the formA shape must have... orThe values of X are literals orAll objects of triples with predicate P must be IRIs.The complete list of these rules can be found in theappendix.Nodes that violate any of these rules are calledill-formed.Nodes that violate none of these rules are calledwell-formed.Ashapes graph is ill-formed if it contains at least one ill-formed node.

This section is non-normative.

The following example illustrates the syntax of aSPARQL-based constraint.

The target of the shape above includes allSHACL instances ofex:Country.For those nodes (represented by the variablethis), the SPARQL query walks through the values ofex:germanLabeland verifies that they are literals with a German language code.

The SPARQL query returns result setsolutions for all bindings of the variablevalue that violate the constraint.There is a validation result for eachsolution in that result set, applying themapping rules explained later.In this example, each validation result will have thebinding for the variablethis as thesh:focusNode,ex:germanLabel assh:resultPath and the violating value assh:value.

The following example illustrates a similar scenario as above, but with aproperty shape.

Shapes may have values for the propertysh:sparql, and these values are eitherIRIs orblank nodes.These values are calledSPARQL-based constraints.

SPARQL-based constraints have exactly onevalue for the propertysh:select.The value ofsh:select is aliteral of datatypexsd:string.The classsh:SPARQLConstraint is defined in the SHACL vocabulary and may be used as thetype of these constraints (although no type is required).Using theprefix handling rules, the value ofsh:select is a valid SPARQL 1.2 SELECT query.The SPARQL query derived from the value ofsh:selectprojects the variablethis in the SELECT clause.

The following two properties are similar to their use inshapes:

SPARQL-based constraints may have values for the propertysh:message and these are eitherxsd:string literals or literals with a language tag.SPARQL-based constraints may have at most one value for the propertysh:deactivatedand this value is eithertrue orfalse.

SELECT queries used in the context ofproperty shapes use a special variable namedPATH as a placeholder for the path used by the shape.

The only legal use of the variablePATH in the SPARQL queries ofSPARQL-based constraintsandSELECT-based validators is in thepredicate position of atriple pattern.A query that uses the variablePATH in any other position isill-formed.

This section explains thevalidator ofsh:SPARQLConstraintComponent.Note that this validator only explains one possible implementation strategy, andSHACL processors may choose alternative approaches as long as the outcome is equivalent.

This section is non-normative.

The following example demonstrates how SPARQL can be used to specify new constraint components using the SHACL-SPARQL language.The example implementssh:pattern andsh:flags using aSPARQL ASK query to validate that eachvalue node matches a given regular expression.Note that this is only an example implementation and should not be considered normative.

Constraint components provide instructions to validation engines on how to identify and validateconstraints within ashape.In general, if ashapeS has avalue for a propertyp, and there is aconstraint componentC that specifiesp as a parameter, andS has values for allmandatory parameters ofC,then the set of these parameter values (including theoptional parameters) declare aconstraint and the validation engine uses a suitablevalidator fromCto perform the validation of this constraint.In the example above,sh:PatternConstraintComponent declares the mandatory parametersh:pattern,the optional parametersh:flags,and avalidator that can be used to perform validation against eithernode shapes orproperty shapes.

ASPARQL-based constraint component is anIRI that hasSHACL typesh:ConstraintComponent in theshapes graph.

The mechanism to declare newconstraint components in this document is limited to those based on SPARQL.However, then general syntax of declaring parameters and validators has been designed to also work for other extension languages such as JavaScript.

This section defines thevalidator ofSPARQL-based constraint components.Note that this validator only explains one possible implementation strategy, andSHACL processors may choose alternative approaches as long as the outcome is equivalent.

As the first step, avalidatorMUST be selected based on the rules outlinedin3.2.3Validators.Then the following rules apply, producing a set ofsolutions of SPARQL queries:

• ForASK-based validators: For eachvalue nodev where the SPARQL ASK query returnsfalsewithvpre-bound to the variablevalue,create onesolution consisting of the bindings($this,focus node) and ($value,v).LetQS be a list of thesesolutions.
• ForSELECT-based validators:If theshape is aproperty shape, then prior to executionsubstitute the variablePATH where it appears in thepredicateposition of atriple patternwith a valid SPARQL surface syntax string of theSHACL property pathspecified viash:path at theproperty shape.LetQS be thesolutions produced by executing the SPARQL query.

The SPARQL query executions aboveMUSTpre-bind the variablesthis and, if supported,shapesGraph andcurrentShapeas described in2.3.1Pre-bound Variables in SPARQL Constraints ($this, $shapesGraph, $currentShape).In addition, eachvalue of aparameter of theconstraint component in theconstraintMUST bepre-bound as a variable that has theparameter name as its name.

The production rules for the validation results are identical to those forSPARQL-based constraints,using thesolutionsQS as produced above.

Anode expression that has avalue forsh:select is called aselect expression with thefunction namesh:SelectExpression.

A node in an RDF graph is awell-formedselect expression if it is ablank nodethat is thesubject of exactly onetriple withsh:select aspredicate and aliteral asobjectwithdatatypexsd:string.Using theprefix handling rules, the value ofsh:select is a valid SPARQL 1.2 SELECT query.The SPARQL query derived from the value ofsh:selectprojects exactly one variable in the SELECT clause.

The remainder of this section is informative.

Here is an example use of aselect expression, computing the values of a property shape for the property "full name" as the concatenation of theex:firstName, a space, and theex:lastName.

This example also illustrates the use ofsh:prefixes to insert PREFIX declarations into the beginning of the query before parsing.Note that the query is executed with the currentfocus nodepre-bound to the variablethis.

Here is an example use of aselect expression, computing the target nodes of a shape to consist of all instances ofex:Person where theex:age is less than18.

From the following data graph, onlyex:Benjamin is a target node.

The following query expresses a potential definition ofclass targets in SPARQL.The variabletargetClass will bepre-bound to the given value ofsh:targetClass.Allbindings of the variablethis from thesolutions become focus nodes.

SELECT DISTINCT ?this    # ?this is the focus nodeWHERE {?this rdf:type/rdfs:subClassOf* $targetClass .}

The following query expresses a potential definition ofsubjects-of targets in SPARQL.The variabletargetSubjectsOf will bepre-bound to the given value ofsh:targetSubjectsOf.Allbindings of the variablethis from thesolutions become focus nodes.

SELECT DISTINCT ?this    # ?this is the focus nodeWHERE {?this $targetSubjectsOf ?any .}

The following query expresses a potential definition ofobjects-of targets in SPARQL.The variabletargetObjectsOf will bepre-bound to the given value ofsh:targetObjectsOf.Allbindings of the variablethis from thesolutions become focus nodes.

SELECT DISTINCT ?this    # ?this is the focus nodeWHERE {?any $targetObjectsOf ?this .}

The following query expresses a potential SPARQL-based validator forsh:class.

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

The following query expresses a potential SPARQL-based validator forsh:nodeKind.

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

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

ASK {FILTER ($minExclusive < $value)}

Similar definitions are possible for:

• sh:minInclusive: <=
• sh:maxExclusive: >
• sh:maxInclusive: >=

The following query expresses a potential SPARQL-based validator forsh:minLength.

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

The following query expresses a potential SPARQL-based validator forsh:maxLength.

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

The following query expresses a potential SPARQL-based validator forsh:pattern.

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

The following query expresses a potential SPARQL-based validator forsh:disjoint.

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

The following query expresses a potential SPARQL-based validator forsh:lessThan.

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

The following query expresses a potential SPARQL-based validator forsh:lessThanOrEquals.

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

The following query expresses a potential SPARQL-based validator forsh:in.

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

[css]

CSS Snapshot 2023. Chris Lilley; Elika Etemad; Tab Atkins Jr.; Florian Rivoal. W3C. 7 December 2023. W3C Working Group Note. URL:https://www.w3.org/TR/css-2023/

[rdf12-concepts]

RDF 1.2 Concepts and Abstract Syntax. Olaf Hartig; Pierre-Antoine Champin; Gregg Kellogg; Andy Seaborne. W3C. 25 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-concepts/

[rdf12-turtle]

RDF 1.2 Turtle. Gregg Kellogg; Dominik Tomaszuk. W3C. 20 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-turtle/

[REC-xml-names]

Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL:https://www.w3.org/TR/xml-names/

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL:https://www.rfc-editor.org/rfc/rfc2119

[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL:https://www.rfc-editor.org/rfc/rfc8174

[shacl12-core]

SHACL 1.2 Core. W3C. W3C Editor's Draft. URL:https://w3c.github.io/data-shapes/shacl12-core/

[sparql12-query]

SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 28 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-query/

[vc-data-model]

Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL:https://www.w3.org/TR/vc-data-model/