Section 2

Data Schema

How instrument metadata is structured, how it differs from the base PIDINST standard, and how records are published to DataCite and versioned over time.

2.1 PIDINST Schema

The PIDINST web application uses the PIDINST metadata standard [1] as the foundation for describing AuScope-funded and AuScope-owned instruments. This provides a structured and consistent way to capture the key information required to identify, describe, manage, and publish instrument records.

The schema captures the main PIDINST information blocks, including:

Identifier
The persistent identifier assigned to the instrument.
LandingPage
The web page that users are directed to when resolving the instrument identifier.
Name
The recognised name of the instrument, ideally meaningful and unique within the managing organisation.
Owner
The organisation or person responsible for managing, operating, hosting, or providing access to the instrument.
Manufacturer
The organisation or person responsible for building or producing the instrument.
Model
The instrument model, type, or model name.
Description
A summary of the instrument, including its purpose, capabilities, and relevant technical details.
InstrumentType
One or more classifications describing the kind of instrument being registered.
MeasuredVariable
The variables, properties, or phenomena that the instrument measures or observes.
Date
Important lifecycle dates for the instrument, such as when it entered operation or stopped being used.
RelatedIdentifier
Links to related resources, such as documents, datasets, publications, external metadata records, or related instruments.
AlternateIdentifier
Other identifiers used for the same instrument in external systems, inventories, catalogues, or registries.

2.2 Adjustments to the Schema

The PIDINST schema is used as the base schema, but it has been enhanced to support additional AuScope registry requirements. These enhancements include information about the location of the instrument, funding references, and instrument classification, which provides a high-level category for grouping instruments.

The schema also includes temporal information about the instrument lifecycle. In addition to the standard Commissioned and Decommissioned dates, the application supports a broader Date Range to describe the period during which an instrument was active, available, or relevant to a record.

Model and Alternate Identifier are mandatory here. In the original PIDINST schema, Model and Alternate Identifier are optional fields. However, in the AuScope PIDINST implementation, these fields are mandatory. This is because an organisation may manage multiple instruments with the same or similar name from the same manufacturer. In these cases, the model and an alternate identifier, such as a serial number, asset number, inventory number, or other local identifier, are required to distinguish one instrument from another. A combination of manufacturer, model, and alternate identifier, therefore, helps ensure that each instrument record can be uniquely and reliably identified within the registry.

2.3 Publishing to DataCite

For publishing and DOI creation, the enhanced PIDINST metadata is mapped to the DataCite Metadata Schema 4.7. This mapping allows instrument records to be transformed into DataCite-compatible metadata so that they can be published and assigned DOIs. The mapping approach follows the official PIDINST-to-DataCite guidance [2], where key PIDINST fields such as identifier, name, owner, manufacturer, model, dates, related identifiers, and alternate identifiers are mapped to corresponding DataCite properties.

2.4 Versioning

The PIDINST application supports versioning to track changes made to instrument records over time. This is important because instrument metadata may change as new information becomes available, such as updates to ownership, contacts, location, lifecycle dates, related resources, or operational status.

In this application, each time a user creates a new version of an instrument record, a new DOI is generated for that version. This ensures that each published version has its own persistent and citable identity. Older versions remain accessible, but they are clearly linked to the newer versions of the same instrument record.

The application maintains relationships between versions so that users can understand the history of an instrument record. When viewing a record, users can see whether other versions exist and can navigate through the version history. If a user opens an older version, the application clearly indicates that they are not viewing the latest version and provides a way to access the most recent version.

This approach helps preserve the integrity of published metadata while still allowing instrument records to evolve over time. It distinguishes between the instrument as a real-world object and the published metadata versions that describe it. Each version can be cited independently, while the application keeps the version history connected and understandable.

2.4.1 DataCite version linkage

The relationship between instrument versions is also recorded in the DOI metadata registered with DataCite. When a new version of an instrument record is published and a new DOI is created, the DOI of the previous version is included as a related identifier.

The related identifier is recorded with:

Property Value
Related identifier type DOI
Relation type IsNewVersionOf
Related identifier The DOI of the previous version

For example, if a new instrument version with DOI 10.82388/new-version is created from an existing version with DOI 10.82388/previous-version, the DataCite metadata for the new DOI includes the previous DOI with the relationship IsNewVersionOf.

This means the version relationship is not maintained only within the PIDINST application; it is also represented in the DOI metadata itself. Systems that consume DataCite metadata can therefore identify that the newer DOI represents a new version of an earlier published instrument record.

2.5 Platforms: Arrays of instruments

The PIDINST website makes a clear distinction between Instruments and Platforms, even though both record types use the same underlying schema. In this context, an instrument represents an individual device or piece of equipment, while a platform represents a configured collection of instruments used together for a particular purpose.

This distinction is important in geoscience applications, where scientists often combine the same instruments, or selected instruments from a larger set, in different configurations before conducting a survey. For example, a survey platform may consist of several sensors, receivers, transmitters, loggers, or supporting components that are assembled and operated together as a single measurement system.

Therefore, a platform is not necessarily a single physical instrument. Instead, it should be understood as an array or configuration of instruments that work together in a defined arrangement. Recording platforms separately allows users to describe both the individual instruments and the combined systems in which those instruments are deployed. This supports better traceability, especially when instruments are reused across multiple surveys, projects, or configurations.