jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Neumann <marco.neum...@gmail.com>
Subject Re: [GenericRuleReasoner] inner workings
Date Thu, 14 Mar 2019 16:27:52 GMT
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?


On Wed, Mar 13, 2019 at 11:28 PM Holger Knublauch <holger@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.reynolds@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.reynolds@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.nouwt@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 dev@jena.apache.org
> >>>> <mailto:dev@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
-- 


---
Marco Neumann
KONA

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message