The KESE Workshop Series is available online: http://kese.ia.agh.edu.pl Technical Reports of the Wurzburg University: http://www.informatik.uni-wuerzburg.de/forschung/technical reports
AGH University of Science and Technology
Kraków, Poland gjn@agh.edu.pl
— denkbares GmbH Friedrich-Bergius-Ring 15, 97076 Würzburg, Germany joachim.baumeister@denkbares.com
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.
the 28th German Conference on Artificial Intelligence (KI-2005). In 2014 the KESE10 workshops was collocated with the 21st European Conference on Artificial Intelligence (ECAI 2014) in Prague, Czech Republic on August 19. This year we solicited contributions having the following topics: – Knowledge and software engineering for the Semantic Web, – Knowledge and software engineering for Linked Data, – Ontologies in practical knowledge and software engineering, – Business systems modeling, design and analysis using KE and SE, – Practical knowledge representation and discovery techniques in software engineering, – Context and explanation in intelligent systems, – Knowledge base management in KE systems, – Evaluation and verification of KBS, – Practical tools for KBS engineering, – Process models in KE applications, – Software requirements and design for KBS applications, – Software quality assessment through formal KE models, and – 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 six regular, and two short papers were accepted to the workshop. Moreover, two tool presentations were also included. We decided to organize the presentations during the workshop into three topical sessions.
included two papers and one tool presentation. Freiberg and Puppe discuss the use of patterns in engneering of knowledge-based systems. In their tool presentation Furth and Baumeister demonstrate an ontology debugger integrated in a semantic wiki. Hatko et al. apply behaviour-driven development for medical applications.
The second session, entitled Business Processes in KE&SE (Chair: Thomas
The third session Systems and Tools (Chair: Martina Freiberg) included four papers. Ostermayer et al. presented a custom connector architecture for Prolog and Java. Then Ślażyński et al. shared their experiences in migrating rule inference engines to mobile platforms. In their paper Bach et al. discussed knowledge modeling aspects with the open source tool myCBR. Finally, Kluza et al. presented a new wiki-based tool for SBVR.
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 for reviewing and collaboratively discussing the submissions. We would like to thank the Chairmans that supported the KESE Chairs during the event. For the submission and reviewing process we used the EasyChair system, for which the organizers would like to thank all the developers of the system. Last but not least, we would like to thank the organizers of the ECAI2014 conference for hosting the KESE10 workshop.
Workshop Organization
Programme Committee
Knowledge Modelling (Chair: Grzegorz J. Nalepa). Pattern-driven Knowledge Systems Engineering : : : : : : : : : : : : : : : : : : : : : : :
Martina Freiberg, Frank Puppe An Ontology Debugger for the Semantic Wiki KnowWE (Tool Presentation) : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Sebastian Furth, Joachim Baumeister Behaviour-Driven Development for Computer-Interpretable Clinical Guidelines : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Reinhard Hatko, Stefan Mersmann and Frank Puppe Business Processes in KE&SE (Chair: Thomas
Roth-Berghofer).
Ensuring the Semantic Correctness of Workflow Processes: An Ontological Approach : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Thi-Hoa-Hue Nguyen, Nhan Le-Thanh Integration of Activity Modeller with Bayesian Network Based Recommender for Business Processes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Szymon Bobek, Grzegorz J. Nalepa and Olgierd Grodzki Towards an Ontological Analysis of BPMN : : : : : : : : : : : : : : : : : : : : : : : : : : :
Emilio M. Sanfilippo, Stefano Borgo and Claudio Masolo Systems and Tools (Chair: Martina Freiberg).
CAPJA - A Connector Architecture for Prolog and Java : : : : : : : : : : : : : : :
Ludwig Ostermayer, Frank Flederer and Dietmar Seipel Migration of Rule Inference Engine to Mobile Platform. Challenges and Case Study. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Mateusz Slażyński, Szymon Bobek and Grzegorz J. Nalepa Knowledge Modeling with the Open Source Tool myCBR : : : : : : : : : : : : : : Kerstin Bach, Christian Severin Sauer, Klaus-Dieter Althoff and Thomas Roth-Berghofer SBVRwiki (Tool Presentation) : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Krzysztof Kluza, Krzysztof Kutt and Marta Woźniak 1 13 24 30 42 53 59 71 84 95 Pattern-driven Knowledge Systems Engineering
Martina Freiberg and Frank Puppe
freiberg/puppe@informatik.uni-wuerzburg.de Abstract. Despite increasing relevance in research- and industrial contexts, the implementation of knowledge-based systems (KBS) still is a challenging task. We motivate, that patterns|basically a renowned means for providing reusable solutions for similar problems|can drastically leverage development e orts and time. In this paper, we propose a framework for pattern-driven, encompassing KBS development, consisting of: Tailored usability criteria for a clear delimitation of KBS solutions, a basic pattern speci cation template, and a collection of foundational
proach, entailing: The reference implementation of several patterns with the tailored development tool ProKEt, their design- and usability-related evaluation, and empirical evidence of applying pattern-driven KBS development in actual projects. 1
Despite increasing relevance in research- and industrial contexts,
knowledgebased systems (KBS) engineering still denotes a challenging task. In general
software engineering, patterns are renowned for describing proven solutions and
preventing common pitfalls, thus fostering reuse and strongly leveraging overall
development e orts. To date, various pattern collections for general UI- and
interaction design are proposed, including [
In contrast to standard web pages or query forms, KBS do not solely build on strictly prede ned question sequences; rather, they characteristically live from follow-up items| exibly included interview items that become relevant only during the questioning session and based on the concrete user input. Also, KBS often require the prominent integration of additional information for elaborating the knowledge base / interview items more clearly and of (in-place) explanations of the results. This calls for tailored UI and interaction solutions that best support those requirements.
We motivate, that also KBS engineering can strongly pro t from tted
patterns that subsume such proven (and optimally evaluated) KBS solutions; this
can strongly support and re ne requirements engineering, and leverage
encompassing KBS development. First steps into that direction have been already taken
with regards to the knowledge base, e.g., [
The rest of the paper is organized as follows: In Section 2, we introduce a basic KBS pattern speci cation framework: A short de nition of relevant terms, tailored (usability-related) classi cation criteria, and a KBS UI pattern speci cation template. A collection of four framing patterns, that can be ne-tuned into a total of ten pattern variants, is proposed in Section 3. Practical experiences related to pattern-driven KBS development are reported in Section 4, and a summarizing conclusion and promising future work are presented in Section 5. 2
Before proposing a set of usability-related KBS delimitation criteria in Section 2.1 and sketching a basic pattern speci cation template in Section 2.2, we clarify some basic terms used in the remaining paper.
Forward- & backward progression: Forward progression starts with an empty solution set; from one or more init questions, such a KBS then questions in all directions, depending on the particularly implemented indication mechanisms. In contrast, a backward progression KBS is initialized with a target solution and poses only those questions that contribute to the nal state of that chosen solution.
Multiplex consultation- & clari cation KBS: Multiplex consultation KBS use forward progression, whereas clari cation KBS base on backward progression. Clari cation KBS can further be used with two application focuses: Consultation focussed|i.e., the clari cation KBS is started empty, and all contributing questions are posed. Or justi cation focussed|then, such a system is called for justifying a solution that already has been derived in the preceding session, thus corresponding to an elaborate, interactive solution explanation. 2.1
Tailored, Usability-related KBS Classi cation Criteria
Today, diverse UI design- and usability guidelines and standards are available,
such as Nielsen's heuristics [
5. Explorability (Participation): Are users enabled to deviate from the suggested questioning sequence, are potential expert shortcuts provided? 6. Intuition (usage): Are the applied presentation/interaction forms familiar or otherwise self-descriptive? If not, are particularly novice users supported (instructions, tutorials, examples)?
7. Transparency: Is the current state (i.e., state of questions, results, overall progress) clearly and comprehensibly mediated at any time?
8. Clear Arrangement/Aesthetics: Does the overall design exhibit certain aesthetics, e.g., by using a small number of virtual lines & basic symmetry? 2.2
KBS UI Pattern Speci cation Template Table 1 summarizes a basic template for specifying KBS UI patterns in a uni ed and clear manner. All variations of a base pattern exhibit some similar characteristics, e.g., the core KBS objective. They vary regarding the speci c realization of the UI/interaction, the extent of adhering to KBS classi cation criteria (see Section 2.1), the target users, knowledge speci cs, and the imposed consequences. In the following pattern descriptions, we only provide a summarizing template item variations that subsumes speci cs regarding the UI/interaction and required knowledge; we further delimitate the di erences regarding the classi cation criteria and the target users in Table 2; consequences, as well as details on the example implementations, are omitted here due to space restrictions.
geted user types, the speci c UI realization, knowledge speci cs,
(consequences, and example implementation details|not elaborated in
this paper).
We propose four basic KBS UI patterns: Questionnaire, Interview, Clari er, and
Clari er Hybrid, along with variants. In earlier research, we already introduced
three basic interaction categories for KBS, see [
Questionnaire Pattern Problem Statement: The KBS should compactly display a greater part of the KB, o er a highly transparent UI, intuitive usage, and a certain extent of explorability ; comprehensibility, is no key requirement for the core UI itself. Solution: Questionnaire KBS resemble paper- or web-based questionnaire forms. Depending on the particular UI style, many to all indicated interview objects are displayed simultaneously and typically ordered in some form of grid-based layout. Questionnaire may suggest (visually), but does not necessarily prescribe, an optimal interrogation sequence and thus fosters explorative usage. A certain comprehensibility can be achieved by adding auxiliaries|such as informative popups with additional explanations for interview items. Per default, Questionnaire uses forward progression, c.f., Section 2 Variations: Box-, Daily-, and CheckList Questionnaire.
a. Box Questionnaire closely adheres to the design of standard questionnaires by using established, familiar question presentation forms|e.g., checkboxes and radio buttons for choice questions, see Figure 1, I; thereby, each question is rendered within a distinct box, resulting in a very regular layout, but some waste of UI space.
b. Daily Questionnaire, originally inspired by daily newspapers, realizes a more at, juxtaposed presentation style for questions and answers, c.f., Figure 1, II; therefore, each question along with its answer options is placed in a line, implying a less regular yet more compact layout than the Box variant.
c. CheckList Questionnaire mirrors paper-based check lists by representing answer options by columns that simply are ticked o , see Figure 1, III. Therefore, all choice questions need to be mappable to a xed answer set; including further types, e.g., numerical questions, is possible, yet best results regarding e cient interaction and compactness are achieved with choice questions only. 3.2
Interview Base Pattern Problem Statement: The KBS UI should be highly intuitive and easily comprehensible, thus speci cally supporting novice users/domain laymen; in turn, compactness, descriptiveness, e ciency, explorability, as well as UI transparency can be neglected. m w d e ? a )II nd nd rod irew ydn re? y? (I ta ta od d d rd lra h h o n n o l ilg ilg g ta ta do ug r r in h h o re irkong? ing? itraneo itraneo illtcypa lirreag lirreag lliyang rrccou thw rko teh teh toh teh the itcp red iss lirg thw een een lirg een een tho isdo n? iagno itrneo ilraeg ttbew ttbew itrneo ttbew ttbew liraeg iltgh ftoe d a r c c a c c r e w t e e ta ta e ta ta e th o ihg th th no on th no on th id H L Is Is C C Is C C Is D ) I ( . .
| X X C ) a ( ) V I ( 6 5 P ) P 0 2 1 + ( u l F ) b ( , t E K o r P n i d e t n e m e l p m i s a ) I I ( e r i a n n o i t s e u D t I a ( 1 a
l e C l e t F F n Solution: Interview imitates human conversations by presenting always a single question|or a group of related questions|at a time; additional information are available anytime quickly and easily, e.g., by directly integrating it near to the corresponding interview object. Interview typically prescribes the interrogation sequence in a rather xed manner. The basic lack of transparency can be alleviated by integrating auxiliaries such as an interview object history|listing the already processed interview items|and a progress information display. Variations: Strict-, Grouped-, and Hierarchical Interview.
d. Strict Interview displays only a single question at a time together with its additional information, see Figure 2, I. Thus, optimally, the KB should provide suitable auxiliary information for each interview item. Further, a sophisticated indication mechanism is advisable for keeping the possible interrogation paths at solid lengths, especially regarding large KBs.
e. Grouped Interview sequentially displays groups of (optimally topically related) questions or single questions; thus, it is a bit more e cient than Strict Interview, and o ers more explorability, as the particular sequence within question groups is not prescribed. The UI uses a similar basic frame as Strict Interview, where Questionnaire variants are used for rendering the groups, c.f., Figure 2, II.
f. Hierarchical Interview o ers an interactively navigable tree UI speci
cally for decision tree knowledge, c.f., [
Clari er Base Pattern Problem Statement: Selected single solutions in highly expertise domains should be investigated exclusively and in-depth. The KBS UI should be compact, transparent, descriptive, and o er skill-building ability induced by a high comprehensibility of the contents; users should be enabled to increase e ciency in contributing their personal knowledge, e.g., for using shortcuts regarding the interrogation sequence (explorability/participation ). Intuitive usage, in contrast, is no key requirement.
Solution: Clari er characteristically uses backward knowledge, see Section 2, for investigating only a single issue at a time. Therefore, Clari er renders the target solution and all contributing questions|i.e., that potentially alter the solution rating in any way|simultaneously and o ers means to adapt answers and thus investigate the consequences on the solution.
Variations: Hierarchical Clari er and Form Add-on Clari er. ) I I ( 0 7 9 e a 1 l t a ta a ) I ( ) I ( O , ) , a
e x i n I , K t : E 2 g. Hierarchical Clari er exhibits its strengths optimally with backward knowledge that is re ned over several abstraction levels. It displays question and answers options within one node of its tree-style UI, see Figure 2, IV. The topmost node corresponds to the target solution, and is followed by nodes that correspond to the directly solution-relevant questions. Each question node again can be followed recursively by further question levels where the children denote a more ne-granular partition|one or several questions|of its parent. Thus, users decide whether to answer the more abstract top-level questions; or whether to implicitly answer them by expanding them and processing the children|child answers then are propagated recursively back to the parents.
h. Form Add-on Clari er adds minimalistic consultation widgets to static base justi cation presentation forms, such as nding lists or rule graphs, c.f., Figure 1, IV a&b. Clicking the interview objects in the justi cation automatically triggers compact (popup) consultation widgets; those contain all answer options for the respective question, potentially also indicating the value that is added to the solution. This allows for interactively adapting answers and thus exploring and clarifying a selected solution based on its general justi cation view. 3.4
Clari er Hybrid Pattern Problem Description: A more intuitively usable and easily comprehensible UI representation for using clari cation knowledge is desired.
Solution: Clari er Hybrids merge intuitive, comprehensible KBS UIs with backward knowledge for supporting especially also novice or laymen users in using clari cation KBS. Both Questionnaire and Interview patterns are suitable for using backward knowledge. The base implementation of Clari er Hybrid then corresponds to the variants described in Sections 3.1 and 3.2; in contrast to that, the targeted backward knowledge is processed, which might|depending on the actually selected UI variant|require some additions to the base UI; for example, widgets for explicitly navigating the hierarchical re nement levels. Variations: Clari cation Interview and Clari cation Questionnaire. 3.5
Pattern Variants|Detailed Delimitation iacompact recomprehensible irdescriptive t Ce cient tyexplorable i i intuitive l b atransparent sUclear arranged ssreexpertise: leaxypmeernienced XX U expert (X) usage: one-time X frequent X a . 1 .
3
M
M
L
M
H
H
H
H
Our practical experiences related to KBS UI patterns encompass: Support of
pattern-driven KBS development by the tailored tool ProKEt [
ProKEt: Tool Support for Pattern-driven KBS development
We already introduced ProKEt as a tailored KBS engineering tool that
specifically supports template-based development in [
Evaluation of Selected KBS UI Patterns
In early 2014, an encompassing evaluation was conducted regarding ProKEt
reference implementations of the following KBS UI patterns: Box-/Daily
Questionnaire, Strict-/Hierarchical Interview, and Hierarchical Clari er. Therefore, rst
an expert evaluation was conducted by 30 HCI students, using heuristic
evaluation according to Nielsen [
Evaluation Item Daily Success Rate = Correctly solved/all cases 88.71 Questionnaire Items Q1. Overall utility of the system 2.04 Q3. Belief in the result's correctness 1.68 Q4. KB quality=content,structure 2.24 Q5. Knowledge mediation 3.79 Q6. Perceived ease of use 1.95 Q7. E ciency of the KBS 2.01 Q9. Rating of the KBS UI design 3.58 Box 91.53 for Daily regarding its ease of use, simplicity, and e ciency. Thus, we suspect an even further increase in the overall rating of Daily in case it is further enhanced regarding its presentation|including, e.g., a clearer distinction of question and answer items, a more prominent highlighting of answered items, and providing overall visual structure by indicating separators between question/answer lines.
Regarding Hierarchical Clari er, the ratings may seem improvable; yet, this KBS addressed a highly complex KB from the domain of protection against unlawful dismissal, with an equally comprehensive problem description of the dismissal conditions, the correctness of which was to be rated by the KBS. Thus, an utility value of 2.68 and even the more a success rate of 88.31 % are particularly good results in the given context of a highly expertise domain but domain laymen users. Especially the descriptive and transparent style of Hierarchical Clari er, mirroring the derived question/solution ratings directly in the UI may have supported that result; it most likely fostered the overall trustworthiness Q3 (compared to the Interview variants).
As a general important insight it excelled clearly, that the evaluation of a KBS UI always is inherently coupled with the applied KB and the respective problem to be solved. 4.3
Case Studies with pattern-driven KBS Development
Pattern-driven development along with the tool ProKEt already proved highly
bene cial in actual projects. First, we noticed a strong support of the
requirements engineering process. In the Mediastinitis project|where a documentation
KBS for the structured input of operation data is realized, c.f., [
Another advantage is the fostered reuse of KBS solutions. In the EuraHS
project, c.f. also [
Similarly, in the JuriSearch project, see [
In this paper, we motivated the bene ts of pattern-driven development in the context of KBS. For practical support, we proposed a pattern speci cation framework, based on tailored KBS (usability) criteria and a pattern template, and we introduced a collection of 10 fundamental KBS UI/interaction patterns. Further, we reported practical experiences with the approach: Using the tailored KBS engineering tool ProKEt for creating reference implementations of the patterns, evaluating ve of them regarding their design and usability, and empirical experiences with pattern-driven KBS development from current projects.
Despite denoting an exciting approach for leveraging encompassing KBS development, there are several aspects worth investigating in the future: First, the general extension of the tool ProKEt as to entirely support those patterns that are speci ed theoretically only so far. Second, a thorough usability- and design-related base evaluation of the not yet assessed patterns. Third, an indepth inquiry of one assumption that has emerged in the conducted study: That a structural enhancement of Daily Questionnaire may entail even better results compared to Box Questionnaire. Fourth, follow-up studies for investigating patterns in direct comparison for delimitating core characteristics even clearer|e.g., the pure Clari er variants vs. one or both Clari er Hybrids. Another goal is the actual application of further selected patterns in current (and potential future) projects; e.g., using Clari cation Interview as a rst-time user alternative for the Hierarchical Clari er in the JuriSearch project. An Ontology Debugger for the
Semantic Wiki KnowWE
(Tool Presentation)
Sebastian Furth1 and Joachim Baumeister1;2 Abstract. KnowWE is a semantic wiki that provides the possibility to de ne and maintain ontologies and strong problem-solving knowledge. Recently, the ontology engineering capabilities of KnowWE were signi cantly extended. As with other ontology engineering tools, the support of ontology debugging during the development of ontologies is the de cient. We present an Ontology Debugger for KnowWE that is based on the delta debugging approach known from Software Engineering. KnowWE already provides possibilities to de ne test cases to be used with various knowledge representations. While reusing the existing testing capabilities we implemented a debugger that is able to identify failure-inducing statements between two revisions of an ontology. 1
Introduction
In software engineering changing requirements and evolving solutions are
wellknown challenges during the software development process. Agile software
development [
In the eld of ontology engineering the challenges are similar. It is extremely rare that the development of an ontology is a one-time task. In most cases an ontology is developed continuously and collaboratively. Even though this insight is not new and tool support has improved in recent years, a mature method for agile ontology development still is a vision.
The idea of continuous integration (CI) has been adapted for the development
of knowledge systems (cf. Baumeister et al. [
As abandoning a complete change set because of an error is as unrealistic as tracing down the failure cause manually, a method for isolating the fault automatically is necessary. We developed a debugging plugin for the semantic wiki KnowWE that is able to nd the failure-inducing parts in a change set. The debugger is based on the Delta Debugging idea for software development proposed by Zeller [18].
The remainder of this paper is structured as follows: Section 2 describes the delta debugging approach for ontologies; in Section 3 we present the developed plugin for KnowWE in detail. Section 4 contains a short case study while Section 5 concludes with a discussion and the description of future work. 2
Delta Debugging for Ontologies
Prerequisites
The proposed Delta Debugging approach assumes that we are able to access
di erent revisions of an ontology. Additionally, we assume that a mechanism
for the detection of changes exists. We call the di erence between two revisions
the set of changes C. The detection can be realized for example by utilizing
revision control systems like SVN or Git or by manually calculating the di erence
between two snapshots of an ontology. Even more sophisticated change detection
approaches are possible, like the one proposed by Goncalves et al. [
De nition 1 (Changes). Let C = fc1; c2; : : : ; cng be the set of changes ci provided by a change detection mechanism.
De nition 2 (Revision). Let O1 be the base revision of an ontology and O2 = O1 [ C a revision of the ontology, where the set of changes C have been applied.
With respect to a given test one of the revisions has to pass while the other one has to fail a speci c test (Axiom 1).
De nition 3 (Test Function). A function test : O ! BOOLEAN determines for a given ontology whether it passes (T RU E) a speci ed test procedure or not (F ALSE).
Axiom 1 For a given test function test and the revisions O1 and O2 of the ontology test(O1) = T RU E and test(O2) = F ALSE holds. Test outcome The Delta Debugging approach we propose is not limited to a certain test procedure as long as it can assert a boolean value as de ned in De nition 3 and Axiom 1. In software engineering the outcome of a test can also be unde ned. Zeller [18] pointed out three reasons why this can happen: manding products like game engines (for example LÖVE15 and Loom16, both written in Lua).
The second scenario concerns the more complicated compiling toolchain (S2CT) — precisely, before the deployment of the project, we could translate it into the native platform technology. This way we could work on the shared code base without worrying about differences between the platforms. Recently this approach receives a lot of attention — there are many technologies treating C or JavaScript as the portable assembler languages. Especially the latter, given its easy deployment on the web, is currently the compile target of the almost every popular programming language, including even the low level technologies. While making C or JavaScript our compile target does not differ much from using them as the project main language, in the most optimistic scenario we could translate the code base into different language depending on the target platform. This way we could maintain portability of the project and also benefit from native API on every supported platform at the same time. Remarkably, the Haxe17 language can be compiled into JavaScript, C++, C# and Java, trying to make this optimistic scenario possible.
Given the advantages of both S1 and S2 approaches, the hybrid approach simply combines them through the greater modularization of project. While the core black box part of the project can be written in the portable way, possibly using S2HL or S2LL methods, the interface layer should be interchangeable and written in regard to each supported platform separately. Consequently core of the project can truly abstract from platform dependent code (as in the optimistic cases of S2) and it is possible to make a high quality API for the end-users (as in S1). This approach is widely used by the so called wrappers — libraries written in the high level technology, which only wrap the low level library written already in C or other efficient technology. The proposed architecture of the inference engine implemented using the hybrid approach is presented in the figure 1, where the Platform Independent Runtime can mean low level machine programmable using C-family language or some kind of virtual machine destined to run the high level code, for example Lua interpreter or V8 JavaScript engine. The API part of the architecture should contain an query interface and methods to load rules from their plain representation. 5
HeaRT inference engine on mobile platforms
This section will focus on the case of porting the HeaRT inference engine [
The first part of the section will briefly describe our efforts to port existing code to the Android ecosystem, which was believed to be a good platform for the "proof of concept" implementation. The second part will contain plans for the future work, based on the experience gained from the unsuccessful attempts and research results presented earlier in section 4. 15 https://love2d.org/ 16 https://www.loomsdk.com/ 17 http://haxe.org The original implementation of HeaRT was written in the Prolog language and was executed by SWI–Prolog, an open source ISO-compliant Prolog implementation18. Thanks to the Prolog metaprogramming and reasoning features it was easy to represent rules as simple logical clauses and querying could be expressed with standard Prolog queries. Therefore the first attempts to port the engine were focused mainly on possible ways of executing Prolog code on the mobile platforms, particularly Android as it was stated in previous paragraph. The detailed description of these efforts can be found in [19]. In the terminology of Section 4.2 all attempts presented below can be assigned to the S2 category.
First and conceptually the simplest attempt can be categorized as S2LL and consisted of porting the SWI–Prolog environment to the Android platform. Due to the source code written almost entirely in C it was hoped to succeed without breaking changes in the environment. Unfortunately, it could not be carried successfully mainly because of the two major issues: – SWI–Prolog contains large parts of platform dependent code, dealing with the low level facilities like threading support, console interface, etc. Due to the lack of the libraries and different standard library on Android, migration of the SWI–Prolog must involve further refactoring and new conditionally compiled lines of code. – The interface between Java and SWI–Prolog was found to be not satisfactory, particularly it was not clear, whether it would work with the Dalvik Java virtual machine.
Next attempt was supposed to leave aside issues connected with the low level character of the popular Prolog environments and was oriented on their pure Java counterparts (therefore it can be regarded as a S2HL type). Following the carefully carried research four possible candidates were proposed: tuProlog19, jekejeke Prolog20, Gnu 18 http://www.swi-prolog.org/ 19 http://apice.unibo.it/xwiki/bin/view/Tuprolog/ 20 http://www.jekejeke.ch/idatab/doclet/intr/en/docs/package.jsp Prolog for Java21 and jinniprolog22. Despite their supposed ISO-compliance, none of them could be really regarded as a fully working Prolog enviroment. Nevertheless, after large refactoring of HeaRT source code we were finally able to run it using the tuProlog environment. Unfortunately, performance of this solution was unacceptable, clearly not satisfying the R2 and R3 requirements presented in Section 3.
The last used technique concerned translation of Prolog code into Java (therefore it was representative of the S2CT approach). Unfortunately, evaluated Prolog Café translator23, in spite of efficiency, lacked many advanced features used broadly in the HeaRT code, explicitly it dose not support mixing of the dynamic and static predicates. Furthermore, the text representation of HeaRT rules being itself a valid Prolog code, was also needed to be compiled to Java class, making the dynamic loading of the rules very inflexible.
To sum up the foregoing, Prolog proved to be too unpopular language to have adequate running environments on the mobile platforms. Consequently, all approaches of S2 type have to be preceded by the creation (or adaption) of efficient and portable Prolog environment. Due to related development cost, we have currently resigned from this approach. 5.2
Future plans The current plans for the mobile HeaRT development were created according to the S3 approach. The inference elements of HeaRT will be rewritten in the Lua language — the main reasons of this choice are low development cost and large variety of compact and efficient runtimes on even very exotic hardware. The architecture of so called LuaHeaRT matches the one presented in Figure 1. There were identified three major drawbacks of the selected approach: 1. The source code must be completely rewritten into language with different paradigm and capabilities. The related costs are not negligible, but inevitable. 2. Text representation of the rules in HeaRT is also a Prolog code, therefore in original implementation the task of processing it was performed entirely by SWI–Prolog. In the new architecture this process will be divided into two parts: parsing realized by parser included in the API module and semantic analysis performed entirely by the inference engine. Thanks to the formal grammar of the rule format it will be possible to semi-automatically generate parsers for the different platforms. 3. In the desktop version of HeaRT queries are defined as the standard Prolog queries.
For the sake of the new implementation we must specify new, possibly portable method of creating queries. The related code should be automatically generated (similarly to the grammar parser) and included in the API module. On the other hand the inference engine must contain some kind of low level query API, which could be the target of the human friendly representation of queries.
For the aforementioned reasons, there is no doubt that the portable implementation of HeaRT according to the S2 approach will involve the overall redesign of the desktop version. However, it is not entirely bad phenomenon, the end effects can be highly beneficial for the future development of the engine. 6
Summary In recent years, a lot of development was devoted to build applications that make use of contextual information to behave in an intelligent way. Due to the evolution of mobile devices which became omnipresent in every human life, the context-aware application became also one of the primary focus of mobile system developers. However, mobile and desktop environments are different, and therefore migrating solutions between them is not a trivial task. In this paper we focused on the problem of migration of a rule engine to mobile platform.
We defined requirements that every mobile reasoning engine should fulfill to provide efficient reasoning solution. We confronted these requirements with an attempt to migrate Prolog-based rule engine HeaRT onto the mobile platform. Finally, we presented a study of different migration scenarios, and propose a solution that provides both efficiency, portability and allows for effective source code maintenance. 11. Chen, H., Perich, F., Finin, T.W., Joshi, A.: Soupa: Standard ontology for ubiquitous and pervasive applications. In: 1st Annual International Conference on Mobile and Ubiquitous Systems (MobiQuitous 2004), Networking and Services, 22-25 August 2004, Cambridge, MA, USA, IEEE Computer Society (2004) 258–267 12. Ranganathan, A., McGrath, R.E., Campbell, R.H., Mickunas, M.D.: Use of ontologies in a pervasive computing environment. Knowl. Eng. Rev. 18 (2003) 209–220 13. Dey, A.K.: Understanding and using context. Personal Ubiquitous Comput. 5 (2001) 4–7 14. Gu, T., Pung, H.K., Zhang, D.Q., Wang, X.H.: A middleware for building context-aware mobile services. In: In Proceedings of IEEE Vehicular Technology Conference (VTC. (2004) 15. Hu, H., of Hong Kong, U.: ContextTorrent: A Context Provisioning Framewrok for Pervasive
Applications. University of Hong Kong (2011) 16. Palmer, N., Kemp, R., Kielmann, T., Bal, H.: Swan-song: A flexible context expression language for smartphones. In: Proceedings of the Third International Workshop on Sensing Applications on Mobile Phones. PhoneSense ’12, New York, NY, USA, ACM (2012) 12:1– 12:5 17. Kramer, D., Kocurova, A., Oussena, S., Clark, T., Komisarczuk, P.: An extensible, self contained, layered approach to context acquisition. In: Proceedings of the Third International Workshop on Middleware for Pervasive Mobile and Embedded Computing. M-MPAC ’11, New York, NY, USA, ACM (2011) 6:1–6:7 18. Dey, A.K.: Modeling and intelligibility in ambient environments. J. Ambient Intell. Smart
Environ. 1 (2009) 57–62 19. Szymon Bobek, Grzegorz J. Nalepa, M.S.: Challenges for migration of rule-based reasoning engine to a mobile platform. In Dziech, A., Czyz˙ewski, A., eds.: Multimedia Communications, Services and Security. Volume XX of Communications in Computer and Information Science., Springer Berlin Heidelberg (2014) accepted. 20. Nalepa, G.J., Bobek, S.: Rule-based solution for context-aware reasoning on mobile devices.
Computer Science and Information Systems 11 (2014) 171–193 21. Bobek, S., Porzycki, K., Nalepa, G.J.: Learning sensors usage patterns in mobile contextaware systems. In: Proceedings of the FedCSIS 2013 conference, Krakow, IEEE (2013) 993–998 22. Nalepa, G.J., Lige˛za, A., Kaczor, K.: Formalization and modeling of rules using the XTT2 method. International Journal on Artificial Intelligence Tools 20 (2011) 1107–1125 23. Lige˛za, A., Nalepa, G.J.: A study of methodological issues in design and development of rule-based systems: proposal of a new approach. Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery 1 (2011) 117–137 Knowledge Modeling with the Open Source Tool myCBR Kerstin Bach1, Christian Sauer2, Klaus Dieter Altho 3, and Thomas
Roth-Berghofer2 1 Verdande Technology AS
Trondheim, Norway http://www.verdandetechnology.com 2 School of Computing and Technology University of West London, United Kingdom
http://www.uwl.ac.uk
3 Competence Center Case-Based Reasoning (CC CBR)
German Research Centre for Arti cial Intelligence, Kaiserslautern, Germany
http://www.dfki.de/web/competence/cccbr
Abstract. Building knowledge intensive Case-Based Reasoning
applications requires tools that support this on-going process between domain
experts and knowledge engineers. In this paper we will introduce how the
open source tool myCBR 3 allows for exible knowledge elicitation and
formalisation form CBR and non CBR experts. We detail on myCBR 3 's
versatile approach to similarity modelling and will give an overview of
the Knowledge Engineering workbench, providing the tools for the
modelling process. We underline our presentation with three case studies of
knowledge modelling for technical diagnosis and recommendation
systems using myCBR 3.
1
Case-Based Reasoning (CBR) is a methodology introduced by Riesbeck and
Schank [13] and Kolodner [
CBR systems always carry out the retrieve phase which is characterized by a similarity-based comparison of features, while the remaining phases can omitted. Richter [12] introduced to model of four knowledge containers describe the required knowledge within a CBR system: { Vocabulary de ning the range of allowed values for attributes. For numeric values this is usually the value range (minimum, maximum) while for symbolic values this can be a list of values. { Similarity Measures de ning the relationship between attribute values in form of a similarty assignments. Similarity measures can be formulas like the hamming distance for numeric values or reference tables for symbolic values. { Adaptation Knowledge is knowledge describing how cases can be adapted in the reuse step, often represented as rules. { Cases are instances describing situations that have happened and are worth capturing in order to be reused. They instantiate attributes describing the problematic situation as well as a solution description. Their degree of formalization can vary.
Developing CBR systems requires a systematic development of knowledge
models by de ning the requirements and building the models itself. myCBR 3 4
is an open source tool targeting at developing customized knowledge models
with an emphasis on vocabulary and similarity measure development. myCBR 3
is an open-source similarity-based retrieval tool and software development kit
(SDK). With myCBR 3 Workbench you can model and test highly
sophisticated, knowledge-intensive similarity measures in a powerful GUI and easily
integrate them into your own applications using the myCBR 3 SDK[
In the remaining of this paper we will give an overview of other CBR tools
and applications (section 2) as well as showcase the functionalities of myCBR 3
(section 3). In section 4 we will show how myCBR 3 has been applied in di erent
CBR projects while the nal section will sum up the paper and give an outlook
on future work on the tool.
2
Freely available CBR tools are for instance FreeCBR, jCOLIBRI or eXiT*CBR,
which will be brie y discussed in this section. FreeCBR5 is a rather simple CBR
engine, which allows the realization of basic CBR features. However, it does not
cover features like case revision or retention and more individualized knowledge
models, or comprehensive global and local similarity measures, are not
applicable either. Further, it still requires quite some e ort to apply it to a high variety
of tasks. jCOLIBRI started from a task oriented framework also covering
distributed reasoning [
COLIBRI is another platform for developing Case-Based Reasoning (CBR) CBR software. COLIBRI's main goal, opposed to myCBR 3, is to provide the infrastructure required to develop new CBR systems and its associated software components, rather than a CBR knowledge model. COLIBRI is designed to o er a collaborative environment. It is an open platform where users can contribute with di erent designs or components of CBR systems, which will be reused by other users. Subsequently many of the components available have been developed by third-party research groups and contributed to the platform to be shared with the community.
As a platform, COLIBRI o ers a well-de ned architecture for designing CBR systems. COLIBRI also provides a reference implementation of that architecture: the jCOLIBRI framework. jCOLIBRI is a white-box tool that permits system designers to have total control of the internal details of the software. The platform also includes graphical development tools to aid users in the development of CBR systems. These tools are enclosed in the COLIBRI Studio IDE and generate applications that use the components provided by jCOLIBRI.
Furthermore, creating individualized case representations and especially
exible similarity measures is the strength of myCBR 3. eXiT*CBR has also its roots
in machine learning applications and is specialized for medical diagnosis tasks [
In industry, most prominent CBR tools or CBR related technologies are
used by empolis in the on SMILA6 based Information Access Suite7 as well as
by Verdande Technology in DrillEdge 8 [
Knowledge Engineering in myCBR myCBR 3 is an open-source similarity-based retrieval tool and software development kit (SDK)[19]. With myCBR 3 Workbench you can model and test highly sophisticated, knowledge-intensive similarity measures in a powerful GUI and easily integrate them into your own applications using the myCBR 3 SDK. Case-based product recommender systems are just one example of similaritybased retrieval applications.
The myCBR 3 Workbench provides powerful GUIs for modelling knowledgeintensive similarity measures. The Workbench also provides task-oriented con gurations for modelling your knowledge model, information extraction, and case base handling. Within the Workbench a similarity-based retrieval functionality is available for knowledge model testing. Editing a knowledge model is facilitated by the ability to use structured object-oriented case representations, including helpful taxonomy editors as well as case import via CSV les.
The myCBR 3 Software development Kit (SDK) o ers a simple-to-use data model on which applications can easily be built. The retrieval process as well as the case loading, even from considerably large case bases, are fast and thus allow for seamless use in applications built on top of a myCBR 3 knowledge model.
Within myCBR 3 each attribute can have several similarity measures. This feature allows for experimenting and trying out di erent similarity measures to record variations. As you can select an appropriate similarity measure at runtime via the API, you can easily accommodate for di erent situations or di erent types of users.
The myCBR 3 Workbench is implemented as using the Rich Client Platform (RCP) of Eclipse and o ers two di erent views to edit either knowledge models or case bases. In this section we will focus on the modelling view as shown in 1.
The conceptual idea behind the modelling view is that rst a case structure is created, followed by the de nition of the vocabulary and the creation of individual local similarity measures for each attribute description (eg. CCM in 1) followed by the global similarity measure for a concept description (Car in 1).
The modelling view of the myCBR 3 Workbench (see gure 1) is showing the case structure (left), available similarity measures (left bottom) and their de nition (center). Modelling the similarity in the Workbench takes place on the attribute level for local similarity measures and the concept level for global similarity measures. 3.1
Building a Vocabulary The vocabulary in myCBR 3 consists of concepts and attributes. A concept description can contain one or more attribute descriptions as well as attributes referencing concepts, which allows the user creating object-oriented case representations. In the current version myCBR 3 also allows for the import of vocabulary items, e.g. concepts and attributes, from CSV les as well as from Linked (Open) Data (LOD) sources.
An attribute description can have one of the following data types: Double, Integer, String, Date and Symbol. When attributes are de ned, the data types and value ranges are given with initial default values and can be set to the desired values in the GUI. Fig. 1. Example view of the knowledge model view in the myCBR 3 workbench 3.2 The Workbench provides graphically supported modelling of similarity functions that support their de nition. As an attribute description can have more than one similarity measure experimenting with knowledge modelling approaches is facilitated. For numerical data it is providing prede ned distance (or similarity) functions along with prede ned similarity behaviour (constant, single step or polynomial similarity decrease). For symbolic values, myCBR 3 Workbench provides table functions and taxonomy functions. A table function allows de ning for each value pair the similarity value, while a taxonomy subsumes similarity values for subsets of values. Depending on the size of a vocabulary, table similarity measures are hard to maintain and taxonomies allow an easier overview. For symbolic values, also set similarities are provided in order to compare multiple value pairs. For each of the similarity measures, as well as for the global similarity measure(s) a speci c, versatile editor GUI is provided. 4
Case Study
Creating Knowledge from Unstructured Documents
This approach has been developed in machine diagnosis based on experiential
knowledge from engineers[
Such machine manufacturers collect information about machine problems that are submitted by technicians containing machine data, observations and sometimes further correspondence between an engineer or analyst with the technician at the machine. In the end, these discussions usually come up with a solution - however, the solution is normally neither highlighted nor formalized and the topics and details discussed highly depend on the technician and what the Customer Support asks for. That is the reason why cases that are stored for collecting Customer Support information can not directly be used for CBR. Therefore we will di erentiate between Customer Support Cases (CS Cases) and CBR Cases. CS Cases contain original information collected during a discussion between Customer Support and the eld technician, while a CBR Case contains only relevant information to execute a similarity based search on the cases. The CBR cases content represents each CS Case, but contains machine understandable information.
For building the vocabulary, we extracted all nouns and organized them in attribute values, which were directly imported into myCBR 3 and from there discussed with the experts. Especially the given taxonomies provided great feedback, because we were discussing both, the terms as well as their relationship. Further, the workbench provided great feedback in explaining CBR because the information the CBR engine uses gets visible. Experts can see local and global similarity measures as well as they can adjust weightings. After 4 sessions with the experts we had a status where the case formats and vocabulary was ready to be deployed in a prototype.
Throughout the project we kept using the workbench when re ning case formats as well as similarity measure until the experts themselves started looking into the knowledge models themselves.
On the application's backend, we used the myCBR 3 SDK to develop a web-based application that searches for similar customer cases after entering all available machine data and observations. Because of the modularity, we were able to deploy updated knowledge models smoothly into the application. 4.2
Knowledge Formalisation for Audio Engineering A case study on creating a case-based work ow recommendation system for audio engineering support was performed in 2013 [15]. In this study the approach to formalise the special vocabulary used in audio engineering, consisting of vague descriptors for timbres, amounts and directions, was developed. The study introduced CBR as a methodology to amend the problem of formalising the vagueness of terms and the variance of emotions invoked by the same sound in di erent humans. It was further detailed that the researchers opted for the use of CBR due to CBR's ability to process fuzzy and incomplete queries and the ability to choose between grades of similarity of retrieved results to emulate the vagueness. The relations between timbres, amounts and e ects, were modelled into the local similarity measures of the initial CBR knowledge model as they compose the overall problem description part of what was later used as a case in the resulting CBR engine.
A challenge during this case study was encountered in the form of the task of nding an optimal grade of abstraction for the frequency levels in audio engineering within the CBR knowledge model. This was of importance as in any knowledge formalisation task, one is facing the trade-o between an over engineered, too speci c knowledge model and the danger of knowledge loss by employing too much abstraction e.g. choosing the abstraction levels too high. The challenge was met by the researchers by choosing two additional abstraction levels of frequency segments for the timbre descriptors[15].
The next knowledge modelling step consisted of determining the best value ranges for the numerical attributes which were to be integrated into the initial knowledge model. After discussing this approach with the domain experts, the researchers agreed to use two ways to represent amounts in the knowledge model. The rst way used a percentage approach, ranging from 0 to 100% and the second way used a symbolic approach. The symbolic approach was chosen because the domain experts mentioned that from their experience the use of descriptors for amounts, such as 'a slight bit' or 'a touch' were by far more common in audio mixing sessions then a request like 'make it 17% more airy'. So the researchers integrated, next to the simple and precise numerical approach, a taxonomy of amount descriptors into the initial knowledge model. The taxonomy was ordered based on the amount the symbol described, starting from the root, describing the highest amount down to the leaf symbols describing synonyms of smallest amounts.
The researchers used the myCBR 3 Workbench to swiftly transfer their initial elicited knowledge model into a structured CBR knowledge model. Figure 2 provides an insight in the modelling of the local similarity measure for timbre descriptors. The rst gure shows the taxonomic modelling on the left and a section from the same similarity measure being modelled in a comparative symbolic table on the right.
Within myCBR 3 the researchers had the choice between a taxonomic and
a comparative table approach. Considering the versatile use of taxonomies in
structural CBR[
After the initial knowledge model was created the researchers performed a number of retrieval experiments using the myCBR 3 built in retrieval test
Fig. 2. Timbre descriptor taxonomy and comparative table ing facilities. The goal of these tests was to re ne the initial knowledge model, speci cally the similarity measures for the timbre descriptors. Additionally the researchers used the feedback from domain experts to streamline the case structure to the most important attributes. This streamlining was performed within a live system and the researchers were able to directly integrate the streamlined CBR engine into their Audio Advisor application thanks to myCBR 3 's exible API.
Knowledge Formalisation for Hydrometalurgy Gold Ore Processing In this case study a twofold approach to elicitating and formalising knowledge in the domain of hydrometallurgical processing of gold ore was researched. The study demonstrated processes of formalising hydrometallurgy experts knowledge into two di erent CBR knowledge models. The rst knowledge model was than employed in the Auric Adviser work ow recommender software [17].
Based on the knowledge gathered from the domain experts the researchers created an initial knowledge model and distributed the knowledge into the 4 knowledge containers of CBR in the following way: The vocabulary consisted of 53 attributes, mainly describing the ore and mineralogical aspects of an ore deposit. With regard to the data types used, the researchers used 16 symbolic, 26 oating point, 6 boolean and 5 integer value attributes. The symbolic attributes described minerals and physical characteristics of minerals and gold particles, such as their distribution in a carrier mineral. Further symbols were elicited to describe the climate and additional contexts a mining operation can be located in, like for example the topography.
The cases were distinctive mainly with regard to the mineralogical context of the mined ore. Thus the researchers created 5 cases describing refractory arsenopyritic ores, 5 describing free milling gold ores, 2 on silver rich ores, 6 cases on refractory ores containing iron sulphides, 4 on copper rich ores and one each on antimony sulphide rich ores, telluride ore and carbonaceous ore.
To compute the similarity of a query, composed of prospective data, and a work ow case, the researchers modelled a series of similarity measures for which the researchers had the choice between comparative tables, taxonomies and integer or oating point functions. For their initial knowledge model the researchers mainly relied on comparative tables.
The study's approach included the idea to model as much of the complex knowledge present in the domain of ore re nement into the similarity measures as possible. This was based on the assumption that the similarity based retrieval approach provided by the use of CBR would allow to capture and counter most of the vagueness still associated with the selection of the optimal process in the hydrometallurgical treatment of refractory ores domain. For example, it was possible to model into the similarity measures such facts as that the ore does not need any more treatment if it contains gold grains greater than 15 micro meters in diameter. Such facts are easy to integrate into the similarity measure and thus are operational (having an e ect) in the knowledge model. The researchers deemed this capability of the similarity measures to capture and represent such `odd' behaviours of the knowledge model very important. The study assumes also that these `odd' facts or bits of knowledge are hard to capture by rules, and thus has ultimately kept another, rule-based approach of modelling the hydrometallurgical domain knowledge, IntelliGold, from succeeding on a broad scale [20].
For the global similarity measure of the cases the researchers used a weighted sum of the attributes local similarities. This allowed for the easy and obvious emphasise of important attributes, such as for example ` Clay Present', as the presence of clay forbids a selection of hydrometallurgical treatments. As the study mainly aiming for case retrieval, the need for adaptation knowledge was minor. Therefore the researchers did not formalised any adaption knowledge. The retrieval results achieved with the rst knowledge model was described as satisfying in accuracy and applicability by domain experts. In this paper we have presented the approach to knowledge formalisation within myCBR 3. myCBR 3 emphasised the fact that myCBR 3 is a very versatile tool to create CBR knowledge models with a particular versatile suit of editors for similarity modelling. During the evaluations of the presented projects with the stakeholders, especially the domain experts found that the GUIs o ered by myCBR 3 are intuitive, particularly with regard that they did not have prior knowledge of CBR and the required domain knowledge modeling techniques.
Furthermore, also based on experiences from the case studies, we demonstrated that myCBR 3 allows for on-going knowledge model improvement, even in a running application. This fact allows also for knowledge maintenance and re nement in live CBR applications and also enables developers to follow the rapid prototyping approach in their projects. As shown in previous a research cooperation with COLIBRI, as well as in a research cooperation on similarity of event sequences, myCBR 3 is particular versatile for similarity measure based knowledge modelling. Furthermore myCBR 3 is also easily extendable with regard to its SDK and API to cater for any kind of new similarity measures [14].
For future work we are currently reviewing prototype implementations of additional features for myCBR 3. These additional features comprise the ability of automatic extraction of vocabulary items and similarity measures from web community data, the incorporation of drools for the generation of adaption knowledge and the incorporation of case acquisition from databases. Furthermore we are currently nishing the work on the next release of myCBR 3, reaching version 3.1. We are also in the process of integrating a mobile version of myCBR 3, catering for the needs of android application, such as fast access to assets in a future version of myCBR 3 [16].
References 6. Gundersen, O.E., S rmo, F., Aamodt, A., Skalle, P.: A real-time decision support system for high cost oil-well drilling operations. AAAI Publications, Twenty-Fourth IAAI Conference (2012) 7. Hanft, A., Schafer, O., Altho , K.D.: Integration of drools into an osgi-based bpmplatform for cbr. In: Agudo, B.D., Cordier, A. (eds.) ICCBR-2011 Workshop Proceedings: Process-Oriented CBR (2011) 8. Kolodner, J.: Case-based reasoning. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA (1993) 9. Lopez, B., Pous, C., Gay, P., Pla, A., Sanz, J., Brunet, J.: exit*cbr: A framework for case-based medical diagnosis development and experimentation. Artif. Intell.
Med. 51(2), 81{91 (Feb 2011) 10. Recio-Garc a, J.A., D az-Agudo, B., Gonzalez-Calero, P.A.: A distributed cbr framework through semantic web services. In: Bramer, M., Coenen, F., Allen, T. (eds.) Research and Development in Intelligent Systems XXII (Proc. of AI 2005). pp. 88{101. Springer (December 2005) 11. Recio-Garc a, J.A., D az-Agudo, B., Gonzalez-Calero, P.A.: Template based design in colibri studio. In: Proceedings of the Process-oriented Case-Based Reasning Workshop at ICCBR'11. pp. 101{110 (2011) 12. Richter, M.M.: Introduction. In: Lenz, M., Bartsch-Sporl, B., Burkhard, H.D., Wess, S. (eds.) Case-Based Reasoning Technology { From Foundations to Applications. LNAI 1400, Springer-Verlag, Berlin (1998) 13. Riesbeck, C.K., Schank, R.C.: Inside case-based reasoning. Lawrence Erlbaum Associates, Pubs., Hillsdale, N.J. (1989) 14. Roth-Berghofer, T., Sauer, C., Garcia, J.A.R., Bach, K., Altho , K.D., Agudo, B.D.: Building case-based reasoning applications with mycbr and colibri studio.
In: Case-Based Reasoning Research and Development. Springer (2012) 15. Sauer, C., Roth-Berghofer, T., Auricchio, N., Proctor, S.: Recommending audio mixing work ows. In: Case-Based Reasoning Research and Development, pp. 299{ 313. Springer (2013) 16. Sauer, C.S., Hundt, A., Roth-Berghofer, T.: Explanation-aware design of mobile mycbr-based applications. In: Case-Based Reasoning Research and Development, pp. 399{413. Springer (2012) 17. Sauer, C.S., Rintala, L., Roth-Berghofer, T.: Knowledge formalisation for hydrometallurgical gold ore processing. In: Research and Development in Intelligent Systems XXX, pp. 291{304. Springer (2013) 18. Schulz, S.: Cbr-works - a state-of-the-art shell for case-based application building. In: Proceedings of the 7th German Workshop on Case-Based Reasoning, GWCBR'99, Wrzburg. pp. 3{5. Springer-Verlag (1999) 19. Stahl, A., Roth-Berghofer, T.R.: Rapid prototyping of CBR applications with the open source tool myCBR. In: Proceedings of the 9th European conference on Advances in Case-Based Reasoning. pp. 615{629. Springer-Verlag, Heidelberg (2008) 20. Torres, V.M., Chaves, A.P., Meech, J.A.: Intelligold-an expert system for gold plant process design. Cybernetics & Systems 31(5), 591{610 (2000)
SBVRwiki (Tool Presentation) ? Krzysztof Kluza, Krzysztof Kutt and Marta Wo„niak
AGH University of Science and Technology al. Mickiewicza 30, 30-059 Krakow, Poland
{kluza,kkutt}@agh.edu.pl Abstract. SBVR is a mature standard for capturing expressive business rules along with their semantics, and is especially useful in the communication with business people. SBVRwiki is a novel tool that allows for an eective use of the SBVR notation. This online collaborative solution allows for distributed and incremental rule authoring for business analytics and users. It supports creation of vocabularies, terms and rules in a transparent, user-friendly fashion. The tool provides visualization and evaluation mechanisms for created rules, and besides basic syntax highlighting and checking, it allows for logical analysis. As it is integrated with the Loki knowledge engineering platform, it allows for on-the-y conversion of the SBVR rule base and vocabularies to Prolog. The Dokuwiki back-end provides storage and unlimited version control, as well as user authentication. 1
Introduction and Motivation
SBVR (Semantics of Business Vocabulary and Business Rules) [
An eective use of the SBVR notation is non trivial, because it requires certain knowledge engineering skills. Thus, there is a need for software supporting business analytics in the rule acquisition process. Such software should allow for syntax checking, automatic hinting as well as preliminary evaluation of the resulting set of rules.
There are several SBVR-supporting tools like editors that support text-based creation of dictionaries and business rules providing syntax highlighting and suggestions; modelers that allow for generating models based on SBVR compliant documents; or tools that allow a user to import various models and transform them into the SBVR syntax. Considering their limitations of the existing tools supporting SBVR authoring, our motivation is to deliver a lightweight tool allowing for easy creation of the SBVR knowledge bases even for inexperienced users. We opt for a web-based solution that allows business users and analytics to collaborate using a familiar browser-based interface. ? The paper is supported from the Prosecco project funded by NCBR.
SBVRwiki uses the Dokuwiki 1 back-end for storage, unlimited version control and user authentication. The tool supports identication and creation of vocabularies, terms and rules in a transparent, user friendly fashion. It also provides visualization and evaluation mechanisms for created rules.
Our tool is integrated with the Loki knowledge engineering platform [
The rest of the paper is structured as follows. Section 2 discusses the
functional requirements for the wiki-based collaborative platform for knowledge
engineering, especially for requirements analysis. Then, in Section 3 the SBVRwiki
system is presented. Future work is summarized in the nal Section 4.
Wikis are broadly used in various areas including distributed requirements
analysis [
Main functional requirements for an SBVR wiki-based system are as
follows: 1) creation of a new SBVR project composed of vocabularies, facts, and
rules using a set of predened templates, 2) authoring of a project using
structured vocabularies, with identied categories, 3) SBVR syntax verication and
highlighting in text documents, as well as syntax hinting, 4) visualization of
vocabularies and rules as UML class diagrams to boost the transparency of the
knowledge base, 5) le export in the form of SBVR XMI, 6) integration with
the existing PlWiki and BPWiki [
Dokuwiki oers several classes of plugins allowing for ne-grained processing of the wiki text. SBVRwiki implements two main plugin components: SBVRwiki Action Plugin responsible for the le export in the XMI (XML) format. It also handles the user interface events and extends the built-in Dokuwiki editor with shortcuts for common SBVR constructs.
SBVRwiki Syntax Plugin used to enter SBVR expressions as wiki text using a special <sbvr> wiki markup. Using it a user can enter legal SBVR expressions and the plugin oers rich syntax highlighting. Moreover, vocabularies can be visualized with the dynamic translation to UML class diagrams that are rendered by the wiki using the PlantUML tool 2, see Fig. 1. Fig. 1. Class diagram generation with PlantUML (from left: fragment of the fact dictionary; a text le to generate the class diagram; and UML class diagram generated by the PlantUML tool)
There are several advantages of using a Wiki system as the implementation platform. As the SBVR expressions can be stored in separate wiki pages, the content can be simultaneously edited by a number of users. The Loki engine can select only the relevant parts of this knowledge on the y, so the pages can contain not only the SBVR content, but also additional pieces of information, such as comments, gures, media attachments, and hypertext links to other resources in the wiki or on the Web.
For this tool presentation, we uses a benchmark case of SBVR knowledge
base, the classic EU Rent case 3, provided as a part of the SBVR specication [
EU-Rent is a ctional international car rental company. Renters may be individuals or accredited members of corporate customers (a company or similar organization). In each country, EU-Rent oers broadly the same kinds of cars, ranging from economy to premium although the mix of car models varies between countries. Rental prices also vary from country to country. However, dierent models of oered cars are organized into groups, and all cars in a group are charged at the same rates within a country. 2 See: plantuml.sf.net. 3 You can browse the EU-Rent case using wiki on: http://home.agh.edu.pl/~kkutt/ sbvrwiki-demo/. Credentials: demo/demo.
A car rental is a contract between EU-Rent and a renter, who is responsible for payment for the rental and any other costs associated with the rental (except those covered by insurance). A rental booking species: the car group required; the start and end dates/times of the rental; the EU-Rent branch from which the rental is to start.
During creating a new SBVR project, several steps have to be taken. However, this does not require much knowledge of the application because a user is supported by a set of built-in guiding wizards. Using SBVRwiki, a user should dene concepts rst, then writes down facts, and nally rules can be authored. Concepts, facts and rules are stored in the separate Wiki namespaces. The Lexer module of the plugin detects the previously dened tokens what allows for proper syntax highlighting as well as for detecting the use of undened concepts.
In the case of the EU-Rent example, a user can start from creating a dictionary. It is a set of terms grouped in categories. If a user wants to describe concepts such as additional driver or loyalty club, it is a possibility to write down the information about these terms, such as a source, a type or a denition. A user can also group them in category Customers. Finally, dictionary is saved and clearly formatted wiki page can be displayed (see Fig. 2).
The next step consists in creating the base of facts. A user can specify what dependencies exist between previously dened concepts. E.g. it can be specied that loyalty club includes club member, renter is club member, and renter is additional driver. When all such facts are described and saved, simple UML graphs are generated to visualize created database (see Fig. 3). In the last step, a user species rules providing constraints for modeled system. When saved, they are also clearly formatted and visualized in simple graphs form (see Fig. 4).
Fig. 2. EU Rent Terms Dictionary Although the current version of SBVRwiki does not support all aspects of the SBVR standard, it implements enough of its elements to allow users to create complex models of business rules in Structured English. Its limitations are the lack of support for multi-argument facts, polymorphism or additional attributes for the expressions, dictionaries, facts and rules.
As the tool is implemented as a plugin for the DokuWiki system, it can
be integrated with the BPWiki plugin [
SBVRwiki has been recently used in the Prosecco 4 research project as a tool for authoring the SBVR rules. One of the objectives of the project is the development of a system supporting management of SMEs (Small and Medium Enterprises) using business process and rules with well dened semantics. Thus, the tool was used to model vocabularies and rules identied in the SMEs participating in the project.
References