Re: [rules-users] What is inference and how does it facilitate good rule design and maintenance

Leo's reply reads: "In this scenario, aren't we moving logic that would be better expressed in a declarative form (drl) to facts that are coded in java?" I don't think this is an issue. Extracting a fact's property derived from one or more constraints being true as an additional fact isn't doing what Leo is afraid of at all. The CEs resulting in the assertion of this inferred relation are still there in the DRL. I'd be more worried about the consequences of using this approach heavily, in large scale Fact DBs. Adding, to N basic entity facts O(N) additional facts that just express the truth value of a simple or compound constraint is bound to have some impact on resource requirements. -*- It is, however, very desirable to be able to write LHS in a more structured way, not being forced to either repeat CEs or create additional facts establishing secondary properties (such as isAdult). However, the abstraction technique for expressions (and this includes the Boolean expressions in LHS) has been invented a long time ago: functions! If we were able to define a CE function (I'll use "property" to distinguish this from plain DRL functions) like this <result-type> property <name>( <fact-type> <name> ){ <expression> } and use this in LHS the way we are used to, e.g. boolean property adult( Person p){ p.age >= 18} rule x when Person( ..., adult == true ) then ... end It should also be possible to define property functions with multiple fact arguments, or functions with additional parameters that aren't fact types, e.g. double property weight( Thing t, double rho ){ t.volume*rho } rule y $m : Material( $rho : density ) Thing( material == m, weight( $rho ) > 1000 ) -W On Tue, Nov 10, 2009 at 11:13 AM, Leonardo Gomes <leonardo.f.gomes(a)gmail.com&gt; wrote: