• Keine Ergebnisse gefunden

3.3 Metadaten zur Beschreibung des Archivinhaltes

3.3.1 Dublin Core Metadata Set

Der Bedarf an Metadaten besteht nicht erst seit der Beschäftigung mit Langzeitarchivie-rungsfragestellungen. Gerade mit dem explosionsartigen Wachstum online verfügbarer Infor-mationen und Dokumente stieg die Nachfrage nach zusätzlichen, genormten Beschreibungen von digitalen Objekten deutlich an. So gründete sich bereits 1994, noch vor dem großen Durchbruch des World Wide Web (WWW), die Dublin Core Metadata Initiative am Rande einer WWW-Konferenz.

Diese Initiative mündete ein Jahr später in einer Konferenz zur Informationserschließung und -beschreibung. Sie tagte in Dublin im amerikanischen Bundesstaat Ohio. Deshalb gab man einfach der beschlossenen Grundmenge (Kernmenge) von Beschreibungstermen den Na-men ”Dublin Core Metadata”. Diese Terme bezogen sich in erster Linie auf Web-Ressourcen, die kategorisiert und von den gerade aufkommenden stichwortbasierten Suchmaschinen besser gefunden werden sollten.

Die 15 Kernelemente, die um zusätzliche und weitergehend erklärende Felder erweitert werden konnten, erregten zügig das Interesse von Archivaren und Bibliothekaren. Deshalb kam es zu einer schnellen internationalen Verbreitung und einer Standardisierung14 durch die ISO.

DCMI Metadata Terms sind sehr flexibel und ohne feste Reihung angelegt: Jedes Feld ist optional und darf auch häufiger auftauchen. Durch die zusätzlich erlaubten detaillierenden Felder lassen sich auf spezielle Bedürfnisse zugeschnittene Kategorisierungen erreichen.

Eindeutige Kennung Jedes Objekt erhält eine eindeutige IDidentifier, welche seine Identi-fizierung nach einem zum Objekttyp passenden Katalog, wie URN, DOI oder klassischerweise ISBN/ISSN oder URL/PURL erlaubt. Gegebenenfalls wird der Identifier um ein Feld erweitert, wie das Objekt zitiert werden sollte.

Inhaltsbeschreibung Hierzu zählen die Felder:

• title legt den Titel des Objekts fest. Unter dieser Bezeichnung wird ein Objekt formell bekannt gemacht. Weitere Titelergänzungen, wie Übersetzungen, Originaltitel oder Ab-kürzungen gibt man alternativ zum formellen Titel (alternative) an.

• description liefert eine knappe Zusammenfassung des Inhalts. Hinzu können weitere Elemente, wie das Inhaltsverzeichnis oder Listen weiterer Objektbestandteile kommen, tableOfContents. Ebenso sind Verweise auf externe beschreibende Quellen möglich.

• subject entstammt optimalerweise einem formalen Klassifikationsschema. Anders als beimtitlestehen in diesem Feld suchtaugliche Schlagwörter, die dem Thema des Inhalts folgen.

• coverage dient der Eingrenzung von Bereichen, welches ein Objekt beschreibt oder wofür es gedacht ist. Dieses können zeitliche Beschränkung unter Angabe einer Periode, örtliche Beschreibungen oder Koordinaten sein.

14Die DCMI empfahl das ”Dublin Core Metadata Element Set, Version 1.1” zur Standardisierung, welches als ISO 15836 registriert wurde.

Technische Daten dienen in erster Linie Hinweisen zur Verarbeitung oder der Darstellung von Objekten:

• formatbeschreibt das logische Objekt (Abschnitt 2.3) und sein Datenformat (Abschnitt 2.3.2) und gibt damit Hinweise, wie ein Objekt sichtbar gemacht werden kann. Ergän-zende Informationen können Laufzeiten (extent) oder Medientypen (medium) enthal-ten.

• languagebezieht sich auf die natürliche Sprache des Objektinhalts. Dieses gilt sicherlich nicht für alle Objekttypen. Jedoch existieren eine ganze Reihe von Objekten, wie Do-kumente die in einer bestimmten Sprache abgefasst oder Applikationen, die lokalisiert sind. Zur Kennzeichnung sollte das Sprachkürzel nach ISO 639 und, wenn sinnvoll, ein Länderkürzel15 nach DIN EN ISO 3166 eingesetzt werden.

• typebeschreibt die Art oder Gattung eines Objekts, jedoch nicht sein konkretes Daten-format, welches im separaten Feldformat abgelegt wird. Es sollten bestimmte Termini verwendet werden, von denen das ”DCMI Type Vocabulary” eine Reihe vorschlägt.

collectionbezeichnet eine Sammlung von Teilobjekten, die mit eigenen Metadaten ver-sehen sind. Hinzu können nähere Beschreibungen, wieaccrualPolicy (Kriterien der Zu-sammenstellung), accrualMethod (Verfahren) oder accrualPeriodicity (Häufigkeit der Erweiterung) kommen. Weitere Termini sind:

– Texte (”text”) sind klassische statische Dokumente.

– Audiomaterial (”sound”) sind Musik- oder Sprachaufnahmen verschiedener For-men, wie unter anderem Audio-CDs.

– Bildmaterial (”image”) beschreibt die Klasse der Gemälde, Zeichnungen, verschie-dene Typen von Fotografien, Drucke, Landkarten, Diagramme oder Noten. Diese erhalten alle als Zweittyp (”still image”). Zu den Vorgenannten kommen Filme, Videos, Animationen oder Fernsehsendungen hinzu, die mit einem weiteren Typ-element (”moving image”) als bewegt gekennzeichnet werden.

– Klassische, reale Objekte können als (”physical object”) referenziert werden. Das könnte in der Langzeitarchivierung digitaler Objekte zur Beschreibung realer Hard-ware dienen.

– Interaktive Objekte (”interactive resource”, siehe vorherigen Abschnitt 3.2), wel-che vom Anwender Rückmeldungen erfordern, wie Flash-Animationen oder Web-Formulare, sind von Software abzugrenzen. Sie sind jedoch nicht ohne entspre-chende Player oder Dienste ablauffähig.

– Computerprogramme (”software”) können in direkt ausführbarer Binärform oder als Quelltext abgelegt werden. Letzteres bietet sich für Open Source Software an und könnte unter Umständen eine spätere Neukompilation für aktuelle Referen-zumgebungen erlauben.

15Siehe die jeweiligen ISO-Blätter. Der Standard ist durch das Internet Domain Name System sehr ver-breitet.

3.3. METADATEN ZUR BESCHREIBUNG DES ARCHIVINHALTES 55

– Datensätze (”dataset”) sind beispielsweise wissenschaftliche Primärdaten aus Mes-sungen oder Beobachtungen. Sie sollten in definierter Kodierung vorliegen. Da-tensätze nur durch eine Verarbeitung im Computer sinnvoll interpretierbar.

– Dienste (”service”) sind beispielsweise Web-Services zur Interaktion von Program-men über Computernetzwerke hinweg. Sie involvieren Software an beiden End-punkten der Verbindung.

Vernetzung und Einordnung von Objekten in Gesamtsysteme oder -zusammenhänge dient der Klassifizierung komplexerer und voneinander abhängiger Objekte und Sammlungen:

• source verweist auf ein Objekt (bezeichnet mit identifier), von dem das beschriebene Objekt in Teilen oder komplett abstammt. Ähnlich gelagert istrelation.

• relationbeschreibt Beziehungen zwischen verschiedenen Objekten, welche unterschied-lich aussehen können: Wird ein weiteres Dokument referenziert, kann dieses per refe-rences erfolgen, wird es selbst von anderen referenziert, geschieht das mit dem Feld isReferencedBy. Weitere Referenzen können in beide Richtungen über das Datenformat bestehen (hasFormatoderisFormatOf). Zudem kann ein Objekt in einem anderen ent-halten sein oder umgekehrt (hasPartoderisPartOf) oder ein anderes komplett ersetzen beziehungsweise selbst ersetzt werden (replaces umgekehrtisReplacedBy). Interessant sind für Verkettungen, beispielsweise die in Kapitel 6 beschriebenen View-Paths, die Felderrequiresoder für die andere Richtung isRequiredBy. Normen- oder Standardkon-formität lässt sich im Feld (ConformsTo) hinterlegen.

• audience dient der Klassifizierung der Zielgruppe des Objekts.

• instructionalMethod gehört zu den eher speziellen Feldern, die nur für bestimmte Ob-jekte, in diesem Fall Lehr- und Lernmaterialien, sinnvoll Anwendung finden.

Lebenszyklus gibt das Erstellungsdatum (created) des Objekts oder einen anderen charak-teristischen Zeitpunkt wie die Veröffentlichung (issued) an. Alternativ lassen sich Zeitspannen definieren, die am besten der Notation JJJJ-MM-TT16 folgen. Je nach Objekt können ande-re ande-relevante Daten eingesetzt werden: vorgelegt (dateSubmitted), von der Archivaufnahme akzeptiert (dateAccepted). Weiterhin kann ”steht bereit von bis” (available) oder ”in Kraft getreten am, gültig bis” (valid) oder auch ”rechtlich geschützt” (dateCopyrighted) markiert werden. Zulässig und sinnvoll ist in vielen Fällen auch das Datum der letzten Änderung zu vermerken.

Rechte und Personen Viele der in Bibliotheken und Archiven eingestellten digitalen Ob-jekte sind mit bestimmten Rechten versehen, die mit Personen oder Institutionen im Zusam-menhang stehen. Es ist deutlich vorzuziehen, Rechte per Metadaten über das Archivsystem zu verwalten, als Rechte direkt im Objekt zu verankern.17

16Jahr, gefolgt von Monat und Tag nach DIN ISO 8601.

17Vgl. diesbezügliche Diskussion in Abschnitt 7.11.

• creator benennt die letzte Person oder Institution, welche am Objekt Veränderungen vorgenommen hat. Dieses ist der verantwortliche Verfasser oder Urheber, der durch weitere Personen unterstützt gewesen sein könnte (siehe dazu source, contributorund publisher).

• contributorenthält Namen je einer weiteren Person, welche an der Erstellung, Bearbei-tung des Objekts beteiligt waren.

• publisherbezeichnet die veröffentlichenden Instanz. Dieses sind traditionellerweise Ver-leger oder Herausgeber.

• rightssammelt Hinweise und Informationen zu Rechten, die mit dem Objekt verknüpft und zu beachten sind. Dieses kann in Form einer Direktangabe oder auch als Verweis (URI) auf Lizenzbedingungen (license) erfolgen. Näher spezifiert werden kann dieses durchrightsHolder. Hierbei handelt es sich um den Namen einer Person oder Institution, die Verwertungsrechte am Objekt hat oder Eigentümer ist. Mit dem FeldaccessRights bezeichnet man den Sicherheitsstatus und welche Personen(gruppen) Zugriff darauf erhalten dürfen.

• provenancemacht Angaben zur Echtheit, Authentizität des Dokuments. Diese können in Form von Signaturen oder Hinweisen zur Veränderungsgeschichte vorliegen.

Eine Anwendung von Dublin Core Metadaten beschreiben [Ward 2003]. Sie sind Bestandteil von Dokumenten im standardisierten OpenDocument-Format. Eine weitere Beispielanwen-dung ist RSS 1.0.18 Ein weiteres Beispiel der Anwendung und Anlehnung an Dublin Core findet sich in [Gabriel und Ribeiro 2001]. Hier wird ein flexibles und erweiterbares Metada-tenschema für Archive, Bibliotheken und Museen speziell für Multimedia-Objekte, die aus mehreren Teilobjekten bestehen können, vorgeschlagen. In klassischen HTML-Seiten lassen sich Metadaten nach Dublin Core Schema mittels allgemeinen ”meta”-Element im Kopf des Dokuments definieren.

Ein Beispiel für den Kopf einer Web-Seite:

<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.publisher" content="Publisher" />

<meta name="DC.subject" content="Dublin Core Metadaten-Elemente" />

<meta name="DC.creator" lang="en" content="Name of Document Author" />

<meta name="DC.creator" lang="de" content="Name des Autors des Dokuments" />

<meta name="DCTERMS.license" scheme="DCTERMS.URI" \ content="http://www.gnu.org/copyleft/fdl.html" />

<meta name="DCTERMS.rightsHolder" content="Rechteinhaber" />

18Abkürzung für Really Simple Syndication – Konzept und Standard für die Verbreitung von Nachrichten im Internet.

3.3. METADATEN ZUR BESCHREIBUNG DES ARCHIVINHALTES 57

<meta name="DCTERMS.modified" scheme="DCTERMS.W3CDTF" content="2008-01-18" />

</head>

Einen Vorschlag der Anwendung von Dublin Core zur Beschreibung von Computerspielen am Beispiel des Atari VCS 2500 und C64 macht [Huth 2004], S. 102 ff. in einer exemplarischen Studie.