One of the key benefits on the handle PID system is its flexibility. The system allows you to determine exactly how stringent your metadata requirements are, how the PIDs should be structured, where metadata is stored and to define the relationship between PIDs. This page will introduce you to some of the possibilities and considerations. If you require more support in making these decisions, SURF offers consulting services to help with this.

Metadata storage: internal or landing page

The first decision to make is where your metadata will be stored. With handles this can be done as part of the handle or by having the handle point to a landing page which contains all the metadata. This decision often lies on the object itself and the underlying repository or collection solution being used to store and manage the objects. This choice can also effect the discoverability of your objects and how it can integrate with search engines. We recommend discussing the costs and benefits for your particular object type with experts within your domain.

Landing page PID example:

https://hdl.handle.net/11112/SURF.82df4163-f7c855ca

Internal PID example:

https://dtr-test.pidconsortium.eu/objects/21.T11148/17ce618137e697852ea6

which is fed into a webpage and presented in a human readable format here:

https://dtr-test.pidconsortium.eu/#objects/21.T11148/17ce618137e697852ea6

Metadata schema

The metadata schema allows you to describe an object through an established and defined set of data elements. You can tailor them to be exactly what your institution and objects need. You can make them as flexible or controlled as you want. You can publish the schema to promote interoperability and discovery of your objects. There are also many technical ways to implement them. For more information, reach out to your fellow domain experts or SURF for our metadata schema consultation service.

Example:

Mandatory Fields:
- Identifier (regex)
- Creator (open string)
- Title (open string)

Recommended Fields:
- Date (regex dd/mm/yyyy)
- Description (open string)
- Version (integer)

Optional Fields:
- Language (controlled list)
- Size (float)

Further suggested reading:

ISO's introductory guide to creating a metadata schema

Dublincore schemas

Tombstoning

PID are meant to be persistent. However not all objects can exist in perpetuity. When an object no longer exists or must be retracted from the public sphere, PID best practices recommend "tombstoning" the PID. This means redirecting the PID to a set of relevant metadata, including a description of what the object was and why it is no longer available (aka creating a "tombstone"). Each domain and object type may require a different set of metadata fields to best describe the former object. For more information, reach out to your fellow domain experts or us for our metadata schema consultation service.

Examples:

https://identifiers.org/genedb:LinJ.20.0070

https://doi.pangaea.de/10.1594/PANGAEA.835864

Policy

Most institutions opt to draft a formal PID policy. This can include procedures for transfer of ownership when PID owners are no longer available to maintain their PIDs, how to tombstone PIDs, metadata schemas and integration of PIDs into workflows. Creating and enforcing a formal policy, alone or as part of a general Data Management Policy (DMP), can greatly increase trust.