A couple of semantic wikis have been proposed to serve as collaborative knowledge engineering environments { however, the knowledge of almost all systems is currently based on the expressiveness of OWL (Lite/DL). In this paper we present the concept of a semantic knowledge wiki that extends the capabilities of semantic wikis by strong problem-solving methods. We show how problem-solving knowledge is connected with standard ontological knowledge using an upper ontology. Furthermore, we discuss di erent possibilities to formalize problemsolving knowledge, for example by semantic knowledge annotation, structured text and explicit markups.
Recently, di erent approaches of semantic wikis have been presented as
applications especially designed for the distributed engineering of ontological knowledge,
for example see IkeWiki [
Based on the expressiveness of OWL (Lite/DL) the de ned ontologies are
able to capture a wide range of general knowledge but lack in the possibility
to represent active problem-solving knowledge that is necessary to generate and
drive a (semi-)automated problem-solving session with a user. Such knowledge
typically relates the class of ndings { provided as user inputs and describing
the current problem { with the class of solutions that are derived for the given
problem description. In previous work we presented the concept of knowledge
wikis as an extension of standard wikis adding the possibility to capture,
maintain, and share explicit problem-solving knowledge [
In this paper we describe the (re ned) concept of semantic knowledge wikis that are interpreted as an extension of semantic wikis. Besides basic ontological knowledge { such as the de nition of classes, taxonomic and user-de ned properties { a semantic knowledge wiki is able to represent problem-solving knowledge that is applied on selected classes of the ontology. The problem-solving knowledge can be seen as an external knowledge source for changing the values of concept instances; for example in most of the cases the state of a solution instance is set to the value \established". Beyond that it is not intended that the problem-solving knowledge interacts with other knowledge de ned in the ontology. In future work, we will consider the exchanging semantics of problem-solving knowledge with the knowledge de ned in the ontology, as for example it is currently done in the context of the RIF working group1. In summary, a semantic knowledge wiki represents a distributed knowledge engineering environment not only representing semantic relations between the concepts of an ontology but also explicit derivation knowledge.
In contrast to trained knowledge engineers { well educated in knowledge representation and reasoning { we adress experienced users to act as \ad-hoc knowledge engineers". For this reason, the provided interfaces and markups of the wiki need to be as simple as possible in order to lower the barriers of knowledge acquisition. Furthermore, in running projects we experienced the requirement to handle a mixed granularity of the represented knowledge. An interesting research question is to nd a collection of suitable markups that can cope with the di erent types of knowledge and its granularity, respectively.
In this paper, we rst describe the basic concepts of a semantic knowledge wiki by introducing an upper ontology for problem-solving. This ontology represents the basic classes and properties that are used in a typical problem-solving process. Moreover, this ontology is used as the basis in every new wiki project, since newly de ned concepts are implicitly or explicitly aligned to classes of the upper ontology. We also introduce di erent types of markups for the de nition of problem-solving knowledge. The markups take into account that knowledge can be \formalized" in many di erent ways, ranging from explicit models and rule bases to semantically annotated text or structured text phrases. 2
As discussed above every (semantic) wiki page describes a distinct concept together with formalized properties linking the entity with other classes. In a knowledge wiki we also capture the problem-solving knowledge that is necessary for deriving the particular concept. Then, every wiki page embeds not only semantically annotated text and multimedia but also explicit problem-solving knowledge. 1 RIF WG wiki: http://www.w3.org/2005/rules/wiki/RIF Working Group
As a typical use case, the user of a semantic knowledge wiki can browse the contents of the wiki in a classic web-style {possibly using semantic navigation and/or semantic search features. Moreover, he/she is also able to start an interactive interview where giving a problem description. Based on these inputs an appropriate list of solutions is presented that are in turn linked to the wiki pages representing these particular concepts. Thus, every solution represented in the wiki is considered during a problem-solving process. Instead of using an interactive interview mode the user can enter ndings inline by clicking on inline answers embedded in the normal wiki page. These inline answers are generated based on the semantic annotations made in the article.
In the following we brie y describe the processes of capturing and sharing
knowledge in the semantic knowledge wiki KnowWE [
Semantic annotations and knowledge is edited in the mandatory edit pane of the wiki together with standard wiki content like text and pictures. At the moment
KnowWE proposes the textual acquisition of annotations and knowledge in the edit pane, thus a collection of textual markups for annotations and knowledge is required. For a new solution a corresponding wiki page with the solution's name is created. The wiki page includes describing text in natural language and the explicit knowledge for deriving the solution. In this paper, we introduce the concept of distributed knowledge engineering with knowledge wikis, and we demonstrate the methods and techniques using the toy application of a sports advisor wiki. The running example considers a wiki providing knowledge about di erent forms of sports, both in textual and in explicit manner. Explicit knowledge can be used to derive an appropriate form of sport for interactively entered (user) preferences. Besides such a simple recommendation application the wiki can be used for a variety of tasks brie y sketched in the case study.
For example, in Figure 1 we see the edit pane of an article describing the form of sports \Swimming": Standard text is semantically annotated by the particular properties explains and isContradictedBy for which their meaning is described in the following. Additionally, the rst part of a formalized rule base is shown at the bottom of the edit pane. Here, knowledge for deriving and excluding the solution \Swimming" is de ned. Besides rules derivation knowledge can be formalized in di erent manners, for example, explicit set-covering models, structured texts, semantic knowledge annotations. We discuss the di erent markups in the rest of the paper.
(a) (b) (c)
When saving a wiki article the included knowledge is extracted and compiled to an executable knowledge base. In consequence, we arrive at one separate knowledge base for each wiki article capturing the derivation knowledge for the corresponding concept of the article. With the increasing number of wiki articles the number of knowledge bases will also increase. As we see in the next section the concepts created in the wiki are naturally aligned due to the upper ontology of the knowledge wiki. Furthermore, the developers are encouraged to reuse a pre-de ned application ontology which is build on the xed upper ontology. However, ad{hoc de ned ndings not corresponding to the application ontology can be easily aligned by expressing alignment rules, that match these concepts with concepts of the application ontology. 2.2
Besides standard ways of knowledge sharing in (semantic) wikis like (semantic) searching and browsing we provide two ways for a more interactive knowledge sharing in knowledge wikis: rst, every wiki page can generate an interactive interview from the included knowledge base by asking questions represented by the ndings used in the knowledge base, as for example depicted in Figure 2 a. Second, semantic annotations in text are used to o er inline answers, i.e., clickable text in the article asking for meaningful facts corresponding with the highlighted text, cf. Figure 2 b. In both ways a new nding instance is entered into the knowledge wiki corresponding to the clicked nding object. The instance is propagated to the knowledge wiki broker that in turn derives solutions based on the entered ndings. The propagation paths of the broker are depicted in Figure 3. The entered nding instances are propagated to the broker which aligns Upper Ontology Application Ontology inputs solutions align
Blackboard aligned inputs
aligned solutions update Broker propagate propagate
Knowledge Service [KS1]
Knowledge Base 1 Wiki Article 1 . .
.
Knowledge Service [KSn]
Knowledge Base n Wiki Article n the ndings to a global application ontology (building on an upper ontology) and then les the aligned instances to a central blackboard. Also, the broker noti es all knowledge bases contained in the wiki for the new fact added to the blackboard and gives the possibility to derive solutions based on the currently available facts. Derived solutions are also propagated by the broker as new facts. With the use of this simple broker/blackboard architecture we are able to allow for a distributed problem-solving incorporating the multiple knowledge bases of the wiki. Therefore, all solutions represented in the knowledge wiki can be derived at any page; already derived solutions are presented at the right pane of the wiki as for example shown in Figure 2 c. Here, the solutions "Cycling" and "Jogging" were derived as the most appropriate solutions, even though the ndings were entered on the page describing the solution "Swimming". The presented example can be seen as a specialized case of semantic navigation.
In comparison to our previous work [
Studer et al. [
In the following we describe an upper ontology for problem-solving that is used in the semantic knowledge wiki KnowWE. An excerpt of the upper ontology is shown in Figure 4 a; we omitted less important concepts like textual inputs and values for clarity. All unlabeled associations denote subClassOf relations.
The concept Input plays a key role and allows to describe the world state as a set of variables. Inputs are grouped by the concept Questionnaire to structure inputs into meaningful clusters. The two main subclasses of Input are InputChoice and InputNum to de ne variables with discrete (named) values and numerical value ranges, respectively. Accordingly, a corresponding value subclassing Value is assigned to each Input. The concept Solution denotes a special type of a onechoice input that is not entered by the user but derived by a knowledge base, thus representing the nal output of a problem-solving session. The value range of a solution is restricted to the possible values Established, Suggested, Undened, and Excluded for expressing the current derivation state of the particular solution.
A concrete problem-solving session is represented by an instance of the concept PSSession where a knowledge consumer describes his/her current problem by entering the values of the corresponding observed inputs. The reasoning processes of di erent users are completely independent from each other as each user is describing his own speci c problem instance. The assignment of a value to a (a) (b) corresponding input is captured by the concept Finding, depicted at the top of Figure 4 a.
The proposed knowledge wiki allows for a free and general use of various, alternative knowledge representations to actually derive the concrete solutions de ned in the application ontology. For this reason, derivation knowledge is represented in the upper ontology only in a very general manner, as depicted in the left lower corner of Figure 4 a. For the speci cation of problem-solving relations we introduce the general object properties explains and isContradictedBy with Solution as the domain and LogicExpression as its range: The abstract concept LogicExpression is subclassed by CompositeExpression, which allows fo the composition of logical expressions over ndings by the subclasses Conjunction, Disjunction, and Negation. The semantics of the properties explains and isContradictedBy are described more detailed in the context of the XCL knowledge representation (eXtensible Covering List) in Section 4.
The concrete inputs and solutions of a new wiki application are de ned in the application ontology. With the two special wiki pages WikiFindings and WikiSolutions the structure of the application ontology is maintained: The (user) inputs together with their values are de ned in the article WikiFindings using the special textual markup Kopic. Within this tag we textually de ne new inputs and their corresponding values together with questionnaires grouping the particular inputs. De ned solutions and inputs of the application ontology are automatically subclassing the corresponding concepts of the upper ontology. Figure 4 b shows a part of the input hierarchy of the sports advisor demo already mentioned before. With one dash we denote a new input followed by its type de nition, for example [oc] for one-choice inputs and [num] for specifying numeric inputs. For choice inputs the possible values are listed in the following lines with an additional preceding dash. Analogously, the solutions of the application ontology are organized in the article WikiSolutions. In summary, the application ontology is created and modi ed in a wiki-like way, i.e., by editing the wiki pages WikiFindings and WikiSolutions.
For the knowledge engineering task we propose an evolutionary process model
as introduced by Fischer [
In the previous section we introduced an upper ontology for problem-solving representing the basis of an application ontology. This application ontology denes the speci c inputs and solutions of the particular application domain. As mentioned earlier, every wiki page is able to capture problem-solving knowledge relating de ned inputs with the corresponding solution of the particular wiki page. Since we aim to motivate experienced user to act as ad-hoc knowledge engineers the problem-solving knowledge needs to meet the following requirements: 1. easy to understand and formalize, 2. a compact and intuitive textual representation, 3. yields a transparent and comprehensible inference process.
This will help to break down the initial barriers when 1. making personal knowledge explicit, 2. inserting it into a wiki page text, 3. and nally evaluating the created knowledge.
As complexity in knowledge representation and inference constitutes a major barrier for contribution we face the trade-o between simplicity and expressiveness. Beneath simplicity, we have to make an open world assumption concerning the derivation knowledge for a solution concept. During the development process only a part of the total imaginable/retrievable amount of knowledge is present in the knowledge wiki. Thus, it is desirable that any subset of the ( ctional) complete knowledge can be used to derive the best possible results with respect to the given subset. Further, this subsets of course need to be extensible easily. A knowledge representation meeting this requirements needs to be based on small knowledge units which are to a great extend independent of each other. On the one hand this characteristics enables to build very small but already working knowledge bases which then can be extended subsequently step by step. On the other hand the knowledge bases show some robustness with respect to the deletion of small parts and redundant de nitions by accident or ignorance which is important within the scope of \ad-hoc knowledge engineering".
Considering the concrete problem-solving process of a knowledge consumer
we need to regard that it is unpredictable which exact subset of inputs is
actually observable, as real world situations are often diverse and wicked. Thus, it is
desirable to design the knowledge and the inference process in a way, that each
subset of entered ndings will yield appropriate solution ratings. Of course, in
this case a con dence value based on the size of the entered nding set needs
to be presented along with the resulting solution states. To cope with these
challenges we provide the wiki user a simpli ed but easily extensible version
of set-covering models [
We present three di erent textual markups to integrate simple knowledge as described above in standard wiki texts. To demonstrate the similarities and di erences of the markups we de ne knowledge in each way for the solution Swimming corresponding to the sports advisor demo. eXtensible Covering Lists (XCL) The most compact representation of the covering knowledge is its formalization as an eXtensible Covering List that is wrapped in a Kopic tag. As noted earlier the Kopic tag can be placed anywhere in the wiki article and is also used to de ne other classes of knowledge like the solutions and ndings of the application ontology. The names of the inputs and the corresponding values are matched against the de nitions made in the application ontology found in the WikiFindings article (cf., Figure 4b). In the following example an XCL model for the solution Swimming is shown. Each line represents a positive coverage of the nding by the solution and is called explains relation. The order of the listed ndings is not relevant for the inference process and thus is arbitrary. If the domain knowledge is already available as informal text, then it denotes a simple task to transfer the key ndings described in the text into basic ndings contained in an XCL.
During the inference process the best rated solution is chosen. A solution is rated by comparing the ndings de ned in the XCL against the ndings entered by the user. The rating of a solution is expressed by its covering score. As mentioned before, this numeric score is mapped to four prede ned solution states Unclear (default), Suggested, Establised and Excluded.
The basic XCL representation can be extended in multiple ways: Besides the simple listing of ndings shown above the XCL representation o ers further elements to extend/re ne the expressiveness and selectivity of the covering model that are brie y discussed in the following (the textual markup is given in paratheses): Exclusion knowledge [--]: This marks a relation such that the derivation of the solution becomes impossible to be positively derived when the relation is ful lled. This type of relation is called isContradictedBy and it sets the state of the solution to Excluded when ful lled. Such a constraining relation is de ned by two minus signs in brackets ([--]) at the end of the relation line, as for example shown in line 7 of the markup shown below. Required relations [!]: Relations can be marked as required by using a bracket containing an exclamation mark ([!]). Then a solution can only be established as a possible output when all required relations are ful lled, i.e., the corresponding ndings were positively entered by the user. An example is shown in line 2 in the following markup.
Su cient relations [++]: By adding a bracket with two plus signs ([++]) to a relation we de ne this solution to be a su cient relation. Then, the solution is always established if the corresponding nding is ful lled. We call this relation isSu cientlyDerivedBy. It is important to know that contradicting relations are dominating su cient relations.
Adding weights [ num ]: In the initial version every explains relation is
equally important when compared to the other relations of the XCL, thus
having the default value 1. The default value can be overridden for relations
in order to express their particular importance. In the textual notation the
weight is then entered in brackets at the end of the relation de nition, for
example [
Logical operators (AND, OR): A complex relation can be created by combining relations by logical operators. For example in line 2 of the model shown below the ndings medium = water and Type of sport = individual are connected by the logical or-operator (OR). The resulting knowledge demands that either medium = water or Type of sport = individual needs to be observed to full l the relation. The three basic operators of propositional logic or, and and not can be used.
Threshold values: When rating a solution the numeric covering score is mapped to a solution state. The mapping function is de ned by the threshold values (establishedThreshold and suggestedThreshold). In most cases the internal default threshold values are adequate, but for distinct solutions they can be overriden as shown in line 12-13 of the following example model. In the example, 70% of the expected and observed ndings need to be correctly observed to set the solution tot the state Established, and 50% to set the solution to the state Suggested (higher states overwrite lower states). Further, with minSupport we specify how many percent of the ndings dened in the XCL model need to be entered by the user in order to activate the solutions rating process.
The following markup shows a re ned version of the previous model of the solution Swimming using the described elements. Essentially, the already de ned relations were mostly re ned by relational extensions like su cient, contradicting and necessary properties.
Although the presented representation is experienced to be compact and intuitive for most of the users, it is clearly separated from the remaining text of the wiki article, which usually describes the same concept and its knowledge in natural language. This separation increases the risk of \update anomalies", for example if users are modifying or extending the wiki article but not the corresponding part of formalized knowledge. Therefore, a tighter integration of formal knowledge and informal text of a wiki article is desirable, and for this aim we introduce two possible approaches in the following.
Inline Annotation Many semantic wikis use inline annotation techniques to
describe semantic properties between concepts of the ontology, for example
Semantic MediaWiki [
The semantic annotation of existing sentences means less knowledge acquisition workload compared to the explicit markups introduced before. Although, standard wiki text is tightly integrated with formal knowledge the readability of the text su ers from annotations as shown above.
Structured Text A more radical approach is to omit semantic annotations
when possible and to use NLP techniques for annotating distinct parts of the wiki
text. In the context of our work, we are able to use \structured texts" since 1) the
available text needs to be mapped to a rather simple knowledge representation,
and 2) we can employ the given application ontology as background knowledge
for the concept extraction task. This is very similar to the approach of the
DBpedia project2 described by Auer et al. [
Using this technique we assume, that a distinct block of a wiki article is tagged as a \structured text". Then, this block is parsed in order to identify ndings for which set-covering relations are created. In a rst step we are working with semi-structured texts (e.g. bullet lists, tables). In the following example in Figure 5 a we show a bullet list in standard wiki syntax, where each line contains one (combined) nding explaining the solution Swimming. While the inline annotations expect exact matches we applied some lightweight linguistic methods for matching ndings in structured texts, for example simple string matching combined with stemming and synonym lists already lead to fairly good 2 DBpedia: http://www.dbpedia.org results. In the simplest case we can identify an input name that is de ned in the application ontology together with a corresponding value name, for example as found in line 5 of Figure 5 a: the text phrase \when low risk of injuries is desired" yields the nding \risk of injury = low". The nding de ned by this input-value-pair tuple can be added as a set-covering relation of the solution Swimming. Sometimes only an input is listed and humans implicitly refer to a default value of this input, especially for inputs only having \yes" and \no" as possible values (e.g. \practiced outdoor"). For this type of input we assume \yes" as the default value when creating set-covering relations. For other inputs the default answer needs to be de ned in the application ontology, otherwise the nding cannot be completely identi ed. Another popular case is appearance of the value name in the line as the only indicator of a nding, for example in line 2 in water. If the corresponding input can be clearly identi ed due to the unique (a)
(b) name of the found value, then we automatically generate a relation accordingly. We often can disambiguate the occurrence of such a nding, since most of the times humans only reduce the text to the value name if this would not result in an ambiguity. All identi ed ndings are implicitly annotated and can be used to provide inline answers as shown for example in Figure 5 b.
Although in various forms extensible the XCL representation has limited expressiveness for some type of domain knowledge. 1 <Rules-section> // Abstraction rule r1 for body mass index calculation IF (Height > 0) AND (Weight > 0)
THEN BMI = (Weight / (Height * Height)) 2 3 4 5 6 // Derivation rule r2 for solution Running 7 IF ("Training goals" = endurance) 8 AND ("BMI"<30) AND NOT("Physical Problems" = knees) 9 THEN Running = SUGGESTED 10 </Rules-section>
In order to allow for the creation of complex knowledge relations we
provide further knowledge representations to be used by more experienced users.
The textual markup of alternative representations was introduced in [
We have implemented the presented approach with the system KnowWE [
The project wiki LaDy (for "Landscape Diversity") aims to support domain specialists and interested people to collect and share knowledge in the context of the BIOLOG project. The knowledge appears at di erent levels of detail ranging from textual descriptions and multimedia to formal knowledge covering the e ects on landscape diversity. Typically user inputs consider the description of the investigated landscape, whereas solutions are de ned with respect to the biodiversity of various taxa, di erent ecosystem services and management decisions. At the moment, the knowledge wiki is under development incorporating ecological domain specialists distributed all over germany.
The participating domain specialists have neither background in knowledge representation nor in ontology engineering, and therefore the interfaces need to be as simple and intuitive as possible. In the various kick-of meetings we learned that a simple set-covering list representation was experienced to be intuitive and suitable for the rst steps. After some simple examples the requirements of the users concerning the expressiveness usually grew, and in many cases these requirements could be covered by extended covering lists as shown for example in the following. In Figure 6 a, the solution High plant diversity is de ned by a set-covering list of constrained ndings, where the second item (line 3{5) is a complex nding combining a list of atomic ndings by a disjunction and a conjunction (simpli ed example shown).
In other cases we o ered to transform the existing knowledge to a rule base, since the largest degree of expressiveness can be provided by a rule-based representation. An excerpt for a rule base is shown in Figure 6 b where the value of management productivity is de ned in correspondence of inputs such as genetic diversity and optimized soil retention. Providing a platform for both, exchanging textual knowledge and implementing explicit rules on ecosystem behaviour, LaDy provides a service to condense and to communicate knowledge needed for an e cient management of ecosystem services. 6
We have introduced the concept of a semantic knowledge wiki with the
implementation KnowWE that extends the known OWL-based expressiveness of
other semantic wikis by active problem-solving capabilities. Whereas related
approaches provide strong support to capture ontological knowledge { for example
see [
In the future we are planning to improve the power of natural language to
be used as direct input for knowledge acquisition, incorporating more linguistic
methods and controlled languages. Related work is reported by the Attempto
(a)
(b)
Fig. 6. a) Excerpt of a simpli ed version of a set-covering model for deriving \High
plant diversity" b) rules describing the value of management productivity depending
on inputs such as genetic diversity and optimized soil retention.
project [