updates are worked out in eLTER-PPP WP3 Data Management Plan and Data Policy. Will be available by 2025

will be replaced by the eLTER RI Data Specification latest by 2025

local data provision could derive from that

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

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.

EISCAT_3D is in the commission phase, and is expected to deliver first data late 2023

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

Standard, compatibility with B2FIND harvesting, etc

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.

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.

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)

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.

There's no metadata-data linking schema used. Metadata is usually part of the dataset (in case of Level 3 data in Madrigal the metadata is part of the HDF5 file, in the case of L1 and L2 data, metadata is part of the dataset download).

The EISCAT Schedule provides a human readable overview of experiments and their archived data. Madrigal also provides a machine actionable web service API.

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

EISCAT is a PITHIA-NRF node; this ontology is planned for use in the PITHIA-NRF e-science centre search engine.

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

To be findable, all compounds in TOXRIC come with a unique and persistent identifier, TAID, which is used to link the toxicology and feature data of each compound.
TOXRIC_TAID | TOXRIC Unique ID for chemicals

As the web is dynamic this is planned for longevity: Current link is: https://toxric.bioinforai.tech/

TOXRIC incorporates identifiers and physicochemical properties of compounds from PubChem, and provides external links to PubChem on compound page. Users can click on the PubChem CID to link to the corresponding compound page of PubChem website. In addition, TOXRIC web provide links to all the related databases on the External Database Links page

No mention of metadata in the publication or on the website, only the description of the curation processes: The curation process of toxicology data consists of three parts: compound screening, data source integration, and unit standardization.

Search by SMILES possible for identification of the chemicals

Representation of the chemicals via InChI

Need to check this with the database developers as not specified which ontologies they use

Need to check with database developers as not specified fully.

Not sure here - checking with the database provider

TOXRIC’s curation paradigms are fully described in the manuscript. All datasets collected in the database are described in detail on Data Collection page and can be reused in downloadable files with machine-readable formats (.csv) on Download page of the website. Datasets are lsisted here: https://toxric.bioinforai.tech/collectionDataSource

As a database for ML, is likely to also capture computational or predictive datasets so this could be a good option also.

Usual implementation of CrossRef for journal article type publications.

Via publishing partner of IUPAC's journal where IUPAC formal standards are published.

Used in local implementations, could be used in metadata schema associated with chemical datasets.

Data format associated with some journals and compiled datasets.

Under development; to be recommended for reporting and handling data in journals and compiled datasets.

As appropriate where reference to formal chemical concepts are part of standard specifications.

Instrument vendors, analysis software, ELNs, repositories.

Each term in the IUPAC Gold Book has a registered DOI in CrossRef as a book chapter (https://www.crossref.org/documentation/research-nexus/books-and-chapters/); IUPAC Gold Book is overall 'book' (http://doi.org/10.1351/goldbook); term DOI metadata must include source PAC citations.

Presently being reviewed in an IUPAC project for the Gold Book.

CrossRef Events data (e.g., Wikipedia), https://www.crossref.org/services/event-data/

In order for the TOXRIC to continue to grow and expand, the developers rely on the community to contribute. Users can contribute toxicology data to TOXRIC by uploading data in the contribute box on Contribute page or contacting the developers. => Need Unique identification of data providers.

TOXRIC is freely accessible for academics from a stable, permanent web address (https://toxric.bioinforai.tech/), and does not require account creation or logon.

TOXRIC is freely accessible for academics from a stable, permanent web address (https://toxric.bioinforai.tech/), and does not require account creation or logon. TO

Need to clarify this with database owners but JSON mentioned in the paper

to maximise interoperability and mapping

Described on the website as: Toxicity categories: https://toxric.bioinforai.tech/toxicity. Feature space: https://toxric.bioinforai.tech/collectionFeature

Not sure but bioschema is a good option to consider

In discussion with the database provider.

In discussion with the database provider to select optimal solution. Will remove the unused ones in due course.

FIP.15.T8 | PARC FIP1 T8 - by Barbara Magagna

FIP.19_FCM | PARC_FAIR Convergence - by Barbara Magagna

Eumitrin F-H was isolated from Usnea baileyi

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

Non-systematic usage among platforms Information Systems.

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

Currently for part of the data produced by the platforms.

URI identifier of the MassBank Record following a specified schema

Such a nanopublication represents an annotation of a text according to the Web Annotation Vocabulary.

a snippet of text immediately before the selected text

a snippet of text immediately after the selected text

the URI/URL of the source that is being annotated

is a - connects a thing (left) to the class (right) it belongs to

has the value - links an identifier to its (textual) value

web annotation - a web annotation of a document or other thing

text quote selector - a text quote selector describes a range of text by copying it, and including some of the text immediately before (a prefix) and after (a suffix)

refers to the text - refers to a copy of the text which is being selected

has as body - connects an annotation to its body element

has as selector - connects an annotation to its selector

has the source - links to the source that is being annotated

has as target - connects an annotation to its target

refers to the text right after - refers to a snippet of content that occurs immediately before the content which is being selected

refers to the text right before - refers to a snippet of content that occurs immediately after the content which is being selected

PARC | Partnership for the Assessment of Risks of Chemicals - by (unknown)

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

Metadata in JSON format through REST API

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

metadata of Argo floats available from Global Data Assembly Centre
Argo GDAC | Argo floats metadata dashboard

We think that a persistent identifier for individual cycle file (2 million of them) should be provided. It won't be DOI, it should be a handle.

There should be one pid per Argo float cycle. There are more than 2 million cycles. The pid will be resolved by an Ifremer 'argo data selection' web landing page.

The one-click download of Argo data and metadata is avilable from this DOI: https://doi.org/10.17882/42182

Google dataset search is efficient for cross domain search.

The metadata access is anonymous. The download statistics from https and ftp servers are analyzed without user identification.

The long term preservation of Argo dataset is shared by Ifremer and US-NCEI. Both sites preserve and mint regular DOIs of the whole dataset (monthly snapshots)

The Argo DOI representation language is compliant with DataCite RDF schema and RDF Schema.org

Argo metadata such as sensor type, history records are recorded in Argo NetCDF self descriptive variables. The controlled vocabularies are published on NVS vocab server.

The provenance information is recorded in Argo NetCDF implementation documented on http://dx.doi.org/10.13155/29825

The Argo ontology uses PROV-O to record provenance information. This information can be queried from Argo SPARQL endpoint: https://sparql.ifremer.fr/argo/query.

There is one and only Argo GDAC DOI to cite and access Argo data: (Argo (2023). Argo float data and metadata from Global Data Assembly Centre (Argo GDAC). SEANOE. https://doi.org/10.17882/42182.

The Argo Opensearch engine is available on : https://opensearch.ifremer.fr/

This is a data selection tool with Argo specific subsetting criteria (parameters, deployment years, network). Its API is : https://dataselection.euro-argo.eu/swagger-ui.html#. Its web interface is: https://dataselection.euro-argo.eu

Argo metadata such as sensor type, history records are recorded in Argo NetCDF self descriptive variables. The controlled vocabularies are published on NVS vocab server. Example of Argo parameter codes (Terms describing individual measured phenomena, used to mark up sets of data in Argo NetCDF arrays) : https://vocab.nerc.ac.uk/search_nvs/R03/

The DCAT-AP description of Argo dataset is part of the more general RDF-OWL Argo ontology. http://www.argodatamgt.org/Documentation/Argo-vocabulary-server/Argo-linked-data-and-SPARQL-endpoint

The Argo OGC-sensorthings API is : https://sextant.ifremer.fr/examind/WS/sts/coriolis/v1.1

We use DataCite and Schema.org for Argo data and metadata DOI

The Argo ontology uses PROV-O to record provenance information. This information can be queried from Argo SPARQL endpoint: https://co.ifremer.fr/co/argo-linked-data/html/Argo-HTML-SPARQL/

The Argo ontology RDF is available on https://www.ifremer.fr/co/argo-linked-data/doc/argo-floats.ttl. This ontology is used by Argo SPARQL endpoint : https://co.ifremer.fr/co//argo-linked-data/html/Argo-HTML-SPARQL/

The Argo vocabularies used in NetCDF files are published on NVS vocab server. Example of Argo parameter codes (Terms describing individual measured phenomena, used to mark up sets of data in Argo NetCDF arrays) : https://vocab.nerc.ac.uk/search_nvs/R03/

Argo data and metadata follows the NetCDF-CF conventions

The data and metadata organization are described in: Argo user's manual, http://dx.doi.org/10.13155/29825. It describes the NetCDF CF implementation for Argo data

The Argo GDAC DOI (https://doi.org/10.17882/42182) uses the schema.org metadata schema.

The data access is anonymous. The download statistics from https and ftp servers are analyzed without user identification.

Catalogue documenting all digital assets of the eLTER RI.

FIP.15.T9 | PARC FIP1 T9 - by Barbara Magagna

Madrigal is a de facto standard for distributing analysed data from incoherent scatter radars and other upper atmospheric instruments. It shares metadata from all sites among its instances as simple text files. Madrigal provides both a browser GUI, in recent versions developed in Django, as well as web services with APIs.

OPeNDAP has been considered during Danubius-PP.

OGC CS has been considered during Danubius-PP.

eduGAIN has been decided during Danubius-PP.

At the moment, in Danubius there is no implemented repository.

Several options are considered. No final decision yet.

Community relevant. Used for legacy data.

DataCite metadata schema is going to be used for data collections

Being the LifeWatch ERIC Metadata Catalogue published online, Google automatically indexes its main pages.

It represents the standard de facto as secure communication protocol.

The knowledge representation languages used for datasets depend from the LifeWatch ERIC national node. Some examples are XMLS, CSV, DwC-A, NetCDF, etc.

The LifeWatch ERIC Metadata Catalogue actually allows to manually specify the thesaurus/vocabulary to be used for a given field (e.g., keyword, type, etc.) but in the future we plan to use drop-down and autocomplete lists for the semantic annotation of metadata fields and values by using semantic artifacts provided by the EcoPortal platform.

The structured vocabularies used to encode datasets depend on the LifeWatch ERIC national node.

We use the ISO 19139:2007 profile for several kinds of resources (e.g., services, workflows, virtual research environments, etc.).

We use the EML 2.2.0 standard for datasets metadata records.

A mixture between mostly CC-BY, CC-0 and CC-BY-NC is used, it depends on the LifeWatch ERIC national node.

The DOIs are the best way to permanently identify a given digital object, in a format controlled by the International DOI Foundation. We have an agreement with DataCite and this will guarantee the cross-domain findability. When a DOI is not available, users can specify a persistent internal identifier.

The authentication & authorisation technique for datasets depends from the LifeWatch ERIC national node. For example, in some cases the access through ORCID is currently used, in other cases the traditional login mechanism that identifies and authenticates users through the couple of credentials (username and password) is used.

In the future we will use the PARTHENOS Entities (PE) to extend the ontological model and the RDF schema of different assets.

The models, schemas used for datasets depend from the LifeWatch ERIC national node. Some examples are DwC-A, NetCDF, etc.

We use the ISO 19139:2007 profile for several kinds of metadata resources, that are: services, workflows, virtual research environments, and research sites.

The XML allows us to exchange metadata records among distributed sources. This format is used to download metadata records both in the LifeWatch ERIC Metadata Catalogue and EcoPortal.

EcoPortal API returns JSON as the default content type.

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.

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.

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

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

Will be replaced by the eLTER RI Data Specification.

currently under development. draft prototype ready

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.

UUID are appended to the URI of the eLTER Catalogue (Digital Asset Register, DAR). UUID is also used in DEIMS-SDR to identify the MD records for sites, locations, sensors and networks

for eLTER a community profile based on the INSPIRE required fields and requirements for EML 2.0 was definded using a local schema which is mapped to ISO19115/19139 to expose metadata. For the Digital Asset Register (DAR) metadata are held in schema-neutral json document, which allows sharing of ISO19115/19139 metadate as a schema-on-read service through a RESTful API.

this is implemented for site datasets (processing level 0 and 1) using EUDAT B2SHARE as common repository. For the eLTER Central Data Node (CDN) this is under development and will be implemented 2025 onwards.

currently under development. the eLTER Digital Asset Register will be operational by end 2023 focusing n the documentation of digital assets (datasets, models, provenance) of the eLTER RI

currently within eLTER we use a combination of web services from DEIMS-SDR, DAR, B2SHARE and DataCite to disseminate metadata covering the different assets of the RI

DEIMS-SDR contains metadata to existing data repositories and linking dataset metadata to the respective eLTER facilility

the eLTER Central Data Node (CDN) currently contains storage of time series data (OGC SOS), geospatial data (OGC WMS/WFS) as well as files. The eLTER CDN is currently still under development and will be operational by mid 2024.

the eLTER DIP (EcoSense) is a web interface to view and access information on datasets shared

currently implemented within the eLTER Digital Asset Register (DAR)

SPARQL (open) endpoint serving the SPARQL semantic query language to retrieve and manipulate data stored in Resource Description Framework (RDF) format

User authenticates (login/passwd) against the internal catalog database of the GeoNetwork instance.
GeoNetwork account in the internal catalog database

Automatic conversion from internal metadata format to Datacite

This is a data selection tool with Argo specific subsetting criteria (parameters, deployment years, network). Its API is : https://dataselection.euro-argo.eu/swagger-ui.html#

The Argo vocabularies used in NetCDF files are published on NVS vocab server

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

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.

Recommended within ENVRI Atmospheric community

Recommended within ENVRI Atmosphere community

Metadata longevity plan is part of IAGOS Data Preservation Policy

CF standard names has been chosen as Reference vocabulary by ENVRI Atmosphere community. Used for observed variables

Community standard. Used for observed variables, instrument types and platform type

The community would like to establish a mechanism to cite data(sets) in scientific publication to better show the value of data and increase the incentive to make it publicly available. DOIs, often in addition to data warehouse specific unique identifiers, will help with that since they put the datasets on the same level as other citations.

Implementation was tested in the prototype combining institutional repositories and nano-specific warehouses.

Similar to institutional repositories, this listing needs to be integrated into (or even replaced by) a more general solution. Even if this might be helpful for getting datasets provided e.g. as supporting material of scientific publications into this general solution, the need to curate the metadata manually limits the available entries.

Database provided by the NanoCommons project to host data from many different EU funded projects.

Database specifically designed to provide data for model development and nanoinfomatics applications

To my knowledge is this the underlying mechanism of the EOSC and ELIXIR A&A

Use to represent the eNanoMapper ontology.

Major activity of the nanosafety community to cover all data for risk assessment.

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

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

Home made JSON format, compliant with standards

Home-made metadata format compliant with standards

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

Internal format compliant with ISO standard

Conversion of all data to NetCDF planned.

Metadata uses schema based on ISO19115/139

open, free, and universally implementable protocol

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

Seadatanet products have implemented CC-BY

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

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

Extended metadataschema based on ISO19139 to accommodate for oceanography specifics

Aggregated records published via OpenSearch

A sparql endpoint is now available for aggregated records AND for original granularity with over 60M triples. in RDF... cdi.seadatanet.org/sparql

was already implemented behind marine-id

domain always requested into about preservation of data and metadata, captured in the data policy, however not machine actionable

The NVS have been developed by BODC based on the SDN requirements and specifically fulfill the needs of the marine data community. Vocab L22 now added in the metadata to describe sensor information, and a link to sensor instance info added.

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

part of the metadata model, used when sharing biodiversity data via BIO-ODV format

NVS service used as main vocabulary for parameters, instruments, etc. vocab L22 - Sensor type - added in metadata.

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

extended sensor metadata, which is available from a ref from the metadata xml.

There was already provenance info in the metadata, now added more info about sensors via L22 and link to sensor instance (SWE).

added as part for envrifair work to describe the sensor info as prov for the data

Aggregated CDI records will be distributed via spra

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

Aggregated records exposed to GEOSS Geoportal

A sparql endpoint is now available for aggregated records AND for original granularity with over 60M triples. in RDF... cdi.seadatanet.org/

added to CDI (and other metadata directories) metadata as part of envrifair work

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

DataCite DOI will be assigned to data collections

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

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

Data download via primary repositories through HTTPS.

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

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

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

Widely used for data citation, mainly used by us for collections and elaborated data products

Handle PIDs are used for all data objects at the highest possible granularity

As defined by the CP white paper and to implement the open data sharing defined by the statutes of ICOS ERIC.

Used in Jupyter hub and many other applications by the community for easy access to SPARQL, ontology, metadatahttps://pypi.org/project/icoscp/

The m2m interfaces to interact with the meta and data services and other back end services are based on REST 'inspired' https calls. The calls are document at the CP github repository at pages https://github.com/ICOS-Carbon-Portal/meta and https://github.com/ICOS-Carbon-Portal/data

For ORCID and Facebook identity providers

ICOS is set up for the long term, 20-25 years starting from 2015. Statutes and data policy mention that data and metadata should be preserved also after that. In case ICOS ERIC is wound down in the future there will be a one year period to develop the contingency plan. All current landing pages generated dynamically by our metadata system can then be generated as static html pages that will together form a frozen metadata system which can be served by a simple static website at very low cost or be integrated as sub-site in another permanent website.

CF-1.7 compliant netcdf metadata included in the netcdf data objects

All ICOS data is available open and free.

Standard in the community and recommended within ENVRI Atmospheric community

Recommended within ENVRI Atmospheric community. Automatic conversion from IAGOS metadata pivot format to datacite profile

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

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

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

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)

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

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.

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

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.

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

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.

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

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.

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?

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

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.

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

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

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

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

5 years min. as defined in the ACTRIS DMP

used for fully quality controlled data, open for anybody.

widely used, no need for authentication.

Handle server hosted by AERIS with a prefix obtained from ePIC

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

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

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

Metadata available in the ACTRIS data portal through HTTPS.

Direct download via primary repositories through HTTPS.

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.

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

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

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.

The AOP-Wiki serves as the primary repository of qualitative information for the international AOP development effort coordinated by the Organisation for Economic Co-operation and Development (OECD)

The eNanoMapper ontology covers the full scope of terminology needed to support research into nanomaterial safety. It builds on multiple pre-existing external ontologies such as the NanoParticle Ontology

The PARC Human Biomonitoring Data FIC facilitates the availability and (re)use of Human Biomonitoring (HBM) datasets created or used in the context of the PARC Project for the benefit of the broader chemical risk assessment community.

FIP.14 CON1| Pamdemic PACT FIP consultation 1

FIP.16.CON1 | PARC FIP 1 E2a Event consultation

GloPID-R brings together funders investing in research related to new or re-emerging infectious diseases. Our aim is to increase preparedness and speed up the research response to outbreaks with pandemic potential. GloPID-R facilitates coordination and information sharing among major global funding organizations through our working groups, guidance, tools, and multiple resources. Through our worldwide network of research funders, we facilitate coordinated investment to improve preparedness and a rapid research response to epidemics and pandemics. The overriding aim of our work is to impact global health by saving lives.
GloPID-R | Global Research Collaboration for Infectious Disease Preparedness

This nanopublication consists of hand-coded statements in the form of RDF triples where subject, predicate, as well as object values can be arbitrarily set.

A startup company registered in Switzerland

This nanopublication expresses a causal (e.g. "A causes B"), spatio-temporal (e.g. "A is included in B"), or comparative (e.g. "A is larger than B") relation between two things.
Expressing a simple causal, spatio-temporal, or comparative relation

Describes lifecycle of metadata within SC GMP DWH
SCGMPDWH_MPP | Stockholm Convention Global Monitoring Plan Metadata Preservation Policy

Dataset can be identified by URI and downloaded.

In the future we are going to use FAIR Data Point or/and SPARQL API

Not FAIR enough. Will be transformed into vacabulary.

Stockholm Convention Global Monitoring Plan DWH

This nanopublication maps identifiers to labels, which can be used, for example, to populate drop-down lists of input forms.

This nanopublication includes a text that is citing an existing paper, where that citation is typed with the Citation Typing Ontology (CiTO).
Making a statement about a paper using CiTO

This nanopublication is a recommended example of a superpattern claim.

The Research Organization Registry (ROR) includes IDs and metadata for more than 102,000 organizations and counting. Registry data is CC0 and openly available via a search interface, REST API, and data dump. Registry updates are curated through a community process and released on a rolling basis.

The HBM4EU Project is a pan-European research project gathering Human BioMonitoring Data

Files are encrypted by themselves with private and public keys.

HBM4EU | Human BioMonitoring 4 EU Project

Expressing a general claim with a super-pattern

informal label or text for the whole superpattern instance

universal context (i.e. no context restriction)

This nanopublication makes a statement that in the context of a thing of a certain type (e.g. a mouse), another thing of a certain type (e.g. a gene) tends to have a relation (such as causing) to another thing of a certain type (e.g. a disease) in the same context.

More information about the super-pattern can be found in this publication: https://doi.org/10.1145/3460210.3493561

organizer of the event (ROR, URL or name)

This nanopublication expresses a causal (e.g. "A caused B"), spatio-temporal (e.g. "A is included in B"), or comparative (e.g. "A is larger than B") relation between two things.

This nanopublication expresses a causal (e.g. "tends to cause"), spatio-temporal (e.g. "tends to include"), or comparative (e.g. "tends to be larger than") relation between the instances of two classes. The subject and object are classes, and the relations are defined based on the instances of these classes. All these relations start with "tends to ..." and therefore do not necessarily hold for all instances. This aspect of "tending to" is deliberately left underspecified. For more precise statements, use the super-pattern template instead.
Expressing a causal, spatio-temporal, or comparative relation between instances of classes

has instances that tend to affect instances of

has instances that tend to cause instances of
has instances that tend to be caused by instances of

has instances that tend to be followed by instances of

has instances that tend to be included in instances of

has instances that tend to be necessary and sufficient for instances of

has instances that tend to be necessary for instances of

has instances that tend to be the same as instances of

has instances that tend to be sufficient for instances of

has instances that tend to contribute to instances of

has instances that tend to co-occur with instances of

has instances that tend to decrease instances of

has instances that tend to enable instances of

has instances that tend to entail instances of

has instances that tend to follow instances of

has instances that tend to have a different value from instances of

has instances that tend to have a larger value than instances of

has instances that tend to have the same value as instances of

has instances that tend to have a similar value as instances of

has instances that tend to have a smaller value than instances of

has instances that tend to include instances of

has instances that tend to increase instances of

has instances that tend to inhibit instances of

has instances that tend to prevent instances of

has instances that tend to require instances of

the URI of your article (published or pre-print)

From research described in an article (published/preprint)