-->

<--

This page describes the current RuleML design.

The RuleML Design

The current RuleML design is summarized in this section. RuleML encompasses a hierarchy of rules, including reaction rules (event-condition-action rules), transformation rules (functional-equational rules), derivation rules (implicational-inference rules), also specialized to facts ('premiseless' derivation rules) and queries ('conclusionless' derivation rules), as well as integrity-constraints (consistency-maintenance rules). Till now, we have been mostly defining derivation rules, facts, and queries (cf. current DTDs).

The RuleML hierarchy of general rules branches into the two direct categories of reaction rules and transformation rules. On the next level, transformation rules specialize to the subcategory of derivation rules. Then, derivation rules have further subsubcategories, namely facts and queries. Finally, queries specialize to integrity constraints. More subdivisions are being worked out, especially for reaction rules. Thus, the top-level RuleML picture looks as follows (type tags are given with each category, of which the most specific ones are used for concrete rule markups):

rules: rule

    reaction rules: react

    transformation rules: trans

        derivation rules: imp

            facts: fact

            queries: query

                integrity constraints: ic

A graphical view of RuleML rules is a reduction tree rooted in general rules. Its main branches distinguish reaction rules and transformation rules. Directly below transformation rules are derivation rules, Derivation rules specialize to facts and queries, which themselves can become integrity constraints. Thus, the most important reduction possibilites are as follows:

                     rules
                    /     \
                1. /       \ 2.
                  /         \
       reaction rules   transformation rules
                                 |
                              3. |
                                 |
                          derivation rules
                            |          |
                         4. |       5. |
                            |          |
                           facts   queries     
                                       |
                                    6. |
                                       |
                                   integrity constraints

Let us discuss the reduction tree's numbered reduction links in turn. (For a more fine-grained discussion of derivation rules, facts, and their further specialization to RDF triples see KR Principles and DTD Modularization, in particular the hierarchy slide 11.)

1. Reaction rules can be reduced to general rules that return no value.
2. Transformation rules can be reduced to general rules whose 'event' trigger is always activated.
3. Derivation rules can be reduced to transformation rules that like characteristic functions on success just return true.
4. Facts can be reduced to derivation rules that have an empty (hence, 'true') conjunction of premises.
5. Queries can be reduced to derivation rules that have -- similar to refutation proofs -- an empty (hence, 'false') disjunction of conclusions or -- as in 'answer extraction' -- a conclusion that captures the derived variable bindings.
6. Integrity constraints can be reduced to queries that are 'closed' (i.e., produce no variable bindings).

While general rules, as the all-encompassing rule category, could implement all other ones, in RuleML we are introducing tailored special-purpose syntaxes for each of these categories, as shown by the RuleML hierarchy at the beginning of this section. The following reductions of markup syntaxes only serve for our preliminary structuring of the various categories (for instance, we plan to permit and/or nestings besides flat conjunctions as premises):

• Reaction rules: <react> <_event> trigger </_event> <_body> <and> prem1 ... premN </and> </_body> <_head> action </_head> </react> reducible to <rule> <_event> trigger </_event> <_body> <and> prem1 ... premN </and> </_body> <_head> action </_head> <_foot> empty </_foot> </rule>
• Transformation rules: <trans> <_head> conc </_head> <_body> <and> prem1 ... premN </and> </_body> <_foot> value </_foot> </trans> reducible to <rule> <_event> active </_event> <_body> <and> prem1 ... premN </and> </_body> <_head> conc </_head> <_foot> value </_foot> </rule>
• Derivation rules: <imp> <_head> conc </_head> <_body> <and> prem1 ... premN </and> </_body> </imp> reducible to <trans> <_head> conc </_head> <_body> <and> prem1 ... premN </and> </_body> <_foot> true </_foot> </trans>
• Facts: <fact> <_head> conc </_head> </fact> reducible to <imp> <_head> conc </_head> <_body> <and> </and> </_body> </imp>
• Queries: <query> <_body> <and> prem1 ... premN </and> </_body> </query> reducible to <imp> <_body> <and> prem1 ... premN </and> </_body> <_head> bindings( var1, ..., varK ) </_head> </imp>
• Integrity constraints: <ic> <_body> <and> prem1 ... premN </and> </_body> </ic> reducible to <query kind="closed"> <_body> <and> prem1 ... premN </and> </_body> </query>

Other ways of reduction would have also been possible:

• Transformation rules could be conversely reduced to derivation rules over special relations that have an extra argument for the transformation values, much like in their treatment with a built-in equality relation.
• Derivation rules could be reduced to reaction rules whose 'event' trigger is always activated and whose action just adds or 'asserts' a conclusion when certain events/conditions (premises) are recognized/fulfilled. This asserting of conclusions can be regarded as a purely declarative step, as used for model generation and fixpoint semantics. Such rules can thus also be applied backward for proving a conclusion from premises.
• Integrity constraints could be reduced to "denials" or special reaction rules whose only possible kind of action is to signal inconsistency when certain conditions are fulfilled (perhaps after recognizing a trigger event).

These reduction possibilities would have led to the following reductions of markup syntaxes:

• Transformation rules: <trans> <_head> conc </_head> <_body> <and> prem1 ... premN </and> </_body> <_foot> value </_foot> </trans> reducible to <imp> <_head> conc-with-value </_head> <_body> <and> prem1 ... premN </and> </_body> </imp>
• Derivation rules: <imp> <_head> conc </_head> <_body> <and> prem1 ... premN </and> </_body> </imp> reducible to <react> <_event> active </_event> <_body> <and> prem1 ... premN </and> </_body> <_head> <assert> conc </assert> </_head> </react>
• Integrity constraints: <ic> <_body> <and> prem1 ... premN </and> </_body> </ic> reducible to <react> <_event> trigger </_event> <_body> <and> prem1 ... premN </and> </_body> <_head> <signal> inconsistency </signal> </_head> </react>

We can now make more precise our views regarding the application direction for the various rule categories:

• Reaction rules can only be applied in the forward direction in a natural fashion, observing/checking events/conditions and performing an action if and when all events/conditions have been recognized/fulfilled.
• For transformation rules, on the other hand, the backward direction is normally preferred.
• Derivation rules can be equally applied in the forward direction as well as in the backward direction, the latter reducing the proof of a goal (conclusion) to proofs of all its subgoals (premises). Since in different situations different application directions of derivation rules may be optimal (forward, backward, or mixed), RuleML does not prescribe any one of these.
• For facts or 'unit clauses' there is no notion of an application direction.
• For queries there is the following notion of application direction: as top-down goals, they are proved backward; but they can also be proved forward via 'goal-directed' bottom-up processing.
• Integrity constraints are usually forward-oriented, i.e. triggered by update events, mainly for efficiency reasons. But they can instead be backward-oriented, trying to show (in)consistency by fulfilling certain conditions (without need for recognizing any event).

Site Contact: Harold Boley. Page Version: 2002-09-03


"Practice what you preach": XML source of this homepage at indesign.xml (indesign.xml.txt);
transformed to HTML via the adaptation of Michael Sintek's SliML XSLT stylesheet at homepage.xsl (View | Page Source)