Re: JESS: Which comes first, the chicken or the rule?
I would say that if you reorganized the facts and get a different answer and/or reorganize your rules and get a different answer, your inference engine is not valid. I worked on a pagination app that provided the xy coords for the layout of each page. Certainly all of the facts were already there, text, graphics, etc. The rules nibbled away 8 pages at a time, when it had 10 scores for each page it took the highest and get then worked on the next pages. I tneeded many facts in advance but it didn't make sense to paginate dozens of pages forward. It was the controll facts at runtime that made the rules fire correctly. The inference engine went into phases, facts asserted by rules. It was that controll that made this work. Not whether rules or facts are loaded in any certain order. But yeah I have no idea if that was good form? later -- !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN html head meta http-equiv=Content-Type Content=text/html; charset=iso-8859-1 /head bodya href=http://jakarta.apache.org/tapestry/;img src=http://howardlewisship.com/images/no-struts.png; width=200 height=154 alt=Friends Don't Let Friends Code Struts border=0//a /body /html Matthew Hutchinson [EMAIL PROTECTED] wrote: Hi everyone, Just a conceptual question... since starting with Jess, it always seemed to me generally you have the rules established first, then load in facts which in turn trigger these rules. No problems there. But is it proper to consider having the facts already in memory and *then* adding rules which I know will trigger - basically a sort of query on the data mentality? Is this a bad concept? Cheers, Matt -- Matthew Hutchinson Ph.D. Candidate Department of Spatial Sciences Curtin University of Technology GPO Box U1987 Perth, Western Australia 6845 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: Which comes first, the chicken or the rule?
I think Matthew Hutchinson wrote: Just a conceptual question... since starting with Jess, it always seemed to me generally you have the rules established first, then load in facts which in turn trigger these rules. No problems there. But is it proper to consider having the facts already in memory and *then* adding rules which I know will trigger - basically a sort of query on the data mentality? Is this a bad concept? Jess will work either way; you can even add rules to a running program. But in general, Jess is designed with the rules, then facts paradigm in mind. For a given collection of facts and rules, defining the rules first, then populating working memory will be faster than doing thing the other way around -- but both ways are correct and will work fine. - Ernest Friedman-Hill Advanced Software Research Phone: (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: Which comes first, the chicken or the rule?
If I understand what you are doing, you probably have some legacy data from which to work. If that's the case, don't even look at the legacy data until you have determined the rule logic. Then decide what data would be necessary to support that logic. If the data exist (or if most of it exists) within the legacy system, it shouldn't be too hard to convince management that you need just a few extra attributes or tables in the existing database. However, if there are drastic changes, then perhaps you can pull the legacy data down to your Unix or (God forbid!) Windows platform and add what you need at that point. The last solution is usually what happens on most projects. On the other hand, Dr. Friedman-Hill is correct in that you can always add rules (assuming that the data are there to support the rules) or even add rules and objects later. And this is also what normally happens on most rulebased projects. Even XCON started with only a few hundred rules, grew to over 1,000 the first year or so and then past 10,000 rules within a few years as more and more rule modules (sets) were added. If you are working on an enterprise project, probably the best thing is to do a pilot project with a few hundred rules, a few (less than 50 normally) objects and do an end-to- end implementation. Be sure to involve the highest level of management (for approvals and support) and the lowest levels of users (to be sure that it works correctly and will be widely accepted) along the way. Then grow gradually, not by leaps and bounds. Bon Chance! SDG jco James C. Owen Senior Consultant [EMAIL PROTECTED] http://www.kbsc.com Never give up. Never give up. Never, never, never give up. From a speech by former Prime Minister, Winston Churchill, during the most trying times of the British Empire; a great leader too soon forgotten by his country after keeping it from being swallowed up by the Nazi Empire during the second world war. On Dec 13, 2005, at 8:43 AM, Matthew Hutchinson wrote: Hi everyone, Just a conceptual question... since starting with Jess, it always seemed to me generally you have the rules established first, then load in facts which in turn trigger these rules. No problems there. But is it proper to consider having the facts already in memory and *then* adding rules which I know will trigger - basically a sort of query on the data mentality? Is this a bad concept? Cheers, Matt -- Matthew Hutchinson Ph.D. Candidate Department of Spatial Sciences Curtin University of Technology GPO Box U1987 Perth, Western Australia 6845 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]
