Semantic wikis are successfully used in various application domains. Such systems combine the exible and agile authoring process with strong semantics of ontologies. The current stateoftheart of systems, however, is diverse in the sense of having a common ground. Especially, the expressiveness of the knowledge representation of semantic wikis undergoes continuous improvement. In the paper, two semantic wiki implementations are discussed, that are both extending semantic wiki implementations by strong problem-solving knowledge. We compare their approaches and we aim to condense the fundamental characteristics of a strong problem-solving wiki.
Recently, the most important development of the Internet concerned not the lower network network layers, but the higher application or service layers related to the Web technology. This is mainly due to the fact, that while the speed and storage capacities of the Web increased by orders of magnitude, its search and processing capabilities remained almost unchanged on the conceptual level.
This phenomena led, almost a decade ago, to the proposal of the Semantic Web. In this architecture a number of higher level semantic facilities built on top of the Web would allow not just to search data but to reason with knowledge . In fact, this was the point where the focus of the Web development moved from content (data) to knowledge (in a broad sense). A decade later, a number of semantic technologies is available and widely used, starting from the data structuring XML, to meta-data annotations with RDF and ontologies with RDFS and OWL. While these technologies provided knowledge encoding and representation solutions, the challenge remains to provide an ecient knowledge processing and reasoning with rules on the Web. This is in fact the point, where most of the current Semantic Web research focuses. Recent rule standards from W3C include RIF and SWRL. ? The paper is partially carried out within the AGH UST Project No. 10.10.120.105
Besides knowledge representation and reasoning, a sensible knowledge
engineering solution for the Web is another important challenge. While the Semantic
Web initiative targets mainly representation aspects, it does not directly address
the specic problems stemming from the massively parallel and collaborative
nature of the Web. Social networks, that provide specic services on top of the Web
and the Semantic Web, try to cope with these problems. Recently the wiki
technology has gained importance with respect to the collaborative knowledge
acquisition and engineering. The development of semantic wikis, such as IkeWiki [
Existing semantic wikis allow for an introduction of semantic information (e.g. meta-data, ontologies) into a wiki. In fact, they often allow to build a wiki around an ontology, which improves their conceptual coherence. Most of the semantic wikis reached a stage where the reasoning capabilities have to be added. This is where some limitations of existing solutions become exposed.
In this paper, we introduce a categorization of semantic wiki functions in order to simplify the comparison of system approaches and implementations. The categorization will concentrate on the features required during knowledge engineering activities and will omit other important aspects such as data storage and scalability of the implementations. We compare the two semantic wikis PlWiki and KnowWE according to the introduced scheme. 2
Categorization of Expressive Semantic Wikis The semantic wiki community tracks the recent developments of semantic wiki features within a matrix 3. For example, the matrix lists features such as editing paradigm, annotation mechanism , programming language and license. For systems extended by expressive knowledge formalizations we see that this categorization is too broad to capture the their special capabilities. For this reason, we propose a supplementary set of feature categories in the following, which we use to describe the wiki implementations in the latter of the paper.
We see that semantic wikis are not used in a unied application context, but are often designed to match to a more specic application area. Thus, the particular systems cannot be compared in a linear order, but show advantages and disadvantages for specic applications. A new matrix can help to simplify the selection of a system for a given work task.
Often, the systems are designed with a specic application context in mind. Possible values are: 1. Community-based ontology engineering 2. Encyclopedia-like application, e.g., Wikipedia enhancement 3 http://semanticweb.org/wiki/Semantic_Wiki_State_Of_The_Art
The semantic wiki represents the developed knowledge in a particular format. This sub-area species the type of structure, how the atomic concepts of the knowledge base are represented, it names the used knowledge representation language, and discusses if/how additional sources of knowledge are connected. 1. Subject granularity: What is the level of detail of the atomic concepts represented in the knowledge base. This also corresponds to the main structuring paradigm of the system; i.e., most wikis use the single wiki pages as the underlying structuring paradigm, where the particular concepts are represented by single wiki pages. Possible values are: (a) One concept/property for each wiki page, (b) Multiple concepts/properties for one wiki page, (c) Otherplease specify 2. Knowledge representation language: This sub-area names the expressivity of the underlying knowledge representation. Possible values are: (a) RDF(S), (b) OWL, (c) Other/combinationplease specify 3. Additional knowledge sources: In addition to standard ontological knowledge, often a special type of additional knowledge is attached, for example, rules and domain models. Possible values are: (a) SWRL rules, (b) Prolog rules, (c) Model-based knowledge, (d) Text in controlled language, (e) Otherplease specify
In practical applications the user interface for the development and use of the represented knowledge is of prime importance. Here, most of the current semantic wiki implementations strongly dier and show emphasis on their chosen application context. 1. Knowledge editing paradigm: How is the knowledge acquired and maintained within the wiki system? Possible values ares: (a) Inline text markup: The knowledge entered and maintained in combination with the usual textual edit pane of the wiki. The wiki oers special purpose markup to dene the knowledge entities. (b) Semantic forms/visual editors: Ontological concepts and more expressive knowledge is dened using customized forms and graphical editors. (c) Multiple (combination of above approaches) (d) Otherplease specify 2. Semantic search/knowledge retrieval: One prominent application of knowledge use is the integration of semantic search facilities. Of interest is the applied approach of integrating the search into the wiki as well as the language to formulate the queries. (a) Used query language: SPARQL, Datalog-like queries, otherplease specify. (b) Query integration: Special-purpose forms, queries embedded into the wiki article, interview questionnaires, otherplease specify. (c) Further capabilities of knowledge use: Generated knowledge-based interviews, Prolog queries, otherplease specify. 3. Semantic navigation: The semantic annotations of the wiki articles allows for an improved navigation through the contents of the system. Some systems provide a simple extension of semantic navigation by extending the standard link structure, whereas other implementations (additionally) facilitate semantic search by generated fact sheets interlinking connected articles. (a) Extended links within wiki article (b) Generation of fact sheets (c) Otherplease specify
This sub-area species the capabilities of the wiki with respect to the import and export of knowledge from and to external sources. 1. Import facilities: Is it possible to import external knowledge sources, and if yes then what type of sources are supported? Possible values are: (a) RFS(S)/OWL, (b) SWRL, (c) RIF, (d) Proprietary knowledge sources please specify, (e) none 2. Export facilities: Is it possible to export the knowledge base of the wiki to an external storage? (a) RDF(S)/OWL, (b) SWRL, (c) RIF, (d) Proprietary knowledge sources please specify, (e) none
Due to the fast development of new technologies and application areas, the extensibility of existing wiki systems by new features is very important. This sub-area captures the type of extensibility and lists a number of already existing extensions/modications of the wiki.
(a) Plug-in mechanism, (b) Code-in mechanism, (c) none, (d) otherplease specify 2. Existing extensions/modications: Please list running extensions of the wiki system.
With the proposed categorization we try to capture the conceptual properties of semantic wikis. Please note that we tried to not include technical details of the implementation of the wiki systems, such as data storage (databases vs. text) and the programming language.
We rst summarize the features of KnowWE according to the introduced feature matrix and then we introduce the system in more detail. 3.1
We summarize the KnowWE features according to the introduced feature matrix:
4) Special-purpose system for knowledge engineering tasks B. Underlying knowledge representation 1) Subject granularity a) One concept/property for each wiki page 2) Knowledge repr. lang. c) Combination (OWL and Special-purpose problem-solving knowledge) 3) Add. knowledge sources e) Other: heuristic rules, decision trees, fault models C. UI for knowledge capture and sharing 1) Editing paradigm: a) Inline text markup, b) visual editors (for d3web extension) 2) Search/Retrieval a) SPARQL, b) Queries embedded into the wiki article, interview questionnaires, c) Further capabilities: Generated knowledge-based interviews 3) Semantic navigation a) Extended links within wiki article, b) Generation of fact sheets, c) Other: Knowledge-based interview
1) Import facilities 2) Export facilities E. Extensibility 1) Extension mechanism 2) Extensions mods a) OWL, d) Proprietary: text (KnOce) a) OWL, d) Proprietary: text (KnOce), xml (d3web) (a) Plug-in mechanism d3web plugin, semantic tagging plugin Hermes plugin 3.2
In this section, we introduce the general features of KnowWE by using a simple example application for diagnosing car faults. The basic idea is, that possible causes for a car fault the solutions of the problem are represented by corresponding wiki articles. The wiki contains, for instance, articles about empty battery, clogged air lter , and bad ignition timing .
Inline Editing of Text and Knowledge In Figure 1, a page of the wiki is
shown, describing the solution bad ignition timing . Besides standard text
describing the problem in more detail, also explicit problem-solving knowledge is
included on the page. In Figure 1-(1) two heuristic rules of the rule base are
displayed, that describe some derivation knowledge of the solution. The rst rule
states, that the solution Bad ignition timing will receive a negative score, if the
user enters for the symptom engine start that it neither does not start nor barely
starts. The second rule states a positive score, if the engine noise was observed
by the user as ringing or knocking. Besides the representation of rules, we also
allow for the inclusion of model-based knowledge and decision trees, see [
We see, that the derivation knowledge for a solution is locally dened and maintained together with the corresponding article of the solution; see the right top of Figure 1 for an example edit panel of the wiki, where a rule base (Figure 16) is edited inline. This allows for a simplied update of informal (e.g., text) and explicit knowledge (e.g., rules) about one entity.
Although, the wiki is mainly used as a tool for knowledge engineering, it also provides interfaces for interactive problem-solving. We give an example of the problem-solving process in the following: Some parts of the text are related to concepts of the knowledge base, and thus have a meaning for the problemsolving process. Specic semantic annotations relate these text parts with the concepts. In the view mode of the wiki the user is able to click on the annotated text and can enter ndings based on the corresponding concept. We call this approach inline answers for problem-solving in wikis. The text phrase "engine noises" within the text was annotated by the corresponding concept Engine noises available in the knowledge base, see Figure 1-(2). In the given example, the value knocking for the concept Engine noises was entered by the user. In the solutions pane of the wiki Figure 1-(3) we see that the solution Bad ignition timing is derived with a high score, whereas the alternative solution Clogged air lter was also derived and is considered as a possible solution. Both solutions were derived on the basis of this nding and previously entered ndings. By clicking on the solution Clogged air lter in the solutions pane, we quickly can navigate to the wiki article describing the corresponding article.
Alternatively, the user is able to download an executable version of the knowledge base by clicking the download button, see Figure 1-(4). This way, the knowledge bases can be developed using the wiki and later are exported to an external application when required.
Semantic Annotations In KnowWE, semantic annotations are dened inline
with the wiki text. The markup for those annotations was inspired by the syntax
of Semantic MediaWiki [
<=> subClassOf:: TechnicalProblem] that can be solved ... In the example shown above, the text phrase "Bad ignition ... problem" is annotated, stating, that the concept represented by this article is a subClassOf the concept TechnicalProblem . The annotation itself states, that the annotated text phrase documents/justies the given relation.
By this type of annotations many useful ontological relations can be dened inline the wiki text. All annotations are represented in the application ontology and can be queried using a SPARQL. Queries are embedded into the wiki text, and the results of the queries are shown in the view mode of the article. 3.3
KnowWE is typically used together with the d3web plugin for building
knowledgebased applications. The system is currently used in a number of (industrial
and academic) projects, ranging from simple recommender systems to
complex decision-support systems for technical and medical devices. For example,
KnowWE provides a technical platform to support a scientic community in
the biological domain in the context of the BIOLOG Wissen 4 project. BIOLOG
Wissen serves as a web-based application for the collaborative construction and
use of a decision-support system for landscape diversity. It aims to integrate
knowledge on causal dependencies of stakeholders, relevant statistical data, and
multimedia content. We refer the interested reader to [
The PlWiki [
The features of PlWiki according to the introduced feature matrix are: A. Targeted applications 4) Special-purpose system for knowledge engineering tasks B. Underlying knowledge representation 1) Subject granularity b) Multiple concepts/properties for one wiki page 2) Knowledge repr. lang. c) Other/combination (Prolog low-level, OWL higher-level) 3) Add. knowledge sources b) Prolog rules C. UI for knowledge capture and sharing 1) Editing paradigm: a) Inline text markup, d) Other: Prolog editing support 2) Search/Retrieval a) Prolog queries, b) Queries embedded into the wiki article, c) Further capabilities: Prolog predicates for knowledge processing 3) Semantic navigation a) Extended links within wiki article, b) Generation of fact sheets
1) Import facilities
E. Extensibility 1) Extension mechanism 2) Extensions mods
edge format, Prolog, XTT a) OWL (planned) d) Proprietary: Prolog (a) Plug-in mechanism, (b) Code-in mechanism
Custom Prolog extensions, SWI Semantic Layer 4 BIOLOG is funded by the German Federal Ministry of Education and Research from 2007-2009 (nal funding phase). 5 CliWE (Clinical Wiki Environment) is funded by Drgerwerk, Germany and runs from 2009-2012. 4.2
System Architecture The main objective of the PlWiki design is to deliver a
generic and exible knowledge engineering solution [
DokuWiki provides a exible plugin system, providing ve kinds of plugins (see www.dokuwiki.org/devel:plugins ). The current version of PlWiki implements both the Syntax and Renderer plugin functionality. Text-based wikipages are fed to a lexical analyzer (Lexer) which identies the special wiki markup. The standard DokuWiki markup is extended by a special <pl>...</pl> markup that contains Prolog clauses. The stream of tokens is then passed to the Helper that transforms it to special renderer instructions that are parsed by the Parser. The nal stage is the Renderer, responsible for creating a client-visible output (e.g. XHTML). In this stage the second part of the plugin is used for running the Prolog interpreter.
Knowledge Representation Features Below basic use examples of the generic Prolog representation are given. <pl> capital(germany,berlin). country(germany). country(poland). </pl>
This simple statement adds two facts to the knowledge base. The plugin invocation is performed using the predened syntax. To actually specify the goal (query) for the interpreter the following syntax is used: <pl goal="coutry(X),write(X),nl,fail"></pl>
It is possible to specify a given scope of the query (in terms of namespaces): <pl goal="country(X),write(X),nl,fail" scope="prolog:examples"></pl>
A bidirectional interface, allowing to query the wiki contents from the Prolog code is also available, e.g.: <pl goal="consult(’lib/plugins/prolog/plwiki.pl’),
wikiconsult(’plwiki/pluginapi’),list."></pl>
There are several options how to analyze the wiki knowledge base (that is
Prolog les built and extracted from wiki pages). A basic approach is to combine
all clauses. More advanced uses allow to select pages (e.g. given namespace) that
are to be analyzed. On top of the basic Prolog syntax, semantic enhancements are
possible. These can be easily mapped to Prolog clauses. An example of editing
session with PlWiki can be observed in Fig. 2.
Semantic Representation Layer Besides the generic Prolog-based
knowledge representation features based on pure Prolog clauses, typical semantic wiki
features are supported. Semantic Media Wiki (SMW) [
To provide a better compatibility with existing solutions parsing of SMW wikitext is provided, with a corresponding Prolog representation available. The wiki user can use the SMW syntax directly in DokuWiki to enter wikitext. The PlWiki plugins transforms the wikitext to Prolog clauses, asserted to the internal knowledge base. In fact these clauses could also be introduced by using the PlWiki <pl></pl> tags. Examples are shown below, with the SMW syntax given rst, and the corresponding Prolog representation after it.
Berlin is the capital city of [[capital_of::Germany]] [[category:city]] wiki_category(’City’,’Berlin’).
wiki_property(capital_of,subject_page_name,’Germany’).
Germany is a country in central Europe. [[category:country]] [[location:=Central Europe]] wiki_category(’Country,’Germany’). wiki_attribut(page_uri,location,’Central_Europe’).
The Prolog clauses are asserted to the PlWiki knowledge base by the syntax plugin analyzing the wiki text. In a similar fashion simple queries are handled. A query for a category or property is simply mapped to a Prolog goal: {{#ask: [[category:city]] [[capital of::Germany}} wiki_category(’Cities’,Page), wiki_property(capital_of,Page,’Germany’), wiki_out(Page).
Plain RDF annotations are also supported. Currently, these are separated from the explicit annotations mentioned above. For compatibility reasons an RDF annotation can be embedded directly in XML serialization, then it is parsed by the corresponding Prolog library, and turned to the internal representation, that can also be used directly. SWI-Prolog’s represents RDF triples simply as: rdf(?Subject, ?Predicate, ?Object). So mapping the above example would result in: rdf(’Berlin’,capital_of,’Germany’).
Using wiki knowledge it is possible to dene rules, e.g.: Nordic country is a country with location set to Northern Europe is in Prolog: <pl cache="true"> nordic_country(X) :wiki_category(X,’country’), wiki_attribute(X,’location’,’Northern Europe’). </pl>
Compound queries can also be created and executed as Prolog predicates. 4.3
PlWiki is in an experimental development phase. Current applications include special knowledge engineering tasks, including basic rule-based reasoning tasks in the wiki, and teaching knowledge engineering classes. Future applications are planned, including dedicated knowledge intensive closed community portals. System development will focus on exible user interfaces supporting complex knowledge representation features. 5
Semantic wikis are successful examples of semantic applications and are widely used in academia and industry. From the technological viewpoint, however, we currently see no common baseline for the expressiveness and functionality of semantic wikis. In contrast, the available and active semantic wiki implementations strongly dier in their characteristics. In this paper, we introduced a catalog of functions with which systems can be compared and evaluated. We emphasized the functionality of wikis with respect to knowledge engineering activities, thus excluding certainly important aspects such as editing paradigm, data storage, and scalability. The semantic wiki implementations KnowWE and PlWiki were presented according to the introduced catalog.
This work is an initial attempt in this research direction. In the future, we are planning to undertake an extensive study not only incorporating two systems, but comparing all available and active semantic wiki implementations within a feature matrix. The studies would we also aimed at providing benchmark case studies implemented using dierent wiki implementations which would allow for a synthetic comparison and feature analysis.