====== Differences ====== This shows you the differences between two versions of the page.
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 a 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 |