Reaction Rules for the Rule Markup Language
Reaction RuleML Home
Reaction RuleML
 
 

Reaction RuleML 0.2

Adrian Paschke, Alexander Kozlenkov, Harold Boley, Said Tabet, Michael Kifer, Mike Dean

Version history:
2006-10-12 - Reaction RuleML 0.1
2007-07-22 - Reaction RuleML 0.2

Quick Links:

Syntax, Schema, Examples, Glossary

Overview

Reaction RuleML is a general, practical, compact and user-friendly XML-serialized language and rule interchange format for the family of reaction rules. It incorporates different kinds of production, action, reaction, complex event notification / messaging and KR temporal/event/action logic rules into the native RuleML syntax using a system of step-wise extensions. In particular, the approach covers different kinds of reaction rules from various domains such as global active-database ECA rules and triggers, forward-directed production rules, backward-reasoning temporal-KR event/action/process logics, complex event processing, notification & messaging and active update, transition and transaction logics. It covers different execution styles for processing them such as active, where the reaction rules are applied in a global context and actively pull or detect the events possibly clocked by a monitoring/validity time function, messaging, where the reaction rules send event messages and wait (listen) on or query for matching event message instances, e.g. incoming event messages (inbound), which match with the define event definition patterns, and reasoning, where the focus is on the formalization of events and actions and reasoning on their effects on changeable knowledge states (fluents) and state transitions. Reaction rules can be specified on a global level in a tight combination with other rule types such as derivation rules or integrity constraints or locally, i.e. nested within other derivation or reaction rules. There are different evaluation styles for reaction rules such as strong and weak interpretation which are used to manage the "justification lifecycle" of local reaction rules in the derivation process of the outer rules. Reaction RuleML supports procedural calls on external procedures with side effects and enables expressive transactional OID-based updates on the extensional and intensional knowledge base, i.e. on facts and rules. Sophisticated postconditional verification, validation and integrity tests (V&V&I) using integrity constraints or test cases can be applied as post-conditional tests, which possibly might lead to roll-backs of the update actions. Complex events and actions can be expressed in terms of complex event / action algebra operators and workflow-like processes and coordination patterns. Different complex event processing, selection and consumption policies can be configured.
Reaction RuleML Home
Content

Overview
Scope
Modularization
Changes
Examples
XSD Schema
Syntax
Glossary
Editor
Validation
Translators
References

 
News

Reaction RuleML 0.2 Release, 2007-07-01 (xsd)

Int. RuleML Symposium on Rule Interchange and Applications (RuleML-2007), 2007-10-25/26, co-located with the 10th International Business Rules Forum
Register NOW !!!

all news>>

 
Reaction RuleML List

Archives
Subscribe

post a message:
reaction-tg@ruleml.org

 
Publications

Paper at VLDB EDA-PS'07 (pdf)

Reaction RuleML 0.1 Tutorial at RuleML'06 (slides)

Reaction RuleML Poster at RuleML 2006 (pdf)

Position Paper at Business Rules Forum 2006 (pdf)

all publications>>

 
Members Section

Login
 

Scope

Reaction RuleML covers constructs for (complex) events, actions and states/fluents/transition (changeable properties and transitions) definition and processing/reasoning for different derivation rule, production rule and reaction rule programs according to the

Reaction RuleML Classification of the Event / Action / State Definition and Processing Space

 

Modularization

Reaction RuleML follows the design principle of RuleML and defines new constructs within separated modules which are added to the RuleML family as additional layers on top of the hornlog layer of RuleML. Version 0.2 generalizes the syntax of rules to a core rule format which can be specialized in different language families to different rule types such as derivation rules, production rules, reaction rules as well as mixed formats such as serial derivation rules which contain locally nested reaction rules and event/action constructs, e.g. update literals. The layers are not organized around complexity, but add different modelling expressiveness to the Reaction RuleML core for the representation of behavioural (re)action and KR event/action logic.

The language fulfils typical criteria for good language design such as minimality, symmetry and orthogonality. With minimality we mean that Reaction RuleML provides only a small set of needed language constructs in addition to the existing constructs in RuleML, i.e., the same meaning cannot be expressed by different language constructs. Symmetry is fulfilled in so far as the same language constructs always expresses the same semantics regardless of the context they are used in. Orthogonality permits every meaningful combination of a language constructs to be applicable. Moreover, Reaction RuleML satisfies typical knowledge representation adequacy criteria such as epistemological adequacy w.r.t. the various application domains of reaction/action/production rules and KR event / action logics:

"A representation is called epistemologically adequate for a person or a machine if it can be used practically to express the facts that one actually has about the aspects of the world.„

McCarthy/Hayes 1969

 

Derivation RuleML: Defines Syntax and Semantics for Derivation Rules

PR RuleML: Defines Syntax and Semantics for Production Rules

Reaction RuleML: Defines Syntax and Semantics for Reaction Rules

KR RuleML: Defines Syntax and Semantics for KR event/action logic formalisms and state, transition, process logic formalisms

 

Changes

Changes in this 0.2 release relative to the previous version 0.1 are detailed below, including examples where appropriate

1) Reaction RuleML 0.2 replaces <Implies> from RuleML and generalizes the syntax of different rule families by introducing one general <Rule> construct for all types of Rules. For instance:

Derivation Rule:                                             Production Rule:                                             ECA Rule:

<Rule style="reasoning">       <Rule style="active">          <Rule style="active">
  <if>...</if>                        <if>...</if>                       <on>...</on>
  <then>...</then>                    <do>...</do>                       <if>...</if>
</Rule>                            </Rule>                               <do>...</do> </Rule>

2) Reaction RuleML 0.2 adds an optional meta data label <label>, a scope <scope>, and a qualification <qualification> to a RuleML specification <RuleML>, rule bases (module) <Rulebase> or <Assert> (implicit rule base), Queries <Query>, rules <Rule>, and facts/goals <Atom>.

  • The meta data label can be used to define additional meta data (binary propety-value pairs) about the rule, e.g. the user-defined rule name or Dublin Core annotations such as dc_data or dc_author.
  • The scope defines a view on the rule base, i.e. it constructs a view using query expressions on an explicitly closed part of the (possible distributed) modularized knowledge base. More specific scopes of queries and goals (e.g. goal literals in the body of a rule) overwrite defined default scopes of rule bases which apply by default to all goals/queries in the respective rule bases. If no scope is specified a query/goal applies on the maximum scope which is the entire knowledge base (note, might be possibly an open distributed KB on the Web).
  • The qualification defines an optional set of rule qualifications such as a validity value, fuzzy value or a priority value. Again more special qualifications of e.g. rules overwrite more general qualifcations of rule bases (modules), e.g. module1 > module 2 (module1 is superior to module2).
<Assert>

 <Rulebase>
   <!-- qualification of rule base / module
   <qualification>
     <Plex>
          <!-- module 1 has priority level 1 -->
          <Expr><Fun per="value">priority</Fun><Ind type="xsd:Integer">1</Ind></Expr>
          <!-- the module is applicable after 2007-07-01 -->
          <Expr> 
                <Fun per="value">validity</Rel>
                <Expr>
                    <Fun per="value">start</Fun>
                    <Ind>2007-07-01</Ind>
                </Expr>
          </Expr>
     </Plex>
   </qualification>
   <!-- oid of the rule base / module -->
   <oid><Ind>module1</Ind></oid>  
  
   <Rule>
    <!-- meta data label -->
    <label>
      <Plex>
         <Expr><Fun uri="dc:titel" per="value"/><Ind>rule1</Ind></Expr> <!-- user-defined rule name -->
         <Expr><Fun uri="dc:author" per="value"/><Ind>Adrian Paschke</Ind></Expr>
         <Expr>
               <Fun uri="dc:description" per="value"/>
               <Ind>Discount rule for premium customers</Ind>
         </Expr>
      </Plex>
    </label>
  
    <!-- rule scope -->
    <scope>
       <!-- define scope for the rule on the local module with oid "module1"
            i.e. all goals of the rule by default apply with respect to the scope "#module1"            
       -->
       <Ind uri="#module1"/>
    </scope>
  
    <!-- rule qualification -->
    <qualification>
      <Plex>
        <Expr> <!-- applicability period of the rule -->
         <Fun per="value">validity</Fun>
         <Expr>
           <Fun per="value">start</Fun>
           <Ind>2007-07-01</Ind>
         </Expr>
         <Expr>  
           <Fun per="value">end</Fun>
           <Ind>2007-08-01</Ind>
         </Expr>
        </Expr>
       </Plex>
     </qualification>
  
     <!-- object id of the rule -->
     <oid><Ind>r0001</Ind></oid>
  
     <!-- main part of the rule -->
     <if>
      <Atom>
         <Rel>premium</Rel>
         <Var>Customer</Var>
      </Atom>
     </if>
     <then>
      <Atom>
         <Rel>discount</Rel>
         <Var>Customer</Var>
         <Ind type="math:Percentage">10</Ind>
      </Atom>
     </then>
    </Rule>
  
    ...

 </Rulebase>
</Assert>

3) Reaction RuleML 0.2 defines the following update actions which can be used within rules (e.g. production rules, serial Horn rules or ECA reaction rules) to dynamically modify, add and retract knowledge:

Assert (add knowledge); Retract (retract knowledge); Update (update knowledge); Equal (assign knowledge to variable)

The optinal attribute @all="yes|no"; default="no" in <Assert>, <Retract> and <Update> denotes if the update action applies on all knowledge formulas or all modules which match the pattern or module oid defined in the update action.
The optinal attribute @safety="normal|transaction"; default="transaction" in <Assert>, <Retract> and <Update> transactional (bulk) updates which might be possible rolled-back or normal updates without transaction safety.
The update construct is introduced for convinience reasons. The most general form is update(fact1,fact2) or update(module1,module2). This is equivalent to the two update actions retract(fact1), assert(fact2) or retract(oid1), assert(oid2). A simpler form update(fact1) or update (oid1) is equivalent to retract(fact1), assert(fact1) or retract(oid1), assert(oid1). 

<Rule style="active"> <!-- production rule --> 
   <if>
       <And>
            <Atom><Rel>available</Rel><Var>Service</Var></Atom>
            <Atom><Rel>request</Rel><Var>Task</Var></Atom>
       </And>
   </if>
   <do>
       <Assert>
            <Atom><Rel>loaded</Rel><Var>Service</Var><Var>Task</Var></Atom>
       </Assert> 
   </do> 
</Rule>
<Rule style="reasoning"> <!-- serial Horn rule -->
  <if>
    <And>
       <Atom><Rel>employee</Rel><Var>Name</Var><Var>Salary</Var></Atom>
       <Equal> <!-- increase salary and assign value to variable -->
           <Var>IncreasedSalary</Var>
           <Expr>
              <Fun per="value">add</Fun>
              <Var>Salary</Var>
              <Var>Bonus</Var>
           </Expr>
       </Equal>
       <Update all="yes" safety="transaction"> <!-- transactional all-update with new salary -->
           <Atom>
               <Rel>employee</Rel>
               <Var>Name</Var>
               <Var>IncreasedSalary</Var>
           </Atom>
       </Update>
    </And>
  </if>
  <then>
     <Atom>
        <Rel>increasedSalary</Rel>
        <Var mode="?">Name</Var> <!-- input or output variable-->
        <Var mode="-">IncreasedSalary</Var> <!-- output variable -->
     </Atom>
  </then> 
</Rule>

<Rule style="active"> <!-- production rule with complex action on modules -->
   <if>
      <Atom>
         <Rel>occurs</Rel>
         <Ind>outage</Ind>
      </Atom>
   </if>
   <do>
     <Succession> <!-- complex action -->
       <!-- add rule base with oid "module2" -->
       <Assert>
           <!-- oid of asserted rulebase (module) -->
           <oid><Ind>module2</Ind></oid>
           <Rulebase>
              <Rule>
                 <oid><Ind>r1</Ind></oid>
                 ...
              </Rule>
           </Rulebase>
       </Assert>
       <!-- update rule r1 with rule r2 -->
       <Update>
           <oid><Ind uri="#r1"/></oid>
           <Rule><oid><Ind>r2</Ind></oid>...</Rule>
       </Update>
       <!-- remove module1 -->
       <Retract><oid><Ind uri="#module1"/></oid></Retract>
     </Succession> 
   </do>
</Rule>

4) Reaction RuleML 0.2 redefines the complex event and action algebra and adds further operators for complex event and action definitions:

Action Algebra:
    Succession (Ordered Succession of Actions), Choice (Non-Determenistic Choice),
    Flow (Parallel Flow), Loop (Loops)
Event Algebra:
    Sequence (Ordered), Disjunction (Or) , Xor (Mutal Exclusive), Conjunction (And),
   Concurrent , Not, Any, Aperiodic, Periodic

 

5) Reaction RuleML 0.2 defines Complex Event Messages also on the top-level of RuleML for message interchange: 

<RuleML>
  <Message mode="outbound" directive="ACL:inform">...</Message>
</RuleML>

 

6) Reaction RuleML 0.2 defines the RuleML Interface Description Language (RuleML IDL) for describing the signatures of public rule functions together with their mode ("+"=input; "-"=output; "?"=input or output) and type declarations. These interface descriptions are important in open distributed rule-based environments. 


<Assert>
 <Rulebase>
   <label>
       <!-- Interface describing the signature of the add function in this rule base (module)
            which concats two Strings -->
       <Interface>
          <label>
            <!-- Huma-oriented description of the interface -->
            <Expr>
               <Fun uri="dc:description"/>
               <Ind>adds (concats) two Strings and returns the result as first argument</Ind>
            </Expr>
          </label>
          <Fun per="value">add</Fun> 
          <Var type="java://java.lang.String" mode="-">Result</Var> 
          <Var type="java://java.lang.String" mode="+">String1</Var> 
          <Var type="java://java.lang.String" mode="+">String2</Var> 
       </Interface>
    </label>
    <Rule>
       <if>
           <!-- Result = String1.concat(String2) -->  
           <Equal>
              <Var java://java.lang.String>Result</Var>
              <Expr>
                  <oid><Var type="java://java.lang.String">String1</Var></oid>
                  <Fun per="value">concat</Fun>
                  <Var type="java://java.lang.String">String2</Var>
              </Expr>
           </Equal>
        </if>
        <then>
           <Atom>
               <Rel>add</Rel>
               <Var type="java://java.lang.String" mode="-">Result</Var> 
               <Var type="java://java.lang.String" mode="+">String1</Var> 
               <Var type="java://java.lang.String" mode="+">String2</Var> 
            </Atom>
       </then>
    </Rule>
 </Rulebase>
</Assert>

7) Reaction RuleML 0.2 explicitly denotes the usage (@per="plain|value|effect|modal") of functions and relations rather than providing only @in="no|yes" (change planned generally for RuleML 0.91 to RuleML 0.92 transition).A <Rel> or <Fun> with "plain" use is left uninterpreted, with "value" use is interpreted purely for its value,with "effect" use is interpreted impurely both for its value and its (side-)effect action (e.g. procedural attachment),and with "modal" use is intpereted as pure modality.

8) Reaction RuleML 0.2 generalizes the support for procedural attachments. A procedural attachment is a function or predicate whose implementation is given by an external procedure. Two types of procedural attachments are distinguished:

  • Boolean-valued attachments (or predicate attachments), wrapped by <Atom>, which call methods which return a Boolean value, i.e., which are of Boolean sort (type).
  • Object-valued attachments (or functional attachments), wrapped by <Expr>, which are treated as functions that take arguments and return one or more objects, i.e., which are of a function sort.
<!-- Bind the constructed Java object to the variable Date = java.io.Calendar.getInstance() -->
<Equal>	
  <Var>Date</Var>				      
  <Expr>		
     <!-- class -->
     <oid><Ind uri="java://java.util.Calendar"/></oid> 
     <!-- constructor  -->
     <Fun per="effect">getInstance</Fun>
  </Expr>
</Equal>

<!-- Use the bound object of the variable and call a function of the object -->
<Atom>
  <!-- object previously bound to Date -->
  <oid><Var>Date</Var></oid>
  <Rel per="effect">isSet</Rel>
  <Ind>1</Ind>
</Atom>

<!-- Call a C# method -->
<Atom>
  <oid><Ind uri="c-sharp://System.Console"/></oid>
  <Rel uri="WriteLine"/>
  <Ind>Hello World</Ind>
</Atom>

9) Reaction RuleML 0.2. is extensible and supports adding XML elements and/or attributes of non-RuleML namespaces to RuleML terms by using them as types.

<Atom>
  <oid>
    <Ind type="cbe:CommonBaseEvent">i000000</Ind>
  </oid>
  <Rel per="value" uri="cbe:msg"/>
  <Ind type="xs:string">Hello World</Ind>
</Atom>

It also supports XPointer and XPath expressions as manipulation and query language to point into and select data from external XML data sources

<Atom>
   <Rel>name</Rel>
   <Ind uri="person.xml#xpointer(//Person/LastName[1]/text())/>
</Atom>


<Atom> 
   <Rel uri="BPEL_Process.xml#xpointer(//invoke[@name=checkHotel])"/>
</Atom>

It is possible to define query and manipulation expressions that operate on (large) resource sets instead on singleton resources, e.g. to specify a consturctive view over a set of external nodes specified by a XPath query expression.

<Atom>
  <oid><Ind uri="customer.xml#xpointer(/Customer[1]/range-to(/Customer[4]))"/></oid>
</Atom>

The URIs are query expressions that return constructive views on resource sets that are treated as singletons, i.e. a constructive view over a set of resources is a singleton with an unique URI denoted by the query expression.. It is possible to bind the views to variables similar to the approach of binding constructed Java objects to variables and reuse the variables in the local reasoning/execution scope.

<!-- Bind the constructed resource set to the variable Customers  --> 
<Equal> 
   <Var>Customers</Var> 
   <Expr> 
      <!-- constructive view as singleton with unique oid -->
      <oid><Ind uri="customer.xml#xpointer(/Customer[1]/range-to(/Customer[4]))"/>
   </Expr>
<Equal>

<!-- Access the bound variable using "$" notation -->
<Atom>
  <Rel>name</Rel>
  <Ind uri="$Customers/Customer[1]/LastName/text()"/>
</Atom>

The special "$" notation for variable access in attributes is a "short cut" notation for an expression with the variable in the unique object identifier (oid) and the query in the function of the expression:

 <Expr>
   <!-- resource/object or resouce set/object collection bound to variable used as context node -->
   <oid><Var>Customers</Var></oid>
   <!-- query expression -->
   <Fun per="value" uri="Customer[1].LastName/text()"/>
 </Expr>

The Reaction RuleML implementation may support other expression languages or query languages such as e.g. SQL, SPARQL, OWL2Prova RDF in a similar way to select resource sets and create constructive views on external data sources.

 

Examples

Reaction RuleML 0.2 examples
Reaction RuleML 0.2 Primer

 

XSD Schemas

A stable XML Schema specification of Reaction RuleML 0.2 has been created.

 

Syntax

Core Reaction Rule 0.2 Syntax:

<Rule style="active" evaluation="strong">
  <label> <!-- meta data --> </label>
  <scope> <!-- general scope of rule --> </scope>
  <qualification> <!-- qualifications --> </qualification>
  <oid> <!-- object identifier --> </oid>
  <on> <!-- event --> </on>
  <if> <!-- condition --> </if>
  <then> <!-- conclusion --> </then>
  <do> <!-- action --> </do>
  <after> <!-- postcondition --> </after>
  <else> <!-- else conclusion --> </else>
  <elseDo> <!-- else/alternative action --> </elseDo>
  <elseAfter> <!-- else postcondition --> </elseAfter>
</Rule>

complete syntax, content models and meta models >>

 

Glossary

Small glossary with basic constructs/tags - a more detailed description will follow soon:

  • Rule: General reaction rule construct
  • @style: Denotes execution style of the reaction rule: "active | messaging | reasoning"; default = "reasoning"; optional
  • @evaluation: Optinal attribute denoting the interpretation of the reaction rule: "strong | weak"; default="strong"
  • on, if, then, do, after, else, elseDo, elseAfter: Role tags for the reaction rule parts which might be used to specialise a Rule to a certain type, e.g. to a derivation rule (if-then or if-then-else), a trigger rule (on-do), a production rule (if-do), an ECA rule (on-if-do) and special cases such as ECAP rule (on-if-do-after) or mixed rule types such as serial derivation rule with alternative action (if-then-elseDo)
  • Sequence, Disjunction, Conjunction, Xor, Concurrent, Not, Any, Aperiodic, Periodic: Event Algebra operators
  • Succession, Choice, Flow, Loop: Action Algebra operators
  • Message: Defines an inbound or outbound message
  • Assert, Retract: Update primitives to update the intensional and extensional KB
  • Initiates, Terminates: KR event/action logics construct initiating or terminating a state (a.k.a. fluent or window)

complete glossary (to appear)>>

 

Editor

RuleML / Reaction RuleML Editor (to appear)

 

Validation


You can validate your Reaction RuleML XML documents online with the Reaction RuleML Validator Services

 

Translators

You can translate your Reaction RuleML XML documents with the Reaction RuleML Translators Services

 

References

Site Contact: Adrian Paschke - Last Update 2007-07-21