This document defines SPARQL-related extensions of the SHACL Shapes Constraint Language. SHACL is a language for validating RDF graphs against a set of conditions. These conditions are provided as shapes and other constructs expressed in the form of an RDF graph. While the Core part of SHACL defines the basic syntax of shapes and the most common constraint components supported by SHACL, the SPARQL-related extensions cover features that extend the expressiveness of Core by means of SPARQL. In particular, this document defines how constraints and constraint components can be defined using SPARQL.
TODO: More will be added on Node Expressions/targets once that part is ready. Other features from SHACL-AF such as user-defined functions may get added.
This document specifies the SPARQL-related features of the SHACL (Shapes Constraint Language).
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 to make 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:
| Prefix | Namespace |
|---|---|
rdf: |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: |
http://www.w3.org/2000/01/rdf-schema# |
sh: |
http://www.w3.org/ns/shacl# |
xsd: |
http://www.w3.org/2001/XMLSchema# |
ex: |
http://example.com/ns# |
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.
SHACL Definitions appear in blue boxes:
# This box contains SPARQL or textual definitions.
Grey boxes such as this include syntax rules that apply to the shapes graph.
SPARQL variables using the $ marker represent external bindings that are pre-bound or, in the case of $PATH, substituted in the SPARQL query before execution (as explained in ).
true denotes the RDF term "true"^^xsd:boolean.
false denotes the RDF term "false"^^xsd:boolean.
This document defines the SHACL-SPARQL language that extends SHACL Core. This specification describes conformance criteria for:
This document includes syntactic rules that shapes and other nodes need to fulfill in the shapes graph. These rules are typically of the form A shape must have... or The values of X are literals or All objects of triples with predicate P must be IRIs. The complete list of these rules can be found in the appendix. Nodes that violate any of these rules are called ill-formed. Nodes that violate none of these rules are called well-formed. A shapes graph is ill-formed if it contains at least one ill-formed node.
SHACL-SPARQL supports a constraint component that can be used to express restrictions based on a SPARQL SELECT query.
Constraint Component IRI: sh:SPARQLConstraintComponent
| Property | Summary |
|---|---|
sh:sparql |
A SPARQL-based constraint declaring the SPARQL query to evaluate. |
The syntax rules and validation process for SPARQL-based constraints are defined in the rest of this section.
The following example illustrates the syntax of a SPARQL-based constraint.
The SPARQL query returns result set solutions for all bindings of the variable value that violate the constraint.
There is a validation result for each solution in that result set, applying the mapping rules explained later.
In this example, each validation result will have the binding for the variable this as the sh:focusNode,
ex:germanLabel as sh:resultPath and the violating value as sh:value.
The following example illustrates a similar scenario as above, but with a property shape.
Shapes may have values for the property sh:sparql, and these values are either IRIs or blank nodes.
These values are called SPARQL-based constraints.
SPARQL-based constraints have exactly one value for the property sh:select.
The value of sh:select is a literal of datatype xsd:string.
The class sh:SPARQLConstraint is defined in the SHACL vocabulary and may be used as the type of these constraints (although no type is required).
Using the prefix handling rules, the value of sh:select is a valid SPARQL 1.2 SELECT query.
The SPARQL query derived from the value of sh:select projects the variable this in the SELECT clause.
The following two properties are similar to their use in shapes:
SPARQL-based constraints may have values for the property sh:message and these are either xsd:string literals or literals with a language tag.
SPARQL-based constraints may have at most one value for the property sh:deactivated
and this value is either true or false.
SELECT queries used in the context of property shapes use a special variable named PATH as a placeholder for the path used by the shape.
The only legal use of the variable PATH in the SPARQL queries of SPARQL-based constraints
and SELECT-based validators is in the
predicate position of a triple pattern.
A query that uses the variable PATH in any other position is ill-formed.
A shapes graph may include declarations of namespace prefixes so that these prefixes can be used to abbreviate the SPARQL queries derived from the same shapes graph. The syntax of such prefix declarations is illustrated by the following example.
The values of the property sh:declare are IRIs or blank nodes,
and these values are called prefix declarations.
The SHACL vocabulary includes the class sh:PrefixDeclaration as type for such prefix declarations
although no rdf:type triple is required for them.
Prefix declarations have exactly one value for the property sh:prefix.
The values of sh:prefix are literals of datatype xsd:string.
Prefix declarations have exactly one value for the property sh:namespace.
The values of sh:namespace are literals of datatype xsd:anyURI.
Such a pair of values specifies a single mapping of a prefix to a namespace.
The recommended subject for values of sh:declare is the IRI of the named graph containing the shapes that use the prefixes.
These IRIs are often declared as an instance of owl:Ontology, but this is not required.
Prefix declarations can be used by SPARQL-based constraints,
the validators of SPARQL-based constraint components,
and by similar features defined by SHACL extensions.
These nodes can use the property sh:prefixes to specify a set of prefix mappings.
An example use of the sh:prefixes property can be found in the
example above.
The values of sh:prefixes are either IRIs or blank nodes.
A SHACL processor collects a set of prefix mappings as the union of all
individual prefix mappings that are values of the SPARQL property path sh:prefixes/owl:imports*/sh:declare
of the SPARQL-based constraint or validator.
If such a collection of prefix declarations contains multiple different namespaces for the same value of sh:prefix,
then the shapes graph is ill-formed.
(Note that SHACL processors MAY ignore prefix declarations that are never reached).
A SHACL processor transforms the values of sh:select (and similar properties such as sh:ask)
into SPARQL by prepending PREFIX declarations
for all prefix mappings.
Each value of sh:prefix is turned into the PNAME_NS, while each value of sh:namespace is turned
into the IRIREF in the PREFIX declaration.
For the example shapes graph above, a SHACL-SPARQL processor would produce lines such as PREFIX ex: <http://example.com/ns#>.
The SHACL-SPARQL processor MUST produce a failure if the resulting query string cannot be parsed into a valid SPARQL 1.2 query.
In the rest of this document, the sh:prefixes statements may have been omitted for brevity.
This section explains the validator of sh:SPARQLConstraintComponent.
Note that this validator only explains one possible implementation strategy, and
SHACL processors may choose alternative approaches as long as the outcome is equivalent.
true
as a value for the property sh:deactivated.
Otherwise, execute the SPARQL query specified by the SPARQL-based constraint $sparql
pre-binding the variables this and, if supported,
shapesGraph and currentShape as described in .
If the shape is a property shape, then prior to execution
substitute the variable PATH where it appears in the predicate
position of a triple pattern
with a valid SPARQL surface syntax string of the SHACL property path
specified via sh:path at the property shape.
There is one validation result for each solution that does not have true as the binding for the variable failure.
These validation results MUST have the property values explained in .
A failure MUST be produced if and only if one of the solutions has true as the binding for failure.
When the SPARQL queries of SPARQL-based constraints and the validators of SPARQL-based constraint components are processed, the SHACL-SPARQL processor pre-binds values for the variables in the following table.
| Variable | Interpretation |
|---|---|
this |
The focus node. |
shapesGraph (Optional) |
Can be used to query the shapes graph as in GRAPH $shapesGraph { ... }.
If the shapes graph is a named graph in the same dataset as the data graph then it is the IRI of the shapes graph in the dataset.
Not all SHACL-SPARQL processors need to support this variable.
Processors that do not support the variable shapesGraph MUST report a failure if they encounter a query that references this variable.
Use of GRAPH $shapesGraph { ... } should be handled with extreme caution.
It may result in constraints that are not interoperable across different SHACL-SPARQL processors and that may not run on remote RDF datasets.
|
currentShape (Optional) |
The current shape. Typically used in conjunction with the variable shapesGraph.
The same support policies as for shapesGraph apply for this variable.
|
The property values of the validation result nodes are derived by the following rules, through a combination of result solutions and the values of the constraint itself. The rules are meant to be executed from top to bottom, so that the first bound value will be used.
| Property | Production Rules |
|---|---|
sh:focusNode |
|
sh:resultPath |
|
sh:value |
|
sh:resultMessage |
These message literals may include the names of any SELECT result variables via
{?varName} or {$varName}.
If the constraint is based on a SPARQL-based constraint component, then the component's parameter names can also be used.
These {?varName} and {$varName} blocks SHOULD be replaced with suitable string representations of the values of said variables.
|
sh:sourceConstraint |
|
SPARQL-based constraints provide a lot of flexibility but may be hard to understand for some people or lead to repetition. This section introduces SPARQL-based constraint components as a way to abstract the complexity of SPARQL and to declare high-level reusable components similar to the Core constraint components. Such constraint components can be declared using the SHACL RDF vocabulary and thus shared and reused.
The following example demonstrates how SPARQL can be used to specify new constraint components using the SHACL-SPARQL language.
The example implements sh:pattern and sh:flags using a
SPARQL ASK query to validate that each value 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 validate constraints within a shape.
In general, if a shape S has a value for a property p, and there is a constraint component
C that specifies p as a parameter, and S has values for all mandatory parameters of C,
then the set of these parameter values (including the optional parameters) declare a constraint and the validation engine uses a suitable validator from C
to perform the validation of this constraint.
In the example above, sh:PatternConstraintComponent declares the mandatory parameter sh:pattern,
the optional parameter sh:flags,
and a validator that can be used to perform validation against either node shapes or property shapes.
A SPARQL-based constraint component is an IRI that has SHACL type
sh:ConstraintComponent in the shapes graph.
The mechanism to declare new constraint 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.
The parameters of a constraint component are declared via the property sh:parameter.
The values of sh:parameter are called parameter declarations.
The class sh:Parameter may be used as type of parameter declarations but no such triple is required.
Each parameter declaration has exactly one value for the property sh:path.
At parameter declarations, the value of sh:path is an IRI.
The local name of an IRI is defined as the longest NCNAME
at the end of the IRI, not immediately preceded by the first colon in the IRI.
The parameter name of a parameter declaration is defined as the local name of the value of sh:path.
To ensure that a correct mapping from parameters into SPARQL variables is possible, the following syntax rules apply:
Every parameter name is a valid SPARQL VARNAME.
Parameter names must not be one of the following: this, shapesGraph, currentShape, path, PATH, value.
A constraint component where two or more parameter declarations use the same parameter names is ill-formed.
The values of sh:optional must be literals with datatype xsd:boolean.
A parameter declaration can have at most one value for the property sh:optional.
If set to true then the parameter declaration declares an optional parameter.
Every constraint component has at least one non-optional parameter.
The class sh:Parameter is defined as a SHACL subclass of sh:PropertyShape,
and all properties that are applicable to property shapes may also be used for parameters.
This includes descriptive properties such as sh:name and sh:description
but also constraint parameters such as sh:class.
Shapes that do not conform with the constraints declared for the parameters are ill-formed.
Some implementations MAY use these constraint parameters to prevent the execution of constraint components with invalid parameter values.
The property sh:labelTemplate can be used at any constraint component to suggest how constraints could be rendered to humans.
The values of sh:labelTemplate are strings (possibly with language tag) and
are called label templates.
The remainder of this section is informative.
Label templates can include the names of the parameters that are declared for the constraint component
using the syntaxes {?varName} or {$varName},
where varName is the name of the parameter name.
At display time, these {?varName} and {$varName} blocks SHOULD be replaced with the actual parameter values.
There may be multiple label templates for the same subject, but they should not have the same language tags.
For every supported shape type (i.e., property shape or node shape) the constraint component declares a suitable validator. For a given constraint, a validator is selected from the constraint component using the following rules, in order:
sh:nodeValidator, if present.sh:propertyValidator, if present.sh:validator.
If no suitable validator can be found, a SHACL-SPARQL processor ignores the constraint.
SHACL-SPARQL includes two types of validators, based on SPARQL SELECT (for sh:nodeValidator and sh:propertyValidator)
or SPARQL ASK queries (for sh:validator).
Validators with SHACL type sh:SPARQLSelectValidator are called SELECT-based validators.
The values of sh:nodeValidator must be SELECT-based validators.
The values of sh:propertyValidator must be SELECT-based validators.
SELECT-based validators have exactly one value for the property sh:select.
The value of sh:select is a valid SPARQL SELECT query using the aforementioned prefix handling rules.
The SPARQL query derived from the value of sh:select projects the variable this in its SELECT clause.
The remainder of this section is informative.
The following example illustrates the declaration of a constraint component based on a SPARQL SELECT query.
It is a generalized variation of the example from .
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.
Once a constraint component has been declared (in a shapes graph), its parameters can be used as illustrated in the following example.
The example shape above specifies the condition that all values of ex:germanLabel carry the language tag de
while all values of ex:englishLabel have en as their language.
These details are specified via two property shapes that have values for the ex:lang parameter required by the constraint component.
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 shapes and node shapes. SHACL-SPARQL provides an alternative, more compact syntax for validators based on ASK queries.
Validators with SHACL type sh:SPARQLAskValidator are called ASK-based validators.
The values of sh:validator must be ASK-based validators.
ASK-based validators have exactly one value for the property sh:ask.
The value of sh:ask must be a literal with datatype xsd:string.
The value of sh:ask must be a valid SPARQL ASK query using the aforementioned prefix handling rules.
The remainder of this section is informative.
The ASK queries return true if and only if a given value node
(represented by the pre-bound variable value) conforms to the constraint.
The following example declares a constraint component using an ASK query.
Note that the validation condition implemented by an ASK query is "in the inverse direction" from its SELECT counterpart:
ASK queries return true for value nodes that conform to the constraint, while SELECT queries return those value nodes that do not conform.
This section defines the validator of SPARQL-based constraint components. Note that this validator only explains one possible implementation strategy, and SHACL processors may choose alternative approaches as long as the outcome is equivalent.
As the first step, a validator MUST be selected based on the rules outlined in . Then the following rules apply, producing a set of solutions of SPARQL queries:
v where the SPARQL ASK query returns false
with v pre-bound to the variable value,
create one solution consisting of the bindings
($this, focus node) and ($value, v).
Let QS be a list of these solutions.
PATH where it appears in the predicate
position of a triple pattern
with a valid SPARQL surface syntax string of the SHACL property path
specified via sh:path at the property shape.
Let QS be the solutions produced by executing the SPARQL query.
The SPARQL query executions above MUST pre-bind the variables
this and, if supported, shapesGraph and currentShape
as described in .
In addition, each value of a parameter of the constraint component in the constraint
MUST be pre-bound as a variable that has the parameter name as its name.
The production rules for the validation results are identical to those for SPARQL-based constraints,
using the solutions QS as produced above.
This section introduces node expression functions based on SPARQL.
A node expression that has a value for sh:select is called a select expression with the function name
sh:SelectExpression.
A node in an RDF graph is a well-formed select expression if it is a blank node
that is the subject of exactly one triple with sh:select as predicate and a literal as object
with datatype xsd:string.
Using the prefix handling rules, the value of sh:select is a valid SPARQL 1.2 SELECT query.
The SPARQL query derived from the value of sh:select projects exactly one variable in the SELECT clause.
The output nodes of a select expression are the list resultNodes consisting of exactly the bindings of the (only)
variable that is projected from the SELECT clause.
If present in the scope, the value of the scope variable focusNode MUST be pre-bound as the value of the SPARQL variable this.
eval(expr, activeGraph, scope) -> resultNodes
The remainder of this section is informative.
Some features of SHACL-SPARQL rely on the concept of pre-binding of variables as defined in this section.
The definition of pre-binding used by SHACL requires the following restrictions on SPARQL queries.
SHACL-SPARQL processors MUST report a failure when it is operating on a shapes graph
that contains SHACL-SPARQL queries (via sh:select and sh:ask) that violate any of these restrictions.
Note that the term potentially pre-bound variables includes the variables this,
shapesGraph, currentShape, value (for ASK queries),
and any variables that represent the parameters of the constraint component that uses the query.
MINUS clauseSERVICE)VALUES clauseAS ?var for any potentially pre-bound variableshapesGraph and currentShape which are optional as already mentioned in
For solution mapping μ, define Table(μ) to be the multiset formed from μ.
Table(μ) = { μ }
Card[μ] = 1
Define the Values Insertion function Replace(X, μ) to
replace each occurence Y of a
Basic Graph Pattern,
Property Path Expression,
Graph(Var, pattern)
in X with join(Y, Table(μ)).
The evaluation of the SPARQL Query
Q = (E, DS, QF) with pre-bound variables μ
is defined as the evaluation of SPARQL query Q' = (Replace(E, μ), DS, QF).
This section enumerates all normative syntax rules of SHACL. This section is automatically generated from other parts of this spec and hyperlinks are provided back into the prose if the context of the rule in unclear. Nodes that violate these rules in a shapes graph are ill-formed.
| Syntax Rule Id | Syntax Rule Text |
|---|---|
| sparql-nodeKind | Shapes may have values for the property sh:sparql, and these values are either IRIs or blank nodes. |
| SPARQLConstraint-select-count | SPARQL-based constraints have exactly one value for the property sh:select |
| SPARQLConstraint-select-datatype | The value of sh:select is a literal of datatype xsd:string. |
| select-query-valid | Using the prefix handling rules, the value of sh:select is a valid SPARQL 1.2 SELECT query. |
| select-query-this | The SPARQL query derived from the value of sh:select projects the variable this in the SELECT clause. |
| SPARQLConstraint-message-datatype | SPARQL-based constraints may have values for the property sh:message and these are either xsd:string literals or literals with a language tag. |
| SPARQLConstraint-deactivated-maxCount | SPARQL-based constraints may have at most one value for the property sh:deactivated |
| PATH-position | The only legal use of the variable PATH in the SPARQL queries of SPARQL-based constraints
and SELECT-based validators is in the
predicate position of a triple pattern. |
| declare-nodeKind | The values of the property sh:declare are IRIs or blank nodes |
| prefix-count | Prefix declarations have exactly one value for the property sh:prefix |
| prefix-datatype | The values of sh:prefix are literals of datatype xsd:string. |
| namespace-count | Prefix declarations have exactly one value for the property sh:namespace. |
| namespace-datatype | The values of sh:namespace are literals of datatype xsd:anyURI. |
| prefixes-nodeKind | The values of sh:prefixes are either IRIs or blank nodes. |
| prefixes-duplicates | A SHACL processor collects a set of prefix mappings as the union of all
individual prefix mappings that are values of the SPARQL property path sh:prefixes/owl:imports*/sh:declare
of the SPARQL-based constraint or validator.
If such a collection of prefix declarations contains multiple different namespaces for the same value of sh:prefix,
then the shapes graph is ill-formed. |
| ConstraintComponent | A SPARQL-based constraint component is an IRI that has SHACL type
sh:ConstraintComponent in the shapes graph. |
| Parameter-predicate-count | Each parameter declaration has exactly one value for the property sh:path |
| Parameter | At parameter declarations, the value of sh:path is an IRI. |
| parameter-name-VARNAME | Every parameter name is a valid SPARQL VARNAME. |
| parameter-name-not-in | Parameter names must not be one of the following: this, shapesGraph, currentShape, path, PATH, value. |
| parameter-name-unique | A constraint component where two or more parameter declarations use the same parameter names is ill-formed. |
| optional-datatype | The values of sh:optional must be literals with datatype xsd:boolean. |
| optional-maxCount | A parameter declaration can have at most one value for the property sh:optional. |
| ConstraintComponent-parameter | Every constraint component has at least one non-optional parameter. |
| Parameter-conformance | Shapes that do not conform with the constraints declared for the parameters are ill-formed. |
| labelTemplate-datatype | The values of sh:labelTemplate are strings (possibly with language tag) |
| nodeValidator-class | The values of sh:nodeValidator must be SELECT-based validators. |
| propertyValidator-class | The values of sh:propertyValidator must be SELECT-based validators. |
| SPARQLSelectValidator-select-count | SELECT-based validators have exactly one value for the property sh:select. |
| validator-class | The values of sh:validator must be ASK-based validators. |
| ask-count | ASK-based validators have exactly one value for the property sh:ask |
| ask-datatype | The value of sh:ask must be a literal with datatype xsd:string. |
| ask-sparql | The value of sh:ask must be a valid SPARQL ASK query using the aforementioned prefix handling rules. |
| SelectExpression-syntax | A node in an RDF graph is a well-formed select expression if it is a blank node
that is the subject of exactly one triple with sh:select as predicate and a literal as object
with datatype xsd:string. |
| SelectExpression-query-valid | Using the prefix handling rules, the value of sh:select is a valid SPARQL 1.2 SELECT query. |
| SelectExpression-query-output-nodes | The SPARQL query derived from the value of sh:select projects exactly one variable in the SELECT clause. |
| pre-binding-limitations |
The definition of pre-binding used by SHACL requires the following restrictions on SPARQL queries.
SHACL-SPARQL processors MUST report a failure when it is operating on a shapes graph
that contains SHACL-SPARQL queries (via
|
This appendix uses parts of SPARQL 1.2 in non-normative alternative definitions of the semantics of constraint components and targets from [[shacl12-core]]. While these may help some implementers, SPARQL is not required for the implementation of the SHACL Core language.
SPARQL variables using the $ marker represent external bindings that are pre-bound or, in the case of $PATH, substituted in the SPARQL query before execution (as explained in ).
TODO: Assuming SHACL Core 1.2 allows node expressions as constraint parameters, explain that they are evaluated prior to substitution.
The following query expresses a potential definition of class targets in SPARQL.
The variable targetClass will be pre-bound to the given value of sh:targetClass.
All bindings of the variable this from the solutions become focus nodes.
SELECT DISTINCT ?this # ?this is the focus node
WHERE {
?this rdf:type/rdfs:subClassOf* $targetClass .
}
The following query expresses a potential definition of subjects-of targets in SPARQL.
The variable targetSubjectsOf will be pre-bound to the given value of sh:targetSubjectsOf.
All bindings of the variable this from the solutions become focus nodes.
SELECT DISTINCT ?this # ?this is the focus node
WHERE {
?this $targetSubjectsOf ?any .
}
The following query expresses a potential definition of objects-of targets in SPARQL.
The variable targetObjectsOf will be pre-bound to the given value of sh:targetObjectsOf.
All bindings of the variable this from the solutions become focus nodes.
SELECT DISTINCT ?this # ?this is the focus node
WHERE {
?any $targetObjectsOf ?this .
}
The following query expresses a potential SPARQL-based validator for sh:class.
ASK {
$value rdf:type/rdfs:subClassOf* $class .
}
The following query expresses a potential SPARQL-based validator for sh: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 for sh: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:
The following query expresses a potential SPARQL-based validator for sh:minLength.
ASK {
FILTER (STRLEN(str($value)) >= $minLength) .
}
The following query expresses a potential SPARQL-based validator for sh:maxLength.
ASK {
FILTER (STRLEN(str($value)) <= $maxLength) .
}
The following query expresses a potential SPARQL-based validator for sh: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 for sh:disjoint.
SELECT DISTINCT $this ?value
WHERE {
$this $PATH ?value .
$this $disjoint ?value .
}
The following query expresses a potential SPARQL-based validator for sh:lessThan.
SELECT $this ?value
WHERE {
$this $PATH ?value .
$this $lessThan ?otherValue .
BIND (?value < ?otherValue AS ?result) .
FILTER (!bound(?result) || !(?result)) .
}
The following query expresses a potential SPARQL-based validator for sh:lessThanOrEquals.
SELECT $this ?value
WHERE {
$this $PATH ?value .
$this $lessThanOrEquals ?otherValue .
BIND (?value <= ?otherValue AS ?result) .
FILTER (!bound(?result) || !(?result)) .
}
The following query expresses a potential SPARQL-based validator for sh:in.
ASK {
GRAPH $shapesGraph {
$in (rdf:rest*)/rdf:first $value .
}
}
Like most RDF-based technologies, SHACL processors may operate on graphs that are combined
from various sources. Some applications may have an open "linked data" architecture and dynamically
assemble RDF triples from sources that are outside of an organization's network of trust.
Since RDF allows anyone to add statements about any resource, triples may modify the originally
intended semantics of shape definitions or nodes in a data graph and thus lead to misleading results.
Protection against this (and the following) scenario can be achieved by only using trusted
and verified RDF sources and eliminating the possibility that graphs are dynamically added via
owl:imports and sh:shapesGraph.
SHACL-SPARQL includes all the security issues of SPARQL.
The original 1.0 version of SHACL was produced by the RDF Data Shapes Working Group. See its SHACL 1.0 Acknowledgements section.
The detailed list of changes and their diffs can be found in the Git repository.
sh:SelectExpression, see Issue 288