Mark Proctor | 7 Dec 2011 17:46

[rules-dev] Drools&jBPM at ICAART 4th International Conference on Agents and Artificial Intelligence

We have a tentative full day tutorial for Droosl & jBPM in Portugal, 
Algarve, in Febuary 6 - 8. I'm just waiting for internal confirmations, 
but I wanted to start getting prelimary communication out there.

http://www.icaart.org/tutorials.asp

Mark
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Mauricio Salatino | 7 Dec 2011 17:49
Picon
Gravatar

Re: [rules-dev] Drools&jBPM at ICAART 4th International Conference on Agents and Artificial Intelligence

WOW, that sounds great!
Let me know if I can help with something, I'm not sure how far away is
Esteban from there.. but we can start planning to assist :)
Cheers!

On Wed, Dec 7, 2011 at 1:46 PM, Mark Proctor <mproctor <at> codehaus.org> wrote:
> We have a tentative full day tutorial for Droosl & jBPM in Portugal,
> Algarve, in Febuary 6 - 8. I'm just waiting for internal confirmations,
> but I wanted to start getting prelimary communication out there.
>
> http://www.icaart.org/tutorials.asp
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

--

-- 
 - CTO  <at>  http://www.plugtree.com
 - MyJourney  <at>  http://salaboy.wordpress.com
 - Co-Founder  <at>  http://www.jugargentina.org
 - Co-Founder  <at>  http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
(Continue reading)

Mark Proctor | 8 Dec 2011 16:22

[rules-dev] Drools & jBPM at ICAART (Portugal) 4th International Conference on Agents and Artificial Intelligence

<http://4.bp.blogspot.com/-_b77C8kLxEk/TuDUJkn_TlI/AAAAAAAAAnY/_QPFAuMEdOo/s1600/icaart.png>
Droosl & jBPM  <at>  ICAART 2012 is now confirmed, and myself (Mark Proctor) 
and Dr Davide Sottara will be there. If you have any interesting 
research on or with Drools & jBPM that you would like to present on the 
day, let us konw.
6-8 Febuary 2012
Vilamoura, Algarve, Portugal
http://www.icaart.org/tutorials.asp

The day is a tutorial day aimed at all levels. It will start with 
general introductions to the technology but will slant off to more of 
our research based projects such as Drools Semantics and Chance, as it's 
part of an academic conference. We would also like to give an 
opportunity for the people to present their own research, slots can be 
anything from 20minutes to 60 - contact me if you are interested 
mproctor at codehaus d0t org.

There will also be plenty of time for discussions and help with your own 
projects.

*Abstract*

Drools is the leading open source, industry focused, rule engine. While 
Drools started life as a Rete based forward chaining engine, it has 
since transcended. It's ongoing mission is to explore declarative 
paradigms from a practical and industrial perspective, to boldly go 
where no engine has gone before.

The tutorial will start with a gentle introduction, suitable for all 
level of expertise, covering the core language and functionality slowly 
(Continue reading)

Mark Proctor | 8 Dec 2011 16:30
Picon
Favicon

[rules-dev] Drools & jBPM at ICAART (Portugal) 4th International Conference on Agents and Artificial Intelligence

Please help spread the word :)

<http://4.bp.blogspot.com/-_b77C8kLxEk/TuDUJkn_TlI/AAAAAAAAAnY/_QPFAuMEdOo/s1600/icaart.png>
Droosl & jBPM  <at>  ICAART 2012 is now confirmed, and myself (Mark Proctor) 
and Dr Davide Sottara will be there. If you have any interesting 
research on or with Drools & jBPM that you would like to present on the 
day, let us konw.
6-8 Febuary 2012
Vilamoura, Algarve, Portugal
http://www.icaart.org/tutorials.asp

The day is a tutorial day aimed at all levels. It will start with 
general introductions to the technology but will slant off to more of 
our research based projects such as Drools Semantics and Chance, as it's 
part of an academic conference. We would also like to give an 
opportunity for the people to present their own research, slots can be 
anything from 20minutes to 60 - contact me if you are interested 
mproctor at codehaus d0t org.

There will also be plenty of time for discussions and help with your own 
projects.

*Abstract*

Drools is the leading open source, industry focused, rule engine. While 
Drools started life as a Rete based forward chaining engine, it has 
since transcended. It's ongoing mission is to explore declarative 
paradigms from a practical and industrial perspective, to boldly go 
where no engine has gone before.

(Continue reading)

Geoffrey De Smet | 12 Dec 2011 17:08
Picon
Gravatar

[rules-dev] New module created: knowledge-internal-api

Hi guys,

At Mark's and Kris's request, I've created a new module 
knowledge-internal-api in droolsjbpm-knowledge.
This module will - in time - contain all the internal API between 
drools, jBPM and guvnor.

Advantages:

1) jBPM would no longer need to depend on drools-core.

2) It's clear that if you break backwards compatibility of the API in 
that module, that drools version X won't work with jbpm version X + 1 
(and vica versa).
Or put differently, if you change something in drools-core, you're safe 
(now you are not).

--

-- 
With kind regards,
Geoffrey De Smet

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Mark Proctor | 12 Dec 2011 23:28

Re: [rules-dev] [rules-users] Opportunistic Backward Chaining

On 12/12/2011 21:39, Maciej Gowin wrote:
I saw that there is an open issue for Opportunistic Backward Chaining:
https://issues.jboss.org/browse/JBRULES-3272

While I want to start working on this topic during my PhD thesis
my question is if there is any work done on this?
Is there any possibility to contribute in solving this issue?
Of course I know that there is already Prolog Style Query Based
Backward Chaining implemented.
Come onto irc to discuss:
http://www.jboss.org/drools/irc

As a quick summary drools supports unification and derivation queries, that work in the same way that you would expect from a prolog system. However in Drools those derivation trees can be fully materialised, like a materialized view in a database. What this means is that as the underlying ground terms change, the result set is updated to reflect that. So a query becomes a live view over a derivation tree.

This materilized tree almost gives us OBC, because each query + argument is materized on first request. The problem though is currently this derivation tree is unique to the caller. What we need to do is make any derivaition tree, query + arguments, available as a global cache. So when we go to execute a query, we first see if anyone else has, and if so we just re-use those results. If it doesn't exist in the global cache we execute the query, which results in it being cached. This same caching mechanism of query + arguments is used to stop infinite recursion, which is a problem solved by the "tabling algorithm".

I'm very close to a nieve implementation that effectively uses a hashmap as an ondemand cache of query results. The tabling algorithm actually recommends a tree instead, claiming better performance. I'll try and abstract the use of a hashmap so research in alternative "caching" algorithms can be tried out, to see which gives better performance.

Further work can look into a heurstic cache to evict unused query+argument results. When a query+arguments derivation tree is no longer used, we don't want to make it available for GC straight away, instead we should use some eviction queue that keeps around often requested query+argument derivation trees, but evicting older and not used often ones for GC. The heuristics would allow tuning of memory utilisation too, to stop the cache consuming all the memory.

I believe Davide has more he'd like to see built on this, for out of the box abductive reasoning. Btw this is probably more of a thread for the dev mailing list :)

Mark


_______________________________________________ rules-users mailing list rules-users <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Maciej Gowin | 13 Dec 2011 01:08
Picon

Re: [rules-dev] [rules-users] Opportunistic Backward Chaining

Mark, thanks for quick answer. I will try to ping you on irc tommorow while is getting late here in Poland.

2011/12/12 Mark Proctor <mproctor <at> codehaus.org>
On 12/12/2011 21:39, Maciej Gowin wrote:
I saw that there is an open issue for Opportunistic Backward Chaining:
https://issues.jboss.org/browse/JBRULES-3272

While I want to start working on this topic during my PhD thesis
my question is if there is any work done on this?
Is there any possibility to contribute in solving this issue?
Of course I know that there is already Prolog Style Query Based
Backward Chaining implemented.
Come onto irc to discuss:
http://www.jboss.org/drools/irc

As a quick summary drools supports unification and derivation queries, that work in the same way that you would expect from a prolog system. However in Drools those derivation trees can be fully materialised, like a materialized view in a database. What this means is that as the underlying ground terms change, the result set is updated to reflect that. So a query becomes a live view over a derivation tree.

This materilized tree almost gives us OBC, because each query + argument is materized on first request. The problem though is currently this derivation tree is unique to the caller. What we need to do is make any derivaition tree, query + arguments, available as a global cache. So when we go to execute a query, we first see if anyone else has, and if so we just re-use those results. If it doesn't exist in the global cache we execute the query, which results in it being cached. This same caching mechanism of query + arguments is used to stop infinite recursion, which is a problem solved by the "tabling algorithm".

I'm very close to a nieve implementation that effectively uses a hashmap as an ondemand cache of query results. The tabling algorithm actually recommends a tree instead, claiming better performance. I'll try and abstract the use of a hashmap so research in alternative "caching" algorithms can be tried out, to see which gives better performance.

Further work can look into a heurstic cache to evict unused query+argument results. When a query+arguments derivation tree is no longer used, we don't want to make it available for GC straight away, instead we should use some eviction queue that keeps around often requested query+argument derivation trees, but evicting older and not used often ones for GC. The heuristics would allow tuning of memory utilisation too, to stop the cache consuming all the memory.

I believe Davide has more he'd like to see built on this, for out of the box abductive reasoning. Btw this is probably more of a thread for the dev mailing list :)

Mark


_______________________________________________ rules-users mailing list rules-users <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Salaboy | 13 Dec 2011 02:34
Picon
Gravatar

Re: [rules-dev] New module created: knowledge-internal-api

Cool, I imagine that this project will be used to define a new API for all the modules right? Is this the
project that we should use for some of the experimental APIs? For a while I was pushing some changes in the
human tasks module interface, should I include those APIs here? 

Cheers

- CTO  <at>  http://www.plugtree.com
- MyJourney  <at>  http://salaboy.wordpress.com
- Co-Founder  <at>  http://www.jbug.com.ar
- Mauricio "Salaboy" Salatino -

On 12/12/2011, at 11:08, Geoffrey De Smet <ge0ffrey.spam <at> gmail.com> wrote:

> Hi guys,
> 
> At Mark's and Kris's request, I've created a new module 
> knowledge-internal-api in droolsjbpm-knowledge.
> This module will - in time - contain all the internal API between 
> drools, jBPM and guvnor.
> 
> Advantages:
> 
> 1) jBPM would no longer need to depend on drools-core.
> 
> 2) It's clear that if you break backwards compatibility of the API in 
> that module, that drools version X won't work with jbpm version X + 1 
> (and vica versa).
> Or put differently, if you change something in drools-core, you're safe 
> (now you are not).
> 
> -- 
> With kind regards,
> Geoffrey De Smet
> 
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Mark Proctor | 13 Dec 2011 09:15

Re: [rules-dev] New module created: knowledge-internal-api

On 13/12/2011 01:34, Salaboy wrote:
> Cool, I imagine that this project will be used to define a new API for all the modules right? Is this the
project that we should use for some of the experimental APIs? For a while I was pushing some changes in the
human tasks module interface, should I include those APIs here?
Abosolutely. Like knowledge-api the javadocs for this will be published 
and available to the user, we can document the apis there in the manual. 
However unlike knowledge-api everythig in internal-api is considered 
subject to change, there is no guarantee we won't change them. So it's a 
great "staging" ground for experimental apis that we want users to play 
with for a while, but we don't want to lock down quite yet, atleast not 
until we decide it's ready to go to knowledge-api.

Mark
>
> Cheers
>
> - CTO  <at>  http://www.plugtree.com
> - MyJourney  <at>  http://salaboy.wordpress.com
> - Co-Founder  <at>  http://www.jbug.com.ar
> - Mauricio "Salaboy" Salatino -
>
> On 12/12/2011, at 11:08, Geoffrey De Smet<ge0ffrey.spam <at> gmail.com>  wrote:
>
>> Hi guys,
>>
>> At Mark's and Kris's request, I've created a new module
>> knowledge-internal-api in droolsjbpm-knowledge.
>> This module will - in time - contain all the internal API between
>> drools, jBPM and guvnor.
>>
>> Advantages:
>>
>> 1) jBPM would no longer need to depend on drools-core.
>>
>> 2) It's clear that if you break backwards compatibility of the API in
>> that module, that drools version X won't work with jbpm version X + 1
>> (and vica versa).
>> Or put differently, if you change something in drools-core, you're safe
>> (now you are not).
>>
>> --
>> With kind regards,
>> Geoffrey De Smet
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Esteban Aliverti | 13 Dec 2011 09:34
Picon
Gravatar

Re: [rules-dev] New module created: knowledge-internal-api

Brace yourself, more magical casts are coming :)


I like the idea of have a well documented and stable api like knowledge-api. I have some doubts though:
What is going to be the initial state of internal-api? 
I see it has some utility classes now, but what is the idea? To start from a copy of knowledge-api?
Is knowledge-api going to be independent of drools-core? 
 
Best Regards,

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Esteban Aliverti
- Developer <at> http://www.plugtree.com
- Blog <at> http://ilesteban.wordpress.com


On Tue, Dec 13, 2011 at 9:15 AM, Mark Proctor <mproctor <at> codehaus.org> wrote:
On 13/12/2011 01:34, Salaboy wrote:
> Cool, I imagine that this project will be used to define a new API for all the modules right? Is this the project that we should use for some of the experimental APIs? For a while I was pushing some changes in the human tasks module interface, should I include those APIs here?
Abosolutely. Like knowledge-api the javadocs for this will be published
and available to the user, we can document the apis there in the manual.
However unlike knowledge-api everythig in internal-api is considered
subject to change, there is no guarantee we won't change them. So it's a
great "staging" ground for experimental apis that we want users to play
with for a while, but we don't want to lock down quite yet, atleast not
until we decide it's ready to go to knowledge-api.

Mark
>
> Cheers
>
> - CTO <at> http://www.plugtree.com
> - MyJourney <at> http://salaboy.wordpress.com
> - Co-Founder <at> http://www.jbug.com.ar
> - Mauricio "Salaboy" Salatino -
>
> On 12/12/2011, at 11:08, Geoffrey De Smet<ge0ffrey.spam <at> gmail.com>  wrote:
>
>> Hi guys,
>>
>> At Mark's and Kris's request, I've created a new module
>> knowledge-internal-api in droolsjbpm-knowledge.
>> This module will - in time - contain all the internal API between
>> drools, jBPM and guvnor.
>>
>> Advantages:
>>
>> 1) jBPM would no longer need to depend on drools-core.
>>
>> 2) It's clear that if you break backwards compatibility of the API in
>> that module, that drools version X won't work with jbpm version X + 1
>> (and vica versa).
>> Or put differently, if you change something in drools-core, you're safe
>> (now you are not).
>>
>> --
>> With kind regards,
>> Geoffrey De Smet
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Gmane