Re: JESS: Goal in each action
To jump in.. I suggest that everyone buys that book if they are going to use Jess. It *does* repeat some material available in the online docs and other places, but also includes quite a good bit more code and examples than I found anywhere else. Roger Studner On 1/26/06, Daniela CLARO <[EMAIL PROTECTED]> wrote: > > Hi James, > Thank you very much for your deeply answer. I have some comments to add..
RE: JESS: Goal in each action
Hi James, Thank you very much for your deeply answer. I have some comments to add... Actually, I completely agree with you that rule-based systems are a kind of data-driven and forward chaining also. In my example, the planner that I am devellopping, I can have an explicitly goal, but actually I dynamically create my plan and my goal depends on which rules are decided by the user to be included. Each rule corresponds to a web service in real world and the goal of my planner is to order the rules, saying which one should be before the other. For example, if I am constructing a stairs, first I need the concrete and then I can construct a stairs. Thus based on preconditions the actions will be organized in the order of its execution. In this case my goal was construct a stair, but if I had put also action floor, probably my goal would be construct a new floor, and stair will only be an intermediate step. More or less, I hope you have understood what I am doing... About the book, I can buy it, but is it different from the Docs in Jess, or they are similar? Do you really encourage me to buy it? Thank you very much, I will probably post another message about some other problems I am having when implementing Jess with Java beans. Daniela -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de James C. Owen Envoyi : mercredi 25 janvier 2006 20:36 @ : jess-users@sandia.gov Objet : Re: JESS: Goal in each action Deniela: As stated before, which you might not have seen, most of the problems with newbies and rulebased systems is that the process is declarative rather than procedural as with most other languages. When a rule is refracted (removed from the agenda permanently because it has already) the rule that is deleted is the rule+data, meaning that the same rule logic may appear several times but with a different set of data. If the data are changed, then the rule logic might appear again. Now, to goal-oriented rules. Normally, in most rulebased systems, recency is one of the first items to consider. So, if a new goal is asserted it will take precedence over any other goals. That's why the goal usually appears as the first condition in the rule. The manner in which the rules are processed is not like other languages; it is determined as an abstract problem and is solved by the conflict resolution strategy. And, yes, under the covers, each OR is broken down into two rules complete with data associated with that rule. Here is a fairly easy way to think of the rules: All of the rules and all of the data are put into a big pot. Each rule associates itself with a set of data and becomes an object. When we use goal- oriented rules, we restrict each set of rules to only those with the current goal - which can change if any of the rules assert another goal. During the first cycle, all of the rules+data are examined (1) to associated each datum with a specific rule, (2) to associate a rule with specific data and (3) to see if any of the rules evaluate to TRUE. All of the rules that evaluate to TRUE are put on the Agenda Table as well as being put into a truth maintenance table. Then the rules are evaluated according to conflict resolution. If any datum is changed then any rule that used that datum is RE-evaluated to see if (1) it was false and is now true and it will be put on the Agenda table or (2) if it was true and on the Agenda table and is now false it will be removed. ONLY those rules where the data are changed are evaluated. And numerous tests over the years have determined that even with thousands of rules, only two or three rules are changed during one cycle of rules. Meaning that not all of the rules need to be checked - only those who data have changed. I know that all of this might seem a bit low-level and simplistic, but sometimes we tend to forget that rules are "kind of" data driven - it's also sometimes called forward chaining which may or may not be a misnomer. Above all, read the book on Jess, "Jess in Action", and go through the examples and tutorials before attempting to design your own system. If I sound condescending, I apologize but it's most difficult to answer questions over the internet without sounding like a professor talking to a student. If this has been of any help, good. If not, then just toss it. :-) SDG jco James C. Owen Senior Consultant [EMAIL PROTECTED] http://www.kbsc.com "Never give up. Never give up. Never, never, never give up." From a speech by former Prime Minister, Winston Churchill, during the most trying times of the British Empire; a great leader too soon forgotten by his country after keeping it from being swallowed up by the Nazi Empire during the second world war. On Jan 25, 2006, at 2:51 AM, Daniela CLARO wrote: > Thank you Ernest, > I have more questions about it...The first one is that I'd read that > Jess memorizes each
Re: JESS: Goal in each action
Deniela: As stated before, which you might not have seen, most of the problems with newbies and rulebased systems is that the process is declarative rather than procedural as with most other languages. When a rule is refracted (removed from the agenda permanently because it has already) the rule that is deleted is the rule+data, meaning that the same rule logic may appear several times but with a different set of data. If the data are changed, then the rule logic might appear again. Now, to goal-oriented rules. Normally, in most rulebased systems, recency is one of the first items to consider. So, if a new goal is asserted it will take precedence over any other goals. That's why the goal usually appears as the first condition in the rule. The manner in which the rules are processed is not like other languages; it is determined as an abstract problem and is solved by the conflict resolution strategy. And, yes, under the covers, each OR is broken down into two rules complete with data associated with that rule. Here is a fairly easy way to think of the rules: All of the rules and all of the data are put into a big pot. Each rule associates itself with a set of data and becomes an object. When we use goal- oriented rules, we restrict each set of rules to only those with the current goal - which can change if any of the rules assert another goal. During the first cycle, all of the rules+data are examined (1) to associated each datum with a specific rule, (2) to associate a rule with specific data and (3) to see if any of the rules evaluate to TRUE. All of the rules that evaluate to TRUE are put on the Agenda Table as well as being put into a truth maintenance table. Then the rules are evaluated according to conflict resolution. If any datum is changed then any rule that used that datum is RE-evaluated to see if (1) it was false and is now true and it will be put on the Agenda table or (2) if it was true and on the Agenda table and is now false it will be removed. ONLY those rules where the data are changed are evaluated. And numerous tests over the years have determined that even with thousands of rules, only two or three rules are changed during one cycle of rules. Meaning that not all of the rules need to be checked - only those who data have changed. I know that all of this might seem a bit low-level and simplistic, but sometimes we tend to forget that rules are "kind of" data driven - it's also sometimes called forward chaining which may or may not be a misnomer. Above all, read the book on Jess, "Jess in Action", and go through the examples and tutorials before attempting to design your own system. If I sound condescending, I apologize but it's most difficult to answer questions over the internet without sounding like a professor talking to a student. If this has been of any help, good. If not, then just toss it. :-) SDG jco James C. Owen Senior Consultant [EMAIL PROTECTED] http://www.kbsc.com "Never give up. Never give up. Never, never, never give up." From a speech by former Prime Minister, Winston Churchill, during the most trying times of the British Empire; a great leader too soon forgotten by his country after keeping it from being swallowed up by the Nazi Empire during the second world war. On Jan 25, 2006, at 2:51 AM, Daniela CLARO wrote: Thank you Ernest, I have more questions about it...The first one is that I'd read that Jess memorizes each rule that it passes and so Jess doesn't pass two times in the same rule. Am I right? If yes, in Monkey and Bananas example, I do not understand why it changes the goal in some actions, because for me the goal in a planner should be allways the same, for example eat bananas and as the planner is running and passing to into rules, it will not fire that rule again. If a rule has the OR operator, then as you said it creates another rule, and see below what it does. Actually, I thought that changing the goal in each action is the only way to make sure Jess will fire this rule only one time, but...how about the others solutions, how can I get them? Imagine that we have these rules: (clear) (deffacts start (fermetureFenetre pose) (fermeturePorte pose) (fauxPlafond pose) (exist cloison) ) (reset) (defrule peindre-murs-et-plafonds (fermetureFenetre pose) (fermeturePorte pose) (fauxPlafond pose) (exist cloison) => (assert (murPlafond peint)) (printout t "Peint murs et plafonds" crlf) ) (defrule fournir-poser-papier-peint (murPlafond peint) => (assert (papierPeint pose)) (printout t "Fourniture et pose des Papiers Peint" crlf) ) (defrule peindre-sol (or (murPlafond peint) (papierPeint pose)) => (assert (sol peint)) (printout t "Peint le sol" crlf) ) (defrule fournir-poser-moquette (sol
JESS: Goal in each action
Thank you Ernest, I have more questions about it...The first one is that I'd read that Jess memorizes each rule that it passes and so Jess doesn't pass two times in the same rule. Am I right? If yes, in Monkey and Bananas example, I do not understand why it changes the goal in some actions, because for me the goal in a planner should be allways the same, for example eat bananas and as the planner is running and passing to into rules, it will not fire that rule again. If a rule has the OR operator, then as you said it creates another rule, and see below what it does. Actually, I thought that changing the goal in each action is the only way to make sure Jess will fire this rule only one time, but...how about the others solutions, how can I get them? Imagine that we have these rules: (clear) (deffacts start (fermetureFenetre pose) (fermeturePorte pose) (fauxPlafond pose) (exist cloison) ) (reset) (defrule peindre-murs-et-plafonds (fermetureFenetre pose) (fermeturePorte pose) (fauxPlafond pose) (exist cloison) => (assert (murPlafond peint)) (printout t "Peint murs et plafonds" crlf) ) (defrule fournir-poser-papier-peint (murPlafond peint) => (assert (papierPeint pose)) (printout t "Fourniture et pose des Papiers Peint" crlf) ) (defrule peindre-sol (or (murPlafond peint) (papierPeint pose)) => (assert (sol peint)) (printout t "Peint le sol" crlf) ) (defrule fournir-poser-moquette (sol peint) (or (murPlafond peint) (papierPeint pose)) => (assert (moquette pose)) (printout t "Fourniture et pose de moquette" crlf) ) (run) My answers are: Peint murs et plafonds Fourniture et pose des Papiers Peint Peint le sol Fourniture et pose de moquette Fourniture et pose de moquette Peint le sol 6 And then as Jess consider &1 as another rule, it did not stop at the first "Fourniture et pose de moquette" but it tries to execute the OR operator and fire the rule "Fourniture et pose de moquete" and "Peint le sol" two times. Thus is it the reason that I should change the goals in each rule to assure that Jess will fire only one time each rule even if I have an OR operator? Thus my answer in the first planner would be like that: Peint murs et plafonds Fourniture et pose des Papiers Peint Peint le sol Fourniture et pose de moquette This order is fixed based on the preconditions, but imagine that X can be executed before Y or before Z. Thus how can I force that the first plan shows me X before Y and than another plan shows me X before Z. How can I get the other plan? Here is the watch all from Jess> (batch peinture.clp) ==> Focus MAIN ==> f-0 (MAIN::initial-fact) ==> f-1 (MAIN::fermetureFenetre pose) ==> f-2 (MAIN::fermeturePorte pose) ==> f-3 (MAIN::fauxPlafond pose) ==> f-4 (MAIN::exist cloison) ==> Activation: MAIN::peindre-murs-et-plafonds : f-1, f-2, f-3, f-4 MAIN::peindre-murs-et-plafonds: +1+1+1+1+1+1+1+2+1+1+1+2+1+1+1+2+t MAIN::fournir-poser-papier-peint: +1+1+1+1+t MAIN::peindre-sol: =1=1=1=1+t MAIN::peindre-sol&1: +1+1+1+1+t MAIN::fournir-poser-moquette: +1+1+1+1=1=1=1+2+t MAIN::fournir-poser-moquette&1: =1=1=1=1=1=1=1+2+t FIRE 1 MAIN::peindre-murs-et-plafonds f-1, f-2, f-3, f-4 ==> f-5 (MAIN::murPlafond peint) ==> Activation: MAIN::fournir-poser-papier-peint : f-5 ==> Activation: MAIN::peindre-sol : f-5 Peint murs et plafonds FIRE 2 MAIN::fournir-poser-papier-peint f-5 ==> f-6 (MAIN::papierPeint pose) ==> Activation: MAIN::peindre-sol : f-6 Fourniture et pose des Papiers Peint FIRE 3 MAIN::peindre-sol f-6 ==> f-7 (MAIN::sol peint) ==> Activation: MAIN::fournir-poser-moquette : f-7, f-5 ==> Activation: MAIN::fournir-poser-moquette : f-7, f-6 Peint le sol FIRE 4 MAIN::fournir-poser-moquette f-7, f-6 ==> f-8 (MAIN::moquette pose) Fourniture et pose de moquette FIRE 5 MAIN::fournir-poser-moquette f-7, f-5 Fourniture et pose de moquette FIRE 6 MAIN::peindre-sol f-5 Peint le sol <== Focus MAIN 6 Jess> Thank you!!! Daniela To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED]