Due to their low entry barrier, easy deployment, and simple yet powerful features, wikis have gained popularity for agile knowledge management in communities of almost all sizes. Semantic wikis strive to give entered information more structure in order to allow automatic processing of the wiki's contents. This facilitates enhanced navigation and search in the wiki itself as well as simple reuse of information in external applications or for generating different views on the same information. This makes semantic wikis especially interesting for corporate intranet deployment, implementing the Semantic Intranet. In this paper, we will have a look at Kaukolu, an open source semantic wiki prototype, being deployed in a corporate intranet. External applications use information authored in Kaukolu, effectively forming a cluster of applications interacting and sharing data.
Wikis become more and more important for managing content of corporate intranets, serving as a platform for information exchange and as knowledge repositories. Typically, part of the information found in corporate intranets are simply plain text (e.g., texts describing projects, templates for mails, brainstorming, tips and best practices, . . . ), but a major part of the content consists of structured data such as lists relating people to projects, product feature lists, publication lists, or simply collections of annotated web links. While simply being able to manage all of this different content by dropping it—as text—into the wiki is handy, a direct consequence of this is that everything in the wiki is essentially text and therefore cannot be imported into other applications such as spreadsheet applications, databases, or a content management system used for the external web site. So, a lot of data duplication needs to be done, ultimativaly resulting in unnecessary workload, outdated content, and inconsistencies in the data presented at different places for differing audiences.
Semantic wikis try to implement a way to establish and maintain structure of the wiki’s content using semantic web technologies in order to facilitate information reuse or, in general, to facilitate accessibility of the information to automated means. Also, knowledge of the inner structure of the information contained in wiki pages can be used to enhance browsing and search in the wiki.
In section 2, we give a short overview over the basic wiki ideas and explain the shortcomings of wikis concerning structured data. In section 3, an overview over (semantic) wiki implementations is given, some semantic wiki features are explained, and several problems with existing semantic wikis are mentioned. Kaukolu, our implementation of a semantic wiki, is introduced in section 4, along with a walkthrough in section 5. In section 6, a number of possible enhancements of Kaukolu are presented. We end with a conclusion in section 7. 2
Wikis allow a group of people to collaboratively author information using a tool that is easy to use. The main features a wiki provides are kept simple, but flexible, in order to allow for using the basic features for a number of different purposes. For example, the very basic wiki idea of editing a text page allows both editing a document and doing a discussion. Backlinks, another standard wiki feature, can be used for navigation, tagging, or grouping sets of pages. Basic content format of wikis is text so import/export functionality is limited to text formats.
Current applications of wikis range from open encyclopedias such as Wikipedia to collaborative information spaces for both open communities such as open source software projects (e.g., http://wiki.mozilla.org/—even software project management software such as Trac1 feature wikis for documentation and information exchange) and closed communities such as company intranets.
A major drawback of wikis is that they are intended only to edit and display plain text2—content that represents structured data (e.g., tables or sets of wiki pages using the same structure) can only be exported as text or HTML. These formats preserve content and looks to some degree, but the information structure (i.e., explicit knowledge of what values populate what properties of what entities) gets lost3. This is unfortunate: People who maintain, for example, their publication list in the wiki, have to manually re-enter the same information in other places such as the company extranet. However, duplication of information is tedious work, often leading to inconsistencies and large amounts of outdated information. Also, lack of data structure prevents us from running queries or compiling statistics against the data.
Importing information into a standard wiki suffers from the inability to process structured data, too. For example, while it is possible to import spreadsheet data by attaching the spreadsheet file to a wiki page, this data cannot be accessed 1 http://www.edgewall.com/trac/ 2 Text can get formatted, but this is for the looks only. 3 Some wikis support structured data to some degree using templates or similar features. However, typically these are proprietary approaches that provide no interoperability with other applications. or edited in the wiki. The spreadsheet’s data structure cannot be exploited and reused. Another way to import spreadsheet data would be to export the data as HTML in the spreadsheet application and import the HTML into the wiki. However, importing large amounts of HTML prevents the users from contributing to the content. Even if users dare to edit the HTML code, keeping the original spreadsheet document in sync with the changes can only be done manually.
This means that existing structures effectively cannot be maintained inside the wiki. Since structured data gets “flattened” on import, users may end up with an unstructured data repository that is difficult to manage and difficult to keep in sync with the corresponding information outside of the wiki.
How to solve this issue?– A naive solution for importing spreadsheet data, for example, would be to import comma–separated values4 (CSV) into the wiki. This would at least bring one benetfi of wikis, namely collaborative editing, together with structured data. However, readability and eflxibility of CSV is very low. Anybody trying to introduce a new property of an item (anybody who would try to add a new column) would have to reformat all data that has been added so far. Also, anybody depending on the old CSV structure would have to get notified.
Semantic wikis try to overcome the problem stated above by combining semantic web standards such as RDF/S or OWL with the wiki paradigm. One idea is to annotate structure in the wiki by providing metadata for existing features such as links and pages. On the other hand, one can strive to completely represent the wiki content using instances of the respective ontology language. 3
In [
In most traditional wikis, the idea of metadata typically only appears in a very technical way. For example, in JSPWiki5, metadata is added directly into the wiki text using special tags, and mostly serves the purpose of implementing access control. In SnipSnap6, labels may get attached to wiki pages, serving mainly as a categorization scheme.
The semantic wiki Platypus7 adds RDF(S) and OWL metadata to wiki pages. Metadata has to be entered separately from wiki text and relates a wiki page to another resource; thus, metadata can be transformed into a list of related pages that can be shown along with the actual wiki page. 4 http://en.wikipedia.org/wiki/Comma-separated values 5 http://www.jspwiki.org/ 6 http://snipsnap.org/ 7 http://platypuswiki.sourceforge.net/
The Semantic MediaWiki8 [
Rhizome10 [
IkeWiki11 [
OpenRecord12 is a kind of database/spreadsheet wiki. It focuses on enabling the user to enter structured data using tables. It heavily uses JavaScript, providing almost the feeling of a standalone application. However, currently it is in alpha stage only.
Existing (semantic) wikis lack in some areas: Interoperability: While one of the main points of semantic web standards is interoperability, there seems to be no semantic wiki that allows import of RDF data. Some wikis allow usage of ontologies (in OWL or RDFS language), but integration into the wiki concepts seems to be amendable. For example, ontologies loaded typically do not show up in the wiki since they are loaded into a separate repository. Thus, ontologies are deemed to remain static and cannot be edited by users of the wiki.
Annotation complexity: In existing semantic wikis, RDF is mainly used for annotations: RDF supplies semantic information that describes existing human– readable features. Since the basic blocks of wikis are pages and links between them, mapping a wiki to RDF can be done by using pages as representatives of RDF resources, with links between wiki pages denoting relations between RDF resources. This approach is typically implemented by enabling the user to attach RDF triples to wiki pages13, but setting the subject of each triple of the page 8 http://semediawiki.sourceforge.net/ 9 http://mediawiki.sourceforge.net/ 10 http://rx4rdf.liminalzone.org/Rhizome 11 http://ikewiki.salzburgresearch.at/ 12 http://openrecord.org/ 13 Often in terms of selecting types for links to other pages to the page’s URI14. It follows that when using RDFS, wiki pages must be both of the type wiki:page and of the type the resource the wiki page is supposed to describe. This has two drawbacks: First, from a knowledge engineer’s point of view, existence of an entity that is both a text (a wiki page) and, for example, a person, is not desirable. Second, while the approach can be handy for generating RDF data of “shallow” ontologies with few classes and many relations15, we think that it reaches its limits as soon as more elaborate ontologies and structures are used. For example, in Figure 1 the RDF structure of a foaf:person is depicted. In semantic wikis that identify an RDF resource with a wiki page, one wiki page of the type foaf:person can be used to model this data. However, if we try to model the data shown in Figure 2 (a bibtex entry represented in a format similar to the format used by the bibtex2rdf 16 converter), we would need four wiki pages (one wiki page per RDF resource) for just one bibtex entry.
There are other cases that make the problem even more obvious. For example, imagine a large table that lists 100 products along with a short description and price. In order to express this in a semantic wiki that identiefis a page with a resource, one gets forced to create 100 wiki pages, one for each row of the table, both cluttering title index and recent changes pages.
In general, we believe that imposing a structure on wiki contents due to technical reasons is against the wiki way. Users should be free to use whatever page structure they want. Structured data, as is RDF, is only another view on the wiki content.
Paul : foaf:Person +foaf:name = Paul +foaf:mbox = mailto:paul@mail.net +foaf:homepage = http://paul.home.page/ +foaf:depiction = http://paul.home.page/paul.png
Smooth migration: While some existing semantic wikis allow addition of
semantic features to existing content (for example, by typing previously untyped
links in the wiki), no wiki seems to provide features to assist the user when
extracting further semantic features from (imported) plain text.
14 The point is that in this approach triples are bound to pages because of their subject
URI. It does not really matter whether this URI is the URL the wiki page can be
browsed at, a separate “wiki page concept URI”, or an arbitrary URI.
15 For some applications such as Gnowsis [
dc:isPartOf
Paul_person : bt:Person +vc:FN = Paul Miller
vc:N
Paul_fullname : vc:Name +vc:Given = Paul +vc:Family = Miller
Proc04 : bt:Proceedings +dc:date = 2004 +dc:title = WISKY 2004
Queries: The only means of querying semantic information is either very simple
queries built with a user interface (such as “Show a list of all publications to me”)
or complex queries entered manually in a query language such as SPARQL [
Kaukolu17, our implementation of a semantic wiki, builds on JSPWiki18 and Sesame 219. It differs in several aspects from the existing semantic wikis. – no restrictions are imposed on RDF triples attached to a page (triple’s subjects are not fixed) – arbitrary RDF(S) lfies can be imported – aliases can be defined for resources and predicates – autocompletion supports the user when formalizing content
We currently use Kaukolu internally in our department. An evaluation in another company will take place this year.
Kaukolu allows to formulate arbitrary RDF on any wiki page using a slightly extended wiki syntax. Subjects of RDF triples are not required to represent the URI of the page the triple is located at. This solves the issues explained in section 3 and allows for more complex RDF data. 17 Available at http://kaukoluwiki.opendfki.de/ including sources 18 http://www.jspwiki.org/ 19 http://www.openrdf.org/
Being able to associate arbitrary RDF with a wiki page not only works when formulating RDF but also allows to import RDF. In fact, since RDF Schema is also represented in RDF, one can even import RDFS ontologies to Kaukolu using this method. Imported RDFS ontologies can be used in various ways within Kaukolu, we will explain this later. A direct benetfi of RDFS ontologies being stored on wiki pages is that this way users are able to edit and extend the ontologies used by the wiki in a straightforward way, using all features a wiki provides (versioning, collaborative authoring, viewing diffs, . . . ). However, one has to say that currently changing RDFS using this approach is quite difficult as one has to directly work on RDFS without any tool support.
In contrast to most existing semantic wikis, users of Kaukolu are not required
to use localnames, labels, or namespaces of RDFS properties in order to express
RDF triples using these predicates. For example, typically the user has to write
something like (this) dc:author “Author Name” if he wants to express that the
current wiki page has a Dublin Core author property. In Kaukolu, we allow an
intermediate step: every RDF instance or RDFS property may be associated
to arbitrary strings (aliases) that can be used instead of the URI/label of the
respective property or instance. In Figure 3, aliases are defined using the
hasSubjectURI/hasPredicateURI keyword. This not only relieves the user from having
to remember namespaces or localnames but also facilitates internationalization
by usage of ontology metainformation [
Of course, even with wiki syntax and aliases for properties and instances, entering RDF triples is a tedious task. Without further support, the user would need to keep the documentation of the ontologies always at hand, typing mistakes would introduce severe errors, and the user would have to remember the URIs of all RDF instances created in the wiki. In Kaukolu, there is ontology–based autocompletion support, which proposes aliases based on RDFS range and domains. For example, when typing Paul knows, with Paul being a foaf:person, and knows being associated to foaf:knows, the system automatically proposes a list of foaf:persons denfied in the wiki to complete the RDF triple, as only foaf:persons are allowed as range of foaf:knows, even without any prexfi typed. If a prexfi has been typed already, it is used to narrow down the list of suggestions. Autocompletion works for predicates, too. In case no alias is found in the typed text, Kaukolu assumes that the user does not intend to write triples, and simply proposes names of wiki pages as autocompletion suggestions, based on the prefix already typed. So if you type “InfoOn”, and there are “InfoOnPaul” and “InfoOnSarah” pages in the wiki, those both page names are suggested.
Most other semantic wikis have been rewritten from scratch and therefore miss several standard wiki features such as file attachments, access control, plugin support, or support for multiple backends. Kaukolu is based on JSPWiki20, an established wiki that is quite feature–complete. 5
In the following, we will demonstrate some of Kaukolu’s features. Paul Miller
will import an ontology describing bibtex entries into Kaukolu, and add a new
publication item to a wiki page (ontology–driven autocompletion will help here).
Then, Paul will export the bibtex RDF generated into an external application
RDFHomepage [
Add a Publication Entry: In Figure 4, we see a user adding a publication entry to his wiki page. Since hasType (corresponding to rdf:type) implies that the triple’s object will be of type rdfs:Class, only instances of rdfs:Class are displayed in the autocompletion suggestion box.
The complete page describing Paul’s publication item is shown in Figure 5. Note that one can use standard wiki markup along with the RDF extensions (a bullet list is used).
an HTML page generated by RDFHomepage using the RDF formulated on the user’s wiki page. Note that the page generated is intended for external audiences and cannot be edited. The RDF created in Kaukolu, a Java–based application, is processed by RDFHomepage, a PHP–based application. 20 http://www.jspwiki.org/ Kaukolu can be used for different ontologies, too. For example, RDFHomepage not only generates a publication list, but also uses information contained in an organizational repository (formulated in RDF/S) for generating a list of projects the respective person using RDFHomepage participates in. Kaukolu allows to collaboratively maintain the organizational repository which up to now has been maintained centrally in our department. 6
Kaukolu currently does not provide means to generate a number of RDF constructs. Most notably, it cannot deal with RDF containers such as bags, sequences, and alternative values yet. While this is a drawback when authoring or importing RDF, expressivity is not touched by leaving these features away since these constructs can be substituted by RDF lists and multiple–valued properties in most cases. Alternatively, Kaukolu’s wiki syntax for creating RDF triples could be extended to incorporate handling of containers.
Another limitation of Kaukolu is its inability of generating blank nodes. On import, any blank nodes may get assigned a random and unique URI. However, Kaukolu currently never exports blank nodes.
We have identiefid several ways in which Kaukolu may be improved.
Use of RDF metadata within Kaukolu: While currently the main reason
for generating RDF is its usage in external applications, Kaukolu can use RDF
data for navigation: If RDF data is attached to a page, it can be shown in a
navigation sidebar. We are aware that this is only a very basic feature. Further
possibilities for using annotations within the wiki would be to use them for
search or feature a reverse translation of RDF to wiki markup or HTML directly
for display which would allow to create customized views on formalized wiki
content (“Show a list of all persons working in project X here” or “Show a
list of all properties of software X here”). Previous work on this topic includes
Fresnel [
SProUT natural language processing module [
Kaukolu must be part of a wiki page’s text and therefore gets displayed when the page gets rendered. Since Kaukolu allows aliases for subjects, predicates, and properties to get embedded in natural text (as in “PaulMiller came to know SarahMiller in 2005”), there is no absolute need of separating the parts of the text that represent RDF from the remaining text. However, in practice embedding triples often leads to awkward sentences. A more flexible way of embedding RDF–generating content into wiki pages seems desirable. In the future, we will implement a feature that allows to separate RDF–generating statements from normal text. Features to generate these statements as well as features to keep them in sync with normal text will be added. 7
In this paper, we gave an overview over the ideas of (semantic) wikis and implementations that are available. Our semantic wiki prototype Kaukolu addresses some of the shortcomings of existing semantic wikis and is intended for intranet usage. Its main features are its ability to import and export RDF and its ontology–supported autocompletion feature which relieves users from having to know the ontologies used letter by letter. We believe that export and import of structured data are essential features for a semantic web application. A demonstration of theses features was given, using a publication list as an example for structured content which gets formulated in Kaukolu and used in a separate application, illustrating Kaukolu’s export functionality. Finally, we discuss some issues in Kaukolu, along with ideas how to address them. 21 http://www.smartweb-project.de/
This work has been supported in part by the NEPOMUK project, which is funded by the IST Programme of the European Union under grant FP6-027705.