Semantic Wikis allow users to semantically annotate their Wiki content. The particular annotations can differ in expressive power, simplicity, and meaning. We present an elaborate conceptual model for semantic annotations, introduce a unique and rich Wiki syntax for these annotations, and discuss how to best formally represent the augmented Wiki content. We improve existing navigation techniques to automatically construct faceted browsing for semistructured data. By utilising the Wiki annotations we provide greatly enhanced information retrieval. Further we report on our ongoing development of these techniques in our prototype SemperWiki.
Wikis are collaborative hypertext authoring environments. Wikis allow people
to collaboratively collect, describe, and author information. Since most
information in ordinary Wikis consists of natural-language texts, structured access and
information reuse are practically not possible [
Semantic Wikis allow users to make formal descriptions of resources by annotating the pages that represent those resources. Where a regular Wiki enables users to describe resources in natural language, a Semantic Wiki enables users to additionally describe resources in a formal language. By adding metadata to ordinary Wiki content, users get added benefits such as improved retrieval, information exchange, and knowledge reuse.
An ordinary Wiki should offer functionality3 such as access control, binary data management, version management, notification, and data export. In our opinion, a Semantic Wiki should specifically address three additional questions:
? This material is based upon works supported by the Science Foundation Ireland under Grants No. SFI/02/CE1/I131 and SFI/04/BR/CS0694 and by the European Commission under the Nepomuk project FP6-027705. 3 http://en.wikipedia.org/wiki/Wiki
Recently several Semantic Wikis have been developed, such as Platypus [
In this paper we specifically address these three questions in a broader way:
in Sect. 2 we analyse Wiki annotations from a conceptual level, discuss
representation mechanisms, and current annotation support in Semantic Wikis. In Sect.
3 we offer an improved navigational model based on semantic annotation; the
navigation model is similar to e.g. Longwell4 for faceted browsing of
semistructured data, but works, in contrast to existing approaches, for arbitrary datasets
with arbitrary structure. We report on our prototype implementation
SemperWiki [
In the following section we discuss our first question: how to annotate Wiki content?
Let us first analyse what an annotation is. We annotate data all the time:
when we read a paragraph, and mark “great!” in the margin, that is an
annotation; when our text editor underlines a misspelled word, that is also an
annotation. Annotations add some information to some other information; to
annotate means “to make notes or comments” [
Another way to view annotations is metaphorically: URIs5 are the “atoms” of the Semantic Web and semantic annotations are the “molecules”. The Semantic Web is about shared terminology, achieved through consistent use of URIs. Annotations create a relationship between URIs and build up a network of data. 2.1
We now explore the conceptual model behind annotation in more depth. The
term “annotation” can denote both the process of annotating and the result of
that process [
Investigating the nature of annotation further, we can model it as a quadruple: Definition 1 (Annotation). An annotation A is a tuple (as, ap, ao, ac), where as is the subject of the annotation, the annotated data, ao is the object of the annotation, the annotating data, ap is the predicate, the annotation relation, that 4 http://simile.mit.edu/longwell/ 5 http://www.w3.org/Addressing/ defines the type of relationship between as and ao, and ac is the context in which the annotation is made.
Example 1 (Informal annotation).
The annotation subject can be formal or informal. For example, when we put a note in the margin of a paragraph, the informal convention is that the note applies to the paragraph, but that pointer is not formally defined. If we however use a formal pointer such as a URI6 to point to the paragraph then the subject is formally specified.
The annotation predicate can be formal or informal. For example, when we put a note in the margin, the relation is not formally defined, but we may informally derive from the context that that the note is a comment, a change-request, an approval or disapproval, etc. If we use a formal pointer to an ontological term that indicates the relation (e.g. dc:comment) then the predicate is formally defined.
The annotation object can be formal or informal. If an object is formal we can distinguish different levels of formality: textual, structural, or ontological. For example, then string “This is great!” is a textual object. A budget calculation table in the margin of a project proposal is a structural object. And an annotation object that is not only explicitly structured but also uses ontological terms7 is an ontological object.
The annotation context can be formal or informal. Context can could indicate when the annotation was made and by whom (provenance), or within what scope the annotation is deemed valid, for example in a temporal scope (it is only valid in 2006) or in a spatial scope (it is only valid in Western Europe). Usually context is given informally and implicitly. If we use a formal pointer such as a URI then the context is formally defined.
Combining the levels of annotation subject, predicate, and object, we can
distinguish three layers in annotations: i) informal annotations, ii) formal
annotations (that have formally defined constituents and are thus machine-readable),
6 One can use XPointer to point to a paragraph in a document and XPointer can be
used as a URI, as discussed in http://www.w3.org/TR/xptr-framework/#escaping.
7 Ontological means that the terminology has a commonly understood meaning that
corresponds to an shared conceptualisation called ontology [
Example 2 (Formal annotation). <h t t p : / / p a p e r s . o r g / m i n i m a l i s m#minor> <h t t p : / / l o c a l h o s t / schema#d i s a g r e e > ” that ’ s not minor ! ” .
Definition 3 (Semantic annotation). A semantic annotation As is a formal annotation Af , where the predicate ap and the context ac is an ontological term, and the object ao conforms9 to an ontological definition of ap.
Example 3 (Semantic annotation). <h t t p : / / p a p e r s . o r g / m i n i m a l i s m#minor> i b i s : con [ r d f : t y p e i b i s : Argument ;
r d f : l a b e l ” that ’ s not minor ! ” ] . 2.2
We can, similarly to [
Structure Annotations that describe the structure of a page or of a set of pages, such as hyperlinks (inter-page structure), headings, subheadings, and paragraphs (internal page structure), and itemised and numbered lists. Semantics Annotations that relate pages or page elements to arbitrary resources through typed ontological relations, such as categorising a page in a taxonomy, specifying the friends of a described person, or the books of a described author. 8 http://www.w3.org/DesignIssues/Notation3.html 9 The notion of “conformance” is rather weak in some ontology languages (such as RDFS or OWL) since these are not constraint-based languages (as opposed to e.g. database schemas). However, we use the notion of conformance to differ between “good” usage of textual objects, for example to indicate the name of a person, and “bad” usage of textual objects, for example to indicate the friends of a person. 10 These annotations could formally be considered semantical, because they have an explicit and shared meaning, which is used by the rendering engine.
Annotations in a regular Wiki are limited to layout and structural annotations. Semantic annotations are unique to Semantic Wikis, and are the further focus of this section.
We now present one possible annotation syntax for semantic annotations,
namely the one used in SemperWiki [
The example page shown in Fig. 1 describes the World Wide Web
Consortium. The page includes some English text, and some annotations which state
(using the Wordnet and Semantic Web Research Community ontologies) that
the W3C is an organisation lead by Tim Berners-Lee. The syntax includes
referencing using namespace abbreviations, internal Wiki pages, and full URIs; see
[
W3C The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential. rdf:type wordnet:Organization swrc:head http://www.w3.org/People/Berners-Lee/card#i Having defined annotations in Wikis, we now answer the second question: how to formally represent Wiki content?
RDF11 is a straightforward way to represent these annotations formally, since it has exactly the same model as our annotations. We can either use standard RDF to represent annotations without context, or RDF quads (which is a common RDF extension) for annotations with context.
RDF does pose some constraints on the constituents of triples: the subject must be a URI or a blank node (not a literal), and the predicate must be a URI (not a literal or blank node). If we follow these restrictions in our annotations, RDF offers a good representation model. 11 http://www.w3.org/RDF/
We represent pages and their annotation in RDF as follows: each page is an RDF resource, and each annotation a property of that resource. We can represent not only the semantic annotations in RDF but the whole Wiki content. The (natural language) Wiki content is captured through the predicate semper:content, the outgoing links to other pages through the predicate semper:links. Figure 2 shows the RDF graph that represents the page in Fig. 1. Problem: documents vs. concepts Because annotations can describe concepts (the W3 consortium) and web documents (the page about the W3 Consortium), the question arises which URI to use as the annotation subject.
For example, the Wiki page in Fig. 1 also contains the statement that it was created on January 1, 2006. But does this statement say that the document was created in 2006 or that the subject concept of the document, i.e. the W3C, was created in 2006? We may derive with some background information that we mean the first, but we actually need a way to say both: we sometimes want to make statements about a concept and sometimes about the document describing that concept.
This issue (often referred to as the “URI crisis”) is well-known from early
discussions on Web architecture, and has gained renewed interest in the Semantic
Web community. The problem is that it is unclear what a URI denotes (at least,
it is unclear for URIs that are URLs, but the discussion focuses primarily on http
URIs which are indeed URLs). A URL can denote a name, an abstract concept,
a web location, or a document [
Hawke [
Unfortunately, using a URN to identify concepts violates the fundamental
Web principle that a URI should point to a location with useful information
about the thing it identifies [
To complete this solution, we need to extend our Wiki syntax in two ways to include a way: 1. to distinguish annotations about a document (Wiki page) from annotations about the concept, which we do by prefixing the annotation with the ! symbol. 2. to relate a page to the concept it describes (in case the page describes a concept in a different naming authority, e.g. a page on http://wikibase/W3C that describes urn://w3.org), which we do with semper:about. Having answered the first two questions (how to annotate and how to represent Wiki content), we now characterise the annotation and representation in several existing Semantic Wikis.
Annotations in Semantic Wikis are formal and possibly semantic, i.e. they are
formally defined, and possibly use ontological terms. We have selected several
dimensions to classify annotations in Semantic Wikis from the literature (we
again focus on the annotation result, not the annotation process). We have added
one new dimension to capture the important notion of annotation context:
12 The proposal is a bit more intricate, but for our purposes this explanation suffices.
13 see e.g. http://w3.org/TR/annotor [
W3C The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential semper:about urn://w3.org rdf:type wordnet:Organization swrc:head http://www.w3.org/People/Berners-Lee/card#i Now we have an annotation about the page itself: !dc:date "2006/01/01"
(a) example page 2006/01/01
Fig. 3: RDF representation of an example page
Subject attribution (also called “scope” [
Subject granularity (also called “lexical span” [
Object type (also called “annotation form” [
These dimensions can indicate the level of annotation in current Semantic
Wiki approaches. We do not provide an exhaustive evaluation, but evaluate
WikSAR [
dimension WikSAR Sem. MediaWiki IkeWiki SemperWiki attribution current current current current, any URI granularity page page page page, any fragment repr. distinction no no yes yes terminology reuse no no yes yes object type literal, page literal, page literal, page literal, page, URI context no no no no
Table 1: Annotations in current Semantic Wikis Subject attribution Most existing Wikis only allow statements about the current page. The subject of an annotation is never explicitly stated, but always implicitly assumed to be the page on which the statement appears. In SemperWiki the user can explicitly state the subject of the annotations, because we separate the page and the thing it describes (as explained in Sect. 2.3), and annotations can thus be attributed to arbitrary URIs.
Subject granularity Most existing Wikis only allow annotation of complete pages, not of subsections or arbitrary parts of text, for the same reason (implicitly) as mentioned above.
Since SemperWiki allows users to attribute annotations to arbitrary URIs one could annotate a document fragment as follows: create a Wiki page, point it to the document fragment using an XPointer URI, and annotate the page.
Representation distinction Of the discussed Wikis only SemperWiki clearly separates the page from the concept that it describes, and offers a syntax that distinguishes annotations of the page from annotations of the concept. IkeWiki also separates pages from the concepts that they describe (a concept can be represented on multiple pages), but does not, as far as we know, offer a syntax to manually express this distinction.
Terminology reuse IkeWiki and SemperWiki allow existing terminology to be reused in annotations (through namespace definitions or full URIs), the rest can only create annotations using internal Wiki pages and can thus not make use of existing terminology.
Object type All discussed Wikis allow an object to be a literal or an internal Wiki page. Of the discussed Wikis, only SemperWiki allows the object of an annotation to be an arbitrary URI. No Semantic Wiki allows unnamed resources (blank nodes) as objects.
Context Is ignored in all existing Wikis.
Summarising, we have developed a conceptual model for annotations in general, and for semantic annotations in the context of Semantic Wikis specifically. Given this model we have seen that current Semantic Wikis offer only limited annotation possibilities (which is not necessarily wrong, but has now been recognised explicitly), and do not clearly separate the page from the concept that it describes. We have shown how SemperWiki addresses these limitations. 3
Having answered the first two questions, we now investigate the third question: how to navigate Wiki content?
When navigating an ordinary Wiki, all content is considered either a
hyperlink or some natural language text. The hyperlinks between pages can be
followed, and the full-text can be searched by keyword. But if users can not
exactly formulate their information need, an exploration technique is necessary
that helps users to discover data [
In our opinion, navigating a Wiki has two phases: looking for a page, and
looking at a page. In an ordinary Wiki, exploration in both phases is limited
to predefined hyperlinks. In Semantic Wikis, the semantic annotations structure
the Wiki content, and we can use that structure to offer improved exploration
through a technique called faceted browsing [
Existing approaches for faceted browsing rely on manually constructing the facets for a fixed data structure. But since Wiki content can form arbitrary and fluent structures (because users can add arbitrary annotations to pages), we need to adjust faceted browsing to arbitrary data structures.
In this section, we present our approach to automatically construct facets for an arbitrary semi-structured dataset, independent of its structure. 3.1
Faceted browsing is a superior exploration technique for large structured datasets
[
In faceted browsing, the information space is partitioned using orthogonal conceptual dimensions of the data (these dimensions are called facets). Each facet has multiple restriction values; users select a restriction value to constrain relevant items in the information space.
In the Semantic Wiki, a facet corresponds to an annotation predicate ap and a restriction value corresponds to an annotation object ao. The annotation subject is the result (or purpose) of the faceted browsing: faceted browsing is a search process that takes the predicate and object values as input and returns possible matching the subject.
For example, a collection of art works can consist of facets (predicates) such as type of work, time periods, artist names and geographical locations. Users can select a certain restriction value (object) such as the 20th century to constrain the visible collection to only some art works. Multiple constraints are applied conjunctively.
Existing approaches [
We combine several existing techniques to offer faceted browsing for arbitrarily structured data. Setting up faceted browsing for a specific dataset involves two steps: i) selecting proper facets and ii) partitioning each facet into a number of restriction values.
In most existing faceted browsers, both steps are done manually: an administrator examines the dataset (e.g. a museum collection), selects useful facets (e.g. time period, artist name, location), and partitions each facet into useful restriction values: e.g. the time facet would be divided in 20 centuries, the artist facet into 26 starting letters, and the location (hierarchically) into continent and then countries.
We focus on automation of the first step: selecting proper facets. 3.3
A facet should only represent one important characteristic of the classified
entity [
Frequency A good predicate has a high occurrence frequency inside the
collection. The more distinct resources a predicate covers, the more useful it is in
dividing the information space [
Object values A good predicate has a limited number of different object values (between 2 and 20). If there are too many different objects to choose from, then the options are difficult to display and may disturb the user. Intuition A good predicate reflects the scope of the information space and is intuitive for the user. For example, a user who only knows the author of some book will try to find it by using the facet “author”. Conversely, a user who only knows the title of a book will try to find it using the “title”.
We define three metrics (for the first three properties) that rank the appropriateness of each predicate; we exclude the mathematical treatment for brevity. Fig. 4 shows these metrics for a sample (CiteSeer) dataset. We cannot define a metric for intuition, since we cannot properly define intuition.
(b) power (a) Predicate frequency
Distinguishing
(c) Object values Frequency To measure the frequency of a predicate, we use a simple function based on the number of distinct resources that have the predicate. For example, in Fig. 4a we see that year and type occur frequently in the sample data. Distinguishing power To measure the distinguishing power of a predicate we use a simple function based on the number of distinct subjects having the same object. If each object has the same number of distinct subjects, the score of the predicate is highest. For example, in Fig. 4b we see that the predicate year is not very balanced: there are more publications in later years.
Object values For displaying and usability purposes (the user should be able
to have an overview of options and decide on a restriction value), the number of
different object values should be approximately between [
This section presents our prototype implementations of the previous ideas.
Our open-source prototype SemperWiki15 [
Fig. 5: SemperWiki prototype
We are currently porting SemperWiki to a Web architecture to make it
crossplatform accessible, using ActiveRDF [
Secondly, we have built a prototype that implements the automatic selection of facets. The resulting faceted browsing interface is shown in Fig. 6; please note that this interface is automatically generated for arbitrary data. In this dataset, year, type, booktitle and journal are the facets (selected from the predicates), and 1988, 1992, etc. are the facet values (annotation objects without clustering). The prototype is implemented in Ruby and ActiveRDF, and works on arbitrary RDF data sources through the generic RDF API of ActiveRDF.
We have not yet done a comprehensive assessment, but an initial evaluation19 looks promising: the metrics automatically select the most important predicates (such as year, type and author) as the most important facets. The results of our work allows us to give good answers to the three initial research questions of this paper. We are satisfied with this overall results but we will also have in the following a short discussion about possible unsettled points.
Our approach for annotation in the Semantic Wiki ignores the context of annotations. Actually, to our knowledge, all annotation approaches ignore the notion of context. More research is needed on identifying and on modelling context of annotations. 19 On a sample CiteSeer dataset from http://www.csd.abdn.ac.uk/∼ggrimnes/swdataset.php.
Secondly, when annotating Wiki concepts we might encounter a naming ambiguity if two people use different URNs for the same real-world concept. But a large-scale social system as Wikipedia shows us that naming ambiguity tends to resolve over time (people reuse socially accepted names), especially if enhanced with a popularity-based recommendation system.
The solution for the representation problem of documents vs. pages, as presented in Sect. 2.3, has one drawback concerning existing RDF data. Unfortunately the world is already full of RDF statements that do not clearly distinguish documents and pages, but use URLs to refer to both. Employing our solution, encountering a URN as subject we would know that the concept is meant, but encountering a URL we would not be sure that the document is meant; the URL could be a “legacy” URL that does not conform to our distinction and is (wrongly) used to identify a concept. Our solution has therefore only limited applicability, but that is unfortunately the nature of the problem. 6
As explained in the introduction, a Semantic Wiki needs to address three questions:
2. how to formally represent content? 3. how to navigate content?
We have developed an elaborate model of annotations and shown how SemperWiki –as opposed to other Semantic Wikis– supports very rich annotations. We have shown how to formally represent content, and shown how SemperWiki – as opposed to other Semantic Wikis– correctly distinguishes between documents and concepts, without limiting the possible annotations. Further, we have presented how the existing technique of faceted browsing can be adjusted to flexible semistructured data, by automatically constructing facets from the data. Finally, we have developed metrics for facet (predicate) selection and techniques for object clustering inside each facet.
Faceted browsing is a superior data exploration technique [
We are currently extending our work in several directions. First, we are integrating the faceted browser into the Web version of SemperWiki. Secondly, we are developing the clustering step of the faceted browser, and evaluating the quality of the facet construction algorithm. Thirdly, we are working on a page recommendation system, that works in the second phase of Wiki navigation and recommends (similar or related) pages to the current page, based on the structure of the Wiki content.