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).
Rules have also continued to play an important role in
Intelligent Agents and
AI shells
for knowledge-based systems, which need a Web interchange format, too.
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 a preliminary RuleML design
and a preliminary Version 0.8 system of DTDs
for some RuleML sublanguages.
On the first day of W3C's
Technical Plenary and WG Meeting Event, 26 February - 2 March 2001,
RuleML participants organized a Birds Of a Feather session, using
this presentation material;
in addition, at the
RDF Interest Group: Face to face meeting 26/27 Feb 2001
we presented
RDF Relationships and DTD Modularization.
Further activities are planned in conjunction with
IJCAI-01,
in August 2001, in Seattle, Washington,
and with the third
International Conference on Electronic Commmerce,
ICEC2001, in Vienna, Austria,
in October/November 2001.
There will be an Invited Talk on RuleML at the
14th International Conference of Applications of Prolog,
INAP2001,
in Tokyo, Japan, in October 2001.
Sections
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 goal 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.
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.)
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:
- Mathematical Markup Language
(MathML):
However, MathML's Content Markup is better suited for defining functions
rather than relations or rules
- DARPA Agent Markup Language (DAML):
While the contributing
SHOE project
has permitted Horn rules and a DAML-RULES is planned, the current
DAML-ONT
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
Besides on the related work, the RuleML Initiative is based on
the following proposals of the participants listed in parentheses:
- Agent Frameworks
(Leon Sterling,
Department of Computer Science and Software Engineering, University of Melbourne, Australia)
- AORML
(Gerd Wagner,
Faculty of Technology Management, I & T, Eindhoven University of Technology, The Netherlands)
- CommonRules
(Hoi Chan,
IBM T.J. Watson Research, USA)
- BRML/DAML-RULES
(Benjamin Grosof,
MIT Sloan School of Management, USA)
- Euler
(Jos De Roo,
AGFA, Belgium)
- FLIP
(Jose Hernandez-Orallo,
DSIC, Politechnical University of Valencia, Spain)
- Jess
(Ernest Friedman-Hill,
Distributed Systems Research, Sandia National Labs, USA)
- KNOW: Knowledge Norm Of Webmind
(Pei Wang,
Webmind Inc., USA)
- Mandarax
(Jens Dietrich,
Department of Computer Science, Polytechnic of Namibia, Namibia)
- PDDL: Planning Domain Definition Language
(Drew V. McDermott,
Department of Computer Science, Yale University, USA)
- Protege-2000
(Mark Musen,
Stanford Medical Informatics, USA)
- RBML: Rule Base Markup Language
(Chris Roberts,
Sun Microsystems, USA)
- RFML
(Harold Boley,
DFKI, Germany)
- SeCo
(Beat Schmid,
Institute for Media and Communications Management,
University of St. Gallen, Switzerland)
- Triple
(Stefan Decker,
Stanford InfoLab,
LastMile Services;
Michael Sintek,
DFKI,
Stanford Medical Informatics;
Germany, USA)
- URML
(David Ash,
Real Time Agents Inc.;
Prabhakar Bhogaraju,
MindBox;
Said Tabet,
Nisus;
USA)
- XRML
(Jae Kyu Lee,
ICEC,
KAIST, Korea)
|
|
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
CLIPS/Jess
(forward rules),
Prolog
(backward rules),
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 original tentative RuleML kernel comprised the tags
<rule> ... </rule> for rules with
unspecified use direction
(possibly employing the 'attributed'
<rule dir="forward"> ... </rule>
and
<rule dir="backward"> ... </rule>
for the two specified use directions),
<conc> ... </conc>
and
<prem> ... </prem>
for a rule conclusion ('then'-part, action, consequent)
and premise ('if'-part, condition, antecedent),
and
<var> ... </var>
for rule variables.
Besides the top-level rule elements of
conclusions and premises,
further ones may be needed such as trigger conditions
for forward rules and
exception (unless) conditions
for non-monotonic logics.
However, there now exists a preliminary RuleML design
and a preliminary system of DTDs
for some RuleML sublanguages.
- Rule syntaxes: Rules with 1 conclusion and
N conjunctive premises could be written equivalently as
<rule> prem1 ... premN conc </rule>
or as
<rule> conc prem1 ... premN </rule>.
Should we also allow rules with M>1 conclusions, interpreted
conjunctively as in forward rules (rather than the disjunctive interpretation
in Gentzen sequents, whose effect could be obtained by an explicit or
as the single conclusion)? They could be written equivalently as
<rule> prem1 ... premN conc1 ... concM </rule>
or as
<rule> conc1 ... concM prem1 ... premN </rule>.
Here is an (XHTML-p-containing, semiformal) example
with M=N=1, in the
first of the two equivalent syntaxes:
<rule> <prem> <p>You want to review rule principles</p> </prem>
<conc> <p>You may look at
<a href="http://www.cs.brandeis.edu/~cs35a/notes/rules/index.htm">Rule-Based Systems</a></p> </conc> </rule>.
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
rules.
Attributes could specify this and
additional properties
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>
and
<goal> query-to-be-proved </goal>
'statements' for forward and backward rules?
Or should, e.g., goal be identified with prem?
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,
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 ...
- 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
<rule> conc prem1 ... premN </rule>
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 preliminary example
(creator.ruleml,
creator.ruleml.txt)
and DTD for RDF triples
(ruleml-urcbindatagroundfact.dtd,
ruleml-urcbindatagroundfact.dtd.txt).
- 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.
- 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
(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?
- Semiformal rules: How should natural-language rules be incorporated
into RuleML? Within
<conc> ... </conc> conclusions
and
<prem> ... </prem> 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?
- 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,
from reaction rules (event-condition-action rules),
via integrity-constraint rules (consistency-maintenance rules) and
derivation rules (implicational-inference rules),
to facts (premiseless derivation rules).
Till now, we have been mostly working on derivation rules and facts
(cf. current DTDs).
The RuleML hierarchy of rules constitues a partial order rooted in
reaction rules. Its second main layer consists of, next to each other,
integrity-constraint rules and derivation rules.
The third layer just specializes derivation rules to facts.
Thus, the global RuleML picture looks as follows:
reaction rules
/ \
1. / \ 2.
/ \
integrity constraints derivation rules
|
3. |
|
facts |
Let us discuss the hierarchy's numbered specialization 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.)
- Integrity constraints are considered as "denials" or
special reaction rules
whose only possible kind of action is to signal inconsistency when
certain conditions are fulfilled.
- Derivation rules are considered as special reaction rules
whose action happens to only add or 'assert' a conclusion
when certain conditions (premises) are 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.
- Facts are considered as special derivation rules that
happen to have an empty (hence, 'true') conjunction of premises.
We can now make more precise our views regarding the application direction
for the four rule categories:
- General 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.
- Integrity constraints are usually also forward-oriented, i.e.
triggered by updates, mainly for efficiency reasons.
- Derivation rules, on the other hand, can be applied in
the forward direction as well as in a 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' it makes little sense to talk of
an application direction.
While reaction 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.
The following markup syntax only serves for our preliminary distinction
of the four categories (for instance, we plan to permit and/or nestings besides flat conjunctions as premises):
- Reaction rules:
<rule> <and> prem1 ... premN </and> action </rule>
- Integrity constraints:
<ic> <and> prem1 ... premN </and> </ic>
implemented by
<rule> <and> prem1 ... premN </and> <signal> inconsistency </signal> </rule>
- Derivation rules:
<if> conc <and> prem1 ... premN </and> </if>
implemented by
<rule> <and> prem1 ... premN </and> <assert> conc </assert> </rule>
- Facts:
<fact> conc </fact>
implemented by
<if> conc <and> </and> </if>
2001-01-31: A preliminary RuleML DTD has been released:
RuleML DTD Version 0.7.
2001-06-26: A revised version has been (PRE-)released:
RuleML DTD Version 0.8.
The discounting business rules example shows some of the envisaged features:
discount.ruleml
(discount.ruleml.txt).
An experimental RDF translator for a subset of RuleML 0.7 is available in XSLT:
RuleML in RDF Version 0.2.
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.
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
has 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 but intriguing
piece of code that can 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 rdf2java)
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.
If you are interested to join the RuleML Initiative,
please send a link describing your
work related to rule markup to
Harold Boley
and Said Tabet.
Depending on your RuleML suggestions, you may contact some
(select above)
or all
(RuleML distribution)
of the current participants.
Site Contact:
Harold Boley.
Page Version: 2001-06-21
"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)
