RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
I think that James Owen wrote: As I recall, salience in rulebased programming is akin to goto statements in BASIC; a crutch for poor programming On that subject: Just as there are legitimate, structured uses for the GOTO statement in some languages, salience can be used in a structured way that doesn't violate the spirit of rule-based programming. I've spent a lot of time studying the Jess In Action sections on salience, modules, general flow control in Jess programs, and anything else I could find on the subject -- and it's all very helpful. However, ironically, I recently came across an old ART Enterprise tutorial manual (1987) that has a fantastically clear explanation of when it is proper to use salience and how to do it. (For the AI history buff: ART was one of the first commercial expert system shells and was also the progenitor of CLIPS - Jess's inspiration. See http://www.ghg.net/clips/WhatIsCLIPS.html#History ) In any case, the examples (easily extrapolated to Jess) were (quoting now): * To stratify the rule base into classes of rules dedicated to different tasks (filtering, pre-processing, etc.) * To give a very important rule priority over most other or all other rules (error conditions or alarms). * To keep a utility rule in the background until the rest of the program has run to completion (final output, re-init fact base, etc.) As far as item one goes, it's easy to implement in Jess with global variables like this: (defglobal ?*TASK_PRIORITY_1* = 500) (defglobal ?*TASK_PRIORITY_2* = 200) (defglobal ?*TASK_PRIORITY_3* = 100) (defrule foo-1 (declare (salience ?*TASK_PRIORITY_1*)) ... = ... ) (defrule foo-2 (declare (salience ?*TASK_PRIORITY_2*)) ... = ... ) and so on. Again, this would be for controlling layers of rules that sort of swarm on completing one complex task at a time. One other technique that I've been practicing is the notion of LHS Control Patterns (LHSCP), that is asserting and retracting ordered facts (triggers) to enable or disable large groups of rules simultaneously. In other words, in a rule having the LHSCP, if that control fact is not present in working memory, then that rule (and all rules of its kind) are essentially disabled until reactivated by the assertion or modification of that control fact or facts. This seems to handle a wide range of control problems without, again, violating the rule-based paradigm. However, there was no mention of (defmodule) in ART in '87 -- although CLIPS has had it for awhile now -- so maybe even the structured use of salience is dated. Clearly Dr. Friedman-Hill prefers a modular approach in JIA -- changing the focus of modules to control activations of groups of rules -- and that certainly seems the best way to go for most Jess applications. BTW - Examples of creative uses of salience or other control mechanism in Jess would be much appreciated. -JM Jason Morris Morris Technical Solutions [EMAIL PROTECTED] www.morristechnicalsolutions.com fax/phone: 503.692.1088 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]
Re: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
I'm sorry - I just can not resist the temptation to jump in here. It would seem to me, that no matter which technique is used to modularlize the execution of rules (rule sets) whether it be control flags, priorities, etc., the ultimate challenge of applying any control flow architecture will be to deal with the work-flow related aspects. In other words, I may have a requirement to build a tree of of independently executing rules (since the rule execution my be IMPLICITLY parallel) and see which successfully completes (as in rule flow A or rule flow B) and use that to move higher up in my tree of goals. In effect, I am trying to create a multi-threaded procedural control which matches the classical definitions of work flow with its forks and joins of independent processes. How I engineer the control (in either the determistic or non-deterministic layer) is secondary to achieving a control flow architecture which determines which rule sets are eligible to execute. - Original Message - From: Jason Morris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 28, 2004 10:13 AM Subject: RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS] I think that James Owen wrote: As I recall, salience in rulebased programming is akin to goto statements in BASIC; a crutch for poor programming On that subject: Just as there are legitimate, structured uses for the GOTO statement in some languages, salience can be used in a structured way that doesn't violate the spirit of rule-based programming. I've spent a lot of time studying the Jess In Action sections on salience, modules, general flow control in Jess programs, and anything else I could find on the subject -- and it's all very helpful. However, ironically, I recently came across an old ART Enterprise tutorial manual (1987) that has a fantastically clear explanation of when it is proper to use salience and how to do it. (For the AI history buff: ART was one of the first commercial expert system shells and was also the progenitor of CLIPS - Jess's inspiration. See http://www.ghg.net/clips/WhatIsCLIPS.html#History ) In any case, the examples (easily extrapolated to Jess) were (quoting now): * To stratify the rule base into classes of rules dedicated to different tasks (filtering, pre-processing, etc.) * To give a very important rule priority over most other or all other rules (error conditions or alarms). * To keep a utility rule in the background until the rest of the program has run to completion (final output, re-init fact base, etc.) As far as item one goes, it's easy to implement in Jess with global variables like this: (defglobal ?*TASK_PRIORITY_1* = 500) (defglobal ?*TASK_PRIORITY_2* = 200) (defglobal ?*TASK_PRIORITY_3* = 100) (defrule foo-1 (declare (salience ?*TASK_PRIORITY_1*)) ... = ... ) (defrule foo-2 (declare (salience ?*TASK_PRIORITY_2*)) ... = ... ) and so on. Again, this would be for controlling layers of rules that sort of swarm on completing one complex task at a time. One other technique that I've been practicing is the notion of LHS Control Patterns (LHSCP), that is asserting and retracting ordered facts (triggers) to enable or disable large groups of rules simultaneously. In other words, in a rule having the LHSCP, if that control fact is not present in working memory, then that rule (and all rules of its kind) are essentially disabled until reactivated by the assertion or modification of that control fact or facts. This seems to handle a wide range of control problems without, again, violating the rule-based paradigm. However, there was no mention of (defmodule) in ART in '87 -- although CLIPS has had it for awhile now -- so maybe even the structured use of salience is dated. Clearly Dr. Friedman-Hill prefers a modular approach in JIA -- changing the focus of modules to control activations of groups of rules -- and that certainly seems the best way to go for most Jess applications. BTW - Examples of creative uses of salience or other control mechanism in Jess would be much appreciated. -JM Jason Morris Morris Technical Solutions [EMAIL PROTECTED] www.morristechnicalsolutions.com fax/phone: 503.692.1088 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] 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]
RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
I think that Rich Halsey wrote: How I engineer the control (in either the determistic or non-deterministic layer) is secondary to achieving a control flow architecture which determines which rule sets are eligible to execute. Rich, No argument here: I think that it's understood that developers are not so concerned with the firing of individual rules so much as the switching between groups of rules to perform a component task that may have many individual sub-tasks. My point was that salience, diligently applied, still has its uses and ought not be automatically disparaged. -JM Jason Morris Morris Technical Solutions [EMAIL PROTECTED] www.morristechnicalsolutions.com fax/phone: 503.692.1088 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rich Halsey Sent: Friday, May 28, 2004 9:02 AM To: [EMAIL PROTECTED] Subject: Re: JESS: Re: your mail [REGARDING SALIENCE IN JESS] I'm sorry - I just can not resist the temptation to jump in here. It would seem to me, that no matter which technique is used to modularlize the execution of rules (rule sets) whether it be control flags, priorities, etc., the ultimate challenge of applying any control flow architecture will be to deal with the work-flow related aspects. In other words, I may have a requirement to build a tree of of independently executing rules (since the rule execution my be IMPLICITLY parallel) and see which successfully completes (as in rule flow A or rule flow B) and use that to move higher up in my tree of goals. In effect, I am trying to create a multi-threaded procedural control which matches the classical definitions of work flow with its forks and joins of independent processes. How I engineer the control (in either the determistic or non-deterministic layer) is secondary to achieving a control flow architecture which determines which rule sets are eligible to execute. - Original Message - From: Jason Morris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 28, 2004 10:13 AM Subject: RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS] I think that James Owen wrote: As I recall, salience in rulebased programming is akin to goto statements in BASIC; a crutch for poor programming On that subject: Just as there are legitimate, structured uses for the GOTO statement in some languages, salience can be used in a structured way that doesn't violate the spirit of rule-based programming. I've spent a lot of time studying the Jess In Action sections on salience, modules, general flow control in Jess programs, and anything else I could find on the subject -- and it's all very helpful. However, ironically, I recently came across an old ART Enterprise tutorial manual (1987) that has a fantastically clear explanation of when it is proper to use salience and how to do it. (For the AI history buff: ART was one of the first commercial expert system shells and was also the progenitor of CLIPS - Jess's inspiration. See http://www.ghg.net/clips/WhatIsCLIPS.html#History ) In any case, the examples (easily extrapolated to Jess) were (quoting now): * To stratify the rule base into classes of rules dedicated to different tasks (filtering, pre-processing, etc.) * To give a very important rule priority over most other or all other rules (error conditions or alarms). * To keep a utility rule in the background until the rest of the program has run to completion (final output, re-init fact base, etc.) As far as item one goes, it's easy to implement in Jess with global variables like this: (defglobal ?*TASK_PRIORITY_1* = 500) (defglobal ?*TASK_PRIORITY_2* = 200) (defglobal ?*TASK_PRIORITY_3* = 100) (defrule foo-1 (declare (salience ?*TASK_PRIORITY_1*)) ... = ... ) (defrule foo-2 (declare (salience ?*TASK_PRIORITY_2*)) ... = ... ) and so on. Again, this would be for controlling layers of rules that sort of swarm on completing one complex task at a time. One other technique that I've been practicing is the notion of LHS Control Patterns (LHSCP), that is asserting and retracting ordered facts (triggers) to enable or disable large groups of rules simultaneously. In other words, in a rule having the LHSCP, if that control fact is not present in working memory, then that rule (and all rules of its kind) are essentially disabled until reactivated by the assertion or modification of that control fact or facts. This seems to handle a wide range of control problems without, again, violating the rule-based paradigm. However, there was no mention of (defmodule) in ART in '87 -- although CLIPS has had it for awhile now -- so maybe even the structured use of salience is dated. Clearly Dr. Friedman-Hill prefers a modular approach in JIA -- changing the focus of modules to control activations of groups of rules
RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
Let me jump in just for fun here as well. The old ART (original flavour of the mid 80's that Jason refers to) had something called viewpoints that allowed one to explore multiple lines of reasoning at once. It could, I imagine, have been suitable for today's distributed computing environments or such. But it dealt with these 'threads' of reasoning quite well allowing one to 'poison' a viewpoint if it was no longer useful, etc. It's too long ago and I don't remember all the details. It was dropped from future versions of ART in the interest of efficiency ... or perhaps because it was too advanced for or of limited use to users of the time. One of the people in a project I was working on several years ago implemented an interesting support for finite state machines using ART Enterprise's (the latest version of ART) equivalent of Jess's modules. We used this to control our movement from state to state so that certain rules sets were enabled at appropriate times. It was a bit of overkill for the project (we could have just used the modules I think) but it had a lot of flexibility for controlling things in a rule based system. I'm showing my age ... Bob Orchard National Research Council CanadaConseil national de recherches Canada Institute for Information TechnologyInstitut de technologie de l'information 1200 Montreal Road, Building M-50 M50, 1200 chemin Montrial Ottawa, ON, Canada K1A 0R6 Ottawa (Ontario) Canada K1A 0R6 (613) 993-8557 (613) 952-0215 Fax / tilicopieur [EMAIL PROTECTED] Government of Canada | Gouvernement du Canada -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rich Halsey Sent: Friday, May 28, 2004 12:02 PM To: [EMAIL PROTECTED] Subject: Re: JESS: Re: your mail [REGARDING SALIENCE IN JESS] I'm sorry - I just can not resist the temptation to jump in here. It would seem to me, that no matter which technique is used to modularlize the execution of rules (rule sets) whether it be control flags, priorities, etc., the ultimate challenge of applying any control flow architecture will be to deal with the work-flow related aspects. In other words, I may have a requirement to build a tree of of independently executing rules (since the rule execution my be IMPLICITLY parallel) and see which successfully completes (as in rule flow A or rule flow B) and use that to move higher up in my tree of goals. In effect, I am trying to create a multi-threaded procedural control which matches the classical definitions of work flow with its forks and joins of independent processes. How I engineer the control (in either the determistic or non-deterministic layer) is secondary to achieving a control flow architecture which determines which rule sets are eligible to execute. - Original Message - From: Jason Morris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 28, 2004 10:13 AM Subject: RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS] I think that James Owen wrote: As I recall, salience in rulebased programming is akin to goto statements in BASIC; a crutch for poor programming On that subject: Just as there are legitimate, structured uses for the GOTO statement in some languages, salience can be used in a structured way that doesn't violate the spirit of rule-based programming. I've spent a lot of time studying the Jess In Action sections on salience, modules, general flow control in Jess programs, and anything else I could find on the subject -- and it's all very helpful. However, ironically, I recently came across an old ART Enterprise tutorial manual (1987) that has a fantastically clear explanation of when it is proper to use salience and how to do it. (For the AI history buff: ART was one of the first commercial expert system shells and was also the progenitor of CLIPS - Jess's inspiration. See http://www.ghg.net/clips/WhatIsCLIPS.html#History ) In any case, the examples (easily extrapolated to Jess) were (quoting now): * To stratify the rule base into classes of rules dedicated to different tasks (filtering, pre-processing, etc.) * To give a very important rule priority over most other or all other rules (error conditions or alarms). * To keep a utility rule in the background until the rest of the program has run to completion (final output, re-init fact base, etc.) As far as item one goes, it's easy to implement in Jess with global variables like this: (defglobal ?*TASK_PRIORITY_1* = 500) (defglobal ?*TASK_PRIORITY_2* = 200) (defglobal ?*TASK_PRIORITY_3* = 100) (defrule foo-1 (declare (salience ?*TASK_PRIORITY_1*)) ... = ... ) (defrule foo-2 (declare (salience ?*TASK_PRIORITY_2*)) ... = ... ) and so on. Again, this would be for controlling layers of rules that sort of swarm on completing one complex task at a time. One other technique that I've been practicing is the notion of LHS Control Patterns (LHSCP), that is asserting and retracting
Re: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
It is always a pleasure to reply to Bob Orchard !! To be a little more specific, a gentleman by the name of Dracos Manolescu published some work entitled A Micro-Workflow along with a Java-based system. As I read his papers (?) and looked at his Java examples, I came away with a much clearer view of what it would take to craft rule flow in the form of an architectural control flow, i.e., laying a procedural control layer on top of rule sets. At this point, I have done this type of control flow with rule engines other than JESS and I intend to do it in JESS in the not too distant future. However the technique that I have evolved can not be called intuitively obvious yet - it is basically a tree of Java data structures that are asserted into the working memory to make up sub-goals of a goal tree. But, by doing it this way I really do get the implicitly parallel effect that I want - unfortunately, one rule engine from a BIG vendor requires each flow path to be executed to completion BEFORE it allows anything else to happen, so I don't consider this to be implicitly parallel execution of rules and goals. My main point to all of this is that we first need an archtecture for rule/work flow and then we can worry about the implementation via control flags, priorities, etc.. I see them as secondary in importance. - Original Message - From: Orchard, Bob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 28, 2004 11:55 AM Subject: RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS] Let me jump in just for fun here as well. The old ART (original flavour of the mid 80's that Jason refers to) had something called viewpoints that allowed one to explore multiple lines of reasoning at once. It could, I imagine, have been suitable for today's distributed computing environments or such. But it dealt with these 'threads' of reasoning quite well allowing one to 'poison' a viewpoint if it was no longer useful, etc. It's too long ago and I don't remember all the details. It was dropped from future versions of ART in the interest of efficiency ... or perhaps because it was too advanced for or of limited use to users of the time. One of the people in a project I was working on several years ago implemented an interesting support for finite state machines using ART Enterprise's (the latest version of ART) equivalent of Jess's modules. We used this to control our movement from state to state so that certain rules sets were enabled at appropriate times. It was a bit of overkill for the project (we could have just used the modules I think) but it had a lot of flexibility for controlling things in a rule based system. I'm showing my age ... Bob Orchard National Research Council Canada Conseil national de recherches Canada Institute for Information Technology Institut de technologie de l'information 1200 Montreal Road, Building M-50 M50, 1200 chemin Montrial Ottawa, ON, Canada K1A 0R6 Ottawa (Ontario) Canada K1A 0R6 (613) 993-8557 (613) 952-0215 Fax / tilicopieur [EMAIL PROTECTED] Government of Canada | Gouvernement du Canada -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rich Halsey Sent: Friday, May 28, 2004 12:02 PM To: [EMAIL PROTECTED] Subject: Re: JESS: Re: your mail [REGARDING SALIENCE IN JESS] I'm sorry - I just can not resist the temptation to jump in here. It would seem to me, that no matter which technique is used to modularlize the execution of rules (rule sets) whether it be control flags, priorities, etc., the ultimate challenge of applying any control flow architecture will be to deal with the work-flow related aspects. In other words, I may have a requirement to build a tree of of independently executing rules (since the rule execution my be IMPLICITLY parallel) and see which successfully completes (as in rule flow A or rule flow B) and use that to move higher up in my tree of goals. In effect, I am trying to create a multi-threaded procedural control which matches the classical definitions of work flow with its forks and joins of independent processes. How I engineer the control (in either the determistic or non-deterministic layer) is secondary to achieving a control flow architecture which determines which rule sets are eligible to execute. - Original Message - From: Jason Morris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 28, 2004 10:13 AM Subject: RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS] I think that James Owen wrote: As I recall, salience in rulebased programming is akin to goto statements in BASIC; a crutch for poor programming On that subject: Just as there are legitimate, structured uses for the GOTO statement in some languages, salience can be used in a structured way that doesn't violate the spirit of rule-based programming. I've spent a lot of time studying the Jess In Action sections on salience, modules, general
RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
Footnote The ART manual that I ...came across was graciously donated to my cause by Bob Orchard. Bob: I know I should have grabbed the Viewpoint manual, too! :-D Given the pace of programming evolution, it's comforting to know that study of something twenty years old (ART) can still give insight into programming something modern (Jess) better. -JM 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]
Re: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
Just a side note here: It is most refreshing to see the big guns weigh in with their thoughts and references. While some of it may be extraneous rabbit trails it is, nevertheless, enlightening. I realize that the Jess email list is supposed to be dedicated to solving the so-called real world problems, but when folks like Bob, Jason, Rich and Ernest begin to philosophize and wax rhetoric - well, I think it gives us a sense of history that, in the words of (was it Einstein?) We stand on the shoulders of Giants. So much has gone before us that is still valid and, in effect, gives us the insight, sometimes, to help mold our minds to the process, or the why, rather than the how. And, while I love just to sit in the background and read these insightful discourses, it's back to work to work for the plebeians such as me. (Such as I?) whatever... :-) SDG jco 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]
RE: JESS: Re: your mail [REGARDING SALIENCE IN JESS]
If I have been able to see further, it was only because I stood on the shoulders of giants. Sir Isaac Newton It's fun to wonder what a guy like Newton would have done with a tool like Java or Jess. Would Newton have been a programmer? I think he'd have been fascinated by exploring his ideas numerically. -JM Jason Morris Morris Technical Solutions [EMAIL PROTECTED] www.morristechnicalsolutions.com fax/phone: 503.692.1088 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of James Owen Sent: Friday, May 28, 2004 11:16 AM To: [EMAIL PROTECTED] Subject: Re: JESS: Re: your mail [REGARDING SALIENCE IN JESS] Just a side note here: It is most refreshing to see the big guns weigh in with their thoughts and references. While some of it may be extraneous rabbit trails it is, nevertheless, enlightening. I realize that the Jess email list is supposed to be dedicated to solving the so-called real world problems, but when folks like Bob, Jason, Rich and Ernest begin to philosophize and wax rhetoric - well, I think it gives us a sense of history that, in the words of (was it Einstein?) We stand on the shoulders of Giants. So much has gone before us that is still valid and, in effect, gives us the insight, sometimes, to help mold our minds to the process, or the why, rather than the how. And, while I love just to sit in the background and read these insightful discourses, it's back to work to work for the plebeians such as me. (Such as I?) whatever... :-) SDG jco 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] 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]
