Dublin Core

Dublin Core ist ein Metadatenschema zur Beschreibung von elektronischen Ressourcen.

Genauer handelt es sich um eine Sammlung einfacher und standardisierter Konventionen zur Beschreibung von Dokumenten und anderen Objekten im Internet, um diese mit Hilfe von Metadaten einfacher auffindbar zu machen. Urheber dieses Schemas ist die „Dublin Core Metadata Initiative“ (DCMI).

Die DCMI wurde 1994 am Rande einer World-Wide-Web-Konferenz in Chicago gegründet. Einige an Fragen der Informationsbeschreibung und -erschließung Interessierte beschlossen dort, eine Konferenz zu diesen Themen zu organisieren. Diese Konferenz, die im März 1995 in Dublin/Ohio stattfand, wurde nach den organisierenden Organisationen, dem Online Computer Library Center und dem National Center for Supercomputing Applications, OCLC/NCSA Metadata Workshop genannt. Im Rahmen dieser Konferenz einigten sich die etwa 50 Teilnehmer auf eine Grundmenge von beschreibenden Termen für die Kategorisierung von Webressourcen und nannten diese Metadatenmenge nach dem Tagungsort Dublin Core metadata.

Autoren von Webressourcen sollten durch dieses Metadatenschema in die Lage versetzt werden, ihre Ressourcen so zu beschreiben, dass sie etwa von stichwortbasierten Suchmaschinen gefunden werden können. Da das Schema schnell die Aufmerksamkeit von Bibliotheken, Museen usw. auf sich zog, entwickelte sich aus dieser Initiative ein internationales Übereinkommen über eine Kernmenge von Metadaten.

Die DCMI verfügt über eine Reihe von spezialisierten Arbeitsgruppen („Communities“). Die Mitarbeit in diesen Arbeitsgruppen ist freiwillig und unentgeltlich, beteiligt sind vor allem Mitarbeiter der Organisationen, die an der Weiterentwicklung und Verbreitung von Metadaten-Standards ein Interesse haben. Die Arbeit dieser Gruppen wird von einer kleinen Gruppe, dem Direktorat, angeleitet. Dem Direktorat steht eine Art Aufsichtsrat zur Seite (Board of Trustees). Daneben gibt es als beratende Gremien das Advisory Board, das im Wesentlichen aus den Leitern der Arbeitsgruppen und aus externen Experten besteht, und das Usage Board, dessen Aufgabe die Entwicklung einer adäquaten Terminologie für die Metadaten-Kategorien ist.

Die aktuellen Aufgaben der DCMI sind die Weiterentwicklung und Pflege des Metadatenschemas, die Entwicklung von Werkzeugen und Infrastrukturen, die die Verwaltung und Pflege von Metadaten erleichtern und die Verbreitung von Wissen und Kenntnissen über Metadaten durch Schulungen usw.

Folgende 15 Kernfelder, engl. core elements, werden als „Dublin Core Metadata Element Set, Version 1.1 (ISO 15836)“ von DCMI empfohlen. Die „DCMI Metadata Terms“ empfehlen zusätzliche Felder sowie detaillierende Felder (element refinements), die eine auf speziellere Bedürfnisse zugeschnittene Beschreibung bzw. Kategorisierung erlauben. Alle Felder sind optional, können mehrfach auftauchen und im Gegensatz zu anderen Metadaten-Schemata in beliebiger Reihenfolge stehen. ‚Dokument‘ steht hier stellvertretend für Werk bzw. ganz allgemein Quelle.

• identifier: Eindeutige Identifizierung des Dokuments nach einem passenden Katalog, beispielsweise ISBN/ISSN, URL/PURL, URN oder DOI, sowie ggf. den Eintrag (bibliographicCitation), wie das Dokument zu zitieren ist.

• format: Die Formatangabe soll eine Hilfe geben, womit das Dokument dargestellt bzw. weiterverarbeitet werden kann; Größe oder Laufzeit als (extent); Medientyp (medium) als Angabe des physikalischen Datenträgers oder Materials, auf digitale Inhalte bezogen sinnvollerweise als MIME-Typ anzugeben.
• type: Art bzw. Gattung des Dokuments, bezeichnet am besten mithilfe eines Terminus, noch korrekter durch Nennung eines URI aus dem „DCMI Type Vocabulary“.
  • Kollektion („Collection“) von Unterdokumenten mit jeweils eigenen Metadaten.
    accrualPolicy: Nach welchen Kriterien ist die collection zusammengestellt?
    accrualMethod: Mit welchem Verfahren erfolgt die Zusammenstellung?
    accrualPeriodicity: Mit welcher Häufigkeit werden Unterdokumente hinzugefügt?
  • Ereignis von beschränkter Zeitdauer („Event“), wobei der Metadatensatz besonders offensichtlich gewissermaßen zum Selbstzweck wird und so etwas wie einen Kalendereintrag mit Verweis auf die eigentliche Quelle darstellt.
  • Tonmaterial („Sound“) von Sprachaufnahmen über Klänge bis zur Audio-CD, das für die direkte Tonwiedergabe gedacht ist (vgl. ID3-Tag).
  • Bildmaterial („Image“) wird für Fotografien, Gemälde, Drucke, Landkarten, Diagramme und Zeichnungen oder Noten sowie auch für Animationen, Filme/Videos oder Fernsehprogramme als Oberbegriff verwendet. Letztere werden durch ein zweites Typ-Element ("Moving Image") als bewegte gekennzeichnet (vgl. MPEG-7), erstere durch ein zweites Typ-Element ("Still Image") als unbewegte (vgl. IPTC), oder als Abbildung von Textbasiertem ("Text").
  • Textbasierte Inhalte („Text“).
  • Reale, physische Objekte („Physical Object“), nicht aber deren Abbildungen („Image“) oder Beschreibungen („Text“).
  • Interaktives Dokument („Interactive Resource“), das Benutzereingaben erfordert, z. B. ein Formular.
  • Programm („Software“) als Quelltext oder in ausführbarer Form, soweit es nicht ein interaktives Dokument ist, sondern für die dauerhafte Installation.
  • Datensatz („Dataset“) in spezieller, definierter Kodierung, die für die maschinelle Weiterverarbeitung gedacht ist.
  • Dienste oder Dienstleistungen („Service“), wie ein Copy-Shop oder auch ein Web-Server.
• language: Sprache des Dokumenteninhalts. Empfohlen wird ein Sprachkürzel nach ISO 639, bei Bedarf ergänzt um einen Länderkürzel nach DIN EN ISO 3166, dem ein „Hyphen-Minus“ vorangestellt ist: beispielsweise also gsw für Schweizerdeutsch, ger-ch für Schriftdeutsch nach Schweizer Regeln, ger-de-by für Bayerisch, oder schlicht ger bzw. gebräuchlicher de für Deutsch. Die in einzelnen Elementen (z. B. s. u. alternative) verwendete Sprache wird nicht durch language gekennzeichnet, sondern mit entsprechender Kürzelbildung im Element selber.

• title: Titel des Dokuments, unter dem es „formell bekannt“ gemacht wird. Das Feld wird von anzeigenden Programmen gerne in den Titelbalken übernommen. Abkürzungen oder auch Übersetzungen des Titels werden alternativ zum formellen Titel (alternative) angegeben.
• subject: Thema des Inhalts in suchtauglichen Schlagwörtern (keyword), die bestenfalls einem formalen Klassifikationsschema folgen.
• coverage: Eingrenzung des vom Dokument inhaltlich abgedeckten Bereichs allgemein, räumlich/örtlich beispielsweise durch Namen nach TGN, auch durch Angabe von Koordinaten (spatial) oder zeitlich (temporal) in Zahlen unter Benennung einer Ära oder Periode.
• description: Kurzzusammenfassung des Inhalts des Dokuments in Freitext (abstract), Kopie des Inhaltsverzeichnisses bzw. Liste der Bestandteile (tableOfContents) oder als Verweis auf eine beschreibende Quelle. Das Feld wird in Dialogen von bearbeitenden Programmen gerne als „Kommentar“ gelistet.

• creator: Nach DCMI der Name derjenigen Person oder Organisation, die vorrangig für die Anfertigung des Dokuments verantwortlich ist, also der verantwortliche Verfasser oder Urheber (vgl. source, contributor sowie publisher) des Dokuments in seiner aktuellen Fassung. Das sollte, muss aber nicht, eine natürliche Person sein.
• publisher: Name der veröffentlichenden Instanz, typischerweise der Verleger oder Herausgeber. Auch hier muss nicht, aber sollte die verantwortliche natürliche Person benannt werden.
• contributor: Name je einer weiteren Person, die zur Erstellung des Dokuments einen Beitrag geleistet bzw. verantwortet hat.
• rights: Information zur Klarstellung der Rechte, die an dem Dokument gehalten werden oder dies betreffend zu beachten sind, als Direktangabe, in Form eines Verweises (URI) auf Lizenzbedingungen (license) oder Rechteverwerter. Unter (accessRights) wird der Sicherheitsstatus des Dokuments spezifiziert und wer Zugriff darauf hat bzw. haben darf.

• source: Verweist (vgl. o. Identifier) auf ein Dokument, von dem das aktuell beschriebene Dokument ganz oder in Teilen abgeleitet wurde.
• relation: Verweist (vgl. o. Identifier) auf ein Dokument, mit dem das beschriebene Dokument in Beziehung steht.
  Wird ersteres Dokument zitiert o. ä., wird es vom beschriebenen referenziert (references); umgekehrt wird das beschriebene selber vom referenzierten referenziert (isReferencedBy).
  Wenn das Referenzierte vom Referenzierenden bei Beibehaltung des Inhalts abgeleitet wurde, hat letzteres i. S. der Beschreibung nur ein Format (hasFormat); umgekehrt ist das Referenzierende nur ein Format des Referenzierten (isFormatOf).
  Wenn das Referenzierte logisch oder physikalisch im Referenzierenden enthalten ist, hat das Referenzierende es zum Bestandteil (hasPart) oder nur eine Version davon (hasVersion); umgekehrt ist das Referenzierende Teil bzw. Version des ersteren (isPartOf) bzw. (isVersionOf).
  Wenn ersteres Dokument von letzterem ersetzt wird (replaces); umgekehrt (isReplacedBy).
  Wenn das Referenzierte vom Referenzierenden als Voraussetzung für seine Funktionsfähigkeit benötigt wird (requires); umgekehrt (isRequiredBy).
  Auf einen Standard einer Norm, der das beschriebene Dokument genügt, kann in (ConformsTo) verwiesen werden.

• date: Ein charakteristisches Datum oder auch eine Zeitspanne im Lebenszyklus des Dokuments, sinnvollerweise in Notation nach DIN ISO 8601 als JJJJ-MM-TT, auch im Sinne von Bearbeitungsvermerken und durchaus auch in die Zukunft gerichtet. Im Zweifelsfall das Datum der letzten Dokumentänderung. Sonst das relevante Datum bzgl. Copyright (dateCopyrighted), „erstellt am“ (created), „vorgelegt am“ (dateSubmitted), „geändert am“ (modified), „eingegangen am“ (dateAccepted), „veröffentlicht am“ (issued), „steht bereit von bis“ (available), „in Kraft getreten am, gültig von bis“ (valid).

Dublin-Core-Metadaten können zum Beispiel mit RDF/XML dargestellt werden. Sie sind Bestandteil von Dokumenten im standardisierten OpenDocument-Format. Eine weitere Beispielanwendung ist RSS 1.0.

In normalen, in HTML verfassten Webseiten können Dublin-Core-Metadaten mit dem allgemeinen meta-Element im Dokumentkopf angegeben werden. Als Hinweis auf den verwendeten Namensraum sollte "DC." für die Kernelemente bzw. "DCTERMS." für Refinements vorangestellt werden. Sinnvollerweise wird zuerst die Referenzdefinition des verwendeten Schemas indiziert.

Beispiel:

<head profile="http://dublincore.org/documents/dcq-html/">
  <title>Dublin Core</title>
  <link rel="schema.DC"      href="http://purl.org/dc/elements/1.1/" />
  <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
  <meta name="DC.format"        scheme="DCTERMS.IMT"      content="text/html" />
  <meta name="DC.type"          scheme="DCTERMS.DCMIType" content="Text" />
  <meta name="DC.title"         content="Dublin Core" />
  <meta name="DC.publisher"     content="Jimmy Wales" />
  <meta name="DC.subject"       content="Dublin Core Metadaten-Elemente, Anwendungen" />
  <meta name="DC.creator"       content="Björn G. Kulms" />
  <meta name="DCTERMS.license"  scheme="DCTERMS.URI" content="http://www.gnu.org/copyleft/fdl.html" />
  <meta name="DCTERMS.rightsHolder" content="Wikimedia Foundation Inc." />
  <meta name="DCTERMS.modified" scheme="DCTERMS.W3CDTF" content="2006-03-08" />
</head>

• Liste von Metadatenformaten
• Semantic Web
• Semantischer Desktop
• Sacherschließung
• Formalerschließung
• WebCite

• Dublin Core Metadata Initiative (englisch)
• Dublin-Core-Metadaten in HTML-Dokumente einbetten (englisch)
• Dublin-Core-Metadaten in RDF/XML ausdrücken (englisch)
• SELFHTML: Metaangaben nach Dublin-Core
• Beispiel für Dublin-Core-Metadaten

1. ↑ Ein Link zu diesem Datensatz findet sich hier: https://lccn.loc.gov/38020780, abgerufen am 27. Dezember 2014.