#  Executive Summary

PoliVisu aims to establish the use of big data and data visualisation as an
integral part of policy making, particularly, but not limited to, the local
government level and the mobility and transport policy domain. The project’s
relation with data is therefore essential and connatural to its experimental
research objectives and activities.

Additionally, the consortium has adhered to the H2020 ORDP (Open Research Data
Pilot) convention with the EC, which explicitly caters for the delivery of a
DMP (Data Management Plan).

According to the PoliVisu DoA (2017), data management planning, monitoring and
reporting is part of WP2 - the Project and Quality Management work package -
and foresees the delivery of four consecutive editions of the DMP at months 6,
12, 24 and 36.

This first edition, however, is not a mere collection of principles, as it
sets the stage for the ongoing and next activities handling with data, before
and even after the project is completed. As per the DoA description: “ _DMP_ ​
_describes the data management lifecycle for all data sets that will be
collected, processed or generated by the research project. It is a document
outlining how research data will be handled during a research project, and
even after the project is completed, describing what data will be collected,
processed or generated and following what methodology and standards, whether
and how this data will be shared and/or made open, and how it will be curated
and preserved”._

We basically envisage three main data usage scenarios, which jointly compose
PoliVisu’s data management lifecycle:

  * Original data produced by the PoliVisu consortium and/or individual members of it (e.g. during a dissemination action or a pilot activity) 

  

  * Existing data already in possession of the PoliVisu consortium and/or individual members of it prior to the project’s initiation 

  

  * Existing data sourced/procured by the PoliVisu consortium and/or individual members of it during the project’s timeline 

  

The structure of this document is as follows:

  * **Section 1** presents PoliVisu’s data management lifecycle and frames the DMP within the EU H2020 Guidelines and FAIR data handling principles, thus setting the stage for the following parts. 

  

  * **Section 2** is a brief overview of the legal framework, including the EU regulation on personal data protection (GDPR), the H2020 provisions for open access to research data, the specific provisions of the PoliVisu Grant Agreement and Consortium Agreement and some special provisions for big data management. 

  

  * The core of the DMP is **Section** ​ **3** ,​ in which the data usage scenarios are presented and the key issues to be examined in relation to each scenario are discussed. These issues include decisions on e.g. data anonymization, privacy and security protection measures, licensing etc. 

  

  * **Section 4** concludes the document by anticipating the expected contents of future editions of the DMP. 

  

For completeness of information, the reader interested in getting to know how
the PoliVisu consortium plans to deal with data may also refer, in addition to
this DMP, to the following, already or soon to be published, deliverables:
D1.1 (Ethical Requirement No. 4), D1.3 (Ethical Requirement No. 3), D2.2
(Project Management

Plan), D2.3 (Quality and Risk Plan), D6.1 (Pilot Scenarios), D7.1 (Evaluation
Plan) and D8.1 (Impact

Enhancement Road Map).

#  Introduction

Visualisation and management of (big) data in a user friendly way for public
administration bodies is one of the primary goals of the PoliVisu project. The
intention is to support integration of (big) data into policy and decision
making processes. The project’s relation with data is therefore essential and
connatural to its experimental research objectives and activities.
Additionally, the consortium adhered to the H2020 ORDP (Open Research Data
Pilot) convention with the EC, which explicitly caters for the delivery of a
DMP (Data Management Plan).

According to the PoliVisu DoA (2017), data management planning, monitoring and
reporting is part of WP2 - the Project and Quality Management work package -
and foresees the delivery of four consecutive editions of the DMP at months 6,
12, 24 and 36. This first edition, however, is not a mere collection of
principles, as it sets the stage for the ongoing and next activities handling
with data, before and even after the project is completed.

##  The PoliVisu Data Management Lifecycle

As per the DoA description, the PoliVisu DMP “ _describes_ ​ _the data
management lifecycle for all data sets that will be collected, processed or
generated by the research project. It is a document outlining how research
data will be handled during a research project, and even after the project is
completed, describing what data will be collected, processed or generated and
following what methodology and standards, whether and how this data will be
shared and/or made open, and how it will be curated and preserved”._

This paragraph summarizes the management procedures that will be followed when
dealing with the data of relevance for the PoliVisu project, and which will be
further described in Section 3 of this document.

We envisage **three main data usage scenarios** ​ :​

  1. Original data produced by the PoliVisu consortium and/or individual members of it (e.g. during a dissemination action or a pilot activity); 

  

  2. Existing data already in possession of the PoliVisu consortium and/or individual members of it prior to the project’s initiation; 

  

  3. Existing data sourced/procured by the PoliVisu consortium and/or individual members of it during the project’s timeline. 

  

  

For each of the above scenarios, the key issues to be examined are displayed
by the following logic tree:

**Figure 1 – The PolIVisu Data Management Life Cycle**

For each dataset (or even data point) handled in the project, the first level
of control/decision making must deal with its **nature** ​ ,​ notably whether
it has been (or will be) deemed Confidential, or Anonymised and Public (it
cannot be that the two latter things diverge, apart from very special
occasions, which are coped with in the third logical category displayed in the
picture).

Depending on the assessment of nature, the resulting, mandatory **action** ​
**lines** can then be summarized as follows:

  * For any acknowledged **Confidential** ​  1  dataset (or data point), the Consortium and/or each Partner in charge of its handling shall control (if existing) or define (if not) the **Licensing** ​ **rules** and the **Privacy** ​ **and security measures** (to be) adopted in the process.​ 

  

  * For any acknowledged **Anonymised** ​ **and Public** dataset (or data point), the only relevant discipline to be clarified is the set of **Open** ​ **Access rules** that apply to the case. This set is little controversial for PoliVisu, as the ODRP convention has been adopted, as specified above. Note that the use of open data across the PoliVisu pilots, including e.g. Open Transport Maps or Open Land Use Maps, falls in this category. 

  

  * Any dataset (or data point) that does not belong to any of the former two categories is subject to an additional level of action by the Consortium and/or Partner in charge, leading to its classification as either Confidential or Anonymised and Public. In that regard, the two, mutually exclusive action items belonging to this level are: 

  

○ the **anonymisation** ​ **for publication** action, leading to the migration
to the second category of data, or

○ the adoption of appropriate **privacy** ​ **and security measures** (very
likely the same applied to the category of Confidential data) in case
anonymisation is not carried out for whatever legitimate reason. Note that in
this latter case, i.e. without anonymisation, **no** ​ **licensing rules are
applicable** (i.e. the PoliVisu consortium rejects the commercialisation of
the personal profiles of human beings as a non-ethical practice).

##  Reference Framework and Perimeter of the DMP

The following picture – borrowed from the official EU H2020 information portal
2  \- clearly identifies the positioning of the DMP in the context of projects
that – like PoliVisu – have voluntarily adhered to the Pilot on Open Research
Data in Horizon 2020  3  .

**Figure 2: Open access to scientific publications and research data in the
wider context of a project’s dissemination and exploitation (source: European
Commission, 2017)**

As can be seen, a DMP holds the same status and relevance as the project’s
Dissemination Plan  4  . More specifically, in the former document, one should
retrieve the full list of research data and publications that the project will
deliver, use or reuse, as well as the indication of whether some data will be
directly exploited by the Consortium, having been patented or protected in any
other possible form. In the latter document, one should retrieve the
Consortium’s detailed provisions for all data and publications that can be
shared with interested third parties, with or without the payment of a fee  3
.

In particular, the following definitions – all taken from the aforementioned
EU H2020 portal – shall apply to our discourse:

  * **Access** :​ “ _the_ ​ _right to read, download and print – but also the right to copy, distribute, search, link, crawl and mine_ ​”; 

  

  * **Research Data** :​ “ _[_ ​ _any] information, in particular facts or numbers, collected to be examined and considered as a basis for reasoning, discussion, or calculation. In a research context, examples of data include statistics, results of experiments, measurements, observations resulting from fieldwork, survey results, interview recordings and images. The focus is on research data that is available in digital form_ ​”; 

  

  * **Scientific Publications** :​ “ _journal_ ​ _article[s],_ … _monographs, books, conference proceedings, [and] grey literature (informally published written material not controlled by scientific publishers)”_ ​, such as reports, white papers, policy/position papers, etc.; 

  

  * **Open Access Mandate** :​ “​ _comprises 2 steps: depositing publications in repositories [and] providing open access to them_ ​”. Very importantly, these steps “ _may_ ​ _or may not occur simultaneously_ ​”, depending on conditions that will be explained below: 

    * **“Green”** ​ **Open Access (aka Self-Archiving)** ​: it is granted when the final, peer-reviewed manuscript is deposited by its authors in a repository of their choice. Then open access must be ensured within at most 6 months (12 months for publications in the social sciences and humanities). Thus, open access may actually follow with some delay (due to the so-called “embargo period”); 

  

    * **“Gold”** ​ **Open Access (aka Open Access Publishing)** :​ it is granted when the final, peer-reviewed manuscript is immediately available on the repository where it has been deposited by its authors (without any delay or “embargo period”). Researchers can also decide to publish their work in open access journals, or in hybrid journals that both sell subscriptions and offer the option of making individual articles openly accessible. In the latter case, the so-called “article processing charges” are eligible for reimbursement during the whole duration of the project (but not after the end of it). 

  

  

In the PoliVisu **DoA** ​ (2017), the following provisions for Open Access
were defined, which have become part of the Grant Agreement (GA) itself:
_“PoliVisu_ ​ _will follow the Open Access mandate for its publications and
will participate in the Open Research Data pilot, so publications must be
published in Open Access (free online access). Following the list of
deliverables, the consortium will determine the appropriate digital objects
that will apply to the Data Management Plan. Each digital object, including
associated metadata, will be deposited in the institutional repository of
Universitat Politècnico Milano, whose objective is to offer Internet access
for university's scientific, academic and corporate university in order to
increase their visibility and make it accessible and preservable.”_
​Evidently, these provisions belong to the **“Green” Open Access** ​ case.​

As far as patenting or other form of protection of research results is
concerned (the bottom part of Figure 2), the ground for this has been paved by
the PoliVisu Consortium Agreement (2017) - following the DoA, which recognises
that _“formal_ ​ _management of knowledge and intellectual property rights
(IPR) is fundamental for the effective cooperation within the project lifetime
and the successful exploitation of the PoliVisu Framework and tools within and
after the end of the project”_ ​. Further steps towards a clarification of the
licensing mechanisms will be taken in the context of the 3 foreseen editions
of the Business and Exploitation Plan in the context of WP8 (deliverables D8.3
due at month 12, D8.6 due at month 24 and D8.10 due at month 34). As a general
principle, the GA article 26.1 is faithfully adopted in the PoliVisu
Consortium Agreement (CA), according to which “ _Results_ ​ _are owned by the
Party that generates them_ ​”. This is what article 8.1 states. And in
addition, article 8.2 specifies that “ _in_ ​ _case of joint ownership, each
of the joint owners shall be entitled to Exploit the joint Results as it sees
fit, and to grant non-exclusive licences, without obtaining any consent from,
paying compensation to, or otherwise accounting to any other joint owner,
unless otherwise agreed between the joint owners_ ​”.

We take the above provisions also as a **guideline** ​ **for the attribution
of responsibilities of data management** ,​ as far as PoliVisu research
results are concerned. Very shortly, we posit that **ownership** ​ **goes hand
in hand with the responsibility for data management** .​ The latter involves
the same project partner(s) who generate new data, individually or jointly. In
case of reuse of existing data, i.e. owned by someone else (a third party or
another PoliVisu partner), the individual or joint responsibility is to
**check** ​ **the nature of data** (as specified in Figure 1 above) and
**undertake** ​ **the consequent actions** as will be further described also
in Section 3 below.

##  Alignment to the Principles of FAIR Data Handling

Generally speaking, a good DMP under H2020 should comply with the FAIR Data
Handling Principles. FAIR stands for Findable, Accessible, Interoperable and
Re-usable, as referred to a project’s research outputs – notably those made
available in digital form.

The FAIR principles, however, do not belong to H2020 or the EC but have
emerged in January 2014, as the result of an informal working group convened
by the Netherlands eScience Center and the Dutch Techcentre for the Life
Sciences at the Lorentz Center in Leiden, The Netherlands  4  .

Very pragmatically, the European Commission (2016) considers the FAIR
principles fulfilled if a DMP includes the following information:

  1. _“The handling of research data during and after the end of the project”_

  

  2. _“What data will be collected, processed and/or generated”_

  

  3. _“Which methodology and standards will be applied”_

  

  4. _“Whether data will be shared/made open access”, and_

  

  5. _“How data will be curated and preserved (including after the end of the project)”._

  

  

In the case of PoliVisu, the above information is provided in Section 3 of
this document, which consists of five paragraphs, respectively:

  1. Data summary ( _typologies and contents of data collected and produced_ ​ ​) 

  

  2. Data collection ( _which procedures for collecting which data_ ​ ​) 

  

  3. Data processing ( _which procedures for processing which data_ ​ ​) 

  

  4. Data storage ( _data_ ​ ​ _preservation and archiving during and after the project_ ​ ​) 

  

  5. Data sharing (i _ncluding provisions for open access_ ​ ​) 

  

  

The following table matches the aforementioned EC requirements with the
contents dealt with in Section 3 paragraphs.

**Table 1. Alignment between this DMP and the EC’s requirements**  
  
<table>  
<tr>  
<th>

**This document’s Section 3 TOC**

**EC requirements**

</th>  
<th>

**3.1 Data Summary**

</th>  
<th>

**3.2 Data**

**Collection**

</th>  
<th>

**3.3 Data**

**Processing**

</th>  
<th>

**3.4 Data**

**Storage**

</th>  
<th>

**3.5 Data**

**Sharing**

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

**A. “The handling of research data during and after the end of the project”**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

**B. “What data will be collected, processed and/or generated”**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

**C. “Which methodology and standards will be applied”**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

**D. “Whether data will be shared/made open access”**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

**E. “How data will be curated and preserved (including after the end of the
project)”**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

This Introduction has presented PoliVisu’s data management lifecycle and
frames the DMP within the EU H2020 Guidelines and FAIR data handling
principles. The remaining structure of this document comes as follows:

  * **Section 2** is a brief overview of the legal framework, including the EU regulation on personal data protection (GDPR), the H2020 provisions for open access to research data, the specific provisions of the PoliVisu grant agreement and consortium agreement and some special provisions for big data. 

  

  * **Section 3** presents and discusses the data usage scenarios in the framework outlined in the above Table and examines the key issues in relation to each scenario. These issues include decisions on e.g. data anonymization, privacy and security protection measures, licensing etc. 

  

  * **Section 4** concludes the document by anticipating the expected contents of future editions of the DMP. 

  

  * In **Annex** ​ **I** the​ interested reader can find a running list of utilized / relevant data sources, which will be further updated over the course of the project. 

  

#  Legal framework

This section briefly overviews the key normative references making up the DMP
external context. The next paragraphs respectively deal with:

  1. The PSI Directive and its recent modifications and revisions proposals (dated April 2018); 

  

  2. The General Data Protection Regulation, coming into force in May this year; 

  

  3. The terms of the H2020 Open Research Data Pilot (ORDP) the PoliVisu consortium has adhered to; 

  

  4. The resulting, relevant provisions of both the Grant and the Consortium Agreements; 

  

  5. The special provisions for big data management mentioned in the DoA and thus become binding for all partners; 

  

  6. A general outline of PoliVisu’s licensing policy. 

  

  

##  The PSI Directive

The Directive 2003/98/EC on the re-use of Public Sector Information (PSI)
entered into force on 31 December 2003. It was revised by the Directive
2013/37/EU, which entered into force on 17 July 2013. The consolidated text
resulting from the merge of these two legislative documents is familiarly
known as the PSI Directive, and can be consulted on the Eur-Lex website  7  .

On 25 April 2018, the EC adopted a proposal for a revision of the PSI
Directive, which was presented as part of a package of measures aiming to
facilitate the creation of a common data space in the EU. This review also
fulfils the revision obligation set out in Article 13 of the PSI Directive.
The proposal has received a positive opinion from the Regulatory Scrutiny
Board and is now being discussed with the European Parliament and the Council.
It comes as the result of an extensive public consultation process, an
evaluation of the current legislative text and an impact assessment study done
by an independent contractor  8  .

The current PSI Directive and its expected evolution is noteworthy and useful
to define the context of the PoliVisu project in general and of this DMP in
particular. Thanks to the PSI Directive and its modifications and
implementations  9  , the goal of making government data and Information
reusable has become shared at broad European level. In addition, the awareness
has been remarkably growing that as a general principle, the datasets where
PSI is stored must be set free by default. However, fifteen years after the
publication of the original PSI Directive, there are still barriers to
overcome (better described in the aforementioned impact assessment study) that
prevent the full reuse of government data and information, including data
generated by the public utilities and transport sectors as well as the results
from public funded R&D projects, two key areas of attention for PoliVisu and
this DMP.

##  The EU Personal Data Protection Regulation (GDPR)

Regulation (EU) 2016/679 sets out the new General Data Protection Regulation
(GDPR) framework in the EU, notably concerning the processing of personal data
belonging to EU citizens by individuals, companies or

7  8 _​https://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=CELEX:02003L0098-20130717_

9 Available online at:
_​http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=51491_

For instance, the INSPIRE Directive (2007/2/EC) builds mechanisms for data and
corresponding Web services discoverability on top of the PSI Directive. See: ​
_https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32007L0002
&from=en _

public sector/non government organisations, irrespective of their
localization. It is therefore a primary matter of concern for the PoliVisu
consortium.

The GDPR was adopted on 27 April 2016, but will become enforceable on 25 May
2018, after a two-year transition period. By then, it will replace the current
Data Protection Directive (95/46/EC) and its national implementations. Being a
regulation, not a directive, GDPR does not require Member States to pass any
enabling legislation and is directly binding and applicable.

The GDPR provisions do not apply to the processing of personal data of
deceased persons or of legal entities. They do not apply either to data
processed by an individual for purely personal reasons or activities carried
out at home, provided there is no connection to a professional or commercial
activity. When an individual uses personal data outside the personal sphere,
for socio-cultural or financial activities, for example, then the data
protection law has to be respected.

On the other hand, the legislative definition of personal data is quite broad,
as it includes any information relating to an individual, whether it relates
to his or her private, professional or public life. It can be anything from a
name, a home address, a photo, an email address, bank details, posts on social
networking websites, medical information, or a computer’s IP address.

While the specific requirements of GDPR for privacy and security are
separately dealt with in other PoliVisu Deliverables (such as D1.1 on POPD
Requirement No. 4 due by month 6 and D1.2 on POPD Requirement No.

6 delivered at month 3, as well as D4.5 & D4.6 on Privacy rules and data
anonymization, due by months 24 & 30 respectively) it is worth noting here
that the PoliVisu consortium has formed a working group composed of the
partner organisations Data Protection Officers (DPOs). The DPO function and
role has been introduced by the GDPR and better defined by a set of EC
guidelines, given on 13 December 2016 and revised on 5 April 2017  10  .

The GDPR text is available on the Eur-Lex website  11  .

##  Open Access in Horizon 2020

As partly anticipated in Section 1, the EC has launched in H2020 a flexible
pilot for open access to research data (ORDP), aiming to improve and maximise
access to and reuse of research data generated by funded R&D projects, while
at the same time taking into account the need to balance openness with privacy
and security concerns, protection of scientific information, commercialisation
and IPR. This latter need is crystallised into an opt-out rule, according to
which it is possible at any stage - before or after the GA signature - to
withdraw from the pilot, but legitimate reasons must be given, such as
IPR/privacy/data protection or national security concerns.

With the Work Programme 2017 the ORDP has been extended to cover all H2020
thematic areas by default. This has particularly generated the obligation for
all consortia to deliver a Data Management Plan (DMP), in which they specify
what data the project will generate, if it will not be freely disclosed for
e.g. exploitation related purposes or how it will be made accessible for
verification and reuse, and how it will be curated and preserved.

The ORDP applies primarily to the data needed to validate the results
presented in scientific publications. Other data can however be provided by
the beneficiaries of H2020 projects on a voluntary basis.

The costs associated with the Gold Open Access rule, as well as the creation
of the DMP, can be claimed as eligible in any H2020 grant.

As already mentioned, the PoliVisu consortium has adhered to the **Green Open
Access** ​ rule.​

10  11  ​See: ​ _http://ec.europa.eu/newsroom/document.cfm?doc_id=44100_

_​https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016R0679_

##  Grant Agreement and Consortium Agreement provisions

The key GA and CA provisions worth mentioning in relation to our discourse on
data management have been already introduced to a great extent in the previous
Sections. Now we simply reproduce the corresponding articles.

###  Grant Agreement

_24.1 Agreement on background_

The beneficiaries must identify and agree (in writing) on the background for
the action (‘agreement on background’).

‘Background’ means any data, know-how or information — whatever its form or
nature (tangible or intangible), including any rights such as intellectual
property rights — that: (a) is held by the beneficiaries before they acceded
to the Agreement, and (b) is needed to implement the action or exploit the
results.

_26.1 Ownership by the beneficiary that generates the results_ Results are
owned by the beneficiary that generates them.

‘Results’ means any (tangible or intangible) output of the action such as
data, knowledge or information — whatever its form or nature, whether it can
be protected or not — that is generated in the action, as well as any rights
attached to it, including intellectual property rights.

_26.2 Joint ownership by several beneficiaries_ Two or more beneficiaries own
results jointly if: (a) they have jointly generated them and (b) it is not
possible to:

  1. establish the respective contribution of each beneficiary, or 

  

  2. separate them for the purpose of applying for, obtaining or maintaining their protection. 

    1. _Obligation to disseminate results_

  
  

  

  

Unless it goes against their legitimate interests, each beneficiary must — as
soon as possible — ‘disseminate’ its results by disclosing them to the public
by appropriate means (other than those resulting from protecting or exploiting
the results), including in scientific publications (in any medium).

  2. _Open access to scientific publications_

  

  

Each beneficiary must ensure open access (free of charge online access for any
user) to all peer-reviewed scientific publications relating to its results.

  3. _Open access to research data_

  

  

Regarding the digital research data generated in the action (‘data’), the
beneficiaries must:

(a) deposit in a research data repository and take measures to make it
possible for third parties to access, mine, exploit, reproduce and disseminate
— free of charge for any user — the following: (i) the data, including
associated metadata, needed to validate the results presented in scientific
publications as soon as possible;

(ii) other data, including associated metadata, as specified and within the
deadlines laid down in the 'data management plan');

(b) provide information — via the repository — about tools and instruments at
the disposal of the beneficiaries and necessary for validating the results
(and — where possible — provide the tools and instruments themselves).

(...)

As an exception, the beneficiaries do not have to ensure open access to
specific parts of their research data if the achievement of the action's main
objective, as described in Annex 1, would be jeopardised by making those
specific parts of the research data openly accessible. In this case, the data
management plan must contain the reasons for not giving access.

_39.2 Processing of personal data by the beneficiaries_

The beneficiaries must process personal data under the Agreement in compliance
with applicable EU and national law on data protection (including
authorisations or notification requirements). The beneficiaries may grant
their personnel access only to data that is strictly necessary for
implementing, managing and monitoring the Agreement.

###  Consortium Agreement

_Attachment 1: Background included_

According to the Grant Agreement (Article 24) Background is defined as “data,
know-how or information (…) that is needed to implement the action or exploit
the results”. Because of this need, Access Rights have to be granted in
principle, but Parties must identify and agree amongst them on the Background
for the project. This is the purpose of this attachment  5  .

(...)

As to EDIP SRO, it is agreed between the Parties that, to the best of their
knowledge, The following background is hereby identified and agreed upon for
the Project: (...)

Algorithms for the analysis of data characterizing the traffic flow from
automatic traffic detectors. Mathematical model of traffic network of roads in
the Czech Republic, including car traffic matrix.

(...)

As to HELP SERVICE REMOTE SENSING SRO, it is agreed between the Parties that,
to the best of their knowledge, The following background is hereby identified
and agreed upon for the Project: (...) Metadata Catalogue Micka.

Senslog Web Server.

HSLayers NG.

Mobile HSLayers NG Cordova.

VGI Apps.

(...)

As to GEOSPARC NV, it is agreed between the Parties that, to the best of their
knowledge, The following background is hereby identified and agreed upon for
the Project: (...) geomajas (http://www.geomajas.org).

INSPIRE>>GIS view & analysis component.

(...)

As to INNOCONNECT SRO, it is agreed between the Parties that, to the best of
their knowledge, The following background is hereby identified and agreed upon
for the Project: (...) WebGLayer library (available at http://webglayer.org/).

(...)

As to CITY ZEN DATA, it is agreed between the Parties that, to the best of
their knowledge, The following background is hereby identified and agreed upon
for the Project: (...) Warp10 platform (www.warp10.io).

(...)

As to ATHENS TECHNOLOGY CENTER SA, it is agreed between the Parties that, to
the best of their knowledge, The following background is hereby identified and
agreed upon for the Project: (...)

TruthNest, which will be integrated as a service within PoliVisu through an
API to be provided by ATC

(...)

As to SPRAVA INFORMACNICH TECHNOLOGII MESTA PLZNE, PRISPEVKOVA ORGANIZACE, it
is agreed between the Parties that, to the best of their knowledge, The
following background is hereby identified and agreed upon for the Project:
(...)

Mathematical model of traffic network of roads in the city of Pilsen,
including a car traffic matrix (so- called CUBE software:
http://www.citilabs.com/software/cube/).

(...)

As to MACQ SA, it is agreed between the Parties that, to the best of their
knowledge, The following background is hereby identified and agreed upon for
the Project: (...)

M3 Demo version in Macq's cloud for development, not allowed to put online or
in production. Excluded: background and especially data which is not owned by
Macq or which it is not allowed to share.

(...)

As to PLAN4ALL ZS, it is agreed between the Parties that, to the best of their
knowledge, The following background is hereby identified and agreed upon for
the Project: (...) Smart Points of Interest (http://sdi4apps.eu/spoi/).

Open Transport Map (http://opentransportmap.info/).

Open Land Use Map (http://sdi4apps.eu/open_land_use/).

(...)

As to STAD GENT, it is agreed between the Parties that, to the best of their
knowledge, The following background is hereby identified and agreed upon for
the Project: (...)

Any software developed for the publication, analysis, harmonisation and/or
storage of data by the City, its ICT partner Digipolis, or any subcontractor
thereof.

(...)

##  The PoliVisu licensing policy

There is at the moment no single licensing policy within the PoliVisu
consortium, either for the software (so-called Playbox) or their individual
components, some of which belong to the Background as mentioned in the
previous subparagraph. This is probably a topic of discussion for later
project stages. Likewise, there has been no explicit consideration of the data
licensing issue at the broad consortium level yet - which can be due to the
relatively early stage of the project’s lifespan and the limited number of
plenary meetings done so far.

However, a few building blocks can already be identified, based on the
discussion done in this document, the

GA provisions quoted above as well as others not quoted yet, and the
individual partners declarations in the CA. These provisions have been
implicitly accepted by the PoliVisu consortium members upon their signature of
the aforementioned documents and are therefore totally enforceable. They are
summarized in the table below.

**Table 2. Building blocks of the PoliVisu licensing policy**  
  
<table>  
<tr>  
<th>

**Typology of data**

</th>  
<th>

**Licensees**

</th>  
<th>

**During the project period**

</th>  
<th>

**After the project period**

</th>  
<th>

**Legal references**

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

Pre-existing (e.g. part of the Background knowledge of PoliVisu, as listed in
the CA Attachment 1)

</td>  
<td>

Other members of the

PoliVisu consortium

</td>  
<td>

Royalty free usage

No right to sublicense

</td>  
<td>

Under fair and reasonable conditions

</td>  
<td>

GA Art. 25.2

GA Art. 25.3

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

Any interested third party

</td>  
<td>

As per the Background commercial licence

</td>  
<td>

As per the Background commercial licence

</td>  
<td>

CA Attachment 1

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

Sourced from third parties for the execution of project activities (e.g.
portions of large datasets)

</td>  
<td>

Other members of the

PoliVisu consortium

</td>  
<td>

Royalty free usage

No right to sublicense

</td>  
<td>

Within the scope of the third party’s license

</td>  
<td>

General rules on IPR and license details

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

Any interested third party

</td>  
<td>

No right to sublicense

</td>  
<td>

No right to sublicense

</td>  
<td>

General rules on IPR and license details

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

Freely available in the state of art (e.g. Open

Data)

</td>  
<td>

Other members of the

PoliVisu consortium

</td>  
<td>

Royalty free usage

</td>  
<td>

Royalty free usage

</td>  
<td>

Within the scope of the data owner’s license

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

Any interested third party

</td>  
<td>

Royalty free usage

</td>  
<td>

Royalty free usage

</td>  
<td>

Within the scope of the data owner’s license

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

Newly produced  6  during the project (i.e. part of the Foreground knowledge
of PoliVisu)

</td>  
<td>

Other members of the

PoliVisu consortium

</td>  
<td>

Royalty free usage

No right to sublicense

</td>  
<td>

Under fair and reasonable conditions

</td>  
<td>

GA Art. 26.2

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

Any interested third party

</td>  
<td>

Open access at flexible conditions

</td>  
<td>

Open access at flexible conditions

</td>  
<td>

GA Art. 29.3

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

##  Special provisions for big datasets

The PoliVisu DoA describes how big data from different sources – notably
available at city level, in relation to the nature of the identified project
pilots, dealing with mobility and traffic flows – can distinctively contribute
to the three processes of policy experimentation belonging to its Framework:
design, implementation and (real time) evaluation of policy solutions  7  .

Big data, as defined in ISO/IEC CD 2046, is data stored in "extensive datasets
− primarily in the characteristics of volume, variety, velocity, and/or
variability − that require a scalable architecture for efficient storage,
manipulation, and analysis". This may include ‘smart data’, i.e. coming from
sensors, social media, and other human related sources. This obviously raises
questions about data security and privacy, which are explicitly and
extensively dealt with in a dedicated WP (1) and will ultimately become part
of a policy oriented manual, issued in two consecutive editions as
Deliverables D7.4 (due at month 24) and D7.6 (due at month 32).

In another WP (4), the PoliVisu DoA extensively deals with the smart data
infrastructure for cities that is now going to be developed within the
project. This is based on the Warp 10 big data architecture and will set up
various data processing and analytical steps. The general principle and modus
operandi is that any (big) data can be used in any application, can be
analysed and correlated with other sources of data and can be used to provide
detection of patterns to understand the effective functioning of
infrastructures, transport systems, services or process within a city. The
processed and analysed big data will be published as map services. Free and
open source geospatial tools and services will be used to generate OGC
standards (especially WMS-T and WFS), TMS and vector tile based open formats
for integration in GIS applications.

The existing OTN traffic modelling tool will be automated and ported to a big
data processing cloud to yield near-real-time traffic calculations. The
process will be calibrated to make the traffic model algorithms more accurate
(in space and time) using real time and historical traffic sensor data. System
interfaces and GUI will be developed to interact with the traffic modelling
software.

Existing crowdsourcing tools (such as Waze and plzni.to) will be adopted and
complemented with standard interfaces, protocols and data models to turn user
generated data into actionable evidence for policy making. New modules will be
designed for the SensLog open source library to support its integration with
big data technologies.

Data analytics functions and algorithms will be implemented to support policy
making processes. Social

Media analytics will be based on TruthNest. This tool will be extended with a
monitoring mechanism for Twitter contents that gathers any information on
mobility trends automatically and in real-time and sends alerts to users on
possible events.

Open source geospatial software (such as WebGLayer) will be used to realise
the big data visualisation. The tool will be extended with support for line
and area features. Advanced visualisation components will be added in the form
of multiple linked views, filters through interactive graphs, parallel
coordinates relationship analysis, map-screen extent filters, and area
selection. Focus will be set on the visualisation and filtering of mobility
related information and the comparison between different scenarios, time
periods and locations, in particular on mobile and touch devices.

The appropriate metadata will be defined for supporting the different tools
and processes in real life decision making conditions. This includes the
structures, services, semantics and standards to support big data, sensor
data, advanced analytics and linked data. Two open source metadata tools will
be considered in the project: GeoNetwork and Micka. The consortium will
contribute to the definition of integrated metadata standards in the OGC
metadata workgroup.

Considering the above scenario, as well as the DoA statement that “PoliVisu
will treat the data as confidential and will take every precaution to
guarantee the privacy to participants, i.e., ensuring that personal data will
be appropriately anonymised and be made inaccessible to third parties” (Part
B, p. 102) the resulting, natural implication is that a number of
anonymization, aggregation, and blurring techniques must be tested well in
advance, and applied to sourced and produced datasets in dependence of the
requirements of the various project pilots. The results of this effort will be
released as two WP4 Deliverables, notably a White Paper on data anonymisation
issued in two consecutive editions, D4.5 at month 24 and D4.6 at month 30.

However, due to the key role played by anonymization in the context of the
PoliVisu project and the need to balance privacy and security with the policy
(end user) requirements of having usable datasets for e.g. traffic flows
measurement, detection of trends, or sentiment analysis, it is highly
recommended that the contents of this section be updated and integrated when
the next edition of this DMP is published, notably at month 12 of the work
plan.

#  PoliVisu Data Management Plan

In this Section, the data usage scenarios presented in the Introduction are
used as a basis for discussing the key issues to be examined in relation to
each distinct paragraph of the PoliVisu DMP. As a reminder, the three
scenarios, which jointly compose the PoliVisu’s data management lifecycle,
are:

  * Original data produced by the PoliVisu consortium and/or individual members of it (e.g. during a dissemination action or a pilot activity); 

  

  * Existing data already in possession of the PoliVisu consortium and/or individual members of it prior to the project’s initiation; 

  

  * Existing data sourced/procured by the PoliVisu consortium and/or individual members of it during the project’s timeline. 

  

On the other hand, the datasets handled within the three above scenarios can
belong to either of these three categories:

  * Confidential data (for business and/or privacy protection); 

  

  * Anonymised and Public data (as explained in the Introduction, these two aspects go hand in hand); ● Non anonymised data (the residual category). 

  

##  Data summary

The following table summarizes the typologies and contents of data collected
and produced. For each distinct category, a detailed list will be provided in
the next edition of the DMP, due by month 12.

**Table 3. Summary of relevant data for the PoliVisu research agenda**  
  
<table>  
<tr>  
<th>

**Nature of datasets**

**Data usage scenarios**

</th>  
<th>

**Confidential**

</th>  
<th>

**Anonymised and Public**

</th>  
<th>

**Non anonymised**

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

**Original data produced by the**

**PoliVisu consortium**

</td>  
<td>

Raw survey/interview/sensor data

Evidence from project pilots

Personal data of end users

New contacts established

</td>  
<td>

Summaries of surveys/interviews

Data in reports of pilot activities

End user data on public display

Contact data within deliverables

</td>  
<td>

Photos/videos shot during public events

Audio recordings (e.g.

Skype)

Data in internal repositories

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

**Existing data already in possession of the PoliVisu consortium and/or
partners**

</td>  
<td>

Data embedded in some of the Background solutions

(see par. 2.4.2 above) Contact databases

</td>  
<td>

Data embedded in some of the Background solutions (see par.

2.4.2 above)

Website logs and similar metrics

</td>  
<td>

N/A

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

**Existing data sourced/procured by the PoliVisu consortium and/or partners**

</td>  
<td>

Raw data in possession of the Cities or of any third party involved in the
pilots

</td>  
<td>

Free and open data (including from scientific and statistical publications)

</td>  
<td>

N/A

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

The main implications of the above table for the three usage scenarios are the
following, in **decreasing** ​ **order of urgency** for the related action
lines as well as **increasing** ​ **order of gravity** for the consequences of
any inadvertent behaviour by the members of the consortium:

  * The organisation of Living Lab experimentations (as foreseen by the project’s work plan) implies that personal data handling of the end users acting as volunteers must be carefully considered, also for their ethical implications. 

  

  * For any photos/videos shot during public events, it is crucial to collect an **informed** ​ **consent note** 8  from all the participants, with an explicit disclaimer in case of intended publication of those personal images on e.g. newspapers, internet sites, or social media groups. This will bring the data back into the Confidential category, where it is legitimate to store and/or process it for legitimate reasons. 

  

  * For any audio recordings stored, e.g. in the project’s official repository (currently Google Drive) or in individual partners’ repositories, care must be taken of the risk of involuntary disclosure and/or the consequences of misuse for any unauthorized purpose. Same goes for the personal data of each partner in the consortium. 

  

  * Informed consent forms must be signed (also electronically) by all participants in surveys, interviews and/or pilot activities. As an alternative option, the partner in charge will commit to anonymisation and other related measures as a way to protect the identity of the respondents/pilot users. 

  

  * Informed consent forms are also required when using available contacts (be they preexisting to the project or created through it) to disseminate information via e.g. newsletters or dedicated emails. In this respect, the GDPR provisions are particularly binding and must be carefully considered, at least in any doubtful case. 

  

  * As a general rule, access conferred to Background knowledge on a royalty free basis during a project execution does not involve the right to sublicense. Therefore, attention must be paid by each partner of PoliVisu to ensure the respect of licensing conditions at any time and by any member of the team. 

  

  * This also applies to any dataset sourced or procured from third parties during the PoliVisu project’s lifetime. 

  

##  Data collection

The following table summarizes the procedures for collecting project related
data. For each distinct case, some concrete examples will be provided in the
next edition of the DMP, due by month 12.

**Table 4. Summary of PoliVisu data collection procedures**  
  
<table>  
<tr>  
<th>

**Nature of datasets**

**Data usage scenarios**

</th>  
<th>

**Confidential**

</th>  
<th>

**Anonymised and Public**

</th>  
<th>

**Non anonymised**

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

**Original data produced by the**

**PoliVisu consortium**

</td>  
<td>

Surveys

Interviews

Pilot activities

F2F / distant interaction

</td>  
<td>

Newsletters

Publications

Personal Emails

Open Access repositories

</td>  
<td>

Events coverage - directly or via specialised agencies

A/V conferencing systems

Internal repositories

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

**Existing data already in possession of the PoliVisu consortium and/or
partners**

</td>  
<td>

Seamless access and use during project execution

</td>  
<td>

Seamless access and use during project execution

</td>  
<td>

N/A

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

**Existing data sourced/procured by the PoliVisu consortium and/or partners**

</td>  
<td>

Licensed access and use during project execution

</td>  
<td>

Free and open access and use during project execution

</td>  
<td>

N/A

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

An implication of the above table that may not have been evident in the
previous one, is that **every** ​ **partner is responsible for the behaviour
of all team members** ,​ which may also include subcontracted organisations
(e.g. specialised press agencies) or even volunteers. The latter circumstance
does not exempt the delegate of a certain job in case of improper application
of extant norms and rules.

All data will be collected in a digital form – therefore CSV, PDF, (Geo)JSON,
XML, Shape, spreadsheets and textual documents will be the prevalent formats.
In case of audio/video recordings and images, the most appropriate standards
will be chosen and adopted (such as .gif, .jpg, .png, .mp3, .mp4, .mov and
.flv). Ontologies will be created in Protégé file format (.pont and .pins) or
.xml/.owl can also be used. Website pages can be created in .html and/or .xml
formats.

Individually, each research output will be of manageable size to be easily
transferred by email. However, it is important to note that email transfer can
become a violation of confidentiality under certain circumstances.

##  Data processing

The following table summarizes the procedures for processing PoliVisu related
data that can be envisaged at this project’s stage. As one can see, most of
them make reference to the contents of paragraph 2.6 above. In this sense,
more can probably be added to the cells of the table. For this purpose,
however, some exemplary case descriptions will be provided in the next edition
of the DMP, due by month 12.

**Table 5. Summary of PoliVisu data processing procedures**  
  
<table>  
<tr>  
<th>

**Nature of datasets**

**Data usage scenarios**

</th>  
<th>

**Confidential**

</th>  
<th>

**Anonymised and Public**

</th>  
<th>

**Non anonymised**

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

**Original data produced by the**

**PoliVisu consortium**

</td>  
<td>

Anonymisation

Visualisation

</td>  
<td>

Statistical evaluation

Visualisation

</td>  
<td>

Selection/destruction

Blurring of identities

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

**Existing data already in possession of the PoliVisu consortium and/or
partners**

</td>  
<td>

Anonymisation

Statistical evaluation

Metadata generation

</td>  
<td>

Visualisation

Analytics

Publication as map services

</td>  
<td>

N/A

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

**Existing data sourced/procured by the PoliVisu consortium and/or partners**

</td>  
<td>

Anonymisation

Statistical evaluation

Metadata generation

</td>  
<td>

Visualisation

Analytics

Publication as map services

</td>  
<td>

N/A

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

Apart from the specific software listed in paragraph 2.6 above, state of the
art productivity tools will be used to process/visualize the data used or
generated during the project. Typically, the partners are left free to adopt
their preferred suite (such as Microsoft Office™ for PC or Mac, Apple’s iWork™
and OpenOffice™ or equivalent). However, the following tools are the ones
mainly used by the consortium:

  * Google’s shared productivity tools (so-called G-Suite™) are used for the co-creation of outputs by multiple, not co-located authors. 

  

  * Adobe Acrobat™ or equivalent software is used to visualise/create the PDF files. 

  

  * Protégé™ or equivalent software is used to generate the ontologies. 

  

  * Photoshop™ or equivalent software are used to manipulate images. 

  

  * State of the art browsers (such as Mozilla Firefox™, Google Chrome™, Apple Safari™ and Microsoft Internet Explorer™) are used to navigate and modify the Internet pages, including the management and maintenance of social media groups. 

  

  * Cisco Webex™ or Skype™ (depending on the number of participants) are the selected tools for audio/video conferencing, which may also serve to manage public webinars. 

  

  * Tools like Google Forms™, and optionally SurveyMonkey™ and LimeSurvey™, are used for the administration of online surveys with remotely located participants. 

  

  * Dedicated Vimeo™ or YouTube™ channels can help broadcast the video clips produced by the consortium to a wider international audience, in addition to the project website. 

  

  * Mailchimp™ or equivalent software is helpful to create, distribute and administer project newsletters and the underlying mailing lists. 

  

##  Data storage

The following table summarizes the procedures for storing project related
data, during and after the PoliVisu lifetime, and the most frequently used
repositories. As for the previous paragraphs, we limit ourselves now to
listing the headlines and commit to adding more contents to the cases in the
next edition of the DMP, due by month 12\.

**Table 6. Summary of PoliVisu data storage procedures**  
  
<table>  
<tr>  
<th>

**Nature of datasets**

**Data usage scenarios**

</th>  
<th>

**Confidential**

</th>  
<th>

**Anonymised and Public**

</th>  
<th>

**Non anonymised**

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

**Original data produced by the**

**PoliVisu consortium**

</td>  
<td>

Individual partner repositories

Common project repository

</td>  
<td>

Project website

Open access repository

</td>  
<td>

Individual partner repositories

Common project repository

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

**Existing data already in possession of the PoliVisu consortium and/or
partners**

</td>  
<td>

Specific software repositories

</td>  
<td>

Playbox components

Map services

</td>  
<td>

N/A

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

**Existing data sourced/procured by the PoliVisu consortium and/or partners**

</td>  
<td>

Individual partner repositories

Third party repositories

Cloud repositories

</td>  
<td>

Playbox components

Map services

Cloud repositories

</td>  
<td>

N/A

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

Google Drive™ is the selected tool as Polivisu’s data and information
repository. This include both the project deliverables (including relevant
references utilised for their production or generated from them as project
publications, e.g. journal articles, conference papers, e-books, manuals,
guidelines, policy briefs etc.) and any other related information, including
relevant datasets. This implies that the privacy and security measures of
Google Drive™ must be GDPR compliant. The verification of such circumstance is
the responsibility of the coordinator.

Additionally, the coordinator will make sure that the official project
repository periodically generates back-up files of all data, in case anything
may get lost, corrupted or become unusable at a later stage (including after
the project’s end). The same responsibility goes to each partner for the local
repositories utilised by them (in some cases, these are handled by large
organisations such as Universities or Municipalities; in others, by SME or
even personal servers or laptops).

Collectively, we expect the whole set of outputs to reach the size of 500-600
Gb all along the project duration. This range will particularly depend on the
number and size of the received datasets to be utilised for the execution of
PoliVisu pilots.

Whatever the license that the consortium establishes for final datasets, their
intermediate versions will be deemed as **business confidential** ​ , and
restricted to circulating only within the consortium.​

Finally and as stipulated in the DoA, each digital object identified as R&D
result, including their associated metadata, will be stored in a dedicated
open access repository managed by POLIMI, to the purpose of both preserving
that evidence and making it more visible and accessible to the scientific,
academic and corporate world.

The next edition of this DMP will provide additional details on such open
access repository.

In addition to POLIMI open access server, other datasets may be stored on the
following repositories: ● Cordis, through the EU Sygma portal

  * The PoliVisu website (with links on/to the Social Media groups) 

  

  * Individual Partner websites and the social media groups they are part of 

  

  * The portals of the academic publishers where scientific publications will be accepted ● Other official sources such as OpenAIRE/Zenodo  16  and maybe EUDAT  17 

  

16  17  _​https://www.zenodo.org/communities/ecfunded/?page=1 &size=20 _
_​https://eudat.eu/what-eudat_

● Consortium’s and Partners’ press agencies and blogs ● PoliVisu official
newsletters.

##  Data sharing

Last but not least, the following table summarizes the procedures for sharing
PoliVisu related data in a useful and legitimate manner. When sharing, it is
of utmost importance to keep in mind, not only the prescriptions and
recommendations of extant rules and norms (including this DMP), as far as
confidentiality and personal data protection are concerned, but also the risk
of voluntary or involuntary transfer of data from the inside to the outside of
the European Economic Area (EEA).

In fact, while the GDPR applies also to the management of EU citizens personal
data (for business or research purposes) outside the EU, not all the countries
worldwide are subject to bilateral agreements with the EU as far as personal
data protection is concerned. For instance, the US based organisations are
bound by the so-called EU-U.S. Privacy Shield Framework, which concerns the
collection, use, and retention of personal information transferred from the
EEA to the US. This makes the transfer of data from the partners to any US
based organisation relatively exempt from legal risks. This may not be the
same in other countries worldwide, however, and the risk in question is less
hypothetical than one may think, if we consider the case of personal sharing
of raw data with e.g. academic colleagues being abroad for the purpose of
attending a conference. It is also for this reason that the sharing of non
anonymised data is discouraged for whatever reason, as shown in the table.

**Table 7. Summary of PoliVisu data sharing procedures**  
  
<table>  
<tr>  
<th>

**Nature of datasets**

**Data usage scenarios**

</th>  
<th>

**Confidential**

</th>  
<th>

**Anonymised and Public**

</th>  
<th>

**Non anonymised**

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

**Original data produced by the**

**PoliVisu consortium**

</td>  
<td>

Personal email communication

Shared repositories

</td>  
<td>

Project website

Open access repository

</td>  
<td>

N/A

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

**Existing data already in possession of the PoliVisu consortium and/or
partners**

</td>  
<td>

Personal email communication Shared access to software

repositories

</td>  
<td>

Shared access to Playbox components Map services

</td>  
<td>

N/A

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

**Existing data sourced/procured by the PoliVisu consortium and/or partners**

</td>  
<td>

Personal email communication

Shared repositories

</td>  
<td>

Shard access to Playbox components Map services

</td>  
<td>

N/A

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

As for the above mentioned procedures, additional case descriptions will be
provided in the next edition of the DMP, due by month 12.

#  Conclusions and Future Work

This document is the first of a series of four planned deliverables concerning
the PoliVisu Data Management Plan (DMP) in fulfillment of the requirements of
WP2 of the project’s work plan. The main reason for planning four versions of​
the DMP (at months 6, 12, 24 and 36) and particularly two of them during the
first project year, is​ evidently related to the need to hold on until the
development as well as piloting activities of PoliVisu gain further momentum,
in order to:

  * Secure the current, proposed structure of contents against any changes suggested by the gradual and incremental start up of the core project activities, and 

  

  * Colour the already existing contents with important add-ons based on the learning process that the Polivisu partners will activate throughout the project’s lifetime, considering also that most of project work will be oriented to operationalizing the connection between data handling (including analytics and visualization) and the policy making cycle outlined in deliverable D3.2 (also resting under POLIMI responsibility, like the present one). 

  

This edition of the DMP has, in our opinion, fulfilled the immediate goals of
such a stepwise approach to data management, by:

  * Presenting the legislative and regulatory framework, shaping the external context of this DMP in a relatively immutable manner, at least within the timeframe of the PoliVisu project; 

  

  * Identifying the fundamental principles of FAIR data handling according to the EC requirements and that the PoliVisu consortium and individual partners are bound to respect; 

  

  * Proposing a unitary description of the PoliVisu data management lifecycle, a precise requirement of the DoA and that has been the leitmotif and conceptual architrave of the whole document; 

  

  * Summarizing the key aspects of data collection, processing, storage and sharing (the typical contents of a DMP) within the proposed lifecycle elements and particularly highlighting - first and foremost, to the attention of the partners - some key aspects of data management that go beyond the operational link with open access policy (the likely reason why this deliverable has been assigned to POLIMI) and interfere with privacy and security policies (an ethical topic falling under the competence of WP1) as well as with the way background knowledge and tools will be developed, deployed and customised to serve the needs of the city pilots (a topic entirely covered by the WP4 team). 

  

As for now, it would be a great result if this first edition of the PoliVisu
DMP could enable all partners to understand the different action items that
handling with data of different nature, origin and “size” imply for anyone
wanting to stay in a “safe harbour” while actively contributing to the
successful achievement of pilot and project outcomes.

Indeed, this document can be found lacking in a variety of respects, which
will be gradually covered within the forthcoming editions of it. Some of the
contents left unattended or only partly covered by this edition of the DMP
include:

  1. A timeline of partners contributions. Until now, the contents have been provided mainly by the responsible author (POLIMI) with the other partners acting as external reviewers. In the future, and especially from now until month 12, a collaboration plan must be designed, covering most of the aspects associated with small “signposts” here and there along the preceding text. 

  

  2. A clearer connection with data handling in other deliverables. In fact, due to the tight connection between project activities and data management, the reader interested in getting full information on how the PoliVisu project deals with data should also refer, in addition to this DMP, to the following, already published, deliverables: D1.1 (Ethical Requirement No. 4), D1.3 (Ethical Requirement No. 3), D2.2 (Project Management Plan), D2.3 (Quality and Risk Plan), D6.1 (Pilot Scenarios), D7.1 (Evaluation Plan) and D8.1 (Impact Enhancement Road Map). Additional deliverables will be released until month 12. It then makes sense to coordinate better and more explicitly the contents of these in order not to miss precious information while at the same time avoid duplications and inconsistencies in the framing and reporting of this crucial theme. 

  

  3. While commenting the TOC of this document about one month ago, some partners proposed a more detailed consideration of the following topics: open standards, open data licensing, and consortium level policies. The latter aspect has been partly dealt with by reconstructing ex post some provisions of the GA and CA that are already binding for all partners. However, it is certainly worthwhile to make a more explicit and (to some extent) forward looking plan of e.g. what kind of licenses should be part of all the output categories making up the project results. It is also in that context that the issues of open standards and open data licenses (other than those belonging to the open access scheme) may be more extensively dealt with. 

  

  4. Another missing indication is certainly that of the partners responsible for the various steps of data management. At the moment, the crucial question of “who is in charge of” collecting, processing and storing data for each partner or deciding to limit or allow full access to some datasets, is subject of future decision making and will also depend on the maturity level of the pilot partners involved and strategic decisions when designing the PoliVisu platform. This question is not trivial (the answer equating the members of each partner team, or the heads of the teams, with the “people in charge” is by no means acceptable, giving too many things for granted, including the lack of hierarchies and other sorts of complexity within each partner’s organisation). In fact, some internal work is ongoing within the consortium at the level of creating a working group of the Data Protection Officers of each participant organisation. However there is more in between, and it will be the task of the next DMP edition to dig into the issue, thus contributing to the specialisation and clarification of the use cases now presented very superficially, in table form, within the preceding Section 3. 

  

  5. A final, indispensable aspect to be covered by a DMP is obviously the post-project scenario. What is the consortium’s and individual partners’ foresight of the management of pilot related datasets and more generally, of all the datasets created during the project’s lifetime that - for legitimate reasons, first and foremost exploitation related - are not subject to immediate publicity and may nonetheless require considerable attention and care to be maintained and preserved? Arguably the PoliVisu work plan is at a too early stage to enable a firm definition of these aspects. However with the progress of activities (and time), we expect that the operational links created at pilot level between (big) data handling, the behaviours of people involved in the Living Lab experimentations, and the three stages of the PoliVisu policy cycle will start generating insights and enable the collection of evidence in view of the broader dissemination and exploitation phases of the project.