IKS Alpha Development
Public Deliverable 5.0
- Fabian Christ (UPB)
- Enrico Daga (CNR), Gregor Engels (UPB), Sebastian Germesin (DFKI), Ozgur Kilic (SRDC), Benjamin Nagel (UPB) and Stefan Sauer (UPB)
- 1 IKS in a Nutshell
- 2 Introduction
- 3 Development Process Overview
- 4 Top-Down Design
- 5 Bottom-Up Prototyping
- 6 Alpha Stack
- 7 Discussion and Outlook
- 8 References
IKS in a Nutshell
“Interactive Knowledge Stack” (IKS) is an integrating project targeting small to medium Content Management Systems (CMS) providers in Europe providing technology platforms for content and knowledge management to thousands of end user organizations. Current CMS technology platforms lack the capability for semantic web enabled, intelligent content, and therefore lack the capacity for users to interact with the content at the user’s knowledge level. The objective of IKS therefore, is to bring semantic capabilities to current CMS frameworks. IKS puts forward the “Semantic CMS Technology Stack” which merges the advances in semantic web infrastructure and services with CMS industry needs of coherent architectures that fit into existing technology landscapes. IKS will provide the specifications and at least one Open Source Reference Implementation of the full IKS Stack. To validate the IKS Stack prototype solutions for industrial use cases ranging from ambient intelligence infotainment, project management and controlling to an online holiday booking system will be developed.
This document describes the current status of the IKS Alpha development. The IKS Alpha is the first IKS release and a first proof that the applied development process leads to the desired results. In this document we will have a look at the development process and the status of the project within this process. The development process is divided into a top-down development and a bottom-up approach. Results of both approaches will be briefly described. At certain points in this document we will refer to deliverables of the different tasks in WP5 for further details. At the end of this document we will describe the architecture of the IKS Alpha and discuss the next steps which will lead us step by step to a final IKS implementation and reference architecture.
Development Process Overview
The applied development process in this project is a combination of planning the IKS top-down and learning how the system should be build by bottom-up prototyping. The IKS Alpha version is the first IKS version bringing together the results of both approaches. The IKS Alpha consists of components developed from the bottom-up approach which are heavily inspired by the design ideas of the top-down approach. With IKS Alpha the whole project is at a stage where both top-down and bottom-up approaches meet and the final IKS design and implementation phase starts middle-out. The current situation is depicted in Fig. 1.
The idea behind the top-down approach is an architecture refinement process shown in Fig. 2, which consists of three phases: architecture analysis, design, and implementation. The IKS requirements phase is part of the analysis phase where requirements and architectural ideas from WPs one, two, and three are collected and consolidated using the presented analysis architecture in Fig. 6 as reference.
After the Analysis Phase the next step is to refine the analysis architecture by adding concrete components and their interfaces. This phase is the Design Phase. The last phase is to implement the components and realize the architecture in code in the Implementation Phase. This more traditional style of a software development process was mainly driven by the research partners of the IKS consortium to ensure that the whole IKS is based on solid requirements and concepts.
In each phase we use the architecture domain model shown in the Annex as the architecture meta-model (AMM). During the analysis phase the AMM only consists of concepts like tiers and layers. The design phase adds the concepts of components, services, and interfaces. For the implementation phase we will need further concepts, e.g. design patterns.
The architectures of the different phases are syntactical instances of the AMM. Additionally, we have to consider that the named elements of the architectures have to be founded by a common IKS language which should be defined by an IKS ontology. This common language ensures that concepts like "tagging" are uniquely defined inside the IKS project to prevent ambiguity. This means that each architecture is also an ontological instance of the IKS ontology which is also refined between analysis and design.
The described relationships are depicted in Fig. 3. At the level of domain independent architecture meta-model we define the architectural elements which may be used in the different phases. At the instance level below, the concrete domain dependent architectures are specified, like the analysis architecture. These instances become domain dependent by being ontological instances of the used domain specific ontology. As the meta-model is refined from phase to phase the ontologies are refined, accordingly.
The first result of applying the architecture refinement process is an analysis architecture which can be designed based on the gathered requirements. This analysis architecture is expressed using concepts like layers and tiers. In the next step this analysis architecture is refined by adding more information about components, services and interfaces to the layers of the analysis architecture. The result is a design architecture which forms the basis for the concrete implementation.
Refining the Analysis Architecture
The description of architectural elements is refined by adding more information in the different phases. The main architectural elements of the analysis architecture are tiers and layers. At the beginning of the analysis phase the specification of a layer consists of a name, a unique ID, and a description. This information is based on the used analysis ontology.
During the analysis phase all functional requirements from the first three WPs have to be related to the layers. Here each functional requirement is mapped to exactly one layer to get an 1:1 relationship between functional requirements and layers. This ensures that functional requirements are connected to the IKS architecture and possible architectural mismatch becomes identifiable.
In the design phase components are added to the layers which are used to group components logically. The layer description is extended by component descriptions and their interfaces. Accordingly, the analysis ontology is refined and new terms are added which will be needed to describe the components and interfaces. When adding components to the layers the functional requirements which are related to the layers have to be reconsidered and related to the components. By this, each functional requirement becomes traceable to one concrete component. Precondition for this is that functional requirements are formulated at an adequate level of abstraction to map them to components. The concept of a layer description is depicted in Fig. 4.
The top-down approach was mainly driven by the research partners inside IKS. On the other hand the bottom-up approach was driven by the industrial partners, who liked to demonstrate their technical view on IKS. One challenge for the industrial partners was to communicate how they think an IKS should look like to become easily usable and integrateable for CMS vendors.
The bottom-up approach started with a first "Hackathon", a developers' camp in Furtwangen in spring 2010. The result of this first meeting was the "Furtwangen IKS Semantic Engine" called "FISE". Starting from this, the development went on in a distributed fashion known from many Open Source software projects and with further "Hackathon" meetings. FISE became the basic infrastructure for the idea of a semantic engine with content enhancement services which are able to enhance plain text with semantic annotations.
Beside FISE the first components of WP5 started to evolve. The development of the first versions of these components was already influenced by the ideas of FISE and the fundamentals from the requirements engineering and analysis phase of the project. With IKS Alpha we have the first version of IKS whereby the existing implementation has mainly emerged from bottom-up. Nevertheless do the WP5 components reflect on the requirements defined in the analysis phase. The WP5.x deliverables document which requirements are already addressed in IKS Alpha; see subsection Bottom-Up Prototyping for details.
Both processes from top-down and bottom-up meet at the point where first components exist and the analysis architecture is in a refinement phase by adding components and their interfaces. We call this phase the "middle-out" phase where the results of both approaches are combined.
In this phase the requirements and the analysis architecture are mapped to components from the bottom-up approach. The mapping is possible because existing components already address some requirements and were designed according to the ideas of the analysis architecture. The result is a combined view on the system with a first concrete architecture for the Alpha version.
The Alpha architecture is the first physical manifestation of an architecture which is one step towards the final IKS reference architecture. During the middle-out phase this architecture is refined by designing and prototyping missing parts, reviewing them and starting over again. The difference in this iterative process is that implementation and design are now tied together as it is known from existing agile software development processes [Cockburn02]. During this iterative process the Beta version and in the end the final IKS are released.
The top-down design started with a design workshop in Paderborn in spring 2010 [Christ10]. The result of this workshop was a first set of functional boxes at the different layers of the initial seven layer architecture. The main result of this workshop was an early picture (see Fig. 5) of the IKS architecture which mainly shows a set of boxes to group needed functionalities. As this was the first stack design workshop no further definition about the arrangement of those boxes and their relationships were made.
Error code: 127
From this starting point onwards the analysis architecture was refined in several review steps. The result was the IKS analysis architecture which is shown in the next subsection.
Error code: 127
The next table lists all used tiers of the analysis architecture with a brief description.
|IKS Client Tier||#ct||For all kinds of IKS clients.|
|IKS Server Tier||#st||The main IKS server.|
|IKS Management Tier||#mt||For managing the IKS server and repositories.|
|IKS Repository Tier||#rt||Contains data storages and repositories.|
The following table is the reference layer specification used by the analysis architecture and provides a unique ID for each layer which should be used for referencing them, e.g. from requirements, and a description.
|Knowledge Interaction||#ki||User centric knowledge interaction is a key feature of the IKS.|
|Presentation & Interaction Patterns||#pip||The presentation of knowledge and the handling of user interaction patterns is the top server layer. These features may not be implemented by each client and are therefore part of the server. Nevertheless, may clients implement their own presentation and interaction pat-terns beside the features offered by the server. This layer is the counterpart to the knowledge interaction layer at the client tier.|
|Knowledge Access||#ka||Clients may get access to knowledge using the knowledge access layer of the server which concentrates the access to lower level layers. Each information which should be offered to the client must be accessible through the knowledge access layer.|
|Process & Rule Execution||#pre||Dynamic models which handle processes and rules for different features are a basic concept of the IKS. The layer for process & rule execution encapsulates all components which interpret/execute processes and rules defined by dynamic models.|
|Atomic Services||#as||The atomic service layer is a generic layer where the different IKS services are placed. These services are accessible using a RESTful interface at the knowledge access level. More complex services which reuse atomic services may be part of this layer or part of any upper layer.|
|Integration & Distribution||#id||The IKS will be able to include knowledge from many different sources, especially it may reuse information offered by a CMS dynamically. The integration & distribution layer integrates others services outside the IKS into the server. This layer decides whether to use any external service or the local data access layer below.|
|Data Access||#da||The data access to the local repositories in the repository tier is encapsulated in the data access layer. This ensures a standardized abstract access layer for all kinds of content storages.|
|Model Access||#ma||The access to the various models which may be used inside the IKS is also encapsulated in a separate model access layer to have a standardized abstract model access mechanism.|
|Presentation & Interaction Models||#pim||Components which deal with presentation and interaction models for the client part are located in this layer.|
|Dynamic Models||#dm||Components for handling dynamic models for processes and rules are located in the dynamic models layer.|
|Static Models||#sm||Components for handling static models like ontologies, schemas, etc. are located in the static models layer.|
|Presentation & Interaction Management||#pimgt||Management components for presentation and user interaction aspects are grouped in this layer.|
|Dynamic Model Management||#dmmgt||This layer is for management capabilities for dynamic models.|
|Static Model Management||#smmgt||This layer is for management capabilities for static models.|
|Integration Management||#imgt||The integration and distribution behaviour of the IKS can be managed using components of this layer.|
|Access Management||#amgt||Access to content stores can be configured and man-aged by components of the access management layer.|
|Repository Management||#rmgt||Different repositories and their content are managed by components of this layer.|
|Persistence||#per||The persistence layer groups all data storage components.|
|External Services||#exts||The external services are neither a tier nor a layer of the IKS architecture. These services may be accessible over some network and are not in the scope of the IKS.|
The main objective of the top-down approach is to control the design and development process with respect to the elicited IKS requirements. As shown in Fig. 1, the analysis architecture and the IKS Alpha implementation are directly related to the requirements. Thereby, the top-down approach ensures that the required functionalities are actually addressed by the IKS Alpha.
The mapping process between requirements and the analysis architecture is described below. It serves two purposes:
- Validating the completeness of the analysis architecture, by evaluating that each requirements is addressed by a layer.
- Providing traceability in the development by setting relations among requirements and layers, that are refined into components.
The general process for the requirement mapping is shown in Fig. 7. Since non-functional requirements are usually addressing the software in general (e.g. performance or robustness) it is not useful to map these requirements to a specific layer. Thus, we focus on the mapping of functional requirements to the analysis architecture.
Error code: 127
In the first step, a functional requirement is selected and mapped to matching layers of the analysis architecture. In this context the term "matching", means that the requirements should be addressed by the functionality implemented in this layer according to the layer descriptions. If a requirement can be mapped to more than one layer, the requirement is refined to more specific requirements, that are addressed by exactly one layer.
If a functional requirement can not be assigned to a layer in the analysis architecture, this indicates that the architecture needs to be updated by a layer that provides the required functionality. The required layer is added to the analysis architecture and the requirement is mapped to the updated architecture.
In order to support the requirements mapping process described in the previous section we developed a web application termed IKS Requirements Consolidation Tool [IRCT]. The usage of IRCT in IKS has two benefits for the development process:
- Providing a central portal application for the maintenance and management of data from the requirements engineering and architectural design
- Communication platform that brings together top-down refinement and bottom-up prototyping
In different IKS work packages 1077 requirements have been elicited that need to be related to the analysis architecture (see Fig. 6). As shown in Fig. 8 the whole information about these requirements, e.g.: id, title, description, related use cases, assigned components etc. can be maintained by IRCT. The assignment of a requirement to a layer of the analysis architecture can easily be done using the illustrated graphical user interface.
The main challenge in the development process is to bring together the top-down and bottom-up approach. Using the requirements that are addressed by both approaches as an integration point is a promising approach to bridge the gap among them. Therefore IRCT also provides support for mapping implemented components to requirements. By using the "comment" functionality the communication between project members working on the top-down and bottom-up approach is motivated and improved.
Error code: 127
Monitoring the mapping process, IRCT also provides public browsing of assigned requirements using the different layers. Thereby, it can easily be traced which requirements need to be addressed in the implementation of a specific layer. The corresponding GUI is shown in Fig. 9.
Error code: 127
In this subsection we will describe the different prototypes which emerged from bottom-up. Starting with the FISE approach and going on with the components from WP5.
Semantic Engine (FISE)
The FISE approach was mainly driven by the industrial partners of the IKS consortium. Basic idea was to create a so called "semantic engine" which is accessible through a simple RESTful HTTP interface. The engine supports the enhancement of content given as plain with semantic meta-data. As an example, FISE supports the extraction, i.e. the annotation of named entities like places and persons in a given text. The following Fig. 10 depicts the idea of the FISE approach.
The FISE architecture consists of three parts: A (1) "Job Manager" receives incoming requests for content enhancement and delegates them to specific (2) enhancement engines. Additionally, FISE is able to (3) store the content along with the extracted meta-data. More details about the architecture are depicted in Fig. 15.
At the technology level FISE is designed using OSGi. Each component like the "Job Manager" or the enhancement engines are OSGi bundles. At runtime the different bundles are linked and act as one component based system. The component based software development and its process is perfectly supported by using OSGi. Its main advantage is the support for distributed component development. Once the interfaces between components are defined each component can be designed and implemented independently of other components. In a project like IKS with many distributed parties this approach worked well for FISE development and it's foreseen to go this way with the further IKS development.
Knowledge Interaction (INTERPRET)
In the Alpha Architecture (see Fig. 15), the INTERPRET component is located on the top layer and is responsible for managing and supporting the interaction of the user with the content, stored in the IKS-enabled content management system. In INTERPRET, the user's interactions are seen as tasks (e.g., contribute content to the CMS, retrieve this content, ...) which can be modelled within INTERPRET. Using these models, INTERPRET is then able to trigger IKS functionalities (e.g., retrieve related content, ...) using the technologies from the lower stack layers to support the user in reaching the goal of the ongoing task. The modular architecture allows a CMS developer to customize INTERPRET at any time, by adding new task models or IKS functionalities to the system. However, we deploy the system with out-of-the-box models.
One key requirement to INTERPRET was to implement it as a service for the CMS, instead of an in-between solution which is typical for interaction management systems. As the system is then not able to "eavesdrop" the ongoing interactions, it has to rely on a constant update of events from the CMS. Moreover, it is able to give recommendations, how, when and which content should be presented, whereas the CMS is in control of the final decision (see Fig. 11).
Error code: 127
Knowledge Representation and Reasoning (KReS)
The Knowledge Representation and Reasoning System (KReS) is a standalone set of software components targeted at the realization of the vast majority of functionalities and requirements belonging to the IKS knowledge management layer.
KReS Alpha is developed in Java as a set of OSGi components for the Apache Felix platform, and provides developers with a Java API and a set of RESTFul services. The KReS implementation relies on the OWLAPI for the ontology management (e.g., OWL2 and OWLLink support), on the JENA API for RDF-related features (e.g., SPARQL support), and provides Hermit as a built-in reasoner.
KReS has five main software components (see Fig. 12), each consisting of an OSGi bundle, or set thereof. As illustrated by Fig. 13, the components are the following:
- API: Provides interfaces and abstract Java specifications of all the components that are intended to be of interest for CMS developers. The components below altogether provide default implementations of the API. The API is documented as a reference for all developers who wish to provide custom implementations, or interact with KReS programmatically;
- RESTFul services: Provides a set of HTTP RESTful services for using KReS functionalities from client applications;
- Ontology Network Manager (ONM): Implements the API (see above) for managing OWL (including OWL2) ontologies, in order to prepare them for usage by reasoning services, refactorers, rule engines and the like;
- Rule Manager and Inference Engine (R&I): Implements the API (see above) for management of rules, and the execution of rule sets (called recipes in KReS), and the execution of reasoning tasks.
- Reengineering and Refactoring Engines (SEMION): Provides a set of functionalities for reengineering and refactoring of models, e.g., triplification, performed over the knowledge stored in a CMS persistence store, according to a set of customized ontologies and rules.
Error code: 127
KReS Alpha has been developed as a set of OSGi bundles for the Apache Felix environment, so it is naturally integrated with other IKS components such the Persistence Store (which KReS uses as persistence layer), FISE and INTERPRET.
The semantic lifting task is heavily based on the FISE architecture for the Alpha version. Semantic lifting is achieved by the concept of enhancement engines already available in FISE. The following enhancement engines for semantic lifting are available in IKS Alpha:
- Metadata and Text Extraction (Metaxa)
- Language Identification (LangId)
- Named Entitiy Extraction (Open NLP)
- Entity References
- Linking to third party semantic annotators
Persistence Store is the main component of the Semantic Data Access and Persistence Layer. Its responsibility is to provide storage and access points for the semantic data.
Persistence Store provides two types of interfaces to access semantic data. As an OSGi bundle it implements the interfaces specified in the FISE framework. Secondly, it has RESTful interfaces. Fig. 14 depicts the architecture of the Persistence Store component. As shown in the figure, Persistence Store component can be bound to Jena triple store at the backend and in future versions it will be also possible to configure persistence store with different triple stores. Furthermore, current version of the persistence store can be configured to interact with OWLlink reasoners to perform inferencing on the stored semantic data.
The detailed architecture and implementation information is available in the alpha stack report of persistence components. The report also describes an Ontology Generator component which creates bridges between the content repositories and the Persistence Store component. Ontology Generator enables connecting content repositories through standard interfaces like JCR and CMIS. Furthermore it provides RESTful services to enable content repositories to submit their content model.
Error code: 127
The IKS Alpha version is a first attempt to bring together different components from the bottom-up prototyping and aligning them to the analysis architecture from the top-down approach. Bringing together the different parts yields to the Alpha Architecture described in the following subsection.
The Alpha Stack Architecture shown in Fig. 15 combines the different components in a coherent view on the stack. This view is a combination of the analysis architecture with existing components and their "use" relationships. The current architecture is in a "work in progress" state what explains why certain functionalities are not present in this architecture at this stage of the project. For example the management capabilities are only rudimentary available in the Alpha version.
Basically, we have components with first implementations for user Knowledge Interaction with INTERPRET and an underlying layer for different kinds of services which are necessary according to the requirements. The FISE services address the semantic lifting requirements and the KReS services address required model, i.e. ontology, management functionalities. Both define interfaces to required data stores. At the Persistence layer we have a first implementation of a Persistence Store which is able to use different kinds of triple store implementations as its backend.
The four layers in this architecture are only loosely coupled in the Alpha version. The reader may have observed that components are not always connected by any "use" relationship to each other, e.g. between the "Knowledge Interaction" layer and the underlying layer with "Knowledge Access etc.". The components of these layers may communicate using HTTP RESTful interfaces. Using this loosely coupling strategy in the Alpha version was an advantage to organize the distributed development of different parts. Theses parts can already be used together but for the upcoming Beta version the interaction between layers has to be reviewed in order to release the full potential of the IKS.
IKS Alpha Showcase
The showcase for the IKS Alpha consists of four tasks to demonstrate the core features which have to be available with this version. The first task is "Develop IKS Services" which focuses on the methodology of how new IKS services are development within the environment of the Alpha version. Second task is "Register IKS Services" followed by "Activate IKS Services". Both tasks demonstrate how newly developed services are registered and activated to become usable. The last task is "Customise IKS Services" to show how services can be configured and customized.
Develop IKS Services
The IKS Alpha architecture is technically based on OSGi components. Developing new IKS services means to develop a new OSGi component which implements the required interfaces. For example a new enhancement engine would have to implement the corresponding interface which is defined by the FISE service API component. Each enhancement engine is developed as one OSGi component.
Register IKS Services
New services can be registered within the IKS just by deploying them inside the IKS Alpha infrastructure defined by the underlying OSGi infrastructure. The used OSGi framework implementation ensures that deployed services are available when the IKS starts up.
Activate IKS Services
Services can be activated and deactivated at runtime within IKS Alpha. This functionality is also realized using the underlying OSGi component infrastructure which allows the activation and deactivation of components at runtime by design. The IKS Alpha is implemented according to this design and allows the activation and deactivation of services at any point in time.
Customise IKS Services
IKS services can be customized in the Alpha version using the configuration interface of the OSGi framework, called OSGI console. Using this interface users can manipulate parameters offered by IKS services. This customisation interface is only a basic variant of what is needed in a final IKS but it already allows users to configure and customise services.
IKS Alpha Demo
The IKS Alpha will be shipped with two demo user stories to demonstrate the usage and features of IKS Alpha. These demos will be part of the IKS Alpha release and will pop-up as the stack is launched.
Discussion and Outlook
IKS Alpha is the first release of the IKS to demonstrate the basic concepts behind IKS in a prototypical way. This version is a technical proof of concept of how the IKS should look like. It forms the basis in terms of technology and infrastructure for the ongoing iterative development of subsequent IKS versions. The IKS Alpha version combines the results of top-down and bottom-up engineering and is the starting point for the middle-out process.
Although the IKS Alpha has emerged from two different angles the result reflects a common understanding of the needed concepts inside IKS. It was a very helpful approach to have prototypical technologies like FISE which stands for the industrial view on the IKS and the research based top-down view. Both angles explain what is needed expressed in different languages. With IKS Alpha there is the first version of IKS with a combined view which is shared by the whole IKS consortium.
Starting from IKS Alpha the iterative improvement process starts which ends with the final IKS. All further improvements have to be based on the requirements from the top-down approach and are implemented on the basis of the bottom-up approach. The monitoring of requirements to implementation helps to control the project's progress. With the help of tools like IRCT and issue tracker systems for the developers this monitoring can be assured. At the end of development all requirements have to be either implemented by IKS or are marked and justified as not relevant.
|[Christ10]||IKS Architecture Work in Progress Document|
|[Cockburn02]||Alistair Cockburn, Agile Software Development, Addison-Wesley, 2002|
|[Felix]||Apache Felix Platform - http://felix.apache.org/|
|[OSGi]||OSGi Alliance. OSGi Service Plattform Release 4.2. [Online] September 2010. http://www.osgi.org/Specifications/HomePage|
|[RM-SOA06]||OASIS. Reference Model for Service Oriented Architecture, V1.0. 2006|
|[Szyperski02]||Szyperski, C.; Gruntz, D. & Murer, S. Component Software - Beyond Object-Oriented Programming, Addison-Wesley. 2002|
|[UML10]||OMG. Unified Modeling Language, Superstructure (2.3). Technical report. 2010|
|[Weill07]||MIT Center for Information Systems Research, Peter Weill, Director, as presented at the Sixth e-Business Conference, Barcelona Spain, 27 March 2007|