SHACL Rules draft review (2026-05, -06)

[recalcitrantsupplant]

Starting with a discussion & happy to raise one or more PRs depending on feedback

Structural/flow

1. It would be good to carry one worked example through the document, including working through the stratification step by step. Probably this should be an example involving negation, but with as few triples / rules as possible so it does not bloat the document. This would also help tie Sections 3, 4 and 6 together more concretely.

2. In the section 3 introduction, add an explicit reference to SPARQL, as this will make it a lot easier for users with RDF/SPARQL experience to understand and connect to the head/body concepts. Perhaps this was the intention once S3.8 is complete.

3. Section 3.1 "Basic Usage" sticks out as a general heading where the others are "feature" centric ("Recursion" etc.). Could it be changed to a feature like heading. "Pattern Matching" is the best name I can come up with.

4. Data blocks should be mentioned somewhere in S3. Would seem excessive to have its own section but not sure what else it could go under.

5. In S6, we should add brief introductions to the evaluation subsections before the pseudocode.

Minor points

6. For responsibility for avoiding infinite loops (Section 1 Introduction), I wonder whether the introduction is the right place for this sentence. To what extent do end users, as opposed to implementers, need to be aware of this? End users may instead benefit from implementations that do cycle detection, have iteration limits, etc. Perhaps S3.2 (Recursion) and one of the evaluation sections in S6 are better places.

7. Also in the S1 introduction, the wording around stratification could be read that different outcomes from different ordering are permitted and then corrected for. The stratification should prevent different orderings though, so this could be reworded to frame this as the motivation.

8. Section 3.5 should say explicitly that if a SET expression evaluates with an error, the current solution is dropped and the rule emits nothing for that solution.

9. In S4.3 Rule Dependency, I found the R1/R2 direction unintuitive. My instinct is to read R1 as the earlier or producing rule and R2 as the later or dependent rule, so for "R1 depends on R2" I need to make a mental note while reading the rest of the paragraph. I recall this was discussed previously and there was a desire to follow a mathematical convention where variables are introduced in order. If others also find this counterintuitive, I think the best solution would be to add a sentence such as: "Rule R1 may produce triples which rule R2 depends on, making R2 a dependency of R1." The R1/R2 references can then be inverted.

10. In S4.3, the definitions of open / closed dependency are a bit repetitive between the intro and then again under "Rule dependency". Was there a merge issue here? I think the second half of this sentence was a copy paste error "matches a triple template of R2 in a negation element".

@afs @simonstey @robert-david @liviorobaldo @osavkovic

[liviorobaldo]

Hi David,

Thanks for this to-do agenda, very useful. My comments are below:

1. I agree, but it should also include run-once rules. The two main issues with production rule systems such as the one we are trying to develop are: (1) indeterminism when using non-monotonic operators, and (2) infinite loops when creating new resources in the head. We should show how these are addressed in SHACL 1.2.

2. I don’t quite understand what you are proposing here. By the way, did you mean section "3.7 Relationship between SHACL Rules and SPARQL" (not S3.8)?

3. I would rather avoid “feature-centric” titles. Thus, I would for instance change "Recursion" => "Adding recursive rules" or something similar. More importantly, these sections currently start directly with examples, but they should begin with an introductory paragraph. For example, in the "Recursion"/"Adding recursive rules" section, I would add a short introduction explaining: (1) what recursive rules are (with the example), (2) how they are executed (i.e., until saturation / no more triples can be inferred), and (3) that since this may lead to infinite loops, we'll introduce run-once rules to prevent them.

4. I agree. We should expand the narrative of the sections/subsections, and we can also use "data blocks" within those narratives. By the way, I was looking at the definition of "data block" in S4.1. It says: "These triples are added to the inference graph as additional facts and are included in the inference process". I don’t think this sentence should be part of the definition; in any case, I found it quite confusing. My understanding was that data blocks are simply sets of triples provided as input together with the rules. Or not?

5. I agree, same as point 3.

6. Good catch… I was actually the one who added the sentence: "Users are responsible for ensuring that iterative applications of rules that generate new blank nodes or literals do not result in infinite loops". This was written before we introduced run-once rules, and I had forgotten about it. Run-once rules are precisely meant to avoid infinite loops, which is why I like them. So I think this sentence should just be removed (assuming my understanding of run-once rules is correct).

7. I don't understand your objection here. The introduction says: "SHACL Rules also support constructs such as negation as failure, which could lead to different inferred graphs depending on the order in which rules are executed. To avoid this, rules are evaluated using stratification, which establishes a single implicit ordering among rules, ensuring that the same inference graph is always produced". This is exactly saying that stratification prevents different orderings. That said, if you still find it ambiguous in English (you’re a native speaker, I’m not 😅), feel free to suggest an alternative wording.

8. OK, but was this decided as a general specification? In other words, is this something we should stipulate, or is it implementation-dependent (i.e., some implementations may tolerate what you describe while others may simply raise an exception)? I don’t remember what was agreed on this.

9. Makes sense, I agree.

10. Indeed, the content is repeated. It might be useful here to include one example of an open dependency and one of a closed dependency.

Cheers,
Livio

[recalcitrantsupplant]

Hi Livio,

Thanks for the feedback - I think a lot has been covered by the updates Andy has in the open PR as per his responses below. For some of the others:

"These triples are added to the inference graph as additional facts and are included in the inference process". I don’t think this sentence should be part of the definition

Because this is "how" more than "what"? If the second sentence were removed entirely I think it would be less clear. Would something like this be better:
"A data block is a set of triples that provide additional input facts to the inference process."

Section 3.5 should say explicitly that if a SET expression evaluates with an error, the current solution is dropped and the rule emits nothing for that solution.

was this decided as a general specification?

To the best of my memory yes, and it's what is currently in the algorithm at 6.4

[liviorobaldo]

"A data block is a set of triples that provide additional input facts to the inference process."

=> Yes, I think this provides a better definition

[liviorobaldo]

P.S. I've just noticed that @afs has provided a new definition of a data block, which also looks good:

"Data blocks allow concisely providing RDF triples directly to the rule set evaluation. Triples in datablocks are added to the inference graph and are available for matching in the body of rules."

[afs]

one worked example through the document

Suggestions for what subject area that example might be?

[recalcitrantsupplant]

A few, happy to flesh out one of these:

1. software package dependencies, not depending on things with vulnerabilities, min age etc.
2. scope 3 emissions i.e. counting CO2 emissions for all indirect sources used to create some product
3. food ingredients + allergens
4. Bill of materials for a product + sanctions on where parts are sourced from or dual use etc.

Perhaps 4 is best, and good to do something non IT related, though 1 might be easier to understand for the same reason.

[afs]

Thank you @recalcitrantsupplant,

1. Worked example
   Yes - agreed.
   Suggestions for running example should be are most welcome.
   Let's rework the example after the other changes.

2. Added a paragraph about SPARQL. More can be said in section 3.7.

3. How about "Basic Patterns" (a name with a nod to SPARQL basic graph patterns)? Like SPARQL, "basic" is the point where the rules touch the data. "Pattern Matching" would also work.

4. New subsection added near the end - revisit when we settle on a running example and then point out that DATA { :s :p :o } is the same as writing RULE { :s :p :o }" WHERE {}.

5. Done!

6. Removed as @liviorobaldo suggests

7. I've removed the clause "which establishes a single, implicit ordering among rules, " so it talks about the purpose of consistent outcome (the "what") and not about the means (the "how").

More to come on PR #916

[recalcitrantsupplant]

Thank you

1 - Yes will come up with a suggestion(s) - perhaps extending the existing example is fine.. I'll come up with something
3 - I think Basic Patterns is good, even if people aren't familiar with the grammar it suits.

[afs]

In S4.3 Rule Dependency, I found the R1/R2 direction unintuitive.

I've reworked the dependency section but not reversed R1/R2; I hope it is a bit clearer and, when completed, the examples will help.

I didn't find reversing R1/R2 as that much better. "RA depends on RB" becomes "RX is a dependency for RY" which, to me, isn't that much better.

[afs]

PR #916 merged - I hope I have caught all comments.

The document is always open for review.

Issues spun off:

• Add well-formedness conditions relating to NOT #690
• Create a running example for the rules description section #930