Grzegorz J. Nalepa and Joachim Baumeister
AGH University of Science and Technology
Krakw, Poland gjn@agh.edu.pl denkbares GmbH Friedrich-Bergius-Ring 15, 97076 Wrzburg, Germany
joachim.baumeister@denkbares.com
Research questions and practical exchange between Knowledge Engineering for intelligent systems and Software Engineering of advanced software programs have been fruitfully discussed over the last years. Many successful examples demonstrate the clear symbiosis between these two research areas.
In 2005 the KESE workshops took place for the rst time in Koblenz at the 28th German Conference on Articial Intelligence (KI-2005). Nine years later the KESE9 workshops return to Koblenz, where it is collocated with the 36th Annual Conference on Articial Intelligence in Koblenz (September 16-20, 2013). This year we solicited contributions having the following topics: Knowledge and software engineering for the Semantic Web Ontologies in practical knowledge and software engineering Business Rules design, management and analysis Business Processes modeling in KE and SE Practical knowledge representation and discovery techniques in software engineering Agent-oriented software engineering Context and explanation in intelligent systems Knowledge base management in KE systems Evaluation and verication of KBS Practical tools for KBS engineering Process models in KE applications Software requirements and design for KBS applications Declarative, logic-based, including constraint programming approaches in SE As from the beginning the workshop series shows a healthy mixture of advanced research papers showing the direction to the next years and practical papers demonstrating the actual applicability of approaches in (industrial) projects and concrete systems. This year ve regular, and two short papers were accepted to the workshop. Moreover, one tool presentation was also included.
In their paper "Integrating Semantic Knowledge in Data Stream Processing" the authors Beckstein et al. describe dierent approaches on integrating stream data and semantic domain knowledge. In particular, as accessing methods the continuous query language CQL is compared with the SPARQL extension CSPARQL.
Kramer et al. describe new possibilities for explanation generation. Their paper "Towards Explanation Generation using Feature Models in Software Product Lines" investigate how the approach can be applied in dynamic software product lines (DSPL).
In the paper "A Prolog Framework for Integrating Business Rules into Java Applications" the authors Ostermayer and Seipel show an approach to connect the data structures of the logic-based language Prolog with the wide-spread programing language Java.
Baumeister et al. report in their paper "Continuous Knowledge Representations in Episodic and Collaborative Decision Making" on a new type of decision support systems and demonstrate its application in an industrial case study for managing the knowledge about chemical substances.
Pascalau introduces guidelines for designing and engineering advanced software systems to be used by end-users. The paper "Identifying Guidelines for Designing and Engineering Human-Centered Context-Aware Systems" proposes a declarative level to hide the technical level of systems engineering from the end-users.
Kluza et al. tackle business process modeling and give an overview of recommendation possibilities. Their paper "Overview of Recommendation Techniques in Business Process Modeling" describes a categorization of recommendation approaches.
Newo and Altho report in their paper "Knowledge Acquisition for Life Counseling" on a concrete project that uses case-based techniques and information extraction methods in the life counseling domain.
Kaczor et al. give a tool presentation and show in "HaDEsclipse - Integrated Environment for Rules" an environment for engineering rule-based systems. The tool is based in the well-established software tool Eclipse.
The organizers would like to thank all who contributed to the success of the workshop. We thank all authors for submitting papers to the workshop, and we thank the members of the program committee as well as the external reviewers for reviewing and collaboratively discussing the submissions. For the submission and reviewing process we used the EasyChair system, for which the organizers would like to thank Andrei Voronkov, the developer of the system. Last but not least, we would like to thank the organizers of the KI 2013 conference for hosting the KESE9 workshop.
The 9th Workshop on Knowledge Engineering and Software Engineering (KESE9) was held as a one-day event at the 36th German Conference on Articial Intelligence
(KI2013) on September 17 2013, in Koblenz, Germany
Joachim Baumeister, denkbares GmbH, Germany Grzegorz J. Nalepa, AGH UST, Krakw, Poland
HaDEsclipse - Integrated Environment for Rules (Tool Presentation) : : : : Krzysztof Kaczor, Grzegorz J. Nalepa and Krzysztof Kutt 1 13 24 36 46 70 77 Integrating Semantic Knowledge in
Data Stream Processing Simon Beckstein, Ralf Bruns, Jurgen Dunkel, Leonard Renners University of Applied Sciences and Arts Hannover, Germany
Email: forname.surname@hs-hannover.de Abstract. Complex Event Processing (CEP) has been established as a well-suited software technology for processing high-frequent data streams. However, intelligent stream based systems must integrate stream data with semantical background knowledge. In this work, we investigate di erent approaches on integrating stream data and semantic domain knowledge. In particular, we discuss from a software engineering perspective two di erent architectures: an approach adding an ontology access mechanism to a common Continuous Query Language (CQL) is compared with C-SPARQL, a streaming extension of the RDF query language SPARQL. 1
Nowadays, much information is provided in form of data streams: sensors, software components and other sources are continuously producing ne-grained data that can be considered as streams of data. Examples of application elds exploiting data streams are tra c management, smart buildings, health monitoring, or nancial trading. Intelligent decision support systems analyze stream data in real-time to diagnose the actual state of a system allowing adequate reactions on critical situations.
In recent years, Complex Event Processing (CEP) [
However, for understanding the business meaning of stream data, the data items must be enriched with semantical background knowledge. For instance in tra c management, velocity measures must be related to speci c knowledge about the road network (e.g. road topology and speed limits). In contrast to data streams, this background or domain knowledge is usually rather static and stable, i.e. without frequent changes.
Ontologies de ned by Description Logic (DL) [
Note that SPARQL was originally developed to process static data and is therefore not suitable for the processing of data streams. Otherwise, conventional CEP languages provide no inherent concepts for accessing ontological knowledge.
In this work, we will investigate di erent approaches on how to integrate data stream processing and background knowledge bases. In particular, we will discuss two di erent aspects from a software engineering perspective: { How can CQL languages provided by standard CEP systems make use of ontology models? { How useful are recently proposed streaming extensions of SPARQL such as C-SPARQL?
The remainder of the paper is organized as follows. The next section discusses related work and other research approaches. Subsequently, section 3 introduces brie y CEP. Then, section 4 discusses the di erent types of information that can be exploited in stream based systems. The following sections 5 and 6 describe and compare two di erent approaches of integrating background knowledge into stream processing: The rst approach adds an ontology access mechanism to a common CQL-based architecture. The second one uses C-SPARQL, a streaming extension of SPARQL. The nal section 7 provides some concluding remarks and proposes an outlook for further lines on research. 2
In practice, nearly all stream processing systems are using a proprietary Continuous Query Language (CQL). At present, many mature implementations of event processing engines already exist. Some well-known representatives are ESPER2, JBoss Drools Fusion3 or Oracle CEP4. As already discussed, none of these engines neither target nor support a built-in way to integrate semantic background knowledge.
Another class of approaches target the integration of RDF ontologies with
stream processing. Di erent SPARQL enhancements have been developed in
order to query continuous RDF streams. Basically, they all extend SPARQL by
sliding windows for RDF stream processing:
{ C-SPARQL provides an execution framework using existing data
management systems and triple stores. Rules distinguish a dynamic and a static part,
which are evaluated by a CQL and a SPARQL engine, respectively [
Beside SPARQL extensions, various proprietary CEP languages have been proposed for integrating stream processing and ontological knowledge: For instance, Teymourian et. al. present ideas on integrating background knowledge for their existing rule language Prova5 (with a corresponding event processing engine) [13, 14].
In summary, many proposals for SPARQL dialects or even new languages have been published, but so far not many results of practical experiments have been proposed.
This paper examines two di erent approaches for integrating RDF and stream data from a software engineering perspective. First, we extend the well-known CQL of ESPER with mechanisms for accessing RDF ontologies. Then, this approach is compared with C-SPARQL, one of the SPARQL extensions that integrates SPARQL queries and stream processing. 3
Complex Event Processing (CEP) is a software architectural approach for
processing continuous streams of high volumes of events in real-time [
A pattern match signi es a meaningful state of the environment and causes either creating a new complex event or triggering an appropriate action.
Fundamental concepts of CEP are an event processing language (EPL), to express event processing rules consisting of event patterns and actions, as well as an event processing engine that continuously analyses event streams and executes the matching rules. Complex event processing and event-driven systems generally have the following basic characteristics: 5 https://prova.ws/ { Continuous in-memory processing : CEP is designed to handle a consecutive input stream of events and in-memory processing enables real-time operations. { Correlating Data: It enables the combination of di erent event types from heterogenous sources. Event processing rules transform ne-grained simple events into complex (business) events that represent a signi cant meaning for the application domain. { Temporal Operators : Within event stream processing, timer functionalities as well as sliding time windows can be used to de ne event patterns representing temporal relationships. 4
In most application domains, di erent kinds of knowledge and information can be distinguished. In the following, the di erent types of knowledge are introduced by means of a smart building scenario:6 An energy management system that uses simple sensors and exploits the background knowledge about the building, environment and sensor placement.
The main concepts used in the knowledge base are rooms and equipment, such as doors and windows of the rooms. Rooms and equipment can be attached with certain sensors measuring the temperature, motion in a room or the state of a door or a window, respectively. By making use of this background information, the raw sensor data can be enriched and interpreted in a meaningful manner. For instance, room occupancies due to rescheduled lectures or ad-hoc meetings can be identi ed for achieving a situation-aware energy management. In this sample scenario, we can identify three types of knowledge classi ed according to their di erent change frequencies: 1. Static knowledge: We de ne static knowledge as the knowledge about the static characteristics of a domain, that almost never or very infrequently changes. A typical example in our scenario is the structure of a building and the sensor installation.
Static knowledge can be modeled by common knowledge representation formalisms such as ontologies. Because this information does usually not change, appropriate reasoners can derive implicit knowledge before the start of the stream processing. OWL can serve as a suitable knowledge representation language that is supported by various reasoners, for example KAON27 or FaCT++8. 2. Semi-dynamic knowledge: We consider semi-dynamic knowledge as the knowledge about the expected dynamic behavior of a system. It can be represented by static knowledge models, e.g. ontologies, as well. In our scenario, a class schedule predicts the dynamic behavior of the building: though the 6 More details about the smart building scenario can be found in [12]. 7 http://kaon2.semanticweb.org/ 8 http://owl.man.ac.uk/factplusplus/ class schedule can be de ned by static data (e.g facts in an ontology), it causes dynamic events, e.g. each monday at 8:00 a 'lecture start' event. Of course, real-time data produced by sensor could outperform the predicted behavior, e.g. if a reserved class room is not used. 3. High-dynamic knowledge: The third type of knowledge is caused by unforseeable incidents in the real world. It expresses the current state of the real world and cannot be represented by a static ontology. Instead the current state has to be derived from continuous stream of incoming data. This type of knowledge can be described by an event model specifying the types of valid events.9 Examples in our scenario are sensor events representing observations in the physical world, e.g. motion, temperature, or the state of a window or door, respectively.
The three knowledge types introduced above provide only a basic classi cation scheme. As already discussed in the introduction (section 1), various types of information must be integrated and correlated in order to derive complex events that provide insight to the current state of a system. 5
Using Semantic Knowledge in Event Processing In this section, we will investigate how the di erent types of knowledge introduced above can be integrated in stream processing { in particular, how ontological knowledge can be exploited in stream processing.
We start our discussion with a small part of an ontology for our energy management scenario (see Figure 1). This sample ontology is used in the following paragraphs for discussing the di erent knowledge integration approaches. The model de nes the three concepts 'room', 'sensor' and 'equipment' and their relationships. It shows that each room can contain sensors and equipment. Furthermore, it speci es that a certain sensor is either directly located in a certain room or attached to an equipment located in a room.
Note that the location of a sensor can be inferred from the location of the equipment it is attached to. The dashed line describes this implicit property, which can be expressed as role composition in Description Logic: isAttacedT o ○ IsEquippedIn ⊑ hasLocation: A DL role composition can be considered as a rule: If a sensor is attached to an equipment and the equipment is equipped in a certain room, then the sensor is assumed to be located in the same room.
Listing 1.1 de nes two individuals (Window362 and an attached contact sensor C362W ) using the RDF turtle notation10 . Using the above presented DL rule, it can be inferred that the contact sensor is located in room 362 and the triple (:C362W :hasLocation :Room362) can be added to the knowledge base.
In the same way, further role and concept characteristics of the ontology can be used for reasoning purposes. 9 Note that such an event model can also be formally de ned by an OWL ontology. 10 http://www.w3.org/TR/turtle/ As a rst approach of integrating stream data and background knowledge we have chosen the established event processing engine ESPER. Since it is a regular CQL based engine it does not natively support the access of additional knowledge bases. Figure 2 depicts the conceptional architecture of the approach. Di erent event sources send streams of events via message channels to the ESPER CEP engine. The event sources provide all events in a format that is processable by ESPER, for instance simple Java objects (POJOS). The cycle within the engine should denote that the events are processed in several stages. Each stage transforms relatively simple incoming events into more complex and meaningful events.
Knowledge Access: As already mentioned, ESPER does not inherently support a speci c access to a knowledge base such as an OWL ontology, but it provides a very general extension mechanism that allows invoking static Java methods within an ESPER rule. Such methods can be used for querying a Java domain model, a database or any other data source. To make our OWL domain
Fig. 2. Architecture using ESPER as CEP component model accessible from ESPER rules, we implemented an adapter class that uses the Jena Framework11 to query the ontology via SPARQL.
Events: Because ESPER can only process Java objects, the adapter has to map RDF triples to Java objects. For instance, the mapping transforms an RDF-URI identifying a sensor to an ID in the Java object. Each Java class corresponds with a certain concept of the ontology TBox.
Queries: ESPER provides its own event processing language that is called ESPER Event Query Language (EQL). EQL extends SQL with temporal operators and sliding windows. A simple example is given in Listing 1.2 that shows how motion in a certain room is detected by an ESPER query.
SELECT room FROM pattern [ every mse = MotionSensorEvent ], method : Adapter . getObject ( mse . sensorID ) AS room
Listing 1.2. A sample ESPER query
Actions triggered by a pattern match are implemented in a listener class that must be registered for an ESPER rule. A listener can call any event handling Java method or create a new complex event. The example rule looks rather simple, because the access to the knowledge base is hidden behind the method call (here: Adapter.getObject(mse.sensorID)). In our case, the adapter executes a SPARQL query using the Jena framework as shown in Listing 1.3. 11 http://jena.apache.org PREFIX : < http :// eda . inform .fh - hannover . de / sesame . owl > PREFIX rdf : < http :// www . w3 . org /1999/02⤦
Ç/22 - rdf - syntax - ns #> SELECT ? room ? object WHERE { :"+ sensorID +" : isAttachedTo ? object ;
: hasLocation ? room . Listing 1.3. SPARQL query in the Jena-Adapter method Adapter.getObject(sensorID) 5.2
C-SPARQL
As an alternative approach, we investigate a software architecture using
CSPARQL12, a streaming extension of SPARQL. Figure 3 illustrates the main
building blocks of the architecture. The main di erence to the previous approach
is, that all event sources produce a continuous stream of RDF data. This means
that the entire knowledge base of the system uses RDF as uniform description
formalism.
Knowledge access: In this approach, C-SPARQL queries are used for accessing
the homogeneous RDF knowledge base. A single C-SPARQL query can combine
incoming RDF streams with static background knowledge (also represented in
RDF).
12 We used the 'ReadyToGoPack', an experimental implementation of the concept in
[
(⟨subji; predi; obji⟩; ti) The subject is a unique event identi er, the predicate and object describe event properties. The timestamp is added by the engine and describes the point of time the event arrived. Listing 1.4 shows a set of RDF triples describing a simpli ed temperature sensor event. : event123 rdf : type
ÇTemperatureSensorEvent : event123 : hasSensorId : event123 : hasValue :3432 24.7^^ xsd : double
:⤦
Listing 1.4. A sample temperature event Queries: C-SPARQL queries are syntactically similar to SPARQL. Listing 1.5 shows a C-SPARQL query expressing the same pattern as the ESPER query in Listing 1.2. In contrast to SPARQL, it provides language extensions for temporal language constructs like (sliding) time and batch windows as shown at the end of the FROM STREAM-clause. The FROM-clause selects the various data streams SELECT ? room FROM STREAM < http :// eda . inform .fh - hannover . de /⤦ ÇMotionSensorEvent . trdf >⤦ Ç[ RANGE 10 s STEP 1s] FROM < http :// eda . inform .fh - hannover . de⤦
Ç/ sesame . owl > WHERE { ? mEvent rdf : type : MotionSensorEvent ;
: hasSensorID ? sid .
? sid : hasLocation ? room . }
Listing 1.5. A sample C-SPARQL query that are processed in the query. Each C-SPARQL query can either generate new triples that can be processed by another query or call a (Java) listener class to trigger an action.
An interesting point to mention is that the C-SPARQL engine internally transforms the query into a dynamic part dealing with the event stream processing and a static part accessing the background knowledge. These parts are each individually executed by a suitable engine or query processor. This behavior is transparent for the user as the entire rule is written in C-SPARQL and the rule result contains the combined execution outcome. 6
In this section, we will investigate the capabilities of two introduced approaches of integrating stream processing and background knowledge. Based on our practical experiences, we discuss the two architectures from a software engineering perspective. Table 1 summarizes the results of the comparison. The criteria will be discussed in more details in the following paragraphs. Maturity: ESPER is a widely used event processing engine, which is under development by an active open source community for many years and, consequently, has reached a stable and market-ready state. It provides a comprehensive documentation and several guides, as well as tutorials. In contrast, CSPARQL, and the ready-to-go-pack in particular, is a conceptual prototype. This means that the implementation is not as mature and, furthermore, it is not as good documented as ESPER. So far, there are no published experiences about real-world projects using C-SPARQL.
Event Pattern Expressiveness: According to its maturity, ESPER provides a rich set of operators for specifying event patterns, e.g. for de ning di erent types of sliding windows or various even aggregations operators. The event algebra of C-SPARQL is less expressive compared to ESPER, but, nevertheless, it supports all important features for general event processing tasks.
Conceptual Coherence: C-SPARQL allows the processing of stream data and the integration of static background knowledge by using only one paradigm (or language). Listing 1.5 shows a C-SPARQL query that combines event stream processing and SPARQL queries. In this sense, a C-SPARQL query is self-contained and coherent: only C-SPARQL skills are necessary for understanding it.
In contrast, ESPER does not support inherent access to knowledge bases. Consequently, specialized Java/Jena code must be written to integrate background data. The ESPER-based architecture combines the ESPER query language (EQL) for stream processing and Jena/SPARQL code implemented in a Java adapter class to query knowledge bases. The ESPER rules are not selfcontained and delegate program logic to the adapter classes. Note that this can also be viewed as an advantage: hiding a (perhaps) big part of the logic in method calls results in simpler and easier understandable rules.
Dynamic Rules: Changing a rule at runtime is di cult in ESPER, because modifying an ESPER rule can cause a change of the EQL pattern and of the SPARQL query in the listener class of the corresponding rule. In this case, the code must be recompiled. C-SPARQL makes changes much easier, because only the C-SPARQL query must be adjusted. Such queries are usually stored as strings in a separate le, which can be reloaded at runtime - even for rules including completely new queries of the knowledge base.
Heterogeneous knowledge sources: C-SPARQL is limited to ontological background knowledge stored in RDF format. In contrast, ESPER can be extended by arbitrary adapters allowing the usage of di erent knowledge sources. For instance, beside RDF triple stores also relational databases or NoSQL data sources can be used. However, the access methods have to be implemented and maintained by hand, as mentioned in the previous paragraph.
Stream Reasoning Support: Both approaches do not support stream reasoning, i.e. implicit knowledge is not automatically deduced when new events arrive. Conventional reasoners can only deal with static data, but not with highfrequent RDF streams. But, because (static) background knowledge changes infrequently, a conventional reasoning step can be processed, if a new fact in the static knowledge base appears.
Considering the two approaches from a conceptional point of view, C-SPARQL
is better suited for inherent reasoning. For instance, SPARQL with RDFS
entailment can be achieved by using materialization or query rewriting [
In this paper, we have discussed two di erent architectural approaches of integrating event stream processing and background knowledge.
The rst architecture uses a CQL processing engine such as ESPER with an adapter class that performs SPARQL queries on a knowledge base. In this approach stream processing and knowledge engineering is conceptually and physically separated.
The second architecture is based on an extension of SPARQL to process RDF data streams. C-SPARQL allows integrated rules that process stream data and query RDF triple stores containing static background knowledge. Thus, C-SPARQL provides a more homogeneous approach, where query logic, event patterns and knowledge base access are combined in one rule and is, therefore, superior from a conceptional point of view.
Otherwise, CQL engines are well-established in real-world projects and at this time, they o er higher maturity and better performance. Therefore, CQL-based systems are (still) superior from a practical point of view.
Generally, the integration of semantic reasoning into stream processing is still
an open issue that is not fully supported by any approach yet. Stream reasoning
is therefore an important and promising research eld to put e ort in and has
several work in progress, for example the appproaches in [
This work was supported in part by the European Community (Europaischer Fonds fur regionale Entwicklung) under Research Grant EFRE Nr.W2-80115112. Towards Explanation Generation using Feature
Models in Software Product Lines Dean Kramer, Christian Sauer, and Thomas Roth-Berghofer School of Computing and Technology, University of West London,
St Mary's Road, London W5 5RF, United Kingdom
{first.lastname}@uwl.ac.uk Abstract. Dynamic Software Product Line (DSPL) Engineering has gained interest through its promise of being able to unify software adaptation whereby software can be con gured at compile time and runtime. Just like conventional adaptive software, software dynamism can confuse the user, and lower user trust. Variability knowledge expressed in a feature model though may not be understandable to the end user. Explanations have been shown to improve intelligibility of the software, and improve user trust. In this work, we consider how explanations can be used in DSPLs, by adding explanatory knowledge to feature models that can be used to generate explanations at runtime. 1
Introduction Smart phones in recent years have seen high proliferation, allowing more users to stay productive while away from the desktop. It has become common for these devices to have an array of sensors including GPS, accelerometers, digital compass, proximity sensors, sound etc. Using these sensors with other equipment already found in phones, a wide set of contextual information can be acquired.
This contextual information can be used in Context-Aware Self Adaptive
(CASA) software. This software can monitor di erent contextual parameters
and dynamically adapt at runtime to satisfy the user's current needs [
Dynamic Software Product Lines (DSPL) enables the SPL to be recon
gurable at runtime [
Feature Modelling has become the de facto method of variability representation, used in software product lines. In feature models, the adaptation of the product, be it static, or dynamic, are modelled, enabling a wide variety of products and product behaviours. While feature modelling is of great use in the development, the dynamics within feature modelling can be confusing to endusers. To amend the seemingly unpredictable and thus confusing nature of the behaviour of a dynamic system and the results it produces, it is desirable to enable the system to explain its behaviour as well as the results it produces to the end-user. As we will detail further on in this paper explanations are very useful to justify results a system produces and thus help to rebuild the trust an end-user has in the systems behaviour and results. So explanations are useful to the end-user as they can counter the mentioned non-transparency of DSPL end-products and their dynamic behaviours.
In our previous work [18], on enabling a system we developed to generate explanations, we investigated the integration of explanations into a context acquisition engine, used for developing context-aware applications. We did this with regard to mobile applications were one has to adhere to many constraints. We developed a ContextEngine to easier deal with such limitations and situation-speci c information across applications [12], thus easing the creation of context-aware, mobile systems. We noticed that with the increased adaptability and dynamics of context-aware applications came an increase in complexity of the application, which in turn made it harder to understand the behaviour of such applications. In our initial research on this topic we then described how we enhanced the ContextEngine platform with explanation capabilities. As we describe in this paper and as it was proven in a variety of other work on explanations, explaining can be seen as complex reasoning task on its own. In our initial work we focused on the use of canned explanations. Canned explanations are information artefacts, pre-formulated by the software engineer, that serve as explanatory artefacts stored in the system and delivered to the user on demand. We integrated storage facilities for such information artefacts, or explanatory knowledge artefacts within the code structure of the ContextEngine and thus were able to provide these stored canned explanations on demand to a software engineer working with the ContextEngine. After this early steps and relatively simple approach, based also on a further study into the matter of explanation provision in the feature model and especially in the automated analysis feature models (AAFM) domain, we decided to elaborate on our initial work.
The rest of the paper is structured as follows: We introduce the feature modelling background of our work in the following section and based on the technological possibilities described there motivate our approach to use an extended feature model for explanation generation in Section 3. We then interlink our approach with related work on feature modelling, explanation generation and the use of explanations itself in the following section. We then introduce our approach to explanation generation from explanatory knowledge stored in an the term notation offers a convenient access to objects and subobjects in PROLOG; more than one component can be accessed in a single line. Usually, If–Then–Else statements with many alternatives are hard to review in JAVA, but much easier to write and read in PROLOG. Due to the rules approach, multiple results are inferred implicitly; in a DATALOG style evaluation, there is no need to explicitly encode a loop. In a PROLOG style evaluation, all results can be derived using the meta–predicate findall/3.
Using the PROLOG package DATALOG [14] from the DISLOG Developers’ Kit
(DDK), we can, e.g., support the development phase in PROLOG by visualizing the rule
execution with proof trees [
The main predicate in the business rule base computes the financial key data for a single order. The facts of the input knowledge base will be provided by the JAVA application, as we will see later. Derived financial_key_data/2 facts are collected in a PROLOG list, which will be presented as a result set to JAVA.
Listing 1.3: Business Rules for Financial Key Data financial_key_data(Order, Profits) :order_to_charges(Order, Charges), Order = order(article(_, _, prices(Base, Market)), _, _), Charges = charges(Shipping, Netto, Fees).
Gross_Profit is Netto - Base, C_Margin is Gross_Profit - Fees - Shipping, Profit_Ratio is C_Margin / Market,
Profits = profits(Gross_Profit, C_Margin, Profit_Ratio). order_to_charges(Order, Charges) :
Order = order(Article, Country, Logistician), Article = article(_, Category, prices(_, Market)), call(Order), tax(Country, Tax_Rate), shipping_charges(Country, Logistician, Charges), Shipping is Charges / (1 + Tax_Rate), Netto is Market / (1 + Tax_Rate), platform_charges(Category, Commission, Discount), Fees is Market * Commission * (1 - Discount), Charges = charges(Shipping, Netto, Fees).
The predicate order_to_charges/4 first computes the charges for the shipment, then an article’s netto price using the tax rate of the country of dispatch, and finally the fees for selling an article on the online platform in a given category. We use the PROLOG terms Order, Profits, and Charges to keep the argument lists of the rule heads short. E.g., order_to_charges/4 extracts the components of Order in line 2 and calls the term Order in line 4. Thus, we can avoid writing the term Order repeatedly – in the head and in the call. In the code, we can see nicely, which components of Order are used in which rule, since the other components are labeled by underscore variables.
4 2.3
Constraints in PROLOG In knowledge bases, facts often reference each other. E.g., in our business rules application, we have the following foreign key constraints: for every order/3 fact, there must exist corresponding facts for tax/2 and shipping_charges/4, whose attribute values for Country match the attribute value for Country in order/3. The same holds for category in platform_charges/3 and category in order/3. Another frequently occuring type of constraints are restrictions on argument values; e.g., the values for Country could be limited to countries of the European Union.
This meta information between facts in a knowledge base usually remains hidden; the developer of the rule set knows these constraints, and only sometimes they are easy to identify within the set of business rules. For validation purposes of knowledge bases, however, this information is crucial, in particular when a knowledge base for a request is arranged by a programmer other than the creator of the set of rules.
Constraints, such as the foreign key constraints from above, can simply be specified and tested in PROLOG. The execution of the PROLOG predicate constraint/1 is controlled using meta–predicates for exception handling from SWI PROLOG. With print_message/2, a meaningsful error message can be generated, and exceptions can be caught with catch/3. In Listing 1.4, the foreign key constraints on Country and Category are checked.
We can also represent standard relational constraints in XML. XML representations
for create table statements have been developed and used in [
Listing 1.4: Foreign Key Constraints constraint(fk(shipping_charges)) :forall( shipping_charges(Country, _, _),
tax(Country, _) ). constraint(fk(article_charges)) :forall( article(_, Category, _),
platform_charges(Category, _, _) ). 3
Integration of PROLOG Business Rules into JAVA The workflow of PBR4J follows three steps, cf. Figure 1. First, PBR4J extracts an XML Schema description for the knowledge base and the result set of a given set of PROLOG rules. Then, the user must extend the extracted XML Schema by names for atomic arguments, numbers and strings from PROLOG and review the type description. Finally, PBR4J uses the XML Schema to generate JAVA classes and packs the generated classes into a JAVA Archieve (JAR). After embedding the JAR into the JAVA application, the set of PROLOG rules can be called from JAVA. The facts derived in PROLOG are sent back to JAVA, where they are parsed; then, they can be accessed by the generated classes. 5
Fig. 1: Workflow of PBR4J
In the following, we describe the transformation of the knowledge base to an XML representation, from which we subsequently extract the XML Schema. Then we show that the JAVA classes generated from the XML Schema reflect the complex structured knowledge base in an object–oriented way. The result set is handled in a similar manner; thus, we describe only the transformation of the knowledge base and omit further processing details for the result set. 3.1 An XML Schema for the Knowledge Base XML is a well–known standard for representing and exchanging complex structured data. It allows for representing PROLOG terms and improves the interoperability between PROLOG and JAVA programs, since XML is easy to read. We extract an XML Schema from the XML representation of the knowledge base, and we generate JAVA classes from the extracted XML Schema.
We use the predicate prolog_term_to_xml(+Term, -Xml) for the transformation of a PROLOG term to XML. Listing 1.5 shows the XML representation for the PROLOG term with the predicate symbol order/3. Notice the XML attribute type and the names of elements representing arguments of complex terms on the PROLOG side.
Listing 1.5: An Order in XML Format <order type="class"> <country type="string">Germany</country> <logistician type="string">Fast Logistics</logistician> <article type="class"> <ean type="integer">98765</ean> <category type="string">Books</category> <prices type="class"> <base type="decimal">29.00</base> <market type="decimal">59.99</market> </prices> </article> </order> 6
These are necessary, because JAVA is a typed language, whereas PROLOG builds data structures from a few basic data types. The representation for class attributes in JAVA is a typed Name="Value" pair. In order to map the knowledge base from PROLOG to JAVA, we must give names to arguments of PROLOG facts, if they are atomic, numbers, or strings, and we must add a type information. The functor of a complex PROLOG term is mapped to the tag of an element with type="class". The structure of the XML representation easily can be generated from the PROLOG term structure, and some of the type information can be inferred automatically from the basic PROLOG data types. But, type preferences and meaningful names for atoms, numbers, and strings must be inserted manually.
From the XML representation of the knowledge base and the result set, we can extract a describing XML Schema using PROLOG. The XML Schema is a natural way to describe and to define the complex data structure. Known techniques are available for validating the XML representation of the knowledge base w.r.t. the XML Schema. Listing 1.6 shows the description of an order/3 term in XML Schema. The XML Schema of the knowledge base can contain further information in attributes like minOccurs and maxOccurs.
Listing 1.6: Fragment of the XML Schema describing order/3 <xsd:element name="order" type="order_Type"
minOccurs="1" maxOccurs="unbounded" /> <xsd:complexType name="order_Type"> <xsd:sequence> <xsd:element name="article" type="article_Type" /> <xsd:element name="country" type="xsd:string" /> <xsd:element name="logistician" type="xsd:string" /> </xsd:sequence> </xsd:complexType> 3.2
Scaffolding of JAVA Code From the XML Schema, we generate JAVA classes using the PROLOG–based XML transformation language FNTRANSFORM [13]. FNTRANSFORM offers recursive transformations of XML elements using a rule formalism similar to – but more powerful than – XSLT. Every xsd:element in the schema with a complex type will be mapped to a JAVA class. Child elements with simple content are mapped to attributes. Figure 2 shows a fragment of the UML diagram for the generated classes.
Fig. 2: Generated Classes
All classes associated with the class KnowledgeBase implement the methods check and toPrologString. An example of the method toPrologString of the generated class Order is shown in Listing 1.7. A recursive call of check controls that all necessary input data are set before the method toPrologString is called to build a knowledge base in a string format, which can be parsed easily by PROLOG using the predicate string_to_atom/2. The transformation to a PROLOG term can be achieved by atom_to_term/3.
Parts of the generated class RuleSet are shown in Listing 1.8. The method query sends a PROLOG goal together with a knowledge base in string format from JAVA to PROLOG. As a default interface between JAVA and PROLOG, we have implemented a simple connection with a communication layer based on standard TCP/IP sockets. Other interfaces can be implemented and set as the value for the attribute prologInterface of the class RuleSet. The default interface is represented by the class PrologInterface, which is fix and not generated every time a set of PROLOG rules 8 is integrated into a given JAVA application via PBR4J. The class PrologInterface must be integrated into the JAVA application once, and it must be accessible for all generated classes of the type RuleSet.
Listing 1.7: toPrologString in Order public String toPrologString() { this.check(); StringBuilder sb = new StringBuilder(); sb.append( "order" + "(" + this.article.toPrologString() + ", " "’" + this.getCountry() + "’" + ", " "’" + this.getLogistician() + "’" + ")" ); return sb.toString(); }
The result set that is sent back from PROLOG to JAVA is parsed by the method parseResult of the class RuleSet. As for the class PrologInterface, the class PrologParser is not generated and must be integrated into the JAVA application once and be accessible for all generated classes of the type RuleSet. The method parseProlog of PrologParser saves the content of the string returned from PROLOG in a structured way to a hashmap. The hashmap than can be further processed efficiently by the method readData that all classes associated with the class ResultSet must implement. The method readData analyses the hashmap and fills the data list of the class ResultSet.
Listing 1.8: The Class RuleSet package pbr4j.financial_key_data;
All generated classes are organised in a namespace via a JAVA package. The package
access protection ensures that the class RuleSet can only contain a
KnowledgeBase from the same package. The package can be stored in a JAVA Archive (JAR) – a
compressed file that can not be changed manually. This creates an intentional generation
gap, cf. Fowler [
Listing 1.9: A JAVA Call to the Business Rules import pbr4j.financial_key_data.*; public class TestCall { public static void main(String[] args) {
RuleSet rules = new RuleSet(); KnowledgeBase kb = new KnowledgeBase(); // ... filling the knowledge base with data ... rules.query(kb); ListIterator<Object> it =
rules.getResultSet().listIterator(); while (it.hasNext()) {
System.out.println(it.next().toPrologString() + "."); } } }
It is not visible in JAVA that a request is made to a rule set written in PROLOG. Running the JAVA code from above creates the system output shown in Listing 1.10; we have added some newlines to improve readability. The first fact is derived from the data described in Subsection 2.1. The second fact is derived from another order of the same article, that is shipped to France. Charges for the shipment to a foreign country are higher, and the tax rate of France is 0.196, which explains the slightly lower argument values of profits/3.
Listing 1.10: order Result Set financial_key_data( order( article(’98765’, ’Books’, prices(29.00, 59.99)), ’Germany’, ’Fast Logistics’ ), profits(21.41, 11.70, 0.195) ). order( article(’98765’, ’Books’, prices(29.00, 59.99)), ’France’, ’Fast Logistics’ ), profits(21.16, 7.70, 0.128) ). 5
Conclusions We have presented a largely automatic approach for integrating a set of PROLOG rules seamlessly into JAVA applications. XML Schema is used for specifying the XML format for exchanging a knowledge base and a result set, respectively, between PROLOG and JAVA.
On the PROLOG side, we use a generic mapping from the PROLOG representation of the knowledge base and the result set to an XML representation enriched by data type information and names for atoms or numbers, and we extract a describing XML Schema from the XML representation. On the JAVA side, we scaffold JAVA classes from the XML Schema, that reflect the complex structured PROLOG terms in an object–oriented way. Accessing a set of rules from JAVA is simply done by invoking the JAVA methods of the generated classes without programming PROLOG or creating complex query strings.
We have illustrated our approach using a set of business rules that we have already integrated with our framework into a commercial E–Commerce system written in JAVA. Acknowledgement. We acknowledge the support of the Trinodis GmbH.
11 12. L. Ostermayer, D. Seipel. Simplifying the Development of Rules Using Domain Specific Languages in DROOLS. Proc. Intl. Conf. on Applications of Declarative Programming and Knowledge Management (INAP) 2013. 13. D. Seipel. Processing XML–Documents in Prolog. Proc. 17th Workshop on Logic Programming (WLP), 2002. 14. D. Seipel. Practical Applications of Extended Deductive Databases in DATALOG . Proc.
Workshop on Logic Programming (WLP) 2009. 15. D. Seipel. The DISLOG Developers’ Kit (DDK).
http://www1.informatik.uni-wuerzburg.de/database/DisLog/ 16. D. Seipel, A. Boehm, M. Fröhlich: Jsquash: Source Code Analysis of Embedded Database Applications for Determining SQL Statements. Proc. Intl. Conf. on Applications of Declarative Programming and Knowledge Management (INAP) 2009, Springer, LNAI 6547. 17. P. Singleton, F. Dushin, J. Wielemaker: JPL: A Bidirectional Prolog/Java Interface http://www.swi-prolog.org/packages/jpl/, 2004. 18. J. Wielemaker. SWI PROLOG Reference Manual http://www.swi-prolog.org/pldoc/refman/
Regis Newo and Klaus-Dieter Altho German Research Center for Arti cial Intelligence, DFKI GmbH,
Research Group Knowledge Management, Competence Centre Case-Based Reasoning
Email: firstname.surname@dfki.de
Abstract. In this paper, we explain how highly unstructured domain
knowledge can be acquired and integrated in a case-based reasoning
system. We apply our approach to the life counseling domain. We introduce
the two steps of our knowledge acquisition approach in such unstructured
domains. The rst step is manual and relies on domain experts. The
second step is automatic and uses information extraction techniques. Our
approach has the potential to contribute to the formalizing and
establishing of an important subset of life counseling terminology. In addition,
our approach could serve as an example for comparable weak theory
domains.
1
Case-Based Reasoning (CBR) is a methodology for problem solving based on
the fact that previously experienced knowledge can be used to solve new
problems [
Our application SeBaPort (Portal for counseling, in German Seelsorge- und Beratungsportal) deals with life counseling. Life counseling deals with the wellbeing of humans. Life counselors conduct converstions with consulters, give advices and help them to help themselves. Counselors often rely on past expriences for the counseling. The goal of SeBaPort is to help counselors by providing them with counseling cases (depending on their requests), which they can learn from. This makes CBR an ideal methodology to process the knowledge used in that domain.
Life counseling is a domain which is highly unstructured. This makes it very di cult to develop a CBR system for life counseling and be able to provide knowledge in the previously mentioned knowledge containers. For this application domain, we would have to develop an initial set of vocabulary and similarity measures, and also nd a methodology to process the available (unstructured) cases and store them in our case base. SeBaPort does not aim at providing solutions for a given counsel or problem, primarily because the acceptance of the counselors would signi cantly diminish, if we claim to be able to provide complete solutions to counseling problems.
In order to build a life counseling CBR system, we started by developing an initial CBR model and acquiring structured cases. In this paper, we describe in Section 3 how we designed our initial CBR model and our approach for the acquisition of (structured) cases in Section 4. Afterwards we will present some related work in Section 5 and will conclude the paper in Section 6. In the next section, we will rst give an elaborate presentation of the life counseling domain. 2 Life counseling is concerned with the welfare of human beings, more precisely the thinking, feeling, acting, and also the faith of persons. Life counselors help people deal with their problems and con icts. They conduct several counseling interviews with the consulters. The main idea is to help people help themselves by having several discussions with them, give them multiple views on their problem and give them basic hints. Life counselors for example give exercises, which are part of a counseling method, to consulters after an interview. During the following interviews, they try to nd out, whether it helped the consulter or it should be changed.
In order to do that, counselors themselves mainly rely on their experience in the domain, but also on the methodical knowledge they learned during their formation. They are grouped in small communities to share their experiences. As they do not only build on self-made experiences but also on those from others, they often rely on peer consulting and supervision to critically analyse past cases (and be able to learn from them). Further they contact other colleagues when they need help in an actual or past counseling case. Such help might comprise a whole counseling case or just information about parts or aspects (e.g., the method or exercise that can be used in a given situation) of life counseling. Our goal is to provide a system that can be used to help life counselors in their work. We want to provide a decision support system that helps the counselors to document and share their experiences. They would also learn new cases from others and be able to nd hints and references (e.g., to counseling methods) while looking for help (when they deal with a given case). The intended functionality of our system is presented in gure 1 on the basis of the CBR cycle.
An example of the description of the patient's problem in a documented case is given below.
Woman, 48 years old, married and 3 children: 12, 15 and 18 years old. She has been working shifts as a full-time midwife for 2 years. She attends counseling because of insomnia due to her often alternating shift work. She has particularly problems with insomnia after night shifts. She
Fig. 1. CBR Cycle in Life Counseling cannot ignore surrounding noises and she cannot completely darken her bedroom. As a consequence of this, she is often tired, is not able to work under pressure and su ers from headaches.
The documentation of the case also contains the documentation of each interview with for example the applied methods, goal validation and solution interventions. 3
Case Model for Life Counseling When developing CBR systems, one of the rst challenges is to ll the knowledge containers. We have to evaluate which kind of knowledge is availaible in order to know which containers can be lled. In life counseling, the knowledge that is easier to acquire is the experirences made by the experts represented as cases. Due to lack of formalization in the domain, we need to nd a way to extract formalized knowledge from the available cases. For that, we want to structure the information contained in cases.
Fig. 2. Structure of a life counseling case Most experts have their own way to write down their cases. Furthermore, the cases do not contain the same kind of information, have di erent levels of detail and elaborateness. It is thus nearly impossible to automatically detect a structure in raw cases.
Our approach to structure the available cases is to get the needed information from the experts. Instead of getting unstructured cases, we want to be able to get semi-structured cases from the experts. For that purpose, we elaborated a structure that should be used by the experts. The used structure has to re ect the way of thinking of life counselors. We thus have to involve experts in order to de ne such a structure.
Table 2 shows the structure for life counseling cases that we developed. It is
based on a preliminary study done with domain experts (i.e. counselors) [
As another example, the CBR has attributes for the number of children as well as the gender and the age of each children. 4
Two-Step Case Acquisition Now that we de ned a case model, the next challenge is to ll our case base with life counseling cases following the model. Unfortunately, counselors do not have a formal manner to document their cases. This leads to unstructured case descriptions. In order to be able to use those cases in our CBR system, we have to nd methods to formalize the existing knowledge (i.e. cases). This is a di cult task because of the diversity of information available in a case, as can be seen in the last section. Our approch for the knowledge acquisition consists of two steps.
The goal of the rst step is to organize the available information. This is a manual step in which the available diversi ed information is mapped to the structure de ned in Section 3. We rely on domain experts to cope with this assignment. In SeBaPort, this step is realized by providing experts with web forms, which can be used to enter the cases. At the end of this step, we have a case description that matches the structure de ned in Table 2.
The second step of the knowledge acquisition is automatic and consists of using
information extraction to obtain structured CBR cases. The complexity of this
step depends on the type of information given by the experts in the rst step.
Some information, like the gender or the nationality of the patients can be
easily matched to a formal case model. Other, like the medication or the children,
need more e ort for the formalization. For example, the way information about
medication is given di ers from one expert to another and can be more or less
expressive. Nevertheless we have to be able to match the natural language
description of the medication information to our formal model which contains the
additional attributes de ned at the end of Section 3. Another example is the
attribute children, for which the same holds. From the given description, we have
to be able to identify, if given, the number of children, the age and/or gender of
each children and so on. In the example given in Section 2, we would identify 3
children and the ages of the children. However, the gender are not documented.
We used information extraction techniques provided by the component ANNIE
of the framework GATE (see [
Another goal we pursue in SeBaPort, is to be able to learn from the acquired
cases in order to formalize the application domain. We thus want to perform a
stepwise knowledge formalization for life counseling. This has to be done from
scratch because the domain, as explained earlier, is highly unstructured. We are
actually trying to gain the formalized knowledge from the acquired cases. The
purpose is to be able to tackle the fact that there are not only several ways
to document a counseling case, but also di erent counseling perspective. The
representatives of each perspective often have problems to deal with case
documentations from other perspectives. A formaliztion like the one we are targeting
would promote the intercommunication between the representatives of the di
ent perspectives.
The idea of using CBR in medical related domains has been explored in the
last couple of years. In [
There have been many other CBR applications in medical domains. Nevertheless,
to our knowledge, SeBaPort is the rst one to deal with life counseling.
As for knowledge formalization, there are also other approaches that deal with
that topic. One of them is the knowledge formalization continuum presented in
[
In [
Conlusion In this paper, we presented the domain of life counseling and how the available knowledge can be used to develop a CBR system (SeBaPort). SeBaPort will help life counselors to extend their knowledge and learn from past cases. We showed how we are actually extracting the knowledge from available cases and we want to use it for the knowledge formalization. We intend to test our knowledge acquisition by evaluating the similarity measures with the acquired cases. The evaluation is still an ongoing work. Furthermore we will develop an approach to incorporate experts' feedback to our formalization process.
(Tool Presentation) ? Krzysztof Kaczor 1, Grzegorz J. Nalepa 1, Krzysztof Kutt1 AGH University of Science and Technology,
Al. Mickiewicza 30, 30-059 Krakw, Poland kk@agh.edu.pl, gjn@agh.edu.pl, kutt@agh.edu.pl Abstract. In the paper a presentation of HaDEsclipse is given. It is an environment for design and implementation of rule-based systems within the Semantic Knowledge Engineering (SKE) approach. It is build with the use of the Eclipse framework, integrating the previously developed components of the HaDEs environment. HaDEsclipse integrates modules for conceptual prototyping of rule bases, and a visual editor for logical design of extended decision tables that group rules working in similar context. It also allows for generating an executable form of the system, that can be later executed by an inference engine. While the SKE is targeted mainly at knowledge engineers, the use of the Eclipse framework makes the development easier for software engineers. 1
Rule-based systems (RBS) play an important role in knowledge engineering and
software engineering, e.g. with the business rules approach [
However, HaDEs turned out to be hard to use for knowledge engineers not
familiar with SKE as well as for software engineers. This gave the motivation to
develop a new front end to HaDEs, based on the popular Eclipse IDE. In this
paper we present this new tool called HaDEsclipse [
Our research concerns the representation and formal verication of RBS. An
important result of our research is the SKE (Semantic Knowledge Engineering ) [
The main features of this methodology are:
1. Visual rule representation . The provided XTT2 [
The SKE approach can be applied to a wide range of intelligent systems. In this
context, two main areas have been identied in the project: control systems, in
the eld of intelligent control, and Business Rules [
The HaDEs framework aims at supporting the SKE approach. In this approach, the application logic is expressed using forward-chaining decision rules. They form an intelligent rule-based controller or simply a business logic core. The logic controller is decomposed into multiple modules represented by decision tables. HaDEs supports a complete hierarchical design process for the creation of knowledge bases. The whole process consists of three stages: conceptual, logical and physical design and is supported by a number of tools providing the visual design and automated implementation 1.
The conceptual design is the rst stage of the process. During this step, the ARD+ (Attribute Relationships Diagrams ) method is used. The principal idea for this stage is to build a graph dening functional dependencies between attributes on which the rules are built. This stage is supported by two visual tools: VARDA (Visual ARD+ Rapid Development Alloy ), and HQEd.
The logical design is the second stage of the process. During this stage, rules
are designed using the visual XTT2 (Extended Tabular Trees version 2 ) [
Having a complete XTT2-based model the physical implementation can
be generated automatically. In this stage, a logical model is transformed into
an algebraic presentation syntax called HMR2 (HeKatE Meta Representation ).
HMR is a textual representation of the XTT2 logic. It is a human readable form,
as opposed to the machine readable HML format. The HMR representation can
be directly executed by the dedicated inference engine tool, called HeaRT3
(HeKatE Run Time ) [
HaDEs proved to be an ecient framework for designing rule bases within the SKE approach. However, its main limitation is that it is a set of loosely connected tools. Moreover, these tools have custom GUIs, which is problematic for engineers not familiar with SKE. This gave motivation for the development of a new platform, providing a more user friendly front end to HaDEs.
A decision was made to use the popular Eclipse IDE, which is a widely used
tool in the software engineering community. Using it a new integrating front
end to HaDEs was developed [
The main functional requirements of HaDEsclipse are aimed at integrating the existing components of HaDEs using Eclipse: 1. ARD+ support: (a) Code editor with syntax highlighting, formatter, content assistant and error checking, (b) Integration with VARDA, (c) Wizard to create new ARD+ les. 2. HML support: (a) Code editor with syntax highlighting and checking, content assistant, (b) Integration with HQEd, (c) Wizard to create new HML les. 3. HMR support: 2 See https://ai.ia.agh.edu.pl/wiki/hekate:hmr . 3 See https://ai.ia.agh.edu.pl/wiki/hekate:heart (a) Code editor with syntax highlighting, code formatter, content assistant and error checking, (b) Integration with HeaRT. 4. Preferences card: (a) Code editors settings, (b) HaDEs environment parameters. 5. Intuitive Eclipse wizards, views and perspective.
The architecture of HaDEsclipse is presented on Fig. 1. It consists of 5 parts: three of them support HaDEs languages and the other two are responsible for view and wizards. Communication with HaDEs environment (VARDA, HQEd, HeaRT) is handled using JHeroic library.
ARD+ Support
HML Support Parser Editor Syntax Coloring Content Assistant Code Formatter Views
HeaRT View HQEd View
HaDEsclipse
JHeroic
HMR Support Wizards
HeaRT
Fig. 1. Architecture of HaDEsclipse
The tool was implemented in Java as a plugin for Eclipse. All of the functional requirements where met. Five modules of HaDEsclipse successfully support the design with SKE. Thanks to HaDEsclipse the models created in the subsequent design phases are easily interchanged between the HaDEs tools. Moreover, the tool allows to run and verify rule models in HeaRT. For the visual design of the XTT2 tables HQEd is used, but les produced with it are exchanged with other tools transparently for the user.
An example session with the tool is presented in Figures 2 and 3. In the rst gure the conceptual design with ARD+ is presented. The conceptual model of the rule base is described using a set of attributes and dependencies between them. The HML le contains prototypes of decision tables holding the conditional and decision attributes. In the second gure the HMR editing process is presented. The plugin supports both syntax highlighting and hinting, as well as a structured XML editor in the case of ARD+. Schemas (headers) of the tables are dened base on the HML description. In given tables rules are dened using the xrule construct.
Fig. 2. HML Editor 4
In the paper the HaDEsclipse tool was presented. It is an integrating front-end
for the HaDEs framework, which supports the knowledge engineering process in
the SKE approach [
Our future works include further integration of HaDEsclipse with other tools
we developed. This includes design tools for business processes, and integration
with business process engines. Finally, recent results include an Eclipse-based
tool for generating test cases for unit testing based on a rule-based specication.
This framework will be integrated with HaDEsclipse, bringing more practical
benets from the area of knowledge engineering to software engineers [
1. von Halle, B.: Business Rules Applied: Building Better Systems Using the Business
Rules Approach. Wiley (2001) 2. Nalepa, G.J.: Semantic Knowledge Engineering. A Rule-Based Approach.
Wydawnictwa AGH, Krakw (2011) 3. Nalepa, G.J., Ligƒza, A., Kaczor, K.: Formalization and modeling of rules using the XTT2 method. International Journal on Articial Intelligence Tools 20(6) (2011) 11071125 4. Ligƒza, A.: Logical Foundations for Rule-Based Systems. Springer-Verlag, Berlin,
Heidelberg (2006) 5. Kaczor, K., Nalepa, G.J.: HaDEs presentation of the HeKatE design environment.
In Baumeister, J., Nalepa, G.J., eds.: 5th Workshop on Knowledge Engineering and Software Engineering (KESE2009) at the 32nd German conference on Articial Intelligence: September 15, 2009, Paderborn, Germany, Paderborn, Germany (2009) 5762 6. Bator, P.: Projekt i implementacja narzƒdzi do edycji wiedzy regu“owej HeKatE na platformie Eclipse. Master’s thesis, AGH University of Science and Technology (2012) supervisor: Grzegorz J. Nalepa. 7. Nalepa, G.J., Ligƒza, A.: HeKatE methodology, hybrid engineering of intelligent systems. International Journal of Applied Mathematics and Computer Science 20(1) (March 2010) 3553 8. Nalepa, G.J.: Architecture of the HeaRT hybrid rule engine. In Rutkowski, L., [et al.], eds.: Articial Intelligence and Soft Computing: 10th International Conference, ICAISC 2010: Zakopane, Poland, June 1317, 2010, Pt. II. Volume 6114 of Lecture Notes in Articial Intelligence., Springer (2010) 598605 9. Grzegorz J. Nalepa, K.K.: Proposal of a rule-based testing framework for the automation of the unit testing process. In: Proceedings of the 17th IEEE International Conference on Emerging Technologies and Factory Automation ETFA 2012, Krakw, Poland, 28 September 2012. (2012)