Mark Proctor | 2 Jan 02:53 2008

[rules-dev] KnowledgeBase

With Drools moving rules and processes to first class citizens I'm 
thinking of depreacting RuleBase to be called KnowledgeBase. What do 
people think?
http://en.wikipedia.org/wiki/Knowledge_base

Mark
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Massi Gmail | 3 Jan 14:49 2008
Picon

Re: [rules-dev] KnowledgeBase

 
Reading the wikipedia doc, It seems that a knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance information like the "object model".
 
As far as I understood the rulebase does not contain anything related to the object\fact model.
 
So I would say that the rulebase is "part of" the knowledge base and not the "knowledgebase" itself.
 
It's just an idea....
 
Massi
 
 
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Vineet Khosla | 3 Jan 19:24 2008
Picon

Re: [rules-dev] KnowledgeBase

Peter Jackson supports the wiki concept. Knowledge base has 'both rules and various declarations'.
Lets keep it 'rule base'.
 
Vineet


----- Original Message ----
From: Massi Gmail <mmquelo <at> gmail.com>
To: rules-dev <at> lists.jboss.org
Sent: Thursday, January 3, 2008 5:49:23 AM
Subject: Re: [rules-dev] KnowledgeBase

 
Reading the wikipedia doc, It seems that a knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance information like the "object model".
 
As far as I understood the rulebase does not contain anything related to the object\fact model.
 
So I would say that the rulebase is "part of" the knowledge base and not the "knowledgebase" itself.
 
It's just an idea....
 
Massi
 
 


Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Mark Proctor | 3 Jan 20:48 2008

Re: [rules-dev] KnowledgeBase

Vineet Khosla wrote:
<!-- DIV {margin:0px;} -->
Peter Jackson supports the wiki concept. Knowledge base has 'both rules and various declarations'.
Lets keep it 'rule base'.
rule base isn't so appropriate now, as we also have  Processes in it. We already have functions, and soon enough we'll also add in Templates for class definitions (already there, but not exposed).
 
Vineet


----- Original Message ----
From: Massi Gmail <mmquelo <at> gmail.com>
To: rules-dev <at> lists.jboss.org
Sent: Thursday, January 3, 2008 5:49:23 AM
Subject: Re: [rules-dev] KnowledgeBase

 
Reading the wikipedia doc, It seems that a knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance information like the "object model".
 
As far as I understood the rulebase does not contain anything related to the object\fact model.
 
So I would say that the rulebase is "part of" the knowledge base and not the "knowledgebase" itself.
 
It's just an idea....
 
Massi
 
 


Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. _______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Mark Proctor | 7 Jan 21:49 2008

[rules-dev] validator

I'm thinking about an ontology constraint system, based around field 
setter validation. However I cannot decide how to handle invalid changes 
in a consequence or in external java code. I'll may leverage the JSR 303 
- Bean Validation - http://jcp.org/en/jsr/detail?id=303.

Although I have several concerns with the spec, one is that it always 
validates objects and passes in the field as an object - with primitive 
intensive stuff that can add an overhead, due to auto boxing. I'm more 
tempted to pass in the main Object itself and users can then use the 
FieldExtractor to read the field as they require, either as an Object or 
a primitive with full co-ercion - the FieldExtractor would be injected. 
Further to that I can't see how you would make the validator session 
aware, and doing it via constructor injection would mean a validator per 
session which is not desirable. I spoke to the spec lead and he 
mentioned using LocalThread variables. However we can have multiple 
sessions in the same thread, just not executing at the same time, which 
means the current executing session would need to set itself on that 
localthread variable - basically context switching, which I don't like.

We should have a variable that lists the validator errors for the 
current working memory action phase, for user interrogation - much like 
Hibernate Validator (RI for JSR 303) allows you to list validation 
errors on a insert or update on a session.

But in rule engines we have other considerations:
The first fundamental question is do we allow invalid changes or do we 
always roll them back? My prefernce, much like a database, is the data 
model as seen by the engine is always valid.

Now if we assume the invalid change must be rolled bank or not applied 
how do we expose this to the user:
-Throw an exception, up to them if they catch and it will exit the 
engine if not caught.
-Do nothing, roll back the change and continue executing the consequence 
as normal, they can check the validator variable if they need to.
Allow for "catch" like blocks either after each modify block, or after 
the "then" block. Do we have one large catch block, or do we have some 
sort of type matching....

Currently my preference is for a "catch" block after the "then" block. 
I'm tempted to just have one large catch block and users can do an 
iteration of the validator variable doing "if" checks; we can always add 
in type matching later. The catch block can either resume or throw an 
exception; on resumption it will attempt to validate the bean again, if 
it's changed, if it's still invalid the process repeats.

Mark
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Michael Neale | 8 Jan 05:56 2008
Picon

Re: [rules-dev] validator

I don't like the catch block idea at all. We have a rule language not  
a programming language.

Sent from my iPhone

On 08/01/2008, at 6:49, Mark Proctor <mproctor <at> codehaus.org> wrote:

> I'm thinking about an ontology constraint system, based around field  
> setter validation. However I cannot decide how to handle invalid  
> changes in a consequence or in external java code. I'll may leverage  
> the JSR 303 - Bean Validation - http://jcp.org/en/jsr/detail?id=303.
>
> Although I have several concerns with the spec, one is that it  
> always validates objects and passes in the field as an object - with  
> primitive intensive stuff that can add an overhead, due to auto  
> boxing. I'm more tempted to pass in the main Object itself and users  
> can then use the FieldExtractor to read the field as they require,  
> either as an Object or a primitive with full co-ercion - the  
> FieldExtractor would be injected. Further to that I can't see how  
> you would make the validator session aware, and doing it via  
> constructor injection would mean a validator per session which is  
> not desirable. I spoke to the spec lead and he mentioned using  
> LocalThread variables. However we can have multiple sessions in the  
> same thread, just not executing at the same time, which means the  
> current executing session would need to set itself on that  
> localthread variable - basically context switching, which I don't  
> like.
>
> We should have a variable that lists the validator errors for the  
> current working memory action phase, for user interrogation - much  
> like Hibernate Validator (RI for JSR 303) allows you to list  
> validation errors on a insert or update on a session.
>
> But in rule engines we have other considerations:
> The first fundamental question is do we allow invalid changes or do  
> we always roll them back? My prefernce, much like a database, is the  
> data model as seen by the engine is always valid.
>
> Now if we assume the invalid change must be rolled bank or not  
> applied how do we expose this to the user:
> -Throw an exception, up to them if they catch and it will exit the  
> engine if not caught.
> -Do nothing, roll back the change and continue executing the  
> consequence as normal, they can check the validator variable if they  
> need to.
> Allow for "catch" like blocks either after each modify block, or  
> after the "then" block. Do we have one large catch block, or do we  
> have some sort of type matching....
>
> Currently my preference is for a "catch" block after the "then"  
> block. I'm tempted to just have one large catch block and users can  
> do an iteration of the validator variable doing "if" checks; we can  
> always add in type matching later. The catch block can either resume  
> or throw an exception; on resumption it will attempt to validate the  
> bean again, if it's changed, if it's still invalid the process  
> repeats.
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Mark Proctor | 8 Jan 06:31 2008

Re: [rules-dev] validator

Michael Neale wrote:
> I don't like the catch block idea at all. We have a rule language not 
> a programming language.
How do we deal with invalid sets? Without a catch block, ther "then" 
scoped or "modify" scoped, we have only two choices - always throw an 
exception, do nothing and just expose a validator variable. Considering 
we don't want to add 'if' statements into the consequence how would the 
user then handle processing the validator variable?
>
>
> Sent from my iPhone
>
> On 08/01/2008, at 6:49, Mark Proctor <mproctor <at> codehaus.org> wrote:
>
>> I'm thinking about an ontology constraint system, based around field 
>> setter validation. However I cannot decide how to handle invalid 
>> changes in a consequence or in external java code. I'll may leverage 
>> the JSR 303 - Bean Validation - http://jcp.org/en/jsr/detail?id=303.
>>
>> Although I have several concerns with the spec, one is that it always 
>> validates objects and passes in the field as an object - with 
>> primitive intensive stuff that can add an overhead, due to auto 
>> boxing. I'm more tempted to pass in the main Object itself and users 
>> can then use the FieldExtractor to read the field as they require, 
>> either as an Object or a primitive with full co-ercion - the 
>> FieldExtractor would be injected. Further to that I can't see how you 
>> would make the validator session aware, and doing it via constructor 
>> injection would mean a validator per session which is not desirable. 
>> I spoke to the spec lead and he mentioned using LocalThread 
>> variables. However we can have multiple sessions in the same thread, 
>> just not executing at the same time, which means the current 
>> executing session would need to set itself on that localthread 
>> variable - basically context switching, which I don't like.
>>
>> We should have a variable that lists the validator errors for the 
>> current working memory action phase, for user interrogation - much 
>> like Hibernate Validator (RI for JSR 303) allows you to list 
>> validation errors on a insert or update on a session.
>>
>> But in rule engines we have other considerations:
>> The first fundamental question is do we allow invalid changes or do 
>> we always roll them back? My prefernce, much like a database, is the 
>> data model as seen by the engine is always valid.
>>
>> Now if we assume the invalid change must be rolled bank or not 
>> applied how do we expose this to the user:
>> -Throw an exception, up to them if they catch and it will exit the 
>> engine if not caught.
>> -Do nothing, roll back the change and continue executing the 
>> consequence as normal, they can check the validator variable if they 
>> need to.
>> Allow for "catch" like blocks either after each modify block, or 
>> after the "then" block. Do we have one large catch block, or do we 
>> have some sort of type matching....
>>
>> Currently my preference is for a "catch" block after the "then" 
>> block. I'm tempted to just have one large catch block and users can 
>> do an iteration of the validator variable doing "if" checks; we can 
>> always add in type matching later. The catch block can either resume 
>> or throw an exception; on resumption it will attempt to validate the 
>> bean again, if it's changed, if it's still invalid the process repeats.
>>
>> Mark
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Edson Tirelli | 8 Jan 14:11 2008

Re: [rules-dev] validator


   Well, we can't let the the exception escape the consequence block, since it would invalidate the working memory.
   So, we have 2 options I think:

* If we make the validation framework enforce valid values, we need it to raise an exception that is catch by a transparent consequence catch block and is handled the same way we already handle them, but stopping rule firing.

* If we make the validation framework just warn about invalid values, we can create a warning mechanism so that users can handle such warnings, but let the value to be set and continue running the engine as if no problem was found.

   I don't see many other options on that... I still prefer first option.

   My 0.02c.

   []s
   Edson

2008/1/8, Mark Proctor < mproctor <at> codehaus.org>:
Michael Neale wrote:
> I don't like the catch block idea at all. We have a rule language not
> a programming language.
How do we deal with invalid sets? Without a catch block, ther "then"
scoped or "modify" scoped, we have only two choices - always throw an
exception, do nothing and just expose a validator variable. Considering
we don't want to add 'if' statements into the consequence how would the
user then handle processing the validator variable?
>
>
> Sent from my iPhone
>
> On 08/01/2008, at 6:49, Mark Proctor < mproctor <at> codehaus.org> wrote:
>
>> I'm thinking about an ontology constraint system, based around field
>> setter validation. However I cannot decide how to handle invalid
>> changes in a consequence or in external java code. I'll may leverage
>> the JSR 303 - Bean Validation - http://jcp.org/en/jsr/detail?id=303.
>>
>> Although I have several concerns with the spec, one is that it always
>> validates objects and passes in the field as an object - with
>> primitive intensive stuff that can add an overhead, due to auto
>> boxing. I'm more tempted to pass in the main Object itself and users
>> can then use the FieldExtractor to read the field as they require,
>> either as an Object or a primitive with full co-ercion - the
>> FieldExtractor would be injected. Further to that I can't see how you
>> would make the validator session aware, and doing it via constructor
>> injection would mean a validator per session which is not desirable.
>> I spoke to the spec lead and he mentioned using LocalThread
>> variables. However we can have multiple sessions in the same thread,
>> just not executing at the same time, which means the current
>> executing session would need to set itself on that localthread
>> variable - basically context switching, which I don't like.
>>
>> We should have a variable that lists the validator errors for the
>> current working memory action phase, for user interrogation - much
>> like Hibernate Validator (RI for JSR 303) allows you to list
>> validation errors on a insert or update on a session.
>>
>> But in rule engines we have other considerations:
>> The first fundamental question is do we allow invalid changes or do
>> we always roll them back? My prefernce, much like a database, is the
>> data model as seen by the engine is always valid.
>>
>> Now if we assume the invalid change must be rolled bank or not
>> applied how do we expose this to the user:
>> -Throw an exception, up to them if they catch and it will exit the
>> engine if not caught.
>> -Do nothing, roll back the change and continue executing the
>> consequence as normal, they can check the validator variable if they
>> need to.
>> Allow for "catch" like blocks either after each modify block, or
>> after the "then" block. Do we have one large catch block, or do we
>> have some sort of type matching....
>>
>> Currently my preference is for a "catch" block after the "then"
>> block. I'm tempted to just have one large catch block and users can
>> do an iteration of the validator variable doing "if" checks; we can
>> always add in type matching later. The catch block can either resume
>> or throw an exception; on resumption it will attempt to validate the
>> bean again, if it's changed, if it's still invalid the process repeats.
>>
>> Mark
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



--
  Edson Tirelli
  JBoss Drools Core Development
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Michael Neale | 8 Jan 12:33 2008
Picon

Re: [rules-dev] KnowledgeBase

Also things in the future like neural nets and other potentially learned data. I guess whatever we call it it will be the deployable unit 


Sent from my iPhone

On 04/01/2008, at 5:48, Mark Proctor <mproctor <at> codehaus.org> wrote:

Vineet Khosla wrote:
Peter Jackson supports the wiki concept. Knowledge base has 'both rules and various declarations'.
Lets keep it 'rule base'.
rule base isn't so appropriate now, as we also have  Processes in it. We already have functions, and soon enough we'll also add in Templates for class definitions (already there, but not exposed).
 
Vineet


----- Original Message ----
From: Massi Gmail <mmquelo <at> gmail.com>
To: rules-dev <at> lists.jboss.org
Sent: Thursday, January 3, 2008 5:49:23 AM
Subject: Re: [rules-dev] KnowledgeBase

 
Reading the wikipedia doc, It seems that a knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance information like the "object model".
 
As far as I understood the rulebase does not contain anything related to the object\fact model.
 
So I would say that the rulebase is "part of" the knowledge base and not the "knowledgebase" itself.
 
It's just an idea....
 
Massi
 
 


Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. _______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Michael Neale | 9 Jan 03:17 2008
Picon

Re: [rules-dev] recursion checking util

The analysis tool would be good for some of this. But it is for static  
analysts. This sounds like it could be a runtime tool that optionalls  
detects and stops it. Very handy.

Sent from my iPhone

On 09/12/2007, at 23:08, Darko IVANCAN <ivancan <at> gmx.de> wrote:

> Hi Mark,
>
> Should this be an (a) off-line or an (b) on-line tool ?
> (a) off-line: parse rule file and point out the lines/rules which  
> could
> lead to a potential recursion
> (b) on-line: identifiy a potential recursion while runtime by  
> observing
> the agenda and the working memory
>
> Sounds like fun indeed, ... I'll take a look once I have some time,
> Darko Ivancan
>
> On 09/12/2007 08:41, Mark Proctor wrote:
>> I've been getting requests for a testing tool that checks for
>> recursion, and exits the test if its detected. Any takers fancy  
>> having
>> a go at this? Mostly its just an event model thing, bit like the  
>> audit
>> view. But as recursion is not just about rule recursion, but
>> Activation recursion too (i.e. rule recursion with the same data),
>> you'll need to create a stack of rules and tuples, and check against
>> that stack for possible recursions. Should be fun :)
>>
>> Mark
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


Gmane