On Fri, Apr 9, 2010 at 1:21 AM, Franz Schwab <franz.schwab(a)gmx.net&gt; wrote: Could you please be more specific? I have heard the term "refactoring" in connection with certain modifications of a (Java) source program. Is that the idea? And "transformation" can be almost anything that produces a B from an A... How do you define "knowledge base"? Does this mean that you have a measure for the quality of KBs? or simply to delete bad smells. ?? If I were inclined to be funny, I'd say you start by opening a window; but so I just ask you to be more specific. -W I have to admit that I

Hi Franz, just a few thoughts... "Design" in connection with rule-based systems has several flavours. Some of the terms I'm going to use here are not well-established, so I'll use quotes to mark them. All of this is off-the-cuff, and certainly sketchy. There is the "large-scale design" of a RB application. This is where you decide about - fact types, i.e., the type of ontology you'd like to use (if not Pojos) - the kind of session: stateful (truly a production system) or stateless (basically just derivative, no fact updates). - data flow: how and when to insert facts, how and when to extract results - architecture of the embedding (Java) application - whether to use CEP - ... Then there is "rule design patterns", something that's akin to rule programming techniques, mostly decisions about - when and how to use "auxiliary facts", - how to use or not use salience (i.e., rule priority) - how to order patterns within a rule, - when to use FOP quantifiers or more sophisticated CEs (e.g. accumulate) - whether to flatten lists into facts or leave them as a complex attribute, - whether to go for a DSL - whether to use decision tables - ... On a level in between, you have rule grouping: - agenda groups - activation groups - rule flow - iterating rule engine activations - ... Sometimes it's possible to delay decisions. For instance, you may not know whether it's better to have many rules in a few basic patterns with distinguising data embedded in them, or to have only a few rules, interpreting the equivalent data contained in static "parameter facts". Here, you could start out with a data representation, and you might decide to create rules later on. (See "templates" in Drools "Expert". And the ongoing discussion in an active thread.) Rules as in Drools or similar systems are simple program structures; the essential part (left hand side) is just a boolean expression. A functionally equivalent engine for the basic CEs would be rather easy to write *if you use the naive approach* (i.e., not implement a Rete). Whether rule extension, as implemented in Drools, is a useful feature still remains to be seen. Refactoring of rules is difficult, since they tend to interact in a highly intricate way, especially in production systems. Occasionally you can refactor by reducing the number of rules, replacing similar rules with a more general one that incorporates equivalent processing logic as data. For instance, if you have several rules implementing binary operations (think of the elementary algebraic or logic operators), you can factor them into a single BinOp rule where the actual operation is an attribute of the fact representing the operation, implemented - depending on your RBS - as a lambda, or a function pointer, or a method of an object of some subclass. (If this is too hazy, you can ask me for an example.) -W On Fri, Apr 9, 2010 at 1:41 PM, Franz Schwab <franz.schwab(a)gmx.net&gt; wrote: