**1\. Executive summary**

The purpose of this deliverable is to outline how data will be handled during
the project and after it is completed.

Plan4Act is participating on the EU Open Research data pilot. Open Research
Data Pilot aims to improve and maximise access to and re-use of research data
generated by the Project. As part of this, we deliver a Data Management Plan
(DMP).

The Data Management Plan will address how data will be collected, generated
and processed during the project, following what methodology and standards
will be used, what data will be shared and /or made openly available and how
will it be curate and preserved.

This document is intended to be the first of the two iterations of the DMP
that will be formally submitted during the project. Thus, the DMP is not a
fixed document but evolves and is more precise during the lifespan of the
project.

Page of 21

**2\. Principles of Data Management.**

#  2.1 Data Management Requirements

The current deliverable has been based on the guidelines of the EU Commission
regarding the openness of the data generated from a project that has been
funded by the H2020. According to these guidelines the scientifically-oriented
data that are going to be generated by the Activage project will be formed so
that they can be easily **discoverable** , **accessible** , **assessable** and
**intelligible** , **usable** beyond the original purpose of their collection
and usage but also **interoperable** to appropriate quality standards.

#  2.2 EU Commission Guidelines for Data Management

The EU Commission has published some guidelines for appropriate data
management plans in Horizon 2020 projects. This guide is structured as a
series of questions that should be ideally clarified for all datasets produced
in any H2020 project.

The table following on the next page presents the different aspects of the
questions raised on FAIR Data Management - template along with a comment
validating the conformance of the Plan4Act project or each work package (Table
2).

Page of 21  
  
<table>  
<tr>  
<th>

**DMP**

**Component**

</th>  
<th>

**Issu**

</th>  
<th>

**es to be addressed**

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

Data Summary

</td>  
<td>

1\.

</td>  
<td>

State the purpose of the data collection/ generation

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

</td>  
<td>

2\.

</td>  
<td>

Explain the relation to the objectives of the project

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

</td>  
<td>

3\.

</td>  
<td>

Specify the types and formats of data generated/collected

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

</td>  
<td>

4\.

</td>  
<td>

Specify if existing data is being re-used (if any)

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

</td>  
<td>

5\.

</td>  
<td>

Specify the origin of the data

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

</td>  
<td>

6\.

</td>  
<td>

State the expected size of the data (if known)

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

</td>  
<td>

7\.

</td>  
<td>

Outline the data utility: to whom will it be useful

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

FAIR Data. Making data findable, including provisions for metadata.

</td>  
<td>

1\. 2.

3\.

4\.

</td>  
<td>

Outline the discoverability of data (metadata provision)

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?

Outline naming conventions used

Outline the approach towards search keyword

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

</td>  
<td>

5\.

</td>  
<td>

Outline the approach for clear versioning

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

</td>  
<td>

6\.

</td>  
<td>

Specify standards for metadata creation (if any). If there are no standards in
your discipline describe what type of metadata will be created and how

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

Making data openly accessible

</td>  
<td>

1\.

2\.

</td>  
<td>

Specify which data will be made openly available? If some data is kept closed
provide rationale for doing so

Specify how the data will be made available

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

</td>  
<td>

3\.

</td>  
<td>

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?

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

</td>  
<td>

4\.

</td>  
<td>

Specify where the data and associated metadata, documentation and code are
deposited

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

</td>  
<td>

5\.

</td>  
<td>

Specify how access will be provided in case there are any restrictions

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

Making data interoperable

</td>  
<td>

1\.

</td>  
<td>

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.

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

</td>  
<td>

2\.

</td>  
<td>

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?

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

Increase data re-use (through clarifying licences)

</td>  
<td>

1\. 2.

3\.

</td>  
<td>

Specify how the data will be licenced to permit the widest reuse possible

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why

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

</td>  
<td>

4\.

</td>  
<td>

Describe data quality assurance processes

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

</td>  
<td>

5\.

</td>  
<td>

Specify the length of time for which the data will remain re-usable

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

Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

Estimate the costs for making your data FAIR. Describe how you intend to cover
these costs

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

</td>  
<td>

2\.

</td>  
<td>

Clearly identify responsibilities for data management in your project

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

</td>  
<td>

3\.

</td>  
<td>

Describe costs and potential value of long term preservation

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

Data security

</td>  
<td>

1\.

</td>  
<td>

Address data recovery as well as secure storage and transfer of sensitive data

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

Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former

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

Other

</td>  
<td>

1\.

</td>  
<td>

Refer to other national/funder/sectorial/departmental procedures for data
management that you are using (if any)

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

TABLE 1: FAIR Data Management -Horizon 2020 DMP

Page of **21**  
  
<table>  
<tr>  
<th>

**DMP Component**

</th>  
<th>

**WP1**

**Neuronal recordings**

</th>  
<th>

**WP2**

**Network Modelling**

</th>  
<th>

**WP3**

**Hardware Controller**

</th>  
<th>

**WP4**

**Smart House interface & control **

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

Data Summary

</td>  
<td>

  1. Predictive brain activity and predictive neural planning and the technological use of these results. 

  

  2. Data types will be multiunit neuronal data [Cerebus (Blackrock Microsystem) file types: *.nex, *.nsx, *.ccf]; behavioural data: *.csv; and videotracking data [Plexon CinePlex Studio (Dallas, Texas, United States)]: 

  

  

*.dv3, *.avi, *.dvt. 

  4. N/A. 

  

  5. Neuronal data is recorded from the PRR, PMd, M1 and SMA regions. (6) Expected size of the 128 channels neuronal data will be from GBs to TBs. 

  

  

(7) Neuronal data will be transferred to WP2.

</td>  
<td>

(1) Simulated spike train data, model network data, and simulation / virtual
experiment parameter data. (2) Data will provide virtual point of reference
and comparison for primate data for which ground truth is known.

  3. Spike data in .npy and 

  

  

HDF5, model data in .npy, HDF5, CSV or .txt, parameters in CSV or .txt (may
eventually migrate to PANDAS).

  4. N/A. 

  

  5. Neural network simulations. 

  

  6. Uncertain; depends on completeness of network ground truth required; will be between ~10 MB and 1 GB per virtual experiment. (7) Uni-Goe, Primate Lab, SDU. 

  

  

</td>  
<td>

(1), (2) Data represents network topologies and methods (software) for complex
temporal signal processing of recordings or brain model outputs for the device
interface, i.e., smart house interface.

  3. Data type will be C, C++, and VHDL programming codes and network topology diagrams providing implementation independent documentation. 

  

  4. A part of the software is from our MOdular Robot COntrol environment. 

  

  5. Embodied AI and Neurorobotics Lab at SDU. 

  

  6. Probably 5 GB. 

  

  7. The data will be useful for smart house control (WP4) within the project and other developers as well as robotic community in the domain of FPGA-based signal processing and control. In a more general perspective, the presented methods are useful for generic brain machine interfaces working on task and intention recognition level. 

  

  

</td>  
<td>

(1), (2) Service interface data with universAAL service into Living Lab. Data
for communication with uviversAAL Smart House living Lab service.

  3. Data Type will be universAAL Device Ontology and JSON. 

  

  4. N/A. 

  

  5. Smart House Living Lab. 

  

  6. Not know, probably kbs. 

  

  7. The data will be used for the FPGA of WP3. 

  

  

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

FAIR Data.

Making data findable, including provisions for metadata.

</th>  
<th>

(1), (2), (3), (6) Converted neuronal data are discoverable and recognizable
through Hierarchical Data Format (HDF5), comma separated files (metadata).

  4. N/A. 

  

  5. WP1 does not apply versioning on the raw data. 

  

  

</th>  
<th>

(1), (2), (3) HDF5 and / or PANDAS.

(4), (5) N/A.

(6) Included timestamp, model parameters, and virtual experiment parameters.

</th>  
<th>

(1), (2), (3) Data (developed software) are discoverable and recognizable
through a

Git repository

(https://github.com).

  4. Plan4Act software, smart house control, brain signal processing. 

  

  5. Clear versioning will be identified by Git commit message. 

  

  6. N/A. 

  

  

</th>  
<th>

(1), (2), (3) Data are discoverable and recognizable through universAAL
platform by using RDF and ontologies.

  4. N/A 

  

  5. Clear versioning will be used during development taking into account backward compatibility. 

  

  6. N/A. 

  

  

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

Making data openly accessible

</td>  
<td>

  1. Some parts of the recorded neuronal data (already converted into HDF5 format) will be made openly available within the consortium. 

  

  2. Neuronal, behavioural and video-taped data will be hosted on institutional local servers with individualized access to the consortium. 

  

  3. Still in development. (4) Local servers at DPZ. 

  

  

</td>  
<td>

  1. Spike data and parameter files will be made available within the consortium, as will some elements of simulation code after publication of papers for which the same simulation framework is used. 

  

  2. Data will be stored on GWDG servers; spike train data and simulation code will be made public following publications according to standards of journals. 

  

  3. Still in development / negotiation. 

  

  4. Local GWDG servers. 

  

  5. Password protected SSH; subject to change. 

  

  

</td>  
<td>

  1. Data (software for FPGAbased complex temporal signal processing, smart house interface, and device control) will be made openly available through GitHub. Special methods are not required to access the data. 

  

  2. Data and related information will be hosted and available on GitHub. 

  

  

(3), (4) N/A.

(5) Data will be publicly available.

</td>  
<td>

(1), (3) Data describing devices will be opened within universAAL platform
though REST interface with authentication.

(2) Data will be hosted at LST servers and client code will be available on
the LST GitLab server.

(5) Access will be managed through JSON Web Token computed with shared
secrets.

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

Making data interoperable

</th>  
<th>

(1), (2) Neuronal data will be converted to standard HDR5 format. Comma

separated files will be used for recording metadata and behavioural data.

</th>  
<th>

  1. All data and metadata is open format, pythonreadable. 

  

  2. Standard where applicable, reference readme / cheat-sheet provided otherwise. 

  

  

</th>  
<th>

(1), (2) Standards and interoperability will be provided as a manual of using
the software. This will be available through GitHub.

</th>  
<th>

(1), (2) Standards and interoperability will be provided through universAAL.

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

Increase data reuse (through clarifying licences)

</td>  
<td>

(1), (2) Data from WP1 will be licenced within the consortium under request.

(3) Unlikely for raw data. (4) Automated quality assurance.

(5) As long as servers remain active.

</td>  
<td>

  1. Data will be openly licensed within consortium, and under GNU or CC license after publications. 

  

  2. As quickly as possible within consortium; in accordance with journal standards following publication. 

  

  3. Unlikely for data; possible for simulation code (which is based on an already existing framework), but we maintain flexibility. (4) Readability and unit check upon storage on subsample of data. 

  

  

(5) As long as servers remain active.

</td>  
<td>

(1), (2) Data will be licensed under the free Software Foundation GNU
licenses.

  3. Data will be available and useable by third parties including after the end of the project. 

  

  4. Unit tests on sample data will provide automated quality assurance, manual tests will 

  

  

be performed on demonstrators.

  5. Data will be available online for undefined length of time on GitHub. 

  

  

</td>  
<td>

(1), (2) Data will be licensed with credential under requests.

  3. The reuse of data will be available under request after the end of the project. 

  

  4. N/A. 

  

  5. The data will remain available fur undefined length of time. They will be integrated into Smart House Living Lab. 

  

  

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

Allocation of resources

</td>  
<td>

(1) Short-term costs will be covered by the Plan4Act project. Long-term costs
will be covered by the DPZ. (2) DPZ is responsible of WP1 data.

(3) Currently not known.

</td>  
<td>

  1. No additional costs anticipated. 

  

  2. UGoe is responsible for relevant data. 

  

  3. Currently uncertain, no costs anticipated. 

  

  

</td>  
<td>

  1. No costs are expected. 

  

  2. SDU is responsible of WP3 data. 

  

  3. No costs. 

  

  

</td>  
<td>

(1) No costs are expected. (2) UPM is responsible of WP4 data.

(3) No costs.

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

Data security

</td>  
<td>

(1) Recorded neuronal, behavioural, metadata and video-taped data will be
stored on local computers, local servers with additional backup systems
applied locally.

</td>  
<td>

(1) Data stored on local

UGoe / GWDG servers with additional local backups by

GWDG.

</td>  
<td>

(1) Data backup will be done by DeIC data (DeIC – Danish eInfrastructure
Cooperation).

</td>  
<td>

(1) Data and service backup, access control and encryption with common
protocols HTTPS, JWT, etc..).

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

Ethical aspects

</td>  
<td>

Ethic approval is available on use of animals.

</td>  
<td>

N/A

</td>  
<td>

N/A

</td>  
<td>

N/A

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

Other

</td>  
<td>

N/A

</td>  
<td>

N/A

</td>  
<td>

N/A

</td>  
<td>

N/A

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

TABLE 2: FAIR Data Management- Plan4Act.

**3\. Plan4act Data Management Plan**

Sections below establish the base for the Data Management Plan.

On one hand, we present the Data Life Cycle (DLC) and, on the other hand, we
present the flow of data generated by our project.

The data life cycle provides a high-level overview of the stages involved in
successful management and preservation of data for use and reuse (Figure 1).

Plan4Act data flow shows the path for the data we create on our project
(Figure 2).

With this combination, we show the relationship established between DLC and
how the data meets the established requirements over their life (Figure 3).

**Figure 1: Data management life cycle**

The Data Life Cycle has six components:

**“CREATING DATA”:** description of the data that will be created, and how the
data will be managed and made accessible throughout its lifetime. Data are
accurately and thoroughly described using the appropriate metadata standards.

**“PROCESSING DATA”:** description of the data that will be captured, checked
and validated, as well as where they will be stored.

“ **ANALYSING DATA”:** data are analysed, interpreted and produce research
outputs.

“ **PRESERVING DATA”:** data are submitted to an appropriate long-term
archive.

“ **GIVING ACCESS TO DATA”:** Internally distributing data, sharing data,
controlling access.

**“RE-USING DATA”:** data must be provided under terms that permit re-use and
redistribution including the intermixing with other datasets.

**Figure 2: Data creation, sharing, and flow between WPs in the project.**

**Figure 3: Data flow within and across WPs for Plan4Act**

Based on the previous diagram “Data flow within and across WPs for Plan4Act”
(Figure 3), we identify four different sources of data that corresponds to the
work packages in the project.

In the following, we describe the objectives for each WP to illustrate more
clearly the data transitions and flows.

First source identified is **Neuroscientific** data that correspond to **WP1 –
“Neuronal recordings** ”. The objective of WP1 is to identify neural activity
patterns in the monkey neocortex predicting planned action sequences in
complex environments. The first objective is to establish advanced SmartCage
equipped with human-like haptic interfaces and a behavioural paradigm for
action sequence planning in unrestraint monkeys. The second objective is to
record massively parallel neural brain activity wirelessly from many
individual neurons simultaneously (100-200 microelectrodes) in 2-3
sensorimotor areas of the cerebral cortex during such action-sequence
planning.

Second source corresponds to “ **WP 2- Network modeling”** .

Based on the experimental data from WP1, the central goal of WP2 is to develop
a neural network model predicting the sequence of planned actions based on the
interaction between the input and the selforganized structure of the network.
These results serve as basis for the neural controller developed in WP3.

Third source corresponds “ **WP3- Hardware controller”.**

The central objective of this WP is to develop a generic hardware adaptable
network controller based on cell assemblies developed in WP2. The standalone
adaptable controller will directly interface to the neural recording system
(WP1) and the smart house system (WP4). It will process recorded sequence-
predicting neural activity (WP1), predict the upcoming sequence of actions,
and generate the corresponding complex action sequences to manipulate the
smart house (WP4).

Fourth and last source corresponds “ **WP4- Smart House interface &
controller” ** .

The central objective of this WP deals with transferring sequence-predicting
neural activity of monkey (WP1) thorough the adaptive neural control (WP3) for
smart house controls.

Given the identified sources and Data Management Life cycle, described before,
as a fundament, in the following sections we will describe the type of data
generated during this project in each work package on each of the data
management steps.

Some work packages might use only parts of the life cycle; for instance, WPs
involved in meta-analysis might focus on the Create, Process, and Analyze
steps, while a WP focusing on primary data collection and analysis might
bypass the Create and Analyze steps. In addition, other WP s might not follow
the linear path depicted here, or reiterating the cycle might be necessary.

The data life cycle serves as a navigation tool for the Plan4Act Project,
facilitating partners in discovering recommendations on how to effectively
work with their data across all stages of the data life cycle.

#  3.1 Creating data

##  3.1.1 WP1 – Neuronal recordings

**Classify data:**

  * 128 channel neuronal data is recorded by Cerebus Neural Signal Processor (Blackrock Microsystem, Salt Lake City, Utah, United States). Couple of Cerebus file types will be recorded. The .nev files contain digitized extracellular electrode spike information. The *.nsx files contain the digitized raw data using continuous sampling rate. Configuration information of the recording are saved into *.ccf files (Cerebus Configuration File). 

  

  * Monkeys are video-taped during the experiment. Video data is recorded by Plexon CinePlex Studio (Dallas, Texas, United States) with four cameras as input sources. The frame rate of the recorded video is 60 fps. 3D Video Tracking information of the monkey`s movement is saved into *.dv3 file. Video format is *.avi, and the program saves digital video tracking information as well using *.dvt text format. 

  

##  Describe data and create metadata

  * Neuronal data is recorded by Blackrock high-performance DAQ system using Cerebus Neural Signal Processor. Details of the file specifications are available online. 

  

(http://support.blackrockmicro.com/KB/View/166838-file-specifications-packet-
details-headersetc).

  * Metadata of the neuronal and the video data is stored in comma separated files (cvs file type). 

  

  * Metafile has the following information about the recorded data (behavioural, electrophysiological data). 

    * Date of the recording 

  

    * Name of the online sorted spike data 

  

    * Headstage informations 

  

    * Orientation of the antenna 

  

    * BR_bank 

  

    * Input area (e.g. PMd, PRR, M1) 

  

    * Behavioral and log data of the task 

  

    * Name of the video file 

  

    * Name of the monkey 

  

    * Experimenter 

  

    * Name of the task 

  

    * Config file of the task 

  

    * Notes 

  

  

###  3.1.2 WP 2- Network modeling

**Classify data:**

 Python simulation code, spike data, and metadata will be produced.

##  Describe data and create metadata

● All simulations will be done in Python. Code will be made available. At
least initially, the BRIAN simulation framework will form the core of the
simulator. Results will be saved, depending on specifics, in .npy, HDF5, or
PANDAS format, with parameters saved in plaintext (.txt) or CSV, possibly
integrated into PANDAS when applicable.

**3.1.3 WP3- Hardware controler**

##  Classify data

 WP3 is working on recordings obtained from Monkey experiments (WP1) and
Neuronal Network Modelling (WP2/3). These data sets are subject to the
management life cycle defined by the corresponding collaborators. Reduced test
data sets will be provided directly with the source code.

##  Describe data and create metadata

 The processed brain-activity data for controlling devices in the smart house
of UPM is intended for online-use. The processed command stream for the smart
house is not stored, as it reprocessing with the provided methods will
regenerate the output stream (derived data). Links to published data from
WP1/2 will be provided with the programming codes.

**3.1.4 WP4- Smart House interface & controler. **

##  Classify data

  * Request/Response data to universAAL Smart House controller service. 

  

Format will be:

  * Json for service interface, 

  

  * Device Ontology of universAAL contextbus 

  

**Describe data and create metadata**

  * 3D Living Lab data model. 

  

#  3.2 Processing Data

**3.2.1 WP1 – Neuronal recordings**

##  Data capture process

  * Task control software is written in C++ programming environment and the task control software uses animal and task specific configuration files in comma separated files to run the appropriate task. Neuronal data are recorded from the parietal reach region, dorsal premotor cortex, primary motor cortex and supplementary motor cortex using chronically implanted floating microelectrode arrays. During the experimental recording, we use real-time behavioural video surveillance to track the movements of the animals. We dye one of the wrist of the animals. That dyed point serves as tracking point of the arm. Cover of the wireless transmitter positioning in the top of the head of the animal serves as second tracking point. These video-tracking information are used as a behavioural control of the plan and movement related neuronal signals. 

  

**Check, validate.**

  * First, comma separated metafiles are used to match behavioural, video-tracked and neuronal data. Behavioural data will be pre-processed in Matlab. 

  

Second, video-tracked data will be pre-processed in Plexon CinePlex Studio.
Plexon CinePlex Studio software will be used to obtain the three-dimensional
spatial coordinates of the tracking point. Third, recorded neuronal data will
be pre-processed using Plexon Offline Sorter then the data (e.g. spike, LFP
data) will be converted to HDF5 format. HDF5 format is widely used file format
to store and to organize large amounts of data. The following pre-processing
steps will be done in Matlab environment (MathWorks, Natwick, Massachusetts,
United States).

##  Manage and store data in local database

 The recorded neuronal, behavioural, video and metadata will be stored
locally on the recording computers. After each recording session, these data
are backed up into our local servers (e.g. NAS).

##  Transfer data

 Pre-processed and extracted neuronal signals will be transferred to WP2
using local file servers with individual access to the consortium.

**3.2.2 WP 2- Network modeling**

##  Data capture process

  * Data saved directly from simulation. 

  

**Check, validate.**

  * Random validation checks on storage. 

  

**Manage and store data in local database**

  * Data directly saved on local storage and GWDG servers. 

  

##  Transfer data

 Access to local servers as possible, details still in negotiation.

**3.2.3 WP3- Hardware controler**

##  Plan consent for internal sharing

 Data will be internally shared through owncloud/nextcloud of the ENS lab
with password protection.

##  Local data location

 Offline data will be stored in standard hdf5 format in accordance to the DPZ
data storage. Online data between the Embedded FPGA-based signal processing
and control platform and that smart house, will be wrapped in a JSON-based
protocol which will be sent over HTTPS for security.

###  3.2.4 WP4- Smart House interface & controller

Data for service interface are processed at each service call in real-time in
order to change device states. Data related to the 3D Living Lab simulator are
processed into a binary application.

##  Plan consent for internal sharing (data shared, consent)

 3D Living Lab simulator will be based on Open Scene Graph Binary (osgb)
format, anyway it will be embedded into a binary application.

##  Local data location

 Sensible data that are related to the identification of the devices of the
Smart House Living Lab are stored in MySQL database owned by LST.

#  3.3 Analysing Data

**3.3.1 WP1 – Neuronal recordings**

##   Interpret data

Statistical analysis will be done in Matlab and R programming environment
using HDF5 and/or comma separated files (*.csv). Matlab and R codes will be
saved as *.m and *.r files, respectively. For illustration purposes we use
*.jpg, *.png, *.svg file types.

##   Produce research outputs

Research outputs are produced by Matlab and R Scientific manuscript(s) will be
made by Microsoft (Redmond, Washington, United States) Word software.

**3.3.2 WP 2- Network modeling**

##   Interpret data

All data analysis will be done in Python. Results will be saved, depending on
specifics, in .npy, HDF5, or PANDAS format.

##   Derive data

All simulations will be done in Python. Code will be made available. At least
initially, the BRIAN simulation framework will form the core of the simulator.
Results will be saved, depending on specifics, in .npy, HDF5, or PANDAS
format, with parameters saved in plaintext (.txt) or CSV, possibly integrated
into PANDAS when applicable.

##   Produce research outputs

All research will come from Python; technical writing will be performed in
LaTex.

**3.3.3 WP3- Hardware controler**

##   Interpret data

Data analysis will be implemented in C++ and Python, data will be stored in
HDF5 and plaintext (CSV) files, whatever is most appropriate in the context.
The FPGA will be programmed in VHDL.

##   Derive data

Derived data will be provided implicitly by the generating programs with
suitable parameter sets.

##   Produce research outputs

Technical writing will be performed in LaTeX, the research output will be the
processed by C++ and Python programs.

**3.3.4 WP4- Smart House interface & controler. **

N/A

**3.4 Preserving Data.**

Each WP preserve data as entities that will work with their own data, as well
as a common project where data sets will be shared and preserved.

##  WP1- Neuronal recordings

From the beginning of the project, all raw data collected in the
neurophysiological experiments of WP1 will be stored on a central
institutional server. Data on this server is subject to automated backups (a)
for mirroring, i.e. keeping a mirror-image of the data on hardware which is
physically separate from the original data-storage, and (b) for incremental
backup, i.e. providing long-term storage of the data without overwriting or
deleting older versions of the data.

##  WP4- Smart House interface & controller

Data of WP4 related to the service interaction are preserved into the servers
of LST.

Backup and applications developed during the project will be also available
into the GitLab repository of LST (
_https://gitlab.lst.tfo.upm.es/users/sign_in_ ).

**3.5 Giving access to Data.**

Internal Access will be provide for each partner to ensure accessibility,
security and confidentiality of the data.

##  WP1- Neuronal recordings

From the beginning of the project, neurophysiological and metadata collected
in WP1 will be available for the consortium partners upon request. Data will
be made accessible via commercial file sharing software (OwnCloud)
administered by the institute’s IT department.

##  WP4- Smart House interface & controller

Data access in WP4 is provided through REST services in JSON format. These
services allow to the clients coming from WP1 and WP3 to interact with the
devices of the Smart House Living Lab. In order to access to the services,
they are required:

 confidentiality and  authentication.

Confidentiality is guaranteed by using HTTPS connection that hide the data
sent into the requests to the services, while authentication is guarantee
through the secure signatures based in Json Web Token  [ _rcf7519_ ]  with
expiration time.

**3.6 Re-Using Data.**

##  WP1- Neural recordings

Collection of empirical data in cognitive systems neuroscience with non-human
primates is very demanding and time-consuming, resulting in project durations
of typically a few years. At the same time, the complexity of the data is
substantial.

The high value of the data and its complexity lead to a situation, in which a
successfully collected data set is mostly being used over many years following
the end of the immediate data collection period, with publications being
published sometimes 10 years later.

To make this possible, data is stored and documented in a way that analysis of
the data over many years is possible by different scientists in the lab and by
collaboration partners.

**WP4- Smart House interface & controller. **

Services and their related data, developed in WP4, will be available and
reused for further projects and applications also after the lifetime of
Plan4Act.

**3.7 Plan4Act Open Access.**

Open access can be defined as **the practice of providing on-line access to
scientific information that is free of charge to the reader** .

In the context of Research and Development, Open Access typically focuses on
access to “scientific information”, which refers to two main categories:

 Peer-reviewed scientific research articles (published in academic journals);
 Scientific research data (data underlying publications and/or raw data).

The European Commission sees Open Access not as an end in itself but as a tool
to facilitate and improve the circulation of information and transfer of
knowledge in the European Research Area (ERA) and beyond.

###  3.7.1 Open Research Data Pilot in Horizon2020

**Open data** is data that is free to use, reuse, and redistribute. The Open
Research Data Pilot aims to make the research data generated by Horizon 2020
projects open.

Requirements are:

  * Develop (and keep up-to-date) a Data Management Plan (DMP). 

  

  * Deposit your data in a research data repository. 

  

  * Make sure third parties can freely access, mine, exploit, reproduce and disseminate it. 

  

  * Make clear what tools will be needed to use the raw data to validate research results (or provide the tools themselves). 

  

This deliverable “Data Management Plan" itself is part of the requirements.
Other requirements will be achieved providing the free data access and the
tools required.

Plan4Act aims to deposit the research data needed to validate the results
presented in the deposited scientific publications, ideally via a data
repository.

We consider use the OpenAIRE/CERN solution created to H2020 outputs the ZENODO
repository. Plan4Act repository will be created on Zenodo under Science
Community.

_https://www.openaire.eu_ _https://zenodo.org/_ .

#  3.8 Conclusions

This deliverable shows the data creation flow along this project. At this
stage, Data Management Plan for Plan4Act is a live document that will be
updated in accordance with the stages of the project.