RE: [PRD] PICK specification --> comment

I acknowledge the different email exchanges and point of views.
Christian and I have quite the same understanding on this PICK function.
Let me summarize my point of view using the following points:
- My wiki page explained 2 concepts: refraction vs. repeatability. I
advocate that we should use the right word for the right thing.
- Either refraction or repeatability is per rule instance, and not per
rule. Anything that occurred on a rule instance should not impact other
rule instances.
- I also propose to map "age" into "recency", which defaults to the
number of cycles in the engine.
- For the rest, see Christian comments below.

It is also my understanding that the CR strategy we are discussing is
just one strategy, that we can name it by "inference strategy" (or
forward chaining?). We said that we should allow to define other
strategies, for example one with no rule chaining. Paul, what do you
think of this capability, and which strategies do we predefine?

If we predefine the "inference strategy", I would also like it to be
specified in relatively high level terms. It's good that we improve
mutual understanding with these discussions about refraction,
repeatability, etc. But I wonder if a spec with some simple terms, such
as "order by this" "order by that" without entering into the details
isn't more appropriate.

Changhai

-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Paul Vincent
Sent: mardi 28 octobre 2008 10:38
To: Christian de Sainte Marie; Gary Hallmark
Cc: RIF WG
Subject: 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 10:54:18 UTC