SPARQL-RL generates new RDF data by evaluating a set of declarative - rules against an input RDF graph. Rules are written in a + rules against an input RDF graph. Rules are written in a SPARQL-like text syntax.
@@ -187,15 +184,15 @@
- Implementations of SPARQL-RL provide one or both of operations + Implementations of SPARQL-RL provide one or both of the operations infer and query. The infer operation applies the rules to a given - base graph and produces an inference graph containing the - RDF triples derived by rule execution that do not appear in the base graph. + base graph and produces an inference graph containing the + RDF triples derived by rule evaluation that do not appear in the base graph. Combining the inference graph with the base graph is optional and left to users. The query operation determines whether and how a - given goal pattern can be derived from the base graph + given goal pattern can be derived from the base graph using the rules.
@@ -203,12 +200,11 @@
- SPARQL-RL also supports negation as failure, that could lead to - different inferred graphs depending on the order in which rules are - executed. To avoid this, rules are evaluated using the technique - of stratification, which establishes a single, implicit - ordering among rules, ensuring that the same inference graph is always - produced. + SPARQL-RL also supports negation as failure, which could lead to + different inference graphs depending on the order in which rules are + evaluated. To avoid this, rules are evaluated using the technique + of stratification, which establishes an ordering among rules, + ensuring that the same inference graph is always produced.
SPARQL-RL can be referred to as SRL when the context is clear. @@ -216,8 +212,8 @@
- The following other specifications provide fundamental terminology - that is used in this document: + The following specifications provide fundamental terminology + used in this document:
- Throughout the document, color-coded boxes containing RDF graphs in - Turtle will appear. These fragments of Turtle documents use the prefix - bindings given above. + Throughout the document, color-coded boxes contain rules in SPARQL-RL syntax + or contain RDF graphs in Turtle syntax.
# This box represents rules@@ -292,8 +287,8 @@
A conforming [=SRL document=] is an - RDF string that +
A conforming [=SPARQL-RL document=] is an
+ [=RDF string=] that
conforms to the grammar starting with the
RuleSet
production as defined in
@@ -301,12 +296,13 @@
- This specification does not define how a [=SPARQL-RL processor=] handles non-conforming [=rule sets=]. + This specification does not define how a [=SPARQL-RL processor=] + handles non-conforming [=SPARQL-RL documents=].
SPARQL-RL infers new triples given a [=base graph=] and a [=rule set=]. @@ -330,18 +326,16 @@
SPARQL-RL execution is defined so that the order of rule execution does not lead to different outcomes when creating new RDF terms, - including new blank nodes, nor when testing for the absence of a - pattern. In other words, the same inference graph is produced + including new blank nodes, or when testing for the absence of a + pattern. In other words, the same inference graph is produced regardless of the order of rule execution.
-SPARQL-RL has a human-friendly syntax inspired by [[[SPARQL12-QUERY]]]. Rule set evaluation contains elements similar to SPARQL, with differences in the details to ensure that the same inference graph is produced regardless of the order of rule execution.
-The examples in this section describe software components and their dependencies: a frontend calls an application server, and @@ -355,12 +349,11 @@
A [=triple pattern=] is matched against triple data to give values to variables. The pattern has - three elements, each of which is an RDF term, or a variable, - or it can be a pattern for a - triple term. + three elements, each of which is an RDF term, a variable, + or is a pattern for a [=triple term=] containing variables.
-In this first example, we have the following data graph and rule set:
+In this first example, we have the following data in the base graph and rule set:
- Rules involving [=assignments=] and rules that create blank nodes - from evaluation of the [=rule head=] are [=run-once rules=]. + Rules involving [=assignments=], rules that create blank nodes + from evaluation of the [=rule head=] and rules with a template + that involves a [=triple term=] containing [=variables=] + are [=run-once rules=]. Such rules are run after all the rules that could produce data that they depend on, and before any rules that depend on the data they produce.
This condition ensures that such rules do not loop back to themselves - and cause an unbounded number of RDF terms. + and cause the creation of an unbounded number of RDF terms. +
++ A constant [=RDF term=] in a [=rule head=] does not make a rule a + [=run-once rule=], even when the term does not occur in the + [=base graph=]: the rule contributes the same term each time it is + evaluated, so it can only add a bounded number of terms.
If evaluating the expression in an [=assignment=] causes an error, @@ -591,8 +592,8 @@
@@ -641,14 +642,14 @@
During evaluation, triples inferred based on one rule are available for matching in other rules. Rule set evaluation proceeds until the [=inference graph=] contains all the possible triples from the inputs of - rule set and data graph. + the [=rule set=] and the [=base graph=].
Evaluation starts with steps to @@ -664,15 +665,15 @@
+ A [=triple template=] is a 3-tuple where each element is + a [=variable=], an [=RDF term=], or a template for a + [=triple term=] with [=variables=]. + The second element of the tuple must be an [=IRI=] or a [=variable=]. + [=Triple templates=] appear in the [=head=] of a [=rule=] and + are used to generate [=RDF triples=]. +
++ A pattern or template for a [=triple term=] in which no + [=variable=] occurs is a [=triple term=], and therefore also + an [=RDF term=]. +
.evaldata,
+ to indicate which graph to use for matching
+ the [=negation element body=].
.evaldata
+ to indicate which
+ graph to use for matching [=triple patterns=] in the body.
+ A rule can be given a URI or a blank node to help identify it.
+ A [=run-once rule=] is a rule that is run exactly once at a + particular point in the evaluation of a rule set. + A [=rule=] is a [=run-once rule=] if any of the following hold: +
+ruleset.datarule.basedatarule.evaldatanegation.basedatanegation.evaldata- We define well-formedness for a sequence of [=rule elements=] + Define well-formedness for a sequence of [=rule elements=] given an initial set of variables.
@@ -1103,7 +1124,7 @@
Let varsi be the set of variables defined by - elti where: + elti as follows:
Let Vi - be the union of + be the union of V0 and all varsj, for j from 1 to i.
Let Vall be the value of VN, - where N is the length of the sequence. + where N is the length of the sequence.
A well-formed sequence is a sequence of [=rule elements=], @@ -1158,7 +1179,7 @@
A rule `R1` depends on a rule `R2` if the output of the second rule affects the evaluation of the body of the first rule. That is, the head of `R2` - has a [=triple template=] that might generate a triple that matches + has a [=triple template=] that can generate a triple that matches a [=triple pattern=] in the body of `R1`, either as a [=triple pattern element=] or inside a [=negation element=].
@@ -1223,7 +1244,10 @@+ A rule with flag `.evaldata` set to `false` matches using the + [=base graph=] and the rule has no dependencies. +
In this first example, the first rule has an open dependency on the second rule. @@ -1255,7 +1279,7 @@
A [=triple pattern=] matches a [=triple template=] if @@ -1267,39 +1291,39 @@
A [=triple pattern=] - depends on a [=triple template=] - if the [=triple pattern=] could possibly match the [=triple template=]. + depends on + a [=triple template=] + if the [=triple pattern=] can + match + the [=triple template=].
-- A [=triple pattern=] - depends on a [=rule=] - if the [=triple pattern=] has dependency on any of the [=triple templates=] - in the [=head=] of the rule. -
- Rule `R1` [=depends on=] `R2` if any [=triple pattern=] in the body of `R1`, - whether as a [=triple pattern element=] or inside a [=negation element=], - depends on - a [=triple template=] in the head of `R2`. + Rule `R1` depends on + rule `R2` if + `R1.evaldata` is `true` and any [=triple pattern=] in the body of `R1`, + whether as a [=triple pattern element=] or inside a + [=negation element=] `neg` where `neg.evaldata` is `true`, + depends on a triple template + in the head of `R2`.
A [=rule dependency=] of rule `R1` on rule `R2` is a [=closed dependency=] - if either of the following conditions hold: + if any of the following conditions hold:
A [=triple template=] can generate an - RDF triple `T1` + [=RDF triple=] `T1` if there are values for the variables of the [=triple template=] such that replacing variables by values - in the template, gives a triple `T2` where + in the template gives a triple `T2` where `T2` equals `T1`.
Similarly, a [=triple pattern=] matches a triple `T1` if there are values for the variables of the - [=triple pattern=] such that replacing variables - in the pattern by the values, gives a triple `T2` where + [=triple pattern=] such that replacing variables + in the pattern by the values gives a triple `T2` where `T2` equals `T1`.
@@ -1338,9 +1360,8 @@- Replacing variables by RDF terms in a triple pattern - includes replacing variables inside - triple terms. + Replacing variables by RDF terms in a triple pattern + includes replacing variables inside [=triple terms=].
- The dependency graph is not affected by the data graph. + The dependency graph is not affected by the [=base graph=].
@@ -1400,9 +1421,9 @@[=Stratification=] imposes constraints on dependencies between [=rules=] - to ensure that [=negation elements=], [=assignment elements=], and - blank nodes created in a [=rule head=] depend only on results computed - using earlier (lower) [=strata=] and the [=base graph=]. + to ensure that [=negation elements=] and [=run-once rules=] depend only + on results computed using earlier (lower) [=strata=] and the + [=base graph=]. This guarantees a single, well-defined, and finite outcome from the evaluation of a [=rule set=] over a given [=base graph=].
@@ -1490,7 +1513,7 @@A [=stratification layer=] `SL` is a pair of disjoint sets of rules (`SL.once`, `SL.general`). - `SL.once` contains [=run-once rules=], which are - rules that use [=assignment elements=] or produce - blank nodes in the [=rule head=]; these rules are each evaluated exactly - once at the start of evaluation of the [=stratification layer=]. - `SL.general` contains the remaining rules, which are evaluated - repeatedly until no new triples are inferred. + `SL.once` is exactly the [=run-once rules=] of the layer; + these rules are each evaluated + exactly once at the start of evaluation of the [=stratification layer=]. + `SL.general` is the set of remaining rules of the layer, + which are evaluated repeatedly until no new triples are inferred.
+ A [=stratification=] of a [=rule set=] is a sequence of [=stratification layers=]. + Each rule in a [=rule set=] appears in exactly one of the sets of one of + the [=stratification layers=]. +
++ The [=stratification layers=] of a [=stratification=] are numbered + from zero. The stratum number of a [=rule=] is the number + of the [=stratification layer=] that contains the rule. + A rule with a smaller [=stratum number=] is in a lower stratum; + one with a larger [=stratum number=] is in a higher stratum. +
++ For every edge from rule `R1` to rule `R2` in the + [=dependency graph=] of the [=rule set=]: +
++ A [=rule set=] can have more than one [=stratification=]. + An implementation can use any [=stratification=] of the [=rule set=]. +
- In other words, there is no `NOT` or run-once rule (assignment or rule [=triple template=] - involving a blank node) involved in a transitive dependency cycle of the [=dependency graph=]. +
+ The [=stratification condition=] is exactly the condition for a + [=stratification=] to exist: a [=stratification=] of a [=rule set=] can + be formed if and only if no cyclic path in the [=dependency graph=] of + the rule set contains a [=closed dependency=].
SET(?var := expr) would be the same as
@@ -1715,7 +1766,7 @@ @@ -1724,24 +1775,25 @@
-Inputs: data graph G, called the base graph, and a rule set RS. +Inputs: graph G, called the base graph, and a rule set RS. Output: an RDF graph GI of inferred triples
μ : V → T,
+ μ : V → T,
where V is the set of all variables
and T is the set of all [=RDF terms=].
The domain of μ is denoted
by dom(μ), and it is the subset
- of V for which μ is defined. We use the term
- [=solution=] where it is clear that a [=solution mapping=] is meant.
+ of V for which μ is defined. The term
+ [=solution=] can be used when it is clear that a [=solution mapping=] is meant.
Write μ0 for the solution mapping, such that
dom(μ0) is the empty set.
- The substitution function, or just a substitution,
+ The substitution function, or just a substitution,
is a function
subst(μ, [=triple pattern=])
that returns a [=triple pattern=]
@@ -1814,12 +1866,12 @@
dom(μ)
is replaced by the [=RDF term=] given by the
[=solution mapping=] for var.
- If the triple pattern result has no variables, then it is an
- [=RDF Triple=].
+ If the triple pattern result has no variables, then it is an
+ [=RDF triple=].
The function subst(μ, [=triple template=])
- is similarly defined. Each occurrence of a variable in the
+ is similarly defined. Each occurrence of a variable in the
[=triple template=] is replaced by the [=RDF term=] given by the
[=solution mapping=] for var.
Let G be an [=RDF graph=] and TP be a [=triple pattern=]. The function `graphMatch(G, TP)` returns a set of all possible @@ -1857,7 +1909,7 @@
graphMatch(G, TP) = { μ | dom(μ) = V and subst(μ, TP) is a triple in G }
+ graphMatch(G, TP) = { μ | dom(μ) = V and subst(μ, TP) is a triple in G }
Let S1 and S2 be solutions.
-compatible(μ1, μ2) = true
+ compatible(μ1, μ2) = true
if forall v in dom(μ1) intersection dom(μ2)
μ1(v) = μ2(v)
compatible(μ1, μ2) = false otherwise
@@ -1891,12 +1943,12 @@ Evaluation Definitions
Let μ1, μ2
be solution mappings, and S1 and S2 be solution sequences.
-
+
merge(μ1, μ2) = μ such that
μ(v) = μ1(v) if v in dom(μ1)
μ(v) = μ2(v) otherwise
-
+
merge(S1, S2) = { μ |
μ1 in S1, μ2 in S2
and compatible(μ1, μ2)
@@ -1933,21 +1985,23 @@ Preparation for Evaluation
building a single, combined rule set as described in
.
- Then preparing the combined rule set
+
Next, the combined rule set is prepared
for evaluation with the following steps.
-
- Check each rule is a [=well-formed rule=], as described in
+ Check that each rule is a [=well-formed rule=], as described in
.
- Calculate the [=dependency graph=], as described in
.
-
- Calculate the [=stratification=] for the combined rule set, as described in
- .
+ Calculate a [=stratification=] of the combined rule set, as described in
+ .
+
+ gives one way to calculate a [=stratification=].
@@ -1958,8 +2012,8 @@ Evaluation of an Expression
An expression, whether used in a [=filter element=] or
an [=assignment element=], is evaluated with
- respect to a solution mapping which provides a value which is an RDF term,
- for each variable in the expression.
+ respect to a [=solution mapping=]. The solution mapping provides the
+ RDF term values for each variable in the expression.
The well-formedness requirements of
ensure that all variables in the expression
appear in the solution mapping.
@@ -1974,7 +2028,7 @@
Evaluation of an Expression
if F is an RDF term:
return F
if F is a variable:
- # By well-formedness, F ∈ dom(μ).
+ # By well-formedness, F ∈ dom(μ).
return μ(F)
# F is of the form F = op(expr1, ..., exprN)
if op is a functional form (e.g., IF, logical-or):
@@ -1995,7 +2049,7 @@ Evaluation of a Rule
A [=rule=] is evaluated by calculating a [=solution sequence=] from the [=rule body=]
and then using each [=solution mapping=] of the [=solution sequence=] to
- generate triples using [=rule head=].
+ generate triples using the [=rule head=].
Blank nodes within [=triple patterns=] behave like variables.
@@ -2043,7 +2097,7 @@
Evaluation of a Rule
SEQ1 = {}
foreach solution μ in SEQ:
S = sequence{ μ }
- if ! N.basedata:
+ if N.evaldata:
NEG = evalRuleElements(N.inner, S, G, GD)
else:
NEG = evalRuleElements(N.inner, S, GD, GD)
@@ -2088,7 +2142,7 @@ Evaluation of a Rule
# Solution sequence of one solution that does not map any variables.
let SEQ0: Solution sequence = { μ0 }
- if ! R.basedata:
+ if R.evaldata:
let SEQ = evalRuleElements(B, SEQ0, G, GD)
else:
let SEQ = evalRuleElements(B, SEQ0, GD, GD)
@@ -2110,13 +2164,13 @@ Evaluation of a Rule
enddefine
- `OUT` may contain triples that are also in the data graph.
+ `OUT` may contain triples that are also in the [=base graph=].
- Evaluation of a [=rule set=] is defined as the execution of each [=stratum=] of the + Evaluation of a [=rule set=] is defined as the execution of each [=stratum=] of a [=stratification=] of the rule set, where each stratum is executed completely and in order before moving on to the next [=stratum=]. A [=stratum=] is evaluated by first evaluating @@ -2137,7 +2191,7 @@
- A SPARQL-RL Document
- is an RDF string
- encoded in UTF-8 [[!RFC3629]] and starting with the
+ A SPARQL-RL document
+ is an [=RDF string=] encoded in UTF-8 [[!RFC3629]] and starting with the
RuleSet
production and conforming to the additional constraints defined in
.
@@ -2659,14 +2712,14 @@
Multiple VERSION directives
- may appear in a [=SPARQL-RL Document=].
+ may appear in a [=SPARQL-RL document=].
Each directive applies to the part of the document following the directive,
until another directive is encountered or the end of the document is reached.
[=Version labels=] can also be given by the `version` parameter of the
- Media Type. In the absence of a current
+ Media Type. In the absence of a current
VERSION directive, the
version specified as part of the Media Type is considered.
White space
(production WS) is used
- to separate two terminals which would otherwise be (mis-)recognized as one
+ to separate two terminals that would otherwise be (mis-)recognized as one
terminal. Rule names below in capitals indicate where white space is
significant; these form a possible choice of terminals for constructing a
SPARQL-RL parser.
@@ -2712,17 +2765,16 @@
The BASE
- directive defines the Base IRI used to
- resolve relative IRI
- references per [[RFC3986]]
+ directive defines the Base IRI used to resolve
+ relative IRI references per [[RFC3986]]
section 5.1.1, "Base URI Embedded in Content".
- Section 5.1.2, "Base URI from the Encapsulating Entity"
+ section 5.1.2, "Base URI from the Encapsulating Entity"
defines how the In-Scope Base IRI may come from an encapsulating document,
such as a SOAP envelope with an `xml:base` directive or a MIME multipart document with a
`Content-Location` header.
@@ -2792,8 +2844,8 @@
where hex is a hexadecimal character
HEX ::= [0-9] | [A-F] | [a-f]
where hex is a hexadecimal character
HEX ::= [0-9] | [A-F] | [a-f]
PREFIX,
or BASE declarationsThis document uses some specific terminal literal strings - [[EBNF-NOTATION]]. To clarify the Unicode code points used for these + [[EBNF-NOTATION]]. To clarify the Unicode code points used for these terminal literal strings, the following table describes specific characters used in this section.
@@ -3002,15 +3054,21 @@- The following algorithm shows one way to resolve imports statements by + The following algorithm shows one way to resolve `IMPORTS` statements by visiting all the referenced documents recursively.
The rule set merge of two rule sets, `RS1` and `RS2`, - is a rule set, `MR`, defined as follows: + produces a rule set, `MR`, defined as follows:
+let RS be a rule set
+let V = {}
+if RS has a location:
+ V = { location of RS }
+endif
+
define ruleSetMerge(rule set RS1, rule set RS2):
let MR be a rule set
MR.rules = RS1.rules ∪ RS2.rules
@@ -3019,23 +3077,19 @@ Example Imports Algorithm
the result is MR
enddefine
-define imports(rule set RS, set of URLs V):
- let I = the set of import URLs declared for the rule set RS
+define imports(rule set RS):
let RS2 be a rule set formed from RS.rules and RS.data
- foreach URL x in I:
+ foreach URL x in RS.imports:
if x ∉ V:
V = V ∪ { x }
read rule set RS3 from URL x
- RS2 = ruleSetMerge(RS2, imports(RS3, V))
+ RS2 = ruleSetMerge(RS2, imports(RS3))
endif
endfor
the result is RS2
enddefine
-let RS be a rule set
-let V = {}
-if RS has a location, V = { location of RS }
-result is imports(RS, V)
+result is imports(RS)
@@ -3093,7 +3147,7 @@
- Applying a SPARQL-RL rule set to a data graph can result in + Applying a SPARQL-RL rule set to an RDF 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 @@ -3175,14 +3229,14 @@
SPARQL-RL can be used to process and create arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (for example, PGP encryption, checksum validation, password-protected compression) may also be used on [=SPARQL-RL documents=]. - Security/privacy protocols must be imposed which reflect the sensitivity of the + Security/privacy protocols must be imposed to reflect the sensitivity of the information in the outcome of SPARQL-RL rule set evaluation.
The security considerations of SPARQL-RL include those of @@ -3208,7 +3262,7 @@
The following people contributed to the development of SPARQL-RL in the rules task force of the Data Shapes Working Group: