This website uses cookies to ensure you get the best experience. By clicking or navigating the site you agree to allow our collection of information through cookies. More info

Posted on Wednesday August 30, 2017

Updated on Monday November 6, 2023

Section 2 - Advanced EDM specifications

In this section we’re going to delve deeper into EDM classes and show you what impact each of the properties has on what you see on the Europeana website. We also share some of the best practice we've acquired over the years, as well as explain what happens with your data here at Europeana before we publish it, or, as we call it, transform it from ‘EDM external’ to ‘EDM internal’.

main image
Title:
An explosion in a laboratory. Oil painting after W. Hogarth.
Institution:
Wellcome Collection
Country:
United Kingdom

There is no denying that EDM is a complex thing, and the devil, as usual, is in the detail. In section 2 of this course, we focus on what you could and should (or, in some cases, shouldn't) do with EDM, so that your records look all nice and shiny on the Europeana website!

We’re going to delve deeper into EDM classes and show you what impact each of the properties has on what you see on the Europeana website. We also share some of the best practice we've acquired over the years, as well as explain what happens with your data here at Europeana before we publish it, or, as we call it, transform it from ‘EDM external’ to ‘EDM internal’.

Lesson 5 - Main EDM classes

Part 1 - ProvidedCHO - the physical artwork


The Provided Cultural Heritage Object - handled through the edm:ProvidedCHO class - refers to ‘the original object that is the focus of the metadata description. It may be either a physical object (painting, book, etc.) or a digital original’.

All the metadata describing the object (creator, historical/geographical coverage, subject, form factor and material, type, licence, etc.) has to be embedded in the edm:ProvidedCHO class.

If this metadata uses dereferenceable URIs, and so is Linked Data compliant, our system will automatically create classes based on those URIs, see Lesson 3.


Part 2 - WebResource


The Web Resource - handled through the edm:WebResource class - refers to ‘a digital representation of the provided cultural heritage object’. It is not a mandatory class, as it is meant to be present in an EDM record only if the related representation is defined with more detail than shown in edm:ProvidedCHO.

Example:

You would use edm:WebResource when the object is in the public domain but the digital representation of it is not. Or if more specific details should be added, such as the position of this representation in relation to other ones - pictures of the object from various angles, pages of a book, etc.  For further examples relating to other digital representations, check the links in the additional resources pages below.

Lesson 6 - Aggregation

The Aggregation class - handled through ore:Aggregation - refers to ‘the set of related resources in the Europeana system about one particular provided object from one provider. These are either created by the provider or generated from the metadata by the Europeana system’.

This class acts as the One Ring in The Lord of the Rings novels, since it has the responsibility of ruling several elements.

The Aggregation class is responsible for linking edm:ProvidedCHO with its related edm:WebResource(s) and its edm:isShownAt - the data provider’s website. Most of the time, that’s the institution in charge of the item, and consequently the producer of this data.

It also holds wider information, such as the licence applied to the record, or the name of its provider and data provider. Such data is critical for consistent Europeana search results when it comes to institutions’ findability and visibility.

Part 1 - Content strategy, or how to use isShownAt / isShowBy / object
Preparing data for publishing EDM records is not always straightforward. One has first to understand the celestial mechanics of Linked Open Data through the RDF standard, and then it is necessary to map the available data to the relevant EDM field.

Working on this day in, day out, has made us aware that some of the most important fields are sometimes unclear in what they refer to. So, here is a summary of the three elements linking to the actual media, embedded into the ore:Aggregation class:

  • edm:isShownAt refers to the web view of the record in full information context, on the original institution's website
  • edm:isShownBy refers to the main representation of the record (if present, this will be used to generate our thumbnail)
  • edm:object refers to the thumbnail image of the record (min 0.1 megapixel in size; this may be the same URL as edm:isShownBy)

You must use either edm:isShownAt or edm:isShownBy. The use of edm:isShownBy is preferred, as it would ensure a direct representation of the record in Europeana Collections. The resource in edm:object is displayed in our search results list/grid, as a thumbnail for a specific record. Then, once on the Europeana individual record page, the user will see the resource in edm:isShownBy and will be pointed to the edm:isShownAt resource if they click on the ‘View at’ link (top right side).


Part 2 - Institutions’ visibility, or demystifying the Provider, Intermediate Provider & Data Provider roles


We, at Europeana, love to classify things. It is not only a compulsive behaviour, but it helps us to ensure we can provide the most filterable search results for our users. Therefore, three categories were created in order to define our partners:

  • edm:DataProvider (mandatory) refers to the institution in charge of the cultural object and which has created the related data;
  • edm:IntermediateProvider is the intermediate organization that selects, collates, or curates data from a data provider, and which then passes the data to an aggregator from which Europeana harvests;
  • edm:Provider (mandatory) is the organization providing data directly to Europeana;

Example: In the case of the data provider Zuidwestbrabants Museum, which delivers data through Erfgoedplus.be to LoCloud, the properties would look like this:
  <edm:dataProvider>Zuidwestbrabants Museum</edm:dataProvider>
  <edm:intermediateProvider>Erfgoedplus.be</edm:intermediateProvider>
  <edm:provider>LoCloud</edm:provider>

Accross a dataset these labels need to be identical (no variant spellings for the same institution) to ensure the consistency of the information displayed and queryable through our search engine.

Lesson 7 - Contextual classes

In the case of dereferencable resources in edm:ProvidedCHO (see Lesson 5), it is possible to include contextual classes that are going to carry the related information of these resources. If not directly implemented by the providers in their data, our system will create such contextual classes based on what is available in the semantic web, thanks to Linked Open Data technologies. Below, we offer a brief intro to the EDM contextual classes.
 

  • edm:Agent refers to all the persons or institutions related to the creation, distribution and collection of the object. It is usually connected to elements such as dc:creator, dc:contributor, dc:publisher.
  • edm:Place and edm:TimeSpan refer to all the geographical and historical information related to the object. They are usually connected to elements such as dc:coverage, dcterms:spatial, dcterms:historical, dcterms:issued, dcterms:created.
  • skos:Concept refers to all the classification fields, such as dc:type, dc:format, dc:subject, dcterms:extent.

Lesson 8 - Best practices of mapping

In this lesson we cover some of the best practice for mapping data into EDM we've acquired over years. We will give practical examples in order to highlight issues our users face when browsing content from Europeana Collections.

Part 1 - dc:language, or xml:lang, or maybe both ?


The dc:language is only used once, in edm:ProvidedCHO, to specify the language that can be applied to the core content of this object. It is only mandatory for textual resources, as we need this information to disambiguate millions of text objects in our search results. Almost any field populated with literals can be embedded with a language attribute xml:lang, in order to specify the language of the provided metadata.

Example:
A French book has been described using both English and French metadata: It will have to be described with <dc:language>fr</dc:language>, as the text was written in French (and because it is obviously a textual resource).

It could be embedded with several dc:subject fields relating to the domains treated in this book; and each occurrence of this field could be disambiguated using a relevant xml:lang attribute, such as
<dc:subject  xml:lang="fr">Patisserie</dc:subject>
<dc:subject  xml:lang="en">Pastry</dc:subject>
<dc:subject  xml:lang="fr">Recette</dc:subject>
<dc:subject xml:lang="en">Recipe</dc:subject>

This gives us a reliable multilingual approach.
 
Part 2 - The curse of the unique title or why you should not have 234,673 items labelled as ‘Photograph’

When people are looking for specific records, or at least have an idea of what they are looking for, they rely on metadata that’s of a decent quality. They shouldn’t have to browse endless lists of results, just because the title of all these records is the same. This explains why, when submitting records for publishing in Europeana, we ask for mandatory metadata elements such as a title or a description, and at least one classifier element related to the historical/geographical/typology information from this object.

Readings

top