<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 14/02/2012 16:25, Edson Tirelli wrote:
<blockquote
cite="mid:CAD7AJncuqbA-GWUHZzryggK=mORuQQeC4zteYKjSOJ0WSf6dYA@mail.gmail.com"
type="cite">
<div><br>
</div>
The overall idea of using labels instead of numbers is a good
thing, but I share some of the concerns Greg seems to have. It
does not matter if the underlying conflict resolution is based on
numbers or not, but mixing this concept with the concept of
salience might be confusing and bring runtime conflicts.
<div>
<br>
</div>
<div> One situation that comes to mind is that as of today, all
conflicts and error messages are resolved by Drools at compile
time. Once the knowledge package is built, adding it to a kbase
will not generate errors or make the kbase inconsistent... so
Drools has no framework to prevent such addition or report back
to the application if such operation can't be completed because
of a conflict and then safely rolled back. A feature such as
this requires runtime validation as the dependencies can be
defined in different knowledge packages where the addition of
one to a kbase does not cause any problems, but the addition of
the other can cause a circular dependency.</div>
</blockquote>
agreed.<br>
<br>
For this to work we must be able to detect if a kbase change is
invalid and roll back. We need this feature anyway, not just for
label based conflict resolution, but also for other typs of
problems. Such as trying to remove type declaration for a type used
in rules that are still present.<br>
<blockquote
cite="mid:CAD7AJncuqbA-GWUHZzryggK=mORuQQeC4zteYKjSOJ0WSf6dYA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div> Another related issue is that if the labels are just
synonyms to certain salience numbers, what happens when someone
mixes salience numbers with labels. How do you decide the order?
Wolfgang suggests mutual exclusivity (which also requires
runtime checking), but I feel that it would be too limiting. For
some cases I prefer to simply assign a number to one rule than
having to annotate multiple rules in order to say: this should
fire before/after those rules.</div>
<div><br>
</div>
<div> In any case, Mark mentioned that he thinks that this is
different from ruleflows (and much lighter). This, in my mind,
is an implementation detail. If I am a user, at the moment, I
don't see a difference between ordering rules based on ruleflow
groups and based on this before/after other than that using
ruleflow-groups, I can define my order graphically in the flow
editor, while in this thing I will have to manage priority
annotating every single rule, and if I ever need to change the
order of some of these priorities, I have to fix it in multiple
places instead of a single diagram.</div>
</blockquote>
The main different is salience is "inline" you don't need external
declarations/invokcations to control orderling like you do with
ruleflow-groups and agenda-groups. So ignoring the implementation
it's use is "lighter" for users. <br>
<br>
But both "inlining" before and after and also externalising the
control are compliementary things, actually the externalising aspect
ties in with our idea for "classifical planning",
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/STRIPS">http://en.wikipedia.org/wiki/STRIPS</a>. ruleflow-groups and
agend-agroups have it all wrong. ruleflow-groups are processes and
thus brittle for change, agenda-groups have no over all archicture.
Hiearathical Task Networks can be visualised a as a graph, yet are
much more robust and fully rule based. So while before/after might
handle "inline" we'll probably take a HTN approach for
externalisation.<br>
<br>
<br>
<blockquote
cite="mid:CAD7AJncuqbA-GWUHZzryggK=mORuQQeC4zteYKjSOJ0WSf6dYA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div> My point is that while the idea of a lightweight,
labeled-priority conflict resolution is good and desirable, I
think we need to mature the idea and maybe make that change in a
transparent way for the user. Maybe this whole concept can be
unified with Mark's uber-group idea instead of creating a
separate feature that will be hard to manage and use...</div>
</blockquote>
damn, and I was about to commit a working implementation ;)<br>
<br>
<br>
<blockquote
cite="mid:CAD7AJncuqbA-GWUHZzryggK=mORuQQeC4zteYKjSOJ0WSf6dYA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div> My .02c</div>
<div><br>
</div>
<div> Edson<br>
<br>
<div class="gmail_quote">On Tue, Feb 14, 2012 at 2:54 AM,
Wolfgang Laun <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">This is an
excellent idea.<br>
<br>
It should be reasonable to assume that "salience" and the
use of<br>
before/after are mutually exclusive.<br>
<br>
Also, salience (irrespective of the way it is defined)
should not be<br>
confused with agenda groups. I tell my students that "focus"
is<br>
suitable for rule flow "in the large" and salience can be
used for<br>
fine-grained prioritizing (with the caveat that more levels
than you<br>
have fingers on your hand are evil).<br>
<br>
The question is whether before and after should be rule
annotations.<br>
If you create a new package element you could define rule
precedence<br>
in one central place, exclusively referring to annotations,
e.g.:<br>
<br>
fire @reset before @cashflow before @print;<br>
<br>
fire @yawn before @stretch before @scratch,<br>
@dinner after @hightea after @lunch after @breakfast;<br>
<br>
Here you see it at a glance, and it opens fewer
possibilities for<br>
creating loops.<br>
<span class="HOEnZb"><font color="#888888"><br>
-W<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
On 14/02/2012, Mark Proctor <<a
moz-do-not-send="true"
href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>>
wrote:<br>
> Davide has suggested a good idea.<br>
><br>
> Now that rules support annotations, and annotations
with values. We<br>
> should add a before/after keyword to each rule.
before/after would then<br>
> take a list of annotations. The idea is to use this
to generate salience<br>
> under the covers.<br>
><br>
> rule resetBalance before( @cashflow ) when then end<br>
><br>
> rule debit @cashflow when then end<br>
><br>
> rule credit @cashflow when then end<br>
><br>
> rule printBalance after(@cashflow ) when then end.<br>
><br>
> Salience gives one rule priority over another, thus
it's declaring an<br>
> implicit relationship between rules. Yet it's a
magic number that<br>
> doesn't easily show this relation, and as the
rulebase grows it can be<br>
> very hard to determine those relationships as
specified by salience from<br>
> reading the rules. before/after allows you to
specify declarative the<br>
> relationships betwen rules in a more maintainable
and readable way, even<br>
> if under the covers it's just generating:<br>
><br>
> rule resetBalance salience 100 when then end<br>
><br>
> rule debit salience 0 when then end<br>
><br>
> rule credit salience 0 when then end<br>
><br>
> rule printBalance saliance -100 when then end.<br>
><br>
> Yes there are agenda-groups and ruleflow-groups,
but they can be a bit<br>
> cumbersome compared to the simplicity of using
salience. This way we get<br>
> the simplicity of using salience, without the
downfalls of it being a<br>
> magic number.<br>
><br>
> What do people think? Any ideas on how we can
improve this? At build<br>
> time it would have to report impossible to resolve
relationships and barf.<br>
><br>
> Mark<br>
> _______________________________________________<br>
> rules-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss by Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com">www.jboss.com</a><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>