Define rule set evaluation

[afs]

Work to define rule set evaluation.

• See this document rendered online here

[afs]

Very early work to show direction.

[osavkovic]

Very early work to show direction.

Hi Andy, could you say a bit more about what kind of input you expect here? For instance, should I provide comments and edits, and should I make them in the document or here?

Thanks, O.

[afs]

Very early work to show direction.

Hi Andy, could you say a bit more about what kind of input you expect here? For instance, should I provide comments and edits, and should I make them in the document or here?

Thanks, O.

This is a (currently draft - i.e. unfinished) PR.

You can make comments and suggest changes here.

All changes come in via pull requests; we do not edit the document directly.

PRs are checked for IPR acceptability automatically. Merging PRs has a policy; in this repo, the policy is to have at least one approval. That is, at a minimum, for governance; someone else checked the submitter has followed process and isn't doing anythign silly. But usually an approval is a general agreement on the content and implied direction.

Changes are not fixed - a later PR can revise designs. This is common.

The default branch of this repo, unusually called gh-pages, not main, should be branch-protected, meaning no one can push directly to it.

[liviorobaldo]

Dear Andy and all,

I tried to update the document. Apologies in advance if I made any mistakes or misunderstood something. It’s my first time working on a W3C working group repo. However, from what I understood from Andy, my update won’t go through until some of you approve it, so feel free to delete anything if I got it wrong 🙂

I thought we should clarify in “2. Outline” that rules can also create new RDF resources and new literals. I included an example of the former (an example of the latter is already in “3. Speculative features”, where a new literal is created and bound to ?FN using concat). I also pointed out that this may lead to infinite loops if a user keeps re-applying the rules. However, as I understand it, we agreed in this issue that avoiding such loops is beyond the scope of SHACL rules; it is up to the programmer to iterate rules only under conditions that prevent infinite loops.

By the way, in “3. Speculative features”, I think we should discuss negation-as-failure and aggregates. The former is already there. However, I’m not clear on what the title “Speculative features” is meant to convey. From what I recall, we decided that we want negation-as-failure and aggregates, so they shouldn’t really be described as speculative.

Cheers
Livio

[afs]

@liviorobaldo

This PR is titled "Define rule set evaluation".
That is its focus and the sections of the document it changes.
The PR was "draft".

You have broken the work I have in-progress and made it hard to deal with @TallTed's suggestions.

Please make a separate PR.

[liviorobaldo]

Dear Andy and all,

My apologies, I didn’t do this on purpose. As I mentioned in my previous message, I’m still learning how to use these tools and understand the collaboration policies for working with all of you.

I now understand that this PR is meant to focus only on Section "6. Shape Rules Evaluation" of the document, so we should restrict comments and edits to that section.

Later today, I will open a new PR titled "SHACL 1.2 Rules - Introduction & Outline", dedicated solely to the first three sections of the document. I will also make sure to explicitly note the scope and invite all of you to review it.

Could you kindly confirm that this is the correct approach? Is there anything else I should pay attention to when I'll create the PR? If I'll make some mistake I will of course delete the new PR.

Thanks again for your patience — I’m still learning and will do my best to avoid causing any inconvenience.

Livio

[afs]

Please remove your commit from this PR.

[liviorobaldo]

Dear Andy,

Ok, apologies again. I am trying to fix my mistake while learning how to use this platform and, of course, to avoid making further errors. I’ve installed GitHub Desktop and opened this branch. I located my commit and can see that “Revert changes in commit” is one of the available options:

Is this the option I should click on?

Thanks for your patience
Livio

[afs]

I don't use GitHub Desktop. It's not available for my OS.

I would have thought you want "reset to commit" where the commit is the place you want to keep. "Define ..."

I hope changes will be made locally so you can check them before pushing them to github.

[liviorobaldo]

Hi Andy,

"Reset to commit" is not selectable, as you can see in the screenshot above. Let me try “Revert changes in commit”. If it does not work or create other troubles, I will remove the content I've added by hand.

As soon as I've time, I will then open a new PR titled "SHACL 1.2 Rules - Introduction & Outline" as I indicated above.

Livio

[liviorobaldo]

PS. I think I managed, can't see anymore the text I've added before in the document rendered online here.

[afs]

"Reset to commit" is not selectable,

Says you can use right-click on the commit you wish to go back to.
https://docs.github.com/en/desktop/managing-commits/resetting-to-a-commit-in-github-desktop

Your screenshot shows the HEAD as focus, not the "Define ..." commit.

“Revert changes in commit” applies your commit but in reverse. See all the lines starting -; the result is 2 commits.

I have reset the branch with a git push -f. A dangerous way to do it (I took a local copy for safety first.) Also - reset the draft flag and cleared the approved flag.

The HEAD is [77aed92] [email protected] (3 days ago) - Define rule set evaluation

[liviorobaldo]

Andy, thank you very much for fixing the troubles I caused. Is there anything I am supposed to do? I think no, because I can now only see one commit, so I think the situation has been restored.

[afs]

Very early work to show direction.

Hi Andy, could you say a bit more about what kind of input you expect here? For instance, should I provide comments and edits, and should I make them in the document or here?

Thanks, O.

We are now at - or exceeding - the usability of the github review UI . Moving around the PR is slow; the new UI can't copy with the large file; accepting suggestions resets the display, hiding some input.

I think it is better for reviewers and for processing review comments to merge this, and then create PRs and raise issues on the document on gh-pages.

[simonstey]

[19] Negation ::= 'NOT' '{' BodyBasic '}' 
[20] BodyBasic ::= BodyTriplesBlock? ( Filter BodyTriplesBlock? )*

means we do not allow for BIND (or nested NOTs) . bug or feature?

[liviorobaldo]

Good catch @simonstey! Without nested NOTs, we cannot represent rules such as:

∀x​[ (A(x)^∀x​[C(x)⇒D(x)]) ⇒ B(x)]

i.e., rules containing universals in the antecedent. For example:

IF { ?p a :Program . NOT{ ?l :in ?p . NOT{ ?l a :correct }} } THEN { ?p a :correct }

This means: "every program ?p whose lines are all correct is correct". Note that this also entails that programs with no lines (i.e., empty programs) are correct, which makes sense (an empty program is, of course, correct).

The nested condition

NOT { ?l :in ?p . NOT { ?l a :correct } }

reads as: "there is no line ?l in program ?p that is not correct". This is how we represent the nested universal:

∀x​[C(x)⇒D(x)]

using negation when the ∀ symbol is not available.

I have worked on some use cases where this type of condition is actually necessary, for instance in the Time Ontology (see this paper, which defines its original semantics: https://www.isi.edu/people-hobbs/wp-content/uploads/sites/58/2023/11/hobbs-pan-TALIP04-1.pdf).

Therefore, I suggest we allow nested NOTs.

On the other hand, I think we should not allow BINDs nested inside NOTs. I cannot see any practical use for them. But if anyone can provide a good example, I’m happy to reconsider.

[afs]

Feature.

There is an issue specifically about negation #674 so we can merge this PR as a partial draft and keep developing it.

Not having features that are outside "datalog" nested inside NOT simplifies the design (AKA simpler getting it right, simpler to get to a complete system we can add features to).

Adding features needs to be proven with use cases to show general applicability, and also a detailed proposal as to how they would work so we can investigate the consequences.

BIND::
The RHS of pattern does not change the body solution. NOT is a specific yes/no condition with no new variable binding ¹. So even if allowed, the assignment would not contribute to the overall body solution which I think is confusing to allow it - it is a mild lost of convenience not being able to calculate a temporary value.

If (that's a big if) we have named tuples as evaluation workspace, the NOT body can be a tuple and then all features are available. That's a more useful feature.

NOT in NOT::
Double negation! What would that mean in this context?

I can imagine (=intuition, =guess) if the inner one was dependent on layers beneath the layer-1 dependency of the outer NOTmaking it layer-2 then something might work but that's complicated. Maybe it's better to say "run two rulesets, one after the other". And again - "named tuples".

Footnotes

1. See Ognjen's comment above https://github.com/w3c/data-shapes/pull/659#issuecomment-3581922057 ↩

[liviorobaldo]

I did some online research. The standard Datalog solution to represent nested NOTs, such as the rule I showed above:

IF { ?p a :Program . NOT { ?l :in ?p . NOT { ?l a :correct } } } THEN { ?p a :correct }

is to introduce an extra predicate and write two rules:

IF { ?l :in ?p . NOT { ?l a :correct } } THEN at_least_one_line_not_correct(?p)
IF { ?p a :Program . NOT { at_least_one_line_not_correct(?p) } } THEN { ?p a :correct }

The semantics is the same.

I agree with Andy that this is simpler from the reasoner's point of view:

Not having features that are outside "datalog" nested inside NOT simplifies the design (AKA simpler getting it right, simpler to get to a complete system we can add features to).

The drawback is that we need to introduce extra rules with auxiliary predicates, which are used only to implement the universal nested in the antecedent. For example, the predicate at_least_one_line_not_correct above is used only in the second rule. If a use case requires many universals in the antecedent, this could lead to verbose rule sets.

Adding features needs to be supported by use cases to show general applicability, and also a detailed proposal for how they would work so we can investigate the consequences.

We would need to empirically measure how frequently rules with universals nested in the antecedent occur in existing use cases. If they occur often, we might need to introduce some kind of "shortcut", i.e., a compact way to represent them (but this should be an "additional feature").

[afs]

Added:

• rebase to gh-pages
• add new shnex: namespace
• placeholder for tests and implementation report