#  Foreword

For this initial draft of the plan, we have collected the information
available at work package levelto give a higher level of details in the
replies.

#  1\. Data Summary

1A) What is the purpose of the data collection/generation and its relation to
the objectives of the project?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Model output from by climate scenarios and prediction systems will be
collected and analyzed to meet the objectives of the project including
tailored and value added products as input to the development of climate
services (WP5).

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

2

</td>  
<td>

Will work with and generate ocean and atmospheric reanalysis data. Model
reanalysis will initially be used as a benchmark on observed oceanic heat and
salt transport towards the Arctic from partners observing systems and mooring
arrays.

Model, satellite and ocean observational data are collected from existing
repositories. The data will be part of the analysis in the WP2 deliverables.
For instance, the reanalysis will be used to compute energy transports in
relation to Arctic variability, ocean observations will be combined with
satellite data to improve knowledge of the Atlantic meridional overturning and
heat flux at subpolar latitude. New Earth Observations will be integrated with
ocean observations to obtain robust basin estimates and these estimates
compared with to state‐ofthe‐art coupled climate models and high resolution
ocean‐only models.

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

3

</td>  
<td>

Generation of data includes a set of coordinated climate model experiments.
This requires the use and compilation of shared forcing and boundary
condition. The data will be generated and analyzed to meet the objectives of
the project including identification of lower latitude drivers of arctic
change.

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

4

</td>  
<td>

This WP will generate sub‐seasonal to decadal climate predictions with the aim
to estimate decadal predictability including the role of Greenland ice sheet
melting. Development and application of new novel initialization techniques
and coordination of experiments across predictions systems requires
compilation and sharing of data internally.

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

5

</td>  
<td>

Data feeding into the development of services are primarily developed in
WP1‐4.

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

1B) What **types and formats of data** will the project generate/collect
(model, observations, consultation ?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Numerical model simulations will be compiled and conducted. Model data will be
in NetCDF file format.

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

2

</td>  
<td>

Generated and collected reanalysis data (NorCPM, MERRA and ERA5), climate
model and CMIP data will be in NetCDF file format. Some model data are
originally in GRIB, but will be transferred with CMOR (
_https://cmor.llnl.gov/_ ) to NetCDF CF conventions and with the CMIP6
protocol as decided by the CMIP panel of the World Climate Research Program.

Ocean observations including hydrographic data, moored ocean current
observations and data from Argo floats will to the widest possible extend be
compiled in NetCDF but in some cases native formats are required to facilitate
analysis. ASCII or CSV formats may be used for timeseries data.

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

3

</td>  
<td>

Modeling data will be generated, using the NetCTD file format.

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

4

</td>  
<td>

Model data from prediction systems will be archived and shared amongst
partners using

NetCDF. For specific prediction systems, the WMO GRIB file format is standard
for atmospheric fields.

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

5

</td>  
<td>

When developed, services are expected to deliver information according to
specific user requirements. Initial formats applied during the development
phase follow WP1‐4.

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

1C) Will you re‐use any existing data and how, indicate links to previous or
ongoing projects?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Data will be ‘re‐used’ from:

  * Model output: CMIP5 (previous) and CMIP6 (ongoing) 

  

  * Model output: Copernicus Climate Change service – seasonal forecasts (previous and ongoing) 

  

  * Several different re‐analyses and observational products. 

  

The analysis and tailoring of products that will be conducted have to our best
knowledge not been undertaken in any previous and ongoing projects, but
complement previous and ongoing project efforts.

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

2

</td>  
<td>

It is planned to re‐use CMIP5 and CMIP6 data in addition to existing
reanalysis data, for example from the French L‐IPSL Labex project. Relevant
simulations for WP2 assessments also come from the PRIMAVERA project.

We share the control simulations and extend the number of control simulations
to have a better signal/noise ratio. There are also links to the APPLICATE
project. We will re‐use the baseline seasonal predictions (in collaboration
with BSC) from that project, while we will focus on individual events in
Blue‐Action.

WP2 will use the publically available hydrographic cruise data (e.g. OVIDE and
EEL), Argo data, moored ocean transport time series (from e.g. RAPID, OSNAP,
GSR‐observatory that are linked to e.g. EU projects NaClim and AtlantOS and
national projects (e.g. RACE II (Germany) and

FARMON (Denmark)) and satellite data from CMESM (former AVISO data).

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

3

</td>  
<td>

For comparison, we will use existing observation/reanalysis data. Available
data from CMIP6 model simulation will be also re‐used.

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

4

</td>  
<td>

Data from the past CMIP5 and available CMIP6 contributions will be used for
analysis. Data from the SPECS projects including specific hindcast and
forecast will enter the analysis.

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

5

</td>  
<td>

Re‐use of data is not envisioned in the final services except as indicated for
WP1‐4.

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

1D) What is the origin of the data?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The data will be generated by the climate model simulations by each partner of
the project. Those data will be generated using the computing facilities of
each partners or using shared resources.

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

2

</td>  
<td>

**Generated model data:** Specific facilities of each partners used to
generate data includes the IPSL/CNRS reanalysis data which are created on the
French TGCC supercomputer, NLeSC data is generated at SURFSara’s CARTESIUS
supercomputer and ECMWFs supercomputer capabilities.

**Collected data:** Reanalysis data that already exist are freely downloadable
from ECMWF (ERA, ORA), NCEP‐NCAR (NCEP reanalysis), NASA (MERRA) and JMA
(JMA).

Publically available ocean observations are collected from websites like Argo,
Ocean SITES and national repositories. Satellite data are collected from the
Copernicus CMEMS webpage. Time

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

</td>  
<td>

series of ocean variable are also used, e.g. new time series of the Atlantic
Overturning Circulation and heat flux across the Greenland‐Portugal Line (
_http://www.seanoe.org/data/00353/46445/)_

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

3

</td>  
<td>

Coordinated simulations generating climate model data are conducted at the
computing facilities of each partner or at shared facilities.

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

4

</td>  
<td>

Coordinated predictions generating climate model data are conducted at the
computing facilities of each partner or at shared facilities, for example:

  * IPSL/CNRS data are created on the French TGCC supercomputers (http://wwwhpc.cea.fr/fr/complexe/tgcc.htm) 

  

  * CMCC data will be generated using the CMCC‐CM2 climate model. Those data will be generated using the computational facilities available at CMCC. 

  

  * DMI will make use of the EC‐Earth coupled climate model running on the high performance computing facilities at DMI/IMO. 

  

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

5

</td>  
<td>

The origin of model data are specified for WP1 and WP4 delivering input to WP5

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

1E) What is the expected size of the data?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The project related model data archives can reach several TBs for one member
of the ensemble simulations that will be generated. Therefore about 1000 TBs
in total will be generated and stored by each partners.

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

2

</td>  
<td>

The size of the generated data such as the IPSL/CNRS reanalysis will depend on
the list of outputs (fields, variables) shared with Blue‐Action partners. This
is still to be decided. Collected data: The simulated data is the largest part
and this will amount up to 500 TB.

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

3

</td>  
<td>

The project related model data archives can reach several TBs for one member
of the ensemble simulations that will be generated. Therefore about 1000 TBs
in total will be generated and stored by each partners.

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

4

</td>  
<td>

A precise figure for the size of the data is still not available, as this will
depend on the number of hindcasts that will be performed, the number of model
variables and their respective saving frequency. However, expectedly the data
size will be of the order of several tens of TBs.

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

5

</td>  
<td>

Data in WP5 are generally value added synthesis of WP1 and WP4 outputs and
data linked to specific services will only be a fraction of these archives.

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

1F) To whom might it be useful outside the project ('data utility')?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The data can be useful to general climate research community and beyond
including the cluster of H2020 projects funded under BG9, 10 and 11\.

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

2

</td>  
<td>

The research community in a broad sense. Modeling groups for validation,
climate system analysis.

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

3

</td>  
<td>

The data can be useful to general climate research community.

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

4

</td>  
<td>

The data can be useful to the wide climate research community, from experts in
climate dynamics, operational oceanography to climate impact analysts. Due to
the idealized nature of part of the simulations that will be performed in WP4,
such model data will mainly be usable by the climate research community.

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

5

</td>  
<td>

Climate service centers in general and targeted stakeholder groups. The
utility of data is to be explored in part as dedicated cluster activities and
in part through the co‐development and codesign of services with stakeholders
(partners).

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

**2\. FAIR data**

##  2\. 1. Making data findable, including provisions for metadata

2.1A) Will 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)?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

It is not relevant and the plan in the project to make the entire data
identifiable and locatable by means of a standard identification mechanism.
Since part of the project is to test novel approaches, the data generated
within the project need to be scientifically ‘quality controlled’ before
sharing widely. Beyond that, the seasonal re‐forecasts conducted in the
project are scientific and should be applied with proper knowledge of the
involved uncertainties. Hence, we expect that data can most appropriately
shared based on individual contacts.

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

2

</td>  
<td>

For specific reanalysis produced (IPSL/CNRS) this will be investigated. For
time series of ocean variables it is not outlined, but will be pursued (e.g.
Pangea).

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

3

</td>  
<td>

It is not feasible or planned plan in the project to make the dataset
identifiable and locatable by means of a standard identification mechanism.

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

4

</td>  
<td>

Individual partners (e.g. IPSL/CNRS) will investigate the feasibility to make
certain datasets locatable and identifiable. Their progress and experiences
will serve to guide the WP partner approach.

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

5

</td>  
<td>

The approach will be considered at a later stage in the development process.

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

2.1B) What naming conventions do you follow, if relevant?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

When applicable, post‐processing of output will follow the CMOR convection
(for CMIP‐style simulations). Seasaonal re‐forecasts will follow the C3S
conventions, which will likely become standard during the project’s lifetime.

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

2

</td>  
<td>

For reanalysis, CMOR (CMIP6). In general CF conventions and CMOR 3 is used for
model data according to the CMIP6 protocol (the ece2cmor code for generating
the data from the raw data is available on github and NLeSCs eSTEP online).
For ocean observations naming conventions are not an issue.

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

3

</td>  
<td>

No convention will be imposed on the participants, in the case model output
data will be used mostly by project partners. When and where resources are
available to post‐process the data, CMOR convention is preferred by partners.

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

4

</td>  
<td>

Need to be decided as part of the coordination. CMOR convention as used within
CMIP6 is a possibility.

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

5

</td>  
<td>

Not relevant.

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

2.1C) Will search keywords be provided that optimize possibilities for re‐use?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Not relevant, see above.

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

2

</td>  
<td>

CMIP6 and CMOR will suffice for model data. For ocean observations exploited
in Blue‐Action, this activity will lie outside the project where observations
are collected.

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

3

</td>  
<td>

CMIP6 and CMOR will suffice for model data.

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

4

</td>  
<td>

This is not planned but the advantages will be investigated (IPSL/CNRS).

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

5

</td>  
<td>

This will be addressed when services are in a more mature state of
development.

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

2.1D) Do you provide clear version numbers?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Model data will be provided with specific reference to model version.

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

2

</td>  
<td>

  * IPSL/CNRS reanalysis: yes, for model versions, assimilation method version. 

  

  * Model outputs (NLeSC): Yes, for the model and for the data generated. 

  

  * Ocean observations and derived products and parameters: when relevant. 

  

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

3

</td>  
<td>

Model data will be provided with specific reference to model version.

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

4

</td>  
<td>

Model versions and type (hindcasts/forecast) will be supplied and we will
follow the CMIP6

naming convention.

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

5

</td>  
<td>

Relevant for product updates.

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

2.1E) 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.  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

As suggested by CMIP/DCPP and C3S.

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

2

</td>  
<td>

IPSL/CNRS reanalysis: CMOR (CMIP6)

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

3

</td>  
<td>

CMOR convention from CMIP6 is a possibility

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

4

</td>  
<td>

CMOR convention from CMIP6

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

5

</td>  
<td>

Not applicable

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

###  2.2. Making data openly accessible

2.2 A) Which data produced and/or used in the project will be made openly
available as the default?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The model data can be openly available on request (see comment above). The
partners will provide the facility for the data exchange, according to their
resources available.

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

2

</td>  
<td>

Model output will be or can be made available on request from partners; all
reanalysis data (IPSL/CNRS) will be openly available. For Ocean observations,
data are open as default.

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

3

</td>  
<td>

The model data can be openly available by request. The partners will provide
the facility for the data exchange, according to their resources available.

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

4

</td>  
<td>

The model data can be openly available by request. Partners will provide the
facility for the data exchange on an ad‐hoc basis and according to the
resources available.

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

5

</td>  
<td>

Not by default

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

2.2 B) Note that in multi‐beneficiary projects it is also possible for
specific beneficiaries to keep their data closed if relevant provisions were
made in the consortium agreement.  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

No beneficiaries have generally closed their data according to the CA.
Exceptions for specific datasets exists.

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

2

</td>  
<td>

No beneficiaries have generally closed their data according to the CA.
Exceptions for specific datasets exists.

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

3

</td>  
<td>

No beneficiaries have generally closed their data according to the CA.

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

4

</td>  
<td>

No beneficiaries have generally closed their data according to the CA.

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

5

</td>  
<td>

No beneficiaries have generally closed their data according to the CA.
Exceptions for specific datasets exists.

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

2.2 C) 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?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The data will be stored by individual institutional depositions, and also (to
be developed during the course of the project) at C3S (seasonal forecasts
only). Methods or software tools to access the data can be institutional
dependent.

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

2

</td>  
<td>

Reanalysis (IPSL/CNRS) data will be provided in NetCDF format. They could be
provided in a depository or any other solution agreed upon within the
consortium. Other model outputs: In the repistories of SURFSara (NLeSC) or
CMIP5/CMIP6 (NERSC). Ocean observations including time‐series will be
transferred to _http://www.oceansites.org_ (under development) to the extent
found relevant.

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

3

</td>  
<td>

The data will be stored by individual institutional depositions. Methods or
software tools to access the data can be institutional dependent.

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

4

</td>  
<td>

In general data will be provided in NetCDF format and provided in a partner
depository or ftp solution. Other general solution may be agreed upon within
the consortium. For example, specific partners may choose to make use of
THREDDS Data Server

(https://www.unidata.ucar.edu/software/thredds/current/tds/) as it will be
easily accessible on the supercomputer used to run the simulations.

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

5

</td>  
<td>

Under consideration.

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

2.2 D) 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)?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

In general, documentation about the software needed to access the data is
publically available.

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

2

</td>  
<td>

NetCDF will be used for reanalysis and model data. NetCDF is open source. It
will also be used for most observational data. No documentation for other
observational data is needed.

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

3

</td>  
<td>

In general, documentation about the software needed to access the data is
publically available.

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

4

</td>  
<td>

NetCDF is open source. Documentation for the use of the software relevant for
data access will be made publicly available. This includes packages for
decoding GRIB data.

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

5

</td>  
<td>

Not applicable

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

2.2 E) 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.  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The data and associated metadata, documentation and code will be deposited at
institutional level.

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

2

</td>  
<td>

The question of deposition is to be decided for the reanalysis data
(IPSL/CNRS). The NLeSC: SURFSara’s repository used by certain partners (NLeSC)
is a trusted and certified repository. For other partners, the data and
associated metadata, documentation and code will as a minimum be deposited at
institutional level. Ocean observations including time‐series will be
transferred to _http://www.oceansites.org_ (under development) to the extent
found relevant.

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

3

</td>  
<td>

The data and associated metadata, documentation and code will be deposited at
institutional level.

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

4

</td>  
<td>

The data and associated metadata, documentation and code will be deposited at
institutional level.

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

5

</td>  
<td>

Data will be part of prototype services and deposited at institutional level.

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

2.2 F) Have you explored appropriate arrangements with the identified
repository? If there are restrictions on use, how will access be provided?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

We have not explored project‐specific arrangements with the respective
repositories.

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

2

</td>  
<td>

Only for the SURFSara’s repository used by certain partners.

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

3

</td>  
<td>

We have not explored appropriate arrangements with the identified repository.

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

4

</td>  
<td>

There is normally no restriction on the depositories identified, but if any,
they could be removed on request. Partners choosing a FTP server solution with
access limited to the BlueAction WP4 partners will have no restrictions.

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

5

</td>  
<td>

Not applicable.

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

2.2 G) Is there a need for a project data access committee?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Over time, many individual agreements might be better followed by a joint
committee or an internal wiki‐page, where policies and data exchanges are
documented.

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

2

</td>  
<td>

No, but there is a need to explore possibilities and agree on a list of
variables to be exchanged. There should be contact points and all should use
DOIs.

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

3

</td>  
<td>

A committee or a group is needed.

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

4

</td>  
<td>

The need of a project data access committee exists according to a number of
partners. This reflects the coordinated nature of work in the WP and in the
first phase a forum at WP level will be created reporting to the Project
Office.

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

5

</td>  
<td>

Not at project level.

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

2.2 H) 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?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Currently, all data exchange is within the project (though across WPs, and
hence with WP5 also to ‘stakeholders’) and by individual agreement (including
specification of purpose). If the number of requests increases, this will have
to be organized (see above).

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

2

</td>  
<td>

Most data are open.

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

3

</td>  
<td>

The present plan is that the data will be available by individual request. We
do not have a good way to ascertain the identity of individual person
accessing the data.

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

4

</td>  
<td>

The present plan is that the data will be available by individual request. We
have not identified a way yet to ascertain the identity of individual person
accessing the data.

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

5

</td>  
<td>

Not applicable

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

##  3\. Making data interoperable

2.3 A) 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)?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

In general, data can be exchanged and re‐use between researchers,
institutions, organizations, countries. However, dependent on complexity of
individual models, documentations are likely needed.

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

2

</td>  
<td>

For model and reanalysis data, the standard format allows interoperability,
although NetCDF is not like rdf, and semantically link with other data is not
possible. Observational data are fully

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

</td>  
<td>

interoperable.

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

3

</td>  
<td>

In general, data can be exchanged and re‐use between researchers,
institutions, organizations, countries. However, dependent on complexity of
individual models, documentations are likely needed.

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

4

</td>  
<td>

Interoperability and re‐use is ensured by the use of NetCDF and GRIB data
formats

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

5

</td>  
<td>

Data and products generated are intended to be interoperable and re‐useable.

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

2.3 B) What data and metadata vocabularies, standards or methodologies will
you follow to make your data interoperable?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

No specific standards.

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

2

</td>  
<td>

 Reanalysis and model data: CMOR (CMIP6) and netcdf  Observational data:
n.a.

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

3

</td>  
<td>

No specific standards.

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

4

</td>  
<td>

CMOR (CMIP6) for standard CMIP6 simulations

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

5

</td>  
<td>

No specific standards.

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

2.3 C) Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

No plan to do that.

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

2

</td>  
<td>

Yes

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

3

</td>  
<td>

No plan to do that.

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

4

</td>  
<td>

For standard CMIP6 simulations, yes.

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

5

</td>  
<td>

No plan.

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

2.3 D) 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?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

We do not plan to use uncommon ontologies or vocabularies in the project.

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

2

</td>  
<td>

We do not generate linked data, so this is a step beyond what is envisioned
and needed now. The metadata standards suffice.

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

3

</td>  
<td>

We do not plan to use uncommon ontologies or vocabularies in the project.

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

4

</td>  
<td>

We do not plan to use uncommon ontologies or vocabularies in the project.

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

5

</td>  
<td>

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

###  2.4. Increase data re‐use

2.4 A) How will the data be licensed to permit the widest re‐use possible?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Wide use of our data is ensured for example by participation in CMIP6 and C3S
(Copernicus). Appropriate re‐use will be ensured by making known what kind of
experiments we conducted so that they can be available on request.

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

2

</td>  
<td>

Software potentially generated in the project will have APACHE license, the
data is fully open.

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

3

</td>  
<td>

We plan to join in larger modeling communities to promote the wider re‐use of
data.

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

4

</td>  
<td>

By ad‐hoc access of data to relevant scientific partners with the purpose of
common scientific work.

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

5

</td>  
<td>

No licensing considered.

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

2.4 B) When will the data be made available for re‐use outside the project? 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.  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

As we make data available on request, we expect to discuss the purpose of the
data use on individual agreement (at minimum a short documentation of the
intention to avoid overlaps). Therefore, we expect to general embargo, and
follow the standard practice (which is, that data can be made available once
we published them).

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

2

</td>  
<td>

No embargo on central reanalysis products (IPSL/CNRS). Ocean observations are
not embargoed.

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

3

</td>  
<td>

After publication, data will be shared with the science communities outside
the project upon request with no specific embargo time but possibly limited by
resources available at partner level.

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

4

</td>  
<td>

A limited time embargo will be applied in order to secure the publication of
coordinated experiments in high‐ranked journals co‐authored by the WP4
investigators.

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

5

</td>  
<td>

No specific embargo time considered.

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

2.4 C) 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.  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Data are usable and not restricted. Reuse may require a good knowledge of the
data, description of limitations, biases, etc.

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

2

</td>  
<td>

Data are usable and not restricted. Reuse may require a good knowledge of the
data, description of limitations, biases, etc.

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

3

</td>  
<td>

Data are usable and not restricted. Reuse may require a good knowledge of the
data, description of limitations, biases, etc.

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

4

</td>  
<td>

Data re‐use will be possible modulo a good knowledge / description of
limitations, biases, etc. The access to model simulations produced within the
WP4 should be made available for scientific research to third parties. The use
for commercial applications after the end of the project will be decided and
regulated at project‐level or as outlined in the consortium agreement.

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

5

</td>  
<td>

Regulated by the CA.

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

2.4 D) How long is it intended that the data remains re‐usable?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

It is decided by either the project or the individual institution.

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

2

</td>  
<td>

At least 5 years for model data, observational data remains re‐usable without
limit.

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

3

</td>  
<td>

It is decided by either the project or the individual institution.

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

4

</td>  
<td>

Possibly without limitation but this will be subject to the individual
partners resource availability **,** once the project is over.

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

5

</td>  
<td>

No limitations considered.

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

##  3\. Allocation of resources

3 A) What are the costs for making data FAIR in your project?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The project has no specific funds to cover the data management cost and these
efforts have not been independently assessed. Costs are embedded in the work
of the research and development teams.

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

2

</td>  
<td>

The project has no specific funds to cover the data management cost and these
efforts have not been independently assessed. Costs are embedded in the work
of the research and development teams.

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

3

</td>  
<td>

The project has no specific funds to cover the data management cost and these
efforts have not been independently assessed. Costs are embedded in the work
of the research and development teams.

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

4

</td>  
<td>

The project has no specific funds to cover the data management cost and these
efforts have not been independently assessed. Costs are embedded in the work
of the research and development teams.

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

5

</td>  
<td>

The project has no specific funds to cover the data management cost and these
efforts have not been independently assessed. Costs are embedded in the work
of the research and development teams.

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

3 B) 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).  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Open access and other eligible costs may be covered by the individual partners
budgets in the projects.

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

2

</td>  
<td>

Open access and other eligible costs may be covered by the individual partners
budgets in the projects.

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

3

</td>  
<td>

Open access and other eligible costs may be covered by the individual partners
budgets in the projects.

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

4

</td>  
<td>

Open access and other eligible costs may be covered by the individual partners
budgets in the projects.

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

5

</td>  
<td>

Open access and other eligible costs may be covered by the individual partners
budgets in the projects.

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

3 C) Who will be responsible for data management in your project (DMI \+ WP
responsible persons)?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

WP leader

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

2

</td>  
<td>

Juliette Mignot (IPSL/CNRS), tbc.

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

3

</td>  
<td>

WP leader

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

4

</td>  
<td>

Didier Swingedouw(IPSL/CNRS), tbc.

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

5

</td>  
<td>

WP leader

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

3 D) 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?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Discussions pending.

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

2

</td>  
<td>

Discussions pending.

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

3

</td>  
<td>

Discussions pending.

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

4

</td>  
<td>

Discussions pending.

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

5

</td>  
<td>

Discussions pending.

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

##  4\. Data security

4 A) What provisions are in place for data security (including data recovery
as well as secure storage and transfer of sensitive data)?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

Following institutional and/or national provisions

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

2

</td>  
<td>

The data are not considered sensitive. Data are securely stored within
repositories.

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

3

</td>  
<td>

Following institutional and/or national provisions

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

4

</td>  
<td>

We will mainly follow institutional or national provisions.

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

5

</td>  
<td>

Assessment of sensitive data is pending.

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

4 B) Is the data safely stored in certified repositories for long term
preservation and curation?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

The project relies in part on certified repositories which ensures long term
preservation and partly on institutional repositories. In general these are
considered safe and will be kept assessable for exchange for the time needed
to the partners to exploit model simulations and publish the most relevant
results. In the longer term (beyond the project duration) these data may be
archived but their availability will be limited.

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

2

</td>  
<td>

The project relies in part on certified repositories (observations,
reanalysis) which ensures long term preservation and partly on institutional
repositories. In general these are considered safe and will be kept assessable
for exchange for the time needed to the partners to exploit model simulations
and publish the most relevant results. In the longer term (beyond the project
duration) these data may be archived but their availability will be limited.

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

3

</td>  
<td>

The project relies in part on certified repositories which ensures long term
preservation and partly on institutional repositories. In general these are
considered safe and will be kept assessable for exchange for the time needed
to the partners to exploit model simulations and publish the most relevant
results. In the longer term (beyond the project duration) these data may be
archived but their availability will be limited.

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

4

</td>  
<td>

The project relies in part on certified repositories which ensures long term
preservation and partly on institutional repositories. In general these are
considered safe and will be kept assessable for exchange for the time needed
to the partners to exploit model simulations and publish the most relevant
results. In the longer term (beyond the project duration) these data may be
archived but their availability will be limited.

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

5

</td>  
<td>

To be detailed.

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

**5\. Ethical aspects**

5 A) 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).  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

We have not identified any ethical or legal issues yet.

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

2

</td>  
<td>

We have not identified any ethical or legal issues yet.

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

3

</td>  
<td>

We have not identified any ethical or legal issues yet.

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

4

</td>  
<td>

We have not identified any ethical or legal issues yet.

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

5

</td>  
<td>

To be evaluated.

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

5 B) Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?  
  
<table>  
<tr>  
<th>

WP

</th>  
<th>

Description

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

1

</td>  
<td>

No privacy issues.

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

2

</td>  
<td>

No privacy issues.

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

3

</td>  
<td>

No privacy issues.

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

4

</td>  
<td>

No privacy issues.

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

5

</td>  
<td>

Will be addressed at a later stage.

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

##  6\. Other issues

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

WP

</th>  
<th>

Description

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

1

</td>  
<td>

No other procedures identified.

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

2

</td>  
<td>

The Dutch national e‐infrastructure is used, in particular SURFSara which is
nationally funded. For ocean ocean observations: Ocean Sites, possibly others.

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

3

</td>  
<td>

No other procedures identified.

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

4

</td>  
<td>

No other procedures identified.

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

5

</td>  
<td>

No other procedures identified.

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