Requirements Specifications of The Horizontal Industrial Use Case

1 / 218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case
www.iks-project.eu
Requirements Specification of the
Horizontal
Industrial Case
Deliverable: 2.2
Requirements Specification for the Horizontal Industrial Case th Delivery Date: 28 Febuary 2010 Author(s): Fabian Christ, Gregor Engels, Stefan Sauer, Gokce B. Laleci, Erdem Alpay, Tuncay Namli, Ali Anil Sinaci, Fulya Tuncer Filename: iks-d22-reqspec_hor_case-20100301.doc Publication Level: Public
Web link: http://www.iks-project.eu/iks-story/documentation
Interactive Knowledge Stack for Semantic Content Management Systems
2 / 218
Copyright Notice
This document contains material, which is the copyright of certain IKS consortium parties, and may not be reproduced or copied without permission. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the IKS consortium as a whole, nor a certain party of the IKS consortium warrant that the information contained in this document is capable of use, nor that use of the information is free from risk, and accepts no liability for loss or damage suffered by any person using this information. Neither the European Commission, nor any person acting on behalf of the Commission, is responsible for any use which might be made of the information in this document. The views expressed in this document are those of the authors and do not necessarily reflect the policies of the European Commission. IKS is co-funded by the European Union and develops technology for intelligent content management
Table of Contents Document History .................................................................................................................. 3 Document Information........................................................................................................... 4 1 Executive Summary ......................................................................................................... 5 2 IKS in a Nutshell ............................................................................................................... 6 3 Methodology ..................................................................................................................... 7 4 Results overview .............................................................................................................. 8 5 Document structure and concepts ............................................................................... 11 6 Requirements specification process ........................................................................... 14 6.1 Existing CMS ....................................................................................................... 14 6.2 Statements from industrial partners..................................................................... 18 6.3 Defining high level requirements ......................................................................... 18 6.4 The refinement process ....................................................................................... 19 7 Actors .............................................................................................................................. 21 8 High Level Requirements .............................................................................................. 24 8.1 Architecture and integration (HLR-2202)............................................................. 24 8.2 Common vocabulary (HLR-2201)........................................................................ 51 8.3 Semantic lifting & tagging (HLR-2203) ................................................................ 67 8.4 Semantic search & semantic query (HLR-2204) ................................................. 86 8.5 Reasoning on content items (HLR-2205) .......................................................... 124 8.6 Links/relations among content items (HLR-2206) ............................................. 130 8.7 Workflows (HLR-2207) ...................................................................................... 149 8.8 Change management, versions and audit (HLR-2208) ..................................... 159
3 / 218
8.9 Multilingualism (HLR-2209) ............................................................................... 173 8.10 Security (HLR-2211) .......................................................................................... 181 9 Summary ....................................................................................................................... 192 10 References .................................................................................................................. 193 11 Annex .......................................................................................................................... 194 11.1 Original statements from industrial partners ...................................................... 194 11.2 Requirements traceability matrix ....................................................................... 195
Document History
Version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Name Fabian Christ Gokce B. Laleci Fabian Christ Gokce B. Laleci Fabian Christ Fabian Christ Fabian Christ Fabian Christ Fabian Christ Fulya Tuncer Fabian Christ Fabian Christ Fabian Christ Fabian Christ Fabian Christ Fulya Tuncer Fabian Christ Fabian Christ Fabian Christ Fabian Christ Fulya Tuncer Date 2009-07-14 2009-07-17 2009-07-17 2009-08-06 2009-08-06 2009-08-14 2009-08-23 2009-09-18 2009-09-23 2009-09-25 2009-10-05 2009-10-09 2009-11-02 2009-11-04 2009-11-09 2009-11-09 2009-11-20 2009-11-27 2009-11-30 2009-12-01 2009-12-06 Remark Initial version Updates (HLR-1,3,5) Updates (Actors, HLR-2,4) Updates (Actors, HLR-1,3,5) Updates (Actors, HLR-4,6) Updates (HLR-6) Extended scenarios for HLR-4 Updated HLR-2 according to comments on mailing list Update of HLR-4 according to comments and changes in HLR-2 Updates HLR-1,3,5 Updated actors and HLR-2 Added HLR-011 Added scenarios and use cases to HLR-011 Added HLR-007 Updated HLR-2,4,6,7,11 Updated HLR-1,3,5,8,9,10 New TOC structure; Updated actors; Updated HLR-4 Renamed and updated HLR-2,4,6,7,11 and actors Added activity diagrams, completed use cases for HLR-2,4,6,7,11 Edited resulting requirements of HLR-2.4.6.7.11 Added executive summary, introduction, description of work, requirements traceability matrix Finished online document (HTML version)
22
Fabian Christ
2009-12-07
4 / 218
23 24 25 26 27 28 29
Fabian Christ Fulya Tuncer Fabian Christ Erdem Alpay Fabian Christ Fulya Tuncer Fabian Christ Andreas Gruber Wernher Behrendt
2009-12-11 2009-12-18 2010-02-05 2010-02-15 2010-02-19 2010-03-01 2010-03-04
First draft with results from online document. Integrated changes from first review ToDos according to Quality Assurance Feedback Merged ToDos from SRDC and UPB Edited use case and activity diagrams Final minor changes Final version to be submitted
Document Information
Item Identifier Author(s): Value IKS-231527-Deliverable2.2-2009 Fabian Christ, Gregor Engels, Stefan Sauer (s-lab, University of Paderborn), Gokce B. Laleci, Erdem Alpay, Tuncay Namli, Ali Anil Sinaci, Fulya Tuncer (Software Research, Development and Consultation Ltd. SRDC Ltd.) IKS Deliverable D2.2 Report: Requirements Specification for the Horizontal Industrial Case iks-d22-reqspec_hor_case-20100301.doc Public Interactive Knowledge FP7 231527 WP2 / T2.2 Fabian Christ, s-lab - Software Quality Lab, University of Paderborn Alessandra Bagnato (TXT) Andreas Gruber (SRFG) Gregor Engels (UPB) Fabian Christ, Gregor Engels, Stefan Sauer, Gokce B. Laleci, Erdem Alpay, Tuncay Namli, Ali Anil Sinaci, Fulya Tuncer, 2009: IKS Deliverable. D2.2 Report: Requirements Specification for the Horizontal Industrial Case
Document title:
Source Filename: Actual Distribution level Project (Title/Number) Work package / Task Responsible person and project partner: Name / QA / Release / Comment Citation information Official citation
Document context information
Quality Assurance / Review
5 / 218
1 Executive Summary
The objective of this deliverable is to provide requirements for the specification for horizontal industrial use cases. The horizontal industrial use case addresses the set of semantic enhancements provided by IKS that could be used by any CMS system, i.e. semantic enhancements that do not address a specific vertical business domain. In order to identify these requirements, we applied a requirements elicitation methodology that is grounded in software engineering processes. We first gathered business scenarios from industrial partners of the IKS project to understand their expectations from a semantically enhanced Content Management System. Furthermore, the existing CMSs of Day, Nuxeo, Alkacon and TXT were analyzed. In addition to these, a "Brainstorming Session on Requirements for Semantic CMS" was conducted in the first IKS Workshop where CMS vendors from outside the IKS consortium also attended. In this session, the CMS Vendors presented their expectations from a semantically enriched CMS. By consolidating the results of these activities, we created the wish list from CMS Developers for a semantically enriched CMS. The items of the wish list were grouped and ten high level requirements were identified. These high level requirements are as follows: Common vocabulary (HLR-2201)

Architecture and integration (HLR-2202) Semantic lifting & tagging (HLR-2203) Semantic search & semantic query (HLR-2204) Reasoning on content items (HLR-2205) Links/relations among content items (HLR-2206) Workflows (HLR-2207) Change management, versions and audit (HLR-2208) Multilingualism (HLR-2209) Security (HLR-2211)
The high level requirements are refined into use-cases (Section 0). These use-cases can be further grouped in to classes according to the dominant actors perspective. This grouping can also be applied to HLRs, e.g. HLR-2203, HLR-2204, HLR-2206, and HLR-2209, are qualified as use cases with a perspective of the CMS user, while HLR-2201, HLR-2205, HLR-2207, and HLR-2208 are qualified as use cases from a point of view of CMS admin and HLR-2202 is qualified from a point of view of CMS developer. Finally HLR-2211 addresses the needs of nearly all actors. The various actors of the IKS system and their relations between each other are described in Section 7. In short, the main actor of the system is the CMS user, which is the common super actor for all specialized actors that are CMS users but also have specialized roles such as a content consumer or a content creator and developer, which can also be specialized such as IKS developer and CMS developer. As a result, in this deliverable we suggest requirements for the development and evaluation of the IKS system for horizontal use cases from the point of view of different actors that interact with the system. The resulting high-level requirements are compiled in Section 11.2. The deliverable is structured as follows. First, we introduce the IKS project and the objectives of this deliverable. Then, the objectives of the task 2.2 in the project, the requirements gathering process, and the concepts of the document are discussed. Afterwards, the details of concepts used for defining IKS actors and high-level requirements are presented. Finally, we conclude this deliverable with a summary and a requirements traceability matrix.
6 / 218
2 IKS in a Nutshell
Interactive Knowledge Stack (IKS) is an integrating project targeting small to medium Content Management Systems (CMS) providers in Europe. These firms are 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 users1 to interact with the content at the users knowledge level. The objective of IKS 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. A rough overview of the stack is shown in Figure 2.1, which identifies the IKS layers that introduce semantic capability to CMSs. Hence, the grand vision of future CMSs is to have semantically enriched content that can interoperate in a flexible and semantically meaningful way. The vision for gathering requirements for horizontal business cases in this deliverable is to identify where semantic technology will make a difference to knowledge- and content management systems which can be utilized in generic and horizontal industry applications.
Figure 2.1 Layers of the IKS Stack
IKS will show that the semantically enhanced stack is generic enough to be used in more than one solution context and domain, with little adaptation. These will be demonstrated in the "Horizontal Industrial Case" within the scope of IKS project.
In this document, the term user refers to organisations using CMSs, content consumers, CMS developers, authors or administrators of CMSs
7 / 218
The aim of this deliverable is to define the domain-independent requirement specifications which will apply to all horizontal applications that are based on semantically enhanced CMS via IKS. The requirement specification from a software engineering perspective across the whole stack is provided in this deliverable. The requirement specification document for the horizontal industrial use case is the target deliverable of task 2.2. Requirements are a description of how a system should behave and what an application is expected to do as well as a description of system properties and attributes, thus determining the qualitative and quantitative characteristics of the system from the perspective of the CMS developer and user. The requirements engineering process covers the complex task of eliciting and documenting the requirements of the customer and all potential users, modelling and analyzing these requirements and documenting them as a basis for system design. Task 2.2 covers both the analysis and the recording of the requirements. And the objective is then to make sure we have well formed, and well written business and system requirements that everyone has agreed to for horizontal use cases design and implementation that will be performed in task 4.2 (Design and Implementation). Thus the requirements specification is critical to the entire software development life cycle. It serves not only as the reference document for the system design specification but also as the base document for generating the validation and acceptance tests. To achieve this aim, first the needs of horizontal frameworks are elicited from business cases, which covers the requirements of the different sectors. Then, the specification of the behavior of the system to be developed is provided with a complete description, which includes a set of use cases that describe all the interactions the users will have with the IKS. Finally the resulting functional and non-functional requirements are identified. As a result of this task, industrial partners of the IKS project will be able to test the software platforms of NUXEO, DAY and TXT with respect to their relative coverage of the IKS and at the same time will be able to demonstrate how IKS can be utilized to develop semantically enhanced horizontal applications.
3 Methodology
The IKS project develops and demonstrates the use of semantically enhanced CMS which allow new forms of interaction with knowledge rich content. To validate the IKS prototype solutions four industrial use cases have been predefined, two more are outlined, and several others will be chosen in the later stages of the project. One of the predefined use cases is has a visionary bias showing how the field of CMS may be influenced and changed through the vision of ambient intelligence. The second looks at the requirements in an area where a very rich knowledge domain is combined with CMS of arbitrary richness in media. The application domain of the second use case is project controlling, and as a demonstration of this, a knowledge-based "project-controlling system" will be analysed, designed and built. One of the outlined use cases looks at requirements from a vertical use case provided by Pisano/CIC who are active in the portal market for travel agencies and who are interested in combining their CMS with recommender systems - another example for a CMS provider moving towards added value through "intelligent content". In contrast, the other outlined use case looks at a horizontal use case from NUXEO and Day Software. These firms are end user-oriented CMS providers with a "horizontally placed" CMS framework. The use case is not fixed w.r.t an actual target application, but has a broad range of functionality where the set of generic functions needed in the IKS, at each of the layers can be studied.
8 / 218
The requirements of all of these use cases will be elaborated within the scope of work package two (WP2). It aims at providing real-world requirements for use cases as witnessed by industrial partners. This deliverable is the target outcome of task 2.2. Parallel to the work in this task, the industrial partners use their existing frameworks and applications to perform the benchmark exercise as part of task 2.1. This exercise is used to analyse the current level of achievement with respect to semantic capabilities. Additionally, IT executives of CMS provider firms were interviewed in order to capture their requirements. While consolidating these requirements, fifteen in-depth interviews with IT executives of CMS provider firms where performed and feedback from six industry partners was gathered. The result were 131 requirements which can be grouped under eleven major topics as follows: Interoperability (e.g., CMIS)

Enrichment of Content Enhanced Search Functionality Intuitive User interface Performance Personalization Flexible Data Modelling Flexible Workflow Modelling Support for Content Creation Multi-channel Access to Content Offline Work Support
Most of the above requirements overlap with the high level requirements that we addressed in this deliverable (see section 0). Since one of the aims of this deliverable is to find out generic requirements of horizontal uses cases, it is a way to validate that the resulting requirements of the horizontal industrial use cases are a part of the requirements of IT executives of the fifteen different CMS provider firms.
4 Results overview
The horizontal industrial use case focuses on the reuse of IKS in several different business domains. Whether IKS is used to enrich a tourist information CMS with semantic features or a health care CMS should not make any difference to IKS. The IKS must be aware of being integrated in CMS of such different domains. This horizontal industrial use case describes the common features which have to be provided by the IKS to ensure impact of the semantic features for all CMS business domains. To ensure this level of impact we gathered input from the industrial partners of the IKS consortium during a requirements workshop. A first result of the work in task 2.2 was the design and setup of the requirements engineering process which is reflected in the structure of this document. Starting from high level requirements (HLR) which were formulated by the industrial partners we set up a systematic approach to refine these HLR into specific software requirements using scenario and use case descriptions. This approach ensures the traceability of each software requirement to a HLR which was formulated by the industrial partners. Details of this process are described in section 6. All requirements are based on use cases which use a common actor's model for CMS. This actors model, described in section 7, is one important result of task 2.2, because this model is the basis for the communication inside the consortium about different use cases and which actors are involved.
9 / 218
Another major result concerns the requirements for an IKS architecture. An important issue for all industrial partners was the claim for an easy to use and technology independent mechanism for integrating the IKS into their existing CMS. The industrial partners suggested to use some kind of RESTful HTTP interfaces to connect CMS and IKS. This requirement was reflected in section 8.1 of this specification. All IKS features are expressed in terms of services which can be accessed by any CMS. These services can be reused to create new higher-order services, the IKS can be extended by new services for semantic features, and services can be replaced. This setup allows a modular development of the IKS and enough flexibility to experiment with different implementations of semantic services. Additionally, each service is required to define further extension points to allow fine grained customization of all semantic features. All further requirements are based on or related to, the architectural requirements. These requirements form the basis for all semantic features the IKS should provide and therefore must be considered by all IKS features. The architectural requirements are of such importance because all involved industrial partners stress the point of easy interoperability with IKS with a minimum of technological dependencies. To ensure the impact of IKS on the whole industry of CMS providers this requirement is essential. Based on the architecture requirements nine HLRs were identified. Each HLR focuses on a specific aspect, which is of importance for all CMS vendors and therefore relevant for the horizontal industrial case. Each HLR is refined using the mentioned requirements engineering process, so that each HLR is the root for a set of requirements which should be reflected in the design of the IKS. This document defines about 200 requirements which result from the ten HLRs and their use cases. Implementations of IKS compliant systems will be benchmarked according to these requirements. At first, we identified the requirement of defining a common vocabulary (HLR-2201, Section 8.2) to standardize the terminology inside a CMS. This ensures a common language for all semantic features of IKS and guarantees that different heterogeneous CMS have the same understanding of the features. Content without any semantic meta-information must benefit from the semantic features of the IKS as new semantically enriched content will. The HLR semantic lifting & tagging (HLR2203, Section 8.3) focuses on the fact that in each CMS, regardless of its domain, content will exist which has to be lifted with semantic information. Tagging is one technique to achieve this but IKS should be able to support further techniques. The need for new approaches is also present for semantic search & semantic query (HLR2204, Section 8.4) which is another key requirement for the IKS. Industrial partners of all domains were focused on the ability to provide better search results for their content as searching is a standard feature in all CMS. This would improve the systems of all industrial partners and strengthen their capability to manage content und make it more findable. Another section of requirements addresses the need for combining content automatically. Both reasoning on content items (HLR-2205, Section 8.5) and the automatic creation of links/relations among content items (HLR-2206, Section 8.6) treat this aspect and define requirements which must be addressed to support such a feature. Again, this functionality is of importance for all domains because it offers the capability of generating an added value by re-combining already existent content. Each CMS provides mechanisms to represent and manage the workflows (HLR-2207, Section 8.7) of content and to support tasks like change management, versions and audit (HLR2208, Section 0). These basic features also need to be updated with a semantic view at the content because new semantic features which operate on the content require new solutions, e.g. for change management. The handling of content workflows can be redesigned by using the semantic information associated with the content. Semantic information can be used e.g. to determine the current state of a specific content in a given workflow. Even the workflow
10 / 218
can be expressed in a semantic way which enables the CMS to provide a very flexible way for defining them. Content in large CMS is created in many different languages, so that all IKS semantic feature should be aware of multilingualism (HLR-2209, Section 8.9) of its users and the content. Ideally, the semantic features are able to operate regardless of the language of the content. Practically, some features will be language based and therefore will not work for all languages. Other features have to be adjusted to the language currently in use. A key requirement is to detect the current language in a first step and then adjust the semantic features in a second step. When content is enriched with such new features of the different HLRs the security (HLR2211, Section 8.10) of accessing the content and its use must be reconsidered. Without the use of semantic features the access to content was often restricted by flags like "read-only" or "no-deletion". The use of semantic features requires new flags like "reasoning-allowed" or "linkable-with" to define which semantic operation may be performed on the content. This topic becomes even more important w.r.t. privacy or copyrights of content. All these HLRs were identified as being of importance for the horizontal industrial case as they are independent of any domain or technology. The IKS has to address all of these HLRs but may focus on specific aspects in different releases as the IKS stack is evolving.
11 / 218
5 Document structure and concepts

This document is structured according to the requirements specification process, which is described in section 6, and the IEEE-830 standard for recommended practice for software requirements specifications [IEEE830]. We will start by describing the process to define the requirements for the horizontal industrial case, and then go on with the model of actors which will interact with the system. Afterwards we will proceed with the refinement description of all high level requirements that were identified for the horizontal use case. Each high level refinement description consists of scenario descriptions, use case descriptions, and the description of the resulting requirements. A high level refinement description starts with meta-data about the high level requirement. This is done in tabular form using the following fields. HLR ID A unique identifier that represents the HLR. The pattern for this ID is "HLR-"[TTNN], where TT is the number of the work package task and NN is a sequential number. Example: HLR-2202 = HLR of task 2.2 with number 02.

Name A name of the HLR Description A textual description of the main aspects of the HLR Classification A classification of the HLR using the following categories: o Cross cutting / non-cross cutting This category is used to distinguish between HLR that have a cross cutting impact on all other HLR, e.g. security, and HLR that describe a single functionality, e.g. search. o Horizontal / Vertical This category is used to distinguish between HLR that are relevant for the horizontal industrial case or not. In this specification we used horizontal HLRs only.
Related HLR If a HLR is related to other HLRs, the IDs of the other HLRs can be listed here. Statements Lists all related statements from the industrial partners, that have influenced the HLR.
After defining the meta information the refinement process starts by describing user scenarios. These scenarios reflect the existing needs and are the basis for the definition of more concrete use cases that should be implemented. Scenarios are free textual descriptions. To formalize the content of the described scenarios actors and use cases are extracted. Actors and use cases are modeled using UML use case diagrams [UML]. To express more details about the activities of an use case we optionally used UML activity diagrams [UML] additionally. Beside the UML diagrams each use case is described in tabular form. These tables consist of the following information: Use Case ID A unique ID to identify the use case. The pattern for this ID is "UC-"[HHHHNN], where HHHH is the four digit number of the HLR and NN is a sequential number. Example: UC-220223 = use case for HLR-2202 with number 23.
12 / 218
Description A textual description of the use case. Relationships to other use cases like o Inheritance The general use case is referred to as the "parent" use case. o Include During the execution of one use case the imported use case is invoked. o Extension A use case invokes its extended use cases when the trigger for the specified extension is true.
Scope The abstract scope of the use case to make it easier for a reader understand the context of this use case. It specifies the parts of IKS system that are involved in the use cases. Actor(s) The involved actors of the use case. Goal The goal that has to be reached by performing the use case. Trigger The trigger of the use case to express which action must take place to trigger this use case. Frequency The frequency in which the use case is triggered.
Beside these information the refinement process offers the opportunity to add more optional details. These information are optional, because in the early phases of the IKS project many details of the requirements, like exact pre- and postconditions are not available. Especially details that require knowledge about the design of the IKS are not available in the phase of task 2.2. More details and further requirements will be added during the design phase of the IKS. Therefore the following fields are optional fields in the use case descriptions of task 2.2. Action An UML activity diagram that expresses a process of activities that are involved when the use case is executed. This is often used to clarify the relationship of use cases in a process view.
Preconditions Preconditions express a set of conditions that have to be fulfilled before the use case can be executed. Minimal Postconditions The minimal postconditions are conditions that at least have to be fulfilled after the use case was executed. In particular the minimal postconditions have to be fulfilled when the use case was executed with errors or exceptions. Success Postconditions The success postconditions must be fulfilled when the use case was executed without any errors or exceptions. These conditions express the normal case of the use case execution. Main Flow The main flow describes the process that is performed within the use case. This can be used to describe the internals of a use case more precisely. This is a narrative based action step to achieve the goal of the use case.
13 / 218
Exceptions Exceptions describe situations where the use case execution makes an exception to the normal behavior that may be described by the main flow. Open Issues Open issues can be used to clarify that the use case description leaves out some points that are open or cannot be answered at this stage. The reader gets a hint that these points should be considered in another phase of the development process.
In the end we give a summary of the identified resulting requirements and provide requirement overviews like a requirements traceability matrix and final listings of all requirements. The resulting requirements are formulated as single testable statements. The formulation is key word based according to [RFC2119]: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Requirements are classified in five different categories: Functional requirements Functional requirements are requirements that express required functionality that cannot be classified as data, interface, or integration requirement.
Data requirements Data requirements are requirements that focus on the transported or handled data and their format. Interface requirements Interface requirements specify requirements for the provided and requested interfaces of a system. Integration requirements Integration requirements are requirements that affect the capability of the system (the IKS) to integrate with other systems (CMS). Non-functional requirements Non-functional requirements are requirements that affect properties like usability, reliability, performance, or supportability.
14 / 218
6 Requirements specification process

We used two approaches to gather requirements: Existing CMS We examined the architectures and features of existing CMS from Alkacon, Day, Nuxeo, and TXT (see section 6.1).
Statements from industrial partners We used statements from the industrial partners (see section 6.2) that were collected during a workshop where industrial partners were asked to brainstorm about requirements for the IKS.
After the first phase of gathering requirements we were able to specify a set of high level requirements (see section 6.3) that were refined using a defined requirements refinement process (see section 6.4).
6.1 Existing CMS

Our first step was to examine the existing CMS of our industrial partners, namely Alkacon, Day, Nuxeo, and TXT. The goal was to identify the commons parts that all these CMS have. These common parts are the basis for our work on requirements for the horizontal industrial case, because the IKS has to support this case by providing features and mechanisms that allow easy use and integration for existing CMS. Our input were product descriptions, slides from the industrial partners about their expectations on the IKS with respect to their own product, the product web-sites, and the running CMS itself. The goal was to identify similarities, common use cases, and needs that all industrial partners share. In the following sub-section we describe the results of this analysis.
6.1.1 Managed content

At first we investigated the types of content that a CMS should be able to handle. Not each system can handle all of them, some are specialized to some content types, but the IKS should be prepared that all types of content are supported. The analysis yields the following list of content types. Documents (office)

Web sites / web applications Multi-Media files (audio, image, video) Individuals (social networking) Postings + Comments (blogs, forums) Short messages (sms, twitter) Topics (wiki) Correspondence (e-mail, newsletter) Feeds (rss)
15 / 218
6.1.2 Content workflow

The next analysis step was a closer look at the content workflow that all reviewed CMS depend on. At first we extracted the common content workflow from content creation to publishing that is depicted in the next figure.
Figure 6.1 From content creation to publishing
The first two phases were not in the focus of the industrial partners, because the main innovations from the IKS are expected to take place in the phases enrichment, storage, and publishing. The result of this analysis was a list of needs grouped by the corresponding content workflow phases. Semantic enrichment needs o Automatic classification and routing o Faceted classification o Use of predefined taxonomies o Automatic semantic tagging o Automatic ranking o Semi-automatic annotations o Annotation with Microformats o Ontology extraction o Concepts, people, places, etc. extraction o Relationship extraction (isA, partOf) o Cross-Source correlations o Document models from ontologies o Knowledge representation
Persistence needs o Workflow states o Relations o Directories o Audit o User preferences o Converted content o Synchronization of Content Repository Semantics with Semantic Persistence Stores
Publishing needs
16 / 218
o Semantic workflows o Collaborative content management with semantic and social techniques o Personalisation of UI o Knowledge view / administration Another workflow that was focused is the search functionality.
Figure 6.2 Search
Search needs o Pluggable external semantic search o Ambiguity resolution o Similarity searches semantic based and multilingual o Relationship recognition o Keyword search o Natural language queries o Ranked search results o Faceted Search
6.1.3 Existing content services

After identifying the needs of the industrial partners, we had a closer look at the existing systems. The question was, which component do already exist in such systems. With the knowledge of existing components we were able to define requirements of the horizontal case with respect to the existing systems. This aspect was important to ensure that it will be possible to integrate the IKS and existing CMS. The result is a list of services that are already used in existing CMS. Creation / Ingestion

Ingestion Schedules Transcoding Indexing Metadata extraction Storing Versioning Audit / Archive Workflow Management Publishing Notification Search and query Rendering User profiles
17 / 218
Security Ad service
6.1.4 Architectural view

The last step was an analysis of the architectural styles that the existing CMS use. We examined architecture diagrams and extracted the common aspects that each system was based on. The result of this analysis is depicted in Figure 6.3.
Figure 6.3: Abstract architectural view on existing CMS
Starting at the bottom each examined CMS consists of a component model that acts as a middleware for the implementation. All services are created according to the used component model. A communication bus enables the communication between components and security features are implemented orthogonal to the services. The data is stored in a content repository and additional information in a meta-data repository. The repositories are realized using some database management system. At the front end the different CMS support GUI access ranging from web applications that are controlled by a browser, over rich client desktop applications to mobile applications, e.g. for smart phones. The next question was how new functionality provided by the IKS may be integrated in this architectural scenario. The idea was to offer a set of semantic services by the IKS, that can be easily used by a standardized communication protocol. This approach was agreed and supported by the industrial partners who would like to see simple RESTful [REST] interfaces to these semantic services. The new situation is depicted in Figure 6.4.
18 / 218
Figure 6.4 Architectural view on existing CMS integrated with IKS semantic services
6.2 Statements from industrial partners

One agenda highlight of the IKS general assembly meeting in Salzburg (May 27-29th, 2009) was a community workshop with a brainstorming session on requirements for semantic CMS. The result of this workshop was a list of statements from the industrial partners that represent their view on a semantic CMS. The industrial partners were asked for features that a semantic CMS should have and that todays CMS system do not provide. The complete list of the statements can be found in the annex of this document (see section 11.1). The resulting list was filtered and used together with the needs from the analysis of existing CMS as the basis for the definition of the high level requirements that are relevant for the horizontal industrial case. It is valid to use these statements as the basis, because they reflect the view of the CMS industry and their needs. To gain as much impact as possible in the CMS industry by the implementation of the IKS we have had to focus rather on the industrial needs than on theoretical thinking.
6.3 Defining high level requirements

The goal of our prior analysis was to have a basis of information that allows us to define a set of high level requirements that can be refined using our requirements refinement process. A high level requirement groups aspects that should be supported by the IKS thematically. Using this grouping strategy we were able to structurize the unstructured wishes and needs of the industrial partners and perform a well defined refinement process. This process starts from the high level requirements and ends with testable software requirements for the IKS. Our starting point was a list with 47 statements of our industrial partners plus the compiled needs from the analysis of existing CMS. The statements and needs were grouped thematically and each group made one high level requirement. The result was the following list of ten high level requirements. Architecture and integration (HLR-2202)

Common vocabulary (HLR-2201) Semantic lifting & tagging (HLR-2203)
19 / 218
Semantic search & semantic query (HLR-2204) Reasoning on content items (HLR-2205) Links/relations among content items (HLR-2206) Workflows (HLR-2207) Change management, versions and audit (HLR-2208) Multilingualism (HLR-2209) Security (HLR-2211)
6.4 The refinement process

After defining the ten high level requirements (HLR) each HLR is refined using the following refinement process. The process starts with the HLR, produces use cases (UC), and results in lists of testable software requirements (R) for the IKS. The following Figure 6.5 depicts the refinement graph as an directed acyclic graph (DAG) that emerges from this process.
Figure 6.5 Refinement DAG, that emerges from the refinement process
The requirements refinement process iterates over all HLRs. For each HLR two refinement steps are performed. The process is depicted in the next figure.
Figure 6.6 Refinement process from HLRs to resulting requirements
The first refinement is to specify scenarios and to extract and consolidate use cases from these scenarios. The result is a set of scenarios and use cases for each HLR. The use case
20 / 218
consolidation is important to identify relationships between use cases and to keep them consistent among each other. The second refinement step is to extract and consolidate the resulting requirements. The software requirements result from the use cases, so that each use case relates to one or more software requirements. A key characteristic of these requirements is their testability. For this the requirements are formulated as simple statements like "The IKS shall be able to...". This formulation is key word based according to [RFC2119] (see section 4). The refinement process is implemented as an open participation process that supports constant input from the involved industrial partners. The process coordination and consolidation of the input was done by the research partners, who also made proposals for the requirements based on the input of the industrial partners. To achieve this in a distributed setup of partners, the documented results were published online at any time with the opportunity for the partners to add comments and make further suggestions.
21 / 218
7 Actors
This section gives an overview of the involved actors. An actor is a role that is associated with the execution of a use case. Each use case is associated with at least one actor that drives the use case. Actors can be human users that interact with the system or technical actors like a service that performs a use case. Actors can be refined to express that one actor is a specialized role of another actor. For example, the actor CMS user is the common super actor for all specialized actors that are CMS users but also have specialized roles like a content consumer or a content creator. Figure 7.1 gives an overview of all used actors and their relationships.
Figure 7.1 Actors overview
22 / 218
Actor CMS
Short name CMS
Description The CMS actor controls all use cases that are automatically executed inside the traditional CMS system. From the viewpoint of the IKS the CMS actor is technically a consumer that sends queries to the IKS and its services. The IKS actor controls all non user driven use cases that are not part of traditional CMS systems. As the IKS will be some kind of service broker this actor is used for use cases that are not handled by a specific service.
IKS
IKS
IKS Service
IKS Service The IKS consists of different services. All use cases that are handled by a specific service are associated with the IKS service actor. CMS User The abstract CMS User is the parent actor of all specialised users. So each use case that is associated with the abstract CMS User can be executed by any specialised actor which uses features of either CMS or IKS. It may be one of Consumers, Managers or Creators. If no specific content consumer is considered we use this more abstract Consumer actor. The abstract Consumer is the parent actor of all specialised consumers. So each use case that is associated with the abstract Consumer can be executed by any specialised consumer actor. A content consumer does not create content of any kind - a consumer is rather a read only user of the system. For example, a content consumer can be a web site visitor who reads the content published by the CMS or an intranet user who has read access to the content of the intranet CMS. Consumers typically have only access to the front end of the CMS with all features for searching, viewing and reading content.
CMS User
Content con- Consumer sumer
Novice con- Novice con- A novice content consumer is a consumer with little or no tent consumer deeper knowledge about underlying technologies or special feasumer tures of the system. It is that kind of user that only wants to use the system quick without a longer learning phase, e.g. first time consumers. By the time they learn more about the system's features and use them as advanced consumers. Advanced Advanced content con- consumer sumer An advanced content consumer has often used the system for a longer period of time and knows all or many of the advanced features that allows him to do his work more efficient. A novice consumer in contrast might not be able to do the same task in the same time and quality as an advanced consumer especially when the task is complex and requires the usage of features that cannot be known by a novice consumer. When a content consumer is able to create content in some situations the consumer becomes a content creator for those use cases. By content creation we mean the process of creating
Content cre- Creator ator
23 / 218
Actor
Short name
Description something that is stored in the system and that can be (re)used by other actors. Typically content creators have access to the back end of the CMS where they have all features for content creation.
Novice con- Novice cre- The novice creator is the greenhorn-backend-user of a CMS, tent creator ator who uses only the basic functionality of the CMS backend and needs often help and advise. On the other hand the novice content creator creates most content elements withouht beeing responsible for the content. Advanced Advanced content cre- creator ator Content manager Manager The advanced creator is the power-backend-user of a CMS, who uses all functionalities of the CMS backend. This actor manages products, articles, news, and publishes the content. The content manager is the super user for content consumption and creation. The manager knows the CMS in detail and is able to configure and manage the workflows within the CMS. The CMS administrator configures and maintains the CMS and the integrated IKS services. The admin is the power user who configures the used IKS services inside the CMS. All use cases that handle development or integration tasks are associacted with some developer actor.
Administrator Admin
Developer IKS oper
Developer
Devel- IKS Devel- The IKS developer is an architect, designer or programmer of oper IKS core functionalities.
CMS Devel- CMS De- A CMS developer is an architect, designer or programmer of a oper veloper CMS. CMS programmers can customize the IKS as they are specialized IKS customizers and specialized service customizers. IKS Custo- IKS Custo- The IKS customizer is an architect, designer or programmer that mizer mizer is able to customize the IKS, e.g. implement a new semantic service using the IKS infrastructure. The customizer does not implement or change the core of the IKS. IKS service Service customizer Customizer An IKS service customizer customizes existing IKS services, e.g. by using defined extension points of an IKS service.
24 / 218
8 High Level Requirements

Based on the wish lists of the industrial partners and the analysis of the existing CMS of Day, Nuxeo, Alkacon and TXT we extracted ten high level requirements (HLR). These HLRs reflect all relevant requirements for the horizontal industrial use case. Each HLR is documented and refined according to the defined requirements specification and documentation process. Architecture and integration (HLR-2202)

Common vocabulary (HLR-2201) Semantic lifting & tagging (HLR-2203) Semantic search & semantic query (HLR-2204) Reasoning on content items (HLR-2205) Links/relations among content items (HLR-2206) Workflows (HLR-2207) Change management, versions and audit (HLR-2208) Multilingualism (HLR-2209) Security (HLR-2211)
8.1 Architecture and integration (HLR-2202)

HLR ID HLR-2202 Name Architecture and Integration Description To allow easy integration of IKS functions into different heterogeneous system environments all IKS functions should be accessible through RESTful service interfaces. So the IKS architecture should be based on a service approach. The implementation should be as technology independent as possible on the one hand and on the other hand provide technology specific access to the services to guarantee best performance results. The communication is based on standardized text-based data formats, e.g. XML. The mantra behind this idea is that everything (data, functions, etc.) inside the IKS stack can be accessed by an URI. The IKS has to be customizable and extendible by new services and the implementation (e.g. an algorithm) has to be exchangeable. Services can be orchestrated/recomposed to new higher order services which re-use existing services. IKS services need access to information that are inside the data repository of the CMS. Therefore, the IKS defines data access interfaces that must be supported by the CMS that integrates the IKS. Classification

Cross cutting Horizontal
25 / 218
Related requirements Statements
none Architecture should be based on services like web services restful services not on libraries, should be independent Try to leverage existing content, have a semantic layer on top of that, create a bridge, semantic restful interface between the available content and semantic layer
Examples / Scenarios
Scenario 1 The CMS uses an IKS service by transmitting an URI and input parameters. The IKS routes the request to the service identified by the URI, invokes the service and sends the response back to the CMS. The response's content is delivered in an IKS specific format. The CMS may send several independent requests in parallel. To identify each request for functions like logging, journalizing, auditing, or for sending requests to the CMS in the context of a service execution, the CMS must provide a request identifier that uniquely identifies the request inside the CMS. These CMS request identifiers are used inside the IKS to manage all incoming request. The IKS itself will need an algorithm to identify all IKS requests uniquely inside the IKS using the CMS request identifier as input.
Figure 8.1 Use case diagram for scenario 1
26 / 218
Scenario 2 Same as scenario 1 but in this case the IKS service needs additional information that must be provided by the CMS, e.g. the IKS service needs information from the CMS's data repository. When requesting information from the CMS the IKS service must provide the original CMS request identifier that allows the CMS to identify the context of this request from the IKS.
Scenario 3 An IKS service needs content as input. In this case the content is delivered by sending a URI or a list of URIs that points to the content. Then the IKS service is able to load content from that URIs. The content might reside inside the CMS but might also be stored somewhere else (Intranet, WWW, etc.). The only demand is that the content is accessible by an URI.
27 / 218
Scenario 4 Some IKS services will need to persist data. This data can be stored in the IKS's own data repository or in the CMS's data repository. When data should be stored inside the CMS the CMS must implement the IKS specific data storing interfaces.
28 / 218
Scenario 5 IKS services will need feedback information from the CMS that tells the IKS service how the CMS user liked the results that were generated by an IKS service in response to a request. This provides IKS services the opportunity to learn from the feedback. Feedback can be given for each pair of request and response.
29 / 218
Scenario 6 As it is unclear how the performance of specific semantic IKS services will behave the CMS can provide performance criteria when requesting the service. One criteria will be that the response must be send in a given period of time by the IKS service - otherwise the results are useless for the requester. This is useful in situations where you cannot expect a user to wait longer than a given time before a result is shown. If the result cannot be computed within this time it is more feasible for the user to continue asynchroniously with his work without the results. The IKS services must be aware of the time they use to compute the results and must be able to cancel the computation immediately when time is up.
30 / 218
Scenario 7 IKS services should be reusable to create new services. The requirement is that the IKS provides a mechanism to create higher order services by re-using existing services (aka service orchestration).
31 / 218
Scenario 8 The IKS must provide a framework that allows the easy integration of new services without changing the core of the IKS. Services are plugins or extensions that might be developed by third parties. The IKS itself is bundled with a set of predefined services but each service can be unplugged and other services can be plugged in. Each service must be implemented according to the IKS service specification. This ensures that all services provide the required horizontal features that are needed, e.g. for performance issues or service orchestration.
Scenario 9 To allow the use of different algorithms for a specific service the service implementation should be exchangeable. Moreover the IKS services can define extension points to allow the extension of a specific service with custom algorithms. The extension point mechanism is standardized through the IKS service specification.
32 / 218
8.1.1 Use Case Descriptions

The use cases are ordered by actors:
CMS
o o o o o o o o o o o o o
UC-220201: Send IKS service request UC-220202: Send request with content URIs UC-220203: Send request with execution time constraint UC-220204: Perform IKS request UC-220205: Perform IKS storage request UC-220206: Send feedback
IKS
UC-220207: Receive request UC-220227: Manage request by identifier UC-220208: Receive feedback UC-220209: Route to service UC-220210: Route feedback to service UC-220211: Invoke service UC-220212: Send response IKS Service o UC-220213: Execute o UC-220214: Cancel execution when time is up o UC-220228: Send CMS request o UC-220215: Request information from CMS o UC-220216: Load content from URIs o UC-220217: Store data o UC-220218: Store data in IKS o UC-220219: Store data in CMS
33 / 218
IKS Customizer o UC-220220: Read IKS service specification o UC-220221: Create service o UC-220222: Implement and document service extension points o UC-220223: Reuse existing service o UC-220224: Plug service in IKS Service Customizer o UC-220225: Create service extension
UC-220201: Send IKS service request

Use Case ID UC-220201 [SC1, SC3, SC5, SC6] Description A CMS sends service requests to a semantic service inside the IKS. Parent none Includes Scope Service invocation Actor(s) CMS Goal The specified IKS service is invoked. Trigger A CMS service request. Preconditions 1. The IKS is ready to receive service requests. Minimal Postconditions 1. The IKS sends a response back to the CMS. Success Postconditions 1. The specified IKS service is invoked and the results are sent back in the response.
UC-220202: Send request with content URIs

Use Case ID UC-220202 [SC3] Description A CMS sends a service requests that transports a list of URIs. The URIs point to content that is processed by the semantic service. The IKS service is able to load the content using the protocol and location specified by the URI. Parent UC-220201 Includes none
34 / 218
Scope Service invocation Actor(s) CMS Goal The specified IKS service is invoked using the list of URIs as input. Trigger A CMS service request with list of URIs.
UC-220203: Send request with execution time constraint

Use Case ID UC-220203 [SC6] Description A CMS sends a service request that transports constrains about the maximum execution time that a service invocation is allowed to consume. If the service processing takes more time the processing has to be canceled and timeout result returns. Parent UC-220201 Includes none Scope Service invocation Actor(s) CMS Goal The specified IKS service is invoked and returns a result without exceeding the maximum execution time. Trigger A CMS service request with maximum execution time constraint. Preconditions 1. The IKS is ready to receive service requests. Minimal Postconditions 1. The IKS sends a response back to the CMS. Success Postconditions 1. The specified IKS service is invoked and its execution is canceled when the maximum execution time is reached. 2. If the IKS execution time is reached the service sends a timeout result in response. 3. If the IKS service finishes the execution within the given time the results are send back in response.
UC-220204: Perform IKS request

Use Case ID UC-220204 [SC2, SC4]
35 / 218
Description The IKS can send requests to the CMS to get additional information from the CMS that is needed for a specific service processing, e.g. load data from the CMS's content repository. Parent none Includes none Scope Request information of CMS Actor(s) CMS Goal Perform the request from the IKS. Trigger An IKS request.
UC-220205: Perform IKS storage request

Use Case ID UC-220205 [SC4] Description A special request to the CMS is the request to store data that comes from the IKS. This can be used to store semantically enriched content inside the CMS's content repository. Parent UC-220204 Includes none Scope Request information of CMS Actor(s) CMS Goal Store the data from the request inside the CMS. Trigger An IKS storage request.
UC-220206: Send feedback

Use Case ID UC-220206 [SC5] Description The CMS can send feedback information to the IKS that tells a specific IKS service how much the user liked the results regarding a specific request. Feedback can be used by the IKS service to tune their semantic calculations. Parent UC-220201 Includes none Scope Feedback Actor(s) CMS
36 / 218
Goal Send feedback information to an IKS service. Trigger A feedback request from the CMS.
UC-220207: Receive request

Use Case ID UC-220207 [SC1, SC5] Description The external IKS interfaces should be implemented using standard technologies, e.g. a RESTful HTTP interface, that use the request-response paradigm for synchronous communication. The IKS may also support asynchronous communication for cases where the request triggers some long running process. The IKS receives requests and routes them to the specific service and invokes that service with the input parameters from the request. This means that each IKS service is reachable through the external interface, e.g. by using RESTful service request. To ensure a high availability of the external interface the IKS should use a request queue and enqueue each request in a first step to be able to receive further requests. The external interface must not be blocked by any running request handling. Parent none Includes UC-220227, UC-220211 Extensions policies: UC-221103 Scope Request handling. Actor(s) IKS Goal Receive the request and invoke the specific IKS service. Trigger A service request was received.
37 / 218
Action
Figure 8.10 Activity diagram for use case "Receive request"
UC-220227: Manage request by identifier

Use Case ID UC-220227 [SC1] Description Each request may contain a CMS specific request identifier that uniquely identifies this request inside the CMS. This CMS specific request identifier must not be changed by the IKS and must be sent back to the CMS in the response. The IKS must manage all incoming requests using its own request identifier that makes the request uniquely identifiable inside the IKS. The information can be used for functions like logging, auditing, journalizing, and in request responses. The IKS request identifier must also be sent back to the CMS in response. Parent none Included by UC-220207 Scope Request handling.
38 / 218
Actor(s) IKS Goal All incoming requests must be managed using a unique request identifier. Trigger A service request was received and must be managed. Preconditions 1. The IKS is ready to receive service requests. Minimal Postconditions 1. The IKS sends a response back to the CMS. Success Postconditions 1. 2. 3. 4. The IKS assigns a unique request identifier to the received request. The unique request identifier is used within the IKS to identify the request. The response contains the unique request identifier. The response contains the unmodified CMS specific request identifier which was received as part of the request from the CMS.
UC-220208: Receive feedback

Use Case ID UC-220208 [SC5] Description A special kind of request is the feedback request that is sent by a CMS. The feedback request gives an IKS service information about how much the user liked the results regarding a specific service request. The IKS receives the feedback and routes it to the specific IKS service. Parent UC-220207 Includes UC-220210 Scope The IKS request handling. Actor(s) IKS Goal Receive the request and send the feedback to the specific IKS service. Trigger A feedback request was received.
UC-220209: Route to service

Use Case ID UC-220209 [SC1] Description A received IKS request is routed to the specific IKS service which handles the request and calculates the result.
39 / 218
Parent none Included by UC-220211 Scope IKS service invocation Actor(s) IKS Goal Identify the specific IKS service and route the request to that service. Trigger An IKS service request was received. (UC-220201) Preconditions 1. The IKS is ready to receive service requests. 2. The target IKS service must be specified within the request. Minimal Postconditions 1. The IKS sends a response back to the CMS. Success Postconditions 1. The IKS routes the request to the specified target service. 2. The target service is invoked and handles the request and calculates a response. 3. The response is sent back to the CMS.
UC-220210: Route feedback to service

Use Case ID UC-220210 [SC5] Description A received IKS feedback request is routed to the specific IKS service. Parent none Included by UC-220208 Scope The IKS feedback handling Actor(s) IKS Goal Identify the specific IKS service and route the feedback request to that service. Trigger An IKS feedback request was received. (UC-220206)
UC-220211: Invoke service

Use Case ID UC-220211 [SC1, SC2, SC3] Description After receiving a request and routing it to the specific service the service is invoked using the parameters from the request. By invoking a service the ser-
40 / 218
vice starts its execution. Parent none Included by UC-220208 Includes UC-220209, UC-220212, UC-220215 Scope IKS service invocation. Actor(s) IKS Goal Invoke an IKS service to start the service execution. Trigger A service request is routed to a service and the invoked. Preconditions 1. The target IKS service is ready for invocation and not blocked by any operation. Minimal Postconditions 1. The target IKS service is invoked and some result returns. Success Postconditions 1. The target service is successfully executed and returns the results.
UC-220212: Send response

Use Case ID UC-220212 [SC1] Description When the service execution has ended the IKS sends the response that was generated by the service back to the CMS. The response sending is part of the service invocation. Parent none Included by UC-220211 Scope IKS service invocation Actor(s) IKS Goal Send the response back to the CMS. Trigger The service invocation has ended and returned a result.
UC-220213: Execute
Use Case ID UC-220213 [SC3, SC4, SC6]
41 / 218
Description When a service is invoked by the IKS it starts its execution. The execution of an IKS service can have several extensions depending on the required use cases that must be performed during the execution. Each service is able to call back the CMS, load additional content, store data, and must be aware of existing execution time constraints. Parent none Extensions CMS callback: UC-220215 ; load content: UC-220216 ; time constraint: UC220214; store: UC-220217; policies: UC-221104 Scope Service execution. Actor(s) IKS Service Goal Execute the service and compute a result. Trigger The service was invoked.
42 / 218
Action
Figure 8.11 Activity diagram for use case "Execute"
UC-220214: Cancel execution when time is up

Use Case ID UC-220214 [SC6] Description If the service was invoked with a maximum execution time constraint then the service has to cancel its execution when time is up and execution has not finished yet regardless the calculated results so far. The execution must end after the maximum execution time and the results must be discarded when the execution did not end in this period of time. Parent none Extends UC-220213
43 / 218
Scope Service execution Actor(s) IKS Service Goal Cancel the service execution when time is up. Trigger The service was invoked with a maximum execution time.
UC-220228: Send CMS request

Use Case ID UC-220228 [SC2, SC4] Description When an IKS service needs to interact with the CMS during service execution it can send requests back to the CMS (callback). The request must contain the CMS request identifier that was sent by the CMS as part of the IKS service request. This information may be needed by the CMS to determine the context of the request. Parent none Includes none Scope Service execution Actor(s) IKS Service Goal Send a request to the CMS. Trigger An IKS service needs to interact with the CMS. Preconditions 1. The CMS is ready to receive requests. 2. The IKS uses the CMS specific request identifier that was received as part of the original request from the CMS within the new request to the CMS. Minimal Postconditions 1. The CMS sends a response back to the IKS. Success Postconditions 1. The CMS returns valid results.
UC-220215: Request information from CMS

Use Case ID UC-220215 [SC2] Description When an IKS service needs additional information from the CMS he can send a request to the CMS. This is useful for loading additional content that could
44 / 218
not be included inside the original IKS service request. Parent UC-220228 Extends UC-220213 (CMS callback) Scope Service execution Actor(s) IKS Service Goal Request and get additional information from the CMS, e.g. from the content repository. Trigger An IKS service needs additional information and requests the CMS.
UC-220216: Load content from URIs

Use Case ID UC-220216 [SC3] Description When an IKS service needs specific content as input this content is not directly included in the IKS service request. The service request just transport pointers (URIs) to the content and the IKS service is able to load that content by using the URIs during the service execution. Parent none Extends UC-220213 Scope Service execution Actor(s) IKS Service Goal Load content from URIs that are delivered as part of the IKS service request. Trigger The IKS service request contains URIs to content.
UC-220217: Store data

Use Case ID UC-220217 [SC4] Description Storing data is the abstract use case of an IKS service that wants to store data in some system. Extensions linking: UC-220623 Extends UC-220213 Scope Service execution Actor(s) IKS Service
45 / 218
Goal Store data in any system during service execution. Trigger IKS service needs to store data.
UC-220218: Store data in IKS

Use Case ID UC-220218 [SC4] Description An IKS service can store data using the persistence layer of the IKS. The data is stored inside the IKS. Parent UC-220217 Includes none Scope Service execution Actor(s) IKS Service Goal Data is stored inside the IKS. Trigger IKS service needs to store data inside the IKS.
UC-220219: Store data in CMS

Use Case ID UC-220219 [SC4] Description An IKS service can store data inside the CMS by sending a storage request to the CMS. The data is stored inside the CMS, e.g. its content repository. Parent UC-220217, UC-220228 Includes none Scope Service execution Actor(s) IKS Service Goal Data is stored inside the CMS by sending a storage request to the CMS from the IKS service. Trigger IKS service needs to store data inside the CMS.
UC-220220: Read IKS service specification

Use Case ID UC-220220 [SC8] Description This use case ensures that there exists an IKS service specification that must be read by an IKS customizer in order to customize the IKS by implementing a new IKS semantic service. The presents and knowledge of the IKS service
46 / 218
specification is mandatory. Parent none Included by UC-220221 Scope IKS customization Actor(s) IKS Customizer Goal Ensure that an IKS customizer is aware of the IKS service specification. Trigger An IKS customizer wants to create a new IKS service.
UC-220221: Create service

Use Case ID UC-220221 [SC7, SC8, SC9] Description A main IKS customization aspect is that an IKS customizer can create new semantic services and include it into the existing IKS. This is a plug-in feature for IKS services offered by the IKS itself. Extensions reuse: UC-220223 Includes UC-220220, UC-220222, Scope IKS customization Actor(s) IKS Customizer Goal Implement an new IKS service. Trigger An IKS customizer wants to create a new semantic service for the IKS.
47 / 218
Action
Figure 8.12 Activity diagram for use case "Create service"
UC-220222: Implement and document service extension points

Use Case ID UC-220222 [SC9] Description Each IKS service can offer its own extension points. This feature allows the customization of existing IKS services by using the service's extension points. These extension points are defined and document during the creation process of an IKS service. Parent none Included by UC-220221 Scope IKS service creation Actor(s) IKS Customizer Goal Implement and document the extension points of an IKS service. Trigger A new IKS service needs to be customizable.
UC-220223: Reuse existing service

Use Case ID UC-220223 [SC7]
48 / 218
Description An IKS customizer can reuse existing IKS services when creating a new IKS service. This use case is about the orchestration of existing IKS services to create new services. The new service can be just a combination of existing services or a mix of service reuse and implementation of new features. Extends UC-220221 (reuse) Included by UC-220706 Scope IKS service creation Actor(s) IKS Customizer Goal Reuse existing IKS services when creating a new service. Trigger A new IKS service want to reuse an existing service.
UC-220224: Plug service in IKS

Use Case ID UC-220224 [SC8] Description After the creation of a new IKS service the new service must be plugged in the IKS to be used. A binding between IKS and plug-ins makes the plug -ins available inside the IKS. For this the IKS needs a binding mechanism for services and the IKS services need to be aware of the mechanism to be compatible with the IKS. Parent none Inherited by UC-007008 Scope IKS service creation Actor(s) IKS Customizer Goal Make a new service available inside the IKS. Trigger A new service shall be used inside the IKS.
UC-220225: Create service extension

Use Case ID UC-220225 [SC9] Description The IKS can be customized by new IKS services. Each IKS service can be customized using the service's extension points. To use an extension point a service customizer create a new service extension that fits into that extension point. Parent none Inherited by UC-007002
49 / 218
Scope Service customization Actor(s) Service Customizer Goal Create an extension for a service extension point. Trigger A service customizer wants to customize an existing IKS service and implements and extension.
8.1.2 Resulting Requirements Description

Functional Requirements
ID Requirement UC-Ref UC-220224 UC-220213
FR-220201 The IKS shall support a plug-in mechanism for semantic services. FR-220202 A service execution shall be stoppable at any point of execution.
FR-220203 The IKS shall be able to handle feedback information from external systems. UC-220208 FR-220204 The IKS shall manage all requests by using unique request identifiers. FR-220205 The IKS shall route each request to a service and invoke that service to handle the request. FR-220206 The IKS shall take the results from a service execution and send it back to the enquirer. FR-220207 The IKS shall be able to load content from URIs. FR-220208 The IKS shall be able to store data inside the IKS UC-220227 UC-220209 UC-220212 UC-220216 UC-220218
FR-220209 The IKS shall be able to store data in external systems, e.g. a CMS content UC-220219 repository.
Data requirements
ID Requirement UC-Ref UC-220202 UC-220203 UC-220206
DR-220201 IKS shall be able to handle service requests that contain lists of URIs. DR-220202 IKS shall be able to handle service requests that contain execution time constraints. DR-220203 The IKS shall define the format and semantics for feedback information.
Integration requirements
ID Requirement UC-Ref
INR-220201 The IKS shall provide external interfaces to become usable by other systems UC-220207 like a CMS.
50 / 218
INR-220202 The IKS shall be extendible by custom services. INR-220203 The external interfaces should use standardized technologies. INR-220203 Each IKS semantic service shall be reachable by an external interface. INR-220204 The IKS semantic services shall be available as RESTful services. INR-220204 The IKS shall be able to request information from other external systems (e.g. a CMS, the WWW) INR-220205 The IKS shall be able to access the data repositories of external CMS. INR-220206 Each IKS service shall be customizable using service extension points. INR-220207 Custom services shall be able to reuse existing services.
UC-220221 UC-220207 UC-220207 UC-220201 UC-220218 UC-220218 UC-220225 UC-220223
Interface requirements
ID IR-220201 IR-220202 IR-220203 Requirement The external IKS interfaces shall support sychronous communication using the request/response paradigm. The external IKS requests/responses shall use a standard technology (e.g. SOAP over HTTP) The external IKS interface may support asynchronous communication, e.g. for long running processes. UC-Ref UC-220207 UC-220207 UC-220207
Non functional requirements

ID NFR220201 NFR220202 NFR220203 NFR220204 NFR220205 NFR220206 NFR220207 Requirement The IKS shall consist of semantic services. IKS semantic services shall be replaceable. UC-Ref UC-220211 UC-220224
When an IKS service is executed with time constraints and the time is up, UC-220213 the service execution has to stop immediately and all bound resources have to be released. The IKS shall provide a service specification that defines formats and struc- UC-220220 tures of IKS services. Each IKS service must be conform to the IKS service specification. UC-220220
The service extension points must be described in a format that is defined by UC-220220 the IKS service specification. IKS services shall be reusable. UC-220223
51 / 218
NFR220208
The IKS shall always be able to receive new requests, i.e. the external inter- UC-220207 face shall not be blocked by any running request processing to allow high availability.
8.2 Common vocabulary (HLR-2201)

HLR ID Name Description HLR-2201 Common vocabulary In order to be able to support semantic services on top of the CMS, there needs to be support for common vocabularies, which will constitute a common understanding for users by relating a content item with clear and precise vocabulary items. These vocabularies can be external ontologies, taxonomies, thesauri, and they can provide horizontal or domain knowledge. Therefore, services for engineering of such vocabularies within IKS are a key requirement. These vocabularies will be utilized in IKS services for providing semantic capabilities. Cross cutting Horizontal
Classification
Related re- HLR-2203: Semantic lifting & tagging quirements HLR-2206: Links/relations among content items Statements

Agree on a set of categories and relations, attributes as the default set Help in finding the good vocabularies, Vocabulary Discovery for CMS Schema Dynamic vocabularies, ontologies SWAN Ontology Schema importing
8.2.1 Scenarios
Scenario 1:
While users are tagging a content item or annotating it, instead of free-text tagging, user may prefer to tag the item with related vocabulary terms from a controlled vocabulary. To find out a related term from a vocabulary, a user needs to have a visualization mechanisms which utilize hierarchies embedded in the vocabulary in order to navigate over it. Therefore, a content creator/consumer may request controlled vocabularies from IKS service and visualize it. For example, if the vocabulary terms are connected through parent-child relations, a ideal visualization technique may be using a tree view format, which let users easily navigate over the tree and see further details ; i.e. vocabulary terms representing finer concepts- or hide unrelated vocabulary items by collapsing and expanding tree nodes. User shall see the list of available vocabularies, and examine the details of the vocabularies.
52 / 218
Scenario 2:
One of the issues in the free-text tagging is finding the right and the most common word to annotate a content item in order to make it discoverable by other users through a keywordbased search mechanism. For this purpose, in addition to navigating vocabulary items, user can search for a vocabulary item, which describes the content in order to find out a related term from a vocabulary. Content creator sends the search query words to IKS Service and IKS service may return a result set which provides possible tags meeting the requirements of content creator, and hence, allows users to use existing ontologies.
Scenario 3:
In order to be able to support semantic services IKS has to rely on and manage a vocabulary which will provide a common understanding on the context and content of items residing in CMS systems. Vocabularies need to be managed via IKS services. Admin will be able to visualize the vocabulary (see Scenario 1) and edit each one if the user thinks that the provided vocabulary is not comprehensive. An admin can add new vocabularies, either by creating a new vocabulary from scratch by entering vocabulary name, vocabulary definition and vocabulary terms or by importing and reusing a vocabulary that is available on the Web. Later the imported vocabulary elements can be associated with the content items. Furthermore, admin can delete the vocabulary altogether, thereby also deleting all its terms (but not the nodes to which they were assigned). Furthermore, the admin needs to update the vocabulary terms and its related fields if she thinks there is any inconsistency in the vocabulary .
Scenario 4:
The vocabulary alignment brings new opportunities for making knowledge accessible by integrating collections at the semantic level and brings better linkage between different semantic data silos. When an admin adds or replaces a vocabulary in the CMS, a vocabulary alignment process needs to be realized in order to resolve conceptual heterogeneity issues and correspondences. After uploading a vocabulary, the vocabulary alignment process finds semantic correspondences between vocabulary elements either automatically or by trigger of the admin, and the possible matchings are presented to the users. And it stores the matching relations for the approved results in a semantic fashion.
53 / 218
Figure 8.13 Use case diagram for HLR-2201

UC-220101: Semantically Navigate Vocabulary [SC1, SC3] UC-220102: Search Vocabulary Item [SC2] UC-220103: Manage Vocabulary [SC3] UC-220104: Add Vocabulary Item [SC3] UC-220105: Remove Vocabulary Item [SC3] UC-220106: Edit Vocabulary Item [SC3] UC-220107: Import External Vocabulary [SC3] UC-220108: Align Vocabularies [SC4]
UC-220101: Semantically Navigate Vocabulary

Use Case ID UC-220101: Semantically Navigate Vocabulary Description An IKS Content Creator or Consumer navigates through and views the available vocabulary element for several operations such as tagging or search. The vocabulary elements come from the selected vocabularies of interest that have
54 / 218
been imported to/created in IKS. The model of the vocabulary needs to include a hierarchical structure to expose the related navigation services. Furthermore, navigation system can utilize semantic linkages between content items and provide a semantic grouping or hierarchical structure based on these semantic relations. Parent Scope Actor(s) Goal Trigger Support for vocabulary navigation through the IKS stack. Creator The goal is to navigate through and view the available constructs inside the vocabulary to proceed to other services such as tagging and search. A Content Creator requests a navigation service from the IKS.
Preconditions 1. A set of common vocabularies such as common ontologies should exist and be ready for processing inside the IKS. 2. The model of the vocabulary should expose either a semantic or structural hierarchical organization regarding the navigational issues. 3. The IKS should provide the necessary implementations and services for the navigation of the common vocabulary, such as discovering ontologies. 4. The user of the IKS should trigger the required events to activate the corresponding services of the IKS. Minimal Postconditions 1. Upon any internal error, the user is informed about the error. Success Postconditions 1. A Content Creator, or Content Consumer successfully visualizes or navigates through the available constructs of the vocabulary.
Main Flow 1. An actor asks for the vocabulary navigation service by using the appropriate RESTful interfaces provided by the IKS. 2. The IKS presents the vocabulary to its user with additional functionalities to allow the navigation through the vocabulary elements. 3. The actor uses one of the navigation features to select a vocabulary element 4. The actor views the vocabulary elements. Extensions
none 1. An actor asks for the vocabulary navigation service by using the appropriate commands provided by the IKS. 1. Vocabulary not found
Exceptions
55 / 218
2. The actor uses one of the navigation features to select a vocabulary element 1. Vocabulary Element not found Open Issues 1. The model of the vocabulary may provide other structural mechanisms along with the hierarchical nature of the ontological vocabularies. Action
Figure 8.14 Activity diagram for use case UC-220101
UC-220102: Search Vocabulary Item

Use Case ID UC-220102: Search Vocabulary Item Description Apart from the navigation services provided by the IKS, the user also wants to search through the constructs inside the vocabulary to find the element that he/she looks for. The user makes use of the related services of the IKS to find the element or similar ones residing in the vocabulary. Parent Scope Actor(s) Goal Trigger Search mechanism within a vocabulary is in the scope of IKS. CMS content creator/consumer The goal is to find the element in the vocabulary of the IKS. The actor requests a search service through the available constructs of the vocabulary from the IKS.
56 / 218
Preconditions 1. A set of vocabularies such as common ontologies should exist and be ready for processing through IKS Services. 2. The IKS should provide the necessary implementations and services for the search inside the common vocabulary. (i.e. text based search of ontology elements) 3. The IKS user should trigger the required events to activate the corresponding services of the IKS Minimal Postconditions 1. The user is informed about the result of the search operation. Upon any internal error, the user is informed about the error. Success Postconditions 1. The IKS user successfully performs query on the vocabulary elements. 2. The user finds the vocabulary element(s) or gets informed about the absence of the searched element. Main Flow 1. An actor asks for the vocabulary search service by using the appropriate RESTful interfaces provided by the IKS. 2. The IKS gets the required inputs from the user and perform the query accordingly. 3. The IKS retuns the search results to the CMS that will be presented to the actors. Extensions Exceptions 1. The IKS gets the required inputs from the actor and perform the query accordingly. 1. Invalid input format 2. The IKS returns the search results to the CMS that will be presented to the users. 1. No search result is available. Open Issues 1. The search operation does not necessarily have to be text based. Some other mechanisms may be adopted for the search inside the vocabulary.
57 / 218
Action
UC-220103: Manage Vocabulary

Use Case ID UC-220103: Manage Vocabulary Description According to the domain specific services of the IKS, and due to the changing nature of the domain model information; the Admin needs mechanisms to manipulate the vocabulary of the system. These administrative operations include editing, removing and adding vocabulary elements. Furthermore, to enable refinements on the vocabulary model for specific domains, the vocabulary exposes a hierarchical structure. Parent Scope Actor(s) Goal Trigger The administration of the vocabulary or vocabularies within the IKS is in the scope of whole system. Admin The goal is to have access to the related administrative services of the IKS and process the requested manipulations on the vocabulary. The admin requests administrative operations on the vocabulary and invokes the related services through RESTful interfaces.
Preconditions 1. A set of vocabularies such as common ontologies should exist and be ready for administrative manipulations inside the IKS 2. The IKS exposes the related administration services on the vocabulary. 3. An admin invokes the vocabulary administration services exposed by the IKS.
58 / 218
Minimal Postconditions 1. For every administrative operation, the admin is informed upon any internal error occurs which prevents the execution of the related operation. Success Postconditions 1. The actor successfully manipulates the IKS vocabulary. Main Flow 1. An admin asks for the administrative services from the IKS by giving the required parameter values by the service in question through RESTful interfaces. 2. The IKS service operates on the vocabulary to reflect the intended manipulation. 3. The IKS informs the actor about the result of the invoked service. Extensions Exceptions 1. An admin asks for the administrative services from the IKS by giving the required parameter values by the service in question. 1. Invalid input parameter 2. The IKS service operates on the vocabulary to reflect the intended manipulation. 1. The IKS Service unavailable Open Issues Action
59 / 218
UC-220104: Add Vocabulary Element

Use Case ID UC-220104: Add Vocabulary Element Description Through a service inside the vocabulary administration, an admin wants to add new elements, such as ontology classes or individuals or properties, to the vocabulary of the system. Parent Scope Actor(s) Goal Trigger UC-220103: Manage Vocabulary Since the addition of a new element affects the vocabulary used throughout the IKS, it is in the scope of the whole IKS. Admin The goal is to insert a new element to the existing vocabulary. An actor invokes the related service of the IKS to add a new element to the vocabulary with the required parameter(s) through RESTful interfaces..
Preconditions 1. The IKS includes a vocabulary. 2. The IKS provides service(s) to insert new elements to the vocabulary. 3. The admin provides the required input values to the related service(s) of the IKS. Minimal Postconditions 1. The admin is informed upon any internal error occurs which prevents the insertion of the new element to the vocabulary. Success Postconditions 1. The new element is successfully created inside the vocabulary. Main Flow 1. An actor invokes the service(s) of the IKS to create a new element inside the vocabulary with the required input parameter values through RESTful interfaces. 2. The add service of IKS runs and creates the new element. 3. The admin is informed about the result of the add operation. Extensions Exceptions 1. The admin invokes the service(s) of the IKS to create a new element inside the vocabulary with the required input parameter values through RESTful interfaces. 1. Invalid input parameter 2. The add service of the IKS runs and creates the new element. 1. The add service unavailable
60 / 218
Open Issues Action See Action section of UC-220103 Manage Vocabulary
UC-220105: Remove Vocabulary Element

Use Case ID UC-220105: Remove Vocabulary Element Description Through a service inside the vocabulary administration, the admin wants to remove an element or elements, such as ontology classes or individuals or properties, from the vocabulary of the system. Parent Scope Actor(s) Goal Trigger UC-220103: Manage Vocabulary Since removal of some elements affects the vocabulary used throughout the IKS, it is in the scope of the whole IKS. Admin The goal is to remove an existing element or elements from the vocabulary. The admin invokes the related service of the IKS to remove an element(s) from the vocabulary with the required parameter(s) through RESTful interfaces.
Preconditions 1. The IKS provides a vocabulary. 2. The IKS provides service(s) to remove elements from the vocabulary. 3. The admin provides the required input values to the related service(s) of the IKS. Minimal Postconditions 1. The admin is informed upon any internal error occurs which prevents the removal of the element(s) from the vocabulary. Success Postconditions 1. The element is successfully removed from the vocabulary. Main Flow 1. The admin invokes the service(s) of the IKS to remove an existing element or elements from the vocabulary with the required input parameter values. 2. The remove service of the IKS runs and removes the element(s). 3. The admin is informed about the result of the remove operation. Extensions Exceptions 1. The admin invokes the service(s) of the IKS to remove an existing element or elements from the vocabulary with the required input parameter values.
61 / 218
1. Invalid input parameter 2. The remove service of the IKS runs and removes the element(s). 1. The remove service unavailable Open Issues Action See Action section of UC-220103 Manage Vocabulary
UC-220106: Edit Vocabulary Item

Use Case ID UC-220106: Edit Vocabulary Element Description Through a service inside the vocabulary administration, the admin wants to edit an element, such as ontology classes or individuals or properties, existing in the vocabulary of the system. Parent Scope Actor(s) Goal Trigger UC-220103: Manage Vocabulary Since editing of some elements affects the vocabulary used throughout the IKS, it is in the scope of the whole IKS. Admin. The goal is to edit an existing element in the vocabulary. The admin invokes the related service of the IKS to edit an element in the vocabulary with the required parameter(s).
Preconditions 1. The IKS provides a vocabulary. 2. The IKS provides service(s) to edit elements inside the vocabulary. 3. The admin provides the required input values to the related service(s) of the IKS. Minimal Postconditions 1. The admin is informed upon any internal error occurs which prevents the edition of the element(s). Success Postconditions 1. The element is successfully edited. Main Flow 1. The admin invokes the service(s) of the IKS through RESTful interfaces to edit an existing element with the required input parameter values. 2. The editing service of the IKS runs and performs the edition on the element. 3. The admin is informed about the result of the editing operation.
62 / 218
Extensions Exceptions 1. The admin invokes the service(s) of the IKS through RESTful interfaces to edit an existing element or elements from the vocabulary with the required input parameter values. 1. Invalid input parameter 2. The editing service of the IKS runs and performs the edition on the element. 1. The editing service unavailable Open Issues Action See Action section of UC-220103 Manage Vocabulary
UC-220107: Import External Vocabulary

Use Case ID UC-220107: Import External Vocabulary Description The admin wants to make use of the ontologies, tagging schemes or taxonomies defined outside the IKS. The IKS provides mechanisms to import externally defined vocabularies. The externally defined mechanism should structurally expose a standard such as OWL ontologies or SKOS. Parent Scope UC-220103: Manage Vocabulary The imported vocabulary is used standalone as another vocabulary within the IKS or aligned/merged with the existing one(s). Therefore the import operation affects whole system through the change in vocabulary of the system. admin The goal is to import an externally defined vocabulary into the IKS. The admin calls the import service or services of the system by giving the necessary input parameters.
Actor(s) Goal Trigger
Preconditions 1. The externally defined vocabulary structurally exposes a well-defined model such as OWL ontology model or SKOS. 2. The IKS has necessary services to process the external vocabulary. 3. The admin provides the necessary input values to process the external vocabulary. Minimal Postconditions 1. The admin is informed upon any internal error occurs which prevents import of the external vocabulary. Success Postconditions 1. The external vocabulary is successfully imported to the IKS.
63 / 218
Main Flow 1. The admin provides the input values to proceed with the processing of the external vocabulary. 2. The IKS processes the external vocabulary. 3. The IKS creates the necessary data structures internally to finish the import of the processed external vocabulary. Extensions Exceptions 1. The admin provides the input values to proceed with the processing of the external vocabulary. 1. Invalid input parameter 2. The IKS processes the external vocabulary. 1. The processing approach of external vocabulary is unavailable. Open Issues 1. The structural model of the external vocabulary may be determined through standard models such as OWL ontologies, SKOS or standardized taxonomy schemes. Action
UC-220108: Align Vocabularies

Use Case ID UC-220108: Vocabulary Alignment Description With the import services of external vocabularies, the IKS may include several different vocabularies internally. The admin wants to merge some or all of the
64 / 218
vocabularies to have a single vocabulary to be used throughout the system. This will increase the reasoning capabilities. Parent Scope Since the alignment of the internal vocabularies change the way of usage of the vocabulary elements which affects the content items throughout the system, such as in tagging or semantic annotations, the scope is the whole IKS. Admin. The goal is to align, merge a number of vocabularies existing inside the IKS to create a common, single vocabulary to be used throughout the system. The admin invokes the relevant service(s) of the IKS to initiate the alignment process.
Preconditions 1. The IKS includes more than one different vocabularies imported previously. 2. The admin initiates the merging process by invoking the relevant service(s) of IKS. Minimal Postconditions 1. The admin is informed upon any internal error occurs which prevents alignment of the vocabularies in question. Success Postconditions 1. The intended vocabularies are aligned into a single, common vocabulary. Main Flow 1. The admin selects the vocabularies to be merged. 2. The IKS processes the alignment operation on the selected vocabularies. 3. The IKS suggests particular alignment options according to the implementation model of the alignment/merge service(s). Extensions Exceptions 1. The IKS processes the alignment operation on the selected vocabularies. 1. The vocabularies to be aligned are not available 2. IKS Vocabulary alignment service is unavailable Open Issues 1. The alignment process may be totally manual, semi-automatic by presenting suggestions to the admin at the time of the processing, or automatic at all. 2. The choice of the implementation mode affects the overall flow of the use-case scenario.
65 / 218
Action

ID Requirement UC-Ref UC-220101 UC-220102 UC-220103 UC-220104 UC-220105 UC-220106 UC-220107 UC-220108 UC-220108
FR-220101 The Vocabulary shall be navigable. FR-220102 The Vocabulary shall be querable. FR-220103 IKS shall expose related administration services on vocabulary.
FR-220104 IKS shall process/parse the uploaded vocabularies. FR-220105 IKS shall provide a vocabulary alignment algorithm. FR-220106 IKS shall suggest a number of possible alignment options.
Data requirements
66 / 218
ID
Requirement
UC-Ref UC-220101 UC-220103 UC-220104 UC-220105 UC-220106
DR-220101 Vocabulary shall be in one of standard format which can be processed by IKS services
DR-220102 The externally defined vocabulary structurally exposes a well-defined model UC-220103 such as OWL ontology model or SKOS. UC-220104 UC-220105 UC-220106 UC-220107
INR-220101 Vocabulary shall be in an accepted standard format. INR-220102 Vocabulary instances shall be convertible to a format which can be processed via reasoners.
ID IR-220101 IR-220102 IR-220103 Requirement An interface shall be implemented for presenting list of Vocabularies UC-Ref UC-220101
An interface shall be implemented for presenting Vocabularies and its struc- UC-220101 tural organization UC-220103 An interface shall be implemented for presenting/editing Vocabulary Items UC-220103 UC-220104 UC-220105 UC-220106 UC-220102 UC-220107
IR-220104 IR-220105 IR-220106
An interface shall be implemented for query construction. An interface shall be implemented for Vocabulary import.
An interface for possible vocabulary alignment options shall be implemented. UC-220108

ID Requirement UC-Ref UC-220101 UC-220103 UC-220104 UC-220105 UC-220106 UC-220102
NFR-220101 Vocabularies shall always be accessible.
NFR-220102 Vocabulary search shall have a reasonable response time.
67 / 218
ID
Requirement
UC-Ref UC-220102 UC-220102
NFR-220103 Query construction interface shall hide technical details from non-expert user. NFR-220104 Vocabulary search shall have high precision and recall rate.
NFR-220105 After vocabulary administration the IKS knowledge store shall be kept in a UC-220103 consistent state by IKS services. UC-220104 UC-220105 UC-220106 NFR-220106 Vocabulary Alignment Algorithm shall provide accurate results. UC-220108
8.3 Semantic lifting & tagging (HLR-2203)

HLR ID HLR-2203 Name Semantic lifting & tagging Description IKS stack should provide services to enable semantic tagging on the content items with the semantic technologies such as ontological classes, RDF properties, microformats etc... IKS stack attaches importance to providing horizontal services to extract semantics from structured and unstructured data automatically or semi-automatically, make suggestions about the annotations and to navigate on the content items in a semantic fashion etc... Classification

Non cross cutting Horizontal HLR-2201: Common vocabulary Semantic tagging Semantic navigation for both consumer and author (not only hierarchical): A semantic navigation mechanism through the content items. Navigating through the subsumption or object relational properties of the content items may constitute an example for this requirement. Automatic generation of micro-formats Help in-editor suggestion of tags, relations between content items, suggest related content inside the CR or from outside world such as web Semantically enhanced rich text editor, add a person Change the presentation model based on semantic data Legacy data, how to semanticize them? Tagging, different for each person, rules for personalized tagging Adding semantics: editor generated consumer participation or automatic extraction? A particular ontology should be suggested in the tagging process of the content items Automatic categorization, similarity search, similarity detection
68 / 218
Visualization of the annotations, as a graph... Semantic history of navigation Extract RDF statements from XML or HTML document Providing API for extracting ontology from unstructured data
Scenario 1: In addition to the meta-data, which are authored by the users, a user can wait for the system to automatically extract some meta-data for the added content item. The content itself carries embedded information which can be used to tag the content item for publishing, discovery purposes. IKS will provide a framework where automatic metadata extraction tools can be plugged into the system, which are capable of analyzing the content item and digging out data about the content to annotate it in order to enhance automated processing. The tool may use statistical keyword based approaches, NLP techniques or image analysis algorithms for automatic meta-data extraction. Furthermore, the accuracy of IKS Services cannot be assumed to be 100% precise, so every findings of IKS service will need the approval of users before committing the action. For example, when a user adds a new article on an earthquake to the content repository, if a user requests IKS semantic services via sending the URL of the content item to IKS Services, IKS services can extract some keywords from the article such its place, its magnitude or frequency etc. Such metadata can be suggested to CMS users as additional metadata. As a result of this metadata extraction relevant ontologies, taxonomies can also be presented to the user, so that users can enrich the content by relating concepts from these ontologies with the data.. In summary, content creators can send pieces of content to the IKS "entity extractor", and it returns suggested entities, in an IKS-specified structured format, preferably in a standard and simple format, such as microformats if applicable. Scenario 2: Automatic entity extractor can also be used for helping the user while s/he is editing the content, a semantically enriched rich text editor can communicate with the IKS services in case of user's trigger and suggest to tag the content pieces with the extracted entities. For example, when s/he is writing "London", the "city" entity can be suggested, alternatively, the user enabled to manually tag content through the tools provided, and annotated content such as RDFa can be proposed accordingly. Scenario 3: To reason over the content data items and their meta-data, they shall be semantically enriched to be ready to be consumed by reasoners. In other words, thee needs to be mechanisms to exploit the already available implicit semantics in CMSs, by making them explicit through ontologies and reasoners. This would require a pre-configuration to specify which part of the CMS Repository handles the content and which part handles the metadata. After this configuration, while the user is adding new content items (or deleting/updating them), the IKS Services will be informed through RESTful interfaces, in turn, IKS will link the related data identified by URLs with the ontology classes and properties through established ontologies. In other words, the content types and fields shall be defined in terms of classes and properties of an ontology or site vocabulary according to predefined configurations so that semantically enhanced features of IKS can be served by virtue of this semantic lifting. For example, when content creator adds a news article into CMS, he/she may request to semantically annotate this content item via pushing the URLs of related data parts to the IKS Ser-
69 / 218
vice, then IKS Service relate it with the ontology and made it available in an IKS-specified format, preferably in a standard and simple format. For example, service can "decide" that it need to be added to the knowledge base as an instance of an OWL ontology class according to its configuration and may also produce RDFa embedded web of datas, this makes content items available to any semantic web tool such as SPARQL engines, RDF crawlers. Scenario 4: User may request IKS Service to tag the content item which is introduced to content system through URLs. While the user is adding new content items, user can send the URLs of content items to IKS Services, and IKS service can send a possible set of tags that can be assigned to the content item by accessing the content item through provided URLs. The integration of extracted meta-data (See Scenario 1) and semantic tagging (See Scenario 2) can be utilized to assign tags to content items more accurately, that altogether provide semantic search as a future service. Scenario 5: As presented in Scenarios, IKS Services can return a set of possibilities for a request rather than providing only one result. For example, when a user request similar contents for a content item from a CMS, a list of similar content items are presented to the CMS by IKS service. The mechanisms evaluating the requests in IKS Services may be enhanced with the feedbacks of users, hence, the goodness of results of IKS Services can be improved. IKS services will track the feedbacks of users and enhance their approaches by taking these feedbacks into consideration. Scenario 6: User can request navigating between content items according to their semantic grouping or hierarchy by utilizing semantic linkages between content items. For example when user is examining content item, she may request to see related items with the examined content. User needs a semantic navigation mechanism which utilizes semantically constructed relations among content items such as semantic history of navigation, visualization of the annotations as graphs, and navigating through the subsumption or object relational properties of the content items. Comprehensible and semantic navigation structures can be derived from existing structures and hierarchies in organizations within IKS Service. CMS user can interact with IKS services to request possible navigational options by invoking related IKS services by passing the URL of the content item and the related parameters.
70 / 218
Figure 8.19 Use case diagram for HLR-2203

UC-220301: Extract meta-data automatically [SC1, SC2] UC-220302: Tag content item semantically [SC2, SC3, SC4] UC-220303: Annotate Content While Editing [SC2] UC-220304: Navigate over content items [SC6] UC-220305: Show Related Ontologies/Taxonomies [SC2, SC3, SC6] UC-220306: Configure Semantic Tagging [SC2, SC3, SC4] UC-220307: Evaluate Feedback [SC5]
UC-220301: Extract meta-data automatically

Use Case ID UC-220301: Extract meta-data automatically Description Content items are usually stored with associated meta-data. Mostly, this data is created by the CMS user and associated with the content item. However, auto-extraction of the meta-data from the content item itself should be done by processing the content item. Parent Scope The scope of the use case covers the knowledge base and other internal tag/annotation procedures of the IK.
71 / 218
Actor(s) IKS Service. Goal The goal is to extract meta-data from the content automatically with minimum possible human intervention. Trigger The IKS user can request an automatic meta-data extraction operation on a content item. Preconditions 1. The IKS is able to process and extract meta-data from the content items which are in some predefined, certain formats (i.e. MPEG-7) through the IKS Semantic Lifting Components. The IKS is capable of processing meta-data from those formats. 2. The content items within the CMS are represented or accessed through a standard methodology, such as JCR. 3. The content item which will be processed for meta-data extraction should be available in one of the predefined, certain formats and should be accessible through the standard interface exposed by the CMS. Minimal Postconditions 1. The user should be informed result of the meta-data extraction. For some fields which are extracted, the values may not be accurate and the result may require a confirmation or rating from the CMS user as a feedback. Success Postconditions 1. Meta-data is extracted from the content item. 2. The extracted fields and values are passed to other services of the IKS (such as IKS Knowledge Base) for further processing such as semantic tagging/annotation. Main Flow 1. The content item which will be processed is given to the related service of the IKS (such as IKS Semantic Lifting) with the additional required parameter values. 2. The related service processes the content item and extracts meta-data fields and corresponding values. 3. The extracted semantics is presented to IKS Knowledge base to be represented in Repository Model 4. The extracted semantics is presented to IKS Services that are using UC-003001 extracts. Extensions Exceptions 1. The content item which will be processed is given to the related service of the IKS (such as IKS Semantic Lifting) with the additional required parameter values. 1. Semantic Lifting Component is not available 2. The related service processes the content item and extracts meta-data fields and corresponding values. 1. Content Item is not accessible 2. Content Item is not in the right format
72 / 218
3. The extracted semantic is presented to IKS Knowledge Base for semantic tagging 1. IKS Knowledge Base is not available Open Issues 1. Meta-data extraction can be configurable according to the users needs. The service can be provided for each content item that is being inserted into the system or for some specific types of content items. 2. Extracted meta-data can be presented to CMS users as suggestions and the user confirmation can assure the accuracy of the values. Action
UC-220302: Tag content item semantically

Use Case ID UC-220302: Tag content item semantically Description Apart from the classical tagging mechanisms of the CMSs, IKS provides mechanisms to create knowledge base items (i.e. OWL ontology individuals)
73 / 218
from the meta-data associated with the content items. Semantic tagging is the process of adding knowledge about the content items through the vocabulary elements (ontologies, taxonomies, thesauri stored in the IKS system). Parent Scope The scope of the semantic tagging is the knowledge base and the related services of the IKS. Actor(s) IKS Service Goal The goal is to generate the tags from the content items and associate the extracted tags with the items, and represent these annotations semantically in the knowledge base of IKS. Trigger The IKS user initiates the related service(s) of the IKS for semantic tagging. Preconditions 1. The IKS includes a vocabulary whose elements can be used in the tagging process of the content items. 2. The IKS provides the necessary functions and services which enable the tagging of the content items in a semantic way. 3. IKS provides a knowledge base in which the semantic constructs, for example ontological representations of the content items meta-data, are kept. These semantic constructs are the semantic tags for the content items residing inside the CMS. Minimal Postconditions 1. The user is informed about the result of the semantic tagging process whether the operation succeeded or failed. Success Postconditions 1. The IKS knowledge base includes the semantic tags/annotations of the content item in question. Main Flow 1. The user selects the content item to tag and invokes the related service of IKS with passing input parameters through RESTful interfaces. 2. The IKS retrieves configuration and ontologies/vocabularies that will be utilized while explicating the content items and meta-data. 3. IKS semantic tagging service is triggered to create the semantic relationships between the content items and the tags inside the IKS knowledge base. 4. Content items and meta-data are converted to knowledge base items. 5. The IKS returns the available tag constructs to the CMS. Extensions Exceptions 1. The CMS presents the available tag constructs to the user. 1. The vocabulary is not available
74 / 218
2. IKS semantic tagging service is triggered to create the semantic relationships between the content items and the tags inside the IKS knowledge base. 1. IKS semantic tagging service is not available 2. IKS knowledge base is not available Open Issues Action
75 / 218
UC-220303: Annotate Content While Editing

Use Case ID UC-220303: Annotate Content While Editing Description Tagging and annotation of the content items can be done while editing the content with the help of the automatic meta-data extraction and other related services. This can be achieved through a semantic rich text editor. This functionality is similar to in-editor help, which reacts to user inputs and suggest some annotation options such as microformats, OWL ontologies etc. By this way, the content will be enriched semantically while being created under the control of user. Furthermore, the content items can be linked with any item residing in the content repository or in the web through URLs. Parent UC-220301: Extract meta-data automatically, UC-220302 Tag content sematically Scope Annotating contents covers the knowledge base and other internal tag/annotation related parts of the IKS. Actor(s) IKS Service Goal The goal is to annotate the content items while being generated. Trigger The IKS user can annotate an item manually by his/her own trigger. Preconditions 1. Automatic meta-data extraction service(s) should be ready in the IKS. 2. Ontologies/vocabularies shall be available in the Content repository which be used in annotation process. Minimal Postconditions 1. The IKS is ready to annotate the next input data. Success Postconditions 1. The content item is successfully annotated with the related elements which are residing eitherinside the content repository or in the web. Main Flow 1. User creates a content item and invokes the related service of IKS with passing input parameters through RESTful interfaces. 2. The system processes the content item in a reasonable response time and analyzes it to see that if it is related with any ontological classes known by the IKS services. 3. The knowledge base of the system is populated with the annotation instances, which are associated with the content item, RDFa annotations can be proposed to the CMS.
76 / 218
Extensions Exceptions 1. Any relation could not be established with the content item. No annotation or tags can be proposed. Open Issues 1. Annotation service can run as a suggestion service for the CMS users who want to annotate a content item. 2. Apart from the suggestions, user can manually establish relations with the content items and ontology classes. Action
UC-220304: Navigate over content items

Use Case ID UC-220304: Navigate over content items Description Navigation through the content items is provided through hierarchical constructs, mostly. A CMS which is capable of interacting with IKS should provide semantic navigation methodologies other than the hierarchy among the content items to ease the navigation through the content items. See also UC-220436: Browse content.
77 / 218
Parent Scope The scope of the semantic navigation is the knowledge base of the IKS. Actor(s) IKS Service Goal The goal is to provide semantic navigation mechanisms which make use of the relations among the elements of the IKS. Trigger The CMS user invokes the related services of the IKS to start the semantic navigation through the content items. Preconditions 1. The system has a knowledge base. 2. The knowledge base of the IKS is populated with the semantic tags/annotations of the content items residing in CMS system through IKS Services. 3. The CMS implements navigation mechanisms which make use of the interrelations among the elements residing in the vocabulary of the system by making use of IKS Services. Minimal Postconditions 1. The IKS is ready to process the next navigation request Success Postconditions 1. The user successfully navigates through the content items with the help of the semantic constructs and relations. Main Flow 1. The user requests a semantic navigation from the CMS and CMS system interacts with IKS to request possible navigational options by passing the URL of the content item and the related parameters. . 2. The CMS presents the navigation mechanism to the user through the appropriate interface implementations by making use of IKS Services. 3. The user makes use of the provided controls to semantically navigate through content items. Extensions Exceptions 1. The CMS presents the navigation mechanism to the user through the appropriate interface implementations by making use of IKS Services. 1. IKS semantic vocabulary services are not available. 2. The user makes use of the provided controls to semantically navigate through content items. 1. Vocabulary not available
78 / 218
Open Issues Action
UC-220305: Show Related Ontologies/Taxonomies

Use Case ID UC-220305: Show Related Ontologies/Taxonomies Description On top of the automatic content tagging feature, users shall be allowed to select other tagging taxonomy/ontology constructs from the related vocabularies or ontologies in order to annotate content item. Related ontology/taxonomy presentation is provided in the IKS Services through meta-data extraction process. This service will present user the related ontologies/taxonomies and hence user can relate content items with semantic constructs which are not discovered by the automatic content tagging process. Parent Scope The scope of the related ontology/taxonomy presentation is the IKS stack presentation layer. Actor(s) IKS Service Goal The goal is two-fold: (1) to discover ontologies/taxonomies related with content item, (2) to present ontologies/taxonomies to let him/her to annotate to content item. Trigger The CMS user can request a related ontology/taxonomy presentation service on a content item.
79 / 218
Preconditions 1. The system has a knowledge base. 2. IKS Service for extracting meta-data is available. 3. IKS service has some domain ontologies and vocabularies. Minimal Postconditions 1. The IKS is ready to process the next request. Success Postconditions 1. The user successfully visualizes the related vocabulary/ontology. Main Flow 1. The user upload a new content item or initiates tagging process of the content item by invoking IKS Services through RESTful interfaces. 2. The IKS service extracts the meta-data from the content item. 3. The IKS selects the related ontologies and taxonomies. 4. The related ontologies are presented to the user. Extensions Exceptions 1. The IKS selects the related ontologies and taxonomies. 1. IKS service does not find a matching ontology or taxonomy for the content item. Open Issues 1. How related ontologies/taxonomies will be determined is an open issue for implementation plan, it may be similarity matching or include some semantic reasoning facilities.
80 / 218
Action
UC-220306: Configure Semantic Tagging

Use Case ID UC-220306: Configure Semantic Tagging Description The users of a content repository express the semantics they have in mind while defining the nodes and properties among the content items and forming them into a particular hierarchy. However, this valuable semantics is not formally expressed, and hence cannot be used in an automated way to discover meaningful relationships among the content items. So user needs a set of tools that first semi-automatically explicate the content repository semantics. Parent Scope The scope of the semantic tagging configuration is knowledge base Actor(s) Manager. Goal The goal is explicating the content repository semantics semi-automatically. Trigger The CMS manager needs to trigger configuration process.
81 / 218
Preconditions 1. The system has a knowledge base. 2. IKS service has some domain ontologies and vocabularies. Minimal Postconditions 1. The CMS is ready to process the next configuration request. Success Postconditions 1. The user successfully configures the semantic tagging and save the configuration. Main Flow 1. The user initiates configuration process. 2. IKS service presents ontology mapping constructs and queries. 3. User selects the correspondences between content items and the ontology mapping constructs. 4. IKS service automatically creates mapping definitions in XML. 5. By processing these semi-automatically formed mapping definitions, an ontology of the repository content is created by IKS services. Extensions Exceptions 1. The IKS selects the correspondences between content items and the ontology mapping constructs. 1. User does not find a correspondence between content items and the ontology mapping constructs.
82 / 218
Open Issues Action
UC-220307: Evaluate Feedback

Use Case ID UC-220307: Evaluate Feedback Description The results of reasoning process can be improved with the feedbacks which are either explicitly or implicitly taken by users. The recommendation algorithms shall utilize the feedbacks of user and present more precise results gradually. See also UC-220208: Receive feedback. Parent Scope The scope of the use case covers the knowledge base and IKS stack. Actor(s) IKS Service. Goal The goal is to improve the results reasoning mechanisms and present more tailored results according to user profile. Trigger Whenever users prefer one result to results sets, IKS systems can automatically capture the feedback.
83 / 218
Preconditions 1. The IKS has recommendation algorithms which utilize user feedback. 2. The content items within the CMS are represented or accessed through a standard methodology, such as JCR. 3. IKS services can communicate with the CMS via RESTful interfaces. Minimal Postconditions 1. IKS service can capture the user's feedback. Success Postconditions 1. The feedback of user can improve the results of IKS services, after the feedback, user can access the content items which are tailored according to his/her taste. Main Flow 1. User's selection from a result set is passed to the IKS services. 2. The related service processes the feedback and aligns the algorithms and data model. Extensions Exceptions 1. The feedback which will be processed is given to the related service of the IKS (such as IKS Recommendation engine). 1. The component, which will handle feedback, is not available. 2. User does not want to disclose his/her feedbacks according to his/her consent. Open Issues 1. The way how feedbacks are retrieved from user is an open issue. Either implicit or explicit mechanisms can be deployed.
84 / 218
Action

ID Requirement UC-Ref UC-220301 UC-220301 UC-220302 UC-220301
FR-220301 IKS services shall process unstructured data FR-220302 IKS services shall extract meta-data from raw data FR-220303 IKS services shall annotate the content items with meta-data FR-220304 IKS services shall handle external well-accepted data formats
FR-220305 IKS services let users to navigate over the content items according to se- UC-220304 mantic relations. FR-220306 IKS service shall create the necessary tags, annotations, relations between UC-220302 the vocabulary element instances. FR-220307 IKS service shall generate OWL instances for the content items and their re- UC-220302 lations. FR-220308 IKS service shall provide in-editor help for annotating content items while UC-220303 creating FR-220309 IKS service let user to assign tags for the content item from a vocabu- UC-220302 lary/ontology, which is discovered by the IKS services. FR-220310 IKS service let user configure semantic mapping correspondences between UC-220306 ontology constructs and content items.
85 / 218
Data requirements
DR-220301 The content item shall store in one of the formats that can be processed by UC-220301 IKS. DR-220302 A knowledge base shall be available. UC-220301 UC-220303
DR-220303 Ontological representations of meta-data and content items shall be kept in UC-220302 knowledge base. DR-220304 A common vocabulary shall be available. UC-220301 UC-220302
DR-220305 Configurations for semantic tagging shall be defined and available for se- UC-220306 mantic lifting.
INR-220301 CMS systems shall be accessed through a standard methodology such as UC-220301 JCR. UC-220302 UC-220303 UC-220306 INR-220302 The output of IKS services shall be in a format which can be processed by UC-220301 rule engines and reasoners. INR-220302 The ontology of the repository content shall be in one of the standard ontol- UC-220304 ogy formats. UC-220306
ID IR-220301 IR-220302 IR-220303 IR-220304 IR-220305 Requirement An interface for assigning tags shall be implemented. An interface for suggesting possible tags shall be implemented. For navigating over the data an interface shall be implemented. UC-Ref UC-220302 UC-220302 UC-220302
Interfaces shall be implemented for presenting user related ontolo- UC-220302 gies/taxonomies. For each semantic tagging configuration option an interface shall be imple- UC-220306 mented.

ID NFR220301 NFR220302 Requirement UC-Ref
Content tagging shall be responsive, it shall recommend some tags before UC-220301 user completed the process of assigning some tag values. UC-220302 UC-220303 The extracted meta-data shall be accurate. UC-220301
86 / 218
ID NFR220303 NFR220304
Requirement The system shall be scalable.
UC-Ref UC-220302 UC-220303
The data navigation interfaces shall be flexible and interactive to handle UC-220304 users requests at the time of submission.
8.4 Semantic search & semantic query (HLR-2204)

HLR ID HLR-2204 Name Semantic Search & Semantic Query Description One of the key outcomes of semantic enhancements on CMSs can be observed through the semantic query and search functionalities of the system. Faceted search mechanisms on top of semantic query language support form the key requirements of this perspective. Having semantic information about content should be used to improve the search capabilities. With semantic data the IKS should extend the traditional search functionality to allow new ways of formulating search criteria and to provide "better" search results. Classification

Non cross cutting Horizontal HLR-002 Architecture and integration Semantically enhanced search Creating a prototype search engine that understand microformats RDFA User friendly RDF query. See the schema, faceted browsing, Semantically supported faceted browsing Similarity search, similarity detection Support for disambiguation of search How to make distributed querying, federation of SPARQL queries Notify semantic search engines about your Site, Semantic Site Map Possibility to create pages by queries, Views
Scenario 1 (Query) When a consumer uses the search functionality she should be able to use it in a way that recognizes her own knowledge level about formulating search queries. A novice consumer should not need to know and see anything about the underlying technologies like RDF. But a more advanced consumer should have the opportunity to formulate queries that directly address the underlying technology. So the IKS should provide different access methods to the search interfaces for different consumer groups with respect to their background. To allow novice consumer to formulate advanced queries the IKS should provide some wizard controlled query editor. Search tutorials should also be available to support novice users.
87 / 218
The consumer enters a query at the GUI of a CMS. Then the CMS decides (perhaps using user parameters) how to handle the query and which IKS services are requested during the query handling. This allows the CMS to easyly use IKS semantic services during the query and search process.
Scenario 2 (Search) When a novice user enters a free text search the IKS should be able to parse that query and try to formulate an advanced query query. A special kind of advanced queries are queries formulated in SPARQL. The IKS must be able to generate SPARQL queries by parsing a novice query and to execute those queries formulated in SPARQL.
88 / 218
89 / 218
Scenario 3 (Search) To support maximum flexibility for the semantic search strategies that should be used for a concrete query the user should be able to configure what happens inside the search engine with respect to the semantic search capabilities. The IKS semantic search should be grouped into different search features. The idea is that each search feature can be used independent from other search features. The user can configure which features should be used for a concrete query. This gives the IKS the opportunity to offer experimental search features that are not used by default. For example the IKS may have the search feature to automatically recognize the language in which the search was formulated. It must be configurable for the user whether this feature should be used in a concrete query or not. Additionally the language recognition feature may support three different algorithms to do the job. It must be possible to configure which one will be used. Search features can be started separately where each feature generates its own result set or they can be arranged in a search chain. To combine search features in a chain they must support a piping concept where the output of one feature is the input of the next feature. The order of the search features in such a chain might be important. So it must be possible to configure the ordering of search features inside the chain by arranging the features. In summary the IKS search should be divided into configurable search features. As a consequence the search capabilities can be extended by adding custom search features. Some features might be mandatory but it is the goal to keep as much features as possible optional. See [NEWSSIFT] for an example that uses similar ideas.
90 / 218
Scenario 4 (Search) One search feature is to support the detection of similarities inside the query and the search results. In combination with disambiguation (see scenario 5) the IKS should offer the feature to use the similarity relationship between words as search input and improve the search results by combining similar ones. The user must be informed about the used similarity relations. Example: The user searches for "beach" in a touristy IKS-CMS. Instead of searching for the exact string "beach" the IKS search should also search for "beaches" and "sandy beach". The results may contain hits about nice beaches but also about "beach volleyball". In this situation the IKS should group the hits about "beaches" and "beach volleyball" separately.
91 / 218
Scenario 5 (Query) Word sense disambiguation is the process of clarifying the meaning of words or phrases. To support better search results the search engine should provide a feature to allow the disambiguation when formulating the query. The disambiguation can be performed automatically or by user support. In the first case some ontology knowledge will be used to clarify the wording. In the second case the search engine makes only suggestions and lets the user decide which meaning of a word is meant.
Scenario 6 (Browsing) In a CMS it is often the case that a user has no specific search query in mind but wants to get an overview by browsing through the content. Also some information might be easier or more intuitively to find by browsing through a navigation structure. The IKS should support the definition of different browsing strategies to browse the content. These strategies should make use of the available semantic information and go ahead standard techniques like browsing by date. In combination with the IKS search capabilities the IKS should support the definition of custom browsing strategies. To do this, a search result is used as the set of content that can be browsed (the browseable content). To configure the browsing strategy the consumer formulates queries that classifies the browseable content. This classification is used as the basis for browsing the content like in faceted browsing techniques (see scenario 7). The browsing strategy can be seen as a search for a concept inside the browseable content. The concept is a dynamic facet that is used to classify the content. The consumer searches for a concept inside the browseable content and the result is the classification of the content using the concept. Example: The consumer wants to browse all hairdressers in Berlin. In a first step he searches for "hairdresser berlin" and gets 50,000 hits. The consumer wants to browse the hairdressers by districts of Berlin. So he creates a new browsing view that uses the district
92 / 218
information (concept) of all 50,000 hits and classifies each hit by its district. Now the consumer classifies the results of district "Prenzlauer Berg" by creating a search query that uses the concept "business hours" as a further facet. The point is that the browse by district and browse by business hours views did not exist before. Browsing views can be dynamically created by consumer defined classification criteria applied to the search result.
Scenario 7 (Browsing) A special browsing feature is the use of faceted browsing which is based on faceted classification. A faceted classification system allows the assignment of multiple classifications to an object, enabling the classifications to be ordered in multiple ways, rather than in a single, predetermined, taxonomic order. A facet comprises clearly defined, mutually exclusive, and collectively exhaustive aspects, properties or characteristics of a class or specific subject. Faceted browsing can be used as an extension to the presentation of search results.
93 / 218
Scenario 8 (Search results) The search results should not only be presentable to the user in some form of list. Search results should be reusable in the sense that customized views are supported. By this a user is able to create a view (page) by defining several search queries and arranging the results in different areas of that view. Specialized UI components will be able to handle all kinds of search results and present them to the user. To support the reuse of such searches the queries and the configuration of the presentation of the search results must be storable.
94 / 218
Scenario 9 (Search sources) The IKS should provide the opportunity to search different sources. The default source is always the content inside the CMS along with the provided semantic information but for some features it is necessary to search other content repositories or simply the WWW. For this the IKS must provide interfaces to access different kinds of content repositories and to make use of other existing search engines. Examples are a JCR content repository, other available public knowledge bases such as Wordnet, DBPedia, the Wikipedia search, or full text search engines. Which sources are considered must be configurable for each query. When the IKS accesses sources outside the CMS the source might not deliver any semantic information with the content. In this case the IKS should use its functions to semantically lift up the content from the external sources.
95 / 218
Scenario 10 (Configurable search results) The search results should be structured adequately and presented to the user dependent on the performed search and configuration. The IKS should provide different options:

Configure the relevance of hits. For example the user can configure that hits from a full text search should be ranked higher than from another semantic search feature. Configure that search results from different search strategies should be presented separately. This allows a user to trace where which hit came from.
96 / 218
Scenario 11 (Query suggestions) A semantic search system needs to support the user to create queries. This includes suggestions of possible search parameters and suitable constraints for selected parameters. (e.g. location Vienna, Vienna and surroundings). In addition a semantic search system should also suggest the user other typical query parameters based on already used ones. (e.g. if a user searches in an archive for news about a topic the system should suggest him that it might make sense to restrict the query also by a time period).
97 / 218
Scenario 12 (Estimated number of search results) The IKS search should learn from executed queries to present the number of estimated search results for a given query. This is possible if the same query was executed prior and the searchable content has not changed much. So the IKS has to store statistics about performed searches. Using this feature the IKS search can suggest the usage of an additional search criteria and show the estimated effect on the number of search results. Example: A user searches for "hairdresser berlin" and gets 50,000 hits. Now the IKS suggests to add a specific district of Paderborn to the search criterias to get more specific results. To show the effect the IKS calculates the estimated number of search results for each district as if the user had added this district to the search criterias. In the example the IKS might suggest that there would be about 1,600 hits if the user adds "Prenzlauer Berg" to the search criterias. The IKS does not perform a search with these new criterias in background. The IKS uses search statistics of prior searches instead to calculate the estimated number of hits.
98 / 218
Query
o o o o o o o o o o o o o o o o
UC-220401: Enter query [SC1, SC2, SC4, SC5, SC9] UC-220402: Enter novice query [SC1, SC2] UC-220403: Enter wizard based query [SC1] UC-220404: Enter advanced query [SC1, SC2] UC-220405: Enter SPARQL query [SC2] UC-220406: Parse query [SC2] UC-220407: Generate advanced query [SC2] UC-220408: Generate SPARQL query [SC2] UC-220409: Handle query [SC1] UC-220441: Send similarity detection request [SC4] UC-220411: Similarity in query detection [SC4] UC-220442: Send word sense disambiguation request [SC5] UC-220412: Word sense disambiguation [SC5] UC-220414: Suggest query parameters [SC11] UC-220442: Send hit calculation request [SC12] UC-220415: Search [SC2, SC6, SC8, SC9]
Search
99 / 218
UC-220416: Configure search [SC2, SC3, SC9] UC-220417: Configure search sources [SC9] UC-220418: Configure search feature [SC3] UC-220419: Select search features [SC3] UC-220420: Arrange search features [SC3] UC-220421: Perform search [SC2, SC9] UC-220422: Perform search in different sources [SC9] UC-220423: Extend search with custom search feature [SC3] UC-220424: Save search [SC8] UC-220425: Save search result statistics [SC12] UC-220426: Calculate estimated number of hits [SC12] Search results and presentation o UC-220427: Present search results [SC2, SC4, SC7, SC9] o UC-220428: Present results for different sources [SC9] o UC-220429: Combine results from different sources [SC9] o UC-220430: Similarity in results detection [SC4] o UC-220431: Present used similarities [SC4] o UC-220432: Provide search results in a reusable form [SC8] o UC-220433: Define a custom view [SC8] o UC-220434: Configure search result view [SC10] o UC-220435: Evaluate search result view configuration [SC10] Browse o UC-220436: Browse content [SC6, SC7] o UC-220437: Faceted browsing [SC7] o UC-220438: Select browsing strategy [SC6] o UC-220439: Define browsing strategy [SC6, SC7] o UC-220440: Define browsing facets [SC7] Use Cases from other HLRs o UC-002001: Send IKS service request [SC1, SC4, SC5, SC12] o UC-002013: Execute [SC12]
o o o o o o o o o o o
UC-220401: Enter query

Use Case ID UC-220401 [SC1, SC2, SC4, SC5, SC9] Description To enter a query is the basis for all use cases associated with query handling. Parent Includes Scope Actor(s) Goal Trigger none UC-220409, Entering a query is the starting point for all IKS search activities. Consumer The user is able to enter a search query. The consumer enters a query.
100 / 218
UC-220402: Enter novice query

Use Case ID UC-220402 Description Novice users do not use advanced search query features and just enter a simple query called a novice query. Parent Includes Extension Scope UC-220401 UC-220406 suggestion: A novice query is the simplest use case for entering a query from a user's point of view. It is the use case where the user just enters some words and that are parsed by the IKS query engine to start a search. Novice consumer A novice consumer can use the IKS search by entering a simple query. The consumer enters a novice query.
UC-220403: Enter wizard based query

Use Case ID UC-220403 Description To give even novice consumers the ability to enter an advanced query the wizard based query is a step by step query entering dialogue. The consumer is asked several questions where the answers are used to generate the concrete query. Parent Includes Scope Actor(s) Goal Trigger UC-220401 UC-220404 A wizard based query is a more user friendly variant of entering an advanced query. Novice consumer A novice consumer can enter an advanced query using a query wizard. The consumer enters a wizard based query.
UC-220404: Enter advanced query

Use Case ID UC-220404 [SC1, SC2] Description Advanced consumers are able to enter advanced queries. An advanced query uses an IKS query syntax to express which information should be used where and which semantic search techniques are used. One concrete technology for this is the use of SPARQL queries (see UC-220405).
101 / 218
Parent Includes Scope
UC-220401 A advanced query is expressed in IKS query syntax. It gives the advanced consumers the ability to use the whole power of semantic information that is hold by the IKS. Advanced consumer An advanced consumer can enter an advanced query in IKS query syntax. The consumer enters an advanced query.
UC-220405: Enter SPARQL query

Use Case ID UC-220405 [SC2] Description SPARQL queries are one technology for supporting advanced queries. The IKS should support SPARQL queries as one language to express advanced queries. Parent Includes Scope Actor(s) Goal Trigger UC-220404 To support advanced queries with a technology that is known to consumers SPARQL queries are one technology that is supported by IKS. Advanced consumer An advanced consumer can enter an advanced query in SPARQL syntax. The consumer enters a SPARQL query.
UC-220406: Parse query

Use Case ID UC-220406 [SC2] Description Each query that was entered must be parsed by the IKS to perform the concrete search for that query. The parsing is different for the different types of queries (novice queries, advanced queries, SPARQL queries). Parent none
Included by UC-220402 Extensions Scope Actor(s) generation: UC-220407 Query parsing is the step between entering a novice query and performing the search. IKS service
102 / 218
Goal Trigger
Parse the query to be able to perform the search for that query. The consumer enters a query that is parsed by the IKS.
UC-220407: Generate advanced query

Use Case ID UC-220407 Description An extension for parsing a query is the generation of an advanced query by parsing a novice query. This generation uses semantic techniques to recognize the semantic information about used words inside the query. E.g. the recognition of locations. Parent Includes Extends Scope Actor(s) Goal Trigger UC-002013 UC-220406 (generation) To generate an advanced query from a simple query is one approach to lift up the query in order to get better search results. IKS service Generate an advanced query by using a simple query as input. The user enters a query that is used as input for the generator.
UC-220408: Generate SPARQL query

Use Case ID UC-220408 [SC2] Description A specialized form of generating an advanced query is the generation of a SPARQL query. Parent Includes Extensions Scope Actor(s) Goal Trigger UC-220407 To generate an advanced query from a simple query is one approach to lift up the query and get a SPARQL query in return. IKS service Generate a SPARQL query by using a simple query as input. The user enters a query that is used as input for the generator.
103 / 218
UC-220409: Handle query

Use Case ID UC-220409 [SC1, SC4] Description After a query was entered it must be handled by the CMS. This can also be used for query handling for incomplete queries while the user is still typing. Included by UC-220401 Includes Extensions Scope Actor(s) Goal Trigger UC-220201 similarity: UC-220441 CMS query handling CMS The consumer query is handled by the CMS. A consumer entered a query.
UC-220441: Send similarity detection request

Use Case ID UC-220441 [SC4] Description When the CMS handles a query it can use the IKS similarity service to identify similar search phrases to present similar search results to the user. This might help a user to get what he is really searching for. Parent Extends Scope Actor(s) Goal Trigger UC-220201 UC-220409 (similarity) CMS query handling CMS The CMS gets similarity results from the IKS service. The CMS handles a query.
UC-220411: Similarity in query detection

Use Case ID UC-220411 [SC4] Description When the CMS handles a query it can use the IKS similarity service to identify similar search phrases to present similar search results to the user. This might help a user to get what he is really searching for. Parent UC-002013
Included by UC-220441
104 / 218
Scope Actor(s) Goal Trigger Action
CMS query handling IKS Service The CMS gets similarity results from the IKS service. The IKS receives a similarity detection request.
Figure 8.39 Activity diagram for use case "Similarity in query detection"
UC-220442: Send word sense disambiguation request

Use Case ID UC-220442 [SC5] Description When the CMS handles a query it can use the IKS similarity service to identify similar search phrases to present similar search results to the user. This might help a user to get what he is really searching for. Parent UC-002001
Included by UC-220409 Scope Actor(s) Goal CMS query handling CMS The CMS gets word sense disambiguation results from the IKS service.
105 / 218
Trigger
The CMS handles a query.
UC-220412: Word sense disambiguation

Use Case ID UC-220412 [SC5] Description This IKS service presents suggestions for the sense of words that are given as input. The results may help a user to specify more exactly what he means by a specific query. Parent UC-002013
Included by UC-220409 Scope Actor(s) Goal Trigger Action CMS query handling IKS Service The IKS service computes suggestions to clarify the sense of words. The IKS received a word sense disambiguation request.
Figure 8.40 Activity diagram for use case "Word sense disambiguation"
UC-220414: Suggest query parameters

Use Case ID UC-220414 [SC11] Description This service is able to suggest further query parameters based on the param-
106 / 218
eters that were already entered by the consumer. Parent Extends Extensions Scope Actor(s) Goal Trigger Action UC-220213 UC-220402 (suggestion) hits: UC-220426 CMS query handling IKS Service The IKS service computes suggestions for additional query parameters. A consumer enters a novice query and the CMS sends a query suggestion request.
Figure 8.41 Activity diagram for use case "Suggest query parameters"
UC-220415: Search
Use Case ID UC-220415 Description A consumer starts a search, so that a search request is sent to the IKS and there handled by the IKS semantic search service. Parent Includes UC-002001 UC-220401, UC-220421
107 / 218
Extends Extensions Scope Actor(s) Goal Trigger Action
search: UC-220439; search: UC-220433 presentation: UC-220427 Search Consumer, CMS The search is executed using the entered query. The user has entered a query and starts a search.
Figure 8.42 Activity diagram for use case "Search"
108 / 218
UC-220416: Configure search

Use Case ID UC-220416 [SC2, SC3, SC9] Description Advanced consumers should be able to configure the IKS search. The configuration should cover the used search features and sources. Extensions Includes Scope Actor(s) Goal Trigger search feature: UC-220418, UC-220419, UC-220420 ; source: UC-220417 none Search configuration Advanced consumer The search service is configured and ready for use with the specified configuration. An advanced consumer wants to configure the search before using it.
109 / 218
Action
Figure 8.43 Activity diagram for use case "Configure search"
UC-220417: Configure search sources

Use Case ID UC-220417 [SC9] Description The search can be configured by specifying the sources that should be considered when a search is performed. Search sources can be different content and knowledge repositories or external databases (e.g. Wikipedia). Extends Includes Scope Actor(s) UC-220416 (source) none Search configuration Advanced consumer
110 / 218
Goal Trigger
The search service is configured and ready for use with the specified search sources. An advanced consumer wants to configure the used search sources.
UC-220418: Configure search feature

Use Case ID UC-220418 [SC3] Description The semantic search should consist of different search features that can be configured separately. Configuration means to set feature specific configuration parameters for a search feature. Examples for search features are the search in different sources (UC-220422) or the similarity in results detection feature (UC-220430). Extends Includes Scope Actor(s) Goal Trigger UC-220416 (search feature) none Search configuration Advanced consumer The search feature is configured will be used according to its configuration during searches. An advanced consumer wants to configure a search feature.
UC-220419: Select search features

Use Case ID UC-220419 [SC3] Description Not each existing search feature must be used during a search. Therefore the used search features can be selected. During this use case the features must be arranged to define the execution order of the selected features. Extends Includes Scope Actor(s) Goal Trigger UC-220416 (search feature) UC-220420 Search configuration Advanced consumer The search features that should be used are selected and arranged. An advanced consumer wants to select the search features that should be used.
UC-220420: Arrange search features

111 / 218
Description The selected search features must be arranged to define the order of execution during search. Extends UC-220416 (search feature)
Included by UC-220419 Scope Actor(s) Goal Trigger Search configuration Advanced consumer The search features are arranged and thus the order of execution is defined.

An advanced consumer wants to arrange the used search features OR Search features are selected (UC-220419)
UC-220421: Perform search

Use Case ID UC-220421 [SC2, SC9] Description The search itself is performed by executing an IKS service. Parent UC-002013
Included by UC-220415 Extensions Scope Actor(s) Goal Trigger source: UC-220422, ; results: UC-220429, UC-220430, UC-220432 Search IKS Service The search is performed and the results are calculated. A consumer starts a search and the IKS semantic search service is called.
112 / 218
Action
Figure 8.44 Activity diagram for use case "Perform search"
UC-220422: Perform search in different sources

Use Case ID UC-220422 [SC9] Description When a search is performed it uses different configurable sources as its database. Extends Includes UC-220421 none
113 / 218
Scope Actor(s) Goal Trigger
Search IKS Service The search is performed using the configured data sources. A search was started.
UC-220423: Extend search with custom search feature

Use Case ID UC-220423 [SC3] Description It should be possible for IKS customizers to implement their own search features and extend the search using these new features. Parent Includes Scope Actor(s) Goal Trigger none none Search customization IKS Customizer An IKS customizer implements a new search feature and extends the IKS search using this new feature. An IKS customizer wants to extend the IKS search by a new self implemented search feature.
UC-220424: Save search

Use Case ID UC-220424 [SC8] Description A consumer should be able to save a search request in order to reuse the request. The stored request consists of the query and the search configuration, e.g. which search features are used. Parent Includes Scope Actor(s) Goal Trigger none none Search Consumer The search request is stored and can be reused. A consumer wants to store a request for later reuse.
UC-220425: Save search result statistics

114 / 218
Description The IKS should be able to store statistics about search results that can be used for other semantic services. The statistic should store made request in combination with information like the number of hits. Extends Includes Scope Actor(s) Goal Trigger UC-220421 (results) none Search IKS Service The IKS search service stores statistical search result information. A search was performed.
UC-220442: Send hit calculation service request

Use Case ID UC-220442 [SC12] Description The CMS system wants to know the estimated number of hits for a given search request. This information can help to decide whether a search should be performed or not. This means that the calculation of the estimated number of hits must be performed without performing the search itself. Parent Includes Scope Actor(s) Goal Trigger UC-002001 UC-220426 Hit calculation CMS The CMS send a hit calculation request and receives the estimated number of hits. The CMS wants to know the estimated number of hits for a given search request.
UC-220426: Calculate estimated number of hits

Use Case ID UC-220426 [SC12] Description The IKS should be able to calculate the estimated number of hits using the stored search statistics (UC-220425). An external system is then able to ask for the estimated number of hits for a given search request. Parent UC-002013
Included by UC-220442 Scope Search
115 / 218
Actor(s) Goal Trigger Action
IKS Service An IKS service calculates the estimated number of hits. A hit calculation request was received.
Figure 8.45 Activity diagram for use case "Calculate estimated number of hits"
UC-220427: Present search results

Use Case ID UC-220427 [SC2, SC4, SC7, SC9] Description The IKS should be able to present the search results using some kind of presentation technique, e.g. a web site. Because the presentation of search results is often handled by the CMS this IKS use case is an optional extension of the IKS search. The presentation of search results can be configured and switched off. Extends Extensions Includes Scope Actor(s) Goal UC-220415 (presentation) source: UC-220428; browse: UC-220436; similarity: UC-220430, UC-220431 UC-220435 Presentation IKS The search results are presented to the consumer.
116 / 218
Trigger Action
A search was performed and the presentation of search results is switched on.
Figure 8.46 : Activity diagram for use case "Present search results"
UC-220428: Present results for different sources

Use Case ID UC-220428 [SC9] Description When a search is performed in different sources the search results must be presented in a way that reflects the results from the different sources. Extends Includes Scope Actor(s) Goal Trigger UC-220427 (source) none Presentation IKS The IKS presents the search results with respect to the used sources. The search results must be presented with results from different sources.
117 / 218
UC-220429: Combine results from different sources

Use Case ID UC-220429 [SC9] Description When a search is performed using different sources the results from the different sources have to be combined by an IKS service. Extends Includes Scope Actor(s) Goal Trigger UC-220421 (results) none Search IKS Service The search results from different sources are combined to one condensed result. A search was performed and produced results from different sources.
UC-220430: Similarity in results detection

Use Case ID UC-220430 [SC4] Description Search results often consist of similar results. Which results are similar depends on the used criteria that are used to compute the similarity. The IKS should be able to support the detection of similar results for given criterias. This helps to condense the result and supports the consumer to identify the results of interest. Extends Includes Scope Actor(s) Goal Trigger UC-220421 (results) none Search IKS Service Similarities in the search results are detected and the results are condensed using this information. A search was performed which used the similarity in results detection feature.
UC-220431: Present used similarities

Use Case ID UC-220431 [SC4] Description When the feature of similarity detection in search results is used the IKS must show the used similarities when presenting the search results to the consumer. This is necessary to give feedback to the consumer about the used similarity criterias. Extends UC-220427 (similarity)
118 / 218
Includes Scope Actor(s) Goal Trigger
none Presentation IKS The used similarities and criterias are presented to the consumer. A search was performed which used the similarity in results detection feature.
UC-220432: Provide search results in a reusable form

Use Case ID UC-220432 [SC8] Description When a search is performed the results must be provided in a reusable format. This format is used when sending the results back to the CMS and enables the CMS e.g. to display the results. Extends Includes Scope Actor(s) Goal Trigger UC-220421 (results) none Search IKS Service The search results are provided in a reusable form. A search was performed.
UC-220433: Define a custom view

Use Case ID UC-220433 [SC8] Description The IKS presentation layer should be able to let a consumer define custom views on content. The content of such views can be filled using the IKS search service. Extensions Includes Scope Actor(s) Goal Trigger search: UC-220415 none Presentation Consumer A consumer has defined a custom view on content. A consumer wants to define a custom view.
119 / 218
UC-220434: Configure search result view

Use Case ID UC-220434 [SC10] Description The modality how search results are presented to the consumer must be configurable. Configuration options can be e.g. the ranking of hits or the layout. Parent Includes Scope Actor(s) Goal Trigger none none Presentation Consumer The consumer has configured the modality for presenting the search results. A consumer wants to configure the search result view.
UC-220435: Evaluate search result view configuration

Use Case ID UC-220435 [SC10] Description The consumer is able to configure the search result view (UC-220434). Each time the search results are presented to the consumer this configuartion must be evaluated. Included by UC-220427 Includes Scope Actor(s) Goal Trigger none Presentation IKS The current search result view configuration is evaluated and used. Search results must be presented.
UC-220436: Browse content

Use Case ID UC-220436 [SC6, SC7] Description A consumer should be able to browse and navigate through the content. Extends Includes Scope Actor(s) UC-220427 (browse) UC-220438 Browsing Consumer
120 / 218
Goal Trigger Action
A consumer is able to browse through the content. A consumer wants to browse through the content.
Figure 8.47 Activity diagram for use case "Browse content"
UC-220437: Faceted browsing

Use Case ID UC-220437 [SC7] Description A special kind of browsing is the technique of faceted browsing. This feature can be used by classifying the content and using this classification as the navigation structure to browse through the content. The faceted browsing is also an extension for presenting search results, which means that search results can be presented by using a view that allows to browse through the search results using faceted browsing. Parent Extends Scope Actor(s) Goal UC-220436 UC-220427 (browse) Browsing Consumer A consumer is able to browse through content by using facets.
121 / 218
Trigger
A consumer wants to browse through the content using facets or rather browse through a search result using facets.
UC-220438: Select browsing strategy

Use Case ID UC-220438 [SC6] Description Browsing through content depends on the used browsing strategy. The strategy defines the navigation structure, e.g. browse by date or file names are simple browsing strategies. A consumer must be able to decide which strategy will be used to customize his browsing needs. Parent Includes Scope Actor(s) Goal Trigger none none Browsing Consumer The consumer can select the browsing strategy. A consumer wants to select another browsing strategy.
UC-220439: Define browsing strategy

Use Case ID UC-220439 [SC6, SC7] Description The consumer should be able to define his own browsing strategies which then can be selected (UC-220438). One option to realize the definition of browsing strategies is to use the IKS search capabilities as an extension. The idea is to use the results of a search as input for the browsing strategy. Parent Includes Scope Actor(s) Goal Trigger none none Browsing Consumer A consumer has defined browsing strategies. A consumer wants to define browsing strategies.
UC-220440: Define browsing facets

Use Case ID UC-220440 [SC7] Description The definition of browsing facets is a special case of defining a new browsing strategy. Facets can also be defined using the IKS search capabilities.
122 / 218
Parent Includes Scope Actor(s) Goal Trigger
UC-220439 none Browsing Consumer A consumer has defined facets to be used for faceted browsing. A consumer wants to define facets.

ID Requirement UC-Ref UC-220401 UC-220412 UC-220421 UC-220422 UC-220416 UC-220417 UC-220418 UC-220420 UC-220429 UC-220427
FR-220401 The IKS shall be able to process search queries. FR-220402 The IKS shall support word sense disambiguation in queries. FR-220403 The IKS search shall be performed by processing the search features. FR-220404 The IKS shall be able to perform searches in different sources. FR-220405 The IKS search shall be configurable. FR-220406 The IKS search sources shall be configurable. FR-220407 Each IKS search features shall be configurable. FR-220408 The IKS search features shall be arranged as a process of execution. FR-220409 The IKS shall be able to combine the search results from different sources. FR-220410 The IKS shall be able to present the search results.
FR-220411 The IKS shall evaluate the current search result view configuration before UC-220435 presenting results. FR-220412 The IKS shall be able to present search results for different sources. FR-220413 The IKS shall be able to present similarities in the search results. FR-220414 The presentation of search results by the IKS shall be configurable. FR-220415 The presentation of search results by the IKS shall be detachable. FR-220416 The IKS shall provide the search results in a reusable way. FR-220417 The IKS shall support the recognition of similarities in queries. FR-220418 The IKS shall support the recognition of similarities in search results. FR-220419 The IKS shall support content browsing. UC-220428 UC-220431 UC-220434 UC-220427 UC-220432 UC-220411 UC-220430 UC-220436
FR-220420 The IKS shall support browsing using different selectable browsing strat- UC-220438 egies. FR-220421 The IKS shall support the definition of custom browsing strategies. UC-220439
123 / 218
ID
Requirement
UC-Ref UC-220437 UC-220440 UC-220433 UC-220414 UC-220426 UC-220403 UC-220406
FR-220422 The IKS shall support faceted browsing. FR-220423 The IKS shall support the definition of customized facets. FR-220424 The IKS shall support the definition of customized views on search results. FR-220425 The IKS shall support the suggestion of additional query parameters. FR-220426 The IKS shall be able to calculate the estimated number of hits for a query. FR-220427 The IKS shall offer a wizard for entering advanced search queries. FR-220428 The IKS shall be able to parse search queries.
FR-220429 The IKS shall be able to generate advanced search queries by parsing the UC-220407 original query. FR-220430 The IKS shall be able to generate queries formulated as SPARQL queries UC-220408 by parsing the original request. FR-220431 The IKS shall be able to store a search consisting of search query and con- UC-220424 figuration for later reuse. FR-220432 The IKS shall be able to store statistics about performed searches. UC-220425
Data requirements
ID Requirement UC-Ref UC-220405
DR-220401 The IKS shall support the SPARQL format.
INR-220401 The IKS search shall be extendible by using/implementing custom search UC-220423 features.
ID IR-220401 IR-220402 IR-220403 IR-220404 Requirement The IKS shall be able to process novice search queries. The IKS shall be able to process wizard based search queries. The IKS shall be able to process advanced search queries. UC-Ref UC-220402 UC-220403 UC-220404
The IKS shall be able to process search queries formulated using SPARQL. UC-220405

ID NFR220401 NFR220402 Requirement UC-Ref
The IKS shall be usable for consumers with all levels of knowledge about UC-220401 semantic search technologies. The IKS shall support different kinds of search queries for different kinds of UC-220401 users.
124 / 218
NFR220403 NFR220404 NFR220405 NFR220406 NFR220407 NFR220408
The IKS search shall be a semantic service. The IKS search shall be composed of customizable search features.
UC-220415 UC-220419
The IKS word sense disambiguation functionality shall be a semantic ser- UC-220412 vice. The IKS similarity in queries recognition functionality shall be a semantic UC-220411 service. The IKS suggestion of query parameters shall be a semantic service. UC-220414
The IKS similarity in search results recognition functionality shall be a se- UC-220430 mantic service.
8.5 Reasoning on content items (HLR-2205)

HLR ID HLR-2205 Name Reasoning on content items Description Extracting implicit set of data from the explicit information residing in the content repositories is a key requirement for horizontal services of IKS stack. Classification

Non cross cutting Horizontal none High Semantic consistency checking in content management system
Related requirements Implementation priority Statements
Scenarios
Scenario 1: The ontology embeds some relationships among content items which can be extracted through inference mechanisms. When a hierarchical taxonomy is converted into ontology, the parent-child relation may reveal implicit information through subsumption relations between content items. For example, if article 1 is tagged with "health", article 2 is tagged with "virus, disease" and if the there is a parent-child relationship between "health" and "disease" taxonomy elements, then when a user queries with the "health" keyword, as a response, not only article 1, but also article2 is returned as the result. After the meta data of the CMS system has been uploaded to IKS and configuration has been saved into IKS, then the data found in IKS system can be utilized by a reasoner tool and the implicit semantic relationships can be revealed.
125 / 218
Scenario 2: In addition to data constraints and restrictions, there are also some other type of rules that states how the restrictions and conditions of the business applies, i.e. business logic. These rules also embed valuable amount of semantic information which can reveal implicit relationships and consistency checking. Users need to encode, save and execute the business rules in the CMS. The all operations -encode, save and execute- will be apart from CMS systems and shall be handled via IKS services and knowledge base.
Figure 8.48 Use Case diagram for HLR-2205

UC-220501: Reason on content items [SC1] UC-220502: Infer Business Rule [SC2]
UC-220501: Reason on content items

Use Case ID UC-220501: Reason on content items Description Reasoning on the semantically tagged pieces of the content items, which is the information residing in the knowledge base, aims to infer the implicit information hided inside the explicitly defined annotations and tagging. The knowledge base of IKS consists of the semantic annotations, vocabularies, ontologies and other semantic data elements related with the content items residing in the CMS. Parent Scope The scope of semantic reasoning is the knowledge base, specifically the persistence layer of the IKS. Actor(s) IKS Goal The goal is to extract the implicit knowledge existing in the knowledge base of the IKS through the explicit knowledge on the content items and take further necessary actions defined for the implicit knowledge. A timer may trigger the related service of IKS or according to the predefined business rules the reasoner can be initiated, such as any change in the knowledge base.
Trigger
126 / 218
Preconditions 1. The IKS consists of a persistent knowledge base populated with semantic data instances. 2. The IKS has interaction with a semantic reasoner. 3. The knowledge base exposes a structure on which semantic reasoning is possible. Minimal Postconditions 1. Any outcome of the reasoning process is logged for the future analysis by the IKS user. Success Postconditions 1. According to the result of the reasoning process, such as inferring a new information piece, the IKS invokes the relevant other services to take the appropriate action if such actions have been predefined. Main Flow 1. Upon the trigger event for the initiation of the reasoning process, reasoning starts. 2. Any information at the time of the processing is logged into a persistent file. 3. If any new knowledge is inferred, the IKS takes the necessary actions according to its internal business rules, such as presenting it to the user. 4. The inferred knowledge is saved to the IKS Knowledge Base. Extensions Exceptions 1. Upon the trigger event for the initiation of the reasoning process, reasoning starts. 1. Reasoner may not be available 2. The inferred knowledge is saved to the IKS Knowledge Base. 1. IKS Knowledge Base may not be available Open Issues Action 1. Reasoning on the knowledge base of the IKS can be done periodically or at each time when a change occurs in the knowledge base. Performance, usability and other parameters affects the choice of implementation. 2. The reasoning procedure can be designed as configurable and the choice for the reasoning parameters can be left to the user.
127 / 218
UC-220502: Infer Business Rule

Use Case ID UC-220502: Infer Business Rule Description The CMS includes high-level rules to reflect the business logic onto the knowledge base. The rules are implemented in the system through a well-defined language, such as SWRL or Jess. The interoperability of the rule language with the vocabulary language holds importance since the rules are defined over the IKS knowledge base which is populated with the semantics of elements residing in the CMS. Parent Scope Actor(s) Goal The scope of rule inference is the knowledge base together with the business logic related inter-disciplines of the IKS. IKS The goal is to represent and execute the high-level business logic of the CMS with well-defined semantics via IKS services.
128 / 218
Trigger
The service(s) of the IKS for the rule inference is triggered on a periodic basis or upon any change on the knowledge base, or upon user request.
Preconditions 1. The IKS has a vocabulary formed of well-defined structures. 2. The IKS Services provide mechanisms to register and manipulate high-level rules into the IKS on top of the vocabulary of the system. 3. The CMS has interaction with IKS Services and IKS Services can collaborate with a rule inference engine to execute the high-level rules on the knowledge base. Minimal Postconditions 1. Any outcome of the rule inference is logged for the future analysis by the IKS. Success Postconditions 1. According to the outcome of the executed rules, the necessary actions are taken by the IKS. Main Flow 1. Upon the trigger event for the initiation of the rule inference, execution of the highlevel rules starts. 2. For every rule defined over the knowledge base, the inference engine executes and tells the result to the related part of the IKS. 3. The IKS takes the necessary actions according to the outcome of the rule executions. Extensions Exceptions 1. Upon the trigger event for the initiation of the rule inference, execution of the highlevel rules starts. 1. Rule Engine is not available 2. The IKS takes the necessary actions according to the outcome of the rule executions. 1. The service to be executed as a result of the rule fired may not be available Open Issues 1. Trigger mechanism for the rule inference is a choice of implementation according to the performance and domain related other issues.
129 / 218
Action
Figure 8.50 diagram for use case UC-220502

FR-220501 IKS service shall infer the implicit information existing in the knowledge base UC-220501 through the explicit knowledge on the content items. FR-220502 IKS Services to provide mechanisms to register and manipulate high-level UC-220502 rules. FR-220503 The system outputs and process history shall be logged. UC-220501 UC-220502
Data requirements
DR-220501 The knowledge base shall consist the semantic annotations, vocabularies, UC-220501 ontologies and other semantic data elements related with the content items residing in the CMS.
130 / 218
ID
Requirement
UC-Ref UC-220502
DR-220502 The rules shall be implemented in the system.
INR-220501 The semantic knowledge kept in the knowledge base has a structure which UC-220501 can be processed by a reasoner. INR-220502 The rules shall be implemented in the system through a well-defined lan- UC-220502 guage, such as SWRL or Jess.
ID IR-220501 IR-220502 Requirement UC-Ref
An interface shall be implemented for presenting the user the findings of rule UC-220501 engine or reasoner An interface shall be implemented for requesting the approval of the user be- UC-220501 fore registering them to knowledge base. UC-220502

ID NFR220501 NFR220502 Requirement The user interfaces shall be user-friendly. UC-Ref UC-220501 UC-220502
The system shall be scalable to handle the growing size of content items UC-220501 and their semantic data. UC-220502
8.6 Links/relations among content items (HLR-2206)

HLR ID HLR-2206 Name Links/relations among content items Description Besides tagging in combination with ontological means, content entities can be (statically) linked. This process can be automated by algorithms that reason on the provided tags and ontologies. Content items are linked among each other during their lifecycles by the help of relevant services inside a CMS. These links/relations are needed to be handled by the semantic services of the IKS stack. Along with the semantic annotations of the content items, semantic relations among them should also be considered. Linking is already a standard technique in CMS that does not need to be reinvented by the IKS. The IKS should therefore focus on automatic link creation by playing on semantic algorithms and data. Nevertheless should the IKS support the traditional way of manual link creation using semantic link suggestion algorithms. Classification
Non cross cutting
131 / 218
Horizontal HLR-004 Semantic search & semantic query Creating the links between content items semi-automatically Help in-editor suggestion of tags, relations between content items, suggest related content inside the CR or from outside world such as web Instance linking, linked data cloud, whenever we create something link it with something existing.. Hierarchy: group staff together
Scenario 1 (Create links) Content can be linked with content from inside the CMS and with content outside the CMS. The IKS should consider different sources for linked content. Examples are content that is accessible through the WWW, content provided by another (compatible) CMS, or plain files accessible by some kind of file protocol.
132 / 218
Scenario 2 (Suggest links) When a user adds new content the IKS should suggest related content that is already inside the CMS and content that is outside the CMS (see scenario1). The sources and which kind of suggestions are used should be configurable. Similar to different search strategies the IKS must be extendible by custom suggestion strategies. Suggestions are provided using the IKS search capabilities.
133 / 218
Scenario 3 (Create links) The user should be able to link content with any other content from inside or outside the CMS. The link's target can be entered directly by an URI or be found by the IKS search capabilities.
Scenario 4 (Link@Save) The IKS should be able to automatically link new content to existing content during save. This action must be configurable and extendible to allow a user to control the link strategy or implement a custom one. Those automatically created links must be visible to the user and be editable afterwards.
134 / 218
Scenario 5 (Create links) A link is just a connection between two entities to express that they are related in some kind. To be more precise the IKS should provide the feature to define different kinds of links that transport more semantic information about the link. There can be more than one link between two content items where each link represents another semantic relation. Those semantic links should also be considered by the IKS search.
135 / 218
Create links o UC-220601: Link content [SC1, SC3, SC4, SC5] o UC-220622: Link content manually [SC1] o UC-220623: Link content automatically [SC1] o UC-220602: Link with internal content [SC1] o UC-220603: Link with external content [SC1] o UC-220604: Select link target [SC3] o UC-220605: Enter link target's URI [SC3] o UC-220606: Find link target [SC3] o UC-220607: Select semantic link type [SC5] o UC-220608: Define semantic link type [SC5]
Suggest links o UC-220609: Configure link suggestions [SC2] o UC-220610: Create content [SC2] o UC-220611: Suggest related content for linking [SC2] o UC-220612: Select suggestion strategies [SC2] o UC-220613: Suggest internal content [SC2] o UC-220614: Suggest external content [SC2] o UC-220615: Evaluate link suggestion configuration [SC2]
136 / 218
Link@Save o UC-220616: Perform content save [SC4] duplicate of UC-220217 o UC-220617: Evaluate link@save configuration [SC4] o UC-220618: Present created links [SC4] o UC-220619: Config link@save [SC4] o UC-220620: Config linking strategy [SC4] o UC-220621: Edit links [SC4]
Other o Search [SC2, SC3] see UC-004012
UC-220601: Link content

Use Case ID UC-220601 [SC1, SC3, SC4, SC5] Description Linking content is the basic use case to connect content with each other. Parent Extensions Scope Actor(s) Goal Trigger none content source: UC220602, UC220603 ; link type: UC220607 Linking Creator Content is linked with each other. A creator wants to link content.
137 / 218
Action
Figure 8.56 Activity diagram for use case "Link content"
UC-220622: Link content manually

Use Case ID UC-220622 [SC1] Description The manual creation of links is the standard procedure in most CMS. The IKS supports this task by offering a semantic service which suggests related content that can be linked to content that a content creator is currently working on. Parent Includes Scope Actor(s) Goal Trigger UC220601 none Linking Creator A content creator linked content manually. A content creator wants to link content manually.
138 / 218
Action
Figure 8.57 Activity diagram for use case "Link content manually"
UC-220623: Link content automatically (link@save)

Use Case ID UC-220623 [SC1] Description In contrast to link content manually (UC220622) the IKS offers a service to link content automatically (aka link@save). This step is configurable and customizable to allow as much flexibility as possible. Parent Extensions Scope UC220601, UC220213 presentation: UC220618 Automatic linking
139 / 218
Actor(s) Goal Trigger Action
IKS Service Content is linked automatically, i.e. without user interaction. Content is saved and automatic link creation is configured or the IKS receives a request for automatic link creation.
Figure 8.58 Activity diagram for use case "Link content automatically"
UC-220602: Link with internal content

Use Case ID UC-220602 [SC1] Description The IKS should support links between content that is stored within the CMS or IKS storage layer and links that point to some content that external to the CMS/IKS, e.g. the Internet. This use case supports links for internal content. Parent Extends Scope none UC220601 Linking
140 / 218
Creator A link is created between internal content. A creator wants to create a link between internal content.
UC-220603: Link with external content

Use Case ID UC-220603 [SC1] Description The IKS should support links between content that is stored within the CMS or IKS storage layer and links that point to some content that external to the CMS/IKS, e.g. the Internet. This use case supports links for external content. Parent Extends Scope Actor(s) Goal Trigger none UC220601 Linking Creator A link is created between internal and external content. A creator wants to create a link between internal and external content.
UC-220604: Select link target

Use Case ID UC-220604 [SC3] Description When creating a link the creator has to select the target for that link. Parent none
Included by UC220601 Scope Actor(s) Goal Trigger Linking Creator, IKS Service A creator has specified the target for a link. A creator wants to specify the target of a link.
UC-220605: Enter link target's URI

Use Case ID UC-220605 [SC3] Description A special case for selecting the target of a link is to enter an URI which points to the target.
141 / 218
Parent Includes Scope Actor(s) Goal Trigger
UC220604 none Linking Creator A creator specified the link's target by entering an URI. A creator wants to specify the target of link by entering an URI.
UC-220606: Find link target

Use Case ID UC-220606 [SC3] Description A special case for selecting the target of a link is to use the IKS search capabilities. Parent Includes Scope Actor(s) Goal Trigger UC220604 none Linking Creator A creator specified the link's target by using the IKS search. A creator want to use the IKS search capabilities to specify a link's target.
UC-220607: Select semantic link type

Use Case ID UC-220607 [SC5] Description The type of links between content transports the semantic of that link. Every time a link is created or suggested the semantic type of that link must be specified. Extends Includes Scope Actor(s) Goal Trigger UC220601 (link type), UC220611 (link type) none Linking Creator, IKS Service A creator or an IKS service selects the semantic link type for a given link. A creator or IKS service needs to specify the semantic type of a link.
142 / 218
UC-220608: Define semantic link type

Use Case ID UC-220608 [SC5] Description Advanced content creators should be able to define their own types of semantic links that can then be used to link content. Parent Includes Scope Actor(s) Goal Trigger none none Customization Advanced creator A new semantic link type is defined and available for use when selecting the semantic link type. An advanced creator wants to define a new semantic link type.
UC-220609: Configure link suggestions

Use Case ID UC-220609 [SC2] Description Advanced creators should be able to configure the IKS link suggestion service. Parent Includes Scope Actor(s) Goal Trigger none none Customization Advanced creator The link suggestion service is configured and uses the new settings. An advanced user wants to configure the IKS link suggestion service.
UC-220610: Create content

Use Case ID UC-220610 [SC2] Description This is the basic use case for creating content. Parent Extensions Scope Actor(s) none link suggestion: UC-220611 Content creation Creator
143 / 218
Goal Trigger
A content creator creates some kind of content. A content creator wants to create new content.
UC-220611: Suggest related content for linking

Use Case ID UC-220611 [SC2, SC5] Description Links are often created during the use case of content creation. The IKS should offer a service that is able to suggest other content that is related to the content which is currently created. This link suggestion engine must be configurable to control the strategy which is used when finding related content and the used semantic link types. To find related content this services uses the IKS search service. Extends Includes Extensions Scope Actor(s) Goal UC220610 (link suggestion) UC220421, UC220615 link type : UC220607; content source: UC-220613, UC-220614 Content creation IKS Service The IKS link suggestion services returns a set of URIs to content that is related to the content that is currently created. The types of the relations are specified by semantic link types. A content creator creates content and wants to see other related content.
Trigger
144 / 218
Action
Figure 8.59 Activity diagram for use case "Suggest related content for linking"
UC-220613: Suggest internal content

Use Case ID UC-220613 [SC2] Description The IKS content suggestion service must be able to suggest content that is stored inside the IKS/CMS. Parent Extends Scope Actor(s) none UC-220611 (content source) Content suggestion IKS Service
145 / 218
Goal Trigger
The IKS service suggests content from the internal IKS/CMS storage. The content suggestion service wants to suggest content from the internal IKS/CMS storage.
UC-220614: Suggest external content

Use Case ID UC-220614 [SC2] Description The IKS content suggestion service must be able to suggest content that is stored outside the IKS/CMS, e.g. the Internet. Parent Extends Scope Actor(s) Goal Trigger none UC-220611 (content source) Content suggestion IKS Service The IKS service suggests content that is stored outside the IKS/CMS. The content suggestion service wants to suggest content that is stored outside the IKS/CMS.
UC-220615: Evaluate link suggestion configuration

Use Case ID UC-220615 [SC2] Description Before the IKS link suggestion service can suggest related content it must evaluate the current link suggestion configuration and prepare the suggestion engine according to that configuration. Parent none
Included by UC220611 Scope Actor(s) Goal Trigger Content suggestion IKS Service The IKS link suggestion service evaluates the configuration and uses the current settings. The IKS link suggestion service is called.
UC-220617: Evaluate link@save configuration

Use Case ID UC-220617 [SC4] Description When content is linked automatically the link@save configuration must be ev-
146 / 218
aluated first. Parent none
Included by UC220623 Scope Actor(s) Goal Trigger Automatic linking IKS Service The current link@save configuration is evaluated and used. Content should be linked automatically.
UC-220618: Present created links

Use Case ID UC-220618 [SC4] Description When links are created automatically it is important to inform the user about this automated step. This gives a user the opportunity to edit such links afterwards. The presentation of automatically created links by the IKS is only available if the IKS presentation functionality is used, otherwise the CMS must take care of the presentation. Parent Extends Scope Actor(s) Goal Trigger none UC220623 (presentation) Automatic linking IKS Service The automatic created links are presented to a user. Content was linked automatically and presentation is configured.
UC-220619: Config link@save

Use Case ID UC-220619 [SC4] Description The strategy and parameters for automatic link creation must be configurable. This use case describes the task of configuring the link@save functionality. Parent Extensions Scope Actor(s) none strategy: UC220620 Configuration Advanced creator
147 / 218
Goal Trigger
An advanced content creator is able to configure the link@save functionality. An advanced content creator wants to configure the link@save functionality.
UC-220620: Config linking strategy

Use Case ID UC-220620 [SC4] Description A special aspect of configuring the link@save functionality is to configure the used strategy for automatic link creation. Different strategies might be implemented and available and the advanced content creator can decide which one should be used. Parent Extends Scope Actor(s) Goal Trigger none UC220219 (strategy) Configuration Advanced creator An advanced content creator is able to configure the used strategy for automatic link creation. An advanced content creator wants to configure the used strategy for automatic link creation.
UC-220621: Edit links

Use Case ID UC-220621 [SC4] Description A content creator must be able to edit links at any time. This use case is especially important when links are created automatically and a content creator wants to edit these links afterwards. Parent Includes Scope Actor(s) Goal Trigger none none Linking Creator A creator is able to edit an existing link, e.g. select a new target, delete the link, etc. A creator wants to edit an existing link.
148 / 218

FR-220601 The IKS shall be able to link content with content.
FR-220602 The IKS shall be able to link content with content that is stored inside the UC-220602 IKS (internal content). FR-220603 The IKS shall be able to link content that is stored outside the IKS (external UC-220603 content). FR-220604 The IKS shall be able to suggest related content for linking during content UC-220611 creation. FR-220605 The strategy for suggesting related content for linking shall be configurable. UC-220609 FR-220606 The IKS shall be able to suggest internal content for linking. FR-220607 The IKS shall be able to suggest external content for linking. UC-220613 UC-220614
FR-220608 The IKS shall use the current link suggestion configuration when suggesting UC-220615 links. FR-220609 The IKS shall be able to create links automatically when content is saved. FR-220610 The IKS shall be able to create links to internal content automatically. FR-220611 The IKS shall be able to create links to external content automatically. UC-220623 UC-220623 UC-220623
FR-220612 The IKS shall use the current link@save configuration when links are cre- UC-220617 ated on save. FR-220613 The IKS shall be able to inform the creator about automatically created links. UC-220618 FR-220614 The automatic link@save creation shall be configurable. FR-220615 The strategy for creating links automatically shall be configurable. FR-220616 The creator shall be able to modify automatically created links. FR-220617 The creator shall be able to select the link's target. UC-220619 UC-220620 UC-220621 UC-220604
FR-220618 The creator shall be able to select the link's target by entering the target's UC-220605 URI. FR-220619 The creator shall be able to select the link's target by using the IKS search. FR-220620 The IKS shall support semantic link types. FR-220621 The IKS shall support the definition of custom semantic link types. FR-220622 The IKS shall ensure that each link has a semantic link type. UC-220606 UC-220608 UC-220608 UC-220607
INR-220601 The strategy for creating links automatically shall be customizable by imple- UC-220620 menting custom strategies.
149 / 218
INR-220602 The strategy for suggesting links shall be customizable by implementing cus- UC-220609 tom suggestion strategies.

NFR-220601 The IKS shall be able to link content by using types of links that express a UC-220607 semantic relationship between content.
8.7 Workflows (HLR-2207)

HLR ID HLR-2207 Name Workflows Description Most CMS system have their own workflow management system to control the flow and lifecycle of content. Focused on the horizontal use case the IKS may not make any assumptions about how these systems work or are implemented. According to HLR002 the IKS should offer services that can be used to implement/extend a workflow management as part of the CMS. Additionally the IKS should provide workflows for semantic actions similar to workflows for content. By this the user can describe a workflow which defines the semantic reasoning algorithms and semantic extraction algorithms that will be applied on a new content entity. Classification

Cross cutting Horizontal HLR-002: Architecture and integration Intelligent content workflows, configured based on organization, hierarchy Customizable workflows
Scenario 1 The workflow management of CMS assigns content to agents that have to handle the content, e.g. editorially. The IKS can support this process by offering a semantic service to determine an agent that should handle a given content. A CMS could use such a service to determine the next responsible agent for a content item according to its current status and semantic annotations. As this decision process is specific for different organisations the service must be customizable using service extensions according to UC002025. Possible points for customization are e.g. the set of available agents (may be people or systems), the semantic description of these agents, and decision rules.
150 / 218
Scenario 2 The IKS offers the opportunity to define new services based on service orchestration (according to UC002023). Based on this the IKS should offer the opportunity to execute a
151 / 218
custom workflow of semantic services. The workflow must be creatable by an IKS customizer and its execution triggered by customized rules.
Example: An IKS customizer wants to execute several IKS services that are arranged in a custom workflow process. The execution of the workflow is triggered either by a specific service request or automatically by analysing the type of content that is received by the IKS. The workflow might like the example workflow in figure HLR2207ACSC1Example that was modelled using an UML activity diagram. Services like the language determination or content type determination might be executed in parallel for the same content. The depending on the content type either the tag extraction service or a service that determines the relationship between people is executed. The whole workflow can be created and maintained by an IKS customizer.
152 / 218
Figure 8.62 Workflow example for scenario 1

The use cases are ordered by actors: Creator o UC-220709: Edit content [SC1]
IKS Service o UC-220701: Perform agent determination [SC1] Service Customizer o UC-220702: Customize agent determination service [SC1] o UC-220703: Define available agents [SC1] o UC-220704: Describe agents semantically [SC1] o UC-220705: Define decision rules for agent selection [SC1]
IKS Customizer o UC-220706: Define service execution workflow [SC2] o UC-220707: Define execution trigger rules [SC2] o UC-220708: Plug service execution workflow in IKS [SC2]
UC-220709: Edit content

Use Case ID UC-220709 [SC1] Description Content editing is a special case of content creation and is the trigger use case that can use other IKS specific service use cases.
153 / 218
Parent UC220610 Extensions agent: UC220701; Scope Content editing Actor(s) Creator Goal A creator can edit content. Trigger A creator wants to edit content.
UC-220701: Perform agent determination

Use Case ID UC-220701 [SC1] Description The IKS should offer a service that is able to determine an (or a set) agent that will be associated to a content item. This is helpful to extend the existing workflow processes of CMSs with semantic features. The CMS can use such a service to determine the agent that should work on content, e.g. editorially. Parent UC220213 Includes none Scope Agent determination Actor(s) IKS Service Goal The IKS offers an agent determination service. Trigger none
154 / 218
Action
Figure 8.63 Activity diagram for use case "Perform agent determination"
UC-220702: Customize agent determination service

Use Case ID UC-220702 [SC1] Description The agent determination service must be adaptable to different environments. Different organisations may have their own rules, workflows and hierarchy of agents. To support this, the agent determination service must be customizable using service extensions. Parent UC002025 Extended Customization Points: UC220703, UC220704, UC220705 by Scope Service customization Actor(s) Service Customizer Goal The agent determination service is customized. Trigger A custom configuration of the agent determination service is needed.
155 / 218
Action
Figure 8.64 Activity diagram for use case "Customize agent determination service"
UC-220703: Define available agents

Use Case ID UC-220703 [SC1] Description To customize the agentdeterminationservice a service customizer must be able to define the set of available agents. The service will choose one (or a set) of those defined agents. Parent Extends Scope Actor(s) Goal Trigger none Customization Point of UC-220702 Service customization Service Customizer The set of available agents is defined and can be used by the service. The set of available agents needs to be customized.
UC-220704: Describe agents semantically

Use Case ID UC-220704 [SC1] Description Beside the definition of available agents each agent must be described semantically to become choosable to the agentdeterminationservice.
156 / 218
Parent Extends Scope Actor(s) Goal Trigger
none CustomizationPoint of UC-220702 Service customization Service Customizer Each agent is described semantically. The agents need to be described semantically before they can be made available.
UC-220705: Define decision rules for agent selection

Use Case ID UC-220705 [SC1] Description The rules to choose an agent or another will differ from environment to environment. This means that these decision rules must be customizable. Parent Extends Scope Actor(s) Goal Trigger none Customization Point of UC-220702 Service customization Service Customizer The decision rules for agent selection are defined. The decision rules for agent selection need to be customized.
UC-220706: Define service execution workflow

Use Case ID UC-220706 [SC2] Description Services can be arranged in custom service execution workflows. These workflows may be defined by UML activity diagram or similar process language. To define a new workflow the workflow itself has to be defined by reusing existing services and by defining the trigger rules that decide when the workflow will be executed. Parent Includes Scope Actor(s) Goal Trigger none UC-220707, UC-220223 IKS service creation. IKS Customizer A new service execution workflow is defined. A customer needs a new service execution workflow.
157 / 218
Action
Figure 8.65 Activity diagram for use case "Define service execution workflow"
UC-220707: Define execution trigger rules

Use Case ID UC-220707 [SC2] Description When defining a new service execution workflow the execution trigger rules must also be defined. They control when the workflow will be executed. Parent none
Included by UC220706 Scope Actor(s) Goal Trigger IKS service creation. IKS Customizer The trigger rules for a service execution are defined. The trigger rules for a service execution workflow needs to be customized.
UC-220708: Plug service execution workflow in IKS

Use Case ID UC-220708 [SC2] Description After defining a service execution workflow it must be plugged in the IKS and be activated for use. Parent UC002024
158 / 218
Includes Scope Actor(s) Goal Trigger
none IKS service creation. IKS Customizer The service is plugged in the IKS and available for use. The service needs to be available.

ID Requirement UC-Ref UC-220701 UC-220701 UC-220703 UC-220705 UC-220706 UC-220707
FR-220701 The IKS shall be able to link content with agents. FR-220702 The IKS shall be able to determine agents for content. FR-220703 The available agents shall be configurable. FR-220704 The decision rules for agent selection shall be configurable. FR-220705 The IKS shall be able to define workflows of service execution. FR-220706 The IKS shall be able to define triggers for the execution of a workflow.
FR-220707 The IKS shall be able to execute services within a process that is defined by UC-220706 a workflow.
INR-220701 The agent determination service shall be customizable. INR-220702 The IKS shall be able to reuse semantic services within a workflow.
INR-220703 A service execution workflow shall be plugged in the IKS like semantic ser- UC-220708 vices.

NFR-220701 The agent determination service shall be a semantic service.
NFR-220702 The available agents for the agent suggestion service shall be described UC-220704 semantically. NFR-220703 A service execution workflow itself shall be a semantic service. UC-220706
159 / 218
8.8 Change management, versions and audit (HLR-2208)

HLR ID HLR-2208 Name Change Management, Versions and Audit Description Like traditional CMS provide the functionality for content versioning and audit, the IKS must provide this concept for semantic information. All IKS services should log their actions in a way that they are comprehensible for a user (transparency) and the service should provide the possibility to undo an action. The IKS stack should also be aware of changing content and provide solutions to invalidate semantic data, e.g. a prior extracted semantic information might become invalid as the content changes. The problem of content evolution will become to a problem of semantic data evolution. The mentioned functionalities are not specific to an application domain of a CMS. Therefore, these services should be provided horizontally. Classification

Cross cutting Horizontal none Change management, notifications Transparency, discoverability, why something has been tagged-audit trail Track where the data come from, manage the source Policies for accessing the data, user authentication, opened for authentication Roles management, trust management Revisions of content Subscribe to update management
Scenario 1: The semantic data is generated and enriched in IKS Stack both by automated IKS services and user authoring as new content items are added or updated in the CMS. As content management systems consists of large amounts of semantic data and as groups of people begin to collaborate on authoring the knowledge stores, the need for some kind of version management becomes apparent since the version control is necessary for legal accountability, backup and disaster recovery. The provision of a version control mechanism will ensure that different copies of the same annotations can be kept synchronised where appropriate and that changes and updates to annotations can be managed. The annotations and semantic data available in the IKS need to be stored in versions as they are updated. The system stores versions of semantic data and annotates them with their date, time, user and adds the users' comments if applicable. Users can comment on revision history as a reminder on why the update is realized. Versioning can make it easy to see who has been working on a document, who added what and why. Furthermore, versioning can be done at the element level or at the ontology level and can include version tracking and control.
160 / 218
Scenario 2: Users can work in groups and IKS can have many simultaneous users or automated processes, which are working on the same content item at the same time. When a number of activities simultaneously realized on the same content, this may result in conflicting changes. Therefore, merging of updated ontologies, meta-data or annotations into one consistent integrated version is needed to let users work collaboratively in a much more streamlined way. The conflicts are resolved via user actions and consistent version is stored to the IKS knowledge base. While presenting the conflicts to user, the system can compare versions in-line by highlighting the parts creating conflicts. Scenario 3 User requests the versioning history of a content item's semantic data from IKS in order to visualize how the semantic features and data evolve since the IKS store will commonly be modified over time with contributions from different parties.Therefore, users get a full version history of all edits and additionally compare certain revisions of the semantic data with others. Scenario 4 Versioning also gives users the ability to revert to earlier revisions of semantic repository if necessary. The updates realized on the knowledge base items can be rolled back and user may set an earlier version as the current version. With versioning level support, the reverting may be adopted at different levels. For example, if user updates an annotation related with a content item that is available in the CMS, he/she may want to go back to the former version on that content item or the whole site. Scenario 5 IKS has a built-in notification system that allows users to be informed about events that occur on selected actions and contents. It is possible to be notified when objects are updated or published, or when workflows are executed and so on. User needs to subscribe to updates on semantic data of a content item and can follow the updates realized on the meta-data, annotation or ontology changes. Scenario 6 It is possible to automatically generate audit logs based on what the users are doing with the system. Information about various operations should be logged and stored. For example, auditing makes it possible to find out which user removed content, and so on. The IKS system provides a set of built-in audit functions that make it possible to generate audit logs for different types of activities. At minimum, for every operation, the system logs the changes that were undertaken, when, and by whom. This powerful feature also enables IKS users to undo and reverse changes if required.
161 / 218
Figure 8.66 Use Case diagram

UC-220801: Version Control [SC1, SC2, SC3, SC4] UC-220802: Present History [SC3, SC4] UC-220803: Revert to older versions [SC4] UC-220804: Merge updates [SC2] UC-220805: Send notifications [SC5] UC-220806: Audit trails [SC3, SC5, SC6]
UC-220801: Version Control

Use Case ID UC-220801: Version Control Description The content available in IKS may evolve either via users or automatic processes which are under the control of users. IKS system provides a version control mechanism which manages the changes to semantic data and domain ontology stored in IKS knowledge base. Parent -
162 / 218
Scope The scope of the version control mechanism is the IKS knowledge base, specifically the persistence layer of the IKS. Actor(s) IKS Goal The goal is to keep track of evolution of semantic data and domain ontology changes and modifications. Trigger Every time an update is realized on an item stored in IKS knowledge base. Preconditions 1. The IKS consists of a persistent knowledge base populated with semantic data instances. 2. IKS version control service can detect the update. Minimal Postconditions 1. Previous version of IKS knowledge base item is stored along with its new version. Success Postconditions 1. New version is set as current version and old version is also kept in the IKS knowledge base. Main Flow 1. Upon the trigger event for an update detection, version control starts. 2. The information related with the update such as date, time, name of the process or the user who realizes the update is retrieved to annotate the new version. 3. The new version is stored with the annotations retrieved in previous step. 4. New version is set as current version. Extensions Exceptions 1. The information related with the update such as date, time, name of the process or the user who realizes the update is stored to annotate the new version. 1. The IKS may not detect source of update Open Issues When the source of update cannot be detected, it is open issue to either keep the change or reject the update.
163 / 218
Action
Figure 8.67 Activity diagram for use case UC-220801 UC-220802: Present History
Use Case ID UC-220802: Present History Description The use case includes presenting the evolution of IKS knowledge base items on a timeline according to output of version control system. Parent UC220801:VersionControl Scope The scope of UC-220802 present history use case is the IKS knowledge base. Actor(s) IKS Goal The goal is to present the evolution history of IKS knowledge base items and enable the user to visualize the changes were undertaken, when, why and by whom. Trigger The service(s) of the IKS for presenting history is triggered upon user request. Preconditions 1. The IKS has a version control system.
164 / 218
Minimal Postconditions 1. The version history of a knowledge base item is presented or the user is informed that there is no available data. Success Postconditions 1. The version history of a knowledge base item is presented. Main Flow 1. Upon the trigger event for the initiation of presenting version history, IKS connects to the data store. 2. IKS retrieves the all version history of the requested item. 3. The IKS prepares the data model. 4. IKS GUI presents the version history. Extensions Exceptions 1. Upon the trigger event for the initiation of presenting version history, IKS connects to the data store. 1. The communication is not available. Open Issues 1. The data model and GUI for the presentation of the version history is not decided yet.
165 / 218
Action
Figure 8.68 Activity diagram for use case UC-220802 UC-220803: Revert the older versions
Use Case ID UC-220803: Revert the older versions Description The changes realized on IKS knowledge base or IKS knowledge base items are undone if an inconsistency is detected or a wrong action is taken. Parent UC220801:VersionControl Scope The scope of UC-220803 Revert the older versions is the IKS knowledge base. Actor(s) CMS administrator Goal The goal is to keep the IKS knowledge base in a consistent state and enable users to undo actions that they want to revert. Trigger The service(s) of the IKS for reverting the older versions of IKS knowledge base or IKS knowledge base items is triggered upon user request. Preconditions 1. The IKS has a version control system. 2. IKS can list version history.
166 / 218
Minimal Postconditions 1. An old version that is specified by the user is set as current version. Success Postconditions 1. An old version that is specified by the user is set as current version and update is logged along with the previous version. Main Flow 1. Upon the trigger event for the initiation of reverting an older version, IKS retrieves the version history of the item from the data store. 2. IKS presents the all version history of the requested item. 3. Upon the selection of user, the selected version is set as current version. 4. The previous version is logged along with action details. Extensions Exceptions 1. IKS presents the all version history of the requested item 1. The history is not available. Open Issues 1. The user can set either the previous version like undo action of document processing tools in every invocation of the functionality or select any version from the history as the current version. Action
167 / 218
UC-220804: Merge updates

Use Case ID UC-220804: Merge updates Description Merging of updated ontologies, meta-data or annotations into one consistent integrated version is provided to let users to work collaboratively in a much more streamlined way. Parent Scope The scope of UC-220804 Merge updates is the IKS knowledge base. Actor(s) CMS administrator Goal The goal is to keep the IKS knowledge base in a consistent state and enable users to merge two parallel versions. Trigger The service(s) of the IKS for merging updates is triggered upon user's commit action to update a version which is competing with its update. Preconditions 1. The IKS has a version control system. Minimal Postconditions 1. User is notified that there is conflicting version in the knowledge base or any internal error. Success Postconditions 1. An integrated version of two updates is stored into the knowledge base without any lost update. Main Flow 1. 2. 3. 4. IKS services detects conflict situation in the update. IKS compares two versions. IKS highlights the differences. IKS creates an integrated version based on integration points that are decided by a user. 5. An integrated version is stored into the IKS knowledge base. Extensions Exceptions 1. IKS services detect conflict situation in the update. 1. The conflict is ignored and the latest update is overwritten. Open Issues 1. The integration of two updates may be made semi-automated by the IKS semantic features.
168 / 218
Action
Figure 8.70 Activity diagram for use case UC-220804 UC-220805: Send notifications
Use Case ID UC-220805: Send notifications Description When an update is realized on the semantic data of an content item, system sends notifications consisting the update details to the users who are subscribed to notifications on that updated item. Thus, the user will be informed on the evolutions of the item on time and enabled to follow the updates. Parent Scope The scope of UC-220805 send notification is the IKS knowledge base. Actor(s) IKS Services Goal The goal is to inform interested users on updates and content changes. Trigger The service(s) of the IKS for sending notification is triggered upon update action on an item which has a subscribed user to be notified on changes. Preconditions 1. The IKS has a subscription system.
169 / 218
Minimal Postconditions Success Postconditions 1. A notification is sent to the user. Main Flow 1. IKS services detect an update on a IKS knowledge base item. 2. IKS checks the subscription list for finding users who need to be informed in case of an update. 3. IKS prepares a notification message. 4. IKS sends the message to the all subscribed users. Extensions Exceptions 1. IKS prepares a notification message. 1. IKS cannot retrieve the details of updates for preparing the notification message. Open Issues 1. The details of notification message are not decided yet.
170 / 218
Action
Figure 8.71 Activity diagram for use case UC-220805 UC-220806: Audit trails
Use Case ID UC-220806: Audit trails Description The Audit Trail is a service provided by IKS for administrators to see a summary of activities performed in the IKS knowledge base. An audit trail covers all editing, approval, and publishing actions and includes identities and timestamps for each action. Parent Scope The scope of UC-220806 Audit trails is the IKS knowledge base. Actor(s) IKS Services, CMS Administrator Goal The goal is to give a detailed account of all activity that has taken place within the IKS system.
171 / 218
Trigger An audit is logged for every activity that has taken place within the IKS system. Preconditions 1. The IKS has a logging system Minimal Postconditions Success Postconditions 1. An audit trail is saved after an activity has taken place within the IKS system. Main Flow 1. IKS services detect an activity in the IKS knowledge base item. 2. IKS retrieves the details of activity and timestamps. 3. IKS saves the audit trail. Extensions Exceptions 1. IKS retrieves the details of activity and timestamps. 1. IKS cannot retrieve the details of activity and timestamps. Open Issues Action
172 / 218

FR-220801 IKS service shall support the versioning of semantic data of the content UC-220801 items, and domain ontology in addition to CMS versioning support on content items. FR-220802 IKS Services shall compare two versions of the same IKS knowledge base UC-220801 item. UC-220804 FR-220803 IKS Services shall present the history of evolution of IKS knowledge base UC-220802 items. FR-220804 IKS Services shall propose merging options while the system or a user tries UC-220804 to commit changes on a newer version of IKS knowledge base item. FR-220805 IKS services shall support version control at different granularity level. UC-220801
FR-220806 IKS services shall revert an older version of either a part or whole IKS know- UC-220803 ledge base based on selected granularity level. FR-220807 IKS services shall automatically generate audit logs based on detected ac- UC-220806 tivities. FR-220808 IKS services shall enable a user to subscribe semantic data updates of a UC-220805 content item or domain ontology changes. FR-220809 IKS services shall have notification services, which will inform users when a UC-220805 user subscribed to be notified when semantic data of a content item or domain ontology is updated. FR-220810 The system shall provide merging mechanisms on the commit time of up- UC-220804 dates in order to provide consistency.
Data requirements
DR-220801 The knowledge base shall store the date, the time, the user and a comment UC-220801 of the user when an update is realized on semantic data of the content items, and the domain ontology. DR-220802 The knowledge base shall store the traces of the updates realized by the UC-220806 automated processes of IKS by keeping track of system generated logs, time and component name and function. DR-220803 Audit trails shall be kept for controlling the consistency of the whole know- UC-220806 ledge base.
This use case is internal to IKS stack and a standalone feature, therefore it has no integration requirements with CMS systems or other IKS requirements.
173 / 218
ID IR-220801 IR-220802 IR-220803 Requirement UC-Ref
An interface shall be implemented for presenting the conflicts that arise while UC-220804 trying to merge versions. An interface shall be implemented for presenting the history of updates. UC-220802
An interface shall be implemented for merging two versions of semantic data UC-220804 of a content item or a domain ontology. An interface shall be implemented for subscription mechanisms. UC-220805
IR-220804

ID Requirement UC-Ref UC-220801 UC-220803 UC-220804 UC-220805
NFR-220801 The user interfaces shall be user-friendly.
NFR-220802 The system shall be scalable to handle the growing size of content items UC-220806 and their semantic data. NFR-220803 The update history shall be updated in real-time in order to not to cause UC-220801 any conflicts.
8.9 Multilingualism (HLR-2209)

HLR ID HLR-2209 Name Multilingualism Description The IKS semantic services should be aware of content in different languages and provide functions to reason about information even if they are in different languages. Furthermore, the services provided by the IKS stack needs to support multilingualism for enabling a variety of users in different nationality to use the IKS. Multilingualism is an requirement of the horizontal services of IKS stack as language support independent of the CMS application domain unless the CMS is not designed for a specific language. Awareness of different languages is a feature for all IKS services. Classification

Cross cutting Horizontal none Multilingualism
174 / 218
Scenario 1 When a CMS provides content in different languages, this necessitates managing the complexity of unifying contents at the IKS stack in order to utilize the IKS services. IKS services will try to unify contents and their meta-data in a common language platform so that it becomes anchored across languages and reasoners and rule engines can use this knowledge to detect implicit knowledge and enrich the content semantically. When a content item is uploaded in a language but the domain ontology which will be related with the content item is in a different language, the content will be processed by terms extracters which are specialized to the input language and they will be translated into the language of the domain ontology to relate them with the concepts defined in the ontology. Or keywords used for search may be provided in one language and ontologies stored in the knowledge base may be in other languages, therefore for faceted search mechanisms the translation must occur and concepts in different languages must be tied up together in order to utilize semantic features of IKS. Scenario 2: A user can prefer to visualize the content and its meta data in a language that is specified by himself/herself. The implicit knowledge, which is extracted from the content items through utilizing domain ontology, needs to be presented in a language which the user sets as the presentation language. IKS multilingualism system allows workflows to be set up that facilitate the translation process either through internally or third party translation systems. Scenario 3: A user can change the language of IKS GUI to any supported. Thus, user can continue to use the IKS GUI in the selected language. The language preference of the user must be stored.
Figure 8.73 Use Case diagram

UC-220901: Relate the concepts and the ontologies in different languages [SC1] UC-220902: Translate the extracted knowledge [SC2] UC-220903: Update user interface [SC3]
175 / 218
UC-009001: Relate the concepts and the ontologies in different languages

Use Case ID UC-220901: Relate the concepts and the ontologies in different languages Description If the IKS services will be utilized for content items which are in a language that is different than the language of the related domain ontology that is available in the IKS system, the system needs to relate the concepts, the meta-data of the contents and the ontologies in different languages to a common language platform so that it becomes anchored across languages. Thus, reasoners and rule engines can use this knowledge to detect implicit knowledge and enrich the content semantically. The system will unify contents in all languages by providing a mapping to shared domain ontologies. Parent Scope The scope of UC-220901 Relate the concepts and the ontologies in different languages is the IKS knowledge base. Actor(s) IKS services Goal The goal is to make a content item that is in a language which is different than the language of the related domain ontology anchored across languages by relating it to the domain ontology. Trigger Whenever an IKS service is invoked for a content item that is in a language other than the default language of the IKS system, the system try to unify the content with the language of the domain ontology, if they are not previously associated. Preconditions 1. The IKS system is enabled to semantically lift a content item for which IKS service is invoked via RESTful interface. 2. The IKS has a domain ontology to map concepts in any supported language into one integrated version. Minimal Postconditions Success Postconditions 1. After the semantic lifting and mapping process, the content items' semantic data is translated to the language of the domain ontology and is in a state that is ready to be utilized by IKS services. Main Flow 1. Upon the trigger event for uploading a new content item upload to the CMS, if a user requests to utilize IKS services to semantically enhance the content item via RESTful services. 2. The content item is tried to parsed by special parsers to the language. 3. Extracted terms are anchored according to the domain ontology. 4. The extracted terms and their corresponding concepts in the domain language ontology are saved to the IKS Knowledge Base.
176 / 218
Extensions Exceptions 1. Extracted terms are anchored according to available domain ontology language. 1. No domain ontology is defined. Open Issues The languages which will be supported in IKS system and available term parsers will be decided. Action
UC-220902: Translate the extracted knowledge

Use Case ID UC-220902: Translate the extracted knowledge Description The semantic of content items residing in the CMS may be presented to users in a language which is selected as the presentation language for meta-data. The concepts defined by the ontology shall be translated into users selected language to let the user visualize the extracted knowledge according to rules and ontology defined in common language of the IKS system. Parent -
177 / 218
Scope The scope of translation of extracted knowledge is the IKS knowledge base. Actor(s) IKS Goal The goal is to translate the semantic data into users preferred language before presenting it. Trigger If a users preference is different than the default language of the IKS system, before presenting any result of IKS services to the user, the service is triggered to translate it. Preconditions 1. The IKS either has internal translation engine or is able to communicate with a third party translation engine. Minimal Postconditions Success Postconditions 1. The extracted semantic data for content items are presented in the language that is selected by user. Main Flow 1. Upon the trigger event for retrieving the outcome of either IKS rule engine or semantic reasoner, the service retrieves the users language preference for the presentation of semantic data. 2. If it is different than the default language, service connects to the translation engine. 3. IKS retrieves the translation of the extracted semantic knowledge. 4. The translation of extracted semantic knowledge is presented to the user. Extensions Exceptions 1. If it is different than the default language, service connects to the translation engine. 1. The translation engine is not available. 2. IKS retrieve the translation of the extracted semantic knowledge. 1. The translation of the concept is not available. Open Issues 1. The translation engines that will be connected to the IKS system will be decided.
178 / 218
Action
UC-220903: Update user interface

Use Case ID UC-220903: Update user interface Description The graphical user interfaces of the IKS system are updated according to users selection. Parent Scope The scope of translation of presentation layer is the IKS knowledge base. Actor(s) IKS Goal The goal is to translate the presentation layer into users preferred language before presenting it. Trigger If a users preference is different than the default language of the IKS system, the update of the presentation layer is triggered whenever a user is selected a language or logged in to the IKS.
179 / 218
Preconditions 1. The IKS has language profile files for the supported languages. Minimal Postconditions Success Postconditions 1. All the expressions seen in the interface of IKS system is updated with their translations in the selected language and the user is informed that the update is completed. Main Flow 1. 2. 3. 4. The service retrieves the users selection. If it is different than the default language, service retrieves the language profile file. IKS parses the profile file. The graphical user interface is updated.
Extensions Exceptions 1. If it is different than the default language, service retrieves the language profile file. 1. The profile is not available. 2. IKS parses the profile file. 1. The profile file may be corrupted. Open Issues 1. The supported languages will be decided.
180 / 218
Action

FR-220901 IKS service shall relate the concepts, the meta-data of the contents and the UC-220901 ontologies in different languages to a common language in order to enable the data consumption of rule engines and reasoners. FR-220902 IKS Services shall translate the semantic data while presenting to the user if UC-220902 the user has requested to visualize the findings in a language other than the default language of IKS. FR-220903 The user interface of the IKS services shall support multilingualism based on UC-220903 the user's preferences.
Data requirements
181 / 218
ID
Requirement
UC-Ref
DR-220901 The system shall keep a profile file for every language that is supported. The UC-220903 file shall store translations of default user interface commands and instructions and their translation. DR-220902 The system shall store users' language preferences. UC-220902 UC-220903
INR-220901 The system shall be capable of interacting with either an internal translation UC-220901 engine or a third party service for translation. UC-220902 UC-220903
ID IR-220901 IR-220902 Requirement UC-Ref
An GUI of IKS shall enable user to specify one of the supported languages UC-220902 as his/her selection. UC-220903 An interface shall be updated according to a user's preference. UC-220903

NFR-220901 The translations shall be precise and accurate.
NFR-220902 The system shall be scalable to handle the growing size of content items UC-220901 and their semantic data. UC-220902
8.10 Security (HLR-2211)

HLR ID HLR-2211 Name Security Description In CMS the content access can be configured using more or less fine grade access controls. When using semantic algorithms the IKS must consider these existing access control restrictions. Additionally the service may consider new kinds of restrictions which reflect the semantic data access, e.g. for algorithms that reason on existing data. The IKS needs a concept how to integrate permission, role and group models that normally exists as part of a CMS inside the IKS. Classification

Cross cutting Horizontal
182 / 218
none

Policies for accessing the data, user authentication, opened for authentication Roles management, trust management
Scenario 1 The CMS sends an IKS service request that contains URIs to content that should be processed by the service (see UC-220202). In this case the IKS assumes that the current user of the CMS has the rights to read the content that is specified by the URIs. The CMS would have proven the access rights before sending the IKS service request. So the IKS service can process the content without any restrictions to user rights. Scenario 2 When an IKS service needs additional information from the CMS the IKS sends a request to the CMS (see UC-220215, UC-220228). The request contains the original CMS request identifier that allows the CMS to determine the context of the request from the IKS service. Having knowledge about the context the CMS can decide which information is accessible for this particular request. Furthermore can the CMS decide which information will be included when handling the request from the IKS and which data will be sent in response. The IKS will only get access to information that is accessible in this context. This decision must be taken by the CMS because the IKS cannot decide this. The IKS has no information about the context of the original request that came from the CMS. Scenario 3 A CMS should be able to add data policy rules inside an IKS request that describe which information from the IKS content repository may be used to fulfil the request. These data policies may also be used by the IKS when requesting information from the CMS during request execution. The syntax and semantics of the data policy rules must be defined by the IKS. In this scenario data policy rules describe the kind of content or relations that may be used by the IKS service. The data rules do not describe any user attributes, roles or access rules.
183 / 218
Scenario 4 When data is stored inside the IKS content repository the access rules to this data set must be stored along. The IKS should not invent and implement a static user and role management that is unaware of existing solutions that are already in use either by the CMS or by the environment where the system is running. The IKS must provide an exchangeable solution that is able to connect custom access information to content and that calculates which rights a given authority has when trying to access a specific piece of content. An embedded IKS security framework must ensure that as much security functionality as possible can be customized. The IKS should only allow a minimum set of interfaces that control the content access rules.
184 / 218
Figure 8.78 : Use case diagram for scenario 4
Scenario 5 CMS and IKS may exchange information of high confidentiality. In these cases both CMS and IKS must provide the capability to secure the communication channel by using cryptographic technologies. This includes a pairing process between CMS and IKS to ensure that the communication partners trust each other and that communication can only take place between these trusted partners.
185 / 218
8.10.1
Use Case Descriptions
The use cases are ordered by actors: CMS o UC-221101: Exchange trust [SC5] o UC-221102: Secure communication channel [SC5] o UC-220201 : Send IKS service request [SC5]
IKS o UC-221103: Handle data policies [SC3] o UC-220207: Receive request [SC3]
IKS Service o UC-221104: Evaluate data policies [SC3] o UC-221105: Store custom data access information [SC4] o UC-220213: Execute [SC3] o UC-220218: Store data in IKS [SC4]
IKS Customizer o UC-221106: Define custom data access information [SC4] o UC-221107: Implement custom data access evaluator [SC4]
UC-221101: Exchange trust

186 / 218
Description To ensure that communication is secure between CMS and IKS both system must exchange trust information before starting any kind of communication. This process is called the pairing of CMS and IKS. Parent none Includes none Scope CMS/IKS communication Actor(s) CMS, IKS Goal CMS and IKS trust each other and allow future communication. Trigger CMS or IKS are paired.
UC-221102: Secure communication channel

Use Case ID UC-221102 [SC5] Description After ensuring that CMS and IKS trust each other each communication between the two system can be secured using cryptologic technologies. Parent none Included by UC002001 Scope CMS/IKS communication Actor(s) CMS, IKS Goal The communication between CMS and IKS is encrypted. Trigger CMS or IKS sends a request.
187 / 218
Action
Figure 8.80 Activity diagram of use case "Secure communication channel"
UC-221103: Handle data policies

Use Case ID UC-221103 [SC3] Description When an IKS request is received the IKS checks whether data policy rules were provided with the request. If there rules available they are forwarded to the IKS service that evaluates the policies during service execution. Parent none Extends UC220207 (policies) Scope The IKS request handling.
188 / 218
Actor(s) IKS Goal Available data policies are received and forwarded to the IKS service. Trigger A request with data policies was received. Action
Figure 8.81 Activity diagram of use case "Handle data policies"
UC-221104: Evaluate data policies

Use Case ID UC-221104 [SC3] Description An IKS service receives data policies and evaluates them during the service execution. The data policies define constraints on content that will be used by the IKS service.
189 / 218
Parent none Extends UC220213 (policies) Scope Service execution. Actor(s) IKS Service Goal The data policies are applied during service execution. Trigger The service is executed with data policies.
UC-221105: Store custom data access information

Use Case ID UC-221105 [SC4] Description When content is stored inside the IKS the IKS must store data access information along with that content. The format and semantics of the data access information are customizable, so thatthe IKS can be flexible adapted to different environments. Parent none Included by UC002018 Scope Service execution Actor(s) IKS Service Goal Customized data access information is stored together with the content inside the IKS. Trigger Data is stored inside the IKS. Action
Figure 8.82 Activity diagram of use case "Store custom data access information"
190 / 218
UC-221106: Define custom data access information

Use Case ID UC-221106 [SC4] Description The data access information is pretended by the IKS. Instead of that the data access information can be customized to support a wide range of environments. Parent none Includes none Scope IKS customization Actor(s) IKS Customizer Goal A new format and semantics of data access information is created and can be used by the IKS. Trigger Another kind of data access information is needed.
UC-221107: Implement custom data access evaluator

Use Case ID UC-221107 [SC4] Description When custom data access information are defined there must also be a custom implementation of the evaluation of those information. The custom evaluator ensures that the data access information are correctly interpreted. Parent none Includes none Scope IKS customization Actor(s) IKS Customizer Goal A new evaluator is implemented and ready to use by the IKS and its services. Trigger A evaluator is needed for a new kind of data access information.
8.10.2
Resulting Requirements Description
FR-221101 The IKS shall be able to exchange trust with external systems.
FR-221102 The IKS shall be able to receive service requests using an encrypted com- UC-220207 munication channel. FR-221103 The IKS shall support the handling of data policies that are received within a UC-221103 service request.
191 / 218
FR-221104 The IKS shall be able to store custom data access information when content UC-221105 is stored. FR-221105 The IKS shall be able to evaluate data policies during service execution. UC-221104
Data requirements
DR-221101 The IKS shall handle data policies.
INR-221101 The IKS shall support a pairing process between external systems and the UC-221101 IKS by exchanging trust. INR-221102 The IKS shall support implementations of custom data access evaluators. INR-221103 The IKS shall support the definition of custom data access information. UC-221107 UC-221106
ID IR-221101 IR-221102 Requirement The IKS shall support requests for pairing. The IKS shall support requests with data policies. UC-Ref UC-221101 UC-221103

NFR-221101 The IKS shall be able to restrict its communication to trusted systems. NFR-221102 The IKS shall be able to secure the used communication channels. NFR-221103 The IKS shall support data access restrictions.
192 / 218
9 Summary
The results of our work in task 2.2 are about 220 requirements for the horizontal industrial case. These requirements evolved from a systematic requirements engineering approach that started with the analysis of current CMS systems and their similarities together with the collection of industrial partners needs in the field of semantic enhancements of their systems. This proceeding ensured that the resulting requirements are founded by industrial needs, which ensures that the IKS will be developed with focus on impact for the CMS providers. The requirements refinement process starting from the identified high level requirements, then creating scenarios and extracting use cases from these scenarios and in the end extracting the resulting software requirements is a formal process that guarantees the traceability of each resulting requirement to its source in the industrial needs. This ensures that no requirement was included which has no connection to any industrial need. The next step will be the consolidation of all requirements which are gathered through the three requirements centric work packages one, two and three. This process will start with the present results of tasks 1.1, 1.2, 2.1 and 2.2. The result of this process will be a consoldidated on all requirements where cross-references and duplicates are resolved. These consolidated requirements will then form one basis for the design and implementation of the IKS.
193 / 218
10 References
IEEE830 UML RFC2119 REST IEEE Recommended Practice for Software Requirements Specification. IEEE Std. 830-1998. IEEE Computer Society. June 1998. OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2. Object Management Group. November 2007. Bradner, S. Key words for use in RFCs to Indicate Requirement Levels. BCP 14, RFC 2119. March 1997. Fielding, R. T. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis. University of California, Irvine. 2000.
NEWSSIFT http://www.newssift.com/
194 / 218
11 Annex
11.1 Original statements from industrial partners
1. Agree on a set of categories and relations, attributes as the default set 2. Help in finding the good vocabularies, Vocabulary Discovery for CMS Schema 3. Dynamic vocabularies, ontologies 4. SWAN Ontology 5. Schema importing 6. Architecture should be based on services like web services restful services not on libraries, should be independent 7. Try to leverage existing content, have a semantic layer on top of that, create a bridge, semantic restful interface between the available content and semantic layer 8. Semantic tagging 9. Semantic navigation for both consumer and author (not only hierarchical): A semantic navigation mechanism through the content items. Navigating through the subsumption or object relational properties of the content items may constitute an example for this requirement. 10. Automatic generation of micro-formats 11. Help in-editor suggestion of tags, relations between content items, suggest related content inside the CR or from outside world such as web 12. Semantically enhanced rich text editor, add a person 13. Change the presentation model based on semantic data 14. Legacy data, how to semanticize them? 15. Tagging, different for each person, rules for personalized tagging 16. Adding semantics: editor generated consumer participation or automatic extraction? 17. A particular ontology should be suggested in the tagging process of the content items 18. Automatic categorization, similarity search, similarity detection 19. Visualization of the annotations, as a graph... 20. Semantic history of navigation 21. Extract RDF statements from XML or HTML document 22. Providing API for extracting ontology from unstructured data 23. Semantically enhanced search 24. Creating a prototype search engine that understand microformats RDFA 25. User friendly RDF query. See the schema, faceted browsing, Semantically supported faceted browsing 26. Similarity search, similarity detection 27. Support for disambiguation of search
195 / 218
28. How to make distributed querying, federation of SPARQL queries 29. Notify semantic search engines about your Site, Semantic Site Map 30. Possibility to create pages by queries, Views 31. Semantic consistency checking in content management system 32. Creating the links between content items semi-automatically 33. Help in-editor suggestion of tags, relations between content items, suggest related content inside the CR or from outside world such as web 34. Instance linking, linked data cloud, whenever we create something link it with something existing.. 35. Hierarchy: group staff together 36. Intelligent content workflows, configured based on organization, hierarchy 37. Customizable workflows 38. Change management, notifications 39. Transparency, discoverability, why something has been tagged--audit trail 40. Track where the data come from, manage the source 41. Policies for accessing the data, user authentication, opened for authentication 42. Roles management, trust management 43. Revisions of content 44. Subscribe to update management 45. Multilingualism 46. Policies for accessing the data, user authentication, opened for authentication 47. Roles management, trust management
11.2 Requirements traceability matrix

This section consists of a summary of all requirements collected along the document. For clearness of arrangement the requirement are separated in the different categories: Functional (coming from uses cases)

Data Integration (describing the interaction to other components) Interface Non-functional
Depending on the category of the requirements a set of attributes will be associated to each requirement. The significants attributes are: RE-ID A unique identifier for the requirement. It will be composed of three parts: R+Type of requirement +enumerator
Requirement The explanation of the requirement.
196 / 218
Referred UC Indicates the corresponding use case from technical point of view. Liability The liability of the requirement according to [RFC2119] Status The status of the requirement, if it is proposed, validated, rejected, designed, implemented, or tested. HLR Indicates which high level requirements it belongs to.
11.2.1
ID
Functional requirements
Requirement Referred UC Liability Status HLR
HLR 2201: Common vocabulary FR220101 FR220102 FR220103 The Vocabulary shall be navi- UC-220101: Seman- SHALL gable. tically Navigate Vocabulary The Vocabulary shall be quer- UC-220102: Search MUST able. Vocabulary Item IKS shall expose related administration services on vocabulary. UC-220103: Manage MUST Vocabulary UC-220104: Add Vocabulary Item UC-220105: Remove Vocabulary Item UC-220106: Edit Vocabulary Item Proposed HLR-2201: Common vocabulary HLR-2201: Common vocabulary HLR-2201: Common vocabulary
Proposed
Proposed
FR220104 FR220105 FR220106
IKS shall process/parse the up- UC-220107: Import SHALL loaded vocabularies. External Vocabulary IKS shall provide a Vocabulary UC-220108: Align alignment algorithm. Vocabularies IKS shall suggest a number of UC-220108: Align possible alignment options. Vocabularies SHALL
Proposed
HLR-2201: Common vocabulary HLR-2201: Common vocabulary HLR-2201: Common vocabulary
Proposed
SHALL
Proposed
HLR-2202: Architecture and integration FR220201 The IKS shall support a plug-in UC-220224: Plug mechanism for semantic ser- service in IKS vices. A service execution shall be stoppable at any point of execution. MUST Proposed HLR-2202: Architecture and integration HLR-2202: Architecture and integration
FR220202
UC-220213: Execute MUST
Proposed
197 / 218
ID FR220203
Requirement
Referred UC
Liability
Status Proposed
HLR HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration
The IKS shall be able to handle UC-220208: Receive MUST feedback information from ex- feedback ternal systems. The IKS shall manage all reUC-2202027: Man- MUST quests by using unique request age request by idenidentifiers. tifier The IKS shall route each request to a service and invoke that service to handle the request. The IKS shall take the results from a service execution and send it back to the enquirer. The IKS shall be able to load content from URIs. UC-220209: Route to MUST service
FR220204
Proposed
FR220205
Proposed
FR220206
UC-220212: Send response
MUST
Proposed
FR220207
UC-220216: Load content from URIs
MUST
Proposed
FR220208
The IKS shall be able to store data inside the IKS
UC-220218: Store data in IKS
MUST
Proposed
FR220209
The IKS shall be able to store data in external systems (e.g. CMS content repository)
UC-220219: Store data in CMS
MUST
Proposed
HLR-2203: Semantic lifting & tagging FR220301 FR220302 FR220303 FR220304 FR220305 IKS services shall process un- UC-220301: Extract MUST structured data meta-data automatically IKS services shall extract meta-data from raw data UC-220301: Extract MUST meta-data automatically Proposed HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging
Proposed
IKS services shall annotate the UC-220302: Tag MUST content items with meta-data content item semantically IKS services shall handle external well-accepted data formats UC-220301: Extract MUST meta-data automatically SHALL
Proposed
Proposed
IKS services let users to navi- UC-220304: Navigate over the content items ac- gate over content cording to semantic relations. items
Proposed
198 / 218
ID FR220306
Requirement
Referred UC
Liability
Status Proposed
HLR HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging
IKS service shall create the UC-220302: Tag MUST necessary tags, annotations, content item semanrelations between the vocabu- tically lary element instances. IKS service shall generate UC-220302: Tag MUST OWL instances for the content content item semanitems and their relations. tically IKS service shall provide inUC-220303: Annoeditor help for annotating con- tate Content While tent items while creating Editing SHALL
FR220307 FR220308 FR220309
Proposed
Proposed
IKS service let user to assign UC-220302: Tag MUST tags for the content item from a content item semanvocabulary/ontology, which is tically discovered by the IKS services. IKS service let user configure UC-220306: Config- MUST semantic mapping correspond- ure Semantic Tagences between ontology con- ging structs and content items.
Proposed
FR220310
Proposed
HLR-2204: Semantic search & semantic query FR220401 The IKS shall be able to process search queries. UC-220401: Enter query MUST Proposed HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query
FR220402
The IKS shall support word UC-220412: Word sense disambiguation in quer- sense disambiguies. ation The IKS search shall be performed by processing the search features. The IKS shall be able to perform search in different sources. The IKS search shall be configurable.
SHALL
Proposed
FR220403
UC-220421: Perform MUST search
Proposed
FR220404
UC-220422: Perform SHALL search in different sources UC-220416: Config- MUST ure search
Proposed
FR220405
Proposed
FR220406
The IKS search sources shall be configurable.
UC-220417: Config- SHALL ure search sources
Proposed
199 / 218
ID FR220407
Requirement
Referred UC
Liability
Status Proposed
HLR HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query
Each IKS search features shall UC-220418: Config- MUST be configurable. ure search feature
FR220408
The IKS search features shall be arranged as a process of execution. The IKS shall be able to combine the search results from different sources.
UC-220420: Arrange MUST search features
Proposed
FR220409
UC-220429: ComSHALL bine results from different sources
Proposed
FR220410
The IKS shall be able to pres- UC-220427: Present MUST ent the search results. search results
Proposed
FR220411
The IKS shall evaluate the cur- UC-220435: Evaluate SHALL rent search result view configu- search result view ration before presenting configuration results. The IKS shall be able to pres- UC-220428: The IKS MUST ent search results for different shall be able to parse sources. search queries. The IKS shall be able to pres- UC-220431: Present SHALL ent similarities in the search Used Similarities results. The presentation of search re- UC-220434: Config- SHALL sults by the IKS shall be con- ure search result figurable. view The presentation of search re- UC-220427: Present SHALL sults by the IKS shall be desearch results tachable. The IKS shall provide the search results in a reusable way. UC-220432: Provide SHALL search results in a reusable form SHALL
Proposed
FR220412
Proposed
FR220413
Proposed
FR220414
Proposed
FR220415
Proposed
FR220416
Proposed
FR220417
The IKS shall support the re- UC-220411: Simicognition of similarities in quer- larity ies. in query detection
Proposed
200 / 218
ID FR220418
Requirement The IKS shall support the recognition of similarities in search results. The IKS shall support content browsing.
Referred UC
Liability
Status Proposed
HLR HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query
UC-220430: SimiSHALL larity in results detection UC-220436: Browse content MUST
FR220419
Proposed
FR220420
The IKS shall support browsing UC-220438: Select using different selectable browsing strategy browsing strategies The IKS shall support the defi- UC-220439: nition of custom browsing Define browsing strategies. strategy The IKS shall support faceted browsing.
SHALL
Proposed
FR220421
Proposed
FR220422
UC-220437: Faceted SHALL browsing
Proposed
FR220423
The IKS shall support the defi- UC-220440: nition of customized facets. Define browsing facets
SHALL
Proposed
FR220424
The IKS shall support the defi- UC-220433: Define a SHALL nition of customized views on custom view search results. The IKS shall support the sug- UC-220414: gestion of additional query pa- Suggest query parameters. rameters SHALL
Proposed
FR220425
Proposed
FR220426
The IKS shall be able to calcu- UC-220426: Calcu- SHALL late the estimated number of late Estimated numhits for a query. ber of hits The IKS shall offer a wizard for UC-220403: Enter entering advanced search que- wizard based query ries. The IKS shall be able to parse UC-220406: Parse search queries. query SHALL
Proposed
FR220427
Proposed
FR220428
SHALL
Proposed
201 / 218
ID FR220429
Requirement
Referred UC
Liability
Status Proposed
HLR HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query
The IKS shall be able to gen- UC-220407: Gener- SHALL erate advanced search queries ate advanced query by parsing the original query. The IKS shall be able to gen- UC-220408: Gener- SHALL erate queries formulated as ate SPARQL query SPARQL queries by parsing the original request. The IKS shall be able to store a UC-220424: Save search consisting of search Search query and configuration for later reuse. The IKS shall be able to store statistics about performed searches. SHALL
FR220430
Proposed
FR220431
Proposed
FR220432
UC-220425: Save SHALL search results statistics
Proposed
HLR-2205: Reasoning on content items FR220501 IKS service shall infer the im- UC-220501: Reason MUST plicit information existing in the on content items knowledge base through the explicit knowledge on the content items. IKS Services to provide mechanisms to register and manipulate high-level rules. The system outputs and process history shall be logged. UC-220502: Infer Business Rule MUST Proposed HLR-2205: Reasoning on content items
FR220502 FR220503
Proposed
HLR-2205: Reasoning on content items HLR-2205: Reasoning on content items
UC-220501: Reason MUST on content items UC-220502: Infer Business Rule
Proposed
HLR-2206: Links/relations among content items FR220601 The IKS shall be able to link content with content. UC-220601: Link content MUST Proposed HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items
FR220602
The IKS shall be able to link content with content that is stored inside the IKS (internal content). The IKS shall be able to link content that is stored outside the IKS (external content).
UC-220602: Link with MUST internal content
Proposed
FR220603
UC-220603: Link with MUST external content
Proposed
202 / 218
ID FR220604
Requirement
Referred UC
Liability
Status Proposed
HLR HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items
The IKS shall be able to sug- UC-220611: Suggest SHALL gest related content for linking related content for during content creation. linking The strategy for suggesting re- UC-220609: Config- SHALL lated content for linking shall ure be configurable. link suggestions The IKS shall be able to suggest internal content for linking. The IKS shall be able to suggest external content for linking. UC-220613: Suggest MUST internal content
FR220605
Proposed
FR220606
Proposed
FR220607
UC-220614: Suggest SHALL external content
Proposed
FR220608
The IKS shall use the current UC-220615: Evaluate SHALL link suggestion configuration link suggestion conwhen suggesting links. figuration The IKS shall be able to create UC-220623: Link MUST links automatically when con- content automatically tent is saved. (link@save) The IKS shall be able to create UC-220623: Link MUST links to internal content auto- content automatically matically. (link@save) The IKS shall be able to create UC-220623: Link SHALL links to external content auto- content automatically matically. (link@save) The IKS shall use the current UC-220617: Evaluate SHALL link@save configuration when link@save configuralinks are created on save. tion The IKS shall be able to inform UC-220618: Present MUST the creator about automatically created links created links. The automatic link@save cre- UC-220619: Config ation shall be configurable. link@save SHALL
Proposed
FR220609
Proposed
FR220610
Proposed
FR220611
Proposed
FR220612
Proposed
FR220613
Proposed
FR220614
Proposed
203 / 218
ID FR220615
Requirement The strategy for creating links automatically shall be configurable. The creator shall be able to modify automatically created links.
Referred UC UC-220620: Config linking strategy
Liability SHALL
Status Proposed
HLR HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items
FR220616
UC-220621: Edit links
MUST
Proposed
FR220617
The creator shall be able to se- UC-220604: Select lect the link's target. link target
MUST
Proposed
FR220618
The creator shall be able to se- UC-220605: Enter lect the link's target by entering link target's URI the target's URI.
MUST
Proposed
FR220619
The creator shall be able to se- UC-220606: Find link SHALL lect the link's target by using target the IKS search. UC-220608: Define The IKS shall support semantic semantic link type link types. The IKS shall support the defi- UC-220608: Define nition of custom semantic link semantic link type types. The IKS shall ensure that each UC-220607: Select link has a semantic link type. semantic link type MUST
Proposed
FR220620
Proposed
FR220621
SHALL
Proposed
FR220622
MUST
Proposed
HLR-2207: Workflows FR220701 FR220702 FR220703 FR220704 The IKS shall be able to link content with agents. The IKS shall be able to determine agents for contents. The available agents shall be configurable. UC-220701: Offer MUST agent determination service UC-220701: Offer MUST agent determination service UC-220703: Define SHALL available agents SHALL Proposed HLR-2207: Workflows HLR-2207: Workflows HLR-2207: Workflows HLR-2207: Workflows
Proposed
Proposed Proposed
The decision rules for suggest- UC-227005: Define ing agents shall be condecision rules for figurable. agent selection
204 / 218
ID FR220705 FR220706 FR220707
Requirement
Referred UC
Liability MUST
Status Proposed
HLR HLR-2207: Workflows HLR-2207: Workflows HLR-2207: Workflows
The IKS shall be able to define UC-220706: Define workflows of service execution. service execution workflow The IKS shall be able to define UC-220707: Define triggers for the execution of a execution trigger workflow. rules The IKS shall be able to exe- UC-220706: Define cute services within a process service execution that is defined by a workflow. workflow
MUST
Proposed
MUST
Proposed
HLR-2208: Change Management, Versions and Audit FR220801 IKS service shall support the UC-220801: Version MUST versioning of semantic data of Control the content items, and domain ontology in addition to CMS versioning support on content items. IKS Services shall compare two versions of the same IKS knowledge base item. UC-220801: Version SHALL Control UC-220804: Merge updates Proposed HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit
FR220802
Proposed
FR220803
IKS Services shall present the UC-220802: Present MUST history of evolution of IKS History knowledge base items.
Proposed
FR220804
IKS Services shall propose UC-220804: Merge merging options while the sys- updates tem or a user tries to commit changes on a newer version of IKS knowledge base item.
MUST
Proposed
FR220805
IKS services shall support ver- UC-220801: Version SHALL sion control at different granu- Control larity level.
Proposed
FR220806
IKS services shall revert an UC-220803: Revert older version of either a part or to older versions whole IKS knowledge base based on selected granularity level. IKS services shall automatiUC-220806: Audit cally generate audit logs based trails on detected activities.
MUST
Proposed
FR220807
MUST
Proposed
205 / 218
ID FR220808
Requirement
Referred UC
Liability SHALL
Status Proposed
HLR HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit
IKS services shall enable a UC-220805: Send user to subscribe semantic notifications data updates of a content item or domain ontology changes. IKS services shall have notifi- UC-220805: Send cation services, which will in- notifications form users when a user subscribed to be notified when semantic data of a content item or domain ontology is updated. The system shall provide mer- UC-220804: Merge ging mechanisms on the com- updates mit time of updates in order to provide consistency.
FR220809
SHALL
Proposed
FR220810
MUST
Proposed
HLR-2209: Multilingualism FR220901 IKS service shall relate the concepts, the meta-data of the contents and the ontologies in different languages to a common language in order to enable the data consumption of rule engines and reasoners. UC-220901: Relate MUST the concepts and the ontologies in different languages Proposed HLR-2209: Multilingualism
FR220902
IKS Services shall translate the UC-220902: Transsemantic data while presenting late the extracted to the user if the user has re- knowledge quested to visualize the findings in a language other than the default language of IKS.
MUST
Proposed
HLR-2209: Multilingualism
FR220903
The user interface of the IKS UC-220903: Update MUST services shall support multilin- user interface gualism based on the user's preferences.
Proposed
HLR-2211: Security FR221101 FR221102 The IKS shall be able to exUC-221101: Exchange trust with external sys- change trust tems. The IKS shall be able to reUC-221107: Impleceive service requests using an ment custom data encrypted communication access evaluator channel. SHALL Proposed HLR-2211: Security HLR-2211: Security
MUST
Proposed
FR221103
The IKS shall support the han- UC-221103: Handle MUST dling of data policies that are data policies received within a service request.
Proposed
HLR-2211: Security
206 / 218
ID FR221104 FR221105
Requirement The IKS shall be able to store custom data access information when content is stored.
Referred UC
Liability
Status Proposed
HLR HLR-2211: Security HLR-2211: Security
UC-221105: Store SHALL custom data access information MUST
The IKS shall be able to evalu- UC-221104: ate data policies during service Evaluate Data poliexecution. cies
Proposed
11.2.2
ID
Data requirements
Requirement Refered UC Liability Status HLR
HLR 2201: Common vocabulary DR220101 Vocabulary shall be in one of UC-220101: Seman- SHALL standard format which can be tically Navigate Voprocessed by IKS services cabulary UC-220103: Manage Vocabulary UC-220104: Add Vocabulary Item UC-220105: Remove Vocabulary Item UC-220106: Edit Vocabulary Item The externally defined vocabu- UC-220107: Import MUST lary structurally exposes a External Vocabulary well-defined model such as UC-220103: Manage OWL ontology model or Vocabulary SKOS. UC-220104: Add Vocabulary Item UC-220105: Remove Vocabulary Item UC-220106: Edit Vocabulary Item Proposed HLR 2201: Common vocabulary
DR220102
Proposed
HLR 2201: Common vocabulary
HLR-2202: Architecture and integration DR220201 IKS shall be able to handle service requests that contain lists of URIs. IKS shall be able to handle service requests that contain execution time constraints. UC-002002: Send re- MUST quest with content URIs UC-002003: Send re- MUST quest with execution time constraint MUST Proposed HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration
DR220202
Proposed
DR220203
The IKS shall define the format UC-220206: Send and semantics for feedback feedback information.
Proposed
HLR-2203: Semantic lifting & tagging
207 / 218
ID DR220301 DR220302
Requirement The content item shall stored in one of the formats that can be processed by IKS. A knowledge base shall be available.
Refered UC UC-220301: Extract meta-data automatically
Liability MUST
Status Proposed
HLR HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging
UC-220301: Extract MUST meta-data automatically UC-220303: Annotate Content While Editing
Proposed
DR220303
Ontological representations of UC-220302: Tag con- MUST meta-data and content items tent item semantically shall be kept in knowledge base. A common vocabulary shall be UC-220301: Extract MUST available. meta-data automatically UC-220302: Tag content item semantically Configurations for semantic tagging shall be defined and available for semantic lifting. UC-220306: Config- SHALL ure Semantic Tagging
Proposed
HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging
DR220304
Proposed
DR220305
Proposed
HLR-2204: Semantic search & semantic query DR220401 The IKS shall support the SPARQL format. UC-220405: Enter SPARQL query MUST Proposed HLR-2202: Architecture and integration
HLR-2205: Reasoning on content items DR220501 The knowledge base shall UC-220501: Reason MUST consist the semantic annota- on content items tions, vocabularies, ontologies and other semantic data elements related with the content items residing in the CMS. The rules shall be implemented in the system. UC-220502: Infer Business Rule MUST Proposed HLR-2205: Reasoning on content items
DR220502
Proposed
HLR-2205: Reasoning on content items
HLR-2208: Change Management, Versions and Audit DR220801 The knowledge base shall UC-220801: Version MUST store the date, the time, the Control user and a comment of the user when an update is realized on semantic data of the content items, and the domain ontology. The knowledge base shall UC-220806: Audit store the traces of the updates trails MUST Proposed HLR-2208: Change Management, Versions and Audit
DR220802
Proposed
HLR-2208: Change Man-
208 / 218
ID
Requirement realized by the automated processes of IKS by keeping track of system generated logs, time and component name and function.
Refered UC
Liability
Status
HLR Management, Versions and Audit
DR220803
Audit trails shall be kept for controlling the consistency of the whole knowledge base.
UC-220806: Audit trails
MUST
Proposed
HLR-2208: Change Management, Versions and Audit
HLR-2209: Multilingualism DR220901 The system shall keep a profile UC-220903: Update file for every language that is user interface supported. The file shall store translations of default user interface commands and instructions and their translation. The system shall store users' UC-220902: Translanguage preferences. late the extracted knowledge UC-220903: Update user interface MUST Proposed HLR-2209: Multilingualism
DR220902
MUST
Proposed
HLR-2211: Security DR221101 The IKS shall handle data poli- UC-221103: Handle cies. Data Policies MUST Proposed HLR-2209: Security
11.2.3
ID
HLR 2201: Common vocabulary INR220101 Vocabulary shall be in an accepted standard format. UC-220107: Import External Vocabulary UC-220108: Align Vocabularies SHALL Proposed HLR 2201: Common vocabulary HLR 2201: Common vocabulary
INR220102
Vocabulary instances shall be UC-220108: Align convertible to a format which Vocabularies can be processed via reasoners.
MUST
Proposed
HLR-2202: Architecture and integration INR220201 The IKS shall provide external UC-002007: Receive MUST interfaces to become usable request by other systems like a CMS. Proposed HLR-2202: Architecture and integration
209 / 218
ID INR220202
Requirement
Refered UC
Liability MUST
Status Proposed
HLR HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration
The IKS shall be extendible by UC-222021: Create custom services. service
INR220203
The external interfaces should UC-002007: Receive MUST use standardized technologies. request
Proposed
INR220204
Each IKS semantic service shall be reachable by an external interface.
UC-002007: Receive MUST request
Proposed
INR220205
The IKS semantic services UC-002001: Send shall be available as RESTful IKS service request services. The IKS shall be able to reUC-002018: Store quest information from other data in IKS external systems (e.g. a CMS, the WWW) The IKS shall be able to access the data repositories of external CMS. UC-002018: Store data in IKS
MUST
Proposed
INR220206
MUST
Proposed
INR220207
MUST
Proposed
INR220208
Each IKS service shall be cus- UC-002025: Create tomizable using service exten- service extension sion points. Custom services shall be able UC-002023: Reuse to reuse existing services. existing service
SHALL
Proposed
INR220209
SHALL
Proposed
HLR-2203: Semantic lifting & tagging INR220301 CMS systems shall be accessed through a standard methodology such as JCR. UC-220301: Extract SHALL meta-data automatically UC-220302: Tag content item semantically UC-220303: Annotate Content While Editing UC-220306: Configure Semantic Tagging Proposed HLR-2203: Semantic lifting & tagging
INR220302
The output of IKS services UC-220301: Extract MUST shall be in a format which can meta-data automatibe processed by rule engines cally and reasoners.
Proposed
210 / 218
ID INR220303
Requirement
Refered UC
Liability
Status Proposed
HLR HLR-2203: Semantic lifting & tagging
The ontology of the repository UC-220304: Navigate MUST content shall be in one of the over content items standard ontology formats. UC-220306: Configure Semantic Tagging
HLR-2204: Semantic search & semantic query INR220401 The IKS search shall be exUC-220423:Extend tendible by using/implementing search with custom custom search features. search feature MUST Proposed HLR-2204: Semantic search & semantic query
HLR-2205: Reasoning on content items INR220501 The semantic knowledge kept UC-220501: Reason MUST in the knowledge base has a on content items structure which can be processed by a reasoner. The rules shall be impleUC-220502: Infer mented in the system through Business Rule a well-defined language, such as SWRL or Jess. MUST Proposed HLR-2205: Reasoning on content items HLR-2205: Reasoning on content items
INR220502
Proposed
HLR-2206: Links/relations among content items INR220601 The strategy for creating links UC-220620: Config automatically shall be custo- linking strategy mizable by implementing custom strategies SHALL Proposed HLR-2206: Links/relation s among content items HLR-2206: Links/relation s among content items
INR220602
The strategy for suggesting UC-2206209: Config- SHALL links shall be customizable by ure implementing custom sugges- link suggestions tion strategies.
Proposed
HLR-2207: Workflows INR220701 The agent determination service shall be customizable. UC-220702: Customize agent determination service The IKS shall be able to reuse semantic services within a UC-220706: Define workflow. service execution workflow SHALL Proposed HLR-2207: Workflows
INR220702
MUST
Proposed
HLR-2207: Workflows
INR220703
A service execution workflow UC-220708: Plug MUST shall be plugged in the IKS like service semantic services. execution workflow in IKS
Proposed
HLR-2207: Workflows
211 / 218
ID INR220901
Requirement
Refered UC
Liability
Status Proposed
HLR HLR-2209: Multilingualism
The system shall be capable of UC-220901: Relate MUST interacting with either an inter- the concepts and the nal translation engine or a third ontologies in different party service for translation. languages UC-220902: Translate the extracted knowledge UC-220903: Update user interface
HLR-2211: Security INR221101 UC- 221101: ExThe IKS shall support a pairing change trust process between external systems and the IKS by exchanging trust. SHALL Proposed HLR-2211: Security
INR221102 INR221103
The IKS shall support imple- UC- 221107: Recieve SHALL mentations of custom data ac- request cess evaluators. The IKS shall support the defi- UC- 221106: Define nition of custom data access custom data access information. information SHALL
Proposed
HLR-2211: Security HLR-2211: Security
Proposed
11.2.4
ID
HLR 2201: Common vocabulary IR220101 IR220102 An interface shall be implemented for presenting list of Vocabularies UC-220101: Seman- MUST tically Navigate Vocabulary Proposed HLR 2201: Common vocabulary HLR 2201: Common vocabulary
An interface shall be impleUC-220101: Seman- MUST mented for presenting Vocabu- tically Navigate Volaries and its structural cabulary organization UC-220103: Manage Vocabulary An interface shall be implemented for presenting/editing Vocabulary Items UC-220103: Manage MUST Vocabulary UC-220104: Add Vocabulary Item UC-220105: Remove Vocabulary Item UC-220106: Edit Vocabulary Item MUST
Proposed
IR220103
Proposed
IR220104
An interface shall be impleUC-220102: Search mented for query construction. Vocabulary Item
Proposed
212 / 218
ID IR220105 IR220106
Requirement
Refered UC
Liability
Status Proposed
HLR HLR 2201: Common vocabulary HLR 2201: Common vocabulary
An interface shall be impleUC-220107: Import SHALL mented for Vocabulary import. External Vocabulary An interface for possible vocabulary alignment options shall be implemented. UC-220108: Align Vocabularies SHALL
Proposed
HLR-2202: Architecture and integration IR220201 The external IKS interfaces shall support sychronous communication using the request/response paradigm. The external IKS requests/responses shall use a standard technology (e.g. SOAP over HTTP) UC-220207: Receive MUST request Proposed HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration
IR220202
UC-220207: Receive MUST request
Proposed
IR220203
The external IKS interface may UC-220207: Receive MUST support asynchronous comrequest munication, e.g. for long running processes
Proposed
HLR-2203: Semantic lifting & tagging IR220301 IR220302 IR220303 IR220304 IR220305 An interface for assigning tags UC-220302: Tag con- MUST shall be implemented. tent item semantically An interface for suggesting possible tags shall be implemented. For navigating over the data an interface shall be implemented. UC-220302: Tag con- MUST tent item semantically UC-220302: Tag con- MUST tent item semantically Proposed HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging
Proposed
Proposed
Interfaces shall be impleUC-220302: Tag con- MUST mented for presenting user re- tent item semantically lated ontologies/taxonomies. For each semantic tagging configuration option an interface shall be implemented. UC-220306: Config- SHALL ure Semantic Tagging
Proposed
Proposed
HLR-2204: Semantic search & semantic query IR220401 The IKS shall be able to process novice search queries. UC-220402: Enter novice query MUST Proposed HLR-2204: Semantic search & semantic query
213 / 218
ID IR220402
Requirement
Refered UC
Liability SHALL
Status Proposed
HLR HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query
The IKS shall be able to pro- UC-220403: Enter cess wizard based search que- wizard ries. based query The IKS shall be able to pro- UC-220404: Enter cess advanced search queries advanced query
IR220403
MUST
Proposed
IR220404
The IKS shall be able to process search queries formulated using SPARQL.
UC-220405: Enter SPARQL query
MUST
Proposed
HLR-2205: Reasoning on content items IR220501 An interface shall be impleUC-220501: Reason MUST mented for presenting the user on content items the findings of rule engine or reasoner An interface shall be implemented for requesting the approval of the user before registering them to knowledge base. UC-220501: Reason MUST on content items UC-220502: Infer Business Rule Proposed HLR-2205: Reasoning on content items HLR-2205: Reasoning on content items
IR220502
Proposed
HLR-2208: Change Management, Versions and Audit IR220601 An interface shall be impleUC-220804: Merge mented for presenting the con- updates flicts that arise while trying to merge versions. SHALL Proposed HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit
IR220602
An interface shall be impleMUST mented for presenting the his- UC-220802: Present tory of updates. History
Proposed
IR220603
An interface shall be implemented for merging two versions of semantic data of a content item or a domain ontology. An interface shall be implemented for subscription mechanisms.
UC-220804: Merge updates
MUST
Proposed
IR220604
UC-220805: Send no- MUST tifications
Proposed
214 / 218
ID IR220901
Requirement An GUI of IKS shall enable user to specify one of the supported languages as his/her selection. An interface shall be updated according to a user's preference.
Refered UC UC-220902: Translate the extracted knowledge UC-220903: Update user interface UC-220903: Update user interface
Liability MUST
Status Proposed
HLR HLR-2209: Multilingualism
IR220902
MUST
Proposed
HLR-2211: Security IR221101 IR221102 The IKS shall support requests UC-221101: Exfor pairing. change trust The IKS shall support requests UC-221103: Handle with data policies. data policies SHALL MUST Proposed Proposed HLR-2211: Security HLR-2211: Security
11.2.5
ID
Non-Functional requirements
HLR 2201: Common vocabulary NFR220101 Vocabularies shall always be accessible. UC-220101: Seman- MUST tically Navigate Vocabulary UC-220103: Manage Vocabulary UC-220104: Add Vocabulary Item UC-220105: Remove Vocabulary Item UC-220106: Edit Vocabulary Item MUST Proposed HLR 2201: Common vocabulary
NFR220102 NFR220103 NFR220104
Vocabulary search shall have UC-220102: Search a reasonable response time. Vocabulary Item Query construction interface shall hide technical details from non-expert user. UC-220102: Search Vocabulary Item
Proposed
HLR 2201: Common vocabulary HLR 2201: Common vocabulary HLR 2201: Common vocabulary
MUST
Proposed
Vocabulary search shall have UC-220102: Search high precision and recall rate. Vocabulary Item
SHALL
Proposed
215 / 218
ID NFR220105
Requirement
Refered UC
Liability
Status Proposed
HLR HLR 2201: Common vocabulary
After vocabulary administration UC-220103: Manage MUST the IKS knowledge store shall Vocabulary be kept in a consistent state by UC-220104: Add VoIKS services. cabulary Item UC-220105: Remove Vocabulary Item UC-220106: Edit Vocabulary Item Vocabulary Alignment Algor- UC-220108: Align ithm shall provide accurate re- Vocabularies sults. SHALL
NFR220106
Proposed
HLR-2202: Architecture and integration NFR220201 The IKS shall consist of semantic services. UC:220211:Invoke service MUST Proposed HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration
NFR220202
IKS semantic services shall be UC-220224: Plug ser- MUST replaceable. vice in IKS
Proposed
NFR220203
When an IKS service is exe- UC-220213: Execute MUST cuted with time constraints and the time is up, the service execution has to stop immediately and all bound resources have to be released. The IKS shall provide a service UC-220220: Read MUST specification that defines for- IKS service specificamats and structures of IKS tion services. Each IKS service must be con- UC-220220: Read MUST form to the IKS service specifi- IKS service specificacation. tion The service extension points must be described in a format that is defined by the IKS service specification. IKS services shall be reusable. UC-220220: Read MUST IKS service specification UC-220225: Create service extension UC-220223: Reuse existing service MUST
Proposed
NFR220204
Proposed
HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration HLR-2202: Architecture and integration
NFR220205
Proposed
NFR220206
Proposed
NFR220207
Proposed
216 / 218
ID NFR220208
Requirement
Refered UC
Liability
Status Proposed
HLR HLR-2202: Architecture and integration
The IKS shall always be able UC-220207: Receive MUST to receive new requests, request i.e. the external interface shall not be blocked by any running request processing to allow high availability.
HLR-2203: Semantic lifting & tagging NFR220301 Content tagging shall be reUC-220301: Extract MUST sponsive, it shall recommend meta-data automatisome tags before user com- cally pleted the process of assigning UC-220303: Annotate some tag values. Content While Editing UC-220302: Tag content item semantically The extracted meta-data shall UC-220301: Extract be accurate. meta-data automatically SHALL Proposed HLR-2203: Semantic lifting & tagging
NFR220302 NFR220303
Proposed
HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging HLR-2203: Semantic lifting & tagging
The system shall be scalable. UC-220302: Tag con- MUST tent item semantically UC-220303: Annotate Content While Editing The data navigation interfaces UC-220304: Navigate SHALL shall be flexible and interactive over content items to handle users requests at the time of submission.
Proposed
NFR220304
Proposed
HLR-2204: Semantic search & semantic query NFR220401 The IKS shall be usable for consumers with all levels of knowledge about semantic search technologies. UC-220401: Enter query SHALL Proposed HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query
NFR220402
The IKS shall support different UC-220401: Enter kinds of search queries for dif- query ferent kinds of users The IKS search shall be a se- UC-220415: mantic service.
SHALL
Proposed
NFR220403
MUST
Proposed
NFR220404
The IKS search shall be com- UC-220419: Select posed of customizable search search features features.
SHALL
Proposed
217 / 218
ID NFR220405
Requirement
Refered UC
Liability
Status Proposed
HLR HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query HLR-2204: Semantic search & semantic query
The IKS word sense disamUC-220412: Word SHALL biguation functionality shall be sense disambiguation a semantic service. The IKS similarity recognition SHALL functionality shall be a seman- UC-220411: Similarity tic service. in query detection The IKS suggestion of query UC-220414: parameters shall be a seman- Suggest query patic service. rameters MUST
NFR220406
Proposed
NFR220407
Proposed
NFR220408
The IKS similarity in search UC-220430: Similarity SHALL results recognition functionality in results detection shall be a semantic service.
Proposed
HLR-2205: Reasoning on content items NFR220501 The user interfaces shall be user-friendly. UC-220501: Reason MUST on content items UC-220502: Infer Business Rule Proposed HLR-2205: Reasoning on content items HLR-2205: Reasoning on content items
NFR220502
The system shall be scalable UC-220501: Reason MUST to handle the growing size of on content items content items and their seman- UC-220502: Infer tic data. Business Rule
Proposed
HLR-2206: Links/relations among content items NFR220601 The IKS shall be able to link UC-220607: Select content by using types of links semantic link type that express a semantic relationship between content. MUST Proposed HLR-2206: Links/relation s among content items
HLR-2207: Workflows NFR220701 NFR220702 NFR220703 The agent suggestion service UC-220701: Offer shall be a semantic service. agent determination service MUST Proposed HLR-2207: Workflows HLR-2207: Workflows HLR-2207: Workflows
The available agents for the UC-220704: Describe MUST agent suggestion service shall agents semantically be described semantically. A service execution workflow itself shall be a semantic service. UC-220706: Define service execution workflow MUST
Proposed
Proposed
HLR-2208: Change Management, Versions and Audit
218 / 218
ID NFR220801
Requirement The user interfaces shall be user-friendly.
Refered UC
Liability
Status Proposed
HLR HLR-2208: Change Management, Versions and Audit
UC-220801: Version SHALL Control UC-220803: Revert to older versions UC-220804: Merge updates UC-220805: Send notifications MUST
NFR220802
The system shall be scalable UC-220806: Audit to handle the growing size of trails content items and their semantic data.
Proposed
HLR-2208: Change Management, Versions and Audit HLR-2208: Change Management, Versions and Audit
NFR220803
The update history shall be UC-220801: Version MUST updated in real-time in order to Control not to cause any conflicts.
Proposed
HLR-2209: Multilingualism NFR220901 The translations shall be precise and accurate. UC-220901: Relate MUST the concepts and the ontologies in different languages UC-220902: Translate the extracted knowledge UC-220903: Update user interface Proposed HLR-2209: Multilingualism
NFR220902
The system shall be scalable UC-220901: Relate MUST to handle the growing size of the concepts and the content items and their seman- ontologies in different tic data. languages UC-220902: Translate the extracted knowledge
Proposed
HLR-2211: Security NFR221101 NFR221102 NFR221103 The IKS shall be able to restrict its communication to trusted systems. UC-221101: Exchange trust MUST Proposed HLR-2211: Security HLR-2211: Security HLR-2211: Security
The IKS shall be able to seUC-221102: Secure MUST cure the used communication communication chanchannels. nel The IKS shall support data ac- UC-221103: Handle cess restrictions. data policies MUST
Proposed
Proposed

Requirements Specifications of The Horizontal Industrial Use Case

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Specifications of The Horizontal Industrial Use Case

Uploaded by

Copyright:

Available Formats

1 / 218

Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case

Requirements Specification of the

Interactive Knowledge Stack for Semantic Content Management Systems

2009-12-11 2009-12-18 2010-02-05 2010-02-15 2010-02-19 2010-03-01 2010-03-04

Document context information

Quality Assurance / Review

Figure 2.1 Layers of the IKS Stack

5 Document structure and concepts

6 Requirements specification process

6.1 Existing CMS

6.1.1 Managed content

6.1.2 Content workflow

Figure 6.1 From content creation to publishing

Figure 6.2 Search

6.1.3 Existing content services

6.1.4 Architectural view

Figure 6.3: Abstract architectural view on existing CMS

6.2 Statements from industrial partners

6.3 Defining high level requirements

Common vocabulary (HLR-2201) Semantic lifting & tagging (HLR-2203)

6.4 The refinement process

Figure 6.6 Refinement process from HLRs to resulting requirements

Figure 7.1 Actors overview

Short name CMS

Content con- Consumer sumer

Content cre- Creator ator

Developer IKS oper

8 High Level Requirements

8.1 Architecture and integration (HLR-2202)

Cross cutting Horizontal

Related requirements Statements

Figure 8.1 Use case diagram for scenario 1

Figure 8.2 Use case diagram for scenario 2

Figure 8.3 Use case diagram for scenario 3

Figure 8.4 Use case diagram for scenario 4

Figure 8.5 Use case diagram for scenario 5

Figure 8.6 Use case diagram for scenario 6

Figure 8.7 Use case diagram for scenario 7

Figure 8.8 Use case diagram for scenario 8

Figure 8.9 Use case diagram for scenario 9

8.1.1 Use Case Descriptions

UC-220201: Send IKS service request

UC-220202: Send request with content URIs

UC-220203: Send request with execution time constraint

UC-220204: Perform IKS request

UC-220205: Perform IKS storage request

UC-220206: Send feedback

UC-220207: Receive request

Figure 8.10 Activity diagram for use case "Receive request"

UC-220227: Manage request by identifier

UC-220208: Receive feedback

UC-220209: Route to service

UC-220210: Route feedback to service

UC-220211: Invoke service

UC-220212: Send response

Figure 8.11 Activity diagram for use case "Execute"

UC-220214: Cancel execution when time is up

UC-220228: Send CMS request

UC-220215: Request information from CMS

UC-220216: Load content from URIs

UC-220217: Store data