**EXECUTIVE SUMMARY**

This deliverable is focusing on the data management planning within the HRADIO
project. To create the data management plan, we applied the ‘Guidelines on
FAIR Data Management in Horizon 2020  1  , which helps to make the research
data findable, accessible, interoperable and reusable. In this deliverable we
will discuss the different types of data that will be gathered, the processing
and storing of the data and the data handling principles.

Data within the HRADIO project will be gathered for 3 objectives, namely
technical integration, service harmonization and user engagement. Personal,
technological and documents repository data will be collected. These data will
be handled as partner specific data, consortium confidential data or open
data.

This is a living document, meaning that the document will be updated
throughout the project’s lifetime, when new data is gathered or when specific
issues concerning data management arise. In this first version, the general
principles (FAIR) for the data management will be discussed in section 2,
followed by the allocation of sources (section 3), data security (section 4)
and ethical aspects (section 5).

In addition to this deliverable, deliverable 7.1 about the ethical
requirements is submitted. In the latter, the ethical clearance took place
through the Vrije Universiteit Brussel Humanities Ethical Board. In addition,
an independent ethical expert is appointed.

#  DATA SUMMARY

In this chapter, the purpose of data collection and the related objectives are
outlined. Also, the different types and formats of the gathered data are
discussed. Furthermore, the reuse of existing data is explained. Finally, the
origin, expected size of the data and the data utility are cited.

##  PURPOSE OF THE DATA COLLECTION AND GENERATION

In the HRADIO study, the purpose of the data collection is related to three
main objectives for radio in the digital era as mentioned in the Grant
Agreement (page 4-5, part B) [1]:

  * **Technical integration:** Today’s radio devices, although providing different reception technologies, lack integration. It’s often up to the listener to make the decision which technology currently will deliver the best and most cost-effective user experience. Application developers for mobile platforms need to be enabled to gain a comfortable access to embedded tuner hardware in order to integrate broadcast and broadband seamlessly into the applications. 

  

  * **Service harmonization:** The permanent availability of return channels paired with the versatility of applications on mobile devices, forces broadcasters into a competition with sophisticated services such as music streaming, on-demand content and general information services. In order not to be perceived as the “old” radio service, broadcasters must combine their traditional linear services together with their IP-based on-demand content in order to provide an integrated service for the listener, which matches the expectations of end-users. 

  

  * **User engagement:** Radio applications on mobile platforms enable broadcasters to get in direct contact with their listeners and increase audience engagement. Besides enabling more interactive features, such as personalization, targeted advertising, games and voting. This also opens up the possibility of measuring exactly the number of people currently listening to the program and analyzing their behavior, as each stream is sent out individually to the end user.” 

  

The collected data within the project will be linked to these three main
objectives. To create a service harmonization and enhance user engagement,
personal data from radio audiences will need to be collected, as well as
specific feedback on user behavior, user experiences and technical performance
of the system. The specific types of data we will collect within the HRADIO
project is discussed in the next section.

##  TYPES AND FORMATS OF DATA GENERATED/COLLECTED

This section gives a description of the different data types we will collect
during the HRADIO project, how open the data will be, and in which format the
data can appear. A summary table is given, followed by a detailed explanation
of data types, data handling and data formats.

Table 1 - Data types and formats  
  
<table>  
<tr>  
<th>

**Data types**

</th>  
<th>

**Data openness**

</th>  
<th>

**Data formats**

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

Personal data:

  * Personal profile data 

  

  * Sensitive personal data 

  

  * Behavioral data 

  

</td>  
<td>

Partner specific datasets

</td>  
<td>

Textual, numerical, audio, pictures, video

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

Technical data

</td>  
<td>

Consortium confidential datasets

</td>  
<td>

Logging data, user statistics,...

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

Other datasets

</td>  
<td>

Open datasets

</td>  
<td>

Logos, templates, audit documents, meeting, reports,,...

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

###  Data types

####  Personal data

Three specific types of personal data will be gathered within the HRADIO
project.

  * The first one is _**personal profile data** . _ This contains sociodemographic data (for example: first name, surname, sex, place of birth, phone-number, email address, profession,...), radio usage data (user patterns via logging data or self-reported behavior), user feedback (in oral or written form, in response to interview and/or survey questions), pictures or videos (taken during workshops or by respondents (for example where they listen to radio). Contact details (physical address, phone number, email address) are only used to contact the participant for the research activity. These data will not be shared with other project partners who are not directly involved in the research activity. The data will also not be saved, nor distributed outside the project. Registration of participants to mailing lists will only happen when they give their explicit permission to do so. All users are ensured to be anonymized when used in project reports. 

  

  * A second specific type of data is _**sensitive personal data** _ . This type of dataset will be gathered when voice control is used as a function of the hybrid radio. This type of data will never be open data, as it can contain data about sexual life, political opinions, mental health,... Therefore, sensitive data will be treated in the same way as personal profile data. 

  

  * A third type of collected data is _**behavioral data** _ . This includes user patterns of the HRADIO services, for example how long the radio user is listening to a radio program. These data will also be anonymized before being made publicly available. 

  

####  Technical data

Within the HRADIO project, also technical data will be gathered, such as
access logs for the quality assurance of the technical solution, user logging
data etc. Depending on the specific nature of the data that is gathered, the
data will be consortium confidential or open. The nature of the technical data
will become clear with the development of the pilots.

####  Other Datasets: documents repository

The repository of documents is used for the purpose to share and store all
documentation related to the execution of the project. The repository within
the HRADIO project for the consortium partners is imec’s MyMinds communication
platform to store and share all project related documents (public, consortium
confidential and partner specific).

For public documents, we will also use the Zenodo repository as well as the
project website (hradio.eu) to allow open access. In what follows we describe
the different types of documents that can be archived in the repository:

  * **User feedback** (interview transcripts, survey responses etc.). These data will be made public after anonymization of the data. 

  

  * **Video and images** of workshops and other research activities. Pictures will only be used after informed consent of the respondents. Videos of the workshops will not be made public, as these will not be anonymized. 

  

  * **Deliverables** : MyMinds will contain the repository of deliverables of the project available to all the partners. It includes public as well as confidential deliverables. Relevant public deliverables are also published on the website. 

  

  * **Reports** : reports that are public will be made available for third parties. 

  

  * **Meeting documents** : will contain documents presented or generated during plenary meetings, work package meetings and conference calls (such as meeting minutes and supporting materials). Depending on the specific meeting topic, meeting minutes can be made public outside the consortium. 

  

  * **Audit documents** : material exchanged among partners for audits preparation. 

  

  * **Work packages documents** : the documentation, specific to that WP will be accessible for all the partners including activities description, APs and others. 

  

  * **Templates and logos** : in this category reference documents and guides to generate standard documents for the project have been uploaded as well as logos and visual materials for media dissemination. 

  

  * **Dissemination** **materials** : papers, articles, blogs resulting from the project tasks,.. This dissemination material will also be made available on the project website. 

  

###  Data openness

There are different ways of data handling, depending on the specific type of
data (personal, sensitive, behavioral, technical data or other data). A

of 33

distinction has to be made between partner specific, consortium confidential,
open and other datasets, as not all the data can be made public, and the
consortium is simultaneously bound to regulations stemming from a) EC open
access policies, b) EC and national data protection regulations, c) Grant
Agreement stipulations and d) Consortium Agreement stipulations.

####  Partner specific datasets

Partner specific datasets cannot be shared with other partners of the
consortium. These data are generated by one specific partner, for example:
e-mail addresses or other personal data of respondents that engage in research
activities. These data will only be used by the partner that generated these
data and are thus confidential data.

####  Consortium confidential datasets

These datasets cannot be made public because of intellectual property or data
privacy constraints, but these datasets can be shared among the consortium
members for research purposes. Examples of consortium confidential datasets
are user patterns or user behavior that cannot be completely anonymized, or
business intelligence gathered for innovation management purposes.

####  Open datasets

Open and other datasets will be made public as much as possible, to the extent
possible, on the condition that these data are anonymized so there will be no
recognizable patterns. Examples of openly available data are logos, station
names, descriptions and bearers, dissemination material etc.

Most of the open datasets can be reused but these data will be anonymized and
thus could not be linked to specific participants. This means third parties
have the opportunity to freely use these data as the data will be available to
everyone.

###  Data formats

The formats of these gathered data will either be textual (i.e.
questionnaires, transcriptions,...), numerical (access logs, logging data,..)
audio or pictures/videos.

In the table below, we indicate if the data is confidential or public, where
the data will be shared and if the data is personal or technical data.

Table 2 - Data confidentiality and sharing location  
  
<table>  
<tr>  
<th>

**Consortium**

**confidential (C), partner specific (PS) or public (P) data**

</th>  
<th>

**MyMinds**

</th>  
<th>

**Project Zenodo** **website**

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

Personal profile data

</td>  
<td>

PS

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Sensitive personal data

</td>  
<td>

PS

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Behavioral data

</td>  
<td>

PS

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Technical data

</td>  
<td>

C or P

</td>  
<td>

x

</td>  
<td>

</td>  
<td>

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

Dissemination materials

</td>  
<td>

P

</td>  
<td>

x

</td>  
<td>

x

</td>  
<td>

x

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

Deliverables

</td>  
<td>

C or P

</td>  
<td>

x

</td>  
<td>

x

</td>  
<td>

x (only P)

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

Reports

</td>  
<td>

C or P

</td>  
<td>

x

</td>  
<td>

x (only P)

</td>  
<td>

x (only P)

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

Meeting documents

</td>  
<td>

C or P

</td>  
<td>

x

</td>  
<td>

</td>  
<td>

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

Templates and logos

</td>  
<td>

P

</td>  
<td>

x

</td>  
<td>

</td>  
<td>

x

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

Audit

documents

</td>  
<td>

C

</td>  
<td>

x

</td>  
<td>

</td>  
<td>

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

Workpackages documents

</td>  
<td>

C

</td>  
<td>

x

</td>  
<td>

</td>  
<td>

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

User feedback

</td>  
<td>

P (after anonymization)

</td>  
<td>

x

</td>  
<td>

</td>  
<td>

x

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

Video and images

</td>  
<td>

C or P (after consent)

</td>  
<td>

x

</td>  
<td>

</td>  
<td>

x

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

##  REUSE OF EXISTING DATA

For piloting activities, it is possible that existing profile data is used.
For the Belgian pilot, Digimeter  2  profiles are used to sample and recruit
potential participants for the pilot activities. In this case, we will reuse
data from these panels when participants accept to participate in the HRADIO
project. Reusing data from these participants is only possible when the panel
manager provides the data from the participants. These data will always be
considered confidential data. Also, for the German pilot, RBB can rely to some
extent on approved user groups that might be recruited and complemented for
the pilot activities.

RBB will reuse data if participants accept to participate in the HRADIO
project. Also, in this case, the personal data will be considered
confidential.

Also, for the technical provision of radio centric metadata such as service
names, service descriptions, logos, links to web streams, podcasts or
slideshow images, existing data from the broadcast partners will be reused in
the HRADIO project. To assure technical interoperability, this data will be
provided by applying the RadioDNS/WorldDAB set of ETSI specifications e.g.
ETSI 102 818 and ETSI 103 270. These data will be public.

##  ORIGIN OF THE DATA

All the data gathered within the HRADIO project, will be the result of
research and piloting activities. Piloting activities including workshops and
user tests will take place in Belgium and Germany, as well as in the UK.
Besides user feedback on the developed scenarios and HRADIO services, also
technical data from the HRADIO client device will be collected and monitored
(e.g. logging data).

##  EXPECTED SIZE OF THE DATA (IF KNOWN)

Currently the expected data size is unknown.

##  DATA UTILITY

Not all the data gathered within the context of the HRADIO project will be
made public (see supra), but some data will be publicly available. In this
case, third parties or other researchers and developers could have an insight
in specific developed services and user feedback on these services. This can
be useful for other research projects working on radio, for broadcasters, for
radio manufacturers etc.

#  FAIR DATA

FAIR data  3  4  stands for findable, accessible, interoperable and reusable
data and is used to ensure good research data management. Below, these four
key elements are discussed more in-depth.

##  MAKING DATA FINDABLE, INVLUDING PROVISIONS FOR METADATA

###  The discoverability of data (metadata provision)

Metadata is provided within the HRADIO project to aid discovery of data in
Zenodo, the platform we will use to share our public project data.

###  Identifiability and locatability of data

We will use the Zenodo archiving system to share all open data generated
within the project. Articles, uploaded on Zenodo, will have a DOI-number.

###  Used naming conventions

Metadata will be used to improve discoverability of the data. We will use
existing vocabularies to describe the metadata via the Data Catalogue
Vocabulary (DCAT)  5  . “ _Naming conventions, once adopted, help people
converge on a shared vocabulary and then make it easier to use the terms in
that vocabulary_ ” [2].

###  Approach towards search keyword

Undefined at this moment.

###  Outline the approach for clear versioning

The deliverables will have a clear version numbering, which is also indicated
at the beginning of each deliverable in a version table. Each deliverable
starts with version

0.1. And consequent versions are numbered 0.2 etc. The final version is
version 1.0. In the table, the added content and revisions in each version is
also indicated.

###  Standards for metadata creation

Personal and technical data produced by HRADIO and intended for publication
will be modelled following linked data principles, so that the data may be
augmented with metadata using dedicated vocabularies.

Data formats are described in section 1.2.3. To complete these formats where
needed and appropriate for data that the project will publish: 1. Provenance
metadata will follow the PROV ontology  6  , a W3C standard

  2. Time-related metadata will follow the Time in OWL ontology  7  , a W3C standard 

  

  3. Geolocation metadata will follow the W3C Spatial Data on the Web Best Practices  8  4\. Metadata to describe published datasets will follow the Data Catalogue Vocabulary (DCAT)  9 

  

  

##  MAKING DATA OPENLY ACCESSIBLE

###  Openly available data and rationale for closed data

If possible, data will be made publicly available (see supra). This means that
open and other datasets will be made public to a certain extent, on the
condition that these data are anonymized so there will be no recognizable
patterns. For example, the participant’s names can be changed in aliases or
codes (i.e. P01, P02,...). Also, radio service and program metadata will be
openly available as the default. Broad search statistics (number of users that
searched for genre x or for keyword y) are shared across search instances in
the federated search architecture. However detailed user search statistics and
usage statistics are collected by search instances but kept closed since
privacy should be preserved as much as possible.

Some partner and consortium datasets are kept closed because of **intellectual
property rights and data protection.** For example, broadcasters expect their
stream URLs to be kept private (because mis-use of streams by unauthorized
third parties, costs broadcaster’s money in wasted bandwidth bills) so for the
project partners offering radio streams, the streams will only be available to
authorized users.

Other private data concerns personal information such as names and addresses
of respondents (see supra) will be anonymized.

###  Format data availability

To comply with the guidelines for open data availability, we will make use of
Zenodo to store and share all open project information free of charge. Also,
the project website will be used as a communication tool.

  * The stored data will include the data, including associated metadata. 

  

  * Information 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). 

  

###  Methods or software tools needed to access the data

All the transcriptions of the interviews and all data files are analyzed with
dedicated software, like SPSS or NVivo, which are commercial available
software tools. All the files that will become publicly available will be
accessible for third parties, for example by transforming the files in a .txt
or .csv format.

###  Deposition of data, metadata, documentation and code

The data will be made available via Zenodo.

###  Provision of access in case of restrictions

The provision of access depends on how open the dataset is. Open data will be
publicly available via Zenodo. For project specific data, most data is
available via the internal project platform (MyMinds). For data that is
partner specific, each partner controls the access and sharing settings.

##  MAKING DATA INTEROPERABLE

###  Data interoperability

Data produced and stored by the metadata dissemination and communication
platform will be fully interoperable. On a syntactic level, this will be
ensured by using standard data description languages like XML and JSON. On a
semantic level, the description of radio service and program metadata will
follow the RadioDNS ETSI standard as defined in ETSI TS 103 270 (Hybrid lookup
for radio services) as well as ETSI TS 102 818 (DAB EPG). Publicly available
interfaces of the platform will follow well known RESTful service principles
for full interoperability with external systems.

###  Vocabulary for inter-disciplinary interoperability

The HRADIO platform will use standard vocabularies for data description
wherever they exist (eg. RadioDNS service and program description) in order to
ensure interdisciplinary interoperability. The offered external interfaces are
fully described, open and extensible. More specifically, the project will use
a linked data approach, for instance by providing the vocabulary context to
turn a JSON document into a JSONLD document. Where possible and useful, e.g.
to improve public content indexing by search engines, the project will also
align data with or provide mappings to the schema.org vocabulary.

If - during development or after initial release - commonly used ontologies
emerge, the system can be extended or changed accordingly while still ensuring
backward compatibility. Other standard vocabularies used within the project,
are the TVAnytime  10  specification.

##  INCREASE DATA REUSE

###  Data licensing to permit the widest reuse possible

It has been agreed that the project results (research results, software,
business models, etc.), which will be provided as open-source components will
be protected under open source licenses (e.g. the EUPL, the LGPL or another
open source license). LGPL is a free software license which allows developers
to integrate software under the LGPL even into proprietary code  11  .

###  Data embargo

This does not apply.

###  Reuse of data by third parties after end of project

The open data will also remain available after the project duration. See
section 1.2.2 for an overview of open data.

###  Length of time for which the data will remain reusable

In the Grant Agreement it is stated that the EU may — with the consent of the
beneficiary concerned — assume ownership of results to protect them, if a
beneficiary intends — up to four years after the period set out in Article 3
(see grant agreement)— to stop protecting them or not to seek an extension of
protection, except in any of the following cases:

  1. the protection is stopped because of a lack of potential for commercial or industrial exploitation; 

  

  2. an extension would not be justified given the circumstances. 

  

  

A beneficiary that intends to stop protecting results or not seek an extension
must — unless any of the cases above under Points (a) or (b) applies —
formally notify the Commission at least 60 days before the protection lapses
or its extension is no longer possible and at the same time inform it of any
reasons for refusing consent. The beneficiary may refuse consent only if it
can show that its legitimate interests would suffer significant harm [3].

We will comply with these guidelines.

###  Data quality assurance processes

####  Personal data

In response to ethical considerations, attention is given to the gathering of
data by using an informed consent each time personal data is collected from
respondents (see annex 1 for a draft version of an informed consent). Besides
ethical considerations, all data within the project is gathered based on
scientifically validated methods. Reliability and validity criteria associated
with these methods are also taken into account, ensuring the data quality.

####  Broadcast content

For UKRP, data quality is assured for broadcasters which are members of
Radioplayer, since UKRP is able to help them provide metadata at a high
standard.

VRT data has been broadcasted in the past, and thus already underwent a
quality check in the media production process.

RBB plans to use audio in the pilots, which have already undergone the normal
production processes. This audio will be further adapted to ensure suitability
for HRADIO. In addition to the audio, we want to use different types of
metadata, ranging from SI data, to data already provided by RadioDNS, to newly
processed or accumulated data.

####  Technical data

For the technical activities within the project, the platform defines the
following data quality assurance processes:

  * Search index data exchanged between two instances of the federated search system is checked by the receiving system on two levels: Syntactically, only well-formed documents are accepted. 

  

Semantically, only content signed by certified federation partners is accepted
and further filtered using a plausibility analysis.

  * Service metadata that was entered manually using the corresponding external interface is checked syntactically and semantically as well (same for service metadata coming from the RadioDNS crawler). 

  

  * User statistics for the broad search mechanism are distributed amongst federation partners. Incoming data is checked syntactically and for plausibility. In addition, only signed content is accepted. 

  

  * Detailed user data collected by the user statistics module is checked syntactically and filtered based on a plausibility analysis. 

  

#  ALLOCATION OF RESOURCES

##  COST ESTIMATION FOR MAKING YOUR DATA FAIR

Making service and program metadata generated within the project openly
accessible is associated with costs for purchase and maintenance of server
infrastructure for search instances. Since the architecture is based on a
federated approach, costs are shared across participating service providers
dependent on the chosen level of engagement. In addition, the publication of
different types of data will be free or at a reasonable cost, for example when
Zenodo will be used. Also, different quality checks have been done and
standards are used within the HRADIO project.

At this moment, it is not possible yet to estimate the specific cost for
making FAIR datasets, however we expect the cost to be reasonable.

##  DATA MANAGEMENT RESPONSIBILITY

Imec will be responsible for the overall data management in the HRADIO
project, but for the data that is considered partner specific (see supra),
every partner is responsible for following the guidelines agreed within the
project and described in this data management plan (see section 1.2.2. Data
openness).

##  COSTS AND POTENTIAL VALUE OF LONG TERM PRESERVATION

The project lead and work package lead decide on the opportunity of long term
preservation through a discussion within the management board meeting. Data
will be kept during implementation of the action and for four years after the
period set out in article 3 of the Grant Agreement [4], the parties must keep
confidential any data, documents or other material (in any form) that is
identified as confidential at the time it is disclosed. If a beneficiary
requests, the Commission may agree to keep such information confidential for
an additional period beyond the initial four years (see supra).

Long term preservation of service and program metadata would allow for deep
analysis of radio program changes over long periods of time. For user data,
longterm analysis could be as well of value for service providers and academic
research but issues of data protection and data sovereignty must be considered
as well. Costs depend on the chosen preservation strategy (Refreshing,
Migration, Replication, Emulation, Encapsulation, ...). Other project
documents, including deliverables can provide interesting benchmark material
for future projects.

#  DATA RECOVERY, STORAGE AND TRANSFER

The International Standard ISO/IEC 17799 covers data security under the topic
of information security, and one of its main principles is that all stored
information, i.e. data, should be “owned”, so that it is clear whose
responsibility it is to protect and control access to that data, to keep it
safe from corruption and involuntary disclosure outside the European Economic
Area. Any evidence of natural persons’ identity and sensitive data collected
during the research will be destroyed at the end of it. For all collected
data, a responsible project partner is appointed that ensures the data is
stored and managed in a secure way.

For internal sharing of project data, we will use the password protected
MyMinds platform. This system has an adequate user administration system,
including individual rights assignment to project participants and back-up
systems to ensure data preservation. For the open sharing of documents, we
will make use of the Zenodo system, which is provided by CERN with support of
the EC. In this platform, only open project data will be shared.

#  ETHICAL ASPECTS

Users will be informed about what data is collected/shared and the purpose of
the collection/sharing, so they can make an informed decision whether they
consent or not. If data would be shared to third parties, this data will be
anonymized.

Requests for informed consents for data sharing and long term preservation are
included in all research activities (e.g. interviews, user workshops,
surveys,...) dealing with personal data.

Within work package 7 of the HRADIO project about the ethical requirements
(see deliverable 7.1), the ethical clearance took place through the Vrije
Universiteit Brussel Humanities Ethical Board. In addition, an independent
ethical expert is appointed.

#  OTHER PROCEDURES

Each project partner that is responsible for piloting activities, will ensure
compliance with their national data protection regulations. The project was
also assessed and approved by the ethical board of Vrije Universiteit Brussel.

#  CONCLUSIONS

In this deliverable, we have set out the data management plan for HRADIO. To
start with, we provided a data summary that explained the purpose and
objectives of data collection, the different types and formats of data, how we
plan to reuse existing data, and the origin, expected size and utility of data
that is gathered in the project.

Secondly, we described how HRADIO will strive to follow the FAIR data
guidelines. This document presents our provisions to make sure that HRADIO
data is findable, accessible, interoperable and reusable.

Next, we illustrated the allocation of resources in the HRADIO project and the
arrangements that we have made in order to ensure data security. We provided
insight into the ethical aspects and legal issues that can have an impact on
data sharing within the project. To conclude, we explained other procedures
for data management which ensure the compliance of the HRADIO consortium
partners with national/funder/sectorial/departmental regulations.

As stated in the executive summary, this data management plan is a living
document. This means that the next step is to update the document throughout
the project’s lifetime when new data is gathered or when specific issues
concerning data management arise. The updates of the data management plan will
be incorporated in the quarterly and periodic management reports (deliverables
D1.4 and D1.5).