IIIF Introduction and Opportunities at Cornell

Editor's Notes

1. What is IIIF? Why is it needed? What can it enable? Where is it going? And how can we use it to improve the services we offer? Talk by Simeon Warner for the Cornell University Library, Visual Resources Working Group. Slides borrow heavily from previous talks by other IIIF participants, including Michael Appleby (Yale University), Robert Sanderson (Stanford University), Jon Stroop (Princeton University), Stuart Snydman (Stanford University), and Benjamin Albritton (Stanford University). Source slide decks include http://www.slideshare.net/jpstroop/iiif-specifications-overview , http://www.slideshare.net/azaroth42/iiif-linked-data, and see presentations from MCN 2014 https://www.youtube.com/watch?v=10nSAljOTCk
2. IIIF goals: unprecedented access, common APIs, culture of shared technologies
3. Why is IIIF needed? A motivating example
4. Story from Ben Albritton about biblioclast Otto Ege
5. Noted biblioclast Otto Ege owned a glossed bible, likely French 12th century
6. He broke up the manuscript in the 40s and 50s to include in one of his manuscript leaf portfolios, which were then sold throughout North America. In the intervening years, many leaves have appeared in collections, but many have also gone missing. We can identify 33 separate institutions owning pieces of this manuscript currently – but there are more institutions and individuals out there that have bits.
7. Current discovery and access situation involves many different institutional services – terrible
8. What does IIIF enable?
9. 18 leaves, not previously recognized as belonging to the Ege book until Albritton began working on them in late 2013
10. 16 institutions – each serving their own image
11. In a continuous scroll view
12. Provide placeholders and info about missing leaves
13. Two images – one from Kenyon College, the other from Ohio State University. Perhaps worth reiterating here that the source images are being copied about here, just the derivative image tiles necessary for display
14. Zoom to compare features from images provided by different institutions – to the detail of the letter
15. Create new interactive presentations that mix overview images, descriptions, page views, detail views etc.
16. Of course these facilities are not limited to manuscripts, one might bring together important sketches from a painter as a way to help understand the final work. In this case we imagine sketches for Constable’s “Stonehenge” which are held at different museums in London
17. Why is IIIF needed? Take two
18. A few statements many of us in the library community have made about our image and collection delivery environments – we are often locked into particular solution
19. Periodic upgrades are required, maintenance often hard to fund
20. Deep zoom is expected by users and they want it to work on their phone too
21. Need to be able to compare items in collection
22. ... and between collections
23. Users should be able to share/link to items, and specific regions
24. Embed in blogs and web pages
25. Users should be able to annotate
26. These are shared requirement so individual institutions should not have to re-invent these facilities
27. With these requirements in mind, let’s revisit the IIIF vision: Create a global framework by which image-based resources (images, books, maps, scrolls, manuscripts, musical scores, etc.) - from any participating institution can be delivered in a standard way - via any compatible image server - for display, manipulation and annotation in any application, - to any user on the Web, in any combination of elements.
28. IIF vision continued - with tens of millions of image-based resources - backed by a consortium of world-leading cultural heritage and research institutions - supported by a rich and growing suite of software tools - incorporating the best of current image delivery technology, and leveraging Web standards
29. Again: What is IIIF? (Now that we know what is needed)
30. Three things: 1.) APIs 2.) growing suite of compatible software 3.) community of adopters
31. The two APIs are: Image API and Presentation API
32. Three layer of compatible software: bottom up: image servers; image clients; image apps
33. Strong IIIF community: national libraries, research institutions, museums, aggregators, projects
34. And not to mention, our systems and website are like silos. Our image repositories web servers and asset management environments are configured as silos. Our front-end applications are one-offs. When moving from site to site, users have to relearn how to engage productively with images.
35. Without standard APIs we are doomed to have silos, applications tied to specific servers. This ties the hands of service providers because they can mix-and-match technologies, and also of users
36. Shared APIs make technologies interchangeable, giving us choices between different technologies in the different roles within our application stack
37. Allowing distributed access over standard APIs allows users to reuse and remix content, and supports an ecosystem of applications
38. The Image API provides just enough information (technical metadata) to allow clients to request derivative images for display. The image API defines URI syntax and packs all of the parameters into a clean path-based syntax. That said, having a tidy persistent URL for citations, annotations, web exhibitions, emailing, and other means of sharing can be quite useful.
39. The Image API specifies how servers must interpret image requests. Servers must apply each transformation from left to right, i.e. in the order specified by the API URI. Servers don’t necessarily have to support all operations and this is expressed in the technical metadata (e.g. rotation is not necessary for common zoom-pan viewers)
40. Presentation API: What it is: Metadata Labels and Values Ordering Arrangement of Images and Other Content Object Structure and Layout Including Links to the Image API Relationships to Related Resources Attribution and Licensing
41. Presentation API: What it is not! It is not another metadata format
42. Paging The API distinguishes between rtl, ltr, ttb, btt directionality There are also features for, e.g. indicating that a page should be skipped
43. Again, back in the Mirador viewer we can see how collections and manifests relate to each other.
44. Presentation API provides detail to interact with images of 3D works
45. Where is IIIF going?
46. IIIF Roadmap: Authorization / Authentication, Search within, Discovery of Manifest and Image Identifiers, CRUD
47. How can we use IIIF to improve the services we offer at Cornell University Library?
48. We can give better services for less effort by working with the IIIF infrastructure and tool suite. Three threads: Image access and viewers, Book readers, Flexible image re-use for commentary, discussion, exhibits
49. Modified version of IA page turner now supports IIIF
50. Significant enthusiasm for IIIF in the hydra community
51. A few pointers, thanks for listening