Case study

Background: the emergence of IIIF

Our cloud services architecture was originally developed to serve the Wellcome Collection’s asset delivery requirements, at the largest scale, while being open for others to use to host smaller scale collections.

We started working with Wellcome Collection to build their Digital Delivery System (DDS) at the end of 2011. When it first launched a year later, the on-premise platform delivered digital objects and deep zoom images to the public. At the back end it integrated with Goobi for digitisation workflow, and Preservica for digital preservation. This was pre-IIIF; in those days, deep zoom images were served using the older DZI format and digital objects were represented by a bespoke JSON format, viewed in the Wellcome Player.

When IIIF came along we adapted Wellcome Collection’s DDS to provide IIIF Presentation API Manifests and IIIF Image Services, replacing the bespoke formats. We also helped develop the IIIF Search and Authentication APIs and ported their existing search and access control integration over to IIIF. The Wellcome Player evolved into the Universal Viewer (UV), and this combination of DDS and UV powered the Wellcome Collection’s digital presence.

From DDS to DLCS

In 2016, with Wellcome Collection digitising up to a million new images a month, we changed the architecture - the on-premise DDS continued to integrate with Goobi and Preservica, but asset delivery was moved to a new platform in the cloud. By providing a standard, IIIF allowed a clean separation of concerns; this new Digital Library Cloud Services (DLCS) platform could provide IIIF Image API services for any image, or transcoded derivatives for any AV resources registered with it. It also hosted born digital formats, could enforce content-advisory or clickthrough access control, as well as deeper authentication integrations, all via the IIIF Authentication API.

The DLCS was designed for integration right from the start - we began by designing a public REST API that met Wellcome Collection’s integration needs, but also catered for other delivery and integration scenarios we encountered across the cultural heritage sector.

Thus asset delivery was decoupled from the Wellcome-specific parts of the overall platform. This approach has proved invaluable as in the years since, Wellcome’s digital preservation, storage and public engagement aspects have changed dramatically while the DLCS has continued to provide standardised IIIF asset delivery, now for over 50 million assets.

This same DLCS API and cloud architecture is now available as IIIF Cloud Services, for anyone to use - whether as an individual using our portal user interface to host a small amount of content, or as an institution like UAL, for example, who use the DLCS as part of an integrated IIIF platform.

A high level view of IIIF Cloud Services at Wellcome Collection today

• Digitised and born digital objects are deposited in Wellcome Collection’s storage service by Goobi and Archivematica workflows
• The iiif-builder process reads BagIt bags for the digital objects and:
  • Reads corresponding descriptive metadata from the Catalogue API
  • Builds IIIF Manifests and Collections to represent the digital objects
  • Registers the asset origins with the Cloud Services API (origins are URIs where the bagged, archived image/AV/file can be found)
• IIIF Cloud Services at registration time:
  • Checks the asset at origin
  • Creates configured thumbnails for asset
  • Transcodes AV to configured output formats
  • Registers any required roles a user must have to see the asset
• IIIF Cloud Services at runtime:
  • Acts as an IIIF Image Server for image assets
  • Serves AV derivatives
  • Delegates to any configured role provider to establish user permissions, if content requires it
  • Enforces content-advisory or clickthrough access restrictions, where content requires it

* While the IIIF Cloud Services platform can also produce IIIF Manifests from querying assets, this approach is only used for previewing at Wellcome Collection; the public Manifests are generated by iiif-builder.