Re: rule repositories [was: Re: JESS: XML, Java and Rules]
[EMAIL PROTECTED] wrote, On 01/06/2003 11:07 AM: Hello Larry, [snip] Would you be so kind to point me out XSLT file for converting DSML to JESS (as example)? Thanks in advance. To avoid cluttering this list with XMLishness, I replied privately to Ru's request. -- -- #::| # Larry Bartz | | # [EMAIL PROTECTED] | Ooo, ooo,| # | Ooo, ooo, oo!| # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::| 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: possible typo with animal.clp
Hi Wiiliam/Peter, This bug was reported against 6.1a2 by Scott Trackman and was fixed in 6.1a3. The workaround if you can't upgrade is to specify the module names explicitly: (save-facts "animal.dat" MAIN::node MAIN::next-gensym-idx)) I think Wiiliam Blake wrote: > > I just an the stock animal.clp example that ships with > Jess6.0 and noticed odd behavior. The rule runs just > fine, but when I answer no to "try again", it doesn't > correctly save the facts I've added. It ends up wiping > the file so that it is empty. > > if I change: > > (save-facts "animal.dat" node next-gensym-idx)) > > to > > (save-facts "animal.dat")) > > it correctly saves the file. > > > peter > - Ernest Friedman-Hill Distributed Systems ResearchPhone: (925) 294-2154 Sandia National LabsFAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov 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: Proposed feature
I think Prof. Michael Stiber wrote: > Please pardon me if I missed part of this discussion by overzealous email > deletions (holiday email cleanup), but is this property more appropriately > attached to the fact, rather than the rule (as is "logical")? In the example > below, the "count" template could be marked so that changes to it won't > re-activate any rules. This seems to match the intuition that the "count" > template below is a different _kind_ of fact than the "x" one. Well, first, yes, you're right, that's an interesting alternative way to express this -- a (single) or (one-shot) conditional element that would apply to patterns within a rule. That would give finer grained control at the expense of a little overhead for every rule (whether it used this feature or not.) In the rule below, though, you'd actually want to mark the first pattern, not the second, yes? You'd want the rule to fire many times for the single (count) fact, but only once for the (x) fact, even when the (x)'s slots were modified. > > On 1/5/03 4:01 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > >>> (defrule count-x-facts > >>> (declare (one-shot TRUE)) > >>> (x) > >>> ?count <- (count (x ?n)) > >>> => > >>> (modify ?count (x (+ ?n 1 - Ernest Friedman-Hill Distributed Systems ResearchPhone: (925) 294-2154 Sandia National LabsFAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov 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]
JESS: possible typo with animal.clp
I just an the stock animal.clp example that ships with Jess6.0 and noticed odd behavior. The rule runs just fine, but when I answer no to "try again", it doesn't correctly save the facts I've added. It ends up wiping the file so that it is empty. if I change: (save-facts "animal.dat" node next-gensym-idx)) to (save-facts "animal.dat")) it correctly saves the file. peter __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com 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: Proposed feature
Ouch! Right! What a way to start the New Year! In all of my previous emails please replace "recursion" with "refraction" - recursion is the self-addressing behavior of an algorithm. By way of explanation, I had been reading on the recursive principles of Rete that same day. I could blame it all on having a "senior moment" except that this has been happening since I was 13 years old, or somewhere near the beginning of puberty. :-) Thanks for the clarification. SDG jco Paul Haley wrote: > FYI, the term "refraction" is traditional for the act of removing an > activation of a rule from the conflict set upon its execution. > > Paul Haley > President & CEO > The Haley Enterprise, Inc. > http://www.haley.com > (412) 741-6420 > Solutions that do what they're told. > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, January 05, 2003 12:57 PM > > To: [EMAIL PROTECTED] > > Subject: Re: JESS: Proposed feature > > > > > > I think James C. Owen wrote: > > > Ernest: > > > > > > Let me see if I can understand what we're actually saying here: As > > > written below, since ?fact is being modified in the RHS of the rule > > > then the rule will be placed on the agenda as available to be fired > > > again, even though the recursion principle would otherwise have > > > removed the rule from consideration.. This is basically the > > > data-driven concept of almost all Rete-type rulebased > > systems and some > > > that are not Rete-based. In fact, the rule will be removed > > (via the > > > recursion principle) from the agenda and never be replaced > > if the rule > > > fires and the data are NOT changed. Recursion is the first rule of > > > conflict resolution of both LEX and MEA and is used by, well, > > > everybody who builds a rulebased system of any kind of > > merit. (Jess, > > > JRules, OPSJ, JEOPS, Advisor, Expert, ART, etc., etc.) > > > > That's right. The current behavior in all cases is that a > > rule won't fire on a given set of unchanged facts more than once. > > > > > > > > So. Now. Are we asking that this should be changed so that if the > > > rules are slot-driven rather than data-driven,? Meaning > > that the rule > > > will be removed if the rule, regardless of data, fires? If so, it > > > can't work because then only one case would match. i.e., > > we would be > > > asking the question, "Is there ANY case" and when the case > > is answered > > > true then the engine stops. > > > > No, not quite. The proposal is for a new, special class of > > rules that will fire no more than once for a given set of > > facts, regardless of whether their slot data changes. > > Currently, modifying any slot in a fact on a rule's RHS will > > make the LHS match again. Under this proposal, this wouldn't > > happen for this special class of rules. > > > > In classical expert systems, facts were just tuples, without > > their own independent existence. In Jess, a fact is a lot > > more like an Object, and it persists over time. Note that in > > OPS-derived systems, where each fact has a numeric id, that > > id traditionally changed when a fact was modified. In Jess, > > the id -doesn't- change, highlighting the Object-ness of a fact. > > > > In a way, there are two different ways to think about Jess > > rules. You can be matching a fact with particular slot data, > > or you can be matching a particular fact object. The latter > > class of rules can sensibly be expected to match a given fact > > (or set of facts) only once; that's the class of rules for > > which the "one-shot" idea is useful. > > > > > > - > > Ernest Friedman-Hill > > Distributed Systems ResearchPhone: (925) 294-2154 > > Sandia National LabsFAX: (925) 294-2234 > > PO Box 969, MS 9012 [EMAIL PROTECTED] > > Livermore, CA 94550 http://herzberg.ca.sandia.gov > > > > > > 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] > -- SDG jco - James C. Owen Senior KE Knowledgebased Systems Corporation 6314 Kelly Circle Garland, TX 75044 972.530.2895 To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message
Re: JESS: Re: Proposed feature
Please pardon me if I missed part of this discussion by overzealous email deletions (holiday email cleanup), but is this property more appropriately attached to the fact, rather than the rule (as is "logical")? In the example below, the "count" template could be marked so that changes to it won't re-activate any rules. This seems to match the intuition that the "count" template below is a different _kind_ of fact than the "x" one. On 1/5/03 4:01 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > But you seem to be ignoring the whole problem, the "refractoriness" > problem, I think you might call it. Show me how, using Jess's current > semantics, you might accomplish what this rule (using the new feature) > does: > >>> (defrule count-x-facts >>> (declare (one-shot TRUE)) >>> (x) >>> ?count <- (count (x ?n)) >>> => >>> (modify ?count (x (+ ?n 1 > > (keeping in mind that the "x" template has forty-seven slots that are > constantly being modified by unrelated rules) and then explain to me > why it's better. > > I think James C. Owen wrote: >> OK, now that we're off and running, one-shot seems like it would work for a >> limited set of circumstances. However, if we use goal-oriented programming >> then we don't need a special set of rules or objects. If we have a specific >> goal and the goal exists THEN we do either one or two things: >> >> 1. If we want to know only that there exists at least one instance of a set >> of circumstances, then the RHS would retract that goal and either assert >> another or let the last goal have predominance on the conflict resolution >> table. >> >> 2. If we want to do something for all of the instances, don't retract the >> goal. Just let nature take it's course and do the same thing for all >> instances of that particular situation. >> >> As has been stated so many times, "Folks, this stuff ain't rocket science. >> It's just logic. And if Psychologists, Business Analysts and Doctors with >> not >> computer training at all can understand this and write decent programs (after >> a year or two of working with it) then any half-fast programmer SURELY can >> understand how to adjust to a given set of circumstances for a certain set of >> rules." Well, actually, that's my favorite quote. It follows the old KISS >> principle. >> >> SDG >> jco >> > > - > Ernest Friedman-Hill > Distributed Systems ResearchPhone: (925) 294-2154 > Sandia National LabsFAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550 http://herzberg.ca.sandia.gov > > > 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] > > > -- Prof. Michael Stiber[EMAIL PROTECTED] Computing and Software Systems http://faculty.washington.edu/stiber University of Washington, Bothell tel: +1-425-352-5280 Box 358534, 18115 Campus Way NE fax: +1-425-352-5216 Bothell, WA 98011-8246 USA 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: Proposed feature
FYI, the term "refraction" is traditional for the act of removing an activation of a rule from the conflict set upon its execution. Paul Haley President & CEO The Haley Enterprise, Inc. http://www.haley.com (412) 741-6420 Solutions that do what they're told. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 05, 2003 12:57 PM > To: [EMAIL PROTECTED] > Subject: Re: JESS: Proposed feature > > > I think James C. Owen wrote: > > Ernest: > > > > Let me see if I can understand what we're actually saying here: As > > written below, since ?fact is being modified in the RHS of the rule > > then the rule will be placed on the agenda as available to be fired > > again, even though the recursion principle would otherwise have > > removed the rule from consideration.. This is basically the > > data-driven concept of almost all Rete-type rulebased > systems and some > > that are not Rete-based. In fact, the rule will be removed > (via the > > recursion principle) from the agenda and never be replaced > if the rule > > fires and the data are NOT changed. Recursion is the first rule of > > conflict resolution of both LEX and MEA and is used by, well, > > everybody who builds a rulebased system of any kind of > merit. (Jess, > > JRules, OPSJ, JEOPS, Advisor, Expert, ART, etc., etc.) > > That's right. The current behavior in all cases is that a > rule won't fire on a given set of unchanged facts more than once. > > > > > So. Now. Are we asking that this should be changed so that if the > > rules are slot-driven rather than data-driven,? Meaning > that the rule > > will be removed if the rule, regardless of data, fires? If so, it > > can't work because then only one case would match. i.e., > we would be > > asking the question, "Is there ANY case" and when the case > is answered > > true then the engine stops. > > No, not quite. The proposal is for a new, special class of > rules that will fire no more than once for a given set of > facts, regardless of whether their slot data changes. > Currently, modifying any slot in a fact on a rule's RHS will > make the LHS match again. Under this proposal, this wouldn't > happen for this special class of rules. > > In classical expert systems, facts were just tuples, without > their own independent existence. In Jess, a fact is a lot > more like an Object, and it persists over time. Note that in > OPS-derived systems, where each fact has a numeric id, that > id traditionally changed when a fact was modified. In Jess, > the id -doesn't- change, highlighting the Object-ness of a fact. > > In a way, there are two different ways to think about Jess > rules. You can be matching a fact with particular slot data, > or you can be matching a particular fact object. The latter > class of rules can sensibly be expected to match a given fact > (or set of facts) only once; that's the class of rules for > which the "one-shot" idea is useful. > > > - > Ernest Friedman-Hill > Distributed Systems ResearchPhone: (925) 294-2154 > Sandia National LabsFAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550 http://herzberg.ca.sandia.gov > > > 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: Proposed feature
Ernest: What I have done in the past is to establish a Goal object to control "rule flow" such that we assert the Goal objects in the reverse order of rule flow so that the last asserted Goal will be examined first. This lets the rules control the flow using the recency of the Goals. If I want to establish that at least one instance of the object (a Platinum loan, for example) exists (don't care how many) then I retract that Goal on the RHS of the rule and the next Goal is examined. If I want to do something with all of the instances of the object, then I don't put the retract in the RHS of the rule. For example, let's say that I wanted a general set of rules such that certain things would be done for all Platinum account holders and another set of rules such that certain things would be done for all of the Platinum accounts. In the first instance, I only need to know that the customer has at least one Platinum account. In the second, I might want to do something special for each Platinum account. First, "assert" all of the Account, Party and the Goal objects that you want to process using the procedure above for the Goal objects. The last Goal asserted looks for PLATINUM accounts. In the first case above, the RHS of the rule would "retract" the Goal of looking for a Platinum account when it found the first instance. The rules would then move on to the next goal. In the second case, you would establish a subset of those Platinum accounts and further process them depending on the next-to-last Goal asserted. Just depends on what the situation calls for. I've used this procedure on my past projects and it seems to work quite well. I really like to use this Goal-oriented or Goal-driven process whenever I'm doing anything like configuration management, pricing, diagnosis, etc. Seems to work "almost" like the old backward chaining process but with just a couple of twists that you have to iron out. SDG jco [EMAIL PROTECTED] wrote: > But you seem to be ignoring the whole problem, the "refractoriness" > problem, I think you might call it. Show me how, using Jess's current > semantics, you might accomplish what this rule (using the new feature) > does: > > > > (defrule count-x-facts > > > (declare (one-shot TRUE)) > > > (x) > > > ?count <- (count (x ?n)) > > > => > > > (modify ?count (x (+ ?n 1 > > (keeping in mind that the "x" template has forty-seven slots that are > constantly being modified by unrelated rules) and then explain to me > why it's better. > > I think James C. Owen wrote: > > OK, now that we're off and running, one-shot seems like it would work for a > > limited set of circumstances. However, if we use goal-oriented programming > > then we don't need a special set of rules or objects. If we have a specific > > goal and the goal exists THEN we do either one or two things: > > > > 1. If we want to know only that there exists at least one instance of a set > > of circumstances, then the RHS would retract that goal and either assert > > another or let the last goal have predominance on the conflict resolution > > table. > > > > 2. If we want to do something for all of the instances, don't retract the > > goal. Just let nature take it's course and do the same thing for all > > instances of that particular situation. > > > > As has been stated so many times, "Folks, this stuff ain't rocket science. > > It's just logic. And if Psychologists, Business Analysts and Doctors with not > > computer training at all can understand this and write decent programs (after > > a year or two of working with it) then any half-fast programmer SURELY can > > understand how to adjust to a given set of circumstances for a certain set of > > rules." Well, actually, that's my favorite quote. It follows the old KISS > > principle. > > > > SDG > > jco > > > > - > Ernest Friedman-Hill > Distributed Systems ResearchPhone: (925) 294-2154 > Sandia National LabsFAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550http://herzberg.ca.sandia.gov > > > 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] > -- SDG jco - James C. Owen Senior KE Knowledgebased Systems Corporation 6314 Kelly Circle Garland, TX 75044 972.530.2895 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: rule repositories [was: Re: JESS: XML, Java and Rules]
Hello Larry, Monday, January 06, 2003, 6:34:41 PM, you wrote: LSB> James C. Owen wrote, On 01/04/2003 10:47 AM: >> LSB> [snip] >> Anyway, regarding XML and rules: Both JRules and Advisor state that >> they have an XML Rule Repository. Well, actually, they have a >> "repository" of rules in XML, but I wouldn't exactly call it a true >> Rule Repository - not in the sense that Rick at EZ-Xpert sets up and >> defines a Rule Repository. LSB> [snip] LSB> I keep my rulebase in the Directory (LDAP and/or X.500), using this LSB> schema: LSB> http://www.ietf.org/internet-drafts/draft-bartz-lsb-policy-rule-components-00.txt LSB> When it's time to load rules into the rule engine, I read the rulebase LSB> from the Directory as DSML (Directory Services Markup Language, LSB> http://www.oasis-open.org/committees/dsml/ ). An XSL transformation LSB> of the DSML-encoded rulebase yields a format (such as a Jess script) LSB> which is suitable for interpretation by the rule engine. Would you be so kind to point me out XSLT file for converting DSML to JESS (as example)? Thanks in advance. -- Best regards, Rumailto:[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]
rule repositories [was: Re: JESS: XML, Java and Rules]
James C. Owen wrote, On 01/04/2003 10:47 AM: [snip] Anyway, regarding XML and rules: Both JRules and Advisor state that they have an XML Rule Repository. Well, actually, they have a "repository" of rules in XML, but I wouldn't exactly call it a true Rule Repository - not in the sense that Rick at EZ-Xpert sets up and defines a Rule Repository. [snip] I keep my rulebase in the Directory (LDAP and/or X.500), using this schema: http://www.ietf.org/internet-drafts/draft-bartz-lsb-policy-rule-components-00.txt When it's time to load rules into the rule engine, I read the rulebase from the Directory as DSML (Directory Services Markup Language, http://www.oasis-open.org/committees/dsml/ ). An XSL transformation of the DSML-encoded rulebase yields a format (such as a Jess script) which is suitable for interpretation by the rule engine. -- -- #::| # Larry Bartz | | # [EMAIL PROTECTED] | Ooo, ooo,| # | Ooo, ooo, oo!| # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::| 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: how to load mySQL driver?
I think Ye Tang wrote: > > the error message is: > Jess reported an error in routine Funcall.execute > while executing (Class.forName org.gjt.mm.mysql.Driver) > while executing (bind ?db (Class.forName org.gjt.mm.mysql.Driver)). > Message: Unimplemented function Class.forName. > > Did I miss something? You're just not using the right syntax. Two things: first, the "dot" operator is never used in Jess, and second, to call static Java methods you have to use the Jess "call" function. The correct syntax is (bind ?db (call Class forName org.gjt.mysql.Driver)) You can omit the "call" when you're calling non-static methods, i.e., (bind ?myStatement (?myConnection getStatement)) - Ernest Friedman-Hill Distributed Systems ResearchPhone: (925) 294-2154 Sandia National LabsFAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov 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]
JESS: how to load mySQL driver?
Hi, gurus: I am a newcomer. My current project involves using jess reflection capability to connect to mySQL within Jess. I could not even get the first step right. The driver is under D:\Jess60\org\gjt\mm\mysql\Driver\ and my CLASSPATH is .;%J2EE_HOME%\lib;%JAVA_HOME%\lib;C:\jdk1.1.8\lib;C:\JavaClasses;D:\Jess60; from Jess prompt I type: Jess> (bind ?db (Class.forName org.gjt.mm.mysql.Driver)) the error message is: Jess reported an error in routine Funcall.execute while executing (Class.forName org.gjt.mm.mysql.Driver) while executing (bind ?db (Class.forName org.gjt.mm.mysql.Driver)). Message: Unimplemented function Class.forName. Did I miss something? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com 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]
