RE: [PRD] PICK specification --> comment

> If the other PRD people are of the same opinion, that would probably
make
> our job easier. So, *Mark*, *Paul*, *Adrian*, etc, what do you think?
This
> could be an easy resolution to discuss in Orlanda.

My thoughts are:

A - use cases like MISMO are not inferencing, and indeed ruleflow-based
BREs use of inferencing can be rare [*1], implying a CR strategy is
irrelevant [*2] in most non-academic use cases for RIF. In other words,
it could reasonably be ignored in PRD1.0 / deferred til such time as
inter-BRE inference rule interchange became a proven PRD limitation [*3]
 
B - a classification scheme of CR strategies sounds dangerously like
"R&D" to me, which should be a huge warning bell for W3C on this topic.
On the other hand, it is "useful" information for rule interchange. On
the other hand again, I would expect CR schemes to be arbitrarily
complex and/or proprietary.

C - the proposed solution (aka/as far as I can tell: "lets have a simple
classifier that provides some CR information to RIF rulesets") seems
like a reasonable compromise. 

Comments:
[1] Anecdotal only - I don't think anyone has done research on this and
I doubt the BRE vendors measure this / want to make such data public

[2] If there is no inferencing, then a rule cycle will only complete
once for any ruleset in scope. Ruleflow-defined rule systems only have 1
ruleset in scope at a time. Therefore, CR is not required. Further,
usually such rulesets will be exclusive (have only a single rule whose
condition matches the current state of WM).

[3] This would be what I would call a pragmatic solution, but others
would call a delaying-the-issues tactic

Terminology:
CR Conflict Resolution
WM Working Memory

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Christian de Sainte Marie
> Sent: 28 October 2008 04:30
> To: Gary Hallmark
> Cc: RIF WG
> Subject: Re: [PRD] PICK specification
> 
> 
> Gary,
> 
> >From your proposed spec for PICK, I understand that you prefer to
define
> the conflict resolution strategies at a larger grain than what I
proposed:
> assuming that your proposal for "repeatable" accounts for "refraction"
> (but... see below), your proposal would specify one parametrable, call
it
> "forward chaining profile": apply refraction with or w/o repetition,
then
> select the instances with the highest priority, then select the
instances
> most/least recently in the agenda; whereas I proposed to define the
> elements (refraction, recency, priority etc) separately, and a simple
way
> to combine them (as a sequence).
> 
> Changhai also prefers a limited number of profiles to the more
flexible,
> but more burdensome specification I proposed initially.
> 
> If the other PRD people are of the same opinion, that would probably
make
> our job easier. So, *Mark*, *Paul*, *Adrian*, etc, what do you think?
This
> could be an easy resolution to discuss in Orlanda.
> 
> However, regarding the repeat/no-repeat part properly said, I think
that
> there is a problem with the specification (or I do not understand your
> proposal correctly, which is entirely possible).
> 
> Gary Hallmark wrote:
> >
> > 1. one of the following is true:
> >    a. repeatable(rule(ri)) is true and age is the greatest i such
that
> > ri is in prior(c, i) and ri is in prior(c, i-1) and ... and ri is in
> > prior(c, 0) and ri != picked(prior(c, i)) and ri != picked(prior(c,
> > i-1)) and ... and ri != picked(prior(c, 1)), or
> >    b. repeatable(rule(ri)) is false and age is the greatest i such
that
> > ri is in prior(c, i) and ri is in prior(c, i-1) and ... and ri is in
> > prior(c, 0) and rule(ri) != rule(picked(prior(c, i))) and rule(ri)
!=
> > rule(picked(prior(c, i-1))) and ... and rule(ri) !=
rule(picked(prior(c,
> > 1))), and
> 
> As I read it, this says that, in any configuration, all the fireable
> instances are in the agenda, and that the "age" of a particular
instance
> is the number of consecutive configurations in a row in which it has
been
> fireable since it has been last fired (if repeatable), or since it or
any
> other instance of the same rule has been fired (not repeatable).
> 
> But, then, a rule that was just fired in c-1 and that is again
fireable in
> c will be in the agenda with age 0, whether repeatable or not. For
> instance, if there is only one rule
> R1: if P(?x) then print(?x)
> 
> and 2 facts: P(A) and P(B)
> 
> If R is repeatable and your strategy is most recent first, you will
have:
> A A A A A A .... or B B B B B ... depending on which is fired first
> and if you have least recent first, you will have:
> A B A B A... or B A B A B ... depending on which is fired first
> 
> And if R is not repeatable, you will have a random sequence of A and B
> printed.
> 
> I am pretty sure that this is not what you intended: did I get
something
> wrong, or is, indeed, the proposed specification flawed?
> 
> In a subsequent email, you say that the behaviour for repeatable rules
is
> the same as ILOG's refraction. That would be, as in the specification
that
> I proposed back before the FPWD, that a rule instance that has been
fired
> is *not* in the agenda if it has been fireable ever since (that is, if
its
> age is the number of configurations that were traversed since it has
been
> fired). Is that what you meant?
> 
> Btw, the specification I proposed back before FPWD correctly accounts
for
> ILOG's version of refraction: the example that you provided as proof
that
> it did not work is, really, about what Changhai calls "repeatability"
(and
> I wonder if we may not eventually find out that it is the same
> repeatability as yours :-)
> 
> The example was:
> 
> RuleIncreaseLowSalary:
> If ?employe(hasSalary->?x) and ?x < 1000 then increase salary by 10%
> 
> and there is one fact: John(hasSalary->100)
> 
> According to the version of refraction that I proposed (under the
> misnommer "no-repeat"), the rule would fire again and again until
John's
> salary has been increased to more than 1000 (since ?x binds to a new
value
> in each new configuration). This is obviously not the intended
behaviour.
> 
> But consider the similar rule:
> 
> RuleAccelerateTo200:
> If ?car(speed->?x and ?x < 200 then increase ?x by 10%
> 
> and there is one fact: MyRacingCar(speed->100)
> 
> In that case, the intended behaviour is, indeed, that the speed of
> MyRacingCar is increased until it passes 200!
> 
> The difference is not in refraction, which has no role here since ?x
binds
> to different values in each configuration, in both cases, but whether
or
> not the rule is repeatable: in the case of John's salary, the rule is
> meant to be non repeatable; in the case of MyRacingCar, it is meant to
be
> repeatable.
> 
> Notice that in the example of R1, above, refraction would make the
printed
> result be
> A B or B A depending on which fires first, and repeatability has no
role
> (since refraction does the trick).
> 
> We wil ldiscuss this in Orlando.
> 
> Cheers,
> 
> Christian
>

Received on Tuesday, 28 October 2008 09:39:44 UTC