#  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, delivered in May 2018 as Deliverable 2.10, was not a mere
collection of principles, as it set the stage for the ongoing and next
activities handling with data, before and even after the PoiVisu project is
completed. As per the DoA provisions: “​ _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”._

An open question, apparently unfulfilled by D2.10, was related to the
identification of which data sets would be relevant for PoliVisu (action)
research. An Annex to the Deliverable, entitled “Running list of data
sources”, was left blank with the promise of being taken care of at a later
project stage.

In practice, what happened in the consortium’s life was the release - in month
7 - of Deliverable 6.2

“Baseline Analysis”, authored by Joran Van Daele from Gent together with other
colleagues from AIV, GEOS, ISSY and PILSEN. With that deliverable, which was
coming up as a specification of D6.1, where the different needs and scenarios
of the three pilot cities (namely Gent, Pilsen and Issy-Les-Moulineaux) had
been described in detail, an extensive overview was provided of the already
available datasets in each city, as well as the missing ones at the date of
release of that Deliverable.

Therefore, this second edition of the PoliVisu DMP takes stock of the baseline
analysis carried out in D6.2 and uses the information contained therein to
fill in the Annex entitled “Running list of data sources”. This is the major
change with respect to the first edition.

Globally speaking, the original structure of D2.10 has been preserved while
working at the release of D2.11 and the contents of the first edition repeat
themselves quite identically in this document. The reader who is already
familiar with D2.10 may be puzzled by this decision. In fact, the proposed
approach is perfectly coherent with the conception of the DMP as a “living
Deliverable”, being updated at periodic dates following the progress in the
underlying project related activities.

In conclusion, and apart from minor corrections of (mainly) typos all along
the preexisting text, only Sections 4 and Annex 1 of this edition are new. Of
course, and until further advice, all Sections of this DMP remain valid and
enforceable - for what pertains to or influences the daily work of the
PoliVisu partners​.

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 and the already mentioned D6.2 (Baseline Analysis), 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. The first edition, however, was not a mere collection of
principles, as it set the stage for the ongoing and next activities handling
with data, before and even after the project is completed.

In the following text, we reproduce the contents of Section 1 of D2.10 almost
unchanged, apart from some corrections of typos or equivalent modifications
aimed at improving readability and understandability. In case the reader is
already familiar with D2.10 contents, the remainder of this Section may be
skipped at all.

##  The PoliVisu Data Management Lifecycle

As per the DoA provisions, the PoliVisu DMP “​ _describes the data management
lifecycle_ 1  _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. To get a prompt overview of
the relevant datasets for the three pilot cities, the interested reader is
referred to ​Annex 1 to this document, entitled “Running list of data
sources”.

After an internal discussion, also during the May 2018 held in Issy Les
Moulineaux, the partners agreed to 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** 2  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
3  \- 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  4  .

**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  5
.

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  6  .

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 1** ​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 2018; 

  

  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. 

  

  

In the following text, we reproduce the contents of Section 2 of D2.10 almost
unchanged, apart from some corrections of typos or equivalent modifications
aimed at improving readability and understandability. In case the reader is
already familiar with D2.10 contents, the remainder of this Section may be
skipped almost completely, with the only exception of Section 2.7 that has
been created from scratch to deepen the level of analysis on data
anonymisation.

##  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 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.

##  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  12  .

(...)

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  13  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  14  .

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 or
TrulyMedia as an alternative option. 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, in the first edition
of the DMP it was highly recommended that the contents of this Section be
updated and integrated when this edition of the DMP would be published, namey
at month 12 of the work plan. This is the purpose of the following subsection.

##  Special provisions for data anonymization

The main conclusion of D6.2 and the internal partner survey done in
preparation for it, has been that the majority of relevant datasets for the
three pilot cities are already available and those that aren't have the
potential to become so. However, further analyses and data preparations are
needed before the partners can combine available (and for the moment
unavailable/unusable) datasets, because of the wide variety in data standards
and the differentiating quality of the datasets. Among these additional steps
towards achieving ‘data readiness’, anonymization is a key process component.
According to Deliverable 6.2 conclusions, this aspect is particularly relevant
in the case of Gent, and more specifically for the student housing datasets.
In any case, the next statements are general in principle and need to be
adopted and translated into practice by all the members of the PoliVisu
consortium.

###  Overview of available techniques

By anonymization, the legal and technical practice of data management intends
a collection of methods and tools to transform a collection of personal data
available to an organisation, in such a way to impede the establishment of a
transparent, and potentially harmful, connection between the information
contained in the dataset and the personal identity of the individual data
subject(s). Indeed, many techniques are known from the state of the art,
including (non exhaustively) the following:

○ **Attribute suppression** ​: consisting in the removal of an entire part of
a dataset (also referred to as “column” in spreadsheets);

○ **Record suppression** ​: consisting in the removal of an entire part of a
dataset (also referred to as “raw” in spreadsheets);

○ **Swapping** ​: consisting in the rearrangement of items in the dataset such
that the individual attribute values are still represented therein, but
generally, do not correspond to the original records. This technique is also
referred to as shuffling and permutation;

○ **Data perturbation** ​: consisting in a modification of the values from the
original dataset to be slightly different from the original ones;

○ **Character masking** ​: achieved by using a constant symbol (e.g. “*” or
“x”) in the place of a data point - typically, a name/surname string or other
recognizable elements of a record;

○ **Pseudonymisation** ​: achieved by using a pseudonym in the place of a
name/surname string, with or without the possibility of coming back to the
original identity of the data subject(s) - depending on whether the data owner
decides to keep track of the matching and store that information in a secure
place. This technique is also referred to as coding;

○ **Generalisation** ​: achieved by deliberately reducing the precision of
available data through e.g. converting a person’s age into an age range, or a
precise location into a less precise location. This technique is also referred
to as recoding;

○ **Aggregation** ​: achieved by converting a dataset from a list of records
to summarised values;

○ **Creation of a “synthetic” dataset** ​: achieved by using the original data
to generate a wholly different collection, instead of modifying the original
dataset.

###  Limitations and risks

Generally speaking, all the above techniques achieve the goal of protecting
the personal identity of the data subjects, although their impact on the
integrity and usability of the underlying dataset is obviously different and
should be carefully considered prior to undertaking any irreversible action.

Nevertheless, an important element of reflection is related to the known fact
that all the aforementioned approaches are ​ **static** \- in the sense that
they refer to an ideal (perhaps too idealistic) situation whereby the dataset
to be anonymised is fully available at the time, has a standard format and is
clean and complete; thus, the process of anonymisation can be successfully
performed rather easily with the support of one or more methods and tools and
especially once for all. Unfortunately this is not the case in the normal
practice, where datasets are incomplete, “dirty”, subject to continuous
revision and upgrade, including in few (but not infrequent) cases the addition
of new records/attributes and/or the initiation of new forms of data
collection such as audio/video, images, texts, geolocation, biometrics etc.

In such a ​ **dynamic** \- not to say all chaotic - situation that
characterizes real life, even the implementation of either of the above
methods and tools can prove inappropriate and lead the whole anonymisation
process to unsatisfactory results. Not to mention the biggest risk of all,
that the anonymisation process itself is prone to failure and therefore, to an
unwanted disclosure of personal data; this, not necessarily because of
inherent mistakes in use or the improper use of some of the aforementioned
techniques, but more simply due to a careless management of security aspects
(such as when storing the information on pseudonyms in a not too secure place)
or even more simply, to an insufficient level of protection against the use of
third parties’ data sources to decipher some information related to people
that was supposed to be anonymised.

In such difficult context, the best (and perhaps the only) defence is
procedural: which means that in the case of PoliVisu pilots, the preparatory
stage outlined in Deliverable 6.2 should be complemented by the roll-out of a
visibly and transparently implemented anonymisation process. This is expected
to integrate the use of other techniques mentioned in D6.2 such as data
cropping, data cleansing and ETL, social media scraping and time series
creation.

#  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). 

  

In the following text, we reproduce the contents of Section 3 of D2.10 almost
unchanged, apart from some corrections of typos or equivalent modifications
aimed at improving readability and understandability. In case the reader is
already familiar with D2.10 contents, the remainder of this Section may be
skipped at all.

##  Data summary

The following table summarizes the typologies and contents of data collected
and produced. For each distinct category, a preliminary list is provided in
Annex 1 to this document and will be updated in the next edition of the DMP,
due by month 24.

**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** 15  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. Annex 1 to this document (“Running list of data sources”) provides some
concrete examples of data usage scenarios. More of them will be added to the
third edition of the DMP, due by month 24, as allowed by the expected progress
of PoliVisu city pilots.

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

**Nature of datasets**

</th>  
<th>

**Confidential**

</th>  
<th>

**Anonymised and Public**

</th>  
<th>

**Non anonymised**

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

**Data usage scenarios**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </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. Annex 1 to this document
(“Running list of data sources”) provides some meaningful case descriptions.
More of them will be added to the third edition of the DMP, due by month 24,
as allowed by the expected progress of PoliVisu city pilots.

**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**

</td>  
<td>

Anonymisation

Statistical evaluation

</td>  
<td>

Visualisation

Analytics

</td>  
<td>

N/A

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

**and/or partners**

</th>  
<th>

Metadata generation

</th>  
<th>

Publication as map services

</th>  
<th>

</th> </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. Annex 1 to this document (“Running list of data
sources”) provides some contents for the pilot descriptions. More of them will
be added to the third edition of the DMP, due by month 24, as allowed by the
expected progress of PoliVisu city pilots.

**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  ● 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 previous tables, Annex 1 to this document (“Running list of data
sources”) provides some initial case descriptions. More of them will be added
to the third edition of the DMP, due by month 24, as allowed by the expected
progress of PoliVisu city pilots.

#  Conclusions and Future Work

This document is the second in a row 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). 

  

In the first edition of the DMP (deliverable D2.10) we basically envisaged
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. 

  

That 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). 

  

All the above contents originated in D2.10 have not been removed from this
document, but only aligned with and supplemented by some extra items within
​this second edition of the DMP, notably reflecting progress in the
consortium’s and partners’ reflections on some aspects left unattended and
explicitly mentioned in the conclusions of the Deliverable 2.10, namely:

  * Integration of the baseline analysis done in D6.2 until month 7; 

  

  * Compilation of Annex 1 “Running list of data sources”; 

  

  * Provision of case descriptions for Section 3; 

  

  * A more careful consideration of data anonymisation related aspects in Section 2. 

  

In so doing, some of the contents left unattended or only partly covered by
the previous edition of this DMP have been covered, which reflect:

  1. A stronger integration of partners contributions in the texts composing this document, although with the twin filter of the responsible author (POLIMI) who provided most of the contents by now, with other partners acting as external reviewers, and the table provided as Appendix to Deliverable 6.2, which has been “scrapped” by the responsible author to create Annex I to this DMP. 

  

  2. A deeper connection with the topic of data handling in other deliverables that this one only, and particularly: 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). This in order not to miss any precious information while at the same time avoiding duplications and inconsistencies in the respective structure and contents. 

  

  

Still, this document can be found lacking in a variety of respects, which will
be gradually covered within the forthcoming editions of it. They include the
following:

  3. While commenting the TOC of D2.10, 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 surely 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 early work within the consortium has been dedicated 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.

As for now, it is still possible to conclude - as we did in the previous
edition of this Deliverable - that it would be a great result if 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 the pilot and project outcomes.