Marine-ID is generally accepted method and solution for AAA in the marine domain

Access via Marine-ID authentication in the CDI service

metadata records in RDf via SparQL endpoint

The NVS have been developed by BODC based on the SDN requirements and specifically fulfill the needs of the marine data community.

SDN has developed metadata directories for organisations, cruises, research projects, databases, that are involved in, or used by, the datacenters when collecting data. In the metadata of the datasets there are refs to these metadata directories (instead of free text!).

NVS service used as main vocabulary for parameters, instruments, etc.

metadata directories used as vocabularies to describe organisations, cruises, projects with relation to the data

metadata for datasets in CDI format are based on ISO19115/19139, extended with the domain profile with vocabs etc. The ISO requirement originates from the overarching infrastructures that demanded inspire standards.

also available - flattened for the sdn community profile

Now using https://www.seadatanet.org/Data-Access/License/1.0 but will be made as GUPRI under ENVRIFAIR, plus mapping to CCBY. Mapping has been made as preparation.

There is already provenance info in the metadata, but more info about sensors involved will be included.

Custom built identifier system set up before other PID systems were easily available.

PID assigned via B2Handle to each datafile when stored in cloud. Please mint a B2 Handle nanopub

Extended metadataschema based on ISO19139 to accommodate for oceanography specifics

No generic system was available, and because of the ammount of metadata records DOI's are not feasible. Therefore dedicated PID-CDI identifier solution.

Aggregated records exposed to GEOSS Geoportal

Dedicated user interface offering facets to search the large collection of data sets (>2.7M).

Overarching services demand harvesting of metadata via OGC services

Aggregated records published via OpenSearch

Aggregated CDI records will be distributed via spra

metadata records for aggregated CDI metadata in RDF via SparQL endpoint, original granularity will follow. as well as DCAT-AP compliance that will be introduced.

The NVS have been developed by BODC based on the SDN requirements and specifically fulfill the needs of the marine data community. However for provenance the used vocabs will be expanded with L22 (sensor type) as well as links to the Sensor Instance! (cant make this)

Now using https://www.seadatanet.org/Data-Access/License/1.0 but will be made as GUPRI under ENVRIFAIR, plus mapping to CCBY

ISO adopted PROV-O will be investigated, but probably better fit for data products (sextant). In CDI more info about sensors will be included.

There is already provenance info in the metadata, and more info about sensors will be included.

DOI assigned via Sextant to each metadata. Example : http://dx.doi.org/10.12770/a7b7d13f-0b95-445b-ba83-fe9357c9e154

DOI assigned via Sextant to each metadata

Metadata uses schema based on ISO19115/139

Dedicated search interface : https://www.seadatanet.org/Products#/search?from=1&to=30

sparql endpoint for Seadatanet products : https://sextant.seadatanet.org/sparql/

Harvesting of the catalogue bu using CSW : https://sextant.ifremer.fr/geonetwork/SEADATANET/eng/csw?SERVICE=CSW&REQUEST=GetCapabilities

open, free, and universally implementable protocol

Metadata records available in RDF via SPARQL endpoint : https://sextant.seadatanet.org/sparql/

NVS service used as main vocabulary for parameters, instruments etc.

metadata for products are based on ISO19115/19139, extended with the domain profile with vocabs etc. The ISO requirement originates from the overarching infrastructures that demanded inspire standards.

Seadatanet products have implemented CC-BY

There was already provenance info in the metadata,

Generally relevant. Used for direct download of data.

widely used, no need for authentication.

used for fully quality controlled data, open for anybody.

Metadata available in the ACTRIS data portal through HTTPS.

Data download via primary repositories through HTTPS.

ACTRIS internal vocabulary is used for variable names in the ACTRIS data portal.

Metadata are stored in a MongoDB database. Documents are identified by a UUID.

DOI are minted using the AERIS prefix (obtained via the French member of Datacite: INIST-CNRS)

Automatic conversion from internal metadata format to Datacite schema

Internal format compliant with ISO standard

Automatic conversion from internal metadata format to Datacite

Using Thredds data server. We would need to convert all data to the NetCDF format

Home made JSON format, compliant with standards

Conversion of all data to NetCDF planned.

Home-made metadata format compliant with standards

Conversion from EDF files to be done. Both format will be distributed

For some of the ACTRIS datasets, DOIs are still not available

Datacite is used by the parts of ACTRIS that have implemented DOIs for their datasets.

The metadata of the ACTRIS metadata catalog is indexed in WMO Information System (WIS) and available through their search engine.

Direct download via primary repositories through HTTPS.

5 years min. as defined in the ACTRIS DMP

Handle server hosted by AERIS with a prefix obtained from ePIC

Internal metadata format compliant with standards, incl. ISO 19115

Using Thredds data server. We need to convert all data to the NetCDF format

5 years min. as stated in the ACTRIS DMP

HDF4 files, a conversion to NetCDF is planned for ACTRIS but both formats will be distributed because HDF is required by NDACC

Cost effective solution, our data portal requires lots of PIDs due to large number of digital objects.

DOIs required for collections, e.g. yearly data sets.

Our data portal already assigns PIDs (EPIC handle) for any arbitrary data collection downloaded by the user.

EPIC handle PID points to DO landing page containing the URL of the actual file for downloading, and each file contains PID to the corresponding landing page.

Open access required by the community. Easy access to metadata.

Open access required by the community. Easy access to data.

A Handle PID is going to be assigned to all data products and instruments

DataCite DOI will be assigned to data collections

DataCite metadata schema will be used for data collections

All our (meta)data are NetCDF 1.7 compliant. The definition of new CF variable names is under discussion with CF community

Metadata in JSON format through REST API

NetCDF compliant with Climate and Forecasts (CF) Metadata Convention v1.7

Currently joining italian DataCite consortium

No specific constraints related to UUID use. Limitation is about the incomplete production of metadata records

Non-systematic and heterogeneous practice between platforms. Need for implementation support

Non-systematic usage among platforms IS.

DCAT-AP is intended to be the unifying profile in the ENVRI context. Starting state

GeoNetwork, in use in the AnaEE France community. CKAN portal under development at the AnaEE EU level (https://data.anaee.eu/)

In use in the AnaEE France community. CKAN portal under development at the AnaEE EU level,with the objective of indexing the platform remote catalogues

Preliminary state. Only registered users in a local internal database have write access.

Preliminary state for an institutional repository 1) Open access for published data on Dataverse repository 2) Restricted access for contributors

Use in the AnaEE France community. Netcdf files are generated from the AnaEE semantic pipelines. Will be extended to other AnaEE european platforms

Initially used in the AnaEE France community. To be extended to EU level

Initially used in the AnaEE France community. Extended to the EU level

INSPIRE compliance and metadata catalogue interoperability

Not yet implemented. Preliminary work in 2021

Not yet implemented. The objective is to add PROVenance elements to the semantic characterisation already in use in AnaEE for the description of data and their contexts, and to implement it using the developped pipelines

Planned at least in the AnaEE France community.

Preliminary state for an institutional repository. 1) Open access for published data on Dataverse repository. 2) Restricted access for contributors.

NetCD files will be generated from the AnaEE semantic pipelines. First for data French platforms then extended to other AnaEE european platforms.

Initially used in the AnaEE France community.

Initially used in the AnaEE France community. The (OBOE) extension for describing AnaEE experimentation is still under development.

Planned to be integrated in the AnaEE pipelines.

Not yet implemented. Planned to be integrated in the AnaEE semantic pipelines.

DCAT-AP is intended to be the unifying profile in the ENVRI context.

GeoNetwork, in use in the AnaEE France community.

In use in the AnaEE France community. CKAN portal wil be implemented at the AnaEE EU level, with the objective of indexing the platform remote catalogues.

Initially used by the AnaEE France community. To be extended to EU level.

The identifier should be able to handle Digital Specimens (a specific type of Digital Object) and related metadata.

A Registration Agency for Digital Specimen and Natural Science Collections data is needed given the diverse and cross-cutting needs for specimen data. A global engagement is required to realise the potential power of persistent identifiers.

DiSSCo does not specifically distinguish between data and metadata for digital specimen, allowing most data fields to be used also as metadata for discovery.

Understanding how schema.org works with the Digital Object Architecture.

The FAIR Digital Object model should be able to handle Digital Specimens (a specific type of Digital Object) and related metadata and a wide variety of collections and specimens data. For Digital Specimens, often there is no distinction between data and metadata, the attributes for the digital object should be index and discoverable.

A FAIR service providing access to Digital Specimens and Collections. Harmonising data from different types of collections and institutions of different sizes can be a challenge.

Ensuring interoperability between DiSSCo and GBIF infrastructures.

A FAIR service providing access to Digital Specimens and Collections. Harmonising data from different types of collections and institutions of different sizes can be a challenge. As each individual specimen is described as Digital Object, the dataset concept for DiSSCo is not clearly defined. Collection Object (group of Digital Specimens) can be thought of as datasets.

Different systems (bata providers are not aware of DOIP and not compatible yet.

A common guidelines and recommendations for application programming interfaces (APIs) is lac

DOIP is not natively supported in the systems currently used in the community. At the moment it only provides JSON response.

REST is widely use however, not all systems will have a REST API endpoint. Alternative would be to import the data

A single sign on (SSO) interface that is compatible with EOSC and AARC guidelines. Not all the institutions are AAI federation ready so alternative federated login options need to be provided (such as orcid, google).

A policy to help the community understand what data should be open or not. How to handle ethical and legal issues.

The Data Management Plan is a living document. Proper training, resources need to be in place for

DarwinCore Archive provides a mechanism to share data in a tab delimited format.

JSON Schema alone is not enough for validation, need semantic validation (JSON-LD etc.)

How to maintain the standards and vocabularies? How to make it usable for different systems?

Again, concept of datasets need to be defined within our community.

currently under development. Needs to align with existing specifications and also efforts from other research infrastructure in the biodiversity domain.

The specification design work in openDS is an iterative process. There will be pilots and testing done of the concepts via the cordra software implementation at nsidr.org

Each object contains a minimum of mandatory terms consistent with its formal object type definition, with the possibility to include optional additional terms and enrichments as necessary.

We might need to use different licenses for certain attributes of the objects. At the moment, our idea is as open as possible and as closed legally necessary. For example, hiding location data for endangered species.

Training and education for the data providers, managers, stewards for understanding different aspects of open data licenses.

There are other alternatives and options out there (Cloudevents, distributed ledgers, other transactional systems). How to combine these?

Availability (in contrast to DOIs), easy maintenance of local handle server, etc

Standard, compatibility with B2FIND harvesting, etc

Use has been evaluated in EUDAT prototype project

This is a legacy system that will be merged with the EISCAT_3D data portal in future. Implementation TBD.

MADRIGAL has served well for distributing analysed data from the legacy systems and will remain in use for that purpose. It will not scale well to EISCAT_3D data however.

Existing EISCAT datasets should be downloadable through a web browser. For future EISCAT_3D data it is planned to use DIRAC to stage data for analysis on grid or cloud resources.

Existing EISCAT datasets should be downloadable through a web browser. For future EISCAT 3D data it is planned to use DIRAC to stage data for analysis on grid or cloud resources.

Available identity providers of all EISCAT users, including those in China and Japan, must be federated.

An old de facto standard among incoherent scatter radars and other upper atmospheric instruments.

MADRIGAL data are archived in a legacy binary format. Transfer to a HDF5 based standard is going on.

Description was implemented as a prototype exercise in ENVRI.

Analysed data inserted in Madrigal are also indexed by experiment in https://handle.eiscat.se

DataCite metadata records are added when analysed results are converted from Matlab to HDF5 files.

EISCAT is a member o the PITHIA Network of Research Facilities and PITHIA builds upon developments during the ESPAS FP7 project.

A version of the EISCAT data download server which is an OIDC introspection enabled Checkin client has been developed.

Used in EISCAT HDF5 archive format for Level 3 data (analysed physical parameters)

De facto standard among legacy incoherent scatter radars

Archived Level 3 (analysed) data have been converted to two new HDF5 based archive formats. This includes MADRIGAL version 3 which now uses a HDF5 format as standard.

Analysed data from EISCAT radars (Level 3 data) are now archived in a dedicated HDF5 format and indexed in a SQL database with DataCite metadata records.

Persistent identification of research sites and observation facilities.

eLTER DIP is the central access point to eLTER metadata from a range of sources using geonetwork as backbone technology.

EUDAT B2FIND harvests eLTER metadata from DEIMS-SDR and the related B2SHARE repository. The effort was renewed within the implementation of the EOSC-Hub project. B2FIND is used as additional domain agnostic discovery portal.

DEIMS-SDR REST-API shares information on sites, locations, sensors, datasets and networks as json.

Direct download using https/http request for datasets shared via B2SHARE.

General eLTER data policy fosters open data. Restrictions might apply for site based data under embargo.

Will be replaced in the long run by the final eLTER RI Data Spec.

Information on metadata creation and update is provided as part of the MD model.

Used for datasets shared via B2SHARE. issuing DOI from the eLTER CDN will be implemented in 2022.

Persistent identification for research sites and observation facilities implemented in DEIMS-SDR.