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.

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.