#  1\. Publishable Summary

This deliverable provides the data management plan for the ROSIN project,
which details how data will be stored, tagged and archived throughout and
after the project. ROSIN will create data through _interviews and mining
software repositories_ as well as developing trainings materials and
associated source code for our education program. Additionally, ROSIN will
collect data by receiving applications to the ROSIN FTP grant program,
registering participants in education activities and collecting information
about attendants in our dissemination events _]_ . The data management plan
deals with how data will be stored in a secure and privacy-safeguarding way,
and how reuse and sharing after the project will be ensured. The deliverable
also provides governance arrangements on how to carry out the data management
plan in practice. The deliverable is a living document that will be updated
over the course of the project.

Table 1 summarizes the main information about the data managed in ROSIN a
described along the rest of this document.

_Table 1. Overview of ROSIN data._  
  
<table>  
<tr>  
<th>

Data definition

</th>  
<th>

Data origin

</th>  
<th>

Data type or format

</th>  
<th>

Expecte

d size

</th>  
<th>

Identification

</th>  
<th>

Metadata to find

</th>  
<th>

Metadata to

interoperate

</th>  
<th>

Access - who

</th>  
<th>

Access - how

</th>  
<th>

License?

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

**FTP proposal**

</td>  
<td>

3  rd  parties applying for FTP grant

</td>  
<td>

PDF documen

t

</td>  
<td>

MB

</td>  
<td>

Unique

identifier

</td>  
<td>

Keywords rosinftps.fluidreview. com sitemap

</td>  
<td>

No

</td>  
<td>

Confidential, only applicants, ROSIN

Board and

committees

</td>  
<td>

https://rosinftps.fluidreview.com

</td>  
<td>

\--

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Version 1.0 27-09-2017 5

#  2\. Data Summary

In this section, the following information is maintained for each WP in ROSIN,
as far as applicable:

  * _What is the purpose of the data collection/generation and its relation to the objectives of the project?_

  

  * _What types and formats of data will the project generate/collect?_

  

We consider the following main types of data to manage in ROSIN: Software
source code, technical documentation, Media (images, videos, etc), user data

Data formats include text, numbers, images, 3D models, text files, audio
files, video files, software executables.

  * _Will you re-use any existing data and how?_

  

  * _What is the origin of the data?_

  

  * _What is the expected size of the data?_

  

  * _To whom might it be useful (‘data utility’)?_

  

In the following sections the data summary information is described for each
WP.

##  2.1. WP1

WP1 is responsible for running the project. Data is collected from the
consortium partners, mainly regarding financial, legal, and administrative
matters for example, meetings, reports, events etc. Also the planning is
handled in WP1. The format of the data can be in Word, Excel, PPT, image file
formats or PDF. The data is saved on the GitHub  _rosin-project/intranet_
repository managed by TU Delft. All files can be handled through basic
commercial off-the-shelf software.

The contributors to the data collection within WP1 are all ROSIN consortium
members.  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

Coordination of the work developed in ROSIN, reporting of the project results
to the EU Commission.

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

_What types and formats of data will the project generate/collect?_

</td>  
<td>

Management and technical reports, videos and images.

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

_Will you re-use any existing data and how?_

</td>  
<td>

No

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

_What is the origin of the data?_

</td>  
<td>

Consortium activity leading to project deliverables

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

_What is the expected size of the data?_

</td>  
<td>

Unknown at this moment

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

_To whom might it be useful (‘data utility’)?_

</td>  
<td>

ROSIN consortium members and EU Commission. Additionally, public deliverables
can be useful to professionals related to robotics, especially: developers,
entrepreneurs, SMEs, robot manufacturers, robot users (e.g. manufacturing,
logistic or production companies in general), system integrators, researchers,
students, etc.

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

##  2.2. WP2

The main data generated in WP2 is the source code for ROS-I software produced
by 3  rd  parties in the Focused technical Projects. Additional data produced
is:

  * FTP application, evaluation and granting process: 

    * FTP proposals (technical reports in PDF) o Evaluations of FTP proposals (technical reports in PDF) o Contracts 

  

  

  * FTP execution: in addition to source code: 

    * technical reports, software logs, software debug information, 3D models that are managed by each FTP members o Dissemination material: images, videos, presentations, will be handled by WP5 

  

  

  
<table>  
<tr>  
<th>

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

</th>  
<th>

Increment the available code base of ROS open source robotics software for
industrial applications.

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

_What types and formats of data will the project generate/collect?_

</td>  
<td>

Collect: user data (contact information of professionals applying for FTP),
and for each FTP: project proposal, evaluation reports, contract

Generate: Source code, technical reports, software logs, software debug
information, 3D models, videos, images,

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

_Will you re-use any existing data and how?_

</td>  
<td>

Existing data might be used by FTP developers

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

_What is the origin of the data?_

</td>  
<td>

  * FTP application, evaluation and granting process 

  

  * The execution of the Focused technical Projects 

  

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

_What is the expected size of the data?_

</td>  
<td>

Unknown at this moment

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

_To whom might it be useful (‘data utility’)?_

</td>  
<td>

The produced source code will be useful to the community of ROS developers and
users.

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

##  2.3. WP3

The data generated in WP3 will be standard data collected and created in
software engineering research process in order to analyze problems, and
evaluate solutions.  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

The data is collected to assess the practices of quality assurance in the
ROS/ROS-I project and to monitor whether an improvement of quality has been
achieved by the ROSIN project efforts.

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

_What types and formats of data will the project generate/collect?_

</td>  
<td>

Interviews with project members (text), observation data (video, screencast,
transcripts), structured data resulting from analysis of code repositories
(bug reports, pull requests, source code).

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

_Will you re-use any existing data and how?_

</td>  
<td>

No.

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

_What is the origin of the data?_

</td>  
<td>

The data is created in the project (interviews, observation) or extracted from
publically available repositories (mostly github.com).

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

_What is the expected size of the data?_

</td>  
<td>

Below few gigabytes.

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

_To whom might it be useful (‘data utility’)?_

</td>  
<td>

The data will be made available to researchers in software engineering in
robotics, to further support research in quality assurance for robotics
platforms and applications (outside the ROSIN project).

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

##  2.4. WP4

The data collected by WP 4 are three-fold. On the one hand, source codes used
in schooling activities will be developed and stored in local git repositories
with no access to persons outside the consortium for now. The reason is to
assure and retain high quality of the ROS applications developed for teaching
activities until the curriculum has been further worked out.

The second type of data collected by WP4 is the training materials. These will
be lecture slides and teaching tutorials in form of pdf documents. These will
be stored in the project’s github repository.

The third type of data will be personal data of the ROSIN schooling activities
participants as well as evaluation data of a training. The first one will be
kept securely without public access. Likewise, the evaluation data will be
kept privately in order to improve the quality of the teaching activities.  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

Data will be generated in form of teaching materials (lecture slides and
tutorial in pdf format and source code). The relation to the project’s
objective are to be able to conduct high-quality trainings.

The personal data and the evaluation data are kept for internal use, for one,
for documenting the number of taught participants, and for another to improve
future teaching activities.

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

_What types and formats of data will the project generate/collect?_

</td>  
<td>

The types will be source codes, pdf files and personal data records

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

_Will you re-use any existing data and how?_

</td>  
<td>

Suiting existing teaching material might be adopted in case no existing IP
rights will be harmed. Existing ROS and ROS-I software package will be used
and adopted for training activities.

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

_What is the origin of the data?_

</td>  
<td>

The vast majority of the data are created by the members of the project,
except for existing ROS and ROS-I packages.

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

_What is the expected size of the data?_

</td>  
<td>

Unknown at the moment

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

_To whom might it be useful (‘data utility’)?_

</td>  
<td>

The data created in the teaching might be useful for other players in the
growing ROS teaching community.

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

##  2.5. WP5  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

Data about the participants at dissemination events might be collected and
used to gauge the type of audience that the project is reaching, in order to
balance among different type of attendees (academia, industry, etc). Likewise,
unsolicited expression of interests received in relation to the project can be
received.

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

_What types and formats of data will the project generate/collect?_

</td>  
<td>

Personal data records with affiliation.

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

_Will you re-use any existing data and how?_

</td>  
<td>

Yes, in case users express interest in receiving information about the project

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

_What is the origin of the data?_

</td>  
<td>

Attendees themselves, possibly through the events’ organizers or by personal
communication

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

_What is the expected size of the data?_

</td>  
<td>

Unknown at the moment

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

_To whom might it be useful (‘data utility’)?_

</td>  
<td>

To project management, in order to assess the success of the outreach of the
project (central to its stated goal)

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

##  2.6. WP6  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

For WP6 on ethical issues, we will collect the proposals for Focused Technical
Projects (FTP), including the proposers own ethics analysis. We use these
texts and checklists to decide whether or not to co-fund the FTP. Within WP6,
we do not collect data in another format than these texts.

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

_What types and formats of data will the project generate/collect?_

</td>  
<td>

The only type of data relevant for WP6 is the FTP proposal texts.

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

_Will you re-use any existing data and how?_

</td>  
<td>

At this moment (start of the project) we have no intention to use explicit
databases or other collections.

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

_What is the origin of the data?_

</td>  
<td>

The ethics analyses are produced by the FTP proposers.

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

_What is the expected size of the data?_

</td>  
<td>

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

_To whom might it be useful (‘data utility’)?_

</td>  
<td>

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

#  3\. FAIR data

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

What naming conventions do you follow? Do you provide clear version numbers?

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

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.

###  3.1.1. WP1  
  
<table>  
<tr>  
<th>

What naming conventions do you follow? Do you provide clear version numbers?

</th>  
<th>

Naming conventions and numbering for project deliverables and other documents
such as meeting agendas and minutes, presentation slides, are described in
ROSIN deliverable D1.2 Project Management guidelines

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

Will search keywords be provided that optimize possibilities for reuse?

</td>  
<td>

Not necessary.

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

What metadata will be created to make the data findable?

</td>  
<td>

Not necessary.

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

###  3.1.2. WP2  
  
<table>  
<tr>  
<th>

What naming conventions do you follow? Do you provide clear version numbers?

</th>  
<th>

Regarding FTP application, evaluation and granting process, the relevant
naming conventions can be found in the  _ROSIN_ _Call_ _for_ _Focused_
_Technical_ _ProjectsApplicant_ _Guide_

Regarding FTP results, relevant naming conventions that will be encouraged can
be found:

  * _http://wiki.ros.org/Industrial_

  

  * _http://wiki.ros.org/ROS/Patterns/Conventions_

  

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

Will search keywords be provided that optimize possibilities for reuse?

</td>  
<td>

Relevant keywords to category the FTPs will be identified and implemented in
FluidReview

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

What metadata will be created to make the data findable?

</td>  
<td>

Relevant keywords to category the FTPs will be identified and implemented in
FluidReview

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

###  3.1.3. WP3  
  
<table>  
<tr>  
<th>

What naming conventions do you follow? Do you provide clear version numbers?

</th>  
<th>

The data obtained from software repositories will be indentifiable and
traceable by appropriate identifiers (repository names, pull request numbers,
issue numbers and commit hashes, or otherwise URLs).

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

Will search keywords be provided that optimize possibilities for reuse?

</td>  
<td>

Since most data is textual, indexable, and published on the web in open
formats, no additional keywords are necessary for modern search engines.

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

What metadata will be created to make the data findable?

</td>  
<td>

We will create websites for sharing the public parts of the data, along with
deliverables and research papers (that will provide a searchable context for
search engines). When relevant, data will also be hosted on code repositories
(github.com), which increases searchability. The datasets will always be
described, including definition of contents and intended applications.

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

###  3.1.4. WP4  
  
<table>  
<tr>  
<th>

What naming conventions do you follow? Do you provide clear version numbers?

</th>  
<th>

All data are stored under git version control with distinct names indicating
the type and purpose of the respective data.

This also includes the complete git history of the data.

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

Will search keywords be provided that optimize possibilities for reuse?

</td>  
<td>

We consider the possibility to tag certain states of the repository in order
to easily find final states of source modules. Lecture slides follow a naming
convention in the repository that makes it easy to find them.

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

What metadata will be created to make the data findable?

</td>  
<td>

Not beyond the possibilities of git

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

###  3.1.5. WP5

_To complete by FHG_  
  
<table>  
<tr>  
<th>

What naming conventions do you follow? Do you provide clear version numbers?

</th>  
<th>

As data pertains users and their affiliation, conventional address book
conventions will be followed

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

Will search keywords be provided that optimize possibilities for reuse?

</td>  
<td>

A subdivision across categories (academia, system integrator, OEM, etc) will
be considered

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

What metadata will be created to make the data findable?

</td>  
<td>

Not beyond the keywords

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

###  3.1.6. WP6  
  
<table>  
<tr>  
<th>

What naming conventions do you follow? Do you provide clear version numbers?

</th>  
<th>

Because at this moment (start of the project) the data collection work within
WP6 is limited to the collection of texts containing the proposers own ethical
analysis, we do not need a specific data naming convention or versioning
numbering other than standard text versioning conventions.

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

Will search keywords be provided that optimize possibilities for reuse?

</td>  
<td>

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

What metadata will be created to make the data findable?

</td>  
<td>

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

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

Note that in multi-beneficiary projects it is also possible for specific
beneficiaries to keep their data closed if relevant provisions are made in the
consortium agreement and are in line with the reasons for opting out.

How will the data be made accessible (e.g. by deposition in a repository)?
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)?

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.

Have you explored appropriate arrangements with the identified repository?

If there are restrictions on use, how will access be provided? Is there a need
for a data access committee?

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

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

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

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

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

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?

**3.3.1. WP1**

Not applicable.

###  3.3.2. WP2  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

To be decided based no research on robotics and ROS available vocabularies and
ontologies

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

_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?_

</td>  
<td>

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

###  3.3.3. WP3  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

Standard formats (yaml, xml) will be used with schema appropriate for storing
the data. Schema will be documented in research reports.

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

_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?_

</td>  
<td>

N/A [standard schema do not exist for bug summaries, tool evaluation reports,
etc.]

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

###  3.3.4. WP4  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

The ROS-I common vocabularies for source packages and robotics teaching
applications will be used.

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

_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?_

</td>  
<td>

Does not apply

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

**3.3.5. WP5**

Not yet applicable. Update by FHG when repository of ROS-I industrial
applications is created

**3.3.6. WP6**

Not applicable

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

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

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

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

_How long is it intended that the data remains re-usable? Are data quality
assurance processes described?_

**3.4.1. WP1**

No applicable.

###  3.4.2. WP2  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

Source code produced in FTPs will be licensed under Apache

2.0

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

_When will the data be made available for re-use?_

</td>  
<td>

For each FTP, the code will be made immediately available upon completion of
the FTP, and only under exceptional circumstances with a maximum delay of 2
years since the start of the FTP

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

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

</td>  
<td>

All source code developed in FTPs will be made publicly available and reusable
under Apache 2.0.

The following data may remain confidential to the FTP group indefinitely:
detailed requirements, Documentation, Proprietary 3D Models, Pictures, Live
demos, Demo video, since those may contain IP of the companies involved in the
FTP.

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

_How long is it intended that the data remains re-usable? Are data quality
assurance processes described?_

</td>  
<td>

The source code created in an FTP will remain indefinitely available. The
quality assurance process for the code will be defined in different
deliverables of WP3.

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

###  3.4.3. WP3  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

Source code produced will be licensed under Apache 2.0. The research data will
be releases under a public domain license. Results of the analysis and design
of tools will be published in open access papers (under copyright).

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

_When will the data be made available for re-use?_

</td>  
<td>

The source code repository data will be made available as soon as it is
created (on the fly).

Personal data (for instance transcripts of interviews, videos) that will not
be published or shared at all. For sensitive data, only extracted summaries
and analysis results will be available in the research reports, papers and
deliverables. Fragments of personal data may be released, if we manage to
obtain consent of the involved persons (but this cannot be guaranteed up
front).

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

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

</td>  
<td>

Yes, it is the intention that some of the data will be used as benchmarks in
future research on quality assurance in robotics.

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

_How long is it intended that the data remains re-usable? Are data quality
assurance processes described?_

</td>  
<td>

We will strive to maintain the data live as long as it is realistically
reasonable, and definitely at least for several years beyond the project
duration. Since we are talking about relatively small volumes of data, they
can be hosted in public code repositories and websites, that have reasonably
good durability (such as github.com, figshare.com). Using open formats (git,
yaml, etc) will facilitate reasonably smooth migration to newer formats,
should this become necessary.

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

###  3.4.4. WP4  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

All teaching material will be published under Creative Commons License CC-BY-
ND in order to allow the usage of the material. In order to ensure high
quality standards of the teaching, the license does not allow to change the
material or use parts thereof. After sufficient measures to ensure the quality
of the source codes that will be generated in preparation of a schooling
activity and used in it, the source packages should also be published under
Apache 2.0 license or the license which is determined by the ROS packages used
for the teaching activity.

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

_When will the data be made available for re-use?_

</td>  
<td>

_Yes, under the above explained licenses._

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

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

</td>  
<td>

See above.

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

_How long is it intended that the data remains re-usable? Are data quality
assurance processes described?_

</td>  
<td>

See above.

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

###  3.4.5. WP5  
  
<table>  
<tr>  
<th>

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

</th>  
<th>

Marketing material to be made publicly available at events such as trade fairs
and demos will not be restricted in terms of distribution, but not all of it
will be available in source form to be edited by third parties

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

_When will the data be made available for re-use?_

</td>  
<td>

yes, to consortium members _._

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

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

</td>  
<td>

Possibly a selected part.

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

_How long is it intended that the data remains re-usable? Are data quality
assurance processes described?_

</td>  
<td>

As it is marketing material, it is intended to be valid for as long as the
project runs.

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

**3.4.6. WP6**

Not applicable.

#  4\. Allocation of resources

_What are the costs for making data FAIR in your project?_

The costs for making data FAIR in your project are unknown at this moment.

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

A total budget of 12500EUR for open access publications have been allocated to
TUD, FHA and ITU. In the third ROSIN Project Meeting in Copenhagen Nov. 2017
it will be discussed whether this covers the foreseen needs for data
management.

_Who will be responsible for data management in your project?_

Each workpackage leader is responsible for managing the data involved in their
respective workpackage according to the procedures and provisions detailed in
this Document Management Plan. The ROSIN Coordinator will ensure this.

_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)?_

This will be discussed in the third ROSIN Project Meeting in Copenhagen Nov.
2017

#  5\. Data security

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

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

Data generated by activity of ROSIN partners in WP3, WP4 and WP5, including
the dissemination of executed FTPs, is secured in:

  * The GitHub organization for the project and its associated repositories, maintained by TUD :  _https://github.com/rosin-project_

  

  * The project website, maintained by FHG and hosted by WordPress:  _http://rosin-project.eu/_

  

Data generated in the FTP application, evaluation, granting and monitoring of
FTPs is secured in the online platform provided by FluidReview:
_https://rosin-ftps.fluidreview.com/_

#  6\. Ethical aspects

At this moment (start of the project), there are no indications that ROSIN
will collect data with ethical or legal issues. The project focuses on the
development of open-source software, and the software (as far as foreseen)
will not collect user data requiring informed consent.

#  7\. Other issues

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

We do not make use of other national/funder/sectorial/departmental procedures
for data management.

#  8\. Tools potentially useful for ROSIN DMP

These are the tools that have been identified of interest for ROSIN’s DMP.
They have been curated from the  _H2020_ _Programme_ _Guidelines_ _on_ _FAIR_
_Data_ _Management_ _in_ _Horizon_ _2020_ (section 8):

  * _EUDAT_ _B2SHARE_ tool includes a built-in license wizard that facilitates the selection of an adequate license for research data. 

  

  * _Zenodo_ ,  an OpenAIRE and CERN collaboration), allow researchers to deposit both publications and data, while providing tools to link them. It already includes several robotics datasets and publications. 

  

  * _DMP_ _online_ contains some guidance to complement the H2020 DMP guidelines