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 -- > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
