Just a brief note on what I've seen recently on the Jess users group emails. BASIC, FORTRAN, COBOL, Pascal, C, C++, C#, Java - all of those are still procedural languages, meaning that they are not "declarative" in nature. One of the first rules in using a rulebase is that if the program can be defined in a procedural manner, then do NOT use a rulebase to solve the problems. Just as you had to move your thinking from truly procedural (BASIC, FORTRAN, COBOL, Pascal and C) to Object Oriented (C++, C#, Java, etc.) then you also have to migrate your thinking from Procedural/OO to Declarative concepts.
Sounds cool, huh? Well, it is. If you have to have something happen in a 1-2-3-4-5-6-7-8-9-10 manner, that's truly procedural. Well, what about salience. Answer: Salience, like other things (such as inheritance) should be rare and very little of that. Meaning, if you need more then three levels of salience they you probably have a procedural algorithm that would work better. If you have 5 or 6 levels, definitely there is a better solution than rules.
Think of rules like this: I need a very general statement that is always true regardless of the data feed. When you think of a rule, think of it like this;
IF there is any X
such that X(1) = 5
AND X(2) = var1
AND if there is any Y
such that Y(1) = var1
AND Y(2) = Color.Red
AND if there is any Z
THEN set Z(1) = 10
AND print a statement...
Think of this as ever-constricting sets of information. First, I want to know if there is any X in memory. If so, I want the sub-set of all X where X(1) = 5. Then I want to set var1(a) = X(a)(2) and var1(b) = X(b)(2), meaning that I have at least two X objects in working memory, X(a) and X(b). For each X in memory, you have two datum, X(1) and X(2) => you have four datum points for comparison. Now, you will have at least two more datum for each Y object in memory. For example, lets say that you have 15 X objects and 25 Y objects. That would mean 60 X datum points and 100 Y datum points. And, of the 160 datum points, you want only those subsets where ...
Very generalized thinking; not a 1 - 2 - 3 - 4 - 5 kind of logic, but rather a "what if" kind of logic. And describing projects in this manner is supposed to be how the natural mind thinks, not the 1 - 2 - 3 kind of thinking that you were taught in math classes. (Yes, it was difficult for everyone who ever studied science.) Remember, these kind of programs were thought up by psychologists, not mathematicians. By physicians trying to determine the KIND of infection(s), not chemists trying to determine the makeup, or the WHAT, of the infection.
I guess it all comes down to this: RTFM, Read The Fabulous Manual!! BEFORE you start writing so-called "rules". RESIST THE URGE TO CODE !! Rather, think out the problem first. If you're thinking step 1 do this and step 2 do that, that's the wrong kind of thinking. Rather, think "What if I have a row of data composed of 150 elements and another row of data composed of 150 elements. What kind of decision do I want to make?" This is the kind of thinking that Doctors, Psychologists, Insurance Underwriters, Bank Loan Officers make, not planners.