IIIF in EDM pattern

The International Image Interoperability Framework (IIIF) is a standard for serving and consuming high quality images online, with the ability to instruct a server about the desired resolution, or image manipulations such as rotation and zooming and it enables institutions in the cultural heritage sector to share better quality digital content.

Discussions with partners in the IIIF community have lead us to identify a pattern that Europeana providers can use to submit IIIF resources from their own services in a simple way, using a small extension to the WebResource element from the Europeana Data Model. The first draft recommendations were published in the deliverable D4.4 Recommendations for enhancing EDM to represent digital content as part of the Europeana Cloud project.

In EDM, IIIF resources showing as cultural object are represented as instances of the class edm:WebResource.

This guide explains how providers can include suitable descriptions for these IIIF WebResources in the EDM metadata they send to Europeana. We include a formal definition of the new EDM elements used to submit IIIF resources according to the pattern explained here.

Step 1: Providers MUST identify the type of link between the IIIF resource for the object and the object.

EDM uses the general property edm:hasView to link an ore:Aggregation about a provided cultural object to the "views" of this object on the web. In the case of IIIF resources, the suitable property SHOULD be

• edm:isShownBy

• edm:object OR edm:hasView (if there is already an edm:isShownBy present).

See the EDM Definitions and EDM Mapping Guidelines for more information on the semantics of these properties.

Step 2: Providers SHOULD supply an identifier for the WebResource referenced as a 'view' of the object.

EDM doesn't strictly require that the WebResource for a IIIF 'view' have a specific identifier. In a pure RDF context it could in fact be left without any identifier.

A IIIF viewer can generate views from the information supplied in the following steps. However, a non-IIIF viewer will not be able to do this.

For wider consumption of IIIF resources by Europeana data re-users, we recommend that providers SHOULD supply URIs for the IIIF 'view', that can be consumed by any traditional web client. The most natural way to do this is to use URLs that employ appropriate IIIF parameters on the base IIIF service so that clients obtain a good image, as in https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1/full/full/0/native.jpg

The URI for the WebResource MUST be the one of the media view and MUST NOT be the one of a IIIF manifests. Manifests are metadata files and not (media) views for a cultural object. The manifest resource represents a single object and any intellectual work or works embodied within that object http://iiif.io/api/presentation/2.0/#manifest.

Example:

Step 3: Providers MUST flag the WebResource as a IIIF-compliant resource

This is done by connecting the WebResource to a resource of type svcs:Service using svcs:has_service and by indicating that the WebService conforms to (dcterms:conformsTo) the IIIF profile. The value of dcterms:conformsTo MUST be the URI http://iiif.io/api/image

Step 4: The identifier of the Service MUST be the 'base URI' of the IIIF resource.

See the IIIF specifications for the definition of the base URI: https://iiif.io/api/image/2.0/#uri-syntax

Example:

Step 5: The provider MAY indicate a level of IIIF implementation.

A IIIF Manifest allow a IIIF viewer to render the image in a relevant setting. The 'base' WebResource from steps 1 and 2 can be connected to a manifest URI using the property dcterms:isReferencedBy.

The definition of a IIIF “protocol”, for example http://iiif.io/api/image/2/level1.json, can be added with a doap:implements as this property corresponds to the “protocol” element in the IIIF JSON context. However, Europeana itself will not exploit it now. But data re-users with specific needs might benefit from the availability of this information.

Example:

Step 6: The provider MAY provide access to a IIIF Manifest

Optional: provide access to a IIIF manifest using dcterms:isReferencedBy.

Manifests are highly nested JSON documents that indicate what is the preferred way to render the IIIF resources. They can give information on how images are related to each other like the order that images should display, the structure of a document like a table of contents, and descriptive information for the resource and individual images.

The 'base' WebResource from steps 1 and 2 can be connected to a manifest URI using the property dcterms:isReferencedBy.

Specifications of the WebService URI (<svcs:has_service rdf:resource="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1"/>) should follow the recommendation made at

http://iiif.io/api/image/2.0/#uri-syntax: