jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Knublauch <>
Subject Re: [GenericRuleReasoner] inner workings
Date Thu, 14 Mar 2019 22:25:44 GMT

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


> On Wed, Mar 13, 2019 at 11:28 PM Holger Knublauch <>
> 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
>> 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
>> ( 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
>> 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
>> 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
>> 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
>> 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]
>>> On Wed, Mar 13, 2019 at 10:14 AM Dave Reynolds
>>> <> 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]
>>>> 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 <
>>>>> 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
>>>>>> 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*
>>>>>> 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]
>>>>>> [2]
>>>>>> [3]
>>>>>> 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)
>>>>>> <> 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
>>>>>> 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
> turn
>>>>>> will be used to answer queries."
>>>>>>>> source:
>>>>>>>> Apart from Jena's documentation, Jena's mailing lists and
> source
>>>>>> code, are there any resources that can better help me grasp what
>>>>>> 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
>>>>>> <>?
>>>>>>>> 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

View raw message