Executive Summary  5

Introduction  6

Legal framework  7

Grant agreement and Consortium agreement  7

Personal data protection in MUV: EU regulations  7

Open Access in H2020  8

MUV’s Data management plan (DMP)  8

Data summary  8

Data localization and metadata  12

Making data openly accessible  14

Making data interoperable  17

Responsibilities for data management  17

Data re-use  19

Data security  20

Conclusions  20

Annex I data sources  21

###  Abbreviations  
  
<table>  
<tr>  
<th>

CA

</th>  
<th>

Consortium Agreement

</th>  
<th>

EURAXES

</th>  
<th>

European Charter for

Researchers and Code

Conduct

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

CSV

</td>  
<td>

Comma-separated Values

</td>  
<td>

ECGA

</td>  
<td>

European Comission Grant Agreement

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

DFS

</td>  
<td>

Distributed File System

</td>  
<td>

GDPR

</td>  
<td>

Eurpean Genera Data Protection Regulation

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

DMP

</td>  
<td>

Data Management Plan

</td>  
<td>

MUV

</td>  
<td>

Mobility Urban Values

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

IPR

</td>  
<td>

Intellectual Property Rights

</td>  
<td>

SQL

</td>  
<td>

Structured Query Language

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

EB

</td>  
<td>

Ethics Board

</td>  
<td>

NO-SQL

</td>  
<td>

Not Only Structured Query Language

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

EC

</td>  
<td>

European Comission

</td>  
<td>

WP

</td>  
<td>

Work Package

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

#  Executive Summary

This deliverable contains the first version of the Data Management Plan (M6).
It describes the nature of the data that will be collected and used during the
MUV project. The data has been divided into four overarching data categories:

  * **Participants’ data** . MUV is a research project that will involve real users during some of its research activities. Our research involves the collection of personal data, first, for requirement elicitation, second, for valuation purposes and, third, to improve the quality of experience within a real-time feedback loop. 

  

  * **Data for expert systems** . As stated in D6.1, MUV envisions to use several distinct data sources to feed the recommendation engine, one of the central components of the MUV platform. This data will be used by the application to take decisions in order to offer and promote more sustainable mobility decisions to the users. 

  

  * **Data for evaluation** . Also identified in D6.1, different data sources have been selected to measure the impact of the MUV project. These datasets are either from the data generated by the application, from the data collected for the expert systems or from external data sources (like national statistics institutes). These datasets will be the base for publication of research papers. 

  

  * **Code** . Files containing the code of the platform is considered also as output data of the project. These datasets are designed for compilation/interpretation by a compiler/interpreter of the specific language. This category also comprehends the configuration files and scripts needed to run any needed tool. 

  

It also describes the governance model of this data which is based on several
aspects: i) the current legislation, ii) the ethics related to working with
data, iii) the technical aspects regarding data storage and processing and iv)
the responsible parties for collecting and accessing the data.

#  Introduction

This deliverable reports the management procedures that will be followed when
dealing with the data of MUV, including generated datasets, gathered datasets,
research data and code. It has been designed to be compliant with the
Guidelines on FAIR Data Management in Hoirizon 2020  1  and reviewed with the
Checklist for a Data Management Plan v4.0  2  . Due to the evolving nature of
MUV and its methodology, based on co-creation design and AGILE development,
the datasets of MUV will be collected (or even created) during and after the
project lifetime. Moreover, MUV is a project with many different datasets.
Hence, MUV has envisioned several deliverables to report different aspects of
data. Specifically:

**D6.1 Data Preparation (M6):** This deliverable has been already submitted
and presents in detail the different datasets that will be processed and
valorised in MUV and the techniques that will be used to prepare them for
further analysis.

**D1.4 Data Management Plan (M7):** This deliverable, which deals with the
management procedures of all the data generated or used in MUV, including the
code and the research data (publications).

**D6.2 Detailed data management and privacy plan (M10):** This deliverable
will specify the procedures for the privacy and security of the data collected
and generated in MUV (including anonymization).

**D1.4 Data Management Plan - Update (M19, M31):** Updates of the DMP to adapt
to the evolving nature of MUV.

**D10.1 H - Requirement No. 1 (M10):** Details on the procedures and criteria
that will be used to identify / recruit research participants, including how
to ethically manage this data. **D10.2 POPD - Requirement No. 2 (M10):**
Confirmation by all the competent Data Protection Officers from the National
Data Protection Offices, including the files declared with personal data and
how they will be managed according to the legislation and with ethical
considerations.

**D10.3 GEN - Requirements No. 3 (M4):** The Ethics report including how to
ethically treat the data generated in MUV.

In order to avoid information repetition, but at the same time produce a self-
contained deliverable, this D1.4 will summarize the identified categories of
datasets envisioned in MUV and will include all the tables describing these
datasets in the Annex. More information regarding specific procedures on how
to prepare the data for data quality and for data re-use will be found in
D6.1. Information about the procedures to secure the data and assure its
privacy will be found in D6.2. Any ethical consideration will be found in the
deliverables of WP10, specifically D10.1, D10.2 and D10.3.

#  Legal framework

The objective of this section is to describe the legal framework of the
project linked with the data policy. In this sense this section reviews the
IPR framework established by the ECGA, the Consortium Agreement (CA) and the
overarching European legislation regarding data protection.

##  Grant agreement and Consortium agreement

MUV has not participated in the Research Data Pilot (article 29.3 of the ECGA)
hence this legal framework on data management derives from the articles of the
ECGA and the CA. Of them, main points to take into consideration are the
following:

· The ECGA defines in article 26 the ownership of the project results. These
results are any tangible or intangible output of the actions including data
and information and are owned by the institution that generates them. In case
the results are generated by two or more institution rules defined in article
26.2 of the ECGA and article 8.2 of MUV’s CA must be applied.

· Unless it goes against the legitimate interest of the beneficiaries the
results must be disseminated by disclosing them. This means that the
beneficiaries have the right to protect the results in case the institution
plans to protect or exploit the results.

· As defined in the article 8.4 of the CA 30 calendar days prior to any
publication notice must be given to the other parties. Objections must be
raised in writing within 15 calendar days after the receipt of the notice. The
publication will be permitted if no objection is made within this time limit.

##  Personal data protection in MUV: EU regulations

The project is committed to observe the EU Data Protection Directive 94/46/EC
when dealing with data and the forthcoming European General Data Protection
Regulation.

MUV has a whole Work Package dedicated to Ethical Issues (WP10). This WP will
deal and manage all ethical issues that arise during the project lifetime,
including those related to data gathering, publications and datasets. MUV also
leverages on an Ethics Board (EB), which is an external group of experts with
special competences in Ethics, protection of personal data and security. Upon
request of the EC the consortium established an EB, as they could provide
valuable knowledge, advice and guidance on the work planned in the project and
the data related to it.

IPR’s and exploitation rights (including data) are extensively covered in D1.3
“Plan for managing Knowledge and Intellectual Property” (M7).

#  Open Access in H2020

The workflow related to publications is clearly stated in the CA (article 8),
and further evolved in D1.3. The same instructions are provided in MUV’s
Project Management Handbook.

MUV will attempt to open access to datasets with multiple purposes. Most of
these datasets can be reused, but the terms of use will be properly specified.
It is expected that during the project certain contents can be generated and
they can be of interest for researchers. With this purpose, the project will
identify which datasets can be made public, and which only re-used by project
members. This will be treated on a case-by-case basis. Data research will be
published following the same approach as for publications. This means that
data will be accessible within the 6 months after its publication.

#  MUV’s Data management plan (DMP)

##  Data summary

**Purpose of the data collection**

MUV project envisions four main categories of data to be collected during the
project lifetime.

  * **Participants’ data** . MUV is a research project that will involve real users during some of its research activities. Our research involves the collection of personal data, first, for requirement elicitation, second, for valuation purposes and, third, to improve the quality of experience within a real-time feedback loop. 

  

  * **Data for expert systems** . As stated in D6.1, MUV envisions to use several distinct data sources to feed the recommendation engine, one of the central components of the MUV platform. This data will be used by the application to take decisions in order to offer and promote more sustainable mobility decisions to the users. 

  

  * **Data for evaluation** . Also identified in D6.1, different data sources have been selected to measure the impact of the MUV project. These datasets are either from the data generated by the application, from the data collected for the expert systems or from external data sources (like national statistics institutes). These datasets will be the base for publication of research papers. 

  

  * **Code** . Files containing the code of the platform is considered also as output data of the project. These datasets are designed for compilation/interpretation by a compiler/interpreter of the specific language. This category also comprehends the configuration files and scripts needed to run any needed tool. 

  

**Relation to the objectives of the project**

MUV general objective is to “ _lever behavior change in local communities in
an entirely novel approach to reducing urban traffic. Rather than focus on
infrastructure, it raises citizen awareness on the quality of the urban
environment to promote a shift towards more sustainable and healthy mobility
choices. MUV solutions will be open, co-created with a strong learning
community of users and stakeholders, and piloted in a set of diverse urban
neighborhoods spread across Europe: Amsterdam (NL), Barcelona (ES), Fundao
(PT), Ghent (BE), Helsinki (FI), Palermo (IT). In order to ensure the
effectiveness of the mobility solutions and really match the communities and
stakeholders’ needs, all the project’s main activities (co-creation sessions,
software development and impacts’ analysis) will iterate three times during
the piloting phase._

_Real impact is measured with an evidence-based approach to maximize economic
viability and Social Return on Investment (SROI) and drive replicability and
the scaling up and out of MUV solutions._ ”

From the objective definition, it raises naturally the need for the three
envisioned categories of data. Firstly, **participants’ data** to be able to
create the communities that will allow MUV solutions to be “ _open, co-created
with a strong learning community of users and stakeholders, and piloted in a
set of diverse urban neighborhoods spread across Europe”_ and to elicit the
requirements of MUV “ _to ensure the effectiveness of the mobility solutions
and really match the communities and stakeholders’ needs”_ .

Secondly, **data for expert systems** to “ _raise citizen awareness on the
quality of the urban environment to promote a shift towards more sustainable
and healthy mobility choices”_ . Finally, **data for evaluation** to measure
real impact “ _with an evidence-based approach to maximize economic viability
and Social Return on Investment (SROI) and drive replicability and the scaling
up and out of MUV solutions._ ”

Relation of data with specific objectives is shown in the Table 1\.  
  
<table>  
<tr>  
<th>

understanding the neighborhoods’ peculiarities and emerging values to **define
an effective behavior change strategy**

</th>  
<th>

A recommendation engine is one of the central components of the MUV platform.
It will be fed with several data sources regarding user profile, environmental
context and public transport system and will produce and present specific
smart and sustainable choices to the user

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

**co-designing site-specific solutions** for better and more liveable urban
environments

</td>  
<td>

Co-creation and co-design is the methodology of the project. Hence, data will
be collected to be able to run these activities (participants’ personal data).
The results of these activities will also be collected (requirements,
validation).

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

**developing scalable digital solutions and technologies** to improve globally
the experience of urban mobility

</td>  
<td>

Heterogeneous datasets will be collected from all the different pilot areas.
These datasets will be obtained through city's open data portals, through the
MUV application and through the monitoring stations of MUV. In conclusion, MUV
data model will be defined to be able to escalate to any new region or area.

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

**raising awareness among citizens** **on the importance of sustainable and
healthy mobility choices** , reducing private vehicular traffic and its
negative externalities (pollution, noise, deterioration of urban
infrastructures, time wasted in traffic jams, cost …) and encouraging local
consumption

</td>  
<td>

Several datasets regarding environmental measurements will be collected,
either from the cities’ open portals or from the monitoring stations installed
in MUV. A visualization of these datasets will be offered to the user to raise
awareness on the topic of sustainable mobility.

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

**analyzing, visualizing and sharing mobility and environmental data** to
build an effective decision support system for multiple stakeholders

</td>  
<td>

As mentioned in the same objective, these

datasets will be collected to fed the recommendation engine and build a
complete decision system.

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

**integrating new co-created mobility solutions into urban policy-making** and
planning processes at neighborhood level

</td>  
<td>

Outputs of the co-creation activities will be collected, with special focus to
requirement elicitation and validation of the solution.

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

**bringing the whole experiment to the market through an innovative business
model** in order to improve urban transportation in crowded neighborhoods and
cities all over the world

</td>  
<td>

MUV data model will be open and scalable to allow the experiment to be moved
to new regions and cities.

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

_Table 1: Relation of gathered data with the objectives of MUV_

**Type and format of the data**

MUV will collect several datasets and the formats of such datasets vary
depending on their sources. Specifically, we can identify 7 types of datasets
inside the three categories described.

  * Participants’ data. 

    1. Personal details of the co-creation participants, like name, age, contact details, etc. The format of this dataset will be a file declared in each national data protection office. 

  
  

  

○ Outputs of the activities, including requirement elicitation and validation
feedback. Format will be unstructured text in tables.

  * Data for expert systems. 

    1. Data from MUV application like users’ profile data or users’ behaviour. Format of these datasets will be SQL tables. 

  
  

  

○ Social media data, extracted from public social network interaction. Format
of these datasets will be non-structured text stored in No-SQL databases.

○ Data from open data portals, including environmental and public
transportation data. Format of this data may vary depending on the specific
portal but it is usually in CSV, XML or JSON format.

○ Monitoring stations data, from the monitoring stations created in MUV.

Format of these datasets will be JSON stored in NO-SQL databases. ● Data for
evaluation

○ User engagement evaluation data, composed by the interaction of the users
with the platform. Will be stored in structured files.

○ Research publications done during the life of MUV. The format of these
publications will be either LATEX  3  or MS-WORD / Open Office.

  * Code 

    1. Code sentences will be stored in language specific files. 

  
  

  

**Origin of the data**

There are six possible origins of the data:

  * Open data portals from the municipalities, connected through an API. 

  

  * MUV application, including the interaction of the user with the application. 

  

  * Social media data from social media networks, specially twitter. 

  

  * MUV monitoring stations data, from the stations created and deployed within the project. 

  

  * Data from the participants in the co-creation activities. 

  

  * Research publications and code created by the MUV researchers / developers. 

  

**Size of the data**

We do not envision very large datasets in MUV but the exact size is difficult
to predict. Datasets from open data portals are in the scale of some megabytes
and data collected by the MUV application can be stored in traditional SQL
tables with one entry per user. In addition, data from the participants is
expected to be of some kilobytes.

Social media data and MUV monitoring stations data is the data that can
represent a higher challenge in terms of size. However, we cannot predict such
size at this moment, since we need to define the frequency and the scope of
this collection through the co-creation activities. Finally, research papers
and code files are usually not exceeding few megabytes.

##  Data localization and metadata.

Data will be stored in a cloud defined in WP4. The cloud infrastructure will
contain a specific module for data storage that will be designed and
partitioned according to the needs of the different datasets regarding
security, format and processing capabilities. Details of this architecture
will be presented in D4.1.

Storing formats for each one of the datasets have been designed and defined in
D6.1 and depend on the needs of each dataset. We will use five types of data
storage technologies

  * Plain files are the oldest and simplest way of storing a data. Data is stored in a file with a specific format. A very known example of this type of storage is the Comma Separated Value (CSV) file, where commas are used to separate different values and end of lines indicate new rows. Files are used because they are easy to transfer and because they can be ingested easily in other storage or processing technologies. 

  

  * Relational Databases are the most known and used storage technology. Relational databases are based on formal tables which contain strongly-typed variables (types of variables like integer, float, string etc. are predefined). For example, a client of a company has a name (string), an age (int), etc. Each new client is a new instance of the table with the same fields but different values. To uniquely identify each instance of the table, a value that never repeats must be selected, this value is called the Primary Key of the table. Moreover, different tables need a connection, for example each client may have ordered several different commands, so there should be a new table which represents each command with its own primary key. 

  

Again each command can be composed by several products, which should be
represented in a new table. The link between different tables is done using a
foreign key (e.g. the id of the client is stored in the command table). The
main advantages of relational databases are their strong schema, which assures
availability of the data, and the specific language designed to operate over
them (called SQL), which facilitates operations and the possibility to apply
any preparation technique directly. The drawbacks are the lack of scalability
(the relations between tables introduce checks and delays) and their poor
flexibility (predefined types and mandatory fields) which do not deal well
with low quality and high volume data.

  * Non-relational databases are a new type of databases which appeared few years ago to deal with the flexibility problems of relational databases. In non-relational databases, usually known as Not Only SQL (NO-SQL), information is stored in documents which contain few mandatory fields and are not strongly-typed. It is on the designer hands to define indices that permit the location of specific documents in a collection of documents. NO-SQL databases are fast, can deal with high volume of data and can store not cleaned data, while at the same time can locate easily the datasets (if the indices are well designed). However, NO-SQL datasets do not allow data processing and connectors with specific external technologies (like Elastic search, R, etc.) are needed. 

  

  * Distributed file systems (DFS) are designed for data processing. In DFS data is partitioned into blocks and distributed among different nodes and partitions. Using this approach, data processing techniques can run in parallel, especially with the use of the MapReduce paradigm  4  . DFS are very convenient for data preparation techniques, especially for high-volume, high-velocity and high-heterogeneity. Moreover, availability is assured through replication. However, they do not contain relations between different datasets and are not designed to easily locate data. 

  

  * Versioning systems are softwares that act as a folder that is uploaded to a server to avoid any possible loss, but that track not only the files included in the folder, but also the changes from one version to another. Versioning systems are used for code development and for paper production. 

  

Naming convention in MUV will follow the tables of identified datasets
explained in D6.1 and also in the Annex I of this document. Moreover, metadata
will be added to open data in order to classify and facilitate location of the
data. This metadata will be in the form of tags regarding the nature of the
data i.e. transport, environmental, etc. For code and research papers, well-
known standards and best practices will be used.

MUV identifies the following stakeholders of the data:

  * Users of the application, that will visualize processed data to help them take more sustainable and healthier decisions. Their interests are on data directly involved with their interaction with the application, e.g. recommendations, pollution map, transit map, etc. 

  

  * MUV developers, that will use MUV data as a base for further developments. Their interests are on data that measures the activity of the users, e.g. profiling of the users and their level of activity in the platform, impact of their activity, etc. they are also interested in the code of the project. 

  

  * MUV evaluators / researchers, that will use MUV data to evaluate or measure the impact of the MUV platform. Their interests are on impact of MUV in the cities, e.g. traffic, pollution, noise, etc. They are also interested in the research publications of the project. 

  

##  Making data openly accessible.

As explained in D1.3, the MUV consortium will attempt to maximise the
visibility and exploitation of the project and its long-term impact, by
providing as many as possible publicly available results that can be easily
discovered and reused. Specifically, appropriately identified datasets
(anonymized end-user data whenever possible according to the “Article 29 Data
Protection Working Party”  5  , as well as, wherever possible, software
releases) will be generated and collected to drive the project’s technical
work. With this purpose, the project will identify which datasets can be made
public, and which only reused by project members. This will be treated on a
case-by-case basis.

Open data

**Open data** will be stored and made available through Symphony (  _Symphony_
)  . Moreover, all datasets regarding municipalities will be also made
accessible through the municipalities’ open data portals.

**Research data** will be made accessible through Zenodo (  _Zenodo_ )

**Code** will be made accessible through github (  _Github_ )

All these datasets will be included in a table detailing the following fields:

  * Type of dataset 

  

  * Format 

  

  * File type 

  

  * Owner 

  

  * Open data set (Y/N) 

  

  * Licensing 

  

  * Comments 

  

When publishing the databases, any needed software tools or tool needed to
access to the data will be included in the description of the data-base.

Table 2 summarizes the level of access to each dataset  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

**Subcategory**

</th>  
<th>

**Openness**

</th>  
<th>

**Comments**

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

Participant’s data

</td>  
<td>

Personal details

</td>  
<td>

Private

</td>  
<td>

Personal details of the participants will be private

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

Outputs of the activities

</td>  
<td>

Confidential / public

</td>  
<td>

outputs of the activities will drive to the requirements and evaluation.
Depending on the nature of the outputs will be kept confidential (within the
consortium) or open

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

Data for expert systems

</td>  
<td>

Users’ profile data

</td>  
<td>

Private / confidential

</td>  
<td>

Personal data will be kept private. Other types of data (profiling) will be
confidential within the consortium for evaluation and improvement needs.

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

Users’ behaviour data

</td>  
<td>

Private/confi dential

</td>  
<td>

Same as previous

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

social media data

</td>  
<td>

Public

</td>  
<td>

Only public social media data will be used.

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

Environmen

tal data

</td>  
<td>

Public

</td>  
<td>

Environmental data is gathered from the open data portal

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

MUV

monitoring stations data

</td>  
<td>

Public

</td>  
<td>

Monitored data will be made public

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

Public transport data

</td>  
<td>

Public

</td>  
<td>

Transport data will be made public

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

Traffic data

</td>  
<td>

Public/confid ential

</td>  
<td>

Publicly available data will be open. We envision the possibility to gather
private traffic data (mainly from google maps) which will be confidential for
use only inside the consortium

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

Data for evaluation

</td>  
<td>

Recommen

dation system input data

</td>  
<td>

N/A

</td>  
<td>

This is a set of parameters to be used as input to the recommendation system.
These are parameters from other already identified datasets and their
confidentiality level will be maintained

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

User

engagemen

t evaluation data

</td>  
<td>

N/A

</td>  
<td>

Same as before

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

KPI evaluation data

</td>  
<td>

Public

</td>  
<td>

KPIs data will be made public for evaluation and maximization of impact.

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

Research publications data

</td>  
<td>

Public

</td>  
<td>

Research publications will be under open or green access.

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

Code

</td>  
<td>

Code files

</td>  
<td>

According to CA

</td>  
<td>

Taking into account firstly the IPR and the Consortium Agreement, code will be
made open when possible.

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

</td>  
<td>

Scripts and configuratio n files

</td>  
<td>

According to CA

</td>  
<td>

Same as before

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

_Table 2: Levels of access for the MUV datasets_

We foresee MUV evaluation data to be used actively and extensively for
research purposes, including the publication of papers to conferences and
journals. Eventually, data for expert systems can also be used for research,
especially in more technical publications regarding data science and
artificial intelligence. We don’t foresee research use for participant’s data,
and if this situation arises, only aggregated results (anonymized) will be
allowed to be published (according to Article 6 of the GDPR  6  ). Data
published in open data portals (and identified in D6.3) will be kept at least
2 years beyond the life of the project. Other data sources will be tied to the
life of the website of MUV (1 year after the end of the project). Any kind of
research data will be held in persistent research repositories. No associated
costs are envisioned for the data repositories. Either research data
repositories and open data repositories are free of charge and maintained by
non-profit organizations or administrations.

Several activities are envisioned in the scope of T6.3 - Open data
valorisation in order to preserve the datasets and to make them persistent and
easy to locate and use. Aspects like open formats, use of standards and linked
data will be taken into account.

If an entity or particular from outside the consortium asks for access to
personal or closed data, the General Assembly will decide either to give
access or not. The proprietary of the data set can exercise his veto as
specified in the CA.

In case there is a request to access private content by a third party/external
entity, the question will be evaluated by the project coordinator and those
partners involved. In case the request is internal, the part requesting access
will contact the project coordinator, who will take it to the General Assembly
(GA) and the GA will evaluate, jointly with the hosting partner, whether it is
possible or not. All decisions will follow the  _European Charter for_
_Researchers and Code of Conduct_ (EURAXESS), the Consortium Agreement and the
Grant Agreement.

##  Making data interoperable.

For research data collected and generated in the project, a fit-for-purpose
file naming convention will be developed in accordance with best practice for
qualitative data, such as described by the UK Data Archive (2011). This will
involve identifying the most important metadata related to the various
research outputs. Key information includes content description, date of
creation, version, and location.

To make the datasets in the platform easily findable searchable tags will be
added to the metadata. When uploading the data the creator of the dataset also
have the option to create new tags that corresponds to the contents of the
dataset making it easier for other users to find and re-use the data.

MUV is strongly committed to produce any kind of data in open formats. For
files, Comma Separated Values (CSV)  7  files will be preferred, when possible
including links to other files and hence, promoting linked data  8  .

Depending on the choice of repositories we are however likely to follow the
standard of The Data Catalog Vocabulary (DCAT) (Data Catalog Vocabulary, 2014)
as it defines a standard way to publish machine-readable metadata about a
dataset where appropriate.

We also intend to use common ontologies and vocabularies for data.

##  Responsibilities for data management.

Each partner will be solely responsible of the quality and accuracy of the
data provided and of making data accessible, table summarizes partners per
datasets. The PC (PUSH) will provide support and advice to the consortium.
Table 3 summarizes these responsibilities for each one of the MUV datasets.  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

**Subcategory**

</th>  
<th>

**Openness**

</th>  
<th>

**Responsible partner**

</th>  
<th>

**Partners with limited accessing rights**

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

Participa nt’s data

</td>  
<td>

Personal details

</td>  
<td>

Private

</td>  
<td>

Amsterdam pilot ->AAU

Barcelona pilot -> I2CAT

Fundao pilot -> BAG

Ghent pilot -> LUCA

Helsinki pilot -> FVH

Palermo pilot -> PUSH

</td>  
<td>

AMST

IMI BCN

FUNDAO

GENT

MUNI PAL

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

Outputs of the activities

</td>  
<td>

Confidenti al / public

</td>  
<td>

Amsterdam pilot ->AAU

Barcelona pilot -> I2CAT

Fundao pilot -> BAG

Ghent pilot -> LUCA

Helsinki pilot -> FVH

Palermo pilot -> PUSH

</td>  
<td>

All

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

Data for expert systems

</td>  
<td>

Users’ profile data

</td>  
<td>

Private / confidenti

al

</td>  
<td>

PUSH

</td>  
<td>

I2CAT, ISMB, WAAG, LUCA

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

Users’ behaviour data

</td>  
<td>

Private/co nfidential

</td>  
<td>

PUSH

</td>  
<td>

I2CAT, ISMB, WAAG, LUCA

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

social media data

</td>  
<td>

Public

</td>  
<td>

ISMB

</td>  
<td>

PUSH, I2CAT, WAAG, LUCA

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

Environment al data

</td>  
<td>

Public

</td>  
<td>

I2CAT

</td>  
<td>

All

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

MUV

monitoring stations data

</td>  
<td>

Public

</td>  
<td>

WAAG

</td>  
<td>

I2CAT, ISMB, PUSH, LUCA

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

Public transport data

</td>  
<td>

Public

</td>  
<td>

I2CAT

</td>  
<td>

All

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

Traffic data

</td>  
<td>

Public/con fidential

</td>  
<td>

I2CAT

</td>  
<td>

PUSH, ISMB, WAAG, LUCA

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

Data for evaluatio n

</td>  
<td>

Recommenda

tion system input data

</td>  
<td>

N/A

</td>  
<td>

ISMB

</td>  
<td>

I2CAT, WAAG, PUSH

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

User engagement evaluation

</td>  
<td>

N/A

</td>  
<td>

ISMB

</td>  
<td>

I2CAT, WAAG, PUSH

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

</td>  
<td>

data

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

KPI evaluation data

</td>  
<td>

Public

</td>  
<td>

ISMB

</td>  
<td>

ALL

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

Research publications data

</td>  
<td>

Public

</td>  
<td>

LUCA

</td>  
<td>

All

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

Code

</td>  
<td>

Code files

</td>  
<td>

According to CA

</td>  
<td>

PUSH

</td>  
<td>

N/A

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

</td>  
<td>

Scripts and

configuration files

</td>  
<td>

According to CA

</td>  
<td>

PUSH

</td>  
<td>

N/A

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

_Table 3: Summary of the responsible partners and partners with accessing
rights to the MUV datasets_

Regarding research data and research publications, prior to uploading any
database to zenodo, the responsible has to inform the GA 30 days in advance.

Every six months the PC will request the consortium for pre-printed
manuscripts (accepted), slides and posters, and non-protected raw data
supporting papers and deliverables for updating the project public repository
in zenodo.

##  Data re-use.

MUV data will be licensed from the creation of the dataset to ensure that it
is used according to the defined terms. Any re-used dataset by MUV will
respect the previous license of the dataset.

**Research Publications** : Each publication will be licensed on a case-by-
case basis, taking into account embargo periods if applicable. Questionnaires
are licensed under Creative

Commons Attribution-Non Commercial 4.0. Video Footage is licensed under
Creative Commons Attribution-Non Commercial 4.0 (strictly forbidden to use it,
totally or partially, for commercial purposes).

**Private data:** Private data will be licensed by the owner (partner) of the
dataset. **Confidential data:** Confidential data will be licensed by the
owner (partner) of the dataset, which has to include the rights to allow the
partners with accessing rights to access to such information.

**Public data:** Public data will be licensed under the Open Data Commons Open
Database

License (ODbL)  9  which is an open license for data (and databases) which
requires attribution (owner of the data must be kept when reusing it) and
share-alike (the same license must be applied when re-using data).

Regarding data quality, D6.1 specifically describes the processes that will be
used to ensure data quality, including cleaning and enrichment (to remove or
correct erroneous samples) and curating to ensure perdurability and easy
classification of the datasets. For publications and research data, all
content will be peer-reviewed.

##  Data security

Data security in MUV will be treated in a specific deliverable, D6.2 Detailed
Data Management and Privacy Plan which is a confidential deliverable that
assures that any security procedure is not disclosed publicly.

#  Conclusions

MUV considers four types of data: Participant’s data, Data for expert systems,
Data for evaluation and Code. In this deliverable we analyze these four types
of data from several aspects. Firstly, its relation with the objectives of the
project. Secondly, the procedures and techniques that will be used to store
them and assure its accessibility. Finally, their nature
(open/private/confidential), their license and their owners.

It is important to note that, except for research data and code, which have
very standardized procedures to define these aspects, all the other datasets
are very heterogeneous (from a wide range of different sources) and with
different privacy, preparation and ethics requirements. Hence, three specific
deliverables must be considered together with the Data Management Plan
presented here, to obtain all the picture of the data activities of MUV.
Firstly, D6.1 for data preparation techniques, including cleaning and
curation. Secondly, D6.2 for data privacy and security, including
anonymization. Finally, D10.1, D10.2 and D10.3 for ethics and legal
requirements regarding data.