On 15/03/2019 2:27 am, Marco Neumann wrote:
Thank you for the clarification Holger. It's what I was looking for and it
will help me to scope my future application of SHACL in my RDF / SPARQL
pipelines. since you mentioned that it lacks support for Jena on a graph
level, that means it doesn't have direct access to in-memory and persistent
storage in Jena?
What I wrote earlier was ambiguous, and the SHACL API certainly does
operate directly on the Jena Graphs. What I meant however was that my
implementation doesn't hook into InfGraph and related mechanisms as
described in
https://jena.apache.org/documentation/inference/
Holger
On Wed, Mar 13, 2019 at 11:28 PM Holger Knublauch <hol...@topquadrant.com>
wrote:
My impression is that the audience for "rules" is quite diverse, and
different tasks require different solutions. This summary of the recent
W3C workshop
http://wiki.ruleml.org/index.php/W3C_Workshop_on_Web_Standardization_for_Graph_Data:_Rules_and_Reasoning
enumerates some kinds of rules. From the part of the community that I am
involved in, I can comment on SPIN and SHACL.
There is clear evidence that SPARQL CONSTRUCT queries are practically
useful, in particular for data transformation tasks (from one graph to
another). SPARQL offers enormous flexibility, a large number of
implementations, functions, graph matching etc. Many people seem to
simply collect SPARQL queries in a text file or program and run them one
by one, in a single simple loop. SPIN is and was used as an RDF syntax
to link SPARQL CONSTRUCT queries to class definitions. This offers a way
to exchange those rule definitions in a standard form and provides a
relatively natural style of organizing rules that would otherwise be a
flat list. By scoping rules to classes, SPIN also introduced a
mechanisms for implementations to choose which rules apply to a given
instance. SPIN was used as input to SHACL at W3C.
The SHACL-SPARQL rules generalized SPIN a bit further, by attaching
rules not only to classes but to shapes. And shapes introduce the notion
of target nodes, e.g. making it possible to state that a certain rule
shall only apply to all subjects of a certain predicate
(sh:targetSubjectsOf). In contrast to SPIN, SHACL is also a W3C
standard. The SHACL-AF document that defines the rules does not have the
same W3C status as the main SHACL spec, it's a Working Group Note
(https://www.w3.org/TR/shacl-af/). This was in part because the Data
Shapes WG was not chartered to even work on this topic even though many
members of the WG were interested in the topic. There is ongoing work on
the SHACL-AF spec (currently mostly driven by myself), with the latest
draft at
https://w3c.github.io/shacl/shacl-af/
In addition to SPARQL CONSTRUCTs, SHACL also introduces a different type
of rules based on a less expressive yet more declarative syntax,
so-called Node Expressions. Rules based on these node expressions can be
attached to shapes too, and either wrapped into so-called TripleRules or
(in the newer editions) Property Value Rules. The latter are explained in
https://www.topquadrant.com/graphql/values.html
Property value rules are attached to property shape declarations, and
can therefore be computed whenever a property is needed, e.g. to display
on a form. They offer a basic kind of backward chaining. For example, if
one rule computes "age" from date of birth, then another rule can
compute "isAdult" from "age", with "age" being computed on the fly.
As pointed out earlier, there is an open source implementation of these
rules for Jena at
https://github.com/TopQuadrant/shacl
The rule engine there does not link to Jena on a Graph level, but
requires external triggers to produce inferred triples. However,
property value rules can be computed on the fly as part of SPARQL
queries. None of this implements an ambitious RETE engine or so, but
rather simple algorithms. But even these simple algorithms seem to have
plenty of use cases, and many people argue that the logical complexity
of some rule languages is not really needed for their needs.
Any feedback, bug reports and feature requests are welcome. Moving
forward, I would strongly encourage anyone with interest in these SHACL
rules to help with the process of turning them into a more stable W3C
standard, potentially a W3C recommendation. That work would continue in
the SHACL Community Group for now, so use that mailing list at
https://www.w3.org/community/shacl/
HTH
Holger
On 13/03/2019 8:49 pm, Marco Neumann wrote:
correct if me if I am wrong but from my vantage point I seem to notice
a silent consensus in the RDF community to go from SPIN rules to SHACL
which now comes with its own SHACL rule engine [1].
The new SHACL efforts are mostly guided by TopQuadrant and a change
from the initial layered approach to go with SPARQL RDF
(SPIN+(SHACL-rules)). So I presume the current game plan is that SHACL
will "rule" them all in the end.
If so it would be nice to have a feature list for SHACL rules. And
does this mean it will be rules without validation and just CONSTRUCT
queries or are the rule semantic restrictions build into SHACL? I am
sure this will work fine for many use cases we have but since we are
starting to blur the lines between rules/reasoner/sparql would be nice
to have some general autoritative clarification here.
[1]
https://github.com/TopQuadrant/shacl/blob/master/src/main/java/org/topbraid/shacl/rules/RuleEngine.java
On Wed, Mar 13, 2019 at 10:14 AM Dave Reynolds
<dave.e.reyno...@gmail.com> wrote:
Hi Marco,
Sorry, I'm not aware of other rule engines having been wired to Jena
but
that doesn't mean it hasn't been done. In particular I'm surprised
there's not a drools-for-jena project somewhere. People have certainly
experimented with that, even written papers comparing performance [1],
but I'm not aware of any supported tooling.
Dave
[1] https://ieeexplore.ieee.org/document/7516153
On 12/03/2019 22:18, Marco Neumann wrote:
so what's your current recommendation for a superior third party rules
reasoner that works efficiently with the jena tooling? free &
commercial
option welcome
Marco
On Mon 14. Jan 2019 at 19:16, Dave Reynolds <dave.e.reyno...@gmail.com
wrote:
Hi Barry,
[Agreed that dev is probably the better place to discuss this.]
The two engines in jena are indeed loosely styled on RETE and on
tabled
datalog. However, I wouldn't claim they were particularly complete or
good implementations of either. So while looking at some of the
source
literature that inspired them might be helpful don't expect very
much of
what's covered in the literature to be present in the code.
For RETE then the wikipedia article [1] is a good summary and source
of
starting references. I had a copy of the original Forgy paper [1](ref
1), among others,when I was doing the work. There has been a *lot* of
work on improvements to RETE since the 80s and while there were times
when we might have done a new forward engine using more modern
techniques it never happened.
For the backward engine the approach is a variant of SLG-WAM as used
for
XSB but highly highly simplified since we can't express general
tuples
or recursive data structures within jena's triples. A few google
searches haven't turned up the exact paper that originally inspired
the
approach. The closest I've found are [2] and [3], which probably
cover
the same ground.
Let me reinforce that the Jena engines are really simplified. They
were
enough to get the job done at the time (over a decade ago now) and
have
proved useful for some people since but I wouldn't want to defend
any of
the implementation choices.
Dave
[1] https://en.wikipedia.org/wiki/Rete_algorithm
[2]
https://pdfs.semanticscholar.org/2078/96964ee85f983cd861a4f8c5dff0bfc9f03e.pdf
[3]
https://pdfs.semanticscholar.org/6c6d/26e8fe1b755140ffcb57025b021a046b2a3b.pdf
On 14/01/2019 16:33, ajs6f wrote:
I have no useful general information about the reasoning framework,
but
I am copying this over to dev@. Discussions of how to extend Jena
definitely have a place there.
ajs6f
On Jan 14, 2019, at 6:40 AM, Nouwt, B. (Barry)
<barry.no...@tno.nl.INVALID> wrote:
Hi all, I want to investigate the inner workings of the
GenericRuleReasoner (with the purpose of extending it in the
future). In
Jena's documentation I read:
"Jena includes a general purpose rule-based reasoner which is used
to
implement both the RDFS and OWL reasoners but is also available for
general
use. This reasoner supports rule-based inference over RDF graphs and
provides forward chaining, backward chaining and a hybrid execution
model.
To be more exact, there are two internal rule engines one forward
chaining
RETE engine and one tabled datalog engine - they can be run
separately or
the forward engine can be used to prime the backward engine which in
turn
will be used to answer queries."
source: https://jena.apache.org/documentation/inference/#rules
Apart from Jena's documentation, Jena's mailing lists and its
source
code, are there any resources that can better help me grasp what is
happening inside the generic rule reasoner? For example, the text
above
mentions the forward chaining RETE engine and the tabled datalog
engine,
are there any scientific papers that I might read to better
understand
their inner workings?
Maybe this question is better suited for the d...@jena.apache.org
<mailto:d...@jena.apache.org>?
Regards, Barry
This message may contain information that is not intended for you.
If
you are not the addressee or if this message was sent to you by
mistake,
you are requested to inform the sender and delete the message. TNO
accepts
no liability for the content of this e-mail, for the manner in which
you
use it and for damage of any kind resulting from the risks inherent
to the
electronic transmission of messages.
--
---
Marco Neumann
KONA
--
---
Marco Neumann
KONA
