What is a PID?

The FAIR principles [1] recommend assigning Persistent Identifiers (PIDs) to research resources as a key requirement for making them findable, accessible, interoperable and reusable. A wide range of identifier types [2] exists (some examples include Digital Object Identifiers (DOIs), ePIC PIDs, PURLs, UUIDs, …) that can be used to reference digital objects. However, determining which of these identifiers actually meet the requirements to be called a “PID” is not straightforward.

Within the community, the core functionality expected of a PID is threefold: it must provide a globally unique and unambiguous reference to an object, ensure persistence over time, and be resolvable [3]. Based on these criteria, we adopt the more explicit term GUPRI (Globally Unique, Persistent, Resolvable Identifier) as a formal definition of what constitutes a PID. In the following, different aspects of a GUPRI are explained and discussed.

Identifiers

Most abstractly, an identifier is a name, label, or sequence of characters (letters, numbers, symbols) attached to a specific object in a system, used to unambiguously identify this object. An object may be digital (e.g. a dataset, publication) or physical (research instrument, inventory item). An identifier typically belongs to a system of identifiers which

  • follows a fixed syntax, and/or

  • has a specific resolution algorithm to map the identifier to the object (or metadata about the object).

Examples:

  • UUIDs can be used for identifying objects. Each UUID follows a fixed, predefined syntax, consisting of groups of 8-4-4-4-12 digits xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

  • A DOI has a fixed syntax, consisting of a prefix (starting with 10.) and a suffix, both separated by a slash (10.xxxx/xxxxxxx). The DOI resolver https://www.doi.org takes a DOI as input and performs a fixed number of steps to map a DOI to a landing page containing metadata about the object which the DOI is attached to.

Global Uniqueness

An identifier (belonging to a system of identifiers) is locally unique if it is only allowed to be attached to one specific object (within a system of objects). In other words, it cannot be simultaneously attached to two different objects in the same system. Globally unique means that if identifiers from multiple identifier systems are put together, they all still unambiguously map to their local objects within their local systems.

Examples:

  • If your own lab or warehouse system guarantees that no other item in that system can ever get 12345, then 12345 is locally unique within that system. But another lab, warehouse, or database can also use 12345 for a completely different item.

  • A DOI is globally unique due to two facts:

    • If two different local systems both use DOI, then it is guaranteed that they do not use the same DOI because they must use different prefixes/namespaces (i.e., the first system only uses DOIs of the form 10.0001/xxxx, and the second one only uses DOIs of the form 10.12345/xxxx). Hence, DOIs from different local systems never collide.

    • Strictly speaking, anyone could invent his own identifier MyID for his own local system that looks similar to DOI and even potentially duplicates existing DOIs (please don’t do this, and also do not invent your own PID system: PID systems evolved over decades through community coordination to develop mechanisms for guaranteeing uniqueness and interoperability). But then the DOI resolver would map the DOI to an object in a different local system than the resolver belonging to the MyID does. In other words, global uniqueness is not just about the identifier string itself looking different; it also depends on resolution services (see Resolvability).

Resolvability

An identifier system is called (generally) resolvable if there exists a resolution service/resolver for that system which is capable of unambiguously mapping an identifier from that system to the location (URL) of the object (or metadata about the object) that it identifies. The process performed by the resolution service is called resolution. Resolution should make use of standardized protocols and behave consistently for all identifiers of that system. Resolution may fail on single identifiers (which means that the mapping from an identifier to the object cannot be performed) if these identifiers are not managed as intended (see also Persistence). Resolution could fail due to several reasons, such as:

  • The PID is not mapped to the intended location anymore, e.g. because the referenced object (or its metadata) has moved or does not exist anymore.

  • The service that should provide the object (or its metadata) is not responding.

  • The local server or the global resolution system is not available.

Single identifiers (belonging to a system of identifiers) are called resolvable if their resolution does not fail.

Note:

  • Resolvability is both a characteristic of an identifier system as a whole and of single identifiers within the system: A system that has a resolver is capable of generally resolving its identifiers. However, resolution may fail on single identifiers, in which case this single identifier would be not resolvable.

  • Multiple resolution [3]: One and the same identifier may be resolved to different results (a resolver implements one or several of these options). A typical combination is resolution to:

    • a human-readable landing page with metadata and other information,

    • a machine-readable metadata representation,

    • a direct link to the digital object being described,

    • and a link to a long-term preservation copy.

  • There is a nuance between resolvability and global resolvability: Resolvability does not imply that anyone can successfully resolve an identifier in every case. Resolution can be

    • Public, where anyone can resolve the identifier.

    • Restricted, where the identifier resolves only for users with the right permissions, e.g. access may be restricted due to a paywall, an embargo period, or limitations based on the intended use of the resource.

    • Context-dependent, where resolution works only inside a specific system or through a particular resolution service.

    However, if an identifier is used for citation, it should be globally resolvable with 24/7 availability of a resolver, since users rely on fast resolution [4].

  • Resolvability also does not imply that access to the object is guaranteed for anyone in any case. E.g., even if the identifier resolves to a landing page providing metadata to describe the object, the object may only be accessible after login.

Examples:

  • Handle-based identifiers are generally resolvable by using the global handle resolver https://hdl.handle.net. Resolution uses the Handle Protocol and exhibits a consistent behaviour:

    However, resolution of single handles may lead to a 404 response or other errors. Those identifiers would be called not resolvable.

  • URNs are assigned within different namespaces, where the namespaces have their own resolvers. For example, URN:NBN:DE and URN:ISBN have different resolvers.

  • URLs are resolved through the Domain Name System (DNS) into an IP address, under which location one may find e.g. a webpage or file.

Persistence

Persistence is a nuanced concept, making it hard to say that an identifier is either fully persistent or not [3], [5]. Rather, it makes sense to look at various characteristics of a PID that ensure a high probability that an object can be identified via an identifier for as long as possible. A high probability for long-term availability results from a combination of three main factors, as described in [3]: Registry and resolution persistence, management persistence, and resource persistence.

Registry and Resolution Persistence

Persistence of identifiers relies on providing organizations (i.e., the organizations from which identifiers can be obtained) and governing authorities (i.e., organizations governing the identifier system) to maintain their services, including identifier registries and resolvers, in the long term [3]. This feature can be broken down into more fine-grained aspects, such as:

  • Commitment to persistence: Providing organizations and governing authorities should be committed to standards, procedures and long-term operation through legal bindings [6].

  • Community Adoption: Strong relevance of an identifier system to its community promotes broad adoption, fosters community support, and helps secure sustainable funding [6].

  • Sustainable business model: A sustainable financial business plan for involved providing organizations and governing authorities is essential [3], [4], [6].

  • Long-term strategy: Providing organizations and governing authorities should have a long-term perspective to operate their identifier services. There should also be “an exit strategy to ensure ongoing resolution in case of discontinuments or organisational failures” [6].

Management Persistence

The owner of an identifier (often the repository where the object is stored) needs to take care of maintaining the correct link between the identifier and the resolution target. In more detail:

Each identifier is associated with the object it identifies by storing an URL (and potentially other meta information). While the identifier itself is a name identifying an object, the associated URL points to a location where the object (or metadata about the object) is stored. However, when the object is removed, moved to another domain, or moved to a different path on the same server for any reason (e.g. administrative workflows), the URL of this object changes. While the identifier as a name of the object stays constant, the URL associated with the identifier is designed to be flexible, such that the owner of the identifier can update the associated URL if the object location changes. This capability mitigates link rot: the gradual degradation of links that occurs when the target resource is moved, deleted, or altered without updating the corresponding link. It means a URL may no longer lead to the intended object, even though the object itself still exists elsewhere [7].

The owner of the PID is responsible for preventing link rot by maintaining the mapping between the PID and the current URL, including updating redirects when the object is moved. If the URL behind the PID is not updated, the PID may still exist, but it no longer points to the right object. Management persistence means that the identifier owner commits to keeping the associated URLs up to date.

Object Persistence

The object identified by the identifier should remain accessible and usable, while taking version management approaches and, in some cases, legal restrictions into account. This can be roughly split into three aspects:

  • Object continues to exist: It is recommended to only assign a PID to objects that are expected to “be preserved for long term, that is, over several hardware and software generations” [3]. Generally, once published, scholarly outputs should remain available and should not be retracted or destroyed, except when legal obligations require it or in cases of research fraud [3].

  • Tombstones with persistent metadata: If an object that was assigned a PID ceases to exist, then the PID should still be preserved, resolving to a tombstone page including basic metadata for the object that has been removed, the reason of its deletion, and possible pointers to any succeeding versions [3], [4]. As an example, there may be situations in which sensitive information about the object must be removed for legal reasons, such as in response to a data subject’s right to erasure under the GDPR [8].

  • Content persistence: Content of objects may change over time in different ways: the file format of the object may change, there may be corrections, improvements and additions, or content may be fully replaced while keeping thematic continuity [5]. Content persistence means that the content of the object should exhibit a level of persistence that is adequate for the given context, including applying proper versioning concepts. Changes in content can be problematic for scientific reproducibility, because earlier citations may no longer point to exactly the version of the content that was used to produce later results. For data and code in particular, keeping the content fixed is especially important. In some contexts, however, such change is expected and acceptable, for example in Wikipedia pages. [3]

In summary, PIDs should only be assigned to objects that are expected to exhibit a degree of persistence in the first place. Achieving persistence requires coordinated effort from multiple stakeholders, including the organizations that provide and govern the PID system, the administrative owner of the PID, and end users who avoid substantial changes to the referenced content. This shared responsibility entails sustained commitment and associated costs.

Examples:

  • “Stable” institutional URLs: Sometimes institutions use URLs under a so-called stable domain, for example https://my_company.com/id/12345, to identify objects. We believe that such URLs are generally not persistent, because domain names often reflect trademarks, company names, or department names, and these can change over time. If the URL changes, an administrator can of course create redirects to the new address. However, this leaves the object with two identifiers, making it difficult to tell whether a document citing the old URL and one citing the new URL refer to the same object unless they are compared directly [7].

  • PURL: The persistence of PURLs is questionable due to several reasons: PURL owners have no obligation to maintain the linked resource, the administrative interface to register and update PURLs was previously broken for months leading to a decrease in trust, and PURL has comparatively limited adoption, making major investments on the development of either PURL specification or its technical infrastructure seem unlikely at the moment [3].

Footnotes

Contributors

Creator: Jana Böhm (https://orcid.org/0009-0004-9802-113X)

Reviewers: Sven Bingert (https://orcid.org/0000-0001-9547-1582), Stephanie Hagemann-Wilholt (https://orcid.org/0000-0002-0474-2410)

last changed: 2026-06-15