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

[JohnnyCaimbridge]

Well, just going back and forth and taking the time to explain my issue / the
functionality I had in mind has helped significantly in my own
understanding, and at the very least I am now confident in what sort of
limitations there are.  So, I don't consider this time a waste, and thanks
for trying to understand me.

--
View this message in context: 
http://drools.46999.n3.nabble.com/Partial-Unification-Derivation-of-Facts-tp3372546p3373529.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

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

[JohnnyCaimbridge]

How would I go about implementing the first part to your solution? (where you
say "if it is the 'matching' rule that defines the parameter set you can
define the parameters literally in that rule")

I am not aware of any syntax that would permit this type of behavior--that
would allow me to (in the matching rule's condition) literally define the
values the rules deriving "A" should use, instead of the deriving rule
matching it against working memory (ie to indicate from the matching rule
that the derivation rule should always use a certain value as a condition
rather than matching against working memory).

Given:
rule "derivation rule"
when
   $prm1 : Param1()
then
  insert( new A($prm1) );
end

, the following indicates that working memory should be pattern matched for
an "A" with getParam1() == new Param1("val").  Of course, this is not my
desired functionality:
rule "matching rule 1"
when
   A( param1 == new Param1("val") )
then
   // do w/e
end

What I would like to see is--given the "derivation rule" above--something
like this:
rule "matching rule 2"
when
   $a : A( param1 := new Param1("val") )
then
  // do something with $a
end

^ Ideally this would tell the rule "derivation rule" to attempt to derive
A(), but under the assumption that param1 should be initialized with "new
Param1("val")" as opposed to strictly matching for it in WM.  However, the
more I look at this, more it seems like backward chaining is necessary...

--
View this message in context: 
http://drools.46999.n3.nabble.com/Partial-Unification-Derivation-of-Facts-tp3372546p3373242.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

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

[JohnnyCaimbridge]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

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

[JohnnyCaimbridge]

NOTE: Reposted because I only just subscribed to the mailing list.

Hello, 

I have a set of Fact types which represent factors matched and used
throughout the other rules.  Each of these Fact types may be derived in a
variety of mutually exclusive ways--ie based on the line of business or
other factors.  The rules are all well-defined for these Facts.  Something
like this: 

declare FactorType1 
   value : BigDecimal 
end 

rule "FactorType1" 
when 
   LineOfBusiness( this == LineOfBusiness.LOB1 ) 
   // some other conditions 
   $prms : Params() // ***provisional*** where to specify needed context
dependent parameters? see below 
then 
   BigDecimal value = new BigDecimal("0"); 
   // ... determine value based on conditions and $prms 
   insert( new FactorType1(value) ); 
end 

// 

The problem is that in the rules which match these Facts, there are many
context dependent (ie *always* unique to that particular rule) parameters
which must be "passed" to the derivation of those Facts.  I'm referring to
these as "Params" above.  Now, a rule that uses FactorType1: 

rule "a rule that uses FactorType1" 
when 
   // some conditions 
   FactorType1( $value ) 
   $prms : Params(prm1,prm2,prm3,...) // ***provisional*** how to indicate
that FactorType1 should use these parameters in its derivation? 
then 
   // perform some calculation with $value 
end 

The parameters which these Facts use cannot be asserted as Facts themselves. 
They are unique to the rules which match on the FactorTypes, so that would
mean I'd need a duplicate rule for every rule that uses a FactorType (even
with "rule inheritance", this is excessive). 

It's almost as if I need to specify a "partial derivation" or "partial
unification" of the Fact type, which is only asserted once a rule indicates
that it is providing the "unbound" portion of the derivation.  I understand
queries can be used for some sort of partial unification, but I have no clue
how to apply them to my problem and I can't find any good examples or
documentation on their usage/behavior. 

Thanks in advance  



--
View this message in context: 
http://drools.46999.n3.nabble.com/Partial-Unification-Derivation-of-Facts-tp3372546p3372546.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users