Journal:Persistent identification of instruments

Full article title	Persistent identification of instruments
Journal	Data Science Journal
Author(s)	Stocker, Markus; Darroch, Louise; Krahl, Rolf; Habermann, Ted; Devaraju, Anusuriya; Schwardmann, Ulrich; D'Onofrio, Claudio; Häggström, Ingemar
Author affiliation(s)	TIB Leibniz Information Centre for Science and Technology, University of Bremen, British Oceanographic Data Centre, Helmholtz-Zentrum Berlin für Materialien und Energie, Metadata Game Changers, Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen, Lund University, EISCAT Scientific Association
Primary contact	Email: markus dot stocker at tib dot eu
Year published	2020
Volume and issue	19(1)
Article #	18
DOI	10.5334/dsj-2020-018
ISSN	1683-1470
Distribution license	Creative Commons Attribution 4.0 International
Website	https://datascience.codata.org/articles/10.5334/dsj-2020-018/
Download	https://datascience.codata.org/articles/10.5334/dsj-2020-018/galley/962/download/ (PDF)

Abstract

Instruments play an essential role in creating research data. Given the importance of instruments and associated metadata to the assessment of data quality and data reuse, globally unique, persistent, and resolvable identification of instruments is crucial. The Research Data Alliance Working Group Persistent Identification of Instruments (PIDINST) developed a community-driven solution for persistent identification of instruments, which we present and discuss in this paper. Based on an analysis of 10 use cases, PIDINST developed a metadata schema and prototyped schema implementation with DataCite and ePIC as representative persistent identifier infrastructures, and with HZB (Helmholtz-Zentrum Berlin für Materialien und Energie) and the BODC (British Oceanographic Data Centre) as representative institutional instrument providers. These implementations demonstrate the viability of the proposed solution in practice. Moving forward, PIDINST will further catalyze adoption and consolidate the schema by addressing new stakeholder requirements.

Keywords: persistent identification, instruments, metadata, DOI, handle

Introduction

Between March 2018 and October 2019, the Research Data Alliance (RDA) Working Group (WG) Persistent Identification of Instruments (PIDINST) explored a community-driven solution for globally unambiguous and persistent identification of operational scientific measuring instruments. A "measuring instrument" is understood to be a “device used for making measurements, alone or in conjunction with one or more supplementary devices,” as defined by the Joint Committee for Guides in Metrology (JCGM). Hence, PIDINST chose to address the problem of persistently identifying the devices themselves (i.e., each unique device), the real-world assets with instantaneous capabilities and configurations, rather than the identification of material instrument designs (i.e., models).

Instruments are employed in numerous and diverse scientific disciplines. Instruments can be static (e.g., weather station, laboratory instrument) or mobile when mounted on moving platforms (e.g., remotely operated underwater vehicles, drones). They may be used in observation or experimentation research activities. They may be owned and operated by individual researchers, research groups, national, international, or global research infrastructures or other types of institutions. For instance, at the time of writing, the Integrated Carbon Observation System (ICOS) operates approximately 3,000 instruments at over 130 stations in 12 European countries. Astronomy is well known for their intense use of telescopes. Those working in the life sciences employ an array of instrument types, ranging from microscopes to sequencers. The engineering sciences, too, make heavy use of instruments.

Persistent identifiers (PIDs) have a long tradition for the globally unique identification of entities relevant to or involved in research. They were developed “to address challenges arising from the distributed and disorganised nature of the internet, which often resulted in URLs to internet endpoints becoming invalid,” (Klump and Huber, 2017) making it difficult to maintain a persistent record of science. Examples for well established persistent identifiers include:

• the digital object identifier (DOI), used to identify literature, data files, and other objects;
• the Open Researcher and Contributor ID (ORCID), a persistent identifier for identifying researchers;
• the International Geo Sample Number (IGSN), a persistent identifier for physical samples and sample collections;
• the Research Organization Registry (ROR), a persistent identifier for organizations; and
• the Research Resource Identifier (RRID), an identifier for physical resources, such as mice and antibodies, in the life sciences.

Borgman suggested that “to interpret a digital dataset, much must be known about the hardware used to generate the data, whether sensor networks or laboratory machines.” Borgmann also highlights that “when questions arise […] about calibration […], they sometimes have to locate the departed student or postdoctoral fellow most closely involved.” A persistent identifier for instruments would enable research data to be persistently associated with such crucial metadata, helping to set data into context. Moreover, discovering and retrieving an instrument’s metadata through resolvable identifiers aligns with the FAIR data management principles, a set of guiding principles for the management of research data and its metadata by making them findable, accessible, interoperable, and reusable. Buck et al. suggested that data provenance information is fundamental to a user’s trust in data and any data products generated. They also recommended persistent identifiers for instruments as one of the next levels of data interoperability required to better understand and evaluate our oceans. Thus, more broadly, FAIR metadata about instruments is critical in the scientific and research endeavors.

In addition to improving the FAIRness of instrument metadata, the persistent identification of instruments is also important for trusted cross-linking to valuable scientific objects, such as the research data they produce, which can be persistently identified themselves. A similar argument can be made for cross-links between instruments and literature since instruments (typically the instrument model) are generally mentioned in the literature as materials. Such cross-linking has received considerable attention in the community. The Scholix project and the corresponding RDA/WDS Scholarly Link Exchange (Scholix) WG have recently proposed and implemented a common schema to standardize the exchange of information about the links between literature and data. As a result, it is now easier for a data publisher that discovers a link between data and literature to share this information, and for the publisher of the article to benefit by establishing a cross-link from literature to data. With the PID Graph, the FREYA Project is now generalizing cross-linking literature and data to other entities, including people, organizations, funders, etc. Arguably it makes good sense to enrich these connections by adding instruments.

Currently, there is no globally implementable way to persistently identify measuring instruments. Addressing this challenge, the present article describes the results of the work conducted by PIDINST, an 18-month RDA Working Group project that aimed at establishing a cost-effective, operational solution based on existing PID infrastructures, combined with a robust metadata schema for accurate identification, retrieval, and automation into workflows. The solution was demonstrated with two institutional instrument providers.

Methodology

The PIDINST Case Statement specified the working group (WG) objectives and deliverables. The WG took an agile-type (empirical and iterative) approach, engaging with members and stakeholders through virtual and physical RDA Plenary meetings to ensure the results met with requirements. PIDINST operated following the methodology described in more detail in this section, summarized as follows:

1. Collect use cases.
2. Identify common metadata.
3. Develop and publish the schema, and implement community feedback to its versions.
4. Catalyze schema implementation by existing PID infrastructure.
5. Prototype adoption by existing institutional instrument providers.
6. Engage the wider community at RDA Plenaries.
7. Hold regular biweekly virtual meetings.

PIDINST began with collecting use cases describing how a particular stakeholder would benefit from persistent identification of instruments. Use case descriptions included an introduction to the domain and infrastructure, related work by the infrastructure (if applicable), and a table describing the required properties of instrument metadata associated with the persistent identifier. The metadata properties were described for their name, occurrence, definition, value datatype, and an indication whether properties should be in metadata held by the PID infrastructure or the institutional instrument provider, for instance on the landing page.

Building on the use cases—in particular, the table describing the required metadata properties—PIDINST identified, organized, and harmonized the metadata properties that were common across use cases. We tabulated metadata properties as reported in use cases, harmonized their names (e.g., "Identifier," "Instrument Identification," and "Persistent Identifier" were harmonized as "Persistent Identifier"), counted property occurrence, and grouped properties into 10 categories that emerged from the metadata analysis (i.e., were not predefined).

Given the identified common metadata, PIDINST iteratively developed a schema and obtained community feedback, particularly at RDA Plenaries. The first version was presented at the RDA 12th Plenary Meeting (Gaborone, November 2018). Following suggestions from that discussion, the properties ownerContact, ownerIdentifier, ownerIdentifierType, manufacturerIdentifier, manufacturerIdentifierType, and modelName were added to the schema. The revised version was presented at the RDA 13th Plenary Meeting (Philadelphia, April 2019) and finally at the RDA 14th Plenary Meeting (Helsinki, October 2019). Each revision took into account community feedback at RDA Plenaries, as well as issues posted on GitHub.

Having developed and published a metadata schema, PIDINST initiated discussions on schema implementation with existing PID infrastructures, in particular DataCite and ePIC. The discussions, held at RDA Plenaries and in virtual meetings, aimed to (1) create awareness among these infrastructures about PIDINST developments and (2) catalyse implementation. In addition to implementation by existing PID infrastructures, PIDINST also actively supported the adoption by existing institutional instrument providers through engaging institution representatives at RDA Plenaries and in virtual meetings. Several institutions have shown interest in implementing the proposed solution (discussed later in "Adoption"), and some have already taken concrete steps (next section).

PIDINST had its kick-off meeting at the RDA 11th Plenary Meeting (Berlin, March 2018) and had working sessions at each subsequent Plenary until the 14th Plenary Meeting (Helsinki, October 2019), where the group had its wrap-up session. The working sessions were generally well attended by a highly engaged audience. The wider community feedback informed and validated the developments. The work was conducted between Plenaries, and coordination, as well as discussion, was supported by biweekly open participation virtual meetings. PIDINST continues to maintain its deliverables and will be represented at future Plenaries.

Results

Between November 2017 and October 2018, the WG collected 14 use cases. An additional use case was submitted in February 2019, resulting in a total of 15, of which 14 included the table describing the required metadata and are thus considered complete. The majority of use cases are in the earth sciences (60%). Table 1 provides an overview of the collected use cases. All use cases for which we have obtained author permission to publish are available on GitHub.

Table 1. Overview of the use cases collected by RDA WG PIDINST. "Submission" is the month of first use case submission by authors to the WG. "Completed" is the month during which the use case was completed with the required metadata. In some instances, the metadata was provided later. For UC4, the authors didn’t provide the metadata; the use case was thus not completed (N/A). For UC1, UC5, UC8, and UC15 the metadata was provided after October 2018; these use cases were thus not considered in the metadata analysis. * = Use cases used in analysis on October 2018 Use case Title Domain Main author Submission Completed 1 GEOFON Global Seismic Network Earth sciences Quinteros, J. 11/2017 03/2019 2 * Helmholtz-Zentrum Berlin für Materialien und Energie Multidisciplinary Krahl, R. 11/2017 06/2018 3 * National Imaging Facility, Australia Multidisciplinary Tapat, V. 12/2017 06/2018 4 Institute for Electromagnetic Sensing of the Environment (CNR) Earth sciences Oggioni, A. 01/2018 N/A 5 Sensor Information System (AWI) Earth sciences Macario, A. 04/2018 12/2018 6 * Marine Sensor Web Enablement Working Group Earth sciences Huber, R. 05/2018 05/2018 7 * ORCID Publisher Demeranville, T. 05/2018 08/2018 8 Integrated Carbon Observation System Carbon Portal Earth sciences D'Onofrio, C. 06/2018 12/2018 9 * British Oceanographic Data Centre Earth sciences Darroch, L. 07/2018 07/2018 10 * European Southern Observatory Astronomy Bordelon, D. 08/2018 08/2018 11 * Forschungszentrum Jülich, Central Library (literature supplier for large-scale research facilities) Publisher Frick, C. 09/2018 09/2018 12 * PANGAEA, Data Publisher for Earth & Environmental Science Publisher Devaraju, A. 09/2018 09/2018 13 * Permanent Service for Mean Sea Level Earth sciences Darroch, L. 10/2018 10/2018 14 * LTER-Europe Earth sciences Oggioni, A. 10/2018 10/2018 15 UK Polar Data Centre Earth sciences Tate, A. 02/2019 02/2019

Performed in October 2018, we used the metadata of 10 then-completed use cases (marked with a ^* in Table 1, Column 1) in an analysis that identified, organized, and harmonized the common properties. We tabulated properties, harmonized their names, counted property occurrence, and grouped properties into the following 10 categories: Identification, Instrument, Model, Owner, Manufacturer, Date, Capability, Output, Related Instrument, and Publisher. Table 2 summarizes the analysis of metadata common to the use cases.

Table 2. Overview of the collected metadata, analysis of common metadata and mapping of properties onto the PIDINST schema. * = Properties common to at least five use cases # Property Category Occurence Schema 1 * Persistent identifier Identification 10 Identifier, identifierType 2 Landing Page URL Identification 4 LandingPage 3 Alternative Identifier 2 AlternateIdentifier, alternateIdentifierType 4 Resource Type 4 5 * Instrument Name Instrument 10 Name 6 * Instrument Description Instrument 6 Description 7 Instrument Category Instrument 3 8 * Instrument Type Instrument 5 InstrumentType 9 Device URL Instrument 1 10 Model Model 4 modelName 11 Sub-model Model 2 12 * Instrument Owner Owner 6 Owner 13 Owner Indentifier Owner 4 ownerIdentifier, ownerIdentifierType 14 Country Owner 2 15 Ownership Start Date Owner 1 16 Ownership End Date Owner 1 17 Contact Name 2 ownerName 18 Contact eMail 2 ownerContact 19 Contact Phone 2 20 Contact Institution 2 21 Institution Identifier 1 22 * Manufacturer Manufacturer 6 Manufacturer, manufacturerName 23 Manufacturer Identifier Manufacturer 1 manufacturerIdentifier, manufacturerIdentifierType 24 Serial Number Manufacturer 3 25 * Date Date 5 Date 26 Date Type Date 2 dateType 27 Capability Capability 3 28 Capability Type Capability 1 29 Capability Extent Capability 1 30 Characteristic 2 31 Event 2 32 Output/Observable Property Output 3 VariableMeasured 33 Related Instrument Name Related Instrument 2 34 Related Instrument Identifier Related Instrument 1 35 Publisher Publisher 2 36 Publication Year Publisher 2 37 Instance Reference 1 38 Funding Reference 1 39 Related Identifier 1 RelatedIdentifier 40 Related Identifier Type 1 relatedIdentifierType 41 Relation Type 1 relationType 42 Contributor 1 43 Contributor Type 1

While the 43 properties collected may suggest high heterogeneity, only a few can be considered common. Properties common to at least five use cases (50%) are Persistent Identifier, Instrument Name, Instrument Description, Instrument Type, Instrument Owner, Manufacturer, and Date (marked with a ^* in Table 2, Column 1). Table 2 also maps the collected properties onto the proposed PIDINST schema, which is published on GitHub. As we can see, there is a mapping for all common properties. We have included additional schema properties which the WG considered important or useful even if they were not common among the considered use cases. Most notably, we include RelatedIdentifier as a flexible technique to represent identifiers of entities related to the instrument, such as articles describing the instrument or the previous version of the instrument.

PIDINST has actively supported the adoption and implementation of the schema with two stakeholders: (1) PID infrastructures, in particular DataCite and ePIC, and (2) institutional instrument providers, in particular HZB (Helmholtz-Zentrum Berlin für Materialien und Energie) and BODC (British Oceanographic Data Centre).

Collaboration with DataCite resulted in a mapping of the PIDINST schema with the DataCite schema version 4.3. This mapping is also published on GitHub. It shows that most instrument metadata of the PIDINST schema can be represented adequately also using the DataCite schema, even though some of the definitions need to be stretched. Still, we identified a few shortcomings with this mapping. Most notably, the DataCite schema has no suitable property for the model name. Furthermore, the controlled list of values for the resourceTypeGeneral property lacks a suitable value for "Instrument." We submitted corresponding issues at the GitHub repository of the DataCite schema. Specifically, we suggest to:

• add "Instrument" to the controlled list of values for resourceTypeGeneral;
• add a value indicating “was used in” to relationType to relate an instrument with events;
• add a Series property, which would solve the model name issue; and
• add "Name" to the controlled list of values for titleType.

Amending the DataCite schema to address these issues would further increase the usability of the DataCite schema for instruments.

Collaboration with ePIC resulted in a prototypical implementation of the PIDINST schema in the ePIC infrastructure. ePIC provides a Data Type Registry infrastructure that enables the definition and description of metadata schemata in a hierarchical way, such that all definitions get a unique reference by a Handle. This framework is flexible enough for the definition of most possible metadata schemata. The PIDINST schema is hierarchical and contains at the first level a number of elements which contain substructures such as Owners, which is a list of objects containing ownerName, ownerContact, etc. The complete prototypical definition of the PIDINST schema is given under the name "Properties-PID-instruments" (see here, for example). This definition contains all first-level metadata elements of the PIDINST schema. Hence, a PIDINST metadata description can be given as a single object containing all first-level metadata elements as subobjects or, for instance, as a collection of the first-level metadata elements. Additionally, ePIC provides the possibility to include small metadata elements into the Handle record itself, giving useful information already at the reference level. This kind of metadata is called PID information type and is particularly useful for digital objects where metadata rather than data is of major interest.

Both the DataCite mapping and the ePIC implementation of the PIDINST schema have been prototypically tested with institutional instrument providers. As a first test case for the DataCite mapping, HZB minted four DOIs with DataCite for HZB instruments: two beamlines at the Berlin Research Reactor BER-II, one beamline at the synchrotron radiation source BESSY II, and one experimental station at BESSY II. The DOIs resolve to the respective instrument pages from the HZB instrument database, which already existed beforehand and were thus not created for this purpose. One particularity with these instruments is that they are custom-built by HZB. Thus, in the metadata "HZB" appears as Creator as well as Contributor, with property contributorType value "HostingInstitution." It is noteworthy that one of the DOIs uses the additional property fundingReference from the DataCite schema to acknowledge external funding that HZB received for upgrading the instrument. This property was not considered in the PIDINST schema, or in the DataCite mapping. HZB plans to continue the adoption and to mint DOIs for all its beamlines and experimental stations that are in user operation in the near future.

BODC tested the ePIC implementation in web-published, sensor technical metadata descriptions encoded in the Open Geospatial Consortium’s (OGC) SensorML open standards for conceptualizing and integrating real-world sensors. In an initial test case, a PID was minted for a Sea-Bird Scientific SBE37 Microcat regularly deployed on fixed-point moorings in the Porcupine Abyssal Plain Sustained Observatory (PAP-SO) in the north Atlantic. As seen in the handle record (Table 3), the implementation uses well-established, controlled vocabularies to facilitate adoption and (semantic) interoperability of the metadata record. The vocabularies are published by the NERC Vocabulary Server (NVS), which makes use of the World Wide Web Consortium’s (W3C) Simple Knowledge Organization System (SKOS). At BODC, each instrument’s technical description is published using a unique URL (e.g., https://linkedsystems.uk/system/instance/TOOL0022_2490/current/) identifying the instrument locally, which is included in data transmissions to identify the instrument that produced them. The respective Handle (e.g., http://hdl.handle.net/21.T11998/0000-001A-3905-F) resolves directly to the URL of the instrument’s technical description, which contains machine-readable metadata, such as the name, manufacturer and serial number. To enable cross-referencing, the Handle is added within the description as an identifier property labelled "Instrument persistent identifier" (Listing 1). In this way, redirection to the instrument’s SensorML URL enables globally unique identification of the instrument without costly changes to the existing publication infrastructure and data workflows.

Table 3. Handle record of instrument identifier http://hdl.handle.net/21.T11998/0000-001A-3905-F displaying instrument metadata compliant with the PIDINST schema as implemented by ePIC Type Data URL https://linkedsystems.uk/system/instance/TOOL0022_2490/current/ 21.T11148/8eb858ee0b12e8e463a5 (Identifier) { "identifierValue":"http://hdl.handle.net/21.T11998/0000-001A-3905-F", "identiferType":"MeasuringInstrument" } 21.T11148/9a15a4735d4bda329d80 (LandingPage) https://linkedsystems.uk/system/instance/TOOL0022_2490/current/ 21.T11148/709a23220f2c3d64d1e1 (Name) Sea-Bird SBE 37-IM MicroCAT C-T Sensor 21.T11148/4eaec4bc0f1df68ab2a7 (Owner) [{   "Owner": {     "ownerName":"National Oceanography Centre",     "ownerContact":"louise.darroch@bodc.ac.uk",     "ownerIdentifier":{       "ownerIdentifierValue":"http://vocab.nerc.ac.uk/collection/B75/current/ORG00009/",       "ownerIdentifierType":"URL"     }   } }] 21.T11148/1f3e82ddf0697a497432 (Manufacturer) [{   "Manufacturer":{     "manufacturerName":"Sea-Bird Scientific",     "modelName":"SBE 37-IM",     "manufacturerIdentifier":{       "manufacturerIdentifierValue":"http://vocab.nerc.ac.uk/collection/L35/current/MAN0013/",       "manufacturerIdentifierType":"URL"     }   } }] 21.T11148/55f8ebc805e65b5b71dd (Description) A high accuracy conductivity and temperature recorder with an optional pressure sensor designed for deployment on moorings. The IM model has an inductive modem for real-time data transmission plus internal flash memory data storage. 21.T11148/f76ad9d0324302fc47dd (InstrumentType) http://vocab.nerc.ac.uk/collection/L22/current/TOOL0022/ 21.T11148/72928b84e060d491ee41 (MeasuredVariable) [{   "MeasuredVariable":{     "VariableMeasured":"http://vocab.nerc.ac.uk/collection/P01/current/CNDCPR01/" } },{   "MeasuredVariable":{     "VariableMeasured":"http://vocab.nerc.ac.uk/collection/P01/current/PSALPR01/" } },{   "MeasuredVariable":{     "VariableMeasured":"http://vocab.nerc.ac.uk/collection/P01/current/TEMPPR01/" } },{   "MeasuredVariable":{     "VariableMeasured":"http://vocab.nerc.ac.uk/collection/P01/current/PREXMCAT/"   } }] 21.T11148/22c62082a4d2d9ae2602 (Date) [{   "date":{     "date":"1999-11-01",     "dateType":"Commissioned"   } }] 21.T11148/eb3c713572f681e6c4c3 (AlternateIdentifiers) [{   "AlternateIdentifier":{     "AlternateIdentifierValue":"2490",     "alternateIdentifierType":"serialNumber"   } }] 21.T11148/178fb558abc755ca7046 (RelatedIdentifiers) [{   "RelatedIdentifier":{     "RelatedIdentifierValue":"https://www.bodc.ac.uk/data/documents/nodb/pdf/37imbrochurejul08.pdf",     "RelatedIdentifierType":"URL",     "relationType":"IsDescribedBy "   } }]

Listing 1. SensorML metadata snippet showing the embedding of the instrument’s (Handle) persistent identifier <sml:identifier>   <sml:Term>     <sml:label>Instrument persistent identifier</sml:label>     <sml:value>http://hdl.handle.net/21.T11998/0000-001A-3904-0</sml:value>   </sml:Term> </sml:identifier>

Discussion

Rapid advances in technology means we are producing more instruments and data than ever. From simple thermistors, to large-scale synchrotrons, to global sensor observing networks, there is a growing need for innovation to address the management of these valuable assets and the data they produce. The proposed solution enables the persistent and consistent identification of instruments for citation, cross-linking, and retrieval purposes across local and global instrument facilities, networks, and data systems.

There are many benefits to the proposed solution. It builds on existing infrastructure and is designed to facilitate easy identification. It comprises a persistent identifier and metadata schema with a list of core metadata properties chosen for accurate identification of the instrument and for setting it into context. Metadata includes the instrument’s name, a textual description, the manufacturer, the institution that owns or manages it, and references to other objects or entities that relate to the instrument. These metadata give meaning to the persistent identifier and are therefore registered with PID infrastructure.

To make persistent identification of instruments across diverse communities practical, the PIDINST schema includes only a small set of common properties. As instruments are increasingly complex and specialized, technical metadata, such as configuration and calibration, are often extensive, dynamic, and inherently difficult to standardize. There is no common standard for this kind of technical metadata that would be meaningful for all experiment techniques across scientific disciplines. However, specific standards for particular scientific communities do exist or are evolving. One approach that has had some success in the earth and environmental sciences is SensorML. Together with the OGC's Sensor Web Enablement (SWE) Common Data Model Encoding Standard, SensorML provides a conceptual model as well as XML and JSON encodings for sensors and measurement processes metadata. In general, however, the lack of standardization prevents this metadata from being registered with PID infrastructure. Instead, detailed information including descriptive material, contact information, applications, technical data, and guidance for using the instrument may be provided on the landing page associated with the instrument identifier. Technical metadata may also be linked from the metadata registered with PID infrastructure using RelatedIdentifier with property relationType value "HasMetadata" to enable automatic retrieval.

The PIDINST schema is designed to complement multidisciplinary best practices for property values. Many properties allow for soft-typing, giving users the ability to use values of their choice, such as free text or domain-specific standards. Property attributes enable users and machines to understand the context of the value (e.g., ownerIdentifier, ownerIdentifierType), again using free text or standards. A similar approach is used in the DataCite metadata schema. Domain-specific standards can vary among communities. For example, the SeaDataNet research infrastructure and SWE Marine Profiles group recommend controlled vocabularies and identifiers to annotate datasets and open standards related to instruments, including the SeaVox Device Catalogue for instrument model designs, the BODC Parameter Usage Vocabulary for measured variables, and the European Directory of Marine Organisations (EDMO). Communities in the earth sciences have chosen to label measured parameters with Climate Forecast Standard Names. The PIDINST schema allows these communities to use property values of their choice. While soft-typing is practical towards multidisciplinary use, it does reduce interoperability because different communities use different standards for values as described above. However, with such heterogeneity and establishment, it is impractical to use one standard for all use cases. The use of identifiers with knowledge representation schemes (e.g., SKOS) goes some way to improving understanding between information systems and can be used in the schema shown in Listing 1. Thus, the PIDINST schema complements multidisciplinary best practices through soft-typing while facilitating the use of standards which can enhance interoperability, if desired.

Another important goal for the PIDINST schema is to facilitate linking among instruments and journal articles, datasets, and other research objects. These links are made using RelatedIdentifier elements in the identifier metadata, and the relationships are described using relationType elements. For instance, the identifier metadata of the four previously mentioned HZB instruments registered with DataCite contain related identifiers with property relationType value "IsDescribedBy." Listing 2 provides an example. The relations point to journal articles that describe the instruments and provide technical details. These articles serve a similar purpose as “data papers”, i.e., articles that describe datasets, published in peer reviewed journals to provide recognition for dataset creation by means of an article. Thus, we term such articles “instrument papers.” To name an example, the Journal of large-scale research facilities (JLSFR) publishes such articles.

Listing 2. Snippet of DataCite metadata (https://api.datacite.org/dois/10.5442/NI000001) relating the HZB instrument “E2 – Flat-Cone Diffractometer” (https://doi.org/10.5442/NI000001) with a journal article describing the instrument (https://doi.org/10.17815/jlsrf-4-110) "relatedIdentifiers": [{   "relationType":"IsDescribedBy",   "relatedIdentifier":"10.17815/jlsrf-4-110",   "relatedIdentifierType":"DOI" }]

Together, instrument papers and landing pages provide important documentation that helps scientists and users more generally understand the instruments and how they have been used in scientific experiments. This documentation is designed to be read by humans. Structured metadata linked using persistent identifiers, on the other hand, enable machine readability and processing of information about instruments. These representations of information, for humans and for machines, are complementary.

As we presented here, PIDINST prototyped the schema implementation with both DataCite and ePIC. These implementations have pros and cons, which we briefly discuss. Worldwide, DOIs arguably have better recognition. Furthermore, the infrastructure for minting DataCite DOIs is easier for many institutions and comes with substantial tooling. On the other hand, DataCite DOIs may incur considerable costs if DOIs are minted for a large number of instruments. Furthermore, ePIC handles are more flexible when it comes to supporting custom metadata standards. Indeed, as our results clearly demonstrate, we could implement the PIDINST schema as proposed only with ePIC.

While the PIDINST schema has already been shown to be viable in practice, it is not yet finalized in all details. One of the remaining open issues is that the group did not achieve a consensus on the best representation of an instrument’s serial number. We do have the AlternateIdentifier property, so in principle, adding an AlternateIdentifier with alternateIdentifierType value "SerialNumber" would be the obvious way to include the serial number in the metadata. Consequently, adding a dedicated SerialNumber property to the schema has been rejected as redundant with AlternateIdentifier. The only drawback is that alternateIdentifierType is defined as free text and not a controlled vocabulary. As a result, there is no guarantee that everyone who registers instrument metadata spells this type alike, which may be a problem when searching for instrument metadata by serial number. Changing the definition of alternateIdentifierType to a controlled vocabulary is problematic, too, as there may be new use cases for AlternateIdentifier that would not be readily supported. Finally, the definition for some schema properties (e.g., InstrumentType and MeasuredVariable) is rather vague and the value is defined as free text. This is mainly due to the lack of suitable vocabularies. Other open issues with the schema, such as the final definitions of the terms in some controlled vocabularies, are relatively minor.

A further limitation of the presented work is the relatively small set of use cases and their bias for the earth sciences (60%), and therefore limited coverage of the disciplines. In current and future work, PIDINST will continue maintaining its deliverables, including advancing and supporting further adoptions in disciplines other than the earth sciences. As such, PIDINST will test the viability of the proposed metadata schema and its implementation with PID infrastructures more widely. As part of metadata schema maintenance, PIDINST will consider, discuss, and implement the concerns various communities may have.

The use of persistent identifiers for instruments is currently an emerging solution that is gaining momentum operationally, as evidenced in our adoption cases (see next section). Increasing its uptake in the future may also involve engagement with instrument manufacturers. They could provide machine-readable instrument specifications, support the inclusion of the persistent identifier into instrument output, or even register instruments “at birth.”

We have recently seen the development of dedicated community-level sensor registries aimed at harmonizing and standardizing sensor metadata across instrument networks, as exemplified by the European Esonet Yellow Pages for deep sea observatories or the NSF/EarthCube X-Domes for cross-domain environmental sensors. The use of persistent identifiers in such registries would not only boost uptake, but also these facilities may become direct members of PID providers, minting identifiers for institutions or individuals who do not have dedicated PID services. Uptake may also be accelerated through adoption by other PID providers (e.g., EZID). To support adoption in communities, PIDINST has published the schema as a “living document” on GitHub, where users may request updates to the schema, helping it to evolve with new and specialized stakeholders.

Adoption

In addition to HZB and BODC, who have already demonstrated the practical viability of the proposed solution, we briefly present in this section how other research infrastructures and institutional instrument providers motivate and plan the implementation of the proposed solution.

The Integrated Carbon Observation System (ICOS) is a pan-european research infrastructure for quantifying and understanding the greenhouse gas balance of the European continent. It conducts many continuous in-situ measurements like gas concentrations, wind speed and direction, humidity, temperature, etc. To deliver high-quality measurement data, ICOS considers the adoption of a persistent identifier for instruments a must for documenting data provenance and tracking calibration history.

PANGAEA is a data infrastructure for archiving and publishing earth and environmental science datasets. It is jointly managed by the Alfred Wegener Institute, Helmholtz Center for Polar and Marine Research (AWI), and the Center for Marine Environmental Sciences (MARUM) of University of Bremen. The infrastructure holds more than 380,000 persistently identified (DOI) datasets from individual researchers, projects, data centers, and research infrastructures. The metadata of a dataset includes relations between the dataset and related persistently identified entities such as specimens, authors, and articles. Metadata can be further enriched with instrument information. Using the AWI Sensor Information System, a subset of the published datasets has already been linked to their instruments. Since source information of a dataset (e.g., instrument and method) is essential to interpreting the quality of the dataset and to facilitating its reusability, further work should be done to link the remaining and new data submissions with their instrument PIDs, where applicable. As a data provider, PANGAEA only curates limited information of a device, such as device name, identifier, and type. For both the persistent identification as well as for the description of instruments, PANGAEA thus relies on institutional instrument providers.

EISCAT3D will be an international research infrastructure, using radar observations and the incoherent scatter technique for studies of the atmosphere and the near-Earth space environment above the Fenno-Scandinavian Arctic, as well as for the support of the solar system and radio astronomy sciences. EISCAT3D will implement persistent identification for instruments following the recommendations by PIDINST. The radar is complex, more digital than previous radars, and is roughly divided into a number of separate units. While software is a substantial constituent of these units, they can be largely be regarded as hardware units, each persistently identified. Updates to the units will be primarily to software and result in new unit versions with own PIDs. The radar itself can also be persistently identified, and the relation type "HasComponent" can be used to relate to the persistently identified units.

Conclusion

The Research Data Alliance Working Group Persistent Identification of Instruments (RDA WG PIDINST) was created with the aim to develop a community-driven solution for persistent identification of instruments. Based on use cases, the WG published a metadata schema and prototyped schema implementation with DataCite and ePIC, as well as with two institutional instrument providers. The WG has thus demonstrated the practical viability of the proposed solution for persistent and consistent identification of instruments for citation, cross-linking, and retrieval purposes across local and global instrument facilities, networks, and data systems. We argue that one of the key advantages of the proposed solution is that it builds on existing PID infrastructure. PIDINST encourages communities to explore both the DataCite and ePIC implementation in order to gain a better understanding for which use cases they serve best. In addition to maintaining the schema and addressing new stakeholder requirements, PIDINST will continue to actively engage with stakeholders to promote further adoption of the schema.

Acknowledgements

We would like to thank all use case authors for their invaluable contribution to this work as well as the participants of online and offline meetings for their contributions. We also thank DataCite and ePIC for helpful cooperation. Finally, we thank the Research Data Alliance for endorsing and supporting the PIDINST WG. This work was supported by the FREYA project, which has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement Nr. 777523.

Funding

This paper was supported by the RDA Europe 4.0 project that has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 777388.

Competing interests

Ulrich Schwardmann is a member of the management board of the ePIC Persistent Identifier Consortium for eResearch, which is on a voluntary basis. All other authors declare that they have no competing interests.

Notes

This presentation is faithful to the original, with only a few minor changes to presentation. In some cases important information was missing from the references, and that information was added. The original article lists references in alphabetical order; however, this version lists them in order of appearance, by design. All footnotes—which are simply URLs—from the original article were turned into either external links or full citations for this version.