Define rule set evaluation #659
Conversation
afs
requested review from
liviorobaldo,
osavkovic,
recalcitrantsupplant,
robert-david and
simonstey
|
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. |
| An expression is evaluated with respect to a [=solution mapping=] to give | ||
| an [=RDF term=] result. |
There was a problem hiding this comment.
| An expression is evaluated with respect to a [=solution mapping=] to give | |
| an [=RDF term=] result. | |
| An expression is evaluated with respect to a [=solution mapping=] to | |
| result in an [=RDF term=]. |
| <pre class="algorithm"> | ||
| Inputs: data graph G and a rule set RS. | ||
| Output: an RDF graph GI of inferred triples | ||
| <p>The inferred triples does not include any triple present in the set of triples of G.</p> |
There was a problem hiding this comment.
| <p>The inferred triples does not include any triple present in the set of triples of G.</p> | |
| <p>The inferred triples do not include any triple present in the set of triples of G.</p> |
| <dt><dfn>Evaluation Graph</dfn></dt> | ||
| <dd> | ||
| A [=evaluation graph=] is an [=RDF Graph=] that combines the base graph | ||
| and all triples produce by rule during the the evaluation of a rule set. |
There was a problem hiding this comment.
| and all triples produce by rule during the the evaluation of a rule set. | |
| and all triples produced by rules during the the evaluation of a rule set. |
| Let S1 and S2 be solutions. | ||
| </p> | ||
| <pre>compatible(<var>μ</var><sub>1</sub>, <var>μ</var><sub>2</sub>) = true | ||
| if forall v in dom(μ1) intersection dom(μ2) |
There was a problem hiding this comment.
"Forall" (with no space) is a programming-language-specific function. "For all" (with space) is English. These blocks appear to be an English narration, which calls for "for all". If these are blocks of some programming language, they all need to be reviewed with an eye to that vocabulary, so there must be a declaration of what that language is.
| if forall v in dom(μ1) intersection dom(μ2) | |
| if for all v in dom(μ1) intersection dom(μ2) |
There was a problem hiding this comment.
It is "programming language" in a general sense as is used in formal descriptions, including academic papers.
Later, we can replace forall with ∀. Or not. This draft PR is work-in-progress.
There was a problem hiding this comment.
Hm. I would prefer for all (and for each), but I won't block on this, especially if the overall WG prefers forall (and foreach).
| If two solutions are comptible, the merge of two solutions is the solution that maps variables of | ||
| each solution to the [=RDF term=] from one or other of the solutions. |
There was a problem hiding this comment.
| If two solutions are comptible, the merge of two solutions is the solution that maps variables of | |
| each solution to the [=RDF term=] from one or other of the solutions. | |
| If two solutions are compatible, the merge of two solutions is the solution that maps | |
| variables of each solution to the [=RDF term=] from one or other of the solutions. |
| <dd> | ||
| If two solutions are comptible, the merge of two solutions is the solution that maps variables of | ||
| each solution to the [=RDF term=] from one or other of the solutions. | ||
| (It is the union of solutions if defined as sets of pairs.) |
There was a problem hiding this comment.
| (It is the union of solutions if defined as sets of pairs.) | |
| (It is the union of solutions if they are defined as sets of pairs.) |
| Let [x/<var>μ</var>] be | ||
| if x is an RDF term, the [x/row] is x | ||
| if x is a variable then [x/row] is the value of x in the row | ||
| if x is a variable then [x/row] is <var>μ</var>(x) |
There was a problem hiding this comment.
| if x is a variable then [x/row] is <var>μ</var>(x) | |
| if x is a variable, then [x/row] is <var>μ</var>(x) |
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 |
|
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 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 |
|
This PR is titled "Define rule set evaluation". You have broken the work I have in-progress and made it hard to deal with @TallTed's suggestions. Please make a separate PR. |
|
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 |
|
Please remove your commit from this PR. |
|
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 |
|
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. |
|
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 |
This reverts commit 180c163.
|
PS. I think I managed, can't see anymore the text I've added before in the document rendered online here. |
Work to define rule set evaluation.