You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by ajs6f <aj...@apache.org> on 2019/01/14 16:33:57 UTC
Re: [GenericRuleReasoner] inner workings
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) <ba...@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<ma...@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.
Re: [GenericRuleReasoner] inner workings
Posted by Adrian Walker <ad...@gmail.com>.
Hi All,
Correcting a link.... This one
www.executable-english.com/demo_agents/RDFQu eryLangComparison1.agent
<http://www.executable-english.com/demo_agents/RDFQueryLangComparison1.agent>
should of course be
www.executable-english.com/demo_agents/RDFQueryLangComparison1.agent
Based on comments so far, this one may also be useful
www.executable-english.com/A_Wiki_for_Business_Rules_in_Open_Vocabulary_Executable_English.pdf
Cheers, -- Adrian
On Wed, Mar 13, 2019 at 11:50 AM Adrian Walker <ad...@gmail.com>
wrote:
> Hi Lorenz &All,
>
> *Marco*'s original question was
>
>
> *what's your current recommendation for a superior third party rules
> reasoner that works efficiently with the jena tooling? free & commercial
> option welcome *
> Lorenz B. wrote:
>
>
> *The code [1] just indicates to use some online service - so a user has
> to register and, as far as I can see, has to pay US $100 per month. And you
> need the data as SQL database? Or can it process RDF directly?*
>
> Actually, the user does not have to register with the reasoner endpoint,
> either from a Java client, or from a browser in shared mode. Registration
> is
> only for a more private way of using the system.
>
> Small examples run without the need for for a SQL database. For larger
> examples the
> system automatically generates and runs SQL queries "under the covers".
> The SQL generator could in principle be modified to emit SPARQL queries.
>
> Here's a simple example of querying RDF [2].
>
> HTH, -- Adrian
>
>
> [1] www.executable-english.com/iblClient1.java
> <http://www.executable-english.com/iblClient1.java>
>
> [2] www.executable-english.com/demo_agents/RDFQu eryLangComparison1.agent
>
> <http://www.executable-english.com/demo_agents/RDFQueryLangComparison1.agent>
>
>
>
> On Wed, Mar 13, 2019 at 1:39 AM Lorenz B. <
> buehmann@informatik.uni-leipzig.de> wrote:
>
>> I don't see how this link to some code example to some whatever online
>> service answers his question...can you explain this please a bit more?
>>
>> I mean, if I understood correctly, Marco was asking for some rule engine
>> that can be combined with Apache Jena. So, I'd expect something like
>> Drools engine with a Jena adapter or the like. And ideally I guess a
>> standalone, open source, free to use tool.
>>
>> I read through your research paper but couldn't figure out what the
>> underlying rule engine is based on nor could I see any benchmarks w.r.t.
>> performance.
>> Moreover, the code just indicates to use some online service - so a user
>> has to register and, as far as I can see, has to pay US $100 per month.
>> And you need the data as SQL database? Or can it process RDF directly?
>>
>> Sorry for my questions, it's just because I've never heard about this
>> tool before. And I'm a bit confused how it works on RDF data.
>>
>>
>> > Marco,
>> >
>> > This might be of interest:
>> >
>> > www.executable-english.com/iblClient1.java
>> >
>> > HTH, -- Adrian
>> >
>> > On Tue, Mar 12, 2019 at 3:18 PM Marco Neumann <ma...@gmail.com>
>> > 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)
>> >>> <ba...@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
>> >>> <ma...@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
>> >>
>> --
>> Lorenz Bühmann
>> AKSW group, University of Leipzig
>> Group: http://aksw.org - semantic web research center
>>
>>
Re: [GenericRuleReasoner] inner workings
Posted by Adrian Walker <ad...@gmail.com>.
Hi Lorenz &All,
*Marco*'s original question was
*what's your current recommendation for a superior third party rules
reasoner that works efficiently with the jena tooling? free & commercial
option welcome *
Lorenz B. wrote:
*The code [1] just indicates to use some online service - so a user has to
register and, as far as I can see, has to pay US $100 per month. And you
need the data as SQL database? Or can it process RDF directly?*
Actually, the user does not have to register with the reasoner endpoint,
either from a Java client, or from a browser in shared mode. Registration
is
only for a more private way of using the system.
Small examples run without the need for for a SQL database. For larger
examples the
system automatically generates and runs SQL queries "under the covers".
The SQL generator could in principle be modified to emit SPARQL queries.
Here's a simple example of querying RDF [2].
HTH, -- Adrian
[1] www.executable-english.com/iblClient1.java
<http://www.executable-english.com/iblClient1.java>
[2] www.executable-english.com/demo_agents/RDFQu eryLangComparison1.agent
<http://www.executable-english.com/demo_agents/RDFQueryLangComparison1.agent>
On Wed, Mar 13, 2019 at 1:39 AM Lorenz B. <
buehmann@informatik.uni-leipzig.de> wrote:
> I don't see how this link to some code example to some whatever online
> service answers his question...can you explain this please a bit more?
>
> I mean, if I understood correctly, Marco was asking for some rule engine
> that can be combined with Apache Jena. So, I'd expect something like
> Drools engine with a Jena adapter or the like. And ideally I guess a
> standalone, open source, free to use tool.
>
> I read through your research paper but couldn't figure out what the
> underlying rule engine is based on nor could I see any benchmarks w.r.t.
> performance.
> Moreover, the code just indicates to use some online service - so a user
> has to register and, as far as I can see, has to pay US $100 per month.
> And you need the data as SQL database? Or can it process RDF directly?
>
> Sorry for my questions, it's just because I've never heard about this
> tool before. And I'm a bit confused how it works on RDF data.
>
>
> > Marco,
> >
> > This might be of interest:
> >
> > www.executable-english.com/iblClient1.java
> >
> > HTH, -- Adrian
> >
> > On Tue, Mar 12, 2019 at 3:18 PM Marco Neumann <ma...@gmail.com>
> > 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 <da...@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)
> >>> <ba...@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
> >>> <ma...@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
> >>
> --
> Lorenz Bühmann
> AKSW group, University of Leipzig
> Group: http://aksw.org - semantic web research center
>
>
Re: [GenericRuleReasoner] inner workings
Posted by Marco Neumann <ma...@gmail.com>.
Thank you for the attempt to further clarify Adrians "contribution"
here Lorenz. I did send a reply unintentionally directly to Adrian
yesterday omitting the list.
So here I go again:
Thank You Adrian,
I was thinking more along the lines of an updated version of a list
for Jena like
https://www.w3.org/2005/rules/wg/wiki/List_of_Rule_Systems
or
https://www.w3.org/2001/sw/wiki/Category:Rule_Reasoner
over the years they seem to have constantly ignored you and IBL in the
reports. wonder why ... is it a hosted system only?
On Wed, Mar 13, 2019 at 8:39 AM Lorenz B.
<bu...@informatik.uni-leipzig.de> wrote:
>
> I don't see how this link to some code example to some whatever online
> service answers his question...can you explain this please a bit more?
>
> I mean, if I understood correctly, Marco was asking for some rule engine
> that can be combined with Apache Jena. So, I'd expect something like
> Drools engine with a Jena adapter or the like. And ideally I guess a
> standalone, open source, free to use tool.
>
> I read through your research paper but couldn't figure out what the
> underlying rule engine is based on nor could I see any benchmarks w.r.t.
> performance.
> Moreover, the code just indicates to use some online service - so a user
> has to register and, as far as I can see, has to pay US $100 per month.
> And you need the data as SQL database? Or can it process RDF directly?
>
> Sorry for my questions, it's just because I've never heard about this
> tool before. And I'm a bit confused how it works on RDF data.
>
>
> > Marco,
> >
> > This might be of interest:
> >
> > www.executable-english.com/iblClient1.java
> >
> > HTH, -- Adrian
> >
> > On Tue, Mar 12, 2019 at 3:18 PM Marco Neumann <ma...@gmail.com>
> > 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 <da...@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)
> >>> <ba...@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
> >>> <ma...@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
> >>
> --
> Lorenz Bühmann
> AKSW group, University of Leipzig
> Group: http://aksw.org - semantic web research center
>
--
---
Marco Neumann
KONA
Re: [GenericRuleReasoner] inner workings
Posted by "Lorenz B." <bu...@informatik.uni-leipzig.de>.
I don't see how this link to some code example to some whatever online
service answers his question...can you explain this please a bit more?
I mean, if I understood correctly, Marco was asking for some rule engine
that can be combined with Apache Jena. So, I'd expect something like
Drools engine with a Jena adapter or the like. And ideally I guess a
standalone, open source, free to use tool.
I read through your research paper but couldn't figure out what the
underlying rule engine is based on nor could I see any benchmarks w.r.t.
performance.
Moreover, the code just indicates to use some online service - so a user
has to register and, as far as I can see, has to pay US $100 per month.
And you need the data as SQL database? Or can it process RDF directly?
Sorry for my questions, it's just because I've never heard about this
tool before. And I'm a bit confused how it works on RDF data.
> Marco,
>
> This might be of interest:
>
> www.executable-english.com/iblClient1.java
>
> HTH, -- Adrian
>
> On Tue, Mar 12, 2019 at 3:18 PM Marco Neumann <ma...@gmail.com>
> 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 <da...@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)
>>> <ba...@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
>>> <ma...@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
>>
--
Lorenz Bühmann
AKSW group, University of Leipzig
Group: http://aksw.org - semantic web research center
Re: [GenericRuleReasoner] inner workings
Posted by Adrian Walker <ad...@gmail.com>.
Marco,
This might be of interest:
www.executable-english.com/iblClient1.java
HTH, -- Adrian
On Tue, Mar 12, 2019 at 3:18 PM Marco Neumann <ma...@gmail.com>
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 <da...@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)
> > <ba...@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
> > <ma...@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
>
Re: [GenericRuleReasoner] inner workings
Posted by Holger Knublauch <ho...@topquadrant.com>.
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 <ho...@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
>>> <da...@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)
>>>>>> <ba...@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
>>>>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Marco Neumann <ma...@gmail.com>.
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 <ho...@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
> > <da...@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)
> >>>> <ba...@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
> >>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Holger Knublauch <ho...@topquadrant.com>.
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
> <da...@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 <da...@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)
>>>> <ba...@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
>>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Marco Neumann <ma...@gmail.com>.
in any event good to have your view on this as a "consensus"
On Wed, Mar 13, 2019 at 11:11 AM Dave Reynolds
<da...@gmail.com> wrote:
>
> Hi Marco,
>
> Not a "consensus" that I'm part of so not something I could comment on.
>
> Dave
>
> On 13/03/2019 10:49, 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
> > <da...@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 <da...@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)
> >>>> <ba...@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
> >>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Marco Neumann <ma...@gmail.com>.
that was my question indeed, I wasn't sure if they are shared or not. thanks
On Wed, Mar 13, 2019 at 11:26 AM ajs6f <aj...@apache.org> wrote:
>
> I'm not sure what you mean by "editors" or "the dev group", but I am one person. Apache committer email addresses are not shared.
>
>
> ajs6f
>
> > On Mar 13, 2019, at 7:23 AM, Marco Neumann <ma...@gmail.com> wrote:
> >
> > just for reference is the email "ajs6f@apache.org" always one person
> > or is it used by a number of different editors in the dev group?
> >
> >
> >
> >
> > On Wed, Mar 13, 2019 at 11:15 AM ajs6f <aj...@apache.org> wrote:
> >>
> >> I'm not at all sure where the idea of a "silent consensus" came from. Certainly there _is_ interest in SHACL (as there should be), but that's all I can see.
> >>
> >> ajs6f
> >>
> >>> On Mar 13, 2019, at 7:10 AM, Dave Reynolds <da...@gmail.com> wrote:
> >>>
> >>> Hi Marco,
> >>>
> >>> Not a "consensus" that I'm part of so not something I could comment on.
> >>>
> >>> Dave
> >>>
> >>> On 13/03/2019 10:49, 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
> >>>> <da...@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 <da...@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)
> >>>>>>> <ba...@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
> >>>>>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by ajs6f <aj...@apache.org>.
I'm not sure what you mean by "editors" or "the dev group", but I am one person. Apache committer email addresses are not shared.
ajs6f
> On Mar 13, 2019, at 7:23 AM, Marco Neumann <ma...@gmail.com> wrote:
>
> just for reference is the email "ajs6f@apache.org" always one person
> or is it used by a number of different editors in the dev group?
>
>
>
>
> On Wed, Mar 13, 2019 at 11:15 AM ajs6f <aj...@apache.org> wrote:
>>
>> I'm not at all sure where the idea of a "silent consensus" came from. Certainly there _is_ interest in SHACL (as there should be), but that's all I can see.
>>
>> ajs6f
>>
>>> On Mar 13, 2019, at 7:10 AM, Dave Reynolds <da...@gmail.com> wrote:
>>>
>>> Hi Marco,
>>>
>>> Not a "consensus" that I'm part of so not something I could comment on.
>>>
>>> Dave
>>>
>>> On 13/03/2019 10:49, 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
>>>> <da...@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 <da...@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)
>>>>>>> <ba...@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
>>>>>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Marco Neumann <ma...@gmail.com>.
just for reference is the email "ajs6f@apache.org" always one person
or is it used by a number of different editors in the dev group?
On Wed, Mar 13, 2019 at 11:15 AM ajs6f <aj...@apache.org> wrote:
>
> I'm not at all sure where the idea of a "silent consensus" came from. Certainly there _is_ interest in SHACL (as there should be), but that's all I can see.
>
> ajs6f
>
> > On Mar 13, 2019, at 7:10 AM, Dave Reynolds <da...@gmail.com> wrote:
> >
> > Hi Marco,
> >
> > Not a "consensus" that I'm part of so not something I could comment on.
> >
> > Dave
> >
> > On 13/03/2019 10:49, 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
> >> <da...@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 <da...@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)
> >>>>> <ba...@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
> >>>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by ajs6f <aj...@apache.org>.
I'm not at all sure where the idea of a "silent consensus" came from. Certainly there _is_ interest in SHACL (as there should be), but that's all I can see.
ajs6f
> On Mar 13, 2019, at 7:10 AM, Dave Reynolds <da...@gmail.com> wrote:
>
> Hi Marco,
>
> Not a "consensus" that I'm part of so not something I could comment on.
>
> Dave
>
> On 13/03/2019 10:49, 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
>> <da...@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 <da...@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)
>>>>> <ba...@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
>>>>> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Dave Reynolds <da...@gmail.com>.
Hi Marco,
Not a "consensus" that I'm part of so not something I could comment on.
Dave
On 13/03/2019 10:49, 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
> <da...@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 <da...@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)
>>>> <ba...@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
>>>> <ma...@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
>
Re: [GenericRuleReasoner] inner workings
Posted by Marco Neumann <ma...@gmail.com>.
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
<da...@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 <da...@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)
> >> <ba...@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
> >> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Dave Reynolds <da...@gmail.com>.
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 <da...@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)
>> <ba...@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
>> <ma...@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.
>>>
>>
Re: [GenericRuleReasoner] inner workings
Posted by Marco Neumann <ma...@gmail.com>.
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 <da...@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)
> <ba...@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
> <ma...@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
Re: [GenericRuleReasoner] inner workings
Posted by Dave Reynolds <da...@gmail.com>.
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) <ba...@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<ma...@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.
>