> > David Pautler wrote: > > I'm evaluating Drools and other RMSs, looking for one that provides > > the following features: > > > > 1) Citation tracking. I need to note what articles or scenarios > > motivated a rule, and be able to provide a short description of how > > the rule supports each. This goes beyond commenting because I need to > > have access to a list of all articles and scenarios used and be able > > to jump to the rules that hang from them. > > Mark Proctor: > Not quite sure what you mean, this is an addition you want to the rule > language itself? Can you provide more details, maybe we can help you > work on this. I'm not sure if the feature belongs in the rule language or only in a RMS. Here's a description of how it would be used: 1) When creating a rule in an IDE, there would be an option to indicate the source of the rule. Specifically, there would be a pulldown menu of article titles previously used as sources, plus a way of indicating the page range within the article. 2) In addition to specifying the source, the widget would allow entering a text description. For example, the description might indicate how the syntax of the original ruleset was changed to accomodate one's own syntax. 3) As a ruleset is maintained, and one finds that rules need to be altered to fit new-found scenarios, one would want to append a new source (article or scenario) to the ones already listed for a rule. The history of sources and descriptions would really help avoid mistakes such as changing a rule to fit a new case but breaking it for older cases. 4) Whenever one wants to write a publication about the ruleset, the source histories would help a great deal in describing the intellectual history of the ruleset, not to mention in generating the bibliography. Is this the sort of detail you were looking for?

> > 2) Jess rule language. Our team has a symbolic AI background, and > > Drools' language is non-intuitive to us. It appears that Drools is > > built on Jess, and Jess' language would work much better for us. Is > > there a way to use Jess' language, including intellisense support? > > Drools is not built on Jess or related to Jess in anyway, I guessed that it was, due to listing the Jess book in your bibliography of the overview page, and there was no explanation of the relation of it to Drools.

> other than > that we all have our own implementations of the Rete algorithm and have > followed many of the features implemented in Clips, which itself was > derived from ART. The Drools DRL language itself was designed as a more > intuitive and less verbose language, this becomes increasinly important > as you start to add more complex syntax which becomes harder to read > with a lisp approach. I think most people in here would agree that the > Drools DRL approach is an improvement over the lisp approach of > clips/jess - apart from the die hard lisp fans. I'm not a die-hard Lisp fan. The CLIPS/Jess language style is just more similar to the way most people write predicate calculus formulas.

> That said I have an experimental project to provide some level of clips > support. See this blog for detalis: > http://blog.athico.com/search/label/Clips This looks very promising for us. > Drools was designed from the start to work with pojos, Jess has an > internal data structure that the pojos must be copied into. For this > reason our performance compared to Jess when working with pojos is > atleast double. Drools 5.0 also has a new more robust Rete algorithm, > that is not subject to inconsistencies affecting modify and retract, we > call this assymetrical Rete, rather than Jess' symmetrical Rete. Further > to this our Rete supports partitioning for parallel evaluation, which > was needed for our CEP work. This performance note is great info to have. If you have more details on this "inconsistency affecting modify and retract", I'd like to hear more, too.

> > 3) Export to sourceforge. Our deployments involve exporting the > > rulebase and associated citation tracking to sourceforge or google > > code. That is, we want to deploy text rather than binaries. Is there a > > better way to do this than a simple db export? > > > > I've checked the user manuals and list archives for each of these > > questions but wasn't able to answer them for myself. > > Again not really sure what you are discussing, wouldn't just putting the > .drl up at sourceforce achieve this? I'm not sure of all that goes into these DRL files...it appears that they use xml to describe the entire ruleset of a package. This would work fine for us, although we would like to have a way of associating them with the "source histories" I described above -- perhaps by using the same filename for both, in the same dir, but a different extension for the history.

> Btw if you do continue your research on Drools, I would encourage to put > your details and your research up on the Drools Research Network page, We'd be happy to do so.

> and also join the mailing list I'm already on the users list; I didn't see a research-specific one.

_______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Hi Mark, > This sounds like a really nice BRMS feature, to hold additional meta > data. As nice as it is though, it's unlikely the core team will be able > to do this at the moment as we have more basic and essential > functionality to do first, but we will work with anyone that wants to > build and submit this type of feature. > Actually, this feature is probably much needed. I have a situation with the BRMS as well, where I was using it to store pricing tables in insurance. Basically, the table was a simple look-up for so and so age and so and so gender the price(or rate) would be X.

The issue, I face right now is that I can potentially have quite a few of these tables. I did a small "test" (Not a proper benchmark, but a quick and dirty test with all dummy records) on how rules would fare with a small three column decision table of 15,000 rows, with 10 concurrent threads. The performance I found satisfactory given I was firing all 15000 rules for each of the threads. On, my PC it gave me 2.5-4 seconds, which was quite decent. However, the memory footprint of the rule-base created scared me. It was over 300 MB. This to me at least does not scale well on a production environment and we would have much more than the simple three column dummy rules I wrote for the test.

Another problem, obviously was the time it took to load the rule base(I serialized it to a file) and also the fact that I had to change the Perm-Gen Space settings to get it to work. (Since, every rule becomes a class of its own this would surely be a problem in big rule-bases).

Maybe a rules-engine is an overkill for such a simple thing but it is actually part of a much more complex underwriting and pricing algorithm. (Putting everything is rules is really elegant, but alas does not seem possible as the rule-base would become very large!!). The alternative I have thought of is to store the data like the pricing look-up table as a simple excel and then use "Rules" to extract data from it. The aim being to give the users the flexibility to change the look-up table and then to change rules. Not, sure if this is the best approach still playing around with it. In any case, I am currently still storing the data as an Excel in the BRMS but rather than using it as a rule, would use the REST API to access the Excel and process it. It is kind of hack but I am sure business users would not be able to make out the difference between a business rule asset decision table sheet and an excel sheet with just data in it. As a side note, I am not quite sure, if I can use the templating mechanism to work like this. Instead of creating separate rules for each record, the template could just process data. Hence, it would be great if all we can have is a separate tab under Rules to store "Meta-Data" and be able to access it from rules as needed. I may do this myself, but since we are taking commercial support from RedHat on Rules, I would need to clarify with them first on what the implications on support are if we change the BRMS.

Cheers, Vikrant -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor Sent: Saturday, September 27, 2008 11:48 PM To: Rules Users List Subject: Re: [rules-users] citation tracking, Jess rule language, & export to sourceforge David Pautler wrote: >>> David Pautler wrote: >>> I'm evaluating Drools and other RMSs, looking for one that provides >>> the following features: >>> >>> 1) Citation tracking. I need to note what articles or scenarios >>> motivated a rule, and be able to provide a short description of how >>> the rule supports each. This goes beyond commenting because I need to >>> have access to a list of all articles and scenarios used and be able >>> to jump to the rules that hang from them. >>> >> Mark Proctor: >> Not quite sure what you mean, this is an addition you want to the rule >> language itself? Can you provide more details, maybe we can help you >> work on this. >> > I'm not sure if the feature belongs in the rule language or only in a > RMS. > > Here's a description of how it would be used: > > 1) When creating a rule in an IDE, there would be an option to > indicate the source of the rule. Specifically, there would be a > pulldown menu of article titles previously used as sources, plus a way > of indicating the page range within the article. > > 2) In addition to specifying the source, the widget would allow > entering a text description. For example, the description might > indicate how the syntax of the original ruleset was changed to > accomodate one's own syntax. > > 3) As a ruleset is maintained, and one finds that rules need to be > altered to fit new-found scenarios, one would want to append a new > source (article or scenario) to the ones already listed for a rule. > The history of sources and descriptions would really help avoid > mistakes such as changing a rule to fit a new case but breaking it for > older cases. > > 4) Whenever one wants to write a publication about the ruleset, the > source histories would help a great deal in describing the > intellectual history of the ruleset, not to mention in generating the > bibliography. > > Is this the sort of detail you were looking for? > This sounds like a really nice BRMS feature, to hold additional meta data. As nice as it is though, it's unlikely the core team will be able to do this at the moment as we have more basic and essential functionality to do first, but we will work with anyone that wants to build and submit this type of feature. >>> 2) Jess rule language. Our team has a symbolic AI background, and >>> Drools' language is non-intuitive to us. It appears that Drools is >>> built on Jess, and Jess' language would work much better for us. Is >>> there a way to use Jess' language, including intellisense support? >>> >> Drools is not built on Jess or related to Jess in anyway, >> > I guessed that it was, due to listing the Jess book in your > bibliography of the overview page, and there was no explanation of the > relation of it to Drools. > We just listed books of interest to people with regards to expert systems. >> other than >> that we all have our own implementations of the Rete algorithm and have >> followed many of the features implemented in Clips, which itself was >> derived from ART. The Drools DRL language itself was designed as a more >> intuitive and less verbose language, this becomes increasinly important >> as you start to add more complex syntax which becomes harder to read >> with a lisp approach. I think most people in here would agree that the >> Drools DRL approach is an improvement over the lisp approach of >> clips/jess - apart from the die hard lisp fans. >> > I'm not a die-hard Lisp fan. The CLIPS/Jess language style is just > more similar to the way most people write predicate calculus formulas. > yup, that's why I started the experimentla drools-clips module that I linked to. But it needs a lot of love and am hoping someone from the community will step up to maintain this. >> That said I have an experimental project to provide some level of clips >> support. See this blog for detalis: >> http://blog.athico.com/search/label/Clips >> > This looks very promising for us. > > >> Drools was designed from the start to work with pojos, Jess has an >> internal data structure that the pojos must be copied into. For this >> reason our performance compared to Jess when working with pojos is >> atleast double. Drools 5.0 also has a new more robust Rete algorithm, >> that is not subject to inconsistencies affecting modify and retract, we >> call this assymetrical Rete, rather than Jess' symmetrical Rete. >> > Further > >> to this our Rete supports partitioning for parallel evaluation, which >> was needed for our CEP work. >> > This performance note is great info to have. If you have more details on > this "inconsistency affecting modify and retract", I'd like to hear more, > too. > There is some stuff on the blog about symmetrical and assymetrical rete. >>> 3) Export to sourceforge. Our deployments involve exporting the >>> rulebase and associated citation tracking to sourceforge or google >>> code. That is, we want to deploy text rather than binaries. Is >>> > there a > >>> better way to do this than a simple db export? >>> >>> I've checked the user manuals and list archives for each of these >>> questions but wasn't able to answer them for myself. >>> >> Again not really sure what you are discussing, wouldn't just putting >> > the > >> .drl up at sourceforce achieve this? >> > I'm not sure of all that goes into these DRL files...it appears that > they use xml to describe the entire ruleset of a package. This would > work fine for us, although we would like to have a way of associating > them with the "source histories" I described above -- perhaps by using > the same filename for both, in the same dir, but a different extension > for the history. > have an idea for this, if a rule was compiled from a src, it would keep a url to that source. Thus if it was compiled from the brms, you get a url to that file, where the addional meta data is held. >> Btw if you do continue your research on Drools, I would encourage to >> > put > >> your details and your research up on the Drools Research Network page, >> > We'd be happy to do so. > great :) >> and also join the mailing list >> > I'm already on the users list; I didn't see a research-specific one. > It's on the drools research network page. > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users MASTEK LTD. Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List. In the US, we're called MAJESCOMASTEK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users