-->

<--

Rules in (and for) the Web have become a mainstream topic since inference rules were marked up for E-Commerce and were identified as a Design Issue of the Semantic Web, and since transformation rules were put to practice for document generation from a central XML repository (as used here). Moreover, rules have continued to play an important role in AI shells for knowledge-based systems and in Intelligent Agents, today both needing a Web interchange format, and such XML/RDF-standardized rules are now also usable for the declarative specification of Web Services.

The Rule Markup Initiative has taken initial steps towards defining a shared Rule Markup Language (RuleML), permitting both forward (bottom-up) and backward (top-down) rules in XML for deduction, rewriting, and further inferential-transformational tasks. The initiative started during PRICAI 2000, as described in the Original RuleML Slide, and was launched in the Internet on 2000-11-10. Besides the previous XML-only RuleML and the current XML/RDF-combining RuleML, there is also an approach towards an RDF-only RuleML. Complementary efforts consist of the development of (Java-based) rule engines such as Mandarax RuleML and XSB-RDF RuleML. There now exists an initial RuleML design and a Version 0.8 system of DTDs for basic RuleML sublanguages.

The Initiative

The participants of the RuleML Initiative constitute an open network of individuals and groups from both industry and academia. We are not commencing from zero but have done some work related to rule markup or have actually proposed some specific tag set for rules. Our main objective is to provide a basis for an integrated rule-markup approach that will be beneficial to all involved and to the rule community at large. This shall be achieved by having all participants collaborate in establishing translations between existing tag sets and in converging on a shared rule-markup vocabulary. This RuleML kernel language can serve as a specification for immediate rule interchange and can be gradually extended - possibly together with related initiatives - towards a proposal that could be submitted to the W3C.

Uses

Rules are being used for many interconnected purposes, capturing regularities in application domains such as the following:

• Engineering: Diagnosis rules (also model-based approaches appreciate and combine with rules, as described by Adnan Darwiche in Model-based diagnosis under real-world constraints, AI Magazine, Summer 2000)
• Commerce: Business rules (including XML versions such as the Business Rules Markup Language (BRML) of IBM's Business Rules for Electronic Commerce project)
• Law: Legal reasoning (Robert Kowalski and Marek Sergot have been formalizing legal rules in an Imperial College group)
• Internet: Access authentication (Tim Berners-Lee proposed registration engines that use authentication rules such as the following: Any person who was some time in the last 2 months an employee of an organization which was some time in the last 2 months a W3C member may register.)

Scope

Rules can be stated (1) in natural language, (2) in some formal notation, or (3) in a combination of both. Being in the third, 'semiformal' category, the RuleML Initiative is working towards an XML-based markup language that permits Web-based rule storage, interchange, retrieval, and firing/application.

Markup standards and initiatives related to RuleML include:

• Mathematical Markup Language (MathML): However, MathML's Content Markup is better suited for defining functions rather than relations or general rules
• DARPA Agent Markup Language (DAML): While the contributing SHOE project has permitted Horn rules and a DAML-RULES is planned, the current DAML+OIL (March 2001) does not yet include a specification of explicit inference rules
• Predictive Model Markup Language (PMML): With this XML-based language one can define and share various models for data-mining results, including association rules
• Attribute Grammars in XML (AG-markup): For AG's semantic rules, there are various possible XML markups that are similar to Horn-rule markup
• Extensible Stylesheet Language Transformations (XSLT): This is a restricted term-rewriting system of rules, written in XML, for transforming XML documents into other XML documents

Participants (Updated: 2002-08-06)

2001-05-11: "RuleML, the emerging standards effort on XML Rules knowledge representation, continues to progress in its design -- and also in its acceptance; notably, IBM this past month joined as participant and publicly disclosed that it is prototyping support for RuleML. Presentation materials from two recent W3C meetings, and a new short overview conference paper, are now available: see http://www.mit.edu/~bgrosof/#XMLRules." (Also see: alphaWorks Posting. Contact: Hoi Chan.)

Steps

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

DTDs-Schemas

2001-01-31: A preliminary RuleML DTD has been released: RuleML DTD Version 0.7.
2001-07-11: A revised DTD version has been finalized: RuleML DTD Version 0.8.
2001-09-25: A preliminary XML Schema for a Datalog subset of RuleML has been released: RuleML Schema Version 0.8.
2002-04-02: A query DTD version has been realized (cf. Queries): RuleML DTD Version 0.8.
The discounting business rules example shows some of the features: discount.ruleml (discount.ruleml.txt).

Queries

As in many deduction approaches, RuleML queries are regarded as headless implications, symmetrically to regarding facts as bodiless implications. They enumerate the bindings of all their free (existentially interpreted) variables.

Queries were added to RuleML 0.8 as a third top-level element of rulebases besides facts and imps (since this extension is purely additive, all queriless RuleML 0.8 rulebases should still validate). This gives us "for free" all refinements of RuleML's existing system of sublanguages via the _body role of queries: because of RuleML's DTD inheritance, additions were only required for ruleml-datalog.dtd (ruleml-datalog.dtd.txt) and urcbindatagroundfact.dtd (urcbindatagroundfact.dtd.txt). In particular, ruleml-datalog.dtd's query-extended rulebase definition is inherited by ruleml-hornlog.dtd, where queries in datalog use only inds and vars but queries in hornlog automatically also permit cterms (because hornlog atoms permit cterms).

RuleML queries are illustrated by our business-rule example discount.ruleml (discount.ruleml.txt) and by Eric Prud'hommeaux's RDF Query example wsdl-rdf-query.ruleml (wsdl-rdf-query.ruleml.txt).

This query incorporation into RuleML assumes that the sublanguage expressiveness should be the same for 'assertions' (facts and imps) and for the 'requests' (queries) on them. So, it cannot, e.g., express queries on ground triples (containing no variables) via non-ground triples (containing variables): creator.ruleml (creator.ruleml.txt). However, users can still employ one rulebase (module) with its DTD for 'assertions', and another rulebase (module) with a different DTD for 'requests'.

RDF

An experimental RDF translator for a subset of RuleML 0.7 is available in XSLT: RuleML in RDF Version 0.2. RuleML 0.8 now stands in the direct Context of RDF.

2001-06-20: Michael Sintek has implemented a (Java) parser for an RDF version of the Horn-logic subset of RuleML 0.8; it reflects an RDF RuleML syntax by (Java) classes that currently generate textual Horn clauses but could be adapted for generating the XML RuleML syntax: The FRODO rdf2java Tool. A converse translator from XML RuleML 0.8 to RDF RuleML 0.8 should be easier to write in XSLT than was possible for the above-linked RuleML 0.7 translator.

Induction

The FLIP Group uses RuleML in machine learning: About using RuleML for expressing machine learning knowledge. In the LispMiner project work with RuleML is directed towards statistical association rules.

Translators

Since RuleML should help rule-system interoperation, (XSLT, ...) translators for RuleML rulebases are rather important. Please send us further translator pairs between your system and RuleML -- even if your translators are (still) partial.

In February 2001 Mike Dean created the first operational RuleML rulebase, GEDCOM, with rules on family relationships (child, spouse, etc.) run via XSLT translators to the XSB, JESS, and n3/cwm engines.

2001-09-17: Harold Boley has specified XSLT translators between the Horn-logic subsets of RuleML and RFML. These can make implementations of both systems available to each other and permit, e.g., a preliminary HTML rendering of RuleML rulebases. The XSLT stylesheets may also serve as blueprints for specifying further translators to/fro RuleML.

2001-09-19: Andreas Eberhart implemented an alpha version of OntoJava. The basic idea is to automatically map Protégé ontologies, instances defined in them, and RuleML rules into a sinlge Java main memory DB / rule engine that can then be used as the basis of an application. He is looking forward to hearing of your ideas and input.

2002-02-04: Andreas Eberhart extended OntoJava by reaction rules:

<java>
        runtime.Loader.load("http://localhost:8080/servlet/SearchGate?flight="
                         + <var>F</var>.name, false);
</java>

2002-07-08: Said Tabet created an XSLT stylesheet for transforming from a version of RuleML to Jess. The full Java environment for running this is available from Said Tabet.

Engines

One or more rule engines will be needed for executing RuleML rulebases. On 2000-11-15, the RuleML Initiative thus joined forces with the Java Specification Request JSR-000094 Java Rule Engine API. This cooperation will enable a direct cross-fertilization between the complementary specifications of the open XML-based Rule Markup Language and of the Java runtime API for rule engines.

2001-06-04: Jens Dietrich implemented the first complete input-processing-output environment for RuleML. To download the api (source code) click Mandarax RuleML. Any feedback is welcome! If you have problems, don't hesitate to contact Jens for assistance.

2001-06-26: Michael Sintek has implemented a small XSB-based engine that can also be looked at as the first RuleML querying agent. It's a servlet (running in Tomcat) that receives RuleML rulebases in RDF RuleML syntax (since he uses The FRODO rdf2java Tool) together with some queries, evaluates them with XSB Prolog (in auto-tabling mode, which should be equivalent to bottom-up evaluation!), and returns the result as an HTML page containing the bindings as facts of instantiated queries. A future version must, of course, return a RuleML file. Simply try this URL. Click on 'example' and paste the RDF RuleML popping up into the input window (note that pasting XML/RDF cannot be directly done in IE, only in Netscape; use "view source" in IE). Alternatively, you can use the Prolog parser and RDF translator to generate the RDF RuleML. Since we cannot guarantee that the above URLs always work (server reboots etc.), this picture shows the agent in action. Any feedback is welcome! If you have problems, don't hesitate to contact Michael for assistance.

2002-02-06: Bruce Spencer further refined The Design of j-DREW, a Deductive Reasoning Engine for the Semantic Web.

2002-03-08: Jens Dietrich has finally published Mandarax 1.6 with major improvements, including new docs and all the features discussed in the Mandarax Dagstuhl Talk. One of the new packages is xkb_b1.jar -- it contains a modular driver to translate rule bases to XML and vice versa. I.e., there are tiny adapter objects responsible for exporting/importing rules, facts, terms etc. This should enable us to set up a reference application for any new standard in hours.

User Interfaces (New: 2002-08-15)

RuleML Participant Jens Dietrich's Oryx (version 2.1) has a graphical Knowledge Editor for business rules and a Repository that contains the description of predicates, functions, and database connections. "Oryx works with open XML based formats, support for the emerging RuleML standard and the open source Mandarax XKB 1.0 format is included." (http://www.jbdietrich.com).

Michael Sintek has implemented a Prolog parser and RDF translator to generate RDF RuleML.

Andreas Eberhart wrote a small tool that allows you to convert Prolog (currently, Datalog) rules to RuleML. This Prolog2RuleML tool is available both online and as a command line version.

Rulebase Library

A library of RuleML rulebases is being accumulated here as a collection of use cases for further design discussion and as examples for practical rule exchange (RuleML Library). The highest version of RuleML (currently 0.8) should be used whenever possible. If you have an entry, please send us its pointer.

• 2002-03-06: Mike Dean's GEDCOM rulebase GEDCOM RuleML 0.7, with rules on family relationships (child, spouse, etc.), has been made available: GEDCOM RuleML 0.8 (View | Page Source).
  This is Elina Hotman's result of having GEDCOM RuleML 0.7 (local copy: GEDCOM RuleML 0.7), first transformed by the XSLT stylesheet ruleml2rfml_gedcom.xsl (a translator version of ruleml2rfml.xsl) to the -- likewise positional -- RFML form GEDCOM RFML 0.8, and then having that further transformed by the XSLT stylesheet rfml2ruleml_gedcom.xsl (a translator version of rfml2ruleml.xsl) to the -- role-using -- RuleML 0.8 form GEDCOM RuleML 0.8.
  Coincidentally, Jos De Roo used GEDCOM RuleML 0.7 to generate GEDCOM N3, from which Jonathan Borden generated GEDCOM RDFxt (www-webont-wg -- LANG: GEDCOM N3 as RDFxt). Thus, GEDCOM looks like a good benchmark for transforming between RuleML and related systems (future transformers should directly start off from GEDCOM RuleML 0.8 or higher). A draft specification for the original GEDCOM XML is available.
• 2002-06-24: Sabrina Scherer and Benjamin Olschok, University of Saarbrücken, in cooperation with Harold Boley, DFKI, have completed the prototype of a Rule-Applying Comparison-Shopping Agent, RACSA, which takes into account various (discount-like) rules for computing the special price a customer will be offered. RACSA is based on RuleML, Mandarax, and Java; it is currently being developed for comparing refrigerator end prices in the German and European market, but can be easily adapted to other products and/or markets. A RACSA servlet and the comparison-shopping rulebases will soon be made available here for testing.
• 2002-07-08: Said Tabet created an XSLT stylesheet for transforming from a version of RuleML to Jess. This is exemplified by an animal rulebase transformed from its neutral RuleML version (rules1.xml.txt) into a forward-reasoning Jess version. The full Java environment for running this is available from Said Tabet.

Papers-Publications

• Harold Boley: A Web Data Model Unifying XML and RDF. Draft, September 2001.
• Harold Boley: The Rule Markup Language: RDF-XML Data Model, XML Schema Hierarchy, and XSL Transformations, Invited Talk, INAP2001, Tokyo, October 2001.
• Harold Boley, Said Tabet, Gerd Wagner: Design Rationale of RuleML: A Markup Language for Semantic Web Rules, Proc. SWWS'01, Stanford, July/August 2001.
• Andreas Eberhart, An Agent Infrastructure based on Semantic Web Standards, Workshop on Business Agents and the Semantic Web at the AI 2002, Calgary, Canada
• Andreas Eberhart, Automatic Generation of Java/SQL based Inference Engines from RDF Schema and RuleML, International Semantic Web Conference 2002, Sardinia
• Benjamin Grosof: Representing E-Business Rules for the Semantic Web: Situated Courteous Logic Programs in RuleML, Proc. Workshop on Information Technologies and Systems (WITS '01), New Orleans, December, 2001.
• Benjamin Grosof, Mahesh D. Gandhe, Timothy W. Finin: SweetJess: Translating DamlRuleML to Jess, Proc. International Workshop on Rule Markup Languages for Business Rules on the Semantic Web, Sardinia (Italy), June 2002.
• Benjamin Grosof and Terrence Poon: Representing Agent Contracts with Exceptions using XML Rules, Ontologies, and Process Descriptions, Proc. International Workshop on Rule Markup Languages for Business Rules on the Semantic Web, Sardinia (Italy), June 2002.
• Gerd Wagner: How to Design a General Rule Markup Language?, Invited Talk, Workshop XML Technologien für das Semantic Web (XSW 2002), Berlin, June 2002.

Group-Subgroups

• RuleML Group, Leads: Harold Boley & Said Tabet
• Reaction Rules Subgroup, Leads: Gerd Wagner & Steve Ross-Talbot
• Ontology Combination Subgroup, Leads: Benjamin Grosof & Andreas Eberhart
• Defeasible Rules Subgroup, Leads: Grigoris Antoniou & Michael Schroeder

Contacts

If you are interested to join the RuleML Initiative, please send a link describing your work related to rule markup to Harold Boley & Said Tabet; same for general RuleML questions/suggestions. Depending on your specific RuleML interests, you may also contact some RuleML Subgroup (select above) or some RuleML Participant (select above). If you like, you can also easily address all RuleML Participants (RuleML distribution list).

Site Contact: Harold Boley. Page Version: 2002-08-15


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