Linked Open Data is a way of publishing structured data that allows metadata to be connected and enriched, so that different representations of the same content can be found, and links made between related resources. All Europeana datasets can be explored and queried through the SPARQL API.

The metadata for all the objects in the Europeana portal is open, in that it is all licensed under the CC0 Public Domain Dedication under the terms of the Data Exchange Agreement (DEA), and can be freely downloaded via the API.

Linked Open Data - What is it? from Europeana on Vimeo (also en Français, auf Deutsch, in Italiano and en Español )

The data is represented in the Europeana Data Model (EDM). The described resources are each addressable and dereferenceable by their URIs; for instance, leads either to an HTML page on the Europeana portal for the object it identifies or to raw, machine-processable data on this object. Please see the technical details and the animation above for background on our motivation.

If you have any questions or feedback, contact us on the Europeana LOD group


The started as an experimental pilot in February 2012 with a small number of data providers who committed at an early stage to Europeana's initiative of promoting more open data. The project has been described in a paper presented at the Dublin Core 2011 conference. In October 2012, a large subset of the Europeana’s dataset (metadata on 20 million texts, images, videos and sounds) was transformed into linked data and made available from More recently within the Europeana Creative project, a new pilot was developed and hosted by Ontotext Corp. containing the full Europeana dataset at the time (metadata on about 36 million).

Tools created with the Europeana LOD API

ECLAP Linked Open Graph

ECLAP Linked Open Graph

ECLAP Linked Open Graph allows users to see, explore and browse the relationships among the ECLAP content and other types of resource created on the ECLAP platform.

Data structure

This page provides information on how the metadata served by is organised.

We assume that the reader has extensive knowledge of Linked Data technology. has also been described in the technical paper presented at the Dublin Core 2011 conference.

Background - The Europeana Data Model (EDM)

The Europeana Data Model has replaced the previous model Europeana Semantic Elements (ESE). It is a much more flexible and precise model than ESE, and offers the opportunity to attach every statement to the specific resource it applies to, and to reflect some basic form of data provenance. The main EDM requirements include:

  • distinguishing between a 'provided item' (painting, book) and its digital representations

  • distinguishing between an item and the metadata record describing it

  • allowing the ingestion of multiple records for the same item, which may contain contradictory statements about it

As a consequence of EDM having to meet these requirements, EDM data has a level of complexity above that which Europeana currently maintains. This level of complexity is comparable to what can be found in the data of many Europeana providers, and thus, we argue, it enables better exploitation of that data. Note also that, as much as possible, EDM re-uses elements coming from already-established vocabularies, such as Dublin Core, OAI-ORE, SKOS and CIDOC-CRM, thus lowering the cost of its creation and, hopefully, its adoption.

For more information on EDM, we refer to the EDM Definitions and EDM Primer on Europeana's technical documents page. The EDM OWL ontology is accessible through content negotiation but it is also directly available. Please be aware that both and those documents are under constant revision. There could therefore be some (minor) discrepancies between them!

Generating EDM data for Europeana includes semantic connections to external (linked data) sources. The vast majority of external links come from semantic enrichment realised at the Europeana Office, connecting Europeana items to places (as provided by GeoNames), concepts (from the GEMET thesaurus), persons (from DBpedia) and time periods (from an adhoc time period vocabulary). But the number of external links provided by data providers is constantly growing including links to AAT , GND, Iconclass, VIAF) or any domain vocabulary following the EDM recommendations for metadata on contextual resources.

A walk through the resources served at

The core EDM classes, together with the properties we expect to be applied to their instances, are presented in these templates. Of course it is unrealistic that all of the EDM properties are used for any single object exposed in Europeana. The EDM data harvested from Europeana providers, as well as the enrichment work by Europeana, allow us to create and describe a network of EDM resources for every Europeana object, as shown in this big picture example. The following explains in more detail the data that can be found for every class of resource served by

Item (Provided Cultural Heritage Object): Item resources represent objects (painting, book, etc.) for which institutions provide digital representations to be accessed through Europeana. Provided Cultural Heritage Object (CHO) URIs (e.g. are the main entry points in A provided CHO is the hub of the network of relevant resources (cf. below). When applicable, the Europeana URIs for these objects also link, via 'owl:sameAs' statements, to other linked data resources about the same object. In, no descriptive metadata (creator, subject, etc.) is directly attached to item URIs. It is instead attached to the proxies that represent a view of the object, from a specific institution's perspective (either a Europeana provider or Europeana itself).


Provider's proxy: These resources (e.g. are used as subjects of descriptive statements (creator, subject, date of creation, etc.) for the item, which are contributed by a Europeana provider. In the OAI-ORE model, proxies enable the separation of different views for the same resource, in the context of different aggregations. This allows us to distinguish the original metadata for the object from the metadata that is created by Europeana, an important requirement for us. Descriptive properties that apply to these proxies mostly come from Dublin Core : view an example. Proxies are connected to the item they represent a facet of using the 'ore:proxyFor' property. They are attached to the aggregation that contextualises them using 'ore:proxyIn'. Note to the reader: given the lack of support for named graphs (aka 'quadruples') in the RDF standard, ORE introduced proxies in order to support referencing resources in the context of a graph. Eventually, named graphs may be natively supported by RDF, which would lead to obsolescence of the proxy construct.

Providers Proxy

Provider's aggregation: These resources (e.g. provide data related to a Europeana provider's gathering of digitised representations and descriptive metadata for an item. As shown in this data, they are related to digital resources about the item, be they files directly representing it ('edm:object' and 'edm:isShownBy') or webpages showing the object in context ('edm:isShownAt'). They may also provide controlled rights information applying to these resources ('edm:rights'). Other statements provided in the same ESE record as the descriptive metadata for the item – but that do not always clearly apply to it – are also attached to aggregations. Finally, provenance data is given in statements using 'edm:provider' (the direct provider to Europeana in the data aggregation chain) or 'edm:dataProvider' (the cultural institution that curates the object). The aggregation is connected to the item resource using the 'edm:aggregatedCHO' property.

Providers Aggregation

Europeana's proxy: The second type of proxies served at are Europeana proxies (e.g. which provide access to the metadata created by Europeana for a given item, distinct from the metadata provided by the provider. Here one can find 'edm:year' statements, indicating a normalised date associated with the object. We also serve millions of generic 'edm:hasMet' enrichments, created by Europeana from a range of ESE descriptive fields (read documentation). These statements connect a Europeana proxy to places from GeoNames, concepts from the GEMET thesaurus, persons from DBpedia and periods from an adhoc time vocabulary. Finally, a proxy is connected to the item it represents a facet of, using the 'ore:proxyFor' property, as well as to the aggregation that contextualises it, using 'ore:proxyIn'.

Europeana Proxy

Europeana's aggregation: a Europeana aggregation (e.g. bundles together the result of all data creation and aggregation efforts for a given item. It aggregates the provider's aggregation (using ore:aggregates), which in turn will connect to the provider's proxy. Next to the provider aggregation, one can find the digitised resources serves for the item, i.e., an object page ('edm:landingPage') and a thumbnail (using a combination of 'edm:hasView' and 'foaf:thumbnail'). The Europeana proxy is also connected to this aggregation, as mentioned above.

Europeana Aggregation

Namespaces used in

The following RDF namespace abbreviations are currently used in

Further Reading

Linked Open Data FAQ

This page addresses the most important points of the Linked Open Data pilot.

Learn more
Salon des Cent. Octobre-novembre 1895
Lapierre, Charles (1867?-?)
18th century
Bibliothèque de l'INHA