The need to preserve digital information in the long term is a primary concern of many initiatives, one of which is the development of the Reference Model for an Open Archival Information System (OAIS) by the Consultative Committee on Spatial Data Systems (CCSDS) and the International Organization for Standardization (ISO) [1].
One of the preservation problem is how to maintain the integrity of hyperlinks in the long-term, which may extend indefinitely.
In a previous note, the existence of a digital service that turns the Persistent Hyperlinks independent of the protocol and the resolver domain name has been shown [2]. Essentially, this digital service consists in what we call a Source Resolver.
The purpose of this note is to illustrate the use of that digital service, for example, in the case of a Federation of Archives [1], that allows Persistent Hyperlinks to work with Local Destination Resolvers (each one being an Archive extention) instead of a global Destination Resolver.
By Local Destination Resolver, it is intended that the Archive which contain the destination resources works also as a resolver for all its Archival Information Packages (AIPs) identifiers [1], i.e. both have the same domain name. In turn, the Archive hosting the AIP containing the source resource (e.g., this HTML page) works as a Source Resolver [2], i.e. both have also the same domain name. In the two cases, we say that the resolver is an extention of the Archive.
Inicially, it is suposed that each Archive identifies its AIPs independent of each other. In this way, as commented in [1]: "when an Archive joins a Federation, there is no assurance that some of its current AIP identifiers are not already used by other members of the Federation. An example of a general solution to this problem is to form the AIP identifiers in the Federation by assigning a Unique ID for each Archive in the Federation and concatenating it to the identifier for each AIP preserved by that Archive".
Here, to assign a unique ID to each Archive we propose a simpler alternative standard to ISO X.500 Directory Services Naming. This standard reuses part of the standard presented in [3]. Futhermore, to refer to the unique ID of an Archive, we use the general expression "Namespace Prefix" (see definition below), already used in [2] to identify a naming system†.
This HTML page contains three examples of Fully Persistent Hyperlinks (see definition below). In each example, the hyperlink point to a destination resource hosted by an Archive that is a member of an open Federation of Archives whose members have each a registered Namespace Prefix (see Observation 6) that identifies them.
The three corresponding destination resources are hosted in two Archives that belong to this open Federation. They are identified by the Namespace Prefix: upn:3Q3U5H8 and upn:35SP775. The source resource does not need to be hosted in to a federated Archive. However, for security reasons and to avoid confusion with malicious Archives (see Observation 7), it should also be hosted in a federated Archive, as is the case with this page.
In the context of the definitions below regarding URI identifier resolution, the word object applies to terms such as resource, package or even AIP, all of which are targets of the preservation in Archives.
– A Source Object (SO) is an object which cites another object.
– A Destination Object (DO) is an object which is cited by another object.
– A Source Archive is an Archive which contains one or more Source Objects.
– A Destination Archive is an Archive which contains one or more Destination Objects.
– A Hyperlink (from a Source Object - SO to a Destination Object - DO) is a computational command inserted into the SO, whose argument specifies the URL of the DO, and which, when activated, brings the DO on the user's screen. Example: https://www.sciencedirect.com/science/article/abs/pii/S0034425721003874.
– A Namespace is a set of names.
– An Identifier (of an object) is a unique name within a specific Namespace that is assigned permanently to that object by an Archive. Example: 10.1016/j.rse.2021.112667.
– A Namespace Prefix (of an Archive or a resolver) is a unique name assigned to an Archive or a resolver, used to form the URI of potential Destination Objects. Example: urn:doi.
– A URI (of an object) is the concatenation of an Archive, or a resolver, Namespace Prefix and the Identifier of that object. Example: urn:doi:10.1016/j.rse.2021.112667.
– A Browser Resolver is a browser feature that concatenates the default base URL to the value of the each relative hyperlink contained in a Source Object.
– A Source Resolver is an extension of a Source Archive that maps/directs each Namespace Prefix to an appropriate Destination Resolver URL from a set of one or more possible URLs.
– A Destination Resolver is an independent resolver or an extension of an Destination Archive that maps/directs each Destination Object Identifier to the corresponding current Destination Object URL.
– A Persistent Hyperlink (from a Source Object - SO to a Destination Object - DO) is a computational command inserted into the SO, whose argument specifies a protocol, a global Destination Resolver domain name and the DO Identifier, and which, when activated, brings the DO on the user's screen. Example: https://doi.org/10.1016/j.rse.2021.112667.
– A Persistent Relative Hyperlink (from a Source Object - SO to a Destination Object - DO) is a relative Persistent Hyperlink (from the SO to the DO) whose DO Identifier is resolved by a global Destination Resolver, at the request of a Source Resolver. Example: urn:doi:10.1016/j.rse.2021.112667.
In other words, a Persistent Relative Hyperlink is a computational command whose argument specifies neither the protocol nor the domain name of the resolver, but it does specify the Namespace Prefix (e.g., urn:doi) which is resolved by the Source Archive working as a Source Resolver. In the background, the DO Identifier need be resolved by a global Destination Resolver.
– A Local Destination Resolver is an extension of an Archive that maps/directs each of his Destination Object Identifier to the corresponding current Destination Object URL.
– A Fully Persistent Hyperlink (from a Source Object - SO to a Destination Object - DO) is a Persistent Relative Hyperlink (from the SO to the DO) whose DO Identifier is resolved by a local Destination Resolver, at the request of a Source Resolver. Example: upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS (see Example 1 below).
Examples of three Persistent Relative Hyperlinks were given in [2]. In the next section, examples of three Fully Persistent Hyperlinks are now presented.
The three hyperlinks below are relative Persistent Hyperlinks‡. This can be verified by looking at the value of the respective href attribute in the source code of this HTML page.
They are Fully Persistent because the Source Archive works as a Source Resolver that triggers the Local Destination Resolver which is an extention of the Destination Archive.
- First example of Fully Persistent HTML hyperlink
- Second example of Fully Persistent HTML hyperlink
- Third example of Fully Persistent HTML hyperlink
Title of the Destination Object (DO): The Internet Based Identifier (IBI) and the IBI Network.
Available from: upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS
Hyperlink source code: <a href="./upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS" target="_blank">upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS</a>
In this example the Destination Object is in the original Destination Archive, that is, in the Archive in which its URI was formed, and not in an Archive to which it was migrated. This was, at least, the situation at the time this note was written, and this can be verified by consulting to the complete metadata of the Destination Object: upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS: (the final colon (:) redirects to the complete metadata).
The Site and Identifier lines of the complete metadata, in the first field area called Identify statement, indicate that the Destination Object is hosted in the Archive (Site) registered under the Namespace Prefix upn:3Q3U5H8 and its Identifier is 8JMKD3MGP3W34R/44C25PS (see Figure 1a).
Figure 1a. Screenshot of the Site and Identifier lines of the complete metadata of the Destination Object, showing the Namespace Prefix: upn:3Q3U5H8 of the Archive hosting it and its Identifier 8JMKD3MGP3W34R/44C25PS – Screenshot taken on November 26, 2025.
Figure 1b. Screenshot of the Host Collection line of the complete metadata of the Destination Object, showing the Namespace Prefix: upn:3Q3U5H8 of the Archive hosting it (see red arrow) – Screenshot taken on November 26, 2025.
Title of the Destination Object (DO): Research and development on a small Spherical Tokamak.
Available from: upn:35SP775:8JMKD3MGP7W/36U89RH
Hyperlink source code: <a href="./upn:35SP775:8JMKD3MGP7W/36U89RH" target="_blank">upn:35SP775:8JMKD3MGP7W/36U89RH</a>
In this example the Destination Object is NO LONGER in the original Destination Archive, meaning that after been hosted there and assigned a URI, it migrated to another Archive. This was, at least, the situation at the time this note was written, and this can be verified by consulting to the complete metadata of the Destination Object: upn:35SP775:8JMKD3MGP7W/36U89RH:.
The Site and Identifier lines of the complete metadata, in the first field area called Identify statement, indicate that the Destination Object is hosted in the Archive (Site) registered under the Namespace Prefix upn:3Q3U5H8 and its Identifier is 8JMKD3MGP7W/36U89RH (see Figure 2a).
Figure 2a. Screenshot of the Site and Identifier lines of the complete metadata of the Destination Object, showing the Namespace Prefix: upn:3Q3U5H8 of the Archive hosting it and its Identifier 8JMKD3MGP7W/36U89RH – Screenshot taken on November 26, 2025.
Figure 2b. Screenshot of the Host Collection line of the complete metadata of the Destination Object, showing a list of its successive migrations from top to bottom, namely, between the Archive identified as: upn:35SP775 and the Archive identified as: upn:3Q3U5H8 – Screenshot taken on November 26, 2025.
Finally, in this example, at the time this note was written, the first Archive still existed meaning that there was a rearrangement of objects between two federated Archives.
The proposed approach ensure that the Destination Objects (AIPs) will be findable once they have been moved from a federated Archive to another, provided that the Destination Archives are able to resolve the Identifiers created by other Archives in the Federation.
Title of the Destination Object (DO): Curso 8 - Conceitos e Ferramentas para Análise de Imagens de Radar de Abertura Sintética (SAR).
Available from: upn:GJR3MH:5PFmX3pFwXQZ55QH/xUCHa
Hyperlink source code: <a href="./upn:GJR3MH:5PFmX3pFwXQZ55QH/xUCHa" target="_blank">upn:GJR3MH:5PFmX3pFwXQZ55QH/xUCHa</a>
In this example, again, the Destination Object is NO LONGER in the original Destination Archive, meaning that it migrates from an Archive to another. This can be verified by consulting to the complete metadata of the Destination Object: upn:GJR3MH:5PFmX3pFwXQZ55QH/xUCHa:.
The Site and Identifier lines of the complete metadata, in the first field area called Identify statement, indicate that the Destination Object is hosted in the Archive (Site) registered under the Namespace Prefix upn:35SP775 and its Identifier is 5PFmX3pFwXQZ55QH/xUCHa (see Figure 3a).
Figure 3a. Screenshot of the Site and Identifier lines of the complete metadata of the Destination Object, showing the Namespace Prefix: upn:35SP775 of the Archive hosting it and its Identifier 5PFmX3pFwXQZ55QH/xUCHa – Screenshot taken on November 26, 2025.
Figure 3b. Screenshot of the Host Collection line of the complete metadata of the Destination Object, showing its migration from the Archive identified as: upn:GJR3MH to the Archive identified as: upn:35SP775 (see the two red arrows) – Screenshot taken on November 26, 2025.
Ultimately, in this example, at the time this note was written, the first Archive upn:GJR3MH no longer existed. This means that there must have been an agreement between the two federated Archives to ensure the continued effective preservation of, at least, part of the threatened holdings, should the original Archive cease to operate. The proposed approach ensure that the Destination Objects (AIPs) will be findable once they have been moved to a successor Archive.
- Observation 1 (Formation of the URI of a Destination Object):
All digital objects hosted in Web Archives are potential Destination Objects (DOs). To distinguish one object on the Web from others, in addition to the local identification made by each Archive, we use the Namespace Prefix assigned to Archives or to global Destination Resolvers. Concatenating the latter with the former results in the formation of a URI.
When using Local Destination Resolvers rather than global Destination Resolvers, two important rules must be followed to ensure that the URIs of potential Destination Objects are formed based on the correct Namespace Prefix for dissemination and use by fully persistent hyperlinks in future Source Objects. The two rules are:
• Once an Archive has registered its own Namespace Prefix, it must preserve the newly created Namespace Prefix in the Provenance Information of the potential Destination Objects that do not yet have such Provenance Information.
• Once an object is submitted to or disseminated from an Archive, the Archive's Namespace Prefix must be preserved in the object's Provenance Information.
Once formed, the URI of a Destination Object will never change, even if the object migrates to another Archive. Hence the importance of preserving the Namespace Prefix in the object's Provenance Information.
A convenient way to preserve the URI Namespace Prefix of a Destination Object is to retain it at the first place in a list of Archives identifiers (also call here, host collections identifiers) that chronologically describe all the Archives that have hosted the Destination Object, as in Examples 2 and 3 above (see the top red arrows in Figures 2b and 3b).
The above object's Provenance Information will play an important role to select all the Namespace Prefix currently in use in each Archive having a registered Namespace Prefix (see the mapping denoted g in Observation 5 below).
- Observation 2 (Source Resolver and Prefix-ResolverURL mapping):
Table 1 illustrates how the Archive $localSite works as a Source Resolver to solve the above three examples. As with any resolver, the URL path component (e.g., upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS — see Line 1 of Table 1) is an identifier, but with the difference that it is an URI defined in the global scope of the possibly IANA registered URI Namespace Prefix.
The Namespace Prefix of this URI (e.g., upn:3Q3U5H8) identifies one or more candidates to be the Local Destination Resolvers for the resolution of the specific Destination Object Identifier (e.g., 8JMKD3MGP3W34R/44C25PS).
In turn, the URLs of one or more possible Destination Resolvers (e.g., ${upn:3Q3U5H8ResolverURL} for upn:3Q3U5H8 — see Line 2 of Table 1) is assigned to each Namespace Prefix (e.g., upn:3Q3U5H8) thus forming a mapping that we call "Prefix-ResolverURL".
It may be necessary to assign more than one Destination Resolver URL to a specific Namespace Prefix (e.g., the URL list {${upn:35SP775ResolverURL}} for upn:35SP775 — see Line 5 of Table 1) because the holdings of an Archive have been distributed among more than one active Archive, as in Example 2.
In this case the Source Resolver must check which URL is responding before redirecting the client's resolution request to the appropriate Destination Resolver. This is done at the first check of the day, and the resulting appropriate Destination Resolver is then assigned to the URI (see Line 6 of Table 1).
This type of assignment leads to the construction, in each Source Resolver, of a mapping from the set of cited Destination Object URIs in its Source Objects to the set of possible Destination Resolver URLs. This mapping is used to avoid further checks until the following day.
Table 1 - Source Resolver operation
Source Resolver http://$localSite/upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS Assigment to upn:3Q3U5H8 upn:3Q3U5H8 ↦ {${upn:3Q3U5H8ResolverURL}} Destination Resolver ${upn:3Q3U5H8ResolverURL}/upn:3Q3U5H8:8JMKD3MGP3W34R/44C25PS Source Resolver http://$localSite/upn:35SP775:8JMKD3MGP7W/36U89RH Assigment to upn:35SP775 upn:35SP775 ↦ {${upn:35SP775ResolverURL}} Assigment to the URI upn:35SP775:8JMKD3MGP7W/36U89RH ↦ $url Destination Resolver $url2 Source Resolver http://$localSite/upn:GJR3MH:5PFmX3pFwXQZ55QH/xUCHa Assigment to upn:GJR3MH upn:GJR3MH ↦ {${upn:GJR3MHResolverURL}} Destination Resolver ${upn:GJR3MHResolverURL}/upn:GJR3MH:5PFmX3pFwXQZ55QH/xUCHa The first time they are requested on a given day, each Source Resolver must have its own Prefix-ResolverURL mapping updated based on one or more reference Prefix-ResolverURL mappings, which in turn are continuously updated by each Destination Archive (see Observations 4 and 5 below).Currently, there is a reference Prefix-ResolverURL mapping that can be accessed by pointing to upn:9HFNHE:QABCDSTQQW/4E7MG35. This mapping need not be unique but, in this case, some kind of synchronization between them would be convenient.
- Observation 3 (Example of the overall resolution process):
The overall process of resolution of a Destination Object's URI involves three resolvers. Figure 1 is an illustration of the behaviour of each resolver in the case of Example 2 above, at the time this note was written.
• Firstly, the Browser Resolver combines the base URL:
http://gjfb0520.sid.inpe.br/col/urlib.net/www/2023/11.16.13.37/doc/
with the hyperlink:
upn:35SP775:8JMKD3MGP7W/36U89RH
what leads to the URL:
http://gjfb0520.sid.inpe.br/col/urlib.net/www/2023/11.16.13.37/doc/upn:35SP775:8JMKD3MGP7W/36U89RH
• Secondly, this URL activates the Source Resolver which gets from the Prefix-ResolverURL mapping the following assignment:
upn:35SP775 ↦ {${upn:35SP775ResolverURL}}
after check of which Destination Resolver is responding, the Source Resolver establishes the following assignment:
upn:35SP775:8JMKD3MGP7W/36U89RH ↦ $url.
what leads to the URL:
http://mtc-m21c.sid.inpe.br/upn:35SP775:8JMKD3MGP7W/36U89RH
• Thirdly, this URL activates the Destination Resolver which uses the following assignment:
8JMKD3MGP7W/36U89RH ↦ col/sid.inpe.br/mtc-m19@80/2010/02.12.16.37/doc/publicacao.pdf
what leads to the URL:
http://mtc-m21c.sid.inpe.br/col/sid.inpe.br/mtc-m19@80/2010/02.12.16.37/doc/publicacao.pdf
Figure 1. Resolution process of the hyperlink of Example 2 on November 26, 2025.
Source: Author - Observation 4 (Rules for the construction of the reference Prefix-ResolverURL mapping):
A reference Prefix-ResolverURL mapping is a dynamical mapping (that changes over time), here denoted f, from the set A to P(B), the power set of B, where:
• A is a set of possibly IANA registered name-type URI Namespace Prefix, and
• B is a set of URLs that resolved, or that can resolve some URI having a Namespace Prefix in the set A.
The subset f(a) of B consists of the URL(s) that can currently resolve some URI having a as its Namespace Prefix.The rules for the construction of a reference Prefix-ResolverURL are:
– When a new Namespace Prefix a (e.g., upn:3Q3U5H8) is registered with the information that the assigned Destination Resolver's URL is b (e.g., http://mtc-m21c.sid.inpe.br), a is added to A, if necessary b is added to B (b may have existed serving another Archive), and f(a) set to the value {b}. Hence, the pair (a, {b}), is added to the graph of the f mapping. Here is an example of such added pair (case of Example 1):
(upn:3Q3U5H8, {http://mtc-m21c.sid.inpe.br}).– When, a DO with Namespace Prefix a (e.g., upn:35SP7758) migrates, from one Archive to another with URL b (e.g., http://mtc-m21c.sid.inpe.br) and is the first to do so, b is inserted into f(a). Here is an example of an updated pair after a URL insertion (case of Example 2):
(upn:35SP775, {http://mtc-m16d.sid.inpe.br http://mtc-m21c.sid.inpe.br}).In fact, for reasons of efficiency of the Source Resolvers, an Archive (here, the Archive with URL http://mtc-m16d.sid.inpe.br) that transfers the part of its holdings identified by the same Namespace Prefix, should try to transfer it to the fewest possible number of other Archives, if possible to only one. It is also a way to preserve the overall integrity of Archive holdings.– When, an Archive with Namespace Prefix a (e.g., upn:GJR3MH) and URL b1 (e.g., http://lagavulin.ltid.inpe.br) is discontinued and its holdings are migrated to another Archive with URL b2 (e.g., http://mtc-m16d.sid.inpe.br), b1 is removed from f(a) and b2 is added in place. Here is an example of an updated pair after such holdings migration (case of Example 3):
(upn:GJR3MH, {http://mtc-m16d.sid.inpe.br}). - Observation 5 (Construction of a reference Prefix-ResolverURL mapping from its transpose):
The implicit implementation of a reference Prefix-ResolverURL mapping construction rules can be done indirectly from another dynamical mapping, here denoted g, from the set B to P(A), the power set of A, where g(b) is the subset of A of Namespace Prefix of URI that could currently and eventually be resolved by b.
The mappings f and g verify that, for any a in A and b in B,
b is in f(a) ⇔ a is in g(b).We say that the pair of mappings (f, g) forms a connection between the sets A and B. An essential property of that connection is that one mapping uniquely determines the other:
g(b) = {a in A : b is in f(a)},f(a) = {b in B : a is in g(b)}.Considering that the two mappings f and g of the above connection induce, respectively, two relations: "b is in f(a)" on A × B and "a is in g(b)" on B × A which are mutally transpose, we say that f and g are also Mutually Transpose.
Hence, a reference Prefix-ResolverURL mapping f can be updated and recreated at any time from its transpose g whose values can be obtained from each Archive that have a registered Namespace Prefix and a fixed IP address.
The idea is to have a specific standard that defines a communication protocol allowing an Archive b to send its list g(b) of UPNs to the federation with which it was registered and that maintains the reference Prefix-ResolverURL mapping f.
- Observation 6 (Creation, syntax and registration of the UPN URI scheme):
"UPN" stands for Uniform Package Name. The upn URI scheme still needs to be registered with IANA. Inicially, this scheme was designed to identify any Archival Information Package (AIP) hosted on the Archives of the URLib platform [4], however it can be used to identify any Destination Object deposited in Archives identifying their holdings and working as Destination Resolvers for those holdings.
All UPNs must have the same syntax as URNs [5]. This applies in particular to the syntax of the Namespace-Specific String, which is the part of the UPN URI that is not the Namespcae Prefix.
The Destination Archives working as local Destination Resolvers and are insterested in having their resources cited via fully persistent hyperlinks must register a UPN Namespace ID.
To create and register a new UPN Namespace ID, point to upn:LPEJ5E:QABCDSTQQW/4DMTTQE and send an e-mail to the representative of an Archive federation of your choice, stating the Archive's URL for the created UPN Namespace ID.
- Observation 7 (Security considerations):
A Persistent Relative Hyperlink [2] or a Fully Persistent Hyperlink [this note] are processed by what we call a Source Resolver. The function of the Source Resolver is to assemble the URL of the appropriate Destination Resolver which in turn assembles the URL of the DO to be directed to the client's browser for redirection (see Observation 3).
The Source Resolver is an extension of a Source Archive. In turn, the Archive is a member of an open Federation of Archives, whose members have registered UPN namespace ID and are interested in using relative hyperlinks to preserve the integrity of their hypertexts.
A malicious Archive that is probably not part of the Federation may have made a copy of a SO from a federated Archive, and its Source Resolver may assemble a malicious URL to be directed straight forward to the client's browser for redirection. In this case, the client, upon clicking a SO relative hyperlink that points to a DO, will likely see a different DO than expected.
For security reasons, it would then be necessary:
• That the Source Archive register a UPN Namespace ID and the federation with which it was registered to ensure the correct functioning of its Source Resolver;
• For the client's Browser Resolvers to display a warning message whenever, in the presence of relative URI hyperlink, the Archive's URL does not belong to those known by the Federations.
Consequently, in the presence of relative URI hyperlink, browsers would need to consult lists of federated Archives such as upn:9HFNHE:QABCDSTQQW/4E7MG35/federatedArchives.txt, avaliable in January 2026, to decide whether or not to display the warning message.
- Observation 8 (Sufficient condition to get a Fully Persistent Hyperlink):
It is sufficient for a Persistent Relative Hyperlink (from a SO to a DO having a UPN ID) to become a Fully Persistent Hyperlink to change the URI Namespace Prefix that points to the global Destination Resolver to the Namespace Prefix that points to the Local Destination Resolver identified by the UPN ID of the DO.
A next note introduces yet another definition of hyperlink, the so-called Robust Hyperlink, which is the last stage of the proposed advanced hyperlink types and contributes to solving the problem of the continued existence of Web resources [6].
References
[1] THE CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS). Reference Model for an Open Archival Information System (OAIS) - CCSDS 650.0-M-3. Reston: CCSDS, 2024. 150 p. (CCSDS 650.0-M-3). Available from: https://ccsds.org/wp-content/uploads/gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/01//650x0m3.pdf.[2] BANON, G. J. F. Example of three Persistent Relative Hyperlinks. [S.l.] Deposited in the URLib collection, 2023. IBI: <QABCDSTQQW/49884CP>. Available from: upn:EFDBHS:QABCDSTQQW/49884CP.
[3] COMISSÃO-DE-ESTUDOS ABNT/CB08/SC010/CE70. System for IBI generation. São José dos Campos: Comissão-de-Estudo ABNT/CB08/SC010/CE70, version: 2021-11-14. 48 p. IBI: <J8LNKB5R7W/3NSP3DL>. Available from: upn:32NSFRP:J8LNKB5R7W/3NSP3DL.
[4] BANON, G. J. F. What is URLib?. [S.l.] Deposited in the URLib collection, work-in-progress. IBI: <LK47B6W/E6H5HH>. Available from: upn:9HFNHE:LK47B6W/E6H5HH.
[5] SAINT-ANDRE, P.; FILAMENT and KLENSIN, J. Uniform Resource Names (URNs) [S.l.] Internet Engineering Task Force (IETF). Request for Comments: 8141. ISSN: 2070-1721. Available from: <doi:10.17487/RFC8141>.
[6] BANON, G. J. F. Example of Robust Hypertext and authentic data. [S.l.] Deposited in the URLib collection, 2023. IBI: <QABCDSTQQW/4AEFPDB>. Available from: <upn:E8KGRE:QABCDSTQQW/4AEFPDB>.