RuleML Initial Steps
2002-08-22: Version 1.0
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.
- Web research: What related work exists?
Preliminary results are collected in this page.
Who else should be involved?
For example, members of the
and related AI-language communities already
expressed their interest.
Feel free to contact us, send URLs, etc.
- 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.
- 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?
- 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>
<imp direction="bidirectional"> ... </imp>
for the specified use directions),
<_head> ... </_head>
<_body> ... </_body>
for the rule _head ('then'-part, conclusion, consequent)
and _body ('if'-part, premise, antecedent),
<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.
- 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>
<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>
<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".
- 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
Attributes could specify this and
of a rulebase besides giving it a name, version number, etc.
- Rule application: How should rules be called?
Will we need
<iterate> rulebase-to-be-iterated </iterate>
<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?
- 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?
- 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,
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 ...
- 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
Discussions of this and many more "RDF-logic" issues started with
RDF and Logic Programming.
There now is a typical example
and a DTD for RDF triples
- Ontology coupling: How are rules best coupled to (the taxonomy part of)
The SHOE language
appears to be the first to have achieved such a coupling on the Web.
Building on this,
may lead the way on how to achieve
such a coupling, starting from the ontology side of the dichotomy.
- 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.
- 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.
- XML stylesheets:
What (XSLT) stylesheets
should be used for external (browser)
presentations of rules
Which one should be the standard presentation, if any?
Should some preprocessing, with XSLT, transform certain restricted rule forms
into XSLT rules?
- Semiformal rules: How should natural-language rules be incorporated
into RuleML? Within
<_head> ... </_head> conclusions
<_body> ... </_body> premises,
we could, as illustrated, use XHTML's
paragraph tags with informal content as an alternative to
(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)
- Rule documents: On the level of entire XML documents,
how do we best mix rulebases with
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
as well as a suitable plug-in for a rule engine.
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)