#  EXECUTIVE SUMMARY

The goal of this deliverable is to define the initial data sets to be used in
CAPTAIN project along with processes associated with those data sets and user
rights definition according to GDPR. This document is designed as a set of
tables, defining data sets and guidelines associated with each type of data
set and processes of data collection, storage, publication and security.

This report complements the provisions of the Grant Agreement and its annexes
as well as the Consortium Agreement, which has been already signed by all the
beneficiaries, in that it clearly defines the data sets of the project and
processes associated.

#  INTRODUCTION

The goal of CAPTAIN is to offer assistance through a very comfortable,
intuitive, transparent yet effective interaction paradigm: by transforming the
home itself into a transparent and tangible interface where instructions are
projected onto the real context augmenting it when and where needed while
interaction occurs by touching or moving real life objects.

CAPTAIN combines emerging non-invasive technology to deliver a radically new
ICT based system that empowers and motivates older adults in need of guidance
and care, through:

  * Projective Augmented Reality (PAR). Although PAR has been a fairly well studied research field for many years, there has been hardly any use for assistive technology for older adults. 

  

  * Gamified-coaching experience. A crucial part of this is the development of the virtual coach, which provides a continuous communication and empowerment mechanism across the CAPTAIN experience. ● Non-invasive physiological and emotional data analysis from facial micro-expressions and human body pose analysis thanks to scalable, robust, and accurate deep learning and artificial intelligence technologies. 

  

  * Non-invasive movement and gait data analysis through real-time location of the person from 3D sensors, which will be used to identify seniors’ movements 

  

The data coming from the cameras, pico-projectors, sensors, etc. integrated in
the home environment will be collected and analysed through the automated
reasoning and autonomous learning algorithms.

In order to ensure integration with existing IT ecosystems and maximise
interoperability, CAPTAIN will develop an open source API (Application
Programming Interface). This way, through the API it will be possible to
access existing building blocks and expose all the CAPTAIN’s functionalities
(inputs, output, intermediate inferences and algorithms results) to third
party solutions (both research projects or commercial products).

This document is the CAPTAIN data management plan (DMP). The DMP describes the
data management life cycle for all datasets to be collected, processed and/or
generated by the research project. The CAPTAIN DMP describes, among others:

  * The handling of data during and after the project 

  

  * The type of data that will be collected, processed, or gathered 

  

  * How the data will be pseudonymized and secured 

  

  * Whether and how the data will be made (openly) accessible 

  

  * How the data is stored; all above aka “preventive measures taken to ensure protection” 

  

  * Role of Data Management Official 

  

  * “Reaction measures” in case of data breach 

  

This version of the document is the first one to be published and due to the
living matter of it as well as evolving nature of the project itself, going to
be updated regularly with corresponding changes and final version of the DMP
is due to M36 of the project.

As a separate document to the DMP, the CAPTAIN Ethics policy as well as Study
Plan has been designed (D1.2, WP10 and WP7 deliverables).

The procedures described in this DMP shall be followed by all members of the
consortium and ensure that data on human participants are collected, stored,
transferred and used in a secure setting; that use of the data is compliant
with ethic-legal requirements (including signed informed consent, ethics
approval, and the applicable data protection laws, furthermore the EU data
protection regulation, which is applicable from May 2018). Management of
datasets that include personal information and health information of data
subjects will be compliant with the General Data Protection Regulation (GDPR,
Regulation (EU) 2016/679). The GDPR is a regulation by which the European
Parliament, the European Council and the European Commission intend to
strengthen and unify data protection for individuals within the European Union
(EU).

Despite the fact that GDPR will affect each country legislation in different
ways, CAPTAIN will follow data minimisation principle, reflected in GDPR,
despite of location – data collected will be adequate, relevant and limited to
what is necessary in relation to the purposes for which they are processed.

#  DATA SETS

CAPTAIN collected data sets should be divided by accessibility, storage
location, lifespan and access criteria.

By accessibility data sets are divided as:

  * Restricted Data – data sets accessible only by Data Subjects and defined CAPTAIN Administrators roles. These data sets are stored locally in CAPTAIN appliances in an encrypted way and should not leave the appliance at any time. 

  

  * Service Data – data sets used by CAPTAIN components for providing its functionality and services. From research perspectives these data sets could be useful although at the time of this DMP creation it has not been clearly requested by any institution. Proposed to be pseudonymised and stored in CAPTAIN local storage if not requested or deleted immediately after processing. 

  

  * Pseudo-Opened Data - data sets collected for research purposes and/or CAPTAIN service provision. These data should be pseudonymised and stored in CAPTAIN Cloud and accessible for institutional research purposes. 

  

Restricted Data should be linked to Service Data and Pseudo-Opened Data in
such a way that Data Subject at any time could execute his/her rights
regarding collected data, per GDPR.

Exact data linkage mechanism will be defined as long as CAPTAIN project
evolves in time.

By storage location data sets are divided as:

  * Local Data Sets – data sets stored in encrypted way in secured space inside of CAPTAIN appliance and never leave the CAPTAIN installation location. These are Restricted Data and Service Data sets. 

  

  * External Data sets – data sets aimed for research and/or service purposes and stored in pseudonymised way at CAPTAIN Cloud. Nothing prevents temporarily store these data sets inside CAPTAIN for internal processing, but their final destination will be the CAPTAIN cloud. PseudoOpened Data sets fall under this definition. 

  

Details about storages and their implementation will be covered by CAPTAIN
architecture and reflected in DMP as project evolves in time.

By lifespan data sets are divided as:

  * Temporal data sets – data sets collected during CAPTAIN development sprints. These data sets are specifically to be used for development purposes and should be deleted after CAPTAIN release/deployment. Nothing prevents the deletion of any part or all temporal data sets at any time prior to the M36 milestone. 

  

  * “Permanent” data sets – data sets to be collected after CAPTAIN release and used in deployed CAPTAIN appliances. These data sets will follow the lifetime rules set in GDPR. 

  

CAPTAIN should define several roles with various data access rights, allowing
various personal to access collected data for processing purposes. The
following roles are identified in CAPTAIN with corresponding data sets access
criteria:

  * Data Subject/Nominated Proxy – CAPTAIN user or person representing him/her. Should be able to access all data sets related to him/her and execute his/her right against these data. 

  

  * Administrator – technical role, responsible for CAPTAIN HW/SW installation, configuration, maintenance and support. Only Service Data sets are accessible if required by this role. 

  

  * “Clinical” – CAPTAIN power user, responsible for CAPTAIN services/utilities configuration, management and Data Subject activities monitoring. Service and Pseudo-Opened Data sets should be accessible by this role. 

  

  * Researcher – Pseudo-Opened Data Sets consumer, using these sets for research and publishing purposes. 

  

3.1 RESTRICTED DATA SETS

  1. Data Subject ID Personal Data 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**DataSubjectID**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

CAPTAIN Data set, targeted for Data Subject unique identification as CAPTAIN
appliance user:

● CAPTAIN appliance ID – ID linked to Data Subject and pseudonymising him/her
at the same time. **No Name/Family Names nor National ID will be collected** .
● Links on Service Data and Pseudo-Opened Data

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

Data Subject him/herself, after consent is given.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Nature and scale of data**

</th> </tr>  
<tr>  
<td>

It is expected that the datasets will be set during CAPTAIN Activation and
assignment to dedicated Data Subject. Specified data sets will be used for
unique identification of specified below data sets and by no means opened to
other than Data Subjects and CAPTAIN appliance corresponding roles. _Data
Format:_ TBD.

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The collected data is not targeted for external usage.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**DATA SHARING**

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

As identified by CAPTAIN Roles.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

These data sets are not shared at any time and could be accessed by Data
Subject/Nominated Proxy for his/her Data Subjects Rights execution per GDPR.

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

Locally at CAPTAIN internal storage.

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

The dataset volume is expected to be TBD.

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

TBD.

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Small one-time costs covered by CAPTAIN.

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

Data Subject/Nominated Proxy

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td> </tr> </table>

  2. Data Protection 

  

  

Restricted Data Set is protected from unauthorised access by all means,
including encryption and anonymization. At the same time, upon request by Data
Subject, corresponding all types of datasets could be fetched for Data
Subjects rights execution. Residing these data sets locally at CAPTAIN
appliance secure storage adds yet another security level.

3.2 SERVICE DATA SETS

  1. Data Subject Personal Data 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**DataSubject**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

CAPTAIN Data set, targeted for Data Subject personal information such as but
not limited to:

  * Age 

  

  * Sex 

  

  * Location 

  

  * “Diagnosis” 

  

  * Activities Recommendations 

  

  * Online Services identifiers 

  

  * Photos made by CAPTAIN, if such function is available 

  

  * Link from CAPTAIN appliance ID – used for chaining data sets. ● Links on Service Data and Pseudo-Opened Data 

  

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

Data Subject him/herself, after consent is given.

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

It is expected that the datasets will be collected during CAPTAIN everyday
usage/activity. _Data Format:_ TBD.

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

Part of the collected data could be useful for researchers (age/location,
etc.), while another part (identifiers/photos, etc.) could be used by various
CAPTAIN components, API for providing corresponding services.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Related scientific publication(s)**

</th> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**DATA SHARING**

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

Given the nature of the data set part of the data should never be shared,
while some of it could be accessed externally upon request for research
purposes.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

Access procedures TBD.

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

Locally at CAPTAIN internal storage.

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

The dataset volume is expected to be TBD.

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

TBD.

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

Small one-time costs covered by CAPTAIN.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

Data Subject/Nominated Proxy during CAPTAIN activation and everyday usage

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

</td> </tr> </table>

  1. Projections Data 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**Projections Data** 1  
</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

This dataset, in case of projection device fixed on the ceiling, is required
for the projection mapping pipeline, specifically the mesh of the Data
Subject’s environment as input.

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

2/3D Projection devices, fixed in key locations in the lab/home (for example,
the ceiling, wall).

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

The raw data used to compute the mesh depends on the desired outcome:

  * 2D Projections: o For dynamic objects (the participant’s body or a moving object), raw data are the live point clouds of the living room (depth map). This amount of data is huge: 640x480 16bit depth images at 30fps. 

  

o For static technique the raw data are one 640x480 16-bit depth image or a
sequence of images of the living room illuminated by structured lights. In the
latter case, the images are captured once for all (offline) and the amount of
data is about 20 or 30 1080p or 720p images.

  * 3D Projections: o Same as above plus the user’s head position _Data Format: TBD_

  

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

The dataset will be accompanied with detailed documentation of its contents.

</td> </tr>  
<tr>  
<td>

**DATA SHARING***

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

The dataset could become publicly available after pseudonymisation. The
inclusion of a participant’s data in the public part of this dataset will be
done on the basis of appropriate informed consent to data publication. Data
sets will be pseudonymised prior to access granted.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

No access will be granted unless specific request will be done by partners
and/or research institutions.

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

Local as well as external repositories should be used.

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

This is temporal data set and corresponding lifespan should be applied.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

**HOL**

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr> </table>

  1. Data Protection 

  

  

Service Data Sets are intended to hold internal service data, originally not
aimed for exposition outside of the CAPTAIN. While, upon request, data sets
could be exposed externally, following clear consent provided by Data
Subjects. Data sets should be stored in encrypted form and at the same time
specific processes will be defined for participant data sets with regard to
fetching, identification of all data relating to a specific participant, and
allowing Data Subject rights execution with all corresponding data sets.

3.3 PSEUDO-OPENED DATA SETS

  1. BodyGestureGait 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**BodyGestureGait**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

Dataset for human identification, postures, gestures, gait and balance
analysis tracking experiments, especially during activities of daily living
(ADL) where MentorAge will be the main sensor.

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

The dataset will be collected using the MentorAge sensor during daily
activities

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

It is expected that the datasets will be collected mainly during activities of
daily living in a real-life environment. The seniors will be asked to follow a
protocol containing daily activities, interaction with smart devices, virtual
tangible surfaces and the other CAPTAIN systems. Focus will be given to the
system under experimentation but always as part of a holistic daily living
scenario to ensure ecological validity. The session for each participant will
last approx. 60-90 minutes.

The dataset will contain the user’s silhouette as this is provided by the
MentorAge SDK (Skeleton with bones and joints) as well as continuous
collection of point clouds (3D depth data) of the space. It will be
investigated further whether the RGB and depth image will be collected.

_Data Format:_ PNG/JPG or mp4 for images (both RGB and depth), JSON for the
coordinates of the joints and bones, XML or TXT for annotations, data array
for depth information (2D matrices with depth information).

The dataset will be on the order of ~2-5 GB per recording hour.

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The collected data will be used for the development and evaluation of the
human activity monitoring, the gait analysis and the location of the senior in
order to fulfil the “whenever and wherever is needed” requirement of the
CAPTAIN project. The different parts of the dataset could be useful in the
benchmarking of a series of human tracking methods, focusing either on human
identification, on posture and gesture analysis and tracking as well as in
detecting, if possible, symptoms and signs that are related to health status.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

The dataset will accompany our research results in the field of human activity
monitoring and gait analysis of people in real homes. Corresponding
publications are:

Konstantinidis, E. I., Billis, A. S., Dupre, R., Fernández Montenegro, J. M.,
Conti, G., Argyriou, V., & Bamidis, P. D. (2017). IoT of active and healthy
ageing: cases from indoor location analytics in the wild. Health and
Technology, 7(1), 41–49. https://doi.org/10.1007/s12553-016-0161-3

Konstantinidis, E. I., Antoniou, P. E., Bamparopoulos, G., & Bamidis, P. D.
(2014). A lightweight framework for transparent cross platform communication
of controller data in ambient assisted living environments. Information
Sciences, 300, 124–139. http://doi.org/10.1016/j.ins.2014.10.070

</td> </tr> </table>  
<table>  
<tr>  
<th>

Konstantinidis, E. I., Billis, A. S., Bratsas, C., & Bamidis, P. D. (2016).
Active and Healthy Ageing Big Dataset streaming on demand. In Proceedings of
the 18th International Conference on HumanComputer Interaction. Toronto,
Canada.

</th> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

It should be noted that although several RGB-D datasets stemming from 3D
sensor dealing with human activity analysis are publicly available (see
datasets below), they must be further assessed regarding their compatibility
with the CAPTAIN project requirements (the sensor is expected to be on the
ceiling rather in front of the television as usual in most of the available
datasets).

_G3D_ ( _http://dipersec.king.ac.uk/G3D/G3D.html_ )  : G3D dataset contains a
range of gaming actions captured with Microsoft Kinect. The Kinect enabled us
to record synchronised video, depth and skeleton data. The dataset contains 10
subjects performing 20 gaming actions: _punch right, punch left, kick right,
kick left, defend, golf swing, tennis swing forehand, tennis swing backhand,
tennis serve, throw bowling ball, aim and fire gun, walk, run, jump, climb,
crouch, steer a car, wave, flap and clap_ .

_MSRC-12 Kinect gesture dataset_ ( _http://research.microsoft.com/en-_

_us/um/cambridge/projects/msrc12/_ )  : The Microsoft Research Cambridge-12
Kinect gesture data set consists of sequences of human movements, represented
as body-part locations, and the associated gesture to be recognized by the
system.

_RGB-D Person Re-identification Dataset_ ( _http://old.iit.it/en/datasets-and-
code/datasets/rgbdid.html_ )  : A new dataset for person re-identification
using depth information. The main motivation is that the standard techniques
(such as  _SDALF_ )  fail when the individuals change their clothing,
therefore they cannot be used for long-term video surveillance. Depth
information is the solution to deal with this problem because it stays
constant for a longer period of time.

_DGait Database_ ( _http://www.cvc.uab.es/DGaitDB/Summary.html_ )  : DGait is
a new gait database acquired with a depth camera. This database contains
videos from 53 subjects walking in different directions.

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

For the algorithm’s training data collection (experimental dataset),
participants from the pilot sites in NIVELY, AUTH and APSS will be recruited.

</td> </tr>  
<tr>  
<td>

**Technology for Data Collection**

</td> </tr>  
<tr>  
<td>

The body gesture and gait dataset will be collected through the MentorAge
sensor (NIVELY) or any other similar technology that will be described in the
D2.2 - First version of system specifications

</td> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

Although this has not been defined at the time being (it will become clear
after the user stories are presented to the participants), a protocol asking
the participants performing movements similar to their activities of daily
living is expected (walking, sitting, washing dishes, etc.)

</td> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

The collection of the experimental dataset will take place in a fully
controlled and safe environment in any of the partners NIVELY, AUTH, APSS
living labs.

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr> </table>  
<table>  
<tr>  
<th>

The dataset will be accompanied with detailed documentation of its contents.
Indicative metadata include: a) description of the experimental setup and
procedure that led to the generation of the dataset, b) type of exercise in
case the dataset produced during exergames, c) documentation of the variables
recorded in the dataset, and d) annotated posture, action and activity.

</th> </tr>  
<tr>  
<td>

**DATA SHARING**

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

Only the data captured by a subset of the participants during the initial
phases by normal healthy control subjects could become publicly available,
while the rest of them will be private to serve the CAPTAIN R&D objectives.

The inclusion of a (normal healthy control) subject’s data in the public part
of this dataset will be done on the basis of appropriate informed consent to
data publication. It will be investigated further whether the silhouette
(coordinates of joints and bones) subset of the dataset could be publicly
available.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

For the portions of the dataset that will be made publicly available, a
respective web page will be created on the data management portal (the use of
the CAC-playback manager  2  will be assessed) that will provide a description
of the dataset, links to a download section and a playback possibility in case
the playback manager approach is followed. The private part of this dataset
will be stored at a specifically designated private space of AUTH, NIVELY,
APSS or other CAPTAIN partner, in dedicated hard disk drives, on which only
members of the AUTH, NIVELY, APSS or other CAPTAIN partner research team whose
work directly relates to these data will have access. For further CAPTAIN
partners to obtain access to these data, they should provide a proper request
to the AUTH/ NIVELY/APSS or other CAPTAIN partner primarily responsible,
including a justification over the need to have access to these data. Once
deemed necessary, AUTH/ NIVELY / APSS or other CAPTAIN partner will provide
the respective data portions to the partner.

CAC-playback manager: Konstantinidis, E. I., Billis, A. S., Bratsas, C., &
Bamidis, P. D. (2016). Active and Healthy Ageing Big Dataset streaming on
demand. In Proceedings of the 18th International Conference on Human-Computer
Interaction. Toronto, Canada.

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

The applicable datasets will be publicly available 2 years after the end of
the project to allow the consortium prepare and submit the scientific
publications.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

For the public part of the dataset, a link to this will be provided from the
Data management portal. The link will be provided in all relevant CAPTAIN
publications. A technical publication describing the dataset and acquisition
procedure will be published.

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

The dataset will be designed to allow easy reuse with commonly available tools
and software libraries. In case of supporting the online playback of the
datasets, libraries for a variety of programming languages will be released
(e.g.  _http://www.cac-framework.com/_ )  
</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be accommodated at the data management
portal of the project website.

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be preserved online for as long as there
are regular downloads. After that it would be made accessible by request. The
private part of the dataset will be preserved by AUTH/NIVELY/APSS for the
period required by GDPR.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

The dataset is expected to be several gigabytes, provided that each recording
hour is expected to be ~2-5 GB.

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

Probably two dedicated hard disk drives will be allocated for the dataset; one
for the public part and one for the private. In this case the costs associated
with its preservation will be according to the hardware cost (hard drives).

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

Small one-time costs covered by CAPTAIN.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

**NIVELY, AUTH, APSS**

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

**NIVELY, AUTH**

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

**NIVELY, AUTH, APSS**

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

The data are going to be collected within activities of WP3, WP4, WP6 and WP8,
to mainly serve the research efforts of T3.2, T4.1, T4.3, T4.4, T6.1 and T6.4.

</td> </tr> </table>

  2. InGameMetrics 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**in-GameMetrics**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

This dataset will include in-game metrics and games’ performance of all the
sessions so as to facilitate subsequently analysis with respect to the
clinical assessment tests towards research on early signs of health
deterioration and physical and cognitive assessment (linear correlation of in-
game metrics with clinical assessment tests).

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

The dataset will be collected using the webFitForAll (wFFA) platform which
accommodate different types of serious gaming interventions.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Nature and scale of data**

</th> </tr>  
<tr>  
<td>

The datasets will be collected during the serious gaming interventions of
wFFA. The serious games will ask the user to go under specific exercises or
gaming tests while mechanisms in the background will track and collect the
user’s performance. In the case of Exergames, the user will be asked to
perform specific exercises which will be captured by a 3D sensor.

The dataset will contain metrics like reaction time, player’s path / optimum
path, goal time, movement range, balance, min and max angles of movements,
wrong choices and much more in-game metrics that will arise during the design
requirements of the serious games.

_Data Format:_ RDF triples or JSON

The dataset is expected to be composed of 180 records per serious gaming
session.

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The collected data will be used for the development and evaluation of the
Personalized Game Suite in terms of usability, acceptance and user’s
assessment. The different parts of the (semantically annotated where
applicable) dataset could be useful in the benchmarking of a series of serious
games, focusing either on detecting and assessing user’s physical and
cognitive state or in the effectiveness axis as the primary role of the
interventions. The latter will feed the **T5.2** which is intended to
dynamically recommend game adaptations for personalised and optimised use as
well as keeping the users in the “flow zone” which represents the feeling of
being complete and energized focus in an activity with a high level of
enjoyment and fulfilment towards increased adherence.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

The dataset will accompany our research results in the field of human activity
monitoring. AUTH team has an already existing dataset, including recordings
from elderly people going through Exergames, that will be used in analysis and
algorithms testing. Corresponding publications are:

Bamparopoulos, G., Konstantinidis, E., Bratsas, C., & Bamidis, P. D. (2016).
Towards exergaming commons: composing the exergame ontology for publishing
open game data. Journal of Biomedical Semantics, 7(1), Article nr 4.
http://doi.org/10.1186/s13326-016-0046-4

Konstantinidis, E., Bamparopoulos, G., & Bamidis, P. (2016). Moving Real
Exergaming Engines on the Web: The webFitForAll case study in an active and
healthy ageing living lab environment. IEEE

Journal of Biomedical and Health Informatics, 1–1.
http://doi.org/10.1109/JBHI.2016.2559787

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

It should be noted that there are no serious games datasets available online.
To the best of our knowledge, the only open dataset regarding serious games,
and more specifically Exergames performed by older adults, is the one that
AUTH has published a couple of years before described in:

Bamparopoulos, G., Konstantinidis, E., Bratsas, C., & Bamidis, P. D. (2016).
Towards exergaming commons: composing the exergame ontology for publishing
open game data. Journal of Biomedical Semantics, 7(1), Article nr 4.
http://doi.org/10.1186/s13326-016-0046-4

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

**Although AUTH will use previous collected anonymized datasets for the
algorithms’ training, if new datasets are needed** participants from the pilot
sites in NIVELY, AUTH and APSS will be recruited.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Technology for Data Collection**

</th> </tr>  
<tr>  
<td>

The data will be collected through the webFitForAll exergaming platform which
will be the physical and cognitive intervention component of the CAPTAIN
system.

</td> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

The users will be asked to follow a physical training protocol composed of:
webFitForAll is part of the broader framework of research on "active aging",
improving physical fitness for the elderly and vulnerable groups and, of
course, the fight against dementia. It is based on modern Information and
Communication Technologies (ICT) providing physical exercise to maintain good
physical fitness through an innovative, low-cost technology platform that
combines exercise with games.

It includes protocols of exercises aimed at the elderly and vulnerable groups,
specially designed by scientists skilled in the elderly. These exercises,
tailored to the specificities of the users, enhance aerobic fitness,
flexibility, balance and strength.

Aerobic, activates the body's circulatory and cardiovascular system. Improves
the performance of the heart both at rest and during exercise.

Flexibility, is necessary to avoid injuries. Create more flexibility and a
greater range of motion, increase blood flow, wellness and inner peace and
better posture.

Balance, improves static and functional balance, mobility, and enhance the
performance of their functional tasks in their everyday lives. Physical
training can improve balance and reduce the risk of falling.

Strength, helps to prevent the loss of muscle mass that accompanies aging
(prevention of sarcopenia), which is a major problem in the elderly, but also
in maintaining bone mass. Improving the musculoskeletal system increases
muscle mass, joint flexibility, and bone strength.

The basic level of protocol is set at an intensity of 50-60% of maximum heart
rate and reaches the third level by intensity about 70-85%. The protocol can
be adapted to the needs of the user.

</td> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

The collection of the experimental dataset will take place in a fully
controlled and safe environment in any of the partners NIVELY, AUTH, APSS
living labs.

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

The dataset will be accompanied with detailed documentation of its contents.
Indicative metadata include: a) description of the experimental setup and
procedure that led to the generation of the dataset, b) type of exercise or
game, c) documentation of the variables recorded in the dataset, and d)
semantic annotation based on existing ontologies.

</td> </tr>  
<tr>  
<td>

**DATA SHARING***

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

The dataset could become publicly available. The inclusion of a subject’s data
in the public part of this dataset will be done on the basis of appropriate
informed consent to data publication.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

A proposed access procedure is to automatically convert the acquired game
results to RDF triples and published on the web as open data, accessible
through a SPARQL Endpoint. In order to facilitate access, links to a download
section where the datasets will be downloaded as JSON files will be provided
if

</td> </tr> </table>  
<table>  
<tr>  
<th>

required. The private part of this dataset will be stored at a specifically
designated private space of AUTH, in dedicated hard disk drives, on which only
members of the AUTH research team whose work directly relates to these data
will have access. For further partners to obtain access to these data, they
should provide a proper request to the AUTH primarily responsible, including a
justification over the need to have access to these data. Once deemed
necessary, AUTH will provide the respective data portions to the partner.

</th> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

The applicable datasets will be publicly available two years after the end of
the project to allow the consortium prepare and submit the scientific
publications.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

For the public part of the dataset, a link to this, as well as to the SPARQL
endpoint will be provided from the Data management portal. The link and the
SPARQL endpoint will be provided in all relevant publications. A technical
publication describing the dataset and acquisition procedure will be
published.

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

The dataset will be designed to allow easy reuse with commonly available tools
and software libraries.

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be accommodated at AUTH servers,
accessible by the SPARQL endpoint.

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be preserved online for as long as there
are regular downloads. After that it would be made accessible by request.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

The dataset is expected to be several hundreds of MB, provided that each
session is expected to produce a volume of ~80 KB of data.

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

The dataset will be stored in the serious gaming server hosted by AUTH. There
are no costs associated with its preservation. In the case that Microsoft
Azure will accommodate the serious gaming server, there will be an additional
cost of approximately 20 Euros (€) per month for one year

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

The costs associated with the data archiving and preservation will be covered
by the CAPTAIN project budget.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

**AUTH**

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

The data are going to be collected within activities of WP7, T4.4 and used in
T5.2 and WP8.

</td> </tr> </table>

  3. SensorsData 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**SensorsData**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

For T4.1 and T 4.2 own data will be used for training. For research and WP5
purposes still will be useful to collect validation data; the amount of
validation data could be decided based on data sources and the legal issues
associated with it.

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

Data will be created based on user presence detection, user pose, user
identification as well as face emotion recognition, speech emotion
recognition, fuse speech and face emotion.

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

Compressed video (such as H.264) at the resolution of the sensors. The bitrate
should be sufficient so that no artefacts are present in highly dynamic
situations (the effective bitrate depends on the camera that will be
integrated).

Validation data does not need to be large. A few minutes of footage in each
scene that should be supported is enough.

_Data Format:_

H.264 video and text-based annotations.

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The dataset can be used to debug the emotion and pose detection algorithms in
real-life situations of the project and to fine tune pre-processing
parameters. Moreover, it can be used by the system integration team to
validate the integration.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

nViso proprietary datasets (cannot be integrated nor reused)

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

The subjects depend on the problems that need to be solved.

</td> </tr>  
<tr>  
<td>

</td> </tr>  
<tr>  
<td>

</td>  
<td>

**Technology for Data Collection**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

</td> </tr> </table>  
<table>  
<tr>  
<th>

Camera used in the device.

</th> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

The collection protocol is defined case by case depending on the issues that
need to be solved (for instance if during the tests a problem in low light
condition is detected then the video should be captured in these conditions).

</td> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

For this data the risks the collection protocol can be adapted as to minimize
the risks.

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

The dataset will be accompanied with detailed documentation of its contents.

</td> </tr>  
<tr>  
<td>

**DATA SHARING***

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

Since very small amount of data is required for WP4 purposes it should be
possible to collect it in a way that it doesn't pose major ethical/privacy
problems. Since it is so small the video to be shared could even be reviewed
and explicit consent be given by the participants to share it.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

No continuous access of the data is necessary. Data can be transferred to the
relevant party when it is required.

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

This data is for debug reason and should not be shared outside the scope of
debugging.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

This data is not intended for dissemination.

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

This data is used only of debug and no reuse is expected.

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

There is no need of long term storage.

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

The data can be destroyed as soon as the debugging is completed.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

The data collected is used to validate the performance and possibly tune some
pre-processing parameters. A few hours of total footage covering different
lightning conditions, environments, device setups and people should be more
than enough.

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

No preservation is expected.

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

The costs associated with the data archiving and preservation will be covered
by the CAPTAIN project budget.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

**NVISO, APSS**

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

WP4 and WP5

</td> </tr> </table>

  4. DailyDiaryNutrition 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**DailyDiaryNutrition**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

This dataset will include the records created by users themselves, describing
their daily activities in nutrition - diet, food consumed, time, duration etc)
in plane text or in form of questionnaire.

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

The dataset will be collected using diary style application available via
appliance User Interface.

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

The datasets will be collected regularly (assuming daily) by using users
goodwill (could be several times a day) or predefined reminders set. Form to
fill will be presented allowing users to write down their daily activities
related to nutrition.

The dataset will contain text and/or checkboxes with data associated.

_Data Format:_ TBD

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The collected data will be used for the development, evaluation and correction
of the activities related services provided by the of the appliance. The
different parts of the dataset could be useful in the benchmarking of a
already provided services, focusing on efficiency of them.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th> </tr>  
<tr>  
<td>

</td>  
<td>

**Technology for Data Collection**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**DATA SHARING***

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

The dataset could become publicly available after pseudonymisation. The
inclusion of a subject’s data in the public part of this dataset will be done
on the basis of appropriate informed consent to data publication.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

The applicable datasets will be publicly available two years after the end of
the project to allow the consortium prepare and submit the scientific
publications.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

The dataset will be designed to allow easy reuse with commonly available tools
and software libraries.

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be preserved online for as long as there
are regular downloads. After that it would be made accessible by request.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

The costs associated with the data archiving and preservation will be covered
by the CAPTAIN project budget.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

</td> </tr> </table>

  5. DailyDiarySocial 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**DailyDiarySocial**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

This dataset will include the records created by users themselves, describing
their daily activities (Social Interactions) in plane text or in form of
questionnaire.

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

The dataset will be collected using diary style application available via
appliance User Interface.

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

The datasets will be collected regularly (assuming daily) by using users
goodwill (could be several times a day) or predefined reminders set. Form to
fill will be presented allowing users to write down their daily social related
activities - phone calls, visits, Skype (or similar) chats, social networking
etc. The dataset will contain text and/or checkboxes with data associated.

_Data Format:_ TBD

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The collected data will be used for the development, evaluation and correction
of the activities related services provided by the of the appliance. The
different parts of the dataset could be useful in the benchmarking of an
already provided services, focusing on efficiency of them.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th> </tr>  
<tr>  
<td>

</td>  
<td>

**Technology for Data Collection**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**DATA SHARING***

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

The dataset could become publicly available after pseudonymisation. The
inclusion of a subject’s data in the public part of this dataset will be done
on the basis of appropriate informed consent to data publication.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

The applicable datasets will be publicly available two years after the end of
the project to allow the consortium prepare and submit the scientific
publications.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

The dataset will be designed to allow easy reuse with commonly available tools
and software libraries.

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be preserved online for as long as there
are regular downloads. After that it would be made accessible by request.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

The costs associated with the data archiving and preservation will be covered
by the CAPTAIN project budget.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

</td> </tr> </table>

  6. DailyDiaryPhysical 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**DailyDiaryPhysical**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

This dataset will include the records created by users themselves, describing
their daily activities (Physical Activities) in plane text or in form of
questionnaire.

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

The dataset will be collected using diary style application available via
appliance User Interface.

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

The datasets will be collected regularly (assuming daily) by using users
goodwill (could be several times a day) or predefined reminders set. Form to
fill will be presented allowing users to write down their daily physical
activities - physical exercises, walking, gym etc.

The dataset will contain text and/or checkboxes with data associated.

_Data Format:_ TBD

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The collected data will be used for the development, evaluation and correction
of the activities related services provided by the of the appliance. The
different parts of the dataset could be useful in the benchmarking of an
already provided services, focusing on efficiency of them.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th> </tr>  
<tr>  
<td>

</td>  
<td>

**Technology for Data Collection**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**DATA SHARING***

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

The dataset could become publicly available after pseudonymisation. The
inclusion of a subject’s data in the public part of this dataset will be done
on the basis of appropriate informed consent to data publication.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

The applicable datasets will be publicly available two years after the end of
the project to allow the consortium prepare and submit the scientific
publications.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

The dataset will be designed to allow easy reuse with commonly available tools
and software libraries.

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be preserved online for as long as there
are regular downloads. After that it would be made accessible by request.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

The costs associated with the data archiving and preservation will be covered
by the CAPTAIN project budget.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

</td> </tr> </table>

  7. DailyDiaryADL 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**DailyDiaryADL**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

This dataset will include the records created by users themselves, describing
their daily activities related to potential risk of fall associated difficulty
with Activities of Daily Living (ADL) in plane text or in form of
questionnaire.

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

The dataset will be collected using diary style application available via
appliance User Interface.

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

The datasets will be collected regularly (assuming daily) by using users
goodwill (could be several times a day) or predefined reminders set. Form to
fill will be presented allowing users to write down their notes about their
condition related to ADL and (potential) risk of fall. The dataset will
contain text and/or checkboxes with data associated.

_Data Format:_ TBD

</td> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

The collected data will be used for the development, evaluation and correction
of the activities related services provided by the of the appliance. The
different parts of the dataset could be useful in the benchmarking of an
already provided services, focusing on efficiency of them.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th> </tr>  
<tr>  
<td>

</td>  
<td>

**Technology for Data Collection**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**STANDARDS AND METADATA**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**DATA SHARING***

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

The dataset could become publicly available after pseudonymisation. The
inclusion of a subject’s data in the public part of this dataset will be done
on the basis of appropriate informed consent to data publication.

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

The applicable datasets will be publicly available two years after the end of
the project to allow the consortium prepare and submit the scientific
publications.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

The dataset will be designed to allow easy reuse with commonly available tools
and software libraries.

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

The public part of this dataset will be preserved online for as long as there
are regular downloads. After that it would be made accessible by request.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

The costs associated with the data archiving and preservation will be covered
by the CAPTAIN project budget.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

</td> </tr> </table>

  8. TheCAPTAINCoach 

  

  
  
<table>  
<tr>  
<th>

**DATA SET REFERENCE NAME**

</th>  
<th>

**TheCAPTAINCoach**

</th> </tr>  
<tr>  
<td>

**DATA SET DESCRIPTION**

</td> </tr>  
<tr>  
<td>

**Generic description**

</td> </tr>  
<tr>  
<td>

Internal data generated by CAPTAIN sensors during appliance everyday
functionality will be cleaned, pre-processed, anonymized (or at least
pseudonymized), summarized and then delivered to the cloud platform, where
this dataset will reside.

The resulting data set will contain two kinds of information:

● Longitudinal data from users covering high level features such as emotional
states, activities of daily living, travel and gait patterns, as well as
cognitive/physical training results (T4.5) ● Personalized guides and
recommendations (T5.1-T5.3)

</td> </tr>  
<tr>  
<td>

**Origin of data**

</td> </tr>  
<tr>  
<td>

The input data will be the distilled combination of the outputs from **WP4
through T4.5** **and T5.1 - T5.3** .

</td> </tr>  
<tr>  
<td>

**Nature and scale of data**

</td> </tr>  
<tr>  
<td>

All output data from systems in **WP4** (sensing) through T4.5:

  * User presence information 

  

  * Emotional, behavioural and contextual activity information (sensitive data) 

  

  * Indoor location and gait analysis 

  

  * Physical and cognitive training progress monitoring (sensitive data) Coaching information: 

  

  * Guides and recommendations for interventions 

  

  * User model instances ( **coming from T5.1 & T.5.3 ** ) for motivational engine & HCI. 

  

_Data Format:_

Expected volume may require Big Data management tools, and all these data will
be mainly numeric and text. In order to structure this data JSON file format
is foreseen unless for simplicity a tabular representation such as CSV file is
enough. Each data point must include the user ID and the timestamp.

</td> </tr> </table>  
<table>  
<tr>  
<th>

If linkage among events is required, this will be also stored. Data will
reflect a longitudinal dimension across a broad spectrum of elderly people
with different characteristics, background and interests.

This data should be served through the CAPTAIN cloud system through a clean
REST API, including authentication methods.

A support backup could be sent digitally to the researcher profiles, as a SQL
database export. In this case, the expected size could be in the range of MB
to several GB per user.

The annotations should include ground truth (validated by experts) about the
evolution of each person, as well as the category to which each subject
belongs (each time a person moves from one category to another needs also to
be annotated)

</th> </tr>  
<tr>  
<td>

**To whom the dataset could be useful**

</td> </tr>  
<tr>  
<td>

To those interested in developing and evaluating virtual coaching algorithms.
In particular, the anonymized part of the collected data could be useful for
researchers, while the pseudonymized part of the dataset will be useful for
Vicomtech in order to implement the CAPTAIN coach. Additional CAPTAIN services
may be created based on the anonymized part of this dataset.

</td> </tr>  
<tr>  
<td>

**Related scientific publication(s)**

</td> </tr>  
<tr>  
<td>

TBD

</td> </tr>  
<tr>  
<td>

**Indicative existing similar data sets** (including possibilities for
integration and reuse)

</td> </tr>  
<tr>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**SAMPLE DATA**

</td> </tr>  
<tr>  
<td>

**Subjects to be enrolled**

</td> </tr>  
<tr>  
<td>

Broad spectrum of subjects (age, gender, health profile, etc) are required:

  * People with major cognitive/physical impairment should be excluded. 

  

  * 50 could be a reasonable amount of subjects 

  

  * Enrolment must cover recording for more than 6 months per subject 

  

</td> </tr>  
<tr>  
<td>

</td> </tr>  
<tr>  
<td>

**Technology for Data Collection**

</td> </tr>  
<tr>  
<td>

Data will be collected in two parallel ways: a) using a lifelogging smartphone
app, containing a set of questionnaires which will be filled by either the
data subjects or their nominated proxy everyday, and b) by using the modules
developed in WP4 as well as the implementations of tasks 5.1 to 5.3. Since WP4
modules and T5.1-5.3 implementation is part of the project, they will not be
available for the first pilots when data will be collected, therefore, in
those cases only lifelogging based surveys will be collected and available.

</td> </tr>  
<tr>  
<td>

**Protocol for Data Collection**

</td> </tr>  
<tr>  
<td>

A combination of data self-reporting (lifelogging), questionnaires and
structured interviews is foreseen

  * If possible, at least for the pilots when the outputs from WP4, T51-T5.3 tasks should be available, data captured from those outputs should be included into this dataset 

  

  * Task 4.5 leader, DIGIFLAK should provide this dataset 

  

  * Collected data should cover a period of at least 6 months 

  

</td> </tr> </table>  
<table>  
<tr>  
<th>

  * Depending on the final data reporting process, it could take more than 2 hours/day 

  

  * Seasonal analysis may be of interest 

  

The protocol will be as follows:

  1. Per each pilot first it will be decided if WP4 and or T5.1-5.3 modules are available for capturing this kind of data. If so, they will be installed and enabled to capture data 

  

  2. Lifelogging smartphone app will be made available to data subjects, including explanation to them (and the nominated proxy if exists) 

  

  3. Data subjects will perform the activities as described in the pilot 

  

  4. Data subjects (or nominated proxies) will carry out the lifelogging process 

  

  5. Data will be processed to the CAPTAIN cloud system and made available during the pilot, with a delay of at most 1 week. During this process, data will be only pseudonymized and only available to CAPTAIN members 

  

  6. After finishing the pilot (except for data subjects which may be enrolled for future pilots), data will be anonymized by following this procedure: 

    1. Create a new person ID for each original person ID, which must not be directly obtainable from the original 

  

    2. Replace all references to original ID by the new ones, obtaining a new dataset D' 

  

    3. Delete any table with the correspondence between the original and new ID d. Send WP5 partners D' 

  
  

  

  

</th> </tr>  
<tr>  
<td>

**Potential Risk Associated with Data Collection**

</td> </tr>  
<tr>  
<td>

**Risk**

</td>  
<td>

**Level**

</td>  
<td>

**Probability**

</td> </tr>  
<tr>  
<td>

Safety in performing activity

</td>  
<td>

High

</td>  
<td>

Low

</td> </tr>  
<tr>  
<td>

Using technologies

</td>  
<td>

High

</td>  
<td>

Medium

</td> </tr>  
<tr>  
<td>

Psychological implications

</td>  
<td>

Medium

</td>  
<td>

Low

</td> </tr>  
<tr>  
<td>

**Access type**

</td> </tr>  
<tr>  
<td>

For the pseudonymized part of the dataset user and password-based control will
be implemented as well as a registry of the access to the data. Access control
will be restricted to CAPTAIN project members, and specifically to WP5 and
task 4.5 participants.

For the anonymized part of the dataset, access will also be controlled by
password, but access may be granted upon request. Access will also be
registered.

In both cases read only access will be provided

</td> </tr>  
<tr>  
<td>

**Access Procedures**

</td> </tr>  
<tr>  
<td>

This dataset will be accessed through a REST API provided by the CAPTAIN cloud
system. Additionally, SQL backups are foreseen.

</td> </tr>  
<tr>  
<td>

**Embargo periods** (if any)

</td> </tr>  
<tr>  
<td>

The applicable datasets will be publicly available two years after the end of
the project to allow the consortium prepare and submit the scientific
publications.

</td> </tr>  
<tr>  
<td>

**Technical mechanisms for dissemination**

</td> </tr>  
<tr>  
<td>

For the public part of the dataset, a link to this will be provided from the
Data management portal. The link will be provided in all relevant CAPTAIN
publications. A technical publication describing the dataset and acquisition
procedure will be published.

</td> </tr>  
<tr>  
<td>

**Necessary S/W and other tools for enabling re-use**

</td> </tr>  
<tr>  
<td>

The dataset will be designed to allow easy reuse with commonly available tools
and software libraries.

</td> </tr>  
<tr>  
<td>

**Repository where data will be stored**

</td> </tr>  
<tr>  
<td>

This dataset will be accommodated at the data management portal of the project
website.

</td> </tr>  
<tr>  
<td>

**ARCHIVING AND PRESERVATION** (including storage and backup)

</td> </tr>  
<tr>  
<td>

**Data preservation period**

</td> </tr>  
<tr>  
<td>

This dataset will be preserved online for as long as there are regular
downloads. After that it would be made accessible by request. The private part
of the dataset will be preserved by DIGIFLAK for the period required by GDPR.

</td> </tr>  
<tr>  
<td>

**Approximated end volume of data**

</td> </tr>  
<tr>  
<td>

~GBs

</td> </tr>  
<tr>  
<td>

**Indicative associated costs for data archiving and preservation**

</td> </tr>  
<tr>  
<td>

Probably two dedicated hard disk drives will be allocated for the dataset; one
for the public part and one for the private. In this case the costs associated
with its preservation will be according to the hardware cost (hard drives).

</td> </tr>  
<tr>  
<td>

**Indicative plan for covering the above costs**

</td> </tr>  
<tr>  
<td>

The costs associated with the data archiving and preservation will be covered
by the CAPTAIN project budget.

</td> </tr>  
<tr>  
<td>

**PARTNERS ACTIVITIES AND RESPONSIBILITIES**

</td> </tr>  
<tr>  
<td>

**Partner Owner / Data Collector**

</td>  
<td>

**DIGIFLAK**

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data analysis**

</td>  
<td>

**VICOMTECH**

</td> </tr>  
<tr>  
<td>

**Partner in charge of the data storage**

</td>  
<td>

**DIGIFLAK**

</td> </tr>  
<tr>  
<td>

**WPs and Tasks**

</td> </tr>  
<tr>  
<td>

The data is going to be collected in WP4, through T4.5 and then used in T5.4

</td> </tr> </table>

  1. Data Protection 

  

  

For the public part of the Pseudo-Opened Data Sets, a link will be provided
from the Data management portal. At the same time specific processes will be
defined for related to specified Data Subjects data sets fetching, making
possible identification all data related to dedicated Data Subject and
allowing Data Subject rights execution with all corresponding data sets.

#  DATA SUBJECTS RIGHTS

4.1.1 THE RIGHT TO BE INFORMED

Data Subject will be informed within predefined timeframe if data sets
corresponding to him/her will be processed or there is a request to provide an
access to Semi-Secured data, related to Data Subject. CAPTAIN will provide
Data Subjects with information including: CAPTAIN proposals for processing
their personal data, CAPTAIN retention periods for that personal data, and who
it will be shared with.

4.2 THE RIGHT OF ACCESS

Specific mechanism via Data Management Portal will be provided for Data
Subject to access their personal data and supplementary information, allowing
them allows to be aware of and verify the lawfulness of the processing.

4.3 THE RIGHT TO RECTIFICATION

Data Subject either directly via Data Management portal or indirectly via
CAPTAIN administrator will have an ability to correct data sets, when personal
data are found to be inaccurate.

4.4 THE RIGHT TO ERASURE

With additional stipulations, Data Subject will have an ability to issue a
request for all data erasure and, within predefined but non-later that within
40 days after request, CAPTAIN administrator will have an ability to delete
all corresponding to Data Subject data sets.

4.5 THE RIGHT TO RESTRICT PROCESSING

With additional stipulations, Data Subject will have an ability to limit the
processing of his/her personal data sets, with several rules and exceptions
defined during consent processing.

4.6 THE RIGHT TO DATA PORTABILITY

Data Subject will be informed within predefined timeframe if data sets
corresponding to him/her is going to be transferred to outside of current Data
Centre.

4.7 THE RIGHT TO OBJECT

Data Subjects at any time could say they don’t want the personal data
processing to be done or going on. Then within predefined timeframe all data
sets corresponding to him/her is going to be set on hold and excluded from
processing till consent on processing is given back.

4.8 THE RIGHT REGARDING AUTOMATED DECISION-MAKING

CAPTAIN will not base a decision solely on automated means, including
profiling, which produces legal or similar effects. All activities regarding
Data Objects data sets will get clear and undoubtful consent from him/her.

4.9 OTHER RIGHTS

Specified by DMO Data Policies will define the steps required for executing
other Data Subjects rights like Consent withdraw, data breach notification and
compensation.

#  IN CASE OF EMERGENCY – DATA BREACHES

In case of unluckily event of data breach the following process should be used
(Figure 1):

Figure 1: Escalation Process

#  DATA MANAGEMENT OFFICIAL

Data Management Official, appointed by CAPTAIN consortium, will provide both
the permanent security and privacy audit of all system’s components and data
storage, validating risks associated with data breach as well as potential
threats. The audit will cover all system components including hardware
appliances, servers, communication channels, applications, operational
systems, access rights, etc. The audit will be extended after CAPTAIN
completion, if required, monitoring appliances installed at Data Subject
households, as well as collected data storages and data processing.

CAPTAIN Data Management Official will be the contact point for the supervisory
authority on issues relating to processing of data sets as well as any issues
related to Data Subjects and their rights execution.

Each Living Lab or pilot partner, in cases where collected data is not stored
in CAPTAIN cloud but in local storage, should nominate a person with a similar
role and responsibility to the Data Management Official. CAPTAIN Data
Management Official should be in permanent contact with corresponding
personnel at Living Labs/Pilot Partners, validating risks associated with data
breaches as well as potential threats.

#  ETHICS INCLUDING CONSENT

CAPTAIN consortium policies about Ethics and Safety are outlined in D1.2
Ethics and Safety Manual.