Europeana Data Model (EDM)
Einstieg zu Pflichtfeldern und empfohlenen Feldern in den Metadaten des EDM-Metadatenstandards
- Einstieg: Pflichtfelder
- Einstieg: Europeana Data Model (EDM)
- Pflichtfelder zum Kulturgut
- Pflichtfelder zum digitalen Objekt
- Technischer Aufbau EDM
- Kurzreferenz EDM-Pflichtfelder
- Weitere empfohlene Felder
- Kontextuelle Klassen in EDM
- Beispiel-Datensätze in EDM
- Qualität der Metadaten
- 3 Qualitätsstufen für Metadaten nach Europeana
- Sprach-Tags in EDM
- Validierung von EDM mit Metis Sandbox
- Bereitstellung von IIIF-Bildern im EDM
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.
- Titel «dc:title»
- Beschreibung «dc:description»
- Identifikator «dc:identifier»
- Sprache «dc:language»
- Medientyp «edm:type»
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.
- Thema «dc:subject»
- Räumlicher Bezug «dcterms:spatial»
- Zeitlicher Bezug «dcterms:temporal»
- Objekttyp «dc:type»
Pflichtfelder zum digitalen Objekt
- Daten-Provider «edm:dataProvider»
- Nutzungsrecht «edm:rights»
- Rechteinhaber:in «dc:rights»
- Ressourcenadresse «edm:isShownBy»
- Kontextadresse «edm:isShownAt»
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.
Die Metadatenfelder, wie sie sich aus Sicht der Nutzerinnen und Nutzer zeigen. Grafik: Kulturpool, CC0.
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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
- EDM Mapping Guidelines – offizielle umfassende Dokumentation im Wiki
- Factsheet: The Europeana Data Model for Cultural Heritage (PDF)
- Europeana Publishing Framework – beschreibt die Content- und Metadata-Qualitätsstufen
- Europeana und FAIR-Prinzipien – Europeana erfüllt die FAIR-Prinzipien
- Europeana: Metadata – Informationen zu den Metadaten im EDM
- Mag.art. Julian Palacz: Einführung in die Metadatenstandards (Kulturpool Webinar)
- Lukas Graf, BSc: Grundlagen Metadaten (Kulturpool Webinar)
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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>
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/300263554
für Tiermalerei (mehrere Werte sind möglich)
<dc:type rdf:resource="http://vocab.getty.edu/aat/300033618" />
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
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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" />
Im Kulturpool verweist die Kontextadresse stets auf das Objekt in der Originalsammlung der Institution. Die Ressourcenadresse ist nicht sichtbar.
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
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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».
- «ore:Aggregation»: Dient als Haupteinstiegspunkt beim Lesen eines Datensatzes. Verweist weiter auf «edm:ProvidedCHO» und «edm:WebResource» und enthält ein paar Grundinformationen, wie die liefernde Institution. Muss genau einmal pro EDM-Datensatz vorkommen.
- «edm:ProvidedCHO»: Beinhaltet Informationen zum Kulturgut (Cultural Heritage Object) selbst. Muss genau einmal pro EDM-Datensatz vorkommen.
- «edm:WebResource»: Beinhaltet Daten zu einem Digitalisat (z. B. Bild oder 3D-Modell des Kulturguts). Kann öfter vorkommen (z. B. Bild des Objekts von vorn, Bild des Objekts von der Seite).
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:
- Es gibt Objekte (
edm:ProvidedCHO
,edm:WebResources
…) mit Properties (z. B.:dc:title
,dc:type
…). Diese Properties können entweder auf ein anderes Objekt verweisen oder auf einen Literal (z. B.: „Gemälde“), wodurch eine Graphenstruktur entsteht. - Objekte werden über eine eindeutige ID (URI) identifiziert, die für den Verweis von anderen Objekten aus verwendet wird.
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&metadataPrefix=edm&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&metadataPrefix=edm&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>
- Das äußerste Element ist immer ein
rdf:RDF
-Tag, hier werden die vollen Namespaces für alle verwendeten prefixes angegeben (rdf, dc, edm …) - Die Objekte
ore:Aggregation
,edm:ProvidedCHO
undedm:WebResource
sind hierarchisch alle auf derselben Ebene definiert und bekommen über das Attributrdf:about
eine eindeutige URI zugewiesen. Diese muss nicht auflösen, sondern dient in erster Linie als ID, über die darauf verwiesen werden kann. - Andere Properties wie
edm:aggregatedCHO
können über das Attributrdf:resource
auf ein Objekt mit der angegebenen URI verweisen. - Für die
edm:WebResource
-Objekte ist die identifizierende URI auch gleichzeitig die URL, unter der die Ressource abrufbar ist. - Wenn zu einem Property mehrere Werte vorhanden sind, können diese einfach ein weiteres Mal angegeben werden (mit wenigen Ausnahmen, siehe besonders
isShownBy
undisShownAt
). - Wenn die Sprache eines Felds bekannt ist, kann diese im Attribut
xml:lang
angegeben werden.
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:
- «edm:Agent»: Eine natürliche oder juristische Person, oder Gruppe
- «edm:Place»: Ein Ort
- «edm:TimeSpan»: Eine Zeitspanne
- «skos:Concept»: Ein Konzept
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
:
- Selbst gewählte URLs aus einer eigenen Domäne.
- Dienen in erster Linie als Identifikatoren und müssen großteils nicht auflösen. Ausnahmen sind hierbei Web-Ressourcen, deren URLs immer auf eine Repräsentation des Objekts auflösen müssen (z. B. Link zum Objekt im Kontext der eigenen Online-Sammlung oder Direktlink zu einer Datei als Digitalisat, z. B. Bild-, Audio-, Video- oder Textdatei).
- Global einzigartig, auch über Klassen hinweg (nicht selber Identifier für Aggregation und ProvidedCHO).
- Sollte sich in Zukunft nicht mehr ändern.
- Beispiel: https://museum.example/rdf/objects/cho_{identifier}, bzw https://museum.example/rdf/objects/aggregation_{identifier}
- Durch die Angabe eines erfundenen Pfades, der nicht auflöst, kann die Option offen gehalten werden, die RDF-Daten in Zukunft dort abrufbar zu machen.
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:
- «edm:type»: Muss exakt einmal angegeben werden und darf nicht öfter vorkommen. Es kann sein, dass mehrere Werte passen, dann muss man sich auf einen davon festlegen. Zum Beispiel wäre bei Urkunden mit Bildern als Digitalisaten sowohl TEXT als auch IMAGE argumentierbar. In diesem Fall würden wir eher TEXT empfehlen, da der Textinhalt noch immer im Vordergrund steht.
- «edm:rights»: Hier darf pro Aggregation oder Web-Ressource jeweils nur eine Lizenz angegeben werden. Wenn es mehrere Digitalisate mit unterschiedlichen Lizenzen gibt, sind diese Lizenzen in der jeweiligen Web-Ressoure anzugeben.
- «edm:isShownBy» und «edm:isShownAt»: Sollen jeweils nur einmal vorkommen für die Haupt-Web-Ressourcen. Wenn es weitere Digitalisate gibt, müssen diese in «edm:hasView» angegeben werden.
- «edm:object»
- «edm:aggregatedCHO»
- «edm:dataProvider» und «edm:provider»
Was ist der Unterschied zwischen xml:lang und «dc:language»?
- xml:lang ist ein Attribut, das für einzelne Felder angegeben werden kann, um die Sprache des angegebenen Werts zu kennzeichnen. Wenn möglich, sollte dies immer angegeben werden. Beispiel:
<dc:subject xml:lang="de">Porträt</dc:subject> <dc:subject xml:lang="en">portrait</dc:subject>
- «dc:language» ist ein eigenes Feld, in dem die Sprache des eigentlichen Kulturerbe-Objekts angegeben werden kann, wenn es einen sprachlichen Aspekt gibt (z. B. bei Texten oder Audio). Beispiel:
<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.
- Aggregationsobjekt «ore:Aggregation» ↓
- Kulturgut «edm:ProvidedCHO» ↓
- Digitale Ressource «edm:WebResource» ↓
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) | 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
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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 Grafiksammlung
, Bibliothek 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).
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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.
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.
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
- Überblick der Klasseneigenschaften im European Data Model (EDM)
- Zusammenfassung der Metadatengüte in Europeana (PDF)
- Getty Art & Architecture Thesaurus (AAT)
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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&metadataPrefix=marc21&identifier=oai:alma.ACCONB:990031578530603338#Aggregation">
<edm:aggregatedCHO rdf:resource="https://eu02.alma.exlibrisgroup.com/view/oai/43ACC_ONB/request?verb=GetRecord&metadataPrefix=marc21&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&metadataPrefix=marc21&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>
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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:
- Mit der Verwendung von persistenten Identifikatoren (PIDs) können einzelne Objekte eindeutig und dauerhaft verknüpfbar gemacht werden.
- Um die beschreibenden Daten vergleichbar zu machen, helfen kontrollierte Vokabulare. Ein Objekt kann damit etwa in einer Datenbank leichter parallel zu ähnlichen Objekten gefunden werden. Durch die Angabe eines Eintrags aus einem kontrollierten Vokabular können auch Fehler bei einer Freitexteingabe vermindert werden. Oft verwendete kontrollierte Vokabulare sind der Getty AAT, die gemeinsame Normdatei (GND), Iconclass, Wikidata oder VIAF. Auch die Dateiformate der Mediendateien, die als MIME-Types ausgewiesen werden, zählen somit zur Standardisierung.
- Zu den Metadaten sollten Sprach-Tags hinzugefügt werden. Diese geben die Sprache an, in der ein Metadatenfeld mit einem Freitext befüllt oder übermittelt wurde. Hierbei empfiehlt es sich, den → ISO-Standard 639 zu verwenden.
- Weitere Standards, wie etwa die ISO-Standards, helfen bei der Vereinheitlichung und der damit einhergehenden besseren Auffindbarkeit der Objekte. Beispielsweise normiert der Standard ISO 8601-1 die Zeit- bzw. Datumsangabe. Die Erweiterung ISO 8601-2 erlaubt es auch, dass ungefähre oder unbekannte zeitliche Angaben strukturiert und sinnvoll erfasst und auffindbar werden.
- Im Europeana Publishing Framework werden drei Qualitätsstufen für Metadaten definiert, die auf Kriterien wie Genauigkeit, Konsistenz und Vollständigkeit basieren.
- In der Arbeitsgruppe Minimaldatensatz u. a. von der Deutschen Digitalen Bibliothek (DDB) wurde eine Empfehlung für den Minimaldatensatz für Museen und Sammlungen erarbeitet. Diese soll Museen und Sammlungen helfen, konsistente und qualitativ hochwertige Daten online bereitzustellen. Dabei werden relevante Standards auf eine leicht verständliche und zugängliche Weise vermittelt und die Prinzipien von FAIR und CARE berücksichtigt. Die Empfehlung beschreibt sowohl erforderliche Daten für die Erfassung als auch für den Export der Daten an Kulturportale.
Es empfiehlt sich, für eine bessere Auffindbarkeit und eine bessere Vernetzung der Objekte die Daten einheitlich und strukturiert in der Datenbank einzutragen.
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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:
- Stufe A – Einfache Suchplattform: Die digitalen Objekte können über die Suche mit genauen Stichwörtern gefunden werden, auch kann man die Ergebnisse nach Kategorien filtern. Die Institutionswebsite wird verlinkt.
- Stufe B – Erkundungsplattform: Die digitalen Objekte können mit allgemeineren Begriffen gefunden werden, Sammlungen können im Kontext gezeigt werden. Die Objekte können in mehreren Sprachen gefunden werden und werden in thematischen Zusammenstellungen zu Personen, Orten und Organisationen präsentiert.
- Stufe C – Wissensplattform: Die digitalen Objekte können über Beziehungen zueinander gefunden werden (=„inspirationsorientierte“ Suche). Thematische Zusammenstellungen können für Projekte in Bildung, Forschung sowie in der Kultur- und Kreativwirtschaft verwendet werden, wodurch Reichweite und Bekanntheit der Institution verstärkt werden.
Anforderungen der einzelnen Stufen
Die verschiedenen Stufen der Metadatenqualität laut Europeana setzen sich zusammen aus:
- Prozentsatz der Sprachauszeichnungen (Sprach-Tags) in den relevanten benutzten Metadatenfeldern,
- Felder, die gewisse Such- und Browsing-Szenarien ermöglichen (siehe weiter unten) und
- Metadatenfelder aus kontextuellen Klassen.
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.
- Stufe A: Zumindest 25 % der relevanten EDM-Metadatenfelder haben eine Sprachauszeichnung. Es ist mindestens ein Metadatenfeld für weitere Suchszenarien ausgefüllt. Keine Bedingungen für die kontextuellen Klassen.
- Stufe B: Zumindest 50 % der relevanten EDM-Metadatenfelder haben eine Sprachauszeichnung. Es sind mindestens drei unterschiedliche Metadatenfelder für weitere Suchszenarien aus zwei verschiedenen Bereichen ausgefüllt. Mindestens eine kontextuelle Klasse mit allen Pflichtelementen oder einem Link zu einem unterstützten Linked-Open-Data-Vokabular existiert.
- Stufe C: Zumindest 75 % der relevanten EDM-Metadatenfelder haben eine Sprachauszeichnung. Es sind mindestens vier unterschiedliche Metadatenfelder für weitere Suchszenarien aus zwei verschiedenen Bereichen ausgefüllt. Mindestens zwei kontextuelle Klassen mit allen Pflichtelementen oder einem Link zu einem unterstützten Linked-Open-Data-Vokabular existieren.
Die Metadatenfelder für weitere Such- und Browsing-Szenarien stammen aus vier Bereichen:
- Suche nach Datum oder Zeitspanne
- Suche nach Subjekt und Typ
- Suche nach Handlungsträger
- Suche nach Orten
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 |
|
«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
- Europeana Publishing Framework
- Europeana Publishing Guide
- Europeana Publishing Framework: Metadata: Quick Summary (PDF)
- Europeana Publishing Framework: Content: Quick Summary (PDF)
- Europeana: Semantic Enrichment
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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.
<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.
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
- Europeana: Europeana Publishing Framework: Metadata. Quick Summary (PDF)
- Mindestanforderung Sprach-Tag von Europeana
- ISO 639-3 Liste der Sprach-Tags
Die Inhalte dieser Seite sind unter CC0 bereitgestellt.
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
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:
- Es muss eine ZIP-Datei hochgeladen werden.
- Darin müssen alle zu testenden Datensätze als einzelne XML-Dateien liegen.
- In diesen Dateien darf nur der EDM-Datensatz liegen (äußerstes Element rdf:RDF). Es darf also kein vollständiger OAI-PMH-Response sein.
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:
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.
Beispiel für eine erfolgreiche Validierung
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:
Einschränkungen der Metis-Sandbox
- Es werden pro Upload immer nur maximal 1.000 Datensätze validiert.
- Nicht alle Fehler können abgefangen werden, nicht erfasst werden etwa:
- rein inhaltliche Fehler,
- wenn URLs zu Vokabularen wie GND als Feldinhalt anstatt als
rdf:resource
angegeben sind, - wenn gleiche Werte in
rdf:about
für unterschiedliche Elemente angegeben sind.
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:
- Es werden Ressourcen zur Verfügung gestellt, die nicht dem IIIF Protokoll entsprechen.
- Es werden IIIF Ressourcen ohne IIIF Manifest zur Verfügung gestellt und die Kompatibilität mit der IIIF Image API wird deklariert.
- Es werden IIIF Ressourcen mit IIIF Manifest zur Verfügung gestellt und die Kompatibilität mit der IIIF Image API wird deklariert.
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:
- Es werden Ressourcen zur Verfügung gestellt, die nicht dem IIIF Protokoll entsprechen.
- Es werden IIIF Ressourcen mit IIIF Manifest zur Verfügung gestellt und die IIIF Kompatibilität wird deklariert.
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
- Eine oder mehrere Ressourcen der Klasse
edm:WebResource
zeigen die Existenz von bildlichen Inhalten an. - Auf die deklarierten Ressourcen wird in anderen Feldern des EDM (z.B.
edm:isShownBy
) verwiesen.
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
- Der Kulturpool generiert auf Basis der drei bereitgestellten Ressourcen ein basales IIIF-Manifest und beliefert damit den Viewer des Kulturpools.
- Auf der Detailseite des beispielhaften Objektes ist es möglich durch die drei bereitgestellten Bilder zu blättern.
- Der Viewer weist grundsätzliche Funktionalitäten wie z. B. Rotation und Zoom auf.
- Die Auflösung des Bildes ist festgelegt und wird - z. B. im Zuge des Zoomens - nicht adaptiert.
Ressourcen die dem IIIF Protokoll entsprechen
IIIF Ressourcen ohne Manifest und mit Deklaration der IIIF Image API
Ausführung
Wie oben ...
- Eine oder mehrere Ressourcen der Klasse
edm:WebResource
zeigen die Existenz von bildlichen Inhalten an. - Auf die deklarierten Ressourcen wird in anderen Feldern des EDM (z.B.
edm:isShownBy
) verwiesen.
Darüberhinaus ...
- Die angeführten bildlichen Inhalte werden über eine IIIF Image API ausgeliefert.
- Die URL der Ressourcen führt jeweils zu einem über das IIIF-Protokoll passend ausgelieferten Bild.
- Die zugrundeliegende IIIF API wird als Ressource mit
<svcs:Service>
deklariert.- Innerhalb der
<svcs:Service>
Ressource wird das Level der bereitgestellten Image API via<doap:implements>
deklariert. - Innerhalb der Ressource wird immer
<dcterms:conformsTo rdf:resource="http://iiif.io/api/image"/>
, d.h. der IIIF Standard ausgewiesen.
- Innerhalb der
- Webressourcen, die bildliche Inhalte über das IIIF Protokoll ausliefern referenzieren mit
<svcs:has_service>
die Basis URI des jeweiligen Bildes. - Der Identifier für
<svcs:Service>
(und dementsprechend auch in Verwendung beisvcs:has_service
) ist die Basis URI des Bildes.
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:
- Eine URL in der Form von z. B.
https://beispiel-institution.at/iiif/bild-1/full/max/0/default.jpg
ist ein starker Indikator dafür, dass ein URI Syntax auf dem IIIF Protokoll ((https://iiif.io/api/image/3.0/#2-uri-syntax) bedient wird. - Die URLs verweisen auf ein Bild. - Ein Webbrowser wäre fähig das Bild hinter der URL anzuzeigen.
- Die Syntax
full/max/0/default.jpg
garantiert im Sinne des IIIF Image Protokolls die Auslieferung eines passend formatierten Bildes:-
full
: Das Bild wird ohne jegliche Zuschnitte ausgeliefert. -
max
: Das Bild wird in voller größe ausgeliefert. -
0
: Das Bild wird ohne Rotation ausgeliefert. -
default
: Das Bild wird (im Gegensatz zu z. B.gray
oderbitonal
) in Standardqualität ausgeliefert.
-
Weiter sei der Zusammenhang zwischen den Identifikatoren der edm:WebResource
Ressourcen und der svcs:Service
Ressource hervorgehoben:
-
"rdf:about="https://beispiel-institution.at/iiif-service/bild-1/full/max/0/default.jpg"
ist die URL eines konkreten Bildes inklusive aller notwendigen IIIF Parameter. -
"rdf:about="https://beispiel-institution/iiif-service/bild-1/"
ist die URL des Endpoints der Parameter entgegen nimmt um das konkrete Bild auszuliefern.
Resultat
Wie oben ...
- Der Kulturpool generiert auf Basis der drei bereitgestellten Ressourcen ein basales IIIF-Manifest und beliefert damit den Viewer des Kulturpools.
- Auf der Detailseite des beispielhaften Objektes ist es möglich durch die drei bereitgestellten Bilder zu blättern.
- Der Viewer weist grundsätzliche Funktionalitäten wie z. B. Rotation und Zoom auf.
Darüberhinaus ...
- Die Auflösung des Bildes ist durch die Deklaration der IIIF Image API adaptiv wird im Zuges des Zoomens angepasst.
IIIF Ressourcen mit Manifest und mit Deklaration der IIIF Image API
Ausführung
Wie oben ...
- Eine oder mehrere Ressourcen der Klasse
edm:WebResource
zeigen die Existenz von bildlichen Inhalten an. - Auf die deklarierten Ressourcen wird in anderen Feldern des EDM (z.B.
edm:isShownBy
) verwiesen. - Die angeführten bildlichen Inhalte werden über eine IIIF Image API ausgeliefert.
- Die URL der Ressourcen führt jeweils zu einem über das IIIF-Protokoll (für einen Webclient) passend ausgelieferten Bild.
- Die zugrundeliegende IIIF API wird als Ressource mit
<svcs:Service>
deklariert.- Innerhalb der
<svcs:Service>
Ressource wird das Level der bereitgestellten Image API via<doap:implements>
deklariert. - Innerhalb der Ressource wird immer
<dcterms:conformsTo rdf:resource="http://iiif.io/api/image"/>
, d.h. der IIIF Standard ausgewiesen.
- Innerhalb der
- Webressourcen, die bildliche Inhalte über das IIIF Protokoll ausliefern referenzieren mit
<svcs:has_service>
die IIIF Image API. - Der Identifier für
<svcs:Service>
(und dementsprechend auch in Verwendung beisvcs:has_service
) ist die Basis URI der IIIF API.
Darüberhinaus ...
- Die via
edm:WebResource
deklarierten IIIF Ressourcen verweisen über<dcterms:isReferencedBy>
auf ein IIIF Manifest aus der Presentation API.
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 ...
- Der Viewer weist grundsätzliche Funktionalitäten wie z. B. Rotation und Zoom auf.
- Die Auflösung des Bildes ist durch die Deklaration der IIIF Image API adaptiv wird im Zuges des Zoomens angepasst.
Darüberhinaus ...
- Der Kulturpool verwendet das zur Verfügung gestellte IIIF-Manifest und beliefert damit den Viewer des Kulturpools.
- Auf der Detailseite des beispielhaften Objektes ist es möglich durch die über das Manifest bereitgestellten Bilder zu blättern.
- Der IIIF Viewer des Kulturpools zeigt die Metadaten aus dem Manifest direkt im Viewer an.