This document defines the Inference Rules support of the SHACL Shapes Constraint Language (SHACL).
While the Core part of SHACL focuses on the basic syntax of shapes and constraint validation of data graphs,
the SHACL Inference Rules cover features that can be used to infer new triples from existing triples in the data graph.
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
Publication as
a First Public Working Draft does not imply endorsement
by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than a work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
defines an RDF syntax for expressing SHACL concepts
Note
Implementers can partially check their level of conformance with the above specifications by successfully passing
the test cases of the SHACL 1.2 test suite.
Note, however, that passing all the tests in the test suite does not imply complete conformance to the specifications.
It only implies that the implementation conforms to the aspects tested by the test suite.
1. Introduction
This document specifies the Inference Rules support of the Shapes Constraint Language (SHACL).
1.1 Terminology
Throughout this document, the following terminology is used.
The SHACL inference rules defined in this document are sometimes simply called SHACL rules or even rules.
SHACL SPARQL rules are sometimes simply called SPARQL rules.
Note
Inference rules should not be confused with constraints.
Constraints define conditions that a data graph should conform to,
while rules define how additional (implicit) statements can be derived/inferred from the statements
that are explicitly asserted in a data graph.
Terminology that is linked to portions of RDF 1.2 Concepts and Abstract Syntax is used in SHACL Inference Rules as defined there.
Terminology that is linked to portions of other SHACL 1.2 documents is used in SHACL Inference Rules as defined there.
A single linkage is sufficient to provide a definition for all occurrences 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:
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.
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 in the SPARQL query before execution.
true denotes the RDF term "true"^^xsd:boolean.
false denotes the RDF term "false"^^xsd:boolean.
1.3 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 in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all
capitals, as shown here.
This document defines the SHACL Inference Rules framework that extends SHACL Core.
This specification describes conformance criteria for:
SHACL defines an RDF vocabulary to describe shapes - collections of constraints that apply to a set of nodes.
Shapes can be associated with nodes using a flexible target mechanism, e.g. for all instances of a class.
One focus area of SHACL is data validation.
However, the same principles of describing data patterns in shapes can also be exploited for other purposes.
SHACL rules build on SHACL to form a light-weight RDF vocabulary for the exchange of rules that can be used
to derive inferred RDF triples from existing assertedtriples.
The SHACL rules feature defined in this document includes a general framework using the properties
such as sh:rule and sh:condition, plus an extension mechanism for specific rule types.
This document defines two such rule types: SHACL SPARQL rules and triple rules.
2.1 An Example SPARQL Rule
This section is non-normative.
The following example illustrates a simple use case of a SPARQL rule that applies to all instances of
the class ex:Rectangle and computes the values of the ex:area property by multiplying
the rectangle's width and height:
An engine that is capable of executing such rules uses the target statements associated
with the shapes in the shapes graph to determine which rules need to be executed on which target nodes.
For those target nodes that conform to any condition shapes, it executes the provided
CONSTRUCT queries to produce the inferred triples.
During the execution of the query, the variable this has the current focus node as pre-bound variable.
In addition to SPARQL-based inference rules, this document introduces triple rules.
These rules rely on node expressions instead of SPARQL queries to compute the inferred triples.
Here is the same scenario as the previous example, using a triple rule.
3. Syntax of SHACL Rules
The SHACL instances of sh:Rule, including its subclasses sh:SPARQLRule and sh:TripleRule,
are called SHACL rules.
SHACL has a flexible, extensible design in which multiple types of rules can be supported,
but this document only defines two of them: SPARQL rules and triple rules.
Each SHACL rule has at least one rdf:type
which is a IRI.
3.1 Rule Types
A rule type is identified by an IRI.
Each rule type defines execution instructions that can be implemented by rule engines through the function
execute(rule, focusNodes) -> inferredTriples where
rule is the rule to execute, focusNodes is a set of nodes provided by a rule engine,
and inferredTriples is the graph of (output) triples that are not in the base graph.
RuleR has rule typeT if R is a SHACL instance of T.
Rules can have multiple types, e.g., to provide instructions that work either in SPARQL or JavaScript,
depending on the capabilities of the engine.
The creator of rules with multiple types needs to make sure that such rules have consistent semantics.
A shape rule is a rule that is the object of a sh:rule triple.
Shape rules are executed for all target nodes of the shape which is the subject
of the sh:rule triple.
A global rule is a rule that is not linked to a shape by
a sh:rulepredicate.
A shape rule may have values for the property sh:condition to specify shapes
that the target nodes must conform to before they become focus nodes for the rule.
The values of sh:condition at a rule must be well-formed shapes.
Rules may be deactivated by setting sh:deactivated to true.
Deactivated rules are ignored by the rules engine.
Each rule may have at most one value for the
property sh:deactivated.The values of sh:deactivated are either
of the xsd:boolean literals true or false.
3.5 Grouping of Rules into Layers (sh:layer)
Rules may be grouped into layers, identified by a numeric value.
During execution, a SHACL rules engine will iterate over all rules with the same numeric layer value
before moving to the next layer.
Layers with a smaller numeric value will be executed before those with a larger number.
Each rule may have at most one value for the
property sh:layer.The values of sh:layer at rules
are literals with datatype xsd:integer or xsd:decimal.
If unspecified and unless it has been computed by a custom rule processor, the default layer of a rule is 0.
An example of sh:layer to control the execution order of rules is provided in Example 6.
3.6 Ordering of Rules (sh:order)
Rules may specify their relative execution order within the same layer as defined in this section.
Each rule may have at most one value for the
property sh:order.The values of sh:order at rules
are literals with datatype xsd:decimal or xsd:integer.
If unspecified and unless it has been computed by a custom rule processor, the default execution order is 0.
When the rules are executed, within the same layer, rules with larger order values will be executed after those with smaller values.
The inferred triples of one rule (or group of same-order rules) become immediately visible to the subsequent rule (or group of same-order rules) in the order.
Rules with the same order are executed concurrently and must not see each other's inferences before they have all completed.
The sets of triples individually inferred by these rules are merged into the inference graph.
3.7 Run-once Rules (sh:runOnce)
A SHACL rules engine iterates over the rules, allowing the same rule to be
executed multiple times until no further triples are inferred.
However, some rules may produce fresh blank nodes with each execution and therefore cause infinite iterations.
Rules may use the property sh:runOnce to instruct a rules engine that the rule is
only executed once and before the other rules in the same layer.
Each rule may have at most one value for the
property sh:runOnce.The values of sh:runOnce at rules
are literals with datatypexsd:boolean.
A run-once rule is a rule for which at most one iteration is performed (per shape, if it is a shape rule), i.e. it is executed at most once per focus node.
All other rules are called iterating rules.
A rule that has true as its value for sh:runOnce is a run-once rule.
Custom rule processors may compute additional run-once rules when sh:runOnce is absent.
SHACL Core includes the following properties to derive property values that are not necessarily asserted in the data graph:
sh:defaultValue defines what values should be used
when no other values are present for a property.
For example, the default value of ex:childCount could be 0.
sh:values defines general instructions for computing
derived values for a property.
For example, the ex:area of a rectangle may be derived by multiplying its ex:width and ex:height.
Both properties can use node expressions including those defined in SHACL 1.2 Node Expressions.
Both properties can only be used to compute the objects of a given predicate for the
subjects that are targeted by shapes.
This means that sh:defaultValue and sh:values describe implicit triples
that are similar to inferences produced by rules.
When a rule refers to a certain property, it is reasonable for the rule to expect that these
implicit triples are present.
This section explains how rules can make sure that such derived triples are present before the rule executes.
The expected derived triples of a rule are the derived triples for all values
of the property sh:expectedPredicate at the rule.
All this is best explained by an example:
A SHACL rules engine will remove the derived triples from the inferences at the end of
processing each layer, except those triples that have also been inferred by rules.
Some engines may have a setting to keep all derived triples, for example
when data is exported to systems that do not support SHACL.
4. Rule Sets
The input to a SHACL rules engine is a set of rules called a rule set.
A rule set is identified by an IRI.
The property sh:hasRule can be used to declare that a rule set has a given rule as a member.
The default rule set of a graph is the set of all rules in the graph.
Rule sets can use the property sh:includesRuleSet to (transitively) include other rule sets.
The sh:RulesGraph class MAY be used as an rdf:type
of the IRI of a graph that typically acts in the role of a rules graph.
The remainder of this section is non-normative.
The graph type classes (sh:DataGraph, sh:ShapesGraph, sh:RulesGraph)
represent roles that are not mutually exclusive; a single graph MAY be typed with more than one of these classes.
Rules graphs MAY contain sh:rule triples that reference shapes defined in
other graphs, allowing rules to be managed independently of shape and ontology definitions.
6. The sh:RulesEntailment Regime
SHACL defines the property sh:entailment
to link a shapes graph with entailment regimes.
The IRIsh:RulesEntailment represents the SHACL rules entailment regime.
In the following example, the shapes graph indicates to a SHACL validation engine that the SHACL rules
inside of the shapes graph need to be executed prior to starting the validation.
It is sometimes useful for inference rules to produce triples that are only visible during the execution
of other rules but do not end up in the final inferences.
A temporary triple is an inferred triple for which the inference graph contains a
reifier with the valuesh:tempTriple true.
Temporary triples and their reifiers are visible to executing rules.
Rules can produce such triples as illustrated in the following example:
Creating temporary triples can be helpful when a computation is too complex to be carried out by a single rule.
The complex computation can then be decomposed into multiple rules:
some rules infer partial results, from which other rules derive the final results.
The partial results are only functional to the computation of the final results and are no longer needed once the latter have been obtained.
By marking these partial results as temporary triples, they are automatically removed after the final results have been computed.
8. General Execution Instructions for SHACL Rules
A SHACL rules engine is a computer procedure that takes as input
a data graph called the base graph, a shapes graph, and an optional rule set (defaulting to the default rule set of the shapes graph)
and is capable of producing triples that are not in the base graph.
The new triples that are produced by a rules engine are called the inferred triples.
The inference graph consists of these inferred triples.
The evaluation graph is the union of the base graph and the inference graph.
If the rule is a global rule (i.e., not linked to any shape via sh:rule),
then the rule is executed with an empty set of focus nodes: execute(rule, []).
During execution of a rule, the evaluation graph is used as the active query graph.
After execution of a rule, the inferred triples from the execute function are added to the inference graph.
The execution of a rule set is defined as follows:
For all layers in the rule set (in ascending order):
Compute the expected derived triples for all rules in the layer
Execute one iteration over all run-once rules in the layer
do
Execute one iteration over all iterating rules in the layer
while the iteration has produced newly inferred triples
Delete the derived triples (except those that were also inferred by rules)
and their reifiers
Delete the temporary triples and their reifiers
Rule engines MAY also report a failure after a pre-configured maximum iteration count has been exceeded or
a pre-configured maximum number of inferred triples has been produced.
This can help as a guard to avoid out-of-memory problems and infinite loops.
At no time are inferred triples visible to the shapes graph, i.e. it is impossible for rules
to modify the definitions of rules or shapes.
9. Tracking the Rule that has produced a Triple (sh:sourceRule)
Rule engines MAY have an option to generate additional triples that can be used to track
which rules have produced the inferred triples.
The property sh:sourceRule can be used in a reifier of a triple in the inferences graph
to link the triple with the rule.
The values of sh:sourceRuleSHOULD be IRIs.
The following example indicates that the triple ex:Alice ex:friend ex:Bob has been
inferred by the rule ex:SymmetricPropertyRule.
If a rule engine adds these triples, the triples MUST NOT be visible to executing rules.
10. Custom Rule Processors (sh:ruleProcessor)
The general execution algorithm described above assumes that
the author of the rules is responsible for selecting a suitable ordering and layering/grouping
of rules to achieve the desired outcome.
Some SHACL rule implementations MAY implement different algorithms to determine:
This can, for example, be used by engines that support controlled subsets of SHACL rules
for which it is possible to compute rule dependencies automatically.
Another example is a rule engine that automatically prevents infinite loops because rules
generate blank nodes.
Some SHACL rule implementations MAY also report additional failures that are not reported
by the default algorithm.
The property sh:ruleProcessor can be used at rule sets or rules
to instruct a rules engine that non-standard processing is required for the given rules.
The values of sh:ruleProcessor are IRIs,
or literals with datatypexsd:string.
When used in a rule set, the values of sh:ruleProcessor from an included rule set also
apply to the including rule set.
A rules engine that encounters rules or rule sets with a value for sh:ruleProcessor
that they are unable to handle MUST report a failure.
This would be a good place to cross-reference the ongoing SPARQL-RL work, if this integrates naturally with SHACL Inference Rules.
For example we could add an example with sh:ruleProcessor "SRL 1.2".
11. Built-in Rule Types
The SHACL inference rules framework defines a general syntax of rules and their execution algorithm.
This document defines the two rule types from the following two subsections.
This section defines a rule type called SHACL SPARQL rules, often just "SPARQL Rules",
identified by the IRIsh:SPARQLRule.
SPARQL rules have the following properties:
Property
Summary and Syntax Rules
sh:construct
The SPARQL CONSTRUCT query.
SPARQL rules must have exactly one
value for the property sh:construct.The values of sh:construct
are literals with datatype xsd:string.
sh:prefixes
The prefixes to use to turn the sh:construct into a SPARQL query.
SPARQL rules may use the property sh:prefixes to declare a dependency on prefixes based on the
mechanism defined in Prefix Declarations for SPARQL Queries.
This mechanism allows users to abbreviate URIs in the sh:construct strings.
EXECUTION OF SPARQL RULES
Let Q be the SPARQL CONSTRUCT query derived from the values of the properties
sh:construct and sh:prefixes of the SPARQL rule in the shapes graph.
Let S, P and O be the sets of nodes produced by evaluating
the node expressions that are the values of sh:subject, sh:predicate
and sh:object respectively at the triple rule.
Where sh:subject, sh:predicate, or sh:object are absent, use
the list consisting of the current focus node (which is empty for global rules).
For each combination of members s of S, p of P and
o of O, infer a triple with subjects,
predicatep and objecto.
Skip ill-formed triples, for example when a blank node is used as predicate.
Appendix
A. Summary of Syntax Rules
This section enumerates all normative syntax rules of this document.
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.
Applying a SHACL inference rule set to a data graph can result in
significant computation and memory usage, which may be exploited
to cause denial of service.
Applications should take care to limit the amount of computation and
memory usage that can be caused by applying such rule sets.
SHACL inference rules can be used to process and create arbitrary application data;
security considerations will vary by domain of use.
Security/privacy protocols should be imposed which reflect the sensitivity of the information in the outcome of rule set evaluation.
Security considerations of this document include all the security considerations of
SHACL SPARQL,
SHACL Core.