Skip to content.


Personal tools
You are here: Home » NewsLetter » Volume 1, Issue 1 » Semantic Web Technologies Column

RuleML, SWRL and REWERSE: Towards a General Web Rule Language Framework

Gerd Wagner Dept. Information & Technology, Eindhoven University of Technology, The Netherlands

Towards a General Web Rule Language Framework


Gerd Wagner

Dept. Information & Technology, Eindhoven University of Technology, The Netherlands


We report on three important research efforts that attempt to develop languages and techniques for specifying and processing rules for the Semantic Web: the Rule Markup Language (RuleML) Initiative, the Joint Committee’s Semantic Web Rule Language (SWRL) effort, and the European research project network REWERSE.


1  Introduction

Rules are considered to be a design issue for the Semantic Web (on top of the ontology layer in Tim Berners-Lee’s Semantic Web layer cake) and have been a topic of discussion in the W3C Web Ontology Working Group, but have not been included in the Web ontology language OWL. It is expected that there will be a W3C Working Group for developing a W3C rule markup language, possibly starting in 2004.

Rule markup languages, that allow to express business rules as modular, stand-alone units in a declarative way, and to publish them and interchange them between different systems and tools, will play an important role for facilitating business-to-customer (B2C) and business-to-business (B2B) interactions over the Web.

In a narrow sense, a rule markup language is a concrete (XML-based) rule syntax for the Web. In a broader sense, it should have an abstract syntax as a common basis for defining various concrete sublanguages serving different purposes.

Rules may be considered at three different abstraction levels:

1.      At the business domain level, rules are statements that express (certain parts of) a business/domain policy (e.g., defining terms of the domain language or defining/constraining domain operations) in a declar­ative manner, typically using a natural language or a visual language. Examples are:

(R1) “The driver of a rental car must be at least 25 years old”

(R2) “A gold customer is a customer with more than $1Million on deposit”

(R3) “An investment is exempt from tax on profit if the stocks have been bought more than a year ago”

(R4) “When a share price drops by more than 5% and the investment is exempt from tax on profit, then sell it”

R1 is an integrity rule, R2 and R3 are derivation rules, and R4 is a reaction rule (see below for explanations of these rule categories). These appear to be the major semantic categories of business rules. Actually, many business rules appear to be reaction rules, which specify policies for real-world business behavior.

2.      At the platform-independent level, rules are formal statements, expressed in some formalism or computational paradigm, which can be directly mapped to executable statements of a software platform. Rule languages used at this level are SQL:1999, OCL 2.0, and ISO Prolog. Remarkably, SQL provides operational constructs for all three business rule categories mentioned above: checks/assertions operationalize a notion of constraint rules, views operationalize a notion of derivation rules, and triggers operationalize a notion of reaction rules.

3.      At the platform-specific level, rules are statements in a specific executable language, such as Oracle 10g views, Jess 3.4, XSB 2.6 Prolog, or the Microsoft Outlook 6 Rule Wizard.

Generally, rules are self-contained knowledge units that involve some form of reasoning. They may, for instance, specify

-        static or dynamic integrity constraints (e.g. for constraining the state space or the execution histories of a system),

-        derivations (e.g. for defining derived concepts),

-        reactions (for specifying the reactive behavior of a system in response to events)

Given the linguistic richness and the complex dynamics of business domains, it should be clear that any specific mathematical account of rules, such as classical logic Horn clauses, must be viewed as a limited descriptive theory that captures just a certain fragment of the entire conceptual space of rules, and not as the only definitive, normative account. Therefore, in RuleML, a family of rule languages capturing the most important types of rules is being defined.

2  RuleML

The main categories of rules considered in RuleML [1,2] are derivation rules, integrity rules (constraints), reaction rules, production rules and transformation rules, as depicted in Figure 2. The concepts of derivation rules, integrity constraints, and reaction rules are considered to be meaningful both as (computation-independent) business rule categories and as (platform-independent) computational rule categories, whereas the concepts of production rules and transformation rules appear to be only meaningful as computational rule categories.

Notice that those categories whose name is in italics, such as DerivationRule, refer to an abstract concept of rule, while the others (with non-italicized names), such as “SQL:1999 View”, refer to rule concepts of concrete languages such as SQL:1999.  

Each part of a rule is an expression of some type, playing a specific role within the rule. The different parts of RuleML rules named by the roles they play, and their types, are listed in Table 1.

The main link between the different types of rules is the notion of a LogicalFormula or of a LogicalSentence, one of which being used in all of them. Traditionally, logical formulas are expressed in a language based on a predicate logic signature. However, OCL is the language of choice for expressing logical formulas referring to the state of a system whose structure is defined by a UML class model.


Table 2: RuleML rule expression components and their corresponding types.

Rule Expression Component

Type of Expression Component


Logical Sentence


Logical Formula


Logical Formula


Logical Formula

Transformation Invoker


Transformation Return


Triggering Event

Event Term

Triggered Action

Action Term

Produced Action

Action Term



Figure 2: Rule concepts and rule expressions at different levels of abstraction.


The rules R2 and R3 above are examples of derivation rules. Another example, where a derived attribute in a UML class model is defined by a derivation rule, is the following:

A car is available for rental if it is not assigned to any rental contract and does not require service.

This rule defines the derived Boolean-valued attribute isAvailable of the class RentalCar by means of an association isAssignedTo between cars and rental contracts and the stored Boolean-valued attribute requiresService, as shown in the UML class diagram in Figure 3, where the derivation rule is expressed as an implicational OCL invariant that states that for a specific rental car whenever there is no rental contract associated with it, and it does not require service, then it is be available for a new rental.


Figure 3: An OCL invariant defining the derived attribute isAvailable of the class RentalCar.


We now present the concrete XML syntax of this rule according to the simplified RuleML 0.85 syntax. The tag <naf> stands for negation-as-failure.





Recently, the Joint US/EU ad hoc Agent Markup Language Committee, which had developed the influential DAM+OIL web ontology language proposal, has proposed the Semantic Web Rule Language (SWRL) [3], whose syntax is based on a combination of OWL DL and the Datalog sublanguage of RuleML. The semantics of SWRL is a straightforward extension of the first-oder model-theoretic semantics of OWL DL. Since, like RDF and OWL, SWRL is based on classical 2-valued logic, it cannot deal with partial information and with closed predicates. Therefore, it cannot encode the rule for available rental cars shown in Figure 3. But it can encode property-chaining rules like the rule for hasUncle:


       <swrlx:individualPropertyAtom swrlx:property="hasFather">
       <swrlx:individualPropertyAtom swrlx:property="hasBrother">
       <swrlx:individualPropertyAtom swrlx:property="hasUncle">


The acronym “REWERSE” stands for “Reasoning on the Web with Rules and Semantics”. It is the name of a new research network funded by the EU Commission and Switzerland within the "6th Framework Programme" (FP6), Information Society Technologies (IST), see [4]. REWERSE aims at

-        developing a coherent and complete collection of inter-operable reasoning languages for advanced Web systems and applications;

-        testing these languages on context-adaptive Web systems and Web-based decision support systems selected as test-beds for proof-of-concept purposes;

-        bringing the proposed languages to the level of open pre-standards amenable to submissions to standardization bodies such as the W3C.


4  Workshops

In 2004, there will be three international workshops on reasoning and rules in the Semantic Web:

  • Business Rule Modelling and Markup for Intelligent Distributed 
    Applications, 9/10 August 2004, PRICAI 2004 Workshop 3, Auckland University of Technology, New Zealand (
  • The Second Workshop on Principles and Practice of Semantic  Web Reasoning (PPSWR 2004) at the 20th International Conference on Logic Programming (ICLP) supported by the REWERSE Network of Excellence and the CoLogNet Network of Excellence. 6-10 September 2004, St Malo, France (
  •  Rules and Rule Markup Languages for the Semantic Web
    (RuleML-2004), 8 November 2004, Hiroshima, Japan, in conjunction with the 3rd International Semantic Web Conference (ISWC2004),




[1]  Boley, H., Tabet, S., Wagner G.: Design Rationale of RuleML: A Markup Language for Semantic Web Rules. International Semantic Web Working Symposium (SWWS), June 2001, Stanford, USA.








Imprint      Privacy Disclaimer