Does output include base graph triples

[nicholascar]

The section Rule Set Evaluation indicates that:

"The inferred triples do not include triples present in the set of triples of the base graph."

However, the definition given for an evaluation graph is:

"A evaluation graph is an RDF Graph that combines the base graph and all triples produced during the evaluation of a rule set."

• Q1: So I conclude that an evaluation graph is not the output but an interim thing. Is this correct?

If I want to use a SHACL Rules engine to remove triples from a graph, I could do so by generating (selecting) the triples to be removed and then removing them from the base graph if the output was inferred triples only but not if it included the base graph as then I would get no result.

• Q2: Is removal by inferring triples to be removed and then removing them from the base graph an expected use pattern?

[liviorobaldo]

Hi Nicholas,

Sorry, but I don't fully understand your Q1. I don't see the two claims as contradictory. It is true that inferred triples do not include triples from the base graph. Those inferred triples are then added to/combined with the base graph to obtain the evaluation graph. In other words, the evaluation graph is different from the set of inferred triples: it is the union of the base graph (see let G_I = G_0 and let G_I = Y ∪ G_I in “5.4 Evaluation of a Rule Set”) and the inferred triples, which are disjoint from one another.

The evaluation graph is not an "interim thing"; it is the output of the Evaluation of a Rule Set. With the current specification, it is up to the implementer to re-run the Evaluation of a Rule Set until no new triples are inferred. We could, of course, stipulate this ourselves (i.e., define an Evaluation of a Rule Set that iterates until saturation), but this raises the problem of infinite loops: rules can also create new RDF resources and literals, so re-iteration may never reach saturation.

Last week I created a PR to rewrite the Introduction of the rules: #722
These issues are being discussed there. From that discussion, I understand that it may be possible to implement mechanisms to detect and prevent infinite loops, which could provide a solution.

Regarding your Q2, yes, I think what you propose is an expected pattern. This is also discussed in the PR linked above; see in particular the third bullet point at the top, which I quote here:

• Regarding “SHACL Rules only add content to the knowledge graph”, rules do not remove content. See the discussion here: allowing rules to remove content, although potentially useful, could introduce several issues, particularly with respect to guaranteeing termination of rule execution. For this reason, I think we should avoid this.

So either we extend the grammar with rules that delete triples (which would be very difficult to handle), or we avoid that and delete triples using exactly the pattern you propose: we select the triples that must be deleted and then delete them. However, SHACL Rules cannot be used for this purpose, because they infer triples rather than select them.

Cheers

[afs]

• Q1: So I conclude that an evaluation graph is not the output but an interim thing. Is this correct?

Yes. The evaluation graph is the working graph of the new triples and the base graph.

Then in:
https://www.w3.org/TR/shacl12-rules/#eval-rule-set
the inference graph is calculated as only "new triples".

Now, if the task is to update the base graph and the task does not need to know which triples are inferred and which are original (e.g. no provenance tracking required), an engine can (in a transaction!) work with only the evaluation graph.

• Q2: Is removal by inferring triples to be removed and then removing them from the base graph an expected use pattern?

No. Rule evaluation isn't selecting triples (calculating a subset of base graph).
Use SPARQL Update which can select a subset of triples to be deleted.
Deleting triples invalidates earlier rule conclusions.

We have speculated about post-inference actions but here such as thing exists - SPARQL Update.

@nicholascar Do you have use case where deletion can't be done with SPARQL Update?

Given the timescale of the working group, we are in danger of over-committing. We should keep a focus on the core rules as inference. There is enough work to be done to achieve that focused goal.

[afs]

With the current specification, it is up to the implementer to re-run the Evaluation of a Rule Set until no new triples are inferred.

If by "current specification" you mean SHACL-AF (SHACL 1.0) then that is true.

If you mean SHACL 1.2 Rules, then that is not true. Evaluation of a rule set finds all possible inferences for the given set of rules according to the expressivity we are focused on (datalog with stratified negation). Running the rules again does not generate more triples (caveat: fresh terms which is an area we do not have an agreed approach for).

Last week I created a PR to rewrite the abstract of the rules: #722

s/abstract/introduction/

[liviorobaldo]

If you mean SHACL 1.2 Rules, then that is not true. Evaluation of a rule set finds all possible inferences for the given set of rules according to the expressivity we are focused on (datalog with stratified negation). Running the rules again does not generate more triples

Thanks for the clarification ❤️ I hadn't realised that. But, yes, with stratification, the Evaluation of a Rule Set can indeed be executed only once, re-executing it does not produce any further triples.

caveat: fresh terms which is an area we do not have an agreed approach for

Yes, the introduction of new RDF resources and literals is one of the main open issues we need to address next.

[recalcitrantsupplant]

Do we need to add a formal definition of "inference graph" alongside base graph and evaluation graph in 5.1. Something like "the RDF Graph of inferred triples".

Then in 5.4 should "GI" be changed to "GE", and then after saturation, GI = GE - G0?

[nicholascar]

OK, it seems at though a definition for the "inference graph" would be a useful clarification.

Do you have use case where deletion can't be done with SPARQL Update?

No, my use case, and current implementation, is just to use a SPARQL DELETE to remove things from a graph. I was just wondering if I may be able to use only one rule execution engine to do everything I want, rather than SHACL here and SPARQL there.

Having said that, at this stage I think I can do all the addition tasks I'm currently doing with Rules with SPARQL UPDATE too...

If a definition for "inference graph" can be added or if the idea of having one is rebuffed and if there's no more to say about deleting for now, then I'll close this issue!

[liviorobaldo]

@recalcitrantsupplant, I agree that we need a definition of “inference graph,” but I don’t quite understand this comment:

Then in 5.4 should "GI" be changed to "GE", and then after saturation, GI = GE - G0?

As @afs noted (see comments above), there is no saturation: the algorithm in §5.4 is executed only once (perhaps in the future, when considering the creation of new RDF resources or literals, we might need to execute it multiple times, but first we need to find a way to prevent infinite loops).

[liviorobaldo]

PS. Actually, the definition of “inference graph” is already (implicitly) present: it is the definition of the "evaluation graph":

evaluation graph
A evaluation graph is an RDF Graph that combines the base graph and all triples produced during the evaluation of a rule set.

We could either rename this as "inference graph", as I think the term "evaluation" is more relevant in the context of "…during the evaluation of a rule set". Alternatively, we could write:

A evaluation graph, a.k.a. "inference graph", is an RDF Graph that combines…

By the way, I would call it "inferred graph", consistently with the (new) introduction (see PR #722). Or, we may call it "inference graph", both here and in the (new) introduction. I'm ok with both options.