Re: JESS: NRL for Jess
On Jun 24, 2008, at 8:53 AM, Peter Lin wrote: I'm going to disagree that NRL is an anti-pattern. OK. It all depends on how you use it. Agreed... though since I having a tendency to be querolous, I'd change how to when. I've successfully designed and built custom business rule languages in the past. The key is keeping the domain well defined and narrow. I am tempted to envy you a bit here (in that the scope has been defined and narrow enough to capture in a DSL, but interesting enough to warrant an expert system shell). Don't try to make a DSL that is a general purpose language. Agreed. Unfortunately, it's been my experience that there is a significant risk that a customer will drive DSLs inexorably towards a general rule language. For example, say I want to create a rule language for defining privacy rules for mobile phones. ...crisp example elided (nothing to quibble about) ... Once you have enough rules to get a good idea of the scope, you can start designing the language. Generally at the point the scope is clearly resolved in the projects I'm thinking of, the bulk of the rules work has mostly been done. The rules development coincided with exploring the subject domain with one (or a handful) of experts. The maintenance of the rules that followed been associated with a few experts at most, along with a knowledge engineer, and at fairly low change rates. Changing the rules in a mobile phone privacy system or a message routing system would seem to have a lot more rule-editing users, and a more constrained capability than sendmail + scripting would still be useful without a high risk of scope creep. Writing the parser is heavily dependent on how solid the DSL is. Once you have the parser, converting to JESS is straight forward. That seems reasonable. No argument that the parser - Jess conversion should be mechanical, if a good DSL can be designed. But the effort requires enough users/usage to justify. Some rule patterns can even be simplified into fact assertions, meta- rule to interpret them. OTOH, the problem has to be constrained very well, or this approach can fail in a manner analogous to a overly specific DSL. Perhaps the key is that one must the problem well enough defined before attempting to define a DSL. Analysis first, /then/ DSL design decisions. - Mike 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: NRL for Jess
the cost versus benefit definitely is an important consideration. In the past, I built custom languages for privacy rules and regulatory compliance rules, which are sufficiently narrow. I definitely wouldn't attempt a DSL for general business rules. That will most likely result in a nightmare. peter On Wed, Jun 25, 2008 at 1:50 AM, Michael Smith [EMAIL PROTECTED] wrote: On Jun 24, 2008, at 8:53 AM, Peter Lin wrote: I'm going to disagree that NRL is an anti-pattern. OK. It all depends on how you use it. Agreed... though since I having a tendency to be querolous, I'd change how to when. I've successfully designed and built custom business rule languages in the past. The key is keeping the domain well defined and narrow. I am tempted to envy you a bit here (in that the scope has been defined and narrow enough to capture in a DSL, but interesting enough to warrant an expert system shell). Don't try to make a DSL that is a general purpose language. Agreed. Unfortunately, it's been my experience that there is a significant risk that a customer will drive DSLs inexorably towards a general rule language. For example, say I want to create a rule language for defining privacy rules for mobile phones. ...crisp example elided (nothing to quibble about) ... Once you have enough rules to get a good idea of the scope, you can start designing the language. Generally at the point the scope is clearly resolved in the projects I'm thinking of, the bulk of the rules work has mostly been done. The rules development coincided with exploring the subject domain with one (or a handful) of experts. The maintenance of the rules that followed been associated with a few experts at most, along with a knowledge engineer, and at fairly low change rates. Changing the rules in a mobile phone privacy system or a message routing system would seem to have a lot more rule-editing users, and a more constrained capability than sendmail + scripting would still be useful without a high risk of scope creep. Writing the parser is heavily dependent on how solid the DSL is. Once you have the parser, converting to JESS is straight forward. That seems reasonable. No argument that the parser - Jess conversion should be mechanical, if a good DSL can be designed. But the effort requires enough users/usage to justify. Some rule patterns can even be simplified into fact assertions, meta- rule to interpret them. OTOH, the problem has to be constrained very well, or this approach can fail in a manner analogous to a overly specific DSL. Perhaps the key is that one must the problem well enough defined before attempting to define a DSL. Analysis first, /then/ DSL design decisions. - Mike 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: NRL for Jess
On Jun 23, 2008, at 6:40 PM, Barry Flower wrote: I am interested in using Natural Rules Language for business rules definition and was wondering if anyone is aware of an implementation (commercial or otherwise) that can be used with Jess. I understand that it would need to be constrained for a specific business domain and would assume that the NRL would have the facility to be customised (using a constraint taxonomy or ontology). Cheers Barry I wouldn't recommend DROOLS in general [1], but they do have some support for creating a custom domain-specific language (DSL). If having a DSL is of paramount importance, it is worth a gander. But... IMO, such DSLs are usually an anti-pattern. The DSL might get you started great guns at first and for demos -- but it will not do everything you and the customer will want, and then you'll have two problems: the problem at hand, and maintaining a rapidly expanding feature list for the DSL. With the pressure to keep moving forward, the likely ad hoc development of the DSL will become increasingly unwieldy, frustrating, and expensive to maintain. As a developer -- unless all of your testing and development works within an automated testing environment, I suspect you'll find debugging and maintaining a DROOLS-based rules engine significantly more difficult, due to how it compiles and loads rules. Even with the automation, the Jess command line is a powerful development environment (like any REPL). So maybe you'll have three problems. Depends on whether you find it useful to drop bits of code into an interpreted environment full of state or you re-run after editing (or re-run after compiling and editing). If you had a really large, and non-technical, set of rule writers relative to the software development team, and a budget to pay for DSL maintenance, then a DSL might make sense. But good language design is tough for non-trivial cases. Pretty soon one can find that the rules need to be more expressive than first thought, and more and more arcane syntax is needed, and one begins to wonder why the rule developers weren't just trained on the original rule engine's language. It's much the same yin/yang as the issues surrounding visual/ wizardly rule editors. If you go this way, try to study the best commercial software first, and only then decide if you want to roll your own. $0.02 and change, - Mike [1] Unfortunately, the open sourceness of DROOLS seems to trump any and all advantages Jess has to offer in many developers minds. Jess's current license is an Achilles heel in many environments. The lack of an interpreted, shell-oriented, paradigm (no REPL) is a huge loss.
Re: JESS: NRL for Jess
I'm going to disagree that NRL is an anti-pattern. It all depends on how you use it. I've successfully designed and built custom business rule languages in the past. The key is keeping the domain well defined and narrow. Don't try to make a DSL that is a general purpose language. For example, say I want to create a rule language for defining privacy rules for mobile phones. The first thing I do is define a set of entities the rules would need to reason over. A ficticious example might be this. addressbook name number relation time allow deny take a message The next step is to define some privacy rules a person might write. It might looks like this. deny any call not in my addressbook allow any call from family take a message for non-family before 8 am and after 6 pm Once you have enough rules to get a good idea of the scope, you can start designing the language. Writing the parser is heavily dependent on how solid the DSL is. Once you have the parser, converting to JESS is straight forward. peter On Tue, Jun 24, 2008 at 12:33 AM, Michael Smith [EMAIL PROTECTED] wrote: On Jun 23, 2008, at 6:40 PM, Barry Flower wrote: I am interested in using Natural Rules Language for business rules definition and was wondering if anyone is aware of an implementation (commercial or otherwise) that can be used with Jess. I understand that it would need to be constrained for a specific business domain and would assume that the NRL would have the facility to be customised (using a constraint taxonomy or ontology). Cheers Barry I wouldn't recommend DROOLS in general [1], but they do have some support for creating a custom domain-specific language (DSL). If having a DSL is of paramount importance, it is worth a gander. But... IMO, such DSLs are usually an anti-pattern. The DSL might get you started great guns at first and for demos -- but it will not do everything you and the customer will want, and then you'll have two problems: the problem at hand, and maintaining a rapidly expanding feature list for the DSL. With the pressure to keep moving forward, the likely ad hoc development of the DSL will become increasingly unwieldy, frustrating, and expensive to maintain. As a developer -- unless all of your testing and development works within an automated testing environment, I suspect you'll find debugging and maintaining a DROOLS-based rules engine significantly more difficult, due to how it compiles and loads rules. Even with the automation, the Jess command line is a powerful development environment (like any REPL). So maybe you'll have three problems. Depends on whether you find it useful to drop bits of code into an interpreted environment full of state or you re-run after editing (or re-run after compiling and editing). If you had a really large, and non-technical, set of rule writers relative to the software development team, and a budget to pay for DSL maintenance, then a DSL might make sense. But good language design is tough for non-trivial cases. Pretty soon one can find that the rules need to be more expressive than first thought, and more and more arcane syntax is needed, and one begins to wonder why the rule developers weren't just trained on the original rule engine's language. It's much the same yin/yang as the issues surrounding visual/wizardly rule editors. If you go this way, try to study the best commercial software first, and only then decide if you want to roll your own. $0.02 and change, - Mike [1] Unfortunately, the open sourceness of DROOLS seems to trump any and all advantages Jess has to offer in many developers minds. Jess's current license is an Achilles heel in many environments. The lack of an interpreted, shell-oriented, paradigm (no REPL) is a huge loss. 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: NRL for Jess
I've done this before using a custom domain specific language. What I did was define a syntax and grammar for a business rule language, which was then compiled and stored as RuleML. At execution time, I translated the RuleML to JESS clips. in terms of storage, the rules were stored in the dsl format and ruleml format. it can be done, if you're not afraid of defining your language and start small. peter On Mon, Jun 23, 2008 at 6:40 PM, Barry Flower [EMAIL PROTECTED] wrote: I am interested in using Natural Rules Language for business rules definition and was wondering if anyone is aware of an implementation (commercial or otherwise) that can be used with Jess. I understand that it would need to be constrained for a specific business domain and would assume that the NRL would have the facility to be customised (using a constraint taxonomy or ontology). Cheers Barry Barry Flower | Global Head eFM Strategy Solutions | WIB Technology Westpac Institutional Bank | Level 2, Westpac Place, 275 Kent Street, Sydney, NSW 2000 T +61 2 8254 6308 | M +61 439 467 971 | E [EMAIL PROTECTED] Please consider our environment before printing this email. WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately. It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments. This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision. Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency. Westpac Banking Corporation ABN 33 007 457 141. 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]
