[rules-dev] Runtime fact-set and rule-set separation

[Mark Proctor]

sigh... these are getting more numerous :(

This is a question for the user mailing list, you want to know how to 
"use" drools, you are not asking on how to develope drools itself.

Please read this thoroughly:
http://www.jboss.org/drools/lists.html

Mark

Tomasz Krzywicki wrote:
> I am looking for some lightweight solution of fact sets separation
> withing single working memory. ... I am possibly messing up with
> terminology therefore please let me present an example.
>
> I have set of facts
>
> "Set 1" contains:
>  - Fact ( name==A, property==1)
>  - Fact ( name==B, property==2)
>
> "Set 2" contains:
>  - Fact ( name==A, property==1)
>  - Fact ( name==C, property==2)
>
>
> - I would like to execute my dedicated package of rules for
>  instance of "Set 1" within single working memory.
>
> - When "Set 1" is inserted ( instantiated ) twice or more into the
>  working memory I would like to separate the scope of rules to
>  this particular instance
>
> - I would like to insert "Set 2" at the same time multiple times
>  and execute separate set of rules dedicated for "Set 2" separately
>  on each of inserted instance of "Set 2"
>
> - In some cases I would like to have access to facts from other
>  instances of different sets within same working memory. eg.:
>
>  - rule associated to "Set 1" checks all the occurrences of
>    Fact( name == A ) - means it could read state of Fact
>    from other instances of "Set 1" and "Set 2"
>  - rule associated to "Set 1" checks state of fact associated
>    to Fact ( name == A ) from "Set 2"
>
> I could do it currently by
>  - adding extra fact indicating instance to working memory
>  - adding property to my Fact indicating origin ( instance in this case )
>  - altering each rule.
>
> Example: reaching facts in particular instance
>  ...
>  when:
>     Instance ( instanceId: id, name == "Set 1")
>     Fact ( ... , origin == instanceId )
>     ...
>  then
>  ( ... )
>
> Example: reaching fact in multiple instances
>  ...
>  when:
>    Fact (...)
>  ...
>  then
>
>
> Idea behind is very prosaic. Majority of the rules are written
> in my case with single instance context in mind. Only sometimes
> there is a need to look out of the "hedge".
> So my example requires more typing and better specification
> for *modeler* ( name of the role in my org - means person who
> writes the rules ) who is using simpler single *model*
> ( set of rules + set of facts ).
>
> I am trying to implement this using multiple, chained working
> memories but maintenance of graph of working memories does
> not look very practical for longer term and its not working
> perfectly.
>
> How could it be implemented - high level of course
> Or better ... How I would like to use it :)
>
> RuleBase ruleBase = RuleBaseFactory.newRuleBase();
> ruleBase.addPackage ( "Set1" , MyPackageForSet1 );
> // 1st argument is context name, 2nd compiled rule package
>
> WorkingMemory wm = ruleBase.newStatefulSession();
> wm.insertInContext ( "Set1", new Fact (A,1) ) // this could be also
> solved by implementing interface on the fact
> // inserting instance and context pointer after fact creation
> // and then inserting it to wm regular way.
>
> than if there would be a need to reach fact from other
> contexts I would specify it using something-like-this syntax
>
> ...
> when
>   Fact ( ... )     // facts within same context and instance
>   *.Fact ( ... )   // facts from all facts sets (contexts)
>   <ContextName>.Fact ( ... )   // facts from all
>                                // instances of specific context.
>   <ContextName>(*).Fact ( ...) // same as above
>   <ContextName>(1).Fact ( ...) // facts from specific
>                                // instance of specific context.
>
> Ok. What I am looking here.
> - is something like this possible now out of the box and
>   I skipped this nice chapter in documentation?
> - does it make sense from your point of view to implement this
>   kind of functionality. In my case it has lets say business
>   justification and will allow to implement really complex solutions in
>   nice way.
> - Does this problem have some buzzwordish/scientifically blessed
>   name so I can express it better next time or maybe find something
>   interesting in mailing list archive.
>   (Changing subject to something more sufficient is more the welcomed )
> - is it at all possible ;)
> - what I am missing in this problem description?
>
> And big thanks for reading it till the end.
>
> tk.
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>