Europeana Data Model (EDM)

Einstieg zu Pflichtfeldern und empfohlenen Feldern in den Metadaten des EDM-Metadatenstandards

Einstieg: Pflichtfelder

Für die Datenanbindung an den Kulturpool werden Ihre Daten in den Metadatenstandard Europeana Data Model (EDM) überführt. Dafür brauchen Sie eine gewisse Mindestanzahl an Objektinformationen in den → Metadaten, und zwar Pflichtfelder zum Kulturgut und Pflichtfelder zum digitalen Objekt. Eine Kurzübersicht für Technik-Verantwortliche finden Sie in den Pflichtfeldern für EDM-Metadaten.

Für eine Anbindung an den Kulturpool müssen die folgenden Informationen über ein Kulturgut und dessen Digitalisat vorhanden sein. Das Datenmodell ist nicht in Form einer Tabelle darstellbar, sondern gleicht einem Netz mit Verbindungen. Manche der Datenfelder ergänzen sich, manche ermöglichen multiple Einträge oder folgen einem bestimmten Datenformat.

Pflichtfelder zum Kulturgut

Sie können Titel oder Beschreibung verwenden oder beides ausfüllen, mindestens eines der beiden Felder ist zwingend notwendig. Die Sprache ist nur für Text-Medien verpflichtend, für andere Medientypen wird sie empfohlen.

Thematische Pflichtfelder zum Kulturgut

Von den vier thematischen Feldern Thema, Räumlicher Bezug, Zeitlicher Bezug und Objekttyp sind mindestens eines der Felder zwingend notwendig, mehrere sind möglich und empfohlen.

Pflichtfelder zum digitalen Objekt

Auf den folgenden Seiten werden die Pflichtfelder zum Kulturgut und die Pflichtfelder zum digitalen Objekt im Detail erläutert. Weiters finden Sie eine Kurzübersicht für Technik-Verantwortliche mit allen Pflichtfeldern und allen weiteren empfohlenen Feldern als Referenz.

Metadatenfelder aus Nutzersicht

Für Nutzerinnen und Nutzer des Kulturpools zeigen sich die Metadaten etwas anders, als sie aus Sicht der Institutionen eingegeben werden (siehe Grafik). 

Die Filteroptionen zur Suche ergeben sich aus den Metadaten, die die Institutionen an den Kulturpool übermitteln. Gleichzeitig passt der Kulturpool die Such- und Filterfunktionen an Suchbedürfnisse der Nutzerinnen und Nutzer an: Es werden für die Suchanfrage bestimmte Datenfelder zusammengefasst und aufbereitet, etwa fließen in den Datumsfilter mehrere mögliche Zeitangaben hinein. Die Filteroptionen lassen sich somit nicht immer 1:1 auf Datenfelder zurückführen.

pflichtfelder-hoch-03b.png

Die Metadatenfelder, wie sie sich aus Sicht der Nutzerinnen und Nutzer zeigen. Grafik: Kulturpool, CC0.

Einstieg: Europeana Data Model (EDM)

Informationen zu den Objekten und ihren Digitalisaten werden in freier und strukturierter Form als sog. „Metadaten“ in das Sammlungsmanagementsystem eingetragen. Um eine gute Datenqualität zu gewährleisten, hilft das Eintragen nach Metadatenstandards, das Orientieren an den FAIR-Prinzipien und das Verwenden von kontrollierten Vokabularen. Für den Kulturpool brauchen Sie in den Metadaten gewisse Pflichtfelder für das Europeana Data Model (EDM).

Die Objekte in einer Sammlung können mit verschiedenen Informationen beschrieben werden. Diese sind oftmals schon vor der Digitalisierung in analoger oder digitaler Form dokumentiert worden. Durch eine Auswertung der internen Informationsquellen, wie Inventarbücher, frühere analoge Fotografien oder Unterlagen beim Eingang der Objekte, können bereits Informationen über die Provenienz und die Beschreibung der Objekte festgehalten werden: Diese Informationen über ein Objekt werden Metadaten genannt.

Die Metadaten werden üblicherweise in einem Sammlungsmanagementsystem zu einem Objekt eingetragen. Die Daten werden somit nicht wie in einer Tabelle gespeichert, sondern mehr wie in einem Netz untereinander verbunden. Dadurch können mehrere Beschreibungen zu demselben Feld eingetragen, aber auch an anderen Stellen verbunden werden.

Metadatenstandards

Um die Daten nicht nur in sich strukturiert, sondern über Institutionsgrenzen hinweg verständlich, vergleichbar und für einen Austausch verfügbar zu machen, existieren Metadatenstandards. In den unterschiedlichen Domänen haben sich verschiedene Standards entwickelt und durchgesetzt: beispielsweise Dublin Core, EDM, LIDO oder MARC21. 

Was ist das Europeana Data Model (EDM)?

Der Kulturpool verwendet das Europeana Data Model (EDM). Entwickelt von Europeana, dient dieser Standard zur einheitlichen Beschreibung von Werken aus den vielfältigen Domänen des europäischen Kulturerbes. EDM erfasst Objekte, ihre digitalen Repräsentationen und Kontexte. Durch Prinzipien des Semantic Web und → Linked Open Data fördert es die Vernetzung verschiedener Sammlungen. Zudem ermöglicht EDM die Darstellung von Beziehungen zwischen Objekten, Ereignissen und Orten, unterstützt das Verständnis von Kulturgütern und trägt zur digitalen Landschaft des Kulturerbes in Europa bei.

Die offizielle und umfassende Dokumentation von Europeana zu EDM ist in den EDM Mapping Guidelines der Europeana Knowledge Base zu finden.

Linktipps

Pflichtfelder zum Kulturgut

Für die Datenanbindung an den Kulturpool werden Ihre Daten in den Metadatenstandard Europeana Data Model (EDM) überführt. Dafür brauchen Sie eine gewisse Mindestanzahl an Objektinformationen in den → Metadaten, und zwar Pflichtfelder zum Kulturgut und Pflichtfelder zum digitalen Objekt. Eine Kurzübersicht für Technik-Verantwortliche finden Sie in den Pflichtfeldern für EDM-Metadaten.

Mit diesen Informationen beschreiben Sie das Kulturgut selbst. In den folgenden Beschreibungen der Pflichtfelder finden Sie jeweils Beispiele für mögliche Werte sowie die offizielle Bezeichnung im EDM-Metadatenstandard (z. B. «dc:title») und XML-Code aus den Beispiel-Datensätzen in EDM. Bis auf den Medientyp («edm:type») sind hier in allen Feldern mehrere Werte möglich.

Im EDM-Metadatenstandard wird dieser Datenblock als „Daten zum Kulturgut“ «edm:ProvidedCHO» beschrieben.

Sie können Titel oder Beschreibung verwenden oder beides ausfüllen. Mindestens eines der beiden Felder ist zwingend notwendig. Sollten Sie keinen Titel verwenden, zeigen wir die Beschreibung als Titel an.

Titel «dc:title»
Der Titel des Objekts beschreibt bereits möglichst konkret das Objekt, ist so klar wie nötig und so kurz wie möglich. In einem Suchportal wie dem Kulturpool spielen Titel und Beschreibung eine wichtige Rolle für die Auffindbarkeit durch Suchbegriffe. Exakte Übersetzungen des Titels können hier ebenfalls eingetragen werden (mit Sprach-Tags markiert).
Orpheus und Euridike, Panneau für ein Musikzimmer für die Weltausstellung in Paris (mehrere Werte sind möglich)

<dc:title xml:lang="de">Orpheus und Euridike</dc:title>
<dc:title xml:lang="en">Orpheus and Euridice</dc:title>
<dc:title xml:lang="de">Panneau für ein Musikzimmer für die Weltausstellung in Paris 1900</dc:title>

Beschreibung «dc:description»
Die Beschreibung des Objekts kann in einem oder mehreren Absätzen und nötigem Detailgrad Informationen zu dem Objekt geben. Sollten Sie keinen Titel verwenden, empfiehlt sich bei langen Beschreibungen das Führen eines zusätzlichen Felds mit einer Kurzbeschreibung.
Die Metallarbeiten wurden von Georg Klimt und Franz Siegel angefertigt. (mehrere Werte sind möglich)

<dc:description xml:lang="de">Die Metallarbeiten wurden von Georg Klimt und Franz Siegel
  angefertigt. Malerei und Pastiglia von Erwin Puchinger. Das Panneau war in einem von
  Josef Hoffmann gestalteten Raum auf der Weltausstellung 1900 in Paris präsentiert.</dc:description>

Identifikator «dc:identifier»
Der Objektidentifikator (kurz: ID) ist eine alphanumerische Kurzbezeichnung. IDs müssen innerhalb Ihres Datenmodells einzigartig sein, üblicherweise folgen sie einem bestimmten Muster. Hier kann auch ein → PID verwendet werden. Mehrere Identifikatoren sind möglich.
MAL 367, 273660 … (mehrere Werte sind möglich)

<dc:identifier>MAL 367</dc:identifier>
<dc:identifier>273660</dc:identifier>

Sprache «dc:language»
Nur für Objekte mit dem Medientyp „Text“ («edm:type» TEXT) ist eine Angabe der verwendeten Sprache des Objekts verpflichtend; für andere Medientypen mit sprachlichen Elementen wird sie empfohlen. Für die Sprachenangabe sollten die zwei- oder dreistelligen Sprachcodes aus → ISO 639 (Set 1 oder 3) verwendet werden. 
de, fr, en … (mehrere Werte sind möglich)
Wenn die Sprache unbekannt ist, kann der Spezialcode und (undetermined) verwendet werden.

Die Sprachauszeichnung ist nicht zu verwechseln mit den Sprach-Tags, die sich jeweils auf die Sprache der einzelnen Einträge in den Metadaten beziehen, nicht wie hier auf das Objekt selbst.

<dc:language>de</dc:language>

Medientyp «edm:type» 
Der Medientyp beschreibt grob das übermittelte Format des Objekts. Hier ist strikt nur einer der fünf verschiedenen Werte möglich: IMAGE, TEXT, SOUND, VIDEO, 3D. (Die Werte sollten in Großbuchstaben geschrieben werden.) Für Objekte im Text-Format ist die Angabe der Sprache («dc:language») verpflichtend, um anzugeben, in welcher Sprache der Text verfasst oder zur Verfügung gestellt wurde (siehe weiter oben).
IMAGE, TEXT, SOUND, VIDEO, 3D (nur ein Wert möglich)

<edm:type>TEXT</edm:type>


pflichtfelder 01.png

Die Datenfelder in der Ansicht im Kulturpool. Viele Objekte verwenden Beschreibung und Titel.

Thematische Pflichtfelder vom Kulturgut

Im verwendeten Datenmodell bleibt es Ihnen überlassen, ob Sie eines der folgenden vier Felder Thema, Räumlicher Bezug, Zeitlicher Bezug oder Objekttyp verwenden oder mehrere ausfüllen. Von den vier Felder ist mindestens ein Feld verpflichtend, mehrere oder alle sind möglich. Mehrere auszufüllen wird empfohlen.

Thema «dc:subject»
ist das Leitthema des Objekts, etwa das Thema eines Bildes oder die Darstellung einer Skulptur.
Religion, Sprache, König, Stadt, Schlacht … (mehrere Werte sind möglich)

<dc:subject rdf:resource="https://iconclass.org/48C26" />
<dc:subject xml:lang="de">Porträt</dc:subject>
<dc:subject xml:lang="de">König; Kaiser</dc:subject>
<dc:subject xml:lang="en">portrait</dc:subject>
<dc:subject xml:lang="en">king; emperor</dc:subject>


Räumlicher Bezug «dcterms:spatial»
Der durch das Objekt thematisierte oder dargestellte Ort oder Raum.
Europa, Frankreich, Waldviertel, Linz … (mehrere Werte sind möglich)

<dcterms:spatial>Wien</dcterms:spatial>
<dcterms:spatial>Ringstraße</dcterms:spatial>

Zeitlicher Bezug «dcterms:temporal»
Der durch das Objekt thematisierte oder dargestellte Zeitraum, eine Periode, ein Datum oder ein Zeitpunkt. Für genaue Datumsangaben wird Formatierung nach → ISO 8601 empfohlen, etwa YYYY-MM-DD
Renaissance, um 1900(mehrere Werte sind möglich)

<dcterms:temporal xml:lang="de">Römisches Reich</dcterms:temporal>

Objekttyp «dc:type»
Der Objekttyp beschreibt die Art oder das Genre des Objekts. 
Buch, Zeichnung, Diapositiv, Damenkleidung, Druckgrafik, Flugblatt, Modezeichnung, Postkarte …
Für die Auswahl wird empfohlen, ein kontrolliertes Vokabular zu verwenden. Referenzen auf kontrollierte Vokabulare werden nicht als Text, sondern als URI übermittelt.
http://vocab.getty.edu/page/aat/300263554für Tiermalerei (mehrere Werte sind möglich)

<dc:type rdf:resource="http://vocab.getty.edu/aat/300033618" />

pflichtfelder 02b.png

Von den vier thematischen Feldern Thema, Ort, Zeitraum und Objekttyp ist mindestens eines notwendig.

Häufige Fragen (FAQ)

Was ist der Unterschied zwischen «edm:type» und «dc:type»?

Das Metadatenfeld «edm:type» beschreibt die Materialklassen des Digitalisats. Europeana erwartet einen der fünf möglichen Werte: TEXT, IMAGE, SOUND, VIDEO oder 3D (in Versalien).

Ist das Digitalisat einer geschnitzten Skulptur ein Foto, ist für «edm:type» „IMAGE“ auszuwählen.

Bei Digitalisaten mit dem Medientyp „TEXT“ muss immer die Sprache des Texts im Feld «dc:language» mitgeliefert werden. Natürlich kann die Sprachauszeichnung auch bei den anderen Medientypen ergänzt werden, dies wird auch empfohlen.

Das Metadatenfeld «dc:type» beschreibt die Beschaffenheit (Art, Genre) des Originalobjekts. Die Werte für dieses Feld sollen am besten einem kontrollierten Vokabular entnommen werden. Im Beispiel der geschnitzten Skulptur ist «dc:type» „Skulptur“ oder besser ein Link zu „carvings“, z. B. im Getty AAT http://vocab.getty.edu/page/aat/300047203.

Kulturpool Forum: Metadaten (Anmeldung nötig)

Was ist der Unterschied zwischen «dc:language» und einem Sprach-Tag?

Die Sprachauszeichnung «dc:language» bezieht sich auf die Originalsprache des Objekts. Etwa kann ein Buch in der Sprache Französisch verfasst sein. Die Sprachauszeichnung wird wie üblich zum Objekt als Feldwert eingetragen. Hingegen können mit Sprach-Tags einzelne Werte in Feldern ausgezeichnet werden: So können etwa Werte zum Thema mehrsprachig mit König; Kaiser (de) und king; emperor (en) ausgewiesen werden. Für beides – «dc:language» und die Sprach-Tags – werden die zwei- oder dreistelligen Codes der → ISO-Standards 639-1 und 639-3 verwendet.

Linktipps

Pflichtfelder zum digitalen Objekt

Für die Datenanbindung an den Kulturpool werden Ihre Daten in den Metadatenstandard Europeana Data Model (EDM) überführt. Dafür brauchen Sie eine gewisse Mindestanzahl an Objektinformationen in den → Metadaten, und zwar Pflichtfelder zum Kulturgut und Pflichtfelder zum digitalen Objekt. Eine Kurzübersicht für Technik-Verantwortliche finden Sie in den Pflichtfeldern für EDM-Metadaten.

Daten zum digitalen Objekt

Mit diesen Informationen beschreiben Sie das digitale Objekt, das Sie vom Kulturgut erstellt haben. Bis auf das Feld Rechteinhaber:in («dc:rights») ist hier in allen Feldern nur ein Wert möglich.

Im EDM-Datenstandard wird zwischen „Daten zum Aggregationsobjekt“ «ore:Aggregation» und „Daten zum digitalen Objekt“ «edm:WebResource» unterschieden. Das Aggregationsobjekt ist eine Art übergreifendes Einstiegsobjekt, das je auf die Metadaten des Kulturguts und der Digitalisate verweist. Im EDM haben die „Daten zu den digitalen Objekten“ selbst keine Pflichtfelder, sehr wohl aber die „Daten zum Aggregationsobjekt“. Wir haben diese hier zusammengefasst.

Daten-Provider «edm:dataProvider»
In diesem Feld geben Sie den Namen Ihrer Institution an – als Partnerinstitution und Daten-Provider des Kulturpools –, wie Sie im Kulturpool sichtbar angezeigt werden soll. Ändert sich der Name Ihrer Institution zu einem späteren Zeitpunkt, weisen Sie uns bitte darauf hin.
Naturhistorisches Museum Wien, Salzburger Regionalmuseen und Sammlungen … (nur ein Wert möglich)

<edm:dataProvider xml:lang="de">MAK – Museum für angewandte Kunst, Wien</edm:dataProvider>

Nutzungsrecht «edm:rights»
Im Nutzungsrecht führen Sie einen Link zum Rechtsstatus der Digitalisate an. Rechte- und Lizenzangaben für das Digitalisat beschreiben Möglichkeiten und Genehmigungen, ein Digitalisat im Internet darzustellen und zu nutzen. Die Lizenzangabe wird nicht als Text, sondern als URI übermittelt (Rechteerklärungen im EDM-Metadatenstandard). Die URIs richten sich strikt nach der Liste der möglichen Werte und sind daher mit http und nicht https zu schreiben. 
http://creativecommons.org/licenses/by-sa/4.0/ für CC BY-SA (nur ein Wert möglich)

<edm:rights rdf:resource="http://creativecommons.org/licenses/by/4.0/" />

Rechteinhaber:in «dc:rights»
Als Rechteinhaberin/Rechteinhaber steht der Name der Person oder Institution, die über die Rechte der Digitalisate verfügt. (mehrere Werte sind möglich)

<dc:rights xml:lang="de">Österreichische Nationalbibliothek</dc:rights>


Ressourcenadresse «edm:isShownBy»
Die Ressourcenadresse ist der Link zum Digitalisat bei der Institution. Üblicherweise führt dieser Link direkt auf die Mediendatei. Über den Link wird das Digitalisat selbst (Bild, Text, Audio, Video, 3D) im Browser angezeigt. (Dieser Link ist für die Nutzerinnen und Nutzer im Kulturpool nicht sichtbar.) In diesem Feld ist nur ein Wert möglich, weitere Links (z. B. für weitere Ansichten) können in «edm:hasView»  übermittelt werden.
https://sammlung.wienmuseum.at/openapi-images/objects/1026509/1676465_default.jpg (nur ein Wert möglich)

<edm:isShownBy rdf:resource="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_1.jpg" />

Kontextadresse «edm:isShownAt»
Die Kontextadresse ist der Link zum Digitalisat im Kontext bei der Institution. Üblicherweise führt dieser Link auf die Mediendatei im Kontext. Der Link führt auf eine Übersichtsseite, auf dem die Mediendatei gemeinsam mit den beschreibenden Informationen sichtbar ist.
https://sammlung.wienmuseum.at/objekt/1026509/ (nur ein Wert möglich)

<edm:isShownAt rdf:resource="https://sammlung.mak.at/sammlung_online?id=collect-273660" />


pflichtfelder 04.png

Im Kulturpool verweist die Kontextadresse stets auf das Objekt in der Originalsammlung der Institution. Die Ressourcenadresse ist nicht sichtbar.

pflichtfelder-04.png

Das Nutzungsrecht wird als URI übermittelt und verweist somit direkt auf den Rechtstext. Der Filter „Kann ich es weiterverwenden?“ fasst die Nutzungsrechte für Nutzerinnen und Nutzer einfach zusammen.

Linktipps

Technischer Aufbau EDM

Bausteine des EDM

Ein EDM-Datensatz besteht grundsätzlich aus verschiedenen Elementen, die jeweils einen Teil der Informationen enthalten und in einem Verhältnis zueinander stehen.

Hauptklassen

Im EDM gibt es die drei Hauptklassen «ore:Aggregation», «edm:ProvidedCHO» und «edm:WebResource».

Technisch basiert EDM auf dem  → RDF-Standard, weshalb man die Daten leicht als Graphen darstellen kann:

Genaue Kenntnisse von RDF können ein tieferes Verständnis von EDM schaffen, die wichtigsten Grundlagen für EDM sind:

Grundsätzlich können RDF-Daten in vielen verschiedenen Formaten hinterlegt werden (RDF-XML, Turtle, JSON-LD …). Da Europeana die Daten jedoch in der XML-Serialisierung erwartet und es für XML auch einige Tools gibt, werden wir uns hier nur auf diese Variante konzentrieren. Das obige Beispiel würde in RDF-XML folgendermaßen aussehen:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/" xmlns:edm="http://www.europeana.eu/schemas/edm/"
    xmlns:ore="http://www.openarchives.org/ore/terms/">

    <ore:Aggregation rdf:about="https://sammlung.mak.at/sammlung_online?id=collect-273660#Aggregation">
        <edm:aggregatedCHO
            rdf:resource="https://sammlung.mak.at/oai-pmh?verb=GetRecord&amp;metadataPrefix=edm&amp;identifier=collect-273660" />
        <edm:dataProvider xml:lang="de">MAK - Museum für angewandte Kunst, Wien</edm:dataProvider>
        <edm:isShownAt rdf:resource="https://sammlung.mak.at/sammlung_online?id=collect-273660" />
        <edm:isShownBy rdf:resource="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_1.jpg" />
        <edm:provider>Kulturpool</edm:provider>
        <edm:rights rdf:resource="http://creativecommons.org/licenses/by-sa/4.0/" />
    </ore:Aggregation>

    <edm:ProvidedCHO
        rdf:about="https://sammlung.mak.at/oai-pmh?verb=GetRecord&amp;metadataPrefix=edm&amp;identifier=collect-273660">
        <dc:contributor>Georg Klimt (Maler; Wien, 1900)</dc:contributor>
        <dc:identifier>273660</dc:identifier>
        <dc:title xml:lang="de">Orpheus und Euridike</dc:title>
        <dc:title xml:lang="en">Orpheus and Euridice</dc:title>
        <dc:type>Gemälde</dc:type>
    </edm:ProvidedCHO>

    <edm:WebResource rdf:about="https://sammlung.mak.at/sammlung_online?id=collect-273660" />
    <edm:WebResource rdf:about="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_1.jpg" />
    
</rdf:RDF>
Sprach-Tags

Wie im vorhergehenden Beispiel kann, wo sinnvoll, die Sprache der Metadatenfelder per Attribut xml:lang angegeben werden. Durch Wiederholung ist es möglich, den selben Inhalt in mehreren Sprachen anzugeben:

<dc:type xml:lang="en">oil painting</dc:type>
<dc:type xml:lang="de">Ölgemälde</dc:type>

Generell wird empfohlen, alle Feldinhalten in so vielen Sprachen wie möglich anzugeben, da die Daten, besonders über die Weitergabe an Europeana, einem internationalen Publikum zugänglich gemacht werden sollen.

Der angegebene Sprachcode muss → BCP 47 konform sein. In Praxis reicht in den meisten Fällen die Auswahl des entsprechenden → ISO 639-1 oder 639-3 Codes.

Kontextuelle Klassen

Zusätzlich gibt es noch vier Kontextuelle Klassen, die genau gleich verwendet werden (aus technischer Sicht kein Unterschied zu den Hauptklassen).

Auf diese wird hauptsächlich vom edm:ProvidedCHO aus verlinkt und sie kapseln bestimmte Informationen zusammen. Die Rolle, die die Kontextuellen Klassen im Datensatz spielen, hängt von der Verlinkung ab. So kann eine Person (edm:Agent) beispielsweise creator sein, oder nur contributor.

Die verfügbaren Kontextuellen Klassen sind:

In XML könnte es in der Verwendung zum Beispiel folgendermaßen aussehen: 

<rdf:RDF>
  <edm:ProvidedCHO>
    <dc:contributor rdf:resource="AgentID_1"/>
  </edm:ProvidedCHO>

  <edm:Agent rdf:about="AgentID_1">
    <skos:prefLabel>Georg Klimt</skos:prefLabel>
    <skos:altLabel>Klimt, Georg</skos:altLabel>
    <rdaGr2:dateOfBirth>1867</rdaGr2:dateOfBirth>
    <rdaGr2:dateOfDeath>1931</rdaGr2:dateOfBirth>
  </edm:Agent>
</rdf:RDF>

Kontrolliertes Vokabular/Thesauri

Kontrollierte Vokabulare und Thesauri können referenziert werden, statt die Kontextklassen selbst zu definieren. Vorteile dabei sind, dass nur die URL angegeben werden muss, alle weiteren Informationen werden dann darüber abgerufen. Außerdem ermöglicht dies eine Standardisierung und Identifizierung von Entitäten über mehrere Datensätze und Institutionen hinweg.

Die Verlinkung erfolgt über das Attribut rdf:resource:

<dc:contributor rdf:resource="https://d-nb.info/gnd/136070213"/>

Der Tag darf in diesem Fall keinen Inhalt haben, da bereits auf komplexere Strukturen verlinkt wird.

→ Liste der unterstützten Vokabulare

FAQ

Was ist der Unterschied zwischen rdf:about und rdf:resource?

rdf:about muss bei der Definition von Instanzen («edm:ProvidedCHO», «oreAggregation», «edm:WebResource» …) angegeben werden, über die dann mit den inneren Tags etwas ausgesagt wird.

rdf:resource wird hingegen verwendet, um auf eine Ressource zu verweisen, die an einem anderen Punkt definiert wird.

Wie vergebe ich URIs in rdf:about und rdf:resource?

rdf:about:

rdf:resource: Muss bei selbst definierten Ressourcen genau die URL sein, wie sie im zugehörigen rdf:about steht. Bei Referenz auf externe Ressourcen sollte eine URL aus einem von Europeana unterstützten Vokabular genutzt werden. Hierfür muss immer der Hauptlink der Ressource angegeben werden, der bei den meisten Vokabularen extra aufgelistet wird (z. B. als „Page Link“ oder „Link zum Datensatz“).

Wie kann ich mehrere Informationen in einem Feld angeben?

Bis auf wenige Ausnahmen können die Felder in EDM fast immer einfach wiederholt werden, um mehrere Werte anzugeben. Bei einem Objekt aus Porzellan mit Golddekor könnte das im ProvidedCHO zum Beispiel so aussehen:

<dcterms:medium>Porzellan</dcterms:medium>
<dcterms:medium>Gold</dcterms:medium>

Die wichtigsten Ausnahmen sind:

Was ist der Unterschied zwischen xml:lang und «dc:language»?
<dc:language>de</dc:language>

Linktipp

Kurzreferenz EDM-Pflichtfelder

Für die Datenanbindung an den Kulturpool werden Ihre Daten in den Metadatenstandard Europeana Data Model (EDM) überführt. Dafür brauchen Sie eine gewisse Mindestanzahl an Objektinformationen in den → Metadaten, und zwar Pflichtfelder zum Kulturgut und Pflichtfelder zum digitalen Objekt. Eine Kurzübersicht für Technik-Verantwortliche finden Sie hier in den Pflichtfeldern für EDM-Metadaten.

Im EDM-Metadatenstandard wird zwischen Metadaten in den Klassen Aggregationsobjekt, Kulturgut und Digitale Ressource unterschieden. Jede Klasse hat eine Gruppe an Feldern, manche davon sind Pflichtfelder. Das Aggregationsobjekt ist die Kombination aus Kulturgut und Digitalisat (im Bibliothekswesen „Katalogisat“ genannt). Es kommen noch weitere kontextuelle Klassen und Verbindungen hinzu.

Zum besseren technischen Verständnis haben wir kommentierte EDM-Beispieldatensätze erstellt. 

Mindestanforderungen nach EDM

Die fett gedruckten Felder sind Pflichtfelder zur Darstellung Ihrer Objekte im Kulturpool und in Europeana.

Aggregationsobjekt «ore:Aggregation»

Felder der Mindestanforderungen 

Feldbezeichnung Bedeutung EDM Standard → Kardinalität
Kulturgut
Verbindung zur Kulturgut-Klasse über eine URI oder einen lokalen Identifikator, siehe «edm:ProvidedCHO» «edm:aggregatedCHO» 1…1
Daten-Provider Name der Institution, die die Daten für den Kulturpool zur Verfügung stellt «edm:dataProvider» 1…1
Kontextadresse
Webadresse zum digitalen Objekt in vollem Kontext (Angabe als URL zur Seite mit Metadaten und Medienansicht)
«edm:isShownAt» 0…1
Ressourcenadresse
Webadresse zum digitalen Objekt, Link zur Mediendatei (z. B. URL zur Bilddatei). Nur ein Wert möglich, weitere Werte in Ansichten («edm:hasView») eintragen.
«edm:isShownBy» 0…1
Nutzungsrecht Informationen zu Rechtsstatus (Copyright und Nutzungsrechte) des digitalen Objekts, Angabe als URI «edm:rights» 1…1

Empfohlene Felder 

Feldbezeichnung Bedeutung EDM Standard → Kardinalität
Ansichten Weitere Ressourcenadressen zum digitalen Objekt, etwa weitere Ansichten (z. B. Seitenansicht, Detailansicht)

«edm:hasView»

0…n

Vollständige Auflistung aller Felder von ore:Aggregation

Kulturgut «edm:ProvidedCHO»

Diese Feldbezeichnungen beziehen sich auf das ursprüngliche Kulturgut, mit der Ausnahme der Medienkategorie «edm:type», das sich auf den generellen Medientyp des digitalen Objekts bezieht. Der Objektidentifikator «dc:identifier» ist kein Pflichtfeld von Europeana, aber des Kulturpools.

Felder der Mindestanforderungen

Feldbezeichnung Bedeutung EDM Standard → Kardinalität

Sie können Titel oder Beschreibung verwenden oder beides ausfüllen, mindestens eines der beiden Felder ist zwingend notwendig.

Titel Titel oder Name des Objekts
«dc:title» 0…n
Beschreibung Beschreibung des Objekts
«dc:description» 0…n
Identifikator
Identifikator des Objekts (eindeutig innerhalb der Institution)
«dc:identifier» 0…n
Sprache
Sprache des Texts auf dem Objekt, Pflichtfeld, wenn Medientyp «edm:type» TEXT ist, Angabe als ISO 639-1 oder 639-3) «dc:language» 0…n
Medientyp
Medienkategorie des digitalen Objekts (Einzig mögliche Werte: IMAGE, TEXT, VIDEO, AUDIO, 3D)
«edm:type» 1…1

Von den vier thematischen Feldern Thema, Räumlicher Bezug, Zeitlicher Bezug und Objekttyp sind mindestens eines der Felder zwingend notwendig, mehrere sind möglich und empfohlen.

Thema Thema, das das Kulturgut darstellt oder behandelt «dc:subject» 0…n
Objekttyp
Begriff zur Beschreibung der spezifischen Art des Objekts (Angabe durch kontrolliertes Vokabular) «dc:type» 0…n
Räumlicher Bezug Räumliches Thema des Objekts «dcterms:spatial» 0…n
Zeitlicher Bezug
Zeitliches Thema des Objekts «dcterms:temporal» 0…n

Empfohlene Felder

Feldbezeichnung Bedeutung EDM Standard → Kardinalität
Alternativer Titel
Alternativer Titel, auch Abkürzungen oder ungenaue Übersetzungen
«dcterms:alternative» 0…n
Erstellungsdatum Erstellungsdatum des Objekts «dcterms:created» 0…n
Datum
Datum, das in Bezug auf das Objekt signifikant erscheint. Angabe nach → ISO 8601) Wo möglich, durch die genaueren Felder «dcterms:temporal», «dcterms:created» oder «dcterms:issued» ersetzen.
«dc:date» 0…n
Bezug Kontextuelle/zeitliche/räumliche Beschreibung des Inhalts des Objekts «dc:coverage»
0…n
Material Material oder Trägermedium «dcterms:medium» 0…n
Maße/Dauer Größe oder Dauer des Objekts (Angabe mit Maßangaben)
«dcterms:extent» 0…n
Veröffentlicht durch Veröffentlichende Person oder Institution  «dc:publisher» 0…n
Ist ein Teil von
Eine Ressource, in der das Objekt physisch oder logisch enthalten ist, z. B. eine Sammlung
«dcterms:isPartOf» 0…n
Schöpfer:in Die das Objekt erschaffende Person
«dc:creator» 0…n
Standort Standort (Institution, Lagerort) des Kulturguts «edm:currentLocation» 0…1
Provenienz Herkunft des Objekts, Eigentümerwechsel «dcterms:provenance» 0…n

Vollständige Auflistung aller Felder von edm:ProvidedCHO

Digitale Ressource «edm:WebResource»

Im Datenmodell von Europeana gibt es im digitalen Objekt keine Pflichtfelder, sondern nur ein empfohlenes Feld empfohlene Felder.

Empfohlene Felder

Feldbezeichnung Bedeutung
EDM Standard → Kardinalität
Medientyp
Medientyp des digitalen Objekts (z. B. Video)
«dc:type» 0…n
Schöpfer:in Zur Erschaffung des digitalen Objekts beitragende Person (z. B. Fotograf:in) «dc:creator» 0…n
Rechteinhaber:in Name der Person oder Organisation, welche über die Rechte verfügt
«dc:rights» 0…n
Nutzungsrecht Informationen zu Copyright und Nutzungsrechten (nur falls abweichend zum Nutzungsrecht im Aggregationsobjekt)
«edm:rights» 0…1
Digitale Maße
Größe oder Dauer der Ressource (z. B. 4000 × 3000 px)
«dcterms:extent» 0…n

Vollständige Auflistung aller Felder von edm:WebResource

Weitere empfohlene Felder

Die folgenden Felder werden entweder von Europeana oder dem Kulturpool empfohlen. Wo nicht anders angegeben, sind immer mehrere Einträge für ein Feld möglich.

Weitere empfohlene Datenfelder zum Kulturgut

Die folgenden Felder betreffen die Klasse «edm:ProvidedCHO».

Alternativer Titel «dcterms:alternative»
Alternative Titel des Objekts, auch Abkürzungen, Übersetzungen oder alternative Schreibweisen.

Bezug «dc:coverage»
Kontextuelle/zeitliche/räumliche Beschreibung des Inhalts des Objekts. Anstelle von «dc:coverage» für räumliche und zeitliche Themen des Kulturguts wird empfohlen, stets die genaueren Datenfelder «dcterms:spatial» und «dcterms:temporal» (siehe Pflichtfelder) zu verwenden.

Beitragende:r «dc:contributor»
Person oder Organisation, die für einen Beitrag zum Objekt verantwortlich ist. Wo zutreffend, verwenden Sie für Schöpfer:innen besser das Feld «dc:creator».

Datum «dc:date»
Weitere zeitliche Bezüge; Datum, das in Bezug auf das Objekt signifikant erscheint (z. B. Ära, Epoche). Wird am besten nach ISO 8601 eingetragen, etwa im Format YYYY-MM-DD. Bitte verwenden Sie, wo möglich, die genaueren Felder «dcterms:temporal», «dcterms:created» oder «dcterms:issued».
1815-12-10

Erstellungsdatum «dcterms:created»
Datum oder Zeitspanne der Erstellung des Objekts. Wird am besten nach ISO 8601 eingetragen, etwa im Format YYYY-MM-DD.
2023-04-08

Veröffentlichungsdatum «dcterms:issued»
Datum der Veröffentlichung des Kulturerbeobjekts. Empfohlen wird ein Datum nach ISO 8601, etwa im Format YYYY-MM-DD. Es sind auch Verweise auf Zeitspannen möglich.
1815

Veröffentlicht durch «dc:publisher»
Veröffentlichende oder für die Verfügbarmachung des Objekts verantwortliche Person oder Institution (Individuum, Institution, Verlag …).
Wilhelm Stempfle VLB, Innsbruck

Ist ein Teil von «dcterms:isPartOf»
Eine Ressource, in der das Objekt physisch oder logisch enthalten ist, z. B. eine Sammlung.
Fotosammlung, Numismatik, Bildarchiv und GrafiksammlungBibliothek und Kunstblättersammlung

Material «dcterms:medium»
Material oder physisches Trägermedium des Objekts.
Metall

Maße/Dauer «dcterms:extent»
Größe oder Dauer des Objekts. Bitte führen Sie die Maßangaben an.
30 cm x 20 cm x 15 cm (L x B x H)
oder für Mediendateien 3:45

Provenienz «dcterms:provenance»
Herkunft des Objekts, Eigentümerwechsel, Verwahrung von Signifikanz.
Sammlung der Künstlerin bis 2020, danach Übergabe an NHM

Schöpfer:in «dc:creator»
Erschaffender oder zur Erschaffung des Objekts beitragende Person.
Gustav Klimt

Standort «edm:currentLocation» (nur ein Wert möglich)
Aktueller Standort (Institution, Lagerort) des Kulturguts.
Naturhistorisches Museum Wien 

Ursprung «dc:source»
Quelle, Ursprung; eine mit dem Objekt verbundene Ressource, von der das Objekt ganz oder teilweise abgeleitet ist.
Security Magazine S. 3–12

Vorangehendes Objekt «edm:IsNextInSequence»
Das vorangehende Objekt, wenn beide Objekte Teile einer Reihe sind oder zu derselben Gesamtressource gehören. Dieses Feld hilft bei der richtigen Anzeige einer Reihenfolge und wird als URI angegeben.

Weitere empfohlene Datenfelder zum Aggregationsobjekt

Die folgenden Felder betreffen die Klasse «ore:Aggregation».

Ansichten «edm:hasView» (mehrere Werte möglich)
Feld für weitere Links zu digitalen Webressourcen. Es ergänzt die beiden Pflichtfelder Kontextadresse «edm:isShownAt» und Ressourenadresse «edm:isShownBy» und erlaubt das Eintragen weiterer Ressourcenadressen, etwa für mehrere Ansichten eines Objekts (z. B. Seitenansichten, Detailansichten).

<edm:hasView rdf:resource="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_3.jpg" />
<edm:hasView rdf:resource="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_4.jpg" />
<edm:hasView rdf:resource="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_6.jpg" />
<edm:hasView rdf:resource="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_7.jpg" />
<edm:hasView rdf:resource="https://sammlung.mak.at/img/1200x1200/publikationsbilder/mal-367_8.jpg" />

Provider «edm:provider» (nur ein Wert möglich)
Im Feld Provider wird die Organisation eingetragen, die Daten an Europeana übermittelt. In diesem Feld steht als Fixwert der Kulturpool.

<edm:provider>Kulturpool</edm:provider>

Objektadresse «edm:object» (nur ein Wert möglich)
Die URL zur Darstellung eines Bilds, das für Vorschaubilder in Europeana verwendet wird. Kann dieselbe URL wie «edm:isShownBy» sein. Es muss sich immer um die URI zu einem Bild handeln, auch bei anderen Medientypen.

Zwischen-Provider «edm:intermediateProvider» 
Der Name einer Zwischenorganisation, wenn nicht direkt an den Kulturpool Daten übermittelt werden, sondern z. B. über einen lokalen Aggregator.  Siehe auch Datenprovider.

Weitere empfohlene Datenfelder zu digitalen Objekten

Die folgenden Felder betreffen die Klasse «edm:WebResource».

Digitale Maße «dcterms:extent»
Ähnlich der Maße des kulturellen Objekts (siehe oben) beschreibt dieses Feld die Größe oder Dauer der digitalen Ressource.
4000 x 3000 px

Medientyp «dc:type»
Medientyp des digitalen Objekts. Der Medientyp aus «dc:type» sollte sich nicht mit dem Medientyp aus «edm:type» (Pflichtfeld beim Kulturgut) gleichen.
Video

Nutzungsrecht «edm:rights» (nur ein Wert möglich)
Informationen zu Copyright, Nutzung und Zugangsrechten des digitalen Objekts (nur anzugeben, falls abweichend zu allgemeinen Informationen aus «edm:rights» auf der Ebene der «ore:Aggregation»), wo es ein Pflichtfeld ist.

Rechteinhaber:in «dc:rights»
Name der Person oder Organisation, welche über die Rechte verfügt. Bitte beachten Sie: Rechteinhaber:in ist auf der Ebene des digitalen Objekts ein Pflichtfeld

Schöpfer:in  «dc:creator»
Zur Erschaffung des digitalen Objekts beitragende Person (z. B. Fotograf:in).

Kontextuelle Klassen in EDM

Kontextuelle Klassen erlauben den Eintrag zusätzlicher Informationen zu Entitäten, die sich vom Kulturgut unterscheiden. Etwa können Details zu Handlungsträgern («edm:Agent»), einer Zeitspanne («edm:Time»), Ortsangaben («edm:Place») oder einem Konzept («edm:Concept») gespeichert werden. Das Kulturgut wird damit in einen größeren Kontext und bessere Verbindungen für Suchzwecke und zur Informationsverarbeitung gesetzt.

Durch Bereitstellen von z. B. zeitlichen Informationen können Kulturgüter in Sammlungen, die alle Objekte eines bestimmten Jahrhunderts darstellen, angezeigt werden. Informationen über das Konzept lassen eine Suche und Darstellung in Sammlungen nach ähnlichen Wörtern zu. Es wird empfohlen, mehrsprachige und → Linked Open Data (LOD) Vokabulare für die Informationen in den Metadatenfeldern zu verwenden, da diese die Übersetzung und infolgedessen die Auffindbarkeit in anderen Sprachen ermöglichen sowie eingetragene, ähnliche Konzepte verbinden und in Hierarchien kategorisieren.

Beispiele: Zu einer Karte über die Bevölkerungsdichte in Europa kann das Konzept „Bevölkerungsgeografie“ hinzugefügt werden, mit einer breiteren Einfassung des Konzepts zu „Geografie“. Andererseits könnte zu dieser Karte über die Bevölkerungsdichte in Europa das Konzept „Bevölkerungsgeografie“ über einen Link zum Eintrag im z. B. Getty AAT hinzugefügt werden, wodurch die weiteren dazugehörigen Kontexte und Hierarchien automatisch verbunden werden. Ein weiteres Beispiel wird in der folgenden Abbildung grafisch dargestellt.

2023-05-16_beispiel_kontextklassen.png

Beispiel zu verschiedenen kontextuellen Klassen: Das Geburtsdatum von Gustav Klimt wird über die kontextuelle Klasse edm:Agent hinzugefügt, da es sich bei diesem Datum nicht um das Gemälde selbst handelt. Ebenso wäre es möglich, auf den Künstler mit einem Link zum Eintrag in einem kontrollierten Vokabular zu verweisen. Durch das Hinzufügen eines Eintrages mit skos:Concept können Ideen oder Bedeutungen des Kulturerbstücks weitergegeben werden. In diesem Beispiel sind die zwei Möglichkeiten für die Weitergabe des Konzepts gegeben, entweder mit einem eigenen Eintrag oder einem Link zum Eintrag im kontrollierten Vokabular. Durch einen Sprach-Tag lassen sich gegebenenfalls Übersetzungen finden.

Anforderungen für die Stufen der Metadatenqualität

Die Elemente in der folgenden Tabelle sind je als Mindestanforderung für die Einteilung in die Metadatenqualitätsstufen zu sehen. Weitere Elemente, die von Europeana gestützt werden, lassen sich auf dieser Webpage finden.

Stufe A: Keine Anforderung für kontextuelle Klassen.

Stufe B: Mindestens eine der folgenden kontextuellen Klassen mit den angegebenen Pflichtfeldern oder einem Link zu einem LOD-Vokabular, das von Europeana unterstützt wird, muss angegeben werden.

Stufe C: Mindestens zwei der folgenden kontextuellen Klassen mit den angegebenen Pflichtfeldern oder einem Link zu einem LOD-Vokabular, das von Europeana unterstützt wird, müssen angegeben werden.

kontextbezogeneKlassenGrafik.png

Metadatenfelder aus den verschiedenen kontextuellen Klassen und deren Verhältnis zueinander für die Mindestanforderungen, wenn kein Link zu einem Eintrag in einem LOD Vokabular angegeben wird. 

Felder per Akteur «edm:Agent»

Mindestanforderungen

Feldbezeichnung Bedeutung
EDMStandard
Bevorzugte Bezeichnung
Der Name des Akteurs in der bevorzugten Form
«skos:prefLabel»

Felder per Ort «edm:Place»

Mindestanforderungen

Feldbezeichnung  Bedeutung
EDM Standard
Breitengrad
Der Breitengrad des Orts
«wgs84_pos:lat»
Längengrad
Der Längengrad des Orts «wgs84_pos:long»
Bevorzugte Bezeichnung
Der bevorzugte Name des Orts
«skos:prefLabel»

Felder per Zeitspanne «edm:TimeSpan»

Feldbezeichnung Bedeutung
EDM Standard
Bevorzugte Bezeichnung
Die bevorzugte Bezeichnung der Zeitspanne
«skos:prefLabel»
Beginn
Start der Zeitspanne
«edm:begin»
Ende
Ende der Zeitspanne
«edm:end»

Felder per Konzept «skos:Concept»

Mindestanforderungen

Feldbezeichnung Bedeutung
EDM Standard
Bevorzugte Bezeichnung
Die bevorzugte Bezeichnung des Konzepts
«skos:prefLabel»

Linktipps

Beispiel-Datensätze in EDM

Verwendung

Diese Datensätze zeigen in verschiedenen Kategorien auf, wie ein Objekt in EDM repräsentiert werden kann. In den Datensätzen befinden sich mit <!-- ... --> gekennzeichnete Kommentare. Diese bieten zusätzliche Informationen und Erklärungen und haben sonst keine Bedeutung in EDM. Eine grundsätzliche Erklärung zum Aufbau eines EDM-Datensatzes finden Sie unter Technischer Aufbau EDM.

Da je nach Institution oft sehr unterschiedliche Metadaten erfasst werden, sind diese Datensätze weder als vollständige Referenz noch als streng zu erfüllendes Muster zu betrachten. In den Pflichtfeldern in EDM finden Sie weitere Informationen zu den sonstigen verfügbaren Feldern.

Gemälde „Herbsttag im Prater“

<?xml version="1.0" encoding="UTF-8"?>
<!--
    EDM Datensatz zum Gemälde "Herbsttag im Prater", bereitgestellt vom Wien Museum
    Objekt im Kulturpool: https://kulturpool.at/institutionen/wien-museum/31522
    Objekt in der Wien Museum Online-Sammlung: https://sammlung.wienmuseum.at/objekt/205-herbsttag-im-prater/
-->

<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:edm="http://www.europeana.eu/schemas/edm/" xmlns:ore="http://www.openarchives.org/ore/terms/"
    xmlns:rdaGr2="http://rdvocab.info/ElementsGr2/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:skos="http://www.w3.org/2004/02/skos/core#">
    <!-- Pro rdf:RDF kann nur genau ein Objekt angegeben werden. Die xmlns: Attribute müssen für jeden verwendeten
    Namespace (zb. dc:, edm:, ...)
    angegeben werden -->

    <edm:ProvidedCHO rdf:about="https://sammlung.wienmuseum.at/objekt/205/#ProvidedCHO">
        <!-- In ProvidedCHO sind Informationen zum Gemälde selbst. Die URL in rdf:about dient als ID, mit der
        später in der Aggregation auf das ProvidedCHO verwiesen wird und kann grundsätzlich frei gewählt werden,
        solange sie nicht mit einem anderen rdf:about im Datensatz kollidiert. -->

        <dc:creator rdf:resource="https://sammlung.wienmuseum.at/suche/?people=p11434" />
        <dc:date>1881</dc:date>
        <dc:identifier>31522</dc:identifier>

        <dc:subject rdf:resource="https://iconclass.org/25H" />
        <!-- Iconclass Verweis auf "Landschaften" -->

        <dc:subject rdf:resource="https://iconclass.org/25G3" />
        <!-- Iconclass Verweis auf "Bäume" -->

        <dc:subject xml:lang="en">Prater</dc:subject>
        <dc:subject xml:lang="en">Fine Arts</dc:subject>
        <dc:subject xml:lang="en">female artists</dc:subject>
        <dc:subject xml:lang="de">Prater</dc:subject>
        <dc:subject xml:lang="de">Bildende Kunst</dc:subject>
        <dc:subject xml:lang="de">Künstlerinnen</dc:subject>
        <dc:title>Herbsttag im Prater</dc:title>
        <dc:type xml:lang="en">paintings</dc:type>
        <dc:type xml:lang="en">oil painting</dc:type>
        <dc:type xml:lang="de">Gemälde</dc:type>
        <dc:type xml:lang="de">Ölgemälde</dc:type>
        <dcterms:isPartOf xml:lang="de">Gemäldesammlung</dcterms:isPartOf>
        <dcterms:isPartOf xml:lang="en">painting collection</dcterms:isPartOf>
        <dcterms:spatial rdf:resource="https://sammlung.wienmuseum.at/suche/?districts=515444" />
        <edm:type>IMAGE</edm:type>
    </edm:ProvidedCHO>
    <edm:WebResource rdf:about="https://sammlung.wienmuseum.at/openapi-images/objects/205/2358466_preview.jpg">
        <dc:rights>Foto: Birgit und Peter Kainz, Wien Museum</dc:rights>
    </edm:WebResource>
    <edm:Agent rdf:about="https://sammlung.wienmuseum.at/suche/?people=p11434">
        <skos:prefLabel>Tina Blau</skos:prefLabel>
        <edm:begin>1845</edm:begin>
        <edm:end>1916</edm:end>
        <rdaGr2:professionOrOccupation xml:lang="de">Künstlerin</rdaGr2:professionOrOccupation>
    </edm:Agent>
    <edm:Place rdf:about="https://sammlung.wienmuseum.at/suche/?districts=515444">
        <skos:prefLabel xml:lang="en">2nd District: Leopoldstadt, Vienna</skos:prefLabel>
        <skos:prefLabel xml:lang="de">2. Bezirk: Leopoldstadt, Wien</skos:prefLabel>
    </edm:Place>
    <ore:Aggregation rdf:about="https://sammlung.wienmuseum.at/objekt/205/#Aggregation">
        <!-- Das Aggregation Objekt verlinkt auf das Kulturgut und dessen zugehörige Digitalisate und dient als
        Einstiegsobjekt beim lesen des Datensatzes. -->

        <edm:aggregatedCHO rdf:resource="https://sammlung.wienmuseum.at/objekt/205/#ProvidedCHO" />
        <!-- verweist auf das vorher definierte ProvidedCHO, über die selbe URL in rdf:resource und rdf:about -->

        <edm:dataProvider>Wien Museum</edm:dataProvider>

        <edm:isShownAt rdf:resource="https://sammlung.wienmuseum.at/objekt/205/" />
        <!-- URL zum Objekt im Kontext der Onlinesammlung der Institution. Darf nur einmal vorkommen -->

        <edm:isShownBy rdf:resource="https://sammlung.wienmuseum.at/openapi-images/objects/205/2358466_default.jpg" />
        <!-- Direktlink zum primären Digitalisat. Darf nur einmal vorkommen, weitere Digitalisate gehören in
        edm:hasView -->

        <edm:provider>Kulturpool</edm:provider>
        <!-- Institution, die an Europeana liefert -->

        <edm:rights rdf:resource="http://creativecommons.org/licenses/by/4.0/" />
        <!-- Verweis auf die CC BY 4.0 Lizenz, für mögliche Werte siehe
        https://wissen.kulturpool.at/books/lizenzen/page/14-mogliche-lizenzen-in-europeana
        Muss http Version sein, nicht https -->

    </ore:Aggregation>
</rdf:RDF>

Buch mit IIIF „Anweisung für den Gebrauch eines neu verfertigten Globus“

<!--
    EDM Datensatz zum Buch "Anweisung für den Gebrauch eines neu verfertigten Globus", bereitgestellt von der
    Österreichischen Nationalbibliothek
    Objekt im Kulturpool: https://kulturpool.at/institutionen/oenb/%252BZ220163607
    Objekt im Online-viewer der Österreichischen Nationalbibliothek:
    https://digital.onb.ac.at/OnbViewer/viewer.faces?doc=ABO_%2BZ174231609
-->

<rdf:RDF xmlns:edm="http://www.europeana.eu/schemas/edm/" xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdagr2="http://rdvocab.info/ElementsGr2/"
    xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:ore="http://www.openarchives.org/ore/terms/"
    xmlns:svcs="http://rdfs.org/sioc/services#" xmlns:doap="http://usefulinc.com/ns/doap#"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

    <ore:Aggregation rdf:about="https://eu02.alma.exlibrisgroup.com/view/oai/43ACC_ONB/request?verb=GetRecord&amp;metadataPrefix=marc21&amp;identifier=oai:alma.ACCONB:990031578530603338#Aggregation">
        <edm:aggregatedCHO rdf:resource="https://eu02.alma.exlibrisgroup.com/view/oai/43ACC_ONB/request?verb=GetRecord&amp;metadataPrefix=marc21&amp;identifier=oai:alma.ACCONB:990031578530603338" />
        <edm:dataProvider xml:lang="de">Österreichische Nationalbibliothek</edm:dataProvider>
        <edm:provider xml:lang="de">Kulturpool</edm:provider>
        <edm:rights rdf:resource="http://rightsstatements.org/vocab/NoC-NC/1.0/" />
        <edm:isShownAt rdf:resource="http://data.onb.ac.at/ABO/%2BZ174231609" />
        <edm:isShownBy rdf:resource="https://digital.onb.ac.at/rep/access/thumbnail/ABO_%2BZ174231609" />
        <edm:object rdf:resource="https://digital.onb.ac.at/rep/access/thumbnail/ABO_%2BZ174231609" />
    </ore:Aggregation>

    <edm:ProvidedCHO rdf:about="https://eu02.alma.exlibrisgroup.com/view/oai/43ACC_ONB/request?verb=GetRecord&amp;metadataPrefix=marc21&amp;identifier=oai:alma.ACCONB:990031578530603338">
        <edm:type xml:lang="en">TEXT</edm:type>

        <dc:creator rdf:resource="https://d-nb.info/gnd/115866213" />
        <!-- GND-Referenz zu Joseph Jüttner. Wird weiter unten über die gleiche URL noch als Agent weiter
        definiert. Wenn dies nicht so wäre würden die Daten aus der GND abgerufen. -->

        <dc:identifier>AC09998309</dc:identifier>

        <dc:language>de</dc:language>
        <!-- Wichtig: dc:language bezieht sich auf die Sprache des Objekts, in dem Fall ein deutsches Buch. Dies
        ist unabhängig von den xml:lang attributen, die sich auf die Sprache der erfassten Metadaten beziehen -->

        <dc:publisher>Jos. Krauß, Prag</dc:publisher>
        <dc:rights xml:lang="de">Österreichische Nationalbibliothek</dc:rights>

        <dc:subject rdf:resource="https://d-nb.info/gnd/4157633-0" />
        <!-- Referenz auf "Globus" als Thema des Buchs -->

        <dc:title xml:lang="de">Anweisung für den Gebrauch eines neu verfertigten Globus. von Joseph Jüttner</dc:title>

        <dc:type rdf:resource="https://d-nb.info/gnd/4008570-3" />
        <!-- Referenz auf den Eintrag für "Buch" in der GND -->

        <dcterms:created>1822</dcterms:created>
        <dcterms:extent>VI, 41 S.</dcterms:extent>
        <dcterms:isPartOf xml:lang="de">Österreichische Nationalbibliothek / Bildarchiv und Grafiksammlung</dcterms:isPartOf>
        <dcterms:isPartOf xml:lang="de">Österreichische Nationalbibliothek / Sammlung von Handschriften und alten
            Drucken</dcterms:isPartOf>
        <dcterms:isPartOf>Austrian Books Online</dcterms:isPartOf>
    </edm:ProvidedCHO>

    <edm:WebResource rdf:about="https://digital.onb.ac.at/rep/access/thumbnail/ABO_%2BZ174231609">
        <!-- Das Bild unterstützt IIIF, signalisiert durch folgende Einträge: -->

        <dcterms:isReferencedBy rdf:resource="https://iiif.onb.ac.at/presentation/ABO/%2BZ174231609/manifest" />
        <!-- Für IIIF Presentation API: Verweis auf die URL des Manifest -->

        <svcs:has_service rdf:resource="https://iiif.onb.ac.at/images/ABO/%2BZ174231609/00000001" />
        <!-- Für IIIF Image API: Verweis aus svcs:Service Klasse, siehe unten. rdf:resource ist die IIIF base-URL
        des Bildes (dort wo auch das info.json abrufbar ist, aber ohne info.json in der URL) -->
    </edm:WebResource>

    <svcs:Service rdf:about="https://iiif.onb.ac.at/images/ABO/%2BZ174231609/00000001">
        <!-- svcs:Service Klasse wird aktuell nur für IIIF verwendet. rdf:about muss IIIF base-URL sein, siehe
        svcs:has_service in edm:WebResource -->

        <dcterms:conformsTo rdf:resource="http://iiif.io/api/image" />
        <!-- Gibt an, dass IIIF Image API unterstützt wird -->

        <doap:implements rdf:resource="https://iiif.io/api/image/2/level1.json" />
        <!-- Gibt das Level der IIIF compliance an, in diesem Beispiel level 1 -->
    </svcs:Service>

    <skos:Concept rdf:about="https://d-nb.info/gnd/4157633-0">
        <skos:prefLabel xml:lang="de">Globus</skos:prefLabel>
    </skos:Concept>

    <edm:Agent rdf:about="https://d-nb.info/gnd/115866213">
        <skos:prefLabel>Jüttner, Joseph</skos:prefLabel>
        <dc:date>1775-1848</dc:date>
        <rdagr2:professionOrOccupation xml:lang="en">Author</rdagr2:professionOrOccupation>
    </edm:Agent>

</rdf:RDF>

Qualität der Metadaten

Neben den Mindestanforderungen für Metadaten sind noch weitere Aspekte zu beachten, um die Qualität der Metadaten sicherzustellen, etwa Sprach-Tags oder das Verwenden von PIDs und kontrollierten Vokabularen.

Nicht nur Metadatenstandards machen Daten verständlicher und vergleichbarer:

Es empfiehlt sich, für eine bessere Auffindbarkeit und eine bessere Vernetzung der Objekte die Daten einheitlich und strukturiert in der Datenbank einzutragen. 

3 Qualitätsstufen für Metadaten nach Europeana

Im Europeana Publishing Framework werden drei Qualitätsstufen für Metadaten definiert. Zusätzlich gibt es noch vier Qualitätsstufen für die Qualität von digitalen Objekten.

Die Metadaten der angezeigten Objekte im Kulturpool werden an Europeana, die virtuelle Bibliothek für das kulturelle Erbe Europas, weitergeleitet. Deshalb sollten die Daten jedenfalls den Mindestanforderungen für Europeana entsprechen. Europeana definiert im Europeana Publishing Framework drei Stufen der Metadatenqualität (Stufe A–C, EN: tiers), wobei die Vorteile für die jeweiligen Stufen aufeinander aufbauen:

Anforderungen der einzelnen Stufen

Die verschiedenen Stufen der Metadatenqualität laut Europeana setzen sich zusammen aus:

Die zugeteilte Stufe ist abhängig von der Qualität und Menge der bereitgestellten Metadaten und den Möglichkeiten der kulturellen Institution. Natürlich gilt: je umfangreicher und genauer die Metadaten, desto besser.

Die Metadatenfelder für weitere Such- und Browsing-Szenarien stammen aus vier Bereichen:

Mögliche Datenfelder der vier Bereiche in EDM

Suche nach Datum oder Zeitspanne
Erstellungsdatum «dcterms:created»
Zeitlicher Bezug «dcterms:temporal»
Herausgabedatum (Kulturgut), Herausgabedatum (Digitalisat) «dcterms:issued»
Verknüpfung des Objekts mit Objekten/Personen «edm:hasMet» (mit kontextueller Klasse zur Zeitspanne «edm:TimeSpan»)
Suche nach Subjekt oder Typ

Thema

«dc:subject» (mit kontextueller Klasse zum Handlungsträger «edm:Agent»)
Objekttyp «dc:type»
Material «dcterms:medium»
Dateiformat «dc:format»
Suche nach Handlungsträger
Schöpfer:in: (Kulturgut)Schöpfer:in (Digitalisat) «dc:creator»
Beitragende:r «dc:contributor»
Veröffentlicht durch «dc:publisher»
Thema «dc:subject» (mit kontextueller Klasse zum Handlungsträger «edm:Agent»)
Verbindungen des Objekts zu Objekten/Personen «edm:hasMet»
Suche nach Orten
Räumlicher Bezug «dcterms:spatial»
Standort «edm:currentLocation»
Thema mit Eintrag zum Ort «dc:subject» (mit kontextueller Klasse zum Ort «edm:Place»)

Linktipps

Sprach-Tags in EDM

Die Kennzeichnung der Sprache von Informationen in Feldern der EDM-Metadaten passiert über Sprach-Tags. Sprach-Tags sind Qualitätsmerkmale in den 3 Qualitätsstufen für Metadaten von Europeana und wichtige Kriterien für gute Datenqualität nach den FAIR-Prinzipien, neben dem Verwenden von kontrollierten Vokabularen und passenden Lizenzangaben.

Zu Informationen in Metadatenfeldern können Sprach-Tags hinzugefügt werden, um die Sprache des Inhalts zu bezeichnen. Dadurch können diese Informationen in mehrere Sprachen übersetzt werden. So wird der Inhalt für eine mehrsprachige Öffentlichkeit bestmöglich zugänglich. 

<dc:type xml:lang="de">Gemälde</dc:type>
<dc:type xml:lang="en">painting</dc:type>
<dc:type xml:lang="fr">peinture</dc:type>

Wenn etwa das Wort „Gemälde“ mit dem Sprach-Tag „de“ versehen wird, können es Nutzerinnen und Nutzer auf der Website auch mit „painting“ (Englisch) und „peinture“ (Französisch) finden.

Für die Sprachcodes (language code) sollten, wenn möglich, die Sprachcodes der → ISO 639 verwendet werden, etwa die zweistelligen ISO 639-1 Codes oder die dreistelligen ISO 639-3 Codes.

sprach-tags.png

Beispiel für Sprach-Tags in den Metadaten des Kulturpools. (Quelle)

Anforderungen für die Stufen der Metadatenqualität

Für jede drei Qualitätsstufen für Metadaten nach Europeana (Stufe A–C) ist ein bestimmter Prozentsatz von Sprach-Tags in den Metadaten erforderlich, der abhängig von den bereitgestellten Eigenschaften des Kulturguts ist. Der Prozentsatz bezieht sich dabei auf alle angegebenen Metadaten über das Kulturgut («edm:ProvidedCHO»), die einen Texteintrag (Literal/String) erlauben und für einen Sprach-Tag qualifiziert sind.

Für Objekte mit dem Medientyp „Text“ ist eine Angabe der verwendeten Sprache des Objekts verpflichtend; für andere Medientypen mit sprachlichen Elementen (Bild, Audio, Video, 3D) wird sie empfohlen.

Stufe A: Mindestens 25 % der benutzten Felder aus unten stehender Tabelle muss ein Sprach-Tag zugeordnet sein, entweder mit einem Sprachcode (z. B. xml:lang=“de“) oder mit einem Link zu einer kontextbezogenen Entität.

Stufe B: Mindestens 50 % der benutzten Felder muss ein Sprach-Tag zugeordnet sein.

Stufe C: Mindestens 75 % der benutzten Felder muss ein Sprach-Tag zugeordnet sein.

Relevante EDM-Metadatenfelder für Sprach-Tags

Hinweis: Diese Felder beziehen sich auf das Kulturgut. Pflichtfelder sind fett markiert.

EDM-Metadatenfelder mit Sprach-Tags

Kurzbeschreibung EDM-Felder mit Sprach-Tags
Beschreibung
«dc:description»
Nutzungsrecht
«edm:rights»
Thema (am besten mit kontrolliertem Vokabular) «dc:subject»
Titel «dc:title»
Räumlicher Bezug
«dcterms:spatial»
Objekttyp (am besten mit kontrolliertem Vokabular) «dc:type»
Zeitlicher Bezug
«dcterms:temporal»
Bezug
«dc:coverage»
Format
«dc:format»
Beziehung zu anderem Objekt
«dc:relation»
Objekt, von dem dieses Objekt ein Teil ist «dc:source»
Alternativer Titel
«dcterms:alternative»
Anderes Objekt, das Teil dieses Objekts ist «dcterms:hasPart»
Ist ein Teil von
«dcterms:isPartOf»
Referenziert von
«dcterms:isReferencedBy»
Material «dcterms:medium»
Provenienz
«dcterms:provenance»
Referenz «dcterms:references»
Liste von Untereinheiten dieses Objekts
«dcterms:tableOfContents»
Standort «edm:currentLocation» 
Konzeptkategorie, Subkategorie zu dc:type oder dc:format
«edm:hasType»
Allgemeine Eigenschaft für Kontexte oder Zusammenhänge «edm:isRelatedTo»

Linktipps

Validierung von EDM mit Metis Sandbox

Zur Validierung von EDM stellt Europeana die „Metis Sandbox“ unter metis-sandbox.europeana.eu/new bereit. Dort hochgeladene Datensets werden nicht nur auf Korrektheit überprüft, sondern auch gleich auf die Qualitätsstufen für Metadaten von Europeana untersucht.

Upload-Ansicht

Screenshot 2024-04-17 at 12.10.00.png

Wenn Sie Ihren Testdatensatz hochladen, müssen ein Name, das Land und die Sprache immer angegeben werden. Der Name bezieht sich auf das Testdatenset und ist frei wählbar, darf aber bis auf Unterstriche keine Sonderzeichen enthalten. Die Daten können über den Dateiupload („File upload“) direkt hochgeladen werden oder von einer OAI-PMH-Schnittstelle oder einer URL abgerufen werden. 

Format für den Dateiupload

Für den Dateiupload („File upload“) gibt es bestimmte Vorgaben, was das erwartete Format angeht:

Beispiel für einen fehlerhaften Datensatz

In der Metis Sandbox durchlaufen die Daten mehrere Phasen. Scheitert die Validierung, so wird dies bei der entsprechenden Phase angezeigt:

Screenshot 2024-04-17 at 15.24.01.png

In der Detailansicht über den Klick auf „view detail“ zeigt sich in diesem Fall recht schnell, dass der Record weder Titel noch Beschreibung aufweist, wobei eines der beiden verpflichtend gewesen wäre.

Screenshot 2024-04-17 at 15.24.39.png

Beispiel für eine erfolgreiche Validierung

Screenshot 2024-04-17 at 15.22.44.png

Verläuft die Validierung erfolgreich, können über einen Klick auf das Tortendiagramm-Icon Informationen zu den Europeana Content- und Metadata-Stufen („Content Tier“, „Metadata Tier“) eingesehen werden:

Screenshot 2024-04-17 at 15.29.56.png

Einschränkungen der Metis-Sandbox

Linktipp

Bereitstellung von IIIF-Bildern im EDM

Einleitung

Grundlegend können bei der Lieferung von bildlichen Ressourcen an den Kulturpool in Bezug auf IIIF exakt drei Szenarien auftreten, wenn Metadaten bereitgestellt werden. Die Szenarien sind aufeinander aufgebaut, steigen in ihrer Mehrwertigkeit, aber dementsprechend auch in ihrer Komplexität.

Die drei Szenarien lauten wie folgt:

Vorweg sei erwähnt, dass es möglich ist die genannten Szenarien theoretisch innerhalb einer Auslieferung miteinander zu kombinieren (auch wenn dies sehr selten passieren wird). So ist es z. B. vollkommen konform die folgenden Szenarien im Rahmen eines ausgespielten Objektes zu verbinden:

In Folge wird die korrekte technische Umsetzung des jeweiligen Szenarios und die zugehörigen Resultate im Sinne eines Mehrwertes geschildert.

Ressourcen die nicht dem IIIF Protokoll entsprechen

Ausführung

Beispiel

Deklaration

<rdf:RDF [...]>
	[...]
    <edm:WebResource rdf:about="https://beispiel-institution.at/bild-1.jpg">
		[ ... ]
    </edm:WebResource>
    
    <edm:WebResource rdf:about="https://beispiel-institution.at/bild-2.jpg">
		[ ... ]
    </edm:WebResource>

    <edm:WebResource rdf:about="https://beispiel-institution.at/bild-3.jpg">
		[ ... ]
    </edm:WebResource>
	[ ... ]
</rdf:RDF>

Referenz

<rdf:RDF [...]>
	[ ... ]
	<ore:Aggregation [...]>
		<edm:isShownBy rdf:resource="https://beispiel-institution.at/bild-1.jpg"/>
		<edm:hasView rdf:resource="https://beispiel-institution.at/bild-2.jpg"/>
		<edm:hasView rdf:resource="https://beispiel-institution.at/bild-3.jpg"/>
		
		[ ... ]
	</ore:Aggregation>
	[ ... ]
</rdf:RDF>

Resultat

Ressourcen die dem IIIF Protokoll entsprechen

IIIF Ressourcen ohne Manifest und mit Deklaration der IIIF Image API

Ausführung

Wie oben ...

Darüberhinaus ...

Beispiel

Deklaration

<rdf:RDF [...]>
	[...]
    <edm:WebResource rdf:about="https://beispiel-institution.at/iiif-service/bild-1/full/max/0/default.jpg">
	    <svcs:has_service rdf:resource="https://beispiel-institution/iiif-service/bild-1/"/>
		[ ... ]
    </edm:WebResource>
    
    <edm:WebResource rdf:about="https://beispiel-institution.at/iiif-service/bild-2/full/max/0/default.jpg">
	    <svcs:has_service rdf:resource="https://beispiel-institution/iiif-service/bild-2/"/>
		[ ... ]
    </edm:WebResource>

    <edm:WebResource rdf:about="https://beispiel-institution.at/iiif-service/bild-3/full/max/0/default.jpg">
	    <svcs:has_service rdf:resource="https://beispiel-institution/iiif-service/bild-3/"/>
		[ ... ]
    </edm:WebResource>

	<svcs:Service rdf:about="https://beispiel-institution/iiif-service/bild-1/">
	    <dcterms:conformsTo rdf:resource="http://iiif.io/api/image"/>
	    <doap:implements rdf:resource="http://iiif.io/api/image/2/level1.json"/>
	</svcs:Service>

	<svcs:Service rdf:about="https://beispiel-institution/iiif-service/bild-2">
	    <dcterms:conformsTo rdf:resource="http://iiif.io/api/image"/>
	    <doap:implements rdf:resource="http://iiif.io/api/image/2/level1.json"/>
	</svcs:Service>

	<svcs:Service rdf:about="https://beispiel-institution/iiif-service/bild-3">
	    <dcterms:conformsTo rdf:resource="http://iiif.io/api/image"/>
	    <doap:implements rdf:resource="http://iiif.io/api/image/2/level1.json"/>
	</svcs:Service>

	[ ... ]
</rdf:RDF>

Referenz

<rdf:RDF [...]>
	[ ... ]
	<ore:Aggregation [...]>
		<edm:isShownBy rdf:resource="https://beispiel-institution.at/iiif-service/bild-1/full/max/0/default.jpg"/>
		
		<edm:hasView rdf:resource="https://beispiel-institution.at/iiif-service/bild-2/full/max/0/default.jpg"/>
		<edm:hasView rdf:resource="https://beispiel-institution.at/iiif-service/bild-3/full/max/0/default.jpg"/>
	</ore:Aggregation>
	[ ... ]
</rdf:RDF>

Bei dem angeführten Beispiel sei die Struktur der URLs wie folgt näher beschrieben:

Weiter sei der Zusammenhang zwischen den Identifikatoren der edm:WebResource Ressourcen und der svcs:Service Ressource hervorgehoben:

Resultat

Wie oben ...

Darüberhinaus ...

IIIF Ressourcen mit Manifest und mit Deklaration der IIIF Image API

Ausführung

Wie oben ...

Darüberhinaus ...

Beispiel

Deklaration

<rdf:RDF [...]>
	[...]
    <edm:WebResource rdf:about="https://beispiel-institution.at/iiif-service/bild-1/full/max/0/default.jpg">
	    <svcs:has_service rdf:resource="https://beispiel-institution/iiif-service/bild-1/"/>
	    <dcterms:isReferencedBy rdf:resource="https://beispiel-institution/iiif-service/manifest.json"/>
		[ ... ]
    </edm:WebResource>

	<svcs:Service rdf:about="https://beispiel-institution/iiif-service/bild-1/">
	    <dcterms:conformsTo rdf:resource="http://iiif.io/api/image"/>
	    <doap:implements rdf:resource="http://iiif.io/api/image/2/level1.json"/>
	</svcs:Service>

	[ ... ]
</rdf:RDF>

Referenz

<rdf:RDF [...]>
	[ ... ]
	<ore:Aggregation [...]>
		<edm:isShownBy rdf:resource="https://beispiel-institution.at/iiif-service/bild-1/full/max/0/default.jpg"/>
		
	</ore:Aggregation>
	[ ... ]
</rdf:RDF>

Resultat

Wie oben ...

Darüberhinaus ...