- The document introduces the Europeana Data Model (EDM), which was created to allow Europeana to ingest metadata from various sources and domains while maintaining granularity and semantics. - EDM uses standards like Dublin Core, CIDOC-CRM, and RDF to distinguish cultural heritage objects from their representations and metadata, and to represent relationships between objects and contextual information. - EDM profiles allow communities to build on EDM to meet their specific needs while maintaining interoperability, and it has been adopted by projects beyond Europeana seeking interoperable metadata.

1. Introduction to the Europeana Data
Model (EDM)
22nd September 2013, TPDL2013, Malta
Valentine Charles

2. A Collaborative Effort
Original principle: make Europeana ready to ingest metadata that is
closer to specific community concerns
Europeana & partners can develop EDM “profiles” upon which
everyone could build specific functionality
 Based on best practices from sector or domain level
EDM is consolidated with partners who re-use it
 Europeana providers, DPLA, CARARE…

3. Metadata interoperability challenges
 Needs:
• Accommodate different data models
• Accommodate domain specific requirements
• Avoid losing data and keep the best granularity
• Co-exist with the original data

4. EDM rationale: requirements
 Richer metadata - finer granularity
1. Distinguish “provided objects” (painting, book, movie, etc.)
from their digital representations
2. Distinguish object from its metadata record
3. Allow multiple records for a same object, containing
potentially contradictory statements about it
4. Support for objects that are composed of other objects
5. Support for contextual resources, including concepts from
controlled vocabularies

5. Provide more semantics to the data
 A semantic layer on top of Cultural Heritage objects

6. Provide more semantics to the data
 Semantic layer provides more context to the metadata
 Allow the representation of specific relationships
• Aboutness
• Similarity between objects
• Part-whole relation, representation, derivation…
 Promote the re-use of external resources (available as
Linked Data)

7. EDM rationale: principles
 Compatibility with different levels of description
1. Allow different levels of granularity
2. Allow the specificationof domain-specific application profiles
3. Enable the re-use of existing standards

8. EDM basis
 OAI ORE (Open Archives Initiative Object Reuse & Exchange) for
organizing an object’s metadata and digital representation(s)
 Dublin Core for descriptive metadata
 SKOS (Simple Knowledge Organization System) for conceptual
vocabulary representation
 CIDOC-CRM for event and relationships between objects
 Adopt Semantic Web representation principles (RDF)
• Re-use and mix differentvocabularies together
• Preserve original data and still allow for interoperability

9. Resource Description Framework (RDF)
 “Les Misérables’’ was written by Victor Hugo

10. EDM main classes
Groups of things that have common
properties, e.g., web resources.

11. EDM main properties Attributes or characteristics of
resources e.g., a member of the
class Agent will have a name.

12. EDM basic pattern
 A data provider submits to Europeana a “bundle” of an object
and its digital representation(s)

13. An example

14. Descriptive metadata for a cultural heritage
object
The ProvidedCHO is the cultural heritage object which is the
subject of the package of data that has been submitted to
Europeana.
Properties:
dc:contributor, dc:creator, dc:date, dc:format, dc:identifier, dc:language,
dc:publisher, dc:relation, dc:source, dcterms:alternative, dcterms:extent,
dcterms:temporal, dcterms:medium, dcterms:created, dcterms:provenance,
dcterms:issued, dcterms:conformsTo, dcterms:hasFormat,
dcterms:isFormatOf, dcterms:hasVersion, dcterms:isVersionOf,
dcterms:hasPart, dcterms:isPartOf, dcterms:isReferencedBy,
dcterms:references, dcterms:isReplacedBy, dcterms:replaces
dcterms:isRequiredBy, dcterms:requires, dcterms:tableOfContents,
edm:isNextInSequence, edm:isDerivativeOf, edm:currentLocation…

15. Provided CHO example

16. Digital representations of the object
One or more WebResources are provided for the cultural heritage
object.
Properties:
dc:rights
edm:rights
dc:format
dc:description
dcterms:isPartOf
edm:isNextInSequence…

17. Web Resource example

18. Aggregations organise data of a provider
The Aggregation represents the set of related resources about one
real object contributed by one provider.
It carries the metadata that is about the whole set
Mandatory:
edm:aggregatedCHO
edm:dataProvider
edm:isShownBy or
edm:isShownAt
edm:provider
edm:rights
Optional:
edm:hasView
edm:object
dc:rights
edm:ugc

19. Aggregation example

20. <edm:ProvidedCHO rdf:about="#UEDIN:214">
<dc:date>Circa 1840</dc:date>
<dc:description>Technical description: Brass; ligature fitting on bell section at joint;
stockings on main slides. Bell with one coil, angled to face forwards. Repair History: Main slide
possibly not original (tenon of slide section of joint is tapered, bell section joint for cylindrical
tenon).</dc:description>
<dc:identifier>#UEDIN:214</dc:identifier>
<dc:title>Buccin trombone. Nominal pitch: B?.</dc:title>
<dc:type rdf:resource="http://www.mimo-db.eu/InstrumentsKeywords/4378"/>
<edm:type>IMAGE</edm:type>
</edm:ProvidedCHO>
<edm:WebResource rdf:about="http://www.mimo-
db.eu/media/UEDIN/VIDEO/0032195v.mpg">
<edm:rights rdf:resource="http://creativecommons.org/licenses/by-nc-sa/3.0/"/>
</edm:WebResource>
<ore:Aggregation rdf:about="http://www.mimo-db.eu/UEDIN/214">
<edm:aggregatedCHO rdf:resource="#UEDIN:214"/>
<edm:dataProvider>University of Edinburgh</edm:dataProvider>
<<edm:provider>MIMO - Musical Instrument Museums Online</edm:provider>
<edm:rights rdf:resource="http://creativecommons.org/licenses/by-nc-sa/3.0/"/>
</ore:Aggregation>

21. Questions so far?

22. Contextual entities
Representing (real-world) entities related to a provided object
as fully fledged resources, not just strings
edm:Agent
foaf:name
skos:altLabel
rdaGr2:biographicalInformation
rdaGr2:dateOfBirth
skos:Concept
skos:prefLabel
skos:altLabel
skos:broader
skos:related
skos:definition….
edm:TimeSpan
skos:prefLabel
dcterms:isPartOf
edm:begin
edm:end
….
edm:Place
wgs84_pos:lat
wgs84_pos:long
skos:prefLabel
skos:note
dcterms:isPartOf….

23. Place example

24. Applications of EDM
 Europeana Portal
 Europeana Linked Data pilot (data.europeana.eu)
 EuropeanaAPI
 Provision of EDM data: MIMO, CARARE, HOPE projects
 EDM re-use at the Digital Public Library of America,
Smithsonian Institute
 EDM extensions at projects: German Digital Library,
Europeana Fashion, Digital Manuscripts to Europeana
 EDM mapping to Schema.org

25. Documentation
Main documentation:
EDM Definition
EDM Primer
EDM Mapping guidelines for data providers
http://pro.europeana.eu/edm-documentation
 Other resources:
EDM case studies
http://pro.europeana.eu/case-studies-edm
EDM object templates & XML schema
http://europeanalabs.eu/wiki/EDMXMLSchema

26. Cases studies

27. EDM and data providers’ duties & benefits
 Mapping the data to EDM has benefits
• Closer to original metadata
• Data can be contextualized, semantically linked to other data
• Allows for richer semantic query expansion & cross-collection
browsing

28. A mapping to EDM: the CARARE example
 A three-year project making digital content from the
archaeology and architecture heritage domain available to
Europeana.
 Domain-specific metadata schema based on existing
standards from the archaeology and architecture domain
( MIDAS Heritage, LIDO & CIDOC CRM)
• Heritage Assets
• Digital resources
• Collections
• Activities

29. Creating EDM resources from Carare data
 A CARARE object becomes one or several EDM Provided
Cultural Heritage Objects with:
• Related web resources
• Aggregations
• Contextual information about place
CARARE’s HeritageAssets always give raise to one EDM
ProvidedCHOs with its companion Aggregation
edm:ProvidedCHO
HA:PamFond/1978155
ore:Aggregation
http://store.carare.eu/uid/ii
d:1655549/HA:PamFond/
1978155
Heritage Asset’s
identifier
PamFond/1978155

30. A EDM application profile: the Digital Public
Library of America (DPLA) example
 Need to accommodate data from various domains, using various
data standards.
 Re-uses the EDM classes and properties in addition to the specific
DPLA ones.

31. An extension for EDM: The DM2E example