Images and the promise of ARKs with IIIF

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?

IIIF Logo

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.

A rectangular detail region of interest (coordinates 2131,4016,1467,948) requested via IIIF-compliant path elements (parameters) from a manuscript held at the BnF.

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. 

ARKhttps://{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
The ARK Anatomy and the IIIF URI Syntax Recommendations

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.
Website | + posts

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.

Senior Programmer/Analyst at The University of Chicago Library | Website | + posts

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.

ARK Alliance | Website | + posts

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.

  1. 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?

      1. Credit goes to my colleague who implemented IIIF with ARKs at the National Library of Luxembourg 🙂

  2. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.