International Image Interoperability Framework (IIIF): new possibilities for archivesThis article is based on a presentation held during the Conference: Interactive Archives: Digital Challenges & Collaborative Networks, 5th Croatian ICARUS Days & ICARUS Convention #23, Pula – Croatia, on 27 March 2019. It was published in Croatian in the magazine @rhivi, no. 7, 2020, pp. 6-8, see: https://hrcak.srce.hr/250448.
Introduction
Up till now the results of digitisation projects of cultural heritage institutions have been published on the internet in a variety of ways, using all kinds of image galleries and viewer applications. But all these different publication methods are not interoperable with one another, which makes it hard for researchers to use and re-use the collections from different institutions. The International Image Interoperability Framework (IIIF) offers a method to overcome this barrier by providing specifications which make it possible to create free downloadable open source tools to publish image collections in a standardised way. This article introduces the IIIF framework, which offers archival institutions opportunities to better facilitate their online audience.
Background
The IIIF framework is established and driven by a broad community of researchers, national and state libraries, museums, companies and image repositories, committed to providing access to high quality image resources. It is the result of researchers and institutions aligning and pursuing their wishes.
On the wish list of researchers was: being able to copy, download, save and share high quality images of objects or texts as offered by institutions; being able to compare different representations of the same object or text, regardless in which institution they are kept and published online; being able to annotate, transcribe, translate and share this information and being able to search within all this extra information. This matched perfectly with the desire of institutions to better facilitate their online audience: they wanted to have newer, faster image servers, via which they wanted to offer fast and deep zoom functionality; they also wanted to facilitate comparison of images of objects and texts, as well as easy annotation, citation and sharing and embedding of images.
The goals of the IIIF community as mentioned on its websitehttps://iiif.io. are:
- to give scholars an unprecedented level of uniform and rich access to image-based resources hosted around the world,
- to define a set of common application programming interfaces that support interoperability between image repositories,
- to develop, cultivate and document shared technologies, such as image servers and web clients, that provide a world-class user experience in viewing, comparing, manipulating and annotating images.
The IIIF framework
In order to pursue these goals the IIIF community has agreed upon and implemented two major specifications, around which open source tools have been created: the IIIF Image API, which enables a standardised way to access images (scans) stored on a IIIF-compliant image server, and the IIIF Presentation API, which enables standardised presentation of images (scans), including their metadata, stored on a IIIF-compliant image server via a IIIF-compliant or viewer.
The IIIF Image API is a web service to fetch an image or scan from a IIIF-compliant image server by using a standard HTTP or HTTPS request. Such a request can ask for the full image or scan, but can also ask for a specific part of an image or scan and can provide the result in a certain size, rotation, format, etc., all according to the specifications of the API on how to construct such a request or URI, which can be found on the IIIF websitehttps://iiif.io/api/image/2.1/.. The picture belowSource: http://ronallo.com/iiif-workshop-new. shows two of these requests and their results:
The URI at the top of the picture – where the part “www.example.org/image-service” stands for any IIIF image server location and the part “image-identifier” for the identifier of the requested image on that server – fetches the full image as shown in the upper right corner. The URI at the bottom of the picture shows a specified (125,15,120,140) part of that full image, in a certain size (pct:75), mirrored and rotated (!345) and in grey. The picture shows the different stages of this specification, but the result of the full URI will be the grey image at the lower right corner of the picture.
The IIIF Presentation API is a web service which provides information on the structure and layout of an image or scan and/or complex image-based digital objects in a standardised way, to enable different IIIF-compliant viewers to present and publish them. The specifications of this API can also be found on the IIIF websitehttps://iiif.io/api/presentation/2.1/..
The IIIF Image API request generates an info.json file and based on the specifications of the IIIF Image Presentation API a manifest.json file can be created, which should contain all information to enable a IIIF-compliant viewer to display the image or complex image-based digital object with all the advantages of the IIIF framework such as fast and deep zoom functionality and comparing, sharing, annotating, transcribing and translating images.
The manifest.json file has to have a specific structure. It has to contain descriptive metadata on the image or complex image-based digital object, information on the sequence in which multiple images per digital object should be represented and the images themselves represented on a canvas, to which annotations, transcriptions, etc. can be added, which will make a manifest.json file more complicated. The manifest.json files can be created manuallyThe Bodleian Library of the University of Oxford has created a manifest editor which supports the creation of manifests based on access to the info.json files on a IIIF image server: https://github.com/bodleian/iiif-manifest-editor (see also: https://training.iiif.io/europeana/bodliean-editor.html). or derived automatically out of a collection management system. They are usually stored on a manifest server, which can basically be any web server. So a IIIF implementation consists of a IIIF image server and a IIIF image viewer, which can be embedded in the website of an institution, and a manifest server in between. This setup and the communication between these components is shown in the picture belowSource: https://training.iiif.io/intro-to-iiif/SOFTWARE.html..
The IIIF tools
While any web server can be used as a manifest server, the two other components of a IIIF implementation, the image server and the client or viewer, to be embedded in a website, must be IIIF-compliant. Fortunately there are already a lot of these around and the IIIF website contains an overview of available image servers as well as image clients or viewershttps://iiif.io/apps-demos/..
The two most popular IIIF image viewers are Universal Viewer and Mirador, both developed as open source projects of which the code is available on Githubhttps://github.com/UniversalViewer/universalviewer and https://github.com/ProjectMirador/mirador.. These IIIF image viewers each have a demo websitehttps://universalviewer.io/ and https://projectmirador.org/. and that offers a great way to check the functionalities of these viewers and the possibilities of the IIIF framework. One of the main objectives of the IIIF framework is that it fosters the interoperability between collections of the same or different institutions. Institutions can support this not only by publishing images via IIIF-compliant image servers and viewers, but also by giving access to the manifest.json files, which enables researchers to compare images of different collections by simply copying the link to the manifest.json files into the IIIF image viewers. In the Universal Viewer demo site this can be done via the “View IIIF Manifest” option and in the Mirador viewer demo site this is facilitated via the option “Demo”, after which two image slots with self-portraits of the famous painter Vincent van Gogh are shown. By clicking on the “grid”-icon in the upper left part of each image slot and next on the option “replace object”, the next screen will offer the possibility to paste a link to a manifest.json file to replace the image.
An example of a website which has implemented IIIF and offers links to manifest.json files is Fragmentarium, the Digital Research Laboratory for Medieval Manuscript Fragmentshttps://fragmentarium.ms/.. Via its “Search and Browse”-functionalityhttps://fragmentarium.ms/search. it is possible to take a look at the manifest.json file of each manuscript fragment it gives access to and to copy and paste the link to these files into the demo websites of the IIIF image viewers. The picture below shows the result of this copy/paste method in the Mirador viewer demo of two manuscript fragments of Fragmentariumhttps://fragmentarium.ms/overview/F-tjs5 and https://fragmentarium.ms/overview/F-8tq5..
The IIIF community
As mentioned before, IIIF is supported by a large community of researchers and institutions all over the world. The IIIF website shows a long list of all participating institutionshttps://iiif.io/community/.. Currently this list contains the names of 120 aggregators, companies, libraries, museums, projects, research centers and universities, among which 54 are actively involved as a consortium member. Strangely enough no archival institutions are mentioned, although these could benefit a lot from embracing IIIF and thus please their online audience, among which traditionally are a lot of researchers.
IIIF and archives
Fortunately there are some initiatives to start implementing IIIF in the archives domain and the archives community has its own IIIF discussion group within the general IIIF discussion listhttps://groups.google.com/forum/#!forum/iiif-discuss..
The standard for providing online access to information on archival material is EAD/XMLhttp://www.loc.gov/ead/., based on ICA’s ISAD(G)https://www.ica.org/resource/isadg-general-international-standard-archival-description-second-edition/., the standard on how to describe archival material. The EAD/XML finding aids are often linked to digital objects or scans, either via the (internal) EAD element <dao/> or via links to (external) METShttp://www.loc.gov/standards/mets/. files. There are initiatives to combine this information (EAD/XML + <dao/> or METS) to create IIIF manifests. An example is the work on the Digital Archival Navigation Application (DANA) from the Getty Research Institute. Getty’s Alyx Rossetti’s presentation on the principles behind this are available on Slidesharehttps://www.slideshare.net/AlyxRossetti/ead-mets-iiif-representing-digitized-and-nondigitized-archival-content-for-the-getty-research-institutes-digital-archival-navigation-application-prototype.. Another example is the work of Ethan Gruber of the American Numismatic Society on his EADitor, an Xforms based EAD creator/editor, which supports IIIF. The picture below shows the Mirador viewer embedded into the HTML representation of an EAD/XML finding aid, showing a page of a notebook kept in the archive of the coin collector Edward T. Newellhttp://numismatics.org/archives/id/nnan187715..
In addition to this some university archives and libraries in the United States, such as the ones from Princeton, Stanford and Yale, are implementing IIIF in combination with EAD/XML at the moment. A nice example of this is shown in the picture below, an advertising poster kept in the archive of the American publicist Ivy Ledbetter Lee, embedded in the HTML representation of the EAD/XML finding aid describing his papershttps://findingaids.princeton.edu/collections/MC085/c01078..
So institutions keeping archival collections have started to implement IIIF in combination with EAD/XML and in my experience they are eager to share their knowledge about this via the IIIF community channels. Hopefully archival institutions around the world will see the benefit of implementing IIIF, not only for themselves, because most IIIF tools are open source and freely available, but also for their online audience, which will be pleased with a standardised and rich IIIF tooling.
Finally I have one more compelling argument for archival institutions, especially in Europe, to start implementing IIIF: it offers them the possibility to showcase their content in the cross domain portal Europeanahttps://www.europeana.eu/. in a better way. Europeana is more and more focusing on quality of content rather than on quantity and as a result of that it is restricting content aggregation according to its Publishing Framework guidelineshttps://pro.europeana.eu/post/publishing-framework.. One of the principles of these guidelines is to ask aggregators and content providers to always provide direct access to digital objects in order to foster re-use. Current practice among archival institutions is to provide links to digital objects embedded in image galleries, which makes archival content less interesting for Europeana. The implementation of IIIF could overcome this barrier and could rank archival digital objects in higher tiers of the Europeana Publishing Framework.