On Wed, Aug 6, 2008 at 8:10 AM, Michael Neale
<michael.neale@gmail.com> wrote:
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@codehaus.org> 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
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com