=Paper=
{{Paper
|id=None
|storemode=property
|title=Critical evaluation of the XTT2 rule representation through comparison with CLIPS
|pdfUrl=https://ceur-ws.org/Vol-949/kese8-07_09.pdf
|volume=Vol-949
|dblpUrl=https://dblp.org/rec/conf/ecai/KaczorN12
}}
==Critical evaluation of the XTT2 rule representation through comparison with CLIPS==
https://ceur-ws.org/Vol-949/kese8-07_09.pdf
Critical evaluation of the XTT2 rule representation
through comparison with CLIPS1
Krzysztof Kaczor and Grzegorz J. Nalepa2
Abstract. There are two main approaches to the design Business • speed up the design process – formalized rule language opens pos-
Rules. The first one involves formalized methods that strictly define sibility to partially formalize the design process which can, in turn,
the syntax and semantics of rules. This approach usually requires lead to better detection of design errors, possibly at early develop-
technical skills or conceptual knowledge and therefore is not appro- ment stages,
priate for everyone. In the second approach, dedicated rule languages • allow for a superior knowledge base quality control – formal
are used for facilitating rules specification. Nevertheless, such lan- methods can be used to identify logical errors in rule formulation,
guages are usually programming solutions without a precisely de- • simplify knowledge interoperability – partially formalized trans-
fined semantics. This may cause ambiguities in knowledge interpre- lation to other knowledge representation formats are possible, and
tation and thus, the efficient rule interoperability becomes impossi- • allow for custom inference modes – structured rule bases require
ble. The goal of our work is to develop a formalized model for a inference strategies alternative to the classic inference algorithms.
rule representation which will allow for an effective rule interchang-
ing. For this purpose, we want to combine the above mentioned ap- This paper is organized as follows: Section 2 gives a short mo-
proaches by tailoring the formalized rule representation called XTT2 tivation for our work. A short introduction to the XTT2 method is
to languages provided by CLIPS or Drools. This paper is the first provided by Section 3. Section 4 is the main part of this paper dis-
step in our research providing an identification of the most important cussing the most important differences between XTT2 and CLIPS.
differences between the XTT2 and CLIPS rule languages. The paper is concluded with Section 5 providing short summary and
information concerning future works.
1 Introduction
Rule-Based Systems constitute a mature technology in the field of 2 Motivation
Artificial Intelligence. Over the years, they were applied in many do- Together with the development of BR design methods, a number
mains like medicine, engineering [7] or decision support [10]. De- of development tools also increases. Among them very important
spite their maturity, many ideas, algorithms and solutions that are are Drools [4] and OpenRules3 . Sometimes, it is desirable to have
applied in new technologies, such as Business Rules (BR) [22], Se- a mechanism for exchanging knowledge between different tools.
mantic Web [2] or Complex Event Processing [12], are derived from This makes maintenance of the rule bases easier and allows for more
the classic Rule-Based Systems [9]. efficient usage of these tools. Nevertheless, the existing tools usually
Business Rules are one of the latest application of classic rules. allow for BR modeling in an informal way and do not provide any
They are intended to be created by business people in order to define common rule representation model. This provides ambiguity in the
logical aspects of business. Despite the fact that business people may rule semantics and in turn, does not allow for efficient interchanging.
not have any technical skills or scientific knowledge, BR must be A problem of knowledge interoperability is known since classic
appropriate to be used by such users. Currently, many techniques are rule-based expert systems and still remains an open issue. During
used for the specification of BR, from description in natural language the years, several approaches to this problem were proposed. The
to design by using formalized methods. There is no single method most important of them are: Knowledge Interchange Format4 , Rule
that is considered to be the best. Usually, a designer chooses one Markup Language [3], Rule Interchange Format [8] and REWERSE
according to his or her own preferences. Rule Markup Language [23]. Nevertheless, the above mentioned
Rules specification in natural language is very intuitive and does methods provide a very general model of rule-based knowledge rep-
not require any specialized skills. Moreover, such a method allows resentation, what makes their practical application hard or even im-
for an easy specification of very complex rules. However, such in- possible. Hence, practical tools supporting any of these methods do
formal description may be very vague, especially in case of complex not exist or provide only partial support.
rules which may be hard to understand or in the worst case may be The main objective of our current research is to develop a for-
misunderstood. This type of problems can be prevented by using for- malized method for an efficient rule interoperability. We assume that
malized methods having the following advantages: this can be done by providing a common and logic-based rule rep-
• they provide a clear framework enabling uniform knowledge mod- resentation model. Thanks to such a model, the semantics of rules,
eling with well-defined expressive power, specified in other representations, can be clarified or defined. What
1 The paper is supported by the AGH UST Grant. 3 See: http://openrules.com
2 AGH University of Science and Technology, Poland, email: 4 See: http://www.upv.es/sma/teoria/sma/kqml_kif/kif.
kk,gjn@agh.edu.pl pdf
is more, this model will allow to specify which representation can • Rule Syntax — defines how the knowledge can be expressed and
be losslessly translated to another and how this translation should be what are the limitations of a provided rule language i.e. this issue
performed. We assume that the model will be based on the formal- concerns rule language syntax as well as its expressiveness.
ized rule representation method called XTT2 [19] which is provided • Rule Semantics — defines the semantics of the rules and how they
by the Semantic Knowledge Engineering (SKE) methodology [16]. should be interpreted.
The XTT2 method (see Section 3) is a visual method for model- • Rule Processing — is related to inference mechanism as well as
ing structured rule bases. This method is intended to be a rigorously the way how the knowledge processing is performed.
formalized rule language. Nevertheless, a rigorous formalization has
restricted the expressiveness of the language. Thus, in comparison This section is divided into four subsections describing XTT2 in
with other methods, XTT2 has several limitations and significant dif- terms of above mentioned aspects.
ferences. This is why our current work is focused on the extension of
XTT2 towards such languages as CLIPS5 [6] or Drools. These two 3.1 Rule Base
languages have been selected as the reference because they proved to
An XTT2-based rule base contains attributes that store values. Each
be successful implementations of rule-based systems.
attribute-value pair can be considered as a single fact. The set of all
CLIPS is a classic rule-based expert system shell developed by
pairs is called system state and is defined as follows:
NASA in 1984. The original intent for CLIPS was to gain use-
ful insight and knowledge about the construction of expert system s : (A1 = S1 ) ∧ (A2 = S2 ) ∧ . . . ∧ (An = Sn ) (1)
tools and to lay the groundwork for the construction of a replace-
ment tool for the commercial tools being used in that time. Because where Ai are the attributes and Si are their current values.
of its portability, extensibility, capabilities, and low cost, it has re- It is important to notice, that the number of attributes (facts) is con-
ceived widespread acceptance throughout the government, industry, stant during the inference process. The knowledge base modification
and academia. Development of this tool has improved the accessi- can be made only by changing attribute value.
bility to expert system technology throughout the public and private XTT2 provides modularized rule base, where rules working to-
sectors for a wide range of applications and diverse computing en- gether are placed in one context. Contrary to the majority of other
vironments. CLIPS became one of the most commonly known rule systems, where a basic knowledge item is a single rule, in the XTT2
language that was used for e.g. image processing or recognition. formalism the basic component displayed, edited and managed at a
As a classic rule-based tool, CLIPS became a reference tool also time is a single context. A single context corresponds to a single de-
for other tools like Jess which is a rule engine and scripting environ- cision table. Thus, only those rules which have the same conditional
ment providing rule language. It is written in Java. Jess was origi- and decisions attributes can be placed in one context i.e. each rule in
nally a clone of the essential core of CLIPS, but has begun to acquire a decision table determines values of the same set of attributes.
a Java-influenced flavor. Therefore, it is a convenient tool for giving XTT2 is a hybrid knowledge representation combining a decision
Java applets and applications the ability to reason. network and decision tables. Tables are linked together forming a
Drools is a much younger project which was started in 2001. Cur- network-like structure of the XTT2 decision tables. Links define or-
rently Drools is widely used by Business environment as Business der in which tables should be processed. Considering a single table
Logic Integration Platform providing a unified and integrated plat- as a blackbox for determining attribute value, the links corresponds
form for Rules, Workflow and Event Processing. Drools-based rules to functional dependencies between attributes.
are specified using dedicated rule language and processed by dedi-
cated rule engine called Drools Expert. Similarly to Jess, this engine 3.2 Rule Syntax
is also written in Java and allows for easy integration with other ap-
plications written in this language. The XTT2 rule language provide a dedicated syntax called HeKatE
The above mentioned tools are not intended to provide a formal- Meta Representation (HMR). This is a textual representation that can
ized rule representation that is necessary for efficient rule interchange be easily read by human and automatically processed by an inference
preserving their semantics. The provide only programming solutions engine. Moreover, the HMR language is suitable for visual represen-
for rapid development of the rule bases. In our work, we try to com- tation (see Figure 1). Thanks to this, such a knowledge representa-
bine the advantages of formalized methods and programming so- tion provides not only high density of knowledge visualization, but
lutions. This paper describes the first step of this work. The main assures transparency and readability. Additionally, the visual repre-
contribution is the comparison of the XTT2 method with the CLIPS sentation is fully supported by the HQEd [20] graphical editor. Using
language, by identifying the differences and limitations of XTT2 in this editor, a HMR-based representation can be automatically gen-
terms of CLIPS. It describes the most important aspects of extending erated for a given visual model. Then, the HMR representation is
XTT2 towards CLIPS and challenges that must be overcome for an processed by the HeaRT [15] tool which is the dedicated inference
efficient rule interoperability between these two representations. engine for reasoning with the XTT2 rule bases [1].
For study purposes, an example below presents the same rule
in three representations: natural language, HMR representation and
3 Overview of XTT2 XTT2-based visual representation. The rule comes from Cashpoint
This section gives a short introduction to XTT2 (eXtended Tabular case study [5] and is as follows:
Trees) [17, 18]. XTT2 can be considered a multidimensional concept. if
It involves many aspects of the rule-based systems design: driver is younger than 25 years
and
• Rule Base — this aspect involves issues related to structure and
it has driving licence at least three years
maintenance of a rule base.
then
5 See: http://clipsrules.sourceforge.net
increase the driver current discount by 50%
Figure 1. An example of visual representation of XTT2 rule base
3.4 Rule Processing
XTT2 provides a dedicated rule processing mechanism. This is an
advanced inference algorithm that can work in one of four modes:
Figure 2. An example of visual representation of XTT2 rule Fixed Order, Data, Token and Goal Driven (for more details see [13]).
The inference mechanism is responsible for evaluating and executing
(firing) rules. The rules are processed in predetermined order which
This rule can be easily expressed with HMR syntax:
is specified by taking the following issues into account: inference
xrule ’Table1/1’: mode, links between modules, order of the rules in the XTT2 table.
[driverAge lt 25,
drLicAge gte 3] 4 Challenges in the Rule Interoperability between
==> XTT2 and CLIPS
[driverDiscount set (driverDiscount+50)]
The goal of our work is to develop a common unified rule repre-
sentation model for efficient rule interoperability between different
The figure 2 depicts the equivalent visual representation of the pro-
rules representations. Our starting point is formalization of the XTT2
vided HMR syntax.
method which provides the underlying ALSV(FD) logic. Neverthe-
less, the current form of the method does not use the ALSV(FD) logic
effectively (lack of support for complex types) and has several lim-
3.3 Rule Semantics itations. In comparison to CLIPS, this language constitutes a subset
of CLIPS. In this context, the knowledge interchange between XTT2
XTT2 is based on the Attributive Logic with Set of Values over Finite
and CLIPS requires many improvements and changes that must be
Domains (ALSV(FD)) logic [11, 18]. ALSV(FD) is a formal frame-
done in XTT2 in order to provide a better coverage of CLIPS. Some
work for attributive logic that provides syntax, semantics and some
of the limitations stem from the made assumptions and others stem
notes on inference rules for a logical calculus in which attributes
from the visual representation. This section provides a detailed de-
can take set values (generalized attributes). In comparison with other
scription of the most important challenges in the context of extending
attributive logics, its expressive power is increased through the in-
XTT2 and efficient rule interoperability with CLIPS. The section is
troduction of new relational symbols enabling definitions of atomic
divided into subsections according to aspects introduced in Section 3.
formulae. This logic provides very strict and rigorous definition of
rule semantics allowing for knowledge definition which can be un-
ambiguously interpreted. 4.1 Rule Base
A single rule in ALSV(FD) is defined as a set of ALSV(FD) Rule base modification CLIPS provides a mechanism allowing
triples. The exemplary rule from Section 3.2 can be expressed in for modifying a Knowledge Base (KB) by asserting, retracting and
ALSV(FD) in the following way: modifying facts. This can be done using the following commands:
assert, retract and modify. Thanks to this, when the system
r1 : (driverAge, <, 25) ∧ (drLicAge, >=, 3) → is running, the number of facts in the KB can be changed. In contrast
→ (driverDiscount, :=, driverDiscount + 50) to CLIPS, the XTT2-based knowledge base defines a system with a
constant number of facts described by attributes. During the execu-
The complete formalization of XTT2 can be found in [19]. tion, attributes are neither created nor removed from the knowledge
base. Only the current value of the attribute can be changed. Never- that provides its own structure and aggregates a fixed set of labelled
theless, the process of asserting and retracting facts in XTT2 can be fields, possibly of different types, into a single type. An example of
achieved using generalized attributes (see paragraph Multivalued at- such type is a structure that is known from C programming language.
tributes in Section 4.2). The ALSV(FD) logic provides support for complex types and objects
throughout attribute function which denotes a property of an object
Modularization of Knowledge Base Both, XTT2 or CLIPS pro- and allows for accessing its value using property name. However,
vide mechanism for creating modularized knowledge base. In XTT2, currently XTT2 uses only atomic types for defining all attributes in
set of rules that work together are grouped into so called contexts. the knowledge base and assumes that only one object (in this case
Each context corresponds to a single XTT2 table and contains rules it is the system being described) with a specific property name ex-
which have the same attributes in their conditional and conclusion ists. In turn, CLIPS provides deftemplate element that allows
parts. In turn, CLIPS provide modules which can be defined using for defining complex facts consisting of number of typed properties
defmodule construct. In contrast to XTT2, CLIPS modules do not (called slots in CLIPS-based vocabulary):
provide any policy determining which construct can be placed in
a module. In particular any rule (or other construct) can be placed in (deftemplate person
any module. In fact, this is also possible in XTT2 and can be achieved (slot name (type SYMBOL))
by extending rules LHS and RHS by all attributes that appears in the (slot surname (type SYMBOL))
other rules in this context. However, this can lead to formation of (slot gender (type SYMBOL))
large tables in which majority of cells contain always true compar- (slot height (type INTEGER))
isons (an example of such table is depicted in Figure 3). (slot age (type INTEGER))
CLIPS modules allow a set of constructs to be grouped together )
such that explicit control can be maintained over restricting the ac-
cess of the constructs by other modules. This type of control is sim- This example defines a template of person which allows for creating
ilar to global and local scoping used in languages such as C. The complex facts consisting of five typed properties: name, surname,
default behavior in CLIPS restricts constructs in one module to be gender, height and age.
accessible in another. However, this can be modified and selected el-
ements can be permitted to be visible from other modules. In turn, the Multivalued attributes ALSV(FD) provides a generalized at-
XTT2 rules placed in one context are not accessible from another. tribute that can take more than one value at any point of time. This is
In both CLIPS or XTT2, modules are used by rules to provide exe- very important and useful feature of ALSV(FD), however it is hard
cution control. In CLIPS, each module has its own pattern-matching to assess to which element of the CLIPS language it corresponds.
network [13], and thus only rules from the active module can be ac- There are two obvious possibilities:
tivated and executed. Similarly, in XTT2 only rules from the active
context are evaluated and can be executed. • facts list of the same type – a generalized attribute can be used
for aggregation of values having the same type. A value of gener-
Variables CLIPS provides two elements which allow for stor- alized attribute is defined as set. Such sets can be modified using
ing information: facts and variables. Nevertheless, the semantics of set theory operators. In particular union of sets or difference of
these two elements is different. Facts are knowledge-based elements sets can correspond to CLIPS operations of asserting or retracting
which defines what is currently known. Any change made in a set facts to/from knowledge base.
of facts invokes the pattern-matching process. In contrast to facts, • multivalued slots – the deftemplate construct in CLIPS allows
variables are used for defining non knowledge-based values e.g. val- for defining multivalued slots which can take more that one value:
ues of some factors, constant values, etc. Variables can be used as a
part of pattern-matching process, however changes of their values do (deftemplate person
not invoke pattern-matching. CLIPS variables can be defined using (slot name (type SYMBOL))
defglobal construct e.g.: (slot surname (type SYMBOL))
(defglobal ?*high-priority-factor* = 100) (slot gender (type SYMBOL))
(slot age (type INTEGER))
In turn, XTT2 does not provide any concept having the same se- (slot height (type INTEGER))
mantics as CLIPS variables. The system designed with XTT2 con- (multislot friends (type SYMBOL))
sists of attributes. According to ALSV(FD), the state of the XTT2- )
based system is defined as a set of current values of all attributes (assert (person (name Tom) (surname Joe)
specified within the knowledge base. From logical the point of view, (gender M) (age 18) (height 180)
the state of the system is represented as a logical formula (1). Ac- (friends John Alex Emma))
cording to this definition, all XTT2 attributes are considered to be )
knowledge-based elements.
It is important to notice that the inference mechanism from XTT2 This defines a man (M) Tom Joe that is 180 cm tall and 18 years
works in different way than in CLIPS. It evaluates rules in predeter- old and has three friends: John, Alex and Emma. It is important
mined order and changes in attribute values do not affect it. to notice that the list of friends is not treated as one string contain-
ing spaces, only as the list of three separate values.
4.2 Rule syntax Usually multislot contains values with the same semantics (infor-
mally described by a slot name). Apart from the support for com-
Complex types The first and most important limitation of the plex types, the generalized attribute in XTT2 can be used in the
XTT2 is related to complex types. A complex type is a data type same context as the multivalued slots in CLIPS.
Figure 3. An example of a large XTT2 table
Expressions in LHS The XTT2 method provides mechanisms for base: numeric,
logical quality analysis called HalVA [14]. It allows for discovering domain: [0 to 300]].
logical anomalies such as inconsistency, redundancy, contradictions xtype [name: age,
etc. In order to assure higher efficiency of HalVA, the LHS of the base: numeric,
rule can contain only a simple attribute-to-value comparisons e.g.: domain: [0 to 120]].
A = 12 B > 23 C in {1,2,3} In CLIPS, a value of a slot can be restricted using similar
concepts: primitive types, list of values, ranges. However, CLIPS
Such comparisons test a specific attribute against its value. Thus,
provides more primitive types than XTT2: SYMBOL, STRING,
an attribute is always on the left hand side of a comparison and con-
LEXEME, INTEGER, FLOAT, NUMBER, INSTANCE-NAME,
stant value or set of constant values on the right hand side. Neither
INSTANCE-ADDRESS, INSTANCE, EXTERNAL-ADDRESS, and
attributes nor expressions are allowed on the right hand side e.g.:
FACT-ADDRESS. Moreover, CLIPS allows for restricting a number
A = 11+1 B < A-3 of elements in multivalued slots.
The equivalent CLIPS-based definition of slot constraints describ-
In turn, the Right Hand Side (RHS) of a rule can contain complex ing person may look like this:
expressions and attribute references:
(deftemplate person
A := A+1 B := 4*3 (slot name (type SYMBOL) )
In contrast to XTT2, CLIPS allows for any complex expressions in (slot surname (type SYMBOL))
conditional part of the rules. This limitation of XTT2 can be omitted (slot gender (type SYMBOL)
by creating an additional decision table having required expression (allowed-symbols M F))
in its RHS. The figure 4 depicts the equivalent construction in CLIPS (slot height (type INTEGER) (range 0 300))
and XTT2. The rules comes from the Cashpoint example [21] and are (slot age (type INTEGER) (range 0 120))
intended to check if a user has entered a correct PIN. This is done by (multislot friends (type SYMBOL))
comparing enteredPIN and correctPin attributes. The equal- )
ity of this two attributes is a condition that must satisfied in order to The one advantage of XTT2 in comparison with CLIPS is that the
authorize a user. In CLIPS this condition can be placed directly in XTT2 allows for defining symbolic ordered domains. Such concept
LHS of a rule, while XTT2 required an additional table (Table3) is similar to enum construct from C programming language. Thanks
and attribute (pinDifference). to ordering, the symbolic values can be treated as ordinary integer
values e.g.:
Constraints ALSV(FD) provides a concept of attribute domain.
A domain is a finite set of admissible values that attribute can take. xtype [
Each domain is based on one of two primitive types symbolic or nu- name: weekdaytype,
meric. In XTT2, for each attribute a domain must be specified. The base: symbolic,
domain concept plays important role because it is used by verifi- domain: [mon/1,tue/2,wed/3,thu/4,
cation mechanism for discovering logical anomalies in knowledge fri/5,sat/6,sun/7],
base. The example below shows a definition of types (in HMR lan- ordered: yes].
guage) restricting values of the attributes describing a person. We
assume that: In this example a type describing weekdays is defined. Each day has
assigned an equivalent numeric value. Thanks to that one can write:
name is not restricted and can contain any list of characters,
gender can take only two values: M for male and F for female, mon > tue A = tue+wed
height can take a value from the interval [0, 300],
The results of this expressions are equal to results of corresponding
age can take a value from the interval [0, 120].
expressions where symbolic values were replaced with numeric.
xtype [name: name,
base: symbolic]. Values binding In some cases, it is very hard or even impossible
xtype [name: gender, to define LHS of a rule by using only logical and relational oper-
base: symbolic, ators. Let us consider the following example: The knowledge base
domain: [M,F]]. contains information about a number of people described by proper-
xtype [name: height, ties defined in paragraph Complex types:
xrule ’Table3’/1:
[enteredPin eq any,
correctPin eq any] (defrule rule-1
==> ?a <- (atm (enteredPin ?e)
[pinDifference set (correctPin ?c)
(correctPin-enteredPin)] (failedAtempts ?f))
:’Table2’. (test (neq ?e ?c))
=>
xrule ’Table2’/1: (modify ?a (authorizated false)
[pinDifference neq 0] (failedAtempts (+ ?f 1))))
==>
[authorizated set false, (defrule rule-2
failedAttempts set (failedAttempts+1)] ?a <- (atm
:’Table1’. (enteredPin ?e)
xrule ’Table2’/2: (correctPin ?c))
[pinDifference eq 0] (test (eq ?e ?c))
==> =>
[authorizated set true, (modify ?a (authorizated true)))
failedAttempts set failedAttempts]
:’Table1’.
Figure 4. The equivalent construction in XTT2 (on the left) and CLIPS (on the right)
(person (name Tom) (surname Joe) count. So, the variable binding can be used for defining restrictions
(gender M) (age 18) (height 180) across several objects. In our example, the ?h variable is bound in
(friends John Alex Emma)) the first condition and then its value is used in the second condition.
This restricts the set of possible facts that can be matched to the sec-
(person (name Emma) (surname Johnson) ond condition, because apart from the value F of the gender slot,
(gender F) (age 19) (height 180) a matched fact must have the same value of the height slot as the
(friends Tom Julia)) fact matched in the first condition.
Variable bindings is currently not supported in XTT2. Thus, defi-
(person (name Alex) (surname Johnson) nitions of equivalent rule is currently not possible.
(gender M) (age 17) (height 170)
(friends Tom Emma Julia)) Functions CLIPS allows for defining functions. It is possible to
Our task is to define a rule selecting all allowed pairs of persons define a user-defined external functions that can be written in an ex-
which can dance together. Two person can dance together when sat- ternal language e.g. C and then linked with CLIPS during recom-
isfy the following conditions: 1) They have different gender and 2) pilation. Such functions can be later executed directly in CLIPS in
they have the same growth. Such a rule can be easily written us- ordinary manner. Moreover, CLIPS provides a second mechanism
ing mechanism allowing for value binding. This mechanism allows allowing for defining function directly in CLIPS by using CLIPS-
for retrieving desired value during inference and storing it in a user- based syntax. This can be done with the help of the deffunction
defined variable. Then, this variable can be used in further conditions construct. The CLIPS-based functions have all features that an ordi-
as well as conclusion part. The rule for our task can look like this: nary function can have i.e.: unique name, list of parameters, sequence
of actions, returned value, recursion. An example function that cal-
(defrule rule-1 "Our solution" culates the factorial of an argument can be written as follows:
(person (name ?n1) (surname ?s1)
(gender M) (height ?h)) (deffunction factorial (?a)
(person (name ?n2) (surname ?s2) (if (or (not (integerp ?a)) (< ?a 0)) then
(gender F) (height ?h)) (printout t "Factorial Error!" crlf)
=> else
(printout t ?n1 " and " ?n2 crlf) (if (= ?a 0) then
) 1
else
The LHS of the rule contains two conditions that refers to person (* ?a (factorial (- ?a 1))))))
template. Thanks to this, the inference algorithm would try to match
all possible pairs of person facts. When a single match is per- It is important that each function can be invoked from any part of
formed, then the variables (which names start with question mark) a rule and can modify a knowledge base.
are bound to the current value of the matched fact. Binding is made XTT2 provides a similar mechanism to CLIPS user-defined ex-
only one time during a single match and the variable stores bounded ternal functions through callbacks. Callback function is an external
value until this particular match is finished. Thus, usage of bounded function written in Prolog or Java language. Then, such function is
variable in further conditions restricts the set of elements that can invoked by Prolog interpreter directly or by using JPL plugin for call-
be matched because matching algorithm must take its value into ac- backs written in Java.
Rules properties The way, a rule is processed by CLIPS can be
modified by changing rule properties. CLIPS provides support for
two properties auto-focus and salience.
The auto-focus property allows an automatic focus com-
mand to be executed whenever a rule becomes activated. If the
auto-focus property for a rule is true, then a focus command
on the module in which the rule is defined is automatically executed
whenever the rule is activated. This property can be used for defining
rules responsible for values validation:
(defrule VIOLATIONS::bad-age
(declare (auto-focus TRUE))
(person (name ?name) (age ?x&:(< ?x 0)))
Figure 5. An example of dialog invoked by callback function
=>
(printout t ?name " has a bad age value."))
Callbacks in XTT2 are strictly related to attributes. Each attribute The above rule is activated whenever the VIOLATIONS module re-
can have two callback functions assigned: input callback and/or out- ceives focus and checks if all the person facts accessible in that mod-
put callback. The input callbacks are used for retrieving attribute ule have correct value of the slot age.
value from outside system when value of an attribute is not defined. The salience property allows for assigning a priority to a rule.
Thus, this type of callback function can modify a knowledge base. In This property is a part of conflict resolution mechanism, which uses
contrast to input callbacks, the output callbacks cannot modify state a salience value for determining order of rules to be fired. Rules
of the system and are used only for presentation purposes. The or- with higher value have precedence to be executed.
der and time when a callback is invoked is determined by inference XTT2 does not provide any rules properties directly. However, the
algorithm and cannot be redefined. The example below depicts the ALSV(FD) logic defines the decision component (table) as follows:
definition of input callback and attribute to which is assigned:
t = (r1 , r2 , . . . , rn )
xcall ask_console_symbolic: [AttName] >>> (
alsv_domain(AttName,Domain,symbolic), This means that rules placed in an XTT2 table are ordered. The in-
write(’availible answers are ’), ference engine uses this order for determining precedence of rules
write(Domain), nl, evaluation and execution. This precedence can be changed by mov-
write(AttName), write(’: ’), read(Answer), ing rules in the table.
(member(Answer,Domain) -> This behavior corresponds to CLIPS salience rule property.
However, XTT2 forces the different values of rules priority in con-
xattr [name: weekday, trast to CLIPS that allows for rules with the same priority. This is
abbrev: weekday, why, the XTT2 method do not provide conflict resolution strategies.
class: simple,
type: weekdaytype,
comm: in, 4.4 Rule processing
callback: [ask_console_symbolic,[day]] Facts maintenance Any modification of KB in CLIPS that is done
This callback function invokes dialog allowing user to provide by using commands like assert, retract and modify, exe-
value of an attribute. The example of such dialog is depicted in Fig- cutes a pattern-matching algorithm which attempts to match rules
ure 5. The list of possible values is created according to attribute to the current state of the system (as represented by the fact-list and
type. The definition of the attribute weekday type can be found in instance-list). Each rule that has satisfied their conditional part (LHS
Section 4.2 in paragraph Constraints. – Left Hand Side) with respect to the modification is activated for
execution. CLIPS allows non monotonic inference because each rule
firing may again modify the KB. This inference process continues
4.3 Rule semantics while KB is being modified. During this time, any rule can be acti-
Ordered structures CLIPS facts defined by using deffact con- vated and executed many times.
struct are also called non-ordered facts. This is because the fact struc- As it was mentioned, the XTT2 knowledge base contains a con-
ture consists of fields that are referred by named slots. Additionally, stant number of attributes (facts). The only modification that can
CLIPS provides an ordered facts which encode information position- be made is changing of the attribute value. However, in contrast
ally. To access the information, a user must know not only what data to CLIPS, such modifications of the KB do not execute pattern-
is stored in a fact but which field contains the data. The first field matching algorithm in order to find the rules that have satisfied their
of an ordered fact specifies a relation that applied to the remaining conditional parts against to a new system state.
fields in the ordered fact e.g.: This behavior is deliberate and follows from the method assump-
tions. According to this assumptions, the user defines the functional
(father-of jack bill)
dependencies between attributes (links between tables). Thus, if a
This fact defines that bill is the father of jack. rule should be checked for execution when a value of an attribute
The current XTT2 method does not provide any concept with sim- is changed, then a user must define an appropriate dependency. This
ilar semantics. ALSV(FD) provides support only for complex types, allows for optimized rule activating and more advanced inference
where properties of object are referred by attribute function. control in comparison with CLIPS.
5 Summary REFERENCES
The main focus of this paper is to compare XTT2 with the CLIPS [1] Weronika T. Adrian, Szymon Bobek, Grzegorz J. Nalepa, Krzysztof
language. The scope of the provided comparison covers only the ba- Kaczor, and Krzysztof Kluza, ‘How to reason by HeaRT in a semantic
knowledge-based wiki’, in Proceedings of the 23rd IEEE International
sic CLIPS language elements. In fact, the CLIPS language provides Conference on Tools with Artificial Intelligence, ICTAI 2011, pp. 438–
fully object oriented syntax called CLIPS Object Oriented Language 441, Boca Raton, Florida, USA, (November 2011).
(COOL). However, in the context of this paper the COOL syntax has [2] Grigoris Antoniou and Frank van Harmelen, A Semantic Web Primer,
not been taken into account. This paper tries to identify differences The MIT Press, 2008.
[3] Harold Boley, Said Tabet, and Gerd Wagner, ‘Design rationale for
between these two languages in terms of the following aspects: ruleml: A markup language for semantic web rules’, in SWWS, eds., Is-
• Rule Base — differences related to knowledge maintenance and abel F. Cruz, Stefan Decker, Jérôme Euzenat, and Deborah L. McGuin-
ness, pp. 381–401, (2001).
representation,
[4] Paul Browne, JBoss Drools Business Rules, Packt Publishing, 2009.
• Rule syntax — comparison of the languages expressiveness, [5] Tim Denvir, Jose Oliveira, and Nico Plat, ‘The Cash-Point (ATM)
• Rule semantics — differences in knowledge interpretation, ’Problem’’, Formal Aspects of Computing, 12(4), 211–215, (Dec 2000).
• Rule processing — issues related to different knowledge evalua- [6] Joseph Giarratano and Gary Riley, Expert Systems. Principles and Pro-
tion and processing. gramming, Thomson Course Technology, Boston, MA, United States,
4th edn., 2005. ISBN 0-534-38447-1.
As it can be concluded from this paper, expressiveness of the XTT2 [7] Adrain A. Hopgood, Intelligent Systems for Engineers and Scientists,
language (in comparison with CLIPS) is limited in each of the con- CRC Press, Boca Raton London New York Washington, D.C., 2001.
[8] Michael Kifer and Harold Boley, ‘RIF overview’, W3C working draft,
sidered aspect. What is more, this paper shows that the ALSV(FD) W3C, (October 2009). http://www.w3.org/TR/rif-overview.
logic, on which XTT2 is based, has also several limitations. On the [9] The Handbook of Applied Expert Systems, ed., Jay Liebowitz, CRC
other hand, in contrast to CLIPS, the XTT2 language provides strong Press, Boca Raton, 1998.
underlying formalism playing a key role in rule interoperability. Due [10] Antoni Lig˛eza, ‘Expert systems approach to decision support’, Euro-
to the fact that CLIPS language is only a programming solution, a pean Journal of Operational Research, 37(1), 100–110, (1988).
[11] Antoni Lig˛eza, Logical Foundations for Rule-Based Systems, Springer-
definition of an efficient CLIPS-based knowledge interchanging can- Verlag, Berli, Heidelberg, 2006.
not be done. This is why, the extension of both the ALSV(FD) logic [12] David Luckham, ‘Complex event processing (CEP)’, Software Engi-
and XTT2 is a must in order to define an unified and formalized neering Notes, 25(1), 99–100, (2000).
knowledge interoperability method. This extended formalism will [13] Grzegorz Nalepa, Szymon Bobek, Antoni Lig˛eza, and Krzysztof Kac-
zor, ‘Algorithms for rule inference in modularized rule bases’, in Rule-
allow for preserving rule semantics during interchanging. What is Based Reasoning, Programming, and Applications, eds., Nick Bassili-
more, this method is intended to be supported by tools. ades, Guido Governatori, and Adrian Paschke, volume 6826 of Lecture
We selected the CLIPS language because it is considered to be Notes in Computer Science, pp. 305–312. Springer, (2011).
successful in the Artificial Intelligence research community and have [14] Grzegorz Nalepa, Szymon Bobek, Antoni Lig˛eza, and Krzysztof Kac-
been used for many AI software projects. What is more, similarly zor, ‘HalVA - rule analysis framework for XTT2 rules’, in Rule-Based
Reasoning, Programming, and Applications, eds., Nick Bassiliades,
to CLIPS, the XTT2 language is intended to be rule-based systems Guido Governatori, and Adrian Paschke, volume 6826 of Lecture Notes
modeling method in their classic form. On the other side, the current in Computer Science, pp. 337–344. Springer, (2011).
application of rules (Business Rules) differs from the classic systems. [15] Grzegorz J. Nalepa, ‘Architecture of the HeaRT hybrid rule engine’, in
One of the most important difference lies in different rule types. The Artificial Intelligence and Soft Computing: 10th International Confer-
ence, ICAISC 2010: Zakopane, Poland, June 13–17, 2010, Pt. II, eds.,
classic systems usually provide only one rule type called production Leszek Rutkowski and [et al.], volume 6114 of Lecture Notes in Artifi-
rule, while the BR-based languages provide five rule types: Denotic cial Intelligence, pp. 598–605. Springer, (2010).
Rules, Derivation Rules, Integrity Rules, Reaction Rules and Trans- [16] Grzegorz J. Nalepa, Semantic Knowledge Engineering. A Rule-Based
formation Rules. This rule classification is based on the specific rule Approach, Wydawnictwa AGH, Kraków, 2011.
properties (e.g. monotonicity of KB modification) and purposes (e.g. [17] Grzegorz J. Nalepa and Antoni Lig˛eza, ‘A graphical tabular model
for rule-based logic programming and verification’, Systems Science,
reaction on events). We do not discuss the differences between these 31(2), 89–95, (2005).
types in details, because this is out of scope of this paper. These five [18] Grzegorz J. Nalepa and Antoni Lig˛eza, ‘HeKatE methodology, hybrid
types of Business Rules slightly extend the semantics of the produc- engineering of intelligent systems’, International Journal of Applied
tion rules. Nevertheless, each type of Business Rule can be repre- Mathematics and Computer Science, 20(1), 35–53, (March 2010).
[19] Grzegorz J. Nalepa, Antoni Lig˛eza, and Krzysztof Kaczor, ‘Formal-
sented in classic rule-based systems using the production rules. This ization and modeling of rules using the XTT2 method’, International
is why, despite the classic nature of CLIPS or XTT2, these languages Journal on Artificial Intelligence Tools, 20(6), 1107–1125, (2011).
can also be used for BR modeling. [20] Grzegorz J. Nalepa, Antoni Lig˛eza, Krzysztof Kaczor, and Weronika T.
The mentioned in Section 2. methods for rule interoperability (e.g. Furmańska, ‘HeKatE rule runtime and design framework’, in Proceed-
RIF) try to take rule properties and purpose into account. This is why, ings of the 3rd East European Workshop on Rule-Based Applications
(RuleApps 2009) Cottbus, Germany, September 21, 2009, eds., Adrian
such a language is divided into so called dialects. RIF provides two Giurca, Grzegorz J. Nalepa, and Gerd Wagner, pp. 21–30, Cottbus, Ger-
standard dialects for rule representation: BLD (Basic Logic Dialect) many, (2009).
and PRD (Production Rules Dialect). In general, the BLD and PRD [21] Pascal Poizat and Jean-Claude Royer, ‘Kadl specification of the cash
dialects divide rules into two types: allowing for monotonic and non- point case study’, Technical report, IBISC, FRE 2873 CNRS - Univer-
site d’Evry Val d’Essonne, France, Genopole Tour Evry 2, 523 place
monotonic changes in the Knowledge Base. In terms of BR types, des terrasses de l’Agora 91000 Evry Cedex, (January 2007).
usually the Derivation, Denotic and Transformation rules can be ex- [22] Barbara von Halle, Business Rules Applied: Building Better Systems
pressed in the BLD dialect while remaining in the PRD dialect. Using the Business Rules Approach, Wiley, 2001.
Working on extension of XTT2 and ALSV(FD), the different types [23] G. Wagner, A.Giurca, and S. Lukichev, ‘R2ml: A general approach for
of rules will be taken into account and different formalisms will be marking up rules’, in Principles and Practices of Semantic Web Rea-
soning, Dagstuhl Seminar Proceedings 05371, eds., F. Bry, F. Fages,
provided. We assume, the unified rule representation model will be M. Marchiori, and H. Ohlbach, (2005).
based on the Attributive Logic. However, this issue will be elaborated
in details in the future work.