Von ESE zu EDM und darüber hinaus: Wie Europeana Zugang zu Objekten des kulturellen Erbes ermöglicht

Evelyn Dröge, Steffen Hennicke, Julia Iwanowa, Marlies Olensky, Stefanie Rühle, Violeta Trkulja

Einleitung

Europeana, die europäische digitale Bibliothek[1], wurde 2005 von der Europäischen Kommission ins Leben gerufen. Die Vision, die dahinter stand, war eine digitale Bibliothek zu etablieren, die einen einfachen, direkten und multilingualen Zugang zum europäischen kulturellem Erbe bieten sollte. Eine erste Version von Europeana ging im November 2008 online – seitdem wird das Angebot kontinuierlich verbessert und erweitert.

Das Europeana Data Model (EDM) wurde konzipiert, um die verschiedenen reichen Metadaten über Objekte des kulturellen Erbes – auch Cultural Heritage Objects (CHOs) genannt – in Europeana in einem einheitlichen Datenmodell abbilden zu können. Europeana wird von den meisten Nutzern als ein Portal wahrgenommen[2], das Zugriff auf über 30 Millionen Objekte aus Bibliotheken, Archiven und Museen bietet, die aus 36 unterschiedlichen Ländern stammen (Stand November 2013).[3] Durch die Entwicklung des EDM kann Europeana jedoch mehr als nur ein Portal sein. EDM liegt der Ansatz von Linked Open Data (LOD) zugrunde. Dieser erleichtert die Auffindbarkeit und Nutzung von Inhalten in Europeana und macht Metadaten in großem Maßstab zugänglich.[4] Eine Beschreibung von Linked Data hat Tim Berners-Lee, der Erfinder des World Wide Web und (Mit-)Begründer der Semantic-Web- und Linked-Data-Initiative, in den Linked-Data-Prinzipien festgehalten.[5] Charakteristisch für Linked (Open) Data ist demnach, dass die Daten im Web zugänglich, nutzbar für Mensch und Maschine, zu anderen Daten verlinkt und dereferenzierbar über stabile Identifikatoren sind.[6] Idealerweise ist LOD in der Repräsentationssprache „Resource Description Framework“ (RDF)[7] beschrieben. Diese Art der Modellierung bildet nicht nur die Grundlage für semantische Suchfunktionalitäten auf der Europeana-Webseite, sondern ermöglicht auch die Nutzung und Weiterverarbeitung von RDF-Daten außerhalb davon. Dies führt dazu, dass nicht nur das Europeana-Portal selbst, sondern auch andere Anwendungen mit EDM-Daten arbeiten können.

Der vorliegende Beitrag gibt einen Überblick über das Umfeld der aktuellen Entwicklungen in Europeana (Abschnitt 1), über die Funktionsweise von EDM im Vergleich zum Vorgängermodell ESE (Abschnitt 2), eine Einführung in RDF und welche zusätzlichen Möglichkeiten es bietet (Abschnitt 3), EDM als Ontologie (Abschnitt 4), wie EDM spezialisiert werden kann am Beispiel von Anwendungsprofilen der Deutschen Digitalen Bibliothek, der Digital Public Library of America und des DM2E-Projekts (Abschnitt 5), wie es über Links zu anderen Ressourcen angereichert wird und wie Europeana Linked Open Data im Rahmen des LOD-Pilots bereitstellt (Abschnitt 6).

1 Qualität und Interoperabilität von Metadaten in Europeana

Derzeit sind dreißig Projekte an der kontinuierlichen Ausarbeitung Europeanas involviert – manche durch die Entwicklung neuer Techniken, andere durch die Lieferung von Inhalten.[8] Neben den Projekten befassen sich „Task Forces“ mit Aspekten der Weiterentwicklung von Europeana und greifen offene Fragen und Ideen für Verbesserungen auf.[9]

Ein Beispiel hierfür ist die im März 2013 beendete Task Force zur Darstellung von hierarchischen Objekten in Europeana („Taskforce on hierarchical objects“). Das EDM berücksichtigte die Modellierung von Bestandsrelationen bei Objekten mit unterschiedlichen Ebenen nicht ausreichend, beispielsweise Bücher, die in mehrere Teile, Kapitel und Seiten unterteilt werden können; Zeitschriften, die aus mehreren Ausgaben, Artikeln und Seiten bestehen; Aussagen über Hierarchieebenen in kontextuellen Klassen wie Agenten oder Orte. Besonders relevant ist diese Art der Modellierung bei hierarchischen Objekten, die aus Archiven kommen. Um diese Metadaten dem Ursprungsobjekt nachempfunden in EDM abbilden zu können, müssen zusätzliche Properties verfügbar gemacht oder Beschränkungen auf vorhandene Properties aufgehoben werden. Die Task Force empfiehlt in ihrem Abschlussbericht[10] daher unter anderem, dass Properties für Hierarchien bei Objekten wiederholt werden können, um unterschiedliche hierarchische Strukturen (zum Beispiel Seiten und Kapitel bei einem Buch) berücksichtigen zu können, oder dass Aussagen zu Hierarchien auch bei Webressourcen und kontextuellen Ressourcen gemacht werden können.

Die größte Herausforderung, vor der Europeana steht, ist – neben der Darstellung hierarchischer Objekte – die Integration unterschiedlicher Metadatenstandards, die aus diversen Quellen stammen und verwendet werden, um syntaktisch und semantisch heterogene Daten über Objekte des kulturellen Erbes zu sammeln. Derzeit existierende Metadaten-Schemata in diesem Bereich sind beispielsweise web-basierte Vokabulare wie Dublin Core[11], Katalogisierungsschemata in Bibliotheken wie MARC oder MODS, der Archivstandard EAD (Encoded Archival Description)[12] und Schemata zur Datenharmonisierung wie das CIDOC-CRM und FRBR.[13]Metadaten halten eine Schlüsselfunktion im effektiven Management von Ressourcen innerhalb von Informationssystemen inne, wobei Metadaten-Interoperabilität eine Voraussetzung für den einheitlichen Zugang zu Ressourcen in autonomen und heterogenen Informationssystemen ist.[14] Europeana begegnete dem in der Anfangsphase durch die Schaffung des ersten Schemas ESE. Dieser Ansatz stellte sich zwar als einfache und robuste Lösung heraus, doch brachte er Nachteile mit sich, auf die wir später genauer eingehen werden. Dies führte schließlich zu der Entwicklung eines neuen Modells, dem EDM. Dieses basiert auf den Prinzipien von Linked Data, welche einen neuen und vielversprechenden Weg darstellen, Problemen von Interoperabilität bei der Darstellung von Objekten des kulturellen Erbes zu begegnen.[15]Die Vorteile von EDM gegenüber ESE werden deutlich, wenn beide Möglichkeiten der Datenrepräsentation miteinander verglichen werden.

2 Der Wechsel von ESE zu EDM

Europeana benutzt das ESE-Schema seit November 2008.[16] Das Schema repräsentiert den kleinsten gemeinsamen Nenner zwischen den verschiedenen Metadaten-Standards, die zur Beschreibung der gelieferten Objekte an Europeana verwendet werden. Isaac und Haslhofer beschreiben ESE wie folgt: „[T]he Europeana Semantic Elements (ESE) XML Schema […] is essentially a flat record structure that uses the Dublin Core Element Set with some Europeana extensions.“[17]Das Modell strebt die Interoperabilität heterogener Metadaten mittels Zusammenfügen und Reduzieren der verschiedenen Metadatenstandards in ein einfaches Datenmodell an. Beispiel 1 stellt einen fiktiven Metadatensatz in ESE zur Beschreibung von Leonardo da Vincis Gemälde Mona Lisa dar.

<record>
<dc:creator>Leonardo da Vinci (Maler)</dc:creator>
<dc:title>La Joconde – Gioconda & Mona Lisa</dc:title>
<europeana:dataProvider>Bildarchiv Foto Marburg</europeana:dataProvider>
</record>

Beispiel 1: Ausschnitt eines Metadatensatzes in ESE.

Die Grundidee hinter ESE besteht in der Nutzung eines gemeinsamen Metadatenstandards, der so vereinfacht und generisch ist, dass alle gelieferten Metadaten durch ihn abgebildet werden können. Das Problem bei dieser Art der Modellierung ist, dass es nicht möglich ist, zusätzliche semantische Datenfelder zu integrieren, um die Granularitätsebene der Metadatensätze zu erweitern. Durch die vordefinierte feste Liste der möglichen Elemente für die Beschreibung von Metadaten ist ESE sehr unflexibel. Es besteht keine Möglichkeit Zusatzelemente hinzuzufügen, bestehende Elemente zu spezifizieren oder komplexe hierarchische Strukturen, wie beispielsweise in Monographien, formal zu beschreiben. Im ESE-Schema werden alle Inhalte der Datenlieferanten als Literale, also als Textstrings oder Zahlen, gespeichert.

Nachdem Europeana 2008 mit dem ESE-basierten Prototypen gestartet war, erwies es sich als ein weiteres Problem, dass ein Objekt von mehreren Datenlieferanten beschrieben sein kann. Es war nicht möglich, Duplikate verschiedener Datenlieferanten über ein und dasselbe Kulturerbe-Objekt mittels des ESE-Schemas zu differenzieren. Hinzu kam, dass sich viele Metadaten ohne eine Erweiterung des Schemas nicht eindeutig dem physischen Objekt oder dessen Digitalisat zuordnen ließen. Die Evaluation des ersten Prototyps zeigte deutlich, dass diese Probleme nicht mit dem aktuellen Datenmodell zu lösen waren.

Das EDM kann daher als logische und notwendige Weiterentwicklung des ESE-Schemas betrachtet werden. Die in ESE vorgenommene Reduktion und Vereinheitlichung heterogener Datenstandards wurde in EDM revidiert. Das neue Datenmodell ist als ein flexibles und semantisch erweiterbares Modell aufgebaut. Es ist offen und erlaubt sowohl die Spezialisierung durch Subrelationen als auch die Beschreibung von hierarchischen Strukturen. Dabei können im Datenmodell zum Beispiel Relationen vom digitalen Objekt auf seine Bestandteile oder auf seine Vor- und Nachfolgeobjekte mittels Properties wie dcterms:isPartOf und edm:isNextInSequence definiert werden. Darüber hinaus ist es in EDM möglich sowohl Literale als auch Ressourcen als Metadatenwerte zu modellieren und mehrere Aussagen zu einem Objekt zu speichern.[18] Dies wird in EDM durch das zugrunde liegende und vom W3C-Consortium entwickelte RDF-Framework[19] ermöglicht (siehe Abschnitt 4). Einer der Hauptgründe für die Entwicklung des RDF-Frameworks war, die Interaktion zwischen Programmen zu ermöglichen, die Daten aus unterschiedlichen Quellen innovativ miteinander kombinieren mit dem Ziel, neue Informationen zu generieren.[20] Dies wird mit dem EDM-Modell als gemeinsamen Datenformat für die Auszeichnung von Metadaten über Objekte aus dem Kulturerbe etabliert. Dadurch wird die Entwicklung von Anwendungen gefördert, die auf Basis von stark vernetzten Daten neue Wege der Datenrecherche ermöglichen.

Darüber hinaus ermöglicht das EDM die Beschreibung sowohl des Kontexts als auch die Abbildung von sehr detaillierten Angaben zu einem Objekt in Europeana. Auch für die Modellierung von komplexen Objekten stellt das EDM ausreichende Mittel zur Verfügung. Ein weiterer Vorteil von EDM ist die Möglichkeit der Datenanreicherung auf Objektebene. Jedes in EDM ausgezeichnete Objekt verfügt über eine eindeutige Ressource, die durch externes oder internes Verlinken kontextualisiert werden kann.

Durch das EDM wurde die Verarbeitung der gelieferten Metadaten grundlegend verändert. Das Modell enthält die notwendige Expressivität und Flexibilität, um die semantische Bedeutung der Metadaten verwertbar zu machen. Oftmals enthält ein Metadatensatz Angaben über die Erstellung und die Inhaberrechte sowohl für das physische Objekt als auch für das im Web vorhandene Digitalisat.[21] Diese unterschiedlichen Angaben können in EDM mittels Proxies (siehe Abschnitt 4) getrennt und eindeutig zugeordnet werden. Das EDM definiert darüber hinaus eine Reihe weiterer Klassen und Properties, die zur Beschreibung und Vernetzung der Daten (siehe Abschnitt 6) benutzt werden können, wodurch den Nutzern wiederum verbesserte Suchfunktionalitäten angeboten werden können.[22]

Im Juni 2013 wurden die ersten in EDM modellierten Daten nach Europeana geliefert. Seither werden sukzessive die in ESE ausgezeichneten Daten in EDM umgewandelt. Datenlieferanten können jedoch nach wie vor Daten in ESE liefern.

3 Die Entwicklung des neuen RDF-basierten Modells

Die erste Entscheidung hinsichtlich des neu zu entwickelnden Datenmodells war die Wahl der Repräsentationssprache für das Modell selbst. Der W3C-Standard RDF wurde als Definitionssprache für das neue Datenmodell EDM festgelegt. RDF ermöglicht die Modellierung von Daten in Form von Tripeln. Beispiel 2 zeigt einen in RDF modellierten Datensatz mit Informationen über ein CHO.

ex:MonaLisaPainting ex:wasPaintedBy ex:LeonardoDaVinci .
ex:MonaLisaPainting ex:hasLocation ex:Louvre .

Beispiel 2: Datensatz über das Mona-Lisa-Gemälde in Tripelform. “ex:” steht als Abkürzung für den Beispielnamensraum der Ressourcen.

Die Syntax einer RDF-Aussage ist vergleichbar mit der Syntax eines einfachen Satzes einer Subjekt-Verb-Objekt-Sprache. Die RDF-Tripel bestehen aus einem Subjekt, einem Prädikat und einem Objekt. Die natürlichsprachigen Aussagen: „Mona Lisa wurde von Leonardo da Vinci gemalt“ und „Mona Lisa befindet sich im Louvre“ sind äquivalent zu den in Beispiel 2 dargestellten RDF-Sätzen. Im Gegensatz zu der baumartigen Einordnung von XML-Daten liegt den RDF-Daten eine logische Strukturierung als gerichteter Graph zugrunde.

Die Subjekte und Prädikate eines Tripels müssen stets durch eine Ressource belegt werden. Ressourcen in RDF werden mittels URIs (Uniform Resource Identifiers) eindeutig identifiziert. URIs sind integraler Bestandteil des Linked-Data-Konzepts und werden von Berners-Lee, Fielding und Masinter als ein einfaches und robustes Werkzeug für die Identifizierung von einzelnen Tripel-Bestandteilen beschrieben.[23] Des Weiteren werden URIs durch eine standardisierte und hierarchisch geordnete URI-Syntax mit Spezifikationsrichtung von links nach rechts definiert. HTTP-URIs sind ein bekanntes Beispiel für URIs und werden in RDF benutzt. Eine HTTP-URI in RDF identifiziert eine Ressource eindeutig und besteht aus dem Namensraum und der ID der Ressource.

Die Objektposition eines Tripels dagegen kann sowohl durch eine Ressource als auch durch ein Literal belegt werden. In RDF können Ressourcen sowohl ein reales Objekt als auch ein abstraktes Konzept explizit repräsentieren. Die Nutzung von Ressourcen als Metadaten erlaubt weitere Aussagen über jede dieser Ressourcen, unabhängig davon, ob es sich um eine Webseite, ein physisches Objekt oder ein abstraktes Konzept handelt. Über die Ressource „ex:LeonardoDaVinci“ können weitere Aussagen getroffen werden wie Beispiel 3 zeigt:

ex:MonaLisaPainting ex:wasPaintedBy ex:LeonardoDaVinci .
ex:LeonardoDaVinci ex:livedDuring ex:Renaissance .

Beispiel 3: Zusatzaussage über die Ressource ex:LeonardoDaVinci in RDF.

In Europeana wird eine HTTP-URI für eine in EDM ausgezeichnete Ressource wie folgt aufgebaut:

http://data.europeana.eu/data/item/08501/E83B976C1E5BDFDB78F600B5206AD1FE300F141E

Alle EDM-Ressourcen sind über den Namensraum von Europeana http://data.europeana.eu/data/[24] referenzierbar, gefolgt von der lokalen ID wie beispielsweise item/08501/E83B976C1E5BDFDB78F600B5206AD 1FE300F141E. Zusammengefügt ergeben die beiden Teile in diesem Fall die URI für die Ressource „La Joconde – Gioconda & Mona Lisa“. Die URIs sind gemäß den Linked-Data-Prinzipien von Berners-Lee[25] referenzierbar und liefern bei einer „HTTP GET“-Serveranfrage entweder eine menschenlesbare HTML-Webpräsentation oder die maschinenlesbaren RDF-Daten zurück.[26]Ein entscheidender Aspekt mit Blick auf die Funktionalität ist, dass nicht nur menschliche Nutzer diese Art von Information interpretieren können, sondern auch Maschinen. Die Modellierung von RDF-basierten Daten führt sowohl zu einer höheren Flexibilität bei der Publikation von offenen und verteilten Daten, als auch zu einer vielfältigeren Wiederverwendung von Daten im Netz. Die Vernetzung und Wiederverwendung von verteilten und strukturierten RDF-Daten im Netz wird innerhalb der sogenannten Linked Open Data Cloud[27] sichtbar (siehe Abschnitt 6).

4 EDM als Ontologie

Ontologien als Wissensorganisationssysteme im Linked-Open-Data-Umfeld bauen auf der Graphenstruktur von RDF auf. Eine weit verbreitete Definition beschreibt Ontologien als eine „specification of a conceptualization“.[28] Mit anderen Worten: Eine Ontologie spezifiziert eine bestimmte Sichtweise auf eine Wissensdomäne und beschreibt, welche Entitäten dort existieren und wie sie sich zu einander verhalten. Ontologien bestehen im Kern aus Klassen und Relationen oder Eigenschaften (die auch Properties genannt werden): Klassen können dabei als Kategorien für Entitäten verstanden werden, während Properties die möglichen Beziehungen zwischen diesen Entitäten beschreiben. Zusammen bilden Klassen und Properties das Schema einer Ontologie. Entitäten, die einer Klasse zugewiesen werden, werden Instanzen (Individuen) dieser Klasse genannt. Verschiedene logische Konstrukte und Regeln sowie die Dokumentation der Bedeutung von Klassen und Properties sind weitere wichtige Elemente einer Ontologie.

Mit diesen Mitteln lassen sich komplexe Strukturen innerhalb einer Wissensdomäne – oder im Falle von „upper ontologies“ von mehreren Wissensdomänen übergreifend – abbilden. Ontologien sind dabei immer eine spezifische Sichtweise auf eine Wissensdomäne. Daher können verschiedene Ontologien die gleiche Wissensdomäne auf unterschiedliche Weise beschreiben. Das EDM ist eine solche spezifische Sichtweise auf die Wissensdomäne des kulturellen Erbes, für die es eine Reihe von Klassen und Properties zur Beschreibung von Objekten bereitstellt, die im Folgenden näher beschrieben werden.

Dem Datenmodell des EDM liegt RDF zugrunde, während zur Definition der Klassen und Properties in EDM das Resource Description Framework Schema (RDFS)[29] und Elemente aus der Web Ontology Language (OWL)[30] verwendet werden. Beide Ontologiesprachen basieren auf RDF und unterscheiden sich in ihrer Ausdrucksstärke: Während RDFS es erlaubt, einfache Hierarchien mit Klassen und Properties sowie einigen Einschränkungen zum Gebrauch dieser Elemente zu definieren, können mit OWL darüber hinaus teils sehr komplexe logische Konstrukte und Axiome erstellt werden. Dabei beschränkt sich das EDM jedoch weitestgehend auf RDFS.

Als Ontologie für das kulturelle Erbe stellt das EDM beispielsweise eine Klasse edm:ProvidedCHO für das zu beschreibende CHO zur Verfügung. Das Gemälde Mona Lisa von Leonardo da Vinci wäre eine Instanz dieser Klasse. Für die Person Leonardo da Vinci wiederum steht in EDM die Klasse edm:Agent bereit, die Personen aber auch Institutionen repräsentiert. Als eine der möglichen Relationen zwischen einer Instanz der Klasse edm:ProvidedCHO und einer Instanz der Klasse edm:Agent definiert das EDM schließlich die Property dcterms:creator. Diese Property, wie an dem Namensraumkürzel dcterms zu erkennen ist, stammt aus einer anderen Ontologie namens Dublin Core Terms.[31]Ein wichtiger Aspekt beim Aufbau von Ontologien ist die Wiederverwendung von bereits existierenden Klassen und Properties. Ermöglicht wird dies durch den im vorherigen Abschnitt beschriebenen URI-Mechanismus. Durch die Wiederverwendung von weitverbreiteten und etablierten Klassen und Properties wird die Interoperabilität der eigenen Daten erhöht. Dublin Core Terms, als eine sehr allgemein und einfach gehaltene Ontologie zur bibliografischen Beschreibung von Ressourcen im Web, ist hier ein Beispiel für eine wiederverwendete Ontologie in EDM. Das EDM verwendet darüber hinaus Elemente aus weiteren etablierten Ontologien wieder, darunter OAI-ORE[32], Dublin Core, SKOS[33] und FOAF.[34] Damit besteht das EDM als Ontologie aus einer Reihe von eigenen, neu definierten sowie übernommenen Klassen und Properties.

Im Folgenden gehen wir näher auf einige der wichtigsten Klassen und Properties in EDM ein.

Klassen und Properties in EDM

Einer der wichtigsten Unterschiede zum ESE-Schema ist die Verwendung von Klassen in EDM. Klassen dienen in EDM in erster Linie zwei Hauptzwecken: Die drei Kernklassen des EDM – edm:ProvidedCHO, ore:Aggregation und edm:WebResource – dienen zum einen dazu, klar zwischen dem beschriebenen Objekt, den aggregierten Metadaten zum CHO (einschließlich der Informationen zum Datenlieferanten) sowie den digitalen Repräsentationen vom CHO zu unterscheiden. Zum anderen dient eine Reihe von Klassen dazu, Entitäten, die im Zusammenhang mit dem CHO stehen, explizit zu modellieren: edm:Agent für Personen oder Institutionen, edm:Place für Orte, edm:TimeSpan für Zeitspannen, skos:Concept für Konzepte aus kontrollierten Vokabularen sowie edm:Event für Ereignisse. Abbildung 1 zeigt die vollständige Klassenhierarchie des EDM.

img7.jpg

Abbildung 1: EDM Klassenhierachie.[35]

Wie bereits erwähnt, repräsentiert die Klasse edm:ProvidedCHO das beschriebene Objekt und stellt daher die wichtigste Klasse im Modell dar. Im vorherigen Beispiel ist das Gemälde der Mona Lisa das beschriebene Objekt. Daher sind alle deskriptiven Informationen über das Gemälde an die Klasse edm:ProvidedCHO angehängt, wie beispielsweise der Erschaffer (mit der Property dcterms:creator), der Titel (mit der Property dc:title) oder der gegenwärtige Aufbewahrungsort (mit der Property edm:currentLocation) (vgl. Abbildung 2).

img8.jpg

Abbildung 2: Beispiel für die Klasse edm:ProvidedCHO: Das CHO mit dem Titel „Portrait of the Mona Lisa“ hat als Erschaffer ( creator) Leonardo da Vinci und der gegenwärtige physische Aufbewahrungsort ist der Louvre.

Eine Besonderheit des EDM ist die explizite Repräsentation des Metadatensatzes zum beschriebenen Objekt selbst. Wenn ein Datenlieferant eine Beschreibung eines Objekts in Form eines Metadatensatzes an Europeana liefert, wird nicht nur eine Ressource für das beschriebene Objekt erstellt, sondern auch eine Ressource für den Metadatensatz. Die Klasse dieser Ressource ist ore:Aggregation. [36] Wenn mehrere Objekte in einem Metadatensatz beschrieben sind, dann wird für jedes beschriebene Objekt eine eigene Ressource als Instanz der Klasse ore:Aggregation erstellt. Die ore:Aggregation ist mit edm:ProvidedCHO über die Property edm:aggregatedCHO verbunden.

Die ore:Aggregation „aggregiert” beziehungsweise hält alle Informationseinheiten zusammen, die in einem Metadatensatz zu einem physischen Objekt identifiziert werden können: das beschriebene Objekt, den Metadatensatz sowie verschiedene Arten von digitalen Repräsentationen und Sichten auf das Objekt. Die Klasse ore:Aggregation trägt verschiedene Informationen zum Metadatensatz, wie beispielsweise den Ersteller des Metadatensatzes, die Erstellungszeit, Informationen zu den Rechten am Metadatensatz, Verweise auf Bilder zum beschriebenen Objekt, aber auch Informationen darüber, wer die Daten aggregiert und an Europeana geliefert hat. Gerade in einem Kontext wie Europeana, wo sehr viele verschiedene Metadatensätze über Objekte aggregiert werden, ist die Nachvollziehbarkeit von Provenienz, also in diesem Fall wer wann welche Metadatensätze geliefert hat, sehr wichtig.

Mit ore:Aggregation ist darüber hinaus die Klasse edm:WebResource verbunden. Web-Ressourcen können jede Art von digitaler Repräsentation oder Sicht im Web auf das Objekt sein. Im vorliegenden Beispiel könnten dies beispielsweise Thumbnails zum Gemälde der Mona Lisa, eine HTML-Seite zum Gemälde auf der Webseite des Louvre oder ein Video zum Gemälde sein. Die Property edm:hasView verbindet edm:WebResource mit ore:Aggregation. Ähnlich wie im Fall von edm:ProvidedCHO und ore:Aggregation können auch Web-Ressourcen mit eigenen expliziten Aussagen versehen werden, beispielsweise mit Informationen darüber, wer die Rechte an dieser Web-Ressource innehat (vgl. Abbildung 3).

img9.jpg

Abbildung 3: Beispiel einiger Klassenrelationen in EDM: Der Louvre hält die Rechte an der Web-Ressource zur Mona Lisa.

Unterschiedliche Sichtweisen auf dasselbe CHO

Die Klasse ore:Proxy ist eine Besonderheit des EDM und trägt viel zur Flexibilität des Modells bei. Der Proxy wird verwendet, um die Provenienz von deskriptiven Metadaten verschiedener Herkunft über dasselbe Objekt nachzuvollziehen. Das ist in Fällen wichtig, wo verschiedene Datenlieferanten Metadatensätze über dasselbe Objekt an Europeana liefern, wie beispielsweise im Fall der Mona Lisa.[37] In derartigen Fällen werden von Europeana Proxies für jeden Metadatensatz erstellt und dann alle deskriptiven Metadaten des CHO auf den jeweiligen Proxy übertragen. Durch diesen Ansatz ist es möglich, zwei unterschiedliche Beschreibungen zu demselben Objekt auseinanderzuhalten, da jede Beschreibung von einem Datenlieferanten ihren eigenen Proxy hat. Insofern sind auch sich widersprechende Aussagen über ein Objekt möglich. Das EDM folgt hier der „open-world assumption“, die auch RDF und OWL zugrunde liegt und besagt: „Anyone can make statements about any resource.“[38]

5  Metadateninteroperabilität und Anwendungen des EDM

Datenlieferanten müssen, um ihre Metadaten Europeana zur Verfügung zu stellen, Kompatibilität zwischen den ursprünglich vorliegenden Metadatenstandards und dem EDM herstellen. Dies kann zum einen als Mapping gelöst werden, indem für jedes Metadatenelement ein entsprechendes Element in EDM gesucht und als äquivalent zum Element des Datenlieferanten gekennzeichnet wird. Zum anderen können Datenlieferanten das EDM an bestimmten Stellen, an denen es für eine spezifische Anwendung nicht granular genug ist, erweitern beziehungsweise verfeinern oder das EDM in ihre eigenen Datenmodelle einbauen. Wir sprechen daher über Erweiterungen (EDM extensions) so wie Verfeinerungen des EDM (EDM refinements). An dieser Stelle sei darauf hingewiesen, dass eine Spezialisierung des EDM, so wie DM2E diese definiert, eine Kombination aus Erweiterung und Verfeinerung ist, da das DM2E-Modell EDM-Elemente zwar erweitert, also neue Elemente hinzufügt, dies aber immer soweit möglich als Verfeinerung eines existierenden EDM-Elements geschieht.[39] Auf diese Weise wurde das EDM im Laufe verschiedener Europeana-verwandter Projekte angewandt, wiederverwendet und in andere Ontologien integriert.

Da das EDM als Harmonisierungsschema erdacht wurde, das alle in Europeana vorkommenden Metadatenstandards abbilden kann, ist das Modell in generischem Sinne den ESE ähnlich. Mittels der Graphenstruktur des EDM können auch die vorher erwähnten Erweiterungen oder Verfeinerungen des EDM definiert werden. Zum Beispiel kann die Property dc:creator, die ein Teil des EDM ist, durch das Hinzufügen einer Subproperty ex:writer oder ex:painter verfeinert, also genauer definiert und beschrieben werden. Dies ermöglicht es, Leonardo da Vinci als den Maler der Mona Lisa zu definieren und ihn nicht nur als den Erschaffer ( dc:creator) zu beschreiben (vgl. Beispiel 5).

ex:MonaLisa

a ore:Aggregation ;

edm:aggregatedCHO ex:MonaLisa ;

edm:provider ex:Louvre .

ex:MonaLisa

a edm:ProvidedCHO ;

ex:painter ex:LeonardoDaVinci ;

dc:title “Portrait of the Mona Lisa”@en .

ex:Louvre

a ex:Organization ;

skos:prefLabel “Louvre”@en .

ex:LeonardoDaVinci

a ex:Person ;

skos:prefLabel “Leonardo da Vinci”@en .

Beispiel 5: Beispiel für eine EDM-Spezialisierung: da Vinci ist nicht nur als Erschaffer sondern genauer als Maler der Mona Lisa spezifiziert.

Auch die Mona Lisa kann genauer spezifiziert werden: als Gemälde ( ex:painting) und nicht nur als kulturelles Objekt ( edm:ProvidedCHO). Dieses Beispiel verdeutlicht, wie das EDM Metadaten-Interoperabilität ermöglicht: Das EDM gibt eine generische Modellierungsebene vor, die nach Bedarf um beliebig viele verfeinerte untergeordnete Ebenen erweitert werden kann.

In den folgenden Abschnitten werden drei Projekte kurz vorgestellt, die EDM als Grundlage für die Schaffung eines eigenen Datenmodells verwendet oder das EDM erweitert, verfeinert oder spezialisiert haben.

Das Anwendungsprofil der Deutschen Digitalen Bibliothek

Die Deutsche Digitale Bibliothek[40] (DDB) ist der zentrale Zugangspunkt zu digitalen kulturellen und wissenschaftlichen Objekten in Deutschland. Sie kann daher als ein nationales Europeana für Deutschland bezeichnet werden. Die DDB umfasst derzeit circa 5,7 Millionen Objekte aus Gedächntisinstitutionen in Deutschland. Metadaten zu diesen Objekten, die mit einer CC0-Lizenz ausgezeichnet sind, wird die DDB in naher Zukunft auch über das Portal Europeana zur Verfügung stellen. Um die Lieferung der Daten an Europeana zu vereinfachen, hat die DDB ein Datenmodell und ein Anwendungsprofil (Application Profile) entwickelt, deren Grundlage das EDM ist, dieses jedoch erweitert, um so den spezifischen Anforderungen der DDB zu entsprechen.

Die Anforderungen der DDB an das Modell ergeben sich aus den Funktionen, die die in EDM vorliegenden Metadaten für das Portal haben. Die EDM-Daten in der DDB

  • sind Grundlage für die Facettierung,

  • dienen dazu, die hierarchische Gliederung von Objekten abzubilden,

  • ermöglichen die Verlinkung von Normdaten mit Objektbeschreibungen,

  • sind über eine OAI-PMH-Schnittstelle und eine Open API veröffentlicht.

Die Facetten ermöglichen es den Nutzern der DDB, ihre Suche anhand bestimmter Kategorien einzuschränken. Die DDB bietet zurzeit die folgenden Kategorien beziehungsweise Facetten an: Zeit, Ort, Person/Organisation, Stichwort, Sprache, Medientyp, Sparte und Datenlieferant (vgl. Abbildung 4).

img10.jpg

Abbildung 4: Beispiel der Facettensuche der Deutschen Digitalen Bibliothek

Diese Facetten ergeben sich aus der Zuordnung der von den Datenlieferanten bereitgestellten Daten zu einer bestimmten Klasse des EDM. So sind alle Einträge, die der Klasse edm:Place zugewiesen sind, in der Facette Ort zu finden, unabhängig davon, ob es sich um den Ort der Veröffentlichung, der Herstellung oder den im Objekt abgebildeten Ort handelt.

Im nächsten Schritt wird die DDB diese Facetten auf der Grundlage der verwendeten EDM-Properties und LIDO-Klassen[41] verfeinern und den Nutzern so die Möglichkeit geben, zu unterscheiden, ob sie zum Beispiel nach dem Ort der Veröffentlichung, der Herstellung oder dem abgebildeten Ort suchen. Gleichzeitig werden sie mit Hilfe der EDM-Klasse edm:Place aber auch weiterhin die Möglichkeit haben, die Suche ganz allgemein auf Orte einzuschränken.

Neben den Facetten verwendet die DDB das EDM auch, um die hierarchische Gliederung kultureller Objekte darzustellen. Für die Abbildung hierarchischer Strukturen in zusammengehörigen Bibliotheksobjekten (Compound Library Objects), die in den Formaten METS/MODS und MARCXML vorliegen, und für die Darstellung von Hierarchien in archivalischen Beständen, die in EAD geliefert werden, verwendet die DDB die in EDM vorgeschriebene Dublin Core Property dcterms:isPartOf. Um die richtige Zuordnung der Objekte in der DDB anzeigen zu können, hat die DDB eine eigene Property definiert, die ddb:hierarchyPosition. Und um dem Nutzer deutlich zu machen, auf welcher Hierarchieebene er sich im Objekt befindet, beschreibt die Property ddb:hierarchyType die Art der hierarchischen Ebene (mögliche Werte sind hier zum Beispiel Band, Heft, Aufsatz). Neben den DDB-spezifischen Elementen liefert die DDB aber auch die im EDM definierte Property edm:isNextInSequence, um die Kompatibilität mit Metadaten des Europeana-Portals sicherzustellen.

Das Anwendungsprofil der Digital Public Library of America

Mittlerweile hat das EDM es geschafft, nicht nur in europäischen digitalen Bibliotheken Einfluss auf die Metadatenmodellierung zu nehmen, sondern ist auch in der amerikanischen Digital Library Community auf Interesse gestoßen. Das Anwendungsprofil der Digital Public Library of America (DPLA) basiert nämlich auf dem EDM, bedient aber gleichzeitig spezielle Anforderungen der DPLA-Community. Es kann somit als Verfeinerung des EDM bezeichnet werden. Die aktuelle Version des DPLA-Anwendungsprofils[42] verwendet verschiedene Klassen und Properties aus folgenden kontrollierten Vokabularen:

  • RDF und RDFS

  • OAI-ORE

  • EDM

  • Dublin Core namespaces ( dcelements, dcterms und dcmitype)

  • Basic Geo (WGS84 lat/long) Vocabulary [43]

In den DPLA-Kernklassen finden sich die zwei EDM-Kernklassen wieder: edm:WebResource und ore:Aggregation; sowie eine DPLA-spezifische Klasse dpla:SourceResource, die allerdings auch als Unterklasse der EDM-Klasse edm:ProvidedCHO definiert und somit vollends kompatibel mit dem EDM ist. Properties, die dem realen Objekt zugeordnet werden und nicht der digitalen Repräsentation, werden an dpla:SourceResource angehängt. In der Klasse ore:Aggreation hat die DPLA dpla:originalRecord als Subproperty von ore:aggregates definiert, die verwendet werden soll, um den Originaleintrag zu beschreiben.

Das DM2E-Modell

Das DM2E-Modell[44] ist eine im DM2E-Projekt[45] entwickelte Spezialisierung des EDM für (handgeschriebene) Manuskripte. Es ermöglicht beispielsweise semantisch korrekte Mappings von Objekten aus dem Wittgenstein-Archiv[46] und dem Deutschen Textarchiv[47], die bisher nicht in Europeana repräsentiert waren. Das DM2E-Modell erweitert und spezialisiert das EDM, um die Manuskripte akkurat und in ihrem semantischen Kontext darstellen zu können. Die EDM-Kernelemente wurden dabei nicht verändert, aber um Klassen wie zum Beispiel bibo:Book[48], bibo:Journal oder dm2e:Manuscript erweitert. Die hinzugefügten Klassen wurden soweit möglich aus anderen Vokabularen herangezogen und folgen somit den Wiederverwendungsrichtlinien des EDM. Das DM2E-Modell spezialisiert insbesondere EDM-Elemente, die genauere Auskunft über die Beziehung zwischen dem Erschaffer und seinem kulturellen Objekt geben (vgl. pro:author in Beispiel 6) oder die speziell auf Manuskripte zugeschnitten sind (zum Beispiel beschreibt dm2e:incipit die Anfangsworte eines Manuskripts). Das folgende Beispiel 6 zeigt wie das EDM im Rahmen von DM2E spezialisiert wurde, um ein Manuskript Wittgensteins zu beschreiben.

Das aktuelle Modell kann über den DM2E-Namensraum[49] abgerufen werden. Die genauen Spezifikationen sowie Mapping-Empfehlungen sind im DM2E-Wiki[50] zu finden. Es gibt bereits einige Datensammlungen, die auf das DM2E-Modell gemappt wurden. Diese Mappings werden nun dazu verwendet, das Modell weiter zu verfeinern und anschließend zu evaluieren. Die DM2E-Daten werden am Ende des Projekts in RDF unter der Creative-Commons-Lizenz CC0 1.0 zur Verfügung stehen und können über einen SPARQL-Endpoint[51] abgefragt werden.

Die Analyse der Mappings im Rahmen des DM2E-Projektes wird zeigen, ob das Modell weiterentwickelt werden muss oder ob es den Anforderungen der Datenlieferanten und Nutzer genügt. Grundsätzlich ist das Modell in der Lage die von den Partnern im DM2E-Projekt bereitgestellten Manuskripte zu beschreiben. In einigen Aspekten ist das Model sehr detailliert (etwa bei Properties für Wasserzeichen oder Incipits), während andere Aspekte für Manuskripte anderer Institutionen, welche Metadaten für Manuskripte produzieren und keine Anforderungen an das Modell gestellt haben, noch spezialisiert werden könnten. Formate, die derzeit noch nicht gemappt wurden, wie der Archivstandard EAD, müssen ebenfalls in der Weiterentwicklung berücksichtigt werden.

dm2edata:aggregation/uib/wittgenstein/Ms-114
a ore:Aggregation ;
edm:aggregatedCHO dm2edata:item/uib/wittgenstein/Ms-114 .

dm2edata:item/uib/wittgenstein/Ms-114
a edm:ProvidedCHO ;
dc:type dm2e:Manuscript ;
edm:type “TEXT” ;
dc:title “Philosophische Grammatik”@de ;
bibo:isbn “978-3-86680-192-9” .

pro:author dm2edata:agent/uib/authority_gnd/118634313
a foaf:Person ;
skos:prefLabel “Ludwig Wittgenstein”@de ;
owl:sameAs <http://d-nb.info/gnd/118634313> .

Beispiel 6: Beispiel für eine EDM-Spezialisierung: Wittgenstein-Daten im DM2E Modell.

6 Verlinkung zu anderen Ressourcen

Einer der wichtigsten Vorteile in der Nutzung des EDM besteht darin, dass das zugrundeliegende RDF es ermöglicht, semantische Netze zu erstellen. Das prominenteste Beispiel für ein solches semantisches Netz ist die Linked Open Data Cloud (LOD Cloud).[52] In dieser stehen Hunderte von Datenquellen zur freien Verfügung, die sich wiederum auf Billionen RDF-Tripel belaufen. Jede dieser Ressourcen lässt sich mit anderen Ressourcen verbinden. Beispiele für Datenquellen in der LOD-Cloud sind Vokabulare über Personen wie VIAF[53], über Orte wie Geonames[54] oder Informationen aus DBpedia[55], der RDF-Repräsentation von Wikipedia.

Das in diesem Beitrag vorgestellte Beispiel, das Gemälde der Mona Lisa, ließe sich auf einfache Weise mit einer Ressource in der LOD-Cloud verknüpfen. Beispielweise könnte ein Verweis zum Eintrag auf Leonardo da Vinci in VIAF erstellt werden, da sich dort zusätzliche Informationen über da Vinci finden, die im ursprünglichen Datensatz nicht enthalten sind, wie zum Beispiel sein Geburtsdatum oder Orte, an denen er gearbeitet hat. Diese Ressource über da Vinci in VIAF könnte wiederum mit Ressourcen aus anderen Vokabularen verbunden werden. Zurzeit sind Metadatensätze in Europeana nicht miteinander verbunden, was sich in Zukunft sicherlich ändern wird – nicht zuletzt durch Projekte wie DM2E, die an der Kontextualisierung von Daten arbeiten. Eine solche Kontextualisierung lässt sich beispielsweise mithilfe des Tools SILK durchführen,[56] welches in der Lage ist, Beziehungen zwischen Ressourcen aus unterschiedlichen LOD-Quellen zu ermitteln und automatisch anzureichern. In DM2E werden auf diesem Wege Personendaten, Orte und Themen (subjects) automatisch mit anderen LOD-Ressourcen angereichert.

Die in Europeana enthaltenen Daten sind derzeit nicht über die jeweiligen URIs dereferenzierbar. Dieses LOD-Prinzip konnte noch nicht für alle Daten umgesetzt werden, jedoch wird ein Ausschnitt der EDM-Daten über einen LOD-Piloten zugänglich gemacht.[57] Dieser Ausschnitt umfasst 2,4 Millionen Objekte von acht Datenlieferanten und wurde im Februar 2012 bereitgestellt.[58] Das Pilotprojekt sollte zeigen, dass die RDF-basierten EDM-Daten als LOD veröffentlicht werden können. Die Bereitstellung aller EDM-Daten für die Weiterverarbeitung in externen Anwendungen geschieht jedoch nicht über den LOD-Weg, sondern über eine ebenfalls angebotene JSON-basierte API.[59] Für diese Schnittstelle benötigen Entwickler einen Schlüssel, den sie bei Europeana anfordern können. Die Daten können einfach für weitere Anwendungen genutzt werden, sind jedoch nicht mehr RDF-basiert und büßen somit die Vorteile ein, die RDF bietet (wie beispielsweise die zuvor genannte Kontextualisierung). Dies ist nur mit Daten des LOD-Pilots möglich.

7 Fazit

Die auf den Prinzipien von Linked Data basierende Modellierung macht das EDM zu einem erweiterbaren und flexiblen Datenmodell, mit welchem heterogene Daten jeglicher Art integriert und dargestellt werden können. Es erlaubt die Einbindung und Anpassung sehr komplexer (objektzentrierter wie auch ereigniszentrierter) und deskriptiver (Metadaten-)Standards wie TEI, METS/MODS, EAD, LIDO und CIDOC CRM.

Zahlreiche andere Institutionen, unter anderem die hier vorgestellte DDB und DPLA, bauen auf den Erfahrungen von Europeana auf und erstellen eigene Anwendungsprofile, die auf dem EDM basieren. Auch wenn diese Anwendungsprofile zum jetzigen Zeitpunkt in ihrer Vollständigkeit in Europeana noch nicht dargestellt werden können, zeigen sie, dass das EDM als Harmonisierungsschema für den gesamten Kulturerbesektor geeignet ist, da es Bibliotheken, Archiven, Galerien und Museen ermöglicht, neue Datenmodelle auf ihre Ressourcen anzupassen.

Die Schaffung neuer Funktionalitäten, die durch das EDM ermöglicht werden, erlauben es Nutzern neuartige Suchanfragen zu stellen wie: „Gib mir alle Bilder, die eine bestimmte Person darstellen“ oder „Gib mir alle Bilder, die sich in Paris befinden und sortiere diese nach Museum“. Zum jetzigen Zeitpunkt können derartige Suchanfragen in Europeana noch nicht durchgeführt werden, jedoch ist mit der Einführung des EDM ein Schritt in die richtige Richtung getan, da es Nutzern von Europeana zukünftig verbesserte Suchmöglichkeiten bieten wird.

Zahlreiche Projekte im Umfeld von Europeana führen ebenfalls Spezialisierungen des EDM durch, die ebenso wie das DM2E-Modell nachgenutzt werden können, und erforschen neuartige semantische Suchfunktionalitäten, die durch die mit EDM modellierten Daten eröffnet werden. Das Projekt Europeana v2.0 beispielsweise arbeitet an einer Verbesserung, Erweiterung und erleichterten Wiederverwendbarkeit von Inhalten sowie am Ausbau von Funktionalitäten und der damit einhergehenden Verbesserung der Nutzererfahrung.[60] Durch diese und ähnliche Weiterentwicklungen werden Europeana und das EDM kontinuierlich verbessert.

Die Semantic-Web-Technologien und LOD-Prinzipien ermöglichen die Veröffentlichung und somit Wiederverwendung von strukturierten Daten durch Drittentwickler und Endnutzer. Mit der Entwicklung des EDM, das auf diesen Technologien und Prinzipien basiert, sowie der Veröffentlichung seines LOD-Piloten, hat Europeana die Grundlage geschaffen, Daten und Objekte des Kulturerbesektors in einen semantischen, institutionsübergreifenden Kontext zu bringen.[61]


Zu den Autoren

Evelyn Dröge (geboren 1985 in Essen) studierte Informationswissenschaft und Sprachtechnologie an der Heinrich-Heine-Universität Düsseldorf. In ihrer Masterarbeit befasste sie sich mit Anwendungen im Social Semantic Web. Seit März ist sie 2012 wissenschaftliche Mitarbeiterin am Institut für Bibliotheks- und Informationswissenschaft an der Humboldt-Universität zu Berlin. Dort ist sie im Projekt „Digitised Manuscripts to Europeana“ (DM2E) für den Aufbau des DM2E-Modells, einer Spezialisierung des Europeana Data Models (EDM), und Mappings zu dem Modell zuständig. In ihrem Dissertationsvorhaben befasst sie sich mit der Evaluation von automatisierten Verfahren im Mapping von Ontologien.

Steffen Hennicke (geboren 1979) studierte Geschichts-, Politik- und Medienwissenschaften an der Universität Potsdam, University of Sussex und Freien Universität Berlin. Von 2007 bis 2009 entwickelte er Software für Archive, Bibliotheken und Museen. 2009 bis 2011 war er wissenschaftlicher Mitarbeiter am Institut für Bibliotheks- und Informationswissenschaft der Humboldt-Universität zu Berlin im EU-Projekt „EuropeanaConnect“ – Entwicklung und Evaluierung des „Europeana Data Model“ (EDM); seit 2012 ist er im EU-Projekt „Digitised Manuscripts to Europeana“ (DM2E). In seinem Dissertationsvorhaben beschäftigt er sich mit der Frage, wie Nutzerbedürfnisse aus natürlichsprachlichen Anfragen an Archive abgebildet werden können.

Julia Iwanowa (geboren 1976 in Bulgarien) studierte historisch-kulturwissenschaftliche Informationsverarbeitung, Germanistik und Slawistik an der Universität zu Köln. Den Schwerpunkt ihrer Forschungstätigkeit legte sie bereits in ihrer Magisterarbeit auf die Modellierung von Daten mithilfe von gerichteten Graphen. Als wissenschaftliche Mitarbeiterin in mehreren Forschungsprojekten – „Prometheus – das verteilte digitale Bildarchiv“, „OA-Netzwerk“ und „Digitised Manuscripts to Europeana (DM2E)“ – spezialisierte sie sich auf den Forschungsfeldern Ontologie-Entwicklung, Semantic Web und Linked Data. Sie ist wissenschaftliche Mitarbeiterin an der Humboldt-Universität zu Berlin, und arbeitet an der Entwicklung des DM2E-Modells, Datenanalyse sowie XSLT-Mappings.

Marlies Olensky (geboren 1981 in Wien) studierte am Fachhochschul-Studiengang Informationsberufe in Eisenstadt, Österreich. 2009-2014 war sie wissenschaftliche Mitarbeiterin an der Humboldt-Universität zu Berlin, Institut für Bibliotheks- und Informationswissenschaft, im Projekt Europeana in den Bereichen semantische Suche, Metadaten-Enrichment und Europeana Data Model. 2011 war sie Local Organizing Chair der International Conference on Theory and Practice of Digital Libraries in Berlin. Seit Mitte 2013 Forschungsaufenthalt an der National Taiwan University. Ihre Dissertation untersucht die Datenqualität in bibliometrischen Datenbanken (Abschluss Ende 2014).

Dr. Violeta Trkulja (geboren 1974) studierte an der Heinrich-Heine-Universität Düsseldorf Ältere und Neuere Deutsche Philologie und Informationswissenschaft. 2002-2008 war sie wissenschaftliche Mitarbeiterin in der Abteilung für Informationswissenschaft der Heinrich-Heine-Universität Düsseldorf. Sie promovierte zum Thema „Digitale Kluft“ am Beispiel von Bosnien und Herzegowina. Seit April 2010 an der Humboldt-Universität zu Berlin, zunächst im Bereich Antragstellung für die Exzellenzinitiative, ab März 2012 am Institut für Bibliotheks- und Informationswissenschaft. Hier koordiniert sie das von der EU geförderte Projekt „Digitised Manuscripts to Europeana“ und beschäftigt sich darüber hinaus auch mit der Spezialisierung des Europeana Data Models (EDM).

Stefanie Rühle (geboren 1966 in Preetz) hat einen Magister in Osteuropäischer Geschichte, Slavistik und Germanistik sowie ein Diplom in Bibliothekswissenschaften. Sie ist Mitarbeiterin der Niedersächsischen Staats- und Universitätsbibliothek Göttingen und seit 2010 in der Gruppe Metadaten und Datenkonversion für die Lieferung von METS/MODS-Daten an das Zentrale Verzeichnis Digitalisierter Drucke (zvdd) und an die Deutsche Digitale Bibliothek (DDB) zuständig. Stefanie Rühle ist seit 2008 Mitglied verschiedener Dublin-Core-Arbeitsgruppen und seit 2010 Co-Chair der DINI AG KIM. Seit 2011 beschäftigt sie sich außerdem – zunächst im Rahmen von Europeana Libraries, später für die DDB – mit der Entwicklung von EDM-Anwendungsprofilen und EDM-Mappings.


  1. Vgl. Europeana Homepage, http://europeana.eu (Letzter Aufruf: 24.09.2014).
  2. Concordia, C./Gradmann, S./Siebinga, S.: Not just another portal, not just another digital library: A portrait of Europeana as an application program interface. In: IFLA Journal 36 (1) (2010), S. 61-69.
  3. Content, Europeana Professional Webseite, http://www.pro.europeana.eu/web/guest/content (Letzter Aufruf: 24.09.2014).
  4. Isaac, A./Haslhofer, B.: Europeana Linked Open Data – data.europeana.eu. In: Semantic Web 4 (3) (2013), S. 291-297.
  5. Berners-Lee, T.: Linked Data. 2009. W3C Webseite, letzte Aktualisierung: 18.06.2009. http://www.w3.org/DesignIssues/LinkedData.html (Letzter Aufruf: 29.09.2013).
  6. Berners-Lee, T./Fielding, R. T./Masinter, L.: Uniform Resource Identifier (URI): Generic Syntax. 2005. http://tools.ietf.org/html/rfc3986 (Letzter Aufruf: 29.09.2014).
  7. Schreiber, G./Raimond, Y.: RDF 1.1 Primer. W3C Working Group Note 25 February 2014. W3C Webseite. http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/ (Letzter Aufruf: 29.09.2013).
  8. Für einen Überblick siehe http://pro.europeana.eu/web/guest/projects (Letzter Aufruf: 24.09.2014).
  9. Liste unter http://pro.europeana.eu/web/guest/network/task-forces (Letzter Aufruf: 24.09.2014).
  10. Bardi, A./Kupietzky, A./Isaac, A./Matei, D./Weber, D./Arnold, K./Martinzez Conde, M. L./Fingerhut, M./Clayphan, R./Bailly, R./Rühle, S./Charles, V./Agenjo, X.: Recommendations for the representation of hierarchical objects in Europeana. Europeana Professional Webseite. 2013. http://pro.europeana.eu/documents/468623/4a6eb2ec-4cc6-48b1-8824-92a1e564a279 (Letzter Aufruf: 24.09.2014).
  11. Dublin Core (DC) Namensraum. Purl Webseite, http://purl.org/dc/elements/1.1/. Dublin Core Metadata Element Set, Version 1.1., veröffentlicht am 14.6.2012. http://dublincore.org/documents/dces/ (Letzter Aufruf: 24.09.2013).
  12. Vgl. http://www.loc.gov/ead/ (Letzter Aufruf: 24.09.2014).
  13. Hyvönen, E.: Publishing and Using Cultural Heritage Linked Data on the Semantic Web. Synthesis Lectures on the Semantic Web. Theory and Technology (Bd. 3). Palo Alto 2012.
  14. Haslhofer, B./Klas, W.: A survey of techniques for achieving metadata interoperability. In: ACM Computing Surveys, 42 (2) (2010), S. 1-37; Duval, E./Hodgins, W./Sutton, S./Weibel, S. L.: Metadata Principles and Practicalities. In: D-Lib Magazine, 8 (4) (2002). http://www.dlib.org/dlib/april02/weibel/04weibel.html (Letzter Aufruf: 24.09.2014).
  15. Hyvönen, E.: Publishing and Using Cultural Heritage Linked Data on the Semantic Web. Synthesis Lectures on the Semantic Web. Theory and Technology (Bd. 3). Palo Alto 2012, S. 6.
  16. Europeana Professional Webseite: Europeana Semantic Elements Specification and Guidelines. 2013. http://pro.europeana.eu/documents/900548/2eee7beb-b9d8-4532-a089-8e8d6df38ce7 (Letzter Aufruf: 24.09.2014).
  17. Isaac, A./Haslhofer, B.: Europeana Linked Open Data – data.europeana.eu. In: Semantic Web 4 (3) (2013), S. 291-297, S. 293.
  18. Auf Ressourcen wird im folgenden Abschnitt detailliert eingegangen.
  19. Cyganiak, R./Wood, D./Lanthaler, M.: RDF 1.1 Concepts and Abstract Syntax. 2014. W3C Webseite. http://www.w3.org/TR/rdf11-concepts/ (Letzter Aufruf: 03.04.2014).
  20. Klyne, G./Carroll, J. J.: Resource Description Framework (RDF): Concepts and Abstract Syntax. 2004. W3C Webseite. http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ (Letzter Aufruf: 25.11.2013).
  21. Europeana Professional Webseite: Europeana Data Model Primer. 2013. http://pro.europeana.eu:9580/documents/900548/770bdb58-c60e-4beb-a687-874639312ba5 (Letzter Aufruf: 03.04.2014).
  22. Gradmann, S.: Knowledge = Information in Context: on the Importance of Semantic Contextualisation in Europeana (Europeana White Paper No. 1). 2010. Europeana Professional Website. (Letzter Aufruf: 03.04.2014).
  23. Berners-Lee, T./Fielding, R. T./Masinter, L.: Uniform Resource Identifier (URI): Generic Syntax. Technical Report 3986, Internet Engineering Task Force, RFC 3986. 2005. http://tools.ietf.org/html/rfc3986 (Letzter Aufruf: 03.04.2014).
  24. In EDM werden die beschreibenden Elemente (Klassen und Properties, für Details siehe Abschnitt 5) und die zu beschreibenden Metadaten durch zwei unterschiedliche Namensräume repräsentiert. Der oben angeführte Namensraum http://data.europeana.eu/data/ wird für die eigentlichen Metadaten verwendet. Der Namensraum der beschreibenden Klassen und Properties ist http://www.europeana.eu/schemas/edm/.
  25. Berners-Lee, T.: Linked Data. 2009. W3C Webseite. http://www.w3.org/DesignIssues/LinkedData.html (Letzter Aufruf: 09.04.2013).
  26. Weitere Beispiele und eine ausführliche technische Dokumentation finden sich auf der „Europeana Professional“-Webseite: http://pro.europeana.eu/tech-details (Letzter Aufruf: 03.04.2014).
  27. Jentzsch, A./Cyganiak, R./Bizer, C.: State of the LOD Cloud. 2011. http://lod-cloud.net/state/ (Letzter Aufruf: 08.04.2014).
  28. Gruber, T. R.: Toward principles for the design of ontologies used for knowledge sharing. In: Int. J. Human-Computer Studies 43 (5-6) (1995), S. 907-928, S. 908.
  29. Brickely, D./Guha, R. V.: RDF Schema 1.1. 2014. W3C Website. http://www.w3.org/TR/rdf-schema/ (Letzter Aufruf: 09.04.2014).
  30. Hitzler, P./Krötzsch, M./Parsia, B./Patel-Schneider, P. F./Rudolph, S.: OWL 2 Web Ontology Language. Primer (Second Edition). 2012. W3C Webseite. http://www.w3.org/TR/2012/REC-owl2-primer-20121211/ (Letzter Aufruf: 25.11.2013). Die aktuelle OWL Version des EDM auf Europeana Labs: http://europeanalabs.eu/browser/europeana/trunk/corelib/corelib-solr-definitions/src/main/resources/eu/rdf/edm.owl (Letzter Aufruf: 25.11.2013).
  31. DCT (Dublin Core Terms) Namensraum, http://purl.org/dc/terms/ (Letzter Aufruf: 09.04.2014).
  32. OAI-ORE (OAI Object Reuse and Exchange) Namensraum, http://www.openarchives.org/ore/terms/ (Letzter Aufruf: 04.12.2013).
  33. SKOS (Simple Knowledge Organization System) Namensraum, http://www.w3.org/2004/02/skos/core# (Letzter Aufruf: 04.12.2013).
  34. FOAF (Friend of a Friend ontology) Namensraum, http://xmlns.com/foaf/0.1/ (Letzter Aufruf: 04.12.2013).
  35. Europeana Professional Webseite: Europeana Data Model Primer. 2013. http://pro.europeana.eu/documents/900548/770bdb58-c60e-4beb-a687-874639312ba5 (Letzter Aufruf: 03.04.2014).
  36. „ore“ ist das Präfix für den OAI-ORE Namensraum.
  37. Ausführlicher beschrieben im EDM Primer: Europeana Professional Webseite: Europeana Data Model Primer. 2013. http://pro.europeana.eu:9580/documents/900548/ 770bdb58-c60e-4beb-a687-874639312ba5 (Letzter Aufruf: 03.04.2014).
  38. Klyne, G./Carroll, J. J.: Resource Description Framework (RDF): Concepts and Abstract Syntax. 2004. http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ (Letzter Aufruf: 25.11.2013).
  39. Ausnahmen sind zusätzliche Properties wie dm2e:hasAnnotatableContent, die für die Anzeige von Objekten verwendet wird, die mittels eines zusätzlichen Tools annotiert werden können. Solche Properties können keine vorhandenen Properties spezialisieren, da deren Funktionen nicht von EDM abgedeckt werden.
  40. Vgl. https://www.deutsche-digitale-bibliothek.de/ (Letzter Aufruf: 28.03.2014).
  41. Lightweight Information Describing Objects, http://www.lido-schema.org/
    (Letzter Aufruf: 28.03.2014).
  42. DPLA Metadata Application Profile, V3, Feb 2013. http://dp.la/info/wp-content/uploads/2013/04/DPLAMetadataApplicationProfileV3.pdf (Letzter Aufruf: 28.03.2014).
  43. Vgl. http://www.w3.org/2003/01/geo/ (Letzter Aufruf: 28.03.2014).
  44. Dröge, E./Iwanowa, J./Hennicke, S./Eckert, K.: DM2E Model V1.1 Specification. Europeana Professional Website. 2014. http://pro.europeana.eu/documents/1044284/0/DM2E+Model+V+1.1+Specification (Letzter Aufruf: 25.03.2014).
  45. Vgl. http://dm2e.eu (Letzter Aufruf: 26.11.2013).
  46. Vgl. http://www.wittgensteinsource.org (Letzter Aufruf: 26.11.2013).
  47. Vgl. http://www.deutsches-textarchiv.de (Letzter Aufruf: 26.11.2013).
  48. Bibo Spezifikation, 2009. http://bibliontology.com/specification (Letzter Aufruf: 28.11.2013).
  49. DM2E Namensraum, 2014, http://onto.dm2e.eu/schemas/dm2e/ (Letzter Aufruf: 25.03.2014).
  50. Vgl. http://wiki.dm2e.eu/Main_Page (Letzter Aufruf: 04.03.2014).
  51. SPARQL Endpoint, http://semanticweb.org/wiki/SPARQL_endpoint (Letzter Aufruf: 25.03.2014).
  52. Cyganiak, R./Jentzsch, A.: Linking Open Data cloud diagram. 2011. http://lod-cloud.net/ (Letzter Aufruf: 03.04.2014).
  53. OCLC: Virtual International Authority File (VIAF) Data Source. 2012. http://viaf.org/viaf/data (Letzter Aufruf: 03.04.2014).
  54. GeoNames Ontology, 2012, http://www.geonames.org/ontology/documentation.html (Letzter Aufruf: 03.04.2014).
  55. Vgl. http://wiki.dbpedia.org/About (Letzter Aufruf: 03.04.2014).
  56. Volz, J./Bizer, C./Gaedke, M./Kobilarov, G.: Silk-A Link Discovery Framework for the Web of Data. In: Proceedings of the Linked Data on the Web Workshop (LDOW2009). CEUR Workshop Proceedings. Madrid 2009. http://ceur-ws.org/Vol-538/ (Letzter Aufruf: 04.04.2014).
  57. LOD-Pilot von Europeana, data.europeana.eu, http://europeana.ontotext.com/. Daten können über den SPARQL-Endpoint abgerufen werden (Letzter Aufruf: 03.04.2014).
  58. Isaac, A./Haslhofer, B.: Europeana Linked Open Data – data.europeana.eu. In: Semantic Web 4 (3) (2013), S. 291-297.
  59. Europeana Professional, Europeana API, http://pro.europeana.eu/api (Letzter Aufruf: 03.04.2014).
  60. Gradmann, S./Iwanowa, J./ Dröge, E./Hennicke, S./Trkulja, V./Olensky, M./Stein, C./Struck, A./Baierer, K.: Modellierung und Ontologien im Wissensmanagement. Erfahrungen aus drei Projekten im Umfeld von Europeana und des DFG-Exzellenzclusters Bild Wissen Gestaltung an der Humboldt-Universität zu Berlin. In: Information. Wissenschaft & Praxis 64 (2-3) (2013), S. 149-165.
  61. Isaac, A./Clayphan, R./Haslhofer, B.: Europeana: Moving to Linked Open Data. Information Standards Quarterly, Bd. 24 (2-3) (2012), S. 34-40.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>