This paper presents a tool for semantic personal knowledge management called Hypertext Knowledge Workbench (HKW), an editor and browser for semantic personal knowledge models. The tool is designed to be used by a single person to manage her personal notes about any topic that seems relevant. Existing wikis and semantic wikis represent content as pages with a title and content. Hypertext-based Knowledge Workbench (HKW) o ers a more powerful yet simple to use conceptual model and allows entering and using knowledge in di erent degrees of granularity and formality.
In 1958, Peter F. Drucker [
Frand and Hixon [
Polanyi [24] makes a distinction between explicit knowledge encoded in
artefacts such as books or web pages, and tacit knowledge which resides in the
individual. Concerning explicitness of knowledge, Nonaka and Takeuchi [20]
distinguish two kinds of explicitness: explicit and tacit. Later works [
HKW is intended to serve as a personal log book for all kinds of knowledge. E. g. it can be used to record ideas, bookmarks, text modules for or from documents, contact data of persons, notes on sport exercises, cocktail recipes, places to travel to, list of friends who enjoy Chinese cuisine, favoured artists and their interrelationships, nice restaurants, etc. These items often have relations that cannot be represented in specialised tools, e. g. friends living in the cities where I know a nice restaurant; text modules uses in which documents?; idea resulted in which publication?; who knows more about this topic?; who has a record from this rare music artist? The user can decide whether she represents e. g. a relation between a person and a music artist as a tag, a link, typed link or just in natural language. HKW is designed to relief the user from deciding \Will it be worth the e ort to take this note?" and \Where do I le this?" Authoring in HKW is \pay as you go", with very low initial costs yet expressive modelling abilities in the same tool. A user can record any thought at low costs and might develop it later into more structured, more linked, more important notes. HKW can represent structured knowledge from any domain, because the relations and types can be changed and extended by the user at runtime. Informal knowledge represented as plain text or structured text needs no de ned types and relations. 1.1
Existing approaches to personal note management are paper-based approaches
such as sticky-notes, paper notebooks, and a \Zettelkasten" [
There are many software-based approaches for note management; almost
all of them allow full-text search and a virtually unlimited amount of personal
notes. Unfortunately, search is not enough for PKM. As Barreau and Nardi [
create links between notes. Such tools include blogs, wikis, PIM tools, mind map tools, and desktop wikis. These tools o er better usability for quickly creating structured content and linking it with exiting notes. However, if a knowledge base grows to thousands of notes, mere store and retrieval reaches its limits. E. g. which of your recipes were tasty when you tried but do not contain too much chilli, because Dirk does not like chilli? You want to go to Heidelberg { what was the name of the nice restaurant you went to together with Claudia last summer? Or imagine you keep a diary where you occasionally note your running times. Suddenly you weight more than the year before. Did you went running less often than the year before? Most real-world use-cases are not restricted to single domains, rather it is typical to have links across multiple domains (here: recipes, people, travel, sports).
It is obvious that a system can support searching and browsing better, the more structured, more formal the content is. However, requiring to formalise all content is too expensive. Therefore plain ontology editors are not good PKM tools. A system should let the user decide at each step how much formalisation e ort to put into the system. For numerical knowledge, spreadsheet applications such as Microsoft Excel, are an example for the ability to formalise knowledge. A user can either use a spreadsheet just like a sheet of paper or link di erent cells into complex formulas. In a similar way, semantic wikis allow the same exibility for conceptual knowledge. A user can|but is not forced to|formalise link and page types.
Semantic wikis are designed and used not only for collaborative use but also for personal knowledge management (PKM) [21, 23]. Semantic wikis do allow stepwise formalisation of content: First a page is created, then lled with text, spell-corrected, structured, re-structured, and linked to other pages. Then links are typed and pages linked to categories. Ironically, just like with paperbased approaches, changing things is not that easy in semantic wikis. Tasks such as moving content from one page to another or renaming a relation require typically an administrator to run scripts over the database. Second, a common use-case of PKM tools is the need to import knowledge from external sources. In most semantic wikis, the import of semantic data needs to be represented by arti cially generated wiki syntax inserted into pages.
mantic wikis. HKW (a) is backed by a more exible data model, (b) allows to create and change formal statements easily, and (c) integrates authoring, structuring and formalisation. 1.2
The remainder of this paper analyzes the conceptual model of wikis and semantic wikis and compare it to the conceptual model of HKW, called Conceptual Data Structures (CDS) (Sec. 2). In Sec. 3 we analyse the annotation abilities of CDS compared to semantic wikis. We report on the HKW user interface in Sec. 4. In Sec. 5 we compare CDS and HKW to related work before we conclude in Sec. 6.
A conceptual model is not to be confused with a technical data model. As an analogy, compare the technical level of the le system, which consists of nodes, blocks, node tables and le allocation tables, with the user-perceived model: A strict tree containing folders and les.
Wikis have a simple conceptual model: Each page has a name, which is a short string that can be typed on a keyboard and often be remembered by the users. Attached to each page title is the wiki page content. Page content consist of a longer string of characters which are interpreted by the wiki render engine to produce HTML. Special syntax in the page content is interpreted as links to other pages. Links are established by referring to other wiki page titles. Empty wiki pages represent concepts with no description attached.
In semantic wikis, e. g. Semantic MediaWiki [
The conceptual model of HKW | called Conceptual Data Structures
(CDS) | is a generalisation of that model. CDS [26, 27] consists of two layers:
The CDS data model and the CDS relation hierarchy. The semantics of CDS
re-use some of the semantics of RDFS [
The CDS data model1 is a technical data model to represent knowledge. However, most parts are intended to be directly exposed to the user as a conceptual model.
The conceptual model consists of six primitive types. Fig. 1 shows the technical data model with the conceptual parts shown in bold. We describe brie y how the conceptual model works from a user's perspective. This conceptual model is exposed to the user in HKW.
Model A Model can be opened or saved, just like other documents. A Model is a container for items. Such items might be items with content (i. e. NameItems, ContentItems, Relations, or Statements) or automatically appearing triples.
Under the hood: Each Model has a URI. In RDF, each model is represented
as a Named Graph [
ContentItem These are simple text snippets, like the content of a wiki page or a sheet of paper. One can write anything into such a note. The system records automatically creation date, change date and author. One may use wiki syntax to format the note, or link to NameItems by referring to their 1 It is the successor of the \Semantic Web Content Model" (SWCM) presented in [25]
Model contextURI : URI
0..n source target relation Triple
Item (abstract)
0..1
ContentItem Statement
NameItem Relation
inverse
name. Like a wiki page, a ContentItems content size can range from very
short to very long. It may also be the case that a ContentItem has no content.
Under the hood: Each item (i. e. NameItems, ContentItems, Relations, and
Statements) has a unique URI to reference it. Even if the content of an item
changes, the references remain the same. No content can appear outside of
Items. Each piece of content is thus addressable, which makes it easier to
record metadata and introduce versioning. Currently there is no versioning
of content. The representation of content is modelled after resources on the
web (c. f. [
Current triple stores are not designed to handle large byte streams. NameItem A NameItem is just a name. It is like the title of a wiki page or the name of a le within a folder. Like in a wiki, a NameItem must be unique within a model. NameItems do not have any content (besides their name) but it is easy to create links to other items. NameItems allows a user to jump directly to certain entities in the knowledge model, similar to navigating to a known wiki page. Other items can be reached indirectly through search or browse actions.
Under the hood: Representing names as rst class citizens is handy to allow a user to rename e. g. a NameItem without having to change each Statement using it. A NameItem has three restrictions on its content: First, a NameItem has always exactly one content attached to it. Second, a NameItem may have only simple textual content, i. e. no line breaks and no wiki syntax. The content of a NameItem can easily be entered a human (possibly using an auto-completion mechanism). The MIME-type of the content is always \text/plain". Third, this textual content must be unique within a knowledge model: No two NameItems can have di erent URIs and the same content. Formally, for two NameItems n1 and n2 the following holds: n1:content = n2:content , n1 = n2 (1) All these constraints do not hold for ContentItems: They can be empty or two items can have the same content. There may also be ContentItems having the same content as a NameItem.
Relation A Relation describes the way two items are linked to each other. There are many pre-de ned relations, but one can create new relations as needed. The built-in relation hierarchy is described in the next section. Each relation always has an inverse relation de ned, so one can view each link from both sides. E. g. \Dirk knows Claudia" is the same as \Claudia is known by Dirk", if \knows" has the inverse \is known by".
Under the hood: A Relation is a special kind of NameItem. This implies there can not be two di erent relations having the same name. Each Relation p has a mandatory inverse Relation p. The inverse of the inverse of a Relation p is again p: ( p) = p (2) In CDS each statement of the form (s; p; o) can additionally be rendered as (o; p; s) with p being the inverse of p.
Triple A CDS Triple is like a semantic link in a wiki. It connects any two items and denotes the type of the link by a Relation. Triples appear in the user interface e. g. as the result of queries using inferencing.
Under the hood: Triples are not items. They have no metadata or content attached and a user has rst to promote the triple to a Statement before it can be annotated.
Statement A Statement is both a Triple and an Item. As such, it also has a creation date, an author and may even be annotated or have textual content. Annotating statements is useful to state the source of knowledge e. g. in discussion systems.
There are two ways to create Statements. First, a user can use the name of a NameItem in the text of a ContentItem. Then the system automatically creates a statement, where the originating ContentItem is recorded as the author. This allows the user to back-trace the origin of a statement. Second, the user can directly create a Statement between any kind of item. Under the hood: Statements are represented on RDF via a kind of rei cation. Di erent from RDF, each CDS Statement does entail the ground triple (s; p; o). For every Statement (s; p; o), the inverse Statement (o; p; s) is inferred, where p is the inverse of p. That is: 8s; p; o : (s; p; o) 7! (o; p; s) (3) Note that the URI of the Statement does not in uence the asserted facts. It is possible that di erent statements with the same URI assert the same facts but e. g. having di erent annotations. Statements with the same URI must have the same content, i. e. the same source, relation and target. On top of this conceptual data model, CDS de nes a hierarchy of relations.
The CDS built-in relations have been selected after an analysis of a number of existing information structures in applications used for PKM. The core relation types deal with order, hierarchy, di erent forms of annotation (i. e. free-text annotations, tagging, and formal typing), and generic hyper-links. As the relation hierarchy is represented in the CDS data model, the user can (and should) extend it in CDS-based tools such as HKW.
The relation hierarchy itself is represented by the built-in relation cds:hasSubRelation. Each lower-level Relation implies the higher-level Relations, just like in RDF Schema (RDFS). The complete relation hierarchy is described in [28]. 3
In semantic wikis, users can usually either state the type of link or embed metadata about the current page using special syntax constructs. Some wikis (i. e. SemperWiki) allow embedding arbitrary RDF statements on a page). There is a high variance between the capabilities of semantic wikis to create semantic data. [22] compares some popular semantic wikis with respect to their ability to create annotations. We now analyse HKW with the dimensions given in [22]: Attribution, granularity, representation distinction, terminology reuse, object type, and context.
Attribution Most wikis attribute their annotations to the page where the user is editing the wiki syntax. In HKW (and CDS) links are external to the items. Like in other semantic wikis it is possible to create links between entities via syntax constructs. Internally, such syntax constructs are parsed and result in generated statements. However, only HKW allows creating links which do no originate from a wiki page. This allows e. g. easily importing an existing ontology into the knowledge base without the need to append generated wiki syntax to existing text. Furthermore, each Statement in HKW is an Item itself and each Item in HKW has an author and a creation date. This allows recording the provenance of Statements conveniently. The downside of this extended exibility is versioning. Existing semantic wikis where all semantic statements originate in wiki syntax, the page-based wiki versioning is re-used. In HKW, this is not possible. In fact, HKW has currently no versioning. In the future, we plan to add two kinds of versioning: Item-level versioning for the textual content and model-level versioning for the semantic statements.
Granularity HKW allows creating ContentItems of varying size, ranging from single words to full documents, just like the page content of a wiki page. However, di erent from wiki pages, ContentItems have no name, therefore it is cognitively easier to create a large set of them: Imagine an author of a long document would have to name each paragraph in the document individually! In wikis, every entity that one wants to link to must be written on its own wiki page.
In HKW, the amount, size and relation between NameItems and ContentItems can be chosen by the user. Therefore HKW can be used to mimic a classic wiki (with NameItem-ContentItem pairs), but can also be used in other ways, i. e. linking ContentItems with ContentItems and NameItems with NameItems.
Representation Distinction There have been long debates in mailing lists and workshops over the role of URIs that are used to locate information resources on the web and to denote abstract concepts. For practical everyday personal knowledge management tasks this distinction does not matter much. The individual users create their Items with URIs bound to a personal unique namespace, so there is no danger of accidental overlap. As we separate the NameItems from the ContentItems, they have di erent URIs. NameItems may contain only a short string. Line breaks and formatting are not allowed. This reduces NameItems more or less to labels (but unique ones). So there is the ambiguity whether one talks about the NameItem or the concept denoted by the NameItem. However, the same ambiguity is in our everyday life: Do we talk about the name \Dirk Hageman" or the person \Dirk Hageman" when we say \Dirk Hageman"? For pragmatic reasons HKW does not distinguish these two cases in the data model. Note that the information-resource-like ContentItems are distinguished from the name-like NameItems.
Terminology Reuse In HKW, the user is usually not confronted with URIs, so she cannot directly re-use existing URIs. There are two options around this: One is to create explicitly an Item with a given URI, another one is to import an existing ontology as a set of NameItems. The ontology needs either to have unique labels or labels have to be changed to become unique at import time.
Object Type Most semantic wikis link either to other wiki pages or literal values. In HKW, there is no such distinction. All textual content is addressable by URIs. So the object type is neither page nor literal but Item. In the future, we will integrate the CDS API with the NEPOMUK backbone. This will allow the user to link any semantic desktop item with any other semantic desktop or CDS Item and vice versa.
Context As the annotations in HKW are stored as rst-class citizens, provenance and context can be stored. E. g. for each Item the author and creation date are automatically recorded. In addition to that, each Statement can be annotated further by the user. Note that none of the semantic wikis analysed in [22] had a way to record context.
\O enburg" there are icons allowing the user to navigate to the Statement \Dirk Hageman"{\born in"{\O enburg". In a Statement view (c. f. Fig. 2), the Statement can be changed. E. g. the user can change the Relation or create a new source or target. Auto-linking is supported wherever possible. Most actions in HKW are performed in the Relation Tree Widget (c. f. Fig. 3). Each relation 2 Try online or download from http://wiki.ontoworld.org/wiki/CDS_Editor tree widget represents on of the CDS relations (detail, context, before, after, tag, type, annotation, annotation member, related, source, or target). The widget allows deleting existing statements by pressing the little red 'X'; creating new items, relations and corresponding statements. By pressing the blue plus icon next to an existing relation the widget expands and shows two form elds. One to enter a relation name, pre- lled with the relation where the blue plus was selected from and one form eld to create a new item or select among the existing NameItems. The user is free to enter a di erent relation name into the relation eld, again supported by auto-completion. At any time new relations can be created by simply typing in a new Relation name. The Relation is automatically a sub-relation of the main Relation of a box. I. e. creating a new Relation in the top right box (\has annotation") creates a sub-relation of \has annotation". Inverse Relations are automatically created and named \inverse of ...". The name can easily be change by the user in a single place. This allows creating new semantically interlinked items easily. If the user enters a longer text or uses line breaks, the system assumes the user creates a ContentItem. For short text, the system suggest existing NameItems or creates new ones. As a result, a user can always just start typing in the address bar, no matter whether a concept-like NameItem or a note-like longer ContentItem is going to be created.
The HKW prototype has been realised with the Google Web Toolkit (GWT), an open-source AJAX-enabled web user interface toolkit by Google Inc. Styling is done via Cascading Style Sheets (CSS). Due to CSS issues, the tool works currently only properly in the Firefox browser. This is not a problem as Firefox is available free of charge for all platforms. GWT applications are web-applications, which can run in any servlet container. The typical use case is to run the server locally on the desktop. 5
A uni ed model for web content and semantic statements is presented in [
CDS lets the user express knowledge in the form of text (within an item), structure (structured text in items or structures between items) and formal statements (by using relations with de ned semantics). In HKW, searches and navigation do not bring up long documents, but short fragments of text with its relations to other parts.
In the future, we will extend HKW to allow a user to convert a ContentItem structured with wiki syntax into a set of corresponding smaller ContentItems. This will lower the cost of creating Items even further. The reverse operation should also be possible: Merge a set of Items into a single ContentItem, as wiki syntax. This makes gradual formalisation of knowledge easier: First content is written into ContentItems, then these items are structured using wiki syntax, nally they are converted into many smaller Items that can further be annotated as needed.
Fig. 4. HKW prototype screen shot, focusing on Dirk Hageman
[17] Maurer, H. [1999], The heart of the problem: Knowledge management and
knowledge transfer, in `Proc. ENABLE'99', Espoo-Vantaa Institute of
Technology, pp. 8{17.
[18] Mitchell, A. [2005], `The rise of personal km', Inside Knowledge 9(1).
[19] Nonaka, I. and Konno, N. [1998], `The concept of "ba": Building a foundation
for knowledge creation', California Management Review 40(3), 40{54.
[20] Nonaka, I. and Takeuchi, H. [1995], The Knowledge-Creating Company :
How Japanese Companies Create the Dynamics of Innovation, Oxford
University Press.
[21] Oren, E. [2005], SemperWiki: a semantic personal wiki, in [
URL: http://nepomuk.semanticdesktop.org/xwiki/bin/download/ IST/WebHome/D1.2_v10_CDS-Tools.pdf