--- 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}`.