#  Executive Summary

In accordance with the European Commission Directorate-General for Research &
Innovation “Guidelines on Data Management in Horizon 2020” v.2.1, the
ChainReact Consortium partners collected, analysed and selected a series of
datasets that corresponded to their progress regarding ChainReact’s three main
struts: The Whistle, OpenCorporates, and WikiRate. Each Consortium partner
received a call-to-action to introduce the datasets most relevant to their
respective deliverables.

This document reflects on the current state of Consortium agreements on the
datasets that are produced and managed and outlines these sets of data in
detail in terms of their description, selection methodology, use, owner,
effect, data sharing principles and agreements, and lifecycle.

The data management plan will remain alive and evolving throughout the
lifespan and the project. A second submission of the DMP will take effect at
month 12. The datasets may also be altered due to converging factors such as
project maturity, shifts in consumer usage, shifting to following working
phase, etc.

#  Methodology

The methodology followed for drafting this initial DMP adheres to the European
Commission’s Guidelines  1  as interpreted in the online tool DMPonline  2  .
DMPonline produced by the UK's Digital Curation Centre (DCC)  3  to help
research teams address DMP requirements by addressing a series of questions
for each dataset a project produces.

Accordingly, ChainReact’s Initial DMP addresses the fields below for each
dataset:

  * Data set reference and name 

  

  * Data set description 

  

  * Standards and metadata 

  

  * Data sharing 

  

  * Archiving and preservation (including storage and backup). 

  

##  Dataset reference and name

This field is the identifier for the dataset to be produced. The ChainReact
dataset identification follows the naming: Data_ _ <WPno> _ _ _ <serial number
of dataset> _ _ _ <dataset title> _ . Example: **Data_WP2_1_Wikirate_Site** .

##  Dataset description

In this field the data that will be generated or collected is described,
including references to their origin (in cases where data iare collected),
nature, scale, to whom it could be useful, and whether it underpins a
scientific publication. Where applicable, information on the existence (or
non-existence) of similar data and the possibilities for their integration and
reuse are mentioned.

##  Standards and metadata

This field examines existing suitable standards within relevant disciplines,
as well as an outline on how and what metadata will be created. The available
data standards (if any) accompany the description of the data that will
collected and/or generated, including the description on how the data will be
organised during the project, mentioning for example naming conventions,
version control and folder structures.

The DCC provides the following questions to be considered as guidance on Data
Capture Methods:

  * _How will the data be created?_

  

  * _What standards or methodologies will you use?_

  

  * _How will you structure and name your folders and files?_

  

  * _How will you ensure that different versions of a dataset are easily identifiable?_

  

##  Data sharing

In this field we describe how data will be shared, including access
procedures, and embargo periods (if any). We also outline the technical
mechanisms for dissemination, including necessary software and other tools for
enabling re-use; define the breadth of access.

In case the dataset cannot be shared, the reasons for this will be mentioned
(e.g. ethical, rules of personal data, intellectual property, commercial,
privacy-related, security-related).

##  Archiving and preservation

Here the procedures that will be put in place for long-term preservation of
the data will be described, along with the indication of how long the data
should be preserved, what is its approximated end volume, including a
reference to the associated costs (if any) and how these are planned to be
covered. This point emphasizes in the long-term preservation and curation of
data, beyond the lifetime of the project. Where dedicated resources are
needed, these should be outlined and justified, including any relevant
technical expertise, support and training that is likely to be required and
how it will be acquired.

#  ChainReact Datasets

##  WP1 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP1_1_ChainReact_Docs_Site**

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

_Data set description_

</td>  
<td>

A restricted Wagn-based website at docs.chainreact.org used for internal
collaboration of all ChainReact partners. Will include the canonical versions
of reports, deliverables, proposals, and core results of huddles and other
meetings. Because of the flexibility of this platform, it will often be used
for creating structures for organizing other data collaborated on by many
partners.

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

_Standards and metadata_

</td>  
<td>

Like all Wagn sites, the docs site is organized into “cards”. For every edit
of every card (including name, type, and content changes), wagn stores:

 a userstamp  a timestamp, and  an IP address.

When multiple cards are edited simultaneously, these independently tracked
“actions” are grouped into single “acts”. It is also possible to collect
additional metadata and standards-conforming data within cards.

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

_Data sharing_

</td>  
<td>

By default, cards on the docs site are restricted to viewing by partners,
though any individual card may be independently made publicly viewable if
deemed appropriate by its editors. Much of the site’s content is material
being prepared for publication but not appropriate for publication in raw
states. Other cards contain conversations, personal data, and proposals that
have been rejected or not yet agreed upon. It is, by and large, a site for
process rather than final products.

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

_Archiving and preservation_

</td>  
<td>

The docs site is currently stored on the WikiRate production server and will
likely be moved to a smaller server when WikiRate.org moves to a multiserver
architecture. Full site backups are automatically generated daily, with one
copy stored locally and another transferred to our development server. Wagn
automatically handles card revisions, and the complete history of every card
is visible via the interface.

Decko Commons eV has accepted responsibility for continued hosting of and
updated to the website after the project’s completion. Should it be unable to
continue hosting at some point in the future, it will provide all partners
with an archive, which will be made conveniently usable with the installation
of the open-source Wagn/Decko platform.

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

_Data set reference and name_

</th>  
<th>

**Data_WP1_2_Contacts_Database**

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

_Data set description_

</td>  
<td>

Lists of key Contacts at partners, hosted in the form of mailing lists

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

_Standards and metadata_

</td>  
<td>

Standard form of name, and email address, organised into general and project
specific mailing lists (e.g. financial contacts, WP coordination)

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

_Data sharing_

</td>  
<td>

These contact lists are viewable by the ChainReact project team and editable
by the administrators, at WikiRate e.V.

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

_Archiving and preservation_

</td>  
<td>

The data is stored and maintained in ChainReact’s Google apps account

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

##  WP2 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP2_1_Whistle_Research_Informing_Design_Data**

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

_Data set description_

</td>  
<td>

This data-set includes all data collected in relation to research that informs
the design of The Whistle. The nature of this data will include audio-visual
recordings of interviews and user testing sessions \- along with the
associated consent forms, transcriptions, interview/test plans and participant
recruitment lists/documents. This data-set will be stored in a google drive
folder, and relevant people from the project team will be granted access. This
data-set is likely to support scientific publications, in which case
transcripts or excerpts may be shared alongside these publications. This data-
set will not be particularly large, and should not exceed 1 gigabyte in size.

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

_Standards and metadata_

</td>  
<td>

The top-level google drive folder will contain sub-folders for the following:

  * Documents containing interview questions and related materials 

  

  * Interview recordings  Interview transcripts 

  

  * Interview recruitment tracking 

  

Files relating to interviews will be stored within sub-folders named for the
organisation they relate to with titles denoting the person who was
interviewed.

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

_Data sharing_

</td>  
<td>

This data-set will be shared with all relevant project team members through
their google accounts.

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

_Archiving and preservation_

</td>  
<td>

As this data-set will be stored in a google drive folder, it will benefit from
a version history and there should be no issue with its preservation.

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

##  WP3 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP3_1_Whistle_Reports**

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

_Data set description_

</td>  
<td>

A restricted data-set encompassing the full detail of all incoming civilian
witness reports and attachments for The Whistle. The Whistle will run
reporting campaigns, in collaboration with NGOs, to collect reports from
civilian witnesses. When a civilian witness submits a report this will create
a record on The Whistle’s secure server, for the purpose of the data
management plan all such reports are being treated as a single data-set. In
practice, only nominated representatives of the partner NGO for each campaign
will be allowed to access reports related to that campaign. The precise nature
and scale of this data-set will depend on the choice of reporting campaigns.
Ethics deliverable 9.2 contains further detail on how this data will be stored
and transmitted, and deliverable 2.1 contains detail on the ethical review of
prospective campaigns (which includes review of which data will be stored and
procedures for data collection). This data-set will contain sensitive
information, and therefore storing and transmitting it securely is a central
concern for the project. This data-set may be used in academic research, and
therefore may underpin a scientific publication.

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

_Standards and metadata_

</td>  
<td>

As The Whistle is in the early stages of development the choice of a specific
standard for storage of this data is yet to be made. The data for incoming
reports will be similar to that produced by standard web forms that allow
attachments. The choice of a specific standard will be determined by security
considerations.

When a report is submitted, it will be stored along with meta-data such as the
time of creation and IP address of submitter. The Whistle will also allow
aspects of a report to be passed through relevant external APIs that could
facilitate work on verification of its authenticity. Results of these API
calls will also be stored as additional meta-data for a report.

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

_Data sharing_

</td>  
<td>

Due to the sensitive nature of this data-set, access will be tightly
restricted. Only nominated representatives of the partner NGO for a campaign,
and relevant people within the project team, will have access to this data. A
reporting campaign may also produce aggregated or de-personalised data that
can be published on sites like wikirate.org (thus forming part of the
Data_WP5_1_WikiRate_Site_Cards data-set). The manner in which publicfacing
data is produced for a campaign will be considered as part of the ethical
review for a prospective reporting campaign.

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

_Archiving and preservation_

</td>  
<td>

The full data for reports will be retained on the secure server until 3 months
after the reporting campaign ends - at which point it will be transferred to a
secure archive housed separately to the data for live campaigns. Data held in
this archive will only be used for research purposes. Preservation of this
archived data-set will be the responsibility of the research team at
Cambridge. At the point when this data-set serves no further research purpose,
or cannot be maintained securely, it will be destroyed.

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

##  WP4 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP4_1_Possible NGO Partners**

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

_Data set description_

</td>  
<td>

Contacts and engagement data-set to track charities that could be partner with
The Whistle to run test reporting campaigns

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

_Standards and metadata_

</td>  
<td>

Data is stored in a Google Sheet with columns representing:

  * Charity name 

  

  * Location 

  

  * Website 

  

  * Contact Email 

  

  * Funding Band 

  

  * Purpose 

  

  * Digital Literacy 

  

  * Country Focus 

  

  * Population Focus 

  

  * Notes 

  

  * Interview Status 

  

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

_Data sharing_

</td>  
<td>

This data set will be shared with all relevant team members working on the
interview study and outreach with possible partners for The Whistle.

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

_Archiving and preservation_

</td>  
<td>

As this data-set is stored in a google sheet it will benefit from a version
history and there should be no issue with its preservation.

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

##  WP5 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP5_1_WikiRate_Site_Cards**

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

_Data set description_

</td>  
<td>

The primary Wagn database for the WikiRate.org website.

(Note that the assets for this website are treated as a separate dataset,
because they will involve separate archiving and preservation.)

All of WikiRate’s core concepts – Companies, Metrics, Topics, Claims, Reviews,
Sources, and Projects – as well as more standard content like Users and simple
webpages, are organized as cards within a wagn website.

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

_Standards and metadata_

</td>  
<td>

Like all Wagn sites, WikiRate.org is organized into “cards”, and all data are
stored in the same five tables (cards, card_acts, card_actions, card_changes,
and card_references.) As noted in _Data_WP1_1_ChainReact_Docs_Site_ above, for
every edit of every card (including name, type, and content changes), Wagn
stores:

  * a userstamp 

  

  * a timestamp, and 

  

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_1_WikiRate_Site_Cards**

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

</td>  
<td>

 an IP address.

Wagn also supports a REST API that allows this data to be made available in
many formats. Company data will be made available in many standard formats,
including JSON, XBRL, and simpler formats like CSV.

Many metrics themselves contain standardized data. Initially, standards
conformity will be enforced via community feedback and editing, though some
automation will likely be added in later stages.

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

_Data sharing_

</td>  
<td>

Account login information, including encrypted passwords, are protected and
made invisible to web users. All other information on WikiRate.org is
available for reading and download by the general public.

Some metric data providers have requested download limitations so that their
original datasets could not be reconstructed from WikiRate.org. We are
currently weighing the benefits of supporting such limitations (and thus
receiving permission to put more data on WikiRate.org) vs. the costs of having
to support more restrictions and communicate the nature of and rationale for
these restrictions to users.

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

_Archiving and preservation_

</td>  
<td>

Development and promotion of this dataset is the core focus of WikiRate eV,
who intend to see it thrive and grow long after the end of the current
project, supported by broad fundraising and community-building strategies.

The entire database is archived nightly, with a full version tarred and copied
to a remote server. We also frequently make full and partial copies to various
servers for use in development and testing.

Some site copies are used for experimenting with data that we are not yet
ready to publish for technical or social reasons, most commonly permission not
yet granted.

Wagn automatically handles card revisions, and the complete history of every
card is visible via the interface.

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_2_WikiRate_Site_Assets**

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

_Data set description_

</td>  
<td>

Files uploaded to WikiRate.org, including images, structured and unstructured
source files, and optimized CSS and JavaScript.

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

_Standards and metadata_

</td>  
<td>

Metadata for these files are stored as cards in the previous dataset,
_Data_WP5_1_WikiRate_Site_Cards._ Each asset is stored with a card_id and
action_id that allows it to be mapped to that dataset.

However, because our multi-server architecture calls for a canonical database
engine on one server and canonical file service elsewhere, these two datasets
will be tracked separately.

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

_Data sharing_

</td>  
<td>

All files are publicly available. Direct links to the data are provided on
WikiRate.org

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

_Archiving and preservation_

</td>  
<td>

At present, the data remain on our production server and, like the production

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

_Data set reference and name_

</td>  
<td>

**Data_WP5_2_WikiRate_Site_Assets**

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

</td>  
<td>

database, are archived and backed up nightly. Soon they will be moved to an
independent server or cloud service in support of WikiRate.org’s designed
multi-server architecture.

As with _Data_WP5_1_WikiRate_Site_Cards,_ maintenance and development of this
dataset is connected to the primary focus of WikiRate e.V. and will be central
to ongoing planning, fundraising, and promotion.

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_3_CERTH_ Companies**

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

_Data set description_

</td>  
<td>

CERTH’s company entities collection that have been and are going to be
obtained by Web data extraction using easIE (an easy-to-use information
extraction framework).

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

_Standards and metadata_

</td>  
<td>

A schema-free document-oriented database is used which allows us to add or
remove fields from the collection without impact to the database soundness.
Each company is described by the following:

  * id 

  

  * company_name 

  

  * aliases 

  

  * website 

  

  * address 

  

  * country 

  

  * wikirate_id: this field is present only in companies that have been integrated to WikiRate platform. 

  

  * opencorporates_id: this field is present only if there is a matching entity in OpenCorporates database. 

  

Company mapping task will result to the integration of companies between
OpenCorporates and WikiRate. Additional fields might be considered in order to
represent the relationships between companies in our dataset derived from
OpenCorporates corporate networks.

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

_Data sharing_

</td>  
<td>

A RESTful API will be available for anyone who wishes to have access to the
dataset. The data will be available in JSON format.

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

_Archiving and preservation_

</td>  
<td>

Preservation will be ensured by backup of the original database.

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_4_Metrics**

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

_Data set description_

</td>  
<td>

CERTH’s metrics collections that have been and are going to be extracted from
external Web sources by using easIE (an easy-to-use information extraction
framework).

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

_Standards and metadata_

</td>  
<td>

A schema-free document-oriented database is used which allows us to add or
remove fields from the collection without impact to the database soundness.
Each metric is described by the following:

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

**|** P a g e  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP5_4_Metrics**

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

</td>  
<td>

  * name 

  

  * value 

  

  * referred_company 

  

  * citeyear 

  

  * source 

  

  * source_name 

  

  * type 

  

  * currency 

  

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

_Data sharing_

</td>  
<td>

The collected metrics will be available through a RESTful API for anyone who
wishes to have access to the dataset. The data will be available in JSON
format. We encourage people and companies to reuse our data and contribute to
data collection task regarding companies’ CSR performance.

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

_Archiving and preservation_

</td>  
<td>

Preservation will be ensured by backup of the original database.

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_5_WikiRate_Usability**

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

_Data set description_

</td>  
<td>

Results of user testing and design, including think aloud tests, analytics,
reading material, etc.

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

_Standards and metadata_

</td>  
<td>

The top-level google drive folder contains sub-folders for the following:

  * Lean UX Activities 

  

  * UX Design 

  

  * UX Research 

  

Files will be named with descriptive titles coupled with date and version
information. Interview recordings and transcript file names will contain the
name of the organisation represented by the interviewee, a number denoting the
interview’s order and date information.

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

_Data sharing_

</td>  
<td>

This data-set will be shared with all relevant project team members through
their google accounts.

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

_Archiving and preservation_

</td>  
<td>

As this data-set will be stored in a google drive folder, it will benefit from
a version history and there should be no issue with its preservation.

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_6_OpenCorporates_Corporate_Relationship_Sources**

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

_Data set description_

</td>  
<td>

This is the list of potential sources for relationship data, compiled for the
report as part of WP5.1. This dataset is not kept in a database, but in the
Google Doc, which is the master document for the report (rather than the
derived Word Document supplied as a deliverable).

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

_Standards and metadata_

</td>  
<td>

As this is kept in a Google Document, all changes to it are automatically
tracked.

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

_Data sharing_

</td>  
<td>

This is a list of “not yet published” data and is therefore private.

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

_Archiving and preservation_

</td>  
<td>

As the dataset is in the cloud, there is automatic archiving. We also
periodically export the report into different forms (e.g. Word Docs).

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_7_OpenCorporates_Companies**

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

_Data set description_

</td>  
<td>

This dataset is the core dataset of over 100 million companies in
OpenCorporates, all obtained from primary public sources by OpenCorporates

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

_Standards and metadata_

</td>  
<td>

The OpenCorporates company data has multiple fields and attributes, often
deeply nested and rich. The conceptual schema is described (using JSONschema)
at  **_https://github.com/openc/opencschema/blob/master/build/company-
schema.json_ ** (this schema is opensource).

All data is fully provenance, describing both the source and retrieval
timestamp

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

_Data sharing_

</td>  
<td>

The data is available through the OpenCorporates enterprise-level API
(Application Programming Interface), which provides rich querying and
retrieval.

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

_Archiving and preservation_

</td>  
<td>

The data lives on our production MySQL database, which lives on our
multiserver architecture (master + slave + backup slave), which is backed up
daily, with historical backups.

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

_Data set reference and name_

</th>  
<th>

**Data_WP5_8_OpenCorporates_Corporate_Structures**

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

_Data set description_

</td>  
<td>

This dataset is the corporate structure information OpenCorporates has
extracted from official public sources (includes shareholding, subsidiary,
control relationships from company registers, SEC, other regulators)

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

_Standards and metadata_

</td>  
<td>

The OpenCorporates corporate structure data is modelled using our own model,
which is open source (see
**_https://github.com/openc/opencschema/blob/master/build/_ ** for schemas),
and described in  **_a series_ ** **_of_ ** **_blog posts_ ** .  As the data
comes from multiple sources, with varying levels of details and subtle
differences in meaning (for example the way shareholding is represented), the
models need to be able to cope with this, in particular both high and low
granularity, significant ambiguities, and different natures of the
relationship (e.g. shareholding, subsidiaries, other control relationships).

All data is fully provenanced, describing both the source and retrieval
timestamp

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

_Data sharing_

</td>  
<td>

The data is available through the OpenCorporates enterprise-level API
(Application Programming Interface), which provides rich querying and
retrieval. As part of this project we will be working with the partners to
enhance retrieval of corporate structure information via the API

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

_Archiving and preservation_

</td>  
<td>

The data lives on our production MySQL database, which lives on our replicated
multiserver cluster (master + slave + backup slave), which is backed up daily.
In addition, we use a replicated Neo4J cluster for storing the relationships
in a graph database. This is also backed up daily

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

##  WP6 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP6_1_Corporate Engagement**

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

_Data set description_

</td>  
<td>

Contacts and engagement database to help us identify targets and progression
towards corporate engagement

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

_Standards and metadata_

</td>  
<td>

Data will be collected through Google tracking sheets and where possible
tracked in Salesforce software.

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

_Data sharing_

</td>  
<td>

This data set will be shared with all relevant team members working on
outreach, partnerships and engagement. Additionally analysis of this data set
may be used at periodic project meetings to indicate progress and consider
direction

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

_Archiving and preservation_

</td>  
<td>

Salesforce is a dynamic database which will exist in perpetuity whilst
WikiRate e.V. benefits from the non-profit license. If we ever need to migrate
to another software the entire database can be exported. Google sheets will
also exist in perpetuity, and offer a layer of tracking and analysis which
Salesforce cannot capture alone.

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

##  WP7 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP7_1_Collective_Awarness_Platforms_Research**

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

_Data set description_

</td>  
<td>

This data set will be used to analyse the functioning of ChainReact as a prime
example of Collective Awareness Platform. It will be the result of
extract/transform process that will retrieve the data from various ChainReact
databases (especially the repositories of The Whistle and Wikirate), combine
them and transform into the form suitable for research.

The dataset will describe in detail the actions of ChainReact users – their
interactions with the platform, their uploads, their site navigation paths,
etc. It will be used to calculate various indicators describing the overall
functioning of ChainReact.

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

_Standards and metadata_

</td>  
<td>

The specific technology and data model of research dataset is contingent on
the final structure of source databases and the design of research the dataset
will be used for. Both these aspects being under development, there is a wide
range of storage choices being considered at the moment, from standard SQL
schemas, to XML/JSON containers, to graph databases.

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

_Data sharing_

</td>  
<td>

The data set will be initially shared among ChainReact members. It will be
made available publicly as the background for research activities.

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

_Archiving and preservation_

</td>  
<td>

The specific location of the dataset (and consequently archiving and
preservation policies) is yet to be decided. Existing ChainReact
infrastructure (servers) could be used or specific cloud or local solution be
chosen, depending on the dataset and research requirements that will be
decided in the course of the project.

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

_Data set reference and name_

</th>  
<th>

**Data_WP7_2_Title_ChainReact_Evaluation**

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

_Data set description_

</td>  
<td>

This data set comprises of various forms of data needed to evaluate ChainReact
in terms of progress towards the realisation of its goals and the quality of
its inner functioning. The data set includes the progress reports and other
communication with consortium partners, the audio recordings and transcripts
of interviews with ChainReact team members, participatory observation notes
and results of desk research activities.

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

_Standards and metadata_

</td>  
<td>

The data set will be stored as a google drive folder with subfolder structure
reflecting the nature and structure of research material.

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

_Data sharing_

</td>  
<td>

The data-set will be shared mainly among the researchers performing
evaluation. The less sensitive elements of the data-set (eg. progress reports,
desk research notes) will be made available for general reuse by Consortium,
while one-to-one communication recordings will be treated as confidential and
shared only among researchers directly involved in evaluation tasks. The
access control to the data will be realised by google drive sharing mechanism
with possibility of encrypting particular file containers as an extra security
layer.

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

_Archiving and preservation_

</td>  
<td>

The archiving of the data set will be realised by google drive persistence and
versioning mechanism. The data-set will be stored for two years after final
evaluation report, in accordance with evaluation standards, for the purpose of
verification and auditing. After two years the data set will be discarded.

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

##  WP8 Datasets  
  
<table>  
<tr>  
<th>

_Data set reference and name_

</th>  
<th>

**Data_WP8_1_NGO Engagement**

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

_Data set description_

</td>  
<td>

Contacts and engagement database to help us identify targets and progression
towards NGO engagement

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

_Standards and metadata_

</td>  
<td>

Data will be collected through Google tracking sheets and where possible
tracked in Salesforce software.

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

_Data sharing_

</td>  
<td>

This data set will be shared with all relevant team members working on
outreach, partnerships and engagement. Additionally analysis of this data set
may be used at periodic project meetings to indicate progress and consider
direction

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

_Archiving and preservation_

</td>  
<td>

Salesforce is a dynamic database which will exist in perpetuity whilst
WikiRate e.V. benefits from the non-profit license. If we ever need to migrate
to another software the entire database can be exported. Google sheets will
also exist in perpetuity, and offer a layer of tracking and analysis which
Salesforce cannot capture alone.

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

#  Conclusion

This Data Management Plan identifies the datasets managed by the ChainReact
consortium organized by work packages. As detailed under section 3 of this
report “ChainReact Datasets”, the nature of these datasets vary according to
each components’ roles and responsibilities. For example, CERTH’s company
metadata are collected and maintained through the easIE extraction framework
and preserved through regular backup of the database, whereas the outreach
plan set by WikiRate manages a database of contacts and leads that are
categorised according to their outreach status (connection established/not,
connection success/pending, etc.).

The ChainReact datasets are evolving. Therefore, DMP is a living document that
will keep being updated through the lifetime of the project.