WP2 Concept, Requirements & Specification. D2.5: Technical Specification

Transcription

1 WP2 Concept, Requirements & Specification D2.5: Technical Specification Deliverable Lead: WORLD Contributing Partners: ASC, ATOS, CHA, AITEX, TUDA, NFE, TALK, ESE, TIE, IESE Delivery 09/2014 Dissemination Level: Public Version 1.0 This document provides an in-depth technical definition of all ALFRED software components and their subcomponents, including the technical specification of the provided interfaces. Furthermore, it documents the defined app and service data models as well as the technologies chosen as foundation for the implementations of the ALFRED software components.

2 Status Deliverable Lead Internal Reviewer 1 Internal Reviewer 2 Type Work Package ID Sergi Castillo, WORLD Michael Krummen, ASC Laila Shoukry, Stefan Krepp, Tim Dutz, TUDA Deliverable WP2: Concept, Requirements & Specification D2.5: Technical Specification Due Date Delivery Date Status For Approval History Contributions V0.1, WORLD, V0.2, WORLD, TALK, V0.3, WORLD, TALK, TIE, AITEX, ASC, TUDA, V0.4, WORLD, TALK, TIE, AITEX, ASC, TUDA, V0.5, WORLD, TALK, TIE, AITEX, ASC, TUDA, V0.6, WORLD, TALK, TIE, AITEX, ASC, TUDA, V0.7, WORLD, ASC, V0.8, TALK, V0.9, WORLD, TIE, ASC, TUDA, V0.10, WORLD, Final Version V1.0, ASC, TUDA, Note This deliverable is subject to final acceptance by the European Commission. Disclaimer The views represented in this document only reflect the views of the authors and not the views of the European Union. The European Union is not liable for any use that may be made of the information contained in this document. Furthermore, the information is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user of the information uses it at its sole risk and liability. 2 / 305

3 Project Partners Ascora GmbH, Germany Atos Spain sau, Spain Worldline, Spain Charité - Universitätsmedizin Berlin - Department of Geriatrics, Germany Asociacion de Investigacion de la Industria Textil, Spain Technische Universität Darmstadt, Germany National Foundation for the Elderly, The Netherlands Talkamatic AB, Sweden E-Seniors, France TIE Nederland N.V., The Netherlands IESE Business School, Spain 3 / 305

4 Executive Summary The objective of this deliverable is to describe the technical characteristics of the ALFRED system. It is aimed at the technical partners as a support for them in their component developments and the implementation of their interfaces in future WP s. The deliverable covers aspects ranging from the most general overview of the ALFRED system to the most detailed characteristics of each component. The first section, System Overview, provides a global description about the whole ALFRED system, including the architecture global vision, the relationship with the main components of ALFRED system, and a table with the dependencies between components. Afterwards, a section dedicated to the Major Design Principles is presented, describing the decisions adopted to implement several software components along the ALFRED system. Security and Privacy mechanisms and responsibilities are identified, interfaces based in Java and RESTful for the communication between components have been adopted and JavaScript Object Notation has been chosen in order to exchange information between the components. In the Technical Specification section a whole technical description is given. The first part of the section provides a general description of the technical specifications as such, the second part provides the description of the common solutions shared by several components in ALFRED, and finally, for every component that compounds ALFRED, a depth and exhaustive technical description is presented. For each component, different market solutions are identified and evaluated and the most scored solutions are chosen to include them in the ALFRED system. Finally, a Conclusions and Next Steps section describes the summary of this document and proposes it as the starting point to guide the development of WP3 (ALFRED Core) and WP4 WP7 (Pillars I-IV). 4 / 305

5 Table of Contents 1 Introduction ALFRED Project Overview Deliverable Purpose, Scope and Context Status and Target Audience Abbreviations and Glossary Structure System Overview Architecture Components Dependencies between Components Major Design Principles Security and Privacy Java-based Interfaces RESTful Interfaces JavaScript Object Notation Technical Specification General of Technical Specification Technical Specification Major Design Decisions Technology Comparison Technology Selection Component Structure Interfaces Consumed Services Summary Generic Comparison Criteria Common Solutions Operating System Major Design Decisions Technology Comparison Comparison Criteria Possible Technologies and Comparison Technology Selection Personal Assistant Major Design Decisions Technology Comparison Framework Runtime Environment Component Structure Settings View Red Button -View Suggestion Manager Interfaces Service Application priorities Permissions Sensor Categories Consumed Services / 305

6 4.3.6 Summary Health Monitor Major Design Decisions Technology Comparison Comparison Criteria Possible Technologies and Comparison Technology Selection Component Structure The Sensor Abstraction Framework (SAF) The Health Monitor Client (HMC) The Health Monitor Server (HMS) Interfaces Java interface of the SAF API Wrapper RESTful Interfaces of the Health Monitor Consumed Services The Sensor Abstraction Framework (SAF) The Health Monitor Client (HMC) The Health Monitor Server (HMS) Summary Context-aware Dialogue Engine Major Design Decisions Open or Grammar Based Speech Recognizer Embedded or Cloud Based Dialogue Management Technology Comparison Dialogue Management Session Management Automatic Speech Recogniser (ASR) Text-To-Speech Synthesizer (TTS) Technology Selection Dialogue Management Session Management Automatic Speech Recognition Text-To-Speech Synthesis Component Structure Design-Time Subcomponents Runtime Subcomponents Interfaces Enabled App PTT Activated Option Selected Started Activity Stopped Activity Consumed Services Summary / 305

7 4.6 ALFREDO Marketplace Major Design Decisions Technology Comparison Comparison Criteria Possible Technologies and Comparison ALFREDO App Marketplace Possible Technologies and Comparison ALFREDO Web Marketplace Technology Selection Technology Selection for ALFREDO App Marketplace Technology Selection for ALFREDO Web Marketplace Component Structure Interfaces Java Interfaces of the ALFREDO Marketplace RESTful Interfaces of the ALFREDO Marketplace Consumed Services Summary Personalization Manager Major Design Decisions Technology Comparison Comparison Criteria Possible Technologies and Comparison Machine Learning Technology Selection Component Structure Interfaces Java Interfaces of the Personalization Manager RESTful Interfaces of the Personalization Manager Consumed Services Summary Event Manager Major Design Decisions Technology Comparison Comparison Criteria Possible Technologies and Comparison - Event Crawler Possible Technologies and Comparison Event Miner Technology Selection Technology Selection for Event Crawler Technology Selection for Event Miner Component Structure Interfaces Java Interfaces of the Event Manager RESTful Interfaces of the Event Manager Consumed Services Summary Game Manager Major Design Decisions Requirements for ALFRED-ready games Game Suggestion Mechanisms Metadata Format for Games Technology Comparison Technology Selection Component Structure / 305

8 4.9.5 Interfaces Consumed Services Summary Knowledge and Information Storage Major Design Decisions Technology Comparison Semi-Structured Data Storage Technologies Semantic Data Storage Technologies Binary Data Storage Technologies Technology Selection Semi-Structured Data Storage Semantic Data Storage Binary Data Storage Component Structure Overview Encryption Access Control List Interfaces Java Interfaces RESTful Interfaces Consumed Services Summary Web Portal Major Design Decisions Web Portal Frame Health Monitor View Event Manager View ALFREDO Marketplace View User Management View Web Portal Backend Technology Comparison Web Portal Frontend Web Portal Backend Technology Selection Selection for the Web Portal Frontend Selection for the Web Portal Server Backend Component Structure Client Components Backend Components Data Structure Interfaces Web Portal Home Page Authentication Server API Consumed Services Summary Conclusions and Next Steps References / 305

9 List of Figures, Tables and Listings List of Figures Figure 1: Architecture of the ALFRED System Figure 2: Common Solutions Smartphone OS Sales Share in the EU5 in (Q1 2014) Figure 3: PA - Relationship between the PA, Service and External Components Figure 4: Health Monitor Health Monitor Component Structure Figure 5: Health Monitor SAF Class Diagram Figure 6: Health Monitor HMC Class Diagram Figure 7: Health Monitor HMS Class Diagram Figure 8: Health Monitor Health Monitor Class Diagram Figure 9: Health Monitor Data Postprocess Subdiagram Figure 10: Health Monitor Health Profile Subdiagram Figure 11: Health Monitor Configurator Subdiagram Figure 12: Health Monitor Alarm Subdiagram Figure 13: Health Monitor Data Analysis Subdiagram Figure 14: CADE - Component Structure Figure 15: ALFREDO - Marketplace Subcomponents Figure 16: ALFREDO - Class Diagram of App Manager Subcomponent Figure 17: Personalization Manager - Personalization Manager Component Structure Figure 18: Event Manager - Component Structure Figure 19: Game Manager - Component Structure Figure 20: KIS - Component Overview of the Knowledge and Information Storage Figure 21: Web Portal - Mockup of the Web Portal Home Page Figure 22: Web Portal - Mockup for the Web Portal Health Monitor View Figure 23: Web Portal - Mockup for the Web Portal Event Manager View Figure 24: Web Portal - Mockup of the User Management View Figure 25: Web Portal - Component Structure List of Tables Table 1: System Overview Dependencies between ALFRED components Table 2: General Generic Comparison Criteria Table 3: Common Solutions Specific Criteria for the Operating System Table 4: Common Solutions Comparison of Criteria for Operating System Table 5: Personal Assistant Specific Criteria for the Framework Table 6: Personal Assistant Comparison of Criteria for Framework as Basis for the Mobile Assistant Foundation Table 7: Personal Assistant Specific Criteria for the Runtime Environment Table 8: Personal Assistant Comparison of Criteria for the Runtime Environment Table 9: Personal Assistant Specific Criteria for the Suggestion Manager s Communication Table 10: Personal Assistant Comparison of Criteria for the Suggestion Manager s Communication Table 11: Health Monitor Criteria for Technical Specification Table 12: Health Monitor Comparison of Technologies for the Health Monitor / 305

10 Table 13: Health Monitor RESTful Interface Upload Data Table 14: Health Monitor RESTful Interface Add Medical Record Table 15: Health Monitor RESTful Interface Find My Medical Records Table 16: Health Monitor RESTful Interface Find My Medical Records by Patient Table 17: Health Monitor RESTful Interface Remove Medical Record Table 18: Health Monitor RESTful Interface Add Permission Carer Table 19: Health Monitor RESTful Interface Find My Carers Table 20: Health Monitor RESTful Interface Find My Carers Permissions Table 21: Health Monitor RESTful Interface Find My Patients Table 22: Health Monitor RESTful Interface Find My Patient Permissions.. 82 Table 23: Health Monitor RESTful Interface Remove Permission Table 24: Health Monitor RESTful Interface Add Sensor Table 25: Health Monitor RESTful Interface Update Sensor Table 26: Health Monitor RESTful Interface Find Sensor by Id Table 27: Health Monitor RESTful Interface Find Sensor by Criteria Table 28: Health Monitor RESTful Interface Find Sensor by Patient Table 29: Health Monitor RESTful Interface Remove Sensor Table 30: Health Monitor RESTful Interface Attach Sensor Table 31: Health Monitor RESTful Interface Detach Sensor Table 32: Health Monitor RESTful Interface Add Anomaly Configuration Table 33: Health Monitor RESTful Interface Update Anomaly Configuration Table 34: Health Monitor RESTful Interface Find Anomaly Configurations.. 97 Table 35: Health Monitor RESTful Interface Remove Anomaly Configuration Table 36: Health Monitor RESTful Interface Add Alarm Configuration Table 37: Health Monitor RESTful Interface Update Alarm Configuration. 100 Table 38: Health Monitor RESTful Interface Find Alarm Configurations Table 39: Health Monitor RESTful Interface Find Alarm Configuration by Id Table 40: Health Monitor RESTful Interface Remove Alarm Configuration 104 Table 41: Health Monitor RESTful Interface Find Alarms Table 42: Health Monitor RESTful Interface Remove Alarm Table 43: Health Monitor RESTful Interface Add Alarm Tracking Table 44: Health Monitor RESTful Interface Find Alarm Tracking Table 45: Health Monitor RESTful Interface Find Alarm Tracking by Id Table 46: Health Monitor RESTful Interface Remove Alarm Tracking Table 47: Health Monitor RESTful Interface Find Data Table 48: Health Monitor RESTful Interface Analyze Data Table 49: Health Monitor RESTful Interface Remove Data Table 50: Health Monitor RESTful Interface Find Anomalies Table 51: Health Monitor RESTful Interface Remove Anomaly Table 52: Health Monitor RESTful Interface Remove Anomalies Table 53: CADE - Criteria for Technical Specification of Automatic Speech Recognizer 120 Table 54: CADE - Comparison of Technologies for Automatic Speech Recognizer Table 55: CADE - Criteria for Technical Specification of Text-To-Speech Synthesizer Table 56: CADE - Comparison of Technologies for Automatic Speech Recognizer / 305

11 Table 57: ALFREDO - Criteria for Technical Specification Table 58: ALFREDO - Comparison of Technologies for the ALFREDO App Marketplace Table 59: ALFREDO - Comparison of Technologies for the ALFREDO Web Marketplace Table 60: ALFREDO RESTful Interface Information of an App Table 61: ALFREDO RESTful Interface Information of an App by Version 146 Table 62: ALFREDO RESTful Interface Get List of Installed Apps Table 63: ALFREDO RESTful Interface Update list of Installed Apps Table 64: ALFREDO RESTful Interface Binary of an App Table 65: ALFREDO RESTful Interface App Search Table 66: ALFREDO RESTful Interface App Search by Category Table 67: ALFREDO RESTful Interface App Search by Words Table 68: ALFREDO RESTful Interface App Search under Review Table 69: ALFREDO RESTful Interface Rate App Table 70: Personalization Manager - Comparison Criteria for the Personalization Manager Components Table 71: Personalization Manager - Comparison of Technologies for the Machine Learning Technologies Table 72: Personalization Manager RESTful Interface Create User Profile Table 73: Personalization Manager RESTful Interface Retrieve User Profile Table 74: Personalization Manager RESTful Interface Update User Profile Table 75: Personalization Manager RESTful Interface Delete User Profile183 Table 76: Personalization Manager RESTful Interface Search User Profiles Table 77: Personalization Manager RESTful Interface Retrieving Part of the User Profile Information Table 78: Personalization Manager RESTful Interface Subscribe for Recommendations Table 79: Personalization Manager RESTful Interface Unsubscribe from Recommendations Table 80: Personalization Manager RESTful Interface Request Recommendation Table 81: Personalization Manager RESTful Interface Retrieve User s Contacts Information Filtered by Table 82: Personalization Manager RESTful Interface Retrieve User s Contacts Information Filtered by Relation Table 83: Event Manager - Criteria for Technical Specification for the Event Manager Components Table 84: Event Manager - Comparison of Technologies for the Search Engine Technologies Table 85: Event Manager - Comparison of Technologies for the Text-Search platforms. 201 Table 86: Event Manager RESTful Interface Submit Event Table 87: Event Manager RESTful Interface Retrieve and Event from the Knowledge Base / 305

12 Table 88: Event Manager RESTful Interface Search Events in the Events Knowledge Base Table 89: Event Manager RESTful Interface Search Events Mined from the Web Table 90: Event Manager RESTful Interface Delete Event from the Events Knowledge Base Table 91: Event Manager RESTful Interface Save Event in the Events Knowledge Base Table 92: Event Manager RESTful Interface Discard Submitted Event Table 93: Event Manager RESTful Interface Update Event in the Events Knowledge Base Table 94: Event Manager RESTful Interface Delete Outdated Events Table 95: Event Manager RESTful Interface Add Website for Event Extraction Table 96: Event Manager RESTful Interface Remove Website from Event Extraction Table 97: Event Manager RESTful Interface Create User Profile Table 98: Event Manager RESTful Interface Retrieve User Profile Table 99: Event Manager RESTful Interface Update User Profile Table 100: Event Manager RESTful Interface Delete User Profile Table 101: KIS - Shared Criteria for Technical Specification Storage Technologies Table 102: KIS - Comparison of Technologies for Semi-Structured Data Storage Table 103: Comparison of Technologies for Semantic Data Table 104: KIS - Comparison of Technologies for Binary Data Storage Table 105: KIS RESTful Interface Create Bucket Table 106: KIS RESTful Interface Delete Bucket Table 107: KIS RESTful Interface Add Access Right to Bucket Table 108: KIS RESTful Interface Remove Access Right from Bucket Table 109: KIS RESTful Interface Get Access Right for Bucket Table 110: KIS RESTful Interface CRUD-Operation Create Table 111: KIS RESTful Interface CRUD-Operation Read Table 112: KIS RESTful Interface CRUD-Operation Update Table 113: KIS RESTful Interface CRUD-Operation Delete Table 114: KIS RESTful Interface Generic Query Table 115: Web Portal - Adjusted Technology Selection Criteria for the Web Portal Frontend Table 116: Web Portal - Technology Comparison for the Web Portal Frontend Table 117: Web Portal - Special Comparison Criteria for the Web Portal Backend Table 118: Technologies Comparison for the Web Portal Backend Table 119: Web Portal - View, Controller and Validation Directives Table 120: Web Portal - Access Rights Table 121: Web Portal - REST Resource to Login a User Table 122: Web Portal - REST Resource for User Logout Table 123: REST Resource for Authentication / 305

13 Listings Listing 1: Personal Assistant Binding to the Service Listing 2: Personal Assistant Sending a Message to the Service Listing 3: Personal Assistant Register an App to the Personal Assistant Listing 4: Personal Assistant Enumeration Skeleton for the Communication Listing 5: Personal Assistant Enumeration depicting the possible application priorities Listing 6: Health Monitor Java Interface Register Driver Listing 7: Health Monitor Java Interface Unregister Driver Listing 8: Health Monitor Java Interface Register Listener Listing 9: Health Monitor Java Interface Unregister Listener Listing 10: Health Monitor Java Interface Supports URL Listing 11: Health Monitor Java Interface Get Metainfo Listing 12: Health Monitor Java Interface Bind Listing 13: Health Monitor Java Interface Unbind Sensor Listing 14: Health Monitor Java Interface Read Measurement Listing 15: Health Monitor Java Interface Write Information Listing 16: Health Monitor Java Interface Get Properties Listing 17: Health Monitor Java Interface Receive Measurement Listing 18: Health Monitor - Example JSON Supplied for the Upload Data Operation Listing 19: Health Monitor - Example JSON Response Containing the Upload Data Operation Result Listing 20: Health Monitor - Example JSON Response Containing the Find My Medical Records Operation Result Listing 21: Health Monitor - Example JSON Response Containing the Find My Medical Records Operation Result Listing 22: Health Monitor - Example JSON Response Containing the Add Permission to Carer Operation Result Listing 23: Health Monitor - Example JSON Response containing the Find My Carers Operation Result Listing 24: Health Monitor - Example JSON Response containing the Find My Carer Permissions Operation Result Listing 25: Health Monitor - Example JSON Response Containing the Find My Patients Operation Result Listing 26: Health Monitor - Example JSON Response Containing the Find My Patient Permissions Operation Result Listing 27: Health Monitor - Example JSON Supplied for the Add Sensor Operation Listing 28: Health Monitor - Example JSON Response Containing the Add Sensor Operation Result Listing 29: Health Monitor - Example JSON Supplied for the Update Sensor Operation Listing 30: Health Monitor - Example JSON Response Containing the Find Sensor by Id Operation Result Listing 31: Health Monitor - Example JSON Response Containing the Find My Sensors Operation Result Listing 32: Health Monitor - Example JSON Response Containing the Find My Sensors Operation Result Listing 33: Health Monitor - Example JSON Response Containing the Add Anomaly Configuration Operation Result / 305

14 Listing 34: Health Monitor - Example JSON Response Containing the Find Anomaly Configurations by Sensor Operation Result Listing 35: Health Monitor - Example JSON Response Containing the Add Alarm Configuration Operation Result Listing 36: Health Monitor - Example JSON Response Containing the Find Alarm Configurations Operation Result Listing 37: Health Monitor - Example JSON Response Containing the Find Alarm Configurations Operation Result Listing 38: Health Monitor - Example JSON Response containing the Find Alarms Operation Result Listing 39: Health Monitor - Example JSON Response Containing the Add Alarm Tracking Operation Result Listing 40: Health Monitor - Example JSON Response Containing the Find Alarm Trackings Operation Result Listing 41: Health Monitor - Example JSON Response Containing the Find Alarm Tracking by Id Operation Result Listing 42: Health Monitor - Example JSON Response Containing the Find Data Operation Result Listing 43: Health Monitor - Example JSON Response Containing the Analyze Data Operation Result Listing 44: Health Monitor - Example JSON Response Containing the Analyze Data Operation Result Listing 45: CADE Java Interface Enabled App Listing 46: CADE Java Interface PTT Activated Listing 47: CADE Java Interface Started Activity Listing 48: CADE Java Interface Stopped Activity Listing 49: ALFREDO Create App Listing 50: ALFREDO Delete App Listing 51: ALFREDO Get App Listing 52: ALFREDO Publish an App Listing 53: ALFREDO Unpublish Version of an App Listing 54: ALFREDO - JSON Example: Call App Information Listing 55: ALFREDO - JSON Example: App Information Listing 56: ALFREDO - JSON Example: Call App Information by Version Listing 57: ALFREDO - JSON Example: App Information by Version Listing 58: ALFREDO - JSON Example: Call List of Installed Apps Listing 59: ALFREDO JSON Example: List of Installed Apps Listing 60: ALFREDO - JSON Example: List of Installed Apps Listing 61: ALFREDO - JSON Example: Call Binary of an App Listing 62: ALFREDO JSON Example: Call App Search Listing 63: ALFREDO JSON Example: Call App Search by Category Listing 64: ALFREDO - JSON Example: Call App Search by Words Listing 65: ALFREDO JSON Example: Call App Search under Review Listing 66: ALFREDO - JSON Example: List of Apps of a Search Listing 67: ALFREDO JSON Example: Call Rate App Listing 68: Personalization Manager - API Method Signature to Create a New User Profile Listing 69: Personalization Manager - API Method Signature to Retrieve a User Profile / 305

15 Listing 70: Personalization Manager API Method Signature to Update a User Profile Listing 71: Personalization Manager API Method Signature to Delete a User Profile Listing 72: Personalization Manager API Method Signature to Search for User Profiles Listing 73: Personalization Manager API Method Signature to Retrieve Part of the User Profile Information Listing 74: Personalization Manager API Method Signature to Subscribe User for Recommendations Listing 75: Personalization Manager API Method Signature to Unsubscribe User from Recommendations Listing 76: Personalization Manager API Method Signature to Request Recommendation for Events Listing 77: Personalization Manager API Method Signature to Retrieve User s Contacts Information Filter by Listing 78: Personalization Manager API Method Signature to Retrieve User s Contacts Information Filter by Relation Listing 79: Personalization Manager - JSON schema of the UserProfile object Listing 80: Personalization Manager - Example JSON Supplied for the Create User Profile Service Listing 81: Personalization Manager - Example JSON Response Containing the Retrieve User Profile Result Listing 82: Personalization Manager - Example JSON Supplied for the Update User Profile Service Listing 83: Personalization Manager - Example JSON Supplied for the Search Users Profiles Service Listing 84: Personalization Manager - Example JSON Response Containing the Search Users Profiles Result Listing 85: Personalization Manager - Example JSON Supplied for the Retrieving Part of the User Profile Information Service Listing 86: Personalization Manager - Example JSON Response Containing the Retrieving Part of the User Profile Information Result Listing 87: Personalization Manager - Example JSON Supplied for the Subscribe from Recommendations Service Listing 88: Personalization Manager - Example JSON Supplied for the Unsubscribe from Recommendations Service Listing 89: Personalization Manager - Example JSON Supplied for the Request Recommendation Service Listing 90: Personalization Manager Example JSON Response Containing the Request Recommendation Result Listing 91: Personalization Manager - Example JSON Supplied for the Retrieve User s Contacts Filtered by Service Listing 92: Personalization Manager - Example JSON Response Containing the Retrieve User s Contacts Filtered by Result Listing 93: Personalization Manager - Example JSON Supplied for the Retrieve User s Contacts Filtered by Relation Service Listing 94: Personalization Manager - Example JSON Response Containing the Retrieve User s Contacts Filtered by Relation Result Listing 95: Event Manager API Method Signature to Submit an Event / 305

16 Listing 96: Event Manager API Method Signature to Retrieve an Event from the Events Knowledge Base Listing 97: Event Manager API Method Signature to Search Events in the Events Knowledge Base which Meet the Specified Parameters Listing 98: Event Manager API Method Signature to Search Events Mined from the Web Which Meet the Specified Parameters Listing 99: Event Manager API Method Signature to Delete Events from the Events Knowledge Base Listing 100: Event Manager API Method Signature to Save Events in the Events Knowledge Base Listing 101: Event Manager API Method Signature to Discard Events Submitted for the Events Knowledge Base Listing 102: Event Manager API Method Signature to Update Events in the Events Knowledge Base Listing 103: Event Manager API Method Signature to Delete Outdated Events From the Events Knowledge Base Listing 104: Event Manager API Method Signature to Add Websites for the Web Event Mining Listing 105: Event Manager API Method Signature to Remove Websites for the Web Event Mining Listing 106: Event Manager API Method Signature to Create New User Profile for the Event Manager System Listing 107: Event Manager API Method Signature to Retrieve a User Profile From the Event Manager System Listing 108: Event Manager API Method Signature to Update a User Profile in the Event Manager System Listing 109: Event Manager API Method Signature to Delete a User Profile From the Event Manager System Listing 110: Event Manager - JSON schema of the Event Object Listing 111: Event Manager - Example JSON Supplied for the Submit Event Service Listing 112: Event Manager - Example JSON Response Containing the Retrieve Event Service Result Listing 113: Event Manager - JSON Schema of the EventSearchParams Object Listing 114: Event Manager - Example JSON Supplied for the Search Events in the Events Knowledge Base Service Listing 115: Event Manager - Example JSON Response Containing the Resulted Events of the Search Service Listing 116: Event Manager - Example JSON Supplied for the Search the Web for Events Service Listing 117: Event Manager - Example JSON Response Containing the Retrieve Event Service Result Listing 118: Event Manager - Example JSON Supplied for the Save Event Service Listing 119: Event Manager - Example JSON Supplied for the Update Event Service Listing 120: Event Manager - Example JSON Supplied for the Delete Outdated Events Service Listing 121: Event Manager - Example JSON Supplied for the Add Website Service Listing 122: Event Manager - JSON schema of the UserProfile object / 305

17 Listing 123: Event Manager - Example JSON Supplied for the Create User Profile Service Listing 124: Event Manager - Example JSON Response Containing the Retrieve User Profile Result Listing 125: Event Manager - Example JSON Supplied for the Update User Profile Service Listing 126: KIS API Method Signature for Creating a Bucket and the Usage of this Method Listing 127: KIS API Method Signature for Deleting a Bucket and the Usage of the Method Listing 128: KIS API Method Signature to Grant Access Rights to a User for a Bucket and the Usage of this Method Listing 129: KIS API Method Signature to Get Access Rights for a User and the Usage of this Method Listing 130: KIS Factory Method to Create a Test Data Object Listing 131: KIS XSD for a Test Class Listing 132: KIS API Method Signature for the CRUD-Operation crudcreate and the Usage of this Method Listing 133: KIS API Method Signature for the CRUD-Operation crudread and the Usage of this Method Listing 134: KIS API Method Signature for the CRUD-Operation crudupdate and the Usage of this Method Listing 135: KIS API Method Signature for the CRUD-Operation cruddelete and the Usage of this Method Listing 136: KIS API Method Signature to Execute a Generic Query on a Specific Bucket and the Usage of this Method Listing 137: Web Portal - JSON Schema for Basic User Data Listing 138: Web Portal - Example JSON for Basic User Data / 305

18 1 Introduction ALFRED Personal Interactive Assistant for Independent Living and Active Ageing is a project funded by the Seventh Framework Programme of the European Commission under Grant Agreement No It will allow older people to live longer at their own homes with the possibility to act independently and to actively participate in society by providing the technological foundation for an ecosystem consisting of four pillars: User-Driven Interaction Assistant to allow older people to talk to ALFRED and to ask questions or define commands in order to solve day-to-day problems. Personalized Social Inclusion by suggesting social events to older people, taking into account their interests and their social environment. A more Effective & Personalized Care by allowing medical staff and caretakers to access the vital signs of older people monitored by (wearable) sensors. Physical & Cognitive Impairments Prevention by way of serious games that help the users to maintain and possibly even improve their physical and cognitive capabilities. Within this deliverable, the overall project vision in terms of its general positioning, the project s business opportunities and its scientific and technological objectives will be revealed. To this end, a story will be utilized to demonstrate various use cases where different user groups can benefit; the logical structure of the ALFRED project will be described; the theoretical structure of the ALFRED framework will be described, which will be the basis for the ALFRED application, as well as for the ALFREDO marketplace. 1.1 ALFRED Project Overview One of the main problems of western societies is the increasing isolation of older people, who do not actively participate in society either because of missing social interactions or because of age-related impairments (physical or cognitive). The outcomes of the ALFRED project will help to overcome this problem with an interactive virtual butler (a smartphone application also called ALFRED) for older people, which is fully voice controlled. The ALFRED project is wrapped around the following main objectives: To empower older people to live independently for longer by delivering a virtual butler with seamless support for tasks in and outside the home. This virtual butler (the ALFRED app) aims for a very high end-user acceptance by using a fully voice controlled and non-technical user interface. To prevent age-related physical and cognitive impairments with the help of personalized serious games. To foster active participation in society for the ageing population by suggesting and managing events and social contacts. And finally, to improve caring by offering direct access to vital signs for carers and other medical staff as well as alerting in case of emergencies. The data is collected by unobtrusive wearable sensors monitoring the vital signs of ALFRED s users. 18 / 305

19 To achieve its goals, the project ALFRED conducts original research from a user centred perspective and applies technologies from the fields of Ubiquitous Computing, Big Data, Serious Gaming, the Semantic Web, Cyber Physical Systems, the Internet of Things, the Internet of Services, and Human-Computer Interaction. For more information, please refer to the project website at Deliverable Purpose, Scope and Context The purpose of this deliverable is to provide the technical specification for the ALFRED components. The technical specification serves a development guideline, coordinating implementation efforts between the technical partners and ensuring that the prioritized user stories and requirements defined in D2.3 are properly fulfilled from a technical point of view. The technical specification builds upon the market analysis and technology watch performed in D2.2.1 and the functional specification and global architecture defined D2.4. While D2.4 provided a high-level overview of the ALFRED architecture from a functional point of view, the current deliverable defines the actual interfaces, protocols and class/package structures of the ALFRED components and their subcomponents. It also specifies the dependencies and communication between the components. 1.3 Status and Target Audience This document is listed in the -of-work (DoW) as public, as it provides general information about the goals and scope of the ALFRED project and can therefore be used by external parties in order to get according insight into the project activities. While the document mainly aims at the project s contributing partners, this public deliverable can also be useful for the wider scientific and industrial community. This includes other publicly funded research and development projects, which may be interested in collaboration activities. 1.4 Abbreviations and Glossary A definition of common terms and roles related to the realization of the ALFRED project as well as a list of abbreviations is available in the supplementary document Supplement: Abbreviations and Glossary, which is provided in addition to this deliverable. Further information can be found at Structure This deliverable is broken down into the following sections: Chapter 1 introduces the deliverable by giving a general overview of the project and by outlining the purpose, scope, context, status, and target audience of the deliverable. Chapter 2 provides a brief technical overview of the ALFRED system and its components. In chapter 3, the major design principles for ALFRED are presented. These design decisions concern several software components. Chapter 4 provides the technical specification of the ALFRED components. Finally, chapter 5 sums up the conclusions from the delivery. 19 / 305

20 2 System Overview Within this section, a brief overview about ALFRED is given from a technical perspective. First, the overall architecture is outlined. The components in the ALFRED system are then introduced and positioned within the overall architecture. Finally, dependencies between components are outlined. 2.1 Architecture The ALFRED system consists of three major sub-systems: The client, running on the end user s mobile device The server components and subcomponents A web portal, accessed by end users from any web browser The server components and subcomponents serve multiple client instances and may be hosted on a single machine, or distributed across multiple machines. Within the ALFRED project, they are likely to run on the same server. The client and the web portal connect to the server, but not to each other. Client, server and web portal components are described in more detail below, as well as in subsequent sections. 2.2 Components As described in D2.4 Architecture Definition and Functional Specification, the ALFRED system consists of eight components. Some components reside only on the client or server, while others are distributed across client, server and/or web portal, as described in subsequent chapters. Below is a summary of the components and their main roles: The Personal Assistant (PA) provides the graphical user interface and is the central access point between ALFRED components, third-party apps, and serious games. The Health Monitor (HM) provides access to the external sensors and wearables that are part of the ALFRED solution, collects raw sensor data and processes it to health information. The Context-Aware Dialogue Engine (CADE) is responsible for the spoken interaction between the end user and ALFRED. It receives input from the microphone, interprets recognized speech, interacts with apps and serious games, and provides spoken output. The ALFREDO Marketplace (AM) is the repository for all ALFRED apps. It provides management functionalities to the end user, such as finding, installing, updating and deleting an ALFRED app. It also enables developers to upload and manage ALFRED apps. The Game Manager (GM) provides and manages the serious games of the ALFRED system. It uses information for the Personalisation Manager, Health Monitor and the ALFREDO Marketplace in order to suggest and adapt games to the end user. The Personalisation Manager (PM) is the central hub for all user profile information. It processes raw data in order to acquire new, more complex 20 / 305

21 knowledge about the user. All information is then provided as a service to the other components of the ALFRED system. The Event Manager (EM) gathers event information, which is automatically collected by crawling specific domains in the Internet and manually through user input in a web portal. The Knowledge and Information Storage (KIS) acts as a provider of various types of databases to the components of the ALFRED system. It thus enables the other components to store all data save and secure, ensuring data sustainability and privacy. The eight components and the relation to the three sub-systems are depicted in Figure 1. Mobile Client Server Web Portal CADE Frontend CADE Session Manager CADE Backend ALFRED Apps Personal Assistant Knowledge and Information Storage Health Monitor Sensor Abstraction Framework Health Monitor Client Health Monitor Server Health Monitor Web Portal ALFREDO Local App Manager ALFREDO App Marketplace UI ALFREDO App Manager ALFREDO App Portal ALFRED Games Game Manager Personalization Manager Event Manager Event Manager Web Portal Figure 1: Architecture of the ALFRED System 2.3 Dependencies between Components As part of the technical specification of the ALFRED system, dependencies between ALFRED components have been identified. Table 1 shows a summary of such dependencies. Each cell displays services that the component in the column consumes from the component in the row (the provider). This summary of inter-component dependencies provides an overview of relations between components on a high level of description. Consumed services are elaborated in more detail in subsequent sections for the respective components. 21 / 305

22 Table 1: System Overview Dependencies between ALFRED components Provider Consumer PA HM CADE AM EM GM KIS PM PA 1 2 HM 3 4 CADE 5 6 AM 7 8 EM 9 GM 10 KIS PM Below is the table legend (see Table 2) that explains the relations between ALFRED components. The description given is the name of the service which is consumed by the ALFRED component. Relation Consumed Service Relation Consumed Service 1 Notify caregiver 10 Install/Remove game 2 GUI output App runtime access Settings notification 11 CRUD 1 12 CRUD 13 CRUD 3 Spoken output 14 CRUD 4 Get health info 15 CRUD 5 Enable App 6 Spoken output Spoken input 7 App definition access 8 App definition access Store app usage Search installed apps 9 Search events Get user profile Get health profile Get user profile Get health profile Search contacts Get user profile 19 Get user profile 20 Get user profile Get health profile 1 Create, read, update and delete (CRUD) operations, including usage of buckets and management of permissions. 22 / 305

23 3 Major Design Principles In the following subsections, major design principles for ALFRED are presented. These are design decisions that concern several software components. This includes the measures taken to fulfill security and privacy related requirements (section 3.1), the provision of Java-based and/or REST-based interfaces for communication between the components of ALFRED (Section 3.2) and the usage of the JavaScript Object Notation (JSON) as format for messaging between data sources and service as well as applications (Section 3.4). In addition, the choice of Android as underlying mobile Operating System (OS) for the ALFRED mobile application will be discussed in section Security and Privacy As stated in the User Stories and Requirements Analysis (D2.3), two key aspects are especially important for technology uptake among older users: security, guaranteeing the protection of personal data, and control, assuring that the user can influence how her personal data may be used. These requirements are also manifested in the use cases and user stories. In terms of the technical specification of the ALFRED system, the security and privacy related requirements can be broken down into the following aspects: Privacy settings in the end-user front-end Access control within components Security in web-based inter-component communication The first aspect deals with how privacy settings are managed and controlled by the end user. In ALFRED, the front-end to such settings will be provided by the Personal Assistant (PA) and managed by the Personalization Manager (PM). Secondly, access control within components will ensure that personal information stored by a component will not leak to other ALFRED components or to 3rd parties, unless explicitly configured to allow external access. In ALFRED, this requirement primarily applies to PM and the Knowledge and Information Storage (KIS), since PM uses KIS to store personal information. The access control of KIS is described in further detail in section Finally, the ALFRED system also uses web-based communication in the form of RESTful interfaces to provide services to other components. This communication needs to be secure and privacy-aware, so that personal information cannot be leaked by intrusive requests or eavesdropping. This means that all RESTful services must to be secure and adopt authentication mechanism. Below are the two mechanisms that ALFRED will adopt to fulfill these two requirements: Security: The communication between client and server side could be done across an untrusted network and the data could be leaked. In order to avoid this situation, the communication will be secured adopting the Transfer Layer Protocol 2 (TLS) 2 RFC-5246 TLS / 305

24 which ensures an encrypted communication between authenticated communication partners. This security method is also known as HTTPS. Authorization: Once the communication is secure, the user of a web service has to be authenticated. To this purpose, the OAuth 1.0 IETF standard RFC will be used. The principle of OAuth resides in a centralized authorization server which grants access to their server resources without sharing user credentials. OAuth will be used to authenticate the user and to authorize apps or components to act for the user. 3.2 Java-based Interfaces ALFRED provides a distributed system with high cohesion, i.e., single software components encapsulate a particular, well-defined functionality and the degree of redundancies is limited, and loose coupling, i.e., the single software components are independent from each other and could also be used in a different environment or be exchanged within ALFRED. As a result, the single software components need to communicate through interfaces. The choice of using Java-based interfaces is founded on the basis of Java usage. On server side, most of the ALFRED software components are implemented using Java and the necessary interfaces are actually an outcome of these implementations. On client side, the implementation of the ALFRED App is based on Android as Operating System (see section 4.2), for that reason and since Android is written in Java, ALFRED components will use Java-based interfaces to communicate with each other on client side. Hence, whenever possible, Java interfaces will be used, because it provides a direct, lightweight interaction between Java-based software components running in the same JVM (Java Virtual Machine). 3.3 RESTful Interfaces As mentioned in Section 3.2, the communication between components is realized through interfaces. Using Java-based interfaces is the best approach when the communication is realized locally, it means the communication is established in the same machine; but there are different cases where direct interaction using Java interfaces is not possible. It is selfevident that this applies if a different programming language is used for the implementation of a software component. Furthermore, because of the distributed nature of ALFRED, software components will be spread amongst different machines, including small sensor nodes, ALFRED Server side and naturally the ALFRED Mobile application. In such cases, direct interaction through Java interfaces is not possible and a different solution is necessary, which facilitates interaction between remote software components and machines. Interaction between remote software components will be done using RESTful web services. RESTful services provide remote access to functionalities using common HTTP methods (e.g., GET, PUT, POST, or DELETE) and are therefore easy to implement. An alternative would be the usage of the SOAP protocol, which also allows exchanging 3 RFC-5849 OAuth / 305

25 messages (structured information) between software components in a distributed manner. SOAP makes use of the so-called WS-* stack for service implementations and is therefore based on a well-defined set of standardized protocols and technologies. However, SOAP provides a verbose messaging format and is not actively supported by major players from the software industry. In contrast, RESTful web services have gained high popularity in practice. Hence, in ALFRED, RESTful web services will provide the interface to software components whenever it is not possible to make use of Java interfaces and/or functionalities may be invoked remotely. Notably, RESTful web services do not feature a standardized description and messaging format, which makes it necessary to strictly define the message data formats. Software components may offer both Java-based interfaces and RESTful web services. This is especially useful if a software component will be used both locally by other software components as well as remotely. 3.4 JavaScript Object Notation Due to the nature of a distributed system like ALFRED, a lot of data has to be exchanged between different systems and software components. In a first step, data has to be serialized to enable the transmission between two systems, e.g., the ALFRED Mobile application and the ALFRED Server side. Furthermore, both sides need to know how to handle the object that contains the information. Following this, a common standard structure for serialized objects has to be defined. A possible data format that is suitable for this purpose is JavaScript Object Notation (JSON). This data format is very simple, lightweight and in addition it is easily readable for humans. Alternatives would be XML (Extensible Markup Language) or YAML (YAML Ain t Markup Language), which, however, are quite heavyweight and therefore require relatively large efforts for parsing and serializing (XML), or need specific libraries to be installed on both the mobile and the server (YAML). Through the use of JSON this is not required. Particular benefits of JSON are: Human readable structure Easy-structured and resource-efficient Directly available for many programming languages Possibility of direct translation to Java objects and vice versa Although JSON can be directly interpreted by Java, a custom parser should be used to restrict the input parameters of the JSON objects and close this unnecessary security leak. As mentioned above, JSON is more efficient in the use of memory in comparison to XML that has a larger overhead when it describes attributes of objects. In a system that includes battery-powered devices, e.g., the ALFRED mobile device, which also has to deal with a network connection with limited bandwidth, e.g., 3G, the reduction of the amount of data that has to be transmitted is worthwhile. 25 / 305

26 4 Technical Specification This chapter defines the technical specification of the ALFRED system, beginning with component-independent topics and continuing with component-specific definitions. First, section 4.1 provides a general description of the technical specifications as such. Section 0 then provides the specification for technical solutions shared by all components. Sections provide technical specifications for each ALFRED component. Finally Section 4.11 describes the web portal used to provide access to the different components of the ALFRED system. 4.1 General of Technical Specification Technical Specification The following subsections describe the different aspects of the technical specifications of the ALFRED components provided by Sections Major Design Decisions This aspect of the technical specification highlights and discusses the major design decisions which provide the foundation for the component in question. It thereby paves the way for the subsequent technology comparison and selection. Please note that the component-specific design decisions should not be confused with the general design principles outlined in Section Technology Comparison The technology comparison extends the generic comparison criteria defined in Section with specific criteria that are applicable primarily to the component at hand. It then presents the technologies and software frameworks to come into consideration for the subsequent technology selection. The options are briefly named and introduced with focus on their benefits and disadvantages in the context of their intended usage in ALFRED. Finally, the actual comparison of technologies for the software component is presented. To this end, the discussed technologies are rated with regard to the generic and specific comparison criteria. Please note that no actual technology selection is performed in this part of the specification Technology Selection In the technology selection, the most suitable technology or software framework is selected based on the previously performed technology comparison. The selection is briefly discussed and motivated. Furthermore, if the selected technology is found to lack any relevant features with regard to its intended usage in ALFRED, the potential impact of such missing elements is discussed. 26 / 305

27 Component Structure This part of the technical specification provides a more detailed component structure than the one drafted in the functional specification (D2.4). In addition to the increased level of detail, potential impacts of the technology selection are also taken into consideration Interfaces In any collaborative project involving several technical partners, the usage of well-defined interfaces between software components is of significant importance as a means to align implementation efforts between partners and ensuring that the required functionalities are provided by all components. To this end, this part of the technical specification focuses on the component-specific interfaces as manifested by declarations of methods and services offered by the component. The interface specification builds upon the functional specification (D2.4) and extends it based on the dependencies from other components as summarized in section 2.1. In ALFRED, software components may provide Java and/or REST-based interfaces (see Section 3.2). For both kinds of interfaces, the interface definition describes the methods and services and their parameters, return values, error handling, and source code (class stubs). A unified style is used to describe the interfaces Consumed Services This part of the technical specification presents methods and services that the component relies on other components to provide. Together, these component-specific identifications of consumed services form a dependency matrix which is presented in Section 2.1. Please note that dependencies on any potential services are offered by non-alfred components (such as cloud services or usage of the host API) are not listed in this subsection Summary Finally, the last Sub-Section presents a summary of the component-specific technical specification Generic Comparison Criteria As described in Section 4.1.1, a technology comparison and selection is conducted for each ALFRED component. As a basis for these assessments, both generic and component-specific comparison criteria are taken into account. The generic criteria are shared across all components, but their importance may differ between components. Table 2 shows an overview of the generic comparison criteria. The importance ratings are only illustrative examples, but the descriptions are valid for all ALFRED components. 27 / 305

28 Table 2: General Generic Comparison Criteria Parameter Importance Up-to-datedness ++ The usage of cutting-edge technologies has the potential to boost the level of usability and innovation, thereby benefiting end users and attracting attention during the project dissemination and exploitation Stability + Stable and mature technologies are preferred over unstable or immature ones, e.g. products in beta status. This is especially crucial for irregularly updated products. Extensibility & Open Source/Standards + Even if an existing technology can be used as a foundation for a particular component, it is likely that the technology needs to be extended in order to meet all the project requirements. To this end, open source solutions are preferable. Alternatively, a closed-source solution with welldefined extensibility, e.g. in terms of plugin mechanisms, may be considered. Open standards, which may be supported by both open source and proprietary solutions, may potentially simplify implementation efforts and are therefore preferred. Familiarity + Project partners may be familiar with particular technologies, either because they have been developed in another (EU) research project or as a commercial solution by a partner, or have been applied by the partner in the past. In any case, familiarity with an existing technology substantially simplifies implementation efforts and is therefore preferred. Performance ++ Performance may have different meanings in relation to the different ALFRED components, e.g., low latency, Quality of Service (QoS), Quality of Experience (QoE), data/result quality, scalability, or accuracy. Interoperability + Technologies which provide a certain degree of interoperability are preferred, e.g. those that provide open interfaces, a well-defined API, or standardized data formats. 28 / 305

29 4.2 Common Solutions Operating System Major Design Decisions Operating System The operating system is one of the most important choices regarding the Application Runtime Environment, since there are many requirements to the runtime itself. It should at least run on mobile devices. It should be state of the art and be updated on a regular base. Operating System Extensibility and Hardware Access The target platform has to be open for hardware access to make use of internal sensors like the GPS module of the device and outputs like the audio device. Additionally, ALFRED can act as an internal wrapper for third party apps, which means that ALFRED can supervise and control third party access to the operating system or the hardware in order to reduce the possibility of the device being a bottleneck and as a security feature to prevent misuse of operating system or hardware features by third party developers Technology Comparison Comparison Criteria The following table (Table 3) depicts the criteria for the choice of the suitable operating system: Table 3: Common Solutions Specific Criteria for the Operating System Parameter Importance Market Share +++ It is important that the operating system being used has a pretty high market share. Extensibility ++ It should be possible to implement new features without being limited or locked into the system Possible Technologies and Comparison The chosen operating system of the device should be widely available to reach the highest possible customer range. It should further be extensible, and it should be possible to modify the system according to user requirements. Android developed by the Open Handset Alliance under the lead of Google Inc., is a mobile operating system based on the Linux Kernel. It s designed primarily for smartphones and tablets. However, user interfaces for cars, televisions and watches are currently being developed or already available. Android is licensed under the Apache 2.0 license. ios developed by Apple Inc., ios is exclusively distributed across Apple hardware. It features a locked down eco system and a wide range of apps available through the app store. ios is licensed under a proprietary EULA and not open sourced. 29 / 305

30 Windows Phone, currently being developed by Microsoft Corp., is the successor of Windows Mobile Phone. It features an easy to recognize start screen, consisting of so called live tiles, which show context sensitive information and allow the user to trigger actions. As ios, Windows Phone is licensed under a proprietary EULA and doesn t allow modifications to the core. Table 4 list the three mobile operating systems. Table 4: Common Solutions Comparison of Criteria for Operating System Parameter Importance Android ios Windows Phone Generic Criteria Up-to-Datedness Stability Open Source / Standards +/ Familiarity Performance Interoperability License + Apache 2.0 Proprietary Proprietary Specific Criteria Market Share Extensibility To underline the market share hypothesis, the following figure (see Figure 2) shows the market share of mobile operating systems in the European smartphone market: 30 / 305

31 1,10 0,90 8,10 19,20 70,70 Figure 2: Common Solutions Smartphone OS Sales Share in the EU5 in (Q ) According to the statistic by Kantar World Panel, the highest market share of mobile operating systems is taken by the Android platform, which is one important reason to choose Android. Another reason is the more commonly known programming language Java instead of the highly specialized programming language Objective-C, which is mandatory for the most valid Android contender, the ios platform Technology Selection Because of the aforementioned table (see Table 3), Android will be the selected operating system on which the end user application (the Personal Assistant) of the ALFRED system will run. It features a large market share, from which the ALFRED system will profit. Furthermore, due to the open architecture, it is possible to implement new, hardware-near functionality, as being able to define a hot word for the voice recognition. In order to satisfy all component needs and to be ready for the near future, the first Android version with support for wearables devices is selected. This is Android version 4.4 API Level Personal Assistant Android ios Windows Phone BlackBerry Other The Personal Assistant (PA) offers a unified access point to the functionality of the other ALFRED components. It provides Interfaces and the Runtime for ALFRED apps and serious games as well as handling all communication between the ALFRED apps and CADE. 4 By by Kantar World Panel 31 / 305

32 The PA provides API Wrappers for all other ALFRED components. API Wrappers offers an access point to the Authorization Manager, so that apps need special permissions to access these components Major Design Decisions According to the Functional and Technical Specification, the following decisions have been made: Inter-App Communication For the components to communicate with each other, an approach has to be chosen which allows a rapid implementation and a state of the art way of internal messaging. It should be extensible, and should provide a reliable way of bi-directional communication. Security Since the Personal Assistant has access to sensitive data, either directly or indirectly, it has to ensure that only apps with the necessary rights will be able to access sensitive information. Furthermore, only user having the necessary access rights to the system will be able to execute specific tasks Technology Comparison Framework Comparison Criteria The following table (see Table 5) list the specific criteria for frameworks in order to be a fitting basis for the Personal Assistant. Table 5: Personal Assistant Specific Criteria for the Framework Parameter Importance Inter-App Communication +++ It is mandatory that the framework offers a way to communicate between applications in Android. Licensing Support + The license should be free, in terms of free-to-use for both educational and commercial use Possible Technologies and Comparison The Personal Assistant must be able to execute and supervise Android apps, while being itself an Android app. As basis a framework has to be selected which allows such functionalities. The possibilities include the Android Application Framework or one of several cross-platform development frameworks allowing hardware resources access. The descriptions and a comparison table of the possibilities are shown in Section / 305

33 Android Application Framework 5 is a set of APIs that allows developers to quickly and easily create apps for Android devices. It contains tools for designing User Interfaces and a documentation for the API. Essentially an Android app consists of activities (programs that the user interacts with), services (programs that run in the background or provide some function to other apps), and broadcast receivers (programs that catch information important for an app). Xamarin.Mobile 6 is a library that exposes a single set of APIs for accessing common mobile device functionality across the ios, Android, and Windows Phone platforms. This increases the amount of code developers can share across mobile platforms, making mobile app development more productive. Xamarin.Mobile currently abstracts the contacts, camera, and geo-location APIs across ios, Android and Windows Phone platforms. Future plans include notifications and accelerometer services. It is based on Mono 7 and uses C#, so developers can reuse existing.net Framework libraries that are successfully ported to the Mono Framework. Rhodes is a development framework that lets software developers write software for mobile and desktop devices using a mixture of JavaScript, HTML5 and Ruby, instead of device specific languages. It is not a native approach. Instead a native application host a web view rendering the actual app. The PhoneGap Framework 8 is a mobile development framework that enables software developers to build apps for mobile devices using JavaScript, HTML5 and CSS3, instead of device-specific languages. The resulting apps are hybrid, meaning that they are neither truly native (because all layout rendering is done via web views instead of the platform's native UI framework) nor purely web-based (because they are not just web apps, but are packaged as apps for distribution and have access to native device APIs). Table 6 provides an overview of the comparison criteria for the before mentioned frameworks. Table 6: Personal Assistant Comparison of Criteria for Basis Framework Parameter Importance Android Application Framework Xamarin Rhodes PhoneGap Generic Criteria Up-to-Datedness Stability Extensibility & Open +/ / 305

34 Source / Standards Familiarity Performance Interoperability License + Apache 2.0 Proprietary Proprietary Proprietary Specific Criteria Inter-App Communication Licensing Support Technology Selection Based on the aforementioned criteria and the weighting in Table 6 the Android Application Framework is chosen. This will also limit the programming language for the Personal Assistant to Java. Every other Framework described in the comparison Table 6 didn t provide the necessary features, or lacked a proper license Runtime Environment ALFRED will rely on third party apps, which will provide additional benefit to the end user. To achieve this, the Personal Assistant needs to define a runtime environment which can handle generic third party apps. Furthermore, it has to ensure a seamless interaction between all components of the ALFRED system Comparison Criteria The following criteria are used to choose the suitable way to define the runtime environment (see Table 7). Table 7: Personal Assistant Specific Criteria for the Runtime Environment Parameter Importance Deployment +++ It should be possible to deploy the apps in an easy way. Usability ++ In general, the approach should be easy to use for both, developer and end user. Developing ++ Developing should benefit from the approach Possible Technologies and Comparison 34 / 305

35 Compiling Android: Android is an Open Source Operating System, which can be compiled on a Linux based build environment. This allows to create an own adjusted Android operating system (ALFRED OS). This would allow for example the denial to install non-alfred apps. An ALFRED app would require a special signature, so that the ALFRED OS would determine, if an app is a legit ALFRED app. The Personal Assistant would be an integral part of the ALFRED OS. An update to the Personal Assistant would require a firmware-like update, which would need additional effort. Java Reflection: Using reflection, would allow loading generic Java components into the Personal Assistants Appdomain. In order to use this approach every ALFRED app would be needed to be deodexed. Furthermore, a special mechanism to load additional resources (like images, manifests, etc.) has to be developed. Standalone Apps: The runtime environment could be a combination of a simple Android app and services. A central Android service could offer communication functionality for ALFRED-Apps enabling the communication with other ALFRED apps and ALFRED component. An ALFRED app would be a normal Android app consuming this special service. The service would control all interaction while enabling them to participate in the ALFRED platform. Table 8 provides an overview of the comparison criteria fort he before mentioned runtime environment approaches. Table 8: Personal Assistant Comparison of Criteria for the Runtime Environment Parameter Importance Compiling Android Generic Criteria Java Reflection Standalone Apps Stability Familiarity Performance Specific Criteria Deployment Usability Developing Technology Selection According to Table 8, the standalone approach has been chosen. It provides the overall best solution in terms of usability and stability. Furthermore, the standard deployment routines Android offers could be used allowing more distribution channels. 35 / 305

36 4.3.3 Component Structure The detailed component structure has already been defined in D2.4 Architecture Definition and Functional Specification. For an overview of the architecture, see 2.2 Personal Assistant, for an in-depth functional specification see 3.2 Personal Assistant. However, several aspects need additional explanation Settings View Additional to the Architecture Definition and Functional Specification, a settings view for the Personal Assistant is foreseen as a separate app. As the settings view it is not targeting our end users (the older people), it will be designed with the default Android graphic components and text system. It will allow the modification of all settings and will also be the basis for the first setup process. The settings will include: Personal information Carer information and relation Doctor information and relation Access rights With the manipulation of the access rights the user can limit and control the access to all personal data, and activate certain features for third parties (apps, carer, doctor) Red Button -View This view is the entry point for the Personal Assistant. As described in the DoW the Personal Assistant will be represented just as on bit red button. This view will be also used to enter the settings view and will be further utilized to interact with the user if the voice interaction fails. For this, generic options can be displayed. The user can then choose to push one of these options. This interaction is important for CADE. Even in case if the user can t read the option at all, this list of options will help to select the right next steps as with a limited selection of options, single options could be read to the user; Guiding the user better through the input Suggestion Manager As stated in D2.4 - Architecture Definition and Functional Specification, the Personal Assistant features the suggestion manager. There are three different types of suggestions: Applications, Serious Games and Events. Suggestions will be displayed to the user, and the user will be able to accept or dismiss the suggested item. The Suggestion Manager gathers context information, allowing displaying more meaningful suggestions based on the current environment of the user. This will allow the suggestion manager to show a suggestion directly, postpone it or decline it all together. E.g., normally, during the night time, the user doesn t want to receive a suggestion at all. If the event isn t a short term event, it might be reasonable to display the event on the next morning. The same applies to different other events. 36 / 305

37 Comparison Criteria The following criteria are used to determine the mechanism for getting suggestions: Table 9: Personal Assistant Specific Criteria for the Suggestion Manager s Communication Parameter Importance Implementation ++ Implementation of the notification method should be pretty much straight forward. Independence +++ In General, it should be possible to run the notification service without too many dependencies Possible Technologies and Comparison Google Cloud Messaging for Android (GCM) - Service allows sending data from the ALFRED server to the users' Android-powered device, and also to receive messages from devices on the same connection. The GCM service handles all aspects of queueing of messages and delivery to the target Android application running on the target device. It is completely free, and has no quotas. Simple polling: The suggestion manager could simply poll the requested services on a regular base for new suggestions. Reasonable timespans are three hours for events (meaning that the server will be connected every three hours and being asked for suggested events. There won t be a permanent connection) and ten minutes for games. Table 10 provides an overview of the comparison criteria for the before mentioned runtime environment approaches. Table 10: Personal Assistant Comparison of Criteria for the Suggestion Manager s Communication Parameter Importance GCM Polling Generic Criteria Stability Familiarity Performance Specific Criteria Implementation Independence / 305

38 Technology Selection According to the comparison being made in , polling will be used to query for suggestions. It is easy to implement and will reduce the dependency on a third party provider (Google). Google proved in the past that they tend to suspend or modify services in a way that they are not compatible any longer (the predecessor, Android Cloud 2 Device Messaging Service (C2DM), got suspended in 2013 and developers were forced to switch the service) Interfaces This chapter states the interfaces that are consumed or offered by the Personal Assistant Service Figure 3 depicts the interaction and connection of the Personal Assistant with other components of the ALFRED system. Personal Assistant Mobility Assistant Foundation Game Manager Assistant Service Personalization Manager ALFRED App CADE ALFRED Game Health Monitor Figure 3: PA - Relationship between the PA, Service and External Components Third party apps will communicate with the Personal Assistant via an Android Service. Each ALFRED app has to check at start up if the Service is available. If this service is not available, a hint, that the necessary ALFRED app (the Personal Assistant) has to be installed first, should be displayed. The service itself will be implemented as a bound service. A bound service allows components (such as activities) to bind to the service, send requests, receive responses, and even perform interprocess communication (IPC) 9. The service will manage its own lifecycle. It is supposed to run always in the background. Legend Internal Component 3rd Party App External Component / 305

39 Furthermore, to make the IPC possible, the Android Messenger class will be used. Each component, that expects an answer to its request, has to provide a Messenger-Instance in the ReplyTo - property. The binding to this service is shown in Listing 1. Listing 1: Personal Assistant Binding to the Service bindservice(new Intent("eu.alfred.personalassistent.AssistantService"), mconnection,context.bind_auto_create); Every app developer has to connect to the service via the bindservice() method Android offers. Furthermore the name of the service has to be explicitly stated. The full qualified name of the service is: eu.alfred.personalassistent.assistantservice Apps, which would like to talk to the service, must target that package. Furthermore, a Message features a so called what -parameter. This is an integer value allowing the Personal Assistant to distinguish between different targets. Because of the bundle property, the parameters can be adopted for different needs. Listing 2: Personal Assistant Sending a Message to the Service public void sendmessage(view v) { if (!mbound) return; //Create and send a message to the service, //using a supported 'what' value Message msg = Message.obtain(null, 1, 0, 0); Bundle bundle = new Bundle(); bundle.putstring("sampledatakey", "sampledatavalue"); msg.replyto = receivermessenger; msg.setdata(bundle); try { mservice.send(msg); } catch (RemoteException e) { e.printstacktrace(); } } (De-)Register as an External Application Apps need to (de-)register to the Personal Assistant allowing the PA to keep track of all ALFRED apps currently present on the device. Listing 3 show the registration process. 39 / 305

40 Parameters: Listing 3: Personal Assistant Register an App to the Personal Assistant public void sendmessage(view v) { if (!mbound) return; //Create and send a message to the service, //using a supported 'what' value Message msg = Message.obtain(null, 1, 0, 0); Bundle bundle = new Bundle(); bundle.putstring("action", "register"); bundle.putstring("id", "{uniqe_id}"); bundle.putstring("name", "Funny Game"); bundle.putstring("priority", 1); msg.replyto = receivermessenger; msg.setdata(bundle); try { mservice.send(msg); } catch (RemoteException e) { Remarks: action: The action, which should be taken. The following values are possible: o register : Registers the application to the Personal Assistant. o unregister : Unregisters the application from the Personal Assistant. id: A unique id, which will be used to identify the app. Best would be the package name, but a truly random GUID would work either. name: The name of the application. priority: The priority of the application. Please refer to for further information. When providing the replyto -property, the app will receive a confirmation after successful registration Communication The message class has an obtain -method, which allows integer arguments. The idea is to provide an enum, so that the Personal Assistant know exactly, which features are requested by the corresponding component. The enum will have prefixes, so that each component gets a range of values and can add several functions. The enum will be defined as show in Listing 4. Listing 4: Personal Assistant Enumeration Skeleton for the Communication public enum PersonalAssistantOperation{ CADE_DEFAULT(1000), GM_DEFAULT(2000), HM_DEFAULT(3000), ALFREDO_DEFAULT(4000) PM_DEFAULT(5000), EM_DEFAULT(6000), KIS_DEFAULT(7000) } The main idea is that every component gets an integer-based range value. So, e.g., if CADE requests information from the Personal Manager via the Personal Assistant, it should supply an enum value starting with PM_. Depending on the amount and type of 40 / 305

41 functions that should be available to other components, the corresponding enum-values should be set. E.g., if CADE wants to get user information on the Client side, provided by the Personal Manager, it will call the Message.obtain()-Method via a Value of PersonalAssistantOperation.PM_GET_USERINFORMATION. The value should, according to the enum be defined as PM_GET_USERINFORMATION(5001) in the PersonalAssistantOperation-enum Start App This service allows components or apps to start other apps. Apps need to have the matching right to use this service (see ). Parameters: appid: A unique ID identifying the app to be started. Return Value: true if the app could be started Error Handling: none Remarks: none Display Options This service allows CADE to display options if the voice interaction could not fully understand the user. If the argument is empty the screen is cleared and the red button view is displayed again. Parameters: options: A hashmap with keys and options to be displayed to the user. Return Value: the selected key by the user Error Handling: none Remarks: none Application priorities External applications should supply a priority when registering to the PA, as mentioned in The following (see Listing 5) priorities have been defined: Listing 5: Personal Assistant Enumeration depicting the possible application priorities public enum ApplicationPriority { Critical(1), Game(2), Other(3) } It is important that applications reacting on critical commands are registering themselves as critical, otherwise the command may be handled by other apps Permissions Because of the sensitive data ALFRED is using, it is necessary to implement permissions, which will control the flow of information through the ALFRED system. Every service that can be called through the Personal Assistant has to be secured by a corresponding 41 / 305

42 permission. The PA itself will then verify that the caller has the necessary permission to call this service KIS READ_PRIVATE_BUCKET <permission android:name="eu.alfred.personalassistant.read_private_bucket" android:description="reads data from the users private bucket." android:label="read From Private Bucket"> </permission> This permission allows reading data from the users private bucket. WRITE_PRIVATE_BUCKET <permission android:name="eu.alfred.personalassistant.write_private_bucket" android:description="writes data to the users private bucket." android:label="write Private Bucket"> </permission> This permission allows writing data to the users private bucket. READ_PROTECTED_BUCKET <permission android:name="eu.alfred.personalassistant.read_protected_bucket" android:description="reads data from the users protected bucket." android:label="read Protected Bucket"> </permission> This permission allows reading data from the users protected bucket. WRITE_PROTECTED_BUCKET <permission android:name="eu.alfred.personalassistant.write_protected_bucket" android:description="writes data to the users protected bucket." android:label="write Protected Bucket"> </permission> This permission allows writing data to the users protected bucket. READ_INTERNAL_BUCKET <permission android:name="eu.alfred.personalassistant.read_internal_bucket" android:description="reads data from the users internal bucket." android:label="read Internal Bucket"> </permission> 42 / 305

43 This permission allows reading data from the users internal bucket. WRITE_INTERNAL_BUCKET <permission android:name="eu.alfred.personalassistant.write_internal_bucket" android:description="write data to users internal bucket." android:label="write Internal Bucket"> </permission> This permission allows writing data to the users internal bucket Health Monitor REQUEST_VITAL_SENSOR_DATA <permission android:name="eu.alfred.personalassistant.request_vital_sensor_data" android:description="requests sensor data from vital sensors." android:label="request Vital Sensordata"> </permission> This permission allows the application to request vital sensor data from the Personal Assistant. SEND_VITAL_SENSOR_DATA <permission android:name="eu.alfred.personalassistant.send_vital_sensor_data" android:description="sends data to vital sensors." android:label="send Vital Sensordata"> </permission> This permission allows the application to send data to the vital sensor. REQUEST_AV_SENSOR_DATA <permission android:name="eu.alfred.personalassistant.request_av_sensor_data" android:description="requests data from AV sensors." android:label="request AV Sensordata"> </permission> This permission allows the application to request AV sensor data from the Personal Assistant. SEND_AV_SENSOR_DATA <permission android:name="eu.alfred.personalassistant.send_av_sensor_data" android:description="sends data to AV sensors." android:label="send data to AV Sensor"> </permission> This permission allows the application to send data to the AV sensor. 43 / 305

44 REQUEST_HARMLESS_SENSOR_DATA <permission android:name="eu.alfred.personalassistant.send_vital_sensor_data" android:description="request data from harmless sensors like Accelerometer." android:label="request harmless sensor data"> </permission> This permission allows the application to request data from the harmless sensors. SEND_HARMLESS_SENSOR_DATA <permission android:name="eu.alfred.personalassistant.send_harmless_sensor_data" android:description="request data from harmless sensors like Accelerometer." android:label="request harmless sensor data"> </permission> This permission allows the application to request data from the harmless sensors Game Manager READ_FROM_GAMEMANAGER <permission android:name="eu.alfred.personalassistant.write_private_bucket" android:description="writes data to the users private bucket." android:label="write Private Bucket"> </permission> WRITE_TO_GAMEMANAGER <permission android:name="eu.alfred.personalassistant.write_private_bucket" android:description="writes data to the users private bucket." android:label="write Private Bucket"> </permission> Personalization Manager CREATE_USER_PROFILE <permission android:name="eu.alfred.personalassistant. CREATE_USER_PROFILE" android:description="allows the creation of a user profile." android:label="create User Profile"> </permission> This permission allows the creation of a user profile. 44 / 305

45 RETRIEVE_USER_PROFILE <permission android:name="eu.alfred.personalassistant.retrieve_user_profile" android:description="allows the retrieval of the user profile." android:label="retrieve User Profile"> </permission> This permission allows the retrieval of a user profile. UPDATE_USER_PROFILE <permission android:name="eu.alfred.personalassistant.update_user_profile" android:description="allows the update of the user profile." android:label="update User Profile"> </permission> This permission allows updating a user profile. DELETE_USER_PROFILE <permission android:name="eu.alfred.personalassistant.delete_user_profile" android:description="allows the deletion of the user profile." android:label="delete User Profile"> </permission> This permission allows deleting a user profile. SEARCH_USER_PROFILE <permission android:name="eu.alfred.personalassistant.search_user_profile" android:description="allows searching for a user profile." android:label="search User Profile"> </permission> This permission allows searching of a user. RETRIEVE_USER_PROFILE <permission android:name="eu.alfred.personalassistant.retrieve_user_profile" android:description="allows the retrieval of the user profile." android:label="retrieve User Profile"> </permission> This permission allows the retrieval of a user profile 45 / 305

46 Event Manager REQUEST_EVENT_FROM_KIS <permission android:name="eu.alfred.personalassistant.request_event_from_kis" android:description="requests an event from KIS." android:label="request Event From KIS"> </permission> This permission allows requesting for an event stored in KIS. SEARCH_EVENT_IN_KIS <permission android:name="eu.alfred.personalassistant.search_event_in_kis" android:description="searches an event in KIS." android:label="search Event In KIS"> </permission> This permission allows searching for an event stored in KIS. SEARCH_MINED_EVENTS <permission android:name="eu.alfred.personalassistant.search_mined_events" android:description="searches mined events from the web." android:label="search Mined Events"> </permission> This permission allows searching for mined events. DELETE_OUTDATED_EVENT_IN_KIS <permission android:name="eu.alfred.personalassistant.delete_outdated_event_in_kis" android:description="deletes an outdated event in KIS." android:label="delete Outdated Event In KIS"> </permission> This permission allows deleting outdated events stored in KIS. DISCARD_SUBMITTED_EVENT <permission android:name="eu.alfred.personalassistant.discard_submitted_event" android:description="discard a submitted event." android:label="discard a Submitted Event"> </permission> This permission allows discarding submitted events. 46 / 305

47 CADE SEND_CADE_COMMAND <permission android:name="eu.alfred.personalassistant.send_cade_command" android:description="allows the app to send commands to CADE." android:label="send Voice Commands"> </permission> This permission allows the application to send commands to CADE, and get the result back from CADE General START_APP_COMMAND <permission android:name="eu.alfred.personalassistant.start_app_command" android:description="allows the app to start another app by utilizing the Personal Assistant." android:label="start thirdparty App"> </permission> This permission allows the application to start another application through the communication channel Sensor Categories public enum SensorCategory { Vital, AV, Harmless } The sensors themselves are split into several categories, depending on the type of data they are offering. Usually, a sensor will fit in one of these categories. Vital: Vital sensors are supposed to be sensors for vital parameters, like heart or pulse rate, blood pressure etc. They usually offer sensitive vital data, and should therefore be handled with care. AV: AV sensors are audio/video sensors, like cameras, additional microphones or even 3d scanners like the Microsoft Kinect. They usually raise privacy concerns, and should therefore be put in a separate category. Harmless: Harmless sensors are mostly harmless sensors, at least from a health or privacy perspective. This could be sensor like an accelerometer, an ambient temperature sensor or a humidity sensor Consumed Services Due to its nature, the Personal Assistant consumes services from all ALFRED components, either directly or indirectly. The PA will route commands and recommendations from one service to another. Therefore, each component must offer an 47 / 305

48 Android based API, which offers a way to interact with the component, and respects the implementation of the IPC as described in This mostly applies to the external apps and games, which will talk to the Game Manager, utilizing the communication capability of the Personal Assistant Summary Several technologies have been taken into account to suit the needs of ALFRED and the Personal Assistant itself, and were examined. The first step was to select a suitable application framework, which is able to handle communications between apps and components while having a liberate license. This led to the Android Application Framework. Second, the implementation details for the runtime environment were selected. The best fit for all requirements let to standalone Android apps interacting with the tools provided by the Android framework. Furthermore, the communication between third party apps has been specified, and also the necessary permissions and the available sensor categories. 4.4 Health Monitor The Health Monitor component is a distributed system. On the one hand, the client side encapsulates data from wearable sensors and send them to the server. On the other hand the server collects all the data from different clients and processes this data to obtain health information from the user. Different stakeholders will access data from the Health Monitor. They can be grouped as followed: Older Adults: The primary end-user group of ALFRED consists of people aged over 60 years old. They won t interact with this component directly. They will wear wearable sensors allowing the collection of different vital signs. (Informal) Caregivers: They will interact with the ALFRED to receive information and alerts about the people they care about. Medical Staff: Doctors, nurses and other hospital staff will be able to provide more efficient care through direct communication with the patient. They will access personal health information of their patients through the ALFRED portal Major Design Decisions During the discussion of the architecture definition and Functional description, the following mayor design decisions have been made: Easy to use: The Health Monitor Client has to be easy to use, because the end users are usually no technology experts. This implies that the Health Monitor Client will be easy to activate including the handling of the wearable sensors. Autonomy: In order to obtain the maximum autonomy, the mobile device and the wearable sensors have to consume as less energy as possible. The communication technology selected has to allow proper energy management in order to preserve energy consumption. This includes the definition of a specific protocol that permits maximum efficiency in the data transmission tasks. Security: Since ALFRED manages sensitive patient data it is responsible to secure this data and to ensure that only older user, caregivers and medical staff with permission of 48 / 305

49 the older user have access. In addition the communication channels must be encrypted to prevent ears dropping. Compatibility: To ensure maximum compatibility and acceptance the communications technology selected must be widely used and standardized Technology Comparison Comparison Criteria The following table (Table 11) lists the used criteria to compare the different communications technologies available in the market which fulfil all the previous design decisions: Table 11: Health Monitor Criteria for Technical Specification Parameter Importance Energy autonomy ++ Secure transmission ++ Compatibility + In order get a good energy autonomy it will be positive rated mechanisms of efficient bulk data transfers and adaptable transmission power consumption according to the data rate. ALFRED will ensure that external users are unable to break through and steal vital information. To ensure secure transmissions will be appreciated that the selected technology supports encryption and authentication mechanism. To ensure maximum compatibility and acceptance the communications technology selected must be widely used and standardized. The used technology should be standard with mobile devices without need of additional elements Possible Technologies and Comparison Wireless communications have played a very important role in the evolution of smartphones. Different technologies have been developed making possible the data transmission between devices offering mobility for the user. These technologies can be divided into two main groups: Long range wireless technologies and short range technologies. In general long range technologies offer a wider range of mobility with greater energy consumption and short range technologies offers reduces energy consumption and also less mobility in terms of range. The requirements of ALFRED related with connection with sensors should be solved with short range technologies, because these technologies offer personal area communications with a mobile devices, and can be used to connect as wide range of devices. As short range wireless technologies will be considered that offer ranges as a maximum of 100 meters. The technologies most representatives are: ANT provides a simple, low-cost and ultra-low power solution for short-range wireless communication in point-to-point and more complex network topologies. Suitable for various applications, ANT is today a proven and established technology for collection, automatic transfer and tracking of sensor data within sports, wellness 49 / 305

50 management and home health monitoring applications. ANT is a proprietary protocol that operates in the 2.4GHz band. The typical application areas are: sports & fitness, consumer health & medical, mobile accessories and wireless sensor systems. Bluetooth wireless technology is one of the most prominent short range communications technologies with an installed base of more than three billion units. Bluetooth is intended to replace the cables connecting portable and/or fixed devices while maintaining high levels of security, low power and low cost. A fundamental strength of Bluetooth is the ability to simultaneously handle data and voice transmissions. Bluetooth is designed to have very low power consumption by allowing radios to be powered down when inactive. The Bluetooth specification defines a uniform structure with global acceptance to ensure interoperability of any Bluetooth-enabled device. Bluetooth technology operates in the unlicensed industrial, scientific and medical (ISM) band at 2.4 to GHz, which is available and unlicensed in most countries. Bluetooth uses a spread spectrum, frequency hopping, full-duplex signal which was designed to reduce interference between wireless technologies sharing the 2.4 GHz spectrum. The application areas for this technology are: mobile accessories, consumer health/medical, fitness, remote controls and wireless sensor systems. Bluetooth has a new version named Low Energy (BLE), a feature of Bluetooth 4.0 under the standard IEEE within a short range (up to 50 meters) can only support peer to peer and star typology, and as a result cannot establish a meshed network, with a data transmission speed that can reach up to 100 Kbps. It is possible to reach low consumption levels of around 25 ma in transmission, and microamperes when in the sleep mode RFID (Radio Frequency Identification) is a method of storing and retrieving data using wireless systems, comprising a tag (also known as a transponder, smart label/card/ticket); a reader/scanner, which can be either fixed or hand-held, and a host computer plus software. Data is stored on the tag and exchanged with the reader via radio transmissions between the two components. Typically, these transmissions occur in the High Frequency or UHF range although a move into the microwave region is predicted. The majority of the tags in use currently are passive devices, which need to come into close proximity with the reader in order to be powered inductively to enable them to transmit or receive data. More complex and expensive active tags are also available, having a built in power source (i.e. a battery) these can operate over greater distances from the reader and typically have a larger capacity, higher data transfer speeds and increased read/write capability. Wi-Fi (IEEE ) networks use radio technologies based on the IEEE a, b, g and n to provide secure, reliable, fast wireless connectivity. Wi-Fi networks operate in the unlicensed 2.4- and/or 5-GHz radio bands at rates of 54 Mbps or greater. They can provide real-world performance similar to the basic 10BaseT wired Ethernet networks. Their typical application areas are: consumer devices for internet connectivity, industrial and home automation, medical devices and remote patient monitoring, remote monitoring, smart machines, video conferences, security and surveillance. ZigBee ( ) is a standard based technology for remote monitoring, control and sensor network applications. The ZigBee was created to address the need for a cost effective, standard based wireless networking solution that supports low data 50 / 305

51 rates, low power consumption, security and reliability. ZigBee has these typical application areas: home, building and industrial automation; smart wireless lighting control, home control, logistics, advanced metering energy, medical and patient monitoring and energy harvesting. A brief summary of the main features of the short range wireless technologies is presented in next table (Table 12) weighting the before mentioned criteria: Table 12: Health Monitor Comparison of Technologies for the Health Monitor Parameter Importance ANT Bluetooth RFID Wi-Fi ZigBee Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards +/ Familiarity Performance Interoperability Specific Criteria Energy autonomy Secure transmission Compatibility Technology Selection Based on the requirements of ALFRED Bluetooth has been selected as communications technology. This technology has good performance in power requirement, data rate, and latency. ZigBee has also a good performance but still this technology has never been integrated in mobiles in contrast to Bluetooth. Bluetooth has an emerging new low power wireless version that is developed for short-range monitoring and control applications and is expected to be included in billions of devices worldwide in next few years. ANT s technology is similar to Bluetooth in that it transmits information from one enabled device to other using radio waves and is extremely efficient. But ANT is a proprietary protocol, the applications for the network itself are mainly fitness-related, and certain mobile phones do not natively support ANT, forcing to add accessories to the smartphone in order to connect to ANT. Bluetooth covers several technologies. Bluetooth low energy started out as Bluetooth Lite inside of Nokia s research labs in the mid-2000s, and was envisioned as a smaller, 51 / 305

52 lighter companion to regular Bluetooth technology in applications where regular Bluetooth was too complex or too power hungry. A year or so later, it became clear that it made the most sense to develop this technology inside the Bluetooth SIG, and the technology was handed over to them. At this point the technology became known as ultra-low power Bluetooth, and would eventually be re-christened Bluetooth low energy. This technology was included in the Bluetooth 4.0 specification when that was released in For a consumer audience, Bluetooth 4.0 is referred to as Bluetooth Smart or Bluetooth Smart Ready, depending on which form it is presented in. Apart of the commercial brands, now there are three different types of Bluetooth devices: Classic Bluetooth, Bluetooth dual mode and Bluetooth single mode. The Classic Bluetooth is typically used in devices that need a maintained and often high-throughput connection. The second category called dual mode support both Classic and Bluetooth Low Energy is found as Bluetooth Smart Ready. The third category or Single Mode support Bluetooth Low Energy as the only form of communication and is named Bluetooth Smart. Bluetooth Low Energy market is expected to expand rapidly compared to that of ANT & ZigBee. This is because of the huge Bluetooth SIG that backs up the standard. As a comparison between Bluetooth SIG, ZigBee and ANT SIG / Alliance, the number of members for Bluetooth are more than 20,000 companies, compared to only 500 members for ANT and 400 for ZigBee Alliance. This makes the Bluetooth SIG more experienced with a better market view and feedback for enhancements, and this in turn would speed up the emergence of new profiles and services. The physical RF interface of Bluetooth Low Energy is slim and optimized. Since Bluetooth low energy has a lot fewer channels to go through when doing discovery, the process is much quicker, and a connection can be set up within a few milliseconds rather than the couple of seconds required in classic Bluetooth. The channel spacing of Bluetooth low energy is 2 MHz in contrast to BR s 1 MHz; this has the effect of reducing demands on RF filtering. This provides Bluetooth Low Energy with an energy-efficient way of maintaining connections while keeping the radio off as much as possible Component Structure As depicted in the following figure (see Figure 4), the Health Monitor is composed of four different subcomponents: the Sensor Abstraction Framework (SAF), the Health Monitor Client (HMC), the Health Monitor Server (HMS) and the Web Portal. 52 / 305

53 Sensors Sensors Sensors Client component Sensor Abstraction Framework (SAF) Health Monitor Client Web Portal Health Monitor Server Figure 4: Health Monitor Health Monitor Component Structure Each subcomponent will be covered in the following subsections The Sensor Abstraction Framework (SAF) SAF is a component deployed onto the mobile device. It is responsible for (i) managing ALFRED-aware sensors, (ii) obtaining measurements coming from configured sensors and (iii) broadcast sensor measurements among all registered listeners. To fulfill such functionality SAF is internally structured as depicted in the following class diagram (see Figure 5): 53 / 305

54 SAFFacade +registerdriver(in driver : SensorDriver) +unregisterdriver(in driver : SensorDriver) +registerlistener(in url : String, in listener : SensorListener) +unregisterlistener(in url : String, in listener : SensorListener) DriverRegistry SensorPool -pool +registerdriver(in driver : SensorDriver) +unregisterdriver(in driver : SensorDriver) +unregisteralldrivers() +listdrivers() : SensorDriver[*] 1 +addsensor(in url : String, in driver : SensorDriver) : Sensor +removesensor(in url : String) +removeallsensors() +containssensor(in url : String) : Boolean +getsensor(in url : String) : Sensor +listallsensors() : Sensor[*] 1 1 -pool 1 * * 1 «interface» SensorDriver +supportsurl(in url : String) : Boolean +getmetainfo(in url : String = null) : HashMap +bind(in url : String, in props : HashMap = null) : Boolean +unbind(in url : String) +read(in url : String) : Byte[*] +write(in url : String, in data : Byte[*]) 1 -driver * Sensor +geturl() : String +getdriver() : SensorDriver +addlistener(in listener : SensorListener) +removelistener(in listener : SensorListener) +removealllisteners() +listalllisteners() : SensorListener[*] SensorMonitor monitors +run() 1 1 SensorDataDispatcher 1 * -queue +run() «interface» SensorListener notifies 1 +getprops() : HashMap +data(in ts : Long, in url : String, in data : Byte[*]) writes to 1 reads from SensorMeasurements +writemeasurement(in data : SensorMeasurement[*]) +readmeasurements(in ini : Long = null, in end : Long = null, in sensorurl : String = null) : SensorMeasurement[*] +clearmeasurements(in ini : Long = null, in end : Long = null, in sensorurl : String = null) 1 1 * SensorMeasurement +SensorMeasurement(in ts : Long, in url : String, in data : Byte[*]) +gettimestamp() : Long +geturl() : String +getdata() : Byte[*] Figure 5: Health Monitor SAF Class Diagram The entry point to the SAF is the SAFFacade class. This element provides a simple view of the functionalities that are published by SAF. For more information about this interface refer to section The SAFFacade class requires the services provided by the DriverRegistry and the SensorPool classes. The DriverRegistry class encloses all the services required for registering, unregistering and listing all the sensor drivers known by SAF. Internally, each sensor driver is modeled by a class that implements the SensorDriver interface, and it provides services for obtaining meta-info, connecting to a sensor for the first time and reading and writing data into it. 54 / 305

55 The SensorPool class maintains a collection of all currently active sensors. A sensor is active while there is at least one listener registered for it. This class provides services for managing all active sensors, as well as its associated listeners. An active sensor is modeled by the Sensor class, and it is managed by a particular sensor driver. Also, it contains a queue of registered listeners. Each listener is modeled by the SensorListener interface, and contains a method for getting notified (data()) about new measurements coming from sensors and an optional method for providing some configuration parameters about the monitoring activity (e.g. sampling rate, authentication information, etc.) Finally, SAF contains two working threads that implement the producer-consumer pattern: the SensorMonitor and the SensorDataDispatcher. The SensorMonitor gets activated periodicaly and collects information from all active sensors. This data, along with the capturing timestamp and the URL of the sensor is packaged into a SensorMeasurement instance, which is further written to the SensorMeasurements element. The SensorMeasurements class represents a temporal storage for mitigating the speed differences between the SensorMonitor and the SensorDataDispatcher threads. The SensorDataDispatcher thread reads data from the SensorMeasurements element and notifies all registered listeners, accordingly to their configuration The Health Monitor Client (HMC) The Health Monitor Client is a component installed locally on the ALFRED device. It acts as bridge between the SAF and the Health Monitor Server. It is responsible for receiving data from sensors (SAF) and transmitting that data to the Health Monitor Server. To achieve such functionality the Health Monitor Client is internally structured as presented in the following class diagram (see Figure 6): 55 / 305

56 TShirtDriver «interface» SensorDriver +supportsurl(in url : String) : Boolean +getmetainfo(in url : String) : HashMap +bind(in url : String, in props : HashMap) : Boolean +unbind(in url : String) +read(in url : String) : Byte[*] +write(in url : String, in data : Byte[*]) 1 -driver 1 1 HMCLoader Register/Unregister driver & listener SAF API Wrapper «interface» SensorListener +getprops() : HashMap +data(in ts : Long, in url : String, in data : Byte[*]) 1 DataReceiver 1 +start() +stop() -listener 1 1 -preprocessor DataPreprocessor +process(in ts : Long, in sensorurl : String, in data : Byte[*]) 1 -filters FilterRegistry +addfilter(in name : String, in filter : Filter) +removefilter(in name : String) +removeallfilters() +getfilter(in name : String) : Filter +containsfilter(in name : String) : Boolean +listallfilters() : Filter[*] 1 * -filters -filters -metadata 1 1 -metadata 1 -metadata MetadataRepository «interface» Filter +init(in metadata : MetadataRepository, in storage : FilterStorage) +process(in ts : Long, in url : String, in data : Byte[*]) : Byte[*] Health Monitor API Wrapper 1 Sync Data +get(in key : String) : java.lang.object +set(in key : String, in value : java.lang.object) 1 -metadata -metadata 1 Personalization Manager API Wrapper Sync Data 1 FilterStorage 1 1 DataCompressor 1 DataTransmitter +read(in key : String) : Byte[*] +write(in key : String, in data : Byte[*]) -storage +init(in metadata : MetadataRepository, in storage : FilterStorage) +process(in ts : Long, in data : Byte[*], in url : String) : Byte[*] +init(in metadata : MetadataRepository, in storage : FilterStorage) +process(in ts : Long, in url : String, in data : Byte[*]) : Byte[*] +run() -filterstorage 1 1 -syncstorage 1 1 SyncStorage +writesyncdata(in data : SyncData[*]) +readsyncdata(in ini : Long = null, in end : Long = null, in sensorurl : String = null) : SyncData[*] +clearsyncdata(in ini : Long = null, in end : Long = null, in sensorurl : String = null) 1 * Send Data SyncData +SyncData(in ts : Long, in url : String, in data : Byte[*]) +gettimestamp() : Long +geturl() : String +getdata() : Byte[*] Health Monitor API Wrapper Figure 6: Health Monitor HMC Class Diagram The main subcomponent of the Health Monitor Client is the HMCLoader. This class is responsible for starting and stopping the Health Monitor Client. The start() method initializes the environment, mainly by (i) registering the TShirtDriver into SAF, and (ii) enabling receiving measurements from this kind of sensors by registering the DataReceiver listener. The TShirtDriver class is an implementation of the SensorDriver interface presented in the previous section and provides support for communicating with the sensors included in the t-shirt (as example for a wearable sensor) developed in the course of the ALFRED project. 56 / 305

57 The DataReceiver class is an implementation of the SensorListener interface presented in the previous section and listens to measurements coming from the t-shirt. When the HMCLoader registers this listener in SAF, it must provide the exact URL of the concrete t- shirt the ALFRED app will monitor. This information is obtained from the MetadataRepository element, which retrieves all the information either from the Personalization Manager component or from the Health Monitor Server component, through their respective API wrappers. When sensor measurements are received in the DataReceiver subcomponent, they are automatically forwarded to the DataPreprocessor. The DataPreprocessor subcomponent implements a filter preprocess chain. Each inbound sensor measurement may go through a different filter chain (depending on the sensor type, the time, the day of the month, etc.). In order to know the filters to apply to the incoming data, the DataPreprocessor consults the MetadataRepository and retrieves the filters from the FilterRegistry subcomponent. A filter has to implement the Filter interface. Before executing a filter, it must be initialized (init() method). After initialization the filter processes data in the process() method. While processing data, a filter may retrieve information from the MetadataRepository and store temporal data into a persistent storage, implemented by the FilterStorage class. When a filter transforms incoming data, it must return the transformed data, and the transformed data is the input for the next filter in the chain. If a filter finishes the chain i.e. after it no other filters get executed then it must return null. Several filters may be included in the ALFRED app, depending on the developed sensor types, measurement types, configuration parameters, etc. Two special filters will be part of the core distribution: the DataCompressor and the DataTransmitter. The DataCompressor is a filter that compresses the incoming data and returns the result. It may be applied if bandwidth is a limited resource. The DataTransmitter has a dual purpose: It is a filter that transmits the incoming data to the Health Monitor Server, and therefore after it there are no more significant filters, since the filter chain must finish. Data transmission is achieved though the Health Monitor API Wrapper component. It is a daemon. The DataTransmitter filter might not transmit the information, for example in the following cases: (i) when optimizing communications, in order to save bandwidth, the filter may decide to accumulate data before transferring, or (ii) in disconnected scenarios, the filter would not be able to connect against the Health Monitor Server, and then data should be cached locally. In those cases, the filter may decide to store the information bundled into a SyncData object into the SyncStorage subcomponent. The DataTransmitter daemon periodically checks whether some data must be synchronized with the server and starts the synchronization operation when necessary. The Health Monitor Server (HMS) The Health Monitor Server is the core of the Health Monitor component and it implements its main functionalities. Figure 7 depicts the data model used internally: 57 / 305

58 Patient 1 -medical records * MedicalRecord -id : String -type : String -ts : Long -info : String -patients * Permissions 1 * Permission -id : String -type : String -info : String User -id : String -carers * InformalCarer * Carer Attached sensors FormalCarer DataProcessingConfig -filters : String[*] -props : HashMap SensorConfig -props : HashMap * Sensor -id : String -url : String 1 * -sensor -data HistoricalData -ts : Long -data : Byte[*] * -anomalies * -owner 1 * AnomalyConfig -id : String -formula : String 1 * AlarmConfig -alarms -id : String -type : String -target : String -props : HashMap 1 * 1 * Anomaly -id : String -ts : Long -info : String 1 * Alarm -id : String -ts : Long -info : String -alarms 1 * AlarmTracking -id : String -ts : Long -info : String Figure 7: Health Monitor HMS Class Diagram The Health Monitor Server considers two types of users: patients (Patient) and carers (Carer). Carers may be formal (e.g. medical carer) or informal (e.g. a relative). A patient has a medical history. This is modeled as a collection of medical records (MedicalRecord). Each medical record belongs to a particular type (e.g. disease-start, disease-stop, comment, accident, medical-consultation, etc.), took place at a particular point in time (timestamp ts) and entails some information. A carer takes care of some patients. Each patient must grant special permissions to his carers (Permissions), for example to allow accessing his personal data. A carer attaches several sensors (Sensor) to a patient, becoming the owner of those sensors. For the sake of simplicity, a sensor is a device that can obtain only one kind of measurement. If a real world sensor can obtain more than one kind of measurement, then it must be internally modeled as different sensors. Each sensor contains a particular configuration (SensorConfig) that specifies how to obtain measurements from it (e.g. sampling period, accuracy, etc.). Each sensor also contains a particular data processing configuration (DataProcessingConfig) that specifies how to pre and post-process each 58 / 305

59 measurement obtained from the sensor. For now, suffice to say that a flexible filter chain might be configured. All processed data are stored (HistoricalData) so that they can be analyzed at any time. Carers may configure anomalies on sensors (AnomalyConfig). An anomaly typically affects to only one sensor (actually, the measurements obtained from one sensor), and it usually defines a range of normal values with an upper and lower limit, so that the anomaly will be triggered in the case of a measurement out of bounds. The data model also allows the definition of anomalies that affect more than one sensor measurement. A functional language is foreseen, allowing the definition of conditions that must be met to trigger an anomaly, taking multiple measurement values (this is the purpose of the formula attribute) into consideration. Once the anomaly has been configured, several anomalies (Anomaly) may take place at runtime. Those anomalies will be tracked as they happen. Associated with an anomaly, a carer may configure different alarms (AlarmConfig). An alarm represents some kind of notification to someone. We may identify several types of alarms (e.g. mail, push notification, phone call, etc.). Each alarm must have a target and depending on the alarm type a particular kind of configuration. Once an alarm fired it has to be tracked in order to control if it has been successfully served and controlled. This will be handled with the help of the alarm occurrence (Alarm) and the different events on the alarm progress (AlarmTracking). The internal structure of the Health Monitor Server uses the previous introduced data model and implements the required classes and methods. As described in the architecture document, the Health Monitor Server architecture can be described by the following component diagram (see Figure 8): Facade Controller Data PostProcess Framework Health Profile Manager Health Monitor Configurator Alarm Manager Data Analysis Framework Metadata Repository Personalization KIS Figure 8: Health Monitor Health Monitor Class Diagram The full class diagram of the Health Monitor Server is complex. For this reason it is broken down into sub-diagrams. Each sub-diagram will cover on of the following functional aspects: Data postprocess, health profile, configurator, alarm and data analysis. 59 / 305

60 The postprocess functional aspect in depicted in the following subdiagram (see Figure 9): DataPostprocessFacade -security SecurityController +uploaddata(in auth : SecurityInfo, in data : DataPackage[*]) 1 1 +validateidentity(in auth : SecurityInfo) : Boolean +validateoperation(in auth : SecurityInfo, in op : OperationInfo) : Boolean 1 1 -controller DataPostprocessController DataPackage OperationInfo SecurityInfo +uploaddata(in userid : String, in data : DataPackage[*]) +gettimestamp() : Long +geturl() : String +get() : String +getuser() : String 1 1 -processor DataPostprocessor +data(in userid : String, in ts : Long, in url : String, in data : Byte[*]) filters 1 -metadata FilterRegistry +addfilter(in name : String, in filter : Filter) +removefilter(in name : String) +removeallfilters() +getfilter(in name : String) : Filter +containsfilter(in name : String) : Boolean +listallfilters() : Filter[*] 1 MetadataRepository +read(in path : String, in criteria : String) : HashMap[*] +write(in path : String, in value : HashMap) +delete(in path : String) -metadata 1 1 -metadata Send/Get data * -filters «interface» Filter +init(in metadata : MetadataRepository) +process(in userid : String, in ts : Long, in url : String, in data : Byte[*]) : Byte[*] KIS Wrapper DataUncompressor +init(in metadata : MetadataRepository) +process(in userid : String, in ts : Long, in data : Byte[*], in url : String) : Byte[*] 1 AnomalyDetector +init(in metadata 1 : MetadataRepository) +process(in userid : String, in ts : Long, in data : Byte[*], in url : String) : Byte[*] DataTransmitter +init(in metadata : MetadataRepository) +process(in userid : String, in ts : Long, in url : String, in data : Byte[*]) : Byte[*] -notifier AnomalyListener 1 +newanomaly(in anomalyconfigid : String, in anomalyid : String) 1 Figure 9: Health Monitor Data Postprocess Subdiagram As shown in the diagram, every request is received by the DataPostprocessFacade. In this case, only one service is available: receiving preprocessed data from the Health Monitor 60 / 305

61 Client. Every request is validated by the SecurityController. Then the request is forwarded to the DataPostprocessController, which in turn calls the DataPostprocessor, responsible for implementing a filter chain. To that end, the DataPostprocessor must ask the MetadataRepository, in order to know the sequence of filters to apply to each inbound request, and retrieve the different filters from the FilterRegistry. Finally, filters are invoked in the exact order they were specified. Three main filters are implemented: the DataUncompressor, the AnomalyDetector and the DataTransmitter. The DataUncompressor must work in combination with the DataCompressor filter implemented in the Health Monitor Client, and its purpose is to uncompress incoming data for further postprocessing. The AnomalyDetector retrieves anomaly configurations from the MetadataRepository and tries to detect anomalies in the incoming data. If an anomaly is detected it is written to the MetadataRepository and notified to the AnomalyListener element. This one in turn will look for alarms configured for that anomaly in the MetadataRepository and if they exist, then the alarm instance gets created and the notification process begins. The health profile functional aspect in depicted in the following subdiagram (seefigure 10): HealthProfileFacade +addmedicalrecord(in auth : SecurityInfo, in patientid : String, in record : MedicalRecord) : String +findmymedicalrecords(in auth : SecurityInfo, in criteria : String = null) : MedicalRecord[*] +findmedicalrecordsbypatient(in auth : SecurityInfo, in patientid : String, in criteria : String = null) : MedicalRecord[*] +removemedicalrecord(in auth : SecurityInfo, in recordid : String) +addpermissiontocarer(in auth : SecurityInfo, in carerid : String, in permission : Permission) : String +findmycarers(in auth : SecurityInfo) : Carer[*] +findmycarerpermissions(in auth : SecurityInfo, in carerid : String) : Permission[*] +findmypatients(in auth : SecurityInfo, in criteria : String) : Patient[*] +findmypatientpermissions(in auth : SecurityInfo, in patientid : String) : Permission[*] +removepermission(in auth : SecurityInfo, in permid : String) 1 1 -security SecurityController 1 -controller HealthProfileController 1 +validateidentity(in auth : SecurityInfo) : Boolean +validateoperation(in auth : SecurityInfo, in op : OperationInfo) : Boolean +addmedicalrecord(in userid : String, in patientid : String, in record : MedicalRecord) : String +findmymedicalrecords(in userid : String, in criteria : String) : MedicalRecord[*] +findmedicalrecordsbypatient(in userid : SecurityInfo, in patientid : String, in criteria : String) : MedicalRecord[*] +removemedicalrecord(in userid : String, in recordid : String) +addpermissiontocarer(in userid : String, in carerid : String, in permission : Permission) : String +findmycarers(in userid : String) : Carer[*] +findmycarerpermissions(in userid : String, in carerid : String) : Permission[*] +findmypatients(in userid : String, in criteria : String) : Patient[*] +findmypatientpermissions(in 1 userid : String, in patientid : String) : Permission[*] +removepermission(in userid : String, in permid : String) metadata 1 MetadataRepository +read(in path : String, in criteria : String) : HashMap[*] +write(in path : String, in value : HashMap) +delete(in path : String) -metadata 1 -metadata 1 CarersDataManager 1 +addpermissiontocarer(in userid : String, in carerid : String, in permission : Permission) : String +findcarersbypatient(in patientid : String) : Carer[*] +findcarerpermissionsonpatient(in carerid : String, in patientid : String) : Permission[*] +findpatientsbycarer(in carerid : String, in criteria : String) : Patient[*] +removepermission(in permid : String) 1 HealthDataManager +addmedicalrecord(in patientid : String, in record : MedicalRecord) : String +findmedicalrecordsbypatient(in patientid : String, in criteria : String) : MedicalRecord[*] +removemedicalrecord(in recordid : String) 1 Figure 10: Health Monitor Health Profile Subdiagram As before, every request is received by the HealthProfileFacade. This one checks the operation validity making use of the SecurityController. If everything is correct the request is forwarded to the HealthProfileController, which makes extra checking on the request 61 / 305

62 and finally forwards either to the HealthDataManager or the CarersDataManager, depending on the request type. The HealthDataManager implements all operations related with patients health profile management. The CarersDataManager implements all operations related with the patient-carer relationship, mainly permissions. The Health Monitor configuration aspect in depicted in the following subdiagram (seefigure 11): ConfiguratorFacade +addsensor(in auth : SecurityInfo, in url : String, in sensorconfig : HashMap = null, in processingconfig : DataProcessingConfig = null) : String +updatesensor(in auth : SecurityInfo, in sensorid : String, in sensorconfig : HashMap = null, in processingconfig : DataProcessingConfig = null) +findsensorbyid(in auth : SecurityInfo, in sensorid : String) : Sensor +findmysensors(in auth : SecurityInfo, in criteria : String) : Sensor[*] +findsensorsbypatient(in auth : SecurityInfo, in patientid : String) : Sensor[*] +removesensor(in auth : SecurityInfo, in sensorid : String) +attachsensortopatient(in auth : SecurityInfo, in sensorid : String, in patientid : String) +detachsensorfrompatient(in auth : SecurityInfo, in sensorid : String, in patientid : String) +addanomalyconfig(in auth : SecurityInfo, in sensorid : String, in config : AnomalyConfig) : String +updateanomalyconfig(in auth : SecurityInfo, in configid : String, in config : AnomalyConfig) +findanomalyconfigsbysensor(in auth : SecurityInfo, in sensorid : String) : AnomalyConfig[*] +removeanomalyconfig(in auth : SecurityInfo, in configid : String) 1 1 -controller ConfiguratorController 1 -security 1 SecurityController +validateidentity(in auth : SecurityInfo) : Boolean +validateoperation(in auth : SecurityInfo, in op : OperationInfo) : Boolean +addsensor(in userid : String, in url : String, in sensorconfig : HashMap = null, in processingconfig : DataProcessingConfig = null) : String +updatesensor(in userid : String, in sensorid : String, in sensorconfig : HashMap = null, in processingconfig : DataProcessingConfig = null) +findsensorbyid(in userid : String, in sensorid : String) : Sensor +findmysensors(in userid : String, in criteria : String) : Sensor[*] +findsensorsbypatient(in userid : String, in patientid : String) : Sensor[*] +removesensor(in userid : String, in sensorid : String) +attachsensortopatient(in userid : String, in sensorid : String, in patientid : String) +detachsensorfrompatient(in userid : String, in sensorid : String, in patientid : String) +addanomalyconfig(in userid : String, in sensorid : String, in config : AnomalyConfig) : String +updateanomalyconfig(in userid : String, in configid : String, in config : AnomalyConfig) +findanomalyconfigsbysensor(in userid : String, in sensorid : String) : AnomalyConfig[*] 1 +removeanomalyconfig(in userid : String, in configid : String) metadata 1 MetadataRepository +read(in path : String, in criteria : String) : HashMap[*] +write(in path : String, in value : HashMap) +delete(in path : String) -metadata 1 -metadata 1 AnomalyConfigurator 1 +addanomalyconfig(in sensorid : String, in config : AnomalyConfig) : String +updateanomalyconfig(in configid : String, in config : AnomalyConfig) +findanomalyconfigsbysensor(in sensorid : String) : AnomalyConfig[*] +removeanomalyconfig(in configid : String) 1 SensorConfigurator +addsensor(in ownerid : String, in url : String, in sensorconfig : HashMap = null, in processingconfig : DataProcessingConfig = null) : String +updatesensor(in sensorid : String, in sensorconfig : HashMap = null, in processingconfig : DataProcessingConfig = null) +findsensorbyid(in sensorid : String) : Sensor +findsensorsbyowner(in ownerid : String, in criteria : String) : Sensor[*] +findsensorsbypatient(in patientid : String) : Sensor[*] +removesensor(in sensorid : String) +attachsensortopatient(in sensorid : String, in patientid : String) +detachsensorfrompatient(in sensorid : String, in patientid : String) 1 Figure 11: Health Monitor Configurator Subdiagram Every request is received by the ConfiguratorFacade. The operation validity is checked and the ConfiguratorProcessor gets invoked. This one invokes either the SensorConfigurator or the AnomalyConfigurator. Each of them deals with a particular kind of operations, sensor related operations or anomaly related operations respectively. The alarm functional aspect in depicted in the following subdiagram (see Figure 12): 62 / 305

63 AlarmFacade +addalarmconfig(in auth : SecurityInfo, in anomalyconfigid : String, in alarmconfig : AlarmConfig) : String +updatealarmconfig(in auth : SecurityInfo, in configid : String, in config : AlarmConfig) +findalarmconfigs(in auth : SecurityInfo, in anomalyconfigid : String) : AlarmConfig[*] +findalarmconfigbyid(in auth : SecurityInfo, in configid : String) : AlarmConfig +removealarmconfig(in auth : SecurityInfo, in configid : String) +findalarms(in auth : SecurityInfo, in alarmconfigid : String, in criteria : String) : Alarm +removealarm(in auth : SecurityInfo, in alarmid : String) +addalarmtracking(in auth : SecurityInfo, in alarmid : String, in tracking : AlarmTracking) : String +findalarmtrackings(in auth : SecurityInfo, in alarmid : String, in criteria : String) : AlarmTracking[*] +findalarmtrackingbyid(in auth : SecurityInfo, in 1trackingId : String) : AlarmTracking +removealarmtracking(in auth : SecurityInfo, in trackingid : String) 1 -security SecurityController 1 AlarmController 1 +validateidentity(in auth : SecurityInfo) : Boolean +validateoperation(in auth : SecurityInfo, in op : OperationInfo) : Boolean +addalarmconfig(in userid : String, in anomalyconfigid : String, in alarmconfig : AlarmConfig) : String +updatealarmconfig(in userid : String, in configid : String, in config : AlarmConfig) +findalarmconfigs(in userid : String, in anomalyconfigid : String) : AlarmConfig[*] +findalarmconfigbyid(in userid : String, in configid : String) : AlarmConfig +removealarmconfig(in userid : String, in configid : String) +findalarms(in userid : String, in alarmconfigid : String, in criteria : String) : Alarm +removealarm(in userid : String, in alarmid : String) +addalarmtracking(in userid : String, in alarmid : String, in tracking : AlarmTracking) : String +findalarmtrackings(in userid : String, in alarmid : String, in criteria : String) : AlarmTracking[*] +findalarmtrackingbyid(in 1 userid : String, in 1trackingId : String) : AlarmTracking +removealarmtracking(in userid : String, in trackingid : String) 1 -metadata 1 MetadataRepository +read(in path : String, in criteria : String) : HashMap[*] +write(in path : String, in value : HashMap) +delete(in path : String) -metadata -metadata 1 -metadata metadata -metadata 1 1 AlarmTracker +addalarmtracking(in alarmid : String, in tracking : AlarmTracking) : String +findalarmtrackings(in alarmid : String, in criteria : String) : AlarmTracking[*] +findalarmtrackingbyid(in trackingid : String) : AlarmTracking +removealarmtracking(in trackingid : String) AlarmNotifier +notifyalarm(in alarmid : String) +run() AlarmGenerator +newalarm(in alarmconfigid : String, in anomalyid : String, in alarminfo : String) : String +findalarms(in configid : String, in criteria : String) : Alarm[*] +removealarm(in alarmid : String) 1 1 AnomalyListener 1 +newanomaly(in anomalyconfigid : String, in anomalyid : String) 1 AlarmConfigurator 1 +addalarmconfig(in anomalyconfigid : String, in alarmconfig : AlarmConfig) : String +updatealarmconfig(in configid : String, in config : AlarmConfig) +findalarmconfigs(in anomalyconfigid : String) : AlarmConfig[*] +findalarmconfigbyid(in configid : String) : AlarmConfig +removealarmconfig(in configid : String) 1 Figure 12: Health Monitor Alarm Subdiagram The AlarmFacade receives all requests and after checking its validity using the SecurityController forwards them to the AlarmController. In turn the AlarmController makes extra checking, consulting the MetadataRepository and redirects the request to the responsible component, namely: the AlarmConfigurator, the AlarmGenerator or the AlarmTracker. The AlarmConfigurator is responsible for configuring alarms. The AlarmGenerator is responsible for generating alarms, as the result of anomalies detection. To that end, when the AnomalyListener receives a new anomaly, it finds out whether a new alarm must be generated. If an alarm has been generated, it must be notified to the corresponding target, using the AlarmNotifier. Finally, the AlarmTracker keeps track of every generated alarm. The data analysis functional aspect in depicted in the following subdiagram (see Figure 13): 63 / 305

64 DataAnalysisFacade +finddata(in auth : SecurityInfo, in sensorid : String, in criteria : String) : DataPackage[*] +analyzedata(in auth : SecurityInfo, in sensorid : String, in analysistype : String, in criteria : String) : DataPackage[*] +removedata(in auth : SecurityInfo, in sensorid : String, in criteria : String) +findanomalies(in auth : SecurityInfo, in anomalyconfigid : String, in criteria) : Anomaly[*] +removeanomaly(in auth : SecurityInfo, in anomalyid : String) +removeanomalies(in auth : SecurityInfo, in anomalyconfigid : String, in criteria) 1 1 DataAnalysisController 1 -security 1 SecurityController +validateidentity(in auth : SecurityInfo) : Boolean +validateoperation(in auth : SecurityInfo, in op : OperationInfo) : Boolean +finddata(in userid : String, in sensorid : String, in criteria : String) : DataPackage[*] +analyzedata(in userid : String, in sensorid : String, in analysistype : String, in criteria : String) : DataPackage[*] +removedata(in userid : String, in sensorid : String, in criteria : String) +findanomalies(in userid : String, in anomalyconfigid : String, in criteria) : Anomaly[*] 1 +removeanomaly(in userid : String, in anomalyid 11: String) +removeanomalies(in userid : String, in anomalyconfigid : String, in criteria) -metadata 1 MetadataRepository +read(in path : String, in criteria : String) : HashMap[*] +write(in path : String, in value : HashMap) +delete(in path : String) 1 1 AnomalyDetector -metadata 1 -metadata 1 -metadata 1 1 +findanomalies(in anomalyconfigid : String, in criteria) : Anomaly[*] +removeanomaly(in anomalyid : String) +removeanomalies(in anomalyconfigid : String, in criteria) 1 DataAnalyzer 1 +analyzedata(in sensorid : String, in analysistype : String, in criteria : String) : DataPackage[*] 1 DataLoader +finddata(in sensorid : String, in criteria : String) : DataPackage[*] +removedata(in sensorid : String, in criteria : String) 1 Figure 13: Health Monitor Data Analysis Subdiagram All requests are captured by the DataAnalysisFacade, which validates them using the SecurityController and forwards correct requests to the DataAnalysisController. This one in turn redirects to one of the following components: the DataLoader, the DataAnalyzer or the AnomalyDetector. The DataLoader loads data from KIS. The DataAnalyzer analyzes data in order to obtain extra parameters. The AnomalyDetector gives access to detected anomalies Interfaces The Health Monitor exports two interfaces to the rest of the ALFRED system: The SAF interface is published to the components installed in the ALFREDenabled device. Its main purpose is to give access to external sensors. The Health Monitor interface is published remotely by the Health Monitor Server and it may be consumed by any component. Its main purpose is to publish the main functionalities of the Health Monitor subsystem. The SAF interface will be accessed through the SAF API Wrapper, which is a simple Java library for consuming SAF services. It will be presented in the following sections. The Health Monitor interface may be accessed either directly, using the RESTful services or through the Health Monitor API Wrapper, which is again a simple Java library that hides communications details and makes easy the consumption of the Health Monitor exported services. Both interfaces will be presented in the following paragraphs. 64 / 305

65 Java interface of the SAF API Wrapper Three entities are managed by the Java interface of the SAF API Wrapper: the SAFFacade, the SensorDriver and the SensorListener. These three entities publish the operations presented in the class diagram included in section In the following sections we present the operations published by each of these entities SAFFacade The main entry point of SAF Register Driver Before receiving measurements from a particular sensor, the sensor driver must be registered in the environment. This operation allows registering a particular sensor driver in the environment. A driver is an element that implements the SensorDriver interface. This interface publishes all the operations required for communicating against an external sensor. The SensorDriver interface is intended to be consumed internally by the SAF environment. Parameters: driver: The driver to register Return Value: None Error Handling: SAFException if any error arises. Remarks: None Listing 6: Health Monitor Java Interface Register Driver /** driver the driver to register SAFException if any error arises */ void registerdriver(sensordriver driver) throws SAFException; Unregister Driver Unregisters a previously defined driver. Parameters: driver: The driver to unregister Return Value: None Error Handling: SAFException if any error arises. 65 / 305

66 Remarks: None Listing 7: Health Monitor Java Interface Unregister Driver /** driver the driver to unregister SAFException if any error arises */ void unregisterdriver(sensordriver driver) throws SAFException; Register Listener Registers a listener to begin receiving measurements from a particular sensor. Several listeners may be registered for the same sensor. A sensor is identified by a unique URL. A listener is an element that implements the SensorListener interface. Parameters: url: The sensor URL listener: The listener to register Return Value: None Error Handling: SAFException if any error arises. Remarks: None Listing 8: Health Monitor Java Interface Register Listener /** url the sensor URL listener the listener to register SAFException if any error arises */ void registerlistener(string url, SensorListener listener) throws SAFException; Unregister Listener Unregisters a previously registered listener for a concrete sensor. Parameters: url: The sensor URL listener: The listener to unregister Return Value: None 66 / 305

67 Error Handling: SAFException if any error arises. Remarks: None Listing 9: Health Monitor Java Interface Unregister Listener /** url the sensor URL listener the listener to unregister SAFException if any error arises */ void unregisterlistener(string url, SensorListener listener) throws SAFException; SensorDriver Interface that models a sensor driver in the system Supports URL Determines whether a particular URL is supported by this sensor driver. Parameters: url: The URL to check Return Value: true if supported; otherwise false Error Handling: None Remarks: None Listing 10: Health Monitor Java Interface Supports URL /** url the URL to check true if supported; otherwise false */ boolean supportsurl(string url); Get Metainfo To retrieve metainformation about the driver and/or a particular sensor managed by the driver. Parameters: url: The sensor URL (optional). If not specified then information about the driver is retrieved. 67 / 305

68 Return Value: A collection of attribute=value pairs containing all the properties of the driver or the sensor. Error Handling: None Remarks: None Listing 11: Health Monitor Java Interface Get Metainfo /** url The sensor URL (optional). If not specified then information about the * driver is retrieved. A collection of attribute=value pairs containing all the properties of the * driver or the sensor */ HashMap getmetainfo(string url); Bind Sensor Before listening to a particular sensor, it is necessary to bind it. Binding a sensor may entail security/authentication checkings, or transferring sensor configuration parameters settings. Parameters: url: The sensor URL. props: The parameters required to bind a particular sensor (optional). Return Value: true if success; otherwise false. Error Handling: None Remarks: None Listing 12: Health Monitor Java Interface Bind /** url The sensor props The parameters required to bind a particular sensor (optional). true if success; otherwise false. */ boolean bind(string url, HashMap props); Unbind Sensor Unbind a particular sensor. This operation must be done before stopping reading measurements from a particular sensor. Parameters: 68 / 305

69 url: The sensor URL Return Value: None. Error Handling: None Remarks: None /** url The sensor URL */ void unbind(string url); Listing 13: Health Monitor Java Interface Unbind Sensor Read Measurement Read next measurement from a particular sensor. The sensor should have been bound before. Parameters: url: The sensor URL Return Value: The measurement. Error Handling: SensorDriverException if any error arises Remarks: None Listing 14: Health Monitor Java Interface Read Measurement /** url The sensor URL the measurement *@throws SensorDriverException if any error arises */ Byte[] read(string url) throws SensorDriverException; Write Information Send information to the sensor. This may include setting configuration parameters, or any other kind of reverse communication between SAF and the sensor driver. Parameters: url: The sensor URL data: the data to write 69 / 305

70 Return Value: None Error Handling: SensorDriverException if any error arises Remarks: None Listing 15: Health Monitor Java Interface Write Information /** url The sensor URL data the data to write *@throws SensorDriverException if any error arises */ void write(string url, Byte[] data) throws SensorDriverException; SensorListener Interface that models a sensor listener in the system Get Properties Returns some configuration properties in order to enable monitoring a particular sensor. Some examples are: authentication configuration, accuracy configuration, sampling period configuration, etc. Parameters: None Return Value: The configuration properties Error Handling: None Remarks: None Listing 16: Health Monitor Java Interface Get Properties /** the configuration properties */ HashMap getprops(); Receive Measurement The listener receives the next available measurement coming from the registered sensor. Parameters: 70 / 305

71 ts: the timestamp where the measurement was taken url: the sensor URL data: the measurement data Return Value: None Error Handling: None Remarks: None Listing 17: Health Monitor Java Interface Receive Measurement /** ts the timestamp where the measurement was taken url The sensor URL data the measurement data */ void data(long ts, String url, Byte[] data) throws SensorDriverException; RESTful Interfaces of the Health Monitor This section describes the RESTful interface provided by the Health Monitor subcomponent. The interface is implemented by the Health Monitor Server and consumed by any component which requires its functionalities. In particular, the Health Monitor Client and the Web Portal of the Health Monitor will be two components that will be constantly accessing this interface Upload Data Table 13: Health Monitor RESTful Interface Upload Data Upload Data Upload measurement data to the HMS Request Request URL POST Resource Parameters ticket Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " JSON Object data Required Array of An array of data packages, containing measurement data 71 / 305

72 DataPackage JSON Attributes DataPackage objects ts Required long url Required string data Required string Example: see DataPackage JSON Attributes Timestamp of the data package Example: Sensor URL Example: "saf://tshirt/ /heart" String encoded measurement data Example: "244244" Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found { } Listing 18: Health Monitor - Example JSON Supplied for the Upload Data Operation "ticket" : "06632c44dcca4f7f825c0011c ", "data" : [ { "ts":" ", "url":"saf://tshirt/ /heart", "data":"244244" } ] Add Medical Record Table 14: Health Monitor RESTful Interface Add Medical Record Add Medical Record Add medical record to a patient Request Request URL POST Resource Parameters ticket String encoded ticket that contains the issuer identity 72 / 305

73 Required string patientid Required string type Required string ts Required long info Required string Example: "06632c44dcca4f7f825c0011c " ID of the patient Example: "06632c44-dcca-4f7f-825c-0011c " Medical record type Example: "age" Medical record timestamp Example: " " Medical record info Example: 50 Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Attributes medicalrecordid Required String Medical record ID Example: 06632c44-dcca-4f7f-825c-0011c Listing 19: Health Monitor - Example JSON Response Containing the Upload Data Operation Result { "medicalrecordid" : "06632c44-dcca-4f7f-825c-0011c " } Find My Medical Records 73 / 305

74 Table 15: Health Monitor RESTful Interface Find My Medical Records Find My Medical Records Find the medical records of the request issuer Request Request URL GET Resource Parameters ticket Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Criteria for the query Example: age Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object MedicalRecord JSON Attributes medicalrecords Required Array of MedicalRecord objects id Required string type Required string ts Required long info Required string Retrieved medical records Example: see MedicalRecord JSON Attributes Medical record ID Example: 06632c44-dcca-4f7f-825c-0011c Medical record type Example: disease-start Medical record timestamp Example: " " Medical record info Example: arthritis 74 / 305

75 { } Listing 20: Health Monitor - Example JSON Response Containing the Find My Medical Records Operation Result "medicalrecords" : [ { "id":"06632c44-dcca-4f7f-825c-0011c ", "type":"disease-start", "ts":" ", "info":"arthritis" } ] Find Medical Records by Patient Table 16: Health Monitor RESTful Interface Find My Medical Records by Patient Find My Medical Records Find the medical records of the specified patient Request Request URL GET Resource Parameters ticket Required String patientid Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Patient ID Example: 06632c44-dcca-4f7f-825c-0011c Criteria for the query Example: age Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object medicalrecords Required Array of Retrieved medical records 75 / 305

76 MedicalRecord JSON Attributes MedicalRecord objects id Required string type Required string ts Required long info Required string Example: see MedicalRecord JSON Attributes Medical record ID Example: 06632c44-dcca-4f7f-825c-0011c Medical record type Example: disease-start Medical record timestamp Example: " " Medical record info Example: arthritis { } Listing 21: Health Monitor - Example JSON Response Containing the Find My Medical Records Operation Result "medicalrecords" : [ { "id":"06632c44-dcca-4f7f-825c-0011c ", "type":"disease-start", "ts":" ", "info":"arthritis" } ] Remove Medical Record Table 17: Health Monitor RESTful Interface Remove Medical Record Remove Medical Record Remove the specified medical record Request Request URL DELETE Resource Parameters ticket Required String medicalrecordid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Medical record ID Example: 06632c44-dcca-4f7f-825c-0011c / 305

77 Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found Add Permission to Carer Table 18: Health Monitor RESTful Interface Add Permission Carer Add Permission Carer Add specific permission to a carer Request Request URL POST Resource Parameters ticket Required String carerid Required String type Required String info Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " ID of the carer Example: 06632c44-dcca-4f7f-825c-0011c Permission type Example: full-access Extra info included in the permission Example: empty Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 77 / 305

78 JSON Attribute permissionid Required String Permission ID Example: 06632c44-dcca-4f7f-825c-0011c Listing 22: Health Monitor - Example JSON Response Containing the Add Permission to Carer Operation Result { "permissionid" : "06632c44-dcca-4f7f-825c-0011c " } Find My Carers Table 19: Health Monitor RESTful Interface Find My Carers Find My Carers Find the carers of the request issuer Request Request URL GET permission/findcarers Resource Parameters ticket Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object carers Required Array of String Array of carer IDs 78 / 305

79 { } Listing 23: Health Monitor - Example JSON Response containing the Find My Carers Operation Result "carers" : [ "06632c44-dcca-4f7f-825c-0011c " ] Find My Carer Permissions Table 20: Health Monitor RESTful Interface Find My Carers Permissions Find My Carers Permissions Find the permissions of the specified user carer Request Request URL GET Resource Parameters ticket Required String careid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Carer ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object Permission JSON Attributes permissions Required Array of Permission objects id Required string type Array of permissions Example: see Permission JSON Attributes Permission ID Example: 06632c44-dcca-4f7f-825c-0011c Permission type 79 / 305

80 Required string info Required string Example: full-access Permission info Example: "empty" { } Listing 24: Health Monitor - Example JSON Response containing the Find My Carer Permissions Operation Result "permissions" : [ { "id":"06632c44-dcca-4f7f-825c-0011c ", "type":"full-access", "info":"empty" } ] Find My Patients Table 21: Health Monitor RESTful Interface Find My Patients Find My Patients Find the patients of the request issuer Request Request URL GET permission/findpatients Resource Parameters ticket Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object patients Required Array of String Array of patient IDs 80 / 305

81 { } Listing 25: Health Monitor - Example JSON Response Containing the Find My Patients Operation Result "patients" : [ "06632c44-dcca-4f7f-825c-0011c " ] Find My Patient Permissions Table 22: Health Monitor RESTful Interface Find My Patient Permissions Find My Patient Permissions Find the permissions granted by the specified patient Request Request URL GET Resource Parameters ticket Required String patientid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Carer ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object Permission JSON Attributes permissions Required Array of Permission objects id Required string type Array of permissions Example: see Permission JSON Attributes Permission ID Example: 06632c44-dcca-4f7f-825c-0011c Permission type 81 / 305

82 Required string info Required string Example: full-access Permission info Example: "empty" { } Listing 26: Health Monitor - Example JSON Response Containing the Find My Patient Permissions Operation Result "permissions" : [ { "id":"06632c44-dcca-4f7f-825c-0011c ", "type":"full-access", "info":"empty" } ] Remove Permission Table 23: Health Monitor RESTful Interface Remove Permission Remove Medical Record Remove the specified permission Request Request URL DELETE permission/:permid Resource Parameters ticket Required String permid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Permission ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found Add Sensor 82 / 305

83 Table 24: Health Monitor RESTful Interface Add Sensor Add Sensor Add new sensor Request Request URL POST Resource Parameters JSON Objects ticket Required String url Required String sensorconfig Optional JSON Object type Open hashmap of String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor URL Example: "saf://tshirt/ /heart" Sensor configuration dataprocessin ginfo JSON Attributes & Objects dataprocessinginfo Optional JSON object of type DataProcessingInfo filters Required String array props RequieredJSON object of type Open hashmap Data processing sensor configuration Example: see DataProcessingInfo JSON Attributes List of filters to apply on incoming data Example: "accuracy":"10" Configuration parameters for the filters Example: "filters": ["obtain-max", "compress", "transmit"], "props": {"maxofhowmanyvalues":"10", "compressalgorithm ":"ZIP"} Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 83 / 305

84 JSON Attribute sensorid Required String SensorID Example: "06632c44-dcca-4f7f-825c-0011c " { } Listing 27: Health Monitor - Example JSON Supplied for the Add Sensor Operation "ticket" : "06632c44dcca4f7f825c0011c ", "url" : " saf://tshirt/ /heart", "sensorconfig" : { "accuracy":"10", "sample-period":"100" }, "dataprocessinginfo" : { "filters": ["obtain-max", "compress", "transmit"], "props": { "maxofhowmanyvalues":"10", "compress-algorithm ":"ZIP" } } Listing 28: Health Monitor - Example JSON Response Containing the Add Sensor Operation Result { "sensorid" : "06632c44-dcca-4f7f-825c-0011c " } Update Sensor Table 25: Health Monitor RESTful Interface Update Sensor Update Sensor Updates the specified sensor configuration Request Request URL PUT Resource Parameters ticket Required String sensorid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: "06632c44-dcca-4f7f-825c-0011c " 84 / 305

85 JSON Objects sensorconfig Optional JSON Object type Open hashmap of Sensor configuration dataprocessin ginfo JSON Attributes & Objects dataprocessinginfo Optional JSON object of type DataProcessingInfo filters Required String array props RequieredJSON object of type Open hashmap Data processing sensor configuration Example: see DataProcessingInfo JSON Attributes List of filters to apply on incoming data Example: "accuracy":"10" Configuration parameters for the filters Example: "filters": ["obtain-max", "compress", "transmit"], "props": {"maxofhowmanyvalues":"10", "compressalgorithm ":"ZIP"} Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found { } Listing 29: Health Monitor - Example JSON Supplied for the Update Sensor Operation "ticket" : "06632c44dcca4f7f825c0011c ", "sensorid" : "06632c44-dcca-4f7f-825c-0011c ", "sensorconfig" : { "accuracy":"10", "sample-period":"100" }, "dataprocessinginfo" : { "filters": ["obtain-max", "compress", "transmit"], "props": { "maxofhowmanyvalues":"10", "compress-algorithm ":"ZIP" } } 85 / 305

86 Find Sensor by Id Table 26: Health Monitor RESTful Interface Find Sensor by Id Find Sensor By Id Updates the specified sensor configuration Request Request URL GET Resource Parameters ticket Required String sensorid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: "06632c44-dcca-4f7f-825c-0011c " Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object Sensor JSON Attributes & Objects sensor Required JSON Object type sensor id Required String url Required String sensorconfig Optional JSON Object type Open hashmap of of The specified sensor information Sensor ID Example: "06632c44-dcca-4f7f-825c-0011c " Sensor URL Example: "saf://tshirt/ /heart" Sensor configuration dataprocessinginfo Optional JSON object of type Data processing sensor configuration Example: see DataProcessingInfo JSON Attributes 86 / 305

87 DataProcessingInfo dataprocessin ginfo JSON Attributes & Objects filters Required String array props RequieredJSON object of type Open hashmap List of filters to apply on incoming data Example: "accuracy":"10" Configuration parameters for the filters Example: "filters": ["obtain-max", "compress", "transmit"], "props": {"maxofhowmanyvalues":"10", "compressalgorithm ":"ZIP"} 87 / 305

88 Listing 30: Health Monitor - Example JSON Response Containing the Find Sensor by Id Operation Result { } "sensor" : { "id" : "06632c44-dcca-4f7f-825c-0011c ", "url" : " saf://tshirt/ /heart", "sensorconfig" : { "accuracy":"10", "sample-period":"100" }, "dataprocessinginfo" : { "filters": ["obtain-max", "compress", "transmit"], "props": { "maxofhowmanyvalues":"10", "compress-algorithm ":"ZIP" } } } Find My Sensors Table 27: Health Monitor RESTful Interface Find Sensor by Criteria Find Sensor By Criteria Find sensors owned by the request issuer Request Request URL GET Resource Parameters ticket Required String criteria Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Criteria for the query Example: "breath monitor" Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 88 / 305

89 JSON Object sensor Required JSON Object Array of Sensor objects of The sensors that meet the specific criteria Example: see Sensor JSON Attributes Sensor JSON Attributes & Objects id Required String url Required String Sensor ID Example: "06632c44-dcca-4f7f-825c-0011c " Sensor URL Example: "saf://tshirt/ /heart" sensorconfig Optional JSON Object type Open hashmap of Sensor configuration dataprocessin ginfo JSON Attributes & Objects dataprocessinginfo Optional JSON object of type DataProcessingInfo filters Required String array props RequieredJSON object of type Open hashmap Data processing sensor configuration Example: see DataProcessingInfo JSON Attributes List of filters to apply on incoming data Example: "accuracy":"10" Configuration parameters for the filters Example: "filters": ["obtain-max", "compress", "transmit"], "props": {"maxofhowmanyvalues":"10", "compressalgorithm ":"ZIP"} 89 / 305

90 { } Listing 31: Health Monitor - Example JSON Response Containing the Find My Sensors Operation Result "sensors" : [ { "id" : "06632c44-dcca-4f7f-825c-0011c ", "url" : " saf://tshirt/ /heart", "sensorconfig" : { "accuracy":"10", "sample-period":"100" }, "dataprocessinginfo" : { "filters": ["obtain-max", "compress", "transmit"], "props": { "maxofhowmanyvalues":"10", "compress-algorithm ":"ZIP" } } } ] Find Sensors by Patient Table 28: Health Monitor RESTful Interface Find Sensor by Patient Find Sensor By Patient Find sensors attached to the specified patient Request Request URL GET Resource Parameters ticket Required String patientid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Patient ID Example: "06632c44-dcca-4f7f-825c-0011c " Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 90 / 305

91 JSON Object Sensor JSON Attributes & Objects sensor Required JSON Object Array of Sensor objects id Required String url Required String sensorconfig Optional JSON Object type Open hashmap of of The sensors attached to the patient Example: see Sensor Sensor ID Example: "06632c44-dcca-4f7f-825c-0011c " Sensor URL Example: "saf://tshirt/ /heart" Sensor configuration dataprocessinginfo Optional JSON object of type DataProcessingInfo Data processing sensor configuration Example: see DataProcessingInfo JSON Attributes dataprocessin ginfo JSON Attributes filters Required String array props RequieredJSON object of type Open hashmap List of filters to apply on incoming data Example: "accuracy":"10" Configuration parameters for the filters Example: "filters": ["obtain-max", "compress", "transmit"], "props": {"maxofhowmanyvalues":"10", "compressalgorithm ":"ZIP"} 91 / 305

92 { } Listing 32: Health Monitor - Example JSON Response Containing the Find My Sensors Operation Result "sensors" : [ { "id" : "06632c44-dcca-4f7f-825c-0011c ", "url" : " saf://tshirt/ /heart", "sensorconfig" : { "accuracy":"10", "sample-period":"100" }, "dataprocessinginfo" : { "filters": ["obtain-max", "compress", "transmit"], "props": { "maxofhowmanyvalues":"10", "compress-algorithm ":"ZIP" } } } ] Remove Sensor Table 29: Health Monitor RESTful Interface Remove Sensor Remove Sensor Remove the specified sensor Request Request URL DELETE Resource Parameters ticket Required String sensorid Required String patientid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: 06632c44-dcca-4f7f-825c-0011c Patient ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 92 / 305

93 401 Unauthorized 404 Service not found Attach Sensor to Patient Table 30: Health Monitor RESTful Interface Attach Sensor Attach Sensor Attaches the specified sensor to the specified patient Request Request URL POST Resource Parameters ticket Required String sensorid Required String patientid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: 06632c44-dcca-4f7f-825c-0011c Patient ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 93 / 305

94 Detach Sensor from Patient Table 31: Health Monitor RESTful Interface Detach Sensor Attach Sensor Detaches the specified sensor from the specified patient Request Request URL DELETE Resource Parameters ticket Required String sensorid Required String patientid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: 06632c44-dcca-4f7f-825c-0011c Patient ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found Add Anomaly Configuration Table 32: Health Monitor RESTful Interface Add Anomaly Configuration Add Anomaly Configuration Add an anomaly configuration to the specified sensor Request Request URL POST Resource Parameters ticket Required String sensorid String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID 94 / 305

95 Required String formula Required String Example: 06632c44-dcca-4f7f-825c-0011c Anomaly formula Example: temperature above 40 Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Attribute anomalyconfigid Required String Anomaly configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Listing 33: Health Monitor - Example JSON Response Containing the Add Anomaly Configuration Operation Result { "anomalyconfigid" : "06632c44-dcca-4f7f-825c-0011c " } Update Anomaly Configuration Table 33: Health Monitor RESTful Interface Update Anomaly Configuration Update Anomaly Configuration Update the specified anomaly configuration Request Request URL POST Resource Parameters ticket Required String anomalyconfigid Required String formula Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Anomaly configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Anomaly formula Example: temperature above / 305

96 Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found Find Anomaly Configurations by Sensor Table 34: Health Monitor RESTful Interface Find Anomaly Configurations Find Anomaly Configurations Find anomaly configurations set for the specified sensor Request Request URL GET Resource Parameters ticket Required String sensorid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: "06632c44-dcca-4f7f-825c-0011c " Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object anomalyconfigs Required JSON Object of Array of AnomalyConfig objects The anomaly configurations set for the sensor Example: see anomalyconfig JSON Attributes 96 / 305

97 anomalyconfig JSON Attributes id Required String formula Required String Anomaly configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Anomaly configuration formula Example: x -> (x > 1000 x < 10) { } Listing 34: Health Monitor - Example JSON Response Containing the Find Anomaly Configurations by Sensor Operation Result "anomalyconfigs" : [ { "id" : "06632c44-dcca-4f7f-825c-0011c ", "formula" : "x -> (x > 1000 x < 10)" } ] Remove Anomaly Configuration Table 35: Health Monitor RESTful Interface Remove Anomaly Configuration Remove Anomaly Configuration Remove the specified anomaly configuration Request Request URL DELETE Resource Parameters ticket Required String anomalyconfigid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Anomaly configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 97 / 305

98 Add Alarm Configuration Table 36: Health Monitor RESTful Interface Add Alarm Configuration Add Alarm Configuration Add an alarm configuration for the specified anomaly configuration Request Request URL POST Resource Parameters ticket Required String anomalyconfigid Required String type Required String target Required String props Required Open hasmap String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Anomaly configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm type Example: Alarm target Example: Alarm configuration parameters Example: requires-confirmation : yes, priority : high Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Attribute alarmconfigid Required String Anomaly configuration ID Example: 06632c44-dcca-4f7f-825c-0011c / 305

99 Listing 35: Health Monitor - Example JSON Response Containing the Add Alarm Configuration Operation Result { "alarmconfigid" : "06632c44-dcca-4f7f-825c-0011c " } Update Alarm Configuration Table 37: Health Monitor RESTful Interface Update Alarm Configuration Update Alarm Configuration Update the specified alarm configuration Request Request URL PUT Resource Parameters ticket Required String alarmconfigid Required String type Required String target Required String props Required Open hashmap String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm type Example: Alarm target Example: giussepe@lafe.com Alarm configuration parameters Example: requires-confirmation : yes, priority : high Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 99 / 305

100 Find Alarm Configurations Table 38: Health Monitor RESTful Interface Find Alarm Configurations Find Alarm Configurations Find alarms configured for the specified anomaly configuration Request Request URL GET Resource Parameters ticket Required String anomalyconfigid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Anomaly configuration ID Example: "06632c44-dcca-4f7f-825c-0011c " Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object alarmconfig JSON Attributes alarmconfigs Required JSON Object of Array of AlarmConfig objects id Required String type Required String target Required String props Required Open hashmap The configured alarms Example: see alarmconfig JSON Attributes Alarm configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm configuration type Example: Alarm configuration target Example: Alarm configuration specific parameters Example: requires-confirmation : yes, 100 / 305

101 priority : high { } Listing 36: Health Monitor - Example JSON Response Containing the Find Alarm Configurations Operation Result "alarmconfigs" : [ { "id" : "06632c44-dcca-4f7f-825c-0011c ", "type" : " ", "target" : "giusseppe@lafe.com", "props" : { "requires-confirmation : "yes", "priority" : "high" } } ] Find Alarm Configuration by Id Table 39: Health Monitor RESTful Interface Find Alarm Configuration by Id Find Alarm Configuration By Id Find the specified alarm configuration Request Request URL GET Resource Parameters ticket Required String alarmconfigid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm configuration ID Example: "06632c44-dcca-4f7f-825c-0011c " Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 101 / 305

102 JSON Object alarmconfig JSON Attributes alarmconfig Required JSON Object type AlarmConfig id Required String type Required String target Required String props Required Open hashmap of The alarm configuration Example: see alarmconfig JSON Attributes Alarm configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm configuration type Example: Alarm configuration target Example: Alarm configuration specific parameters Example: requires-confirmation : yes, priority : high { } Listing 37: Health Monitor - Example JSON Response Containing the Find Alarm Configurations Operation Result "alarmconfig": { "id" : "06632c44-dcca-4f7f-825c-0011c ", "type" : " ", "target" : "giusseppe@lafe.com", "props" : { "requires-confirmation : "yes", "priority" : "high" } } 102 / 305

103 Remove Alarm Configuration Table 40: Health Monitor RESTful Interface Remove Alarm Configuration Remove Alarm Configuration Remove the specified alarm configuration Request Request URL DELETE Resource Parameters ticket Required String alarmconfigid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found Find Alarms Table 41: Health Monitor RESTful Interface Find Alarms Find Alarms Find triggered alarms belonging to the specified alarm configuration Request Request URL GET Resource Parameters ticket Required String alarmconfigid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm configuration ID Example: "06632c44-dcca-4f7f-825c-0011c " 103 / 305

104 criteria Optional String Criteria for the query Example: priority : high Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object alarmconfig JSON Attributes alarms Required JSON Object Array of Alarm objects id Required String ts Required Long info Required String of The retrieved alarms Example: see alarmconfig JSON Attributes Alarm ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm timestamp Example: Alarm information Example: The blood pressure measurement is too high { } Listing 38: Health Monitor - Example JSON Response containing the Find Alarms Operation Result "alarms" : [ { "id" : "06632c44-dcca-4f7f-825c-0011c ", "ts" : " ", "info" : "The blood pressure measurement is too high" } ] 104 / 305

105 Remove Alarm Table 42: Health Monitor RESTful Interface Remove Alarm Remove Alarm Remove the specified alarm configuration Request Request URL DELETE Resource Parameters ticket Required String alarmid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found Add Alarm Tracking Table 43: Health Monitor RESTful Interface Add Alarm Tracking Add Alarm Tracking Add alarm tracking info to the specified alarm Request Request URL POST Resource Parameters ticket Required String alarmid Required String ts String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm tracking timestamp 105 / 305

106 Required Long info Required String Example: Alarm tracking specific info Example: The alarm has been assisted Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Attribute alarmtrackingid Required String Alarm tracking ID Example: 06632c44-dcca-4f7f-825c-0011c Listing 39: Health Monitor - Example JSON Response Containing the Add Alarm Tracking Operation Result { "alarmtrackingid" : "06632c44-dcca-4f7f-825c-0011c " } Find Alarm Trackings Table 44: Health Monitor RESTful Interface Find Alarm Tracking Find Alarm Tracking Find alarm trackings added to the specified alarm Request Request URL GET Resource Parameters ticket Required String alarmid Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm ID Example: 06632c44-dcca-4f7f-825c-0011c Criteria for the query Example: assisted 106 / 305

107 Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object alarmtracking JSON Attributes alarmtrackings Required JSON Object of Array of Alarm Tracking objects id Required String ts Required Long info Required String The retrieved alarm trackings Example: see alarmtracking JSON Attributes Alarm tracking ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm tracking timestamp Example: Alarm tracking information Example: The alarm has been assisted { } Listing 40: Health Monitor - Example JSON Response Containing the Find Alarm Trackings Operation Result "alarmtrackings" : [ { "id" : "06632c44-dcca-4f7f-825c-0011c ", "ts" : " ", "info" : "The alarm has been assisted" } ] 107 / 305

108 Find Alarm Tracking by Id Table 45: Health Monitor RESTful Interface Find Alarm Tracking by Id Find Alarm Tracking By Id Find the specified alarm tracking Request Request URL GET Resource Parameters ticket Required String alarmtrackingid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm tracking ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object alarmtracking JSON Attributes alarmtrackings Required JSON Object of type Alarm Tracking objects id Required String ts Required Long info Required String The alarm tracking Example: see alarmtracking JSON Attributes Alarm tracking ID Example: 06632c44-dcca-4f7f-825c-0011c Alarm tracking timestamp Example: Alarm tracking information Example: The alarm has been assisted 108 / 305

109 Listing 41: Health Monitor - Example JSON Response Containing the Find Alarm Tracking by Id Operation Result { } "alarmtracking": { "id" : "06632c44-dcca-4f7f-825c-0011c ", "ts" : " ", "info" : "The alarm has been assisted" } Remove Alarm Tracking Table 46: Health Monitor RESTful Interface Remove Alarm Tracking Remove Alarm Tracking Remove the specified alarm tracking Request Request URL DELETE Resource Parameters ticket Required String alarmtrackingid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Alarm tracking ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found 109 / 305

110 Find Data Table 47: Health Monitor RESTful Interface Find Data Find Data Find historical data captured from sensors Request Request URL GET Resource Parameters ticket Required String sensorid Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: 06632c44-dcca-4f7f-825c-0011c Criteria for the query Example: ">40" Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object DataPackage JSON Attributes data Required Array of DataPackage objects ts Required Long data Required Bytes array The retrieved data Example: see DataPackage JSON Attributes Data timestamp Example: The actual data Example: "1000" 110 / 305

111 Listing 42: Health Monitor - Example JSON Response Containing the Find Data Operation Result { } "data" : [ { "ts" : " ", "data" : "1000" } ] Analyze Data Table 48: Health Monitor RESTful Interface Analyze Data Analyze Data Analyze the specified data, obtaining some output Request Request URL GET Resource Parameters ticket Required String sensorid Required String analysistype Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: 06632c44-dcca-4f7f-825c-0011c The requested analysis type Example: ECG Criteria for the query Example: ">40" Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object data The retrieved data 111 / 305

112 DataPackage JSON Attributes Required Array of DataPackage objects ts Required Long data Required Bytes array Example: see DataPackage JSON Attributes Data timestamp Example: The actual data Example: "1000" { } Listing 43: Health Monitor - Example JSON Response Containing the Analyze Data Operation Result "data" : [ { "ts" : " ", "data" : "1000" } ] Remove Data Table 49: Health Monitor RESTful Interface Remove Data Remove Data Remove the specified data Request Request URL DELETE Resource Parameters ticket Required String sensorid Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: 06632c44-dcca-4f7f-825c-0011c Criteria for the query Example: ">40" Response HTTP Status Code Value 200 OK 112 / 305

113 400 Invalid parameters 401 Unauthorized 404 Service not found Find Anomalies Table 50: Health Monitor RESTful Interface Find Anomalies Find Anomalies Find the anomalies triggered by the specified anomaly configuration Request Request URL GET Resource Parameters ticket Required String sensorid Required String anomalyconfigid Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Sensor ID Example: "06632c44-dcca-4f7f-825c-0011c " The anomaly configuration that triggered the requested anomalies Example: 06632c44-dcca-4f7f-825c-0011c Criteria for the query Example: ">100" Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found JSON Object anomalies Required JSON Object Array of Anomaly objects of The retrieved anomalies Example: see anomaly JSON Attributes 113 / 305

114 anomaly JSON Attributes id Required String ts Required Long info Required String Anomaly ID Example: 06632c44-dcca-4f7f-825c-0011c Anomaly timestamp Example: Anomaly specific information Example: The heart rate is too high { } Listing 44: Health Monitor - Example JSON Response Containing the Analyze Data Operation Result "anomalies" : [ { "id" : "06632c44-dcca-4f7f-825c-0011c ", "ts" : " ", "info" : "The heart rate is too high" } ] Remove Anomaly Table 51: Health Monitor RESTful Interface Remove Anomaly Remove Anomaly Remove the specified anomaly Request Request URL DELETE Resource Parameters ticket Required String anomalyid Required String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Anomaly ID Example: 06632c44-dcca-4f7f-825c-0011c Response HTTP Status Code Value 200 OK 400 Invalid parameters 114 / 305

115 401 Unauthorized 404 Service not found Remove Anomalies Table 52: Health Monitor RESTful Interface Remove Anomalies Remove Anomalies Remove the specified anomalies Request Request URL DELETE Resource Parameters ticket Required String anomalyconfigurationid Required String criteria Optional String String encoded ticket that contains the issuer identity Example: "06632c44dcca4f7f825c0011c " Anomaly configuration ID Example: 06632c44-dcca-4f7f-825c-0011c Criteria for the query Example: ">40" Response HTTP Status Code Value 200 OK 400 Invalid parameters 401 Unauthorized 404 Service not found Consumed Services In this section the consumed services of the ALFRED system are listed; grouped by the different subcomponents of the Health Monitor. 115 / 305

116 The Sensor Abstraction Framework (SAF) SAF does not consume any services The Health Monitor Client (HMC) The Health Monitor Client consumes services from the following components: The Personalization Manager: to obtain personal information of the user, mainly its name, age, etc. o Retrieve User Profile (see sections ) The Health Monitor Server (HMS) The Health Monitor Server requires services from the following components: The Personalization Manager: to obtain personal information of the user, mainly its name, age, etc. o Retrieve User Profile (see sections ) The KIS: All operations for manipulating data, and for assigning permissions (to carers) o Create Bucket (see sections ) o Delete Bucket (see sections ) o Add Access Right to Bucket (see sections ) o Add Access Rights for User (see section ) o Remove Access Right for Bucket (see section ) o Get Access Right for Bucket (see section ) o Get Access Rights for User (see section ) o CRUD - Operation Create (see sections ) o CRUD - Operation Read (see sections ) o CRUD - Operation Update (see sections ) o CRUD - Operation Delete (see sections ) o Execute Generic Query / Execute Query on Bucket (see sections ) Summary In this section the technical specification of the Health Monitor component has been presented. First, different technologies for connecting external sensors have been analysed and compared. Then, the different subcomponents of the Health Monitor have been introduced and their internal structure has been described. Finally, the interfaces of all subcomponents have been listed, as well as its dependencies with the other components of the system. 4.5 Context-aware Dialogue Engine The Context-Aware Dialogue Engine (CADE) is responsible for the spoken interaction between ALFRED and the end user. It allows the user to give spoken queries and commands, interprets the utterances and provides verbal feedback and responses. It also identifies ALFRED apps corresponding to the user s intention. CADE interfaces with other ALFRED components in order to fetch app resources, request information and trigger activities. 116 / 305

117 4.5.1 Major Design Decisions This section discusses two important design decisions regarding CADE. First, two distinct categories of speech recognizers are presented; namely open and grammar based. Second, the decision to use an embedded or cloud based architecture for dialogue management is discussed Open or Grammar Based Speech Recognizer The Automatic Speech Recognizer (ASR) depends on a language model which contains the scope of spoken utterances that the ASR is able to recognize. The language model can be either statistical or grammatical. Typically, statistical models are used for open, unrestricted domains, such as for dictation of arbitrary text. In contrast, grammar based models are used for smaller and well-defined domains, such as menu based applications. Both options have benefits and drawbacks. The most obvious benefit of an open language model is its greater linguistic coverage, i.e. its ability to recognise any kind of utterance. On the other hand, greater coverage usually implies weaker accuracy. Conversely, a grammar based language model may provide higher accuracy at the expense of smaller coverage. In ALFRED, two types of user requirements favour an open language model: referring to contacts or geographical entities such as streets by their name, and dictation of text messages. Both requirements are difficult to satisfy with a grammar based model. For this reason, an open language model will be the main choice in ALFRED. The potential drawback of this choice a weaker accuracy can be addressed in various ways. The most obvious strategy is to attend to all of the recognition hypotheses returned by the speech recognizer, rather than only the top ranked hypothesis. In this way, dialogue context and knowledge about the end user can provide additional clues, guiding the dialogue manager towards the best possible interpretation of what the user has said. Such kind of context-aware interpretation will be employed in the ALFRED project Embedded or Cloud Based Dialogue Management The dialogue manager is responsible for making sense of recognized utterances, selecting appropriate answers and follow-up questions, and keeping track of dialogue context, among other things. All of these capabilities may run either embedded on the end user s device, or on a server in the cloud. Both options have benefits and disadvantages. The main advantage of an embedded approach is that it doesn t require a network connection. On the other hand, a cloud based solution relieves computational load from the device, and is usually easier to implement due to less restricted system APIs. Given that a network connection will most likely be required regardless of this particular choice, a cloud based dialogue manager is the best choice for ALFRED Technology Comparison In D2.4 (Architecture Definition and Function Specification), the CADE subcomponents were defined: Backend: containing the dialogue management (dialogue move engine, naturallanguage interpreter, etc.) 117 / 305

118 Frontend: mainly consisting of an automatic speech recognizer and a text-tospeech synthesizer. Session Manager: governing the connection and communication between frontends and backends. The subsequent subsections discuss technical options for these subcomponents Dialogue Management Talkamatic Dialogue Manager (TDM) is a commercial platform for building spoken dialogue systems. It is one of the technologically leading dialogue managers on the market today, with built-in support for rapid development, multimodal interaction, grounding (making sure that all participants in a dialogue agree on what has been said and what it meant), topic-shifts (the ability to keep track of multiple topics), and accommodation (support for integration of relevant, but not requested, user utterances). It also supports context-aware interpretation which can be used to boost speech-recognition accuracy. Additionally, Talkamatic s involvement in the ALFRED project enables the project to get free access to their commercial product, as well as full support. For these reasons, TDM will be chosen as the ALFRED dialogue manager, and no further technology comparison will be required Session Management Session management is built into TDM. Therefore, no further technology comparison or is required for this subcomponent Automatic Speech Recogniser (ASR) The market for Automatic Speech Recognition (ASR) on mobile devices is dominated by two large players: Google and Nuance. Nuance provides different products for different needs: Vocon (for recognition locally on embedded devices), NDEV (for cloud-based unrestricted recognition) and Vocon Hybrid (combining Vocon with NDEV). Google offer their cloud based and unrestricted recognition on the Android platform. In addition to the two dominants, there is also PocketSphinx, an open source option which offers unrestricted as well as grammar based recognition. 118 / 305

119 Table 53: CADE - Criteria for Technical Specification of Automatic Speech Recognizer Parameter Importance Language Support +++ The speech recognizer should support German, French and Dutch (the languages spoken by the participants in the planned pilots) as well as English (enabling validation by all project members). Realtime/Speed ++ Performing speech recognition in real time with a minimum of delays is important for achieving a responsive system and creating a positive user experience. Large Coverage ++ The product should be able to handle large language models without compromising speed and quality. Cost ++ From an economic point of view, the costs for using the technologies should be included in the selection decision. Quality +++ The accuracy of the ASR is essential, especially when dealing with older users. Misrecognitions have a large negative impact on the usability of a speech based system. Platform Availability +++ The availability of the technology on Android. N-best Results ++ Some ASRs return not only their best guess about what the user has said, but also hypotheses with lower confidence values. Such a list of hypotheses is called an n-best list. Combined with dialogue context and knowledge about the user, n-best results can boost the system s ability to make sense of what it has heard. Partial Results + Most ASRs only return a result once the end of an utterance has been detected. However, some ASRs also support partial results on a word-by-word basis. This can be used to give incremental feedback while the user is speaking. The criteria for technical specification of the ASR are outlined in Table 53. Below follows a more detailed list of the possible ASR options. Nuance Vocon 10 recogniser is fast and runs directly on the device. It can cope with relatively large grammars with reasonable speed, and can handle several hundred thousand utterances. The Software Development Kit (SDK) costs per language. It also requires a small runtime licence fee for every unit. Nuance NDEV 11 is a cloud based recogniser from Nuance. It has a general language model, but there are also specialised language models for specific domains such as music and TV. It offers different service levels, including a free option allowing 5000 transactions per day. Since the recogniser is cloud based, a / 305

120 good network connection is required when using speech input. Latency can also be higher than for an embedded recogniser. Nuance Vocon Hybrid 12 provides a combination of Vocon and NDEV. An embedded recogniser (Vocon) runs on the device, providing fast recognition for a smaller grammar, while the software is also connected to a cloud based recogniser, providing slower, network dependent, but wider-coverage recognitions. The ASR from Google 13 is free to use within the Android platform. It is an open recogniser, and Google currently provides two different language models: web search and free form. The web-search language model is adapted for search queries (isolated words, keywords, no complete sentences), while the free-form model supports a wider range of utterances. Like NDEV, Google ASR suffers from the limitations of cloud based recognisers (network requirement and latency). PocketSphinx 14 is an open source recogniser available under GPL and supports open dictation recognition as well as grammar based recognition. Its main disadvantage is its slow performance. A comparison of the ASR options is summarized in Table 54. Table 54: CADE - Comparison of Technologies for Automatic Speech Recognizer Parameter Importance Vocon NDEV Vocon Hybrid Generic Criteria Google Pocket- Sphinx Up-to-Datedness Stability Extensibility & Open Source / Standards Familiarity Performance See Specific Criteria for a breakdown Interoperability License - Proprietary Proprietary Proprietary Proprietary GPL Specific Criteria Language Support Realtime/speed / 305

121 Large Coverage Cost Quality Platform Availability N-best Results Partial Results Text-To-Speech Synthesizer (TTS) As for automatic speech recognizers, the market for text-to-speech (TTS) engines for mobile use is dominated by Nuance and Google. Another similarity is the availability of both embedded and cloud based solutions. In contrast to ASRs, the issue of coverage has no significance, as all TTS products have full coverage within the respective languages. The criteria for technical specification of the TTS are outlined intable 55. Table 55: CADE - Criteria for Technical Specification of Text-To-Speech Synthesizer Parameter Importance Language Support +++ The TTS should support German, French and Dutch (the languages spoken by the participants in the planned pilots) as well as English (enabling validation by all project members). Realtime/Speed ++ Performing speech synthesis in real time with a minimum of delays is important for achieving a responsive system and creating a positive user experience. Cost ++ From an economic point of view, the costs for using the technologies should be included in the selection decision. Quality +++ The quality of the TTS is essential, especially when dealing with older users. Platform Availability +++ The availability of the technology on Android Below follows a more detailed list of the possible TTS options. Nuance NDEV: The TTS feature of NDEV from Nuance has similar characteristics and pricing options as the ASR feature described in section Only the best hypothesis is rated. All other hypotheses have undefined (zero valued) scores, at least in TALK s experience (which is shared by other developers). Nevertheless, the ranking of the hypotheses is still useful for context-aware interpretation. 121 / 305

122 Google: The TTS engine from Google is free to use within the Android platform. 16 Both embedded and networked voices are supported. Acapela: Acapela 17 is a commercial TTS which can be downloaded and installed as a voice on the Android device. Once a voice has been installed, it can be selected for use with the built-in Android API and therefore uses the same technical solution as the Google TTS. The price is currently 3.99 per language and device. Acapela VAAS: Acapela also offer Voice as a Service (VAAS) 18, a commercial cloud based solution. In contrast to the device-installable voices, VAAS does not support the built-in Android API. Instead, transactions are managed over HTTP. espeak: espeak 19 is a free and open source TTS which has been ported to Android. It is still in an early development phase. The built-in Android API is used when accessing the espeak voices. A comparison of the TTS options is summarized in Table 56. Table 56: CADE - Comparison of Technologies for Automatic Speech Recognizer Parameter Importance NDEV Acapela Google Acapela VAAS espeak Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards Familiarity Performance See Specific Criteria for a breakdown Interoperability License - Proprietary Proprietary Proprietary Proprietary GPL Specific Criteria Language Support Realtime/speed Cost / 305

123 Quality Platform Availability Technology Selection Dialogue Management Talkamatic Dialogue Manager (TDM) is selected for dialogue management. It has many powerful and highly competitive dialogue features which are relevant for the requirements in the ALFRED project, and can be used free of charge and with full support from TALK Session Management Session management is provided by TDM and hence requires no further technology selection Automatic Speech Recognition The ASR from Google will be the main option. It is freely available on the Android platform using the built-in API, and has good accuracy. Potential issues with misrecognitions will primarily be addressed with context-aware interpretation. If this does proves insufficient, other ASRs such as Vocon or NDEV may be evaluated Text-To-Speech Synthesis As for speech recognition, the TTS from Google will be the main option due to its free availability on the Android platform. Additionally, the same technical solution can be used to evaluate the potential quality gain of commercial solutions such as Acapela Component Structure CADE consists of design-time and runtime subcomponents. The design-time subcomponents are used during development of 3rd party apps, while the runtime subcomponents are used when the user interacts with ALFRED Design-Time Subcomponents The design-time subcomponents in CADE is an SDK (software development kit) consisting of tools and resources for developing so called Dialogue Domain s. Dialogue domains consist of an ontology, plans and language models of a particular dialogue domain. The ontology defines concepts, entities and actions that the user and the system may reference in questions, answers and requests. The dialogue plans describe how actions are carried out and how questions are answered. Plans also describe what information is needed in order to carry out the actions or answer the questions. The language model or grammar defines mappings between linguistic surface forms and semantic entities. 123 / 305

124 In ALFRED, there will be a Core Domain, describing the dialogue domain for the core functionality of the assistant, as well as app-specific domain descriptions. The Core Domain will be relatively small, as most functionality in the assistant will be provided by the apps. The app-specific domain descriptions will be stored in the ALFREDO Marketplace and will be defined by app developers in an XML format. The exact format of this schema will be developed in T4.1 Question-Answer Modelling. In concrete terms, the design-time part of CADE is an SDK with the following subcomponents: Dialogue Domain Editor: A tool for editing ontologies, plans and language models, allowing the developer to save properly formatted XML files. Dialogue Domain Resources: A set of resources that can be imported or used when creating dialogue domains, e.g. domain-independent linguistic constructions that can be shared across several domains. Dialogue Domain Compiler: A tool for compiling dialogue domains from XML to a runtime format that can be accessed by the runtime subcomponents. The compiler also provides adequate warnings and/or error messages when motivated. Runtime Subcomponents The runtime subcomponents of CADE are used when the user interacts with ALFRED and consists of the following groups of subcomponents: Frontend: mainly consisting of an automatic speech recognizer and a text-tospeech synthesizer. It also provides the facades to other ALFRED components. Backend: consisting of dialogue move engine, natural-language interpreter, etc. Session Manager: providing each frontend with access to a backend, and routing communication between frontend and backend. The subcomponents are distributed across the device and a server, as visualized by Figure 14. For the communication between client side and server side subcomponents, a bidirectional WebSocket connection is used. Other ALFRED components only interact with the CADE frontend, running on the device. For this reason, the message protocol between CADE client and server is considered internal and is not covered by this technical specification. The subsequent subsections describe the CADE subcomponents in more detail. 124 / 305

125 Information State Backend Dialogue Domain Manager Dialogue Domain Dialogue Manager Core GUI Generation GUI Interpretation Turn Manager Dialogue Move Engine Generation Interpretation Session Manager Session Management Frontend Server Side Client Side User Interface Layer Text To Speech Synthesizer Automatic Speech Recogniser Figure 14: CADE - Component Structure Frontend The CADE Frontend provides the user interface layer of the spoken dialogue support in ALFRED. It also acts as the facade between CADE and other components. The frontend runs locally on the ALFRED device and consists of the following parts: Automatic Speech Recognizer (ASR) Text-To-Speech Synthesizer (TTS) The ASR listens to the microphone and returns a textual hypothesis of what the user has said, along with confidence values. Inversely, the TTS receives text to be spoken and outputs it via the mobile device s speakers. Within the ALFRED project, neither ASR nor TTS engines will be developed. Instead, already existing speech engines will be adopted and wrapped within the frontend subcomponents. As discussed in sections and , the built-in ASR and TTS in the Android API will be used Backend 125 / 305

126 The CADE Backend contains the main logic governing spoken dialogue interaction between ALFRED and the user. It runs on a server, and consists of the following parts: Information State: Contains dialogue related information such as dialogue history, issues currently under discussion, and beliefs shared by the user and the system. Interpretation: Produces semantic interpretations of the user utterances recognised by the ASR. Dialogue Move Engine (DME): Uses dialogue plans defined in Dialogue Domain s (see below) in order to identify the user s intention and find corresponding apps. The DME may select follow-up questions and request information from other ALFRED components. It may also request to start or stop activities in other ALFRED components. Generation: Produces textual realizations in natural language from semantic representations of dialogue moves that the DME has selected. Turn Manager: Distributes the turn (the right and opportunity to speak) between the user and the system. Dialogue Domain s: Describes the ontology, the plans and the grammar of a particular dialogue domain. See section Dialogue Domain Manager: Contains domain descriptions for enabled ALFRED apps. GUI Interpretation: Produces semantic representations of input received from the GUI. GUI Generation: Produces graphical descriptions from semantic representations of dialogue moves that the DME has selected. In ALFRED, this may be used for generating clarification buttons when the system is uncertain what the user said Session Manager The CADE frontend and backend communicate via the Session Manager, running on a server. When a new frontend connects to the Session Manager, it first ensures that there is an available backend that can serve it. It then associates them to each other and routes subsequent messages in both directions Interfaces This section describes the public methods of CADE. The number of methods in the interface is quite small. The main reason for this is that the spoken communication between the user and CADE is handled within the component itself. Other components invoke methods in CADE only for the following reasons: to notify that a new app has been installed, to notify about haptic input (e.g. when the push-to-talk button is pressed), and to notify that an activity started or ended. The methods are described in more detail below. All interfaces in CADE are implemented as Java methods in the frontend, which runs on the device Enabled App This method is invoked when a new ALFRED app has been installed. It will cause the CADE backend to load the app resources from the Marketplace, enabling it to manage spoken interactions in relation to the app. 126 / 305

127 Parameters: appid: A unique identifier of the added app. The identifier provides a reference to the location of the app binary, which among other things contains the app s dialogue domain description. Return Value: The method has no return value. In the case of an error, an exception is raised. Error Handling: If an error is encountered, e.g., the same app id is enabled a second time, the method throws an exception describing the nature of the error. Remarks: Note that the caller of the method is not responsible for providing any information about the app. Instead, CADE retrieves information about the app from the Marketplace, using the app identifier. Listing 45: CADE Java Interface Enabled App /** appid, a unique identifier of the enabled app CadeException */ public void enabledapp(string appid) throws CadeException; PTT Activated This method is invoked when the push-to-talk (PTT) icon in the GUI is clicked. The notification will then be forwarded to the ASR so that the system starts listening to the microphone. Parameters: None Return Value: The method has no return value. In the case of an error, an exception is raised. Error Handling: If an error is encountered, e.g., the system is already in a listening state, the method throws an exception describing the nature of the error. Remarks: None /** CadeException */ Listing 46: CADE Java Interface PTT Activated public void pttactivated() throws CadeException; 127 / 305

128 Option Selected In the case that the GUI is used to clarify what the user has said, this service is invoked when a choice is clicked. This notification will then be forwarded to the backend, allowing the dialogue manager to update its state and respond appropriately. Parameters: option: A string containing the semantic value of the selected option. Return Value: The method has no return value. In the case of an error, an exception is raised. Error Handling: If an error is encountered, e.g. in the case of an unexpected value, the method throws an exception describing the nature of the error. Remarks: The semantic values of graphically presented options originate from CADE. They are passed on in the parameters of the method call from CADE which causes the options to be displayed on the screen Started Activity Whenever some component decides to initiate an activity that should be handled verbally by ALFRED, it needs to notify CADE about this. For example, when the Suggestion Manager decides to suggest an event, it notifies CADE using this method. This allows CADE to find a matching dialogue plan for the activity and thereby to ask the user a question or notify him or her about some information in relation to the activity. Parameters: appid: A unique identifier of the app which handles the activity. This may be the core ALFRED app, or an extension. activity: A string matching the definition in the dialogue domain description. parameters: The parameters dictionary may contain action-specific fields such as the name of a contact or event. Return Value: The method has no return value. In the case of an error, an exception is raised. Error Handling: If an error is encountered, e.g., the parameters were invalid in relation to the specified activity, the method throws an exception describing the nature of the error. Remarks: In the source example below, the Suggestion Manager first notifies CADE about a suggested game to play. The activity SuggestGame is built into the core dialogue domain description. That the activity is started in this case refers only to the suggestion, and not to the actual game. Only if the user accepts the suggestion, a new Game activity will be started, as illustrated by the second method call in the example below. 128 / 305

129 Listing 47: CADE Java Interface Started Activity /** appid, a unique identifier of the app activity, an identifier of the activity that was started parameters, a dictionary of action-related parameters */ public void notifystarted(string appid, String activity, Map parameters) // Notify CADE about a game suggestion Map parameters = new HashMap<String,String>() { { put( type, physical ); put( name, Aerobics ); }}; api.notifystarted(api.core_app, SuggestGame, parameters); // Notify CADE that a game has started (e.g. following the user s approval) Map parameters = new HashMap<String,String>() { { put( type, physical ); put( name, Aerobics ); }}; api.notifystarted(api.core_app, Game, parameters); 129 / 305

130 Stopped Activity When activities are completed or aborted, CADE needs to be informed about the completion. This allows CADE to give verbal feedback to the user about what has happened and to update its dialogue state accordingly. For example, if an event has been scheduled, the Suggestion Manager notifies CADE that the activity ended. Following such a notification, CADE verbally informs the user about the scheduling. Parameters: appid: A unique identifier of the app. activity: An identifier of the activity that was started. parameters: The parameters dictionary may contain activity-specific fields such as the name of a contact or event. Return Value: The method has no return value. In the case of an error, an exception is raised. Error Handling: If an error is encountered, e.g., the parameters were invalid in relation to the specified activity, the method throws an exception describing the nature of the error. Remarks: None Listing 48: CADE Java Interface Stopped Activity /** appid, a unique identifier of the app activity, an identifier of the activity that was started parameters, a dictionary of activity-related parameters */ public void stoppedactivity(string appid, String activity, Map parameters) Consumed Services Marketplace o Get App (expects result to contain dialogue domain description in some form, see section ) Personal Assistant o Display Options: Cause GUI to display a list of options, each associated with a label (visible to user) and a semantic value (hidden from user). o Clear Screen: Cause GUI to remove the list of options, and just show the default PTT icon. o Start App/Game Activity: This is invoked when the user initiates some activity provided by a 3rd party app. E.g. if the user says call Otto and a phone app has associated such phrases with a phone-calling activity, then CADE will ask PA to invoke that activity with Otto as a parameter. 130 / 305

131 The same service will be used when starting games. This may be caused by a direct request from the user ( I want to play chess ), or by accepting a suggestion ( Do you want to play chess?, yes please ). o Perform App/Game Query: This is invoked when the user initiated some activity provided by a 3rd party app or game, and CADE needs more information before it can invoke the activity. E.g. if the user says I want to make a phone call, and a phone app has associated such phrases with a phone-calling activity that depends on a contact to call, then CADE will query PA for a list of possible contacts to call (as specified by the app developer in the dialogue domain description). CADE expects PA to forward the query to the specified app, and expects a list of results to be returned. o Validate Parameters: For some activities invoked by the user, certain parameter values may not be valid. For example, if the user says call Otto at home and no home number is registered for Otto, the call cannot be initiated and verbal feedback should be given to the user. To this end, CADE needs to able to query an app whether some given parameter values or valid for a certain activity. PA is expected to route the query to the specified app. Returns true or false. o Recognize Entity: When the ASR hears words that the natural-language interpreter doesn t understand, CADE may ask for help from apps or games to resolve the meaning of these words. For example, if the user says navigate to Oxford Street, the sub-phrase Oxford Street is initially unknown to CADE (although recognized by the ASR). An installed navigation app, however, can look up the street name using the service that it relies on (e.g. Google Maps). CADE passes the unknown sub-phrase and expects a list of results to be returned, each containing a semantic sort (e.g. street or city). PA is expected to route the query to all installed apps and collect the results before returning them to CADE. Personalization Manager o Get/set user model: Retrieve and update binary (or JSON) values representing user habits. This can be used by CADE to improve ASR accuracy. Perhaps this can be done directly with KIS, but it is important that the information is user-specific. See sections and o Get contacts by name: pass name, expect result to be a list containing all contacts with that name. The results should either contain information about each contact s relation to the user, e.g. the user s sister or caretaker, or IDs through which such information can be fetched using some other method. See section o Get contacts by relation: pass relation (e.g. sister ), expect result to contain all matching contacts. See section o Get language (or get (part of) user profile): expect result to contain identifier of the language selected by the end user, e.g. represented using ISO See section Summary This section has technically specified the Context-Aware Dialogue Engine (CADE), responsible for the spoken interaction between the user and ALFRED. Talkamatic 131 / 305

132 Dialogue Manager (TDM) was selected as the dialogue engine, and standard Android speech components were selected for speech recognition and synthesis. Furthermore, the component structure was presented, consisting of a frontend running on the device and a session manager and backend running on a server. Finally, the interaction with other ALFRED components was specified. 4.6 ALFREDO Marketplace ALFREDO Marketplace is the main resource for end users that want to increase their mobile experience with new functionalities and features. This new functionalities are called apps and are accessible through mobile application in every end user ALFRED device. In the next sections concepts of user role will be introduced. For each role, a short description and the definition of its responsibilities will be described in the following list: Developer: Developers creates apps for the ALFRED system. They will be also responsible of the publication of their own apps in the Marketplace. Tester: Testers are responsible for accepting or rejecting newly uploaded apps. Once a new app is uploaded by the developer, it needs to be reviewed by a person in this role, then if the extension is accepted, it is listed and available via Marketplace. End user: End users will download, install and uninstall apps on their ALFRED enabled devices through ALFREDO Marketplace. They will also be able to rate an app based on their own experience. The ALFREDO Marketplace is offered in two forms that will be accessible depending on the user role. For developers and testers, Marketplace will be accessible via web and mobile application whereas for end users; only mobile application will be available Major Design Decisions During the discussion of the Architecture definition and Functional description (deliverable D2.4), the following major design decisions have been made: Ease of use: ALFREDO App Marketplace should be easy to user because end users are not supposed to be technology experts and as older person, most of them would be physically limited. This implies an easy-to-use GUI for mobile application. The ALFREDO Web Marketplace is not restricted to a simple UI since it is used by developers that have a technical background. Availability: Since the ALFREDO App Marketplace will be the most frequently used app and the web vies of the ALFREDO Web Marketplace will be highly visited web platform, all components used by these marketplaces need to be highly available for every frontend described in this section. This includes error-proneness in case of a non-permanent internet connection on the ALFREDO device Technology Comparison Comparison Criteria The subsequent table (see Table 57) depicts the followed criteria to compare the different technologies available in the market which fulfil all the previous design decisions: 132 / 305

133 Table 57: ALFREDO - Criteria for Technical Specification Parameter Importance Distributed Architecture + Since ALFRED will have to handle a large number of end user requests, it will be necessary to have pure parallelism during treating request processes. Besides parallelism the ALFREDO and App Marketplaces need a highly concurrent and scalable backend system to serve data as fast and reliable as possible. Adaptable UI ++ The ALFREDO Web Marketplace is used by developers that need a different level of information than end users that make use of the ALFREDO App Marketplace. Therefore, the ALFREDO App Marketplace needs to be much more general and user friendly, especially for old person end users. Connectivity for Backend Data ++ In order to offer the end users the newest apps the ALFREDO App Marketplace should serve stable and fast connections to the storage backend. Licensing Support + For a fluently implementation the used technologies should be unlicensed, so the developers will not have any constraints during programming Possible Technologies and Comparison ALFREDO App Marketplace The ALFREDO App Marketplace will be based on a solution that fulfils the necessary functionalities and views needed to provide end users with an easy to use solution. The ALFREDO App Marketplace makes use of its own approach for storing information about applications; hence there is no need for the solution to provide its own database access and scheme. The data will be received via the Knowledge and Information Storage (KIS) component. In the following sections, the five most representative technologies available in the market will be presented. Following this list, a table comparing and scoring every important parameter will be exposed to the reader in order to justify which technology will be selected. The five most representative technologies available in the market are: Google play 20 is the most widely known store for Android apps, as it is the store operated by Google, which owns the major share of Android OS variations in the market. It meets nearly all the listed criteria except the open source ability. Unfortunately it is licensed with a non-free license, which renders it not suitable for ALFRED. Amazon App Store 21 is the second largest Android app repository. It offers a much smaller selection of apps than Google Play but assures a minimum of quality because every app has passed the quality tests from Amazon. App Store is limited to the U.S. and a smattering of European nations (UK, France, Germany, Italy and / 305

134 Spain) which make it not suitable for the ALFREDO App Marketplace of the ALFRED project. GetJar 22 is a freeware app for Android that enables users to download over 150,000 apps for several mobile systems for free. It requires Android OS 2.1 or higher. GetJar makes use of a custom, non-free, license and is therefore not suitable for the ALFREDO App Marketplace of the ALFRED project. The F-Droid 23 repository includes more than 1000 open source apps for free download. These apps are sorted in categories as well as in subcategories to simplify the user search. F-Droid makes use of the GPLv3 License and requires all of the apps in the store to be released under this license as well and is therefore not suitable for the ALFREDO App Marketplace component of ALFRED. MyMarket is a marketplace platform written in Java. It is highly customizable due to access to the source code. ALFRED project partners have a lot of experience with this marketplace solution, which makes it the best fitting solution for the ALFREDO App Marketplace component. Table 58: ALFREDO - Comparison of Technologies for the ALFREDO App Marketplace Parameter Importance Google Play Amazon App Store GetJar F-Droid MyMarket Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards +/ Familiarity Performance Interoperability License GPL v3 Custom License Custom License Custom License Custom License Specific Criteria Distributed Architecture Adaptable UI Connectivity for backend data / 305

135 Licensing support Possible Technologies and Comparison ALFREDO Web Marketplace The number of possible basic technologies for the ALFREDO Web Marketplace is quite limited. The limited number of possible existing solutions which, despite their provision of features listed in the requirements, are considered for the ALFREDO Web Marketplace is even reduced due to their limitation to physical items. The ALFREDO Web Marketplace needs to provide several views to create, update and delete applications to developers as well as functionality to browse and search for new ready-to-review applications to testers. Therefore the ALFREDO Web Marketplace will be handled by a web application, so developers and testers that might not make use of the platform chosen for ALFRED can still publish or review extensions. The PHPB2B 24 marketplace script is a full featured marketplace for bidding purposes. It is based on PHP and uses MySQL as storage. It also makes use of the Model View Controller (MVC) design pattern that allows users and developers (in this case the ALFRED project) to customize it in any possible way. Since PHPB2B is a marketplace for physical items the only way to make use of it is to modify the existing code, which means to read and understand the existing codebase as well as changing almost everything. The B2B Marketplace Script 25 is a modern looking yet customizable B2B script written by a company named Eicra. It provides all features needed to create a B2B portal without any programming knowledge. The B2B Marketplace script is targeted at physical items and therefore not suitable for the ALFREDO Web Marketplace. MyMarket Web App is a backend web application a written in Java. It is highly customizable due to access to the source code. ALFRED project partners have a lot of experience with this marketplace solution, which makes it the best fitting solution for the ALFREDO Web Marketplace component Table 59: ALFREDO - Comparison of Technologies for the ALFREDO Web Marketplace Parameter Importance PHPB2B B2B Marketplace Script MyMarket Web App Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards +/ / 305

136 Familiarity Performance Interoperability Specific Criteria Distributed Architecture Adaptable UI Licensing support + GPL v3 Custom License Custom License Technology Selection Technology Selection for ALFREDO App Marketplace As seen in the comparison of existing application marketplaces, the MyMarket solution fulfils most of the requirements needed by the ALFREDO App Marketplace, and is therefore chosen for development. The MyMarket solution is used as a basis for the App Marketplace. The current MyMarket version will be used as it is currently implemented in the cases that it works within the ALFRED project, including interfaces between the different components. But further implementation is needed to meet the needs of ALFRED. The most important extension needs are the following: Modification of the app upload-process in order to include the required parameters to be used in ALFRED. Simplification of the review process. Modification of the app search process in order to include the required search options. Improve the management of the installed apps in the client-side application of the marketplace, as the current implementation only provides a basic mechanism. Integration of the client-side of the marketplace within ALFRED application. Integration of the server-side of the marketplace with the other server-side components of ALFRED. Add support for the newest versions of Android. Change the look & feel for a new more up-to-date design. Removal of ios support. Technology Selection for ALFREDO Web Marketplace The MyMarket Web App solution is the technology selected because it satisfies all the needs of ALFREDO Web Marketplace. It s written in Java, which guarantees the 136 / 305

137 Client sid ALFRED WP2 Public Technical Specification compatibility with the other components which will share the Web Portal. In addition, it s a well-known solution for one of the partners. The integration within ALFRED system will not include much implementation needs since the data storage is handled via the KIS component and the communication with other ALFRED components will be native through Java-based interfaces as described in section Component Structure This component contains two separate marketplaces that are splitted by their target users. The ALFREDO App Marketplace is used by end users and only contains apps to be used within ALFRED device. These apps will extend the features and possibilities of ALFRED and enhance the Quality of Experience (QoE) for end users. The ALFREDO Web Marketplace is used by developers that want to publish their own extensions or by testers that want to review the new ready-to-review extensions. The next figure (see Figure 15) depicts the basic component structure: Tester UI Tester App Manager Developer UI Developer Server sid ALFREDO App Marketplace UI Local App Manager End user Figure 15: ALFREDO - Marketplace Subcomponents The ALFREDO App Marketplace UI is the main app to find and install new ALFRED extensions on the ALFRED devices. This app allows end users to browse 137 / 305

138 apps published in the marketplace and install them on their ALFRED devices. It provides a search functionality that permits to search for apps matching specific filter parameters, and to read the app description. Moreover, end users are able to provide feedback concerning the app (named rating an application), to help other users to decide about the quality of apps they may want to install. The Tester UI is a web GUI for the testers of ALFRED that will permit to review and validate the apps uploaded by developers prior to its publication in the ALFREDO App Marketplaces. The Tester UI will show the list of pending apps to be reviewed. The tester is able to use and test the apps, accept or reject them, and provide a written feedback to the developers. This feedback is then sent to the developer via . Once an app is approved be a tester, it is published in the ALFREDO App Marketplace in order to be used by other developers or end users, respectively. The Developer UI subcomponent is a web GUI aimed at developers that permits to manage the publication of apps in the ALFREDO App Marketplace. It permits to upload new apps, update their descriptions, visualize usage information, and remove them from the marketplace. The Developer UI offer as a main functionality to the developer: app management. The Developer UI permits to manage the publication of apps in the ALFREDO App Marketplace. In this case, the Developer UI also covers the creation of new apps in ALFRED, by providing a form where the developer can introduce all the information of an app and upload the app bundle. All this information is registered in the KIS component, but the application still needs to be reviewed and accepted in order to be published in the ALFREDO App Marketplace. The Developer UI also permits to upload new version of an app, visualize the information of an app, and remove an app from the Marketplace. The Local App Manager is a subcomponent of the ALFREDO App Marketplace responsible for the management of the apps within the ALFRED device, including the installation and uninstallation of apps. It also takes charge of the communication with ALFREDO Web Marketplace. The Local App Manager receives requests from the ALFREDO App Marketplace UI, like a search request or a request to install an app, and then queries the App Manager component on ALFREDO Web Marketplace to perform the request. The App Manager is the main backend subcomponent of the ALFREDO Web Marketplace, handling the server-side functionality for managing apps and providing access to the information stored in the KIS component. It provides a Java interface for the Developer UI, Tester UI and a REST interface for the Local App Manager subcomponent Interfaces This section describes the interfaces of the ALFREDO Marketplace. The ALFREDO Web Marketplace provides different methods to manage apps. The main subcomponent of the ALFREDO Web Marketplace is the App Manager subcomponent, which is the link between the different web UIs and the subcomponents of ALFRED. It provides different Java interfaces to be used by the Developer and Tester UIs, and a RESTful interface to be used by the Local App Manager subcomponent of the ALFRED device. 138 / 305

139 Java Interfaces of the ALFREDO Marketplace This section describes the Java interface provided by the App Manager subcomponent. This interface is used by the Developer and Tester UIs and other ALFRED subcomponents. The next figure (see Figure 16) represents the class diagram of the app Manager subcomponent. Only externally available interfaces are represented. AppManager + createapp (in userid: String, in app: String): String + deleteapp (in appid: String): Boolean + getapp (in appid: String): Object + publishapp (in appid: String, in versionid: String): Boolean + unpublishapp (in appid: String, in versionid: String): Boolean Figure 16: ALFREDO - Class Diagram of App Manager Subcomponent Create App When the user creates an app using the Developer UI, different parameters of the app have to be specified. Once all these parameters have been specified, different Java methods are executed. The first one permits to create the app in the KIS component. In this Java method, the main parameters of the app are specified, like the user that creates the app and the name of the app. The method returns the identifier of the app created, that will be used in the following Java calls for saving further information of the app. Parameters: userid: Specifies the user identifier of the developer creating the app app: Defines the name of the app to be created Return Value: Returns the ID of the created app. Error Handling: An AppCreationException is thrown in case of error during app creation. Remarks: None Listing 49: ALFREDO Create App /** userid, specifies the user identifier of the developer creating the app app, defines the name of the app to be created appid, app identifier AppCreationException, if an error occurs during app creation */ String createapp(string userid, String app) throws AppCreationException; Delete App This method will delete an app from the ALFREDO Web Marketplace. This method is called by the Developer UI when the developer selects the option to delete an app. 139 / 305

140 Parameters: appid: App identifier Return Value: Returns a Boolean indicating if the app deletion has been successful. Error Handling: An AppDeletionException is thrown in case of error during app deletion. Remarks: None Listing 50: ALFREDO Delete App /** appid, app identifier * appdeleted, app identifier AppDeletionException, if an error occurs during app deletion */ Boolean deleteapp(string appid) throws AppDeletionException; Get App This method will return the information of an app stored in the Marketplace. This method is used by the Developer UI and the Tester UI in order to display the information of an app. Parameters: appid: App identifier Return Value: Returns the app object containing all the information of an app. This app object has all the parameters that contain information of the app, e.g., name of the app, version identifier, etc. The complete list of parameters describing the app is specified in Section 0. Error Handling: An AppSearchException is thrown in case of error during app search. Remarks: None Listing 51: ALFREDO Get App /** appid, app identifier * app, app object AppSearchException, if an error occurs during app search */ App getapp(string appid) throws AppSearchException; Publish App 140 / 305

141 Once an app has been approved within the review process, it is ready for publication in the Marketplace. The developer can then submit the app for publication by clicking the corresponding button in the Developer UI, which calls the method described in this section. Parameters: appid: App identifier versionid: Version identifier of the app Return Value: Returns a Boolean indicating if the publication has been successful. Error Handling: An AppPublicationException is thrown in case of error during app publication. Remarks: None Listing 52: ALFREDO Publish an App /** appid, App identifier * versionid, Version identifier of the app AppPublicationException, if an error occurs during app publication */ Boolean publishapp(string appid, String versionid) throws AppPublicationException; Unpublish App This method permits to unpublish the version of an app already published in the Marketplace. Parameters appid: App identifier versionid: Version identifier of the app Return Value: Returns a Boolean indicating if the unpublication has been successful. Error Handling: An AppUnpublicationException is thrown in case of error during app unpublication. Remarks: None 141 / 305

142 Listing 53: ALFREDO Unpublish Version of an App /** appid, App identifier * versionid, Version identifier of the app AppUnpublicationException, if an error occurs during app unpublication */ Boolean unpublishapp(string appid, String versionid) throws AppUnpublicationException; RESTful Interfaces of the ALFREDO Marketplace This section describes the RESTful interface provided by the App Manager subcomponent. This interface will be used by the Local App Manager subcomponent of the ALFRED device in order to communicate with the server-side subcomponents of the ALFREDO Marketplace. These interfaces are already implemented in the current version of the MyMarket App Marketplace. The modification of these interfaces is not foreseen within the project although in some cases they may not use the best implementation approach, because these interfaces are already working and there is a low priority for this modification. Instead, the resources for the development of the ALFREDO App Marketplace will be dedicated to adapt the MyMarket solution to be used within ALFRED and to add or modify the required functionalities which are described in Section Information of an App The following RESTful method provides detailed information of an app. The method accepts as a parameter the identifier of the app. 142 / 305

143 Table 60: ALFREDO RESTful Interface Information of an App Information of an App Provides information of the last version of a published app Request Request URL GET Resource Parameters appid Required integer Id of the app Example: Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes appid Required integer name Required string version Required string date Required string iconurl Required string rating Required string published Required boolean author The ID of the app Example: The name of the app Example: Tetris The ID of the version of the app Example: 1.1 The date of the publication Example: 15/10/2013 The URL of the icon of the app Example: http: //alfred.eu/appmarketplace/app/ /icon/icon.png The rating of the app Example: 4.2 true if the app is published Example: true The author of the app 143 / 305

144 Required string support Required string Example: Alexey Pajitnov Support of the author Example: The following listing is an example of the JSON call: { } "appid": " Listing 54: ALFREDO - JSON Example: Call App Information The JSON response message will contain the detailed information of an app. { Listing 55: ALFREDO - JSON Example: App Information "appid": " ", "name": "Tetris", "category": "Game", "version ": "1.1", "date": "15/10/2013", "iconurl": "http: //alfred.eu/appmarketplace/app/ /icon/icon.png", "rating": "4.2", "published": true, "author": "Alexey Pajitnov", "support ": "support@pajitnov.com" } Information of an App by Version The following method of the RESTful interface provides the detailed information of a concrete version of an app, accepting as parameters the identifier of the app and the identifier of the version. 144 / 305

145 Table 61: ALFREDO RESTful Interface Information of an App by Version Information of an App by Version Provides information of a specific version of a published app Request Request URL GET Resource Parameters appid Required integer versionnumber Required string Id of the app Example: Version number of the app Example: 1.1 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes appid Required integer name Required string version Required string date Required string iconurl Required string rating Required string published Required boolean The ID of the app Example: The name of the app Example: Tetris The ID of the version of the app Example: v1.1 The date of the publication Example: 15/10/2013 The URL of the icon of the app Example: http: //alfred.eu/appmarketplace/app/ /icon/icon.png The rating of the app Example: 4.2 true if the app is published Example: true 145 / 305

146 author Required string support Required string The author of the app Example: Alexey Pajitnov Support of the author Example: The following listing is an example of the JSON call: { Listing 56: ALFREDO - JSON Example: Call App Information by Version "appid": " ", "versionnumber": "1.1 } The JSON response message will contain the detailed information of an app. { Listing 57: ALFREDO - JSON Example: App Information by Version "appid": " ", "name": "Tetris", "category": "Game", "version ": "1.1", "date": "15/10/2013", "iconurl": "http: //alfred.eu/appmarketplace/app/ /icon/icon.png", "rating": "4.2", "published": true, "author": "Alexey Pajitnov", "support ": "support@pajitnov.com" } Get List of Installed Apps The following RESTful method provides the list of installed apps in the device. This method is used by the device to check the list of installed apps. 146 / 305

147 Table 62: ALFREDO RESTful Interface Get List of Installed Apps Get List of Installed Apps Provides the list of installed apps in the device that performs the request Request Request URL GET URL Parameters sorting Optional string offset Optional integer limit Optional integer Sorting parameter Example: date Start of the pagination Example: 10 Number of elements in response Example: 10 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes appid Required integer name Required string version Required string date Required string iconurl Required string rating Required string The ID of the app Example: The name of the app Example: Tetris The ID of the version of the app Example: v1.1 The date of the publication Example: 15/10/2013 The URL of the icon of the app Example: http: //alfred.eu/appmarketplace/app/ /icon/icon.png The rating of the app Example: / 305

148 published Required boolean author Required string support Required string true if the app is published Example: true The author of the app Example: Alexey Pajitnov Support of the author Example: The following listing is an example of the JSON call: { } Listing 58: ALFREDO - JSON Example: Call List of Installed Apps "sorting": date, "offset": 0, "limit": 10 The JSON response will include a list of apps. Listing 59: ALFREDO JSON Example: List of Installed Apps { "apps": [ { "appid": " ", "name": "Tetris", "category": "Game", "version ": "1.1", "date": "15/10/2013", "iconurl": "http: //alfred.eu/appmarketplace/app/ /icon/icon.png", "rating": "4.2", "published": true, "author": "Alexey Pajitnov", "support ": "support@pajitnov.com" } ] } Update List of Installed Apps The following method permits to update the list of installed apps by the mobile device, in case that the list stored on the server is not correct. 148 / 305

149 Table 63: ALFREDO RESTful Interface Update list of Installed Apps Update list of Installed Apps Updates the list of installed apps Request Request URL PUT Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes apps Required array List of apps Example: [app1, app2, ] The JSON uses the same schema as the one used to get the list of installed apps, which is shown in the response of Table 60. The following listing contains an example of the JSON call. Listing 60: ALFREDO - JSON Example: List of Installed Apps { "apps": [ { "appid": " ", "name": "Tetris", "category": "Game", "version ": "1.1", "date": "15/10/2013", "iconurl": "http: //alfred.eu/appmarketplace/app/ /icon/icon.png", "rating": "4.2", "published": true, "author": "Alexey Pajitnov", "support ": "support@pajitnov.com" } ] } Binary of an App The following method of the RESTful interface returns the binary of a concrete version of an app. As request message, the ID of the app and of the version is needed. 149 / 305

150 Table 64: ALFREDO RESTful Interface Binary of an App Binary of an App Provides the binary of an app Request Request URL GET Resource Parameters appid Required integer versionnumber Required integer Id of the app Example: Version number of the app Example: 1.1 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found The following listing is an example of the JSON call: { "appid": " ", "versionid": "1.1 Listing 61: ALFREDO - JSON Example: Call Binary of an App } The response will be the binary data of the app App Search This section contains a set of RESTful methods that allow searching for apps. They are used in different cases, but follow the same format. In all of them the response will be a JSON structure containing a list of apps. The schema is shown in Table 60. The first method permits a generic search of apps, which accepts different parameters in the query. 150 / 305

151 Table 65: ALFREDO RESTful Interface App Search App Search Provides the list of apps that match the search parameters Request Request URL GET URL Parameters country Optional integer category Optional integer haspromoimage Optional string sorting Optional string offset Optional integer limit Optional integer Country Example: 1 Category Example: 2 Select apps with image Example: yes Sorting Example: date Start of the pagination Example: 0 Number of elements in response Example: 10 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes apps Required array List of apps Example: [app1, app2, ] The following listing is an example of the JSON call: 151 / 305

152 { "country": 1, "category": 2, "haspromoimage": yes, "sorting": date, "offset": 0, "limit": 10 Listing 62: ALFREDO JSON Example: Call App Search } The interface in Table 66 is used for a refined search of apps by category Table 66: ALFREDO RESTful Interface App Search by Category App Search by Category Provides the list of apps of a Category Request Request URL GET URL Parameters category Optional integer sorting Optional string offset Optional integer limit Optional integer Category Example: 2 Sorting Example: date Start of the pagination Example: 0 Number of elements in response Example: 10 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes apps Required array List of apps Example: [app1, app2, ] The following listing is an example of the JSON call: 152 / 305

153 { Listing 63: ALFREDO JSON Example: Call App Search by Category "category": 2, "sorting": date, "offset": 0, "limit": 10 } The interface in Table 67 is used for a refined search of apps by words. Table 67: ALFREDO RESTful Interface App Search by Words App Search by Words Provides the list of apps that contain in their name some of the words of the search Request Request URL GET URL Parameters words Optional string sorting Optional string offset Optional integer limit Optional integer Words acting as a filter within the name of the app Example: Tetris Sorting Example: date Start of the pagination Example: 0 Number of elements in response Example: 10 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes apps Required array List of apps Example: [app1, app2, ] The following listing is an example of the JSON call: 153 / 305

154 { Listing 64: ALFREDO - JSON Example: Call App Search by Words "words": Tetris, "sorting": date, "offset": 0, "limit": 10 } The interface in Table 68 is used during reviewing time, and provides the list of apps that are under review. It is used by the mobile devices of testers. Table 68: ALFREDO RESTful Interface App Search under Review App Search under Review Provides the list of apps that are under the testing / review process Request Request URL GET URL Parameters sorting Optional string offset Optional integer limit Optional integer Sorting Example: date Start of the pagination Example: 0 Number of elements in response Example: 10 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes apps Required array List of apps Example: [app1, app2, ] The following listing is an example of the JSON call: 154 / 305

155 { Listing 65: ALFREDO JSON Example: Call App Search under Review "sorting": date, "offset": 0, "limit": 10 } In all the cases of app search included in this section, the JSON response will include a list of apps. Listing 66: ALFREDO - JSON Example: List of Apps of a Search { "apps": [ { "appid": " ", "name": "Tetris", "category": "Game", "version ": "1.3", "date": "01/11/2013", "iconurl": " "rating": "4.4", "published": true, "author": "Alexey Pajitnov", "support ": "support@pajitnov.com" } ] } Rating App The following RESTful method allows the user to rate an app: 155 / 305

156 Table 69: ALFREDO RESTful Interface Rate App Rate App Rates an app Request Request URL POST Resource Parameters appid Required integer versionid Required string rate Required string Id of the app Example: Version of the app Example: 1.1 The rate of the app Example: 3 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found The following listing is an example of the JSON call: { } "appid": , "versionid": 1.1, "rate": Consumed Services Listing 67: ALFREDO JSON Example: Call Rate App Personalization Manager o Get user profile: Retrieve the necessary information to construct application recommendations based on user habits and profile. See sections and CADE o Enable App: When a new application is installed from Marketplace, the CADE component has to be warned about it and then initialize the necessary parameters in order to work with the new application. See section ) 156 / 305

157 Game Manager o Install Game: Game Manager has to be informed when a new game is installed through the Marketplace. o Remove Game: Analogous to install game. Knowledge and Information Storage o Create Bucket (see section ) o Delete Bucket (see section ) o CRUD-Operation Create (see section ) o CRUD-Operation Read (see section ) o CRUD-Operation Update (see section ) o CRUD-Operation Delete (see section ) o Execute Generic Query (see section ) Summary Several technologies that could serve as base technologies for the ALFREDO Marketplace have been examined in regards of different requirements. Especially critical requirements like used language and framework, performance characteristics, extensibility and domain features as well as more uncritical but also telling indicators of a suitable technology like open bug reports and up-to-datedness have been examined and rated to make final technology choices. The ALFREDO Marketplace (both App and Web) will make use of the existing solution MyMarket because it fits the requirements in most cases. The main reason for using this solution is that it is the only solution that is focused on providing the same functionalities needed by the ALFREDO Marketplace, including the processes of uploading apps by the developers, reviewing of apps by the testers, and browsing and downloading of apps by the end users. Moreover, it has been implemented using the same technologies used in ALFRED (mainly Java for the server-side and Android for the client-side), so it will be easy to extend and to integrate with the other ALFRED components. And finally, Marketplace is well-known by partners, which makes it easy to implement in ALFRED ecosystem. 4.7 Personalization Manager The Personalization Manager (PM) component will be a central back-end system where user (i.e. older person) profile information will be stored and to which access will be provided. Additionally PM will ensure the privacy of the user profile information and provide access to the data only to those with adequate access rights. Moreover it will capitalize on the information it hosts, information extracted from social media accounts associated with the older person and on data retrieved from other components such as the Event Manager (section 4.8) to provide personalized recommendations for events for the older person. Finally PM will assist other components by providing context and resolve inputs from the user based on the information it hosts. The following sections will present the major design decisions for the implementation of the Personalization Manager, the comparison and selection of technologies for its realization and interactions with other components in terms of providing and consuming services. 157 / 305

158 4.7.1 Major Design Decisions The services which PM is aiming at can be quite challenging. The clearest\easiest functionality which PM offers is facilitating CRUD operations on user information while ensuring privacy. Even with consideration of the need for a distributed architecture that would support possible simultaneous calls by multiple users, it is perceived as a common functionality compared to the rest. The most challenging functionality is the provision of context about user inputs based on the profile information. Considering that user input could be anything and the context could be also about any number of concepts, this task would become impossible. For this reason the most important decision is the definition of clear boundaries on the kind of context the PM can provide and based on what inputs. Another less challenging but also complex functionality is the recommendations for events. In order to achieve good personalized recommendations various decision were made on the way the information would be represented, inclusion of social media information on the reasoning for the recommendation and the use of machine learning frameworks to contribute to the task. All these decisions are detailed below. Limit categories of context provision: The most important design decision for the implementation of the Personalization Manager is to limit and clearly define the kinds of context which the PM can provide as well as the form of inputs that it receives when asked to provide context. Without this limitation, these boundaries, the promised functionality would be impossible. The reason for this is that context can take numerous forms and reference points and even with only a small set of inputs the number of potential results would be too voluminous to provide resolution. It is decided for the design that the PM will support context provision on direct relationships of the older person with other entities; to provide a more tangible example of the vision for the context functionality, PM would contribute to resolving cases where user provides input such as call my son, call my doctor or call home. The categories of relations the PM will be able to resolve are based on the information model for the description of the user data. Rich and expressive schema for the data model: The data stored in the Personalization Manager will be used (amongst other things) for various reasoning applications such as recommendations and context provision. For this reason it is important for the design of the PM component to select the best information model to represent its stored data. The best option considered for the schema of the PM data is to use rich and expressive models such as ontologies or graphs. This option requires more time in designing the model and inserting the data but makes the data significantly smarter and facilitates the development of machine reasoning applications and optimized deduction of knowledge from the stored data. Moreover, since the data stored in the PM are relatively static, entering new data will not be frequent enough to cause performance issues due to the extra effort to insert information compared to other data models. Capitalize on social media to reinforce social inclusion: Another decision for the design of the PM is to capitalize heavily from social media accounts related to the older person and the information mined from them (with the user s permission). Social inclusion is considered very important for people of certain age and is one of the main objectives of ALFRED. The recommendations for participation to events will take into account various parameters and one of the most important which is expected to provide significant allure is the social aspect. Social aspect concerns 158 / 305

159 cases where events are found in which the participation of a friend/acquaintance of the older person is identified from social media. Employ machine learning for the reasoning: The final design decision for the implementation of the Personalization Manager is to employ machine learning in its various reasoning tasks. In this way the reasoning results will get optimized with time since they will improve as more data are stored on the PM and feedback for the reasoning results is provided. The machine learning applications will boost the personalization feeling of the ALFRED application for the user (i.e. older person) as time and usage increase Technology Comparison The realization of the Personalization Manager will mostly be based on software developed during the project and the technologies/frameworks that will be used to contribute to its realization concern the data store and the machine learning framework. The comparison and selection of data stores will be presented in section 4.10 while the comparison of machine learning frameworks and the selection for the PM will be described in the next sections Comparison Criteria The below table provides an overview of the criteria that are considered important for the selection of technologies, tools and frameworks for the realization of the Personalization Manager and its subcomponents. Table 70: Personalization Manager - Comparison Criteria for the Personalization Manager Components Parameter Importance Scaling ++ The technology selected should have the ability to scale as the volume of requests for recommendations of events and context resolution tasks increases. Collection of Machine Learning Algorithms Implementations Compatibility with graph/ontology data stores ++ The technology selected should provide a wide range of machine learning algorithms implementations in order to facilitate various types of reasoning for tasks of the PM. ++ The technology selected should allow easy integration with graph or ontology data stores as well as exploit their expressive and reach data model Possible Technologies and Comparison Machine Learning A brief introduction of some popular machine learning frameworks and their comparison based on the above described criteria follows: 159 / 305

160 Weka 26 is an open source machine learning suite that provides a wide collection of algorithms implementations for data mining tasks. Data mining application with Weka can be applied both from a GUI and from applications code (in Java). The most important data mining features provided by Weka include data preprocessing, clustering, classification, regression, visualization and feature selection. It is also very extensible and users can plug-in their own implementations of data mining algorithms. Weka supports a wide range of data mining algorithms; however it lacks in scalability and is limited to in-memory applications. KNIME 27 is an open source data integration, analytics, reporting and visualization platform. It provides a GUI from which users can interactively create complete data analysis workflows (which in KNIME terms are called pipelines) and execute them. A defined workflow in KNIME can include data access, data transformation, analytics and data mining, data visualization and data exploitation tasks. KNIME is extensible and users can contribute with their own developed functionalities. KNIME at its core can be used in applications that require scalability. ELKI 28 is an open source data mining platform that provides a wide collection of highly customizable mining algorithms. ELKI s design is driven by principles such as extensibility, completeness, performance, modularity and scalability. ELKI allows users to separate data management tasks and data mining algorithms, so they can select the algorithm of their choice; moreover facilitates users with the comparison and combination of mining algorithms. The main categories of algorithms included in ELKI are clustering, outlier detection and database indexes. ELKI can be used in applications that require high performance and scalability. GraphLab 29 is an open source, graph based distributed computation framework. GraphLab is mainly targeted for sparse iterative graph algorithms and also supports asynchronous execution. It provides a unified multicore and distributed API, it is highly performant and includes an extensive range of machine learning algorithms implementations. Based on GraphLab a variety of libraries are developed for topic modeling, graph analytics, clustering, collaborative filtering, graphical models and computer vision. GraphLap can be used in applications that require scaling. Apache Mahout 30 is an open source machine learning platform that provides a variety of data mining implementations mainly on the domains of collaborative filtering, clustering and classification. Mahout s core data mining algorithms are built on top of Apache Hadoop following the map/reduce paradigm. Moreover Mahout provides algorithms for dimensionality reduction, topic models as well as libraries for common math operations. Mahout is ideal for distributed and scalable applications and has a very active community / 305

161 Table 71: Personalization Manager - Comparison of Technologies for the Machine Learning Technologies Parameter Importance Weka KNIME ELKI GraphLab Apache Mahout Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards +/ Familiarity Performance Interoperability License + GPL 3.0 GPL 3.0 AGPL Apache 2.0 Apache 2.0 Specific Criteria Scalability Collection of Machine Learning Algorithms Implementations Compatibility with graph/ontology data stores Technology Selection The comparison of machine learning frameworks showed two very strong candidates, Apache Mahout and GraphLab. Apache Mahout is considered slightly superior in its features and collection of machine learning algorithms than GraphLab but GraphLab is more appropriate for expressively rich data stores (which are going to be used for storing data of the PM). However the selection for the machine learning framework is Apache Mahout for mainly three reasons: first its performance and features superiority, second its stronger community and expected improvements and finally the fact that GraphLab does not provide a Java API while Java is the language of choice for the development of the Personalization Manager component. Additionally, partners are very excited to research how Apache Mahout could compliment a rich and expressive data store for reasoning applications. 161 / 305

162 4.7.4 Component Structure The Personalization Manager will host the information and provide the functionalities which will ensure the personalized experience for ALFRED users. More specifically, the PM will store and manage (relatively) static information about the older person such as personal profile, health history, preferences and historical data from the interaction of the user with the ALFRED application. Other components of the ALFRED system as well as users related to the older person will be able to perform CRUD operations on the above data through the PM provided they have the appropriate access rights. The access rights assigned to each user related to a given older person will be part of the older person s profile. This information will be used to increase privacy assurance and provide the end user (i.e. older person) a level of control over her/his privacy settings. Additionally, PM based on the information it hosts, combined with information retrieved from other components such as the Event Manager and applied reasoning over the information, it will provide personalized recommendations for events that could be of interest for the older person. Finally, the Personalization Manager will contribute to other components by providing context based on the information it hosts about the older person. These functionalities will be realized by the development of four subcomponents, the Personalization Orchestrator, the Reasoning Engine, the Recommendation Engine and the Personalization Profile Administrator. These components are depicted in the figure (see Figure 17) below, followed by a brief description. 162 / 305

163 Recommendation Engine Rules Personalization Orchestrator Requests Receiver Health Monitor Matchmaker Classifier Recommendation Handler Tasks Scheduler Results Provider Personal Assistant Event Manager Reasoning Engine Personal Profile Administrator Access Rights and Authentication Handler Repository Handler Social Networks Miner Context Extractor Storage Mediator Personal Profile Model Knowledge and Information Storage Figure 17: Personalization Manager - Personalization Manager Component Structure Personalization Orchestrator: The Personalization Orchestrator will be the communication point of the Personalization Manager component with the other components and will allocate specific tasks to the appropriate sub-components Reasoning Engine: The Reasoning Engine will provide functionalities that ensure privacy assurance, context provision and social media mining to other internal subcomponents (e.g., Recommendation Engine) and external components (e.g., CADE- see section 4.5). Recommendation Engine: The Recommendation Engine will provide personalized recommendations for events that could be of interest to the older person based on his profile, preferences history, social and location context, health condition, etc. Personal Profile Administrator: The Personalization Profile Administrator will handle all CRUD operations requested both from other sub-components of the Personalization Manager and by external components, acting as a mediator between the PM and the KIS 163 / 305

164 4.7.5 Interfaces Java Interfaces of the Personalization Manager Create a User Profile This method allows the creation of a new user profile which contains all the information that describes the user. This method will be used when initializing the ALFRED application and the older person (or someone related such as a care giver or a family member) provides all information required by the ALFRED application to complete the user profile. The complete list of attributes for the information that describe the user is going to be defined in future work (T3.4 Personalization Framework) but in the context of this specification some indicative attributes are used for the UserProfile object 31. Parameters: newuserprofile: a UserProfile object with information about the user Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting to create a new user profile has insufficient rights. A UserProfileCreationException if an error occurs during the createuserprofile operation. Listing 68: Personalization Manager - API Method Signature to Create a New User Profile /** * Creates a new user profile with all the required attributes that describe the * user. * newuserprofile a UserProfile object with information about the user InsufficientRightsException if the user attempting to create a new user * profile has insufficient rights UserProfileCreationException if an error occurs during the * createuserprofile operation */ void createuserprofile(userprofile newuserprofile) throws InsufficientRightsException, UserProfileCreationException; Retrieve User Profile 31 Examples of the personal profile information attributes are presented in the Listings with JSON samples presented in section REST Interfaces of the Personalization Manager 164 / 305

165 This method allows the retrieval of the profile information of a user with the specified ID provided that the requester has sufficient access rights. Parameters: userprofileid: a String with the unique identification for the user Return Value: Returns a UserProfile object with information about the user with the specified ID. Error Handling: Remarks: None An InsufficientRightsException if the user attempting to retrieve the user profile has insufficient rights. A UserProfileNotFoundException if the user profile with the specified ID is not found. A UserProfileRetrievalException if an error occurs during the retrieveuserprofile operation. Listing 69: Personalization Manager - API Method Signature to Retrieve a User Profile /** * Retrieves the profile information of a user specified by a unique identification. * userprofileid a String with the unique identification for the user a UserProfile object with information about the user with the specified ID InsufficientRightsException if the user attempting to retrieve the user * profile has insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found UserProfileRetrievalException if an error occurs during the retrieveuserprofile operation */ UserProfile retrieveuserprofile(string userprofileid) throws InsufficientRightsException, UserProfileNotFoundException, UserProfileRetrievalException; Update User Profile This method allows the updating of the profile information of a user with the specified ID provided that the requester of the update has adequate access rights. Parameters: userprofileid: a String with the unique identification for the user updateduserprofile: a UserProfile object with the updated information about the user Return Value: 165 / 305

166 None Error Handling: Remarks: None An InsufficientRightsException if the user attempting to update the user profile has insufficient rights. A UserProfileNotFoundException if the user profile with the specified ID is not found. A UserProfileUpdateException if an error occurs during the updateuserprofile operation. Listing 70: Personalization Manager API Method Signature to Update a User Profile /** * Updates the profile information of a user with a specified ID * userprofileid a String with the unique identification for the user updateduserprofile a UserProfile object with the updated information about * the user InsufficientRightsException if the user attempting to update the user * profile has insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found UserProfileUpdateException if an error occurs during the updateuserprofile * operation */ void updateuserprofile(string userprofileid, UserProfile updateduserprofile) throws InsufficientRightsException, UserProfileNotFoundException, UserProfileUpdateException; Delete User Profile This method facilitates the deletion of the profile of a user with the specified ID provided that the requester of the deletion has sufficient access rights. Parameters: userprofileid: a String with the unique identification for the user Return Value: None Error Handling: An InsufficientRightsException if the user attempting to delete the user profile has insufficient rights. A UserProfileNotFoundException if the user profile with the specified ID is not found. A UserProfileDeletionException if an error occurs during the deleteuserprofile operation. 166 / 305

167 Remarks: None Listing 71: Personalization Manager API Method Signature to Delete a User Profile /** * Updates the profile information of a user with a specified ID * userprofileid a String with the unique identification for the user updateduserprofile a UserProfile object with the updated information about * the user InsufficientRightsException if the user attempting to update the user * profile has insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found UserProfileUpdateException if an error occurs during the updateuserprofile * operation */ void updateuserprofile(string userprofileid, UserProfile updateduserprofile) throws InsufficientRightsException, UserProfileNotFoundException, UserProfileUpdateException; Search User Profiles This method allows searching and retrieving of user profiles which adhere to a set of criteria provided in the parameters. Parameters: searchparameters: an Array of method parameter values. These values will be cast to the types of the actual method parameters Return Value: Returns an list of UserProfile objects with information about users who meet the provided parameters. Error Handling: Remarks: None An InsufficientRightsException if the user attempting to search for user profiles has insufficient rights. A UserProfilesSearchException if an error occurs during the searchuserprofiles operation. 167 / 305

168 Listing 72: Personalization Manager API Method Signature to Search for User Profiles /** * Searches for user profiles that meet the provided parameters. * searchparameters an Array of method parameter values. These values will be * cast to the types of the actual method parameters a List of UserProfile objects with information about users who meet the * provided parameters InsufficientRightsException if the user attempting to search for user * profiles has insufficient rights UserProfilesSearchException if an error occurs during the * searchuserprofiles operation */ List<UserProfile> searchuserprofiles(object[] searchparameters) throws InsufficientRightsException, UserProfilesSearchException; Retrieving Part of the User Profile Information This method allows the retrieval of a subset of the profile information for a user with the provided specified ID. Parameters: userprofileid: a String with the unique identification for the user userprofilefragmentsrequested: a List of enumerators with the parts of user profile requested Return Value: Returns an Array with the requested subset of profile information for the specified user. Error Handling: Remarks: None An InsufficientRightsException if the user attempting to retrieve the profile information has insufficient rights. An InvalidParametersException if the provided parameters for the requested information cannot be resolved to the subset of user profile information requested. A UserProfileNotFoundException if the user profile with the specified ID is not found. A UserProfileRetrievalException if an error occurs during the getuserinformation operation. 168 / 305

169 Listing 73: Personalization Manager API Method Signature to Retrieve Part of the User Profile Information /** * Retrieves a subset of the profile information (as requested in the parameters) of * a user with the specified ID. * userprofileid a String with the unique identification for the user userprofilefragmentsrequested a List of enum values with the parts of user * profile requested an Array with the requested subset of profile information for the * specified user InsufficientRightsException if the user attempting to retrieve the profile * information has insufficient rights InvalidParametersException if the provided parameters for the requested * information cannot be resolved to the subset of user profile information requested UserProfileNotFoundException if the user profile with the specified ID is * not found UserProfileRetrievalException if an error occurs during the * getuserinformation operation */ Object[] getuserinformation(string userprofileid, List<UserProfileFragment> userprofilefragmentsrequested) throws InsufficientRightsException, InvalidParametersException, UserProfileNotFoundException, UserProfileRetrievalException; Subscribe for Recommendations This method allows the subscription of a user with a specified ID to receive personalized recommendations for events that could be of interest. Parameters: Return Value: None userprofileid: a String with the unique identification for the user Error Handling: Remarks: None An InsufficientRightsException if the user attempting to subscribe has insufficient rights. A RecommendationsSubscriptionException if an error occurs during the suscribeforrecommendations operation. 169 / 305

170 Listing 74: Personalization Manager API Method Signature to Subscribe User for Recommendations /** * Subscribes a user with a specified ID to receive recommendations. * userprofileid a String with the unique identification for the user InsufficientRightsException if the user attempting to subscribe has * insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found RecommendationsSubscriptionException if an error occurs during the * suscribeforrecommendations operation */ void suscribeforrecommendations(string userprofileid) throws InsufficientRightsException, UserProfileNotFoundException, RecommendationsSubscriptionException; Unsubscribe from Recommendations This method will be used to unsubscribe a user with a specified ID from receiving personalized recommendations for events. Parameters: Return Value: None userprofileid: a String with the unique identification for the user Error Handling: Remarks: None An InsufficientRightsException if the user attempting to unsubscribe has insufficient rights. A UserProfileNotFoundException if the user profile with the specified ID is not found. A RecommendationsUnsubscriptionException if an error occurs during the unsubscribefromrecommendations operation. 170 / 305

171 Listing 75: Personalization Manager API Method Signature to Unsubscribe User from Recommendations /** * Unsubscribes a user with a specified ID from receiving recommendations. * userprofileid a String with the unique identification for the user InsufficientRightsException if the user attempting to unsubscribe has * insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found RecommendationsUnsubscriptionException if an error occurs during the * unsubscribefromrecommendations operation */ void unsubscribefromrecommendations(string userprofileid) throws InsufficientRightsException, UserProfileNotFoundException, RecommendationsUnsubscriptionException; Request Recommendation This method allows users to trigger a recommendation for events that could be of interest for them and satisfy the input parameters provided. Parameters: userprofileid: a String with the unique identification for the user recommendationparams: an Array of method parameter values. These values will be cast to the types of the actual method parameters Return Value: Returns a List of Event objects which are recommended based on the provided parameters. Error Handling: Remarks: None An InsufficientRightsException if the user attempting to request recommendation has insufficient rights. A UserProfileNotFoundException if the user profile with the specified ID is not found. A GetRecommendationException if an error occurs during the getrecommendation operation. 171 / 305

172 Listing 76: Personalization Manager API Method Signature to Request Recommendation for Events /** * Requests recommendation for events that meet certain specified parameters * userprofileid a String with the unique identification for the user recommendationparams an Array of method parameter values. These values will * be cast to the types of the actual method parameters a List of Event objects which are recommended based on the provided * parameters InsufficientRightsException if the user attempting to request * recommendation has insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found GetRecommendationException if an error occurs during the getrecommendation * operation */ List<Event> getrecommendation(string userprofileid, Object[] recommendationparams) throws InsufficientRightsException, UserProfileNotFoundException, GetRecommendationException; Retrieve User s Contacts Information Filtered by This method will facilitate the retrieval of contacts information for a user with a specified ID filtered by their name which is passed as a parameter. Parameters: userid: a String with the unique identification for the user contacts: a String with the name to filter the user contacts to be retrieved Return Value: Returns a List of UsersContact objects with the profile information of contacts related to the user. Error Handling: Remarks: None An InsufficientRightsException if the user attempting to request user's contacts has insufficient rights. A UserProfileNotFoundException if the user profile with the specified ID is not found. A GetUserContactsException if an error occurs during the getuserscontacts operation. 172 / 305

173 Listing 77: Personalization Manager API Method Signature to Retrieve User s Contacts Information Filter by /** * Retrieves the profile information of contacts filtered by name criterion of a user * with the specified ID. * userid a String with the unique identification for the user contacts a String with the name to filter the user contacts to be * retrieved a List of UsersContact objects with the profile information of contacts * related to the user InsufficientRightsException if the user attempting to request user's * contacts has insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found GetUserContactsException if an error occurs during the getuserscontacts * operation */ List<UsersContact> getuserscontacts(string userid, String contacts) throws InsufficientRightsException, UserProfileNotFoundException, GetUserContactsException; Retrieve User s Contacts Information Filtered by Relation This method will facilitate the retrieval of contacts information for a user with a specified ID filtered by their relation which is passed as a parameter. Parameters: userid: a String with the unique identification for the user relationtype: a Relation enumerator to filter user contacts based on their relation to the user Return Value: Returns a List of UsersContact objects with the profile information of contacts related to the user. Error Handling: Remarks: None An InsufficientRightsException if the user attempting to request user's contacts has insufficient rights. A UserProfileNotFoundException if the user profile with the specified ID is not found. A GetUserContactsException if an error occurs during the getuserscontacts operation. 173 / 305

174 Listing 78: Personalization Manager API Method Signature to Retrieve User s Contacts Information Filter by Relation /** * Retrieves the profile information of contacts filtered by criterion of the * relation to a user with the specified ID. userid a String with the unique identification for the user relationtype a Relation enumerator to filter user contacts based on their * relation to the user a List of UsersContact objects with the profile information of contacts * related to the user InsufficientRightsException if the user attempting to request user's * contacts has insufficient rights UserProfileNotFoundException if the user profile with the specified ID is * not found GetUserContactsException if an error occurs during the getuserscontacts * operation */ List<UsersContact> getuserscontacts(string userid, Relation relationtype) throws InsufficientRightsException, UserProfileNotFoundException, GetUserContactsException; RESTful Interfaces of the Personalization Manager Create a User Profile 174 / 305

175 Table 72: Personalization Manager RESTful Interface Create User Profile Create a User Profile Creates a new user profile with all the required attributes that describe the user Request Request URL POST Resource Parameters newuserprofile Required UserProfile see JSON schema Listing 79 The user profile information 32 Example: see Listing 80 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found The JSON schema used to describe the user profile information is detailed in the listing below (see Listing 79): 32 As mentioned before, the information model for the user profile will be defined during the work in Personalization Framework and the attributes described here are used as an example 175 / 305

176 { Listing 79: Personalization Manager - JSON schema of the UserProfile object "type" : "object", "properties" : { "userprofileid" : { "type" : "UUID" }, "userpersonalprofile" : { "type" : "object", "properties" : { "personalprofileid" : { "type" : "UUID" }, "first" : { "type" : "string" }, "middle" : { "type" : "string" }, "last" : { "type" : "string" }, "gender" : { "type" : "string", "enum" : [ "MALE", "FEMALE" ] }, "dateofbirth" : { "type" : "string" }, "phone" : { "type" : "string" }, "mobilephone" : { "type" : "string" }, " " : { "type" : "string" }, "address" : { "type" : "string" }, "postalcode" : { "type" : "string" }, "city" : { "type" : "string" }, "state" : { "type" : "string" }, "country" : { "type" : "string" }, "socialmediaprofiles" : { "type" : "array", "items" : { "type" : "string" } } } 176 / 305

177 Listing 80: Personalization Manager - Example JSON Supplied for the Create User Profile Service { "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "userpersonalprofile" : { "personalprofileid" : "d2fc9b2b-f758-4fb2-b98e-7a25858f5fc5", "first" : "Lydia", "middle" : null, "last" : "Vance", "gender" : "FEMALE", "dateofbirth" : "03/06/1950", "phone" : "1081 HV", "mobilephone" : " ", " " : "lynd.vance@gmail.com", "address" : "De Boelelaan 1105", "postalcode" : null, "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ] }, "userscontacts" : [ { "userscontactid" : "4ff3d d-4d67-ab e17", "first" : "Helen", "middle" : null, "last" : "Vance", "phone" : " ", "mobilephone" : " ", " " : "hvance@yahoo.com", "address" : "Oosterdokskade 151", "postalcode" : "1011 DL", "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ], "relationtype" : "DAUGTER", "accessrights" : [ "CONTACTS", "HEALTH_PROFILE", "HISTORICAL_DATA", "PERSONAL_PROFILE" ] } ], "userhealthprofile" : { "healthprofileid" : "795ff89d-3d4a-484a-a1a7-74ae08a38be1", "allergies" : null, "chronicalconditions" : null, "bloodtype" : "A+ RH", "notablemedicalincidents" : [ "Guillain Barre syndrome " ], "medicationreceiving" : null }, "userhistoricaldata" : [ { "historicaldataentryid" : "6f86c46a-db64-40f6-bc b839fb", "historicaldataentrycategory" : "GAMES_INSTALLED", "historicaldataentry" : "The game Sudocu was installed.", "entrydate" : "Thu Jul 24 16:24:50 CEST 2014" } ] } 177 / 305

178 Retrieve User Profile Table 73: Personalization Manager RESTful Interface Retrieve User Profile Retrieve User Profile Retrieves the profile information of a user with the specified ID Request Request URL GET Resource Parameters userprofileid Required UUID The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes retrieveduserprofile Required UserProfile see JSON schema Listing 79 The retrieved user profile description with the specified ID Example: see Listing / 305

179 Listing 81: Personalization Manager - Example JSON Response Containing the Retrieve User Profile Result { "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "userpersonalprofile" : { "personalprofileid" : "d2fc9b2b-f758-4fb2-b98e-7a25858f5fc5", "first" : "Lydia", "middle" : null, "last" : "Vance", "gender" : "FEMALE", "dateofbirth" : "03/06/1950", "phone" : "1081 HV", "mobilephone" : " ", " " : "lynd.vance@gmail.com", "address" : "De Boelelaan 1105", "postalcode" : null, "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ] }, "userscontacts" : [ { "userscontactid" : "4ff3d d-4d67-ab e17", "first" : "Helen", "middle" : null, "last" : "Vance", "phone" : " ", "mobilephone" : " ", " " : "hvance@yahoo.com", "address" : "Oosterdokskade 151", "postalcode" : "1011 DL", "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ], "relationtype" : "DAUGTER", "accessrights" : [ "CONTACTS", "HEALTH_PROFILE", "HISTORICAL_DATA", "PERSONAL_PROFILE" ] } ], "userhealthprofile" : { "healthprofileid" : "795ff89d-3d4a-484a-a1a7-74ae08a38be1", "allergies" : null, "chronicalconditions" : null, "bloodtype" : "A+ RH", "notablemedicalincidents" : [ "Guillain Barre syndrome " ], "medicationreceiving" : null }, "userhistoricaldata" : [ { "historicaldataentryid" : "6f86c46a-db64-40f6-bc b839fb", "historicaldataentrycategory" : "GAMES_INSTALLED", "historicaldataentry" : "The game Sudocu was installed.", "entrydate" : "Thu Jul 24 16:24:50 CEST 2014" } ] } 179 / 305

180 Update User Profile Table 74: Personalization Manager RESTful Interface Update User Profile Update User Profile Updates the profile information of a user with the specified ID Request Request URL PUT Resource Parameters userprofileid Required UUID updateduserprofile Required UserProfile object see JSON schema in Listing 79 The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" The updated user profile information Example: see Listing 82 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found 180 / 305

181 Listing 82: Personalization Manager - Example JSON Supplied for the Update User Profile Service { "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", { "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "userpersonalprofile" : { "personalprofileid" : "d2fc9b2b-f758-4fb2-b98e-7a25858f5fc5", "first" : "Lydia", "middle" : null, "last" : "Vance", "gender" : "FEMALE", "dateofbirth" : "03/06/1950", "phone" : "1081 HV", "mobilephone" : " ", " " : "lynd.vance@gmail.com", "address" : "De Boelelaan 1105", "postalcode" : null, "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ] }, "userscontacts" : [ { "userscontactid" : "4ff4f45h-0d4d-4d67-ab v46", "first" : "Nick", "middle" : null, "last" : "Vance", "phone" : " ", "mobilephone" : " ", " " : null, "address" : "Spui 21", "postalcode" : "1012 WX", "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : null, "relationtype" : "SON", "accessrights" : [ "CONTACTS", "HEALTH_PROFILE", "HISTORICAL_DATA", "PERSONAL_PROFILE" ] } ], "userhealthprofile" : { "healthprofileid" : "795ff89d-3d4a-484a-a1a7-74ae08a38be1", "allergies" : null, "chronicalconditions" : null, "bloodtype" : "A+ RH", "notablemedicalincidents" : [ "Guillain Barre syndrome " ], "medicationreceiving" : null }, "userhistoricaldata" : [ { "historicaldataentryid" : "6f86c46a-db64-40f6-bc b839fb", "historicaldataentrycategory" : "GAMES_INSTALLED", "historicaldataentry" : "The game Sudocu was installed.", "entrydate" : "Thu Jul 24 16:24:50 CEST 2014" } ] } } 181 / 305

182 Delete User Profile Table 75: Personalization Manager RESTful Interface Delete User Profile Delete User Profile Deletes a user profile with the specified ID Request Request URL DELETE Resource Parameters userprofileid Required UUID The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found 182 / 305

183 Search User Profiles Table 76: Personalization Manager RESTful Interface Search User Profiles Search User Profiles Retrieves a part of the profile information of a user with a specified ID Request Request URL POST Resource Parameters searchparameters Required Object[] Parameters for the search for users Example: see Listing 83 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes retrievedusers Required Object[] The retrieved users that match the parameters Example: see Listing 84 Listing 83: Personalization Manager - Example JSON Supplied for the Search Users Profiles Service { } "last" : "Vance", "city" : "Amsterdam", 183 / 305

184 Listing 84: Personalization Manager - Example JSON Response Containing the Search Users Profiles Result { } "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "userpersonalprofile" : { "personalprofileid" : "d2fc9b2b-f758-4fb2-b98e-7a25858f5fc5", "first" : "Lydia", "middle" : null, "last" : "Vance", "gender" : "FEMALE", "dateofbirth" : "03/06/1950", "phone" : "1081 HV", "mobilephone" : " ", " " : "lynd.vance@gmail.com", "address" : "De Boelelaan 1105", "postalcode" : null, "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ] }, "userhistoricaldata" : [ { "historicaldataentryid" : "6f86c46a-db64-40f6-bc b839fb", "historicaldataentrycategory" : "GAMES_INSTALLED", "historicaldataentry" : "The game Sudocu was installed.", "entrydate" : "Thu Jul 24 16:24:50 CEST 2014" } ] 184 / 305

185 Retrieving Part of the User Profile Information Table 77: Personalization Manager RESTful Interface Retrieving Part of the User Profile Information Retrieving Part of the User Profile Information Retrieves a part of the profile information of a user with a specified ID Request Request URL POST Resource Parameters userprofileid Required UUID userprofilefragment Required String[] The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" The parts of the user s profile information requested Example: [ "HISTORICAL_DATA", "PERSONAL" ] Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes usersrequestedinformation Required Object[] The requested information about the user Example: See Listing 86 Listing 85: Personalization Manager - Example JSON Supplied for the Retrieving Part of the User Profile Information Service { } "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "informationrequested" : [ "HISTORICAL_DATA", "PERSONAL" ] 185 / 305

186 Listing 86: Personalization Manager - Example JSON Response Containing the Retrieving Part of the User Profile Information Result { } "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "userpersonalprofile" : { "personalprofileid" : "d2fc9b2b-f758-4fb2-b98e-7a25858f5fc5", "first" : "Lydia", "middle" : null, "last" : "Vance", "gender" : "FEMALE", "dateofbirth" : "03/06/1950", "phone" : "1081 HV", "mobilephone" : " ", " " : "lynd.vance@gmail.com", "address" : "De Boelelaan 1105", "postalcode" : null, "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ] }, "userhistoricaldata" : [ { "historicaldataentryid" : "6f86c46a-db64-40f6-bc b839fb", "historicaldataentrycategory" : "GAMES_INSTALLED", "historicaldataentry" : "The game Sudocu was installed.", "entrydate" : "Thu Jul 24 16:24:50 CEST 2014" } ] 186 / 305

187 Subscribe for Recommendations Table 78: Personalization Manager RESTful Interface Subscribe for Recommendations Subscribe for Recommendations Subscribes a user with the specified ID to receive recommendations Request Request URL POST Resource Parameters userprofileid Required UUID The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found Listing 87: Personalization Manager - Example JSON Supplied for the Subscribe from Recommendations Service { "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba" } 187 / 305

188 Unsubscribe from Recommendations Table 79: Personalization Manager RESTful Interface Unsubscribe from Recommendations Unsubscribe from Recommendations Unsubscribes a user with the specified ID to receive recommendations Request Request URL POST Resource Parameters userprofileid Required UUID The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found Listing 88: Personalization Manager - Example JSON Supplied for the Unsubscribe from Recommendations Service { "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba" } 188 / 305

189 Request Recommendation Table 80: Personalization Manager RESTful Interface Request Recommendation Request Recommendation Requests for recommendation of events for a user with a specified ID based on certain criteria provided Request Request URL POST Resource Parameters userprofileid Required UUID recommendationparams Required Object[] The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" The provided parameters for the recommendation Example: see Listing 89 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes resultedrecommendation Required Object[] The recommendation for the user based on his profile information and the criteria provided Example: See Listing 90 { } Listing 89: Personalization Manager - Example JSON Supplied for the Request Recommendation Service "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "eventtype": "Artistic", "eventlocation": "Amsterdam", 189 / 305

190 Listing 90: Personalization Manager Example JSON Response Containing the Request Recommendation Result { { "eventid" : "e263ece0-870f-42ad-b1ca-f0ec5d7874d4", "event" : "C.W. Stoneking", "eventcategory" : "Artistic", "eventtype" : "Blues Concert", "eventlocation" : { "venueid" : "d7ade3b a1c-af08-fac07de17a26", "venue" : "Amsterdam Music Hall", "venueaddress" : "Mezquitalaan 45", "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : "1064NS", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "07/06/2015", "eventstarttime" : "21:00", "eventendtime" : "03:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null }, { "eventid" : "817fa6fe-243c-4ea c6fd75a91e", "event" : "Gregory Porter Concert", "eventcategory" : "Artistic", "eventtype" : "Jazz Concert", "eventlocation" : { "venueid" : "c5fd1c37-59ec-4efd-94aa c2", "venue" : "Amsterdam Music Hall", "venueaddress" : "Mezquitalaan 45", "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : "1064NS", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "03/04/2015", "eventstarttime" : "21:00", "eventendtime" : "03:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null } 190 / 305

191 Retrieve User s Contacts Information Filtered by Table 81: Personalization Manager RESTful Interface Retrieve User s Contacts Information Filtered by Retrieve User s Contacts Information Filtered by Retrieves the contacts of a user with a specified ID, filter by name Request Request URL GET Resource Parameters userprofileid Required UUID contact Required String The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" the name to act as a filter for the retrieval Example: Nick Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes resultedusercontacts Required UserContacts The resulted users contacts Example: See Listing 92 { } Listing 91: Personalization Manager - Example JSON Supplied for the Retrieve User s Contacts Filtered by Service "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "contact" : "Nick", 191 / 305

192 Listing 92: Personalization Manager - Example JSON Response Containing the Retrieve User s Contacts Filtered by Result { "userscontactid" : "4ff4f45h-0d4d-4d67-ab v46", "first" : "Nick", "middle" : null, "last" : "Vance", "phone" : " ", "mobilephone" : " ", " " : null, "address" : "Spui 21", "postalcode" : "1012 WX", "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : null, "relationtype" : "SON", "accessrights" : [ "CONTACTS", "HEALTH_PROFILE", "HISTORICAL_DATA", "PERSONAL_PROFILE" ] } 192 / 305

193 Retrieve User s Contacts Information Filtered by Relation Table 82: Personalization Manager RESTful Interface Retrieve User s Contacts Information Filtered by Relation Retrieve User s Contacts Information Filtered by Relation Retrieves the contacts of a user with a specified ID, filter by relation Request Request URL GET Resource Parameters userprofileid Required UUID contactrelation Required enum The ID of the user profile Example: "668cbaab-0a7c-452b-b588-d5a1df605eba" The relation to act as a filter for the retrieval Example: SON Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes resultedusercontacts Required UserContacts The resulted users contacts Example: See Listing 94 { } Listing 93: Personalization Manager - Example JSON Supplied for the Retrieve User s Contacts Filtered by Relation Service "userprofileid" : "668cbaab-0a7c-452b-b588-d5a1df605eba", "contactrelation" : "DAUGHTER", 193 / 305

194 Listing 94: Personalization Manager - Example JSON Response Containing the Retrieve User s Contacts Filtered by Relation Result { "userscontactid" : "4ff3d d-4d67-ab e17", "first" : "Helen", "middle" : null, "last" : "Vance", "phone" : " ", "mobilephone" : " ", " " : "hvance@yahoo.com", "address" : "Oosterdokskade 151", "postalcode" : "1011 DL", "city" : "Amsterdam", "state" : null, "country" : "The Netherlands", "socialmediaprofiles" : [ " ], "relationtype" : "DAUGTER", "accessrights" : [ "CONTACTS", "HEALTH_PROFILE", "HISTORICAL_DATA", "PERSONAL_PROFILE" ] } Consumed Services Knowledge and Information Storage o Create Bucket (see section ) o Delete Bucket (see section ) o CRUD-Operation Create (see section ) o CRUD-Operation Read (see section ) o CRUD-Operation Update (see section ) o CRUD-Operation Delete (see section ) o Execute Generic Query (see section ) Event Manager o Search Events in the Events Knowledge Base (see section ) o Search Events Mined from the Web (see section ) Summary This section concludes the specification of the Personalization Manager component. The objective and functionalities of PM were recapped followed by the architectural decisions for manufacturing the component. Additionally the technologies comparison and selection based on state of the art research was presented. Finally the provided methods for using the services provided by the PM as well as the services it consumes were defined so that the smooth interaction and cooperation between PM and the rest of the components are guaranteed. 194 / 305

195 4.8 Event Manager The Event Manager (EM) component will handle and maintain a Knowledge Base of events 33. The events will be used by the Personalization Manager (see section 4.7) to provide personalized recommendations to the ALFRED user (i.e. older person). Through the EM, users will be able to insert, browse and retrieve events from the Knowledge Base as well as search the Web for events and request to be saved in the Knowledge Base. Events in the Knowledge Base can be entered either manually or semi-automatically. For manual insertion of events, users will provide description of the events they wish to be persisted in the database. For semi-automatic insertion, the EM will crawl the Web and social media for events, process the fetched text to extract event descriptions and present the results to the user. The user will then evaluate the results and save the preferred ones in the database. Events persisted in the Knowledge Base can be browsed and retrieved both through a dedicated user interface and programmatically through service calls. The main components of the Event Manager are the Web Portal, the Web Crawler, the Event Miner and the Event Knowledge Base Administrator. The communication of the EM with external components will be achieved through REST-based requests and the data exchange format will be JSON Major Design Decisions The essential service which EM provides is a Knowledge Base of events to which CRUD operations can be performed both through a GUI and programmatically. The role of this component is very focused and certain aspects/sub-components of its implementation (e.g., Web Portal, Event Knowledge Base Administrator) are not exactly challenging from an engineering point of view but when it comes to crawling data from the Web and processing the crawled text to extract and summarize events for the users, it can be a very challenging task which requires sophisticated implementations and good selection of tools and frameworks. The decision drivers for the realization of such features is that a semiautomated way of updating the Knowledge Base of events is the easiest and most efficient approach to maintain as well as it will result to a larger corpus of events. Ease of use and maintainability of the Knowledge Base: The inclusion of the older person in various activities is one of the crucial objectives in ALFRED. The inclusion is achieved to a large extend through the personalized recommendations provided by the ALFRED virtual assistant. The recommendations require a Knowledge Base of events which they can filter and evaluate to select events that would be of interest for the user (i.e. older person). The first major decision in regards to the Event Manager component is to make the interaction with the Knowledge Base of events easy so that users populate it with events and are able to maintain a large collection of events updated without excessive costs, times and efforts. The ease of use will be achieved both through user friendly and intuitive user interface and with automation features for extraction of events from the Web. Semi-automatic extraction of events: The second major design decision is to employ Web crawling and data mining so that a wide range of potential events for suggestions are available and can be evaluated for the recommendations. If the 33 Events in this context include social, athletic, musical, educational, etc. 195 / 305

196 population of the Knowledge Base with events was solely manual then the collection of events would possibly be significantly limited and frequently outdated. Moreover, it would be costly in terms of resources, meaning users such as caretakers, family members, etc. who should spend lots of time and effort even to have a limited and often outdated collection of events. This design decision is related to the first (i.e. ease of use and maintainability) but it also leads to issues that need to be considered when employing such technologies such as scalability and performance. Flexible schema, scalability and availability: Finally, the data that will be stored in the Events Knowledge Base, especially in the case of the events that are crawled from the web, will not have a fixed schema. This is due to the fact that the description of the events cannot be guaranteed to be the same type or even similar in all cases and it does not need to be. This schema less approach for the data store will also contribute in the two above decisions, since it will require excessive effort to enter events in the Knowledge Base. Moreover, the Events Knowledge Base will have to deal with a vast volume of data (the more the better) which are not only frequently updated but also queried daily practically for all ALFRED users and their personalized recommendations. So the ability to handle such requests is another important design decision. The technology comparison and selection for the data store that will be used for the Events Knowledge Base is provided in section Technology Comparison The realization of the Event Manager component and its features require the combination of various technologies for its front-end and back-end sub-components. The most challenging parts as mentioned before are the Web crawling and the text processing to mine events. The next sections will provide an overview of the technologies considered and evaluated as well as the criteria for their evaluation Comparison Criteria The below table (see Table 83) provides an overview of the criteria that are considered important for the selection of technologies, tools and frameworks for the realization of the Event Manager and its subcomponents. Table 83: Event Manager - Criteria for Technical Specification for the Event Manager Components Parameter Importance Scalability ++ The technology selected should have the ability to scale as the volume of user requests for web mining and event extraction increases to the Events Knowledge Base increases. This is a criterion for the selection both of the Web crawler and Full-Text Search technologies for the EM component. Configurability ++ The selected technology should be reasonably configurable to allow ALFRED developers and administrators to decide on the trade-offs to achieve optimal performance for the 196 / 305

197 system. This is a criterion for the selection both of the Web crawler and Full-Text Search technologies for the EM component. Retrieval ++ The selected technology for the Web crawler should provide good content retrieval features from the defined locations on the Web for fetching. This will allow the fast and efficient crawling for events as well as provide good raw data for the event mining tasks. Indexing + The selected technology for the web crawler should provide good indexing features to collect, parse and store the retrieved contents from the web for further processing and mining for events. Partition and Replication ++ The selected technology for the Full-Text Search should host and process reliably and effectively the large volume of crawled contents from the Web to be mined for events. For this reason the selected technology should support the division of elements into independent parts for computation and also support multiple executions of the computing tasks. Concurrency ++ The selected technology for the Full-Text Search should support concurrent computations in order to perform adequately fast mining of events from the vast amount of text content retrieved from the Web during crawling Possible Technologies and Comparison - Event Crawler A brief introduction of some popular search engine solutions and their comparison based on the above described criteria follows. Heritrix 34 is an open source, extensible, Web-scale crawler developed by the Internet Archive for the purpose of Web archiving (Gordon Mohr, 2004). Heritrix was developed in Java due to its quality open source libraries, previous works and outside contributions which could benefit the project. Heritrix is accessible from a web based GUI and also provides a command line tool that can be used to initialize crawls. At its core Heritrix is a generic crawler on which exchangeable components can be attached. Mercator (Najork, 1999) is an extensible and scalable Web crawler developed in Java. It can be used to crawl large parts of the Web and fetch millions of Web documents. It is designed in a modular way and allows addition of functionalities originating from third parties. The initial motivation for developing Mercator was the collection of statistics about the Web. Mercator crawls the Web in a random walking approach. The network protocols supported by Mercator to fetch documents include HTTP, FTP and Gopher. Mercator uses checkpoints using a global readers-writers block, in order to retain knowledge/state in case of failures or pauses / 305

198 WebFountain (Lelescu, 2004) is a scalable, high-performant, distributed platform developed by IBM. WebFountain supports data gathering, storing and analyzing massive volumes of unstructured and semi structured text. WebFountain provides capabilities of advanced text analytics on a Web scale. The data gathering of WebFountain is provided via its internal Web crawler, which creates a consistent warehouse of documents from distributed sources over the Web. Its internal crawler is continuous, maintaining fresh copies of its documents by recrawling the Web. The crawling processes of WebFountain are highly configurable including the definition of re-crawling frequency. WIRE 35 is an open source web information retrieval environment developed in C/C++ started by the Center for Web Research. WIRE is composed mainly by a Web crawler, a simple format for storing documents, and tools for extracting statistics and generating reports. WIRE is scalable and can cope with several million documents, and is high performant. It is highly configurable and users can define parameters for crawling and indexing in an XML file. WIRE also provides data analysis capabilities including extraction of statistics and links analysis, generating the results in reports. WIRE is mainly a tool for Web characterization studies but can be extended for other purposes. Apache Nutch (Rohit Khare, 2005) is an open source Web search engine based on Lucene 36. Nutch can be used in global, local and personal scale. Nutch is developed in Java and is designed to provide scalability, flexibility and high configuration abilities. Its architecture is modular, facilitating extensions and plugins in its system. It is provided under the Apache licence and is an active project. The main features of Apache Nutch include crawling, fetching, indexing, storing and analyzing documents. Nutch adopts a transparent approach for its ranking during search aiming for non-biased results. Table 84: Event Manager - Comparison of Technologies for the Search Engine Technologies Parameter Importance Heritrix Mercator WebFountain WIRE Apache Nutch Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards +/ Familiarity Performance / 305

199 Interoperability License + Apache Proprietary Commercial GPL Apache 2.0 Specific Criteria Scalability Configurability Retrieval Indexing Possible Technologies and Comparison Event Miner A brief introduction of some popular text-search platforms and their comparison based on the above described criteria follows: Apache Solr 37 is an open source enterprise search platform built on top of Apache Lucene. Its features include powerful full text support, hit highlighting, faceted search, near real-time indexing, dynamic clustering, database integration, rich document (e.g., Word, PDF) handling and geospatial search. Solr provides a REST API and supports XML, CSV and JSON data formats. It provides distributed indexing, replication and load-balanced querying, automated failover and recovery and a centralized configuration. Solr s external and centralized configuration requires its index structure, text and fields and provides flexibility to the applications that can be used. ElasticSearch 38 is an open source, distributed, real-time full-text search and analytics engine built on top of Apache Lucene. It provides high availability and real time data handling and analytics. ElasticSearch provides a REST API interface and is schema free and document oriented. The supported data format by ElasticSearch is JSON. In ElasticSearch a cluster is able to host multiple indices which can then be queried independently or in groups. It supports faceting and percolating as well as real-time GET requests making its use in combination with NoSQL databases possible. Moreover, ElasticSearch ensures data integrity with conflict management capabilities in cases of conflict while changes from multiple processes. Amazon CloudSearch 39 scalable, fully managed search service in the Amazon Web Services (AWS) Cloud. CloudSearch supports text processing, unstructured text searching, faceted searching, field based sorting, customized relevance ranking, autocomplete and geospatial search. CloudSearch is provided in a pay as you go approach making it cost-effective. It provides a REST API interface and can / 305

200 handle documents in JSON and XML data format. CloudSearch s rich search features can be supported for 33 different languages. Sphinx 40 is an open source, scalable, full-text search server with design that was driven by factors such as integration simplicity and search quality. Sphinx supports search both on files and on batch indexed data stored in SQL and NoSQL databases. Key features of Sphinx include batch and real-time full-text indexes, non-text attributes support, SQL and NoSQL database indexing, rich database-like querying features, better relevance ranking and distributed searching. Sphinx allows the ease of integration by providing three different APIs, namely SphinxAPI (which is native library for most programming languages), SphinxSE (which is a pluggable storage engine for MySQL) and SphinxQL (which allows applications to query Sphinx using standard MySQL client libraries and syntax). Xapian 41 is an open source full-text search engine library, designed to be flexible and adaptable so that its users can extend the indexing and search capabilities in their applications. Xapian is based on the probabilistic information retrieval model and additionally supports a rich set of Boolean query operations. Key features of Xapian include reliable transactions, parallel search and update, support for large databases, relevance based feedback, phrase and proximity searching, wildcard search and spelling correction. Xapian s indexing can support rich document formats such as PDF, Word and OpenOffice. Moreover, it supports stemming capabilities for 15 different languages. Table 85: Event Manager - Comparison of Technologies for the Text-Search platforms Parameter Importance Apache Solr ElasticSearch Amazon CloudSearch Sphinx Xapian Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards +/ Familiarity Performance Interoperability License + Apache 2.0 Apache 2.0 Commercial Dual - GPLv2 and commer cial GNU / 305

201 Specific Criteria Scalability Configurability Partition and Replication Concurrency Technology Selection Technology Selection for Event Crawler From the comparison of web search frameworks and technologies based on which the Event Crawler will be developed, Apache Nutch shows the highest potential. It is a scalable solution which can be extended and configured. Moreover, Nutch is a mature technology with strong community which provides certain confidence in using it as a base for the Event Crawler. Apache Nutch is tested on very large scales and proved to be very performant. Its retrieval and indexing features are better from all considered alternatives and will be used for the retrieval of contents from targeted locations on the Web which will be further processed for mining of events. The Event Crawler sub-component will leverage Apache Nutch to crawl over a defined set of Web locations and pass the retrieved contents to the Event Miner for extraction and summarization of events to be presented to the user Technology Selection for Event Miner The comparison of full-text search frameworks which will be used for the development of the Event Miner did not have a clear winner but provided two very good options to select from, namely, Solr and ElasticSearch. Both frameworks are built on top of Apache Lucene, have the same set of features and their performance is at the same level. Solr is more mature but ElasticSearch makes up for it with a highly focused community and development objective which is to extract value from data instead of general search. The selection of full-text search platform to be used by the Event Miner is ElasticSearch because it allows the development of more real-time search application compared to Solr, has easier configuration and its aim as a framework to derive value from data is in-line with the objective of the Event Miner Component Structure The Event Manager component as mentioned before facilitates the management and maintenance of the Events Knowledge Base. It will provide a user interface for its users (which can be simple users or reviewers) as well as an API that allows calling a subset of its functions programmatically. Through the EM GUI users will be able to insert, browse and update events in the Events Knowledge Base as well as to search the Web for events. Moreover, the EM will provide an API for retrieving events that are stored in the Events 201 / 305

202 Knowledge Base. These functionalities will be realized by the development of fours subcomponents, the Web Portal, the Event Crawler, the Event Miner and the Events Knowledge Base Administrator. These components are depicted in the figure below (see Figure 18), followed by a brief description. Web Event Crawler Event Miner Crawling Policies Data Processor Content Fetcher Information Extraction Raw Content Dumper Text Classification Event Summarization Web Portal Events Knowledge Base Administrator New Event Form Knowledge Base Handler New Events Search Persisted Events Browser Result Events Evaluator Storage Mediator Events Model Knowledge and Information Storage Personalization Manager Figure 18: Event Manager - Component Structure 202 / 305

203 The Web Portal will provide a user interface from which users can perform CRUD operations on the Events Knowledge Base. The users in this context are grouped into two categories, reviewers and simple users. Reviewers have administrational rights over the Events Knowledge Base while simple users can request read, create and update actions but create and update are executed only if a reviewer confirms the process. Moreover, through the GUI users can search the Web for events and decide if they wish to persist in the Events Knowledge Base any of the resulted events. The Web Crawler subcomponent will be responsible for retrieving the contents (mainly text) from a predefined set of Web locations, indexing them and delivering them for further processing and extraction of events. The Event Miner performs information extraction, text classification and summarization over the fetched contents from the Web. The processed description of events is presented to the user when requests search of the Web for events. The Events Knowledge Base Administrator sub-component will act as a mediator for all CRUD requests to the Events Knowledge Base which is placed in KIS (section 4.10). The requests it will have to handle will originate either through the Web Portal or through the EM API Interfaces Java Interfaces of the Event Manager Submitting an event to the Events Knowledge Base This method allows users to submit an event description for evaluation in order to be stored in the Events Knowledge Base. The method will be used in both manual and semiautomatic submission of events. Manual submission concerns cases where users provide the description for the event and semi-automatic concerns cases where users choose to submit an event description extracted from the Web. The method requires as a parameter an Event object which contains attributes that represent information details (a description) of the submitted event. Parameters: newevent: An Event object with information of the submitted event Return Value: None Error Handling: Remarks: None An EventSubmissionException if an error occurs during the submitevent operation. 203 / 305

204 Listing 95: Event Manager API Method Signature to Submit an Event /** * Submits an event description to be saved in the Events Knowledge Base. The event * will be temporarily stored until it will be evaluated by a reviewer who will * either save or discard the event. * newevent an Event object with information of the submitted event EventSubmissionException if an error occurs during the submitevent * operation */ void submitevent(event newevent) throws EventSubmissionException; Retrieving an Event from the Knowledge Base This method allows the retrieval of an event description from the Events Knowledge Base with the specified unique identification. Parameters: eventid: A String with the unique identification of the event to be retrieved Return Value: Returns an Event object that is identified by the specified ID. Error Handling: Remarks: None An EventNotFoundException if no Event object is found in the Event Knowledge Base with the specified ID. Listing 96: Event Manager API Method Signature to Retrieve an Event from the Events Knowledge Base /** * Retrieves an event description with the specified ID. * eventid a String with the unique identification of the event to be * retrieved an Event object that is identified by the specified ID EventNotFoundException if no Event object is found in the Event Knowledge * Base with the specified ID */ Event getevent(string eventid) throws EventNotFoundException; Search Events in the Events Knowledge Base This method facilitates the search for events in the Events Knowledge Base which meet a given set of parameters. Parameters: searchparams: An EventSearchParams object that contains parameters for the search in the Events Knowledge Base Return Value: 204 / 305

205 Returns a List of Event objects which satisfy the specified parameters Error Handling: Remarks: None An EventNotFoundException if no Event object is found in the Event Knowledge Base which meets the specified parameters. An EventSearchException if an error occurs during the searchknowledgebaseforevents operation. Listing 97: Event Manager API Method Signature to Search Events in the Events Knowledge Base which Meet the Specified Parameters /** * Searches the Events Knowledge Base for events which satisfy a given list of * parameters. * searchparams an EventSearchParams object that contains parameters for the * search in the Events Knowledge Base A List of Event objects which satisfy the specified parameters EventNotFoundException if no Event object is found in the Event Knowledge * Base which meets the specified parameters EventSearchException if an error occurs during the * searchknowledgebaseforevents operation */ List<Event> searchknowledgebaseforevents(eventsearchparams searchparams) throws EventNotFoundException, EventSearchException; Search Events Mined from the Web This method facilitates the search for events which were extracted from the Web and meet a specified set of parameters. Parameters: searchparams: An EventSearchParams object that contains parameters for the search Return Value: Returns a List of Event objects which satisfy the specified parameters. Error Handling: Remarks: None An EventSearchException if an error occurs during the searchknowledgebaseforevents operation. 205 / 305

206 Listing 98: Event Manager API Method Signature to Search Events Mined from the Web Which Meet the Specified Parameters /** * Searches events mined from defined locations on the Web which satisfy a given list * of parameters. * searchparams an EventSearchParams object that contains parameters for the * search A List of Event objects which satisfy the specified parameters EventNotFoundException if no Event object is found which meets the * specified parameters EventSearchException if an error occurs during the searchwebforevents * operation */ List<Event> searchwebforevents(eventsearchparams searchparams) throws EventSearchException; Delete Event from the Events Knowledge Base This method allows the deletion of an event with a specified unique identification from the Events Knowledge Base, provided that the requester has sufficient rights. Parameters: eventid: A String with the unique identification of the event to be retrieved Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting the deletion has insufficient access rights. An EventNotFoundException if no Event object is found in the Event Knowledge Base with the specified ID. An EventDeletionException if an error occurs during the deleteevent operation. Listing 99: Event Manager API Method Signature to Delete Events from the Events Knowledge Base /** * Deletes an event description from the Events Knowledge Base. * eventid a String with the unique identification of an Event object InsufficientRightsException if the user attempting the deletion has * insufficient access rights EventNotFoundException if no Event object is found with the specified ID EventDeletionException if an error occurs during the deleteevent operation */ void deleteevent(string eventid) throws InsufficientRightsException, EventNotFoundException, EventDeletionException; 206 / 305

207 Save Event in the Events Knowledge Base This method will be used to save (submitted) events in the Events Knowledge Base by users with the adequate access levels (i.e. reviewers). Parameters: newevent: An Event object with information of the submitted event Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting the saving has insufficient access rights. An EventStoringException if an error occurs during the saveevent operation. Listing 100: Event Manager API Method Signature to Save Events in the Events Knowledge Base /** * Saves in the Events Knowledge Base the submitted events which are temporarily * stored for evaluation. * newevent an Event object with the description of the event to be saved InsufficientRightsException if the user attempting the saving has * insufficient access rights EventStoringException if an error occurs during the saveevent operation */ void saveevent(event newevent) throws InsufficientRightsException, EventStoringException; Discard Submitted Event This method will be used when reviewers decide to discard an event description submitted to be stored in the Events Knowledge Base. Parameters: eventid: A String with the unique identification of the event to be retrieved Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting the discarding has insufficient access rights. An EventDiscardingException if an error occurs during the discardevent operation. 207 / 305

208 Listing 101: Event Manager API Method Signature to Discard Events Submitted for the Events Knowledge Base /** * Discards a submitted event and removes it from the temporary storage with events * for evaluation eventid a String with the unique identification of the event to be * discarded InsufficientRightsException if the user attempting the discarding has * insufficient access rights EventDiscardingException if an error occurs during the discardevent * operation */ void discardevent(string eventid) throws InsufficientRightsException, EventDiscardingException; Update Event in the Events Knowledge Base This method allows users to update the event description of an event specified by the provided unique identification. Parameters: eventid: A String with the unique identification of the event to be retrieved updatedevent: An Event object with the new description for the event Return Value: None Error Handling: Remarks: None An EventNotFoundException if no Event object is found in the Event Knowledge Base with the specified ID. An EventUpdateException if an error occurs during the updateevent operation. Listing 102: Event Manager API Method Signature to Update Events in the Events Knowledge Base /** * Updates the description of an event which is stored in the Events Knowledge Base. * eventid a String with the unique identification of the event to be updated updatedevent an Event object with the new description for the event InsufficientRightsException if the user attempting the update has * insufficient access rights EventNotFoundException if no Event object is found with the specified ID EventUpdateException if an error occurs during the update operation */ void updateevent(string eventid, Event updatedevent) throws InsufficientRightsException, EventNotFoundException, EventUpdateException; 208 / 305

209 Delete Outdated Events This method will provide an easy way to delete events in bulk. Users with sufficient rights can delete events from a specified date provided as a parameter. This will act as garbage collecting for events that are considered outdated and thus no longer useful. Parameters: A Date object with the date till which all events will be considered Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting the deletion has insufficient access rights. An EventDeletionException if an error occurs during the deleteoutdatedevents operation. Listing 103: Event Manager API Method Signature to Delete Outdated Events From the Events Knowledge Base /** * Deletes all events which are taking place from a specified date and back. * date a Date object with the date till which all events will be considered * outdated and will be deleted InsufficientRightsException if the user attempting the deletion has * insufficient access rights EventDeletionException if an error occurs during the deleteoutdatedevents * operation */ void deleteoutdatedevents(date date) throws InsufficientRightsException, EventDeletionException; Add Website for Event Extraction This method will allow users to add another location on the Web for the Event Manager to mine for events. They will provide the URL of the website as well as necessary information for the specific website to allow its effective crawling. Parameters: neweventswebsite: An EventsWebsite object with all the required information Return Value: None Error Handling: An InsufficientRightsException if the user attempting to add new Website for events extraction has insufficient access rights. 209 / 305

210 Remarks: None A WebsiteAdditionException if an error occurs during the addwebsiteforeventextraction operation. Listing 104: Event Manager API Method Signature to Add Websites for the Web Event Mining /** * Adds a new Web location which will used when crawling and mining for events. * neweventswebsite an EventsWebsite object with all the required information InsufficientRightsException if the user attempting to add new Website for * events extraction has insufficient access rights WebsiteAdditionException if an error occurs during the * addwebsiteforeventextraction operation */ void addwebsiteforeventextraction(eventswebsite neweventswebsite) throws InsufficientRightsException, WebsiteAdditionException; Remove Website for Event Extraction This method will allow users to remove a Web location from those visited when mining for events. Parameters: neweventswebsite: An EventsWebsite object with all the required information Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting to remove a Website from those visited for events extraction has insufficient access rights. A WebsiteRemovalException if an error occurs during the removewebsiteforeventextraction operation. 210 / 305

211 Listing 105: Event Manager API Method Signature to Remove Websites for the Web Event Mining /** * Removes a Web location with a specified ID from those which will be used when * crawling and mining for events. * eventswebsiteid a String with the unique identification of the Web location InsufficientRightsException if the user attempting to remove the specified * Website has insufficient access rights WebsiteRemovalException if an error occurs during the * removewebsiteforeventextraction operation */ void removewebsiteforeventextraction(string eventswebsiteid) throws InsufficientRightsException, WebsiteRemovalException; Create User Profile This method will facilitate the creation of user profiles based on the information provided and the access levels assigned to the new profile by the administrator. Parameters: newuserprofile: A UserProfile object with the profile information of the new user Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting to add a new user has insufficient access rights. A UserCreationException if an error occurs during the createuser operation. Listing 106: Event Manager API Method Signature to Create New User Profile for the Event Manager System /** * Creates a new user profile for the Event Manager system. * newuserprofile a UserProfile object with the profile information of the new * user InsufficientRightsException if the user attempting create a new user * profile has insufficient access rights UserCreationException if an error occurs during the createuser operation */ void createuser(userprofile newuserprofile) throws InsufficientRightsException, UserCreationException; 211 / 305

212 Retrieve User Profile This method retrieves the profile information of a user specified by a unique identification. Parameters: userid: A String with the unique identifier of the user profile Return Value: Returns a UserProfile object with the description of the user profile information. Error Handling: Remarks: None An InsufficientRightsException if the user attempting to retrieve the user profile has insufficient access rights. A UserProfileNotFound if the user profile with the specified ID is not found. A UserRetrievalException if an error occurs during the getuser operation. Listing 107: Event Manager API Method Signature to Retrieve a User Profile From the Event Manager System /** * Retrieves user profile information. * userid a String with the unique identifier of the user profile a UserProfile object with the description of the user profile information InsufficientRightsException if the user attempting to retrieve the user profile has insufficient access rights UserProfileNotFound if the user profile with the specified ID is not found UserRetrievalException if an error occurs during the getuser operation */ UserProfile getuser(string userid) throws InsufficientRightsException, UserRetrievalException; Update User Profile This method facilitates the update of the profile information for a user with the specified unique identification parameter. The updated information is provided also as a parameter. Parameters: userid: A String with the unique identifier of a user profile Return Value: None Error Handling: Remarks: An InsufficientRightsException if the user attempting to update the user profile has insufficient access rights. A UserProfileNotFound if the user profile with the specified ID is not found. A UserUpdateException if an error occurs during the updateuser operation. 212 / 305

213 None Listing 108: Event Manager API Method Signature to Update a User Profile in the Event Manager System /** * Updates the profile information of a user with the specified ID. * userid a String with the unique identifier of a user profile updateduserprofile a UserProfile object with the updated information of the * user profile InsufficientRightsException if the user attempting to update the user * profile has insufficient access rights UserProfileNotFound if the user profile with the specified ID is not found UserUpdateException if an error occurs during the updateuser operation */ void updateuser(string userid, UserProfile updateduserprofile) throws InsufficientRightsException, UserProfileNotFound, UserUpdateException; Delete User Profile This method allows the deletion of a user profile and removing its access rights from the system. Parameters: userid: A String with the unique identifier of a user profile Return Value: None Error Handling: Remarks: None An InsufficientRightsException if the user attempting to delete the user profile has insufficient access rights. A UserProfileNotFound if the user profile with the specified ID is not found. A UserUpdateException if an error occurs during the deleteuser operation. 213 / 305

214 Listing 109: Event Manager API Method Signature to Delete a User Profile From the Event Manager System /** * Deletes a user profile from the Event Manager system. * userid a String with the ID of the user to be deleted InsufficientRightsException if the user attempting to delete the user profile has insufficient access rights UserProfileNotFound if the user profile with the specified ID is not found UserDeletionException if an error occurs during the deleteuser operation */ void deleteuser(string userid) throws InsufficientRightsException, UserProfileNotFound, UserDeletionException; RESTful Interfaces of the Event Manager Submitting an Event Table 86: Event Manager RESTful Interface Submit Event Submit an Event Submits a description of an event to be stored in the Events Knowledge Base Request Request URL Resource Parameters HTTP Status Code POST newevent Required Event see JSON Schema Listing 110 Value 200 OK The description of the submitted event Example: see Listing 111 Response 400 Invalid parameters 404 App not found 214 / 305

215 { "type" : "object", "properties" : { "eventid" : { "type" : "UUID" }, "event" : { "type" : "string" }, "eventcategory" : { "type" : "string" }, "eventtype" : { "type" : "string" }, "eventlocation" : { "type" : "object", "properties" : { "venueid" : { "type" : "string" }, "venue" : { "type" : "UUID" }, "venueaddress" : { "type" : "string" }, "venuecity" : { "type" : "string" }, "venuestate" : { "type" : "string" }, "venuepostalcode" : { "type" : "string" }, "venuecountry" : { "type" : "string" }, "venuelatitude" : { "type" : "string" }, "venuelongtitude" : { "type" : "string" } } }, "eventdatetime" : { "type" : "object", "properties" : { "eventdate" : { "type" : "string" }, "eventstarttime" : { "type" : "string" }, "eventendtime" : { "type" : "string" }, "timezone" : { "type" : "string" } } }, "eventsocialmediaurls" : { "type" : "array", "items" : { "type" : "string" } }, "event" : { "type" : "string" } } } Listing 110: Event Manager - JSON schema of the Event Object 215 / 305

216 { } Listing 111: Event Manager - Example JSON Supplied for the Submit Event Service "eventid" : "06632c44-dcca-4f7f-825c-0011c ", "event" : "Innovation in Europe", "eventcategory" : "Educational", "eventtype" : "R&D Projects Conference", "eventlocation" : { "venueid" : "e280254f ede-a6ac eea180", "venue" : "Amsterdam Music Hall", "venueaddress" : "De Corridor 5", "venuecity" : "Breukelen", "venuestate" : null, "venuepostalcode" : "3621ZA", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "21/09/2014", "eventstarttime" : "15:00", "eventendtime" : "09:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null 216 / 305

217 Retrieving an Event from the Knowledge Base Table 87: Event Manager RESTful Interface Retrieve and Event from the Knowledge Base Retrieving an Event from the Knowledge Base Retrieves an event from the Events Knowledge Base with the specified ID Request Request URL GET :eventid Resource Parameters eventid Required UUID The ID of the user profile Example: "e263ece0-870f-42ad-b1ca-f0ec5d7874d4" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes resultedevent Required Event see JSON Schema Listing 110 The retrieved event description with the specified ID Example: see Listing / 305

218 Listing 112: Event Manager - Example JSON Response Containing the Retrieve Event Service Result { "eventid" : "e263ece0-870f-42ad-b1ca-f0ec5d7874d4", "event" : "C.W. Stoneking", "eventcategory" : "Artistic", "eventtype" : "Blues Concert", "eventlocation" : { "venueid" : "d7ade3b a1c-af08-fac07de17a26", "venue" : "Amsterdam Music Hall", "venueaddress" : "Mezquitalaan 45", "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : "1064NS", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "07/06/2015", "eventstarttime" : "21:00", "eventendtime" : "03:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null } 218 / 305

219 Search Events in the Events Knowledge Base Table 88: Event Manager RESTful Interface Search Events in the Events Knowledge Base Search Events in the Events Knowledge Base Searches the Events Knowledge Base for events which meet the provided parameters Request Request URL GET Resource Parameters searchparams Required EventSearchParams see JSON schema Listing 113 An Event JSON object with attributes that describe the search parameters Example: see Listing 114 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes resultedevents Required Event[] see JSON Schema Listing 110 The Event objects that meet the specified parameters Example: see Listing / 305

220 { } Listing 113: Event Manager - JSON Schema of the EventSearchParams Object "type" : "object", "properties" : { "event" : { "type" : "string" }, "eventtype" : { "type" : "string" }, "eventcategory" : { "type" : "string" }, "eventvenue" : { "type" : "string" }, "eventlocation" : { "type" : "string" }, "eventdatetime" : { "type" : "string" } } Listing 114: Event Manager - Example JSON Supplied for the Search Events in the Events Knowledge Base Service { } "eventtype": "Artistic", "eventlocation": "Amsterdam", "eventdatetime": "June 2015" 220 / 305

221 Listing 115: Event Manager - Example JSON Response Containing the Resulted Events of the Search Service { { "eventid" : "e263ece0-870f-42ad-b1ca-f0ec5d7874d4", "event" : "C.W. Stoneking", "eventcategory" : "Artistic", "eventtype" : "Blues Concert", "eventlocation" : { "venueid" : "d7ade3b a1c-af08-fac07de17a26", "venue" : "Amsterdam Music Hall", "venueaddress" : "Mezquitalaan 45", "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : "1064NS", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "07/06/2015", "eventstarttime" : "21:00", "eventendtime" : "03:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null }, { "eventid" : "817fa6fe-243c-4ea c6fd75a91e", "event" : "Gregory Porter Concert", "eventcategory" : "Artistic", "eventtype" : "Jazz Concert", "eventlocation" : { "venueid" : "c5fd1c37-59ec-4efd-94aa c2", "venue" : "Amsterdam Music Hall", "venueaddress" : "Mezquitalaan 45", "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : "1064NS", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "03/04/2015", "eventstarttime" : "21:00", "eventendtime" : "03:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null } 221 / 305

222 Search Events Mined from the Web Table 89: Event Manager RESTful Interface Search Events Mined from the Web Search Events Mined from the Web Searches the Web for events which meet the provided parameters Request Request URL GET web Resource Parameters searchparams Required EventSearchParams see JSON schema Listing 113 An Event JSON object with attributes that describe the search parameters Example: see Listing 116 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes resultedevents Required Event[] see JSON Schema Listing 110 The Event objects that meet the specified parameters Example: see Listing 117 Listing 116: Event Manager - Example JSON Supplied for the Search the Web for Events Service { } "eventtype": "Athletic", "eventlocation": "Amsterdam", "eventdatetime": "17 of July 2015" 222 / 305

223 { } Listing 117: Event Manager - Example JSON Response Containing the Retrieve Event Service Result "eventid" : "e269aae0-870f-43gh-b1ca-f0ec2e7874v4", "event" : null, "eventcategory" : "Athletic", "eventtype" : "Ajax Real Madrid", "eventlocation" : { "venueid" : "d7add2h a1c-ak99-fac32ui17a26", "venue" : "Amsterdam Bilmer Arena", "venueaddress" : null, "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : null, "venuecountry" : "The Netherlands", "venuelatitude" : null, "venuelongtitude" : null }, "eventdatetime" : { "eventdate" : "17/07/2015", "eventstarttime" : "19:00", "eventendtime" : "21:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ null ], "event" : null 223 / 305

224 Delete Event from the Events Knowledge Base Table 90: Event Manager RESTful Interface Delete Event from the Events Knowledge Base Delete Event from the Events Knowledge Base Deletes an event from the Events Knowledge Base with the specified ID Request Request URL DELETE :eventid Resource Parameters eventid Required UUID The ID of the user profile Example: "e263ece0-870f-42ad-b1ca-f0ec5d7874d4" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found 224 / 305

225 Save Event in the Events Knowledge Base Table 91: Event Manager RESTful Interface Save Event in the Events Knowledge Base Save Event in the Events Knowledge Base Saves a submitted event to the Events Knowledge Base Request Request URL POST Resource Parameters eventid Required UUID event Required Event see JSON Schema Listing 110 The ID of the user profile Example: "e263ece0-870f-42ad-b1ca-f0ec5d7874d4" The description of the event to be stored in the Events Knowledge Base Example: see Listing 118 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found 225 / 305

226 { } Listing 118: Event Manager - Example JSON Supplied for the Save Event Service "eventid" : "817fa6fe-243c-4ea c6fd75a91e", "event" : "Gregory Porter Concert", "eventcategory" : "Artistic", "eventtype" : "Jazz Concert", "eventlocation" : { "venueid" : "c5fd1c37-59ec-4efd-94aa c2", "venue" : "Amsterdam Music Hall", "venueaddress" : "Mezquitalaan 45", "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : "1064NS", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "03/04/2015", "eventstarttime" : "21:00", "eventendtime" : "03:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null 226 / 305

227 Discard Submitted Event Table 92: Event Manager RESTful Interface Discard Submitted Event Discard Submitted Event Discards an event submitted to be saved in the Events Knowledge Base with the specified ID Request Request URL DELETE Resource Parameters eventid Required UUID The ID of the user profile Example: "e263ece0-870f-42ad-b1ca-f0ec5d7874d4" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found 227 / 305

228 Update Event in the Events Knowledge Base Table 93: Event Manager RESTful Interface Update Event in the Events Knowledge Base Update Event in the Events Knowledge Base Updates the description of an event with a specified ID in the Events Knowledge Base Request Request URL PUT :eventid Resource Parameters eventid Required UUID updatedevent Required Event see JSON Schema Listing 110 The ID of the user profile Example: "e263ece0-870f-42ad-b1ca-f0ec5d7874d4" The updated description for the event in the Events Knowledge Base Example: see Listing 119 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found 228 / 305

229 Listing 119: Event Manager - Example JSON Supplied for the Update Event Service { "eventid" : "817fa6fe-243c-4ea c6fd75a91e", { "eventid" : "817fa6fe-243c-4ea c6fd75a91e", "event" : "Gregory Porter Concert", "eventcategory" : "Artistic", "eventtype" : "Jazz Concert", "eventlocation" : { "venueid" : "c5fd1c37-59ec-4efd-94aa c2", "venue" : "Amsterdam Music Hall", "venueaddress" : "Mezquitalaan 45", "venuecity" : "Amsterdam", "venuestate" : null, "venuepostalcode" : "1064NS", "venuecountry" : "The Netherlands", "venuelatitude" : " ", "venuelongtitude" : " " }, "eventdatetime" : { "eventdate" : "03/04/2015", "eventstarttime" : "21:00", "eventendtime" : "03:00", "timezone" : "UTC+01:00" }, "eventsocialmediaurls" : [ " ], "event" : null } } 229 / 305

230 Delete Outdated Events Table 94: Event Manager RESTful Interface Delete Outdated Events Delete Outdated Events Deletes all events which are taking place from a specified date and back Request Request URL DELETE outdated/ Resource Parameters date Required string The date till which all events will be considered outdated and will be deleted Example: "03/11/2012" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found Listing 120: Event Manager - Example JSON Supplied for the Delete Outdated Events Service { "date" : "03/11/2012", } 230 / 305

231 Add Website for Event Extraction Table 95: Event Manager RESTful Interface Add Website for Event Extraction Add Website for Event Extraction Adds a location on the web to be crawled when mining for events 42 Request Request URL POST Resource Parameters websiteid Required UUID website Required string websiteurl Required string The ID of the website Example: "f247f8c b3f-85a4-eb2ebd731c6b" The given name of the website Example: "iamsterdam" The URL of the website Example: " Centre/media-assistance/Plan-your-trip/event-calendar" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found Listing 121: Event Manager - Example JSON Supplied for the Add Website Service { "websiteid" : "f247f8c b3f-85a4-eb2ebd731c6b", "website" : "iamsterdam", "websiteurl" : " } 42 Users who wish to add websites when crawling for events need to provide additional information (e.g., schema, source code) regarding the website in order to make the effective crawling possible. The specifics of the information they need to provide will be specified in future work. 231 / 305

232 Remove Website from Event Extraction Table 96: Event Manager RESTful Interface Remove Website from Event Extraction Remove Website from Event Extraction Deletes a location on the web from those crawled when mining for events Request Request URL DELETE :websiteid Resource Parameters websiteid Required UUID The ID of the website Example: "f247f8c b3f-85a4-eb2ebd731c6b" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found 232 / 305

233 Create User Profile Table 97: Event Manager RESTful Interface Create User Profile Create User Profile Creates a new user profile for the Event Manager system Request Request URL Resource Parameters HTTP Status Code POST newuserprofile Required UserProfile see JSON schema Listing 122 Value 200 OK The user profile description to be created Example: see Listing 123 Response 400 Invalid parameters 404 App not found { } Listing 122: Event Manager - JSON schema of the UserProfile object "type" : "object", "properties" : { "userid" : { "type" : "string" }, "first" : { "type" : "string" }, "last" : { "type" : "string" }, "user" : { "type" : "string" }, " " : { "type" : "string" }, "accesslevel" : { "type" : "string", "enum" : [ "ADMINISTRATOR", "REVIEWER", "USER" ] } } 233 / 305

234 Listing 123: Event Manager - Example JSON Supplied for the Create User Profile Service { } "userid" : "578519da-d042-4eae-8f76-432e5237bd42", "first" : "Tasos", "last" : "Martidis", "user" : "tmart", " " : "tasos.martidis@tiekinetix.com", "accesslevel" : "REVIEWER" Retrieve User Profile Table 98: Event Manager RESTful Interface Retrieve User Profile Retrieve User Profile Retrieves a user profile with the specified ID from the Event Manager system Request Request URL GET :userid Resource Parameters userid Required UUID The ID of the user profile Example: "578519da-d042-4eae-8f76-432e5237bd42" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found JSON Attributes userprofile Required UserProfile see JSON schema Listing 122 The user profile with the specified ID Example: see Listing / 305

235 { } Listing 124: Event Manager - Example JSON Response Containing the Retrieve User Profile Result "userid" : "578519da-d042-4eae-8f76-432e5237bd42", "first" : "Tasos", "last" : "Martidis", "user" : "tmart", " " : "tasos.martidis@tiekinetix.com", "accesslevel" : "REVIEWER" 235 / 305

236 Update User Profile Table 99: Event Manager RESTful Interface Update User Profile Update User Profile Updates the description of a user profile with a specified ID in the Event Manager system Request Request URL PUT :userid Resource Parameters userid Required UUID The ID of the user profile Example: "578519da-d042-4eae-8f76-432e5237bd42" updateduserprofile Required UserProfile see JSON schema Listing 122 The user profile with the specified ID Example: see Listing 125 Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found Listing 125: Event Manager - Example JSON Supplied for the Update User Profile Service { } "userid" : "578519da-d042-4eae-8f76-432e5237bd42", { "userid" : "578519da-d042-4eae-8f76-432e5237bd42", "first" : "Anastasios", "last" : "Martidis", "user" : "amart", " " : "anastasios.martidis@tiekinetix.com", "accesslevel" : "REVIEWER" } 236 / 305

237 Delete User Profile Table 100: Event Manager RESTful Interface Delete User Profile Delete User Profile Deletes a user profile with a specified ID from the Event Manager system Request Request URL DELETE user/:userid Resource Parameters userid Required UUID The ID of the user profile to be deleted Example: "578519da-d042-4eae-8f76-432e5237bd42" Response HTTP Status Code Value 200 OK 400 Invalid parameters 404 App not found Consumed Services Knowledge and Information Storage o Create Bucket (see section ) o Delete Bucket (see section ) o CRUD-Operation Create (see section ) o CRUD-Operation Read (see section ) o CRUD-Operation Update (see section ) o CRUD-Operation Delete (see section ) o Execute Generic Query (see section ) Summary This section concludes the description of the Event Manager component. The reader at this point is provided with an understanding of the mission of the EM, the design decisions for its architecture and the technology selection for its realization. Additionally the services it provides are detailed as well as the services of other components it will consume. This detailed definition of the interactions will be invaluable for ensuring the interaction and cooperation of the various ALFRED components after their (to a certain extend) individual development. 237 / 305

238 4.9 Game Manager The Game Manager (GM) component is responsible for all functions of the ALFRED application that are related to serious games (3 rd party apps that fulfil the technical requirements to qualify as ALFRED-ready games or serious games, in the context of the ALFRED system short games ). These functions can be divided into three main sets: Game Management: The GM communicates with the ALFREDO Marketplace (see chapter 4.6) in order to maintain a database of metadata information about the games currently installed on the user s device. Over time, this game metadata is enriched with usage and player performance information and used to enhance both the game suggestion mechanisms and the game control and adaptation mechanisms (see below). Game Suggestion: The GM communicates with other internal components of the ALFRED application, especially with the Health Monitor (see chapter 4.4) and the Personalization Manager (see chapter 4.7), in order to be able to make sophisticated game suggestions to the end user (compare with DoW, tasks 7.1 and 7.2). There are two types of suggestions that the Game Manager initiates: triggers and recommendations. Subchapter explains the difference. Game Control: This is the GM s core functionality and the respective subcomponent of the GM called GAME (see below) is responsible for configuring and adapting games to the likes and needs of the individual user, for starting and stopping such games, and for monitoring player performance during gameplay. If a specific game requires any external hardware to be played. GAME is also responsible for establishing and maintaining communication with this hardware. Among other things, this may include communication with external hardware sensors to measure user activity and wellbeing (also see SAF, chapter ), PCs, TVs, other mobile devices, and online game servers to enable multiplayer game sessions (compare with DoW, tasks 6.2, 7.2 and 7.3). Note: The installation, updating and de-installation of games are handled by the ALFREDO Marketplace Major Design Decisions There are three main challenges related to the Game Manager component, which are explained in the following subsections Requirements for ALFRED-ready games As its name implies, the Game Manager is mainly responsible for managing and controlling games for the ALFRED system. For this reason, games need to adhere to certain requirements in order to allow the Game Manager to fulfill its set tasks. This section investigates what these tasks of the Game Manager are and analyses the implications that their existence has on games: Adding a game: When a game is downloaded from the ALFREDO marketplace to the ALFRED device, the Game Manager needs to be informed about the availability of this new game and its characteristics. Both pieces of information are relevant to the game suggestion process and can be provided through a game metadata file (see below). This metadata file needs either to be included in the respective game s 238 / 305

239 APK or it needs to be send to the Game Manager separately by the ALFREDO marketplace. Both options have advantages: an inclusion in the APK file simplifies the communication between the Game Manager and the ALFREDO Marketplace component, while a separate provision allows the Game Manager to also learn about the characteristics of games that are available from the Marketplace but not currently installed on the user s device. Additionally, an external provision allows the Marketplace to enrich the original metadata files with dynamic information provided by Game Managers (e.g. information about average player performance or game settings preferred by the majority of users). Regardless of the actual implementation, game developers working with the ALFRED platform will have to provide a metadata file for each of their games (see also section ). Removing a game: When a user deletes a game from the device, the Game Manager needs to be informed about this in order to exclude the respective game from game suggestions (more specifically: game triggering, see below) henceforth. This task has no direct implications on the design of games. Establishing hardware communication: Some games (named indoor games in deliverable D2.4, page 43) may require additional hardware to function properly, such as a TV screen or external sensors. The Game Manager is responsible for establishing and maintaining the communication with these components, e.g. via the Bluetooth module. To this end, games should rely on the Game Manager to establish communication with external hardware (and not establish it by themselves). Game configuration: The main target group of the ALFRED system are persons above the age of 60 (see deliverable D2.1, page 11), commonly referred to as older people. However, as Peter Wintlev-Jensen of the European Commission points out, they are not a homogenous group, but rather highly diverse. Consequently, ICT solutions for the elderly need to adapt ( ) to individual needs and capabilities [Win09]. To enable this kind of adaptation, at least to a certain extent, all games should provide for a set of configuration options, such as setting the size of UI elements, the game difficulty, or the type of interaction preferred by the user (e.g. speech-based interaction vs. GUI-based interaction). Depending on various criteria, such as the user s physical and mental disabilities, the Game Manager will then use these options to configure the respective game to the individual user, aiming to provide the optimal gaming experience for this specific person. To this end, a set of meaningful configuration options has to be defined that developers of games should implement (but only if a specific configuration option can reasonably be implemented for the game in question). Game monitoring: A player s usage habits regarding a specific game and her performance for this game are valuable information for the refinement of the game suggestion process (see also section ). Additionally, some of this information may be of interest to relatives or carers (if, for example, a specific game has been integrated into a therapy plan). Also, anonymized usage and performance statistics can be used to support the ALFREDO marketplace in differentiating between popular and not-so-popular games, not only based on user rating, but also on actual usage habits. To this end, games must provide methods to allow the Game Manager to access certain information, such as how the player has performed during the last game session. 239 / 305

240 Game adaptation: Related to the game configuration and game monitoring tasks, it is reasonable that the Game Manager not only configures a given game before it is being started. It should rather also be able to adapt a running game if it detects certain pattern in the user behavior (for example, if the user appears to have difficulties in completing a given task) or if contextual information acquired by sensors or other sources indicates that an adaptation is due (for instance, because the user s heart rate increases significantly). Most kinds of adaptation could also be left to the game mechanic itself. However, it may be reasonable to centralize certain adaptation options at the Game Manager as it may be able to make more sophisticated decisions than the game itself- an open question that has to be investigated. In any case, to allow for such adaptations, the games need to provide for the required adaptation options, similar to the public methods needed for the game configuration and game monitoring tasks. The challenge posed by the management tasks of the Game Manager as detailed above lies in the definition of a meaningful set of methods that need to be implemented by all ALFRED-ready games to enable the Game Manager to configure, monitor and possibly adapt these games to the liking and needs of the specific user Game Suggestion Mechanisms There are two types of suggestions the Game Manager supports, triggering and recommendations. Triggering: One of the three responsibilities of the Game Manager, besides maintaining information about the currently installed games and configuring and monitoring these games while they are being played, is to help cross the gap in between these two states, that is to motivate the player to play a specific game at a specific time (for example, to regularly play an exergame in order to achieve therapy compliance). In other words, the Game Manager aims to convince the player to show an intended behavior at a specific time, in this case to play a specific game. According to the behavior model of the Stanford psychology professor BJ Fogg [Fog09], the likelihood that someone will show an intended behavior essentially requires three things to happen at the same time: at the given moment, the person needs to be motivated enough, she needs to have the required ability to show the intended behavior (in other words, it needs to be easy enough for her), and finally, there needs to be a trigger that activates the person. While the questions of how to create (serious) games that both motivate the player and that neither bore nor stress her are core challenges of game design and have consequently been investigated by many researches [Bar96, SW05, SHM07], the question of when and how to activate a potential player, the so-called triggering, is relatively new and has not been addressed by researchers up until now. Raising the likelihood of successful triggering requires the Game Manager to have access to information about the player s current location, her physical activity, her mood and wellbeing, the state of her environment, her application usage history, and about her traits and characteristics, especially about potential mental and physical disabilities (both temporarily and permanently). To this end, the Game Manager must gather information from various other components of the ALFRED system, specifically the Personalization Manager, the Health Monitor, and the Personal 240 / 305

241 Assistant. How to design and implement successful triggering mechanisms is the second Game Manager-related research challenge of the ALFRED project. Recommendations: The second suggestion type that the Game Manager supports is the suggestion of additional games to the user besides the ones that she has already locally installed on her device. These so-called recommendations of games that are available from the ALFREDO Marketplace and that appear to be matching the user s interest should encourage her to try out new games frequently and to thus help to keep the ALFRED system interesting for a long period of time. The implementation of the recommendation system appears to be less challenging than the realization of a meaningful triggering mechanism. Nevertheless, it offers the opportunity to investigate different approaches for recommending additional software to the user and we expect the actual development of these mechanisms to reveal synergies with the triggering processes Metadata Format for Games The Game Manager component needs to understand the characteristics of the games that are available from the ALFREDO Marketplace and installed on the user s device, both for the sake of being able to make meaningful game suggestions to the user, and for being able to adapt a specific game to a specific player. For this reason, a common metadata format for games is needed, where a set of information is stored. Such as information about a game s specific type (for example exergame, strategy, puzzle ), the minimum and maximum amount of players supported (e.g. 1-4 ), the hardware and software required for playing the game (e.g. Android 4.2 ), and so forth. Indeed, the main challenge of providing a metadata format for games can be split down into several smaller problems: Level of detail: Video games come in many different forms and the differences between two given games can range from being very obvious to being very subtle, but nevertheless crucial. Passionate gamers are aware that even two games from the same subgenre, such as real time strategy games, can provide for a fundamentally different game experience [SW05]. Consequently, a metadata specification that, for example, merely states that the game in question is an exergame is by far not sufficiently precise for sophisticated game selection and configuration mechanisms. On the other hand, the amount of information that can be provided for a specific game by domain experts is almost limitless, as even the simplest game has many technical, social, and cultural facets that may (or may not) be taken into account. As such, the endeavor of defining a metadata format for games requires agreeing on a specific level of detail for the information that is mandatory for game designers and/or domain experts to provide for. This of course also requires defining the corresponding categories, subcategories, and information bits that make up the actual format definition. Information model: A metadata format for games can be realized through different conventions, ranging from comparably simple XML lists of predefined tags on the one hand to ontologies written as sets of OWL statements that allow for reasoning on the information provided on the other. This is not only a choice of processibility, however, but also of acceptance: the simpler the specified format is to understand and work with, the higher the probability that domain experts will adopt it. Consequently, these two factors need to be balanced against one another when deciding for a specific convention. 241 / 305

242 Generalizability: To the best of our knowledge, there is little to no previous work available that tried to establish a common metadata format for digital games in general or for serious games in particular [GGS11]. In this regard, the ALFRED project poses an unique opportunity to design and establish such a format, especially as it also provides for the use cases required for demonstrating such a format s applicability and meaningfulness (semi-automatic game selection from the set of available games at the ALFREDO Marketplace, sophisticated game suggestion from the set of currently installed game extensions on the user s device, game adaptation to the individual user in order to enhance the gaming experience). However, the provision of a Generic Game Metadata Format (GGMF) may prove to be too ambitious and in this regard, the restriction on a subset of such a generic format for ALFRED-ready games only, the ALFRED-specific Game Metadata Format (AGMF), appears to be reasonable. A related topic is the question whether to allow for dynamic information within such metadata files, for example the amount of seconds that a specific user has played a specific game or the average performance results for this game. The provision of a metadata file format for games, either specifically for the ALFRED system or, preferably, for video games in general, is the third Game Manager related challenge posed by the ALFRED project Technology Comparison See chapter ( Technology Selection ) Technology Selection The Game Manager will be implemented as a client-based component in Java for Android to allow for its integration alongside some of the other ALFRED components into a single Android APK (= the ALFRED app ). The exact Android API level that the Game Manager component will be based on depends mainly on the API level of the selection of the OS (see chapter ). At this point of time, there are no further technology selections required and/or possible, in part because various Game Manager-related design decisions require further investigations that will be made during the project itself (such as the selection of a game metadata information model, see chapter 4.9.1) Component Structure As can be seen on the following figure (Figure 19), the Game Manager consists of a total of five subcomponents (subsequently also referred to as modules ), namely three primary modules (GAME, GLM and SG) and two secondary, supporting modules (GDCF and CCF). This section briefly discusses all of these modules and puts a special focus on the interrelations of the Game Manager with the other ALFRED components, ALFRED (game) extensions, and external devices. 242 / 305

243 Figure 19: Game Manager - Component Structure 243 / 305

244 Game Adaptation and Monitoring Entity (1): The Game Adaptation and Monitoring Entity (GAME) are responsible for handling all game configurations, controlling, adaptation and monitoring tasks of games. To this end, it communicates with the games locally installed on the ALFRED device through the Games and Devices Communication Framework of the Game Manager, see below (the actual communication is routed through the Personal Assistant component). The module also interfaces the Component Communication Framework (see below) to acquire up-to-date information about the user s preferences and state from Personal Assistant, the Personalization Manager, and the Health Monitor. This information is required for making meaningful configurations and adaptations. GAME also receives impulses from the Personal Assistant (via the Component Communication Framework) to start games by request of the user, possibly after GAME has successfully triggered her. Lastly, GAME also interfaces the Database Module of the Game Manager, where it stores usage and performance information about the games played by the user (see below). Game Library Manager (2): The Game Library Manager (GLM) maintains the metadata files of all games currently installed on the user s device. Its main tasks lies in adding and removing games (that is, their respective metadata files) from the Database Module (see below). Suggestion Generator (3): The Suggestion Manager (SG) makes game suggestions to the user, based on the set of games currently installed on the user s device. To this end, SG queries various ALFRED components for information about the user s state and her environment, which is done via the Component Communication Framework. It then matches the characteristics of the available games, as available from the Database Module (see below), with this user-related context information and tries to make sophisticated decisions as to when to suggest which game to the user (the actual suggestion delivery is handled by the Personal Assistant component). Database Module (4): The database module is the central storage point for the Game Manager. It is primarily used for holding information about currently installed games in the ALFRED-specific Game Metadata Format. These metadata files are accessed by all three primary Game Manager components (GAME, GLM and SG). Communication Frameworks (5): The Game Manager features two communication frameworks. A communication framework is a set of APIs and method stubs that allow the modules of the Game Manager to interact with software that is external to the Game Manager, notably game extensions and other components of the ALFRED system, but also hardware drivers. There are two separate communication frameworks: the Games and Devices Communication Framework (the GDCF) is responsible for communicating with (external) game extensions and external hardware this includes communication with the Sensor Abstraction Framework (SAF) to access health related sensor data. The Component Communication Framework (the CCF), on the other hand, is responsible for establishing internal communication with the other components of the ALFRED system. Both communications (internal and external) work in both ways by providing Game Manager services to game extensions and other ALFRED components through an API on the one hand, and by consuming services from game extensions, hardware drivers and other ALFRED components on the other 244 / 305

245 hand. The provided and consumed services are covered in chapters 4.9.5( Interfaces ) and chapters 4.9.6( Consumed Services ), respectively Interfaces This section describes the public interfaces provided by the Game Manager to other components of the ALFRED system and to games. Provided to external software: The Games and Devices Communication Framework (GDCF) provides access to the following methods for games and external hardware: o Establish Connection/Terminate Connection: The minimal requirement for an Android-based game to qualify as an ALFRED-ready game is to call these methods whenever it is being started or stopped (= when the application is given focus by the Android OS or when it loses focus). This is to notify the Game Manager that a game is currently running. o Request Configuration: The Game Manager has access to information that can be used to configure a game to better fit an individual user s wants and needs. This configuration process usually takes places before the game is actually being played (different to the adaption process, which can take place during gameplay). By calling this method, a game triggers the Game Manager to pass on a list of settings in a predefined format to the game extension, that can then in turn be used by the game to adjust specific parameters of the game (such as foreground and background colors). The format of this parameter list will be defined within the context of WP7 (see also ). o Request Adaptation: Different to a configuration which takes places prior to a game being played, adaptation is the process of changing the settings of a game during gameplay. This is both a pull and push functionality, meaning that both the Game Manager and a games have to provide a method to transfer adaptation settings from the Game Manager to the respective game extension. As a pull functionality (the game extension requests the Game Manager to transfer adaptation settings to the extension), the Game Manager first needs to be informed about the current state of the game. To this end, this public method of the Game Manager accepts a list of game state values, very similar to the list accepted by the game state delivery method (see below). o Deliver Game State: One of the functionalities of the Game Manager is to monitor gameplay and to use this knowledge to refine the configuration, adaptation and suggestion mechanisms. The Game Manager needs to be informed about how a user has played a game and how well she has performed in respect to the game s rules and challenges. For this reason, a game has to call this method of the Game Manager component prior to termination and to deliver a list of game state variables that inform the Game Manager component about the user performance. The actual format of this list will be defined in the context of WP7. Provided to internal components: The Component Communication Framework (CCF) provides access to the following methods for other components of the ALFRED system: 245 / 305

246 o Install Game: This method is called by the ALFREDO marketplace component when a user downloads and installs a game on her device. It accepts the game description of the specific game in the serious game metadata format in order to inform the Game Manager about the characteristics of this specific game (see also ). o Remove Game: Similar to the install game method, this method has to be called when the user decides to remove a local installation of a game from the device. o Start Game: Gets called by the Personal Assistant when the user wants to start a game. o Stop Game: Analogous to the Start Game method. o Pause Game: Analogous to the Start Game method. o Forward Command: Some games may offer the option of being controllable by voice. Obviously, this will be only be true for comparably simple games with low-complex game mechanics that can be based on a reduced set of user interactions (such as the four commands forward, backward, left and right ). Such commands will then be interpreted by the CADE component and forwarded to the Game Manager component using this method, possibly encoded as an integer parameter (the encoding list for CADE supported commands will be defined within WP7). o Get Game Info: This method can be used to access the metadata files of all games managed by the Game Manager Consumed Services This section describes the services that the Game Manager requests from the other ALFRED components. Personal Assistant: The Game Manager requires the PA to forward messages to and from the other ALFRED components (via the Game Manager s Component Communication Framework) and to and from games (via the Game Manager s Games and Devices Communication Framework). It also requires the PA to present game suggestions (triggers) to the user and to receive the user s feedback to these triggers. Health Monitor: The Game Manager accesses the Health Monitor in order for the following functionalities: o Game Configuration: The Game Manager queries the Health Monitor for health information prior to starting a game. The Game Manager may be able to use this information to initialize the game settings and to better adjust the game difficulty to the user s current (physical) condition. o Game Adaptation: Similar to the Game Configuration process, the Game Manager may also query the Health Monitor for health information while a game is running, especially to ensure that the user does not strain herself (e.g. while playing an exergame). This implies two things: on the one hand, the game in question needs to provide for the respective adaptation options (see section 4.9.1), and on the other, the Health Monitor needs to be able to deliver health-related information (e.g., the heart rate in real time. o Triggering: As described in section 4.9.1, triggering is the act of notifying the user of a situation that is well suited for playing a game. Among other things, 246 / 305

247 successful triggering requires detailed information about the state of the user and especially about her physical (and possibly also mental) condition. This kind of information can be provided by the Health Monitor and to this end, the Game Manager will query the Health Monitor for updated health data whenever the triggering process is initiated by the Game Manager. CADE: The Game Manager requires CADE for the following reasons: o Command Forwarding: One of ALFRED s core features is its full voicecontrollability (see DoW, page 2). While technically speaking, game extensions are not part of the ALFRED system itself, voice-controllability is also desirable for these games in order to keep the user experience coherent, at least in those cases where voice input (and output) is meaningful and achievable. To this end, the Game Manager requires CADE to forward commands (such as left, right and shoot ) when successfully interpreted from the user s utterance while a game is active. Certain commands may also be acted upon by the Game Manager itself (such as end game ). o User Feedback: Similar to receiving and forwarding speech input, CADE is also capable of transforming text into speech output. Both the Game Manager and game extensions may rely on this feature to deliver feedback to the user, when appropriate (i.e., if the user does not suffer from hearing impairments). ALFREDO Marketplace: There are three reasons why the Game Manager needs to communicate with the ALFREDO Marketplace: o Installation of new games: The Game Manager needs to be informed about the installation of new games onto the user s device. This is achieved by sharing the game s respective metadata file with the Game Manager. The exact process of how this sharing takes place needs to be decided, as pointed out in section One option is that the Marketplace component manages additional metadata files that are associated to extension APKs and that are forwarded directly to the Game Manager component when the user downloads games from the Marketplace. o Recommendations: As pointed out in section 4.9.1, the Game Manager supports two different suggestion mechanisms, namely triggering and recommendations. For the latter type, the Game Manager needs to be able to query the Marketplace for all games of a specific type (e.g. Multiplayer Exergames ) and then receive a list of all games that match these search criteria. A much more sophisticated recommendation system would be possible, if the Game Manager could also receive the metadata description files of all the games in question from the ALFREDO Marketplace on request to be able to understand the properties of the respective games. See section o Usage history: The third reason for the Game Manager to communicate with the ALFREDO Marketplace is to share information about a game s usage history and player performance. Anonymized and aggregated, this kind of information can be used by the Marketplace itself to provide a much more sophisticated rating system for games than the well-known five-star user feedback system. The exact nature of information shared is still open to discussion and obviously, privacy concerns should be included. 247 / 305

248 Personalization Manager: The Personalization Manager holds information about the user s characteristics and preferences. The Game Manager requires this information for the following functionalities: o Game Configuration: The Game Manager queries the Personalization Manager for user-related context information prior to starting a game. The Game Manager requires this information to be able to adjust the settings of a game, for instance by taking into account a user s sight or hearing impairments when setting up the game s user interface. To this end, the Game Manager needs to access user data through the Personalization Manager whenever a game is being started. The more specific the information about the user provided by the Personalization Manager, the better the Game Manager can adapt a game to the individual player. This also requires the game extension to provide for the required configuration options (see section 4.9.1). o Triggering: As described in section 4.9.1, triggering is the act of notifying the user of a situation that is well suited for playing a game with the intention of increasing the usage of the serious games provided. Among other things, this can contribute to therapy compliance, when the regular usage of certain applications is advised by care takers. Successful triggering requires detailed information about the state of the user (where is she, how is she feeling, what is she doing), the state of her environment, about her application usage history and performance, her personal preferences and characteristics, and about her time schedule. The two latter bits of information can, at least in part, be provided by the Personalization Manager and to this end, the Game Manger will frequently query the Personalization Manager for the updated user profile. Event Manager: The Event Manager keeps track of upcoming events that may be of interest to the user, but holds no information about whether the user is actually planning to attend these. This kind of information is only available from the Personalization Manager. Due to this, the Game Manager does not interact with the Event Manager directly, but rather queries the Personalization Manager for calendar info. KIS: The Game Manager maintains two types of data: o Game Metadata: The Game Manager keeps track of the metadata files that are associated to each game installed on the device and that include detailed information about the characteristics of a game (see section 4.9.1). Over time, the Game Manager enriches these files with additional information about usage times and game performance. This information is required for refining both the game triggering and the game configuration processes. Additionally, some of the collected information may be forwarded to the ALFREDO Marketplace in order to help it make more sophisticated game recommendations (see above). Since the Game Manager holds only metadata files for the games currently installed, since these files will be very small in size, and since they will not contain sensible information, they may or may not be stored in the KIS, depending on performance and availability considerations that still need to be made. o Reasoning Information: The Game Manager has two reasoning modules. On the one hand, the Game Adaptation and Monitoring Entity (GAME) 248 / 305

249 4.9.7 Summary gathers information from various ALFRED components in order to meaningfully configure a game prior to its start and possibly also to adapt it during gameplay. On the other hand, the Suggestion Generator (SG) requires even more information about the player and her surrounding in order to decide, when she should be triggered for playing a certain game. To this end, both modules will access other ALFRED components, gather information about the player from all of these sources and then try to reason over these information bits. These player gaming profiles will contain private information about the user and so, they will not be stored locally on the device, but online in secure KIS buckets. Consequently, the Game Manager needs to be able to upload, download and modify these gaming profiles whenever it performs reasoning processes. The Game Manager component fulfills three main tasks: firstly, it holds and manages knowledge about the games currently installed on the user s ALFRED device. Secondly, it configures, adapts and monitors the games that the user plays. And thirdly, it tries to close the gap in between the two states game available, but not being played and game being played by frequently suggesting games to the user for playing ( triggering ). These tasks imply multiple research questions that need to be investigated in the second and third year of the ALFRED project among these are the definition of a metadata format to help describe the properties of games in a homogenous way, and the development of sophisticated triggering mechanisms that are capable of determining the right time as to when to best suggest a game to the user Knowledge and Information Storage The Knowledge and Information Storage (KIS) is the central point for all data in the ALFRED system. KIS abstracts different storage technologies to provide a unified storage service to other components. These services will be provided as a web services to any legitimate user of the ALFRED system. Since the ALFRED system will handle and process highly sensitive data (such as vital signs recorded by wearable sensors) data privacy and security is of the utmost importance. The KIS will provide complete separated storage areas as so called Data Buckets. Each Data Bucket can be utilized to create isolated isles of data. By using different Buckets for each user, the confidential data of one user is stored completely separated from the data of another user Major Design Decisions The focus of the KIS is to address the three important attributes which the data of the ALFRED system has. Firstly, the system provides data in great quantities with different background. Secondly, the overall data of the ALFRED system is diverse; it can be categorized as followed: User Profile Data - User relevant data which can be transformed directly to knowledge of a user. User Profile Data are semantic data helping to understand the user and the relations to other user and other available information. Examples for 249 / 305

250 such data are relationship to other users or entities likes and dislikes as well as data about usage history which can improve the accuracy of speech recognition and interpretation of the user. While the results and conclusions based on sensor data, such as the median heart rate is also categorized as profile data, the raw sensor data is categorized as Sensor Data. Sensor Data - The raw sensor data of the wearable sensors for a specific user. This category of data will be stored along with timestamps to create historical data of the constantly recorded vital signs of the end user of the ALFRED system. Payload Data Generic data, not fitting on one of the other categories, such as event data or third party app data. The third and most important attribute of the data in the ALFRED system is the sensitivity of the data due to the health related nature. In order to meet the requirements, the solution has to be thereby scalable, adaptable but also private. This will be fulfilled by storing the data in so called Data Buckets. The data of each Data Bucket can be stored distributed over different kind (adaptable) of any number (scalable) of databases while optionally encrypt (private) the data stored. In addition, each Data Bucket will be an isle for its own boosting the privacy of the data even further. To allow third party developer as well as developer of the ALFRED system the access to the storage with simplicity, the data will be stored encapsulated as different Data Types. The KIS will offer simple CRUD (Create, Read, Update, Delete) operations for all of these Data Types e.g., returning values of a data set or updating properties of a data entry. Additionally, the KIS will provide more advanced query capabilities based on specific Data Types. As different Data Types have different requirements. For example, storing large amounts of binary data files requires optimal data throughput while a semantic database needs to enable graph-based queries, but data throughput is a neglectable factor. Consequentially, several technologies will be utilized to support the different Data Types. Each end user of the ALFRED system will have three Data Buckets to store the user specific data. Each of these Data Buckets has a different Sensitivity Level. This will allow a balance between data privacy and usability. Private data is only accessible for the owner of the data. The data can only be access by the third party applications if explicitly allowed. The data will be not available for the ALFRED system. Protected data is accessible by the ALFRED system to work properly. The data can be made explicitly available for third party applications. Internal data is accessible by the ALFRED system as well as all applications of the ALFRED ecosystem including any third party applications of the ALFREDO marketplace. The end user will have total control over his data by defining the sensitivity level of his data. The Sensitivity Level of the Buckets will be implemented with Access Control List (ACL). This separation of data in different Data Buckets in combination with the SSO solution (see section ) will ensure the privacy and security of the user data. Besides the user data, every actor of the ALFRED system can create Data Buckets in order to store data and utilize the ACL to specific exactly which other user or user groups can access their Bucket. One component may use several different Buckets and may specify their access rights (Denied, Read, Write, Super, see also section ) to share data with other components 250 / 305

251 Each component may create multiple Buckets for storing data, which are fully separated and not influenced by activities of other Buckets. In order to handle the (before mentioned different Data Types) in the best way, three different concepts to store data are foreseen, each of them will utilize a different technology: Semi-Structured will be used to store typical data in a document-oriented way without a fixed data schema. It is usually referred to as NoSQL (Not only Structured Query Language) storage and may be realized by technologies such as CouchDB or Apache Cassandra. A typical data entry in this storage will have an ID and a set of key-value entries, sometimes being hierarchical. Binary Data will allow a file-centric storage for binary data. It may be used to, e.g., store videos, PDFs or any other type or binary data. Queries will be based on the file name or ID, e.g., by requesting the content of document brochure.pdf. Potential base technologies include Amazon S3 or (distributed) file systems. Semantic Data will allow the storage of semantic information. Queries can be based on a semantic query language such as SPARQL. Possible base technologies include Jena or Sesame Technology Comparison For the realization of the KIS component, it is necessary to identify adequate storage technologies to store the different Data Type binary, semi-structured and semantic data. The assessment of these data storages will be carried-out independently in the following sections, but each one shares a basis for the criteria for the technical specification (see Table 101). Table 101: KIS - Shared Criteria for Technical Specification Storage Technologies Parameter Importance Scalability ++ Since ALFRED may need to manage a large amount of service data that will grow continuously, it is necessary to store the increasing amount of data in an efficient way. CRUD Operation Support ++ CRUD stands for create, read, update and delete and forms the base operations of any Database Management System (DBMS). It should be supported by all base technologies. Response Time ++ Speed of writing or reading data from the data storage varies per data storage system used. So it is a very important decision criterion about choosing the underlying software/technology for the data storage. Open Format Compatibility + The used data storage systems must be able to be used in different environments and by different components. As such, an Open Data format has to be chosen to transfer the queries and data between the data storage and the ALFRED components. Costs for Data ++ From an economic point of view, the costs for the data storage should be included in the selection decision, 251 / 305

252 Storage especially when considering cloud-based storages as some are fully managed and the usage of them is not free of costs. Cloud Compatibility + Not all of the existing data storage systems are absolutely suitable to work within a cloud-based system. Therefore it is pivotal whether the chosen systems support it or not. Note: The selection in the following subsections is based on the different Bucket Types (semi-structured, binary and semantic). For managing those data types, a lot of proven technologies exist. For example, there are a lot of different approaches for storing structured information in relational databases. As such, the following selection will compare only the 4-6 most promising technologies for each area in order to keep the document sharp and short Semi-Structured Data Storage Technologies Semi-Structured Data can be used to store data in a document-oriented way without a fixed data schema. It is often referred to as NoSQL (Not only Structured Query Language) storage. A typical data entry in this storage will have an ID and a set of keyvalue entries, sometimes being hierarchical. The following databases can be utilized to store Semi-Structured Data: Amazon DynamoDB 43 and SimpleDB 44 are NoSQL database services. They are easy to use and have a very good scalability. In comparison to SimpleDB, DynamoDB is faster, more flexible and there are no restrictions to the capacity. For this reason, DynamoDB will be used for further comparisons. The core idea is based on distributed hash tables to ensure a high availability as well an incremental scalability. As an externally hosted solution, the use of DynamoDB will lead to additional cost. Microsoft Azure Table Storage Service 45 is a NoSQL database service. It serves access over a RESTful interface or libraries for several programming languages such as.net, Java and PHP. It allows having multiple values for an attribute; the attributes are differentiated by a timestamp, allowing the storage of temporal data. As an externally hosted solution, the use of the Azure Table Storage will lead to additional cost. MongoDB 46 is schema-less open source database that is based on documents. The documents are represented internally with the help of the BSJON specification, which leads to a good performance. MongoDB is written in C++ and is available for Windows, Linux, OS X and Solaris. It serves libraries for many programming languages such as.net, C++, Java, PHP. It contains a master-slave replication mechanism and can be run on Microsoft Azure or own hosted servers and is a costfree solution. MongoDB is a good option for applications that require operation intelligence, flexibility in data management and applications that focus on content / 305

253 such as event logging, metadata management, inventory management, product catalogs and ecommerce applications. Key features of MongoDB include indexing, ad-hoc queries, replication, load balancing, auto-sharding, MapReduce jobs and high availability. Apache CouchDB 47 is a document-based database that can be accessed by a RESTful interface. It is written in Erlang and has a plug-in-architecture, which allows adding extensions. It contains a master-master merge replication mechanism. It can be hosted on own servers to avoid usage costs. CouchDB is a good option for applications that require aggregation of frequently changing data such as contacts, invoices, receipts, etc. Key features of CouchDB include on-the-fly document transformation, real-time change notifications, high availability, partition tolerance, eventual consistency, ACID semantics, MapReduce jobs, master set-ups and automatic conflict detection. Apache Cassandra 48 is an open source, distributed database which can be considered as a hybrid of key-value and column oriented nature. Cassandra is a good option for applications that deal with mission critical data and require failure tolerance and high write throughput while not sacrificing read efficiency such as session storage, content management, profiles, preferences, etc. Cassandra run on top of large amount of commodity servers, offering high availability, low latency for operations and no single point of failure. The key features of Cassandra include linear-scale performance, ease of data storage and distribution, elastic scalability for read/write operations, fault tolerance and simplicity in its configurability. In Table 102, the comparison of the before listed technologies for the storage of the Semi-Structured Data is made. Table 102: KIS - Comparison of Technologies for Semi-Structured Data Storage Parameter Importance Amazon DynamoDB Microsoft Azure Table MongoDB Apache CouchDB Apache Cassandra Generic Criteria Up-to- Datedness Stability Extensibility & Open Source / Standards Familiarity Performance / 305

254 Interoperability License Proprietary Proprietary GNU AGPL v3.0 (drivers: Apache2.0) Apache 2.0 Apache 2.0 Specific Criteria Scalability CRUD Operation Support Response Time Open Format Compatibility Costs for Data Storage Cloud Compatibility Yes Yes Yes Yes Yes Semantic Data Storage Technologies Semantic Data will allow the storage of semantic information. Queries can be based on a semantic query language such as SPARQL. The following technologies are considered to store the semantic data: Sesame 49 is an open source de facto standard framework for RDF data. Its supports a variety of different storage device due to a generic architecture, which abstracts the storage device layer, called SAIL (Storage And Interface Layer). It runs in a Java virtual machine and supports the following relational DBMS to store its data: PostgreSQL, MySQL, Microsoft SQL Server or Oracle. Sesame supports two query languages, SeRQL and SPARQL. As an open source product, Sesame is free of charge and can be hosted on any server running Java. Virtuoso 50 is a multi-model cross-platform data server. Noteworthy of Viruoso is that it stores its data in tuples. This allows also RDF data management with SPARQL support. Successfully used in various projects and products, this data server can store different types of data. As it is cross-platform and a free community edition is provided, it can be hosted on an own server. AllegroGraph 51 is a commercial RDF database. It exists as a free version with a limitation of 5 million triples. It runs on Windows, Linux and OS X and serves / 305

255 libraries for several programming languages including C# and Java. So it can be hosted on local server to reduce the cost of the storage system. Jena 52 is an open source RDF framework. It supports SPARQL as query language. It is very similar to Sesame with the exception that it supports a better support for reasoning, but for this reason the scalability suffers, so that Sesame is the better choice in case of a large amount of data. For data storage, it can use various storage solutions like SQL databases. As an open source product, it can be used free of charge and installed on local servers. BrightstarDB 53 is a schema-free RDF store for the.net platform. It supports SPARQL 1.1 and OData and it is ACID (Atomicity, Consistency, Isolation, and Durability) compliant. It can be hosted on a local Windows server and is downloadable for free. In Table 103, the comparison of the before listed semantic data storages is made. Table 103: Comparison of Technologies for Semantic Data Parameter Importance Sesame Virtuoso AllegroGraph Jena BrightstarDB Generic Criteria Up-to-Datedness Stability Extensibility & Open Source / Standards Familiarity Performance Interoperability License BSD 3- Clause License GPLv2 and proprietary Proprietary Apache 2.0 MT License Specific Criteria Scalability CRUD Operation Support Response Time / 305

256 Open Format Compatibility Costs for Data Storage Cloud Compatibility No No No No No Binary Data Storage Technologies Binary data contains data stored in files such as documents, images or configuration files of applications. For that reason, a technology is needed which offers an easy to use and scalable storage. For storing binary data, the following technologies are compared: Amazon Simple Storage Service (S3) 54 is a key-value storage which is accessible through web service interfaces like REST and SOAP. Amazon provides scalability, high availability and promises an availability of 99.99%. It is a fully managed and externally hosted service and so the usage would lead to additional cost for the project. Microsoft Azure Blob Storage Service 55 offers a service to store large binary files in the Cloud. All stored files are replicated automatically. The storage is available via web service interfaces. The usage is not free of charge since this is a fully managed and hosted solution. A File Server is a computer which provides a shared access to storage resources. It is attached to a network and accessed by attached workstations. It could be installed in a dedicated or in a non-dedicated manner. In the first case, the dedicated server is specially configured as file server and does not offer any other functionality. In the second case, the server is used in parallel for other tasks. This can lead to worse performance. There are several ways and protocols to access the data of a file server regardless of the manner it is installed, e.g., FTP, SFTP, or HTTP. As a technology and not a product, this is free of charge and can be hosted externally or internally. In Table 104, the comparison of the before listed binary data storages is made. Table 104: KIS - Comparison of Technologies for Binary Data Storage Parameter Importance Amazon S3 Microsoft Azure Blob Storage Service Simple File Server Generic Criteria Up-to-Datedness / 305

257 Stability Extensibility & Open Source / Standards Familiarity Performance Interoperability License Proprietary Proprietary Technology - specific Specific Criteria Scalability CRUD Operation Support Response Time Open Format Compatibility Costs for Data Storage Cloud Compatibility + Yes Yes Technology - specific Technology Selection After comparing the technologies in the previous section, the selected technology for each data backend is explained in this section Semi-Structured Data Storage MongoDB was selected as semi-structured data storage, because it is very stable and has a good runtime performance. It is internally in use by at least one project partner that is involved in the development of the KIS. Thus, it is well-tested and the necessary knowhow is already available. MongoDB is an open source solution and uses the GNU Affero General Public License (AGPL), a non-infecting license. It is available for Windows, Linux, OS X and Solaris and drivers exist for many programming languages. The number of drivers continues to grow, because the community develops new ones for further programming languages. It can be run on its own server, in its own private cloud or on Microsoft Azure as a public cloud. The database supports replications by itself, so that the synchronization is fully integrated. 257 / 305

258 Semantic Data Storage Sesame was selected to store semantic data, because it is a de-facto standard to store RDF-based data. It works with several relational DBMS and is platform independent. It has a better performance than Jena for large amounts of data and a better stability then BrightstarDB. It is open source and uses the GNU Lesser General Public License (LGPL), a non-infecting license Binary Data Storage Amazon S3 was selected as binary storage, because it offers a good interoperability through standardized interfaces like REST and SOAP. It offers high availability and scalability. The account on the services is performed in a pay-as-you-use manner and thus there are no up-front costs for initial hardware purchase. Also, through the managed service, costs for storage extensions and administrative work can be avoided, which is a big advantage over a self-hosted free network storage system. Furthermore, it is a broadly established solution for binary data storage and is well documented and features a large community Component Structure Overview Figure 20 provides an overview of the KIS with the selected technologies in this chapter. Each Data Bucket can contain Data Objects of the as required identified Data Types. For the End User three different Data Buckets exists. Each ALFRED app or component can create additional Data Buckets to store additional data. 258 / 305

259 mongodb Sesame AWS S3 User Data External Databases AES encrypted End User Data Buckets Private Protected Internal Storage Wrapper Nexus Cloud Storage Management Semi Structured Data Bucket Data Type Objects Binary Semantic Access Control List Facade Internal Database AES encrypted SUPER WRITE READ DENIED Users/Apps Web Services Figure 20: KIS - Component Overview of the Knowledge and Information Storage Encryption In distributed storage solutions the owner of the data does not always controls the physical access to the hardware the data is stored upon. To add another layer of data privacy the KIS will encrypt all used databases. In cases where this is not possible the data stored in the database will be encrypted instead. This is the case for the binary storage solution AWS S3. For the encryption AES-256 (256-bit Advanced Encryption Standard) will be used. AES is the successor of DES (Data Encryption Standard). AES was standardized in 2001 after a 5 year review. The AES algorithm (Rijndael-Algorithm) is currently one of the most popular algorithms used in symmetric key cryptography. It is also the gold standard encryption technique; many security-conscious organizations actually require that their employees use AES-256 for all communications. AES is FIPS (Federal Information Processing Standard) certified and there are currently no known non-brute-force direct attacks against AES. In fact, AES security is strong enough to be certified for use by the US government for top secret information. During the start-up of the Cloud Storage of the KIS the passphrase must be passed to the system. The passphrase is used to encrypt the Internal Database. The Internal Database stores the passphrases and salts for the encryption of the External Databases Access Control List Each Data Bucket will be protected by an Access Control List (ACL). By default, only the owner of a Data Bucket has access to his Data Bucket. With the ACL the owner takes control which data can be accessed by whom. The access control of specific storage backends will be abstracted so that developers do not have to care about system 259 / 305

260 peculiarities. With this system, it will be possible to provide an access control even for storage types which do not provide such functionality on the required granularity. The following Access Rights will be supported: NotSet used to delete an AccessRight Denied used to deny a user or group any access to a bucket Read used to allow a user or group to read the contents of a bucket Write used to allow a user or group to read and write the contents of a bucket Super used to allow a user or group the same rights as the owner. This includes the right to grand or restricts access rights to the Bucket as well as to delete the Bucket Any entity can be used as identifier to receive an Access Right. The authentication of a user or his membership to a user group has to be validated during the access to the KIS (see ) Interfaces The services of the KIS will be provided as web services as RESTful interfaces (described in Section ) as well as a Java API for Android (described in Section ) Java Interfaces The Java interfaces act as wrappers for the RESTful interfaces (see Section ). They provide a convenient way to access the KIS for Android and Java developers Create Bucket For the creation of Buckets, the API provides the method createbucket. The method has one parameter. The user defined ID for the Bucket. The ID must be unique in the context of the user. Parameters: bucketid: A user defined ID for the bucket. The ID must be unique in the context of the user. Return Value: A bucket object, representing the created bucket. Error Handling: In case of an error, a null-value is returned. Remarks: In Listing 126, the signature of the method for create bucket is shown as well as an example for the usage of this method. The exemplary usage of the method at the bottom of Listing 126 will create a new Bucket with the ID string of the constant BUCKET_TEST_ID. If the API call is successful a bucket object will be returned, otherwise null. 260 / 305

261 Listing 126: KIS API Method Signature for Creating a Bucket and the Usage of this Method /** bucketid, a user defined ID for the bucket. The ID must be unique in the * context of the user on success a Bucket object, otherwise null */ public Bucket createbucket(string bucketid) //Creates a semi-structured bucket under with the id BUCKET_TEST_ID Bucket bucket = api.createbucket(bucket_test_id); Delete Bucket For the deletion of Buckets, the API provides the method deletebucket. The method has one parameter, the ID of the Bucket identifying the Bucket, which shall be deleted. Parameters: bucketid: The ID of the bucket identifying the Bucket to be deleted. Return Value: True on success Error Handling: In case of an error false is returned Remarks: All data saved in the Bucket will be deleted with the Bucket. For this reason, only the owner and user with the AccessRight Super (see also section ) can delete a Bucket. In Listing 127, the signature of the method to delete a Bucket is shown as well as an example for the usage of this method. Listing 127: KIS API Method Signature for Deleting a Bucket and the Usage of the Method /*** bucketid, the ID of the bucket which shall be deleted true on success */ public boolean deletebucket(string bucketid) //Deleted the bucket with the ID BUCKET_TEST_ID api.deletebucket(bucket_test_id); The exemplary usage of the method at the bottom of Listing 127 deletes the bucket with the provided ID. If the API call is successful true is returned, otherwise false. 261 / 305

262 Add Access Rights for User To grant users access rights for a specific Bucket the API provide the method addaccessright. The method has three parameters, the ID of the bucket to which the access rights shall be granted, an ID, which identifies the user or a group of users, and third the right, which shall be granted. Parameters: bucketid: The ID of the bucket to which the right will be granted. id: The user or group ID to whom the access right should be granted. The value NotSet will delete the access right. right: The access right which will be granted to the user. Return Value: True on success Error Handling: In case of an error, false is returned Remarks: Only the owner of the bucket or a user with the Super access right can add access rights to a bucket. In Listing 128, the signature of the method to add access rights for a user is shown as well as an example for the usage of this method. Listing 128: KIS API Method Signature to Grant Access Rights to a User for a Bucket and the Usage of this Method /*** bucketid, the ID of the bucket to which the right will be granted id, the user or group ID to whom the access right should be granted * the value NotSet will delete the access right right, the right to grand to the user or group for the bucket true on success */ public boolean addaccessright(string bucketid, String id, Rights right) //adds the Read-AccessRight to the specific bucket for the specific user boolean success = api.addaccessright(bucket_test_id, SECOND_USER_NAME, Rights.READ); The exemplary usage of the method at the bottom of Listing 128 grants the access right READ to the specific user for the bucket with the provided ID. If the API call is successful, true is returned, otherwise false. 262 / 305

263 Get Access Rights for User In order to retrieve the access rights for a specific user, the API provides the method getaccessrights. The method has one parameter, the ID of the user of whom the access rights shall be queried. Parameters id: The user or group ID of whom the access right should be queried. Return Value: An ArrayList of Right values Error Handling: In case of an error, the list is empty Remarks: None In Listing 129, the signature of this method is shown as well as an example of its usage. Listing 129: KIS API Method Signature to Get Access Rights for a User and the Usage of this Method /*** id, the user or group ID of whom the access right should be queried a list of Rights for the user or group ID */ public ArrayList<Rights> getaccessrights(string id) //Retrieves the access rights for the specific user ArrayList<Rights> rights = api.getaccessrights(second_user_name); The exemplary usage of the method at the bottom of Listing 129 retrieves the access rights for the user with the provided ID. All found access rights are stored in the list CRUD-Operation Create To create a new data object in a bucket, the API provides the method createbucket. As example for a data object for this and all following examples, which require a data object Listing 130 shows a factory method. This method creates an instance of the test class MyTestClass. This class has valid JAXB annotations as well as a corresponding XSD file (see Listing 131). 263 / 305

264 Listing 130: KIS Factory Method to Create a Test Data Object //Creates an instance of MyTestClass. A class with valid JAXB-Annotations and an apt XSD file private MyTestClass gettestclass() { MyTestClass test = new MyTestClass(); test.settestattributeboolean(true); test.settestattributeint(int_before); test.settestattributestring(string_before); return test; } Listing 131: KIS XSD for a Test Class <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs= elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="mytestclass" xmlns=" <xs:complextype > <xs:sequence> <xs:element name="testattributestring" type="xs:string" minoccurs="0" /> <xs:element name="testattributeint" type="xs:int" minoccurs="0" /> <xs:element name="testattributeboolean" type="xs:boolean" minoccurs="0" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> The crudcreate method of the API has two parameters. The first identifies the bucket in which the data object shall be stored. The second is the data object to be stored in the bucket. Parameters: bucketid: The ID of the bucket in which the data object shall be created. object: A generic (Java) object which shall be stored in the bucket. Return Value: True on success Error Handling In case of an error, false is returned Remarks: The Java interface manipulates with the CRUD-operations generic Java objects. 264 / 305

265 In Listing 132, the signature of the method for the CRUD-operation crudcreate is shown as well as an example for the usage of this method. Listing 132: KIS API Method Signature for the CRUD-Operation crudcreate and the Usage of this Method /*** bucketid, the ID of the bucket in which the data object shall be created object, the data object which shall be stored in the bucket true on success */ public boolean crudcreate(string bucketid, DTO object) //Creates test data MyTestClass testdata = gettestclass(); //Call of a Helper Method. The Helper method is a factory method which creates //a DTO object. The Following arguments are required: // -the URI to a valid XSD file describing the class of the object // -the object instance itself // -the package name of the class of the object DTO test = Helper.GenerateGenericObject("res/TestSchema.xsd", testdata, "junit.test.vo"); //Creates the data object "test" in the (with the ID) specific bucket boolean success = api.crudcreate(bucket_test_id, test); The exemplary usage of the method at the bottom of Listing 132 will store the created test data object in the bucket for semi-structured data with the ID BUCKET_TEST_ID. If the API call is successful, the variable success is set to true CRUD-Operation Read To retrieve existing data object from the Cloud Storage component, the API provides the method crudread. For this, a query object is necessary. This object must be of the same type as the data objects that should be retrieved. As mentioned before, for this the factory method shown in Listing 130 will be used. This method creates an instance of the test class MyTestClass. This class has valid JAXB annotations as well as a corresponding XSD file (see Listing 131). The crudread method of the API has three parameters. The first identifies the bucket from which the data objects shall be retrieved. The second is the query data object used to find the data objects in question. The last parameter is for the Java object class of the objects that shall be retrieved. Parameters: bucketid: The ID of the bucket from which the data objects shall be retrieved. object: A generic (Java) object as query with attributes set to search for in the bucket. Return Value: An ArrayList of objects which have matched the attributes of the query. 265 / 305

266 Error Handling: If no matching data object is found, the returned list is empty. Remarks: The Java interface manipulates with the CRUD-operations generic Java objects. In Listing 133, the signature of the method for the CRUD-operation crudread is shown as well as an example for the usage of this method. Listing 133: KIS API Method Signature for the CRUD-Operation crudread and the Usage of this Method /*** bucketid, the ID of the bucket from which the data objects shall be * retrieved object, query object with attributes set to search for in the bucket a ArrayList of object which matches the attributes of the query object */ public ArrayList<DTO> crudread(string bucketid, DTO object) //Creates test data to query for data objects in the cloud storage MyTestClass testquery = new MyTestClass(); //Changes the integer attribute of the test data object testquery.settestattributeint(int_after); //Call of a Helper Method. The Helper method is a factory method which creates //a DTO object. The Following arguments are required: // -the URI to a valid XSD file describing the class of the object // -the object instance itself // -the package name of the class of the object DTO test = Helper.GenerateGenericObject("res/TestSchema.xsd", testquery, "junit.test.vo"); //Creates a list for the results of the CRUD operation ArrayList<MyTestClass> list = new ArrayList<MyTestClass>(); //Retrieve the data objects from a specific bucket matching the query object ArrayList<Object> resultlist = api.crudread(bucket_test_id, test, testquery.getclass()); //Cast the generic result list of objects to the test class for (Object object : resultlist) list.add((mytestclass) object); The exemplary usage of the method at the bottom of Listing 133 creates a query object, which is used for the API call. The result list of objects is cast to the expected type. If no matching objects could be found in the specific bucket the result list is empty. 266 / 305

267 CRUD-Operation Update To update attributes of existing data object in the Cloud Storage component, the API provides the method crudupdate. For this, a query object is necessary. This object must be of the same type as the data objects that should be updated as well as a data object with new values for the objects in question. As mentioned before, for this the factory method shown in Listing 130 will be used. This method creates an instance of the test class MyTestClass. This class has valid JAXB annotations as well as a corresponding XSD file (see Listing 131). The crudupdate method of the API has three parameters. The first identifies the bucket in which the data objects shall be updated. The second is the query data object used to find the data objects in question. The last parameter is the data object with the new values for the found data objects in the Cloud Storage component. Parameters: bucketid: The ID of the bucket from which the data objects shall be retrieved. query: A DTO object, e.g., a generic (Java) object, with attributes set to identify the data objects to be updated. newvalues: A DTO object, e.g., a generic (Java) object, with attributes set to be updated. Return Value: True on success Error Handling: In case of an error, false is returned Remarks: The Java interface manipulates generic Java objects. In Listing 134, the signature of the method for the CRUD-operation crudupdate is shown as well as an example for the usage of this method. 267 / 305

268 Listing 134: KIS API Method Signature for the CRUD-Operation crudupdate and the Usage of this Method /*** bucketid, the id of the bucket in which the datao bjects shall be updated object, query object with attributes set to identify the data objects to * updated newvalues, a data object with new values true on success */ public boolean crudupdate(string bucketid, DTO query, DTO newvalues) //Creates test data to query for data objects in the cloud storage MyTestClass testquery = gettestclass(); testquery.settestattributestring(null); //Creates test data with updated valued MyTestClass testdata = gettestclass(); testdata.settestattributeint(int_after); testdata.settestattributestring(string_after); //Double call of a Helper Method. The Helper method is a factory method which creates //a DTO object. The Following arguments are required: // -the URI to a valid XSD file describing the class of the object // -the object instance itself // -the package name of the class of the object DTO query = Helper.GenerateGenericObject("res/TestSchema.xsd", testquery, "junit.test.vo"); DTO newvalues = Helper.GenerateGenericObject("res/TestSchema.xsd", testdata, "junit.test.vo"); //Updates all attributes of objects found with the query object with the //attributes of the newvalues object boolean success = api.crudupdate(bucket_test_id, query, newvalues); The exemplary usage of the method at the bottom of Listing 134 creates a query object and an object with new values for the data objects which shall be updated in the Cloud Storage component. If the API call is successful, true is returned, otherwise false CRUD-Operation Delete To delete data objects in the Cloud Storage component, the API provides the method cruddelete. For this, a query object is necessary. This object must be of the same type as the data objects that should be. As mentioned before, for this the factory method shown in Listing 130 will be used. This method creates an instance of the test class MyTestClass. This class has valid JAXB annotations as well as a corresponding XSD file (see Listing 131). The cruddelete method of the API has two parameters. The first identifies the bucket from which the data objects shall be deleted. The second is the query data object used to find the data objects in question. Parameters: 268 / 305

269 bucketid: The ID of the bucket in which the data object shall be deleted. Query: A generic (Java) object with attributes set to identify the data objects to be updated. Return Value: True on success Error Handling: In case of an error, false is returned Remarks: The Java interface manipulates generic Java objects. In Listing 135, the signature of the method for the CRUD-operation cruddelete is shown as well as an example for the usage of this method. Listing 135: KIS API Method Signature for the CRUD-Operation cruddelete and the Usage of this Method /*** bucketid, the ID of the bucket in which the data object shall be deleted object, query object with attributes set to identify the data objects to * be deleted true on success */ public boolean cruddelete(string bucketid, DTO object) //Creates test data to query for data objects which shall be deleted MyTestClass testquery = new MyTestClass(); //Call of a Helper Method. The Helper method is a factory method which creates //a DTO object. The Following arguments are required: // -the URI to a valid XSD file describing the class of the object // -the object instance itself // -the package name of the class of the object DTO query = Helper.GenerateGenericObject("res/TestSchema.xsd", testquery, "junit.test.vo"); boolean success = api.cruddelete(bucket_test_id, query); The exemplary usage of the method at the bottom of Listing 135 creates first a data object with attributes to identify the data objects in the Cloud Storage component, which shall be deleted. If the API call is successful, true is returned, otherwise false. 269 / 305

270 Execute Query on Bucket In order to execute a generic query to utilize specific features of one the database backends, the API provides the method executequery. The method has two parameters, the bucketid identifying the bucket on which the query should be executed and the query itself as a string. Parameters: bucketid: The ID of the bucket on which the query will be executed. query: The query as string. Return Value: The result of the query as string. Error Handling: In case of an error, a null value is returned Remarks: The queries will not be parsed nor evaluated before executing, allowing the possible destruction of all data in a database. In Listing 136, the signature this method is shown as well as an example of its usage. Listing 136: KIS API Method Signature to Execute a Generic Query on a Specific Bucket and the Usage of this Method /*** bucketid, the ID of the bucket on which the query will be executed query, the query as string the result of the query as string */ public String executequery (String bucketid, String query) //Retrieves the result of a generic query for the specific bucket String result = api.executequery(bucket_test_id, QUERY_STRING); The exemplary usage of the method at the bottom of Listing 136 retrieves the access rights for the user with the provided ID. All found access rights are stored in the list RESTful Interfaces In order to describe the RESTful interface, each provided service is described in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable) Create Bucket The RESTful interface Create Bucket (Table 105), creates a new Bucket for the user. A Bucket is unique in the context of the user, who created it. 270 / 305

271 Table 105: KIS RESTful Interface Create Bucket Create Bucket Creates a new Bucket for the user. A Bucket is unique in the context of the user, who created it. Request Request URL POST Resource Parameters bucketid Required string Id of the Bucket. Example: testid Response HTTP Status Code Value 201 Bucket created 409 Bucket exists already 502 Database error Delete Bucket The RESTful Interface Delete Bucket (see Table 106), deletes the specific Bucket for the user. This will also deletes all data stored in the Bucket. Only the owner of the Bucket or a user with access right Super can delete a Bucket. 271 / 305

272 Table 106: KIS RESTful Interface Delete Bucket Delete Bucket Deletes the specific Bucket for the user. This will also deletes all data stored in the Bucket. Only the owner of the Bucket or a user with access right Super can delete a Bucket. Request Request URL DELETE Resource Parameters bucketid Required string Id of the Bucket. Example: testid Response HTTP Status Code Value 200 Bucket deleted 401 Insufficient rights 404 Bucket not found Add Access Right to Bucket The RESTful interface for Add Access Right (see Table 107), Modifies the ACL of a Bucket by adding a specific access right to a specific user. The following access rights are supported: NotSet used to delete an AccessRight Denied used to deny a user or group the any access to a bucket Read used to allow a user or group to read the contents of a bucket Write used to allow a user or group to read and write the contents of a bucket Super used to allow a user or group the same rights as the owner. This includes the right to grand or restricts access rights to the Bucket as well as to delete the Bucket Note: The ownership of a Bucket can t be modified. 272 / 305

273 Table 107: KIS RESTful Interface Add Access Right to Bucket Add Access Right to Bucket Modifies the ACL of a Bucket by adding a specific access right to a specific user. Request Request URL PUT PUT Resource Parameters bucketid Required string userid Required string right Required string Id of the Bucket Example: testid Id of the user to receive the access right Example: testuser Access right to be granted to the user Example: READ Response HTTP Status Code Value 200 Access right for user updated 201 Access right for user created 401 Insufficient rights 404 Bucket not found Remove Access Right for Bucket The RESTful Interface Remove Access Right for Bucket (see Table 108), modifies the ACL of a Bucket by removing: all access rights to the Bucket all access rights for a specific user to the Bucket all access rights of a specific kind to the Bucket 273 / 305

274 Table 108: KIS RESTful Interface Remove Access Right from Bucket Remove Access Right from Bucket Modifies the ACL of a Bucket by removing: all access rights to the Bucket all access rights for a specific user to the Bucket all access rights of a specific kind to the Bucket Request Request URL DELETE DELETE DELETE Resource Parameters bucketid Required string userid Optional string right Optional string Id of the Bucket Example: testid Id of the user to receive the access right Example: testuser Access right to be granted to the user Example: READ Response HTTP Status Code Value 200 OK 401 Insufficient rights 404 Bucket not found Get Access Right for Bucket The RESTful Interface Get Access Right for Bucket (see Table 109), get the access controls for a specific Bucket. The result can be filtered by user or access right. 274 / 305

275 Table 109: KIS RESTful Interface Get Access Right for Bucket Get Access Right for Bucket Get the access controls for a specific Bucket. The result can be filtered by user or access right. Request Request URL GET GET GET Resource Parameters bucketid Required string userid Optional string right Optional string Id of the Bucket Example: testid Filter by user Example: testuser Filter by access right Example: READ Response HTTP Status Code Value 200 OK 204 Entry not found 404 Bucket not found JSON Attributes list Optional list A list of JSON objects with id and right attributes. Both attributes are required for every object in the list. Example: [ ] { "id": "testuser", "right": "Read } CRUD-Operation Create The RESTful interface CRUD-Operation Create (see Table 110), executes a create operation on an existing Bucket. This will store the data of the transferred data object. The storage details are based on the Data Type of the transferred data object. 275 / 305

276 Table 110: KIS RESTful Interface CRUD-Operation Create Create Data Object in Bucket Executes a create operation on an existing Bucket. This will store the data of the transferred data object. The storage details are based on the Data Type of the transferred data object. Request Request URL POST Resource Parameters HTTP Parameters bucketid Required string objectid Required string datatype Required string object Required object Id of the Bucket. Example: testid Id of the data object. Unique in the context of the Bucket. Example: testobjectid Data Type of the transferred object. Example: JSON JSON object representing an object of the specified Data Type. Example: { "key": "mykey", "value": "TestValue" } Response HTTP Status Code Value 201 Object created 401 Insufficient rights 404 Bucket not found 409 Object with specific ID already exists in the Bucket CRUD-Operation Read The RESTful interface CRUD-Operation Read (see Table 111), executes a read operation on an existing Bucket. This will retrieve all data objects of a specific type matching the query object. The matching criteria s are based on the Data Type. 276 / 305

277 Table 111: KIS RESTful Interface CRUD-Operation Read Read Data Object from Bucket Executes a read operation on an existing Bucket. This will retrieve all data objects of a specific type matching the query object. The matching criteria s are based on the Data Type. Request Request URL GET Resource Parameters HTTP Parameters bucketid Required string objectid Required string datatype Required String query Required object Id of the Bucket. Example: testid Id of the data object. Unique in the context of the Bucket. Example: testobjectid Data Type of the transferred object. Example: JSON JSON object representing a query object for the specified Data Type. Example: { "key": "mykey"} Response HTTP Status Code Value 200 Object found 204 Object not found 401 Insufficient rights 404 Bucket not found 409 Object with specific ID already exists in the Bucket JSON Attributes list Optional list A list of JSON objects matching the query. Example: [ { "key": "mykey", "value": "TestValue } ] 277 / 305

278 CRUD-Operation Update The RESTful interface CRUD-Operation Update (see Table 112), an update operation on an existing Bucket. This will update all found data objects found with the query object in the Bucket with the provided values in the parameter. 278 / 305

279 Table 112: KIS RESTful Interface CRUD-Operation Update Update Data Object in Bucket Executes an update operation on an existing Bucket. This will update all found data objects found with the query object in the Bucket with the provided values in the parameter. Request Request URL PUT Resource Parameters HTTP Parameters bucketid Required string objectid Required string datatype Required string query Required object object Required object Id of the Bucket. Example: testid Id of the data object. Unique in the context of the Bucket. Example: testobjectid Data Type of the transferred object. Example: JSON JSON object representing a query object for the specified Data Type. Example: { "key": "mykey"} JSON object representing an object of the specified Data Type with attributes set, which will be updated in the data objects found with the query. Example: { "value": "OtherTestValue",} Response HTTP Status Code Value 200 Found objects updated 204 Object not found 401 Insufficient rights 404 Bucket not found CRUD-Operation Delete The RESTful interface CRUD-Operation Delete (see Table 113), executes a delete operation on an existing Bucket. This will delete all data objects of a specific type matching the query object. The matching criteria s are based on the Data Type. 279 / 305

280 Table 113: KIS RESTful Interface CRUD-Operation Delete Delete Data Object from Bucket Executes a delete operation on an existing Bucket. This will delete all data objects of a specific type matching the query object. The matching criteria s are based on the Data Type. Request Request URL Delete Resource Parameters HTTP Parameters bucketid Required string objectid Required string datatype Required String query Required object Id of the Bucket. Example: testid Id of the data object. Unique in the context of the Bucket. Example: testobjectid Data Type of the transferred object. Example: JSON JSON object representing a query object for the specified Data Type. Example: { "key": "mykey"} Response HTTP Status Code Value 200 Object deleted 204 Object not found 401 Insufficient rights 404 Bucket not found 280 / 305

281 Execute Generic Query The RESTful Interface Generic Query (see Table 114), executes a generic query on an existing bucket in the Cloud Storage. Table 114: KIS RESTful Interface Generic Query Information of an App Executes a generic Query in the Bucket based on the provided data type. Generic queries will not be tested and can thereby destroy all data in the Bucket. Request Request URL GET Resource Parameters bucketid Required string datatype Required string Id of the Bucket. Example: testid The Data Type to define on, which data objects the query will be executed. Example: semantic Response HTTP Status Code Value 200 OK 401 Insufficient rights 404 Bucket not found JSON Attributes result Required object Generic JSON object Consumed Services The KIS is designed as autonomous backed system with no need to consume other services expect for the SSO solution described in section Summary In this section, the Knowledge and Information Storage (KIS) was technically specified. During the technology selection (Section ), MongoDB, Sesame and Amazon S3 were selected to store different types of data. An abstraction of these specific storage systems will enable each component and each backend service to create a Data Bucket, which can store data as different Data Types without knowledge of the backend systems. 281 / 305

282 The access to a Bucket can be managed with an Access List Control (ACL) feature to share data with several actors of the ALFRED System. To manipulate the ACL, an interface is given, where rights can be added, removed and queried. So each actor can use the ACL to query the access rights for his Data Buckets. The management of Data Buckets and the dispatching of the according data to the backend systems will be handled by the KIS internally. According to this Specification, the following components have to be implemented: RESTful Interface to expose the Cloud Storage Façade to other ALFRED components Cloud Storage Facade to provide CRUD and query functionality Cloud Storage Backend with Access Control List feature Bucket Abstractors for the three mentioned Storage Backend Systems JAVA API for implementation ease, i.e., for the Android operating system The technical specification of the KIS is focused on data privacy, scalability, and ease of use. The Access Control Lists will give the opportunity to restrict access to data while the abstraction into buckets separates the data type concerns. To provide scalability, adaptability and privacy, the technologies were chosen carefully. 282 / 305

283 4.11 Web Portal The web portal offers visual browser access to all web UIs of the different ALFRED components. It acts as a single point of entry as well as a technical frame for all corresponding views. The components that present a web UI in the portal are the Health Monitor described in section 4.4, the ALFREDO marketplace expressed in section 4.6 and the Event Manager as seen in 4.8. Furthermore, the web portal is responsible for authentication and user profile management. For this, the portal s front end offers a UI to login, register and manage ALFRED users. On the server side, a secure backend takes authentication requests from the different ALFRED components for user verification Major Design Decisions The following sections describe the specific design decisions for the Web Portal that derive from the Architecture Definition and Functional Specification (deliverable D2.4) by addressing the existing visual web views as well as looking at the general technical demands for the client side web portal frame and the server backend Web Portal Frame The ALFRED web portal entry point is a web page that links to the other relevant views of the portal and has no other functionality in itself. Figure 21 shows a simple mockup of the page. Figure 21: Web Portal - Mockup of the Web Portal Home Page Standard controls lead to the respective areas and replace the page s main content with the new views. Global navigation exists at all times so that all main views are always accessible. Certain links are only visible for logged in users that are authorized to access the respective areas. The following main design decisions dictate the web portal frontend: 283 / 305

284 Compatibility: The ALFRED web portal has no special restrictions as to which devices are able to access it. It uses standard technologies that can be displayed in any modern browser on as many devices as possible. UI design reflects that a growing number of modern device allow touch gestures to access web page controls. Efficiency: The web portal is designed for efficiency. The page is clean and does not, for example, rely on unnecessary graphical eye candy. All visual components and controls are part of established standards and are present within lightweight web technologies. The focus lies on page performance, accessibility and ease of use. Service Quality: Due to the nature of the ALFRED project, all related components need to reach a certain standard regarding service quality. Established web technologies ensure the web portal s stability as far as this is reasonably possible and also help with ongoing maintainability. Data consistency is ensured by re-using all of the ALFRED component s REST APIs so that the portal is based on the same data as all other services. Modularity: The different views of the web portal are not dependant on each other. Each view encompasses its own functionality and could be used standalone. This fact allows easier development and maintainability as well as interchangeability. If, for any reason, a view needs to be reworked, it can be easily exchanged in the web portal frame. The modularity aspect is also utilised by the ALFREDO marketplace which is developed with a different technology than the rest of the portal (see section below). 284 / 305

285 Health Monitor View The Health Monitor part of the web portal consists of three subviews which handle the Health Profile, the Health Alarm and Health Analysis options as depicted in Figure 22. Figure 22: Web Portal - Mockup for the Web Portal Health Monitor View As defined in the Architecture Definition and Functional Specification (deliverable D2.4), the Health Profile area displays information related to the user s health data and includes tools for medical caregivers to define and review patient medical records, as well as configurations for controlling its health. The Health Alarm view is responsible for displaying information related to the alarms and includes tools for carers to define and configure anomaly detection rules and alarms. The Health Analysis view displays information related to measurement data and provides reporting and assessment tools. Passive data update: The Health Monitor relies on information where timing and updated data might be an issue. Data on web pages usually updates only when a manual refresh is requested. The portal s health monitor sections, once opened in a browser, provide automatic updates of the data on the view. Changes to a user s health data is published automatically. This way the section can be used as a passive monitor for ongoing changes Event Manager View The Event Manager Web portal view, in accordance to the functional specification, provides three sections as subviews as mocked in Figure / 305

286 Figure 23: Web Portal - Mockup for the Web Portal Event Manager View The subviews present the different UIs to search and create an event, to review event suggestions, or to browse events in the events knowledge base. The section to review events will only be visible to users which are logged in with reviewer privileges. The structure of all the Event Manager s subviews is a two layer page. The first layer presents a list of events as an overview while a second layer opens on single item selection and provides event details and functional controls for the selected item ALFREDO Marketplace View The app marketplace presents a special case in the web portal context. ALFREDO has a different complexity than the other views and has a corresponding dedicated Android mobile view which has to be completely consistent with the view accessible through the web portal. Due to this fact the marketplace web view is developed separately and with different technology. The technical specification for the marketplace web portal view can be found in section 4.6. The modularity of the web portal frame that is mentioned in section nevertheless allows the ALFREDO marketplace to be visually integrated into the web portal for a seamless transition between it and the other views User Management View The User Management view allows access to three subviews as shown in the mock-up in Figure / 305

287 Figure 24: Web Portal - Mockup of the User Management View All subviews of the user management area consist of form based web pages that directly represent the data objects in the ALFRED user buckets of the KIS as mentioned in the backend section The profile view shows the information on the currently logged in user and allows editing of non-permanent data. The administration area allows access to all user information and works as a simplified web view on the complete user database. Administrators can access, review or modify all user data here without the need for a separate database tool. The administration view is only accessible by logged in web portal users with administrator rights. The Create User control opens a form that allows registration of new users. This is usually done during the process where elderly people are newly registered for ALFRED, but it can also be accessed by web portal visitors that have no login. User registration is secured by a double opt-in process via validation Web Portal Backend On the non-visual server side, the web portal fulfils two important technical roles. First it acts as the backend for the web portal UI. Secondly it is responsible for user authentication for the whole ALFRED network. The functions in detail are: Web Server: In context of the web portal pages, the application server acts as the single access point that takes all incoming requests and delivers all responses back to the client. When the web portal communicates with APIs from other ALFRED components, e.g. to display event data, the web server takes the initial requests and routes them to the corresponding interfaces to preclude possible cross domain problems. Authentication Server: The web portal s authentication server acts as the central node to verify the user or the app behind requests. For this, the server provides an 287 / 305

288 API to receive user authentication tokens or secret application identifiers with a backend logic that determines whether the credentials are valid or not. Note that the web server and the authentication server are both described as part of the web portal backend because they exist and run on the same platform. Technically both servers are the same, but they are accessed via a different web resource. All server side components implement standard security measures and address the regular OWASP 56 concerns on web application security Technology Comparison The major design decisions for the web portal allow differentiated technology comparisons for client side and server side components as discussed in the following sections Web Portal Frontend Section already mentions the aspects under which the frontend design decisions were made. Table 115 adjusts the general technology comparison criteria from section for the web portal and adds additional specifics. Table 115: Web Portal - Adjusted Technology Selection Criteria for the Web Portal Frontend Parameter Importance Performance / Efficiency Stability / Service Quality Interoperability / Modularity / Client Compatibility ++ The web portal should run smoothly even on lower end devices and not rely on CPU or GPU intensive calculations or animations. Lower net bandwidth should be taken into account since the portal may be accessed from mobile devices. That implies that page size should be relatively small and bigger chunks of data should be lazy loaded. ++ The web portal has to be stable and also work with bad net connections as much as possible, so communication to a server should be minimized to the absolute necessary. The implementation for the web portal needs to be easily maintainable in case of errors or urgent feature requests. The underlying code base and used libraries should be easy to update in case of discovered security issues or other notable improvements. So the technology needs to be based on standards or generally be widely-used. The views data model needs to be consistent and has to represent the server side data as exact as possible. ++ The technology for the web portal has to run on any standard device without impeding the choice of input method (touch or mouse) or browser variant. No runtime environment besides the web browser itself should be required and plugins should not be necessary. The web portal technology should be able to integrate modules that are not coded with the exact same technology. Although different areas and views should be technical independent from 56 Open Web Application Security Project / 305

289 The relatively standard form based nature of most web portal views lead us to three main groups of technologies: each other so that development and maintenance can be split and is easier to handle and the portal allows future module upgrades in case of need. Interpreted language Web Frameworks: There are a wide number of frameworks that use interpreted programming language. Depending on the language selected, the most common are Rails that uses Ruby; CakePHP uses PHP and Django that uses Python: o Rails was the entrance of the MVC design pattern to the populace of developers, risen with version 2.0 in The current version is 4.1, released on April 8 th of There are different web servers for Rails apps, that provide different core features, but none of them is easy to configure. o CakePHP is a web framework similar to Rails, building on top of the MVC design pattern. The framework consists of many technical layers and is therefore prone to faults that can block the whole system in case of a minor error. o Finally, Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Django needs the usage of a WSGI 57 and is therefore not runnable on every web server available. Thus the used server needs to be highly configured due to the WSGI-extension. Django also underperforms in terms of performance due to the different layers of execution (Webserver WSGI module interpreted Python Code Database). Java Web Application Frameworks: Though there are numerous Java web application frameworks, the two most established ones for richer frontends are Struts and Java Server Faces. Both frameworks are well known and used in numerous enterprise scale web applications. The major version 2 releases of both frameworks are continuously maintained, updated and have an active community and good documentation. Java web applications in general encourage strict MVC architectures and make use of the Java Servlet API to deliver server generated web pages to a client. The result is clean code and consistent data. The biggest problem with java web application frameworks is customization and extensibility. Even though the source code is open source, adding custom functionality to the existing frameworks is very complex. Even well maintained and established add-on libraries, like Apache MyFaces or PrimeFaces for JSF, tend to produce errors during development that are hard to understand and fix. Since the differentiation between JSF and struts lie on a very detailed technical level that are of no relevance for the general selection, JSF is chosen for the comparison because of higher familiarity on the part of the project partners. JavaScript MVC Frameworks: JavaScript MVC frameworks have the advantage that JavaScript could be seen as the native language of the internet. No matter what technology or framework is used, nearly every single page on the web that 57 Web Server Gateway Interface / 305

290 does not utilize its own runtime environment, like Adobe Flash 58 or Microsoft Silverlight 59, is based on JavaScript. Even well-known web technologies like PHP render their client logic JavaScript before delivering to a client. JavaScript MVC frameworks code directly in JavaScript and do not use interpreters or page renderers to translate code for the client side. This has the big advantage that the code base stays in one single technological environment. All logic is natively coded for and directly executed in the browser. A client only needs to communicate with a server to exchange data that is stored in a server side database. In case of performance this means that lag in communication is reduced and time to render code into browser readable format is eliminated. Due to the general popularity of the pure JavaScript approach for web development over the last years, dozens of frameworks exits that, in theory, all achieve the same goal. For ALFRED only four candidates were taken into account during evaluation. This decision is based on dissemination, popularity, up-to-datedness, value proposition and documentation. ly those frameworks are: Backbone.js, AngularJS, Ember.js, and KnockoutJS. Since the differences between the frameworks lie on a very detailed technical implementation level, the choice for the ALFRED technology comparison falls on AngularJS. According to web statistics, Angular has the most active contributor community and better value proposition. The options above presented results in Table 116 for technology comparison. Table 116: Web Portal - Technology Comparison for the Web Portal Frontend Parameter Importance Rails CakePHP Django JSF AngularJS Up-to-Datedness Stability / Service Quality Extensibility & Open Source / Standards Familiarity Performance / Efficiency Interoperability / Modularity / 305

291 Web Portal Backend As described in the section for the major design decisions, the web portal s backend has to fulfill two major roles. First it needs to act as a standard web server that is responsible for delivering the portal s frontend web pages and to route requests to all ALFRED component APIs to populate the UI with consistent server side data. As a second role it has to provide a web service that handles authentication requests. A lot of web technologies can provide a suited server backend for the given roles. To be able to make a justified technology selection the generic comparison criteria have to be extended. Relevant specific backend criteria are described in Table 117. Table 117: Web Portal - Special Comparison Criteria for the Web Portal Backend Parameter Importance Lightweight scalable architecture ++ A lightweight architecture ensures high performance, low latency times and better scalability. These aspects are especially important for the web portal backend because all distributed ALFRED clients and APIs use the backend for their authentication requests. The system therefore needs to handle a lot of short lived processes simultaneously and should not add overhead to the respective calls. Furthermore, light architectures tend to be less vulnerable to hacking attempts and poor usage since the technology is easier to understand and implement than it is the case with more complex frameworks. Data Consistency ++ Data consistency is a big issue for the server backend since the web portal acts as a central access point to all of the ALFRED component s visual data. The backend should be able to handle whatever is stored and delivered by the KIS system without conversion or interfering with the general data structure. The following technologies presented below are the most important and extended solutions available in the market for the implementation of web server: Java: The Java programming language offers a well suited solution for a server side backend. The so called Java Enterprise Edition (JEE) offers a dedicated technology stack for web applications which is well-known, widely used and has an active expert community that ensures standardization. Several libraries offer reference implementations of Java Specification Requests (JSRs) that ensure code functionality and quality. PHP: PHP is known to be the most used programming language for web applications today and therefore a popular target for security attacks. PHP code can be used with various web frameworks that lead the programmer to a simple, clean and reliable code. JavaScript/nodeJS: With ever growing popularity and a very active contributor community, JavaScript, in form of nodejs, became a viable solution for server side technology over the past years. NodeJS offers a very fast and scalable backend system which is based on Google s open source JavaScript Engine V8. The basic 291 / 305

292 nodejs architecture offers a lightweight server system with pinpointed upgradability through numerous add-on packages. Ruby: Is an object oriented programming language with a steep learning curve. It provides many required features out of the box and many add-ons via so called RubyGems that can extend the environment of the web application. The most common framework is Rails that emphasises the user of well-known software engineering patterns and paradigms (see section ). Python: is an interpreted, object-oriented, high level programming language, as similar to Ruby, has a steep learning curve. There are several web frameworks that use Python but the most well-known is Django which follows the MVC pattern as mentioned in section Table 118 shows the weighted criteria for the different possible backend solutions. Table 118: Technologies Comparison for the Web Portal Backend Parameter Importance Java PHP JavaScript / nodejs Ruby Python Up-to-datedness Stability Extensibility & Open Source Familiarity Performance Interoperability Specific criteria Lightweight scalable architecture Data Consistency Technology Selection On the basis of section , Technology Comparison, this chapter is also split into two categories: the technology selection for the web portal frontend and the technology selection for the web portal backend Selection for the Web Portal Frontend The choice for the web portal frontend technology fell on a JavaScript MVC framework. The weighted criteria in Table 116 does not dictate a definite choice, but the fact that JavaScript logic is executed on the client side, and unstable server connections are thus less of an issue, were the deciding factor. As already mentioned in the corresponding section, a lot of MVC frameworks for JavaScript offer the same features. AngularJS is 292 / 305

293 chosen for the web portal frontend development because of a higher predicted efficiency value, the most active contributor community and a better familiarity on side of the project partners Selection for the Web Portal Server Backend The web portal server side will be realized with the JavaScript platform nodejs. Looking at the weighted criteria for the backend in Table 118, it not only fulfills the generic criteria, but it outweighs the alternatives when looking at the specific requirements. The lightweight architecture and indicated performance of nodejs makes it a well suited solution for real time applications like the combined web- and authentication server of the web portal backend. A high value of this decision lies in the fact that nodejs handles JSON data objects natively, without the need for external libraries. Other ALFRED components also work with JSON data and store it in the KIS and the web portal backend can use this data without further conversion. JavaScript, as the language behind the nodejs platform, is also the dominant technology for the selected web portal frontend solution. This means that all web portal components are implemented with the same programming language and work in the same environment. This makes development easier and less prone to errors and unneeded overhead Component Structure The diagram in Figure 25 visualizes the overall component structure of the ALFRED Web Portal. Each coloured box represents a functional component of the portal, while connecting lines indicate which components can communicate with each other. Noncoloured boxes group some components into bigger logical units which makes it easier to understand which components interact with each other. A divider line splits the figure into two general areas. On the left side of the divider the Web Portal s specific components are shown. The right area relates to other ALFRED components which are not part of the portal architecture and which are not depicted to their full extend. The colour coding in the diagram specifies accessibility. Blue components are publicly available from the outside while green components are internal and have no public interface. 293 / 305

294 Figure 25: Web Portal - Component Structure A detailed description for the single elements can be found in the following three chapters about the client components, the backend components and the portal user data Client Components The client side of the web portal accommodates four types of components: Multiple views, a number of controllers, some Validation Directives and a single data service. A View holds the visual elements that are shown in a browser while associated Controllers are responsible for the logic behind the view. Together they practically form dynamic web pages. Validation Directives are used for pages with form input and validate user entered data. Table 119 depicts existing frontend views with their associated controllers and validation directives. Note that not all views need a controller in case a view does not inherit complex logic. Similarly, not all views have a validator attached in case they don t have free form input. Some controllers and validators serve multiple views in case the views share many similar elements and functionalities. Table 119: Web Portal - View, Controller and Validation Directives View Controller Validation Directive Responsibility home MainController, UserController UserDataValidator Frame navigation, home content navigation and user status and login health - - Health area subnavigation 294 / 305