-->
R u l e M L

<--


RuleML Design

Harold Boley, Benjamin Grosof, Michael Sintek, Said Tabet, Gerd Wagner

2002-09-03: Version 0.8




This page describes the current RuleML design.

Contents

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):

Other ways of reduction would have also been possible:

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

However, we prefer the RuleML hierarchy at the beginning of this section.

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


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)

Powered by Cocoon