-->

<--

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.

Steps Towards RuleML

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.

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


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