[rules-dev] Rule Parameters/Aliases

[Mark Proctor]

Found this:
http://www.ilog.com/products/jrules/documentation/jrules67/rtsohelp/wbg_config7.html
"A ruleset parameter is the equivalent of a global variable"

So a ruleset parameter is nothing more than a global, so just use our 
globals as is and you get IN_OUT capabilities. I would strongly advise 
you against representing your entire model this way and just using evals.

Mark


Mark Proctor wrote:
>
> Yoni Mazar wrote:
>> Hi all,
>> We are at the begining of a new clinical decision-support project. We 
>> plan using drools (using Eclipse) in order to manage and execute our
>> business logic. As part of our research, we also evaluated JRules 
>> which has a feature that
>> is very important to us and we could not find in Drools.   
> I've reference the ilog manual on in/out parameters if anyone doesn't 
> know what they are:
> http://www.ilog.com/products/jrules/documentation/jrules67/rsruleset/rs_rls_parameters.html#1026848 
>
> http://www.ilog.com/products/jrules/documentation/jrules67/rsruleset/rs_rls_tskcreatingrulesetparams.html 
>
>
> I don't see the difference between a global and an IN_OUT parameter, 
> and I don't see the value of specifically saying which parameters are 
> IN and which are OUT. It doesn't seem that parameters are facts, they 
> are not asserted into the engine and propagated through the working 
> memory - atleaast I don't think they are, the manual doesn't say 
> clearly enough, it just says they can be referenced from any ruleset 
> component, which seems to be akin to how we do globals.
>> Unless we missed it out, we will probably try and add this functionality
>> ourselves.
>>
>> In JRules, one can define a ruleset (corresponds to a package) with
>> parameters. Each parameter has a datatype (a class), a direction
>> (in/out/inout), and an alias. Then, within the rules, the user can 
>> refer to the parameter alias. For
>> example, a user can define a ruleset with the following parameters:
>> *class=LabResult, direction=in, alias=hemoglobin *class=LabResult, 
>> direction=in, alias=creatinin
>> Then, within a rule, one can write: when hemoglobin.value<10 and 
>> creatinin.value>34 then...   
> We can do the same with globals, but what that actually means is you 
> have a rule that doesn't use any working memory objects, and you put 
> the constraints into one big eval - no pattern matching, so you are 
> turning the rule engine into a scripting engine rather than a 
> production rule system.
>
> If they are indeed facts that allow for pattern matching, then it 
> seems that they constraint by the variable name rather than by object 
> type. I've never liked this, again why not just use mvel directly as a 
> scripting engine. But I have thought of how this would be possible, 
> somethign I call Named Facts - where asserted facts can be given a 
> unique string identifier and a pattern can be told to not only 
> constraint against that object type, but also against that variable 
> name. However this is something that users can emulate themselves now, 
> by just putting an "identifier" field on their facts and constraining 
> on it in the pattern. If someone comes up with a clean way for 
> supporting named facts and provides a patch we will consider including 
> it, but it's not one of our priorities at the moment.
>
>
>> Now, the application retrieves the patient data accordingly 
>> (hemoglobin and creatinine data separetly - even though they are of 
>> the same type) and sets
>> the ruleset parameters: 
>> ruleset.parameters.add("hemoglobin",hemoglobinFact) 
>> ruleset.parameters.add("creatinin",creatininFact)
>> It is important that the definition of the aliases will be done 
>> outside of
>> the rule (and not by defining in-rule variables)
>>
>> This approach simplifies the rules since some of the filtering is being
>> applied externally (not in the rule itself)
>>   
> sounds like it simplifies it, by turning it into a scripting engine 
> where all facts are variables with identifiers.
>> Does someone has an idea how to bridge this gap using Drools? Are 
>> there any workarounds that can be used in order to avoid changes in
>> code?
>>   
> Hopefully my main paragraph above shows you how to emulate this.
>> And here we can use your help:
>> We are new to Drools (and still have to dive into the big ocean of 
>> code that
>> exists). The following features
>>
>> 1) defining parameters (in the package level...something like import)
>> 2) adding in/out modifiers (can be used in LHS, RHS, or both)
>> 3) allowing assignment of aliases to parameters 4) adding such 
>> functionality to the rule editor (auto-complete ,type safety)
>>
>> Where should we start?
>> Do you have any ideas that can help start this process (e.g. relevant
>> classes, modules)?
>> We would appreciate any help regarding any of the items in the list 
>> above.
>> Any hints, suggestions, directions, referals and so on.
>>   
> IF IN_OUT params are nothign more than globals and big fat evails, 
> then you have nothing to do.
>
> If they are named facts, it won't be easy, but you could try the 
> following approach:
> 1) update drools to support named facts, as described previously, this 
> will involve a special type of ObjectType I imagine, and you'll have 
> to change how it matches ObjectTypes so that it also has access to the 
> possible variable name.
> 2) figure out a sane syntax, that is not ambigious, to allow pattern 
> matching on named facts, and update our Antlr files to support this.
> 4) I don't konw if in/out parameters are useful for a stateful 
> session, or only stateless. Either way you will probably want to 
> create some Context object that contains these parameters and then you 
> "insert" them using smething like insertWithParameters( myParams ). 
> With stateless it'll execute and return results directly, with 
> stateful you'll have to figure out how that'll work with possible 
> incremental inserts and fireallrules being called separately.
> 4) Write lots of tests ot make sure it doesn't break anything
>> Thanks a lot.
>>
>> Yoni
>>
>>   
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20080718/2d60d145/attachment.html