Extending SHACL Rules and Defining SHACL Rules Dialects - "minutes" from the Task Force meeting on 7/10/2025

[liviorobaldo]

At the last meeting of the SHACL Inference Rules Task Force, we had an interesting discussion about SHACL rules. In particular, I shared my experience developing SHACL shapes and rules for the Time Ontology (https://www.w3.org/TR/owl-time), which is currently a W3C Candidate Recommendation Draft implemented in OWL. It is widely regarded, at least in academia, as the "de facto" standard for representing temporal information on the Web.

The OWL axioms currently defined for the Time Ontology are not very effective for reasoning about temporal relations. For this reason, I have been working on a paper proposing a SHACL-based replacement for OWL. The latest draft is available here:
https://www.liviorobaldo.com/SHACLTimeOntology.pdf

Let me summarize the key points we discussed at the meeting. Andy suggested that I open a discussion thread here:

1. Grouping rules and shapes: Rules should be organized into sets using a RuleSet tag. For validation, a set of rules should be associated with a corresponding set of shapes. This is not specified in the current WG Note 08 June 2017, where rule sets can only be associated with individual shapes.

2. Iterative execution: Rules must be executed iteratively until no further triples are inferred, similar to OWL axioms.

3. Handling inferred triples: Inferred triples should not be automatically merged with the initially asserted ones. Whether to merge them should depend on the task. For example, merging is useful in validation, where the complete knowledge (asserted + inferred) must be checked. However, for tasks involving provenance tracking, it is better to keep inferred triples separate, since they have a different provenance.

4. Limitations of SHACL shapes: the current SHACL language is insufficient to validate even simple knowledge graphs. See Figure 3 (p. 16) and related discussion in SHACLTimeOntology.pdf. The figure shows a graph that uses only one class and two properties from the Time Ontology. It is not possible to define a SHACL shape that validates such graphs in the general case, i.e., over an arbitrary number of nodes. The specific reason is that SPARQL property paths can define regular expressions over properties, but cannot impose additional constraints on the intermediate nodes traversed by those paths.

5. Two-step validation process: based on point 4, ontology validation should proceed in two stages:
   (a) compute the inferred knowledge graph using a set of SHACL rules, and
   (b) validate the inferred graph using a corresponding set of SHACL shapes.
   Hence, a set of rules must be linked to a set of shapes (see point 1).

6. Order of execution (which came first, the chicken or the egg? :-)): the previous point raises the question of execution order: should rules be applied after shape validation (i.e., validate → infer), or should validation occur after rule application (infer → validate)? Perhaps the two processes could alternate: first validate, then infer, then validate again, etc. until no new triples are inferred. However, this could be computationally expensive. A practical compromise might be three steps:

• Validate the initial graph with the shapes;
• Compute the complete inferred graph (until closure);
• Validate the resulting graph with the shapes.

7. Risks with SHACL-SPARQL rules: unlike OWL axioms, SHACL-SPARQL rules can (1) produce infinite loops and (2) lead to non-deterministic outcomes. These issues are discussed in detail in Section 8 (p. 27) of the paper SHACLTimeOntology.pdf, along with illustrative examples, so I won’t repeat them here.

8. Ensuring determinism and termination: as argued in the paper’s conclusions, anyone proposing a SHACL axiomatization involving SHACL-SPARQL rules must demonstrate that the rules cannot produce infinite loops or non-deterministic results (or, at least, that non-determinism does not affect the outcome of the target task). In my paper, I show that the proposed SHACL axiomatization for the Time Ontology is safe with respect to validation. This was straightforward to verify since only one rule could potentially introduce such problems. However, in more complex ontologies, the analysis can easily become much harder.

9. Need for SHACL dialects/profiles: given the concerns in point 8, we should consider defining SHACL dialects or profiles, similar to what was done in OWL (OWL Lite, OWL DL, etc.). The academic community is well-equipped to lead this effort, as it has done for OWL; there is a vast body of literature on inference complexity, termination, and determinism dating back to Turing’s foundational work. We can adapt those formal results to the context of SHACL-SPARQL rules.

10. Extending SPARQL expressivity: SPARQL lacks built-in operators for certain domain-specific computations (e.g., analytical functions in finance). Implementing such logic purely with CONSTRUCT/WHERE rules can be impractical. Users should therefore be able to define custom functions and invoke them from SPARQL. A promising approach in this direction is SHACL-X (https://github.com/SHACL-X), which integrates SHACL with JavaScript. SHACL-X allows the definition of complex JavaScript functions, which enable loops and conditional logic, which can then be invoked from SHACL. This could inspire a dedicated SHACL dialect supporting embedded procedural logic.

11. Optional DELETE rules: it might also be useful to allow rules of the form DELETE WHERE to "compact" RDF graphs by removing redundant triples. Naturally, this would exacerbate the risks of infinite loops and non-determinism. However, this is a secondary issue compared to the points above.

Final remarks
Last but not least, I believe we should promote the development of general-purpose SHACL ontologies. At present, I’m focusing on the SHACL formalization of the Time Ontology, but in the future I/we could also develop further general-purpose SHACL ontologies for spatial relations, compliance checking, natural language quantifiers, and similar. This would greatly help the dissemination of SHACL, and promote the Semantic Web principles of sharing, reusability, interoperability, etc. I realize, however, that such work may go beyond the remit of the SHACL Inference Rules Task Force... or even that of the Data Shapes Working Group.

[mgberg]

4. ... SPARQL property paths can define regular expressions over properties, but cannot impose additional constraints on the intermediate nodes traversed by those paths.

I know this is tangentially related, but this issue is why I suggested this addition to SPARQL a couple years ago, but I don't think anything will come of it. I don't know if that would be sufficient to solve that particular issue or not.

[afs]

Re: 1, 2, 6, 7.

The current draft describes a datalog-based system applied to a collection of rules. This can be defined for stable, repeated iteration (including recursion) without needing explicitly controlling rule order.

Re: 4. Property paths

I don't completely follow figure 3. Reversing properties can be done with ^ -- one down-up step is (hasEnd/^hasEnd)+.

What is also possible, if property paths are allowed in rules, is to have another rule that defines one step along a path to infer a triple, then write the path expression be in terms of this inferred triple.

Also possibility is to classify the intermediate terms being of type Instance and then have a property path (maybe a property path is not needed) on nodes in the graph of type `Instance.

Directly using property paths is not naturally part of core datalog. Some property paths can be expanded into triple patterns; * and + can be written as rules using intermediate triples so maybe (investigation needed) there are ways to explain them.

One lesson is that there may be inferred triples that might go back into the base graph and other are more like "work space" during the running of a rule set. i.e. we define the system based on n-ary named tuples, one special kind being a triple.

Re: 5, 1, -- rules attached to shapes

We have use cases where rules (and in node expressions with default values) would be executed once to infer new triples from a shape. But what does it mean to have arbitrary iteration for a rule attached to a shape if that rule itself depends on other rules not attached to the shape?

One possibility is to define "attached" as meaning the rule body evaluation starts with a set of ?this bindings, not an empty list of bindings, with the observation that SHACL targeting is a pattern matching so the traget, as a pattern, can be written into the rule body.

[afs]

Re: 5, 1, -- rules attached to shapes

I’m not sure I understand what you mean by “that rule itself depends.” Could you give an example of this dependency? Does it mean that one rule depends on another because the second rule produces a triple needed to trigger the first?

Yes. A rule attached to a shape (SHACL-AF) applies to that shape -- this gives the meaning to sh:this and the focus node for sh:condition.

But if the rule is restricted by attachment, how does that interact with a rule that is not attached to the same shape?

One way is to define "attached" as being initial setting of a special variable ?this - i.e. the first element of a rule body is the pattern-equivalent of a target. In SHACL 1.2, sh:match/sh:where (which is why I think "where" is an unhelpful name) could also be used although it may not be analysable for rule dependencies.

If this style of "attached" is adopted, the rule body can still have dependencies determined, stratification can be used, explicit execution order is not needed, repeated application works.

Another meaning we could give to "attached" is that the rule is run-once; more of a calculation flavour, to prepare the base graph for general ruleset application. We have a use case for this and it aligns with "inference" in node expressions.

What does attaching to a set of shapes involve?

At some point, I think the SHACL 1.2 recommendation should specify the execution order

The problems with explicit rule order are:

1. The user has to do more work in writing rules.
2. Combining rule sets through importing can break.

so ideally IMO avoid order except where necessary (new terms, same strata) and for legacy SPARQL and triple rules.

[liviorobaldo]

Hello!

But if the rule is restricted by attachment, how does that interact with a rule that is not attached to the same shape?

That’s why I was proposing to attach sets of rules to sets of shapes. Otherwise, it becomes difficult to understand the dependencies among rules. In SHACL-AF, for example, we currently have (from https://www.w3.org/TR/shacl-af/#rules-examples):

ex:Rectangle
	a rdfs:Class, sh:NodeShape ;
        ....
	sh:rule [ ... ].

So the rule is embedded in the shape. Inside the rule, we can in turn embed another shape via sh:condition, meaning the rule applies only to RDF resources that satisfy that shape. This already gives us two levels of embedding, which is quite confusing — and also somewhat against the “spirit” of RDF, which flattens all knowledge into triples rather than using nested structures like first-order logic.

Why are these embeddings necessary? From what you mentioned above, I understood that this is mainly to map the variable $this to the one defined in the shape where the rule is embedded, and then pass that value to the second shape embedded within the rule. But do we really need to keep this mechanism? Personally, I find it quite confusing and I don’t see much benefit in it.

Instead, the real issue — the one we’re discussing — is what happens if one rule depends on another. We need a way to explicitly connect the two rules. I didn’t quite understand your proposal of using “attached”, especially since I couldn’t find any information about sh:match or sh:where online. You also mentioned you have a use case for this. Could you kindly share it? It would be really helpful to see that, and maybe more examples in general.

To address the dependency problem, I was suggesting associating a set of shapes with a set of rules. This way, rules are no longer embedded within shapes, and shapes are not embedded within rules either.

:rs a sh:RuleSet.
:ss a sh:ShapeSet.
:rs sh:attached :ss.

Both :ss and :rs apply to the same srl:data, as you called it in the current draft... so maybe we should extend the three lines above to also add the data, perhaps we introduce a new class"srl:Cluster" to cluster together data, rules, and shapes, something like this:

:cluster-1
  rdf:type srl:Cluster;
  srl:data (
    ...
  );
  srl:ruleSet (
    ...
  );
  srl:shapeSet (
    ...
  ).

To reply your question ("What does attaching to a set of shapes involve?"):

The shapes work as in standard SHACL, so they can use $this, which refers to the RDF resource quantified in the sh:target*. On the contrary, the rules do not have $this anymore because they are no longer embedded within a shape, and therefore cannot import $this from that shape. They are independent from the shapes, they just apply to the same data.

But I don’t see any problem with the fact that they no longer have $this. In the current draft, I don’t see any rule in srl:ruleSet (in the example in §4) that actually uses the variable $this. All the rules in the srl:ruleSet refer to the entire dataset in srl:data, and they use variables like ?x, ?v1, and ?v2, but not $this. And that’s fine! These rules aren’t embedded in any shape, so $this simply isn’t defined. The absence of $this doesn’t cause any issues or block inferences. So why should we need this variable at all when executing inference rules?

As in the current SHACL-AF, if we have a srl:Cluster like the one above, we should define the execution order: shapes or rules first. I would avoid introducing sh:condition in srl:ruleSet to force the shapes to execute first. Let’s impose a single order; for example, shapes always execute first on the srl:data. For more details on my opinion about this execution order, see my point "6." in my first reply above.

Finally, about:

The problems with explicit rule order are:

• The user has to do more work in writing rules.
• Combining rule sets through importing can break.
  so ideally IMO avoid order except where necessary (new terms, same strata) and for legacy SPARQL and triple rules.

Yes, I totally understand this. Dealing with negation-as-failure and creating new anonymous individuals requires extra effort from the knowledge engineer. But if someone is willing to make that effort (as many use cases actually demand), why should we forbid it? This is exactly what SWRL does, and as a result, people stopped using it. It's also what standard Datalog does, which is why many academics developed extensions... but those extensions remained mostly in academia.

Here, I was proposing to leave both options open: users can choose to avoid features like unordered execution, non-monotonic operators, and creation of new anonymous individuals, or they can instead choose to take the risk. But then it’s their responsibility if things don’t work as expected.

You also mention "except where necessary" and "for legacy SPARQL and triple rules." Ok, then we are on the same page :-) This is also what I want. But how do we allow that with the srl:RuleSet as defined in the current draft? This is unclear to me, because in your previous reply you said: "The current draft describes a datalog-based system applied to a collection of rules". How can we extend the current draft to also have SPARQL rules in the srl:RuleSet, for those who wish so?

My idea is to define different profiles for srl:RuleSet, similar to how OWL defines profiles. Don’t know OWL too well? Use OWL-Lite, and you’ll avoid problems. Are you (or believe yourself to be) an OWL expert? Then use a more advanced profile... but then don’t complain with us if you run into issues; it's your responsibility to study OWL more carefully. That’s roughly the same message we should communicate here. We should simply make them aware of these issues and how they could, in theory, be addressed. For example, ordering the rules using sh:order might resolve the problem of non-deterministic outcomes.

Cheers
Livio

[afs]

As the group discussed, validation and running rules can treated as independent steps. Both validation on the base data (input) or on the conclusion of base data + inferred triples (output) have use cases.

But if the rule is restricted by attachment, how does that interact with a rule that is not attached to the same shape?

That’s why I was proposing to attach sets of rules to sets of shapes.

You haven't said what attached to a set of shapes means.
What difference does it make to the rule set evaluation?

The problems with explicit rule order are:

• The user has to do more work in writing rules.
• Combining rule sets through importing can break.
  so ideally IMO avoid order except where necessary (new terms, same strata) and for legacy SPARQL and triple rules.

Yes, I totally understand this. Dealing with negation-as-failure and creating new anonymous individuals requires extra effort from the knowledge engineer.

I didn't mention NAF.
There are two forms of NAF which are both well-defined without any need for order from the app/user.

[liviorobaldo]

Good morning 🙂

As the group discussed, validation and running rules can treated as independent steps. Both validation on the base data (input) or on
the conclusion of base data + inferred triples (output) have use cases.

Yes, I completely agree, shapes and rules can be run independently or together. We should leave both options. Actually, three options:

1. only shapes
2. only rules
3. shapes & rules

Apologies, I may have forgotten to mention this in my previous message. The "cluster" I proposed in the previous reply (I should probably pick a better name than "cluster" 🙂) can contain only a set of shapes:

:cluster-1
  rdf:type srl:Cluster;
  srl:data (
    ...
  );
  srl:shapeSet (
    ...
  ).

only a set of rules:

:cluster-2
  rdf:type srl:Cluster;
  srl:data (
    ...
  );
  srl:ruleSet (
    ...
  );

or both:

:cluster-3
  rdf:type srl:Cluster;
  srl:data (
    ...
  );
  srl:ruleSet (
    ...
  );
  srl:shapeSet (
    ...
  ).

If there are only shapes (as in :cluster-1), they are executed on the data exactly as specified in the SHACL 2017 recommendation. If there are only rules (as in :cluster-2), they are executed on the data to compute the inferred graph. If both are present (as in :cluster-3), validation is performed "on the conclusion of base data + inferred triples (output)", as you say.

However, it is not entirely clear how things should work in the third option. Which component should run first: the shapes or the rules? And if we allow the rules to iterate until saturation, should the shapes be re-executed after each iteration (validating each intermediate inferred graph), or only once at the end on the final graph? I have a proposal for this, but I'm not fully convinced about it, so I'm happy to discuss alternatives. See my next reply.

You haven't said what attached to a set of shapes means.
What difference does it make to the rule set evaluation?

In the third option (this is what I meant when a set of rules is "attached" to a set of shapes), in my view the evaluation should be carried out as I specified in point "6." in my first message above:

---

6. Order of execution (which came first, the chicken or the egg? :-)): the previous point raises the question of execution order: should rules be applied after shape validation (i.e., validate → infer), or should validation occur after rule application (infer → validate)? Perhaps the two processes could alternate: first validate, then infer, then validate again, etc. until no new triples are inferred. However, this could be computationally expensive. A practical compromise might be three steps:

• Validate the initial graph with the shapes;
• Compute the complete inferred graph (until closure);
• Validate the resulting graph with the shapes.

---

These three steps are the proposal I mentioned above, the one I’m not fully convinced about so I'm happy to consider alternatives.
Hope this answers your question! If not, it means I have misunderstood it 🙂 Could you please clarify what you meant?

Ok about the ordering of rules: I agree they should be avoided whenever possible, since they just add extra work for the knowledge engineer.

Finally, could you tell me more about the “two forms of NAF that are both well-defined without any need for order from the app/user”? Where can I find the specs for these two NAFs? Is there a link where I can read more? If using one of these avoids non-determinism, that could be a really good solution 🙂

Cheers
Livio

[liviorobaldo]

Hello everyone,

After Tuesday, I studied the basics of stratified programming, and I'm now more convinced that there's no longer a need to stick to SPARQL. We could define a new rule format that doesn't necessarily incorporate SPARQL operators, or at least not all of them.

From my past work on SHACL rules, however, I believe two features of SPARQL should be retained (though not necessarily implemented with the same operators):

1. The ability to generate new RDF resources in the heads of rules. In standard logical approaches, this corresponds to allowing existential quantification in the heads, which are then Skolemized into first-order terms, that is, into new anonymous RDF individuals in our context.

2. The ability to generate new datatype values. For example, we might need to calculate a numeric value (e.g., “80% of the individuals of a class”) and assign it as the object of a datatype property in the rule head. SPARQL supports this through the BIND function, for example:

BIND(0.8 * ?x AS ?y)

Here, ?x could be derived from an aggregate SPARQL operator such as COUNT in another query. Then, in the CONSTRUCT clause, we could have something like:

:a :has-value ?y .

which assigns the newly calculated number to the individual :a via the datatype property :has-value.

A limitation of 2. is that SPARQL provides only a small set of mathematical operators. Suppose we want to reason over an RDF ontology in the financial domain, where values need to be computed using complex financial formulas. SPARQL operators are simply not expressive enough. We might need to calculate, for instance, covariance, moving averages, risk-weighted returns, or other higher-order statistical indicators that require more advanced mathematical operations.

In light of this, as I mentioned at the last meeting, I really like the related initiative SHACL-X.

In SHACL-X, you can define your own JavaScript functions and connect them to SHACL.

I think we should adopt a similar approach and incorporate JavaScript functions into SHACL rules, for example, allowing something like:

BIND(computeRiskWeightedReturns(?x, ?a, ?b, ...) AS ?y)

Here, computeRiskWeightedReturns(?x, ?a, ?b, ...) would be an imported or custom JavaScript function that calculates the risk-weighted returns based on the numerical parameters ?x, ?a, ?b, etc., and assigns the result to the variable ?y.

Cheers
Livio

[afs]

I'm now more convinced that there's no longer a need to stick to SPARQL

Do you mean "SPARQL rules" SHACL-AF or the SPARQL-like language compact rules.

The SHACL Rule language covers both point 1 and point 2.

A limitation of 2. is that SPARQL provides only a small set of mathematical operators

!!??!! https://www.w3.org/TR/sparql12-query/#SparqlOps
which is from https://www.w3.org/TR/xpath-functions-31/ (without sequences). There is an extension mechanism in SPARQL to add functions (implementation language neutral).

We might need to calculate, for instance, covariance, moving averages, risk-weighted returns, or other higher-order statistical indicators that require more advanced mathematical operations.

They are aggregates. Some triple stores already have statistical aggregates (and custom aggregates are allowed in SPARQL - implementation language neutral).

[liviorobaldo]

Hi Andy!

Ok, you're right, I didn't pick a very good example 😅

I'm familiar with the functions you mentioned, the ones prefixed with math:. Those are exactly what I meant when I referred to "a small set of mathematical operators". The issue isn't really that the set is small (that's subjective), but rather that it's fixed. Many additional functions require more advanced computations, which could involve loops, conditional statements, or even importing external libraries.

Anyway, as you pointed out, "There is an extension mechanism in SPARQL to add functions (implementation language neutral)". I didn't actually know about that, I just searched on the Web and found:

https://www.w3.org/TR/sparql11-query/#extensionFunctions

So, the official W3C recommendation indeed states that you can define custom functions. However, it doesn't prescribe any particular implementation language (as you said, it's implementation-language neutral) or specify how this should be done in practice.

I also found that some proprietary SPARQL engines already support this, they provide extra functions and even let users define their own:

https://rdf4j.org/documentation/tutorials/custom-sparql-functions/
https://graphdb.ontotext.com/documentation/11.1/sparql-ext-functions-reference.html

I assume that's what you were referring to.

Fair enough then 😊

I think we can adopt the same approach for SHACL 1.2 Rules. That is, following the model of SPARQL 1.1 by stating that the set of functions is extensible, but that this is optional and left to the discretion of specific engines, making it a non-normative, language-neutral implementation detail... something like that 🙂

Cheers
Livio

PS. about your first question: I meant "SPARQL rules" SHACL-AF

[afs]

I also found that some proprietary SPARQL engines already support this, they provide extra functions and even let users define their own:

So does Apache Jena with GraalVM.

It does not mean it is uniformly a good idea - it's a source of security problems.

[recalcitrantsupplant]

11. Optional DELETE rules: it might also be useful to allow rules of the form DELETE WHERE to "compact" RDF graphs by removing redundant triples. Naturally, this would exacerbate the risks of infinite loops and non-determinism. However, this is a secondary issue compared to the points above.

I think this would be a good addition, perhaps with a name other than DELETE to separate it from SPARQL. I can't find where we have an agenda for the rules TF - will bring this up next meeting.

[liviorobaldo]

Hello! Yes, I am currently working on a use case where we need to represent a set of options available to an individual. For example, suppose we need to state that I have the following options:

[a b c d e]

This can of course be represented as an rdf:List.

Later on, we may discover or infer that I actually have only three of those options, for instance:

[a c e]

It remains logically consistent to keep both rdf:List(s) in the same knowledge graph. However, the first one becomes redundant, and ideally should be removed. To achieve this, we need something equivalent to the DELETE operation in SPARQL.

This made me think that we more generally need such rules whenever we want to implement Conjunction Elimination, i.e.:

((A ∨ B) ∧ A) ⇒ A.

My broader research objective is to re-implement standard logic in RDF+SHACL via RDF reification. This would enable RDF+SHACL to act as a "universal logic", something that many people in academia have dreamt about over the years. Currently, there are hundreds of incompatible logical formalisms, so the same results are often rediscovered independently simply because the respective communities do not interoperate. If you are interested in this topic, you may want to have a look at this other recent paper of mine: https://cronfa.swan.ac.uk/Record/cronfa70457

Anyway, one step at a time 😊 As I mentioned earlier, one issue with the DELETE-WHERE rules we are discussing is that they would exacerbate the risks of infinite loops and non-determinism, and these are serious concerns we have been talking about for some time already.

Cheers,
Livio

[afs]

This can of course be represented as an rdf:List.

One way is to represent as a list. It is not the only way. Why not repeated properties? rdf:lists are not first-class objects in the RDF data model and we have work within the RDF data model. The blank nodes in a list make it "interesting" to manipulate.

RDF graphs by removing redundant triples.

So - to be clear - you mean "domain specific redundancy" not redundancy in RDF. As an RDF graph is a set, triple redundancy is multiple redundant use of blank nodes and can be removed by creating a lean graph.

In your example, the first list may be redundant. It's an application choice. The discovery should be recorded a different property so that "before" and "after" are both present in the model.

[liviorobaldo]

Yes, I agree that rdf:List is not the only way to represent options. In fact, in my use case I represent them using the kind of alternative you suggest (I have a central blank node with a property oneOf that links the options to it). I referred to rdf:List in my previous message because it seemed (to me) more intuitive to understand.

I meant domain-specific redundancy, yes: triples that are logically redundant in the logic of the use case. If you need to track the history of inferences, you can timestamp the triples as you suggest. However, in practice we usually work with the latest updated version of the graph, and removing redundant "old" triples can then improve efficiency as we work with smaller datasets (we could still store the timestamped versions in a backup file or database before deleting them, of course).

[afs]

This would enable RDF+SHACL to act as a "universal logic", something that many people in academia have dreamt about over the years.

Look at N3.

[liviorobaldo]

Yes, I am familiar with N3. In fact, I believe it would also be worth discussing how SHACL rules compare to N3 rules, and whether certain features from N3 could be adopted.