=Paper=
{{Paper
|id=Vol-289/paper-1
|storemode=property
|title=Markups for Knowledge Wikis
|pdfUrl=https://ceur-ws.org/Vol-289/p01.pdf
|volume=Vol-289
|dblpUrl=https://dblp.org/rec/conf/kcap/BaumeisterRP07a
}}
==Markups for Knowledge Wikis==
https://ceur-ws.org/Vol-289/p01.pdf
Markups for Knowledge Wikis
Joachim Baumeister, Jochen Reutelshoefer, Frank Puppe
Institute of Computer Science
University of Würzburg
Würzburg, Germany
baumeister/reutelshoefer/puppe@informatik.uni-wuerzburg.de
ABSTRACT sert and change problem–solving knowledge using a textual
Knowledge wikis extend normal wikis by the representation knowledge markup. Examples for knowledge markup are
of explicit knowledge. In contrast to semantic wikis the the definition of models, rules and the semantic annotation
defined knowledge is mainly used for knowledge–intensive of wiki text. The simplicity and the intuitive representation
tasks like collaborative recommendation and classification. of the markup is very important, since we address normal
In this paper, we introduce a prototype implementation of but ”experienced users” to be the developers of the knowl-
a knowledge wiki, and we discuss appropriate markups for edge wiki and not knowledge engineers that can be trained
problem–solving knowledge to be used in knowledge wikis. thoroughly beforehand. In consequence, the markup should
The main aspect of the proposed markups is their simplicity support the formation of ”ad-hoc knowledge engineers”. The
and compactness, since it is aimed that these markups are formalized knowledge is also used through the wiki interface:
used by normal wiki users. Case studies report on practical the user can enter findings into the wiki system and retrieves
experiences we have made with the development of various appropriate recommendations as a solution for the given in-
knowledge wikis. put.
Categories and Subject Descriptors We describe different markups to be defined in knowledge
H.4 [Information Systems Applications]: Miscellaneous wikis to capture and maintain knowledge for the creation
of recommendation systems. As already emphasized before,
1. INTRODUCTION it is important to provide simple and intuitive markups in
Many successful examples have shown that wiki systems order to enable standard users to adapt this representation.
are a reasonable basis for building information systems in All proposed markups have been implemented in the proto-
a collaborative way, i.e., the creation and evolution of the type system KnowWE (Knowledge Wiki Environment).
content is accomplished by the community itself. In gen-
eral, wiki systems [6] are web-based content–management Wikis are an already proven technology that is well–adapted
systems that allow for the simple construction of new con- by large communities, and therefore the approach of extend-
tent and the evolution of existing content, i.e., mostly text, ing wikis by knowledge markup appears to be quite feasible.
figures and pictures. Here, the content is viewed by a web Due to its open and immediate access to the knowledge a
browser, but is also changed by editing the particular wiki wiki serves as a natural platform for knowledge communi-
page in an edit pane. In order to simplify the interface for ties. In consequence, we also expect a knowledge wiki to
the users, the formatting syntax is commonly less complex be a suitable development tool for “closed communities” [2],
than HTML. The arguably most prominent example of a i.e., a community of interest with a particular goal that is
successful wiki system is the encyclopedia Wikipedia. comparable to open–source software projects. Here, the re-
sulting software is actually used by a wide range of people,
In this paper we focus on knowledge wikis to be used in the but the development process itself is carried out by a smaller
context of classification systems, e.g., systems built for con- (and often distributed) group of specialists. These develop-
sultation, selection, and recommendation tasks. Knowledge ers have the access and the possibility to extend and modify
wikis extend regular wikis by the possibility to create and the system, since they are recognized by the rest of the com-
use explicit knowledge together with the classic wiki con- munity. For example, this clearly differs from systems like
tent. The creation and evolution of the knowledge is done Wikipedia that are mainly built for “open communities”.
within the normal edit pane of the wiki, i.e., developers in-
The following is organized as follows: in Section 2 we give
a brief overview of the knowledge wiki KnowWE applica-
ble for recommendation tasks. Appropriate markups to be
used as explicit problem–solving knowledge are introduced
in Section 3. We discuss the possible integration of explicit
problem–solving knowledge and normal wiki text in Sec-
tion 4, and we provide case studies in Section 5. The paper
is concluded with a summary and outlook in Section 6.
(c)
(b)
(a)
Figure 1: The user interface of the knowledge wiki KnowWE: user inputs are provided by (a) in–place answers
or by (b) starting a structured interview; (c) currently derived solutions are displayed immediately.
2. KNOWWE – A KNOWLEDGE WIKI tated text or by (b) activating a knowledge–based interview
The knowledge wiki KnowWE is an extension of the classic provided by a link. The right pane of the wiki displays cur-
wiki engine TWiki1 in order to support classification tasks in rently derived recommendations for the given inputs (c).
a knowledge–based manner. For the classification task and
its corresponding problem–solving, respectively, we identify
two main ontological classes: user inputs represented by 2.1 Knowledge Creation
questions to the user and solutions (recommendations) de- The acquisition and maintenance of knowledge in a knowl-
rived by the system for a set of given inputs. We support edge wiki is done within the edit pane, i.e., by entering and
different types of user inputs, namely one–choice, multiple– changing text in a browser window. Since we propose an
choice and numeric inputs. In the presented system the extension of classic wikis the problem–solving knowledge
reasoning engine d3web [1, 8] is integrated, which provides is managed together with the text contained in the nor-
a variety of problem–solving methods like heuristic scoring mal wiki. Thus, the knowledge is embedded “in–text”, i.e.,
rules, decision trees, set–covering models, and case–based the textual representation of the actual knowledge is jointly
reasoning. edited together with the textual content of a wiki page.
In this section, we briefly introduce the basic concepts of Figure 2 shows a screenshot of the edit pane of the wiki page
KnowWE, i.e., the creation of new knowledge, the inte- “Swimming” of a knowledge wiki for the consultation and
gration of explicit knowledge into the normal wiki context, selection of a form of sport (see case study in Section 5 for
and the extensions of the wiki for a structured problem– more details). Thereafter, explicit knowledge is added to the
solving process. Throughout the sections we use an exem- normal wiki text surrounded by the special tag Kopic (for
plary sport recommendation system, that tries to select ap- knowledge topic). In the example, we see the textual defi-
propriate forms of sports as solutions for given user inputs nition of a set–covering model for the solution “Swimming
(i.e., the entered preferences). (occasional)”, i.e., the listing of typical preferences/findings
that would derive this solution as an appropriate recom-
In Figure 1 the standard interface of KnowWE is shown: mendation. Besides set–covering models the knowledge wiki
user inputs can be given by (a) inplace–answers of an anno- is able to process further types of knowledge like decision
trees and (heuristic scoring) rules. We describe the possible
1
http://www.twiki.org knowledge representations in Section 3 in more detail.
Figure 2: Creating an article on “Swimming” with the definition of set–covering knowledge.
The user is supported by a help page describing the syntax one wiki page for one solution (or a coherent group of so-
of the knowledge wiki extensions and by an auto completion lutions). The corresponding knowledge is captured on this
feature. The auto completion suggests findings and solu- page within the tag “Kopic”. In consequence, we usually
tions, that are defined in the current or other wiki pages, get a large number of knowledge bases for the entire wiki.
and thus encourages the reuse of already known ontological These knowledge bases are loosely coupled by an alignment
concepts. A syntax check gives verbose feedback in the case process that automatically aligns user inputs with the same
of an incorrect use of definitions. name and type. The alignment process can be simplified
by limiting the allowed inputs to a pre–defined terminology.
2.2 Knowledge Integration Then, new knowledge bases to be inserted are bound to use
The entered text and knowledge, respectively, is stored by this fixed set of possible user inputs. In this case, the inputs
simply using the “Save” button, and usually the page is then of the particular knowledge bases are trivially aligned to the
filed to the repository. KnowWE additionally extracts the corresponding inputs pre-defined in the global ontology.
distinguished parts tagged by “Kopic” in order to compile
an executable knowledge base. The knowledge base is then 2.3 Knowledge Consumption
stored in the knowledge repository. Both, the repository With knowledge consumption we basically consider the pro-
of wiki pages and the repository of knowledge bases, are cess of (interactive) problem–solving when the defined knowl-
defining the knowledge wiki repository, which is depicted in edge is used. In contrast, today’s problem–solving in the
Figure 3. web typically comprises the search of appropriate web sites
and browsing some of them in order to retrieve sufficient in-
formation for solving the actual problem. We call this pro-
Knowledge Wiki Repository
cedure manual problem–solving. Common places for man-
wiki article repository ual problem–solving are knowledge clusters in the web: bul-
save page letin boards and wikis are prominent sources of collaborative
Knowledge Wiki Article
- (annotated) wiki text knowledge clusters, i.e., places where many people capture
- knowledge
knowledge base
and share their knowledge. Examples for wikis can be found
extracted and
compiled
repository in various documentation projects of open–source software,
knowledge the encyclopedia Wikipedia and many enterprise wikis. In
knowledge wikis we try to enhance the manual problem–
solving process described above by knowledge–based tech-
Figure 3: Workflow for saving articles of the knowl- niques: The wiki still provides the content to be read by
edge wiki. the user, but adds interactive elements and offers structured
dialogs to solve the problem in a more formalized way.
In the context of recommendation wikis we commonly define In such an interactive problem–solving session the user en-
ters findings into the knowledge wiki in order to derive ap- the training goals of the user that should fit with the ques-
propriate solutions. User inputs are collected by knowledge tioned form of sports.
services, that contain the corresponding knowledge base but
are also responsible for the data acquisition strategy. Inputs Since the given user inputs are not only submitted to the
from a particular knowledge service are propagated to a bro- currently active knowledge base but also to all other rele-
ker that aligns the respective inputs to globally known on- vant knowledge bases contained in the wiki, further solu-
tological concepts and subsequently stores the aligned con- tions (e.g., forms of sport) are derived as possible solutions.
cepts in a central blackboard. In consequence, all further This possibility for generating differential solutions during
knowledge services are notified of the newly aligned concepts the clarification process enhances the problem–solving capa-
and their particular value is propagated to the correspond- bilities of a knowledge wiki when compared to a traditional
ing knowledge bases. Thus, an entered finding of a user is wiki application.
not only given to the currently active knowledge base, but
also to all other knowledge bases in the wiki that share the 2.3.2 In–Place Answers
particular finding (see Section 2.2). Subsequently, reasoning Often, users are not comfortable with answering structured
results of every registered knowledge base are again returned questions but are more used to solve a specific problem by
to the blackboard for further broadcasting and interpreta- browsing (mostly appropriate) texts, i.e., by manual problem–
tion. solving. For this reason, knowledge wikis additionally of-
fer the possibility to make in–place answers, which allows
for a seamless acquisition of findings during the browsing
Blackboard
process. Here, tagged text phrases with a distinct seman-
aligned inputs aligned solutions tics provide pop–up menus to answer questions during the
browsing process. For example, in Figure 1 the click on the
text phrase “endurance” activates a pop–up asking for the
update “Training Goals” of the user, where “endurance” is a pos-
sible answer. As the structured problem–solving approach
Alignments described above, the entered findings are also given to the
inputs align Broker problem–solving engine in order to derive suitable solutions.
In summary, in–place answers provide a technique for the
solutions
smooth integration of unstructured browsing and structured
problem–solving.
propagate propagate In this section, we briefly described the main ideas of the
propagate knowledge wiki KnowWE that supports knowledge–based
recommendation tasks in a collaborative way. In the follow-
ing section, we introduce a selection of knowledge markups
Knowledge Service Knowledge Service Knowledge Service of KnowWE in more detail.
[KS1] [KS2] [KSn]
Knowledge Knowledge Knowledge
3. KNOWLEDGE MARKUPS FOR WIKIS
Base 1 Base 2 ... Base n Knowledge markups are textual representations of “knowl-
edge” in arbitrary forms. In this paper, we propose textual
representations for different types of knowledge representa-
tions, that can be easily embedded into the normal wiki text.
Here, the syntax of the knowledge markup should be as sim-
Figure 4: Blackboard architecture for the dis- ple as possible in order to allow for an intuitive creation and
tributed problem–solving of the knowledge wiki evolution of the knowledge together with the normal wiki
KnowWE. text. In the best case, typical wiki users are capable to
understand and use the knowledge wiki syntax without a
thorough training.
Figure 4 depicts the communication paths during a dis-
tributed problem–solving session using a blackboard archi- In general, we enclose the definition of a knowledge base in a
tecture with a simple broker for alignments. Within the wiki page with the tag ... ,
proposed knowledge wiki we distinguish two possible ways where theID is the unique identifier of the knowledge base.
for the acquisition of user inputs. We discuss them in more In this Kopic tag further sub–tags are used for the particular
detail in the following. knowledge representations.
2.3.1 Structured Data Acquisition An important issue is the understandability of the knowledge
The developer can add links to any wiki page that reference representation itself: we provide (heuristic scoring) rules, de-
to a structured questionnaire for a solving a problem in a cision trees, and set-covering models as possible knowledge
classic knowledge–based manner, e.g., Figure 1(b) displays representations. Furthermore, we plan to include case–based
a standardized interview generated from a knowledge base. reasoning in the system, since cases are probably the most
intuitive representation to formalize experience knowledge.
In the example, the user clarifies the appropriateness of the In the following, we introduce the particular knowledge rep-
specific sports type by answering a couple of questions, e.g., resentations and their markup, respectively, in more detail.
3.1 Rules of and collects all rules defined for the correspond-
Rules are certainly the most applied knowledge representa- ing knowledge base. The order of rules is not meaningful,
tion for building intelligent systems. A rule r = cr → ar e.g., with respect to a conflict resolution strategy of rule
derives facts as defined in its consequent (rule action) ar , if engines.
the specified rule condition cr is satisfied. Facts derived by
the rule can be interpreted as solutions or further inputs that
are used in conditions of other rules. The rule condition typ-
3.2 Decision Trees
The representation of classification knowledge using deci-
ically consists of an arbitrary combination of conjunctions
sion trees is very popular in machine learning research, but
and/or disjunctions constraining the user inputs. For sake
is also widely used for building knowledge systems manu-
of simplicity we distinguish two basic types of rules, that can
ally. A tree–like structure cannot be represented directly in
be used in the knowledge wiki: abstraction rules for deriving
a textual notion. Therefore, we have decided to use hyphens
new input facts and scoring rules for deriving a new state of
(“-”) in order to express the depth of a particular tree node.
a solution. Then, the consequent of the rule either assigns a
The root of a tree has no preceding hyphen, whereas the
value to an input (abstraction rule), or derives a new state
ancestors of a root are depicted with an increasing number
for a particular solution (scoring rule).
of hyphens. The following example shows the two decision
trees Naive Sport Advisor and Muscle Questions (the line
Scoring Rules. Scores are used to represent a qualita-
numbers are only added for describing the particular lines).
tive approach for deriving solutions with symbolic confirma-
tion weight. These weights state the degree of confirmation
1|
or disconfirmation of a particular solution. In this way, a
2| Naive Sport Advisor
symbolic weight c expresses the strength for which satis-
3| - Training goals [oc]
fied rule condition will confirm/disconfirm the solution s.
4| -- endurance
The definition and semantics of scoring rules goes back to
5| --- Physical problems [oc]
the INTERNIST/QMR project [7]. Analogous to the repre-
6| ---- knees
sentation of the d3web rule system [1] we distinguish seven
7| ----- Swimming (!)
positive weights (P1, . . . , P7) and seven negative weights
8| ---- no problems
(N1, . . . , N7). Here, the weight P7 stands for the categoric
9| ----- Running (!)
derivation of a solution, the counter–weight N7 yields the
10| -- increase muscles
categoric exclusion of a solution. The remaining weights
11| --- Muscle Questions
are defined in a way, so that the aggregation of two equal
12|
weights results in the weight of the next higher weight, e.g.,
13| Muscle Questions
N3 + N3 = N4; two equal weights with opposite sign nullify,
14| - Favorite regions of muscles [mc]
e.g., N3 + P3 = 0.
15| -- arms
16| ...
In the context of knowledge wikis the readability and in-
17|
tuitiveness of the markup is crucial for the success and its
application, respectively. Therefore, we decided to not use
an already existing standardized markup for (horn clause) Inputs. Inner nodes of a decision tree define the user in-
rules like SWRL/RuleML [4], but to promote a more com- puts with their type information in one line. In the example
pact and human–readable notion. above, three questions are defined in the lines 3, 5, and 14.
The type of an input is defined in brackets right after its
In the following example two rules are given: the abstraction
name, e.g., [oc] stands for a one–choice input, [mc] stands
rule r1 derives the body-mass index BMI as a new fact, if the for a multiple–choice input, and [num] stands for a numeric
two inputs Height and Weight are defined and greater than input. The possible answers of the particular inputs (with
zero. The scoring rule r2 adds the new scoring weight P4
indent i) are defined in the subsequent lines using an in-
to the score of the solution Running, if the user has entered
dent increased by one, i.e., i + 1. For example, the question
the input Training Goal is endurance but has not answered Training goals (line 3 with indent i = 1) defines the possible
the question Physical Problems with the value knees. answers endurance (line 4) and increase muscles (line 10),
both with indent i = 2. Besides the creation of the user in-
puts a dialog strategy is also defined by decision trees: pos-
// Abstraction rule r1 sible answers of an input are denoted in an extra line of the
IF (Height > 0) AND (Weight > 0) markup. If such an answer is followed by a user input with
THEN BMI = (Weight / (Height * Height)) an indent increased by one, then this input is interpreted as
a follow–up input to be presented when the previous input
// Scoring rule r2 was answered with the given value.
IF ("Training goals" = endurance)
AND ("BMI" < 30) In knowledge wikis we also use the markup of decision trees
AND NOT("Physical Problems" = knees) to define new user inputs. Then, the attachment of solutions
THEN Running = P4 and indications at the leafs of a tree are optional.
Solutions/Indication. The leafs of a decision tree are lines
that have no immediate subsequent line with a larger num-
The surrounding tag is used as a sub-tag ber of hyphens, e.g. lines 7, 9, and 11. Typically, solutions
are derived in the leafs of a decision tree by writing a scor- we would expect to observe the feature “Favorite regions of
ing weight in parentheses right after the name of the solu- muscles” with value “legs” or “bottom” etc.
tion. We use scoring weights that were already introduced
for scoring rules (cf. Section 3.1) Alternatively, solutions can
be derived categorically by using a exclamation mark, e.g., in Running
line 9 the solution Running is derived categorically by “(!)”.
Besides solutions the leaf of a decision tree can also contain
the indication of another decision tree, e.g. as the decision
tree Muscle Questions is called in line 11. Then, another de-
cision tree is activated at this point of interview instead of
deriving a solution. The activation of other decision trees al- Favorite regions of muscles Training goals in {reducing
...
in {legs, bottom} weight, endurance}
low for the modularization of larger decision trees into com-
ponents, as for example proposed by the pattern heuristic
decision tree [9].
Figure 5: A visual notion of set–covering models.
The most prominent advantage of decision trees is their in-
tuitive definition of a dialog control, i.e., the structuring
and order of inputs to be presented to the user. In the ex- For the application of set–covering models in knowledge wikis
ample above, the input Physical problems is only presented we introduce the simplified version set-covering lists: here,
if the preceding input Training goals was answered with for each solution a collection of inputs is defined that are
endurance. Thus, a compact and meaningful interview is typically observed/entered when the solution is appropri-
defined very easily. Decision trees having the shown size ate; the inputs are enclosed in braces. The example below
are very easy to understand and to maintain. However, for shows a set–covering list for the solution Running:
larger decision trees it is recommendable to partition the tree
logic in a set of sub–trees and refer to these sub–trees from
a main tree. This is sketched with the two exemplary trees
Naive Sport Advisor as the main tree and Muscle Questions Running {
as a sub–tree. Favorite regions of muscles = legs,
Favorite regions of muscles = bottom,
The surrounding tag is used as a sub- Training goals = reducing weight,
tag of and collects all decision trees defined for the Training goals = endurance,
corresponding knowledge base. Since trees can be easily for- Calorie consumption (30min, 75kg) = high,
mulated using XML it would have been an obvious approach ...
to also represent the decision tree by an XML structure. Al- }
though this would yield a reduced compilation effort due to
the existence of well–established XML parsers the resulting
markup appears to be too verbose and complex for standard
wiki users. In contrast, the proposed markup is by far more Typical user inputs are listed that were expected to be ob-
compact and less vulnerable to syntax errors made by the served for the sports form Running, e.g., the preferred mus-
user when defining the decision tree. cle parts to be trained would be answered with legs and bot-
tom, and the goals of doing the sport are (amongst others)
reducing weight and endurance.
3.3 Set–Covering Models
The knowledge markups introduced above considered deduc- The surrounding tag is used
tive knowledge representations, that are commonly useful as a sub-tag of and collects all set–covering lists
for defining classification knowledge. However, in the con- defined for the corresponding knowledge base.
text of recommendation systems it is sometimes preferable
to implement an abductive knowledge representation.
3.4 Reuse of Terminologies
Set–covering models [10] are a prominent and intuitive ex- For every solution we commonly create a new wiki page, that
ample of an abductive knowledge representation. Solutions describes its characteristics as text and multimedia (as done
are described by features that can be typically observed in normal wikis), and also defines explicit problem–solving
when the solution is present. When the user enters inputs knowledge to derive the particular solution for possible user
the best matching solution is selected, i.e., the solution that inputs.
best covers its expected features with the entered findings.
As a special feature, such models can be incrementally ex- With the growth of the wiki a number of knowledge bases
tended by background knowledge in order to improve the is defined distributed over the available wiki pages of the
expressiveness of the knowledge [3]. entire wiki. The particular knowledge bases are connected
with each other by using user inputs with the same names.
For example, the features can be weighted with respect to The reuse of inputs can be encouraged by providing a pre–
their importance for the respective solution or partial simi- defined terminology, that is referenced in every wiki page.
larities can be defined to refine the abductive matching pro- In a particular knowledge base we reference to a pre–defined
cess. In Figure 5 a visual notion for describing the sport terminology by adding the optional attribute terminology
“Running” is depicted; e.g., for a present solution “Running” to the Kopic tag, e.g., in the following markup
ing for the “Training Goals” of the user, where “endurance” is
... a possible answer. As described in Section 2.3 the acquired
user inputs are mainly used for problem–solving.
the knowledge base with ID myKopic references to the ter- 5. CASE STUDIES
minology of another knowledge base with the ID kopicID The applicability of knowledge wikis and their markup, re-
having the namespace WikiPage. spectively, was evaluated in two preliminary case studies.
4. SEMANTIC ANNOTATION OF KNOWL- 5.1 Sport Recommendation Wiki
EDGE WIKIS The first case study was intended as a “proof–of–concept”
In the previous section, the inclusion of explicit problem– experiment: here, an exemplary recommendation system
solving knowledge was described. Ontological concepts (in- for forms of sport was implemented by three students, that
puts, solutions) and the corresponding derivation knowledge were already familiar with the wiki system and the underly-
is easily defined in a textual manner together with the text ing knowledge representation. The recommendation system
of the corresponding wiki page. For each knowledge base a comprises 56 knowledge bases for 31 of the most common
link is created in the view mode of the wiki; the link initi- forms of sports (some sports are redundantly defined reflect-
ates an interview to collect user inputs in a structured way. ing different opinions of the students), and defines in total 38
In this section, we describe a more integrative approach for user inputs. The knowledge bases mostly use set–covering
collecting user inputs: by annotating particular phrases of knowledge for the definition of the derivation knowledge, but
the wiki text the user is able to answer distinguished inputs some decision trees are also included.
in–place during browsing a wiki page. With this first case study the general applicability of the
knowledge wiki and its markup was evaluated. An initial
User inputs are used to annotate text phrases, when they table–like representation of set–covering knowledge for defin-
were previously defined in knowledge bases of an arbitrary ing knowledge for multiple solutions was discarded, since the
wiki page. Similar to the annotation techniques known from markup proved to be not very comfortable for the acquisition
semantic wikis, e.g. [5, 11], in knowledge wikis the semantic and maintenance of the relations. Because the knowledge
meaning of text phrases can be annotated by concepts of the bases in a knowledge wiki mostly define knowledge for a sin-
input terminology. In contrast to semantic wikis the annota- gle solution, a table representation could not show its actual
tion in knowledge wikis is mainly used for problem–solving, power. Furthermore, tables are often difficult to maintain in
i.e., by creating interactive menus to enable data entries of the textual edit pane of a wiki. Instead a list–like markup
the user within a wiki page. The presented knowledge wiki of set–covering knowledge as presented in this paper was in-
introduces the markup troduced. This was experienced to be more compact and
intuitive for the definition of the knowledge for single so-
lutions. In summary, the results were encouraging and a
%TAG{ns="a" input="b" text="c"}% second, now larger case study was initiated.
in order to annotate the displayed wiki text c with an input 5.2 General Recommender Wikis
concept b known from the knowledge base with the names- The second case study considered the creation of knowl-
pace a. If the optional namespace ns is not specified, then edge wikis with a larger group of initially untrained per-
the knowledge base contained in the corresponding wiki ar- sons. In total, 45 students started to implement 11 knowl-
ticle is used to align the annotated input. In the exam- edge wikis with varying sizes. The students formed groups,
ple below, an extract of the normal wiki text of the article where each group undertook the development and evolution
Swimming is annotated in order to link text phrases with of one knowledge wiki. For example, knowledge wikis for
corresponding user inputs, i.e., questions. meal selection, recommenders for holidays and recreation, a
movie advisor, and a wine selection were created. The un-
Swimming is good for trained students were initially introduced into the concepts
%TAG{input="Training goals" of the knowledge wiki and its markup (about 1h). Then,
text="reducing weight"}% the students started to build initial versions of their sys-
successfully or to train tems. A trivial movie recommender was included as a demo
%TAG{input="Training goals" text="endurance"}%. knowledge wiki and helped the new users to get familiar
with the system. In fact, most of the new knowledge bases
were implemented by simply copying, pasting, and adapt-
Here, the input “Training goals” defined in the wiki page ing the demo markup. The set–covering list appeared to
“Swimming” and its included knowledge base “Swim” is an- be the predominant knowledge markup for the second case
notated twice: first, with the text “reducing weight” and study, since it was experienced to be intuitive and compact
second with the text “endurance”. in most of the cases. A significant disadvantage of set–
covering models are their inability of representing negative
In the view mode of an wiki article for the tagged text (exclusion) knowledge, i.e., the presence of user inputs for
phrases pop–up menus are generated that enable the user which a solution should be discarded from the recommen-
to answer the annotated inputs in–place. For example, Fig- dations. This problem was tackled by the introduction of a
ure 1 shows the view mode of the wiki page “Swimming”; the hybrid rule–extension: here, the users are able to define rule
conditions under which a solution is excluded even when the exploit explicit problem–solving knowledge to handle stated
set–covering result was positive. The second case study pro- problems in a more knowledge–based way.
duced about 700 knowledge bases spread over 11 knowledge
wikis; we counted about 2500 edits of the particular knowl- In the near future we are planning to exploit existing learn-
edge bases not including the initial creation of the projects ing methods for automatic annotation: Since the manual
(the logs were not available from the beginning of the case annotation of text phrases in the wiki text appeared to be
study). very time–consuming, we want to simplify this approach by
(semi–)automatic methods. Besides the introduction of ap-
propriate tools attached to the edit pane of the wiki to insert
annotation templates by a mouse click, we are also planning
In summary, we experienced the proposed knowledge markup to suggest annotations based on the results of learning meth-
as an intuitive and compact representation to enable nearly ods.
untrained users to capture and maintain knowledge in a
collaborative way. Whereas the markup for implementing
derivation knowledge (rules, set–covering lists) was success-
7. REFERENCES
[1] J. Baumeister. Agile Development of Diagnostic
fully applied in both case studies, the semantic annotation
Knowledge Systems. IOS Press, AKA, DISKI 284,
of text phrases was only evaluated in the first case study.
2004.
Since, the manual annotation of text appeared to be very
time–consuming the simplification of this approach, e.g., by [2] J. Baumeister, J. Reutelshoefer, K. Nadrowski, and
semi–automatic methods, is an important issue for future A. Misok. Using Knowledge Wikis to Support
work. Scientific Communities. In Proceedings of 1st
Workshop on Scientific Communities of Practice
(SCOOP), Bremen, Germany, 2007.
6. CONCLUSIONS AND OUTLOOK [3] J. Baumeister, D. Seipel, and F. Puppe. Incremental
The development of larger knowledge systems and especially Development of Diagnostic Set-Covering Models with
their maintenance is still a complex and open problem. Even Therapy Effects. International Journal of Uncertainty,
before the success of Web 2.0 applications with the collab- Fuzziness and Knowledge-Based Systems,
orative creation of information and knowledge, e.g., by tag- 11(Suppl.):25–50, November 2003.
ging and writing, many researchers have started to think [4] I. Horrocks, P. F. Patel-Schneider, S. Bechhofer, and
about the collaborative capture and update of knowledge D. Tsarkov. OWL Rules: A Proposal and Prototype
systems. The presented work introduced a collaborative Implementation. Journal of Web Semantics,
approach for knowledge capture and its necessary markup 3(1):23–40, 2005.
tightly integrated in a wiki system. Here, wiki systems al- [5] M. Krötzsch, D. Vrandecic, and M. Völkel. Semantic
low not only for the development of unstructured content MediaWiki. In Proceedings of the 5th International
like text and multimedia, but also provide the intuitive ac- Semantic Web Conference (ISWC06), LNAI 4273,
quisition of explicit knowledge. From our point of view, the pages 935–942, Berlin, 2006. Springer.
most important aspect for the success of such a proposal is [6] B. Leuf and W. Cunningham. The Wiki Way: Quick
the presence of intuitive markups, in order to enable even Collaboration on the Web. Addison-Wesley, New York,
untrained/little trained users to become knowledge wiki de- 2001.
velopers. We have presented different possible knowledge [7] R. A. Miller, H. E. Pople, and J. Myers.
markups that are easy to understand and to apply, and that INTERNIST-1, an Experimental Computer-Based
are used to collaboratively build knowledge wikis for recom- Diagnostic Consultant for General Internal Medicine.
mendation tasks. The case studies showed the applicabil- New England Journal of Medicine, 307:468–476, 1982.
ity of the presented approach and especially the proposed
[8] F. Puppe. Knowledge Reuse among Diagnostic
knowledge markups.
Problem-Solving Methods in the Shell-Kit D3.
International Journal of Human-Computer Studies,
Most related to knowledge wikis are the approaches pro-
49:627–649, 1998.
posed for the development of semantic wikis. For example,
Semantic MediaWiki [5] enhances a normal wiki semanti- [9] F. Puppe. Knowledge Formalization Patterns. In
cally in order to annotate wiki texts with explicit ontological Proceedings of PKAW 2000, Sydney, Australia, 2000.
concepts. Annotations are placed in–text and are based on [10] J. A. Reggia, D. S. Nau, and P. Y. Wang. Diagnostic
the top concept the actual wiki page is describing. Prop- Expert Systems Based on a Set Covering Model.
erties for that concept can be easily formalized within the Journal of Man-Machine Studies, 19(5):437–460, 1983.
normal wiki text. Semantic wikis usually provide markups [11] S. Schaffert. IkeWiki: A Semantic Wiki for
for ontological relations and attributes using a web ontology Collaborative Knowledge Management. In 1st
language like OWL. In contrast, the ontological expressive- International Workshop on Semantic Technologies in
ness of the proposed knowledge wikis is limited to two basic Collaborative Applications (STICA’06), 2006.
objects, i.e., input concepts and solution concepts. How-
ever, we additionally support various knowledge markups to
formalize problem–solving knowledge in a simple manner.
Semantic wikis support the manual problem–solving pro-
cess, i.e., the search for appropriate information for a given
problem, by semantically enhanced search engines and dy-
namic linking between related concepts. Knowledge wikis