Skip to end of banner
Go to start of banner

Media policy

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

lThe Europeana Media Policy outlines the requirements for the links to the media resources that are part of the provided metadata. It complements the information provided with the Publishing Guide and the EDM Mapping Guidelines. By following these requirements, we can give audiences a better experience and a greater connection with your collections. Following these requirements we will:

  • Extract technical metadata from media resources (e.g. mime-type, image size, duration, colour) to allow for a richer search and browse experience and to power functionalities such as enlarging and downloading images and other media.

  • Generate thumbnail (preview) images based on media resources, and show these images as part of the search results to help users find what they are looking for.

  • Display media resources on the item pages in Europeana Collections for a user to get the best possible experience and be able to interact with the content.

Metadata and Media

We will process (links to) media resources in the following three metadata fields:

  • edm:object

  • edm:isShownBy

  • edm:hasView (for each - More than one instance of edm:hasView is possible when more than one media resource is provided.)

We will also process links provided with edm:isShownAt, but we will not generate any thumbnails. Processing the edm:isShownAt involves checking that the link is resolvable and storing the mime-type of the working link. For more details about the metadata fields and their definition, please consult the EDM documentation.

Extract Technical Metadata

Europeana will extract metadata from the media resources provided via the above metadata fields to aid search in Europeana Collections and the APIs, and to determine how to present or consume a web resource in Europeana Collections. This is what we refer to as technical metadata (e.g. the image size, image colours, duration of audio clips). EDM was extended to fit the five media types currently supported by Europeana, namely: Sound, Video, Text, Image and 3D objects.

EDM profile for technical metadata

 EDM profile for technical metadata

To provide additional useful facets and filtering of Europeana resources the addition of technical metadata at the level of the WebResource, which was currently absent from EDM, is needed. This specification applies to five media types which Europeana currently supports, namely: Sound, Video, Text, Image and 3D objects. This profile lists the properties that will apply to the WebResource class and an additional class that were defined to support such functionality.

The working document that contains background information and that forms the basis of this listing can be found at:
https://docs.google.com/spreadsheets/d/17LjVpdUHsqpLhvQ0kvvDd7ja6eAPhSB9dN3NQ0kEbko/edit#gid=0.
Most of the added properties come from the EBUCore set of properties, available at:
http://www.ebu.ch/metadata/ontologies/ebucore/index.html

Approach
A minimal approach has been adopted to the addition of properties to EDM. Not all functions require the addition of a specific property. Consider for example the filtering of Europeana objects based on the presence of a usable thumbnail. This can be detected by checking for the presence of a URL in the “edm:preview” property (and the resource flagged accordingly in a search system) without the need for a specific EDM property to hold that flag in Europeana’s reference data.

Some values can be used to generate further values and, depending on the stage in the processing of data where this happens, a property may be needed to record the output. For example, the orientation of an image will be generated by processing numeric values given in the height and width properties, giving the result as “Portrait” or “Landscape”. A few properties have been created in the EDM namespace even though similar properties already exist elsewhere (e.g. Exif1 and EBUCore2). This is because the allowable values did not match our requirements at this time (e.g. EDM needs literal values in some cases).
These properties are: “edm:hasColorSpace”, “edm:componentColor”, “edm:spatialResolution” and “edm:codecName”.

Properties

All the properties defined below should be applied to edm:WebResource.

edm:codecName

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:hasMimeType

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:fileByteSize

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:duration

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:width

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:height

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

edm:spatialResolution

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:sampleSize

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:sampleRate

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:bitRate

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:frameRate

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

edm:hasColorSpace

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

edm:componentColor

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:orientation

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

ebucore:audioChannelNumber

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

rdf:type

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

Classes

edm:FullTextResource

URI

Label

Definition

Subclass of

Example

Comment

Document history:

Robina Clayphan, Hugo Manguinhas - Final version after review

Hugo Manguinhas, Antoine Isaac - Additional comments incorporated

 EDM profile for technical metadata

To provide additional useful facets and filtering of Europeana resources the addition of technical metadata at the level of the WebResource, which was currently absent from EDM, is needed. This specification applies to five media types which Europeana currently supports, namely: Sound, Video, Text, Image and 3D objects. This profile lists the properties that will apply to the WebResource class and an additional class that were defined to support such functionality.

The working document that contains background information and that forms the basis of this listing can be found at:
https://docs.google.com/spreadsheets/d/17LjVpdUHsqpLhvQ0kvvDd7ja6eAPhSB9dN3NQ0kEbko/edit#gid=0.
Most of the added properties come from the EBUCore set of properties, available at:
http://www.ebu.ch/metadata/ontologies/ebucore/index.html

Approach

A minimal approach has been adopted to the addition of properties to EDM. Not all functions require the addition of a specific property. Consider for example the filtering of Europeana objects based on the presence of a usable thumbnail. This can be detected by checking for the presence of a URL in the “edm:preview” property (and the resource flagged accordingly in a search system) without the need for a specific EDM property to hold that flag in Europeana’s reference data.

Some values can be used to generate further values and, depending on the stage in the processing of data where this happens, a property may be needed to record the output. For example, the orientation of an image will be generated by processing numeric values given in the height and width properties, giving the result as “Portrait” or “Landscape”. A few properties have been created in the EDM namespace even though similar properties already exist elsewhere (e.g. Exif1 and EBUCore2). This is because the allowable values did not match our requirements at this time (e.g. EDM needs literal values in some cases).
These properties are: “edm:hasColorSpace”, “edm:componentColor”, “edm:spatialResolution” and “edm:codecName”.

Properties

All the properties defined below should be applied to edm:WebResource.

edm:codecName

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

edm:codecName

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

 EDM profile for technical metadata

To provide additional useful facets and filtering of Europeana resources the addition of technical metadata at the level of the WebResource, which was currently absent from EDM, is needed. This specification applies to five media types which Europeana currently supports, namely: Sound, Video, Text, Image and 3D objects. This profile lists the properties that will apply to the WebResource class and an additional class that were defined to support such functionality.

The working document that contains background information and that forms the basis of this listing can be found at:
https://docs.google.com/spreadsheets/d/17LjVpdUHsqpLhvQ0kvvDd7ja6eAPhSB9dN3NQ0kEbko/edit#gid=0.
Most of the added properties come from the EBUCore set of properties, available at:
http://www.ebu.ch/metadata/ontologies/ebucore/index.html

Approach

A minimal approach has been adopted to the addition of properties to EDM. Not all functions require the addition of a specific property. Consider for example the filtering of Europeana objects based on the presence of a usable thumbnail. This can be detected by checking for the presence of a URL in the “edm:preview” property (and the resource flagged accordingly in a search system) without the need for a specific EDM property to hold that flag in Europeana’s reference data.

Some values can be used to generate further values and, depending on the stage in the processing of data where this happens, a property may be needed to record the output. For example, the orientation of an image will be generated by processing numeric values given in the height and width properties, giving the result as “Portrait” or “Landscape”. A few properties have been created in the EDM namespace even though similar properties already exist elsewhere (e.g. Exif1 and EBUCore2). This is because the allowable values did not match our requirements at this time (e.g. EDM needs literal values in some cases).
These properties are: “edm:hasColorSpace”, “edm:componentColor”, “edm:spatialResolution” and “edm:codecName”.

Properties

All the properties defined below should be applied to edm:WebResource.

edm:codecName

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

edm:codecName

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

 EDM profile for technical metadata

To provide additional useful facets and filtering of Europeana resources the addition of technical metadata at the level of the WebResource, which was currently absent from EDM, is needed. This specification applies to five media types which Europeana currently supports, namely: Sound, Video, Text, Image and 3D objects. This profile lists the properties that will apply to the WebResource class and an additional class that were defined to support such functionality.

The working document that contains background information and that forms the basis of this listing can be found at:
https://docs.google.com/spreadsheets/d/17LjVpdUHsqpLhvQ0kvvDd7ja6eAPhSB9dN3NQ0kEbko/edit#gid=0.
Most of the added properties come from the EBUCore set of properties, available at:
http://www.ebu.ch/metadata/ontologies/ebucore/index.html

Approach

A minimal approach has been adopted to the addition of properties to EDM. Not all functions require the addition of a specific property. Consider for example the filtering of Europeana objects based on the presence of a usable thumbnail. This can be detected by checking for the presence of a URL in the “edm:preview” property (and the resource flagged accordingly in a search system) without the need for a specific EDM property to hold that flag in Europeana’s reference data.

Some values can be used to generate further values and, depending on the stage in the processing of data where this happens, a property may be needed to record the output. For example, the orientation of an image will be generated by processing numeric values given in the height and width properties, giving the result as “Portrait” or “Landscape”. A few properties have been created in the EDM namespace even though similar properties already exist elsewhere (e.g. Exif1 and EBUCore2). This is because the allowable values did not match our requirements at this time (e.g. EDM needs literal values in some cases).
These properties are: “edm:hasColorSpace”, “edm:componentColor”, “edm:spatialResolution” and “edm:codecName”.

Properties

All the properties defined below should be applied to edm:WebResource.

edm:codecName

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

edm:codecName

URI

Label

Definition

Domain

Obligation&Occurence

Example

Comment

An overview of all the technical metadata facets in Europeana Collections can be found at Documentation on the Europeana Search API. The content tiers, i.e. the quality of a media resource as specified in the Europeana Publishing Framework, are calculated on the basis of the technical metadata.

Retrieving the links to media resources in the above mentioned metadata fields is required in order to access and download those media resources. Downloading each resource is necessary in order to generate the technical metadata (and thumbnails, see below). Europeana will only temporarily download the media resource, which will be discarded after processing.

In order to successfully access and download a media resource, the following requirements must be met:

  • The link to the media resource must be a valid URL (Complies with either IETF RFC 3986: Uniform Resource Identifier (URI): Generic Syntax or IETF RFC 3987 Internationalized Resource Identifiers (IRIs)) and we recommend such URL to use the HTTPS protocol.

  • The link must resolve to a media resource directly, not to a webpage (i.e. where the mime-type of the resource would be "text/html").

  • The link must not return more than three redirects before ending up on the media resource.

  • The media resource must be able to be downloaded within a time span of 20 minutes.

  • The media resource must have a valid mime-type. We have established a list of valid mime-types that we support from ingestion to display in Europeana Collections based on the mime-types maintained by the Internet Assigned Numbers Authority.

  • Large PDF files should be optimised for Fast Web View so they take less time to download. An exception from these requirements are media resources that are embedded in the Europeana Collections portal (see the section below).

Media Formats/Mime Types

 Media Formats/Mime Types

A MIME type (also known as a Multipurpose Internet Mail Extension) 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 purpose of this section is to provide a list of MIME types corresponding to different types of content/media that are supported or not by Europeana.

Media formats supported on Europeana Collections

Format Name

Mime-type

File Extension(s)

Image

JPEG

image/jpeg

.jpeg

PNG

image/png

.png

GIF

image/gif

.gif

Generic Bitmap

image/bmp

.bmp

Microsoft Bitmap

image/x-ms-bmp

.bmp

Text

PDF

application/pdf

.pdf

Video

MPEG-4 Video

video/mp4

.mp4

Open Web Media Project – Video

video/webm

.webm

M4v

video/x-m4v

.m4v

Quicktime video

video/quicktime

.mov, .qt

Audio

MP3 or other MPEG format

audio/mpeg

.mp3

Waveform Audio

audio/x-wav

.wav, .wave

Media formats not supported in Europeana Collections

Not all the links to media resources that Europeana receives from data providers can be displayed in the Europeana Collections portal, however these are still made available for download to our users for reuse. The respective media formats (and mime-types) are presented in the table below.

Format Name

Mime-type

File Extension(s)

Image

TIFF

image/tiff

.tiff

Adobe Photoshop

image/vnd.adobe.photoshop

.psd

Text

Plain Text

text/plain

.txt

Video

Microsoft Windows Media Video

video/x-ms-wmv

.wmv

Flash Video

video/x-flv

.flv

MPEG Video

video/mpeg

.mpg

Audio Video Interleave (AVI)

video/x-msvideo

.avi

Microsoft Advanced Systems Format (ASF)

video/x-ms-asf

.asf

Audio

Native FLAC format (FLAC in its own container)

audio/x-flac

.flac

Windows Media Audio

audio/x-ms-wma

.wma

Audio Interchange File Format

audio/x-aiff

.aiff, .aif, .aifc

Generate Thumbnail Preview Images

Thumbnails are a small image of the digital object. They directly affect the user click-through rate. Requirements and recommendations about the quality of thumbnails are provided in the Publishing Guide.

We will generate thumbnails from the media resources provided via the above metadata fields, if the mime-type of the media resources is valid (see also above). Note that for media resources with the mime-type “application/pdf” we only generate a thumbnail when we find an image in the pdf.

We will generate the following thumbnails:

  • An image with a width of at maximum 200 pixels.

  • An image with a width of at maximum 400 pixels.

The following must be noted:

  • The height of the thumbnail will be proportional in accordance with the aspect ratio.

  • If an image is smaller than 200 or 400 pixels, the original width of the image will be used as the size of the thumbnail (Europeana does not recommend to use images which are smaller than 400 pixels in width).

All thumbnails that we generate can be retrieved via the Thumbnail API. Note that for the thumbnail used for display in the search results of Europeana Collections, we have a specific metadata field: edm:preview. The value for edm:preview will be the thumbnail corresponding to either the media resource obtained from edm:object if available, otherwise the image with the highest resolution of either edm:isShownBy or the first edm:hasView.

Display of Media Resources

CORS

In order for the Europeana Collections portal to access and display media resources coming from providers’ servers, the latter must support Cross-Origin Resource Sharing (CORS). This is because web browsers restrict resources on a web page to be requested from another domain outside the domain it was served (Collections in this case). The CORS standard is needed because it allows servers to specify not only who can access its resources but also how these resources can be accessed.

This is especially important for providers who share resources via IIIF as CORS is essential for our IIIF viewer to perform the image information requests and to obtain the presentation manifests. Without CORS, although the IIIF resources will be displayed in the provider’s website, it won’t be possible to be viewed in the Europeana Collections portal. For more information about CORS.

HTTPS

Providers of IIIF resources are encouraged to deliver their resources over HTTPS so that they can be included in our web page without issue.

Embedding of media resources

In order for an item to be embedded in the Europeana Collections portal, there must be a valid oEmbed endpoint (see example from SketchFab) available where the media referred to in the item is displayed using a third party viewer or player. An exception is made for some data partners that do not support oEmbed.

On the metadata side, a link to a webpage where the item can be displayed and which can be mappable to an oEmbed URL is provided within edm:isShownBy. In order to do this and because there is no information in the metadata that relates the webpage link to the oEmbed endpoint, the Europeana Collections portal has to apply additional logic to convert the URL provided in edm:isShownBy into an oEmbed URL that can be used for embedding. For this, it uses an internal registry of oEmbed endpoints which consists of both a public list and manual additions made by the Collections development team (which also includes the Europeana oEmbed implementations to cover the exceptions). This means that whenever a new dataset is added that uses a different oEmbed endpoint it will need to be added to this registry.

  • No labels