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