=Paper=
{{Paper
|id=None
|storemode=property
|title=Rule Modularization and Inference Solutions – a Synthetic Overview
|pdfUrl=https://ceur-ws.org/Vol-646/DERIS2010paper4.pdf
|volume=Vol-646
}}
==Rule Modularization and Inference Solutions – a Synthetic Overview==
https://ceur-ws.org/Vol-646/DERIS2010paper4.pdf
Rule Modularization and Inference Solutions – a Synthetic Overview
Krzysztof Kaczor and Szymon Bobek and Grzegorz J. Nalepa
Institute of Automatics,
AGH University of Science and Technology,
Al. Mickiewicza 30, 30-059 Kraków, Poland
ABSTRACT rule-bases cause many problems: 1) Maintenance of
the large set of rules. 2) Inference inefficiency – the
Rule–based expert systems proved to be a successful large number of rules may be unnecessary processed.
AI technology in a number of areas. Building such The modularization of the rule-base that introduces struc-
systems requires creating a rulebase, as well as pro- ture to the knowledge base can be considered as the
viding an effective inference mechanism that fires rules way to avoid these problems. The rules can be grupped
appropriate in a given context. The paper briefly dis- in the modules, what can facilitate the maintenance of
cusses main rule inference algorithms Rete, TREAT the large set of rules. What is more, the inference algo-
and Gator. Since large rulebases often require identify- rithm may be integrated with structured rule-base. The
ing certain rule clusters, modern inference algorithms integration can influence the inference performance.
support inference rule groups. In the paper the case of
The main focus of this paper is the inference in
the new version of Drools, introducing the RuleFlow
the structured rule bases. The Section 2 presents the
module is presented. These solutions are contrasted
well-known expert system shells such as CLIPS [1],
with a custom rule representation method called XTT2.
JESS [2] and Drools 5 [3]. It shows how the knowl-
It introduces explicit structure in the rulebase based on
edge base can be structured in these systems and how
decision tables linked in an inference network. In this
the inference algorithm can be used over this structure.
case, the classic Rete–based solutions cannot be used.
The next Section 3 describes three main pattern match-
This is why custom inference algorithms are discussed.
ing algorithms such as Rete [4], TREAT and the most
In the paper possible integration of the XTT2 approach
recent and general Gator. In the Section 5 the main
with that of RuleFlow is discussed.
concepts of the XTT method are introduced. The sec-
tion presents the structure of the XTT knowledge base.
1. INTRODUCTION It also introduces the inference methods taking the un-
derlying algorithm into consideration. The conclusions
Rules constitute a cardinal concept of the rule–based of the paper are included in the Section 6.
expert systems (RBS for short) [1]. Building such sys-
tems requires creating a knowledge base, which in case
of RBS can be separated into two parts: factbase con- 2. EXPERT SYSTEMS SHELLS
taining the set of facts and rulebase containing the set of
rules. To make use of this two parts, the inference en- Expert system shell is a framework that facilitates cre-
gine must be provided. The inference engine is respon- ation of complete expert systems. Usually, they have
sible for generating findings. This is done according most of the important functionalities built-in such as:
to the current state of the factbase and with the help of rule-base, inference algorithm, explanation mechanism,
the rules. In the first task of the inference mechanism user interface, knowledge base editor.
the conditional parts of the rules are checked against Such system must be adopted to the domain-specific
the facts from the factbase. This task is performed by problem solving. This can be done by creation of the
pattern matching algorithm. The output from the al- knowledge base. The knowledge engineer must cod-
gorithm is the set of rules, which conditional parts are ify the captured knowledge according to the formalism.
satisfied. This set of rules is called a conflict set. The The knowledge can be captured in a several ways, but
following task of the inference mechanism is the execu- this issue is not discussed in this paper.
tion of the rules from the conflict set. There are many CLIPS is an expert system tool that is based on
different algorithms for determining an execute order Rete algorithm. It provides its own programming lan-
of the rules, but they are not discussed in this paper. guage that supports rule-based, procedural and object-
The main problem discussed in this paper concerns oriented programming [1]. Thanks to this variety of
inference methods in structured rule-bases. A rule-base programming paradigms implemented in CLIPS, there
can contain thousands or even milions rules. Such large are three ways to represent knowledge in it:
• rules, which are primarily intended for heuristic A rule base in the RBS consists of a collection of
knowledge based on experience, rules called productions. The interpreter operates on
the productions in the global memory called working
• deffunctions and generic functions, which are pri-
memory (WM for short). Each object is related to a
marily intended for procedural knowledge,
number of attribute–value pairs. The set of pairs re-
• object-oriented programming, also primarily in- lated to the object and object itself constitute a single
tended for procedural knowledge. The generally working element.
accepted features of object-oriented programming By convention, the conditional part (IF part) of
are supported. Rules may pattern match on ob- a rule is called LHS (left–hand side), whereas the con-
jects and facts. clusion part is known as RHS. The inference algorithm
The condition in CLIPS is a test if given fact ex- performs the following operations: 1) Match – checks
ists in knowledge database. The right-hand side (RHS) LHSs of rules to determine which are satisfied accord-
of rule contains actions such like assert or retract that ing to the current content of the working memory. 2) Con-
modifies facts database or other operations such like flict set resolution – selects production(s) (instantia-
function invocations that does not affect system state. tion(s)) that has satisfied LHS. 3) Action – Perform
CLIPS has been written in C language. This makes the actions in the RHS of the selected production(s).
the tool very efficient and platform independent. How- 4) Goto 1. The first step is a bottleneck of inference
ever, the integration with other existing systems is not process. The algorithms, which are presented in this
as easy as it is in case JESS. section, try to alleviate this problem.
JESS is a rule engine and scripting environment The Rete algorithm [4] is an efficient pattern match-
written entirely in Sun’s Java language by Ernest ing algorithm for implementing production rule sys-
Friedman-Hill [2] that derives form CLIPS. tems. It computes the conflict set. The naive implemen-
Jess uses a very efficient method known as the Rete tation of the pattern matching algorithm might check
algorithm. In the Rete algorithm, inefficiency of the each production against each working element. The
combinatoric explosion of rules analysis is alleviated main advantage of the Rete algorithm is that it tries to
by remembering the past test results across the itera- avoid iterating over production and working memory.
tions of a rule loop. Only new facts are tested against Rete can avoid iterating over working memory by
each rule conditional part, but still all rules must be storing the information between cycles. Each pattern
taken into consideration. stores the list of the elements that it matches. Due to
Jess supports both forward-chaining and backward this fact, when working memory is changed only the
chaining. The default is forward-chaining. As the knowl- changes are analysed.
edge representation JESS uses rules as well as XML- Rete also can avoid iterating over production set.
based language called JessML. JESS uses LISP-like This is done by forming a tree-like structure (network)
syntax, which is the same as in CLIPS. The JessML is that is compiled from the patterns. The network com-
not convenient to read by human. It contains more de- prise of two types of nodes: intra–elements that involve
tails, what makes this representation suitable for parsers. only one working element and inter–elements that in-
Drools 5 introduces the Business Logic integration volve more than one working element. At first, the
Platform which provides a unified and integrated plat- pattern compiler builds a linear sequence of the intra-
form for Rules, Workflow and Event Processing. Drools elements. This part of the network is called alpha mem-
is now split up into 4 main sub projects: 1) Drools Gu- ory and contains only the one-input nodes. After that,
vnor (BRMS/BPMS) – centralised repository for Drools the compiler builds the beta memory from the inter-
Knowledge Bases. 2) Drools Expert (rule engine). 3) elements. The beta memory consists of the two-input
Drools Flow (process/workflow) provides workflow or nodes. Each two-input node (except the first one) joins
(business) process capabilities to the Drools platform. one two-input node and one one-input node. The first
4) Drools Fusion (event processing/temporal reason- two-input node joins two one-input nodes.
ing) – the module responsible for enabling event pro-
cessing capabilities. Drools Expert is a rule engine ded- R1(a > 17, d(X)),
icated for the Drools 5 rule format. R2(d(X), e(Y ), g(Z)),
Drools 5 implements only forward-chaining engine, R3(c = on, g(Z)), (1)
using a Rete-based algorithm – ReteOO. In the future, R4(e(Y ), f (W )),
Drools 5 is promised to support a backward-chaining. R5(b = F riday, f (W ))
3. RULE INFERENCE ALGHORITHMS When the working memory is changed, the working el-
ements, that has been changed, are let int to the net-
This section discusses three the most important pattern work. Each node of the network tries to match the given
matching algorithms. The descriptions of these algo- working element. If it matches, then the copy of the el-
rithms introduce specific nomenclature. ement is passed to all the successors of the node. The
R1 R2 R3 R4 R5
amination for rules to remove. No matching is
R1 R2
required to process deletion since any instanti-
R1 R2 R3 ation of the rule containing removed element is
simply deleted.
R1 R2 R3 R4
Condition membership introduces new property for
R1 R2 R3 R4 R5
each rule called rule-active that determines weather each
of the rule condition elements is partially matched. The
Fig. 1. A general schema of the Rete network.
match algorithm ignores then rules that are non-active
during production system cycles.
two-input nodes joins the elements from the two differ- Gator algorithm. Both Rete and TREAT offer static
ent paths of the network into bigger one. The last two- networks, which structures are defined arbitrary by the
input element (terminal element) is the output from the design engineer (Rete) and looks mostly the same for
algorithm and contains the information about changes, all kinds of knowledge databases (Rete and TREAT).
which must be applied to the conflict set. This very often leads to the creation of networks that
Rete algorithm has been invented by Charles L. Forgy are not optimal for some knowledge bases.
of Carnegie Mellon University. At first, Rete has been To address this problem a new discrimination net-
assumed as the most efficient algorithm for this prob- work algorithm called Gator was proposed. It is based
lem. The literature did not contain any comparative on Rete, but additionally implements mechanisms for
analysis of the Rete with any other algorithm. Nowa- optimizing network structure according to specific kno-
days, other algorithms such as Treat, A-Treat, Gator are wledge base characteristic. It can be said that Rete and
known. Some of them are discussed in this paper. TREAT are special cases of Gator and as reported in [6]
TREAT algorithm. State saving mechanism im- it outperforms TREAT and Rete in most cases.
plemented in Rete is not very efficient. The structure Every rule in production system can be represented
of the Rete network often stores redundant information by a condition graph with nodes for rule condition ele-
and number of elements stored in beta-memory nodes ments and edges for join conditions.
may be combinatorially explosive. Moreover cost of Gator networks are general tree structures. They
join operation in beta-memory are very expensive when consist of alpha–memory elements (leaves), optional
many addition and deletion operations are preformed. beta-memory elements (internal nodes, that can have
To address these problems new version of Rete algo- multiple inputs) and a P–node which is a root of the
rithm called TREAT was proposed. tree representing a complete RHS of the rule.
Rete algorithm is based on two concepts: Mem-
ory support that creates and maintains alpha–memory R1 R2 R3 R4 R5
and Condition relationship that join operations in beta–
memory. TREAT also uses Memory support, but does R1 R2 R3 R4 R5
not use Condition relationship. Instead Conflict set sup-
port and Condition membership are used. Absence of
R1 R2 R3 R4 R5
Condition relationship implies fact that in TREAT net-
work structure there is no beta memory. Hence, the
structure of TREAT network is flat. Fig. 3. Gator network for rule 1
R1 R2 R3 R4 R5
The optimizing algorithm is iterative. It starts form
networks of size one (which are basically alpha–memory
elements) and combine them into larger optimal net-
R1 R2 R3 R4 R5
works. There is a constraint which states that every
newly created network have to be optimal. That en-
Fig. 2. TREAT network for rule 1 sures that the final network would also be optimal.
The network is built and optimize according to the
The main idea of the TREAT algorithm is to ex-
following rules:
ploit the conflict set support for temporarily redundant
systems. The conflict set is explicitly retain across pro- • Connectivity Heuristic – do not combine two
duction system cycles which allows for the following Gator networks unless there is an explicit con-
advancements comparing to Rete [5]: nection between them in connectivity graph.
• in case of addition of WM element, conflict set • Disjointness constraint – do not combine net-
remains the same, and constrained search for new works unless their respective sets of rule condi-
instantiation of only those rules that contain newly tion elements do not overlap.
added WM element is performed.
• Lowest Cost Heuristic – if there is already a net-
• deletion from WM triggers direct conflict set ex- work that covers the same set of condition as the
new network, and the existing network cost (ac- Each rule can decide which module should be focused
cording to the cost function) no more than the as the next one. To accomplish that, the operation of
new one, discard new network. the focus changing should be included in the rule con-
clusion part. This leads to the structured rulebase, but
More detailed information about cost functions and still all rules are checked against the facts. In terms of
rules for combining Gator networks can be found in [6]. efficiency the modules mechanism does not influence
on the performance of the conflict set creation.
Drools RuleFlow. It is a workflow and process en-
gine that allows advanced integration of processes and
4. KNOWLEDGE MODULARIZATION
rules. It provides a graphical interface for processes
Most of the well–known expert systems have a flat knowl- and rules modelling. Drools have built-in a function-
edge base. In such case, the inference mechanism have ality to define the structure of the rulebase which can
to check each rule against each fact. When the knowl- determine the order of the rules evaluation and exe-
edge base contains a large number of rules and facts cution. The rules can be gruped in a ruleflow–groups
this process becomes inefficient. This problem can be which defines the subset of rules that are evaluated and
solved by providing a structure in the knowledge base executed. The ruleflow–groups have a graphical rep-
that allows for checking only a subset of rules. This resentation as the nodes on the ruleflow diagram. The
Section describes the three well–known expert system ruleflow–groups are connected with the links what de-
shells CLIPS, JESS and Drools and knowledge base or- termines the order of its evaluation. A ruleflow diagram
ganisation implementen in them. is a graphical description of a sequence of steps that the
rule engine needs to take, where the order is important.
CLIPS Modules. CLIPS offers functionality for
Rules grouping in Drools 5 contributes to the effi-
organising rules into so called modules. Modules al-
ciency of the ReteOO algorithm, because only a subset
lows for restriction of access to their elements from
of rules are evaluated and executed. However there is
other modules, and can be compared to global and local
no policy which determines when a rule can be added
scoping in other programming languages. Modulariza-
to the ruleflow-group. Due to this fact, the rules grup-
tion of knowledge base helps managing rules, and im-
ping can provide a muddle in the rule base especially
proves efficiency of rule-based system execution. Mod-
in case of large rulebases.
ules in CLIPS are defined with defmodule command.
In CLIPS each module has its own pattern-matching
network for its rules and its own agenda. When a run 5. XTT–BASED EXPERT SYSTEMS
command is given, the agenda of the module which is
the current focus is executed. Rule execution contin- Knowledge bases in expert system shells described in
ues until another module becomes the current focus, no Section 2 are flat and do not have any internal structure.
rules are left on the agenda, or the return function is To create a conflict set the entire knowledge base have
used from the RHS of a rule. Whenever a module that to be searched, and an intelligent inference control in
was focused on runs out of rules on its agenda, the cur- such unstructuralised system is very difficult. Knowl-
rent focus is removed from the focus stack and the next edge representation languages are not formal neither in
module on the focus stack becomes the current focus. Drools, Jess, nor in CLIPS and as a consequence there
Before a rule executes, the current module is changed are not formalized methods for verifying and analysing
to the module in which the executing rule is defined systems designed with those tools. To solve these prob-
(the current focus). The current focus can be dynami- lems a new knowledge representation method called
cally switched in RHS of the rule with focus command. XTT2 (Extended Tabular Trees) was proposed which
JESS Modules. Jess provides modules mechanism is part of the HeKatE [7] methodology for designing,
that helps to manage large numbers of rules. Rules implementing and verifying production systems.
modularisation can be considered as the structure of the
rulebase. Modules also provide a control mechanism: 5.1. Knowledge representation
the rules in a module will fire only when that module
has the focus, and only one module can be in focus at Main goals of XTT2 knowledge representation was 1)
a time. Jess makes the modules defining possible with to provide an expressive formal logical calculus for rules,
the help of defmodule command. The module name can 2) allow for advanced inference control and formal anal-
be considered as a namespace for rules. This means ysis of the production systems, 3) provide structural
that two different modules can each contain a rule with and visual knowledge representation. XTT2 incorpo-
a the same name without conflicting. Modules can also rates extended attributive table format, where similar
be used to control execution. In general, although any rules are grouped within separated tables, and the sys-
Jess rule can be activated at any time, only rules in the tem is split into such tables linked by arrows represent-
focus module will fire. It is possible to manually move ing the control strategy. Each table consist of two parts
the focus to another module using the focus function. representing condition and decision part of the rule.
To help creating the XTT2 network, ARD+ dia- the initial ones in the XTT network into a FIFO queue.
grams provide the conceptual design. This stage is sup- When there is no more tables to be added to the queue,
ported by VARDA tool that generates XML file (called algorithm fires selected tables in order they are poped
HML in HeKatE methodology) with specification of from the queue. This inference mode s especially use-
types, domains, attributes and dependencies between ful for diagnosis systems, where a lot of symptoms
them. Based on this file a XTT2 skeleton is created in are given as an input that can lead to multiple diagno-
HQEd editor, and the tables are filled with rules [8]. sis. Choosing apropriate reasoning path by the system
Rules representation in XTT2 is based on attribu- saves time and memory. [GDI] A goal-driven approach
tive logic called ALSV(FD) [7]. Each rule in XTT table works backwards with respect to selecting the tables
is of the form: necessary for a specific task, and then fires the tables
forwards so as to achieve the goal. One or more out-
(A1 ∝1 V1 ) ∧ . . . ∧ (An ∝n Vn ) −→ RHS (2) put tables are identified as the ones that can generate
the desired goal values and are put in LIFO queue. As
where the logical formula on the left describes the rule
a consequence only those tables that leads to desired
condition, and RHS is the right-hand side of the rule
solution are fired, and no rules are fired without pur-
covering conclusions (see [7] for more details).
pose. This inference algorithm works best in hypotesis-
The logical rule representation is mapped to the HMR
proving systems, where value of attribute from partic-
language (Hekate Meta Representation) which is an in-
ular table is wanted. [TDI] This approach is based on
ternal rule language for XTT. Following example shows
monitoring the partial order of inference defined by the
HMR the notation and its pseudocode representation.
network structure with tokens assigned to tables. A
xrule tab_4/1: [today eq workday, table can be fired only when there is a token at each
hour in [9 to 17]] ==> input. A token at the input is a kind of a flag sig-
[operation set bizhours].
xrule tab_4/4: [today eq workday,
nalling that the necessary data generated by the preced-
hour gt 17] ==> ing table is ready for use. This inference mode was de-
[operation set not_bizhours]. signed to support systems where a lot of dependencies
between tables and rules are denoted that would require
Pseudocode representation:
many redundant conditions XTT tables. Tokens allow
IF today=workday AND hour>=9 AND hour<=17 THEN to omit those unnecessary conditions, which saves time
operation := bizhours
IF today = workday AND hour > 17 THEN
and memory and makes the system more readable.
operation := not_bizhours The highly modularised knowledge representation
that is used in XTT2 was one of the reasons why in-
This formal, logical representation of the rules al- ference engine – HeaRT – implemented for XTT2 ap-
lows for formal analysis and verification of the system. proach does not use matching algorithm based on Rete.
Due to the fact that HeaRT was implemented entirely
5.2. Intelligent inference controll in Prolog, fast and efficient unification algorithm that
is implemented in Prolog interpreter was used instead.
Described in section 5.1 XTT2 knowledge representa-
tion allows for more efficient inference control during
rule-based system execution. The inference control is 5.3. Structure of the Knowledge Base
assured thanks to firing only rules necessary for achiev-
ing the goal. It is achieved by selecting the desired Considering the differences between the XTT2 approach
output tables and identifying the tables necessary to be and the classic Rete-based solutions, at least two mean-
fired first. The links between tables representing the ings of the notion „structure of the rule base” can be
partial order assure that when passing from a table to given. The first one is related the previously discussed
another one, the latter can be fired since the former one modules in classic expert system shells. There a physi-
prepares an appropriate context knowledge. There are cal structure of the rule base is introduced using mod-
four algorithms based on XTT2 notation that control ules. The global set of rules is partitioned by the system
the inference. They were successfully implemented in designer into several parts in an arbitrary way. This is
HeaRT (HeKatE RunTime) inference engine [9]. a technical solution, similar to source code partitioning
[FOI] The simplest algorithm consists of a hard- methods such as packages is programming languages.
coded order of inference, in such way that every table Practically, these partitions are often merged during the
is assigned an integer number; all the numbers are dif- inference process. Therefore, the partitioning process
ferent from one another. The tables are fired in order itself does not support in optimizing the design and in-
from the lowest number to the highest one. This infer- ference. The second one is realized in the XTT2 rep-
ence algorithm is usefull when a reasoning path is well resentation. Here rules working in the same context,
defined and does not change over rule-based system cy- i.e. having the same conditional attributes are grouped
cles. [DDI] A data-driven inference algorithm iden- into tables (forming simple rule sets) during the design
tifies start tables, and put all tables that are linked to process. This forms a logical structure of the rule base.
This structure is considered during the inference pro- Flow will allow to combine business processes with
cess – only necessary rules are considered, an possibly formal, modular knowledge representation. Since Drools-
fired. Therefore, the modularization process does sup- Flow diagrams may contain other DroolsFlow diagrams,
port optimization of both the design and inference. relations between XTT tables would not be limited to
relation table to table, but may also be considered as
6. CONCLUDING REMARKS realtion system to system. Integrating DroolsFlow and
XTT can be done by invoking HeaRT from within Drools-
All of the common expert system shells described in Flow blocks directly, using the SWI JPL package for
this paper use Rete or its variants as a matching algo- Java integration, or via TCP/IP protocol.
rithm. This is so, because Rete algorithm is very effi-
cient on flat and not structured knowledge base. Once Acknowledgements
knowledge base becomes modularized, Rete loses its
Paper is supported by the BIMLOQ Project funded from
assets. Although idea of modules as sets of not related
2010–12 resources for science as a research project.
in any way rules was introduced in CLIPS, the core in-
ference algorithm – Rete – remained the same. Such
partial modularisation slightly increases performance 7. REFERENCES
of the system, but still did not solve efficient design
and verification problems. Most of solutions presented [1] Joseph C. Giarratano and Gary D. Riley, Expert
in CLIPS or Jess are just modifications of existing ap- Systems, Thomson, 2005.
proaches that have their own historical drawbacks. [2] E. Friedman-Hill, Jess in Action, Rule Based Sys-
To address these problems a new knowledge rep- tems in Java, Manning, 2003.
resentation called XTT2 was proposed that is a part
of newly designed methodology for designing, imple- [3] Paul Browne, JBoss Drools Business Rules, Packt
menting and verifying expert systems, called HeKatE. Publishing, 2009.
It provides visual representation of the knowledge base, [4] Charles Forgy, “Rete: A fast algorithm for the
formal verification of the rule–based systems and in- many patterns/many objects match problem,” Artif.
telligent inference control. XTT2 knowledge base are Intell., vol. 19, no. 1, pp. 17–37, 1982.
highly modularized and hence its internal structure al-
lows for more advanced reasoning. Modularisation in [5] Daniel P. Miranker, “TREAT: A Better Match
XTT is not partial as in CLIPS. XTT tables are not only Algorithm for AI Production Systems; Long Ver-
a mechanism for managing large knowledge bases, but sion,” Tech. Rep. 87-58, University of Texas, July
they also allow for context reasoning, due to the fact 1987.
that each XTT table groups rules that belongs to the [6] Eric N. Hanson and Mohammed S. Hasan, “Gator:
same context (have similar LHS and RHS). Moreover, An Optimized Discrimination Network for Active
rules in XTT2 are based on attributive logic which al- Database Rule Condition Testing,” Tech. Rep. 93-
lows for formal verification of knowledge base. Table 1 036, CIS Department University of Florida, De-
contains the comparison of the expert system shells de- cember 1993.
scribed in this paper and XTT2 approach.
[7] Grzegorz J. Nalepa and Antoni Lig˛eza, “HeKatE
methodology, hybrid engineering of intelligent
Table 1. Comparison of expert system shells systems,” International Journal of Applied Mathe-
matics and Computer Science, 2010, accepted for
Feature XTT CLIPS Jess Drools
publication.
Knowledge modulari- Yes Yes Partial Yes
sation [8] Grzegorz J. Nalepa, Antoni Lig˛eza, Krzysztof Kac-
Knowledge visualisa- Yes No No Yes
tion
zor, and Weronika T. Furmańska, “HeKatE rule
Formal rules repre- Yes No No No runtime and design framework,” in Proceedings
sentation of the 3rd East European Workshop on Rule-Based
Knowledge base veri- Yes No No No Applications (RuleApps 2009) Cottbus, Germany,
fication
September 21, 2009, Gerd Wagner Adrian Giurca,
Inferences strategies DDI, DDI DDI, DDI
GDI, GDI, Grzegorz J. Nalepa, Ed., Cottbus, Germany, 2009,
TDI, FOI pp. 21–30.
Inference algorithm HeaRT + Rete Rete Rete
Unification [9] G. J. Nalepa, S. Bobek, M. Gaw˛edzki, and
Allows for modelling No No No Yes A. Lig˛eza, “HeaRT Hybrid XTT2 rule engine
dynamic processes design and implementation,” Tech. Rep. CSLTR
4/2009, AGH University of Science and Technol-
ogy, 2009.
The idea of integrating XTT2 approach with Drools-