Rule Parameters/Aliases
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Rule Parameters/Aliases
by Yoni Mazar
::
Rate this Message:
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. 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... 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) 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? 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. Thanks a lot. Yoni |
|
|
RE: Rule Parameters/Aliases
by Anstis, Michael (M.)
::
Rate this Message:
I am not sure re-posting the same questions a couple of weeks later will
give any better responses. I also know this would better be addressed to the users forum and not the developers'. With regards, Mike -----Original Message----- From: rules-dev-bounces@... [mailto:rules-dev-bounces@...] On Behalf Of Yoni Mazar Sent: 09 July 2008 12:51 To: rules-dev@... Subject: [rules-dev] Rule Parameters/Aliases 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. 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... 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) 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? 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. Thanks a lot. Yoni -- View this message in context: http://www.nabble.com/Rule-Parameters-Aliases-tp18359434p18359434.html Sent from the drools - dev mailing list archive at Nabble.com. _______________________________________________ rules-dev mailing list rules-dev@... https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev@... https://lists.jboss.org/mailman/listinfo/rules-dev |
|
|
|
|
|
Re: Rule Parameters/Aliases
by Mark Proctor
::
Rate this Message:
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... > 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) > 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. > 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 > > _______________________________________________ rules-dev mailing list rules-dev@... https://lists.jboss.org/mailman/listinfo/rules-dev |
|
|
Re: Rule Parameters/Aliases
by Mark Proctor
::
Rate this Message:
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:
_______________________________________________ rules-dev mailing list rules-dev@... https://lists.jboss.org/mailman/listinfo/rules-dev |
|
|
Re: Rule Parameters/Aliases
by Yoni Mazar
::
Rate this Message:
Hi Mark,
First of all thanks for the response. Using global variables may be a good workaround for in/out parameters. Our purpose of using named parameters is to differentiate between facts which may be of the same type but may have different role (without forcing the rule author to add this logic in the patterns). for example - one can write the following rule: rule "Rule1" when $anemia: Diagnosis(alias == "anemia") $hypertension: Diagnosis(alias == "hypertension") //business logic here Diagnosis (code == "5") from $anemia and Diagnosis (code == "7") from $hypertension then #DO something end but this solution is much better since it extracts the alias complexity outside of the rule: #declare any global variables here global java.util.List anemia; global java.util.List hypertension; rule "Rule1" when //business logic here Diagnosis (code == "5") from anemia and Diagnosis (code == "7") from hypertension then #DO something end this solution will of course force us to introduce the facts twice - once as normal facts inserted to the working memory and once as globals in order to allow the parameterization. will this workaround cause unwanted results (since the facts appear twice)? Thanks Yoni |
|
|
Re: Rule Parameters/Aliases
by Michael Neale
::
Rate this Message:
One thing that people missed that may be interesting is the fact aliasing.
So in the simplest case this is simply renaming a fact so instead of: FooBar() in a rule, you could write YourFabulousObject(). That is clear enough. What would be interesting is the following: FooBar(someField == "abc") aliased too SomethingElse() so the someField == "abc" constraint is always implicitly applied. I could see this being useful, especially when generic facts are used.. this could be Thoughts - any one wanna have a crack at implementing this? On Sat, Jul 19, 2008 at 3:31 AM, Mark Proctor <mproctor@...> wrote: > 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 > > > > > > _______________________________________________ > rules-dev mailing list > rules-dev@... > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ rules-dev mailing list rules-dev@... https://lists.jboss.org/mailman/listinfo/rules-dev |
|
|
Re: Rule Parameters/Aliases
by Michal Bali-2
::
Rate this Message:
Hi, nice idea,
Yoni, in your case the aliases could be implemented as immutable wrapper objects, that implement the same interfaces and just delegate to the wrapped object (alternatively they could extend the object, however the rules will need to do instanceof checking to avoid recursion) example: rule aliasRule when $diagnosis : Diagnosis(alias == "anemia") then insert(new DiagnosisAnemia($diagnosis)); end rule businessRule when DiagnosisAnemia(code == "5") then //do something end The wrapper object should be immutable, otherwise when doing updates you'll have to update both, alias and the original object. You could have 2 rule packages - one for setting up aliases and one for business logic, so that it will be separated I hope this helps. Regards, Michal On Wed, Aug 6, 2008 at 8:10 AM, Michael Neale <michael.neale@...> wrote: One thing that people missed that may be interesting is the fact aliasing. _______________________________________________ rules-dev mailing list rules-dev@... https://lists.jboss.org/mailman/listinfo/rules-dev |
| Free Forum Powered by Nabble | Forum Help |