#  Executive Summary

This document presents the Data Management Plan of the VERTIGO STARTS Project.
It was created based on “Horizon 2020 Data Management Plan” template document
issued by the European Commission. After a reminder on this template based on
the FAIR ( _Findable, Accessible, Interoperable and Re-usable_ ) criteria, it
presents the various processes of data production and use (Data summary) in
VERTIGO and then provides answers to all the questions it addresses in terms
of FAIR criteria.

The Data Management Plan is produced in the framework of the VERTIGO WP3 -
Deployment of brokerage online platform under the responsibility of IRCAM as
workpackage leader and project coordinator.

The main data sets taken into consideration are the ones produced by the
project partners and by third parties concerned with STARTS activities,
including other STARTS projects and stakeholders involved in the STARTS
Residencies program.

Table of Abbreviations  
  
<table>  
<tr>  
<th>

AGPL

</th>  
<th>

Affero General Public License

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

CNIL

</td>  
<td>

Commission Nationale de l'Informatique et des Libertés (France)

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

CNRS

</td>  
<td>

Centre National de la Recherche Scientifique (France)

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

CSS

</td>  
<td>

Cascading Style Sheets

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

DMP

</td>  
<td>

Data Management Plan

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

FAIR

</td>  
<td>

Findable, Accessible, Interoperable and Re-usable

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

SASS

</td>  
<td>

Syntactically Awesome Stylesheets

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

JSON

</td>  
<td>

JavaScript Object Notation

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

URI

</td>  
<td>

Uniform Resource Identifier

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

SSH

</td>  
<td>

Secure Shell

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

SSL

</td>  
<td>

Secure Sockets Layer

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

W3C

</td>  
<td>

World Wide Web Consortium

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

**1\. An introduction to the “Horizon 2020 Data Management**

#  Plan”

The Horizon 2020 DMP has been designed to be applicable to any Horizon 2020
project that produces, collects or processes research data. As part of making
research data findable, accessible, interoperable and re-usable (FAIR  1  ), a
DMP should include information on:

  * the handling of research data during & after the end of the project 

  

  * what data will be collected, processed and/or generated 

  

  * which methodology & standards will be applied 

  

  * whether data will be shared/made open access and 

  

  * how data will be curated & preserved (including after the end of the project). 

  

The Horizon 2020 DMP contains a set of key-questions (in blue in the rest of
the document) to be answered with a level of detail appropriate to each
project.

It is not required to provide detailed answers to all the questions in the
first version of the DMP that needs to be submitted by month 6 of the project.
Rather, the DMP is intended to be a living document in which information can
be made available on a finer level of granularity through updates as the
implementation of the project progresses and when significant changes occur.
Therefore, DMPs should have a clear version number and include a timetable for
updates. As a minimum, the DMP should be updated in the context of the
periodic evaluation/assessment of the project. If there are no other periodic
reviews envisaged within the grant agreement, an update needs to be made in
time for the final review at the latest.

This DMP may be updated as the policy evolves.

##  FAIR Data Management at a glance: issues to cover in Horizon 2020 DMP

This table provides a summary of the Data Management Plan (DMP) issues to be
addressed, as outlined above.  
  
<table>  
<tr>  
<th>

**DMP component**

</th>  
<th>

</th>  
<th>

**Issues to be addressed**

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

**1\. Data summary**

</td>  
<td>

•

</td>  
<td>

State the purpose of the data collection/generation

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

</td>  
<td>

•

</td>  
<td>

Explain the relation to the objectives of the project

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

</td>  
<td>

•

</td>  
<td>

Specify the types and formats of data generated/collected

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

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

Specify the origin of the data

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

</td>  
<td>

•

</td>  
<td>

State the expected size of the data (if known)

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

</td>  
<td>

•

</td>  
<td>

Outline the data utility: to whom will it be useful

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

  2. **FAIR Data**

  

  

2.1. Making data findable, including provisions for metadata

</td>  
<td>

•

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

Outline naming conventions used

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

</td>  
<td>

•

</td>  
<td>

Outline the approach towards search keyword

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

</td>  
<td>

•

</td>  
<td>

Outline the approach for clear versioning

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

</td>  
<td>

•

</td>  
<td>

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

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

2.2 Making data openly

accessible

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

Specify how the data will be made available

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

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

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

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

2.3. Making data interoperable

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow interdisciplinary interoperability? If not,
will you provide

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

</td>  
<td>

</td>  
<td>

mapping to more commonly used ontologies?

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

2.4. Increase data re-use (through clarifying licences)

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

Describe data quality assurance processes

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

</td>  
<td>

•

</td>  
<td>

Specify the length of time for which the data will remain reusable

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

**3\. Allocation of resources**

</td>  
<td>

•

</td>  
<td>

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

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

</td>  
<td>

•

</td>  
<td>

Clearly identify responsibilities for data management in your project

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

</td>  
<td>

•

</td>  
<td>

Describe costs and potential value of long term preservation

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

**4\. Data security**

</td>  
<td>

•

</td>  
<td>

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

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

**5\. Ethical aspects**

</td>  
<td>

•

</td>  
<td>

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

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

**6\. Other**

</td>  
<td>

•

</td>  
<td>

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

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

#  Data Summary

What is the purpose of the data collection/generation and its relation to the
objectives of the project?

This chapter presents the various data production processes in the project. It
includes data produced by the project itself for its own use and/or
communication, and data produced by external users: one of the central
features of the starts.eu platform published by the project is to be the main
support for communication and matchmaking of the STARTS community:
presentation of involved artists, projects, institutions, publication of news,
of calls, etc. A specific case is the process of STARTS Residencies managed by
VERTIGO which presents available Tech Projects and Producers, enables artists
and producers to apply to yearly calls for residencies, and then follows the
selected residencies and publishes documentation on their process and
outcomes.

**Common provisions for data published in the project web platform: starts.eu
and vertigo.starts.eu:**

The starts.eu domain belongs to IRCAM and is hosted by IRCAM in its own
servers located in France. As for the content published on these websites, the
following disclaimer is available :

_This website is the property of IRCAM, Institut de Recherche et de
Coordination Acoustique/Musique, based at 1, place Igor Stravinsky, 75004
paris, a non profit organization state-approved from decree dated the 24th
december of 1976, Siret number : 309 320 612 00018._

_This site along with all the material it contains is the property of IRCAM
and is protected in accordance to the Intellectual Property Code. As such, all
reproductions or representations (partial or complete) of this website, and
all extractions of our databases, by whatever means, without specific
authorization from IRCAM is strictly prohibited._

_This website enables external users to enter their data, including textual
and multimedia contents and to publish these data online. This concerns in
particular presentations of R &D projects and of organisations willing to
participate in the VERTIGO residencies program as Producers, as well as
physical persons registering to the platform such as artists with their
personal data and portfolio and biographies. All data (texts, images, videos,
sounds) are provided under the sole responsibility of these users and IRCAM
disclaims all liability on the authenticity and the truthfulness of the
supplied information. _

##  Data production processes

The hierarchy of data production processes as part of the project is presented
hereinafter. The item numbers are used in the rest of the document for
referencing the related processes.

  1. _Data generated by project partners for the project execution_

    1. _Private data_

  
  

  

  

These data are produced and shared only by the project consortium members for
its execution: internal reports, deliverables, legal documents, calendar, etc.
They are stored in private repositories managed and hosted by IRCAM in its own
servers and accessible only by login/password to the consortium participants:
project data cloud, project management tools, internal mailing lists, etc.

  2. _Public data for communication_

  

  

These data are published in the project web platforms starts.eu and
vertigo.starts.eu. Projects partners have access to the web platform
backoffice through an individual password/login.

  3. _Open source software publication_

  

  

Most of the project’s software development is implemented in open source form
and is published in relevant external repositories such as github.

  2. _Data generated by third parties (starts.eu)_

    1. _Registration of physical persons : login and user profile_

  
  

  

  

Physical persons can register to starts.eu by email/password and can define
their user profile including data fields to be published (such as their name
or pseudo) and others privately stored (such as their email address) and
accessible only to the project consortium.

  2. _Registration of other entities : projects, legal entities, etc._

  

  

Physical persons who commit in being mandated for representing an entity such
as a legal entity (cultural institution, research lab, company etc.) or a
project (such as a Tech collaborative project) can enter information about it
and define the data to be published (text, logo, photo, URL, location, etc.)
and other to be kept private and used solely for the platform management.

  3. _Data production through the platform operation_

  

  

Registered users can use the platform for publishing information, exchanging
with other users, etc. This is for instance the case of other STARTS projects
publishing related news on starts.eu.

  4. _Applications to STARTS Residencies calls_

  

  

Artists, possibly together with legal entities (“Producers”) can apply to
STARTS Residencies calls. They have therefore to upload various materials
(text, photos, videos) in digital form (CV, portfolio, residencies project,
etc.). The call clearly defines which of these materials is to be published
and which ones are to be kept private. In this latter case, their access is
restricted to the project’s participants and to the call’s reviewers and jury
members who sign a non-disclosure agreement of the related information.

  5. _Third parties’ calls managed by the platform_

  

  

The platform also enables third parties, referred to as “Call organisers” to
publish their own calls for residencies. By using the platform, the Call
organisers commit in conforming to the VERTIGO STARTS Residencies Charter
(Full text in Exhibit), and in particular to differentiate the private or
public dissemination status of the application data and to define in the call
text the use to be done with private data.

  6. _Data produced in the process of running STARTS Residencies_

  

  

Residencies selected as part of the STARTS Residencies program operated by
VERTIGO are expected to produce data in digital form presenting their process
and outcomes, including as part of a blog provided by the project. The status
of ownership of these data and grants licensed for their dissemination are
defined as part of a co-production contract to be jointly signed at the
beginning of the residency by all the parties involved in it: the artist(s),
the representative(s) of the Tech project, the representative of VERTIGO and
optionally the representative(s) of producer(s).

  3. _Data produced by the project from third parties’ inputs_

    1. _Modifications of user-entered data_

  
  

  

  

The project may apply slight modifications to user-entered data such as text
rephrasing, image reframing or resizing, video transcoding, etc. before
publishing them.

  2. _Data produced from users’ activity_

  

  

Various kinds of data and figures are produced on the basis of the users’
activity, such as usage statistics, or data linked to their profiles such as
chatting with other users or following them. These data are either used to
monitor the platform usage based on anonymous statistics or for the platform
operation itself (such as storing user setups).

What types and formats of data will the project generate/collect

  * _the software package (Vertigo-Mezzo) is used for the project web platform with domain starts.eu; it is written in (Python, JavaScript, CSS, SaSS, HTML)_

  

  * _data generated and collected through the software by the users like text (SQL, JSON), numbers (SQL,_

  

_JSON), images (JPEG, PNG) and videos (WebM, MP4), audio (MP3, WAV)_

◦ _regarding the platform models_

◦ _regarding the models of each product design and published by residencies_
Will you re-use any existing data and how?

  * _The public data which would have been uploaded by the user, presenting its works for example, will be republished as is (B.x) of with slight modifications (C.1)._

  

What is the origin of the data?

  * _A.x : project partners_

  

  * _B.x and C.1 : third parties registered to the platform_ What is the expected size of the data? 

  

  * _Very difficult to define. It could be dozens of gigabytes of user data at the end of the project._

  

To whom might it be useful ('data utility')?

  * _To the STARTS community in general as data of common interest for the community_

  

  * _To the project and the other STARTS projects as a support of their activity_

  

#  FAIR data

##  Making data findable, including provisions for metadata

Are the data produced and/or used in the project discoverable with metadata,
identifiable and locatable by means of a standard identification mechanism
(e.g. persistent and unique identifiers such as Digital Object Identifiers)?

  * _Each data piece managed by the platform will have a unique URI._

  

What naming conventions do you follow?

  * _No convention: it will depend mostly on titles used for the contents._

  

Will search keywords be provided that optimize possibilities for re-use?

  * _Yes, providing contextual metadata in the HTML headers as well as keywords selected in a thesaurus for each resource._

  

Do you provide clear version numbers?

  * _Yes, only for the software._

  

What metadata will be created? In case metadata standards do not exist in your
discipline, please outline what type of metadata will be created and how.

  * _HTML header metadata_

  

  * _Content metadata (dates, locations, etc.) which are generated from the user operation (such as date of a user process) or from the user data (such as geolocation from a postal address)._

  

##  Making data openly accessible

Which data produced and/or used in the project will be made openly available
as the default? If certain datasets cannot be shared (or need to be shared
under restrictions), explain why, clearly separating legal and contractual
reasons from voluntary restrictions.

_As for data produced by the project (A.x), the project is a CSA and its own
data production is limited to the management of its specific support and
coordination processes : managing the STARTS community, managing residencies
calls and execution, communicating on its activity._

_As for data produced by external users or by their behaviour (B.x and C.x),
the related data production processes clearly specify which ones are to be
publicly disclosed._

How will the data be made accessible (e.g. by deposition in a repository)?

  * _Web (public) with secured access through SSL certificates_

  

  * _DB and files backups on servers (private)_

  

What methods or software tools are needed to access the data?

_Web browsers for public data_

  * _Private and secured SSH sessions for private data_

  

Is documentation about the software needed to access the data included?

  * _Not for public data: all resources are accessible through HTML5 standards_

  

  * _Yes, for private data which can be restored in another instance of the platform software as explained in the Mezzo documentation_

  

Is it possible to include the relevant software (e.g. in open source code)?

  * _Yes, Mezzo and all related dependencies are fully open sourced._

  

Where will the data and associated metadata, documentation and code be
deposited? Preference should be given to certified repositories which support
open access where possible.

  * _Vertigo-Mezzo and Ulysses to be available on GitHub._

  

  * _All data are stored on IRCAM’s servers physically located in its headquarters in France._

  

Have you explored appropriate arrangements with the identified repository?

  * _IRCAM and all partners of the VERTIGO consortium have a full management of all repositories and can allow any collaborator to access to them._

  

If there are restrictions on use, how will access be provided?

This is also specified for each data production process. As a summary :

  * _Public data: no restrictions as any data published on the platform can be accessed_

  

  * _Private data: only consortium members, and for applications, reviewers and Jury members having signed a non-disclosure agreement (B.4), or third parties organisers of calls committing in fulfilling the VERTIGO STARTS Residencies Charter (B.5) are allowed to read users’ data with private status._

  

Is there a need for a data access committee?

  * _A priori no, the access rules having been defined and formalised in the project methodology. If unforeseen questions nevertheless arise, they will be handled by the Project Management Board._

  

Are there well described conditions for access (i.e. a machine-readable
license)?

  * _For the platform software: AGPL licence_

  

_https://fr.wikipedia.org/wiki/GNU_Affero_General_Public_License_

  * _For the user data accessible through the platform: any applicable statement and law applicable to the project in the About / Privacy section and the disclaimer statements, including the one applicable to the project platform and given at the beginning of Part 3._

  

How will the identity of the person accessing the data be ascertained?

  * _Any uploaded data is linked to a user registered in the platform and then in the database which maps these access rights._

  

_Any downloaded data is linked to a cookie generated by the platform itself
linked to the user session anonymously._

##  Making data interoperable

Are the data produced in the project interoperable, that is allowing data
exchange and re-use between researchers, institutions, organisations,
countries, etc. (i.e. adhering to standards for formats, as much as possible
compliant with available (open) software applications, and in particular
facilitating re-combinations with different datasets from different origins)?

  * _Web standards and formats are used for all standard data types (text, images, video, sound…)._

  

  * _In case of the production of specific data not conforming to these standards and needing some special software or any tool to be re-used, for instance technical data inherent to the artworks outcoming from artistic residencies these data will be stored in their original format for further use._

  

What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

  * _Web standards as documented and published by the W3C_

  

Will you be using standard vocabularies for all data types present in your
data set, to allow interdisciplinary interoperability?

  * _No_

  

In case it is unavoidable that you use uncommon or generate project specific
ontologies or vocabularies, will you provide mappings to more commonly used
ontologies?

  * _No mapping is foreseen_

  

##  Increase data re-use (through clarifying licences)

How will the data be licensed to permit the widest re-use possible?

  * _Residency outcomes and contents are published by users under the terms of the licence they have chosen case by case. If any license is defined, the link of the license terms should be accessible through the platform. This is true for the public/private status of user-entered data (B1-4 and B.6) and for third parties calls which must publish the use of private data (B.5)_

  

When will the data be made available for re-use? If an embargo is sought to
give time to publish or seek patents, specify why and how long this will
apply, bearing in mind that research data should be made available as soon as
possible.

  * _Re-use as soon as the data are published online through the platform_

  

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

_Data already published in the project time frame should be used for
publication by third parties. As for data with private status, the goal is to
enable the reuse of the data by further STARTS projects in case IRCAM is not
one of its partners and thus cannot further operate the platform. However,
since there is no legal entity which can be mentioned in the licensing
agreements with a life time longer than the project (for instance the STARTS
program), this will require concerned third parties to ask permission to the
registered users to manage the data in subsequent projects._

How long is it intended that the data remains re-usable?

  * _As long as the platform is online._

  

Are data quality assurance processes described?

  * _The platform provides some guidelines to facilitate data publication in the context of the Web_

  

  * _Rejections of non-standard formats_

  

  * _Reviews and moderation by different committees before any publication_ Further to the FAIR principles, DMPs should also address: 

  

  * _N/A_

  

#  Allocation of resources

What are the costs for making data FAIR in your project?

  * _The related costs concern:_

  

  
<table>  
<tr>  
<th>

◦

</th>  
<th>

_Mostly : the related aspects of development of the project web platform as
part of workpackage WP3, as well as the production of the data management
deliverables._

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

◦

</td>  
<td>

_The part of workpackage WP2 dedicated to the definition of the forms for
applications and applicable to Artists, Tech Projects and Producers and
distinguishing between public and private data;_

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

◦

</td>  
<td>

_The corresponding parts of the call formulations in WP4, as well as for the
production of the VERTIGO STARTS Residencies charter for third parties calls
and the production and management of co-production contracts for residencies._

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

◦

</td>  
<td>

_Elements of the web site editorial content including the IRCAM legal
disclaimer as part of WP5 and the management of existing data for the project
communication._

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

◦

</td>  
<td>

_The use of existing data for the project dissemination as part of WP6,
including the use of platform usage statistics._

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

How will these be covered? Note that costs related to open access to research
data are eligible as part of the Horizon 2020 grant (if compliant with the
Grant Agreement conditions).

  * _The related costs are to be covered as part of the EU Grant for the project._

  

Who will be responsible for data management in your project?

  * _Hugues Vinet, project coordinator, assisted by Guillaume Pellerin, leader of the web platform development WP3 workpackage (IRCAM)._

  

Are the resources for long term preservation discussed (costs and potential
value, who decides and how what data will be kept and for how long)?

  * _WP3 is in charge of the platform development and sustainability. The sustainability plan is to be finalised as part of deliverable D3.7 - Report on Web Platform Development, Usage Statistics and Sustainability Plan – Final._

  

  * _In addition to the data managed through the platform, the data produced as part of the project are stored in the project private cloud and in other repositories managed by IRCAM such as the project mailinglists. The project management board is in charge of specifying requests related to the long-term preservation of these data._

  

#  Data security

What provisions are in place for data security (including data recovery as
well as secure storage and transfer of sensitive data)?

  * _SSL Encryption of all web content by specific certificates_

  

  * _SSH encryption for accessing to the infrastructure by the sys admins and external backups_

  

  * _As defined as an initial constraint at the beginning of the VERTIGO project, the platform doesn’t use any system or digital service hosted outside Europe for all its administrative and platform management._

  

Is the data safely stored in certified repositories for long term preservation
and curation?

  * _Not up to now. A potential platform for back-upping data would be Huma-Num, a long-term preservation service provided by the CNRS in France, but with external and international backups through scientific dedicated networks._

  

#  Ethical aspects

Are there any ethical or legal issues that can have an impact on data sharing?
These can also be discussed in the context of the ethics review. If relevant,
include references to ethics deliverables and ethics chapter in the
Description of the Action (DoA).

  * _N.A._

  

Is informed consent for data sharing and long-term preservation included in
questionnaires dealing with personal data?

  * _Yes_

  

#  Other issues

Do you make use of other national/funder/sectorial/departmental procedures for
data management? If yes, which ones?

• _Procedures defined by the CNIL (Commission Nationale de l'Informatique et
des Libertés, France)_

#  Further support in developing the DMP

The Research Data Alliance provides a Metadata Standards Directory that can be
searched for discipline-specific standards and associated tools.

The EUDAT B2SHARE tool includes a built-in license wizard that facilitates the
selection of an adequate license for research data.

Useful listings of repositories include:

  * _Registry of Research Data Repositories_

  

  * _Some repositories like Zenodo, an OpenAIRE and CERN collaboration), allow researchers to deposit both publications and data, while providing tools to link them._

  

Other useful tools include DMP online and platforms for making individual
scientific observations available such as ScienceMatters.