8:05 p.m.
Just published this, where I'm trying to explain good rule design in
terms more familiar to software developers.
http://blog.athico.com/2009/11/what-is-inference-and-how-does-it.html
Let me know what you think, and hopefully people have other ideas they
can add back in.
Mark
4:13 a.m.
I think I missed something on that post. Just posted a reply.
Cheers,
Leo.
On Tue, Nov 10, 2009 at 3:05 AM, Mark Proctor <mproctor(a)codehaus.org> wrote:
Just published this, where I'm trying to explain good rule design
in
terms more familiar to software developers.
http://blog.athico.com/2009/11/what-is-inference-and-how-does-it.html
Let me know what you think, and hopefully people have other ideas they
can add back in.
Mark
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:20 a.m.
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> wrote:
I think I missed something on that post. Just posted a reply.
Cheers,
Leo.
On Tue, Nov 10, 2009 at 3:05 AM, Mark Proctor <mproctor(a)codehaus.org> wrote:
> Just published this, where I'm trying to explain good rule design in
> terms more familiar to software developers.
> http://blog.athico.com/2009/11/what-is-inference-and-how-does-it.html
>
> Let me know what you think, and hopefully people have other ideas they
> can add back in.
>
> Mark
>
> _______________________________________________
> 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
11:35 a.m.
Wolfgang Laun wrote:
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
What you just described there is prolog "like" in nature, we have some
ideas around that. My BRF talk last week showed some ideas on how we can
integrate POSL. The are upsides and downsides to fact inferrence and
query based inferrence - hopefully we can provide both worlds :)
Mark
On Tue, Nov 10, 2009 at 11:13 AM, Leonardo Gomes
<leonardo.f.gomes(a)gmail.com> wrote:
> I think I missed something on that post. Just posted a reply.
>
> Cheers,
> Leo.
>
> On Tue, Nov 10, 2009 at 3:05 AM, Mark Proctor <mproctor(a)codehaus.org> wrote:
>
>> Just published this, where I'm trying to explain good rule design in
>> terms more familiar to software developers.
>> http://blog.athico.com/2009/11/what-is-inference-and-how-does-it.html
>>
>> Let me know what you think, and hopefully people have other ideas they
>> can add back in.
>>
>> Mark
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:01 a.m.
2009/11/10 Mark Proctor <mproctor(a)codehaus.org>:
Wolfgang Laun wrote:
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).
<result-type> property <name>( <fact-type> <name> ){
<expression> }
and use this in LHS the way we are used to
What you just described there is prolog "like" in nature, we have some ideas
around that. My BRF talk last week showed some ideas on how we can integrate
POSL. The are upsides and downsides to fact inferrence and query based
inferrence - hopefully we can provide both worlds :)
Mark
What I'd really like to have does not extend current LHS semantics and
shouldn't have any impact on rete and inference mechanisms. The "property"
I'm thinking of is a pure CE expression abstraction, without side
effects etc. If
necessary, it could be implemented by textual expansion. Possibly it might
favour compilation into rete but I've never looked into this topic.
-W
1:09 a.m.
Wolfgang Laun wrote:
2009/11/10 Mark Proctor <mproctor(a)codehaus.org>:
> Wolfgang Laun wrote:
>
> 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).
>
> <result-type> property <name>( <fact-type> <name> ){
<expression> }
>
> and use this in LHS the way we are used to
>
> What you just described there is prolog "like" in nature, we have some
ideas
> around that. My BRF talk last week showed some ideas on how we can integrate
> POSL. The are upsides and downsides to fact inferrence and query based
> inferrence - hopefully we can provide both worlds :)
>
> Mark
>
>
What I'd really like to have does not extend current LHS semantics and
shouldn't have any impact on rete and inference mechanisms. The "property"
I'm thinking of is a pure CE expression abstraction, without side
effects etc. If
necessary, it could be implemented by textual expansion. Possibly it might
favour compilation into rete but I've never looked into this topic.
And if a function calls a function and we allow multiple arguments and
return value? heh, the only thing you'll be missing then is unification
arguments ;) And then we have full prolog.
But I get the jist of what you are getting at. Wait till we get the
prolog style backward chaining done, then we can see what additional
work needs to be done to satisfy your requirements. Id be worried about
adding this in first, and the backward chaining after, in-case it stunts
anything.
Mark
-W
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:31 a.m.
2009/11/11 Mark Proctor <mproctor(a)codehaus.org>:
Wolfgang Laun wrote:
2009/11/10 Mark Proctor <mproctor(a)codehaus.org>:
Wolfgang Laun wrote:
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).
<result-type> property <name>( <fact-type> <name> ){
<expression> }
and use this in LHS the way we are used to
What you just described there is prolog "like" in nature, we have some ideas
around that. My BRF talk last week showed some ideas on how we can integrate
POSL. The are upsides and downsides to fact inferrence and query based
inferrence - hopefully we can provide both worlds :)
Mark
What I'd really like to have does not extend current LHS semantics and
shouldn't have any impact on rete and inference mechanisms. The "property"
I'm thinking of is a pure CE expression abstraction, without side
effects etc. If
necessary, it could be implemented by textual expansion. Possibly it might
favour compilation into rete but I've never looked into this topic.
And if a function calls a function and we allow multiple arguments and
return value?
Nested calls would have to conform to the locally visible objects,
i.e., the parameters
of the "property" the call appears in. Having exactly one return value is just
the point.
heh, the only thing you'll be missing then is unification
arguments ;) And then we have full prolog.
No, I don't want that.
But I get the jist of what you are getting at. Wait till we get the
prolog
style backward chaining done, then we can see what additional work needs to
be done to satisfy your requirements. Id be worried about adding this in
first, and the backward chaining after, in-case it stunts anything.
OK. Gives us time to discuss the details :)
And, perhaps, think about adding (relatively) simple things like
permitting, in DRL
import static ...;
final static String foo = ...;
-W
Mark
1:38 a.m.
Wolfgang Laun wrote:
2009/11/11 Mark Proctor <mproctor(a)codehaus.org>:
> Wolfgang Laun wrote:
>
> 2009/11/10 Mark Proctor <mproctor(a)codehaus.org>:
>
>
> Wolfgang Laun wrote:
>
> 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).
>
> <result-type> property <name>( <fact-type> <name> ){
<expression> }
>
> and use this in LHS the way we are used to
>
> What you just described there is prolog "like" in nature, we have some
ideas
> around that. My BRF talk last week showed some ideas on how we can integrate
> POSL. The are upsides and downsides to fact inferrence and query based
> inferrence - hopefully we can provide both worlds :)
>
> Mark
>
>
>
> What I'd really like to have does not extend current LHS semantics and
> shouldn't have any impact on rete and inference mechanisms. The
"property"
> I'm thinking of is a pure CE expression abstraction, without side
> effects etc. If
> necessary, it could be implemented by textual expansion. Possibly it might
> favour compilation into rete but I've never looked into this topic.
>
>
> And if a function calls a function and we allow multiple arguments and
> return value?
>
Nested calls would have to conform to the locally visible objects,
i.e., the parameters
of the "property" the call appears in. Having exactly one return value is just
the point.
> heh, the only thing you'll be missing then is unification
> arguments ;) And then we have full prolog.
>
>
No, I don't want that.
> But I get the jist of what you are getting at. Wait till we get the prolog
> style backward chaining done, then we can see what additional work needs to
> be done to satisfy your requirements. Id be worried about adding this in
> first, and the backward chaining after, in-case it stunts anything.
>
>
OK. Gives us time to discuss the details :)
And, perhaps, think about adding (relatively) simple things like
permitting, in DRL
import static ...;
you can already do this, but we call it import function. We just haven't
done the mapping to allow functions to be imported from different
namespaces, when they are defined in a drl, instead of on a java class.
final static String foo = ...;
This sounds like you want constants defined? I think we need to think
more on the whole area of constants, data initialisations and setup etc.
Mark
-W
> Mark
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:51 a.m.
2009/11/11 Mark Proctor <mproctor(a)codehaus.org>:
Wolfgang Laun wrote:
And, perhaps, think about adding (relatively) simple things like
permitting, in DRL
import static ...;
you can already do this, but we call it import function. We just haven't
done the mapping to allow functions to be imported from different
namespaces, when they are defined in a drl, instead of on a java class.
final static String foo = ...;
This sounds like you want constants defined? I think we need to think more
on the whole area of constants, data initialisations and setup etc.
Exactly. Right now, I can import a class and access its static finals, using
Class.FIELD. But occasionally it's more convenient (also for maintenance) to
define them locally. (Defining a function returning a value is an acceptable
workaround for simple types and String.)
Initialisation: Yes, for instance, the "global" thing is more like a
workaround than a
solution ;-)
-W
Mark
-W
Mark
_______________________________________________
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
2:02 a.m.
Wolfgang Laun wrote:
2009/11/11 Mark Proctor <mproctor(a)codehaus.org>:
> Wolfgang Laun wrote:
>
> And, perhaps, think about adding (relatively) simple things like
> permitting, in DRL
> import static ...;
>
> you can already do this, but we call it import function. We just haven't
> done the mapping to allow functions to be imported from different
> namespaces, when they are defined in a drl, instead of on a java class.
>
> final static String foo = ...;
>
>
> This sounds like you want constants defined? I think we need to think more
> on the whole area of constants, data initialisations and setup etc.
>
>
Exactly. Right now, I can import a class and access its static finals, using
Class.FIELD. But occasionally it's more convenient (also for maintenance) to
define them locally. (Defining a function returning a value is an acceptable
workaround for simple types and String.)
Initialisation: Yes, for instance, the "global" thing is more like a
workaround than a
solution ;-)
We went with "import function" instead of "import static" as
we weren't
sure if anything more than a function would ever be imported, i.e. we
ignored the idea of static fields. We can re-address that, likewise the
importantion of functinos and static "constants" from other namespaces.
I was thinking about something event based. So blocks of code can be
executed at given points in the life cycle of the session. I was
thinking on session initialisation, on call to fireAllRules and when
fireAllRules returns back to java code. We are working on making it
lightweight to listen to events as facts implicitely inserted into the
engine (but not remembered). That way we could actually just have rules,
that match given events to do data initialisation or whetever else is
needed. I'm just not sure what those life cycles should be yet, beyond
what we already have. When we review data initialisation, we can tackle
this whole bag of worms.
Mark
-W
> Mark
>
> -W
>
>
>
> Mark
>
>
>
> _______________________________________________
> 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
>
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:30 a.m.
Leonardo Gomes wrote:
I think I missed something on that post. Just posted a reply.
Cheers,
Leo.
"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?"
That facts are coded in java is incidental there use is still very
declarative. Imperative is "how" and often procedural in nature. By
using the inferred fact the de-coupling makes sure it's not procedural,
the age policy rules do not invoke the card issuing rules. Secondly the
encapsulation and the abstraction makes sure the card issuing rules do
not know the "how" someone is an adult, they have just declaratively
been told that they are.
On Tue, Nov 10, 2009 at 3:05 AM, Mark Proctor
<mproctor(a)codehaus.org> wrote:
> Just published this, where I'm trying to explain good rule design in
> terms more familiar to software developers.
> http://blog.athico.com/2009/11/what-is-inference-and-how-does-it.html
>
> Let me know what you think, and hopefully people have other ideas they
> can add back in.
>
> Mark
>
> _______________________________________________
> 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
5300
days inactive
5301
days old
10 comments
3 participants
participants (3)
-
Leonardo Gomes -
Mark Proctor -
Wolfgang Laun