Packaging rules, shapes, and data with a defined execution order

[liviorobaldo]

In the SHACL Inference Rules Task Force, we are defining the table of contents for the SHACL 1.2 Rules draft.

See discussion 637. The provisional table of contents includes "7. Attaching Rules to Shapes", where we should explain how rules and shapes should work together. Below in the discussion, I propose moving this content to 2. Packaging SHACL. Perhaps in "7. Attaching Rules to Shapes" we could just include a brief pointer to 2. Packaging SHACL.

Concerning how rules and shapes should be executed together, in discussion 603, based on my experience with SHACL-SPARQL, I proposed to associate sets of shapes with sets of rules. This can be done with a new resource we might call "cluster" (but we should actually pick a better name, like "bundle", "package", "module", etc.), which would group data with shapes, with rules, or with both (three options in total). Something like:

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

If both shapes and rules are present, we need to decide the execution order: should shapes run first, or the rules? As I argued in my recent paper (link provided at the beginning of the discussion), shapes should be executed at least once after the rules. This is because what we want to validate is the inferred knowledge graph, consisting of the initially asserted triples plus all triples that can be logically inferred from them. This aligns with the reasonable assumption that if something logically inferred is invalid, then the originally asserted triples must also be considered invalid. Rules serve then to "modularize the effort" when it is too complex, if not impossible, to write a single shape that internally computes all inferred triples before validation.

However, nothing prevents executing the shapes multiple times. For example, if the shapes already invalidate the initially asserted triples, there is no need to compute the inferred knowledge graph. Shapes could also be re-executed after each "round" of rules execution (rules are iteratively re-executed until no new triple is inferred). However, this approach could be computationally expensive.

In light of this, perhaps the best approach is for the SHACL 1.2 recommendation to eventually specify that executing the shapes is mandatory only at the end of the rules' execution (until saturation), while libraries remain free to optionally execute the shapes at the beginning or after each individual round. They could even allow the programmer to make this choice via special parameters in the relevant functions.

PS. I see that in 2. Packaging SHACL, specifically 2.1 Motivation, there are already three issues listed. Can someone add this one? I’m not sure how to do it myself (and perhaps I cannot, as I don’t have the necessary permissions). Thanks.

[TallTed]

Without delving too deeply, I have an intuition that inferring and including that data might result in a knowledge graph which satisfies shapes which were not satisfied by the initial knowledge graph; in other words, I think that even "if the shapes ... invalidate the initially asserted triples, there is [a] need to compute the inferred knowledge graph".

This may not be the case with all initial knowledge graphs, so it may sometimes make sense to evaluate the initial knowledge graph against your shapes, and if that fails, you can skip execution of the rules, and you may know this in advance and want to specify such.

However, in other deployments, you may know that evaluating the initial knowledge graph against your shapes will always fail, and that inferred data may change that, after one or more iterations over the rules, so you want to specify processing the rules some number of times before evaluation the shapes against your (partially or completely) inferred knowledge graph, after which you might want specify a number of times to (re)process the rules before re-evaluating the shapes against your (still partially or completely) inferred knowledge graph.

All of which is to say, I think there should be a way to specify at run time whether to run the shape evaluation or the rule processing first, and if the rules, how many times, and what to do next. This flexibility will allow for a default "simple" behavior, and preserve the ability to handle any "complex" situations a user may encounter.

[liviorobaldo]

I completely agree with your point that:

there should be a way to specify at run time whether to run the shape evaluation or the rule processing first, and if the rules, how many times, and what to do next.

On the other hand, I’m struggling to imagine a case where the inferred knowledge graph satisfies the shapes while the initial knowledge graph does not, unless we also introduce rules that delete triples (see related discussion here).

If rules only add triples, then if the initial set of triples is invalid, any superset of it should remain invalid.

That said, this should ideally be demonstrated formally, and I have not done so, which means your intuition remains absolutely plausible 😊

Cheers,
Livio

[TallTed]

I’m struggling to imagine a case where the inferred knowledge graph satisfies the shapes while the initial knowledge graph does not

The easiest example I can think of would be an inference of a triple that satisfies a SHACL requirement, based on two or more triples that exist in the original knowledge graph.

Perhaps the initial knowledge graph includes triples that indicate that a person was born in 1975, and another that they are a citizen of England, from the two of which the rules can infer that this person is an eligible voter in England.

If the SHACL shapes require triples indicating an entity is an eligible voter, and in what nation, then the original knowledge graph will fail, but the inferred knowledge graph will pass.

[liviorobaldo]

Okay 👍

More generally, we could say that this occurs with shapes that enforce the closed-world assumption, where all relevant data must be explicitly specified and cannot remain unknown. If the initial graph lacks this data, the shapes will invalidate the graph. However, the corresponding triples could be inferred through the rules, in which case the inferred knowledge graph would satisfy the shapes.

Therefore, it seems that shapes should be executed only on the inferred knowledge graph, i.e., after the rules have been applied to saturation. But as you said (and I agree), we could leave the programmer to specify different options at runtime, since there may be contexts I cannot see at the moment.

[afs]

There are two SHACL operations available:

• validate(constraints graph, data graph) -> validation report
• rules(ruleset graph, data graph) -> inferred triples

These steps can be combined as the application requires. The specs can not describe all the possibilities.

Example:

Validate data with a first shapes graph which checks the quality of the basic data - literals conform to datatypes, literal values in the expected values ranges, inverse property functions are max count 1, properties are spelt correctly

Then a first ruleset can be executed with some assurance of the data, e.g. no "tuesday"^^xsd:date or two employee numbers for the same person.

The resulting new triples may provided a new data graph that enables another level of validation with a second shapes graph, e.g. shape instances are complete, whatever "complete" means in the application domain.

Then another ruleset can transform between vocabularies, or provide concrete defaults.

Then another shapes graph is used to validate the transformed vocabulary.

Then another ruleset performs infers domain-specific connection between resources or inferences such as rdfs:domain and rdfs:range so they are not calculated at application runtime.

Yet another ruleset maybe used "backwards" as the application runs - instead of materializing inferences, it is used to answer the question: "is the triple <someURI> rdf:type :T inferred by the data" or the question "what are the ways that ?X :property ?Y matches?"

So my POV: The scope of the rules specification is to define rules(ruleset graph, data graph) for one ruleset and one data graph. How that step is used by an application is outside of SHACL Rules.

If both shapes and rules are present, we need to decide the execution order:

If a profile has a bundle of shapes and rulesets, then the profile may well need to describe the intended usage/workflow, which is more than an execution order.

[nicholascar]

It is true that, to date, including .2 Core & SPARQL, there's been no specification of execution arrangements in SHACL and that these have been left to the implementation.

I agree that the Rules spec need not touch execution arrangements and need only specify rules(ruleset graph, data graph), so if there is to be a way of communicating a required sequence of steps, e.g. validator-01 → rules-02 → validator-02... then it shouldn't be in the Rules spec, perhaps the Profiling spec.

Just note that there's more than just rules & validators used by current SHACL tools. pySHACL can also be told about inferencing other than RDFS (like OWL-RL) and if any ontologies need to be imported before validation too.

[liviorobaldo]

The scope of the rules specification is to define rules(ruleset graph, data graph) for one ruleset and one data graph. How that step
is used by an application is outside of SHACL Rules.

Okay, I agree that this is the better and more flexible solution. However, I think the spec (of both rules and profiling) should make this explicit. They should include a note or disclaimer stating that it is up to the user to programmatically determine the order and number of iterations (of shapes, rules, both, some rules for X times and other shapes for Y times... whatever).