[rules-users] Partial Unification / Derivation of Facts?

[Wolfgang Laun]

All right: if it is the "matching" rule that defines the parameter set
you can either define the parameters literally in that rule or you can
create a lookup-table with the rule name as its key. You can obtain
the rule name generically on the RHS, and you can write some code to
make sure that all "matching" rules identified by some code in their
name have an entry, etc.

The "deriving" rules don't matter - there is no 1:1-correspondence
between them and the "matching" ones.

-W

On 27 September 2011 16:53, JohnnyCaimbridge <nbower at nycm.com> wrote:
> Let me start from scratch as I'm realizing how difficult it is to understand
> my issue.
>
> There is a Fact "A" with some rules use as conditions.  "A" can be derived
> in several different but mutually exclusive ways.  For the most part, the
> rules which define each of these derivations depend on states/conditions
> which the rules matching on "A" are largely agnostic of.
>
> rule "rule deriving A"
> when
>   //some conditions
> then
>   insert( new A(/*some values*/) );
> end
>
> rule "another rule driving A"
> when
>  //some other conditions
> then
>  insert( new A(/*some other values*/) );
> end
>
> // many other rules deriving A
>
>
> However, there are also other "parameters"/"values" needed for the
> computation of the many derivations of "A" (they need to be present in the
> RHSs of rules deriving "A").  The combination of these values are
> context-dependent to each matching of "A" /every time/.  That is, each
> matching of "A" has a unique set of values binded to a particular set of
> parameters expected by rules deriving "A").  Rules deriving "A" need not and
> should not match on these parameters because they are different for every
> matching of "A"; the derivations should (ideally) take on whatever values
> are specified in the matching.
>
> rule "rule matching on A"
> when
>  $a : A() // needs to somehow convey to the derivation of A() that it
> should use a set of values unique to this matching in its derivation
> then
>  // use $a
> end
>
> rule "another rule matching on A"
> when
>  $a : A() // needs to somehow convey to the derivation of A() that it
> should use a set of values unique to this matching in its derivation
> then
>  // use $a
> end
>
> I cannot leave it up to the rules deriving "A" to handle every single case
> of different values for these parameters--there would be thousands of
> different combinations of derivations of "A" and nobody would understand the
> code.
>
> The rules deriving "A" cannot match on general "Parameter" objects because
> the values in the Parameter objects are unique for each matching of "A".
> This would mean that each rule matching "A" would need a counterpart rule
> which asserts the parameters/values needed by the rules deriving "A".  I
> mean, I suppose this /is/ a solution, but it's obviously difficult to
> understand design.
>
> I guess what I'm looking for is something inbetween a function (with
> explicitly binded parameters) and a derivation that is rule based--to be
> able to say "derive this kind of object in any way that you can, but use
> these particular values in its derivation".  Perhaps this is not possible.
>
> --
> View this message in context: http://drools.46999.n3.nabble.com/Partial-Unification-Derivation-of-Facts-tp3372546p3372828.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>