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