R u l e M L


Rule Markup Language

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 goal of the Rule Markup Initiative is to develop RuleML as the canonical Web language for rules using XML markup, formal semantics, and efficient implementations.

RuleML covers the entire rule spectrum, from derivation rules to transformation rules to reaction rules. RuleML can thus specify queries and inferences in Web ontologies, mappings between Web ontologies, and dynamic Web behaviors of workflows, services, and agents.


Rather than focusing on academic research prototypes, RuleML is about rule interoperation between industry standards (such as JSR 94, SQL'99, OCL, BPMI, WSFL, XLang, XQuery, RQL, OWL, DAML-S, and ISO Prolog) as well as established systems (CLIPS, Jess, ILOG JRules, Blaze Advisor, Versata, MQWorkFlow, BizTalk, Savvion, etc.).

The Initiative develops a modular RuleML specification and transformations from and to other rule standards/systems. Moreover, it coordinates the development of tools to elicit, maintain, and execute RuleML rules. It also collects use cases, e.g. on business rules and reactive services.

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.


If you want to review rule principles, (then) you may look at Rule-Based Expert Systems. (BTW, this is itself a simple rule.) If you want to review XML principles, you may go to the beginning of Knowledge Markup Techniques.

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

Rather than reinventing rule principles and markups in each such community, the idea of RuleML is to 'package' the rule aspect of these domains and and make it available as an (XML) namespace, .../RuleML, which can be mixed with a namespace for natural-language (XHTML) texts and possible domain-specific namespaces (much like MathML is mixed into such domain texts).


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:

Participants (Updated: 2002-08-06)

Besides on the related work, the RuleML Initiative is based on the following proposals of the participants listed in parentheses:
  1. Agent Frameworks (Leon Sterling, Department of Computer Science and Software Engineering, University of Melbourne, Australia)
  2. AMIT/ADI (Asaf Adi, Ziva Sommer, IBM Research Lab in Haifa, Israel)
  3. AORML (Gerd Wagner, Faculty of Technology Management, I & T, Eindhoven University of Technology, The Netherlands)
  4. BotForm&trade (Sven Seelig, Sonja Muller Landmann, Smart Bot Technologies, Germany)
  5. BRML/DAML-RULES (Benjamin Grosof, MIT Sloan School of Management, USA)
  6. CommonRules (Hoi Chan, IBM T.J. Watson Research, USA)
  7. Deimos&Phobos (Grigoris Antoniou, Fachbereich Mathematik & Informatik, Universität Bremen, Germany)
  8. EAI Rules engine (Ruth Whalen, Darren D'Amato, Sybase, Inc., New Era Of Networks, Inc., USA)
  9. Euler (Jos De Roo, AGFA, Belgium)
  10. FLIP (Jose Hernandez-Orallo, DSIC, Politechnical University of Valencia, Spain)
  11. j-DREW (Bruce Spencer, Faculty of Computer Science, University of New Brunswick and Institute for Information Technology, National Research Council of Canada, Canada)
  12. Jess (Ernest Friedman-Hill, Distributed Systems Research, Sandia National Labs, USA)
  13. KNOW: Knowledge Norm Of Webmind (Pei Wang, Webmind Inc., USA)
  14. LispMiner (Vojtech Svatek, Jan Rauch, Vaclav Lin, Knowledge Engineering Group, Department of Information and Knowledge Engineering (DIKE), University of Economics, Prague, Czech Republic)
  15. Mandarax (Jens Dietrich, Department of Computer Science, Polytechnic of Namibia, Namibia)
  16. OCML (Enrico Motta, John Domingue, Knowledge Media Institute, The Open University, UK)
  17. OntoJava (Andreas Eberhart, International University in Germany, Germany)
  18. PDDL: Planning Domain Definition Language (Drew V. McDermott, Department of Computer Science, Yale University, USA)
  19. Protégé-2000 (Mark Musen, Stanford Medical Informatics, USA)
  20. RBML: Rule Base Markup Language (Chris Roberts, Sun Microsystems, USA)
  21. RFML (Harold Boley, DFKI, Germany)
  22. RIF (Steve Ross-Talbot, Enigmatec Corporation, UK)
  23. SeCo (Beat Schmid, Institute for Media and Communications Management, University of St. Gallen, Switzerland)
  24. Semantic Matchmaker (Katia Sycara, Massimo Paolucci, The Intelligent Software Agents Lab, The Robotics Institute, School of Computer Science, Carnegie Mellon University, USA)
  25. TRIPLE (Stefan Decker, USC ISI Intelligent Systems Division, LastMile Services; Michael Sintek, DFKI, USC ISI Intelligent Systems Division; Germany, USA)
  26. Type-Based Diagnoser (Jan Maluszynski, Swedish Semantic Web Initiative, Department of Computer and Information Science, Linköping University, Sweden)
  27. URML (David Ash, Real Time Agents Inc.; Prabhakar Bhogaraju, MindBox; Said Tabet, The Rule Markup Initiative; USA)
  28. Versata Logic Suite for Transaction Logic (James Liddle, Kamran Yousaf, Versata; UK)
  29. Vivid Agents/Revise (Michael Schroeder, The School of Informatics, City University London, UK)
  30. Xcerpt (François Bry, Sebastian Schaffert, Teaching and Research Unit Programming and Modelling Language, Institute of Computer Science, Ludwig-Maximilians-Universität München, Germany)
  31. X-DEVICE (Nick Bassiliades, Logic Programming and Intelligent Systems (LPIS) Group, Dept. of Informatics, Aristotle University of Thessaloniki, Greece)
  32. XET/XDD (Vilas Wuwongse, Chutiporn Anutariya, Knowledge Representation Laboratory, Asian Institute of Technology, Thailand)
  33. XRML (Jae Kyu Lee, ICEC, KAIST, Korea)

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


Some initial steps taken by the RuleML Initiative have been to structure the area of rule markup, to raise issues and identify tasks, and to propose tentative rule tags/attributes:
  1. Web research: What related work exists? Preliminary results are collected in this page. Who else should be involved? For example, members of the CLIPS/Jess (forward rules), Prolog (backward rules), and related AI-language communities already expressed their interest. Feel free to contact us, send URLs, etc.
  2. Proposal comparison: Which ones cover what kinds of rules? Where are overlaps between the proposals? The result should be a 'family tree' of rule markup languages, preparing rule translations, language revisions, etc. For exemplary tag comparisons by alignment see sections 3 and 4 of Markup Languages for Functional-Logic Programming.
  3. DTD translation: Can (revised) proposals of participants' rule languages (often described by DTDs) be (XSLT-)translated into each other? In which cases will only partial translations be possible?
  4. Markup harmonization: If different XML tag or attribute names have been used for the same rule parts, which names should be chosen in RuleML? The current tentative RuleML kernel comprised the tags <imp> ... </imp> for derivation rules with unspecified use direction (possibly employing the 'attributed' <imp direction="forward"> ... </imp>, <imp direction="backward"> ... </imp> and <imp direction="bidirectional"> ... </imp> for the specified use directions), <_head> ... </_head> and <_body> ... </_body> for the rule _head ('then'-part, conclusion, consequent) and _body ('if'-part, premise, antecedent), and <var> ... </var> for rule variables. Besides the top-level rule elements _head and _body, further ones may be needed such as _trigger conditions for forward rules and _exception (unless) conditions for non-monotonic logics. There now exists an initial RuleML design and a Version 0.8 system of DTDs for basic RuleML sublanguages.
  5. Rule syntaxes: Rules with 1 conclusion and N conjoined premises could be written equivalently as <imp> <_body> <and> prem1 ... premN </and> </_body> <_head> conc </_head> </imp> or as <imp> <_head> conc </_head> <_body> <and> prem1 ... premN </and> </_body> </imp>. Should we also allow rules with M>1 conjoined conclusions, <and> conc1 ... concM </and>, as for forward rules (rather than the disjoined <or> conc1 ... concM </or> for Gentzen sequents)? They could be written equivalently as <imp> <_body> <and> prem1 ... premN </and> </_body> <_head> <and> conc1 ... concM </and> </_head> </imp> or as <imp> <_head> <and> conc1 ... concM </and> </_head> <_body> <and> prem1 ... premN </and> </_body> </imp>. Here is an (XHTML-p-containing, semiformal) example with M=N=1, in the first of the two equivalent syntaxes: <imp> <_body> <p>You want to review rule principles</p> </_body> <_head> <p>You may look at <a href="http://www.cs.nott.ac.uk/~sxp/ES3/index.htm">Rule-Based Expert Systems</a></p> </_head> </imp>. Once in this semiformal markup, the example could be refined into more and more formal markups, up to a rule in some "logic of recommendation".
  6. Rule modules: A rule module, set, package, or base can be enclosed by explicit tags such as <rulebase> ... </rulebase>. Its elements would constitute an ordered or unordered set of rules. Attributes could specify this and additional properties of a rulebase besides giving it a name, version number, etc.
  7. Rule application: How should rules be called? Will we need <iterate> rulebase-to-be-iterated </iterate> and <goal> query-to-be-proved </goal> 'statements' for forward and backward rules? Or should, e.g., goal be identified with _body? Besides such deduction rules, will certain rules also be called implicitly for checking integrity constraints?
  8. Rule expressiveness: What should be supported in the classical logic spectrum of propositional, Horn, negated-premise, implicational-premise, full-first-order, and higher-order rules? Should also non-classical logics with non-monotonicity (e.g., negation as failure) or rule prioritizing (e.g., Prolog-like cuts or control/meta rules) be supported? Alternatively, can we develop a new logic for the Web, which is open, uncertain, and paraconsistent? Besides such (extended) logic rules, what kinds of transformation rules should be supported? A deductive-transformational bridge could be directed conditional equations as discussed in the Curry Mailing List. Besides the easier derivation or state-preserving ('read-only') rules, what should be supported in the spectrum of reaction rules, from state-changing ('write-enabled') rules that assert and retract instances/facts or rules, to planning rules that generate action sequences effecting changes in some (modeled or real) environment, to reactive rules that are directly coupled to (softbot/robot) effectors operating on the (virtual/physical) world?
  9. Rule semantics: Should we try to fix some (declarative) rule semantics? Should we incorporate, on the rulebase level, (operational) semantics attributes such as for conflict resolution (textual vs. specificity order, "don't care" vs. "don't know" non-determinism) or search strategies (backtracking, iterative deepening, best-first search), or should we leave most of these issues to the receivers of rulebases? For a related discussion of deductive-transformational systems see section 7 of Markup Languages ...
  10. RDF rules: Should we try to avoid rule markup/inferencing to diverge into Resource Description Framework applications and other XML applications? E.g., should a sequential conjunction of N>1 premises of a rule <imp> <_head> conc </_head> <_body> <and> prem1 ... premN </and> </_body> </imp> be represented with binary relations via RDF's Sequence container? Discussions of this and many more "RDF-logic" issues started with RDF and Logic Programming. There now is a typical example (creator.ruleml, creator.ruleml.txt) and a DTD for RDF triples (ruleml-urcbindatagroundfact.dtd, ruleml-urcbindatagroundfact.dtd.txt).
  11. Ontology coupling: How are rules best coupled to (the taxonomy part of) an ontology? The SHOE language appears to be the first to have achieved such a coupling on the Web. Building on this, DAML and OIL may lead the way on how to achieve such a coupling, starting from the ontology side of the dichotomy.
  12. Rule validation: Which XML tools can we use for rule validation? Conversely, which static-analysis tools for the validation and verification of rules could be of interest to the XML community at large? One candidate may be cross-referencing/call-graph programs. This can be seen as complementing rule induction and the markup of its results, as supported by PMML's association rules.
  13. Rule compilation: Should we classify rules according to the compilation targets that can be used for executing them more efficiently, e.g. Rete networks, decisions trees, WAM code, etc.? We could employ markup languages also for these intermediate and low-level rule representations.
  14. XML stylesheets: What (XSLT) stylesheets should be used for external (browser) presentations of rules (cf. RFML's stylesheet)? Which one should be the standard presentation, if any? Should some preprocessing, with XSLT, transform certain restricted rule forms into XSLT rules?
  15. Semiformal rules: How should natural-language rules be incorporated into RuleML? Within <_head> ... </_head> conclusions and <_body> ... </_body> premises, we could, as illustrated, use XHTML's paragraph tags with informal content as an alternative to formal-language tags (the RuleML DTD/Schema would have to accommodate this via something like "p | formala"). Should we allow informal-formal mixtures not only within rulebases but also within individual rules (say, one premise is still expressed in English, while all other rule parts are formalized in Horn logic)? How can we use XML's (natural) language encodings for the natural languages used in semiformal rules, or even in (relation, constant, variable names of) formal rules?
  16. Rule documents: On the level of entire XML documents, how do we best mix rulebases with (XHTML) texts? How can rulebases be made '(inter)active' in such mixed documents, with users running the rules while reading the accompanying texts? This would involve declaring both RuleML and XHTML namespaces as well as a suitable plug-in for a rule engine.


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:

                    /     \
                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:


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


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


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.


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.


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:

                         + <var>F</var>.name, false);
This example loads RDF info into the DB, which comes from a kind of Web Service. So emails can be sent as well, etc. While this is not 'cross-platform', it should be interessting from an engineering point of view.

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.


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.




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)

Powered by Cocoon