Report from IIIF-ification hackathon

[Ben Brumfield]

Fellow RootsDev-er Doug Blank and I just participated in a hackathon in Philadelphia devoted to making more image content on the web available in the IIIF protocol (see http://iiif.io/ ), and I wanted to give a short report to the RootsDev community.

What's IIIF?

IIIF is a suite of related standards for presenting images over the web, describing them, and annotating them.  It's divided into three standards:

Image API. 
This is a standard URL scheme for retrieving images in different sizes, rotations,and formats, as well as for selecting regions for an image.  (See http://iiif.io/#try-it for an example, or go deep in the standard at http://iiif.io/api/image/2.0/ .)

Presentation API.

I'm not fond of the name, but the Presentation API is a way of creating IIIF "manifests" in JSON-LD describing metadata about images: e.g. by specifying the title of a book as an 'object', and a sequence of pages (in order) with their page numbers, image URLs, thumbnail URLs, etc. 

Each page is described as a Canvas which can have one or more images on it. In addition, non-image data described in the Open Annotation/Shared Canvas format can be placed on the canvas to associate transcripts or other Linked Data resources.  Importantly, it's a machine-readable way of describing an online book, newspaper issue, letter, or other document.
http://iiif.io/api/presentation/2.0/

Shared Canvas/Open Annotation

I haven't explored this very deeply, but Shared Canvas is a standard for associating Linked Open Data with a page, photograph, or other visual document described in an IIIF manifest.  I was able to use this to export page transcripts from FromThePage into Mirador, but am still quite a newbie to linked data.  The standard is here: http://iiif.io/model/shared-canvas/1.0/index.html

What did we do at the hackathon?

Shims

The hackathon was devoted to making more online content available via IIIF.   Part of that work was focused on developing 'shims' -- small web-apps that are familiar with the way a particular tool (like ContentDM, Omeka, Flickr, or the Internet Archive) serves images and image set metadata, and act as proxies for IIIF requests.  Installing one of these shims and configuring it to point at a non-IIIF target means that any IIIF-compliant client can connect to the shim and retrieve images from it (albeit often through redirects).

Native Servers

One project worked on building a Ruby-only IIIF server for images, and made a lot of progress.  I was able to use 'riiif' (a Rails engine that implements the Image API via ImageMagick) to provide IIIF access to documents uploaded to FromThePage, and 'osullivan' (a Ruby library for constructing Presentation manifests) to to expose those documents and their transcripts (with Doug's not-inconsiderable help).  Parallel libraries exist for Python.

By the end of the three days, we were able to point the Mirador page turner/viewer tool ( http://projectmirador.org/ ) at services for NYPL, Flickr, FromThePage, and Omeka and ingest and view images within that client.  Very slick.

Client-server Integration

One project coupled the Mirador page-turner/zoomer/annotation application (the main IIIF client we had available at the hackathon) with a server with a well-defined icon, allowing any IIIF-supporting application to present an icon on a web page which, when dragged onto Mirador, would import the document into the Mirador viewer.

Implications for Genealogy Technology

Record Databases

IIIF presents an interesting opportunity to de-couple a repository which contains scanned pages from a database which encodes the data within those documents.  For example, Brooke could post her images on an IIIF-compliant server, then someone else could create a database of those records.  Those records could deep-link link directly to the regions on the pages which contained the record of interest.  Furthermore, since the Shared Canvas/Open Annotation model supports creating JSON representations of records as annotations on a region, the record database could export its own encoding of those records in JSON-LD as annotations on the images hosted on the repository.  A client (say a family tree tool) could ingest only those records of interest to a researcher and simultaneously ingest the images from which they were transcribed, even though the record database and image repository were unaffiliated.

Similarly, a transcription/indexing/encoding tool used to create a record database could present documents to a transcriber from any IIIF-compliant repository in the world, without having to ingest and serve the images itself, nor having to negotiate a separate licensing agreement with the image repository.  (Computer-readable licensing are part of the IIIF presentation API/) 

Family History

As in record databases, the potential for sharing through IIIF is really interesting.  Three weeks ago, I added an IIIF client to FromThePage as a proof-of-concept. This client would allow a researcher to start a transcription and indexing project on, say, three family letters held at one library supporting IIIF and one diary held at a different repository, as well as whatever documents they uploaded to FromThePage to be hosted natively.  This would allow them to edit and display documents from heterogeneous sources in a seamless manner.

At the IIIF hackathon, I (with Doug's help) added IIIF server support to FromThePage, which means that documents photographed by family historians from their own collections and uploaded to that site could (if public) appear alongside documents from the world's leading libraries.  Most family historians may not care much about this sharing aspect with the documents they possess themselves, but other genealogy researchers searching public repositories may be very grateful indeed to find the "shoebox archives" which mention their own ancestors accessible as a side-effect of those original family historians' uploads.

Tree Tools

I don't know enough about tree tools to speak competently here, but maybe Doug can pitch in with his observations.  It certainly seems like the IIIF support for documents, images, and regions can only help evidence-based genealogy technology.

Conclusion

A hackathon is a brief event, and while I walked away with running code, I probably missed a lot from the discussions and the other teams' activities.  I encourage any developer or institution interested in image and image-based-data interoperability to get involved with IIIF.  The IIIF community calls are open to anyone, as is the iiif-discuss Google Group.  Although the core participants are developers from R1 libraries in the US and Europe, I found them to be very interested in outreach among different domains and communities, and surprisingly patient with newbie questions to boot.  The needs of genealogy developers vary substantially, but I feel like this standard answers the desire of at least some of our communities very well indeed.

I'll be happy to attempt to answer questions based on my experience, though I suspect that anything detailed may exceed my knowledge.

Ben

[Brooke Ganz]

I don't have any questions right now, but I just wanted to say that this is very cool and thanks for typing it all up for us!

- Brooke

[todd.d....@gmail.com]

I'll echo Brooke here: thank you!

I've been following IIIF for a while now and it's exciting to see the energy exploding.

On Mon, Oct 5, 2015 at 5:01 PM, Brooke Ganz <aspar...@gmail.com> wrote:

I don't have any questions right now, but I just wanted to say that this is very cool and thanks for typing it all up for us!

- Brooke

--

---
You received this message because you are subscribed to the Google Groups "rootsdev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rootsdev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tod Robbins

Digital Asset Manager, MLIS

todrobbins.com | @todrobbins