IIIF Manifests at Europeana
- Maša Škrinjar
- Hugo Manguinhas
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.
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.1) 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 EDM properties included in Europeana manifests and how they are mapped to IIIF, please refer to the companion page “EDM to IIIF Mapping”.
Structure of the Europeana Manifest
Europeana manifests strongly depend 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 the example below.
Technical metadata is information about the technical qualities of the provided media resource, for example:
height of a video frame expressed as a number of pixels (ebucore:height)
width of a video frame expressed as a number of pixels (ebucore:width)
duration of a track or a signal expressed in ms (ebucore:duration)
the main mime type (ebucore:hasMimeType). Mime type is a standard that indicates the format of a file. It is a fundamental characteristic of a digital resource that influences its ability to be accessed and used over time.
The mime type associated with 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.
Mime type group | v2 | v3 |
(Browser) Supported | Web resource(s) related to edm:isShownBy and edm:hasView(s) is included in the manifest as painting-type annotation(s) on canvas(es), except for Video and Sound types. | Web resource(s) related to edm:isShownBy and edm:hasView is included in the manifest as painting-type annotation(s) on canvas(es). |
Specialised | Thumbnail(s) (extracted during media processing and made available via the Thumbnail API) for the respective web resource(s) is included in the manifest as painting-type annotation(s) on canvas(es) & the actual (non-viewable) web resource(s) is added to the canvas as a rendering component, except for Video and Sound types. | Thumbnail(s) (from the Thumbnail API) for the respective web resource(s) is included in the manifest as painting-type annotation(s) on canvas(es) & the actual (non-viewable) web resource(s) is added to canvas(es) as a rendering component. Example manifest for type image (v3) Example manifest for type video (v3)
|
Non-supported | No canvas is generated & manifest is not linked from the edm:WebResource class. | No canvas is generated & manifest is not linked from the edm:WebResource class. |
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.
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}/{LOCAL_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.