Metadatenformate - Labor für Business Information Systems

Transcription

University of Applied Sciences
Fachbereich Angewandte Informatik
Department of Computer Science
Seminararbeit
im Studiengang Master of Science in Computer Science
Metadatenformate
von
B.Sc. Kai Wiemer
Erstgutachter und Betreuer
Prof. Dr. Andreas Hense
Wirtschaftsinformatik
Zweitgutachter
Prof. Dr. Karl W. Neunast
Verteilte Systeme und deren Akzeptanz
Eingereicht am:
15.06.2008
Inhaltsverzeichnis
Abbildungen
4
Tabellen
5
Quellcode-Listings
6
Abkürzungsverzeichnis
8
1 Einleitung
9
2 Grundlagen
2.1 Typen von Metadaten . . . . . . . . . . .
2.1.1 Beschreibende Metadaten . . . . .
2.1.2 Strukturelle Metadaten . . . . . . .
2.1.3 Administrative Metadaten . . . . .
2.2 Verfahren zur Speicherung von Metadaten
2.2.1 Interne Metadaten . . . . . . . . .
2.2.2 Externe Metadaten . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
12
12
12
12
13
3 Metadatenformate
3.1 Metadaten in der Multimedia . . . . . . . . . . . . . . . . . . . .
3.1.1 MPEG-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Information Interchange Model . . . . . . . . . . . . . . .
3.1.3 VRA Core . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 Exchange Binary Broadcast and Metadata Format . . . . .
3.1.5 ID3-Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.6 Exchangeable Image File Format . . . . . . . . . . . . . .
3.1.7 NISO Metadata for Images in XML . . . . . . . . . . . . .
3.1.8 Extensible Metadata Platform . . . . . . . . . . . . . . . .
3.2 Metadaten im World Wide Web . . . . . . . . . . . . . . . . . . .
3.2.1 Resource Description Framework . . . . . . . . . . . . . .
3.2.2 Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Online Information eXchange . . . . . . . . . . . . . . . .
3.2.4 Open Archives Initiative Protocol for Metadata Harvesting
3.3 Metadaten in (digitalen) Bibliotheken . . . . . . . . . . . . . . . .
3.3.1 Machine-Readable Cataloging . . . . . . . . . . . . . . . .
3.3.2 Metadata Encoding and Transmission Standard . . . . . .
3.3.3 Maschinelles Austauschformat für Bibliotheken . . . . . . .
3.3.4 Metadata Object Description Schema . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
16
17
19
20
21
22
23
25
25
27
28
28
29
29
31
32
33
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
3.3.5
BibTex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4 Metadaten und Dateiformate
4.1 Portable Document Format (.pdf) . . . . . . . . . . . . . . . . . . . . .
4.2 Joint Photographic Experts Group (.jpg, .jpeg) . . . . . . . . . . . . .
4.3 Microsoft Office Standard (.doc, .xls, .ppt) . . . . . . . . . . . . . . . .
4.4 OpenOffice.org (.odt, .ods, .odp) . . . . . . . . . . . . . . . . . . . . . .
4.5 Tagged Image File Format (.tiff) . . . . . . . . . . . . . . . . . . . . . .
4.6 Compuserve Graphics Interchange Format (.gif) und Portable Network
Graphics (.png) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Moving Picture Experts Group (.mpg, .mpeg) . . . . . . . . . . . . . .
4.8 Moving Picture Experts Group 1 Audio Layer 3 (.mp3) . . . . . . . . .
4.9 Hypertext Markup Language (.html, .htm) . . . . . . . . . . . . . . . .
4.10 Komprimiertes ZIP-Archiv (.zip) . . . . . . . . . . . . . . . . . . . . .
36
36
36
37
37
38
5 Metadaten Mapping
41
6 Bewertung
44
Literaturverzeichnis
46
3
38
38
39
39
40
Abbildungsverzeichnis
3.1
3.2
EXIF Metadaten in einer JPEG-Datei . . . . . . . . . . . . . . . . . .
Metadaten mit XMP ausgelesen . . . . . . . . . . . . . . . . . . . . . .
22
25
4.1
Screenshot aus dem Programm ID3-TagIT . . . . . . . . . . . . . . . .
39
4
Tabellenverzeichnis
3.1
Überblick über einige Metadaten des Information Interchange Models .
5
16
Listings
3.1
3.2
3.3
3.4
3.5
3.6
3.7
XML Code des Elements agent des VRA Cores . . . . . . . .
Ausschnitt aus dem MIX-Schema . . . . . . . . . . . . . . . .
Ausschnitt eines MIX XML-Beispiels . . . . . . . . . . . . . .
Ausschnitt eines RDF XML-Beispiels . . . . . . . . . . . . . .
MARC Beispiel für den Personennamen (Autor) . . . . . . . .
Reduziertes MODS Beispiel für die vorliegende Seminararbeit
Beispiel für den BibTex Literaturtyp manual . . . . . . . . .
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
23
23
26
30
34
35
Abkürzungsverzeichnis
CMS
Content Management System
DC
Dublin Core
DCMI
Dublin Core Metadata Initiative
DDL
Description Definition Language
DI
Digital Item
DNB
Deutsche Nationalbibliothek
DRM
Digital Rights Management
DTD
Dokumenttypdefinition
EXIF
Exchangeable Image File Format
GIF
Compuserve Graphics Interchange Format
GNU
General Public Licence
ID3
Identify an MP3
IDE
Integrated Development Environment
IIM
Information Interchange Model
IPTC
International Press Telecommunications Council
JEIDA
Japan Electronics Industry Development Association
JPEG
Joint Photographic Experts Group
LOC
Library of Congress
MAB
Maschinelles Austauschformat für Bibliotheken
MARC
Machine-Readable Cataloging
METS
Metadata Encoding and Transmission Standard
7
Listings
MIX
NISO Metadata for Images in XML
MODS
Metadata Object Description Schema
MOS
Multiple Object Standard
MP3
MPEG-1 Audio Layer 3
MPEG
Moving Picture Experts Group
NAA
Newspaper Association of America
NISO
National Information Standards Organization
OAI
Open Archives Initiative
ONIX
Online Information eXchange
PMH
Protocol for Metadata Harvesting
PNG
Portable Network Graphics
RDF
Resource Description Framework
SDK
Software Development Kit
SOS
Single Object Standard
TIFF
Tagged Image File Format
URI
Uniform Resource Identifier
VRA
Visual Resources Association
W3C
World Wide Web Consortium
XBMF
Exchange Binary Broadcast and Metadata Format
XML
Extensible Markup Language
XMP
Extensible Metadata Platform
8
1 Einleitung
Das Wort Meta stammt aus dem Griechischen und bedeutet frei übersetzt so viel wie
mit, mitten, neben. Metadaten sind demnach Daten über Daten und haben eine beschreibende Funktion. Dass Metadaten ihrerseits auch wieder Daten sind, lässt die
Schlussfolgerung zu, dass Metadaten selbst auch Metadaten besitzen können. Ein Metadatum ist also per se ein Datum. Umgekehrt kommt es aber auf den Standpunkt an.
Das folgende Beispiel verdeutlicht dies: Dem Musikliebhaber geht es primär um die
Musik auf einer CD. Unter der Voraussetzung, dass die CDs nicht nach einem System,
zum Beispiel alphabetisch, im Regal sortiert werden, haben der Name des Interpreten
und der Titel der CD nur einen beschreibenden Charakter. Es handelt sich aus Sicht
des Hörers also um Metadaten. In einem Online Musik-Shop haben diese beiden Eigenschaften einen wesentlich höheren Informationsgehalt, da die Informationen über den
Interpreten und den Titel unabdingbar für ein Warenwirtschaftssystem sind, das mit
Medien dieser Art handelt. In diesem Kontext ist der Inhalt der CD nur zweitrangig.
Das Beispiel verdeutlicht auch, dass das Prinzip, welches hinter den Metadaten steckt,
kein neues ist, auch wenn der Name als solcher relativ jung ist. Schon im Mittelalter
wurde in großen Bibliotheken über den aktuellen Bestand anhand von Katalogen Buch
geführt, um die Masse an Informationen gezielt auffindbar zu machen und sinnvoll
einsetzen zu können. Auch im Alltag trifft man regelmäßig auf Metadaten, oftmals
ohne sich dessen bewusst zu sein. Ein Betriebssystem speichert zu einer Datei immer
auch die Informationen, wann sie zuletzt verändert wurde, welche Zugriffsrechte sie
besitzt und indirekt über die Dateiendung auch das Dateiformat1 . Wer hat noch nicht
ein Telefonbuch in den Händen gehalten oder in einem Branchenheft nach dem nächsten
Klempner gesucht? Auch hierbei handelt es sich um eine Sammlung von Metadaten,
fein säuberlich sortiert nach Branche und Name. Die Fülle an Informationen, die durch
Metadaten darstellbar ist, ist nahezu unerschöpflich. Umso wichtiger ist es, Ordnung
hineinzubringen. Viele Initiativen, Konsortien und Gremien, aber auch Einzelpersonen
haben sich dieses Problem zur Aufgabe gemacht und Parameter und Eigenschaften
bestimmt, um mit einem Satz von Informationen ein Objekt zu beschreiben, es verwaltund wartbar zu machen und es in Beziehungen zu anderen Objekten zu setzen.
Ziel dieser Arbeit ist es, dem Leser einen Überblick über die gängigsten Metadatenformate und Frameworks für Metadaten und deren Anwendungsgebiete zu schaffen.
Hierzu werden im folgenden Kapitel zunächst einige Grundlagen erläutert, um in den
Kapiteln 3, 4 und 5 darauf aufzubauen. Das Kapitel Metadatenformate nennt und beschreibt eine Auswahl von siebzehn Metadatenformaten und erläutert deren aktuellen
Stand. Das Kapitel Metadaten und Dateiformate soll dem Leser verdeutlichen, wie
1
Hierbei ist zu beachten, dass eine Dateiendung durch einen Benutzer verändert werden kann und
sie somit keinen sicheren Rückschluss über das Dateiformat zulässt.
9
1 Einleitung
weit verbreitet Metadatenformate sind, indem einige Dateiformate auf die Möglichkeit
untersucht werden, sie mit Metadaten zu versehen. Das Kapitel Metadaten Mapping
beschäftigt sich mit dem Problem, Metadaten des einen Formats möglichst verlustunbehaftet in ein anderes zu überführen. In der Bewertung wird das Thema Metadaten
von einem kritischen Standpunkt betrachtet und Vor- und Nachteile der verwendeten
Techniken herausgearbeitet. Abschließend erfolgt eine Zusammenfassung.
10
2 Grundlagen
In diesem Kapitel werden einige Grundlagen bezüglich Metadaten geschaffen, um das
Verständnis in den hierauf folgenden Kapiteln zu erhöhen. Zunächst wird auf Typen von
Metadaten und anschließend auf Verfahren zur Speicherung von Metadaten eingegangen. In dieser Arbeit werden primär digitale Objekte1 (DO) und die digitale Verwaltung
von nicht digitalen Objekten2 behandelt. In der Vergangenheit war es üblich, Metadaten in Papierform (Karteikarten, manuelle Katalogisierung, Datensätze) zu speichern.
Da diese Art der Speicherung bedingt durch die fortschreitende Digitalisierung des
Verwaltungswesens und durch die Globalisierung - und dem damit verbundenen höheren Anspruch an Informationsbeschaffung - zunehmend an Bedeutung verliert, wird in
dieser Arbeit nur der Aspekt der digital erfassbaren Metadaten berücksichtigt.
2.1 Typen von Metadaten
Man unterscheidet zwischen beschreibenden, strukturellen und administrativen Metadaten, deren Grenzen jedoch fließend sind. Diese Typen werden in diesem Abschnitt
erläutert.
2.1.1 Beschreibende Metadaten
Beschreibende Metadaten (descriptive metadata) werden dazu verwendet, Quellen und
Objekte zu charakterisieren, zu verwalten und zu identifizieren. Typischerweise bestehen beschreibende Metadaten aus bibliografischen Informationen, wie beispielsweise
dem Autor, dem Titel und dem Datum der Erstellung des DOs. Daneben existieren
aber auch deskriptive Metadaten für den eindeutigen Identifikator, für zusätzliche Informationen und für so genannte Schlagworte, die mitunter sogar etwas über den Inhalt
des DOs aussagen können. Beschreibende Metadaten helfen dabei das digitale Objekt
besser zu verstehen und zu kategorisieren. Viele Suchmaschinen durchsuchen Webressourcen nach ihren Metadaten und beziehen diese in das Suchergebnis mit ein. So zum
Beispiel können HTML-Dokumente <meta>-Felder aufnehmen. Der bekannteste Vertreter der rein beschreibenden Metadaten ist der Dublin Core-Metadatensatz, der in
Abschnitt 3.2.2 erläutert wird.
1
2
Video-, Audio- und Textdateien, Webressourcen, usw.
Bücher, Gemälde, Texte, Tonträger, usw.
11
2 Grundlagen
2.1.2 Strukturelle Metadaten
Mit Hilfe von strukturellen Metadaten (structual metadata) drückt man Beziehungen zwischen Objekten und ihren Komponenten aus und hat so die Möglichkeit Objektmodelle zu erzeugen. Ähnlich der objektorientierten Programmierung können mit
strukturellen Metadaten Hierarchien und Typisierungen aufgebaut und diese dann zum
Beispiel visualisiert werden. Strukturelle Metadaten beschreiben aber auch den strukturellen internen Aufbau eines DOs. So ist es mit ihnen bei komplexen Dokumenten
möglich, durch einzelne Kapitel zu navigieren oder per Shortcut an eine andere Stelle zu
springen. Ein bekannter Vertreter, der strukturelle Metadaten für genau diesen Zweck
einsetzt, ist der so genannte MET-Standard, auf den ab Seite 31 näher eingegangen
wird. Ein METS-Dokument besteht unter anderem aus strukturellen Verknüpfungen,
um den korrekten Aufbau eines Dokuments zu garantieren.
2.1.3 Administrative Metadaten
Je größer die Anzahl der verwalteten Objekte ist, desto kleiner ist der Anteil, den ein
individueller Nutzer versteht. Diesem Problem kann mit administrativen Metadaten
entgegengewirkt werden. Da Metadaten oft in Datenbanken persistiert und verwaltet
werden, findet man auch administrative Metadaten primär in diesem Umfeld. Anfragen
auf digitale Objekte können z.B. die administrativen Metadaten Standort und Signatur
des Objekts liefern und im Kontext eines Bibliothekensystems, an wievielter Stelle eine
Vormerkung platziert werden würde. Wie eingangs erwähnt sind Metadaten ihrerseits
auch wieder Daten, die durch weitere Metadaten beschrieben werden können. Administrative Metadaten können in diesem Zusammenhang auch eine beschreibende (siehe
oben) Funktion haben, indem sie dem Anwender vermitteln, was das beschreibende Metadatum ISBN oder Urheber bedeutet. Auf Basis administrativer Metadaten lassen
sich in Data Warehouse Systemen zudem Nutzungsstatistiken erstellen, indem Zugriffe,
Anzahl der Ausleihen, Reservierungen und Zitierungen usw. erfasst und anschließend
grafisch aufbereitet werden.
2.2 Verfahren zur Speicherung von Metadaten
Metadaten können intern in einem DO3 oder separat in einer eigenen Datei gespeichert
werden.
2.2.1 Interne Metadaten
Interne Metadaten werden in einem speziell für diesen Zweck reservierten Bereich in
der Datei gespeichert. Oftmals befinden sich interne Metadaten im Kopf der Datei
3
Interne Metadaten müssen durch das jeweilige Dateiformat oder durch eine entsprechende Anwendung unterstützt werden.
12
2 Grundlagen
oder am Ende des Dateistroms und werden durch ein bestimmtes Flag gekennzeichnet
bzw. eingeleitet. So wird verhindert, dass Programme Metadaten als Dateiinhalt - zum
Beispiel als Audiosignal - interpretieren und es zu Fehlern kommt. Für das Auslesen
interner Metadaten unterstützen die Programme, die die Datei lesen können, in der
Regel auch die Funktion, die eingepflegten Metadaten zu lesen und zu manipulieren.
So zum Beispiel verfügen alle gängigen Multimedia-Abspieler über die Möglichkeit, die
so genannten ID3-Tags (siehe Abschnitt 3.1.5) aus MP3-Dateien zu lesen und zum Teil
auch zu schreiben. Einfache Texteditoren, wie man sie bei externen Metadaten (siehe
unten) einsetzen kann, erfüllen diese Anforderung jedoch nicht, da die Daten meist
binär vorliegen. Darüber hinaus existieren spezielle interne Metadatenformate, die nur
durch proprietäre Anwendungen überhaupt lesbar sind. Auf diese soll in dieser Arbeit
jedoch nicht eingegangen werden.
2.2.2 Externe Metadaten
Im Gegensatz zu internen Metadaten wird das externe Pendant in einer separaten Datei neben dem zu beschreibenden Objekt gespeichert. Damit die Zusammengehörigkeit
auch dann gewährleistet werden kann, wenn die externe Metadaten-Datei und digitales Objekt physikalisch voneinander getrennt liegen, verfügt die Metadaten-Datei über
einen Identifizierer in Form eines so genannten Uniform Resource Identifier (URI).
Dieser ist eindeutig und referenziert das zu beschreibende Objekt. Einige Ansätze, die
Metadaten extern speichern4 , gehen noch einen Schritt weiter und speichern die beiden
Dateien zusammen in einem gepackten Archiv. Viele Ansätze nutzen als Dateiformat
für die externen Metadaten die durch das World Wide Web Consortium (W3C) entwickelte Markup Sprache XML5 . Der Vorteil von XML liegt auf der Hand: zum einen
ist XML menschenlesbar und damit -verständlich und zum anderen lassen sich XMLDateien mit einem gewöhnlichen Texteditor öffnen und modifizieren.
4
So zum Beispiel das Exchange Binary Broadcast and Metadata Format, welches ab Seite 19, erläutert
wird.
5
In dieser Arbeit werden Grundkenntnisse über XML vorausgesetzt. Sollten diese nicht vorhanden
sein, so bilden [Wor08] und [Wik08] zusammen einen guten Einstieg.
13
3 Metadatenformate
Um Ressourcen und digitale Objekte angemessen zu beschreiben, muss bestimmt werden, welche Informationen Relevanz haben und wie man diese Informationen in einem
Vokabular festlegen kann. Die Wahl des Vokabulars und des Satzes an Informationen hängt stark von der Klassifizierung des zu beschreibenden Objektes ab. So zum
Beispiel könnten bestimmte Zusatzinformationen bei Videodateien von großem Nutzen, bei Büchern oder Webressourcen aber unvollständig und sogar unsinnig sein. Aus
diesem Grund existieren verschiedene Ansätze in Form von Metadatenformaten, um
digitale Objekte - auch des gleichen Typs - zu charakterisieren.
In diesem Abschnitt wird nun eine Auswahl an Metadatenformate vorgestellt, deren
Funktionsweise erläutert und Einsatzgebiete genannt. Zum Zeitpunkt der Erstellung
dieser Arbeit war es ohne großen Aufwand möglich, mehr als dreißig zum Teil exotische
Metadatenformate zu recherchieren. Hier soll deswegen nur eine Auswahl der gängigsten
Formate vorgestellt werden. Zugunsten der Übersicht - und damit der Verständlichkeit
- wird eine Klassifizierung in Metadaten in der Multimedia, im World Wide Web und
in (digitalen) Bibliotheken vorgenommen. Ist eine klare Trennung nicht möglich, wird
explizit darauf hingewiesen.
3.1 Metadaten in der Multimedia
In diesem Abschnitt werden Metadatenformate vorgestellt, die im Bereich der Multimedia Einsatz finden.
3.1.1 MPEG-7
Die Motion Picture Expert Group entwickelte mit MPEG-1, MPEG-2 und MPEG4 Standards, um Multimediadaten kodiert zu repräsentieren und verabschiedete diese durch ISO/IEC. Im Jahre 2002 wurden diese Standards um eine Schnittstelle zur
Objektbeschreibung erweitert, die auch den Beinamen Multimedia Content Description Interface (kurz MPEG-7) trägt. Mit ihr es ist möglich, audiovisuellen Inhalt in
Multimediaumgebungen und -anwendungen zu beschreiben. MPEG-7 kann in diesem
Zusammenhang von den anderen Standards der MPEG dazu verwendet werden, die
Interoperabilität durch zusätzliche Informationen zu vereinfachen und die Flexibilität
des Datenmanagements zu erhöhen [NL99]. Nicht nur bewegte Bilder lassen sich mittels
MPEG-7 beschreiben. Zu den unterstützen Typen gehören auch Bilder, Grafiken, Ton,
14
3 Metadatenformate
3D-Modelle, Sprache und vor allem Informationen darüber, wie diese Elemente miteinander verknüpft sind. So zum Beispiel lassen sich einzelne Objekte in einem MPEG-4kodierten Objekt, welches bewegtes Bildmaterial und Ton beinhaltet, mittels MPEG-7
beschreiben. Unterschieden wird hier zwischen verschiedenen Abstraktionsebenen der
Beschreibung. Auf der untersten Ebene könnten so zum Beispiel Form, Farbe, Größe,
Position (sowohl Ton als auch Bild) und Lautstärke eines Objektes beschrieben werden
und auf der höchsten Abstraktionsebene das Objekt selber als ein sich mit 744 km/h
bewegendes, weißes, in Richtung Südwest fliegendes, düsenbetriebenes Flugzeug, dessen
Triebwerke eine Lautstärke von 120 dB(A) haben. Die Möglichkeit der Abstraktion
hängt natürlich in hohem Maße davon ab, wie gut sich einzelne Objekte, beispielsweise
aus einer Szene, extrahieren lassen.
Der MPEG-7 Standard besteht im wesentlichen aus den folgenden Elementen:
• Deskriptor: Definiert die Syntax und Semantik einer jeden Eigenschaft (Metadatum). Ein Deskriptor hat eine eindeutige Id, einen festen Datentyp und legt
dessen Wertebereich fest. Ein Beispiel hierfür wäre die Brennweite einer Kamera in einer Szene eines Films. Der Deskriptor könnte dann die Id focallength
haben, vom Typ Integer sein und als Wertebereich 10-800 mm haben.
• Deskriptionsschema: Beschreibt die Struktur und die Semantik der Zusammenhänge zwischen Deskriptoren und Deskriptionsschemata in einer Baumstruktur.
Ein Deskriptionsschema wird durch die Description Definition Language (DDL)
ausgedrückt. Bei unserem Beispiel der Filmszene sähe ein Deskriptionsschema
folgendermaßen aus: das Deskriptionsschema scene beinhaltet die Deskriptoren
camera, duration, place und daytime und das Deskriptionsschema actor, welches wiederum die Deskriptoren name, gender und text beinhaltet.
• Description Definition Language: Definiert eine Syntax für Deskriptoren und Deskriptionsschemata und erlaubt es Deskriptionsschemata zu verändert und zu
erweitern. Im Evaluierungsprozess zur Konzipierung der DDL hat sich die Extensible Markup Language (XML) als Beschreibungssprache durchgesetzt.
• Tools: Diese werden dazu verwendet, das Konzept umzusetzen. Sie sollten effizientes Speichern und Übertragen unterstützen. Außerdem die Synchronisierung
von Inhalt und Beschreibung, das Schützen von geistigem Eigentum, usw.
Nach [SS06] unterstützt MPEG-7 rund 450 verschiedene Metadaten, die, wenn es
das Dateiformat unterstützt, intern oder extern gespeichert werden können. Wird die
Schnittstelle nicht intern unterstützt, wird die Zusammengehörigkeit eines digitalen
Objektes zu seinen Metadaten (und umgekehrt) sichergestellt, indem beide über einen
einheitlichen Bezeichner für Ressourcen (URI) miteinander verknüpft werden.
Im Zusammenhang der MPEG soll an dieser Stelle auch kurz auf den Standard MPEG21 eingegangen werden, welcher sich des Konzepts der Metadaten bedient. MPEG-21
ist ein auf offenen Standards basierendes Framework, um multimediale Inhalte zu verwalten und Benutzern zugänglich zu machen. Hierzu werden diese Inhalte, auch Digital
Items (DI) genannt, in einem Prozess, der unter anderem die Produktion, Rechteverwaltung und sogar die Vermarktung umfasst, mit Metadaten versehen und miteinander
15
3 Metadatenformate
verknüpft. Der Standard besteht aus 12 Kernkomponenten, die unter anderem eine
Spezifikation zur Deklaration und Identifikation eines DIs festlegen, ihre Rechteverwaltung definieren und Software bestimmen, die Tools zur Umsetzung der Kernkomponenten bereitstellen. Der Standard ist besonders für Content Provider interessant,
da MPEG-21 als eine Kernkomponente1 eine einheitliche Digital Rights Management
(DRM) Funktionalität unterstützt.
3.1.2 Information Interchange Model
Ausgehend von der Idee digitale Bilddaten, Texte, Ton usw. über ein Netzwerk oder auf
einem lokalen Datenträger effektiv auffindbar zu machen, entwickelte der International
Press Telecommunications Council (IPTC) ab 1990 zusammen mit der Newspaper Association of America (NAA) den einheitlichen Metadatensatz Information Interchange
Model (IIM), der in einem Segment der zu beschreibenden Datei gespeichert wird. Vor
allem Bildagenturen mit großen Bildatenbanken setzen dieses Format ein, da es unter
anderem die Möglichkeit bietet, die Dateien zu taggen, also mit Schlagworten zu versehen. Gewissenhaft eingesetzt sagen diese Schlagworte etwas über den Bildaufbau und
den Inhalt der Szene aus. So ist es möglich Suchanfragen zu starten, die über klassische Metadaten, wie Autor und Titel, hinausgehen und eine inhaltsbezogene Suche
erlauben.
In der folgenden Tabelle werden einige Felder des Datensatzes genannt und deren Funktion erläutert.
Bezeichnung
Headline
Keywords
Copyright
City
Originating Program
Writer/ Editor
Beschreibung
Titel des digitalen Objekts, z.B. Name des Motivs eines
Bildes.
Schlagworte, die den Inhalt des Objekts beschreiben, z.B.
Auto, Berg, Straße, usw.
Rechte, die das digitale Objekt betreffen.
Erstellungsort (Stadt)
Software, mit der das digitale Objekt erstellt/bearbeitet
wurde.
Autor der IPTC-Daten.
Tabelle 3.1: Überblick über einige Metadaten des Information Interchange Models
In der aktuellen Version umfasst das IIM rund 75 Felder. Die vollständige Liste kann
der technischen Spezifikation [Int99b] entnommen werden.
Das IIM wurde weitestgehend von Adobes XMP (siehe Abschnitt 3.1.8) verdrängt,
obwohl der Datensatz der IIM die Basis von XMP darstellt. Da die Adobe Produktreihe den Standard der IPTC-NAA offiziell weder unterstützt noch aus digitalen Daten
ausliest, ist es nur noch eine Frage der Zeit, bis das IIM vollständig verdrängt wird.
Auch wird das IIM zum großen Teil durch das Metadatenformat EXIF (siehe Abschnitt
1
MPEG-21 Teil 4, 5 und 6. Siehe hierzu auch [Org02].
16
3 Metadatenformate
3.1.6) abgedeckt, welches zumindest im Bereich der Bilddaten eine höhere Akzeptanz
genießt2 .
3.1.3 VRA Core
Das Data Standards Committee der Visual Resources Association (VRA) entwarf mit
dem VRA Core im Jahre 1997 einen Satz aus Kernelementen, um ein Datenmodell für
die folgenden drei Klassifizierungen zu entwerfen und somit Informationen über das
Kulturerbe zu wahren.
• Werk (Work): Ein Werk stellt im vorliegenden Zusammenhang eine kulturelle Entität dar. Beispiele hierfür sind Skulpturen, Gemälde, Fotografien, Manuskripte
oder auch eine Aufführung.
• Bilder (Images): Bilder sind als visuelle Repräsentationen der oben genannten
Werke zu verstehen. Hierzu gehören Dias, fotografische Abzüge und digitale Bilder.
• Sammlungen (Collections): Eine Sammlung aus Werken und/oder Bildern, die
konzeptuell oder physikalisch arrangiert wurden. Hierzu gehören unter anderem
Ausstellungen, Sammlungen von gleichen Objekten, die aus verschiedenen Materialien bestehen, oder die Fotoserie eines Shootings.
XML hat, wie Metadaten auch, eine beschreibende Funktion und wird deswegen im
VRA Core eingesetzt. Die Metadaten sind in einer drei-schichtigen Hierarchie sortiert.
Auf oberster Ebene stehen die Elemente, gefolgt von den Unterelementen und zuletzt
die Attribute. Das entspricht exakt der Syntax, die auch XML verwendet. Der VRA
Core beinhaltet die folgenden Felder3 :
• work, collection, or image (id)
• agent
– attribution
– culture
– dates (type)
∗ earliestDate (circa)
∗ latestDate (circa)
– name (type)
– role
• culturalContext
• date (type)
2
3
Gemessen an der Quantität der Anwendungen, die die besagten Metadatenformate unterstützen.
Elemente sind rot dargestellt, Unterelemente grün und Attribute blau.
17
3 Metadatenformate
– earliestDate (circa)
– latestDate (circa)
• description
• inscription
– author
– position
– text (type)
• location (type)
– name (type)
– refid (type)
• material (type)
• measurements (type, unit)
• relation (type, relids)
• rights (type)
– rightsHolder
– text
• source
– name (type)
– refid (type)
• stateEdition (count, num, type)
– description
– name
• stylePeriod
• subject
– term (type)
• technique
• textref
– name (type)
– refid (type)
• title (type)
• worktype
18
3 Metadatenformate
Darüber hinaus beinhaltet der Kern der VRA neun globale Attribute (Datum der
Aufnahme, Hypertext Links, eindeutiger Bezeichner, usw.), die bei allen Elementen und
Unterelementen angewendet werden können. Listing 3.1 zeigt einen XML-Ausschnitt,
der das Element agent vollständig beinhaltet:
Listing 3.1: XML Code des Elements agent des VRA Cores
1
2
3
4
5
6
7
8
9
10
11
12
<agentSet>
<display>Claude Monet (1840-1926), französischer Maler</display>
<agent>
<culture>Französisch</culture>
<dates type="life">
<earliestDate circa="true">1840</earliestDate>
<latestDate circa="true">1926</latestDate>
</dates>
<name type="personal">Claude Monet</name>
<role>Maler</role>
</agent>
</agentSet>
Das METS Editorial Board hat die offizielle Unterstützung des VRA Cores durch
METS bekanntgegeben. Das bedeutet, dass sich der VRA Core aufgrund seiner Darstellung in XML mittels METS (siehe Abschnitt 3.3.2 und [Dig08a]) in andere Objekte
einer Bibliothek integrieren lässt.
3.1.4 Exchange Binary Broadcast and Metadata Format
Das Exchange Binary Broadcast and Metadata Format (XBMF) ist ein auf Dublin Core
(siehe Abschnitt 3.2.2), SOMA 0.54 und EBU Tech 32735 basierendes Metadatenformat,
welches sich von anderen Austauschformaten dadurch unterscheidet, dass es explizit für
das Broadcasting von Multimediainhalten konzipiert wurde.
Die Entwickler vertreten den Standpunkt, dass schon der Dublin Core hinreichend
viele Metadaten liefert, um auch in komplexeren Anwendungsgebieten zu funktionieren. XBMF deckt daher genau diesen Kern ab. Die Metadaten zu den multimedialen
Objekten6 werden im XML-Format hinterlegt. Hierzu werden die durch die Metadaten beschriebenen Objekte nach der folgenden vordefinierten Verzeichnisstruktur im
Dateisystem abgelegt:
4
SOMA steht für Shared Online Media Archive und ist ein unter der General Public Licence (GPL)
stehendes Metadatenformat für den Austausch von Multimediadaten. Es baut auf Dublin Core
und EBU Tech 3273 auf und wird zur Zeit zusammen mit eZ publish, einem Content Management
System (CMS), in OneWorldTV ([One08]) eingesetzt. Für weitere Informationen, siehe [SOM02].
5
EBU Tech 3273 ist eine Methodensammlung zur Messung der farbmetrischen Güte professioneller
Studiomonitore ([Eur93]).
6
In erster Linie werden Audiodateien, aber auch Videos, ganze Websites und eLearning-Objekte
unterstützt.
19
3 Metadatenformate
XBMF
metadata.xml
audio
audiodatei01
audiodatei02
...
dateien
pdf
video
text
...
Das Symbol auf der höchsten Hierarchieebene lässt bereits vermuten, dass der so entstandene Container anschließend archiviert und dabei komprimiert wird. Das geschieht
entweder mit dem Tool tar oder gzip. Das hat zum einen den Vorteil, dass sich die Datenmenge bei der Übertragung reduziert, zum anderen muss lediglich eine einzelne
Datei versendet werden. Auch der Verbreitungsgrad der Kompressionswerkzeuge und
deren Integrierbarkeit in andere Programme spricht für dieses Vorgehen. Ein ausführliches Beispiel für eine XBMF XML-Datei findet sich in [DSD03].
3.1.5 ID3-Tags
ID37 ist ein Metadatenformat speziell für MP3 Dateien und steht für Identify an MP3.
Es handelt sich um ein internes Metadatenformat, jedoch wurde es nie offiziell in den
Standard MPEG-1 Audio Layer 3 (MP3) aufgenommen. Die ursprüngliche Idee bestand darin, die Metadaten an das Ende des Datenstroms zu setzen, da der besagte
Standard der MPEG eine eindeutige Endmarkierung nach den Audiosignalen vorsieht.
Eine Fehlinterpretation durch einen Software-Abspieler wird so verhindert, denn nur
die Informationen nach der Endmarkierung werden als Metadaten verstanden und ausgelesen. Die erste Version wurde 1996 von Eric Kemp eingeführt und trug die Bezeichnung ID3v1. Insgesamt besitzt diese Version der Etikette 8 sieben Metadaten (TAGKennung, Songtitel, Interpret, Albumtitel, Erscheinungsjahr, Kommentar, Genre), wobei die TAG-Kennung nur dazu dient den Beginn des Metadatensatzes zu markieren.
Jedes Metadatum hat eine vordefinierte Größe und insgesamt ist der Datenblock auf
7
Der Name ID3 sollte nicht mit dem Entscheidungsalgorithmus des australischen Forschers J. Ross
Quinlan verwechselt werden.
8
Ein Tag ist im Deutschen ein Etikett, Anhängeschildchen, eine Marke. Entsprechend bezeichnet man
das Versehen von MP3-Dateien mit ID3 Informationen als tagging, also etikettieren, markieren.
20
3 Metadatenformate
128 Byte beschränkt. Das Metadatum Genre wird nicht als zusammenhängende Zeichenkette gespeichert, sondern als eine 1 Byte große Zahl kodiert, um Platz zu sparen.
Jede Zahl entspricht hierbei einem von 125 Genres. Die vollständige Liste ist dem
Anhang des informellen Standards der Version 2.3 [Nil99] zu entnehmen.
Aufgrund der geringen Anzahl an Metadaten, der Beschränkung einzelner Felder auf
maximal 30 Zeichen und fehlender Information über die Zeichenkodierung9 wurde 1998
die Version ID3v2 ([Nil98]) eingeführt und im Jahre 2000 Version ID3v2.4 ([Nil00a] und
[Nil00b]), wobei noch heute dessen Vorgängerversion ID3v2.3 am weitesten verbreitet
ist. Mit dem Sprung auf Version v2 wurde der Datenblock mit den Metadaten an
den Anfang der Datei verschoben und fortan mit der Markierung ID3 identifiziert. Es
fanden insgesamt über 70 Metadaten Einzug in den aktuellen Standard, die sich mit
der entsprechenden Software modifizieren lassen. Ein Großteil der heute verfügbaren
Mediaplayer (Winamp, iTunes, Mediamonkey, usw.) unterstützen ID3. Es existieren
aber auch Programme, die speziell für das Hinzufügen, Erweitern und Ändern (vor
allem Stapelverarbeitungen) von ID3-Tags entwickelt wurden. Sie unterstützen zum
Teil sogar das Hinzufügen von Bildmaterial, wie etwa das Plattencover oder Fotos des
Interpreten.
3.1.6 Exchangeable Image File Format
Das Exchangeable Image File Format (EXIF) wurde von der Japan Electronics Industry Development Association (JEIDA) zum automatischen Speichern von Metadaten
durch Digitalkameras konzipiert. Der Standard sieht neben digitalen Bilddateien auch
das taggen von Audiosignalen vor. Diese Arbeit legt den Schwerpunkt aber auf den ersten Teil der Spezifikation, die Exif Image File Specification. Die erste Version wurde
1995 vorgestellt, eine Reihe von Erweiterungen folgten10 , bis im April 2002 die bis heute aktuelle Version 2.2 veröffentlicht wurde. Die Metadaten umfassen einen Satz von
Informationen und definieren eine Syntax, die primär fototechnische Aspekte abdecken.
Grob lassen sich diese den folgenden Kategorien zuordnen:
• Datei: Name, Kommentar, usw.
• Kamera: Hersteller, Modell, Firmwareversion, horizontale und vertikale Auflösung, Auslösungszähler, usw.
• Bild: Beschreibung, Künstler, Copyright, Belichtungszeit, Blende, eingestelltes
Programm, ISO-Wert, Datum, Uhrzeit, Brennweite des Objektivs, Farbraum,
Blitz (ausgelöst?), Pixel in x- und y-Richtung, Messung des Weißabgleichs, usw.
• Kamera und Bild: Makromodus, Einzelauslösung oder Serienaufnahme, Bildgröße, Stärke der Komprimierung (wenn nicht im RAW-Format fotografiert), Kontrast, Sättigung, Schärfe, selektierter Autofokuspunkt, GPS-Koordinaten, usw.
9
Das führte dazu, dass Zeichensätze falsch interpretiert und Umlaute mitunter nicht korrekt dargestellt wurden.
10
Zum Beispiel das Hinzufügen des sRGB Farbraums, komprimierter Kleinansichten und eben Audiodateien.
21
3 Metadatenformate
• Sonstiges: EXIF-Version, usw.
Diese Liste ist nicht vollständig, zeigt aber einen wesentlichen Teil der Menge an verfügbaren Feldern11 . Abbildung 3.1 zeigt ein selbst erstelltes Foto (links) und einen
Teil der dazugehörigen Metadaten (rechts). Zum großen Teil wurden diese automatisch durch die Kamera gespeichert, Dateiname und Autor wurden jedoch nachträglich
hinzugefügt.
Abbildung 3.1: EXIF Metadaten in einer JPEG-Datei
Diese zusätzlichen Informationen alleine lassen es nur bedingt zu, Aussagen über den
Bildinhalt zu treffen. Der Photograph erinnert sich möglicherweise anhand des Datums
und der Uhrzeit der Aufnahme, was er fotografiert hat. Schwieriger wird es jedoch, wenn
der Prozess der Erkennung automatisiert stattfinden soll. Daher lassen sich semantische
Informationen, beispielsweise über den Inhalt des Bildes, in freien Kommentarfeldern
eintragen oder als Stichworte speichern. Einen Versuch, eine Klassifikation anhand eines
Bayes’schen Klassifizierers mithilfe der gespeicherten Metadaten durchzuführen, wagt
der Artikel [BL04], der 2004 auf der 17. internationalen Konferenz der Mustererkennung
vorgelegt wurde. Dieser Ansatz geht über das klassische taggen hinaus und versucht
anhand Auslösungszeit, Blendenzahl, ISO-Wert, usw. Rückschlüsse auf das fotografierte
Motiv zu ziehen.
3.1.7 NISO Metadata for Images in XML
Metadata for Images in XML (MIX) ist ein XML-Schema, welches Entwickler implementieren können, um digitale Bildersammlungen zu verwalten. Es stellt, wie die bereits
vorgestellten Metadatenformate auch, einen Satz technischer beschreibender Daten zur
Verfügung. Das Schema baut auf dem Standard Z39.87 der National Information Standards Organization (NISO, siehe [Nat06]) auf und setzt die darin definierten Metadaten
11
Die vollständige Spezifikation, einschließlich aller Metadatenfelder, kann unter [Tec02] eingesehen
werden.
22
3 Metadatenformate
für den Austausch und das persistente Speichern von digitalem Bildmaterial um. Entwickelt wird es vom Network Development and MARC Standards Office der Library of
Congress und liegt zur Zeit in der Version 2.0 vom 12. Mai 2008 vor ([Cun08]). Listing
3.2 zeigt einen kleinen Ausschnitt aus dem XML-Schema von MIX. Das nachfolgende
Beispiel in Listing 3.3 zeigt den entsprechenden XML-Code. Das Beispiel wurde der
offiziellen Webseite [Con08] entnommen.
Listing 3.2: Ausschnitt aus dem MIX-Schema
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<xsd:complexType name="BasicImageInformationType">
<xsd:sequence>
<xsd:element name="BasicImageCharacteristics" minOccurs="0" maxOccurs="1">
...
<xsd:complexType>
<xsd:sequence>
<xsd:element name="imageWidth" type="positiveIntegerType" minOccurs="0" maxOccurs
="1">
...
</xsd:element>
<xsd:element name="imageHeight" type="positiveIntegerType" minOccurs="0"
maxOccurs="1">
...
</xsd:element>
...
</xsd:sequence>
</xsd:complexType>
</xsd:element>
...
</xsd:sequence>
</xsd:complexType>
Listing 3.3: Ausschnitt eines MIX XML-Beispiels
1
2
3
4
5
6
7
8
<BasicImageInformationType>
<BasicImageCharacteristics>
<imageWidth>400</imageWidth>
<imageHeight>200</imageHeight>
...
</BasicImageCharacteristics>
...
</BasicImageInformationType>
3.1.8 Extensible Metadata Platform
Die Extensible Metadata Platform (XMP) ist kein Metadatenformat. Es handelt sich
vielmehr um ein Framework, um Metadaten in Binärdateien einzubetten, ohne jedoch
die Lesbarkeit der Daten durch andere Programme, die die XMP nicht unterstützen, zu
gefährden. Adobe entwickelte und veröffentlichte die XMP im Jahre 2001, heute steht
es unter der BSD Lizenz. Zudem hat Adobe ein Software Development Kit (SDK) frei
zur Verfügung gestellt, um Entwicklern die Möglichkeit zu geben, die XMP in eigene
23
3 Metadatenformate
Anwendungen zu integrieren. Es beinhaltet auch Java Quelldateien und die entsprechende API, um Java Programme mit XMP-Unterstützung in Eclipse12 zu entwickeln.
Die XMP liefert die folgenden drei XMP-Kernkomponenten:
• Datenmodell: Das Datenmodell beschreibt theoretisch, wie Metadaten gespeichert werden sollen. Zur Verfügung stehen drei Datenstrukturen. Einfache Typen beschreiben ein digitales Objekt durch beliebig viele Attribut-Wert Tupel.
Eine CD hat das Attribut Komponist und z.B. den Wert Ludwig van Beethoven
(artist="Ludwig van Beethoven"). Strukturen führen eine Sammlung von AttributWert Tupeln ein. Ein Song einer CD kann z.B. durch die Struktur ({artist="xyz"},
{title="abc"}, {duration="00:11:12"}) beschrieben werden. Eine solche Struktur
kann selbst wieder Strukturen oder die folgende Datenstruktur enthalten. Ein
Array hat ähnlich der Datenstruktur in Programmiersprachen einen Namen und
eine Menge von Elementen. Möchte man eine CD mit beliebigen Schlagwörtern
beschreiben, so werden diese in einem Array gespeichert, z.B. cdtags="Ludwig van
Beethoven", "Greatest Song", "Piano". Array-Elemente können Strukturen oder
wieder Arrays sein.
• Speichermodell: Das Speichermodell spezifiziert, wie das Datenmodell implementiert ist. XMP-Eigenschaften werden in einer XML-Struktur gespeichert, wobei
hierfür auf das Resource Description Framework (siehe 3.2.1) zurückgegriffen
wird. Die XMP bietet die Möglichkeit, Metadaten intern oder extern zu speichern. Für die detaillierten technischen Informationen sei an dieser Stelle auf die
Spezifikation [Ado05] verwiesen.
• Schemata: Die XMP bietet dem Anwender die Möglichkeit aus einem Fundus
von Metadatensätzen (Schemata) ein passendes auszuwählen und so zumindest
ein Grundgerüst für das zu beschreibende Objekt zu erhalten. Zur Auswahl stehen
unter anderem der Dublin Core (siehe Seite 27), ein Basisschema von XMP, ein
Schema für die digitale Rechteverwaltung und ein EXIF-Schema.
Abbildung 3.2 zeigt einen Screenshot, der die Metadaten der Spezifikation der XMP
zeigt. Interessant ist vor allem der Zusammenhang zwischen den einzelnen Feldern (z.B.
Titel) verschiedener Metadatenformate (Dublin Core und XMP Core). Dieser Aspekt
wird in Kapitel 5 diskutiert.
12
Eclipse, aktuell in der Version 3.3 verfügbar, ist eine auf Plug-Ins basierende integrierte Entwicklungsumgebung (IDE). Eclipse ist als Open-Source-Software und somit kostenlos erhältlich.
24
3 Metadatenformate
Abbildung 3.2: Metadaten mit XMP ausgelesen
Die XMP unterstützt die Einbettung von Metadaten in eine Vielzahl von Dateiformaten. Hierzu zählen unter anderem TIFF, JPEG, JPEG 2000, GIF, PNG, HTML und
PDF.
3.2 Metadaten im World Wide Web
Nachdem im vorangegangenen Teil Metadatenformate vorgestellt wurden, die sich primär im Bereich der Multimedia positioniert haben, wird im nun folgenden Teil auf
Ansätze eingegangen, die sich mit der Beschreibung von digitalen Objekten und Ressourcen im World Wide Web beschäftigen.
3.2.1 Resource Description Framework
Die Grundidee, die hinter dem Resource Description Framework (RDF) steckt, ist die,
Webressourcen mit zusätzlichen Informationen zu versehen, die dem Betrachter sonst
verborgen blieben. Mit den beigefügten Metadaten sollen Inhalte des WWW maschinell
25
3 Metadatenformate
interpretierbar und zusammen mit dem RDF-Schema13 Zusammenhänge automatisch
erkennbar werden. Es soll außerdem dazu beisteuern, die Kompatibilität zwischen Anwendungen zu gewährleisten, die sich diese maschinenlesbaren Informationen teilen
oder gemeinsam über das WWW darauf zugreifen.
Das RDF ist eine Empfehlung des W3Cs, die das RDF-Modell und deren Syntax 1999
vorstellte. Das RDF-Modell besteht im Wesentlichen aus dem Tripel Ressource (auch
Subjekt genannt), Eigenschaft (oder auch Prädikat) und Objekt (Wert). Eine Ressource ist das Subjekt, welches beschrieben werden soll. Vorstellbar im Kontext des
WWW sind Websites, streambare Videos oder auch elektronische Bücher. Eine Ressource ist definiert durch ihre Eigenschaften. Eine Webseite hat zum Beispiel einen
Urheber und einen Titel, streambare Videos zudem vielleicht einen Vermerk über das
Urheberrecht und eBooks neben dem Titel auch einen Abstract oder eine Angabe über
die Anzahl der Seiten. Diese Eigenschaften haben einen konkreten Wert, der durch
das Objekt repräsentiert wird. Die Webseite könnte den Autor W3C und den Titel
RDF/XML Syntax Specification (Revised) haben, der Vermerk über das Urheberrecht
jegliche Verbreitung verbieten und die Seitenanzahl 615 betragen. Das RDF ist grundsätzlich nicht an eine Darstellungsform gebunden. Das W3C empfiehlt im Vorschlag
[Bec04] aber die Nutzung von XML, welches sich letztendlich auch durchgesetzt hat14 .
Das folgende nach [Bec04] erzeugte Beispiel zeigt einen XML-Ausschnitt, der den Autor
sowie den Titel dieser Seminararbeit beinhaltet.
Listing 3.4: Ausschnitt eines RDF XML-Beispiels
1
2
3
4
5
6
7
8
<rdf:Description rdf:about="www.inf.fh-brs.de">
<ex:editor>
<rdf:Description>
<ex:fullName>Kai Wiemer</ex:fullName>
</rdf:Description>
</ex:editor>
<dc:title>Metadatenformate</dc:title>
</rdf:Description>
Dem Code-Listing ist zu entnehmen, dass das RDF selbst keine Vorgaben für Metadaten liefert. Vielmehr hat der Anwender die Möglichkeit auf Vorschläge (hier Dublin
Core, siehe Abschnitt 3.2.2) anderer Initiativen zurückzugreifen. Das macht diesen Ansatz zwar flexibel, aber bedingt durch das Tripel aus Subjekt, Prädikat, Objekt nicht
mächtig genug, um komplexe Inhalte, wie Klassendefinitionen und Hierarchien zu definieren bzw. automatisch erzeugen zu lassen. Im Jahre 2000 folgte deswegen durch das
W3C der Vorschlag des RDF-Schemas ([BG00]). Ähnlich einer Dokumenttypdefinition (DTD) werden hier durch Klassen und Eigenschaften einfache Ontologien erzeugt.
An dieser Stelle sei auf den genannten Vorschlag des W3C verwiesen. Eine nähere
Erläuterung würde den Rahmen dieser Arbeit sprengen.
13
Das RDF-Schema kann als Erweiterung für das RDF gesehen werden. Das RDF alleine ist nicht
in der Lage komplexe Zusammenhänge, wie etwa Relationen zwischen den Eigenschaften einer
Ressource und anderen Ressourcen darzustellen. Diese Funktionalität steht erst mit dem RDFSchema zur Verfügung.
14
Eine weitere, nicht so verbreitete Methode ist es, die drei Kernkomponenten in einem Graphen
darzustellen. Ressourcen werden als Ellipsen, Eigenschaften als Kanten und deren Werte als runde
Knoten dargestellt. Beispiele hierfür können [Bec04] entnommen werden.
26
3 Metadatenformate
3.2.2 Dublin Core
Der Dublin Core (DC) ist ein standardisierter Satz von Kernelementen, der als Metadaten in Dokumente, Mediadateien oder andere Objekte im Internet eingebettet werden
kann. Hierbei hängt es vom Dokumenten- bzw. Dateityp ab, ob die Metadaten intern
oder extern gespeichert werden. Der DC wurde von der Dublin Core Metadata Initiative (DCMI) im März 1995 in Dublin, Ohio im Rahmen einer Konferenz mit dem
Ziel definiert, Ressourcen im Web einheitlich zu beschreiben, zu kategorisieren und
aufzufinden. Das Dublin Core Metadata Element Set (kurz Dublin Core) liegt aktuell
in der Version 1.1 ([Dub08]) vor und beinhaltet das Vokabular von 15 Eigenschaften
(siehe unten). Der Name Dublin Core setzt sich aus dem Gründungsort der DCMI und
dem Zusatz Core, im Deutschen Kern, zusammen. Die Begrifflichkeit wurde gewählt,
weil sich die DCMI sicher ist, dass die 15 Elemente ein weitreichendes und generisches
Mittel darstellen, um Ressourcen adäquat zu beschreiben und zu lokalisieren.
Der DC ist nur eine Untermenge der so genannten DCMI Metadata Terms, die alle Begrifflichkeiten der durch die DCMI gepflegten Metadaten beinhalten. Hierzu gehören Eigenschaften (z.B. Zielgruppe, Verfügbarkeit, usw.), Kodierungsschemata
für das notwendige Vokabular (z.B. Ländercode, Zahlendarstellung, usw.), Kodierungsschemata für die Syntax (vor allem ISO Normen, z.B. ISO 639-3 zur
Darstellung von Sprachen in Form von 3-stelligen Zeichenketten) und Klassen (z.B.
Dateiformat von Mediadateien im Internet, Anzahl der Zugriffe auf ein bestimmtes Objekt, usw.). Dieser erweiterte Satz von Elementen gibt Anwendern die Möglichkeit ein
Objekt genauer bzw. umfassender zu beschreiben als dies mit dem DC alleine möglich
wäre.
Der Dublin Core umfasst die folgenden 15 Elemente15 :
1. contributor (Mitwirkende/Mitwirkender)
2. coverage (Geltungsbereich, z.B. räumliches oder zeitliches Thema)
3. creator (Urheberin/Urheber)
4. date (Zeitangabe)
5. description (Beschreibung)
6. format (Format, z.B. Dateiformat)
7. identifier (Identifikator, eindeutige Referenz)
8. language (Sprache)
9. publisher (Verlegerin/Verleger)
10. relation (Beziehung, z.B. zu anderen Ressourcen)
11. rights (Rechte)
12. source (Quelle)
15
Diese Aufzählung ist alphabetisch sortiert, gibt also nicht an, in welcher Reihenfolge die Elemente
bei einem Objekt angegeben werden. Die DCMI schreibt keine solche Reihenfolge vor.
27
3 Metadatenformate
13. subject (Thema)
14. title (Titel)
15. type (Typ, z.B. Art oder Gattung)
Der Dublin Core ist ein anerkannter und weit verbreiteter Standard. Es handelt sich
um eine der ersten Entwicklungen im Bereich der Metadaten im Umfeld des WWW und
er wird heute unter anderem in der XMP (siehe Abschnitt 3.1.8) und im RDF (siehe
Abschnitt 3.2.1) eingesetzt. Es ist jedoch leicht ersichtlich, dass der DC aufgrund wachsender Informationsbedürfnisse, steigender Anzahl an Dateiformaten und komplexerer
Zusammenhänge zwischen Webressourcen auf lange Sicht nur unzureichende Möglichkeiten bieten kann, digitale Objekte exakt zu beschreiben und so effektiv auffindbar zu
machen. Daher ist es empfehlenswert, bei fehlenden Feldern auch die DCMI Metadata
Terms mit einzubeziehen.
3.2.3 Online Information eXchange
Das Metadatenformat Online Information eXchange (ONIX) wurde von der Book Industry Study Group entwickelt und liegt zur Zeit in der Version 2.1 vom Juli 2004
vor. ONIX dient dem Austausch von Informationen über das WWW, wurde speziell
auf die Bedürfnisse von Verlegern abgestimmt und wird daher auch ONIX for Books
genannt.
Ein Problem, das bis heute nicht vollständig gelöst werden konnte, ist der Medienbruch,
der mit der Logistik des Buchhandels einhergeht. Ein Beispiel verdeutlicht diesen Sachverhalt: Ein Großteil der Rechnungen im Buchhandel wird zwar computergesteuert erzeugt, dann aber ausgedruckt und auf klassischem Weg per Briefpost an den Kunden
geschickt, nur um im Anschluss auf Seiten des Rechnungsempfängers von Hand wieder
digitalisiert zu werden. ONIX soll diesen zeit- und kostenintensiven Umweg verhindern,
indem es für den Buchhandel relevante Daten einheitlich speichert, digital verfügbar
und zentral zugänglich macht.
Die ONIX-Metadaten werden im XML-Format gespeichert und sind in einer DTD
mit mehr als 400 Elementen definiert. Zu diesen Elementen zählen neben dem Titel
und dem Autor unter anderem auch die ISBN- und EAN13-Nummer, die Anzahl der
verkauften Exemplare und der Preis. Die Dokumente der Spezifikation können unter
[Boo06] eingesehen werden.
3.2.4 Open Archives Initiative Protocol for Metadata
Harvesting
Aufgrund der Vision, Zugang zu noch nicht in Druck gegangener Forschungsergebnisse
und anderer Publikationen zu schaffen und der Verdrossenheit einiger Wissenschaftler
28
3 Metadatenformate
und Autoren gegenüber ihren Verlegern16 , wurde im Jahre 1999 die Open Archives
Initiative gegründet. Ziel war es, ein Protokoll zu entwickeln, das auf der Basis so
genannter Preprint Dokumenten-Server aufbaut. Diese Server sollten zum einen die
zentrale Ablage aktueller wissenschaftlicher Veröffentlichungen erlauben und, was noch
viel wichtiger war, das effektive Recherchieren nach diesen Dokumenten erlauben. Nach
etwa einjähriger Entwicklung wurde im Jahre 2001 die erste (offizielle) Version des OAI
Protocol for Metadata Harvesting (PMH) vorgestellt, das genau diese Idee umsetzt.
Beim PMH handelt es sich also nicht um Vorgaben über einen Satz von Metadaten,
sondern um ein Protokoll, das webbasiert einen einheitlichen Zugang zu mit Metadaten
versehenen Dokumenten schafft.
Voraussetzung hierfür ist es, dass die Diensteanbieter ihre Dokumente so mit Metadaten aufbereiten, dass sie vom PMH erfasst werden können. Die Beschreibung der
digitalen Dokumente erfolgt im XML-Format und muss der Definition eines durch die
OAI erzeugten XML-Schemas genügen. Hierzu zählen der header, der unter anderem
einen einheitlichen Bezeichner, sowie das Datum der Erzeugung oder der letzten Änderung enthält, das Element metadata, das die Metadaten17 enthält und das Element
about, das die Erfassung zusätzlicher Informationen über die Metadaten erlaubt. Das
Protokoll ist nicht an ein bestimmtes Metadatenformat gebunden. Es erlaubt unterschiedliche Formate, verlangt jedoch, dass ein Metadatum mit einem Präfix entsprechend gekennzeichnet wird.
Ein Beispiel für eine erfolgreiche Implementierung ist die Suchmaschine OAIster ([Dig08b]),
die heute als die wichtigste Suchmaschine für öffentliche Inhalte gilt. Zum Zeitpunkt
der Erstellung dieser Arbeit, umfasste die Datenbank Einträge zu mehr als 16 Millionen
Dokumenten von mehr als 950 Institutionen.
3.3 Metadaten in (digitalen) Bibliotheken
Im letzten Teil des Kapitels werden Metadatenformate vorgestellt, die im Bereich der
Verwaltung von (digitalen) Bibliotheken eingesetzt werden.
3.3.1 Machine-Readable Cataloging
Machine-Readable Cataloging (MARC) ist kein einzelnes Metadatenformat, sondern
eine Sammlung von Standards, um zum Beispiel bibliographische Informationen in
16
Steigende Preise für Abonnements wissenschaftlicher Fachzeitschriften und der damit verbundene
Absatzrückgang, sowie größere zeitliche Abstände zwischen Einreichung und Veröffentlichung eines
Artikels und nicht zuletzt die rechtliche Abhängigkeit der Autoren von Verlagen, führte in der
Vergangenheit zu steigender Unzufriedenheit der Autoren und Forscher.
17
Laut der Spezifikation [LS02] der OAI muss dieser Metadatensatz mindestens die Felder des Dublin
Cores beinhalten.
29
3 Metadatenformate
maschinenlesbarer Form darzustellen und zu kommunizieren18 . Die Entwicklung von
MARC durch die Library of Congress (LOC), der weltweit zweitgrößten Bibliothek,
begann parallel mit den ersten Schritten computergesteuerter Erfassungssysteme in
den siebziger Jahren. Die Idee war, einen einheitlichen maschinenlesbaren Satz von
Informationen über bibliothekarische Inhalte (Bücher, Schriften, Fotografien, Karten,
usw.) bereitzustellen und damit die veralteten und schwer wartbaren KarteikartenKataloge zu ersetzen.
Ein MARC Datensatz besteht aus mehreren Feldern, die ihrerseits wieder aus Unterfeldern bestehen können. Es existieren Felder für den Autor, den Titel, für die Zugehörigkeit zu einem Satz usw. Diese Felder werden nicht textuell gespeichert, sondern kodiert
als dreistellige Zahl (Tag). Das hat den Vorteil, dass sie weniger Platz in Anspruch
nehmen und dass rechnergestützte Anwendungen effektiver auf einzelne Felder zugreifen können. Der Name (Autor) eines Feldes (Tag: 100) kann dann, wenn die Metadaten
zum Beispiel in einer Anwendung menschenlesbar visualisiert werden sollen, über ein
Mapping bezogen werden. Viel verwendete Tags sind 010 (LOC-Kontroll-Nummer),
020 (ISBN-Nummer), 100 (Autor), 245 (Titel) und 250 (Edition). Die komplette und
sehr umfangreiche Liste kann unter [Lib07] eingesehen werden.
Folgendes Beispiel zeigt zunächst die Spezifikation und dann ein Beispiel für den
MARC-Eintrag Personenname:
Listing 3.5: MARC Beispiel für den Personennamen (Autor)
1
Spezifikation
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
100 Haupteintrag -- Personenname -- (Primärer Autor)
Indikator 1: Art des Eintrags
0 -- Vorname
1 -- Nachname
3 -- Familienname
Indikator 2: undefiniert
Wurde 1990 obsolet. Ältere Einträge
können 0 oder 1 anzeigen.
Unterfelder:
$a -- Personenname
$b -- Nummerierung
$c -- Titel, die mit dem Namen im Zusammenhang stehen
$q -- Ausgeschriebene Version des Namens
$d -- Datum, der mit dem Namen im Zusammenhang steht,
meist Geburtstag
18
19
Beispiel
20
21
22
23
100 1# $a Goethe, Johann W.
$q (Johann Wolfgang)
$d 1749-1832
18
Neben dem Standard MARC 21 Format for Bibliographic Data, der hier vorgestellt wird, existieren
MARC 21 Format for Authority Data, MARC 21 Format for Holdings Data, MARC 21 Format for
Classification Data, MARC 21 Format for Community Information und Code Listen für Länder,
Sprachen, geographische Bereiche und Organisationen. Weiterführende Informationen hierzu finden
sich auf der Homepage der LOC zu MARC [Lib08a].
30
3 Metadatenformate
MARC wurde zuletzt im Oktober 2007 aktualisiert. Die deutsche und die österreichische Nationalbibliothek befinden sich zur Zeit in der Umstellung vom nationalen
MAB-Format (siehe Abschnitt 3.3.3) auf das internationale MARC.
3.3.2 Metadata Encoding and Transmission Standard
Der Metadata Encoding and Transmission Standard (METS) wird von der Digital Library Federation entwickelt und - wie MARC auch - von der LOC beaufsichtigt und
gepflegt. Im Gegensatz zu MARC handelt es sich bei METS aber nicht um ein Metadatenformat, sondern um ein offenes, nicht proprietäres XML-Schema zur Erzeugung
von XML-Dokumenten. Diese speichern Erschließungsangaben, Verwaltungsdaten und
Metadaten für die Struktur eines DOs und beinhalten Informationen darüber, in welchem Zusammenhang das beschriebene Objekt mit anderen DOs steht. METS schreibt
den Inhalt der Metadaten nicht vor, empfiehlt aber vordefinierte Sätze. So zum Beispiel
lässt sich der in Abschnitt 3.1.3 vorgestellte VRA Core aufgrund seiner XML-Struktur
unkompliziert in das METS-Schema einbinden. Ein METS-Dokument beinhaltet alle
Typen von Metadaten (beschreibende, strukturelle und administrative). Diese können
in unterschiedlichen Sektionen gespeichert und über Identifikatoren referenziert werden. Die Metadaten und das beschriebene digitale Objekt liegen entweder getrennt vor,
oder zusammen im METS-Dokument. Ein solches Dokument besteht aus sieben Teilen,
die im Folgenden genannt und kurz erläutert werden sollen.
• METS Header: Beschreibungen, die das METS-Dokument selber betreffen, werden in das Element <metsHdr> des Kopfteils geschrieben. Zu diesen Beschreibungen gehören der Name der Autoren, das Datum der Erzeugung bzw. der letzten
Änderung oder auch der Stand des Dokuments.
• Descriptive Metadata: Beschreibende Metadaten (Erschließungsangaben) liegen
im Element <dmdSec> und können intern oder extern vorliegen. Liegen sie außerhalb des METS-Dokuments vor19 , so werden sie über einen URI in dem XMLElement <mdRef> referenziert. Interne beschreibende Metadaten werden über das
Element <mdWrap> angesprochen, das entweder binäre Daten (<binData>) oder
- entsprechend des Namensraumes des METS-Schemas - Daten in XML-Form
(<xmlData>) beinhaltet. Die LOC hat als deskriptive Metadatenformate den
DC, das MODS, MARC und den VRA Core für den MET-Standard indossiert
([Dig08a]).
• Administrative Metadata: Metadaten zur Verwaltung werden durch das Element
<amdSec> beschrieben und beinhalten technische Metadaten, Urheberrechte und
Lizenzinformationen, Angaben zur Quelle und digitale Herkunftsangaben. Auch
diese Informationen liegen, wie die Erschließungsangaben, entweder intern oder
extern vor. Bei Bildern ist hier eine Implementierung der in Abschnitt 3.1.7 vorgestellten NISO Metadata for Images in XML denkbar ([Dig08a]).
19
Zum Beispiel in anderen Dokumenten oder in einer Webressource.
31
3 Metadatenformate
• File Section: Wenn das DO aus mehreren Dateien besteht, kann in diesem Abschnitt sichergestellt werden, dass zusammengehörige Dateien auch zusammengehalten werden. Über das Element <fileGrp> können verschiedene (externe)
Quellen z.B. über URLs oder URIs referenziert werden.
• Structural Map: Die Struktur in einem Buch ist dadurch sichergestellt, dass das
Buch gebunden ist und über Seitenzahlen verfügt. Bei DOs ist die Struktur nicht
selbstverständlich. In den Strukturbeschreibungen werden daher genau diese Informationen hinterlegt. So kann gewährleistet werden, dass nach dem Vorwort
Kapitel 1, danach Kapitel 2, usw. folgt. Im Element <structMap> wird mit Hilfe
von <div>-Elementen die Struktur festgelegt.
• Structural Links: Sollen die oben genannten Strukturbeschreibungen miteinander verknüpft werden, erfolgt dies über die Strukturverknüpfungen. Anschaulich
bedeutet dies nichts anderes als beispielsweise im Inhaltsverzeichnis eines PDFDokument auf einen Eintrag zu klicken und direkt auf die gewünschte Seite zu
gelangen.20
• Behavior: Soll das digitale Objekt über die vorangegangenen Elemente hinaus
Programmlogik unterstützen, so wird im Element <behavior> eine Schnittstellendefinition angegeben, die zumindest eine abstrakte Definition der später unterstützten Funktionen enthält. Das Unterelement <mechanism> verweist dann
auf den Programmcode, der die in der Schnittstelle definierten Funktionen implementiert.
Das METS-Schema liegt aktuell in der Version 1.7 vom Oktober 2007 vor und kann
unter [Dig07] eingesehen werden. Das METS-Schema lässt sich aufgrund der unterstützen beschreibenden und administrativen Metadatenformate nicht eindeutig den
Metadatenformaten für (digitale) Bibliotheken zuordnen. Die Kategorisierung erfolgte
aber aufgrund der Betreuung durch die LOC und aufgrund dessen, dass viele Nationalbibliotheken das METS-Schema einsetzen.
3.3.3 Maschinelles Austauschformat für Bibliotheken
Das Maschinelle Austauschformat für Bibliotheken (MAB) ist in seiner aktuellen Version MAB2 (1995), ähnlich MARC, eine Sammlung von Standards. Die Sammlung
umfasst die Formate MAB-Format für bibliographische Daten, MAB-Format für Personennamen, MAB-Format für Körperschaftsnamen, MAB-Format für Schlagwörter und
MAB-Format für Lokaldaten, sowie die beiden provisorischen Formate MAB-Format
für Adress- und Bibliotheksdaten und MAB-Format für Klassifikations- und Notationsdaten. Dieser Abschnitt befasst sich jedoch nur mit dem Teil der bibliographischen
Daten. Auch wenn sich in den Spezifikationen auf Anhieb Parallelen zwischen MAB2
([Die07]) und MARC ([Lib07]) finden lassen, so unterscheiden sie sich doch durch ein
wesentliches Merkmal. MAB2 zeichnet sich durch eine wesentlich höhere Granularität
aus. Jedes Element (Feld) kann als solches verwendet werden. MARC auf der anderen
20
In ihrer digitalen Version unterstützt die vorliegende Seminararbeit diese Funktion. Gekennzeichnet
werden die Verknüpfungen durch diese Farbe.
32
3 Metadatenformate
Seite schreibt bei einigen Feldern auch Unterfelder vor. Dem Listing 3.5 kann man
entnehmen, dass der Personenname unter anderem die Unterfelder Nummerierung und
Datum vorsieht. Bei MAB2 wird dieser Zusammenhang dadurch hergestellt, dass die
atomaren Felder Nummerierung und Datum als Unterelemente von Personenname in
einer Baumstruktur gruppiert werden.
Um MAB2 Felder und Datensätze zu transportieren und durch das in Abschnitt 3.2.4
vorgestellte Protokoll lesbar zu machen, wurde im Jahre 2003 das MABxml-Format
vorgestellt. Die Schemadefinition zur Darstellung der MAB-Felder in XML-Struktur
wurde im Mai 2005 zuletzt aktualisiert und liegt in der Version 1.2 ([Ket04]) vor. Um
die korrekte Darstellung und Umwandlung von MAB2 in MABxml zu garantieren,
wurde zudem ein Satz von Übertragungsregeln definiert (siehe [Ket03]).
MAB2 wurde unter der Führung der Deutschen Nationalbibliothek (DNB) von der
Expertengruppe Datenformate entwickelt und auch gepflegt. Zur Zeit befindet sich die
DNB jedoch in der Umstellung von MAB2 auf MARC. Eine Verbesserung der Übernahme und des Tausches von Fremddaten sowie eine freiere Systemwahl ([Die08]) sollen
diesen Schritt rechtfertigen. MAB2 wurde zunächst nur noch in international kompatibler Weise gepflegt. Anfang 2007 wurde die Weiterentwicklung vollständig eingestellt.
3.3.4 Metadata Object Description Schema
Aufgrund der Tatsache, dass METS für viele Anwender zu viele Felder bietet und es
damit schwieriger wird, genau die Metadaten zu extrahieren, die benötigt werden, wurde das Metadata Object Description Schema (MODS) vom Network Development and
MARC Standards Office der LOC entwickelt. MODS wurde vor allem für die Nutzung
durch Bibliothekenanwendungen entworfen und stellt eine Teilmenge des MARC 21
Format for Bibliographic Data dar21 . Dabei ist es mächtiger als der Dublin Core, aber
nicht so komplex wie METS. Es enthält die vermeintlich wichtigsten Felder von MARC,
was aber mit dem Verlust der speziellen Metadaten bei einer Konvertierung von MARC
nach MODS verbunden ist. Durch diesen Datenverlust ist es anschließend nicht mehr
möglich den originalen MARC Datensatz wiederherzustellen. Ein weiterer Unterschied
ist der, dass Feldnamen im MODS nicht mit einer dreistelligen Zahl (Tag), sondern
mit einem englischen Bezeichner (titleInfo, name, typeOfResource, usw.) benannt
sind.
Auch MODS wurde in einem XML-Schema definiert und liegt aktuell in der Version
3.3 vom 15. Januar 2008 vor (siehe [Lib08c]). Insgesamt beinhaltet das Schema 20
so genannte Top Level Elemente, zu denen neben den bereits genannten auch genre,
language, abstract und location gehören. Listing 3.7 zeigt ein kleines Beispiel einer
MODS-XML-Datei.
21
MODS ist keine echte Teilmenge von MARC. Mit der Entwicklung von MODS wurden einige Felder
vom MARC reorganisiert und dort, wo es sinnvoll war, wurden mehrere Felder zu einem gebündelt.
33
3 Metadatenformate
Listing 3.6: Reduziertes MODS Beispiel für die vorliegende Seminararbeit
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?xml version=’1.0’ encoding=’UTF-8’ ?>
<mods version="3.3"
...
<titleInfo>
<title>Metadaten</title>
</titleInfo>
<name type="personal">
<namePart>Wiemer, Kai</namePart>
<role>
<roleTerm type="text">creator</roleTerm>
</role>
</name>
<originInfo>
<place>
<placeTerm type="text">Sankt Augustin</placeTerm>
</place>
<dateIssued>15.06.2008</dateIssued>
</originInfo>
<language>
<languageTerm authority="iso639-2b" type="code">ger</languageTerm>
</language>
</mods>
3.3.5 BibTex
Diese Seminararbeit wurde mit dem Textsatzprogramm LATEXgeschrieben. LATEXsetzt
das WYGIWYM -Konzept22 um und zeichnet sich vor allem dadurch aus, dass externe
Software-Bibliotheken eingebunden und erstellte Dokumente so um nützliche Funktionen erweitert werden können. BibTex ist eine dieser Bibliotheken und wurde entwickelt, um Literaturangaben einheitlich zu gestalten und Zitationen korrekt durchzuführen. Eine BibTex-Datei enthält für jede Literaturangabe einen Datensatz. Da nicht
alle Quellen die gleichen Felder erfordern, existieren vordefinierte Literaturtypen, zum
Beispiel für ein Buch (@book), einen Artikel (@article) oder für technische Reporte
(@techreport). Ein Literaturtyp hat obligatorische Felder, die zwingend angegeben
werden müssen und optionale Felder, deren Nutzung dem Anwender freistehen. Der
Literaturtyp book hat die Pflichtfelder author, title, journal und year und die optionalen Felder volume, number, pages, month und note.
Folgendes Beispiel zeigt einen manual-Literatureintrag aus der BibTex-Datei dieser
Seminararbeit, der auf die BibTex-Dokumentation verweist.
22
WYGIWYM ist ein Akronym und steht für what you see is what you mean. Im Gegensatz zu what
you see is what you get-Ansätzen, wie das frei verfügbare Open Office Writer, muss der Anwender
Textdateien erstellen und entsprechende Formatierungen mit speziellen Befehlen und Markierungen
kennzeichnen. Die Textdateien werden kompiliert (Satz, Einbinden von Bildern, automatisches
Erstellen von Verzeichnissen, usw.) und das Ergebnis zum Beispiel als PDF exportiert.
34
3 Metadatenformate
Listing 3.7: Beispiel für den BibTex Literaturtyp manual
1
2
3
4
5
6
7
@manual{bibtex01,
author = "Oren Patashnik",
title = "BIBTEXing",
year
= "1988",
month = feb,
note
= "\url{http://dante.ctan.org/CTAN/biblio/bibtex/contrib/doc/btxdoc.pdf}. online am 20.04.2008"
}
Angegeben sind die Metadaten Autor, Titel, Erscheinungsjahr und -monat und ein
zusätzlicher Kommentar, der den URL zu dem extern verfügbaren Dokument und das
Datum der letzten Sichtung beinhaltet. Zu beachten ist, dass nur der Titel ein Pflichtfeld darstellt.
BibTex ist ein verbreitetes Format, das unter anderen bei der Literatur-Suchmaschine
CiteSeer ([NEC08]) verwendet wird. Ein Suchergebnis liefert neben Statistiken über
die Zitation auch den exakten BibTex-Eintrag.
35
In diesem Kapitel soll untersucht werden, inwieweit ausgewählte Dateiformate über
die Möglichkeit verfügen, sie mit Metadaten zu versehen. Hierbei ist zu beachten, dass
es beispielsweise mit dem XBMF grundsätzlich möglich ist, jede Datei mit Metadaten
zu versehen. Wie in Abschnitt 3.1.4 erläutert, wird das Archiv bestehend aus Audiound anderen Dateien komprimiert und über die beigefügte XML-Datei mit Metadaten
angereichert1 . Dieses Kapitel legt den Schwerpunkt der Untersuchung daher auf interne
Metadaten.
4.1 Portable Document Format (.pdf)
Das durch Adobe entwickelte und 1993 mit Acrobat veröffentlichte Portable Document
Format wird heute, wie alle Ausgabeformate der Adobe-Produktreihe (.psd, .ai, .indd,
usw.), durch die Extensible Metadata Platform unterstützt. Aus diesem Grund können alle durch die XMP unterstützen Metadatenformate in PDF-Dateien eingebettet
werden. Die XMP unterstützt durch vordefinierte Schemata unter anderem den Dublin Core und das Exchangeable Image File Format. Beide Formate und deren Felder
wurden im Abschnitt 3.1 vorgestellt. Die steigende Anzahl der Benutzer unter den
Industriestandard-Gruppen - unter anderem das W3C, die DCMI und das IPTC spricht für die steigende Anzahl an unterstützten Formaten in der Zukunft.
4.2 Joint Photographic Experts Group (.jpg,
.jpeg)
Das verlustbehaftete Bildformat der Joint Photographic Experts Group (JPEG) unterstützt die Möglichkeit sowohl Metadaten des EXIFs als auch des IPTCs (Information
Interchange Model) einzubetten. Zu den Metadatenfelder gehören demnach Headline,
Titel des Bildes, Name des Motivs, Keywords, Copyright, verschiedene Ortsangaben,
Writer/ Editor, kameraspezifische Metadaten und weitere Informationen über den Zusammenhang zwischen Bild und Kamera. Das Information Interchange Model wurde
auf Seite 16 und das Exchangeable Image File Format auf Seite 21 vorgestellt.
1
Zu beachten ist, dass das XBMF ein Metadatenformat ist, welches primär für Audiodateien entwickelt wurde. Zwar lassen sich beliebige Dateien im Dateicontainer unterbringen, jedoch stellt sich
die Frage, inwieweit der durch das XBMF zur Verfügung gestellte Satz von Metadaten genügt, um
alle Objekte adäquat zu beschreiben.
36
4.3 Microsoft Office Standard (.doc, .xls, .ppt)
In diesem Abschnitt soll auf die Dateiformate .doc, .xls und .ppt der Programme
Word, Excel und PowerPoint des Microsoft Office Standard-Pakets als Gesamtes eingegangen werden. In den Dateieigenschaften dieser Dateiformate lassen sich neben den
Betriebssystem-spezifischen Metadaten Pfad, Datum der Erzeugung, Letzte Änderung,
Letzter Zugriff, Besitzer, Dateigröße und verschiedenen Prüfsummen, auch die Metadaten Titel, Autor, Thema, Kommentare, Revisionsnummer, Programmname (z.B. Microsoft Word 9.0), Status, Seitenanzahl, Wortanzahl, Zeichenanzahl, Zeilenanzahl, Absatzanzahl, Art der Vorlage, und die Sprache ablesen. Microsoft selber nennt im Artikel
[Mic08] neben den hier genannten außerdem die Metadatenfelder Name des Computers/Netzwerkservers, Namen aller Autoren, Versionsnummern, und weitere versteckte
Felder an. Den Regeln eines bestimmten Metadatenformats scheint dieser Ansatz jedoch nicht zu folgen. Hierfür werden zu wenige allgemeine und zu viele programmspezifische Metadaten gespeichert. Nicht einmal der DC wird abgedeckt.
Um diese Metadaten vor Dritten zu verbergen, hat Microsoft das Add-In Remove Hidden Data für das Office Paket bereitgestellt. An dieser Stelle sollte auch das frei verfügbare Tool MetaViewer der Firma Pinpoint erwähnt werden, welches die Metadaten der
besagten Formate ausliest. Der MetaViewer findet auch in der Forensik Anwendung,
beispielsweise, um den exakten Verlauf von Dokumentenversionen nachzuvollziehen.
4.4 OpenOffice.org (.odt, .ods, .odp)
Ähnlich dem Office Paket der Microsoft Corporation unterstützt das freie OpenOffice.org das Einbetten von Metadaten in das Dokument und liefert im Paket einen
Dialog2 zum Editieren dieser Daten. Die vorhandenen Felder wurden in die folgenden
Kategorien eingeteilt:
• Allgemein: Dateityp, Ort im Dateisystem, Größe, Erstellungsdatum, Änderungsdatum, digitale Signatur, Letzter Druck, Gesamtbearbeitungszeit, Version und
Vorlage.
• Beschreibung: Titel, Thema, Schlüsselwörter und Kommentar.
• Benutzer: In dieser Kategorie lassen sich Informationen zu vier Benutzern als
Freitext angeben.
• Statistik: Dieser Bereich ist abhängig vom Dateityp. In .odt-Dokumenten findet man hier die Anzahl der Seiten, Tabellen, Grafiken, OLE-Objekte, Absätze,
Wörter, Zeichen und der Zeilen, in .ods-Dokumenten die Anzahl der Tabellen,
der Zellen und der Seiten. In .odp-Dateien fehlt diese Kategorie vollständig.
2
Im geöffneten Dokument zu finden unter Datei → Eigenschaften.... Getestet mit der WindowsVersion 2.3.1.
37
Der Dialog bietet dem Anwender zumindest die Möglichkeit die Metadaten der Kategorie Allgemein zu löschen und so zum Teil kritische Informationen vor Dritten zu
verbergen. Auch der Ansatz im OpenOffice.org Paket zielt nicht darauf, ab einen bestimmten Metadatensatz abzudecken.
4.5 Tagged Image File Format (.tiff)
Das Tagged Image File Format (TIFF) ist ein Format zur Speicherung von Bilddaten,
die intern komprimiert (ohne Verlust mit zlib oder verlustbehaftet mit JPEG) werden
können. Eingesetzt wird das Format aufgrund des unterstützten Farbraums und der
Möglichkeit, verlustunbehaftet zu Speichern, vor allem in der Druckvorstufe. Auch das
Tagged Image File Format wird durch das XMP unterstützt und verfügt daher über die
gleichen Möglichkeiten Metadaten aufzunehmen, wie auch JPEG und das im Anschluss
erläuterte Graphics Interchange Format(GIF). Eine TIFF-Bilddatei verfügt über ein
so genanntes Image File Directory (IFD), welches Informationen über das Bild und
Referenzen auf das eigentliche Bild bereithält. Eine dieser Referenzen nutzt das XMP,
um auf das XMP-Datenpaket zu verweisen ([Ado05]).
4.6 Compuserve Graphics Interchange Format
(.gif) und Portable Network Graphics (.png)
Eine GIF-Bilddatei erfüllt genau die Anforderungen, um es im Bereich des WWW
einzusetzen. Es ist verlustunbehaftet und die Dateigröße dabei verhältnismäßig klein,
was einer schnellen Übertragung zu Gute kommt. Der wesentliche Nachteil von GIF ist
der, dass das Bild mit maximal 256 Farben kodiert werden kann. Aus diesem Grund
wurde das Portable Network Graphics Format (PNG) entwickelt. Es komprimiert in
der Regel noch besser als das GIF und unterstützt eine Farbtiefe von bis zu 48 Bit.
Beide Formate können mittels XMP mit Metadaten versehen werden.
4.7 Moving Picture Experts Group (.mpg, .mpeg)
Wenn man von MPEG Dateien spricht, meint man in der Regel verlustbehaftet-komprimierte
Videos im MPEG-2 Format. Da dieser Standard nur strukturelle Metadaten (Aufbau
der Videodatei) bereithält, veröffentlichte die Motion Picture Expert Group 2002 die
Multimedia Content Description Interface (MPEG-7). Mit ihr es ist möglich, audiovisuellen Inhalt, also auch MPEG-2 Dateien, zu beschreiben. Das in Abschnitt 3.1.1
beschriebene Verfahren nutzt jedoch eine extern liegende XML-Datei, um das Objekt
(hier das Video) mit Metadaten zu versehen. Eine Einbettung in die binäre Datei ist
somit nicht möglich.
38
4.8 Moving Picture Experts Group 1 Audio Layer
3 (.mp3)
Der MP3-Standard selbst sieht keine Möglichkeit vor, Metadaten in die Binärdaten
einzubetten. Mit dem auf Seite 20 vorgestellten ID3-Verfahren ist es jedoch möglich
Metadaten intern in MP3-Dateien zu speichern. Da dieser Ansatz speziell für das MP3Format entwickelt wurde, unterstützt es in seiner aktuellen Version alle erdenklichen
Felder, um Musikstücke in diesem Format mit Zusatzinformationen zu versehen. Insgesamt über 70 Felder lassen sich mit aktuellen Mediaplayern oder speziellen Tools
befüllen und das Musikstück somit taggen. Abbildung 4.1 zeigt einen Screenshot aus
dem mächtigen und gleichermaßen komfortablen Tool ID3-TagIT, mit dem man alle
durch ID3 definierten Felder befüllen und eine MP3-Datei zudem mit einem Bild (z.B.
das Plattencover) versehen kann.
Abbildung 4.1: Screenshot aus dem Programm ID3-TagIT
4.9 Hypertext Markup Language (.html, .htm)
HTML-Dateien speichern Metadaten im Header in den so genannten <meta>-Tags.
Diese werden vom Browser nicht angezeigt, können jedoch wichtige zusätzliche Informationen über das Objekt beinhalten. Suchmaschinen durchsuchen mitunter diese Tags
39
und beziehen sie in die Suche mit ein. Seit der Version 4.0 des HTML-Standards werden keine konkreten Metadaten mehr vorgeschrieben, es wird lediglich der syntaktisch
korrekte Aufbau erläutert. Die Standardisierung der Metadaten erfolgt seitdem durch
das W3C in Form des Resource Description Frameworks, welches in Abschnitt 3.2.1
erläutert wurde. Mit dem RDF lassen sich zum Beispiel alle Elemente des Dublin Cores
in HTML-Dateien einbetten.
4.10 Komprimiertes ZIP-Archiv (.zip)
Zum Schluss soll exemplarisch ein komprimierbares Archiv-Dateiformat untersucht
werden. Das ZIP-Format unterstützt keine Metadaten, wie sie in dieser Arbeit genannt
wurden. Angaben über den Autor oder den Titel fehlen, machen im verwendeten Kontext aber auch nur bedingt Sinn. Ein Archiv kann aus mehreren Dateien bestehen, die
von unterschiedlichen Quellen stammen und unterschiedliche Namen haben können.
Aufgrund der Archivierung und Kompression müssen die archivierenden Programme
aber Metadaten über das Objekt in irgendeiner Form speichern, da sonst nicht gewährleistet werden kann, dass die Datei verlustunbehaftet wieder hergestellt werden
kann. Denkbar sind Metainformationen in Form von Lookup Tabellen oder Flags, die
im gepackten Dateistrom einen Dateianfang markieren. Es konnten jedoch keine Informationen über Metadaten, die darüber hinausgehen, recherchiert werden. Weder beim
ZIP-Format, noch bei anderen gängigen Archivformaten (.rar, .ace, .gzip, .tar).
40
5 Metadaten Mapping
Das Beispiel der Deutschen Nationalbibliothek macht deutlich, dass es notwendig sein
kann, Metadaten des einen Formats in ein anderes zu überführen. Im konkreten Beispiel stellt die DNB vom zur Zeit verwendeten maschinellen Austauschformat für Bibliotheken auf das internationale Machine-Readable Cataloging um. Dieser Prozess der
Überführung wird Metadatenmapping oder auch Crosswalking genannt. Die besondere
Herausforderung liegt darin, die Informationen über das digitale Objekt ohne Informationsverlust, ohne Verletzung der Bedingungen des Zielformats und korrekt, das heißt
in die entsprechenden Felder, zu überführen.
In diesem Kapitel sollen Probleme genannt werden, auf die man beim Crosswalking
stoßen kann. Hierfür sollen jedoch weitestgehend keine Lösungsansansätze präsentiert
werden. Zum einen könnte nur ein kleiner Teil der vorgestellten Metadatenformate abgedeckt werden1 . Zum anderen sind die Konvertierungen - wie sich im Verlauf dieses
Kapitels herausstellen wird - zum Teil sehr komplex und beinhalten viele Ausnahmebehandlungen, deren Nennung den Umfang einer separaten Ausarbeitung hätte. Zudem
präsentieren einige Entwickler bereits Ansätze, um das eigene in ein anderes Format,
respektive ein anderes Format in das eigene zu konvertieren. Einige Beispiele werden
am Ende des Kapitels genannt.
Der Prozess des (automatischen2 ) Crosswalks ist also nicht trivial. Die steigende Anzahl
der Metadatenformate und deren unterschiedliche Organisation (XML und andere Formate), machen es zunehmend schwierig, die relevanten Informationen zu extrahieren
und ein korrektes Mapping durchzuführen. Die folgende Aufzählung nennt die Hauptprobleme eines Crosswalks.
• Mapping zwischen zwei unterschiedlich mächtigen Formaten (Fehlende
Felder im Zielstandard): Ein Metadatensatz A, der nur wenige Kernelemente
umfasst, bietet nicht die gleiche Fülle an Feldern wie ein verhältnismäßig mächtigeres Format B. Für nicht vorhandene Felder im Format A hat das zur Konsequenz, dass Informationen verloren gehen. Ziel des Crosswalks kann es daher nur
sein, zumindest alle Kernelemente des Formats A durch entsprechende Felder des
Formats B abzudecken, um den Informationsverlust zu minimieren. Abhilfe für
dieses Problem könnte ein Feld für additional information schaffen, das speziell
für einen solchen Fall reserviert ist. Ist dem nicht so und existieren keine anderen
Ansätze, müssen die Daten verworfen und damit ein Informationsverlust in Kauf
genommen werden.
1
Alleine für die in dieser Seminararbeit vorgestellten Metadatenformate existieren rein theoretisch
mehrere hundert Kombinationsmöglichkeiten, was der Anzahl der möglichen Mappings entspricht.
2
Aufgrund der hohen Anzahl zu verwaltender DOs, muss es das Ziel eines jeden Mappings sein, ein
Format computergesteuert und voll automatisiert in ein anderes zu konvertieren.
41
5 Metadaten Mapping
• Mapping zwischen Formaten unterschiedlicher „Gattung“: Zu Problemen
kann es auch dann kommen, wenn ein Format A, welches speziell für audiovisuelle
Inhalte entwickelt wurde, in ein Format B überführt werden soll, welches für den
Austausch von Informationen elektronischer Bücher dient. Es fehlen adäquate
Felder, um das Mapping korrekt durchzuführen. Dieses konkrete Beispiel lässt
sich auch auf andere digitale Objekte übertragen.
• Doppelter Crosswalk: Mitunter ist es notwendig ein Objekt, welches durch ein
komplexes und vollständiges Metadatenformat B beschrieben ist, durch ein weniger komplexes Format A zu beschreiben und diesen Prozess anschließend wieder
umzukehren3 . Im Kern entspricht der erste Schritt dem erstgenannten Problem,
denn wichtige Informationen des Formats B gehen möglicherweise verloren. Unter
der Voraussetzung, dass alle Felder abgedeckt sind, stellt dieser Crosswalk aus
Sicht des Formats A kein Problem dar. Werden die Felder des Formats A nun
jedoch wieder in das mächtigere Format B überführt, kann nicht sichergestellt
werden, dass unter den Informationen, die verloren gegangen sind, nicht genau
die enthalten sind, die für eine zuverlässige Funktion der dahinterstehenden Anwendung unabdingbar wären. Dieses Problem ist von eher theoretischer Natur,
da es bereits durch eine Sicherung des Satzes B vor der ersten Konvertierung zu
umgehen ist.
• Schnittmenge: Schon der Schritt eine geeignete Schnittmenge zwischen Quellund Zielformat zu finden, kann sich schwierig gestalten, da die Terminologien
der Ansätze mitunter sehr verschieden sind. Der Dublin Core verwendet zum
Beispiel die Terminologie <dc:attribut>wert</dc:attribut> (XML) oder auch <meta
name="DC.attribut"content="wert"/> (HTML). Der MIX-Standard hingegen nutzt
trotz der Verwendung von XML die Terminologie <attribut>wert<attribut>, wobei
die Attribute hierbei zudem über mehrere Ebenen geschachtelt sein können. Die
Schwierigkeit liegt darin, auf Basis dieser unterschiedlichen Terminologien Mechanismen zu entwickeln, die die relevanten Daten extrahieren (wert) und diese
dann in die entsprechenden Felder mappen.
• Unterschiedliche Eigenschaften: Einige Standards definieren über den Inhalt
der Felder hinaus auch gewisse Eigenschaften. So zum Beispiel werden einige
Felder als obligatorisch und andere als optional deklariert. Weiterhin kann die
Spezifikation das wiederholte Vorkommen eines Elements erlauben oder verbieten. Einige Ansätze geben sogar explizite Grenzen an. Unterscheiden sich Quellund Zielstandard in den Eigenschaften ihrer Elemente, müssen Sonderregelungen
geschaffen werden.
• Obligatorische Felder im Zielstandard: Aus der letzt genannten Gruppe von
Problemen ergibt sich unmittelbar ein weiteres. Wenn kein entsprechendes Feld
für ein Element im Ziel vorhanden ist, dieses aber obligatorisch ist, muss geklärt
werden, wie damit verfahren wird.
3
Ein Beispiel: Nicht alle Formate können durch das OAI Protocol for Metadata Harvesting (siehe
Seite 28) erfasst werden. Daher kann es notwendig sein, ein sehr spezielles Metadatenformat in
ein durch das Protokoll erfassbares Format zu konvertieren. Anschließend soll aber wieder das
ursprüngliche Format hergestellt werden.
42
5 Metadaten Mapping
• Unterschiedliches Handling bei Schlagworten: Bei einigen Formaten besteht die Möglichkeit, ein bestimmtes nicht wiederholt vorkommendes Feld mit
Schlagwörtern, getrennt durch einen Delimiter, zu befüllen. Erlaubt der Zielstandard dies jedoch nicht, sondern sieht für jedes Schlagwort ein sich wiederholendes
Feld vor, setzt dies zusätzliches Wissen über das korrekte Mapping voraus und
macht es überdies komplexer.
• Unterschiedliche Kodierung der Felder: In einigen Fällen müssen Felder
zusammengefasst werden, bevor sie gemapped werden. Sieht der Quellstandard
beispielsweise für den Vor- und den Nachnamen jeweils ein eigenes Feld vor, der
Zielstandard jedoch nur ein einziges, muss zusätzlich vor dem Zusammenfassen
festgestellt werden, wie der Name im Zielstandard definiert ist4 .
• SOS vs. MOS: Das in 3.1.4 vorgestellte Exchange Binary Broadcast and Metadata Format beschreibt in seiner im Archiv befindlichen XML-Datei nicht nur die
Audio-Datei, sondern auch alle im Verzeichnis dateien liegenden Dateien. Das
XBMF ist ein so genannter Multiple Object Standard (MOS), der im Gegensatz
zu Single Object Standards (SOS) das simultane Einbetten von Metadaten für
mehrere Objekte erlaubt. Bei der Konvertierung eines MOSs in einen SOS muss
das berücksichtigt werden. Denkbar wäre es, jedes Objekt des Quellstandards für
sich mit Metadaten des Zielstandards zu versehen und die Zusammengehörigkeit
über URIs wiederherzustellen. Der Dublin Core und das Exchangeable Image File
Format sind typische Vertreter der SOSs.
Anhand der vorangegangenen Schilderungen ist leicht ersichtlich, dass ein Mapping ein
gewisses Maß an Planung und große Sorgfalt voraussetzt. Einige Entwickler der im
3. Kapitel vorgestellten Formate sind sich dieser Problematik bewusst und stellen für
ihre Standards die passenden Übertragungsregeln für (zumindest einige) Crosswalks
zur Verfügung. Besonders hervorzuheben sind hier die Konvertierungsschemata der
LOC im Zusammenhang mit dem Metadata Object Description Schema ([Lib08b])
und das Kapitel Metadata Mappings (Crosswalks) im Metadata Reference Guide der
MIT Libraries ([Met06]).
4
Vorname Nachname oder Nachname, Vorname.
43
6 Bewertung
Im 3. Kapitel wurde bereits mit einer kleinen Auswahl gezeigt, wie viele verschiedene Metadatenformate existieren und es wurde zudem verdeutlicht, wie unterschiedlich
diese Ansätze umgesetzt wurden. Die Unterscheidung in Metadaten in der Multimedia,
im World Wide Web und in (digitalen) Bibliotheken wurde zu Gunsten der Übersicht gewählt. Natürlich hätte die Kategorisierung auch auf Basis des Verfahrens ihrer
Speicherung erfolgen können. Metadaten werden entweder separat in einer Datei oder,
wenn es das Dateiformat zulässt, in der Datei gespeichert. Beide Verfahren zeichnen
sich durch Vor- und Nachteile aus.
Werden digitale Objekte mit internen Metadaten transferiert, besteht nicht die Gefahr,
dass die Metadaten verloren gehen. Auf der anderen Seite muss zusätzlicher Aufwand
betrieben werden um die Zusammengehörigkeit von DOs und deren Metadaten zu
sichern. Im Verlaufe dieser Arbeit wurden zwei Ansätze für das externe Speichern
genannt. Zum einen kann die externe Metadatendatei über einen URI mit dem DO
verknüpft werden und zum anderen vor der Übertragung in einem Archiv zusammen
mit dem zu beschreibenden Objekt gespeichert werden.
Ein Vorteil, der sich durch die externe Speicherung ergibt, ist die komfortablere Manipulation der Metadatenfelder. Die meisten externen Ansätze schreiben die Metadaten
in eine XML-Datei, die mit einem herkömmlichen Editor manipuliert werden kann. Es
ist keine spezielle Software notwendig, die den Dateistrom von den internen Metadaten
trennt, um die Informationen menschenlesbar zu machen.
Externe Metadaten ermöglichen es zudem, Redundanz zu vermeiden. So könnte zum
Beispiel eine externe Metadatendatei mehrere digitale Objekte oder zumindest deren
Gemeinsamkeiten1 einmalig beschreiben. Nur die Unterschiede würden in einer separaten Metadatendatei pro DO gespeichert. Dieses Verfahren ist bei der Verwendung
interner Metadaten nicht möglich.
Metadaten sollen dabei helfen, Ressourcen vor allem effektiv auffindbar zu machen.
Auch hierbei ergibt sich ein Unterschied zwischen internen und externen Metadaten.
Metadaten werden oft in Datenbanken verwaltet und ermöglichen es so, Anfragen zu
bestimmten Objekten abzusetzen. Da es wesentlich effizienter und ressourcenschonender ist, eine - im Verhältnis zum beschriebenen Objekt - kleine Metadatendatei zu
durchsuchen, als die Metadaten zunächst aus dem DO zu extrahieren und dann nach
1
Sollen alle Werke eines bestimmten Autors durch Metadaten beschrieben werden, ist es nicht notwendig, den Namen des Autors jedes Mal zu speichern. Sinnvoller ist es, eine Hierarchie aufzubauen,
wobei alle Elemente (hier Werke) auf einer unteren Ebene, die Eigenschaften der darüber liegenden erben. Ein DO, bzw. eine Referenz darauf, läge dann in einem der Blätter des entstandenen
Baumes.
44
6 Bewertung
dem gewählten Kriterium zu durchsuchen, ist der Ansatz der externen Metadaten hier
zu bevorzugen.
Das Thema Metadaten rief in der Vergangenheit zunehmend Datenschützer auf den
Plan. Oft schreiben Anwendungen mitunter sensible Metadaten in die exportierten
Dateien, ohne dass es der Anwender merkt. So kann es passieren, dass mit einem .docDokument der Name der Autoren und die Überarbeitungshistorie übertragen wird.
Dieser Aspekt mag für die meisten Privatanwender unproblematisch erscheinen. Im
geschäftlichen Bereich, wo es vor allem um vertragliche und rechtliche Fragen geht,
kann dieser Umstand nicht einkalkulierbare Risiken bergen. Mitarbeiter in Unternehmen sollten dahingehend aufgeklärt und sensibilisiert werden. Einige Entwickler bieten
zusätzliche Tools an, um Metadaten aus Ihren Dateien zu löschen. In Abschnitt 4.3
wurde ein solches Tool vorgestellt. Andere Anbieter gehen konsequenter an die Sache
heran. Sie bieten dem Anwender bereits beim Export die Möglichkeit, Metadaten zu
schreiben oder bestimmte Felder auszulassen.
Die hohe Anzahl verschiedener Metadatenformate hat zwar den Vorteil, dass sich ein
Anwender das passende heraussuchen kann, birgt aber eine zunehmende Inkompatibilität und damit ein Wartbarkeitsproblem. Das Konzept des Metadaten Mappings
wurde in Kapitel 5 vorgestellt. Mit dem auch Crosswalking genannten Verfahren lassen
sich diese Probleme von der Idee her zwar beheben oder zumindest umgehen, jedoch
bringt das Mapping viele neue Probleme mit sich. Die Deutsche Nationalbibliothek
setzt sich zurzeit genau mit diesen Problemen auseinander, wobei die Umstellung von
MAB auf das internationale MARC-Format aufgrund der Parallelen zwischen den beiden Formaten zwar Sorgfalt erfordert, nicht jedoch als unlösbar einzustufen ist. Zu
berücksichtigende Schwierigkeiten wurden in Kapitel 5 ausführlich erläutert.
Weitere Probleme können sich schon bei der Auswahl des passenden Metadatenformats ergeben. Zum einen sollte das Format alle notwendigen Felder besitzen, dabei
unkompliziert in der Handhabung sein und nicht zuletzt einen hohen Verbreitungsgrad
aufweisen. Nimmt man als Beispiel das in Abschnitt 3.1.1 vorgestellte MPEG-7-Format,
so weist dies zwar alle erdenklichen Felder zum Beschreiben von Multimedia-Dateien
auf, jedoch konnte es sich bis heute nicht durchsetzen. Es versucht allumfassend zu
sein und wird deswegen als zu kompliziert eingeschätzt. Auf der anderen Seite findet
man den Dublin Core, der als einer der gängigsten Sätze gilt und mit seinen 15 Feldern
als unkompliziert einzustufen ist. Mit 15 Feldern stößt man jedoch schnell an gewisse
Grenzen, vor allem, wenn es darum geht, DOs sehr detailliert zu beschreiben. Einen
guten Ansatz verfolgt die Extensible Metadata Platform, die verschiedene Metadatenformate unterstützt und somit vereint, ohne jedoch die Lesbarkeit dieser Daten durch
andere Programme, die die XMP nicht unterstützen, zu gefährden. Ein entscheidender
Nachteil ist der, dass, gemessen an der Dateiformat-Vielfalt, relativ wenige Formate unterstützt werden und diese alle aus dem Umfeld der Multimedia stammen. Es
bleibt abzuwarten, ob vergleichbare Ansätze in anderen Bereichen entwickelt werden
und zukünftig eine ähnlich hohe Akzeptanz aufweisen.
45
[Ado05]
Adobe Systems Incorporated: XMP — Adding Intelligence to Media, September 2005. – http://www.adobe.com/devnet/xmp/pdfs/xmp_
specification.pdf. - online am 20. April 2008
[Bec04]
Beckett, Dave: RDF/XML Syntax Specification (Revised). http://www.
online am 18. Mai
2008
w3.org/TR/rdf-syntax-grammar/, Februar 2004. –
[BG00]
Brickley, Dan ; Guha, R.V.:
Resource Description Framework (RDF) Schema Specification 1.0. http://www.w3.org/TR/2000/
CR-rdf-schema-20000327/, März 2000. – online am 18. Mai 2008
[BGP03]
Bormans, Jan ; Gelissen, Jean ; Perkis, Andrew: MPEG-21: The 21st
Century Multimedia Framework. In: IEEE Signal Processing Magazine 20
(2003), March, Nr. 2, S. 53–62
[BL04]
Boutell, Matthew ; Luo, Jiebo: Photo Classification by Integrating
Image Content and Camera Metadata. In: Proceedings of the 17th International Conference on Pattern Recognition (IEEE) 4 (2004), August,
S. 901–904
[Boo06]
Book Industry Study Group, Inc.: ONIX for Books. http://www.
editeur.org/onix.html, Februar 2006. – online am 20. Mai 2008
[BWH+ 03] Burnett, Ian ; Walle, Rik V. ; Hill, Keith ; Bormans, Jan ; Pereira,
Fernando: MPEG-21: Goals and Achievements. In: IEEE MultiMedia 10
(2003), October-December, Nr. 4, S. 60–70
[Con08]
Congress, Library of: NISO Metadata for Images in XML Schema — Official Website. http://www.loc.gov/standards/mix/, Mai 2008. – online
am 16. Mai 2008
[Cun08]
Cundiff, Morgan: MIX Version 2.0, Mai 2008. – http://www.loc.gov/
standards/mix/mix20/mix20.xsd. - online am 16. Mai 2008
[Day02]
Day, Michael: Metadata — Mapping between metadata formats. http:
//www.ukoln.ac.uk/metadata/interoperability/, Mai 2002. – online
am 20. April 2008
[Die06]
Die Deutsche Nationalbibliothek: MAB — Maschinelles Austauschformat für Bibliotheken. http://www.d-nb.de/standardisierung/
formate/mab.htm, Juni 2006. – online am 20. April 2008
46
[Die07]
Die Deutsche Nationalbibliothek:
MAB2-Titel: OnlineKurzreferenz-Version.
http://www.d-nb.de/standardisierung/txt/
titelmab.txt, November 2007. – online am 23. Mai 2008
[Die08]
Die Deutsche Nationalbibliothek: Datenaustauschprozesse zwischen
Bibliotheken im deutschsprachigen Raum vor dem Umstieg auf MARC 21
mit besonderer Berücksichtigung von MARCXML. http://www.d-nb.de/
standardisierung/pdf/expertise_marcxml.pdf, Februar 2008. – online
am 23. Mai 2008
[Dig07]
Digital Library Federation: METS — Metadata Encoding and Transmission Standard. http://www.loc.gov/standards/mets/mets.xsd, Oktober 2007. – online am 23. Mai 2008
[Dig08a]
Digital Library Federation: Metadata Encoding and Transmission Standard: Extension Schemas, Mai 2008. – http://www.loc.gov/
standards/mets/mets-extenders.html. - online am 12. Mai 2008
[Dig08b]
Digital Library Production Service: OAIster — ...find the pearls.
http://www.oaister.org/, 2008. – online am 20. Mai 2008
[DSD03]
DSD Sztaki, Team Teichenberg, Public Voice Labor: Exchange
Broadcast Binary and Metadata Format, Dezember 2003. – http://sotf.
berlios.de/documents/XBMF_V0-31.pdf. - online am 20. April 2008
[Dub08]
Dublin Core Metadata Initiative: Dublin Core Metadata Element
Set — Version 1.1. http://dublincore.org/documents/dces/, Januar
2008. – online am 18. Mai 2008
[Eur93]
European Broadcasting Union: Methods of measurement of the colorimetric performance of studio monitors. http://www.ebu.ch/CMSimages/
en/tec_doc_t3273_tcm6-10531.pdf, Oktober 1993. – online am 13. Mai
2008
[Ins02]
Institute of Electrical and Electronics Engineers, Inc.: Draft
Standard for Learning Object Metadata, 2002. – http://ltsc.ieee.org/
wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf. - online am 20. April
2008
[Ins04]
Institute for Advanced Technology in the Humanities: Encoded
Archival Context (Beta). http://www.iath.virginia.edu/eac/, November 2004. – online am 20. April 2008
[Int99a]
International Press Telecommunications Council and Newspaper Association of America: Information Interchange Model IIM: the
first multi-media news exchange format. http://www.iptc.org/IIM/, Juli
1999. – online am 20. April 2008
[Int99b]
International Press Telecommunications Council and Newspaper Association of America: Information Interchange Model Version 4. http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf,
Juli 1999. – online am 12. Mai 2008
47
[Ket03]
Kett, Jürgen: Regeln zur Übertragung von MAB2-Datensätzen nach
MABxml-1 — Version 1.0. http://www.d-nb.de/standardisierung/
pdf/mabxml_1_uebertr.pdf, Dezember 2003. – online am 23. Mai 2008
[Ket04]
Kett, Jürgen:
[Lib02]
Library of Congress: Encoded Archival Description. http://www.loc.
gov/ead/, 2002. – online am 20. April 2008
[Lib06]
Library of Congress: Metadata Object Description Scheme. http:
//www.loc.gov/standards/mods/, Juni 2006. – online am 20. April 2008
[Lib07]
Library of Congress: MARC 21 Format for Bibliographic Data —
Field List. http://www.loc.gov/marc/bibliographic/ecbdlist.html,
Oktober 2007. – online am 22. Mai 2008
[Lib08a]
Library of Congress: MARC Standards. http://www.loc.gov/marc/,
März 2008. – online am 20. April 2008
[Lib08b]
Library of Congress:
Metadata Object Description Schema
(MODS) — Conversions.
http://www.loc.gov/standards/mods/
mods-conversions.html, Mai 2008. – online am 03. Juni 2008
[Lib08c]
Library of Congress: Metadata Object Description Scheme 3.3. http:
//www.loc.gov/standards/mods//v3/mods-3-3.xsd, Januar 2008. – online am 23. Mai 2008
[LS02]
Lagoze, Carl ; Sompel, Herbert V.: The Open Archives Initiative
Protocol for Metadata Harvesting — Protocol Version 2.0, Juni 2002. –
http://www.openarchives.org/OAI/openarchivesprotocol.html. - online am 20. April 2008
[Met06]
Metadata Advisory Group of the MIT Libraries: Metadata
Mappings (Crosswalks). http://libraries.mit.edu/guides/subjects/
metadata/mappings.html, Juni 2006. – online am 20. April 2008
[Mic08]
Microsoft Corporation: Find and remove metadata (hidden information) in your legal documents. http://office.microsoft.com/en-us/
help/HA010776461033.aspx, 2008. – online am 28. Mai 2008
[MM04]
Manola, Frank ; Miller, Eric: Resource Description Framework (RDF)
Primer, Februar 2004. – http://www.w3.org/TR/rdf-primer/. - online
am 20. April 2008
[Nat06]
National Information Standards Organization:
Data Dictionary — Technical Metadata for Digital Still Images.
http:
MABxml — Level 1.
http://www.d-nb.de/
standardisierung/formate/mabxml-1.xsd, Mai 2004. – online am 23.
Mai 2008
//www.niso.org/kst/reports/standards?step=2&gid=None&project_
key=b897b0cf3e2ee526252d9f830207b3cc9f3b6c2c, Dezember 2006. –
online am 20. April 2008
48
[NEC08]
NEC Research Institute: SiteSeer.IST — Scientific Literature Digital
Library. http://citeseer.ist.psu.edu/, 2008. – online am 23. Mai 2008
[Nil98]
Nilsson, Martin: ID3 tag version 2, März 1998. – http://www.id3.org/
id3v2-00. - online am 14. Mai 2008
[Nil99]
Nilsson, Martin: ID3 tag version 2.3.0, Februar 1999. – http://www.
id3.org/id3v2.3.0. - online am 14. Mai 2008
[Nil00a]
Nilsson, Martin: ID3 tag version 2.4.0 — Main Structure, November
2000. – http://www.id3.org/id3v2.4.0-structure. - online am 20. April
2008
[Nil00b]
Nilsson, Martin: ID3 tag version 2.4.0 — Native Frames, November 2000.
– http://www.id3.org/id3v2.4.0-frames. - online am 20. April 2008
[NL99]
Nack, Frank ; Lindsay, Adam T.: Everything You Wanted to Know
About MPEG-7: Part 1. In: IEEE MultiMedia 6 (1999), –, Nr. 3, S. 65–77
[One08]
OneClimate: OneWorldTv. http://tv.oneworld.net/, 2008. – online
am 13. Mai 2008
[Org02]
Organisation Internationale De Normalisation: MPEG-21 Overview v.5.
http://www.chiariglione.org/mpeg/standards/mpeg-21/
mpeg-21.htm, Oktober 2002. – online am 12. Mai 2008
[Pat88]
Patashnik, Oren: BIBTEXing, Februar 1988. – http://dante.ctan.org/
CTAN/biblio/bibtex/contrib/doc/btxdoc.pdf. - online am 20. April
2008
[RF]
Rusch-Feja, Diann: Die Open Archives Initiative (OAI) — Neue Zugangsform zu wissenschaftlichen Arbeiten? In: Bibliothek - Forschung und
Praxis, Jahrgang 25, Nr. 3
[SOM02]
SOMA Group: Shared Online Media Archive Metadata version 1. http:
//soma-dev.sourceforge.net/, September 2002. – online am 13. Mai
2008
[SS06]
Smith, John R. ; Schirling, Peter: Metadata Standards Roundup. In:
IEEE MultiMedia 13 (2006), April-June, Nr. 2, S. 84–88
[Tec02]
Technical Standardization Committee on AV & IT Storage
Systems and Equipment: Exchangeable image file format for digital still
cameras: Exif Version 2.2, April 2002. – http://www.exif.org/Exif2-2.
PDF. - online am 20. April 2008
[Wik08]
Xml — Wikipedia, Die freie Enzyklopädie. http://de.
wikipedia.org/w/index.php?title=Xml&oldid=32654667, Mai 2008. –
online am 27. Mai 2008
[Wor08]
World Wide Web Consortium: Extensible Markup Language (XML).
http://www.w3.org/XML/, Mai 2008. – online am 27. Mai 2008
Wikipedia:
49

Metadatenformate - Labor für Business Information Systems

Transcription

Similar documents

Preisliste Nr. 73

Visualisierungstechniken in der Landschaftsplanung am

"B" und

PDF-file, 440 KB - Historisches Centrum Hagen

MABxml - Dokumentation v1.0

Von MAB2 nach MABxml

Anwenderleitfaden für Encoded Archival Description

Erfolgreich Führen mit ethischer Verantwortung