d3.1 kiwi architecture final · pdf filethis deliverable describes the architecture, data...

D3.1: KiWi Architecture 1

D3.1 The KiWi Architecture

Project title: Knowledge in a Wiki Project acronym: KIWI Project number: ICT-2007.4.2-211932 Project instrument: EU FP7 Small and Medium-Scale Focused Research Project (STREP) Project thematic priority: Information and Communication Technologies (ICT) Document type: D (deliverable) Nature of document: R (report) Dissemination level: PU (public) Document number: ICT211932/SRFG/D3.1/D/PU/b1 Responsible editors: Sebastian Schaffert, Rolf Sint Contributing authors: Sebastian Schaffert, Rolf Sint, Szaby Grünwald, Stephanie Stroka Reviewers: - Contributing participants: SRFG Contributing workpackages:

WP3

Contractual delivery: 31 October 2008 Actual delivery:

Abstract: This deliverable describes the architecture, data models, and API of the KiWi system, summarises the technologies used in KiWi, and gives instructions on how to set up the KiWi development environment. Its purpose is to provide interested software developers with the necessary information to be able to quickly participate in the further development of the KiWi system. Keyword List: KiWi, Architecture

Project funded by the European Commission within the Seventh Framework Programme © KIWI 2008

2 D3.1: KiWi Architecture

1. Introduction: Building Modern Web Applications .......................................................................... 5 1.1. Basic Design Principles ........................................................................................................... 5 1.2. Best Practice.............................................................................................................................. 5 1.3. Component-Oriented-Web-Frameworks ................................................................................. 5

1.3.1. Java Enterprise Edition 5 ................................................................................................... 6 1.3.2. JBoss Seam ........................................................................................................................ 7

2. KiWi - A JBoss Seam Application .................................................................................................. 8 2.1. General Techniques for Building Seam Applications............................................................... 8

2.1.1. Plain Old Java Objects ....................................................................................................... 8 2.1.2. Database Access................................................................................................................. 8 2.1.3. Java Annotations ................................................................................................................ 8 2.1.4. Dependency Injection and Outjection................................................................................ 9

3. Rationale and Overall Structure..................................................................................................... 10 4. KiWi Architecture.......................................................................................................................... 12

4.1. Layered System Structure ...................................................................................................... 12 4.2. Persistence of Entities ............................................................................................................. 13 4.3. KiWiEntityManager................................................................................................................ 13 4.4. Services ................................................................................................................................... 14 4.5. Controller Layer (Action Beans)............................................................................................. 14 4.6. View and Backing Beans ........................................................................................................ 15

5. Knowledge Representation ............................................................................................................ 15 5.1. Basic Concepts and Technologies........................................................................................... 15

5.1.1. Knowledge representation................................................................................................ 15 5.1.2. Knowledge storage........................................................................................................... 16 5.1.3. Knowledge querying ....................................................................................................... 16 5.1.4. KiWi TripleStore ............................................................................................................. 16 5.1.5. KiWi KnowledgeSpaces .................................................................................................. 16

6. Data Model and Knowledge Model ............................................................................................... 17 6.1. Data Model............................................................................................................................. 17

6.1.1. User .................................................................................................................................. 17 6.1.2. Content Items ................................................................................................................... 18 6.1.3. Tags.................................................................................................................................. 21 6.1.4. Extended Triples ............................................................................................................. 22 6.1.5. Rules ................................................................................................................................ 23 6.1.6. Layout Descriptions and Widgets .................................................................................... 24 6.1.7. Versioning of Content and Meta-Data ............................................................................. 26

6.2. The Kiwi Business Logic........................................................................................................ 27 6.3. View ....................................................................................................................................... 29 6.4. Knowledge Model.................................................................................................................. 30

7. KiWi Architecture by Example...................................................................................................... 33 7.1. Creating a User ...................................................................................................................... 33 7.2. Authenticate a User................................................................................................................. 34 7.3. Creating a new Content Item ................................................................................................ 36 7.4. Tagging a content item............................................................................................................ 37

8. KiWi Development Environment .................................................................................................. 38 8.1. Setup the Environment............................................................................................................ 38 8.2. Database Configurations ......................................................................................................... 38 8.3. Deploy/ JBoss Application Server / Start the application....................................................... 39 8.4. Testing / TestNG..................................................................................................................... 40 8.5. Debug Seam Applications....................................................................................................... 41 8.6. Source Code Structure and Coding conventions..................................................................... 41


8.7. Documentation, Bug Tracking & Issue Tracking ................................................................... 42 8.7.1. JIRA ................................................................................................................................. 42 8.7.2. KiWi Wiki........................................................................................................................ 42 8.7.3. Fisheye, Crucible ............................................................................................................. 42

9. Conclusion ..................................................................................................................................... 42 10. References.................................................................................................................................... 43


Foreword: Purpose of this Report

This report describes the overall architecture of the KiWi system. Its purpose is primarily to help developers to quickly understand and set up the KiWi core system and start building their own customisations and extensions on top of it.

KiWi uses a component-oriented architecture and builds heavily on Java Enterprise Edition (Java EE 5) and JBoss Seam (currently version 2.1), which bridges the gap between the middleware provided by Java EE and the user interface. While this report gives a short introduction into these technologies in Sections 1 and 2, it is recommended that persons intending to develop on top of KiWi get a more in-depth understanding of these technologies. A good starting point to understand how KiWi as a Seam application is working is the book “Seam in Action” by Dan Allen.

Sections 3-7 follow with a more in-depth introduction of the core concepts and the overall architecture of the KiWi system. Specifically, Section 7 shows by example how the KiWi system performs some of the most common tasks, i.e. storing content, loading content, etc.

Section 8 gives an overview over the development environment that is used by the KiWi developers for version management and bug and issue tracking, and gives instructions on how to setup the KiWi source code in order to get the system running quickly.

Since the KiWi system is developed in an agile way, this document is work in progress and will be superseded by the description of the KiWi Knowledge Representation Component (D3.3), which is due at month 15 of the project.


1. Introduction: Building Modern Web Applications

1.1. Basic Design Principles Software has to be adapted and improved regularly during its lifecycle, because of modifications within its development or runtime environment and on changed requirements from various shareholders using the software.

That is the reason why the main objective of building modern software applications is to design the software in a way that it can be modified easily on the various contexts of their usage. (Pree04)

Thus, current research in software engineering focuses on the construction of adaptable, reusable and flexible software and has emerged several design criterions for building this kind of applications in the last years. For example, the process of subdividing software into components that have a high cohesion and a loose coupling between each other is one outcome of current research in software engineering.

1.2. Best Practice Current literature that concentrates on the topic “Software Architecture” focuses on these issues. One of the most famous publications in this research area is the book “Design Patterns” by Erich Gamma et al. describing several generic patterns for the architecture and the interaction of software components. In the last years the development of web-based software has gained importance. One of the key design patterns for web-based applications is the Model View Controller architectural pattern. This pattern describes an architecture, which guarantees a loose coupling between the view, the business logic and the data model.

1.3. Component-Oriented-Web-Frameworks Based on the Model View Controller paradigm, several Web Application Frameworks have been appeared to support the development of dynamic websites in the last few years. Web Application Frameworks provide libraries for database access, templates, session management and patterns for the reuse of code. (WAF). Furthermore these frameworks are designed to build loosely coupled and reusable web applications, and bundle several state of the art technologies. Some application frameworks combine other frameworks in their implementation and offer a common interface on a high level granularity to the application developer. Summarized, the different frameworks may vary according to their complexity and range. Famous contemporary representatives of such web frameworks are Ruby on Rails, Spring and JBoss Seam. Each of these include other frameworks and several technologies for building modern web applications. For instance, they all support the Ajax technology for building interactive web applications.


1.3.1. Java Enterprise Edition 5

(JavaPass)

There exist three different “flavors” of java: Micro Edition, Standard Edition and Enterprise Edition (JEE). Each of it has its own requirements and use cases. (JavaPass). In the KiWi project we decided to use the Java Enterprise Edition as a technology basis for the system, because it supports structured processes within company environments and allows “... to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server” (WIKJavaEE) The Java Platform, Enterprise Edition (JEE) defines a standard for developing enterprise applications. “It simplifies enterprise applications by basing them on standardized, modular components, by providing a complete set of services to those components, and by handling many details of application behavior automatically, without complex programming.” [JEEOv]

Java Enterprise Edition 5 (JEE5) is a standardized specification of software architecture for building applications in enterprise environments in Java. The two frameworks Enterprise Java Beans 3 (EJB3) and Java Server Faces (JSF) build the core of the JEE5 specification.

EJB3 EJB3 is a framework for database persistence and the business logic. (EJB06) (JSF08) For instance, entity beans can be mapped to the table of the database and an entry in a database table can be mapped to the class. Thus, the data model of an JEE application is realized by EJB3.0 classes, which are mapped to tables on the database. This technique is known as Object Relational Mapping.

Furthermore there exist EJB3 session beans which are used to implement the functionality and the business logic of an application. There are two kind of session beans: Stateful and Stateless (EJBTut)

“A stateful session bean is for example a shopping cart class. The state is the cart holding the shopping items and the quantity. The cart class is hold in your application session and disposed at the end when the user checked out.” (EJBTut) “A stateless bean is a short living class. A typical example is a MailSender class sending a message. You call a method and dispose it. With a application server you do not instantiate the class each time you need it. The application server passes an instance from a pool. This is more efficient.“ (EJBTut)


JSF JSF is a lightweight framework for the view, based on the model-view-controller design pattern. It is used to simplify the development of user interfaces for JEE applications. JSF pages manage user data and are responsible for the interaction of the application with the backend. [YUA08]

1.3.2. JBoss Seam JBoss Seam is a modern open source enterprise framework, which is provided by JBoss, a division of RedHat. The official website of JBoss describes Seam as a “lightweight” Framework for building JavaEE 5.0 applications. Seam is located one layer above JEE and provides an easy understandable Framework for all components in enterprise web applications. Furthermore it supports the development of workflows for company environments. [YUA08, p21]. It is based on JEE5 and integrates EJB3 and JSF, too. Dan Allen describes in (SeamAction) Seam as a “ a progressive application framework for the Java Platform, Enterprise Edition (JavaEE) that makes writing web based applications by finally delivering on the promise of a unified component architecture “. One problem of JEE5 is the integration of these two independent frameworks. EJB3 is built with Java annotations, whereas JSF is configured in XML. Hence, both frameworks are built on different design philosophies and have to be applied separately. JBoss Seam enhances the integration and configuration of these two frameworks by using java annotations exclusively. Thus, the Seam Framework simplifies and unifies the development of java enterprise applications. (YUA08, p21).

Seam integrates generic solutions to several problems in enterprise environments, e.g. permission management, pdf and email creation, the implementation of workflows, etc, which reduces effort and a number of lines of code needed for the implementation of these standard features. (MÜL08)

This makes it possible for developers to concentrate on the implementation of the business logic and innovative parts. Another reason why Seam is suited for the development of web based enterprise applications, like semantic Wikis, is its AJAX support, realized by JSF libraries, which allows the development of modern Web2.0 applications.

Figure 1 illustrates the Technologies which build the basis of the Seam framework. As described in the section above, JBoss Seam combines the frameworks JPA/EJB3 and Java Server Faces. Additionally you can see the JSF libraries rich-faces / Facelets which are based on top of JSF, and an application server which deals as the container of the whole JBoss Seam stack. Richfaces is a

Fig 1: A cross section of the technologies incorporated in the Seam Stack (SeamAction)


javascript library, integrated in Seam and used to build AJAX based views.

In Summary JBoss Seam makes the development of enterprise applications easier and extends JEE5 with additional functionality. (YUA08, p28)

2. KiWi - A JBoss Seam Application Based on state of the art concepts and technologies in the field of enterprise software development, the KiWi developers decided to use Seam as the basis for the development of the KiWi system to design the software in an extensible and adaptable way.

The intention of this section is to give an overview of the Seam architecture, integrated technologies and basic design patterns, used for building Seam applications in general, and to describe how they are used in the implementation of KiWi. It is not in the focus of this deliverable to give a detailed technical description about Seam and the JEE5 specification. For this purpose the authors refer to the Seam and JEE5 websites. (JEE5)

2.1. General Techniques for Building Seam Applications

2.1.1. Plain Old Java Objects A core technique of Seam is the usage of Plain Old Java Objects (POJOs) for components. A POJO is a simple java class with some properties and their corresponding getters and setter methods. It is not inherited from any other class and implements no interface. This makes it easy to use and instantiate in any part of your application.

For instance, the data model of KiWi is realized solely with POJOs. Thus, no framework specific interfaces or abstract classes have to be implemented by the KiWi data model classes.

The Seam framework allows java annotations to annotate simple POJOs for adding functionality to them.

2.1.2. Database Access The persistence layer, containing the KiWi data model, keeps the application independent of the underlying database technology. Hence, an arbitrary database, e.g. MySql, Oracle Database, Apache Derby, etc., can be used.

The KiWi data model is realized by entity objects (POJOs), which are mapped automatically by seam onto the corresponding tables of the database. Each entity bean is a simple POJO, designed according to the EJB3 specifications. (YUA08, p29)

Seam uses Hibernate with Java Persistence API (JPA) extension for the mapping of relational database tables and Entity Bean objects. (HIB) (JPA06) In order to allow unified access to the relational database, the triple store, and a fulltext index, KiWi provides an abstraction layer called “KiWiEntityManager”, which can be injected into other components using the @In annotation. Internally, the KiWiEntityManager uses a Hibernate EntityManager instance and uses it to persist and query entity bean objects. (YUA08, p41)

2.1.3. Java Annotations One of the most important improvements of JEE5, compared to earlier specifications (e.g. J2EE), is the configuration of components with Java Annotations instead of XML. Thus, the configuration of


POJOs is very easy for the programmer and often optional. This is because Seam is based on the “Convention over configuration” paradigm. Hence, most of the annotations are not required and can be left to the default configuration provided by Seam (e.g. the annotation of an entity bean may contain the name of the table to which it should be mapped, or not. In the case it is not, the name of the class is used as the name of the corresponding table.).

2.1.4. Dependency Injection and Outjection “Dependency Injection is a key concept in POJO based development and keeps components loosely coupled.” (SEAM, p219)

POJOs are imported / exported to other components by a common design pattern, called Inversion of Control (IOC). Seam uses dependency injection, one use of the IOC pattern for the import and dependency outjection for the export of components.

“ In dependency injection, the container injects dependent objects into the corresponding properties of a target object after instantiating it, establishing references from the objects to its dependencies. … In addition to injecting values, bijection supports outjection of values. Outjecting is the act of promoting the value of a component property to a context variable where it can be picked by another component or referenced in a JSF view … The combination of injection and outjection of values is known as bijection.” (SEAM, p221)

In this way, for instance data inserted by a user in a web form can be injected into the classes, which contain the business logic of the application. This design pattern is consequently used in KiWi and helps to achieve a loose coupling between the components. (YUA08, p20)


3. Rationale and Overall Structure The KiWi system aims to provide a framework that allows the development of many different kinds of systems that integrate semantic meta-data and human readable content. Consequently, the KiWi architecture follows a layered model and the MVC (model view controller) paradigm with loose coupling particularly between models on the one hand and view/controller on the other hand.

The different layers of the architecture are given in the following diagram, together with a reference to the section in this document where they are discussed. The detailed and precise architecture is described in Section 4.

Fig 2: Overall structure


• Data Model and Persistence form the two bottom layers of the architecture. The KiWi data

model consists of two parts, an object oriented model used for representing general data structures, particularly the human readable content, and an RDF/OWL model used for representing machine-readable data. (RDF04) (OWL04)

• The API (Application Programming Interface) is located on top of the data model and provides most parts of the “controller” part of the MVC paradigm. The API consists of enabling technology components (reasoning, information extraction, personalisation), a common API for accessing the data contained in the data model and manipulating it in various ways, and more specific interfaces for Java EE Backing/Action Beans, Web Services, as well as the KiWi Widget and Layout implementations. Data Model and API together form the core part of the KiWi system and framework, and can be reused in different applications.

• Specific applications are built on top of the API. Applications are not discussed in this deliverable; ideas beyond the three applications covered by the project are covered in D8.1 – KiWi Vision.

Since the concept of combining content and meta-data will apply to many or even most of the applications that are emerging on the Semantic Web, we expect that the architecture described in this document will be applicable in many different settings. We expect that even the implementation of the core parts of KiWi can serve as a platform for most of these applications.


4. KiWi Architecture

4.1. Layered System Structure Fig 3. illustrates the basic design of the implementation of the KiWi system and the interaction of the implemented components. The aim is a loose coupling and a high cohesion of all components within the application. From the bottom up the design can be subdivided into five layers: Persistence, Entity homes, Services, Controller Layer and View.

Fig 3: KiWi Architecture


4.2. Persistence of Entities Entities can be persisted in a relational database as well as in a triple store. A triple store is a database for metadata structured in a Subject – Predicate/Property – Object form, where each node is represented as a URI, blank node or Literal, based on the Resource Description Framework (RDF) form. The variable values of an entity object are mapped to triples and stored in the triple store. Storing data in a relational database and in a triple store is a reasonable design for creating an open knowledge model for the outside world through the use of a triple store on the one hand, as well as storing sensitive data in a more reliable, matured and access-restricted database on the other hand. The triple store serves as the knowledge representing system, whose purpose will be explained in section 4. We use Sesame 2 (SES02) as a framework for storing and querying triples. The relational database holds data that should not be accessible by everyone, e.g. a user’s password. For the persistence of data in the relational database the Hibernate EntityManager provided by the Seam framework is used. The data is stored in the pre-configured database.

4.3. KiWiEntityManager

Fig 4:KiwiEntityManager The KiWiEntityManager is a component that gives unified access to entities (POJOs) that are persisted and/or indexed in the relational database, in the triple store, and in a fulltext index. KiWiEntityManager provides similar methods like the ordinary Java EE EntityManager, most importantly:

• createQuery() to create a query to the triple store and relational database

• persist() to store an entity in the underlying repositories

• find() to load an entity from the underlying repositories

• search() to perform a combined fulltext search and relational and RDF query over the entities in the underlying repositories

In most situations, data is stored in the triple store as well as in the object oriented data model. This is implemented in an EntityHome object, which is associated with the EntityManager and the triple store. For instance, information about the user like first name, surname, etc. is stored in the data model and in the RDF triple store.

The main entity managed by the KiWiEntityManager is the ContentItem (see Section 5). For ContentItems, the KiWiEntityManager also provides facading. Facading means that developers can define additional data views (by using ordinary, annotated Java interfaces) in front of ContentItems that provide more convenient access to information stored in the triple store. For example, a developer can devise a PointOfInterestFacade that provides convenience methods for accessing the longitude and latitude of a ContentItem (by mapping to geo:lang and geo:lat) in addition to the ordinary ContentItem methods.

In summary, the KiWiEntityManager is a service endpoint, which provides the persistence of data. This endpoint is called by other, more specific services.


In the KiWi source code, the KiWiEntityManager is a service that is located in the package kiwi.backend.facade. The component is named “kiwiEntityManager” and can be injected into other components like other services.

4.4. Services A service offers functionality that can be used by several other components, e.g. generating a tag cloud or looking up a user. To guarantee a high cohesion of services, each of them has specific functionality. For instance, there exists a user service, which bundles all methods concerning the user management like creating, deleting, modifying and connecting users. Most of these services are implemented as stateless EJB3 session beans, because in most cases they do not have to hold an own state.

In the KiWi source code, services always consist of three interfaces that describe the signature of the service, and the actual implementation that realises it. The interfaces names end with Service, ServiceLocal, and ServiceRemote, and the implementation with ServiceImpl. The component name for a service is always the same as the main interface except that the first letter is written lowercase. For example, the ContentItemService consists of the following source files:

• the interface ContentItemService, in the package kiwi.api, which provides all method names that are externally visible

• the interface ContentItemServiceLocal, in the package kiwi.api, which extends ContentItemService and is annotated with the @Local EJB annotation

• the interface ContentItemServiceRemote, in the package kiwi.api, which extends ContentItemService and is annotated with the @Remote EJB annotation (for distributed installations)

• the class ContentItemServiceImpl, in the package kiwi.backend, which is normally annotated as @Stateless, which has the component name “contentItemService” and which implements the interfaces ContentItemServiceLocal and ContentItemServiceRemote

4.5. Controller Layer (Action Beans) The controller layer, which contains the concrete business logic, calls the services for a specific purpose on an upper level granularity. This layer consists of stateful beans (so-called action beans) that are scoped as needed by the business process (in Seam terminology: session, conversation or event). For instance, the EditAction bean holds its state throughout the duration of the editing process. Usually, an action bean provides the backing functionality for some kind of user interaction, e.g. editing the content of a page, displaying the tag cloud, registering a user, etc.

Action beans often delegate to several services to provide aggregated functionalities. For instance, if a user creates a new content item by clicking on the button “New Wiki Page” within the application, several services have to be called like creating the content item, adding revision information, adding user information, and so on.

In the KiWi source code, action beans are always stateful and always end with the name “Action”. They are located in the package kiwi.action. Like for services, the component name is the same as the class name with the first letter written in lower case. For example, the EditAction is a conversation-scoped bean that provides the functionality necessary for editing a ContentItem and the corresponding user interaction. The EditAction has the component name “editAction”.

4.6. View and Backing Beans The top layer represents the view, which is implemented in JSF. The main concern of the UI


component tree is to act as a server-side representation of the view and listen for events that occur in the UI. In a lot of cases there is a one-to-one mapping between the elements in the component tree and the elements on the page (with the exception of literal HTML). This binding is done using expression language (EL) notation for value- and method-binding expressions, e.g. #{beanName.methodName}.

Backing beans are simple POJOs consisting of properties and their corresponding getter and setter methods. When a user interface component is bound to a backing bean, the beans properties hold the component's local value. Moreover, these values can be prepared before they are forwarded to the Action Bean, e.g. by validation, modification or transformation. Thus, backing beans are used to manage form data from JSP pages.

In the KiWi source code, action beans often take over the role of view backing beans because the overhead is often unnecessary and they are both closely tied to the view. For example, the EditAction serves both, as a view backing bean for the editor content and as a action bean to store the ContentItem when it has been changed.

5. Knowledge Representation This section covers the purpose of knowledge representation and the technologies that are used for building, handling and storing the KiWi knowledge model.

5.1. Basic Concepts and Technologies

5.1.1. Knowledge representation KiWi has two central assumptions about information: the first one is that every piece of information contains both, structured and unstructured content, and the second one is that information should be versatile in the sense that there can be many different perspectives on information, depending on the user’s personal point of view and context. For example, the same information about the Salzburg Cathedral could be displayed in a Wiki and on a Google Map. In the KiWi vision, this has been described as “breaking information boundaries”.

The central element of knowledge representation in KiWi is the ContentItem. It unifies structured and unstructured data in a single entity and gives flexible access to both. Whereas the core properties of a content item (like the textual content, the identifier, etc.) are stored in a relational database, all flexible structures make use of the Resource Description Framework (RDF), which is one of the core technologies in the semantic web that helps to express meaning through semantic triples. These triples consist of three linked nodes that can either be URIs, blank nodes or literals and which form is similar to human language sentences: subject node – predicate/property node – object node. (TSW01)

Using RDF for representing structured information allows ContentItems to stay versatile. For instance, a content item describing a company can be dynamically extended with information about the location of the company, while a content item describing a person can by dynamically extended with information about the person’s birthday.

Artificial Intelligence and Web researchers have co-opted the philosophical term ontology to explain a concept in form of a document or file that formally defines the relations among terms. In KiWi, RDF Schema (RDFS) and Web Ontology Language (OWL), both mark-up languages based on the RDF/XML (RX04) format, are used to represent ontologies. (TSW01)


5.1.2. Knowledge storage In the application we use Sesame 2 as a framework for RDF triple storing and querying and a relational database for storing the unstructured content. As explained above, the KiWiEntityManager provides a convenient abstraction over these repositories. The user and system documentation as well as the JavaDoc for Sesame 2 can be found under http://www.openrdf.org/documentation.jsp.

Sesame 2 is applicable with the following RDF based mark-up languages:

- N3

- NTriples

- RDF/XML

- TriG

- TriX

- Turtle

Additional ontologies, written in one of the above mentioned languages, can be imported in the system at any time. Furthermore, the content of the triple store can be exported into the above mentioned forms.

5.1.3. Knowledge querying Sesame 2 allows querying with two very similar query languages: SerQL (Sesame RDF Query Language) and SPARQL (Simple Protocol and RDF Query Language). (SER03) (SP08) SerQL was originally developed by the openrdf team as an alternative for the query languages RQL (RQ02) and RDQL (RD04). SPARQL, on the other hand, is a W3C recommendation since January, 2008.

An example on how to construct a SELECT Statement in both languages can be found below: PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?x ?y WHERE{ ?x foaf:knows ?y; }

Listing 1: SPARQL SELECT X Y FROM {X} foaf:knows {Y} USING NAMESPACE foaf = <http://xmlns.com/foaf/0.1/>

Listing 2: SerQL

5.1.4. KiWi TripleStore To abstract the handling of semantic data, we introduced the programming interface KiWi TripleStore. The direct coupling of Java objects and the triple store Sesame 2 was split by reason of enabling a more easy way of acquaintance with storing and querying semantic triples. With the KiWi TripleStore it is possible to persist java entities, list all triples, create new resources, import and export rdf based documents and even more.

5.1.5. KiWi KnowledgeSpaces The concept of a knowledge space and its reasons are explained in this section since the term will appear several times in the following chapter. A knowledge space is similar to a namespace in RDF, but more accurate. It constitutes a mechanism for modularisation where groups of ontologies with a certain context are collected. In future it will be possible to switch between knowledge spaces in the application. This will provide a way to look at knowledge information from another perspective.


6. Data Model and Knowledge Model

6.1. Data Model

6.1.1. User

Fig.5: Data model: User A User object on the KiWi platform represents a human being in terms of the name, the login information, the email, the friends and the address. Every user may be an author of a content item or a tag and participate in a group, which may reflect his/her interest. A User is a subclass of PermissionOwner. Permission management is necessary for the dedication in corporate environments. Additionally every user may have one or more perspectives, which means that the layout of KiWi web pages can be personalized.

Perspective. It may be easier to understand what a perspective is if it is explained in an example:

Peter likes to take photos. His motivation to register at a social network platform may be, to look at


photos taken by other users and to upload own photos. He is very interested in the Exif1 data of the photos.

Anna, on the other hand, is a passionate traveller. She loves to look at photos, too, but her motivation is to see a description about the place where the photo has been taken.

Thus, Peter may have the perspective of a photographer. He will probably have a widget that shows all the information about the camera that took the photo and less the regional background.

Anna may have the perspective of a traveller with a detailed description on where the photo has been taken and a list of other sightseeing’s in that region.

Both may also have more then one perspectives.

6.1.2. Content Items

Fig.6: Data model: ContentItem The content item is the primary “unit of information” in the KiWi Data Model. A Content Item corresponds directly to a resource (identified by a URI or an RDF blank node) and contains textual, media or external content. Resources are connected with meta-data in the RDF store using “extended triples” (see below). The relationship is illustrated in figure. 7:

1 Exchangeable image file format is a specification for the image file format


Fig.7: Content item, content and extended triples • Content Items are all different kinds of content and data items that are stored in the KiWi

system, i.e. (wiki) pages, multimedia, users, roles, rule definitions, layout definitions, widgets, and possibly more. The KiWi system is not restricted a priori to specific content formats.

• URIs or Blank Nodes serve as machine-readable symbolic representations of resources, to be used in extended triples in the RDF-based metadata store. The URI is used to embed a resource in its context and provide machine-readable meaning, e.g. by annotation with formal annotations, reasoning, etc.

• The Textual / Media Content related to a resource is meant for human consumption. The content resembles a wiki page, is easy to edit, supports linking, and is versioned. In the current design each wiki article in a specific language is represented as an own content item describing a single concept. The assumption for this design is that the content about a topic and its authors may differ from language to language. The definition of connections between content items with equivalent content but different languages can be accomplished with metadata relations.

• External Content is the third content option. It is planned to have the possibility to embed external content from other web sites into a content item.

These assumptions make the KiWi data model very different from other wikis or even currently available content management systems. Most important, it treats all kinds of resources equally, leading to a very clean and simple model where every resource has both, a machine-readable and a human-readable description.

A consequence of the direct relationship between content items and RDF resources is that every RDF resource, even those representing widgets, layouts, users, or even rules, can also be described in human readable form, e.g. in terms of a textual description or multimedia

Textual Content. Textual descriptions (“pages”) are represented internally as (structured) XML documents that can be queried and transformed to other representations like HTML or XSL-FO2 (for PDF and other print formats) using standard XML query languages (XQuery, XSLT3) or using the rule-based reasoning language developed in KiWi. (XSL06) (XQ07) (XS99) The XML format used for page representations resembles a subset of HTML, taking into account only core structuring elements. More complex parts of HTML, e.g. forms or JavaScript, are not considered. For example, a (simplified) internal page representation might look as follows:

<div xmlns:kiwi="http://www.kiwi-project.eu/kiwi/html/" kiwi:type="page"> <p>

2 XSL Formatting Objects, defined by the XSL Recommendation at http://www.w3.org/TR/xsl/ 3 XSLT is commonly seen as a transformation language, but the border between querying and transformation is not sharp at all. In fact, XQuery and XSLT compete for the same “market”


... content ... </p> <p> ... content ... </p> </div>

Listing 3: XML format of page Using XML for storing textual descriptions provides significant benefits over, e.g., structured wiki markup, since XML is a standardised markup language, easy to work with, and many tools are available. It is also a key technology for making information exchange between different systems possible.

Fig.8: Data model: TextContent and TextFragment Text Fragments. It is often desirable to annotate not only a content item as a whole but also parts of the content, e.g. a certain section, paragraph or sentence, or names and other entities occurring in the text. So as to allow annotation of text fragments inside the RDF store, each text fragments is identified by a unique, but randomly generated URI.

Since text fragments do not necessarily coincide with the hierarchical XML structure of pages, KiWi introduces the concept of “bookmarks”, as it is also found in e.g. the Open Document Format (ODF) employed by OpenOffice. A bookmark is characterised by two XML empty elements, one indicating the start of a bookmark with a certain ID, and one indicating the end of the bookmark with this ID. In XML, a page containing bookmarks might look as follows:

Fehler! Verweisquelle konnte nicht gefunden werden.While in principle, annotation of multimedia fragments would also be desirable, KiWi is currently restricted to textual fragments

only, as annotating multimedia content has a complexity that is to high to be covered in the project.

Media Content. Other kinds of content are represented internally as “black boxes”, i.e. the system


has only limited means to look inside. Such content is usually stored using some sort of binary representation format and otherwise treated like text pages. Multimedia resources can otherwise be annotated like textual resources, albeit possibly not at the same level of granularity.

6.1.3. Tags

Fig.9: Tag A tag is an entity that connects two content items: One that is tagged and one that explains the domain of the tag and, thus, gives the tag a meaning. This approach is important to distinguish between tags with homonymic labels, e.g. Jaguar. The tagging principle is explained in detail under Knowledge Model in section 6.4.

<div xmlns:kiwi="http://www.kiwi-project.eu/kiwi/html/" kiwi:type="page"> <p> ... content ... <bookmarkStart id=”AF23D567”/> ... more content ... </p> <p> ... content ... <bookmarkEnd idref=”AF23D567”/> ... more content ... </p> </div>


6.1.4. Extended Triples

Fig.10: Data model: Extended triples Machine-readable meta-data is represented using what we call extended triples. At the moment an extended triple conceptually stores a triple like in RDF and a triple id, which is used to reflect the context or, as we call it, the knowledge space in which the triple exists (see section 5.1.5). In a later stage of the project, extended triples will contain additional maintenance information that can be used internally by the KiWi system for various tasks like versioning, transactions, associating a triple with a certain workspace, user, or group, or for reason maintenance (i.e. storing why a certain triple has been asserted). In principle, an extended triple can thus be seen as a “triple with attributes”.


Fig.11: Triple with attributes Note that these attributes could also be represented using RDF triples and reification. However, such a representation has several disadvantages compared to the extended triples proposed for KiWi:

• it requires reification, meaning that the original triple, which assumingly provides the most interesting information, is broken up into parts that have to be reassembled, and

• it mixes up several levels of abstraction, which is not only inconvenient for machines and reasoning, but also for the user, as it clutters the knowledge space,

• it makes it difficult to filter out the information that is used for internal purposes and this not supposed to be exchanged with external systems

The implementation of extended triples is straightforward and fits easily with already existing tools and standards without disguising the original meaning. Triple attributes containing maintenance information are only represented programmatically inside the system, avoiding problematic situations. To the outside world, extended triples look like ordinary triples and can be exported into the usual Semantic Web formats like RDF.

6.1.5. Rules Rules are a natural and intuitive way of expressing consequences, processes, and also functional behaviour. In the KiWi system, rules are considered to be first class objects. The derivations that are drawn based on rules have consequences for many aspects of the system, including “virtual” triples, automatic layout customisation, and enriching content with meta-data to specifically support the user.

In the KiWi system, a rule is a special kind of resource identified by a URI. As such, rules are part of knowledgespaces and have a content item representation like any other resource. This makes it easy to allow users to view and edit rules as part of their interaction with the KiWi system. In its final stage, KiWi will provide specialised, intuitive editors for adding or modifying rules inside the browser.

Rules are associated with similar kinds of maintenance information as extended triples. For example, it might be necessary to disable a certain rule for a certain user because it leads to a layout decision that the user doesn’t like, but leave the rule “enabled” for other users.

The current representation of rules in the data model is a stub; the concrete rule model will be worked out as part of the work on enabling technologies (D2.1/D2.2) and system integration (D4.1/D4.2).


6.1.6. Layout Descriptions and Widgets

Fig.12: Data model: Widgets and LayoutClasses The KiWi user interface will be composed of flexible and configurable “widgets” that can be tailored and composed according to the specific needs of the application context (use case) and even of the individual users, e.g. by graphically rearranging the layout as in iGoogle4 or by customising the layout based on the user preferences and user model. For example, a page showing biology content could automatically insert a taxonomy box widget in the top right corner of the text. render the page in larger font because the user has “bad vision”, or provide an interactive widget for tagging biology resources.

4 http://www.google.com/ig


Fig.13: Taxonomy Widget showing additional information to biology content KiWi widgets are supposed to not only support presentation of content but also interaction with the system. An “editor widget” could thus provide the wiki-style editing capability, a “tagging widget” the possibility to annotate content with free-text tags, and a “socialise widget” could integrate the KiWi system with other Social Software systems like Digg or Magnolia.

For this purpose, KiWi will provide

• a layouting language (similar, but well beyond CSS or similar languages; probably XML-based) that allows to define how widgets are arranged on a page;

• a widget description language that allows to describe visual and interactive properties of components; the language will either use or build on the W3C working draft “Widgets 1.0”5

Like rules, layout descriptions and widget descriptions are a special kind of resource identified by a URI, which are represented by a content item in the KiWi system. As for rules, the KiWi system will provide specialised editors that allow users to view and edit layout and widget descriptions. For example, a graphical, browser-based layouting tool could let users rearrange the layout of components using drag and drop or similar techniques (as e.g. in iGoogle). Widget implementations will be possible in several ways, ranging from simple-to-use templates for non-programmers, over rule-based specifications, up to expressive programming languages like Groovy or page specification languages like JSF.

Details of the layout and widget description languages and the associated data model are developed as part of deliverable D3.3 at a later stage of the project.

5 http://www.w3.org/TR/2008/WD-widgets-20080414/


6.1.7. Versioning of Content and Meta-Data

Fig.14: Versioning, Revision and Updates The KiWi data model includes an elaborate versioning concept that includes versioning of both, content modifications and metadata updates. At the moment, versioning affects the application as a whole and not only single resources or content items. Key concepts of versioning are revisions and updates.

Updates. Updates are atomic, reversible operations on the content and the meta-data. The KiWi data model currently foresees the following kinds of updates:

• text and media content updates: these updates are changes to the textual or media content related to a content item, e.g. addition or removal of text or uploading of a new version of an image.

• renaming and deletion: these updates concern the renaming of a content item; such changes are frequent in emerging systems like wikis and often affect also other pages (e.g. updating of links).

• metadata updates: these updates consist of additions and deletions of extended triples from a knowledge space; in most situations, changes to the knowledge space will consist of more than one metadata update.

• rule updates: these updates comprise changes to the rules that are part of the knowledge space.


Revisions. Revisions bundle several updates together into one “transaction”. Unlike normal wikis, a revision concerns not only a single content item but the complete application: in most situations, a revision will comprise both, content and metadata updates, and it is meaningless to attach the revision to a single content item.

Revisions can be considered atomic, as they represent a single change of the knowledgespace and capture the intention of the user (who defined the update by clicking on “commit”). Undoing a revision always means reversing all updates that are part of the revision.

This requirement is reasonable: consider for instance a revision in which a content item is renamed and all links referring to the page from other content items are updated accordingly (perhaps even automatically). Undoing only parts of this revision will inevitably yield inconsistencies that are probably not intended by the user.

Research into the development of a superior revision and transaction management for KiWi is a core concept and has not yet completed. This topic will, therefore, be discussed in more detail in a later paper.

6.2. The Kiwi Business Logic The controller is build with EJB3 session beans. It is responsible for updating the data model content according to the values entered by the user. (YUA08, p29)

In the following, a short description about KiWis functionality is given. This description contains the current functionality and may evolve or be change in future versions of the software.

User and Content. The user and content specific packages provide functionality to create and edit user and content objects and keep the current user and content object in store.

KiWiEntityManager. The KiWiEntityManager in the package kiwi.backend.facade provides functionality for structured querying as well as fulltext search for ContentItems and Users.

Setup. Setup packages treat the configuration previous to the programs’ initial start-up.

ImportExport. The importing of additional ontologies, as well as the exporting of the existing knowledge model is an important backend feature of KiWi. The importing and exporting process is provided by Sesame 2. The service that accesses the triple store can be found in the import-export packages.

TripleStore. The service interface for accessing the triple store is implemented in TripleStoreImpl.java. It is responsible for inserting, querying and listing RDF triples. Entities that should be stored as triple nodes have to be inherited from KiWiEntity.java, which simply presumes that the implementing classes have a resource (see fig. 15). Since not all entity-attributes should be accessible without permission restriction, just the non-critical properties are stored in the open triple store. An example for sensitive data would be a users’ password. This attribute is exclusively stored in a secure database.


Fig. 15: KiWi entity Therefore, the developer team of Kiwi decided that all properties, which should be stored in the triple store, have to be explicitly annotated with @RDF within the entity class. @RDF(Constants.NS_FOAF + "firstName") private String firstName;

Properties not annotated with @RDF, are not stored in the triple store.

The advantage of this architecture is that the application programmer, who develops a service with the required functionality, does not have to care about how data is persisted and accessed.

Layout. The layout definition action and the layout rule engine are backend services that define how the layout is presented for each user, based on the rules and perspectives that are defined for him/her.

Render. Render services, or render pipelines, treat the process of transforming simple html to cleaned and well-formed xml.

Tagging. Actions associated with listing tags and constructing tag clouds are defined in the backend classes.

Admin. These classes are responsible for the administration functionality of the KiWi application. This means, for instance, that users can be added to or removed from a group. Thus, a group encapsulated one or more users. Furthermore this package offers the functionality to apply access rights to single users or groups of users.


6.3. View JSF EL. The view pages of KiWi are implemented using Facelets. Facelets allow the development of JSF Websites using XHTML code. The connection to the backend is established with embedded JSF-Expression Language (EL). The view is realized by JSF technology, using an AJAX based JavaScript library called RichFaces.

Navigation. One important aspect of Java Server Faces is the separation of JSF pages and navigation. Action beans and their return values manage the navigation, which uses defined navigation rules. These rules are located in pages.xml. Listing 5 illustrates such a navigation rule. If an action bean method returns the String “home”, JSF navigates to the page “home.xhtml”.

(YUA08, p29)

<navigation> <rule if-outcome="home"> <redirect view-id="/home.xhtml"/> </rule> </navigation>

Listing 4: Navigation rules


6.4. Knowledge Model The KiWi Ontology reflects the internal structure of the KiWi entities, namely the User, the ContentItems and the Tags. The model imports and uses the following existing ontologies:

- http://www.holygoat.co.uk/owl/redwood/0.1/tags/

- http://rdfs.org/sioc/ns#

- http://xmlns.com/foaf/0.1/

- http://www.w3.org/2000/10/swap/pim/contact#

- http://www.w3.org/2003/01/geo/wgs84_pos#

- http://purl.org/dc/elements/1.1/

Furthermore we are planning to use UMBEL (http://www.umbel.org/) [6] as a basic vocabulary ontology. The following drawing helps to understand the ontological model of KiWi.

Fig.16: KiWi core ontology


Fig. 16 is a cut-out with the most important entities and entity-attributes as a whole. In the following one will get familiar with each entity.

Fig.17: Ontology: KiwiUser The KiWiUser is an entity that represents a human being that is registered at the KiWi System. The KiWiUser is a merging of &sioc;User, &foaf;Person and &cont&Person, which means that he/she adopts all properties and relations of those entities. Some of the properties are nick name, first name and surname, phone number and email address. Additionally a User can be located at an address, is an author of several or no contents, has other KiWiUsers as known contacts and created several or no tags.

Fig.18: Ontology: address The address is inferred from &geo;Point and &cont;Address to cover the post address as well as the


geological address.

Fig.19: Ontology content item The content of the KiWi pages is stored in content items, which have a KiWiUser as an author, content in textual, medial or external form and properties like title, language, creation date, rating and tags.

Fig.20: Ontology: Tag A tag in the KiWiSystem is an entity which points at the content item that has been tagged and a resource that explains what the tag means. This meaning is often reflected in another content item. With this method we have the ability to give two or more tags the same label, e.g. “Jaguar”, and add different meanings, e.g. http://www.kiwi.eu/cars/jaguar and http://www.kiwi.eu/animals/jaguar. This helps to distinguish between homonyms without defining exotic tag labels like jaguar_car or jaguar_animal. The model expands the holygoat ontology, which already defines relations between a resource that tags (KiWiUser), a resource that has been tagged (content item), the tagging date, as well as related and equivalent tags.


7. KiWi Architecture by Example This chapter describes some typical use cases in the KiWi application in detail. The section is particularly important for developers, who need to get evidence in source code component interaction.

7.1. Creating a User

<div class="dialog"> <s:validateAll> <h:panelGrid columns="2" rowClasses="prop" columnClasses="name,value"> <h:outputLabel for="login">Login: <h:inputText id="login" value="#{kiwi.user.edit.login}required="true"> </h:inputText> <h:outputLabel for="fn">First Name:</h:outputLabel> <h:inputText id="fn" value="#{kiwi.user.edit.firstName}"/> <h:outputLabel for="ln">Last Name:</h:outputLabel> <h:inputText id="ln" value="#{kiwi.user.edit.lastName}"/> <h:outputLabel for="password">Password:</h:outputLabel> <h:inputSecret id="password" value="#{kiwi.user.edit.password}" required="true"/> <h:outputLabel for="email">E-Mail:</h:outputLabel> <h:inputText id="email" value="#{kiwi.user.edit.email}"/> </h:panelGrid> </s:validateAll> <h:commandButton value="Store" action="#{kiwi.action.createUser.createUser}"/> </div>

Fig.21: Form: Creating a user Fig. 21 illustrates a screenshot of the registration form and its corresponding xhtml/jsf code. This form stores login, password, first name, last name and email of a new user in the database.

This example intends to illustrate the activity within the application when a user enters his login information and clicks the store button. <h:commandButton value="Store" action="#{kiwi.action.createUser.createUser}"/>

Subsequently, the createUser() method in CreateUserAction.java is triggered. The interconnection is established by annotating the CreateUserAction Bean with @Name("kiwi.action.createUser")

Values that were inserted into the registration form are directly stored in a user object. This object is generated with EditUserHome. The following code example shows how the variables are stored in the edit user entity via Expression Language Notation: <h:inputText id="fn" value="#{editUser.firstName}" required="true"/>

EditUserHome holds a method that returns a user object. @Factory(value="editUser") public User initUser() { return getInstance(); }

editUser is the context variable that is used to inject the new user into the CreateUserAction @In(value="editUser") User user;

As said before, the createUser() method is triggered. Its function is to call the persist() method in


EditUserHome, which will than lead to the storage in the database and triple store.

Figure 22 illustrates the state of the database and the triplestore after creating a new user:

<rdf:Description rdf:about="http://localhost:8080/KiWi/user/rodolfo">

<foaf:mbox>[email protected]</foaf:mbox>

<rdf:type rdf:resource="http://www.kiwi-project.eu/kiwi/special/KiWiUser"/>

<foaf:nick>rodolfo</foaf:nick>

foaf:surname>Sint</foaf:surname>

<foaf:firstName>Rolf</foaf:firstName>

</rdf:Description>

Fig 22: data persistence

7.2. Authenticate a User A mentioned in //reference: http://docs.jboss.org/seam//, the authentication features provided by Seam Security are built upon JAAS (Java Authentication and Authorization Service), and as such provide a robust and highly configurable API for handling user authentication.

This example illustrates the process of user authentication:

<div class="dialog"> <h:panelGrid columns="2" rowClasses="prop"> <h:outputLabel for="username">Username</h:outputLabel> <h:inputText id="username" value="#{credentials.username}"/> <h:outputLabel for="password">Password</h:outputLabel> <h:inputSecret id="password" value="#{credentials.password}"/> <h:outputLabel for="rememberMe">Remember me </h:outputLabel> <h:selectBooleanCheckbox id="rememberMe" value="#{rememberMe.enabled}"/> </h:panelGrid> </div> <div class="actionButtons"> <h:commandButton value="Login" action="#{identity.login}"/> </div>

Fig.23: Form: login A JBoss Seam Tutorial section describes that the credentials component provides both username and password properties, catering for the most common authentication scenario. These properties can be bound directly to the username and password fields on a login form. Once these properties are set, calling identity.login() will authenticate the user using the provided credentials. […] Similarly, logging out the user is done by calling #{identity.logout}. Calling this action will clear


the security state of the currently authenticated user, and invalidate the user's session.

When the form is filled out and the login button is pressed, the values of username and password are stored in a credential object. Similar to the example above, the action is delegated to the Authenticator.java class, which in-/outjects the following variables: @In UserService userService; @In Identity identity; @In Credentials credentials; @Out(value = "currentUserId", scope = ScopeType.SESSION) Long currentUserId; The authenticate method queries the user by login and saves the current user id. User user = userService.getUserByLogin(credentials.getUsername()); if (user != null) { currentUserId = user.getId(); for (Group mr : user.getGroup()) identity.addRole(mr.getName()); } else { return false; }

The authenticator method is responsible to check if the user exists in the database and if the corresponding password is correct. In the case that the given values match the values in the database, the boolean value true is returned.


7.3. Creating a new Content Item On the front-end side, the form edit.xhtml is responsible for creating a new ContentItem. Fig. 24 shows the user interface that is used for editing a ContentItem using a WYSIWYG editor. This editor is the platform independent editor TinyMCE, an Open Source editor under Lesser Gnu Public License (LGPL) by Moxiecode Systems AB. (http://tinymce.moxiecode.com/)

Fig.24: form: Wiki editor When creating a new Wiki page, the user enters the title of the page, the text of the wiki article and optional an additional attachment. This data is stored in specific fields in the EditorAction, which thus serves as a backing bean for the editing of ContentItems.

private String title; private String content; By clicking on the “Save” button, the content is saved and the storeContentItem() method within the EditorAction bean is executed. This method takes the data from the title and content fields (ContentItemBean.java), transforms the HTML code created by the TinyMCE editor to cleaned and well-formed xml (by calling the service “StoringService”) and delegates the persistence of data to the KiWiEntityManager. The KiWiEntityManager stores the content item in the triple store (fields annotated with @RDF) as well as in the database (primarily HTML content and title, as well as tags for efficient access).


Fig. 25 illustrates how Text Content is persisted in the database.

<rdf:Description rdf:about="http://localhost:8080/KiWi/content/FrontPage">

<modifiedOnxmlns="http://www.kiwi-project.eu/kiwi/core/">29.10.08 16:38</modifiedOn>

<hasTextContent> Textcontent<hasTextContent>

<createdOn xmlns="http://www.kiwi-project.eu/kiwi/core/">29.10.08 16:37</createdOn>

<title xmlns="http://www.kiwi-project.eu/kiwi/core/">WikiPage</title>

</rdf:Description>

Fig 25: Persistence of Text Content (Database and Triple Store)

7.4. Tagging a content item A “tagging field” within the application allows a user to enter free associated tags for the annotation of a content item. Each tag in the KiWi system connects two content items, the tagged and the explaining one. Thus, each tag serves as a link between two contents.

KiWi offers the functionality to handle common problems with homonyms and synonyms in natural language. For instance, the term jaguar is used for the description of two different concepts: For the description of an animal and also for the description of a car. In traditional tagging based content retrieval mechanism a query for one will retrieve both.

In KiWi different meanings are realized as two independent content items, each with an own URI. For instance, the URIs http://www.kiwi.eu/cars/jaguar and http://www.kiwi.eu/animals/jaguar could describe the two different concepts. If a user enters an ambiguous word, like jaguar, the system makes a lookup to identify all existing wiki articles entitled by this tag. In the case that the lookup returns more than one article, the term is ambiguous. As a consequence the application could suggest all existing URIs to the user, and ask him/her to select the right one which describes the concept. If a user has a different meaning than suggested, he/she is able to add another URI.

The jsf code references to the corresponding backing beans to hold the values entered by the user. The backing bean calls the getContentItemByUri() method to return the corresponding content item. If no content item exists a new one will be created. Such operations are implemented in the business logic part of the application. (TaggingActionBean)

<rdf:Description rdf:about="http://localhost:8080/KiWi/tags/cool/11d494b5aae">

<hgtags:taggedResource rdf:resource="http://localhost:8080/KiWi/content/FrontPage"/>

</rdf:Description>


<rdf:Description rdf:about="http://localhost:8080/KiWi/tags/cool/11d494b5aae">

<hgtags:taggedBy>

<rdf:Description rdf:about="http://localhost:8080/KiWi/user/rodolfo">

<foaf:mbox>[email protected]</foaf:mbox>

<rdf:typerdf:resource="http://www.kiwi- project.eu/kiwi/special/KiWiUser"/>

<foaf:nick>rodolfo</foaf:nick>

<foaf:surname>Sint</foaf:surname>

<foaf:firstName>Rolf</foaf:firstName>

</rdf:Description>

</hgtags:taggedBy>

</rdf:Description>

Fig 26: Persistence of a Tag (database and Triple Store)

8. KiWi Development Environment

8.1. Setup the Environment The KiWi application is based on java and JDK5.0+ is required to be installed on your system. For the version control of the KiWi source code a SVN repository is used. For accessing the repository you have to apply for an account at the KiWi coordinator Sebastian Schaffert. ([email protected])

You can use an IDE of your choice, e.g. Eclipse6 or Sun Netbeans7. If the standard installation of your IDE does not support subversion, you have to download and install an appropriate plugin for your IDE. For instance the Subclipse8 plug-in provides support for subversion within the Eclipse IDE. Afterwards you have to enter the address of the KiWi Subversion repository in your Subversion system. This is currently: https://svn.salzburgresearch.at/svn/kiwi/KiWi/trunk

After you entered your svn username and password you can checkout the source code into your local IDE.

8.2. Database Configurations As described in chapter 3, KiWi can be used with any arbitrary database.

After you have downloaded the actual source code you have to remove the. tmpl extension in the filename of some configuration files and adopt them to your own purposes. The following files contain the database configuration information and have to be adopted according to the concrete underlying database.

6 http://www.eclipse.org 7 http://www.netbeans.org 8 http://subclipse.tigris.org/


- ressources/META-INF/persistence-dev.xml - ressources/META-INF/persistence-prod.xml - ressources/META-INF/persistence-test.xml

This example shows the persistence-dev.xml configured for a MySQL database: <persistence-unit name="KiWi"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <jta-data-source>java:/KiWiDatasource</jta-data-source> <properties> <property name="hibernate.dialect" value=" org.hibernate.dialect.MySQLDialect"/> <property name="hibernate.hbm2ddl.auto" value="create-drop"/> <property name="hibernate.show_sql" value="true"/> <property name="hibernate.format_sql" value="true"/> <property name="hibernate.jdbc.batch_size" value="0"/> <property name="jboss.entity.manager.factory.jndi.name" value="java:/KiWiEntityManagerFactory"/> </properties> </persistence-unit>

Listing 5: Persistence configuration In the <properties> tag, some preferences on how to connect to the database can be defined. Some of these configurations are

- the database dialect, which should be compatible to the actual used database,

- the table handling, which can be set to create, create-drop and update,

- additional debug information, and

- a reference to the entity manager or entity manager factory as a global JNDI

The <jta-data-soure> tag refers to the datasource configured in KiWi-dev-ds.xml, which should be modified according to the concrete location, driver and login information of your database.

This datasource is mapped to the JNDI name KiWiDatasource. <local-tx-datasource> <jndi-name>KiWiDatasource</jndi-name> <connection-url>jdbc:mysql://localhost:3306/test</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>user</user-name> <password>newpwd1</password> </local-tx-datasource>

Listing 6: Datasource

8.3. Deploy/ JBoss Application Server / Start the application The KiWi Team decided to use the JBoss Application Server9 as the preferred Application Server for the KiWi project. To deploy the application you have to define the path of your application server in the build.properties file and then run the ant build file in the source folder of the KiWi project. This will create an Enterprise Application Archive (ear) file and copy it into the deploy directory of your Application Server. The build result will be stored additionally in the exploded-archives in your IDE. After the deployment you can start the JBossAS and navigate your web browser to http://localhost:8080/KiWi to start the application.

9 http://www.jboss.org


8.4. Testing / TestNG KiWi uses TestNG10 as a testing framework for different kinds of tests, like unit, functional, end-to-end, integration, etc ...

Notice: The applications database settings and the database settings used by the TestNG tests, have to be configured separately. For running TestNG tests the following steps have to be done:

- Rename the folder bootstrap.tmpl as bootstrap

- Adapt the database connection setting configured in resources/META-INF/persistence-test.xml and resources/KiWi-test-ds.xml.

- Run the buildtest ant-target in build.xml. This ant-task will automatically compile the test classes, copy them to the test-build directory and add the database connection settings to bootstrap/deploy/kiwi-ds.xml and test-build/META-INF/persistence.xml.

- All tests are located in the src/test folder of the project. There are 2 ways to get TestNG tests running:

- Eclipse IDE with TestNG plugin: After configuring your Eclipse IDE according to http://testng.org/doc/eclipse.html, right-click on a test class and select Run As/TestNG Test.

- Eclipse IDE without TestNG plugin or NetBeans IDE: Add the testNG-x.jar to your build path, create testng XML files (instructions can be found here: http://testng.org/doc/documentation-main.html#testng-xml), store them in the same directory as the tests and run the test ant-task.

10 http://testng.org/doc/


8.5. Debug Seam Applications It is possible to debug Seam applications by starting the Server in the debug mode on port 8787. On Mac or Linux machines the following line has to be added to the run.conf/run.sh: JAVA_OPTS="-Xdebug -Xrunjdwp:Server=y,transport=dt_socket,address=8787 %JAVA_OPTS"

On windows machines the comments (rem) on the beginning of the following line in run.bat has to be removed or commented out. Set JAVA_OPTS=-Xdebug –xrunjdwp:transport=dt_socket, address=8787, Server=y, suspend=y %JAVA_OPTS%

(YUA08)

8.6. Source Code Structure and Coding conventions Listing 8 illustrates an overview of the KiWi package structure:

All model related packages are in the package folder src.model, which contains the object-oriented data model of the application. The package src.action includes the KiWi business logic and contains the java action beans. In src.action.bean one can find the Backing Beans. The view folder includes the xhtml files that build the Graphical User Interface (GUI) of the application. All test classes are located in the projects src.test directory. All required jar files can be located in the lib directory. The deployment descriptors, database connection files and data import scripts can be found in the resources directory. All interfaces for services are located in the kiwi.api package. The corresponding implementations can be found in kiwi.backend. The project-wide naming convention regulates that all entity homes end with “Home” (e.g. UserHome.java), all action beans end with “Action” (e.g. CreateUserAction.java), all services end with “Service” (e.g. UserService.java) and all backing beans end with “Bean” (e.g. ContentItemBean.java).

|+ src |+ model |+ action |+ test |+ view |+ web pages (.xhtml, css, images) |+ resources |+ WEB-INF |+ META-INF |+ lib |+ jar libaries |+ build.xml


8.7. Documentation, Bug Tracking & Issue Tracking

8.7.1. JIRA JIRA, developed by Atlassian Software, is an issue tracking and project management system. We use JIRA as the tool where we can collect and track "ideas" and basic requirements concerning the development of the KiWi system (and also the use cases). It supports us to collect all kinds of ideas, tasks, bugs and issues in a structured manner. How JIRA can be installed is documented under: (JIRA). JIRA also allows users to subscribe to an RSS feed that lists the most recent issues.

The KiWi Jira system is available at http://wiki.kiwi-project.eu/atlassian-jira/

8.7.2. KiWi Wiki Additionally, we use a wiki for discussions of several themes according to the KiWi project. Most importantly, the documentation concerning the KiWi software is available at http://wiki.kiwi-project.eu/?title=kiwi:Software .

The wiki is located at: http://wiki.kiwi-project.eu/

8.7.3. Fisheye, Crucible We are using Fisheye and Crucible, which give us a more convenient Web access to the Subversion code repository. You can use them to browse through the repository and see what has changed. You could even comment on changes, but we are currently not using this feature. Again, a nice feature of Fisheye is also that it allows to configure "watches" that sent you an email when something on the code has changed. Currently it is configured in a way that a summary of the day's changes is sent to the kiwi-devel mailing list each night. You can, of course, also use the RSS feed to stay up-to-date.

9. Conclusion As described in the KiWi vision the KiWi software will be a generic platform, which can be applied for different purposes. Within the project, the software will be customized according to three different use cases. Two of them will adapt KiWi to a tool for knowledge management in company environments and one public showcase will customize KiWi to an open Web2.0 community platform.

These different extensions and customizations of the KiWi core system require a well-designed architecture that explicitly foresees a later adaptation.

Therefore the developer team of KiWi decided to use a component based application Framework, which is designed to build modern and modular enterprise web applications.

We decided to use a framework based on the JEE5 specification, because JEE5 is a widely used platform for server programming in the Java programming language.

Furthermore, the KiWi developer team has been focusing on the development of a high cohesion and a loose coupling between the components. However, the present document aims to define the rough architecture of the KiWi software. Some parts of this architecture may change or be improved in a later stage of the software development lifecycle. For example, the current design defines two persistent storages for data, the RDF triple store and the relational database. We are aware of upcoming problems concerning the current implementation synchronisation algorithm. Consequently, parts of this design decision will probably be reworked and improved in the future.


10. References

[SeamAction] Allen, Dan. Seam in Action. Manning Publications, 2008.Greenwich, CT06830

[HIB] Relational Persistence for Java and .NET. available under: http://www.hibernate.org/ [JIRA] Available under: http://www.atlassian.com/software/jira/ [MÜL08] Müller, Bernd. (2008) JBoss SEAM. Die WEB-BEANS–IMPLEMENTIERUNG. Carl Hanser Verlag. München.

[OWL04] Smith, Michael. Welty,Chris. McGuinness, Deborah. (2004) OWL Web Ontology Language Guide. Available under: http://www.w3.org/TR/owl-guide/ [PREE04] Pomberger, Gustav. Pree, Wolfgang. (2004) Software Engineering. Architektur Design und Prozessorientierung. Carl Hanser Verlag München, 2004.

[RDF04] Manola, Frank. Miller, Eric. (2004) RDF Primer. Available under: http://www.w3.org/TR/2004/REC-rdf-primer-20040210/

[RX04] Beckett, Dave. (2004) RDF/XML Syntax Specification (Revised). Available under: http://www.w3.org/TR/rdf-syntax-grammar/ [SP08] Prud'hommeaux, Eric. Seaborne,Andy. (2008) W3C.SPARQL Query Language for RDF. Available under: http://www.w3.org/TR/rdf-sparql-query/ [SES02] Aduna, B.V. (2002) User Guide for Sesame 2.2. Available under: http://www.openrdf.org/doc/sesame2/2.2/users/index.html [SER03] Broekstra, Jeen. Kampman, Arjohn. (2003) SeRQL: A Second Generation RDF Query Language. Available under: http://www.w3.org/2001/sw/Europe/events/20031113-storage/positions/aduna.pdf

[TSW01] Berners-Lee, Tim. Hendler, James. Lassila, Ora. (2001) The Semantic Web. Available under: http://www.sciam.com/article.cfm?id=the-semantic-web

[WAF08] Wikipedia, available under: http://en.wikipedia.org/wiki/Web_application_framework.

[YUA08] Yuan, Juntao. Heute, Thomas. (2008) JBoss Seam. Enterprise Webanwendungen mit JavaEE – einfacher und leistungsstarker. REDLINE GMBH, Heidelberg [RD04] Seaborne , Andy. (2004) RDQL - A Query Language for RDF. available under: http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/ (2004)

[RQL02] Karvounarakis, Gregory. Alexaki, Sofia. Scholl, Michael. Christophides, Vassilis. Plexousakis, Dimitris. (2002) RQL: A Declarative Query Language for RDF.

[XQ07] Boag, Scott. Chamberlin, Don. Fernández, Mary F. Florescu, Daniela. Robie, Jonathan. Siméon, Jérôme. (2007) XQuery 1.0: An XML Query Language. Available under http://www.w3.org/TR/2007/REC-xquery-20070123/

[XS99] Clark, James. (1999) XSL Transformations (XSLT). Available under http://www.w3.org/TR/1999/REC-xslt-19991116 [XSL06] Berglund, Andreas(2006) Extensible Stylesheet Language (XSL) Version 1.1. available under http://www.w3.org/TR/2006/REC-xsl11-20061205/ [JSF08] Burns, Ed. Kitain, Roger. (2008) JavaServerTM Faces Specification, JSR 252 JavaServer


Faces 1.2 . available under http://java.sun.com/javaee/javaserverfaces/download.html [EJB06] DeMichiel, Linda. Keith, Micheal (2006) JSR 220: Enterprise JavaBeansTM,Version 3.0 EJB Core Contracts and Requirements. Available under http://java.sun.com/products/ejb/docs.html [JPA06] DeMichiel, Linda. Keith, Micheal (2006) JSR 220: Enterprise JavaBeansTM,Version 3.0 Java Persistence API. Available under http://java.sun.com/products/ejb/docs.html [JEE5] Website available under http://java.sun.com/javaee/technologies/javaee5.jsp

[JEEOv] Website available under http://java.sun.com/j2ee/overview.html [WIKJavaEE] Website available under: http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition [JavaPass] Website available under:

http://www.javapassion.com/j2ee/J2EEOverview_speakernoted.pdf [EJBTut] EJB 3 Tutorial.Website available under: http://www.laliluna.de/ejb-3-tutorial-jboss.html

d3.1 kiwi architecture final · pdf filethis deliverable describes the architecture, data...

Documents