api4kb_rules
====== Differences ====== This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
api4kb_rules [2012/10/13 10:52] rmbell |
api4kb_rules [2012/10/22 05:13] 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 (RuleML as general rule interchange language and RIF as specialized Web rule interchange format) |
| - | * Load vocabularies | + | * Translate and Load vocabularies |
| - | * Execute rules | + | * Execute rules (transformations from the platform-independent interchange format into the platform-specific executable rule language) |
| + | * Interchange of queries and answers (at a minimum) | ||
| + | * Interchange of rule sets / rule bases | ||
| + | * Interchange of proofs | ||
| + | * Interchange of test cases for verification and validation | ||
| 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 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 | ||
| + | * wrap rule inference services into agents (see e.g. RuleResponder) | ||
| + | * agent role models | ||
| + | * pragmatic primitives for coordination and negotiation (e.g. FIPA ACL primitives) | ||
| + | * description of non-functional properties of the rule service | ||
| + | * 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 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. | ||
api4kb_rules.txt · Last modified: 2012/12/09 15:18 by apaschke
Page Tools
