Ensuring uniqueness and persistence

Starting an identifier system based on the Handle.net system (Kahn and Wilensky, 1995) is not too difficult. The challenge lies in creating a governance system that supports the goals of global uniqueness of the identifier and its persistence (Bütikofer, 2009). Like other persistent identifier systems, IGSN relies on its governance to ensure that an IGSN always resolves to a Web resource with a URL. This does not mean that the sample itself has to be persistent. Often samples are destroyed in an analytical process or are discarded (e.g., water samples), and the Web resource representing the sample should provide the user with information on the current status of the sample.

In the context of IGSN, these requirements are best met by a hierarchical delegation model (Bechtold, 2003) to assign namespace governance and responsibilities for IGSN namespaces. An IGSN is composed of a namespace, sometimes with a sub-namespace, and a sample code (Figure 2). This structure can be likened to the structure of telephone numbers, which consist of an international country code, an area code and the telephone number of the subscriber. In a hierarchical namespace governance model, the IGSN agent does not need to negotiate the allocation of individual identifiers with IGSN e.V., but may solely negotiate them with its clients in its allocated namespace. By delegating parts of the namespace governance to IGSN agents the communication overhead between the agents and the IGSN registry is minimised while offering more flexibility for agents. This is analogous to the current practice for assigning DOI, where DOI agents are allocated a prefix namespace, in which they can mint identifiers as needed.

Namespaces are governed and assigned to agents by IGSN e.V. Within their namespace, each agent may have their own naming convention and must ensure the uniqueness of the assigned IGSN. To minimise administrative efforts, most agents extend the hierarchical delegation pattern by using sub-namespaces followed by unique sample codes as illustrated in Figure 2. This use of prefixes also allows the integration of local naming conventions already in use, thus making it easier to transform the locally unique identifier into one that is globally unique. An example was described by Conze et al (2017) for the International Continental Drilling Program (ICDP). In this example, the IGSN identifiers integrate the established ICDP naming conventions and IGSN can therefore be generated directly from the database without any changes to already established working procedures, naming conventions, or data systems. The hierarchical delegation pattern can also be used to assign sub-namespaces to teams in field sampling campaigns, allowing them to create unique IGSNs offline while in the field and then register them later.

Unlike most other persistent identifiers, IGSNs are not only used by machines but are often written and transcribed by humans onto sample labels, sample bags, and the like. The labelling of sample containers or the incorporation of IGSNs in tables in research articles puts practical limits on the number of characters that can be used. Out of these practical considerations, IGSN e.V. suggests a length between 9–12 characters for an IGSN, but this is not a binding requirement. To reduce the risk of mistyping, an IGSN is case insensitive and IGSN e.V. recommends that care is taken in the use of characters that can easily be confused, in particular in handwriting, such as ‘1’ and ‘I’, or ‘0’ and ‘O’.

An IGSN is resolved as a URI through http://igsn.org/, which uses an HTTP redirect to the underlying Handle.net address. For example, MBCR5034RC57001 refers to a sample from the International Ocean Discovery Program (IODP), registered by MARUM (Center for Marine Environmental Sciences, University of Bremen) on behalf of IODP. The resulting IGSN URI for the identifier is http://igsn.org/MBCR5034RC57001. The browser resolves this URI to the URL of its corresponding landing page by redirecting the request to Handle.net which then further redirects to the URL of the landing page. Since igsn.org simply redirects to Handle.net, it is also possible to resolve an IGSN through any Handle.net resolver (e.g. http://hdl.handle.net/10273/MBCR5034RC57001).

Describing samples for discovery and reuse

A key aspect for the discovery of samples on the Web is their digital representation through a suitable metadata model (Devaraju et al, 2016). There are several domain-specific metadata models available such as Darwin Core (DwC), an extension of Dublin Core, and community-driven metadata standard for sharing biodiversity data (Wieczorek et al, 2012). Similarly, the Biological Collections Ontology (BCO) is an application ontology to link biodiversity collections from various resources, including samples of organisms, ecological surveys and samples in metagenomic studies (Walls et al, 2014). These disciplinary metadata models can be regarded as disciplinary or domain-specific supplement to the IGSN Description Metadata Schema (see also Figure 3).

For the geosciences, the System for Earth Sample Registration (SESAR, http://www.geosamples.org) developed a metadata model schema to describe basic concepts of geological samples (Lehnert, 2011). The U.S. Geoscience Information Network (USGIN) hosts several common content models for the geoscience domain, including the USGIN content model for Physical Samples (Hills, 2015). In a more general context, ISO 19156:2011 (Observations and Measurements, O&M) (OGC Observations and Measurements v2.0 also published as ISO/DIS 19156, 2013) includes a common concept for ‘Specimen’ with minimum attributes such as materialClass, samplingLocation, samplingTime and size. In the O&M model, a ‘Specimen’ is a specialization of ‘SamplingFeature’ which is further classified into various spatial sampling features such as cross-sections, transects and boreholes. The Sensor, Observation, Sample, and Actuator (SOSA) ontology provides constructs to represent sampling information including the relation between a sample and its feature of interest upon which the sampling activity was carried out. All of these models have in common that they interpret a sample as representing some larger feature of interest (Cox, 2020).

The description schemas discussed above may be well suited for samples in the earth and environmental sciences, but will often struggle to accommodate use cases from other disciplines, e.g. archaeology, veterinary medicine or material science. Some of the extended scope may be accommodated in community-specific extensions, while other user communities might need entirely different sample description schemas. Other use cases need to integrate with existing schemas and vocabularies through crosswalks (Damerow et al, 2021). Figure 3 illustrates the concept of community extensions to core description schemas (‘bullseye’) and the parallel existence of multiple description schemas.

The IGSN system architecture

IGSN e.V. developed the IGSN registry based on DataCite’s Metadata Store (https://mds.datacite.org/, Fenner et al, 2019). The IGSN registry provides a REST API and a web user interface to manage IGSN registrations. An IGSN agent forwards the IGSN registrations including the registration metadata to the IGSN registry based on the Registration Metadata schema (see section below). All IGSNs are registered in the Handle System through a Handle Server. It is the role of the IGSN agent to ensure the uniqueness of the identifier and the persistence of the associated landing page describing the sample (Devaraju et al, 2017). The Handle.net Registry manages the resolution of IGSN identifiers to the URL of the landing page describing the sample. IGSN operates in the handle-namespace <10273>. Further technical details on the registry (API) are available online (http://igsn.github.io/registration/). Figure 4 gives a schematic overview of the IGSN system architecture for the minting of IGSN and syndication of IGSN catalogues by IGSN Agents.

IGSN metadata models

A distinctive feature of the IGSN approach to metadata is its separation of registration metadata from description metadata. Other PID registries (e.g. DataCite, ORCID) require the transmission of a common set of metadata as part of the registration process, which is then incorporated into a central catalogue. In contrast to this common practice, the IGSN registration process separates the registration of the identifier and the provision of description metadata using two different schemas. Separating the registration metadata of the identifier from the description of the object gives the IGSN system the flexibility to accommodate a greater variety of applications, which may require different metadata profiles to describe their samples, e.g. for different disciplines or use cases. This approach also matches the standard registration models in ISO 19135 (ISO, 2013) and ISO 11179 (Pon and Buttler, 2009) more closely (Devaraju et al, 2017).

The IGSN Registration Metadata schema (http://schema.igsn.org/registration/) describes:

1. the registrant information;
2. any state changes of the identifier, e.g., submitted, registered, deprecated; and
3. its association with other identifiers such as other IGSN, DOI, etc.

These relations are important to determine the lineage of a sample and how it relates to other objects. Through this metadata element, an IGSN can be linked to other entities, such as a parent-sample, derived child-samples, aggregates of samples (e.g. drill core sections or dredges), sampling features (e.g. outcrops, drill holes). The same element can be used to link to datasets associated with a sample, or publications in which the samples are referenced. The samples are cross-linked to other entities by referencing their persistent identification and describing the nature of this relationship through a controlled vocabulary. This procedure follows common practice among PID providers (see e.g. DataCite Metadata Working Group, 2018); related work in this direction is the patterns proposed by (Cox, 2020) to capture a chain of samples.

The IGSN Description Metadata schema (http://schema.igsn.org/description/ and http://igsn.github.io/metadata/) is developed by the IGSN members with inputs from a community of practice in the earth and environmental sciences. It is used to catalogue a minimum set of descriptive properties of samples and sample collections, such as sample type, material type, contributor, and sampling activity, to aggregate catalogues of samples across IGSN agents into overarching portals. This schema was deliberately kept general to allow the compilation of a global catalogue of, e.g., geological and biological samples and sample collections. It is based on the principles of the DataCite Metadata Schema (DataCite Metadata Working Group, 2016) and modified in terms of cardinality and restrictions on particular metadata elements, while new elements (e.g., geolocation, collection methods, materials) were added to represent essential sample information that goes beyond the requirements of a bibliographic catalogue. Wherever possible, existing controlled vocabularies (e.g., representing sample and material types) like GeoSciML (Sen and Duffy, 2005), Eionet-GEMET (European Environment Agency, 2004), or the material and sample types as defined in the Observations Data Model (ODM) (Horsburgh et al, 2016) were incorporated into the scheme to enrich the metadata and promote consistency of metadata entries. Additionally, a number of vocabularies required to describe physical samples were requested to be added to the ODM registry. In the longer term, the IGSN initiative strives for machine-readable and well-governed standard vocabularies that can be applied to express different aspects of sample metadata. These vocabularies should follow standards, e.g., Simple Knowledge Organization System (SKOS), and should be identified with URIs.

Metadata schemas always encode an information model with a set of applications in mind (Devaraju et al, 2016).

Metadata syndication

The original system design uses the Open Archives Initiative – Protocol for Metadata Harvesting (OAI-PMH) (Lagoze et al, 2002) to share metadata and disseminate catalogues of samples across IGSN agents. A useful feature of OAI-PMH is that it allows serving more than one metadata schema. IGSN agents can therefore develop domain-specific description schemas with their clients to serve their specific communities. Allowing application-specific metadata profiles gives IGSN agents greater flexibility to describe samples for different applications, e.g. allowing harvesting of certain sample types with their domain-specific description metadata required for domain-specific catalogues and applications (Devaraju et al, 2017). These communities are centred around use cases as communities of practice. In addition to IGSN common and community-specific profiles, it is good practice that OAI-PMH servers also offer metadata following the Dublin Core schema to allow harvesting of metadata by generic OAI-PMH clients that are not aware of the IGSN description schema. IGSN provides a mapping of IGSN Descriptive Metadata elements to Dublin Core elements online (see http://igsn.github.io/oai/).

The open nature of using a common protocol for sharing metadata and assembling sample catalogues allows anybody with knowledge of the OAI-PMH endpoints to build applications that make use of these metadata. The AuScope Discovery Portal at http://portal.auscope.org.au/ is an example of an application that aggregates IGSN catalogues hosted by different IGSN Agents by harvesting the metadata catalogues and making them available through a search portal, thus enabling the discovery of samples. However, OAI-PMH was never built to serve several million records, and the fact that some IGSN Agents catalogue millions of samples has shown the limitations of OAI-PMH as a way of syndicating very large volumes of metadata. It is therefore foreseeable that IGSN will abandon OAI-PMH as its mechanism for metadata syndication and adopt a standard based on common Web technologies and schema.org combined with a sitemap file offering a list of all records available at an agent site (Fils et al, 2020).

Linking physical objects to the Web

The digital representation of a sample in the IGSN system is its landing page. The presentation of the sample metadata, or IGSN Landing Page, differs among portals and catalogues. Similar to practices in the DOI system (TIB Hannover, 2012), IGSN agents are required to display a description of the sample that is identified by an IGSN. In the spirit of “intelligent openness” (Royal Society, 2012), parts of a metadata record can be withheld to protect sensitive information, e.g. of vulnerable sites or threatened species. Communities of practice, like the example from the earth and environmental sciences discussed above, agree on a core set of metadata elements to display. Additional elements can be added by individual agents to improve the discoverability of samples, such as sample images, maps, and display of the hierarchical relationship of objects. Figure 5 shows the example of an IGSN Landing Page for a sample from the International Continental Scientific Drilling Programme (ICDP). SESAR landing pages include a QR code for the IGSN that encodes the URL of the landing page. Users can copy and paste the QR code into sample labels and thus directly access landing pages from their mobile app using QR code readers.

Locating physical samples

There are a number of ways on the side of the physical sample to link it with its digital representation (Kahn and Wilensky, 1995; Lannom et al, 2019) on the web using IGSN. The simplest method is to permanently affix a label to a sample, or by writing or engraving its IGSN onto it or its container along with its local accession or inventory number. Because space for labels is limited, in particular on small samples, QR tags or barcodes are more convenient as they offer the possibility to encode any identifying information in a machine-readable way. The technically most accessible way for using QR codes is to encode an IGSN as an actionable handle URI. Ideally, a label should show the QR code, the IGSN, as well as any inventory number in a human-readable way. Figure 6 shows examples of this use case where labels with the IGSN in human-readable form and as a QR code have been attached to a sample and a box holding several samples.

Right from the start, IGSN served as an identifier for both individual samples and for aggregations of samples. Over time other use cases arose, which will be discussed in this section. The first use case, identifying samples and linking them with their virtual representation is pretty straightforward. The idea of aggregate objects that combine several samples under one identifier follows the example of DataCite DOI used to aggregate several individually identified datasets under one DOI. Related to this idea is the identification of sampling features, e.g. boreholes, from which several related samples were taken. And finally, we will describe how to link samples through IGSN to other related objects, both physical and virtual.

Another form of aggregation of samples are ‘collections’ in the sense in which DataCite allows DOI objects to be aggregated under one identifier. An example from DataCite is the dataset published by König-Langlo and Gernandt (2009) of radiosonde ascends near the Georg Forster Antarctic Research Station. While each radiosonde dataset is identified by its individual DOI, the entire set of 426 radiosonde ascends is identified by a collective DOI. Following the same pattern, several samples, each identified by individual IGSN, can be aggregated into a collection of samples with its own IGSN identifying the collection.

Linking data across repositories and cross-linking between samples and related resources

An important aspect of Web resolvable identifiers is their ability to act as anchors for relations between objects such as samples, data, literature, instruments, authors, custodians, organisations, and many more. In this sense, IGSNs act as anchors for data and literature to the physical samples from which they were derived. IGSNs can, therefore, serve as anchors to the provenance of all related resources (texts, images, data, code, derived samples) underpinning the published research results.

A major step for the visibility and discoverability of IGSNs in data publications was the formal inclusion of IGSNs as RelatedIdentifierType in the DataCite 4.0 Metadata Schema (DataCite Metadata Working Group, 2016). This enables the integration of actionable IGSNs directly in the standardised and machine-readable metadata of research datasets (for example, see http://igsn.org/ICDP5054EXF4601) and allows IGSNs to be discovered in catalogues of research data repositories (e.g., GFZ Data Services (http://dataservices.gfz-potsdam.de), PANGAEA (https://www.pangaea.de), EarthChem Library (https://www.earthchem.org/library) and other portals harvesting metadata (e.g., DataCite Search, https://search.datacite.org/). Figure 7 shows how IGSNs link from publications and data tables in publications can be used to link directly to sample descriptions.

As described for scholarly literature, where references are presented as actionable DOIs, it is recommended to also include actionable IGSN identifiers in datasets. This should be done in addition to the inclusion of IGSNs in the metadata of data publications via DataCite’s “relatedidentifiertype”. The IGSNs in datasets should be active Web links enabling cross-linking the data values with the online description of the sample. Such cross-linking benefits researchers since it enables unambiguous reference and effortless discovery of as well as direct access to contextual information about samples in the datasets. As an example, Figure 8 displays the HTML view of a dataset published through the IGSN-external data repository PANGAEA.

Tracking samples from the field to the sample repository

A central issue in managing and discovering samples is the use of ambiguous sample names. The most effective way to avoid this is by applying IGSNs at an early stage of the sample life cycle. Projects in Australia have used electronic field notebooks (Ballsun-Stanton et al, 2018) to document the sampling process and assign an IGSN (Golodoniuc et al, 2016; Noble et al, 2018; Reid et al, 2016) as part of their field sampling activities (Figure 9). In this case, the uniqueness of the IGSN is ensured by assigning sub-namespaces to sampling campaigns. Assigning an IGSN as early as possible in the sampling process allows samples to be tracked through different stages of their life cycle, e.g., sample handling and storage, laboratory analysis, and eventual disposal. Samples can also be tracked if they are moved to different laboratories or repositories. This practice aligns with the principles outlined in the W3C Working Draft on Extensions to the Semantic Sensor Network Ontology (Cox, 2020).

References to sampling features and locations

IGSN can be used to identify related entities that are closely linked to physical samples. Examples are boreholes, mines, outcrops, or other sites. They all have in common that they are not samples themselves, but, to follow O&M terminology, sampling features (Cox, 2020; Haller et al, 2019). From these sampling features, a number of samples could have been taken. In the example of a borehole, drill core is commonly not retrieved in one piece but in several segments or “runs”. Each of these objects is individually identified, as are samples representing subsamples from these objects. The identifiers of these objects relate to each other, mirroring the hierarchical relationships between samples (see e.g. Figure 5 and Conze et al, 2017).