Work in progress
by Gérald Jean Francis Banon
December 2023
Updated in August 2025
Persistent hyperlinks are important because they solve the problem that results from the relocation of web resources. However, other problems must be solved to ensure full persistence. One is the dependence, in some circumstances, on a global resolver and a URL scheme, another is the very existence of the Web resources.
Solutions to the above dependency are presented in [1] and [2] along with definitions and examples of Almost Fully Persistent Hyperlinks and Fully Persistent Hyperlinks, respectively.
This note introduces yet another definition of hyperlink, the so-called Robust Hyperlink, which is the last phase of the advanced types of hyperlink proposed and contributes to solving the problem of the continuous existence of Web resources.
A summary of hyperlink maturity levels, including the robust hyperlink introduced in this note, is provided in Table 1.
Table 1 - Persistent hyperlink maturity levels
URI type |
URI property | Res. level1 |
Safe DO2 |
Hyperlink name type |
Maturity level |
Hyperlink example |
---|---|---|---|---|---|---|
locator | protocol dependent server name dependent location dependent |
0 | location dependent absolute |
Ad-hoc | https://www.clir.org/wp-content/ uploads/sites/6/ pub63watersgarrett.pdf |
|
locator | protocol dependent server name dependent location independent |
1 | persistent absolute |
Basic | https://doi.org/10.1016/j.rse.2021.112667 | |
name | protocol independent server name independent location independent |
2 | almost fully persistent [1] relative |
Procedure driven |
upn:4CR88AP:QABCDSTQQW/49884CP | |
name | protocol independent server name independent location independent |
3 | fully persistent [2] relative |
Trust- worthy |
upn:4CR88AP:8JMKD3MGP3W34R/44C25PS | |
name | protocol independent server name independent location independent |
3 | ✓ | robust relative |
Future facing |
upn:4CR88AP:83LX3pFwXQZeBBx/65ij |
1 Resolution level :: 0: no resolution; 1: global resolver; 2: browser resolver and global resolver; 3: browser resolver and local resolver.
2 Safe Destination Object :: see Observation 4 below.
It is not uncommon for a digital object (information item) to be composed of parts of other digital objects distributed over the Web. This approach, based on the relevant principle of Single source of truth that provides data that are authentic and refenceable, guarantees the authenticity of the reused data and, consequently, prevents its deliberate or unintentional distortion.
To preserve in the Long-Term, that may extend indefinitely, the integrity of such digital object, and those that simply make references to other resources, the Robust Hyperlinks are specially important.
Following the terminology of the Reference Model for an Open Archival Information System (OAIS) [3], this note can be seen as the Data Object (Digital Object) of an Archival Information Package (AIP) preserved in an Archive which is member of a Federation of Archives.
Currently, this Federation have the following members (the first is the one hosting the present HTML page):
– A Robust Hyperlink (from a Source Object - SO to a Destination Object - DO, both belonging to a Federation of Archives) is a Fully Persistent Hyperlink (from the SO to the DO, both belonging to a Federation of Archives)[2], which, when activated, increments a counter in the DO's Context Information that documents the number of times it has been activated from that particular SO.
– A Robust Hypertext is a hypertext whose hyperlinks are robust.
Important Observation: Robust Hyperlinks (from a Source Object - SO to a Destination Object - DO, both belonging to a Federation of Archives) can significantly contribute to solving the problem of the DO's continued existence in the sense that, based on the DO's Context Information there is a digital object, precisely an SO, citing the DO, it is possible to disable any attempt to remove the DO and, in this way, preserve the hyperlink functionality.
– URLib is the acronym for Uniform Repository for a Library, an experimental computing platform that makes hosting of robust hypertext much easier and more secure because the IBI identifier of the Source Object, specifically, its uniform repository name‡, is part of its storage path.
– doc is the standard name of a directory containing a hypertext (digital object) (see illustration in Fig. 1).
Figure 1. A doc directory.
Source: [4]
– A Uniform Repository (or package) is a set of 4 successive directories that forms a unique persistent path to a doc directory (see illustration in Fig. 2).
Figure 2. Example of a uniform repository.
The repository name is: dpi.inpe.br/ronei/1996/11.20.18.56
Source: [4]
When convenient, a repository is represented like a single directory (see illustration in Fig. 3).
Figure 3. Convention.
A repository R1
Source: [4]
– col is the standard name of a directory containing a local collection of uniform repositories stored in an Archive (see illustration in Fig. 4).
Figure 4. A col – local collection – directory.
A local collection col with two repositories R1 and R2.
Source: [4]
– The federation collection is the set of all the federated Archive local collections (see illustration in Fig. 5).
Figure 5. The federation collection.
. . . . .
The set of all the distributed federated Archive local collections forms the overall collection of the Federation.
Source: [4]
This HTML page is an example of Source Object, it is a digital object using Robust Hyperlinks to incorporate parts of two other digital objects†. All these objects belong to the Federation described in the Introduction and consequently the two incorporations below are solved without the need of the IBI global resolver urlib.net (IBI stands for Internet Based Identifier).
Figure 6. Incorporation of a PDF page with its menu bar at the top.
Source: [5]
Incorporation source code: <iframe src="./upn:4CR88AP:83LX3pFwXQZeBBx/65ij/vestiges/urlibServicePage1995.pdf?ibiurl.backgroundlanguage=en&shortmenu=yes"></iframe>
Observation 1, about the source code:
Observation 2: The horizontal bar menu above the displayed PDF is part of the display of the DO. It indicates the IBI of the DO (shown as a tooltip text), its state (here the DO is the original), the license (here CC BY-NC-ND), its Metadata and, finally, a link to a list of the files that comprise the DO (one can verify in this list, the presence of the file vestiges/urlibServicePage1995.pdf been displayed below the horizontal menu). The Context Information in the Allied Materials Area of the Metadata page (see Fig. 7), shows the value of the Citing Item List field. This field is automatically updated and contains the repository name urlib.net/www/2023/12.25.14.57 of the SO (this page). At its right-hand side is the counter of the number of times the DO has been accessed from the SO (this page), this includes the PDF incorporation display and any click onto the anchor <upn:4CR88AP:83LX3pFwXQZeBBx/65ij> of [5] in the References.
Figure 7. Snapshot of the Citing Item List of DO (see red arrow that points to the SO repository name).
Observation 3: The path of this HTML page from the col directory is col/urlib.net/www/2023/12.25.14.57/doc. The moment it is loaded in the browser, the relative URL in the src attribute of the iframe tag is activated and the browser resolves the relative URL, that becomes the absolute URL: upn:4CR88AP:83LX3pFwXQZeBBx/65ij/vestiges/urlibServicePage1995.pdf?ibiurl.backgroundlanguage=en&shortmenu=yes. From the resolved URL, the repository name urlib.net/www/2023/12.25.14.57 of the SO is passed along by the resolver to the Archive who own the DO and which is then able to update the Context Information of the DO with the information that an SO (in this case, the SO with repository name urlib.net/www/2023/12.25.14.57) has requested the DO or part of it.
Observation 4: Once the Context Information of the DO has been updated with the information that at least one SO has requested the DO or part of it, the URLib platform delete procedure of the DO is automatically disabled as shown in Fig. 8, preventing deliberate or unintentional removal of the DO and thus making it safe.
Figure 8. The Delete Button (see red arrow) is disabled while the DO with IBI 83LX3pFwXQZeBBx/65ij has at least one citing item.
Observation 5: If, for some reason, the SO (this page) is deleted from the URLib platform, then the value of the Citing Item List field of the DO metadata will be automatically updated removing the SO from the citing item list.
Figure 9. Incorporation of a bar chart and a link to the Metatada of its original digital object.
Incorporation source code for the bar chart: <img src="./upn:4CR88AP-:8JMKD3MGPCW/3HHLNUH/thesisVivaPublicationYearBar.jpg">
Source code to access the Metadata: <a href="./upn:4CR88AP-:8JMKD3MGPCW/3HHLNUH:">Metadata</a>
Observation 6, about the first source code:
Observation 7: The moment this note is loaded in the browser, the relative URL in the src attribute of the img tag is activated and the browser rebuilt the full URL, that becomes: ./upn:4CR88AP-:8JMKD3MGPCW/3HHLNUH/thesisVivaPublicationYearBar.jpg. Due to the fact that ibi- is used instead of ibi, the repository name urlib.net/www/2023/12.25.14.57 of the SO will NOT be passed along by the resolver to the Archive who own the DO and, consequently, the Context Information of the DO will NOT be updated as it was when using ibi in the first incorporation. In this case, to ensure that the repository name urlib.net/www/2023/12.25.14.57 of the SO will be passed along, at least one click must be made onto the anchor <upn:4CR88AP:8JMKD3MGPCW/3HHLNUH> of [6 ] in the References.
Observation 8, about the second source code: To program the Metadata access, it is suficient to append a colon (:) to the opaque IBI of the Destination Object (DO). No file name needs to be appended.
‡The ibi namespace consists of two sub namespaces [7]. To each digital object (information item) deposited in the URLib platform is assigned two IBI identifiers, one in the uniform repository namespace and the other in an opaque namespace.