There is no denying that EDM is a complex thing, and the devil, as usual, is in the detail. In section two 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 Europeana Collections!
We’re going to delve deeper into EDM classes and show you what impact each of the properties has on what you see on Europeana Collections. 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’.
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 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.
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.
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:
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:
Example: In the case of the data provider Zuidwestbrabants Museum, which delivers data through Erfgoedplus.be to LoCloud, the properties would look like this:
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.
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.
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.
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
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.
Following the links below you'll get in-depth understanding of the concepts we have discussed in this section and how they apply in the context of the Europeana Data Model. If your aim is to practically apply what you've read into mapping your data, then we advise reading the documents linked in these pages.