=Paper=
{{Paper
|id=Vol-206/paper-14
|storemode=property
|title=A Wiki as an Extensible RDF Presentation Engine
|pdfUrl=https://ceur-ws.org/Vol-206/paper14.pdf
|volume=Vol-206
|dblpUrl=https://dblp.org/rec/conf/semwiki/RauschmayerK06
}}
==A Wiki as an Extensible RDF Presentation Engine==
https://ceur-ws.org/Vol-206/paper14.pdf
A Wiki as an Extensible RDF
Presentation Engine
Axel Rauschmayer and Walter Christian Kammergruber
Axel.Rauschmayer@ifi.lmu.de
Walter.Kammergruber@gmail.com
Institut für Informatik
Ludwig-Maximilians-Universität München
Abstract. Semantic wikis [1] establish the role of wikis as integrators of
structured and semi-structured data. In this paper, we present Wikked,
which is a semantic wiki turned inside out: it is a wiki engine that is em-
bedded in the generic RDF editor Hyena. That is, Hyena edits (struc-
tured) RDF and leaves it to Wikked to display (semi-structured) wiki
pages stored in RDF nodes. Wiki text has a clearly defined core syntax,
while traditional wiki syntax is regarded as syntactic sugar. It is thus easy
to convert Wikked pages to various output formats such as HTML and
LaTeX. Wikked’s built-in functions for presenting RDF data and for
invoking Hyena functionality endow it with the ability to define simple
custom user interfaces to RDF data.
Keywords: Semantic wiki, RDF, wiki engine, wiki syntax, RDF presentation.
1 Introduction
What would later be called Wikked started as a project about one and a half
years ago, when we discussed combining two of our favorite technologies: RDF
and wikis. We never thought that this combination would carry us as far as it
did (which we think bodes well for the newly-named community of “semantic
wikis”): Initially, we had an RDF editor called Hyena and just wanted to mark
up and link pages with it. So we implemented the small wiki engine Wikked
and embedded it in Hyena. In the end, Wikked grew far beyond its basic func-
tionality and is now even used for constructing small custom user interfaces that
display and manipulate RDF. The current focus of Wikked is to complement
the GUI-based Hyena and not to replace it with a full-blown web-based RDF
editor. One can, however, run Hyena in a web server mode and have Wikked
act as a “normal” wiki (Sect. 5).
This paper is directed at members of the semantic wiki community, and thus
we neither explain RDF [2, 3] nor wikis [4]. It has the following structure: The
next section describes how Wikked fits into the whole of the Hyena picture and
what Fresnel lenses are. Sect. 3 explains the core components of Wikked, Sect. 4
walks the reader through an example. Sect. 5 illustrates Wikked’s advanced
features such as an interactive command line and a web mode. We end the
paper by giving related work, future research and a brief conclusion.
Fig. 1. A typical Hyena window: To the left is a standard view on the file system.
Center bottom is the editor for the currently open file, center top is a view that lists all
RDF nodes in that file. The editor shows the content of the currently selected resource.
To the right, there is a view displaying the context of the selected resource: incoming
links and functions that can be applied to it.
2 Background
2.1 Hyena
Hyena is a generic RDF editor that has been implemented as a plugin for
the Eclipse Rich Client Platform [5] Fig. 1 shows what a typical Hyena en-
vironment looks like. Hyena’s internal architecture is depicted in Fig. 2. Sup-
port for an RDF vocabulary in Hyena is provided by plugins called vodules
(vocabulary modules). Vodules take care of three different facets of RDF edit-
ing: First, a vocabulary has associated declarative data such as OWL constraints,
rdfs:comments and rdfs:labels. Accordingly, each vodule can contribute a sub-
graph 1 ; every container (or graph) of RDF data that is managed by Hyena is
composed of several subgraphs. Second, there will always be RDF data formats
that cannot be meaningfully edited with a generic editing mechanism. Thus,
vodules can implement their own custom widgets for node editing. Third, im-
perative knowledge might be needed for manipulating RDF data. Vodules add
1
The reader might know subgraphs under the moniker named graphs [6]. We have
emulated this feature before implementations in RDF engines (such as Sesame [7]
became available, which is why we are still using this legacy name.
Vodule
Function "Vocabulary Module"
Public functionality, e. g. * contributes that packages
for manipulating RDF everything that is
nodes contributes needed to edit a specific
RDF vocabulary
* contributes
Subgraph
Sometimes called a is a
"named graph", contains
declarative data such as is a
lenses and namespaces Fresnel Lenses
Vodule for editing lenses
*
Displayer Wikked
GUI widget for editing a Vodule for editing RDF
certain kind of node nodes with wiki content
Hyena User Interface Components
Fig. 2. The main components of Hyena’s user interface are functions, subgraphs and
displayers. A vodule supports editing of RDF vocabularies by making cross-cutting
contributions to each group of components. Vodules for Fresnel lenses and Wikked
pages provide editing support for these vocabularies.
these to Hyena as functions. Note that functions can both be accessed via the
GUI and as Wikked commands.
2.2 Fresnel Lenses
The Fresnel Display Vocabulary [8] is the foundation of Hyena’s generic editing
facilities. This vocabulary is used to define how nodes of a given type should be
displayed. One such definition is called a Fresnel lens. The most basic version
of a lens needs to state what properties should be displayed and in what order.
As an example, here is a minimal lens for the “Friend of a Friend” vocabulary
(FOAF, [9]) written in Notation 3 [10] syntax (taken and abridged from [8]):
:foafPersonDefaultLens rdf:type fresnel:Lens ;
fresnel:classLensDomain foaf:Person ;
fresnel:showProperties ( foaf:name
foaf:surname ) .
We have given this lens node the URI :foafPersonDefaultLens and as-
signed it the type fresnel:Lens. The lens applies to nodes of type foaf:Person
and displays first and last name (in that order; the value of fresnel:showProperties
is an rdf:List). Advanced Fresnel features include more sophisticated format-
ting (display a property value as plain text, a link, an image, . . . ) and negative
definitions (display all properties except X). Fresnel lenses have the advantage
that one can deliver data together with instructions on how it is to be displayed.
The result of applying a lens to a node is called a projection in Hyena.
3 Wikked and WITL (Wikked Template Language)
Wikked is the complete wiki engine, WITL the formal language used for mark-
ing up a page. In this section, we will go into details about the design decisions
we have taken. They were based on several requirements we had: Initially, We
had the RDF editor Hyena and wanted to add notes in rich text. The simplest
solution was to start with plain text and support some wiki markup such as
headings, lists, tables and text styles. Soon it became obvious that it would be
nice to have the ability to display RDF data inside these nodes. For that, we
needed a more complete syntax and gave WITL a bracket-based core syntax
reminiscent of XML. We still support wiki markup by translating it to the core
syntax. RDF integration gave us the ability to refer to other nodes. As wiki
pages were just another kind of node, we arrived at the most basic wiki func-
tionality: markup and linking. Having a syntax with a proper LL(k) grammar
makes it easy to translate our notes to different target markup languages: Apart
from the obvious choice of HTML for rendered display of a note, we can also
produce LaTeX. This proved handy for situations where one does some quick
brainstorming with bullet lists and headings and is able to move on to LaTeX as
a more professional publishing format later. The data we presented using WITL
was still static. We wanted to add more interactivity and were able to do so by
making it easy to extend the WITL vocabulary in Java and by opening up the
rest of Hyena to Wikked. Now WITL commands allow one to apply functions
to RDF nodes.
The Case for Plain-Text Markup. The most obvious reason we went with plain-
text editing is that it is much easier to implement than a true WYSIWYG editor.
Hyena’s users are very technical, so it was to be assumed that they would be able
to handle the challenge. Later, we will still be able to add a WYSIWYG editor.
But as WITL is to be frequently extended, typing a plain text is paradoxically
often more usable than visual editing. LaTeX’s ongoing popularity is testament
to that. Furthermore, plain text is still the most convenient, most widely used
and most cross-platform data format. For example, even if you know nothing
about wiki markup, you are still bound to use it if you are sending an email
with a bullet list from a Windows computer to a Linux computer and store it
in a version control system there. One final consideration is that WITL has to
be easier to type than XML, which we otherwise could have used instead. We
start this section with a quick example and follow up on it with a more detailed
explanation.
3.1 WITL by Example
Before we properly introduce the syntax, we give an example of WITL markup:
The {i:core syntax} uses {b:braces} to delimit markup directions.
Simple links follow the same scheme: {http://hypergraphs.de/}.
Further arguments are separated by carets:
{http://hypergraphs.de^Hypergraphs web site}.
- Then there is also wiki-inspired syntactic sugar
that is translated into the core syntax.
- Bullet lists, **bold**, ~~italics~~ etc. all work.
3.2 Core WITL
At heart, all generic markup languages look very similar: Be it XML, LaTeX or
Lisp’s S-expressions [11], there are always nested named terms. If you didn’t like
S-expressions being part of this last list (because they are not really a markup
language), you can already guess at the hybrid nature of WITL: On one hand,
commands should be easy to type. On the other hand, text will usually domi-
nate, whereas in, say, Java, it can only appear within quotes. So what will our
nested terms look like? As they have to be easy to type, XML’s named clos-
ing brackets are out and terms where only the beginning is named are in, as
in simple LaTeX commands and S-expressions. Let us start by putting braces
around URLs which have to be easy to embed if Wikked is to be worthy of
the “wiki” moniker. We opted for braces, because they appear less frequently in
plain text than parentheses and square brackets2 . We then generalize this syntax
to {tag:argument} where http or ftp of an embedded link is just another tag.
To allow more than one argument, we introduce the caret “^” as an argument
separator. Again not for esthetic reasons, but because it appears rarely in plain
text (as opposed to the ampersand &, less-than < or greater-than >) and because
we will use some of the other candidates (such as the pipe symbol |) for wiki
markup later. This leads us to expressions such as
Text in {b:{i:bold italics}}
A link to {a:http://external.com^External Corp.}
Comments are written as {* Comment *}. Next, if we are to integrate Java,
we need a way to express method invocations: creating a list (with the String el-
ements ‘‘a’’ and ‘‘b’’) and invoking method add on it, to append the element
‘‘c’’, is expressed as {{List:a^b}add:c}.
The final two constructs are raw text and pairs. Raw text is for circumventing
WITL when it isn’t powerful enough: whereas typical plain text will have critical
characters (such as less-than in XML) of the target markup language escaped,
raw text is taken verbatim. Therefore one can directly add code in the target
language. Raw text syntax is [[[raw text]]]. Pairs have two roles: We use
them as a basic data structure, among other things to encode maps and we
use them for specifying options for a function without getting lost in positional
parameters. These two roles are quite related: options are passed to a function as
a separate argument containing a map from string to arbitrary data (specified
by the user as a sequence of pairs). Pairs are written as {key=value}. Fig. 3
gives an overview of the core syntax.
2
Additionally, we want to keep the option open of using square brackets for citations.
Plain text is default, the following constructs are always
started by special character.
{a:url^text} a wikked function, most HTML tags are defined
{http://foo.com} links fit naturally into the syntax scheme
{{List:xxx}add:12} method invocation
{key=value} a pair (e. g. for optional arguments)
[[[raw]]] ”raw” or unescaped text; use to insert HTML
{* Comments *} ignored...
{:varName} synonym for {get:varName}
Fig. 3. The core syntax of WITL.
3.3 Wiki Markup
While the syntax we have introduced so far is very regular and easy to define, for
some of the more commonly used markup, it would be nice to have more “visual”
text markup, just like traditional wikis have. Note that for many constructs, this
syntax is line-based and largely incompatible with our term/bracket-based core
syntax. As we don’t want to lose our core syntax, parsing happens in two stages
in Wikked: First, we parse the core terms. Second, we parse lines inside the
terms and translate traditional wiki markup to core WITL. While a sequence
of lines always starts when a term opens and ends when it closes, a single line
can contain both plain text and nested terms. A plain text newline finishes a
line. Through this translation step, wiki markup is syntactic sugar for the core
syntax. Fig. 4 shows what markup is available. We have intentionally left out
breaks and separator lines as these can be cleanly expressed with normal WITL
as {br} and {hr}.
3.4 Java Integration
We initially experimented with turning WITL into a full-blown programming
language, but it turned out that that was very cumbersome. We didn’t have
the development tools we were used to (life without automated refactoring is
painful) and WITL syntax is more suited for markup than for programming.
As we needed to bridge over to Java anyway3 , we chose to stay very close to
Java when it came to defining WITL’s semantics and libraries: WITL is a func-
tional language whose values are Java objects. For example, when evaluating
the expression {func:[[[]]]^} the first argument is passed to
the function func as the Java text string ‘‘’’, while the second argu-
ment is escaped first and then also passed as a string. Escaping depends on
the currently used target language; for HTML the second argument becomes
‘‘<arg2>’’. Functions cannot be defined (only applied) in pure WITL.
They are defined by registering Java objects with the WITL interpreter. Every
method in such an object hat has been marked with a special annotation [12] is
3
It is, after all, the implementation language of Wikked and Hyena
==== Heading Level 1 ==== Heading Level 1
=== Heading Level 2 === Heading Level 2
== Heading Level 3 == Heading Level 3
= Heading Level 4 = Heading Level 4
Paragraphs Paragraphs are
are
separated by blank lines
separated by
blank lines
Tabs lead to Tabs lead to
indented (quoted) text
indented (quoted) text
**bold** bold
~~italics~~ italics
’’teletype’’ teletype
- Bullet lists • Bullet lists
- can be • can be unordered
unordered 1. or ordered.
+ or ordered. 2. One can also nest them.
+ One can also nest them.
: Colons Colons
are for definition lists with are for definition lists with
: term term
and definition and definition
|| Table | Heading | Table Heading
| cells | in the | cells in the
| table | body |
table body
% single-line comment
Fig. 4. Wiki markup supported by WITL.
afterwards visible as function in WITL. Before applying a function, WITL com-
pares the number and type of the function arguments to the method signature
and makes sure that both correspond. This mechanism facilitates unit-testing
and building new functions by composing existing ones. In both cases one can
stay in Java and does not have to invoke WITL in any way.
3.5 RDF Integration
A wiki goes from mere text to hypertext by allowing one to link pages. There
are two directions of RDF integration in Wikked: First, wikked pages live in-
side RDF, they are normal RDF nodes, with attached literals that store the
page content. We are discouraging the use of blank nodes for wiki pages and
automatically generate a URI node when the user wants to create a new page4 .
The reason for this is that blank nodes cannot (stably) be exported as public
locations. Interestingly, RDF frees us from purely name-based identification of
pages. At the cost of slightly increased complexity, we got rid of problems such
as renaming, support for multiple languages and disambiguation.
Second, one can access RDF content with WITL. The most basic function-
ality here is to link to other nodes which can by either other Wikked pages or
arbitrary RDF content. Hyena uses the types of a node to determine whether
they should be displayed as wiki pages or as something else. Now, where tra-
ditional wikis embed the links to other entities inside the text, this is not a
good option for RDF; renaming a node would result in the connection being
broken. The solution is to reify that connection in RDF. This happens in two
complementary ways:
– Subject linking: Whenever the user has one specific RDF node in mind, he
just pastes its URI into the WITL source; e. g. as {subj:http://my-node.com}.
Before saving, Wikked converts the source in the following manner: The
page node is used as a rdf:Seq of all nodes referenced by subject links.
Therefore, the first subject link is the value of property rdf:_1, the second
one of property rdf:_2, etc. The argument of the subj function is then
changed to be the Seq index. If the above example is the first subject link,
it will be changed to {subj:1}. All this happens transparently to the user:
Before the user edits the page the next time, we put the URIs back in. We
have thus moved the actual link out of the source code into a triple. Insert-
ing the link target into the source on-demand guarantees that it is always
current. Fig. 5 shows subject linking in use.
– Object linking: If the user has attached a set of RDF nodes, he specifies
the property he has used, as in {obj:http://my-predicate.com}. When
displaying the page, Wikked lists all values of that property. Fig. 9 is an
example of object linking.
3.6 Skins
Skins are a feature that has been created for the web (or non-embedded) person-
ality of Wikked. When creating web sites, it is often desirable to have reusable
4
A page node can be easily renamed to a neater URI at any time.
frames for certain subsets of the pages. This is what Wikked provides with
skins: The current display state is denoted as a stack of page IDs (namely, their
RDF nodes). The bottom of the stack is the actual content, an arbitrary amount
of skins can be pushed on top of it:
Index Kind of page
... etc.
2 meta-skin (e. g. content that is the same for the complete web site)
1 skin or meta-page (e. g. a frame for one section of a web site)
0 base page (actual content, without user interface frames)
Rendering of a composite page is performed by going through the stack,
starting with the topmost page. Each page is evaluated and passes evaluation on
to the next stack element with a special function. The result of the evaluation is
usually a text string. This kind of nesting can be compared to around methods
in CLOS or super calls in Java. While navigating through the site via links, each
transition can specify to either remove or replace elements of the page stack.
That is, one can display the same page with a different skin, a different page
with the same skin, (prudishly) not show any skin, etc. In case a skin wants to
display properties of the content page, we allow it to access the page stack. The
index of the content page is always 0, the first skin has index 1, the meta-skin
has index 2 and so on. Whenever one starts up Wikked without specifying what
page to display, it fills the stack with a default URI for the start page (index 0)
and the start skin (index 1).
4 Example
(a) Editing the page (b) Displaying the page
Fig. 5. (Left) We pick the title “To Do” for the new page and type the actual content
in the text field at the bottom. The empty subject link will get us the option to create
a new page. (Right) Using the combo box in the top right corner, we switch the view
from WITL source to rendered HTML.
– Let us say we want to use Wikked to create a page with things we have
to do. We use the standard Hyena command for creating a new node and
assign it the type wikked:Page. Afterwards, we can select a (type-sensitive)
displayer for entering the wiki text. We decide on a fitting title for our page
and type the text containing the to-do items (Fig. 5(a)). Note that we have
not used core WITL, but rather the wiki markup for bullet lists. If we leave
the subject argument empty, Wikked will display a link with which we
can create a new page node. Next, we pick a different view of the currently
displayed node: whereas up to now, we have looked at WITL source, we now
switch to rendered HTML (Fig. 5(b)).
– Before we continue with sketching what we want to tell Harry, we decide
that it makes sense to refer him to two papers of ours. This allows us to
put Wikked’s RDF integration to use: We parse our BibTeX bibliography
with the external BibTeX-to-RDF converter “bibtex2rdf” [13]. Then we use
the Fresnel display vocabulary [8] to tell Hyena how to display the BibTeX
entries. A Fresnel lens declares (per RDF schema class) what properties to
display and in what order. Hyena has a built-in lens editor, so creating the
lens only involves the following four simple steps: First, create a new lens.
Second, add a new property specifying what class this lens applies to. Third,
use a predefined Hyena command to collect all used properties from the
RDF instances in our RDF graph. Fourth, remove those properties that are
to be ignored (none in the example) and rearrange remaining ones via drag
and drop until we are satisfied with their order (Fig. 6).
Fig. 6. Hyena has a built-in editor for Fresnel lenses. This figure shows the finished
lens where the properties have been automatically filled in by looking at all instances of
bibtex:InProceedings. The boxes to the right of the predicate names can be dragged
and dropped to rearrange the order in which properties will be displayed when using
the lens.
– After we have defined the Lens, we want to try it out. First, we use a Hyena
view to show us all instances in the current RDF graph that our lens applies
to (its projections, Fig. 7). Then we click on a list item and have its contents
displayed as defined by the lens (Fig. 8).
Fig. 7. The “Projections” view in Hyena allows us to list all instances that
can be displayed with a certain lens. Here we are displaying all instances of
bibtex:InProceedings.
Fig. 8. One projection of our InProceedings lens. In the top right corner you can see
that using the lens is just another way of displaying a node.
– Now we can create the new Wikked page to hold the citations for Harry,
add rdfs:seeAlso properties referencing the BibTeX entries, and write a
corresponding object link in WITL (Fig. 9(a)). The rendered result is shown
in Fig. 9(b).
– To conclude, we do something a little more fancy: we want to have the same
set of citations as before, but this time we want them displayed in a bullet
list. Furthermore, if someone clicks on a link, we want to search Google for
the paper title, in an external browser. This looks as follows:
Click on any of these papers to search for them via Google:
{ul:
{obj:rdfs:seeAlso^^
{li: {evalLater:{present:{:ANCHOR}}
^{util.google:{literal:{:bibtex:title}}}} } } }
We use an extended version of the object-linking function obj which has
three arguments where the first one contains a property URI, the second op-
tions and the third an expression that will be re-evaluated once for each ob-
ject. During each evaluation, the property values of the current object will be
bound to WITL variables. Within the third argument, function evalLater
displays a link (whose text is the first argument) and postpones evaluating
its second argument until after the link has been clicked. The function we
postpone is util.google which opens an external browser window with the
(a) Editing the page (b) Displaying the page
Fig. 9. (Left) We are using an object link to encode the list of citations we want to
tell Harry about. (Right) The citation list rendered via HTML.
result of a Google query. Furthermore, the helper function present lets us
display a node as “prettily” as possible, i. e. it considers display aids such
as an attached rdfs:label. Function literal extracts the plain text of a
literal. Note that we cannot use wiki markup for iteratively creating the bul-
let list, because the scope of wiki markup does not extend beyond a single
function brace.
5 Command Line and Web Serving
Fig. 10. An interactive session with the WITL command line: We evaluate bold
markup in two variations; present a prettified version of a wiki page node; and show
how editing is added to a page (it can be added to sets of pages via a skin). Note that
one can make out in the produced HTML that the start page is currently selected in
Hyena. Output is shown as it would be encoded in WITL.
Hyena also comes built-in with a Wikked command line where one can
interactively execute WITL code (Fig. 10). What node is currently selected in
Hyena is also reflected in the evaluation environment of the command line, so
one can explore what source code will look like when evaluated “inside” a page.
Hyena, and thus Wikked, can be started in different modes: It can be
started with Eclipse, as a plug-in. But it can also be started stand-alone, ob-
viously with limited functionality. That last mode makes more sense when one
Fig. 11. Hyena’s document hierarchy: First is a container www that serves static web
pages, second is the configuration container config, last is an Eclipse container with
all currently open documents (currently, only “semwiki.rdf” is open). Every container
is accessible via its URI, for example, you are currently seeing the answer to a GET
request to the configuration container.
considers that Hyena can also be used for web-serving: either via Jetty, a small
embeddable web server or as a servlet5 . Jetty can be activated in conjunction
with Eclipse. As a web server, Hyena manages the currently open files in a
named hierarchy of containers. A unique name plus the server address results
in a component having a unique URI. These URIs are used in Hyena’s ReST-
based web service [14, 15] API. While each container can provide a customized
reaction to web requests the most common use cases are: GET requests display
web pages and download data, PUT requests upload RDF files (including wiki
definitions), POST requests allow one to react to form input and DELETE re-
quests remove containers. Several standard containers6 are available: container
www serves static web pages stored in the standard Hyena directory, container
config provides configuration and status information about currently active con-
tainers (Fig. 11) and, if Eclipse is running, there is an eclipse container that
publishes all currently open Hyena documents. For example, we can display the
running example in the web browser by clicking on semwiki.rdf.
6 Related Work
EclipseWiki [16] is a plugin for Eclipse that allows one to edit text files as wiki
pages and to embed links to Eclipse resources. In contrast, Wikked is more
specialized: It has RDF integration and can even link to markers inside files.
ZML [17] from the Rhizome Wiki has markup rules that are similar to ours,
but differs in two important aspects: First, it can “natively” express full HTML
which Wikked foregoes in order to support both LaTeX and HTML; one can
still use raw text as a last resort in Wikked. Second, ZML’s syntax is purely line-
based where WITL’s syntax is a hybrid of bracketed and line-based constructs.
XSDoc Wiki [18] is used for integrating different development artifacts inside
a wiki. Instead of RDF, it normalizes all data as XML and has powerful import
5
Even with Jetty, Hyena establishes connection through a servlet.
6
More containers can be added programmatically at any time.
facilities. XSDoc has more in common with Wikked than is apparent at first
glance: Hyena partly specializes in using RDF for software engineering. One
can, for example, reify Java source code locations as RDF nodes and refer to
them in Wikked. While we do not have XSDoc’s flexible format support, we do
think that RDF is a better data format when it comes to linking and by using
Eclipse to track locations, our linking becomes even more robust.
In the Wiki-Templates paper [19], the authors prominently express the need
to support structure in wikis. Thus Wiki-Templates provide sophisticated sup-
port for structured data entry. Lenses provide much of the same functionality
for Wikked, but projections are not (yet) embeddable inside a wiki page. Fur-
thermore, storing data in RDF has the advantages of being clearly defined and
standardized, as opposed to the custom approach taken by Wiki-Templates.
7 Future Research
One way we could go with Hyena is to put more emphasis on its currently
underdeveloped web-serving abilities. It would have to be based on Ajax [20] (or
Comet [21]) and fully support Fresnel lenses and SPARQL queries. Additionally,
we do not currently provide any way of authentication or encryption. Finally, it
would be nice to combine blog and wiki into something that has been called a
Bliki [22]. Because Wikked is RDF-based and thus highly structured, this would
be a very natural extension, as opposed to some of the kludges that currently
exist.
8 Conclusion
In this paper, we have shown how Hyena and Wikked tackle the problem of
integrating structured and semi-structured data. This problem is very pertinent
to wikis and even more so to semantic wikis. Our answer is separation of con-
cerns: Hyena edits (structured) RDF data, whereas the embedded wiki engine
Wikked is responsible for displaying (semi-structured) wiki content “inside”
RDF nodes. We found that this separation of concerns has great usability ad-
vantages. It also turns the typical semantic wiki inside out: the wiki is embedded
in an RDF editor and not the other way around. Wikked has been adapted to
RDF in one important way: links to data (including other pages) are reified as
true RDF relations and not hidden in the wiki text. That means that Wikked
pages are relatively robust regarding changes in the RDF such as node renam-
ing. Finally, Wikked further enhances Hyena by letting the user invoke Hyena
functionality from within a wiki page. As a result, one can make wiki pages more
interactive.
Acknowledgements. The authors would like to thank Hubert Baumeister for
introducing them to Wikis, when they were still an insider tip; and the SemWiki
workshop reviewers for their comments and their contributions to the section on
related work.
References
1. Wikipedia: Semantic Wiki. http://en.wikipedia.org/wiki/Semantic Wiki (2006)
[Online; accessed 2006-05-02].
2. Rauschmayer, A.: A Short Introduction to RDF for Software Engineers. (2005)
3. Manola, F., Miller, E.: RDF Primer, W3C Recommendation.
http://www.w3.org/TR/rdf-primer/ (2004)
4. Leuf, B., Cunningham, W.: The Wiki Way: Collaboration and Sharing on the
Internet. Addison-Wesley (2001)
5. Eclipsepedia: Eclipse Rich Client Platform.
(http://wiki.eclipse.org/index.php/Rich Client Platform) [Online; accessed
2006-05-02].
6. Carroll, J., et al.: Named Graphs. (http://www.w3.org/2004/03/trix/) W3C In-
terest Group.
7. Broekstra, J., Kampman, A., Mika, P., et al.: Sesame Home Page.
(http://www.openrdf.org/)
8. Semantic Web Interest Group: Fresnel - Display Vocabulary for RDF.
http://www.w3.org/2005/04/fresnel-info/ (2005)
9. : The Friend of a Friend (FOAF) project. (http://www.foaf-project.org/) [Online;
accessed 2006-05-02].
10. Berners-Lee, T.: Notation3 (N3) a Readable RDF Syntax.
(http://www.w3.org/DesignIssues/Notation3.html)
11. Wikipedia: S-expression. http://en.wikipedia.org/wiki/S-expression (2006) [On-
line; accessed 2006-05-04].
12. Bloch, J., et al.: A Metadata Facility for the Java Programming Language (2002)
Java Specification Request 175.
13. Siberski, W.: bibtex2rdf - A Configurable BibTeX to RDF Converter.
(http://www.l3s.de/ siberski/bibtex2rdf/)
14. Fielding, R.T.: Architectural Styles and the Design of Network-based Software
Architectures. PhD thesis, University of California, Irvine (2000)
15. Prescod, P.: Second Generation Web Services.
http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html (2002)
16. Walton, L., Walton, C.: Eclipse Wiki Editor Plugin.
(http://eclipsewiki.sourceforge.net/)
17. Liminal Systems: ZML (Zippy Markup Language).
(http://www.liminalzone.org/ZML)
18. Aguiar, A., David, G.: WikiWiki Weaving Heterogeneous Software Artifacts. In:
Proc. Int. Symp. Wikis, ACM Press (2005)
19. Haake, A., Lukosch, S., Schümmer, T.: Wiki Templates—Adding Structure Sup-
port to Wikis on Demand. In: Proc. Int. Symp. Wikis, ACM Press (2005)
20. Garrett, J.J.: Ajax: A New Approach to Web Applications.
http://www.adaptivepath.com/publications/essays/archives/000385.php (2005)
21. Russell, A.: Comet: Low Latency Data for the Browser.
http://alex.dojotoolkit.org/?p=545 (2006)
22. Fowler, M.: What is a Bliki? http://www.martinfowler.com/bliki/WhatIsaBliki.html
(2003)