Digital images hold critical, compelling scholarly and scientific information. Unlocking their value, however, can be expensive. High-quality image object files are large and complex, and usually come with special storage and network requirements. Advanced software systems are needed for manipulation, zoom, search, display, description, and annotation, and they are often custom-built to work with local object servers. Of course, having persistent identifiers, such as ARKs, for image objects helps protect the large investment needed to create this sophisticated infrastructure.
This embedded interactive figure lets you page and zoom in a medieval manuscript from the BnF (French National Library) thanks to the open-source, IIIF Universal Viewer software.
Only well funded efforts can create sophisticated systems, customized to work with just one or a few repositories. But what if all organizations used the same access methods across their image servers? Then participating servers could share much of the same software, which would only need to be built once. Establishing standard access methods to unlock the value of open image collections across a large number of servers is a goal of “IIIF”.
What is IIIF?
The International Image Interoperability Framework (IIIF – pronounced “triple-eye-eff“) is a community-driven initiative that has defined six open application programming interfaces (APIs).
The APIs provide a rich set of ways to describe, request, and deliver most image-based content on the Web. The idea is that the more repositories adopt the IIIF APIs, the more software developers and vendors will be incentivized to create IIIF-compliant systems. The result will be affordable full-featured systems that work across a large and diverse set of image servers.
One cross-server use of IIIF is the virtual reconstruction demo of a volume from the Châteauroux Municipal Library that was created in 1460. The IIIF-compliant Mirador viewer uses hyperlinks to “fill holes in pages” where illustrations had once been cut out but were later found in various external collections.
This “reunification” demo was borrowed from the Introduction to IIIF video. It highlights a core aim of IIIF, which is to break down institutional silos that discourage content sharing across collections. Such sharing becomes all the more valuable the more that hyperlinks to internal and external institutional image servers are stable. Enter persistent identifiers.
The IIIF API expressed via identifiers
While IIIF recommends no particular persistent identifier for linking to web-accessible content, they mention ARKs and persistence. In particular, the IIIF image API says that an image identifier “may be an ARK, URN, filename, or other identifier.” Also, the IIIF presentation API says that once URIs for web-based resources are published, “they should be as persistent and unchanging as possible.”
In IIIF the base image identifier is a URI with defined path extensions to hold API parameters. The parameters are used to request such things as region, size, quality, and format. For example, this IIIF-compliant URI
https://gallica.bnf.fr/iiif/ark:/12148/btv1b8449691v/f29/2131,4016,1467,948/full/0/default.jpg
https://gallica.bnf.fr/iiif/ark:%2F12148%2Fbtv1b8449691v%2Ff29/2131,4016,1467,948/full/0/default.jpg (the ark:/ and the identifier have been URI percent-encoded per the IIIF specification, see Comments below)
requests the return of a specific rectangular region “2131,4016,1467,948”, at full quality and in the JPEG (“.jpg”) format. This region is shown below.
Image content is often hierarchical, so we need identifiers at more than one level. For example, a bound manuscript is a compound object consisting of page objects. The IIIF model allows for multiple image “canvas” objects under a top-level “manifest” object (covered in the IIIF presentation API).
Congruence of ARK extensions and IIIF paths
ARK suffixes (extensions), which are used to refer to sub-objects in a hierarchy and to variant formats, are a natural fit for IIIF, with its API parameters expressed as path extensions.
Resolver Service Compact ARK
__________________ _______________________________
/ \/ \
https://example.org/ark:/12345/x6np1wh8k/c3/s5.v7.xsl
\____________________________/\________/\___________/
Prefixes Base Name Suffixes
Moreover, because ARKs permit suffix passthrough, it is possible to register just the top-level resolvable ARK to support an infinite number of resolvable suffix combinations without having to register each extension.
While combining ARKs with IIIF holds great promise, there are currently no widely adopted recommendations for using them together. Meanwhile, it should be safe to follow the URI Syntax of the IIIF Image API and the current ARK specification. The table below shows more of the parallelism.
| ARK | https://{NMA}/ark:/{NAAN}/{name}/{qualifiers} |
| IIIF image API request | {scheme}://{server}{/prefix}/ {identifier}/{region}/{size}/{rotation}/{quality}.{format} |
| IIIF image API information | {scheme}://{server}{/prefix}/{identifier}/info.json |
| IIIF presentation API (manifest) | {scheme}://{host}/{prefix}/{identifier}/manifest.json |
| ARK+IIIF example 1 (manifest) | https://example.org/iiif/ark:%2F{NAAN}%2F{objID}/manifest.json |
| ARK+IIIF example 2 (image) | https://example.org/iiif/ark:%2F{NAAN}%2F{imgID}/full/max/0/default.jpg |
ARKs and IIIF in practice
Many organizations use the ARK and IIIF specifications, sometimes in conjunction. Examples include the BnF (French National Library), the British Library, Durham University Library, the Smithsonian Institution, and the University of North Texas Libraries. The application of ARKs within a IIIF ecosystem goes beyond the Image and Presentation APIs. One can imagine minting ARKs in context of other IIIF specifications, or using ARKs to redirect users to various tools and clients.
Some real world experiences from practitioners in the IIIF and ARK communities have been shared in the recorded webinar “Persistent identifiers in IIIF” (organized on 26 October 2021 by the Practical Applications of IIIF and Heritage PIDs projects, both foundation projects in the Towards a National Collection (TANC) programme in the UK).
It was an occasion to present the benefits of using ARKs and IIIF resources for the cultural heritage institutions. Neither has any (direct) fees and both are highly flexible in terms of descriptive metadata. A case can be made that they make persistence and interoperability practicable and affordable for cultural heritage institutions.
Below are more links that could be interesting to people who want to implement ARKs and IIIF.
References
Ben Brumfield, Sara Brumfield, Andy Irving, Rachael Kotarski, Joseph Padfield, Julien A. Raemy, Anne McLaughlin, & Frances Madden. (2021). PIDs in IIIF Webinar. Persistent Identifiers in IIIF. https://doi.org/10.5281/zenodo.5780055
Julien A. Raemy, & René Schneider. (2019). Suggested measures for deploying IIIF in Swiss cultural heritage institutions (White paper) (1.0). HES-SO University of Applied Sciences and Arts, Haute école de gestion de Genève. https://doi.org/10.5281/zenodo.2640416
2021 IIIF Conference presentation by Modou Dia (Pleade) – “Association of IIIF and ARK Protocols”: https://www.youtube.com/watch?v=oFlicS5f8HA
Durham University Library: https://www.durhampriory.ac.uk/about-the-project/technology/ark-urls/
French National Library (BnF): https://api.bnf.fr/api-iiif-de-recuperation-des-images-de-gallica (in French)
John Kunze, Julien A. Raemy, and Richard Higgins (Durham University Library) presented on the topic of ARK and IIIF at the IIIF Community Call on January 25, 2023 which was recorded.
Julien A. Raemy is an Assistant and PhD Candidate in Digital Humanities at the University of Basel, Switzerland. He works as well as Interoperability Specialist for DaSCH, the Swiss National Data and Service Center for the Humanities. He holds a MSc in Information Science from the Haute école de gestion de Genève (Geneva, Switzerland).
He is particularly interested in ways of improving the digital preservation, dissemination and interoperability of cultural heritage objects and their associated metadata through the application of Linked Open (Usable) Data. Julien A. Raemy also investigates digital practices from the perspective of Science and Technology Studies, especially through the lens of the Actor-Network Theory.
John Jung is a Senior Programmer/Analyst in the Digital Library Development Center at the University of Chicago. He provides infrastructure for digital library collections and builds web interfaces to help people search and browse cultural heritage materials in useful and satisfying ways. He has a lot of experience dealing with datasets and all of their idiosyncrasies, and he helps people set up workflows to extract data from legacy systems, and to query, transform and load it into new systems from relational to graph databases.
John has a Master of Design Methods degree from the Illinois Institute of Technology Institute of Design.
John Kunze is a pioneer in the theory and practice of digital libraries. With a background in computer science and mathematics, he wrote BSD Unix software tools that come pre-installed with Mac and Linux systems. He created the ARK identifier scheme, the N2T.net scheme-agnostic resolver, and contributed heavily to the first standards for URLs (RFC1736, RFC1625, RFC2056), for library search and retrieval (Z39.50), for archival transfer (BagIt - RFC8493), for web archiving (WARC), and for metadata (RFC2413, RFC2731, ANSI/NISO Z39.85). Follow-on work in metadata includes creation of the Dublin Kernel and yamz.net.
In your example the slashes between NAAN and the image ID are not encoded:
ARK+IIIF example 2 (image) https://e.g.org/iiif/ark:/{NAAN}/{imgID}/full/max/0/default.jpg
But the IIIF specification (https://iiif.io/api/image/3.0/#3-identifier, respectively https://iiif.io/api/image/3.0/#9-uri-encoding-and-decoding) mentions that “any slashes within the identifier part of the URI must be percent-encoded. Encoding is necessary only for the identifier because other components will not include special characters”. This is the the ARK example in the specs:
identifier=ark:/12025/654xz321 region=full size=max rotation=0 quality=default ark:%2F12025%2F654xz321/full/max/0/default
Do you have any thoughts on this?
Hello Roxana, great comment and good catch! We actually talked about this a couple of weeks ago with John and I am going to edit the post 🙂
Credit goes to my colleague who implemented IIIF with ARKs at the National Library of Luxembourg 🙂
I hate to say it, but as per Roxana’s comment you probably need to correct the first example that you give in this article too.
I.e.
> For example, this IIIF-compliant URI https://gallica.bnf.fr/iiif/ark:/12148/btv1b8449691v/f29/2131,4016,1467,948/full/0/default.jpg
Should become
> For example, this IIIF-compliant URI https://gallica.bnf.fr/iiif/ark:%2F12148%2Fbtv1b8449691v%2Ff29/2131,4016,1467,948/full/0/default.jpg
Personally, I find the URI-encoding of identifiers to be extremely irritating! I can see why it is necessary, but it really messes with the legibility of IIIF URLs, and in this case obfuscates the ARK itself.
Thank you Tristan, I’ve updated the post.