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.

 

The definitions of the terms MUST, MUST NOT, SHOULD, etc. used in this document can be found at https://tools.ietf.org/html/rfc2119

Step 1: Provide the IIIF Resource as EDM WebResource

 

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

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

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:

<ore:Aggregation rdf:about="[ … ]"> […] <edm:isShownBy rdf:resource="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1/full/full/0/native.jpg"/> […] </ore:Aggregation> […] <edm:WebResource rdf:about="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1/full/full/0/native.jpg"/> […]

 

Step 2: Flag the WebResource as IIIF-compliant 

 

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

Example:

<edm:WebResource rdf:about="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1/full/full/0/native.jpg"> <dcterms:isReferencedBy rdf:resource="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/manifest.json"/> <svcs:has_service rdf:resource="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1"/> </edm:WebResource> […] <svcs:Service rdf:about="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1"> […]

 

Step 3: Indicate a level of IIIF implementation

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:

<svcs:Service rdf:about="https://gallica.bnf.fr/iiif/ark:/12148/btv1b55001425m/f1"/> <dcterms:conformsTo rdf:resource="http://iiif.io/api/image"/> <doap:implements rdf:resource="http://iiif.io/api/image/2/level2.json"> </svcs:Service>

 

Step 4: 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: