---
# System prepended metadata

title: EZID Identifier Resolution
tags: [' ARK', identifier, ' PID', ' GUID', ' DOI']

---

---
title: EZID Identifier Resolution
subtitle: Decoupling of EZID and N2T for identifier resolution services.
tags: identifier, PID, GUID, ARK, DOI
author: Dave Vieglais
date: 2023-03-27
---

# EZID Identifier Resolution

## Synopsis

EZID prior to version 3.1 delegates identifier resolution to N2T. EZID version 3.1 supports identifier resolution and continues to synchronize identifier metadata with N2T. Both EZID and N2T operate as Resource Resolvers for EZID identifiers. EZID 3.2 no longer synchronizes identifier metadata with N2T, and EZID becomes the primary Resource Resolver for EZID identifiers. N2T continues its role as Scheme Resolver and Prefix Resolver for EZID (and other) identifiers.

| EZID Version | Identifier as URL |Resolver |
| -- | -- | -- |
| < 3.1 | `n2t.net/identifier` | Resolution only available through N2T. EZID forwards identifier level metadata to N2T |
| 3.1 |  `n2t.net/identifier` |Resolution available through N2T and EZID. EZID forwards identifier level metadata to N2T |
| >=3.2 |  `n2t.net/identifier` or `arks.org/identifier` or `identifiers.org/identifier` | Prefix Resolution through arks.org, Resource Resolution through EZID. EZID does not forward identifier level metadata to N2T.|

## Identifier Resolution Background

The practice of resolving an identifier to a resource location generally involves progressive refinement of location detail gathered through sequential inquiry to different sources of information. When resolution is performed over HTTP, the progressive refinement occurs through a series of HTTP redirects until the resource is located or the resolution is rejected as invalid.

The different sources of information about identifiers can be broadly grouped into three levels: *Scheme Resolver*, *Prefix Resolver*, and *Resource Resolver*.

1. The *Scheme Resolver* directs requests to services appropriate for a particular scheme (e.g. `ark:` or `doi:`).
   For example, a *Scheme Resolver* has knowledge that identifiers using the "doi" scheme may be resolved by the service located at "https://doi.org/". Similarly, that ARK identifiers may be resolved at "https://n2t.net/".
   A *Scheme Resolver* redirects an identifier resolve request to a known *Prefix Resolver*.
2. The *Prefix Resolver* supports grouping of identifiers with particular services. The *Prefix Resolver* typically examines a portion of the identifier such as a prefix to determine which services can provide more detail about the identifier.
   For example, ARK identifiers have a numeric prefix, the "NAAN" (Name Assigining Authority Number). Each NAAN is associated with a service responsible for managing identifiers created with that prefix.
   A *Prefix Resolver* redirects an identifier resolve request to a known *Resource Resolver*.
3. A *Resource Resolver* is able to associate an identifier with the location of a specific resource, which will generally be a Resource Server where the actual resource is stored and made available.
   A *Resource Resolver* service takes an identifier as input, and returns the Resource Server location information to the client. 
   
The three levels of resolution described here is a broad generalization. Fewer or more levels may actually be involved in the resolution of any particular identifier. However, three levels has emerged as a somewhat typical pattern for scalable resolution of globally unique identifiers and provides a useful framework for discussion. 
   
An example of sequential location refinement for resolution of the ARK identifier `ark:/12148/bpt6k10733944` is provided in figure 1.
   
```plantuml
Actor User as user
Participant "Scheme\nResolver" as sr
Participant "Prefix\nResolver" as pr
Participant "Resource\nResolver" as rr
Participant "Resource\nServer" as rs
user -> sr: identifiers.org/**ark:**/12148/bpt6k10733944
activate user
activate sr
sr --> user: 302 "https://n2t.net/ark:/12148/bpt6k10733944"
deactivate sr
user -> pr: n2t.net/**ark:/12148**/bpt6k10733944
activate pr
pr --> user: 302 "https://ark.bnf.fr/ark:/12148/bpt6k10733944"
deactivate pr
user -> rr: ark.bnf.fr/**ark:/12148/bpt6k10733944**
activate rr
rr --> user: 302 "https://gallica.bnf.fr/ark:/12148/bpt6k10733944"
deactivate rr
user -> rs: gallica.bnf.fr/**ark:/12148/bpt6k10733944**
activate rs
rs --> user: 200 "Aventures d'Alice au pays des merveilles / par Lewis Carroll ; illustrées par Arthur Rackham"
deactivate rs
deactivate user
```
> **Figure 1.** Generalization of identifier resolution through three levels of resolver service. The *Scheme Resolver* `identifiers.org` understands "ark:" identifiers are resolved by the *Prefix Resolver* `n2t.net`, which in turn understands identifiers with the prefix "12148" are resolved by the *Resource Resolver* `ark.bnf.fr`. The *Resource Resolver* in turn directs the user to the actual resource.

Note that there may be multiple instances of Scheme, Prefix, and Resource Resolvers. Where content between instances overlaps, it is critical that mechanisms are in place to ensure trustworthy consistency across instances. If knowledge of identifier detail was not consistent across resolver instances, resolution would produce inconsistent results, and so reduce the value of globally unique, resolvable identifiers. Service trustworthiness is important to avoid potential content spoofing or malicious action where an agent deliberately causes resolution to content different from content owner intent (E.g. an identifier pointing to a factual news article redirected to fake news by a malicious agent).

When expressing an identifier as a URL, the identifier is being directly coupled to a service, and so consideration should be given to the availability of the service and efficiency of use within the applicable context. In general, services at the finer level of detail in the resolver chain may be more ephemeral. Server names and url patterns may change as services evolve, and so URLs associated directly with those services may be considered somehwat more fragile in the long term. Hence, there is some benefit to constructing URLs using services at higher levels in the resolution chain.

There is no universal, globally accepted identifier scheme resolver service, though such capability is offered by `identifiers.org` and `n2t.net`. In the example workflow presented in Figure 1. above, any of the following URLs ultimately resolve to the same resource:

1. https://identifiers.org/ark:/12148/bpt6k10733944
2. https://n2t.net/ark:/12148/bpt6k10733944
3. https://ark.bnf.fr/ark:/12148/bpt6k10733944
4. https://gallica.bnf.fr/ark:/12148/bpt6k10733944


URL 4 is most closely associated with the resource, is more efficient for the user (no redirects), though may be more ephemeral and impacted by changes to the collection infrastructure. URL 4 could be considered appropriate for use within the collection viewer application where any future changes to the URL may be managed by the application logic.

At the other extreme, URL 1 might be considered good for long term reference to the resource. Retrieval of the resource is less efficient since there are more redirects, but is arguably more resilient to changes to underlying services since the resolver metadata may be updated as necessary by the resource managers, thus removing the need to change published URLs.


## EZID prior to 3.1

In versions of EZID prior to 3.1, EZID does not perform identifier resolution and instead delegates this functionality to N2T. When an identifier is created or modified in EZID, the changes are propagated to N2T, and clients are directed to N2T for resolution. 

Hence, in versions prior to 3.1, N2T provides Scheme Resolution, Prefix Resolution, and Resource Resolution services for EZID.

```plantuml
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

title EZID Identifier Resolution context, versions before 3.1.

Person(user, "User", "A user looking to resolve an identifier.")
Person(creator, "Creator", "A content creator that associates an identifier with a resource")
System(ezid, "EZID", "The EZID identifier management system")
System(n2t, "N2T", "The N2T identifier resolution service")
System_Ext(resource, "Resource", "A server hosting resources identified by an identifier")
System_Ext(naan, "NAAN Registry", "Associates ARK prefixes with resolver services.")

Rel(naan, n2t, "Informs")
Rel(creator, resource, "Create resource on resource server.")
Rel(creator, ezid, "Create identifier for resource at location.")
Rel(ezid, n2t, "Set identified resource location.")
Rel(user, n2t, "Get location of identified resource.")
Rel(user, resource, "Get resource from location.")
@enduml
```
> **Figure 2.** Context diagram for EZID identifier resolution for EZID versions before 3.1. Resources are located at external servers, and globally unique, resolvable identifiers may be created for those resources using EZID. Resolution of EZID identifiers is handled by N2T, which is updated when identifiers are created or edited on EZID.

```plantuml
@startuml
actor "User" as user
actor "Creator" as creator
participant "EZID" as ezid
participant "N2T" as n2t
participant "Resource\nServer" as server
database "NAANs" as naan
== Create identified resource ==
creator -> server: Create resource
activate creator
activate server
server --> creator: location
deactivate server
creator -> ezid: Create identifier (location)
activate ezid
ezid -> n2t: Set identifier, location
activate n2t
n2t --> ezid: OK
deactivate n2t
ezid --> creator: identifier
deactivate ezid
deactivate creator

== Later: User retrieves identified resource ==
user -> n2t: https://n2t.net/identifier
activate user
activate n2t
n2t <-> naan: Lookup prefix
n2t --> user: location
deactivate n2t
user -> server: get(location)
activate server
server-->user: resource
deactivate server
deactivate user
@enduml
```
> **Figure 3.** Sequence diagram for identifier creation and identifier resolution with EZID prior to version 3.1. 

The identifier expressed as a URL uses the pattern:
```
https://n2t.net/{identifier}
```
Where `{identifier}` is replaced with the identifier being resolved. For example, the identifier `ark:/87292/w97m0403s` would have a suggested URL representation of:
```
https://n2t.net/ark:/87292/w97m0403s
```

N2T returns a `location` of:
```
https://digitalcollections.lib.iastate.edu/islandora/object/isu:Rosene_2787
```

## EZID 3.1

EZID 3.1 supports identifier resolution (i.e. it operates as a Resource Resolver) and so any identifier managed by EZID may also be resolved through that service.

EZID 3.1 continues to synchronize identifier metadata with N2T, so N2T continues to offer equivalent capability as a Resource Resolver for EZID identifiers.

```plantuml
@startuml
actor "User" as user
actor "Creator" as creator
participant "EZID" as ezid
participant "N2T" as n2t
participant "Resource\nServer" as server
database "NAANs" as naan
== Create identified resource ==
creator -> server: Create resource
activate creator
activate server
server --> creator: location
deactivate server
creator -> ezid: Create identifier (location)
activate ezid
ezid -> n2t: Set identifier, location
activate n2t
n2t --> ezid: OK
deactivate n2t
ezid --> creator: identifier
deactivate ezid
deactivate creator

== Later: User retrieves identified resource ==
user -> n2t: https://n2t.net/identifier
activate user
activate n2t
n2t <-> naan: Lookup prefix
n2t --> user: location
deactivate n2t
user -> server: get(location)
activate server
server-->user: resource
deactivate server
deactivate user

== Alternate: ==
user -> ezid: https://ezid.cdlib.org/identifier
activate user
activate ezid
ezid --> user: location
deactivate ezid
user -> server: get(location)
activate server
server-->user: resource
deactivate server
deactivate user

@enduml
```
> **Figure 4.** Sequence diagram for identifier creation and identifier resolution with EZID version 3.1. 

The identifier expressed as a URL uses the pattern:
```
https://n2t.net/{identifier}
```
Where `{identifier}` is replaced with the identifier being resolved. For example, the identifier `ark:/87292/w97m0403s` would have a suggested URL representation of:
```
https://n2t.net/ark:/87292/w97m0403s
```

N2T returns a `location` of:
```
https://digitalcollections.lib.iastate.edu/islandora/object/isu:Rosene_2787
```

Note that there are no outward changes to user interaction with EZID version 3.1. Users *may* use the EZID URL for resolving identifiers, however the recommended "identifier as a URL" pattern is to continue using `https://n2t.net/{identifier}`

## EZID 3.2 onwards

For EZID version 3.2 onwards, identifier level metadata is no longer synchronized with N2T, and so N2T is no longer a Resource Resolver for EZID. N2T continues to operate as a Scheme Resolver and a Prefix Resolver for EZID (and other) identifiers. 

```plantuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

title EZID Identifier Resolution context, versions 3.1 onwards.

Person(user, "User", "A user looking to resolve an identifier.")
Person(creator, "Creator", "A content creator that associates an identifier with a resource")
System(ezid, "EZID", "The EZID identifier management system")
System(n2t, "N2T", "The N2T identifier resolution service")
System_Ext(resource, "Resource", "A server hosting resources identified by an identifier")
System_Ext(naan, "NAAN Registry", "Associates ARK prefixes with resolver services.")

Rel(naan, n2t, "Informs")
Rel(creator, resource, "Create resource on resource server.")
Rel(creator, ezid, "Create identifier for resource at location.")
Rel(user, n2t, "Get location of resolver for identifier.")
Rel(user, ezid, "Get location of identified resource.")
Rel(user, resource, "Get resource from location.")
```
> **Figure 5.** Context diagram for EZID identifier resolution for EZID versions 3.2 and later. Resources are located at external servers, and globally unique, resolvable identifiers may be created for those resources using EZID. Resolution of EZID identifiers is handled by EZID, with N2T responsible for associating the identifier prefix with a resolver service. 

```plantuml
actor "User" as user
actor "Creator" as creator
participant "EZID" as ezid
participant "N2T" as n2t
participant "Resource\nServer" as server
database "NAANs" as naan
== Create identified resource ==
creator -> server: Create resource
activate creator
activate server
server --> creator: location
deactivate server
creator -> ezid: Create identifier (location)
activate ezid
ezid --> creator: identifier
deactivate ezid
deactivate creator

== Later: User retrieves identified resource ==
user -> n2t: resolve(identifier)
activate user
activate n2t
n2t <-> naan: Lookup prefix
n2t --> user: resolver
deactivate n2t
user -> ezid: resolve(identifier)
activate ezid
ezid --> user: location
deactivate ezid
user -> server: get(location)
activate server
server-->user: resource
deactivate server
deactivate user

== Alternate: ==
user -> ezid: https://ezid.cdlib.org/identifier
activate user
activate ezid
ezid --> user: location
deactivate ezid
user -> server: get(location)
activate server
server-->user: resource
deactivate server
deactivate user
```
> **Figure 6.** Sequence diagram for identifier creation and resolution for EZID version 3.2 and later. Individual identifier metadata is no longer propagated to N2T, and instead N2T delgates resolution of identifiers with prefixes associated with the EZID service to EZID.

The identifier expressed as a URL uses the pattern:
```
https://n2t.net/{identifier}
```
Where `{identifier}` is replaced with the identifier being resolved. For example, the identifier `ark:/87292/w97m0403s` would have a suggested URL representation of:
```
https://n2t.net/ark:/87292/w97m0403s
```

N2T recognizes EZID as the Resource Resolver, and so returns a `location` of:

```
https://ezid.cdlib.org/ark:/87292/w97m0403s
```

Which in turn provides the `location` of the resource:

```
https://digitalcollections.lib.iastate.edu/islandora/object/isu:Rosene_2787
```

Note that there are no outward changes to user interaction with EZID version 3.2+. Users *may* use the EZID URL for resolving identifiers, however the recommended "identifier as a URL" pattern is to continue using `https://n2t.net/{identifier}`.

