Introduction

Day Outline

  • Introductions
  • Introduction to IIIF
  • Break
  • Image API
  • Lunch
  • Presentation API and IIIF Manifests
  • Annotations with IIIF
  • Questions

Workshop Collaborative Notes Files: https://docs.google.com/document/d/1xy8tkK9D7Zwl_QX4HL044V2IvDemV_7z6Dugi2yK3xI/edit

What is IIIF? A bird's eye view

The Problem

image

  1. Massive technological redundancy

  2. Un-sustainability

  3. Prevents connectivity, leading to data redundancy

The Solution Enter IIIF

image

Two Types of Image Related Data

  1. Image metadata
  2. Image presentation data

The IIIF Image API (Image Metadata)

The IIIF Image API is a "rule book" coordinating the description of image metadata and how to request it.

Consumers will want to request...

  • The entire image
  • A thumbnail of the image
  • Part of the image
  • A low quality version of the image
  • etc.

Consumers will want to know...

  • How big the image is
  • Which image sizes are pre-cached
  • Which image formats are available
  • What are the rights associated with the images
  • etc.

There are lots of ways this information could be communicated.

The IIIF Image API describes a standard so that we can coordinate our efforts and gain the benefits of that coordination.

The IIIF Image API "standard" can be consulted here

There are two main things that the IIIF Image API rules govern.

  1. URI syntax for REQUESTING images and image information.
  • {scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}
  • For example:
    • http://www.example.org/image-service/abcd1234/full/full/0/default.jpg
  • {scheme}://{server}{/prefix}/{identifier}/info.json
  • For example: http://www.example.org/image-service/abcd1234/info.json
  1. The proper RESPONSE for an image INFORMATION request in an info.json file

Example of a complete info.json response

Important: A IIIF Image Server does not identify a specific piece of software.

A IIIF Image Server is any software that serves/delivers images while following the above rules.

Therefore, there are lots of IIIF Image Servers. For example:

  • Loris written in Python.
  • IIPImage Server high performance image server.
  • riiif written in Ruby as a Rails engine.
  • SIPI IIIFv2 image server written in C++.
  • RAIS 100% open source tile server for JP2 images written in Go.
  • digilib image server written in Java.
  • Cantaloupe - image server written in Java.
  • iiif_s3 Ruby library for generating a static IIIF level 0 Image and Presentation API server on Amazon S3.
  • Hymir IIIF Server IIIF server written in Java supporting IIIF Image and Presentation API.
  • go-iiif IIIF server written in go (fork of greut/iiif).

See https://github.com/IIIF/awesome-iiif/blob/master/readme.md

If we start to imagine how an image viewing application might use this information, we can illustrate it as follows:

https://iiif-2-day-workshop.netlify.com/img/Deep%20zoom.jpg

The above image shows a viewer using the info.json file to learn what "tile" sizes have been pre-cached by the server, what size thumbnail has been pre-cached, etc. And it has used the URI syntax parameters to request different sizes of the image.

The IIIF Presentation API (Image Presentation Data)

We can illustrate the need for a second API, for image presentation data, by filling out the rest of the imagined viewer.

https://iiif-2-day-workshop.netlify.com/img/Image%20and%20Pres%20API.jpg

The above image, in blue, shows the kinds of information a viewer might need to create a useful viewing experience.

Image Viewers will want presentation information, such as ...

  • Titles for a sequence of images
  • Logos of an institution
  • Image order
  • Several versions of an image
  • etc.

Once more, we need a rule book to coordinate our description of this information.

Enter the IIIF Presentation API

The most basic concept of the presentation API is the manfest.json

like the info.json the manifest contains image presentation data described according to the rules of the IIIF Presentation API.

And once more a IIIF Image Viewer does not indicate a specific piece of software.

Any software that displays images from a IIIF server alongside presentation data contained in a manifest.json file can be considered a IIIF Image Viewer.

There are lots and you can build your own.

Other IIIF APIs

The Community

50 Consortium members can be seen here

355+ million images

image

Community Groups

  • Manuscripts
  • Museums
  • Newspapers
  • Outreach
  • Text Granularity
  • 3D

Technical Specification Groups

  • A/V
  • Discovery
  • Software Developers

Nota Bene

Content adapted from, re-used, changed, modified similar content produced by the IIIF Community, especially: Jack Reed https://iiif-2-day-workshop.netlify.com/docs/day-one/welcome.html Jason Ronallo https://github.com/IIIF/training/blob/master/intro-to-iiif/SUMMARY.md Jeffrey C. Witt, Jack Reed, Drew Winget, and Rachel Di Cresce https://github.com/IIIF/training/tree/master/iiif-5-day-workshop

IIIF and Digital Editions

The Aspiration for Completeness and Transparency

The technology of the printed book fundamentally permits many things. This makes the homogeneity and regularity of the critical edition, beyond experimental exception cases, all the more remarkable. Today's ideal type of the existing and learned edition is in many ways a product of its technical surroundings. But is also more than anything else mediated through the centuries-long developed media program of the printed book. Accordingly, the scientifically defined goals of the edition are partially sacrificed to the demands of book culture. The 'aim of transparency' as well as the foundational idea, that the tradition must be re-constructible from the edition, would have indeed been technically realizable. By itself the media program of the book culture prioritized the 'usability', the 'affordability', the 'text normality', the 'clarity', the 'simple usability' ahead of the aspiration for completeness, ahead of the corresponding transparency, and ahead of the historicity of the actual tradition recognizing the additional layers of presentation. The uses of images of original manuscripts is a critical component in this effort.

Die Technologie des Buchdrucks erlaubt grundsätzlich vieles. Umso bemer- kenswerter ist die Homogenität und Regelmäßigkeit der kritischen Editionen jenseits der experimentellen Ausnahmefälle. Der heute bestehende und lehrend vermittelte Idealtyp der Edition ist zu weiten Teilen ein Produkt ihrer technischen Umgebung. Sie ist es aber auch und vor allem mittelbar durch das über Jahrhun- derte entwickelte mediale Programm des gedruckten Buches.11 Dabei werden den Vorgaben der Druckkultur die wissenschaftstheoretisch definierten Ziele der Edi- tion teilweise geopfert. Das ,Transparenzgebot‘12 wie auch die Grundidee, dass die Überlieferung aus der Edition rekonstruierbar sein müsste, wären rein technisch im Buchdruck durchaus realisierbar gewesen. Allein das mediale Programm der Buchkultur setzt die ,Handlichkeit‘, die ,Bezahlbarkeit‘, die ,Textnormierung‘, die ,Eindeutigkeit‘, die ,einfache Benutzbarkeit‘ vor den Vollständigkeitsanspruch, vor eine konsequente Transparenz und vor zusätzliche, die Historizität der tat- sächlichen Überlieferung würdigende Präsentationsschichten.

(Patrick Sahle, Zwischen Mediengebundenheit und Transmedialisierung (editio 24, 2010) p. 25-26

Images have an important role to play in the achievement of transparency and completeness.

But there are problems:

  1. The manuscripts for a given a text are scattered across the globe.
  2. Institutional image data publication is often varied and idiosyncratic.

Enter IIIF.

As more and more institutions adopt the IIIF standard, the dream of transparency is becoming more and more realizable.

Examples

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-leipzig-comparison.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-lbp-leipzig-1.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-lbp-leipzig-2.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/lbp-api-p-image-display.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/lbp-api-collation-display.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/lbp-with-app.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/mirador_same_spot_4_witnesses.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/mirador_same_spot_with_annotations.png

The Aspiration for Scholarly Collaboration over Competition

In the process of creating an edition we are creating lots and lots of auxiliary data highly relevant to image data.

Without a way to share this auxiliary data, it gets re-created.

This redundancy is wasteful.

Rather than collaborating by always building on top of the work that has already been done, scholars are competing to make redundant data.

We need to allow multiple users to work with a common image resources.

IIIF can help make this possible.

Scholars can create auxiliary data and associate it with IIIF image/canvas resources, and then publish that data. Subsequently, an image viewer can retrieve that related data and display it alongside the target resource.

Examples:

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-ldn-leipzig-fragmentarium.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-ldn-leipzig-announcement.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-ldn-leipzig-oldtoc.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-ldn-leipzigms.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-ldn-leipzig-newtoc.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-ldn-leipzigms.png

https://s3.amazonaws.com/lum-faculty-jcwitt-public/iiif-ldn-leipzig-transcriptions2.png

IIIF Image Api →