View Source

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

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

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

Note that in version 2.1 of the IIIF image API (http://iiif.io/api/image/2.1/ ), the parameter “max”: will replace the “full” parameter to request the biggest allowable image as opposed to biggest image available.

Note that Europeana encourages data providers to link to an image of the highest resolution as possible. It will allow Europeana to better serve its users by enabling the download of the images and browsing by technical features (e.g. pixel dimensions, MIME-type, colour palette).

More details on the technical metadata extracted by Europeana from images are available in the EDM /wiki/spaces/EF/pages/1145045000.

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.

In practice:

Supply an identifier for the webResource referenced as ‘view’ for the object
Identify the type of link between the IIIF resource for the object and the object.

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"/>
[…]

From IIIF v2.1 guidelines: https://iiif.io/api/image/2.1/#uri-syntax: The IIIF Image API URI for requesting an image must conform to the following URI Template:

{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}

e.g. http://www.example.org/image-service/abcd1234/info.json

Step 2: Flag the WebResource as IIIF-compliant

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

In practice:

Connect the WebResource to a resource of type svcs:Service using svcs:has_service (the identifier of the Service must be the ‘base URI’ of the IIIF resource)
Indicate that the WebService conforms to (dcterms:conformsTo) the IIIF profile. The value of dcterms:conformsTo MUST be the URI http://iiif.io/api/image

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">
[…]

Make sure that you have enabled CORS [Cross Origin Resource Sharing=security feature for browsers] to enable Europeana to display the images

Step 3: Indicate a level of IIIF implementation

The provider MAY 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

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:

note

"When the base URI is dereferenced, the interaction SHOULD result in the Image Information document. It is RECOMMENDED that the response be a 303 status redirection to the Image Information document’s URI."

<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>