Mapping cross-­domain metadata to the Europeana Data Model (EDM) - EDM introduction


Published on

Presentation given at TPDL2013

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mapping cross-­domain metadata to the Europeana Data Model (EDM) - EDM introduction

  1. 1. Introduction to the Europeana Data Model (EDM) 22nd September 2013, TPDL2013, Malta Valentine Charles
  2. 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. 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. 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. 5. Provide more semantics to the data  A semantic layer on top of Cultural Heritage objects
  6. 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. 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. 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. 9. Resource Description Framework (RDF)  “Les Misérables’’ was written by Victor Hugo
  10. 10. EDM main classes Groups of things that have common properties, e.g., web resources.
  11. 11. EDM main properties Attributes or characteristics of resources e.g., a member of the class Agent will have a name.
  12. 12. EDM basic pattern  A data provider submits to Europeana a “bundle” of an object and its digital representation(s)
  13. 13. An example
  14. 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. 15. Provided CHO example
  16. 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. 17. Web Resource example
  18. 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. 19. Aggregation example
  20. 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=""/> <edm:type>IMAGE</edm:type> </edm:ProvidedCHO> <edm:WebResource rdf:about="http://www.mimo-"> <edm:rights rdf:resource=""/> </edm:WebResource> <ore:Aggregation rdf:about=""> <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=""/> </ore:Aggregation>
  21. 21. Questions so far?
  22. 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. 23. Place example
  24. 24. Applications of EDM  Europeana Portal  Europeana Linked Data pilot (  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
  25. 25. Documentation Main documentation: EDM Definition EDM Primer EDM Mapping guidelines for data providers  Other resources: EDM case studies EDM object templates & XML schema
  26. 26. Cases studies
  27. 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. 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. 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 d:1655549/HA:PamFond/ 1978155 Heritage Asset’s identifier PamFond/1978155
  30. 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. 31. An extension for EDM: The DM2E example