Harnessing the capabilities of the IIIF Presentation API, we are making sharing and reusing digital objects published in Europeana even easier. Now, the great majority of records in Europeana contain a link to a IIIF manifest, powering the display of digital objects in the portal and unlocking new reuse possibilities.

Europeana is combining media resources and metadata from provided EDM into IIIF manifests. Each manifest is linked from edm:isShownBy and edm:hasView web resource(s) through the dcterms:isReferencedBy property and powers the display of media in the Europeana website.

For providers who prefer to retain control over the display of their media resources, we continue to accept manifests created by them. In such cases, the provided manifest is preserved in the dcterms:isReferencedBy property and powers the display, taking precedence over the Europeana-created manifest.

Structure of the Europeana Manifest

Manifest is a central organising unit in IIIF and is accessible via URL that points to a document online (in JSON-LD format). We provide our manifests in Presentation API 2.1 (v2) by default. Version 3.0 (v3) manifests can be returned via content negotiation by sending an Accept header with the value: application/ld+json;profile="http://iiif.io/api/presentation/3/context.json"

Each manifest contains information needed for IIIF-compatible viewers to display digital objects, such as the structure, grouping, and layout of media resources, as well as descriptive metadata and rights information. For the complete list of properties included in Europeana manifests and how they are mapped to IIIF, please refer to the companion pages:

• EDM to IIIF Mapping (v2)

• EDM to IIIF Mapping (v3) 

The structure of Europeana manifests strongly depends on the technical metadata assigned to the provided web resources during the ingestion process, where Metis media service inspects media file(s) supplied in the EDM for technical metadata. If edm:WebResource class related to the processed media file is absent from the provided data, the media service creates it and then adds the technical metadata to it, as in this example:

<edm:WebResource rdf:about="https://zenodo.org/api/files/24ba47a0-41cb-46ad-b39e-8b63ded1a7a8/GR_PIOP_1219EMX034_ELMA_TV_ad_ARB.mp4">
   <edm:rights rdf:resource="http://creativecommons.org/licenses/by-sa/4.0/"/>
   <ebucore:hasMimeType>video/mp4</ebucore:hasMimeType>
   <ebucore:duration>39800</ebucore:duration>
   <ebucore:width rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1920</ebucore:width>
   <ebucore:height rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1080</ebucore:height>
   [...]
</edm:WebResource>

WebResource class excerpt from the record with video file mapped to edm:isShownBy

The mime type associated to the edm:isShownBy and edm:hasView web resources determines if and how these resources are included in the Europeana manifest. This, in turn, affects how media resources associated with the provided object are displayed. 

1 Mime type is available

When the edm:WebResource class contains a mime type, there are three possible scenarios for displaying media resources, depending on the mime type group. We categorised mime types present in Europeana into three groups - for the overview of mime types associated with each group (as well as corresponding media types), please refer to this companion page. 

The main difference between the groups is how they are presented in the canvas. Canvas is a virtual container for media resources (e.g. images, videos) and other presentation content (e.g. transcription, subtitles) that are “painted” onto it. It provides a frame of reference for the layout of the content. 

Note the scenarios are applied per web resource, not per record. If a record has multiple web resource classes, all three scenarios may be applied during the manifest creation. For instance, this could mean some web resources are included in the manifest, while no canvas is created for the others. 

2 Mime type is not available

When the edm:WebResource class does not contain a mime type, no canvas is created for this web resource. In the example below, the mime type of media resource provided in edm:isShownBy was not extracted during ingestion:

<edm:ProvidedCHO rdf:about="/632/_nnkqnsb"/>
  <edm:WebResource rdf:about="http://bc.wbp.lublin.pl/Content/23555/POCZ_U_247.jpg">
  <edm:rights rdf:resource="http://creativecommons.org/publicdomain/mark/1.0/"/>
</edm:WebResource>

WebResource class excerpt from the record with image file mapped to edm:isShownBy. Notice the absence of technical metadata

There are several consequences of the missing mime type: 

• Canvas is not added to the manifest,

• The manifest is not linked from the edm:WebResource class because the web resource (image in the example above) is not included in the manifest,

• Manifest dictates the display of media on the Europeana website: the web resources that are not linked to a manifest are also absent from the manifest. In our example, this results in the provided image not being displayed on the website,

• Ultimately, if no web resource is linked to a manifest, no manifest is available and no media is displayed in the portal.

Benefits for Europeana Providers and Users 

IIIF technologies provide numerous advantages for users and institutions working with digital resources. To enable our providers to benefit from them without needing to invest in developing their own solutions, we have made our manifests publicly available in the most up-to-date version of the IIIF Presentation API (v3). This eliminates the need for providers to create their own manifests to leverage IIIF technologies.

Our manifests enable users to view, manipulate, compare, and share digital objects that are published in Europeana. They can add annotations to media resources, mix up content from different providers, or even build new collections by organising manifests into groups. For instance, if a user wants to use an image from Europeana, they no longer need to search for the image URL in the data or download the image. Instead, they can simply use the manifest and load it into any IIIF-compliant viewer. Currently, all a user needs to retrieve the manifest is the Record ID, which is composed of the dataset and local identifier of the object: https://iiif.europeana.eu/presentation/{DATATSET_ID}/{RECORD_ID}/manifest (you can test our IIIF API using API Console that supports API calls, including manifest retrieval).

By generating IIIF manifests we are also providing an improved user experience in Europeana. Users are encouraged to interact with digital objects in new ways. This includes features such as zooming in and out of digital content and gaining access to additional information like transcriptions and multilingual subtitles through annotations.