The Wiki and the Semantic Web can be compared as two different approaches to capturing knowledge, where the former trades away precise, explicit, and internally consistent semantics for speed and simplicity. Any attempt to bridge these two approaches has to either somehow reconcile these trades-off or make compromises one way or the other. This paper describes how Rhizome, an open source application framework for developing “Semantic Wiki” applications, attempts to bridge these approaches. Rhizome includes a text formatting language called ZML whose syntax is similar to text formatting languages found in most Wikis but with enhancement to make it easy for users to express explicit and arbitrary semantics. Rhizome relies on “shredding”, a flexible framework for specifying rules for characterizing semi-structured content with RDF and providing an ontology that can precisely describe the relationship between the source content and the resulting statements.
The Wiki and the Semantic Web can be compared as two different approaches to
capturing knowledge, where the former trades away precise, explicit, and internally
consistent semantics for speed and simplicity. Any attempt to bridge these two
approaches has to either somehow reconcile these trades-off or make compromises
one way or the other; for example, by adding complexity and constraints that
undermines Wiki design principles or by limiting the scope where Semantic Web data
can be applied (e.g., limiting it to meta-data associated with traditional wiki pages).
The Wiki has proven to be a remarkably successful tool capturing knowledge in a
collaborative, open fashion. The inventor of the Wiki, Ward Cunningham, has
identified several Wiki design principles, which he refers to as the “Wiki-way”[
This paper attempts to conform to the ABCDE format for Semantic Conference
Proceedings[
Rhizome is an open source application framework that makes it easy to develop “Semantic Wiki” applications: applications that can create and utilize RDF data and Semantic Web ontologies while letting users interact with and modify that data in a Wiki-like fashion. In this section we describe how Rhizome attempts to fulfill the Wiki design principles discussed above.
What sort of “(irregular) text conventions” should be used for authoring RDF triples? The simplest approach would be a text format limited to providing a way to explicitly describe RDF triples. And arguably, existing plain text RDF formats such as N3 and Turtles already fit this criteria. However, this approach limits its audience to those with knowledge of RDF and domain-specific ontologies. And even for sufficiently trained users, writing precise and atomic RDF statements flies in the face of the Wiki’s goal of being “quick”.
A more ambitious approach would be to design a more traditional Wiki-like text format whose structure could be easily represented as RDF. However there are several challenges to creating a mapping to generic RDF or some general purpose ontology for content. First, current Semantic Web standards, such as OWL, are not yet powerful enough to inference equivalencies between a representation in a content ontology and its appropriate domain-specific ontology. Second, the most intuitive markup structure for a particular application doesn’t always submit to a straightforward mapping to RDF. Finally, there’s the practical issue that representing structural elements in free form text as RDF creates a tremendous volume of RDF statements, especially if order is preserved.
Because of these limitations, Rhizome’s approach is to use a Wiki-like text format (dubbed ZML) that is flexible enough to express arbitrary structure but doesn’t specify a particular translation to RDF. Instead, the system determines which translation rules to apply based on the content of the text.
Unlike other Wiki text formats, all structural elements in ZML can be arbitrarily
nested (relying on whitespace much like the indentation rules found in the Python
programming language) and annotated with attributes. The result of parsing ZML is
an XML document and in fact ZML can used as a simple, concise alternative syntax
for XML. This design enables the user to easily use microformats[
ZML doesn't directly translate into RDF; instead it relies on “shredding”, the process Rhizome uses to bridge implicit and explicit semantics. Shredding is a flexible framework for specifying rules for characterizing semi-structured content with RDF and providing an ontology that can precisely describe the relationship between the source content and the resulting statements.
Rhizome lets users create rules that trigger shredding on the basis of the content's
type. For example, shredding an RDF/XML document would consist of parsing the
RDF; shredding an (X)HTML document could invoke invoking a GRDDL (Gleaning
Resource Descriptions from Dialects of Languages) [
Rhizome also lets users directly view and edit raw RDF in ZML via RxML, an alternative syntax to RDF with the goal of enabling novices to read and edit RDF using a metaphor conceptually similar to and only incrementally more complicated than application properties file formats such as Microsoft Windows' .ini files. Although RxML can express any set of RDF statements, it presents the RDF in a constrained, simplified manner: as a list of resource URIs, each of which has a set of property name-value pairs.
Providing a unified namespace for users requires a strategy for mapping WikiNames to RDF resource URIs. One simple approach would be to treat the WikiNames themselves as a resource URI, e.g. by introducing a “wiki:” URL scheme. It is obvious that given the decentralized nature of the Semantic Web this approach could not scale without name conflicts arising. Alternatively, we could generate a unique URL from a WikiName; for example by using the actual URL to the web page that corresponds to the WikiName, or by pre-pending some application specific base URI. However, this contradicts the principle of a unified namespace by essentially creating separate namespaces -- users would not be able use to WikiNames to refer to resources outside the system without some way to refer to those namespaces. Thus Rhizome assumes that in order to provide a single, flat namespace of WikiNames that is universally addressable we need to create a level of indirection between a RDF resource URI and its WikiName, and accept that the determination of this relationship is dependent on the context it appears in. WikiNames are treated as a property of a resource, with only slightly stronger semantics than RDF Schema’s “rdfs:label” property. When a WikiName is referenced in content, it is up to the shredding process to assert a relation between it and a RDF resource. This is appropriate because the question of how closely that name should be “bound” to an RDF resource is dependent on the needs of the specific application and what assumptions can be made about the context in which it appears.
The principle of tolerance is harder to achieve with Semantic Web data than the plain
text found in traditional Wikis because Semantic Web data is precise and machine
consumable and so very often requires some degree of validation. Rhizome allows an
application to maximize the tolerance allowable by providing partial, incremental and
ad-hoc of validation of RDF using Schematron. Thus validation can be accomplished
without having to use complex ontology languages such as OWL, which can often
break down in the face of inconsistency. Schematron[
1 Not discussed here is ways in which class inferences add complexity when rules based on class types are allowed.
RxPath is an RDF data access engine that provides a deterministic mapping between
the RDF abstract syntax and the XPath data model. This lets users access RDF data
stores as a (virtual) XML DOM (document object model) and query them using
RxPath, a language syntactically identical to XPath 1.0. This approach allows the full
range of XPath-based languages to be used to query and manipulate RDF models
-for example, XSLT for presentation and transformation, XUpdate[
RxPath maps the set of (subject, predicate, object) triples in an RDF model into a virtual and possibly infinitely recursive tree in which: • the root has a child node corresponding to each resource in the model, • each resource node has child nodes for each statement that it is the subject of • each statement node has a single child node corresponding to the statement's object.
If the statement’s object is a resource, it might in turn have child nodes that
correspond to the statements that the resource is subject of, and so on. Given such a
tree, an XPath expression such as /foaf:Document/dc:creator/* will select
a set containing all the authors of each document resource in the RDF model.
RxPath also supports “named graphs”[
Raccoon is a simple application server that uses an RDF model for its data store. Raccoon uses RxPath to translate arbitrary requests — such as HTTP requests or command line arguments — to RDF resources. Each of these can be associated with style sheets in RxSLT and RxUpdate languages, which can generate responses or update the RDF data store.
Raccoon's goal is to present a uniform and purely semantic environment for applications. This enables the creation of applications that are easily migrated and distributed and that are resistant to change. Raccoon is designed primarily for applications that look at the world as a universe of RDF statements, but it also works with XML-centric applications. Raccoon isn't designed to be a full-featured application server and in fact will often be embedded in another application server. Raccoon's job as an application server is a narrow one—to map a request to a response, possibly modifying the state of the application in the process:
A request is a dictionary of simple values, and an application defines a pipeline of RxPath expressions that transform the request into the response. Raccoon presents both the request and the application's state using the RxPath data model. This approach enables the creation of applications that can be transparently distributed and aggressively cached. Application code is always executed within the context of a request. There are external requests, such as HTTP requests, and internal ones, such as the requests sent when an application starts or stops. Raccoon also provides basic transaction coordination for managing updates to the RDF store. Using contexts enables the application to choose an appropriate consistency model for its needs. If full global atomic consistency isn't needed, Raccoon can cache request responses even more aggressively and still provide the appropriate levels of cache coherency.
Running on top of Raccoon is the actual Wiki application, which offers all the basic functionality found in Wikis, such as letting users create and edit pages on an ad hoc basis; along with some more advanced content management features such as roles and groups, release workflow, and basic facet navigation. Almost all of the Wiki's functionality is implemented in its dynamic pages, which are written in RxSLT, XSLT, and RxUpdate. Users can edit these like any other pages, making it easy to incrementally add and change functionality. They can also use RxUpdate to modify the underlying schema at run-time.This flexibility makes access control very important—to this end, Rhizome uses a flexible schema for authorizing both application-level actions and statement-level changes to the RDF store based on the authorization mechanism described in the previous section. This paper has examined some of Rhizome’s approaches to applying Wiki design principles to the Semantic Web. Despite the challenges of marrying two very different approaches to capturing knowledge, doing so can help reduce the barriers that often hinder the adoption of Semantic Web technologies, such as high learning curves for users, demands for precision and consistency, and the need to develop domainspecific user interfaces.