Use case: Datalog rules

[kvistgaard]

Currently, SHACL AF supports SPARQL rules but not Datalog rules. Unlike SPARQL, Datalog rules support complex recursion and logical reasoning.

To my knowledge, none of the currently available solutions for executing Datalog rules on RDF offers a way to have the rules in an RDF graph. SHACL can support that in a standard way, plus execution order and metadata for rules.

[VladimirAlexiev]

Hi Ivo! @kvistgaard

N3Logic is a superset of datalog and Turtle and (I think) Trig.
It captures premises and conclusions in anonymous named graphs (ok, that's an oxymoron) denoted by brackets, and connects them with => (shortcut for log:implies).
There is also a variant in pure Trig.
It is the foundation of the venerable Cwm, and modern reasoners like Eye.

[afs]

See #295 for some thoughts.

Having an RDF form for (SHACL) rules is, I think, a given.

Defining rule sets requires the ability to determine dependency relationships (e.g. stratification). Requiring that to be explicitly declared would be burdensome, and flawed, if rule sets are seen as libraries to be chosen and combined by the user application.

Currently, the working group is in "phase 1", focusing on updating SHACL Core and SHACL SPARQL, and scoping out Node Expressions (NE). Completing NE is "phase 2". All other work is "phase 2" (SHACL-UI, SHACL Profiles, SHACL Compact Syntax, SHACL Rules).

Another given is that Node Expressions are expected to be used by SHACL Rules.

[veleda]

Having Datalog rules in a standard will also provide increased use of the technology, and build upon a wish by many--moving logic and rules out of "black-box" applications.

There are several vendors building support for Datalog rules in addition to both SHACL validation and (full) OWL reasoning. By standardising this, one would ensure a consistent way for the Datalog support on semantic technologies. Repercussions from that will be more seamless data/rule flows and increased interoperability for rules.

[magbak]

See #295 for some thoughts.

Having an RDF form for (SHACL) rules is, I think, a given.

Defining rule sets requires the ability to determine dependency relationships (e.g. stratification). Requiring that to be explicitly declared would be burdensome, and flawed, if rule sets are seen as libraries to be chosen and combined by the user application.

Currently, the working group is in "phase 1", focusing on updating SHACL Core and SHACL SPARQL, and scoping out Node Expressions (NE). Completing NE is "phase 2". All other work is "phase 2" (SHACL-UI, SHACL Profiles, SHACL Compact Syntax, SHACL Rules).

Another given is that Node Expressions are expected to be used by SHACL Rules.

Is it possible to think of ruleset evaluation as atomic / serializable? So that all of the consequences of the rules appear all at once, ordered before or after other rules? Then stratification becomes an internal matter for the Datalog implementation, and the ordering issues referenced in #295 do not affect Datalog rules differently than SPARQL rules. Or am I missing something?

[afs]

Is it possible to think of ruleset evaluation as atomic / serializable?

For the overall effect of running a ruleset, yes, we would define the outcome as atomic.

Either producing a graph of new triples (or a stream) , and whether they get merged into the data graph is an application decision, or putting back triples into the data graph progressively as long as it is isolated (e.g. a transaction).

Stratification would indeed be internal to how the rules are evaluated.

We will have to make sure information is available to the datalog engine to calculate dependencies.

Or am I missing something?

No, I don't think so.

[kvistgaard]

@VladimirAlexiev , I like N3 rules (and the more recent surfaces spec), but sadly, unlike SHACL, there aren't many tools supporting N3 reasoning. It seems Kauffman was right: we can only advance through the adjacent possible.

[kvistgaard]

To my knowledge, there is no standard specification for Datalog. If we consider what is common as the de facto standard, then the missing aggregates is a limitation.

Syntax-wise, I find Datomic flavour the most concise.