back to main page

About Architecture

This Wiki page describes the NEPOMUK Architecture. In order to have a better understanding of the design rationale, the description will start, first by introducing the NEPOMUK engineering cycle, then the functionalities extracted from the NEPOMUK use cases and then detail the actual architecture diagram.

Engineering Cycle

NEPOMUK relies, among other things, on existing software developed by the partners. On the other hand, usability research is being held with the case studies partners by interviewing potential users of the Social Semantic Desktop (SSD). This specific set up of the project led us to develop our engineering cycle. This cycle represents the way we intend to merge the existing technologies and the needs from users.

Clockwise, the cycle shows the forward engineering cycle. We analyzed the end-user's intended usage of the SSD, studied the different use cases and formulated them into scenarios. We generalized the individual scenarios and extracted the common functionalities that make up the SSD. These functionalities formed the basis to define the reference architecture which in turn lead to the service specification and implementation that is tested by the end-users. On the other hand, partners already started to hack components that are likely to be needed by the SSD or had component developed before the NEPOMUK project started. Therefore, we reverse engineered these components to get their specifications and used the gained experience when defining the architecture.

The construction of the architecture of the SSD is therefore the combination of different parts:

• the requirements and objectives from the vision of the SSD driving the NEPOMUK project,
• the functionalities from user studies (forward engineering), and
• the service specifications of existing implementations (reverse engineering).

The overlaps between these areas give us confidence in the needs. Combining these three sources results in a complete architecture. Thus the architecture represents a shared understanding of all partners involved in the project and we see it as a roadmap towards the realization of the SSD.

NEPOMUK Functionalities

In order to integrate the requirements expressed in the scenarios and other materials produced in the case studies we need to use a more formal approach. All the material was processed by a group of members of the project coming from different areas: developers, case study partners, architects and usability designers. The results of this workshop is an homogeneous list of functionalities required to satisfy the scenarios. For each functionality, we provide a name, a short textual description, inputs, outputs and the relevant material in which this functionality was discovered. We grouped these in five clusters.

In the following we give an overview of the identified functionalities :

• Search enables users to search for resources amongst different sources (either locally or on the network). Users also need to find relevant resources by querying by example.
• Desktop. On their desktop, users manage resources, they use legacy applications to either create or edit documents therefore NEPOMUK needs to integrate these applications. NEPOMUK should provide a notification management system for the user to receive informations regarding shared resources and configure the ways she is notified. Even when offline, users should be able to access relevant resources transparently. We see desktop sharing as the ability to share applications or windows.
• Profiling by logging the user's activity, NEPOMUK should be trained to behave according to the specific user's needs. This automatic behaviours must be tailorable and include annotations and information regarding trust with other users or sources (i.e. if a user do not trust an information source, he should not receive results from this source).
• Data Analysis. To ease semantic annotation of unstructured documents, such as text, users can use keyword extraction. Search results might need to be rearranged using sorting and grouping. The use of reasoning provides with new information.
• Social. At the social level, the management of groups and users enhances social interaction and ease resource sharing. Access rights management tackles with the security needs. Users can publish and subscribe to relevant stream of information, such as the modifications made to a particular resource or the results of a search.

The discussion around these functionalities lead to a new architecture which integrates the user requirements and the SSD vision.

Overview

The NEPOMUK Architecture is organized into three layers (two of them shown in the figure above). The lowest layer (which is not shown in the figure) is the Operating System layer. Although the Architecture tends to be standardized, the particular implementations depend to some extent on the underlying operating system. The layer on top (Applications) represent the set of applications comprised into the knowledge workbench. One of the main goals of NEPOMUK is to provide data interoperability, which means that existing applications will be able to exchange data among them by means of the NEPOMUK Middleware. The NEPOMUK Middleware (the middle layer) represents the core of the NEPOMUK platform and can be split into three main parts:

• Service Registry - provides the means for publishing, unregistering and discovery of services part of the NEPOMUK Middleware.
• Core services - represents the set of standardized services which will be always part of a deployed NEPOMUK plaform. Among these core services, the one which have a particular importance are the Data Services because they provide the necessary functionalities for storing and searching both data and metadata stored on the desktop.
• Extensions - are services which can be included in the NEPOMUK Middleware but are not part of the stardard core set of deployed services. These are mainly high-level services, using the core ones and providing high level functionalities for the applications part of the knowledge workbench.

All services present in the diagram above are described in their corresponding subprojects.

NEPOMUK Middleware Communication

NEPOMUK Service Registry

Provides the means for registering, unregistering and discovering services part of the NEPOMUK Middleware.

• http://www.semanticdesktop.org/wsdl/2007/06/05/NepomukMiddleware.wsdl

ServiceDescriptor?

public String getName();

public String getTypeDescription();

public String getEndpoint();

NEPOMUK Client Library

The NEPOMUK Client Library provides an abstraction layer which hides all the underlying communication details for the clients. It comprises a set of standard interfaces which will always be used by the programmers in order to interact with the NEPOMUK Middleware.

NepomukMiddleware

public NepomukRegistry getRegistry();

NepomukRegistry?

public int registerService(String uri, String typeDescription);

public int registerServiceByName(String name, String uri, String typeDescription);

public int unregisterService(String uri);

public int unregisterServiceByName(String name);

public NepomukService[] discoverServicesByType(String typeDescription);

public NepomukService discoverServiceByType(String typeDescription);

public NepomukService[] discoverServicesByName(String regex);

public NepomukService discoverServiceByName(String regex);

public NepomukService discoverServiceByEndpoint(String uri);

public NepomukService[] discoverAllServices();

public String[] retrieveOperations(String uri);

NepomukService?

public Result sendMessage(Message message);

public ServiceDescriptor getServiceDescriptor();

Message

public void addParameter(Object value, Type type);

public String getMethod();

public Type getExpectedReturnType();

public void setExpectedReturnType(Type type);

public List<Object> getParameters();

public List<Type> getParameterTypes();

Result

public Object getValue();

public String getStatus();

NEPOMUK RDF Components

On client and server side we use RDF2Go to access the RDF models. RDF2Go is an abstraction over triple (and quad) stores. It allows developers to program against RDF2Go interfaces and choose or change the implementation later easily. No compile time dependencies. Easily add new stores. Triple and quad support. Contaxt: Max Völkel, FZI

On top of that, we often use RDFReactor. For each ontology class RDFReactor generates an easy-to-use Java domain class which can be use by any developer to access RDF without deep technical understanding of RDF. Generated classes views the RDF data model through object-oriented Java proxies. It makes using RDF easy for Java developers. Contaxt: Max Völkel, FZI

Contact

• Siegfried Handschuh
• Tudor Groza
• Gerald Reif
• Cedric Mesnage
• Laura Dragan