EuropeanaTech Conference 15 & 16 May 2018, Rotterdam, the Netherlands

1. IIIF Discovery Technical
Specification Group
Work so far
Matthew McGrattan, Digirati (Head of Digital Library Solutions) & Co‐
Chair of the IIIF Discovery TSG

2. A Community
that develops Shared APIs,
implements them in Software,
and exposes interoperable Content

3. Some IIIF History
• IIIF first meeting: Cambridge, 2011.
• Why?
• Every digitisation and digital content delivery project had been done
differently.
• Software was rarely reusable.
• Content was silo’d and unavailable outside of its own specific
environment.
• Developing new platforms for content was expensive.
• Maintaining them once built was even more expensive.

4. Can we make interoperable standards
for this?
• APIs:
• IIIF Image API: how can I get pixels?
• IIIF Presentation API: how can I describe digital objects?
• So that I can create a viewing experience that presents that
content to a user?
• Further APIs:
• IIIF Authentication API: and how can I control what users can see
and do?
• IIIF Content Search: how can I search within a digital object, when
I’m viewing it? (like PDF search)

5. IIIF as a Community (1)
IIIF Consortium (IIIF‐C):
• IIIF‐C Executive:
• High level direction, budgeting, hiring and management of
permanent staff, etc.
• IIIF Coordinating Committee:
• Week‐to‐week orchestration of the community, establishes working
groups and specification activities, etc.
• IIIF Editors:
• Custodians of the IIIF technical specifications, and responsible for
use‐case driven best practice around interoperability.

6. IIIF as a Community (2)
• IIIF Technical Specification Groups (generally time‐bound)
• Discovery
• A/V
• Text Granularity
• IIIF Community Groups (long‐running)
• Newspapers
• Manuscripts
• Museums
• 3D
• Software Developers
• Outreach

7. Background (IIIF Discovery)
• 100s of 1000s of IIIF resources
• Commodity search engines know nothing about IIIF
• The ‘silo ‘problem that was an inspiration for the creation of IIIF
returns:
• Each institution that exposes IIIF content has a different discovery
interface
• With a different search API
• Users want to find content across collections, not just within a silo
• Having found content they want consistent ways to get that
content into the viewing environment or tool(s) they want to use
• IIIF Content Search API is not designed for searching across items
or collections.

8. IIIF Discovery Technical Specification Group
Chairs:
• Antoine Isaac (Europeana)
• Matt McGrattan (Digirati)
• Robert Sanderson (The J. Paul Getty Trust)
Communication Channels:
• Calls very other week on Wednesdays at 1:00pm Eastern (opposite the general IIIF Community
Call) ‐ see IIIF Community Calendarfor details
• Virtual meetings announced on the IIIF‐Discuss email list
• General discussion on the # discovery IIIF Slack channel (Join Slack)
Call Notes and Group Documents:
• IIIF Discovery Tech Spec Group folder
Call Connection Information:
• Online: https://stanford.zoom.us/j/829945399
• Phone: see international numbers ‐ Enter Meeting ID: 829945399, Participant ID: #

9. IIIF Discovery: Charter
• http://bit.ly/iiifdiscoverycharter
Defines the work of the TSG, and the timeline for that work.
• Four key areas:
• Crawling and Harvesting
• How can I know what IIIF resources are out there?
• Content Indexing
• How can I retrieve machine‐readable metadata about those IIIF resources?
• Change Notification
• How do I know when resources change?
• Import to viewers
• How do I get IIIF resources from their context of discovery into the viewing
environment of my choice?

10. Use Cases
• Starting with the Vatican conference, Summer 2017:
• Gather and document use cases around search
• Identify common requirements and patterns of use
• Identify which requirements are likely to be met by the IIIF
Discovery TSG’s process (based on the charter) and which are
out of scope in the current phase of work.
• Begin to scope and write specifications for:
• Crawling and Harvesting
• Import to IIIF Viewers

11. Crawling and Harvesting: A
Deliverables:
• Specification of how content providers publish lists of
resources for discovery by the IIIF community
• Recommendations for how consuming applications process
those lists
• Validation service that checks the lists are correctly
generated
• Registry of institutions’ lists
• Reference implementations of both producer and consumer
applications

12. Crawling and Harvesting: B
Deliverables:
• Specification of how content providers publish lists of
resources for discovery by commodity search engines like
Google or Bing.
Recognition that IIIF‐centric specifications may not work for
commodity search engines and solutions that work for
commodity search engines may not be suitable for the specific
use cases of the IIIF community.

13. Content Indexing
IIIF Presentation API provides information to support presentation only.
But... provides facilities for linking to external descriptions of the objects
(in machine‐readable standard metadata formats).
• What common metadata formats do IIIF communities use?
• How should someone publishing metadata linked to a IIIF Presentation
API manifest reference those formats?
Deliverables:
• Recommendations for profile identifiers and formats, following existing
practice.

14. Change Notification
How can consumers of lists of IIIF content be updated about
changes to that content?
Deliverables:
• Specification for notification interactions
• Reference implementations for notification generators and
consumers
• Validation service for notifications
• If necessary, a central hub for distribution of notifications

15. Import to Viewers
• http://bit.ly/import2viewers
To enable users to work with the content once it has been
discovered, how can content providers and discovery applications
help users import IIF content into external viewing or processing
systems?
Deliverables:
• Specification of content reference import
• Recommendations around consistent UI/UX patterns
• Validation service for the import process
• Reference implementations for generators and consumers

16. Approach / Philosophy
• The Discovery TSG tries to stay agnostic about which
metadata formats are the ‘best’ formats.
• Does not mandate a single data model.
• Instead:
• Provide a standard way of publishing resources.
• Provide a standard way (via existing IIIF Presentation API properties)
of conveying how and in what form machine‐readable metadata is
available.
• Facilitate the growth of new search and discovery tools using these
methods.

17. Centralisation?
• This approach is compatible with a centralising approach:
• Aggregators like Europeana can use this tooling to gather and index
collections from IIIF content publishers.
• The IIIF may maintain a ‘master registry’ of IIIF Discovery endpoints.
• But also with a decentralised approach.
• A particular community of scholars, or even an individual, might
decide to publish their content using just the metadata profile that
is right for their use.
• Use this to build a specialist/specific discovery environment and a
community of practice around discovery for a specific domain.

18. IIIF Change Discovery API 0.1
• Intended Use:
• IIIF aware systems that can leverage IIIF APIs.
• N.B. not, in this specification, commodity search engines like Google
or Bing.
• Documents a consistent, well understood pattern for content
providers to publish lists of content.
• Enrich those lists with information about when content has
changed.
• Not in scope (for this specification): metadata formats.

19. IIIF Change Discovery (the Basics)
• Uses the W3C Activity Streams specification to describe and
serialise changes to resources.
• Semantics of those changes, and patterns of publishing and
consumption, based on those identified by ResourceSync.
• Changes are primarily the creation, modification and deletion
of IIIF Presentation API resources (Collections / Manifests)
• Specifies multiple levels of conformance. All are potentially
deliverable via only static files.

20. Why this approach?
• Paging model already part of the IIIF Presentation API
specification.
• JSON‐LD (as is already the case with IIIF Presentation and
Image APIs)
• Lightweight and easy to implement
• Potentially via just static files.

21. IIIF Change Discovery: Level 0
• Fundamentally, a list of links to IIIF Resources wrapped in an
“Update” Activity Wrapper.
{
"type": "Update",
"object": {
"id": "https://example.org/iiif/1/manifest",
"type": "Manifest"
}
}

22. IIIF Change Discovery: Level 1
• As level 0, but with added time stamps, with lists of multiple
items ordered with most recent first.
{
"type": "Update",
"object": {
"id": "https://example.org/iiif/1/manifest",
"type": "Manifest" },
"endTime": "2017-09-20T00:00:00Z”
}

23. IIIF Change Discovery: Level 2
• As level 1, but complete change lists, with multiple activities
per resource. Create, Delete, Update, etc.
{
"type": "Create",
"object": {
"id": "https://example.org/iiif/1/manifest",
"type": "Manifest" },
"endTime": "2017-09-20T00:00:00Z”
}

24. IIIF Change Discovery: Activities
• Identifier
• Type: Create, Update, Delete
• Object: the IIIF resource affected by the Activity
• endTime
• startTime (optional)
• Summary (textual summary, optional)
• Actor (who/what carried out the activity, optional)

25. IIIF Change Discovery: Paging
• Lists of items provided as pages, and as Collections of Pages with URIs for the
first and last page.
{
"@context": [ "http://iiif.io/api/discovery/0/context.json",
"https://www.w3.org/ns/activitystreams"],
"id": "https://example.org/activity/all-changes",
"type": "OrderedCollection",
"totalItems": 21456,
"first": {
"id": "https://example.org/activity/page-0",
"type": "OrderedCollectionPage" },
"last": {
"id": "https://example.org/activity/page-214",
"type": "OrderedCollectionPage" }
}

26. IIIF Change Discovery: Paging
• Follows the Activity Streams paging model.
•Ordered Collection
•Ordered Collection Page
• OrderedItems
• Activities

27. IIIF Change Discovery: Harvesting
• The Change Discovery API specification also describes an
algorithm for consuming IIIF resources that have been
published via the Change Discovery API specification.
• Implementation:
• Nuno Friere (Europeana)
• Github: https://github.com/nfreire/iiif‐discovery‐crawling
• Jeff Mixter (OCLC)
• Github: https://github.com/mixterj/activity_streams_harvest

28. Implementations (Publishing)
• Matt McGrattan (Digirati)
• Example: https://mcgrattan.org/as/
• Github: https://github.com/mattmcgrattan/iiif‐activity‐streams
• Jason Ronallo (NCSU)
• Example: https://scrc.lib.ncsu.edu/sal_staging/iiif‐discovery.json
• Jeff Mixter (OCLC):
• Example: http://52.204.112.237:3051/activity‐streams
• Github: https://github.com/mixterj/iiif_activity_streams_creation

29. Next Steps
• More implementations of the Change Notification APIs and
feedback from users/developers
• Begin work on Content Indexing
• Continue work on Import to Viewers
• IIIF Discovery Workshop hosted by Stanford in June.