User Tools

Site Tools


api4kb_rules

====== Differences ====== This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
api4kb_rules [2012/10/13 10:52]
rmbell
api4kb_rules [2012/10/22 05:34]
apaschke
Line 1: Line 1:
 APIs for Rule Engines [[start|Link to API4KB Main Page]] APIs for Rule Engines [[start|Link to API4KB Main Page]]
-   * Need to identify a target set of rule languages+   * Need to identify a target set of rule languages ​and rule types (derivation,​ reaction (production,​ ECA, CEP)
    * Need to determine whether support for machine learning, planning, etc. is in scope long term    * Need to determine whether support for machine learning, planning, etc. is in scope long term
-   ​* ​For specific rule languages, ​support for RIF family at minimum +   ​* ​Need support for a general rule language interchange ([[http://​www.slideshare.net/​swadpasc/​reaction-ruleml-ruleml2012paschketutorial|RuleML as general rule interchange language]] and maybe RIF as specialized Web rule interchange format (only support for basic logic rules)) 
-      * Load vocabularies +      * Translate and Load vocabularies 
-      * Execute rules +      * Execute rules (transformations from the platform-independent RuleML interchange format into the platform-specific executable rule language) 
 +      * Interchange of queries and answers (at a minimum; supported by  [[http://​www.springerlink.com/​content/​k13040qqqv262882/​|RuleML]])  
 +      * Interchange of rule sets / rule bases 
 +      * Interchange of proofs 
 +      * Interchange of test cases for verification and validation (see verification,​ validation and integrity testing below)
 Need to see how this connects with the work that is going on for PRR and Decision Management at %%OMG%% Need to see how this connects with the work that is going on for PRR and Decision Management at %%OMG%%
  
 +    * Need support for a rule interface description for distributed rule bases (see [[http://​www.slideshare.net/​swadpasc/​reaction-ruleml-ruleml2012paschketutorial|RuleML]]) 
 +      * description of supported semantics 
 +      * description of public signatures which can be queried (derivation rules) or triggered (reaction rules) including  
 +      * description of life cycle management (e.g. descriptive metadata and qualifying metadata, e.g. validity of the rules, rule management in KB etc.) 
 +    * Need to support rule inference services (looseley-coupled or de-coupled) 
 +      * REST services 
 +      * wrap rule inference services into agents which communicate via messages (see e.g. [[http://​ruleml.org/​RuleResponder/​|Rule Responder]] and [[http://​www.slideshare.net/​swadpasc/​reaction-ruleml-ruleml2012paschketutorial|Messaging in RuleML]]) 
 +        * support for agent role models 
 +        * pragmatic primitives for coordination and negotiation between agents (e.g. FIPA ACL primitives) 
 +      * description of non-functional properties of the rule service (see [[http://​ibis.in.tum.de/​projects/​rbsla/​|Rule Based Service Level Agreements]]) 
 +    * Need support for validation, verification and integrity (VVI) testing 
 +      * Verification ensures the logical correctness of a rule base 
 +      * Validation is concerned with the correctness of a rule-based system in a certain domain or application (e.g. a derived discount of 10% and 5% might be mutual exclusive or might add up depending on the domain/​application) 
 +      * Integrity (constraints) are a way to formulate consistency (or inconsistency) criteria 
 +      * Uses Test Cases for VVI (see [[http://​km.aifb.kit.edu/​ws/​swese2006/​final/​paschke_full.pdf|RuleML test cases for VVI]]) 
 +        * Test Cases can be used for testing at design time (test-driven development) and run time (e.g. rule translation and compliance test cases) 
 +        * Test cases can be interchanged together with rules and  
 +          * used to validate the interchanged rule set in the target system/​environment. 
 +          * Newly received rules can be safely added to an existing rule set, if they pass all existing test cases. 
 +          * Test cases can be predefined by experts while rules are written or combined by “normal” practitioners. The test cases then safeguard this latter authoring process. 
 +          * Test cases are less abstract than the general purpose rules and therefore easier to comprehend for the end user. 
  
 ===== Questions ===== ===== Questions =====
    * Enter questions here    * Enter questions here
api4kb_rules.txt · Last modified: 2012/12/09 15:18 by apaschke