Metadatenanreicherung im digitalen Publikationsprozess

Metadatenanreicherung im digitalen Publikationsprozess

Diplomarbeit an der Technischen Universität Dresden

Januar 2009

Alexander Haffner Betreuer: Dipl.-Bibl. Christine Frodl

Dipl.-Ing. Thorsten Völkel Verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil. Gerhard Weber

Professur Mensch-Computer Interaktion Institut für Angewandte Informatik

Fakultät Informatik

Professur Mensch-Computer InteraktionInstitut für Angewandte Informatik

Fakultät Informatik

AUFGABENSTELLUNG FÜR DIE DIPLOMARBEIT Name, Vorname: Haffner, Alexander Studiengang: Informatik Immatrikulationsnummer: 2704099

Thema: Metadatenanreicherung im digitalen Publikationsprozess Zielstellung: Digitale Bibliotheken nehmen im modernen Publikationsprozess von Dokumenten eine zentrale Rolle ein. Aufbauend auf Konzepten digitaler Archivierungssysteme ist anhand von geeigneten Metadatenanreicherungsstrategien ein optimierter Workflow unter Einbeziehung aller partizipierenden Organisationen zu entwickeln. Weiterfüh-rend sind für die Prozessmodellierung insbesondere Untersuchungen zur Integration von Konzepten zur Erhöhung der Barrierefreiheit einzubinden. Teilziele:

1. Erhebung einer Anforderungsspezifikation für die Bereitstellung von Metada-ten durch Autoren, Verlage und Bibliotheken

2. Konzeption eines Metadatensatzes zur Ausweisung der Barrierefreiheit von elektronischen Publikationen

3. Entwicklung eines erweiterten Prozessmodells unter der Einbeziehung von Accessibility-Aspekten

4. Konzeption und prototypische Implementierung einer webbasierten Anwen-dung für die Einpflege von Digital Talking Books

5. Metadatenvisualisierungskonzepte für die Endnutzer Fachbetreuer: Dipl.-Bibl. Christine Frodl

Dipl.-Ing. Thorsten Völkel Verantwortl. Hochschullehrer: Prof. Dr. rer. nat. habil. Gerhard Weber Beginn: 2008-08-01 Einzureichen bis: 2009-01-31

Unterschrift des verantwortlichen Hochschullehrers

Erklärung Hiermit erkläre ich, Alexander Haffner, die vorliegende Diplomarbeit zum Thema

Metadatenanreicherung im digitalen Publikationsprozess selbstständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufge-führten Literatur- und sonstigen Informationsquellen verfasst zu haben. Ort, Datum Unterschrift

Metadatenanreicherung im digitalen Publikationsprozess Inhaltsverzeichnis

Inhaltsverzeichnis 1 Einführung ......................................................................................... 1

1.1 Motivation ........................................................................................................1 1.2 Zielstellung ......................................................................................................1 1.3 Inhaltlicher Aufbau...........................................................................................2 1.4 Danksagung ....................................................................................................3

2 Metadaten .......................................................................................... 4 2.1 Was sind Metadaten? ......................................................................................4 2.2 Die Rolle der Bibliothek ...................................................................................5

2.2.1 Was braucht ein Katalog?..........................................................................6 2.2.2 Herkömmliche Regelwerke für die Katalogisierung ...................................6 2.2.3 Resource Description and Access (RDA) ..................................................9

2.3 Arten von Metadaten .....................................................................................13 2.4 Metadatenstandards ......................................................................................15 2.5 Zusammenfassung ........................................................................................17

3 Modellierung der Prozesse in digitalen Bibliotheken .................. 18 3.1 Die digitale Bibliothek ....................................................................................18 3.2 Open Archival Information System (OAIS) Reference Model ........................19 3.3 Harvesting .....................................................................................................22 3.4 Open Archives Initiative Object Reuse and Exchange (OAI-ORE) ................25

4 Anforderungen und Analyse .......................................................... 28 4.1 Barrierefreiheit in der digitalen Bibliothek ......................................................28 4.2 Digitale Publikationen ....................................................................................30

4.2.1 PDF-Dokumente ......................................................................................31 4.2.2 Digital Talking Book .................................................................................33

4.3 Prozesspartizipierende Organisationen .........................................................38 4.3.1 Deutsche Nationalbibliothek (DNB) .........................................................38 4.3.2 Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) ..................................................................................................47 4.3.3 Deutsche Zentralbücherei für Blinde zu Leipzig (DZB) ............................53 4.3.4 Mediengemeinschaft für blinde und sehbehinderte Menschen e.V. ........58

5 Barrierefreiheit und Metadaten ...................................................... 61 5.1 Accessibility-Metadaten .................................................................................62

5.1.1 IMS AccessForAll Meta-data (ACCMD)...................................................62 5.1.2 Dublin Core AccessForAll (DC-AfA) ........................................................63

5.2 Metadaten zur Aggregation ...........................................................................65 5.2.1 Metadaten für die Entitätsbeziehungen gemäß dem FRBR Model ..........66 5.2.2 Verknüpfung von Struktur-Metadaten und Accessibility-Metadaten.........68 5.2.3 Serialisierung der Metadaten...................................................................72

6 Modellierung eines erweiterten Prozessmodells für das digitale Publizieren ............................................................................................ 83

6.1 Katalogisierung, Metadatenanreicherung und Archivierung ..........................83 6.2 Ressourcenproduktion und Einpflege ............................................................90 6.3 Zugänglichkeitsgewährung zu Ressourcen ...................................................96 6.4 Kollaborative Accessibility .............................................................................99

7 Komponente zur Einpflege von DTBs ......................................... 101 7.1 Anforderungen.............................................................................................101

7.1.1 Nicht-funktionale Anforderungen ...........................................................101 7.1.2 Funktionale Anforderungen ...................................................................101

Copyright TU Dresden, Alexander Haffner I

Metadatenanreicherung im digitalen Publikationsprozess Inhaltsverzeichnis

7.2 Umsetzung ..................................................................................................102 8 Präsentation von Metadaten ........................................................ 104 9 Schlussbetrachtungen ................................................................. 108 Literaturverzeichnis ........................................................................... 110 Abkürzungsverzeichnis ..................................................................... 116 Abbildungsverzeichnis ...................................................................... 119 Tabellenverzeichnis ........................................................................... 120 A Metadatenstandardkompendium .................................................. 121

A.1 Maschinelles Austauschformat für Bibliotheken (MAB) ..................................121 A.2 MARC 21........................................................................................................121 A.3 Metadata Object Description Schema (MODS)..............................................127 A.4 Dublin Core ....................................................................................................128 A.5 Pica+/Pica3 ....................................................................................................132 A.6 Online Information Exchange (ONIX) .............................................................133 A.7 XMetaDiss......................................................................................................137 A.8 Extensible Metadata Platform (XMP) .............................................................139 A.9 Metadaten zur Langzeitarchivierung ..............................................................142

A.9.1 Preservation Metadata: Implementation Strategies (PREMIS).................142 A.9.2 Langzeitarchivierungsmetadaten für elektronische Ressourcen (LMER) .145

A.10 Metadata Encoding and Transmission Standard (METS) ............................146 A.11 XML Formatted Data Unit (XFDU) ...............................................................148

B DAISY-Metadaten............................................................................ 151 B.1 Metadaten in Digital Talking Books gemäß ANSI/NISO Z39.86-2005............151

B.1.1 Publikationsmetadaten in OPF.................................................................151 B.1.2 Metadaten in SMIL ...................................................................................151 B.1.3 Navigationsmetadaten im NCX ................................................................152

B.2 Metadaten in DAISY 2.02 Dokumenten..........................................................152 B.2.1 Metadaten in NCC.HTML .........................................................................152 B.2.2 Metadaten in SMIL ...................................................................................153 B.2.3 Master SMIL Metadaten ...........................................................................153

C Accessibility-Metadaten................................................................. 154 C.1 IMS AccessForAll Meta-data (ACCMD) Abstract Model ................................154 C.2 Dublin Core AccessForAll (AfA) Abstract Model ............................................155

D Konkordanz DTB-Metadaten - MARC 21....................................... 156 E Beispiele für RDF-Tripel in OAI-ORE ............................................ 159

Copyright TU Dresden, Alexander Haffner II

Metadatenanreicherung im digitalen Publikationsprozess Einführung

1 Einführung 1.1 Motivation Publizierte Werke bewahren seit hunderten von Jahren das kulturelle Erbe unserer Gesellschaft. Die Archivierung und Verbreitung dieser Werke formte den bis zum heutigen Tage geprägten Wissenstand der Menschheit. Insbesondere die Digitalisie-rung von Publikationen und die im Computerzeitalter eingekehrten Distributionsver-fahren haben den Wissenstransfer entscheidend beeinflusst und werden jenen in Zukunft immer stärker beherrschen. Die Anzahl von neu erscheinenden Publikationen ist in den letzten zwanzig Jahren exponentiell angestiegen. Grund dafür ist unter anderem das rasante Wachstum von digitalen Ressourcen im World Wide Web. Die Organisation von Publikationen, ganz gleich ob in digitaler oder nicht-digitaler Form, stellt eine zunehmende Herausforde-rung dar. Bibliotheken übernehmen diese Verantwortung und gehen der Verpflich-tung der Sammlung und Bereitstellung aller Publikationen nach, um Benutzern eine Zugänglichkeit zum enthaltenen Wissen zu gewähren. Die soziale Verantwortung der Bibliotheken liegt folglich in der breiten Streuung von Wissen, um Menschen Chan-cengleichheit und gesellschaftliche Integration zu garantieren. Der globalisierte Informationsaustausch ist bislang die wohl größte Herausforderung. Während im nicht-digitalen Zeitalter der Fokus auf die lokal vorhandenen Bestände gerichtet war, ist er im digitalen Zeitalter auf die Vernetzung aller Bestände weltweit ausgelegt, was eine maximal mögliche Breite an Wissensstreuung bedeutet. Die Zu-sammenführung weltweit existierender Bestände in einem gemeinsamen Katalog wird die dezentralen Suchvorgänge durch Benutzer auf eine einzige Suchanfrage reduzieren und Trefferlisten von bisher nicht vorstellbarem Ausmaß liefern.

1.2 Zielstellung Diese Arbeit widmet sich der Untersuchung von digitalen Publikationsprozessen in Bibliotheksumgebungen, um einerseits der Globalisierung beim Wissensaustausch und andererseits der Zugänglichkeitsgewährung zu diesem Wissen für alle Men-schen gerecht zu werden. Die Vernetzung von Bibliotheken in der gesamten Welt gestattet einen Zugriff auf Katalogisate von enormem Ausmaß. Ziel dieser Arbeit ist es, Lösungen für den adä-quaten Informationsaustausch auf Basis von Metadaten zwischen digitalen Bibliothe-ken vorzustellen. Aufbauend auf diesem Austausch werden Betrachtungen zur Erschaffung eines globalen Kataloges vorgenommen. Der Katalog soll dabei eine innere Organisation aufweisen, die es Benutzern erlaubt, die Katalogeinträge intuitiv und strukturiert zu explorieren. Die Garantie des Wissensbezugs durch alle Menschen stellt ein weiteres zentrales Anliegen dieser Arbeit dar, da es Menschen mit besonderen Bedürfnissen häufig nicht möglich ist, Informationen im selben Maße wie andere Menschen zu erschlie-ßen. Aufkommende besondere Nutzungsbedürfnisse von Menschen können durch Umgebungsgegebenheiten sowie physisch oder psychische Einschränkungen her-vorgerufen werden. Ein Gerechtwerden der Bedürfnisse kann nur durch die Barriere-freiheit der Publikationen und der distribuierenden Prozesse erreicht werden.

Copyright TU Dresden, Alexander Haffner 1


1.3 Inhaltlicher Aufbau Die Arbeit geht vom Ist-Stand der Katalogisierung in Bibliotheken und vom korres-pondierenden Metadateneinsatz für die Archivierung und den Austausch von Katalo-gisaten aus. Neben einer Einführung zur Begrifflichkeit Metadaten, wird eine Metadatenkategorisierung vorgestellt, anhand derer eine Diskussion etablierter Me-tadatenstandards geführt wird. Weiterführend wird im Kapitel 3 auf Basis von Modellen das Wirken in einer digitalen Bibliothek, zwischen digitalen Bibliotheken untereinander und zu externen Mitwirken-den prinzipiell verdeutlicht. Im Fokus der Betrachtungen steht neben der Einpflege, Archivierung und Verteilung von Ressourcen in einem Archivierungssystem insbe-sondere der komplexe Ressourcen- und Metadatenaustausch zwischen Systemen. Im Rahmen der Anforderungserhebung wird erläutert, was Barrierefreiheit in einer digitalen Bibliotheksumgebung für die Zugangsgewährung durch Benutzer mit be-sonderen Bedürfnissen bedeutet und wie Barrierefreiheit in exemplarisch ausgewähl-ten digitalen Publikationsformen bei der Ressourcenproduktion erreicht werden kann. Nachfolgend werden im Rahmen der Analyse aufgedeckte Prozessabläufe ausge-wählter Bibliotheken (Deutsche Nationalbibliothek, Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden, Deutsche Zentralbücherei für Blinde zu Leipzig) detailliert vorgestellt, um im weiteren Verlauf einen gemeinsamen optimier-ten Prozess zu modellieren. In Kapitel 5 wird auf standardisierte Metadatenformate zur Auszeichnung von Barrie-refreiheit eingegangen, um diese im Weiteren mit dem Entitätskonzept aus RDA und dem FRBR Model zu vereinen. Zusätzlich wird ein Strukturierungsansatz für Res-sourcen innerhalb der Manifestation eingeführt, in dem Struktureinheiten Accessibili-ty-Metadaten zugewiesen werden. Abschließend wird eine mögliche Serialisierungsform dieser Metadaten für den Austausch zwischen Bibliothekssyste-men diskutiert. Das Kapitel 6 beschäftigt sich mit der Modellierung eines erweiterten Prozessmodells in Hinblick auf einen globalen Katalog. Hierfür wird eine international abgestimmte Katalogisierung und Metadatenanreicherung sowie Archivierung diskutiert. Weiter-führend werden Betrachtungen zur regelkonformen Ressourcenproduktion und Ein-pflege sowie Zugänglichkeitsgewährung zu diesen Ressourcen im Archivierungs-system vorgenommen. Außerdem wird ein Ansatz zur kollaborativen Accessibility im Kontext der digitalen Bibliothek vorgestellt. Des Weiteren wurde eine webbasierte Anwendung für die Einpflege von Digital Tal-king Books konzipiert und prototypisch implementiert, die insbesondere die organisa-torische Abstimmung beim Metadatenaustausch im deutschen Blindenbibliotheks-wesen im Fokus der Entwicklung hat. Abschließend wird vor den eigentlichen Schlussbetrachtungen zum Erreichten und zu offenen Aspekten dieser Arbeit ein Präsentationskonzept für Katalogisate im glo-balen Katalog erläutert, welches Benutzern aus verschiedenen Sprachräumen und mit unterschiedlichsten Bedürfnissen ermöglichen soll, Publikationen in einer ihnen zugänglichen Form optimiert im Katalog finden und beziehen zu können.



1.4 Danksagung Resümierend darf ich sagen, dass es mir eine Freude ist, die entstandene Diplomar-beit in der vorliegenden Form präsentieren zu dürfen. In diesem Zusammenhang gilt mein Dank für die Ermöglichung der fachübergreifen-den Themenbearbeitung Prof. Weber als betreuenden Hochschullehrer. Außerdem möchte ich meinen besonderen Dank Frau Frodl als Fachbetreuerin aussprechen, die mir nicht nur die Verständniswelt zu Bibliotheksumgebungen geöffnet hat, son-dern immer für die Beantwortung meiner Fragen und die Diskussionen meiner ent-standenen Ergebnisse Zeit fand. Die vorliegenden Resultate wären jedoch ohne das entgegenkommende Mitwirken des Personals der DNB, der SLUB und der DZB nicht zu erreichen gewesen. Daher auch explizit mein Dank an alle Mitarbeiter, die mir in Interviews Rede und Antwort boten. Außerdem soll an dieser Stelle mein Dank gegenüber Prof. Wünschmann zum Aus-druck gebracht werden, der mein Interesse für die Thematik der Barrierefreiheit weckte und mein Wissen in den Jahren der Zusammenarbeit entscheidend prägte. Eine solche Arbeit, wie die hier vorliegende, ist zwar thematisch selbstständig zu be-wältigen, jedoch nicht orthografisch und grammatikalisch. Entsprechend ein beson-ders großer Dank für die durch die Korrekturleser(-innen) Bianca Daniel, Sarah Esmaeili und Wolfram Eberius aufgebrachte Zeit. Mein herzlichster Dank gilt jedoch meiner Familie, welche mich nicht nur während meiner Studienzeit, sondern in meinem gesamten Leben unterstützte und mir einen Anlaufpunkt für Anliegen sämtlicher Lebenslagen bot und immer bieten wird.


Metadatenanreicherung im digitalen Publikationsprozess Metadaten

2 Metadaten Neben den klassischen gedruckten Publikationen halten elektronische Medien einen immer größeren Einzug in unsere Gesellschaft. Die damit entstehende Informations-flut muss für den Endnutzer genauso wie für den Archivar in einer für ihn verständli-chen Form zugänglich gemacht werden. In diesem Zusammenhang gilt es, verlässliches Finden zu ermöglichen, zu unter-scheiden, was verschieden ist, zusammenzuführen, was zusammengehört, gefunde-nes überschaubar darzustellen und gewähltes zugänglich zu machen [EVE07]. Nach einer Klärung des Begriffes Metadaten wird ausgehend von der Rolle der Bib-liothek und deren Regelwerken für die Archivierung das Existieren der Metadatenar-ten diskutiert, um anschließend Metadatenstandards aus verschiedensten Domänen vorzustellen.

2.1 Was sind Metadaten? Die Begrifflichkeit „meta“ stammt ursprünglich aus dem Griechischen und ist ein Wortbildungselement mit der Bedeutung "zwischen, nach, hinter" bzw. zum Ausdruck eines Wechsels (z. B. metaphysisch, Metamorphose, metonymisch, methodisch) [KLU99]. In der Informatik verwendet man „meta“ im Allgemeinen synonym zum englischen Wort „about“. Beispielsweise ist eine Metalanguage eine Sprache zur Beschreibung einer anderen Sprache. Folglich sind, Metadaten Daten zur Beschreibung anderer Daten [CAP03]. Metadata (aus dem Engl.) wird in der heutigen Bibliotheksumgebung in zwei ver-schiedenen Bedeutungen genutzt. Einige Vertreter sehen Metadaten für die Be-schreibung von digitalen und nicht-digitalen Ressourcen vor. Andere Vertreter hingegen (beispielsweise die International Federation of Library Associations and Institutions) nutzen Metadaten ausschließlich für die Beschreibung digitaler Ressour-cen. Die erstgenannte Ausführung ist allerdings näher an der tatsächlichen Verwen-dungsform. In vielen Bibliotheksbeständen werden Metadaten genauso für die Beschreibung von gedruckten und analogen Werken sowie für digitale Publikationen verwendet. Auch ist es ein Trugschluss, dass Metadaten selbst immer in digitaler Form vorliegen müssen. Eine Karteikarte oder ein Katalog enthalten ebenfalls Daten über Daten, jedoch etablierte sich der Begriff Metadaten erst im digitalen Zeitalter. In der Vergangenheit sprach man von Katalogisierung und definierte keine Obermenge für die eingesetzten Techniken. In den beiden letzten Dekaden hat sich der Trend zur Digitalisierung von Metadaten mit all seinen Vorzügen in Bibliotheken und anderen Domänen jedoch weit verbreitet. Es ist gleich wie die Begrifflichkeit eingesetzt wird, zwei Dinge sind jeweils identisch:

1. Es müssen strukturierte Informationen sein, die für die Erbringung eines Mehrwertes in einem Metadatenschema festgehalten sein müssen, und

2. Metadaten müssen eine Informationsressource beschreiben. Die dafür eingesetzten Metadaten sollten dabei möglichst standardisiert sein, um ei-nen interoperablen Austausch zwischen Parteien zu ermöglichen.



2.2 Die Rolle der Bibliothek Eine Bibliothek ist ein Dienstleister, der unter anderem für die Beschaffung, Erschlie-ßung, Sammlung und Bereitstellung von Publikationen verantwortlich ist. Wenn man den Begriff der Beschaffung betrachtet, wird auf den ersten Blick der ur-sprüngliche Charakter deutlich. Bibliotheken kaufen Bücher, Zeitschriften etc. auf bzw. tauschen diese untereinander, um ein breites Angebot an Materialien für ihre Sammlung und Ausleihe zur Verfügung zu stellen. Mittlerweile existiert im Bereich der Beschaffung auch der Meldecharakter Dritter. Hierzu gehört die Abgabe von Pflichtexemplaren an eine Bibliothek. Pflichtexemplare können in physischer und/oder digitaler Form abgegeben werden. Eine weitere Erneuerung der Beschaf-fung ist durch den initiierenden Rollenwechsel zu sehen. Insbesondere Autoren, die nicht zur Meldung ihrer Publikationen verpflichtet sind, möchten ihre Ressourcen trotzdem über eine Bibliothek auffindbar machen. Dem Autor bietet sich somit die Möglichkeit, seine Publikation im Katalog der Bibliothek anzumelden und die zugehö-rige Ressource gemäß Prinzipien der Langzeitarchivierung aufbewahren zu lassen. Die Sammlung (im Folgenden auch als Archivierung bezeichnet) beinhaltet die Si-cherung der Publikationen über eine „lange Zeit“. Laut [BOR06] umfasst Langzeitar-chivierung für digitale Publikationen mindestens einen Zeitraum von 50 Jahren. Dagegen sind eine Vielzahl von nicht-digitalen Publikationen schon seit hunderten und teilweise sogar tausenden von Jahren archiviert. Die Archivierung selbst bedarf eines Managements, um die Ressourcen nicht nur wiederfinden zu können, sondern sie auch einer systematischen Ablage zu unterziehen. Dieses Management wird in Bibliotheken anhand der Katalogisierung umgesetzt. Die Erschließung erfasst die relevanten Daten über eine Publikation in Katalogen. Die Katalogisierung entwickelte sich vom Zettelkatalog nach der alphabetischen Ka-talogisierung hin zu erweiterten systematischen Katalogen. Die Formalerschließung erhebt dabei die bibliografischen Angaben wie Titel, Autor, Erscheinungsjahr etc. Die Sacherschließung nimmt die inhaltlichen Angaben auf, die einen thematischen Zu-griff und die Einordnung in eine entsprechende Systematik erlauben. Hierfür kann neben der Kategorisierung eine Vergabe von Schlagworten stattfinden. Diese sind normierte Begriffe, die nach bestimmten Regeln angelegt und vergeben werden (vgl. Kapitel 2.2.2.2). Des Weiteren gibt ein Katalog an, wo eine Publikation in der Biblio-thek zu finden ist. Im Bibliothekswesen gebräuchliche Katalogformen wurden in den letzten Jahren fast vollständig in elektronische datenbankgestützte Systeme wie den OPAC (Online Public Access Catalogue) überführt. Die Zugänglichkeitsgewährung wird somit durch die im Katalog befindlichen Informa-tionen über darauf aufbauende Suchmechanismen realisiert. Wenn die gewünschte Publikation einmal gefunden wurde, kann das gedruckte Exemplar in der Bibliothek aus dem Leihbestand durch den Benutzer für eine bestimmte Frist entliehen werden oder als Präsenzbestand nur in den Räumen der Bibliothek eingesehen werden. Eine weitere verbreitete Praxis zur Bereitstellung ist die Fernleihe, wobei dem Nutzer ein Exemplar zugesendet wird. Digitale Publikationen können für den Bezug auch im Internet bereitstehen. Dadurch kann neben den aufgeführten Methoden auch eine Distribution über Downloadmechanismen angeboten werden. Hierfür sind selbstver-ständlich die entsprechenden Urheberrechte durch den Leser zu beachten.



2.2.1 Was braucht ein Katalog? Was tatsächlich in einen guten und vor allem in der Zukunft nutzbaren Katalog ge-hört, ist für die Erfüllung der in dieser Arbeit gestellten Aufgaben essentiell. Dieser Abschnitt verdeutlicht die Notwendigkeit des Einsatzes der nachfolgend vorgestellten Metadatenstandards. Was braucht ein Katalog? Bernhard Eversberg ist in seinem Vortrag „Zur Zukunft der Katalogisierung“ [EVE04] unter anderem genau dieser Frage nachgegangen. Ein guter Katalog muss normiert sein. [EVE04] setzt hierfür vier Arten von Normen für die Gestaltung eines Kataloges an.

1. Begriffe: Die einheitliche Verwendung von grundlegenden Begrifflichkeiten im Bibliotheks- und Katalogisierungswesen. Die Definition dieser Begrifflichkeiten wurde einerseits in den Regeln für die alphabetische Katalogisierung (RAK) für den deutschen Sprachgebrauch und in den Anglo-American Cataloguing Rules (AACR) für den englischen Sprachgebrauch umgesetzt.

2. Datenstruktur: Durch eine geeignete Datenstruktur sind die Inhalte des Kata-loges systematisierbar und maschinell verarbeitbar. Eine Datenstruktur dieser Art ermöglicht nicht nur das Suchen im Katalog, sondern auch den Austausch der Inhalte zwischen Katalogisierern bzw. die Anreicherung des Kataloges durch Dritte.

3. Inhalt: Die Erschließung der formalen und inhaltsbezogenen Informationen ist das Herz eines jeden Kataloges. Um diese Informationen in einer einheitlichen Form in jeder Bibliothek aufzunehmen, wurden die RAK und die AACR er-schaffen. Durch diese Regelwerke wird es einem Bibliothekar ermöglicht, die Inhalte konformitätsgetreu zu erheben.

4. Werte: Um die soeben angesprochene Konformität zu erhöhen, bedarf es des Einsatzes von Normdaten. Normdaten umfassen die Wiederverwendung von bereits erschlossenen Inhalten. Normdaten werden durch die Bibliotheken in gemeinsam genutzten Dateien wie der Gemeinsamen Körperschaftsdatei (GKD), der Personennamendatei (PND) und der Schlagwortnormdatei (SWD) gehalten.

Eine weitere interessante Forderung von Eversberg ist eine Norm für die Darstellung der Informationen für den Benutzer im Online-Katalog. Die Norm müsste Begrifflich-keiten sowie Vorschriften für die Präsentation und die Exploration umfassen. Auch sollten normierte Abfragesprachen in den Systemen verwendet werden. Man sieht bei näherer Betrachtung, dass alle Normen dazu dienen, Informationen über die Publikation abzudecken, was darauf hinweist, dass diese Informationen be-reits in den Bereich der Metadaten fallen.

2.2.2 Herkömmliche Regelwerke für die Katalogisierung

2.2.2.1 Regeln für die alphabetische Katalogisierung (RAK) Die Regeln für die alphabetische Katalogisierung (RAK) haben seit Mitte der 70er Jahre zunehmend zu einer Vereinheitlichung der Formalkatalogisierung im deutsch-sprachigen Raum geführt. Insbesondere bei der Einführung von elektronischer Da-tenverarbeitung für die Katalogisierung haben sich Bibliotheken und Bibliotheksverbünde auf die RAK umgestellt [RAK02]. Grundlage war eine Harmoni-sierung der angewandten Regeln der BRD, der DDR und Österreichs.



Das Regelwerk der RAK lässt sich in verschiedene Varianten aufgliedern: RAK-ÖB: für Öffentliche Bibliotheken RAK-WB: für Wissenschaftliche Bibliotheken verschiedene Zusatzregeln, beispielsweise für Musikalien, Karten etc.

Die Regeln für die alphabetische Katalogisierung in wissenschaftlichen Bibliotheken (RAK-WB) sind beispielsweise in neun Hauptabschnitte gegliedert:

1. Grundbegriffe (§ 1 - 36) 2. Allgemeine Regeln (§ 101 - 193): Bestimmen die Aufgaben des Katalogs, Ein-

tragungsarten für Einheitsaufnahme und äußere Form. 3. Allgemeine Ansetzungsregeln (§ 201 - 208): Für die Ordnung der Eintragun-

gen müssen Sachtitel, Personen- und Körperschaftsnamen in die Form von Ordnungsblöcken gebracht werden. Die Bildung dieser Formen nennt man Ansetzung [RAK02]. Die im Abschnitt 9 vorgeschriebene Ordnung nach der gegebenen (mechanischen) Wortfolge erfordert detaillierte Regeln für die Schreibung und Abgrenzung einzelner Wörter als Ordnungswörter.

4. Ansetzung der Namen von Personen (§ 301 - 342): Grundregeln für die Aus-wahl des anzusetzenden Namens bzw. der anzusetzenden Namensform so-wie Regeln für die Ansetzung moderner und persönlicher Namen, um internationale Konsistenz zu erreichen.

5. Ansetzung der Namen von Körperschaften (§ 401 - 486): Vorschriften für die Namensgebung und Ordnung mit Sonderregeln für untergeordnete, Gebiets-körperschaften, für Religionsgemeinschaften und für Kongresse, Ausstellun-gen, Messen, Festwochen und dergleichen.

6. Ansetzung von Sachtiteln und Bestimmung des Einheitssachtitels (§ 501 - 525): Stellt die Ergänzung der allgemeinen Ansetzungsregeln für Sachtitel dar, wobei beispielsweise einleitende Wendungen, im Sachtitel enthaltene Namen von Urhebern und Alternativsachtitel (für übersetzte Ausgaben Sprachbe-zeichnung) angesetzt werden müssen. Auch werden Regeln für die Benen-nung fortlaufender Sammelwerke und Sammlungsvermerke getroffen. Bei der Findung eines Einheitssachtitels muss auf den Originalsachtitel, die am häu-figsten vorkommende bzw. in der wissenschaftlichen Tradition gebräuchliche Fassung oder auf den Formalsachtitel zurückgegriffen werden.

7. Haupt- und Nebeneintragungen unter Personen, Körperschaften und Sachti-teln (§ 601 - 696): Es wird bestimmt, welche Personen in bestimmten Fällen als Verfasser bzw. sonstige beteiligte Personen gelten, und unter wem Haupt- bzw. Nebeneintragungen vorzunehmen sind, sowie die Behandlung anonymer Werke. Außerdem wird bestimmt, was Körperschaften im Sinne der Regeln sind, wann sie als Urheber bzw. sonstige beteiligte Körperschaften gelten und unter welcher Haupt- bzw. Nebeneintragungen vorzunehmen sind. Zusätzlich werden Regeln für die Ansetzung bei fortlaufenden Sammelwerken definiert.

8. Bestimmung des Sachtitels oder des Titels für Haupt- und Nebeneintragungen (§ 701 - 715): Legt fest, welcher von gegebenenfalls mehreren vorhandenen Sachtiteln bzw. Titeln für die jeweils vorgeschriebene Eintragung verwendet werden soll.

9. Ordnung der Eintragungen (§ 801 - 823): Personennamen, Körperschaftsna-men und Sachtitel können alphabetisch geordnet werden. Als Ordnungsele-



mente werden die 26 Buchstaben des deutschen Alphabets und Zahlzeichen verwendet. Ein oder mehrere Buchstaben bilden ein Ordnungswort, ein oder mehrere Zahlzeichen bilden eine zu ordnende Zahl. Eine Ordnungsgruppe besteht aus einem oder mehreren Ordnungswörtern und/oder einer oder meh-reren zu ordnenden Zahlen. Ordnungshilfen sind Zusätze zur Unterscheidung übereinstimmender Ordnungsgruppen. Ein Ordnungsblock besteht aus einer oder mehreren Ordnungsgruppen einschließlich der zu ihnen gehörenden Ordnungshilfen und dient immer der primären Eintragungseinordnung.

Die Regeln werden dabei nach Grundregeln und Sonderregeln unterschieden. Son-derregeln ersetzen bzw. ergänzen die Grundregeln zum Teil. Die Bestimmungen für die Festlegung der Haupteintragungen und die Regeln für de-ren Ansetzung sind für alle Anwender der RAK-WB verbindlich. Die RAK umfasst ein feingranulares Regelwerk für die einheitliche Aufnahme von Publikationen. Allerdings stellt sie nur bedingt bis gar nicht die Struktur für die aufge-nommenen Daten bereit.

2.2.2.2 Regeln für den Schlagwortkatalog (RSWK) Der Schlagwortkatalog ist ein Bibliothekskatalog, der die Publikationen nach Schlag-wörtern verzeichnet und so die punktuelle thematische Suche nach Literatur erlaubt. Unter einem Schlagwort wird dabei ein natürlich sprachlicher Ausdruck verstanden, der den Inhalt der Publikation möglichst kurz, aber präzise wiedergibt. Komplexe In-halte können durch eine Schlagwortkette, eine Kombination mehrerer Einzelschlag-wörter, beschrieben werden. Die Regeln für den Schlagwortkatalog (RSWK) sind das Regelwerk für die verbale Sacherschließung. Grundlage ist nicht nur das Regelwerk, sondern das in der An-wendungspraxis gleich wichtige Verzeichnis der Schlagwörter, die zur Beschlagwor-tung zur Verfügung stehen, die Schlagwortnormdatei (SWD).

Die RSWK sind ein Regelwerk für die intellektuelle Beschlagwortung. Aus-schlaggebend ist der Inhalt eines Werkes, nicht die Titelformulierung. [UML07]

Die 1998 erschienene 3. Auflage der RSWK orientiert sich im Gegensatz zu ihren Vorgängern an den Bedürfnissen der Online-Kataloge. Die Ergänzungslieferungen (2000, 2002, 2005, 2007) haben diesem Prinzip weiter Rechnung getragen und sind gekennzeichnet durch ihr Bemühen, die Regeln zu vereinfachen und sie so auch über den traditionellen bibliothekarischen Bereich hinaus nutzbar zu machen [RSWK07]. Eine besondere Rolle nimmt dabei die SWD ein. Die über die Jahre erfolgten Ände-rungen der RSWK haben die SWD aus ihrer ursprünglichen Umgebung gelöst und sie zu einer Dokumentationssprache gemacht, die als Universalthesaurus nun auch außerhalb der bibliothekarischen Welt genutzt wird. Die Schaffung der SWD mit sei-nen kontrollierten Termini ermöglicht eine effektive Übernahme von Fremddaten in der heterogenen Informationsgesellschaft. Die SWD, die in der Praxis von Anfang an großes Gewicht hatte, steht jetzt im Mittelpunkt des Regelwerks. Trotzdem hat die Schlagwortkette als deskriptives Element in der Aufbereitung von Retrievalergebnis-sen weiterhin Bedeutung [RSWK07]. Bei der Entwicklung der RSWK war die Annäherung an die RAK ein zentrales Ziel. Die Betrachtungen zu Körperschaften mussten in diesem Zusammenhang jedoch zurückgestellt werden, da diese bislang nicht entscheidungsreif sind.



Die inhaltlich tiefgründigere Betrachtung des Regelwerkes würde den Rahmen dieser Arbeit überschreiten. Der Leser wird auf [RSWK07] und [UML07] für eine weiterfüh-rende Recherche verwiesen.

2.2.2.3 Anglo-American Cataloguing Rules (AACR) Im angloamerikanischen Raum werden seit 1967 die Anglo-American Cataloguing Rules (AACR) für die Katalogisierung verwendet. Die zweite Ausgabe (AACR2) stammt aus dem Jahr 1978, die jüngste Revision erfolgte 2002 (AACR2r) sowie das finale Update 2005. AACR2 ist das weltweit am weitesten verbreitete Regelwerk für die Katalogisierung. Es umfasst dabei Regeln für die Formalerschließung sowie teil-weise für die Sacherschließung. Dabei ist die Sacherschließung vorrangig dem Sub-ject Cataloging Manual der Library of Congress (Schlagwörter für Personen, Körperschaften etc.) zu entnehmen. Die Sacherschließung der Werke werden nach den AACR2 angesetzt [HEN06]. Die AACR2 wurden von über 30 verschiedenen Ländern uneingeschränkt übernommen. Herausgeber der AACR sind die American Library Association, die Canadian Library Association und das Chartered Institute of Library and Information Professionals. Da sich diese Arbeit vorrangig auf den deutschsprachigen Raum konzentriert, sei der Leser für weitere Ausführungen auf [AACR08] verwiesen.

2.2.3 Resource Description and Access (RDA) Für die internationale Harmonisierung der Erschließung und damit für weltweite Inte-roperabilität wurde der Ruf nach AACR3 laut, um auch der Beschreibung digitaler Ressourcen besser gerecht werden zu können. Allerdings stellte sich während der Entwicklung heraus, dass dafür der Inhalt wie die Struktur des Regelwerks radikal geändert werden mussten. Resource Description and Access (RDA) wird in Zukunft exakt diese Rolle einnehmen. Im November 2008 wurde der vollständige Entwurf für RDA [RDA08] publiziert. Im Moment sind potentielle Anwender des Regelwerkes da-zu aufgerufen, den Entwurf zu begutachten, woraufhin sich eine Überarbeitung durch das Joint Steering Committee anschließen wird. Die finale Veröffentlichung des Standards ist für das dritte Quartal 2009 angekündigt. Die auf Basis von RDA angesetzten Daten zielen darauf ab, Ressourcen für Endnut-zer besser auffindbar zu machen. Diesbezüglich kann man vier grundlegende Aufga-ben spezifizieren, bei denen die Nutzer explizit unterstützt werden sollen.

• das Finden (find) von Ressourcen entsprechend spezifizierten Suchkriterien, • das Identifizieren (identify) einer Ressource bzw. das Unterscheiden von Res-

sourcen mit ähnlichen Eigenschaften in Bezug zur vorgenommenen Suche, • die Auswahl (select) einer Ressource, die sich mit den Nutzerbedürfnissen

deckt und • der Bezug (obtain) der durch den Nutzer beschriebenen Ressource.

RDA soll in der gegenwärtigen Archivierungslandschaft für die konsistente Ressour-cenbeschreibung benutzt werden. Das Regelwerk beinhaltet eine optimierte Ausrich-tung auf digitale wie auch nicht-digitale Ressourcen, was somit alle Arten von Inhalt und Medien in beliebigen Archiven umfasst. Als Zielgruppen für die Regelwerksnut-zung werden auch Anwender außerhalb der Bibliothekswelt gesehen. Außerdem ist eine multilinguale Abdeckung im Fokus der Verbreitung. Eine Kompatibilität zu international etablierten Prinzipien, Modellen und Standards stellte ein Grundbedürfnis des Joint Steering Committee bei der Entwicklung von



RDA dar. So wurde eine Ausrichtung der Strukturen, der Konzepte und Terminologie am Functional Requirements for Bibliographic Records (FRBR) Model [FRBR98] und dem Functional Requirements for Authority Data (FRAD) Model [FRAD07] vorge-nommen. Die konzeptionellen Modelle sollen neben den domänbeheimateten Akteu-ren auch domainfremden Akteuren ein Verständnis für die Katalogisierung bieten. Außerdem wurden die International Standard Bibliographic Description (ISBD), das MARC 21 Format for Bibliographic Data und das MARC 21 Format for Authority Data in die Entwicklung von RDA mit einbezogen. Der RDA-Standard ist zwar unabhängig von einer bestimmten Struktur zur Datenspeicherung oder Datendarstellung, beinhal-tet jedoch Mappings des RDA Element Sets zu Metadaten in ISBD, MARC 21 und Dublin Core. RDA ist ebenfalls kompatibel zu dem primär kommerziell eingesetzten Metadatenstandard ONIX. Detailinfomationen zu den Formaten befinden sich im Ab-schnitt 2.4 dieser Arbeit. Den Entwicklern von RDA war es des Weiteren wichtig, dass eine kosteneffiziente Integration in existierende Systeme durch einen minimalen Anpassungsaufwand realisierbar ist. Das FRBR Model benennt als ein bibliothekswissenschaftliches Datenmodell unab-hängig von einem Regelwerk oder einer bestimmten Anwendung Beziehungen zwi-schen Entitäten, welche in das RDA Element Set aufgenommen wurden. Man unterscheidet im Modell nach drei Gruppen von Entitäten, wobei die Entitäten der Gruppe 1 im logischen Modell in vier Ebenen untergliedert sind.

• Gruppe 1: Produkte intellektueller bzw. künstlerischer Anstrengungen o Werk: eine abgeschlossene, selbstständige geistige oder künstlerische

Schöpfung, wobei noch kein entsprechender materieller Gegenstand existiert

o Expression: die geistige oder künstlerische Realisierung eines Werkes, wobei die wesentliche Eigenschaft die Form (schriftlich, auditiv, visuell etc.) ist

o Manifestation: die physische Umsetzung des Werks, somit die konkrete Ausgabe, die in einem bestimmten Verlag als Druckversion oder als elektronische Ressource erschienen ist

o Item: das einzelne Exemplar (einzelne Kopie) einer Manifestation • Gruppe 2: Verantwortliche für die unter Gruppe 1 genannten Entitäten: Perso-

nen, Familien und Körperschaften • Gruppe 3: Entitäten, die zur näheren Beschreibung der Entitäten aus Gruppe

1 und Gruppe 2 dienen: Begriff, Objekt, Ereignis, Ort. Zu jeder Entität können eine Menge von Attributen für deren Charakterisierung defi-niert werden. Attribute ermöglichen den Nutzern, ihre Anfragen bei der Suche nach Entitäten präzise zu formulieren und die Antwort zu interpretieren. Es existieren zwei Kategorien von Attributen:

• inherent in an entity (direkt von der Entität abzuleiten/abzulesen) • externally imputed (über Referenz zu einer externen Quelle)

Zwischen allen Entitäten bestehen Beziehungen. Beispielsweise sind Beziehungen zwischen Verantwortlichen (Entitäten Gruppe 2) und Produkten intellektueller bzw. künstlerischer Anstrengungen (Entitäten der Gruppe 1) definiert. Ein Werk kann von einem oder mehreren Verantwortlichen erschaffen (created), eine Expression reali-siert (realized), eine Manifestation produziert (produced) und ein Item besessen (ow-ned) werden. Als primäre Beziehungen bezeichnet man die hierarchichen Zusammenhänge unter Entitäten der Gruppe 1. So ist ein Werk die eigentliche Erschaffung des Produktes



intellektueller bzw. künstlerischer Anstrengungen, eine Expression ist die Realisie-rung dieses Werkes, eine Manifestation die physische Verkörperung einer Expressi-on und ein Item ein spezifisches Exemplar einer Manifestation. Eine Manifestation bzw. ein Item werden in RDA als Ressourcen bezeichnet und prinzipiell ähnlich zum Vorgehen in AACR2 erschlossen. Die Comprehensive Desc-ription erlaubt eine Beschreibung aus einer globalen Sicht für verschiedenste Arten von Ressourcen wie Single-Unit-Ressourcen, Multi-Part-Unit-Ressourcen oder integ-rierte Ressourcen. Die Analytical Description ermöglicht die Beschreibung einzelner Teile einer Ressource, wie einer expliziten Ausgabe einer Serie, einem Artikel in ei-nem Journal oder einem Kapitel eines Buches. Falls die definierten Teile aus der Analytical Description wiederum in weitere Teile aufzugliedern sind, kann mit dem Ansatz der Hierarchical Description eine Baumstruktur zur Ressourcenbeschreibung auf Strukturebene erzeugt werden. Ein Werk und Expressionen sind somit abstrakte Oberklassen zu Manifestationen und Items, über die die Auffindung der Ressourcen für Endbenutzer erleichtert wer-den soll. Die Sacherschließung wird entsprechend auf den abstrakten Entitäten durchgeführt, um sie für die Ressourcen zu übernehmen. Die FRBR-Entitäten sollen als Sucheinstiege dienen, wofür allerdings eine eindeutige Benennung und Identifikation notwendig ist. Diese Eindeutigkeit wird über Normda-ten und definierte Access Points realisiert. Functional Requirements for Authority Data (FRAD) Model ist eine weitere Spezifika-tion der International Federation of Library Associations and Institutions (IFLA), wel-che von der Working Group on Functional Requirements and Numbering of Authority Records (FRANAR) entwickelt wurde und als Erweiterung der FRBR um Normdaten-kontrolle zu verstehen ist. Das Modell unterstützt die internationale Nutzung und Nachnutzung von Normdaten im Bibliothekssektor, wobei der Schwerpunkt auf die Unterstützung der Entitäten der Gruppen 1 und 2 von FRBR gelegt werden. Die Entitäten des FRBR Model sind im FRAD unter bestimmten Namen und/oder Identifikatoren bekannt, die als Basis für die Zugriffspunkte (Access Points) dienen. Über die Regeln in RDA wird die normgerechte Verwendung gesichert.

group 2

group 1group 3associated with

Identifier

Name Controlled

Access Point

Agency

Rules

assigned

known by

basis for

goverened by

created/ modified by

applied by

Abbildung 2.1: FRAD Model Aktuell werden bibliografische Datensätze und Normdatensätze verwendet, die zu-einander über Verlinkung in Beziehung stehen. In Zukunft erwartet man jedoch Da-tenbanksysteme, die die Struktur von FRBR und FRAD reflektieren. Das würde bedeuten, dass einzelne Einträge für jede FRBR-Entität existieren, die wiederum Copyright TU Dresden, Alexander Haffner 11


über ihre Access Points als persistente Identifikatoren verlinkt werden. RDA erlaubt die Beschreibung von Access Points zu fast allen Entitäten aus dem FRBR Model und dem FRAD Model und trägt somit den erwarteten Änderungen genüge. Außer-dem können Access Points zu den Entitätsbeziehungen definiert werden. Allerdings sind derzeit die Attribute und Beziehungen von Gruppe 3 Entitäten des FRAD Model nicht in RDA einbezogen worden. RDA ist in 10 Sektionen untergliedert. Die Sektionen 1-4 beschäftigen sich mit der Ansetzung von Attributen zu den Entitäten gemäß FRBR und FRAD und die Sektio-nen 5-10 decken die Beschreibung der Entitätsbeziehungen gemäß FRBR und FRAD ab.

• Section 1: Recording Attributes of Manifestation and Item • Section 2: Recording Attributes of Work and Expression • Section 3: Recording Attributes of Person, Family, and Corporate Body • Section 4: Recording Attributes of Concept, Object, Event, and Place • Section 5: Recording Primary Relationships between a Work, Expression,

Manifestation, and Item • Section 6: Recording Relationships to Persons, Families, and Corporate Bod-

ies Associated with a Resource • Section 7: Recording Subject Relationships • Section 8: Recording Relationships Between Works, Expressions, Manifesta-

tions, and Items • Section 9: Recording Relationships Between Persons, Families, and Corpo-

rate Bodies • Section 10: Recording Relationships between Concepts, Objects, Events, and

Places Die Gliederung ist nah an das praktische und zeitliche Vorgehen eines Bibliothekars bei der Ressourcenerschließung angelehnt. Das Regelwerk weist außerdem ein Mi-nimum an anzuwendenden Elementen, die sogenannten RDA Core Elements, aus. An dieser Stelle soll der Leser dieser Arbeit auf die Sektion 8 hingewiesen werden. Die Beziehungen unter Werken, Expressionen, Manifestationen und Items sind nicht Bestandteil des RDA Core Element Sets, jedoch im weiteren Verlauf dieser Arbeit essentiell. Es können Werke untereinander in Beziehung gesetzt werden. Dabei kann ein Werk beispielsweise eine Adaption eines anderen Werkes, ein Kommentar oder eine Ergänzung zu einem Werk sowie ein Teil eines größeren Werkes sein. Ei-ne zu einer anderen Expression in Beziehung stehende Expression kann zum Bei-spiel eine revidierte, erweiterte oder gekürzte Version sowie eine Übersetzung dieser sein. Eine Manifestation kann einer anderen Manifestation entsprechen, aber bei-spielsweise in einem anderen Format verkörpert bzw. die elektronische Reproduktion einer vorliegenden Manifestation sein. Ein spezielles Exemplar kann ebenfalls als Vorlage für die Überführung in ein anderes Item oder für eine andere Manifestation gedient haben. Derzeit wird an der Definition der RDA Element Vocabulary gearbeitet, um Beschrei-bungen zu Entitätscharakteristika und Entitätsbeziehungen standardisiert und ma-schinell lesbar auszudrücken. Für die Verbreitung der RDA Value Vocabularies im Semantic Web soll das Resource Description Framework [RDF04], RDF-Schema [RDFS04] und das Simple Knowledge Organisation System (SKOS) genutzt werden. SKOS ist eine formale Sprache zur Kodierung von Dokumentationssprachen wie Thesauri, Klassifikationen oder anderem kontrollierten Vokabular.



Der Anhang der RDA weist zusätzlich Informationen zu Großschreibung, Abkürzun-gen, kontrolliertem Vokabular etc. aus. Außerdem wird auf die Syntax bei Verwen-dung von Metadatenstandards eingegangen. Mit RDA könnte es sogar gelingen, die in Deutschland personaltechnisch getrennte Formal- und Sacherschließung in eine Hand zu bringen. In den Vereinigten Staaten wird dieses Prinzip von Bibliothekaren bereits erfolgreich praktiziert.

2.3 Arten von Metadaten Metadaten können nach der NISO-Definition prinzipiell in die drei Hauptkategorien „Deskriptive Metadaten“, „Struktur-Metadaten“ und „Administrative Metadaten“ unter-teilt werden. „Rechte-Management-Metadaten“ und „Metadaten zur Langzeitarchivie-rung“ werden hierbei als Untergruppe der administrativen Metadaten gesehen. [CAP03] differenziert die administrativen Metadaten weiterhin und definiert eine Gruppe der „Technischen Metadaten“. Ein Aspekt, der bei dieser Definition noch nicht betrachtet wird, ist der kommerzielle Hintergrund der Distribution von digitalen Publikationen. Daher soll in der Kategorisierung für diese Arbeit der nach [FRO08] gewählte Ansatz verfolgt werden, in dem „Marketing- oder handelsspezifische Meta-daten“ als zusätzliche Kategorie in die Betrachtung mit einfließen. Eine in sämtlichen Kategorisierungen vernachlässigte Thematik ist die Einbeziehung von „Accessibility-Metadaten“ zur Ausweisung der Barrierefreiheit von Ressourcen.

1. Deskriptive Metadaten: Dienen der Auffindung, Identifikation und Auswahl von Ressourcen. Außerdem können sie für die Kollokation von Ressourcen für die Zusammenstellung mehrerer Versionen oder die Erfassung von Kopien ver-wendet werden. Das bedeutet, dass deskriptive Metadaten die Beziehungen der Entitäten nach dem FRBR Model beschreiben werden. Zusätzlich können deskriptive Metadaten Aussagen beispielsweise zur Evaluation und Ge-brauchstauglichkeit der Ressource bereitstellen. Die Verbindung zu anderen Ressourcen (Linkage) ermöglicht trotz der Plastizität der Publikation die Ver-linkung zu weiterführenden, zitierten oder ähnlichen Ressourcen.

2. Struktur-Metadaten: Geben Auskunft über die Logik und innere Struktur einer Ressource. Struktur-Metadaten halten die Beziehung beispielsweise zwischen Dateien und Seiten, zwischen Seiten und Kapiteln und zwischen Kapiteln und einem Buch als Ganzen. Die Informationen werden einerseits für die Archivie-rung im Archivierungssystem und andererseits für die Präsentation der Res-source benötigt. Struktur-Metadaten haben insbesondere eine hohe Bedeutung für Ressourcen, die aus einem File-Bundle (Aggregation) beste-hen. Die Zughörigkeitsausweisung und Anordnung von Dateien einer Aggre-gation entspricht der primären Verwendungsweise von Struktur-Metadaten in der Praxis.

3. Administrative Metadaten: Sollen das Management und die Aufbewahrung von Ressourcen im Archivierungssystem erleichtern. Hierfür werden Informa-tionen über die Erstellung und Speicherung der Dateien sowie Metadaten über deren Quelle und Herkunft zur Verfügung gestellt. Des Weiteren wird ein Ver-antwortlicher für die Ressource ausgewiesen. Auch Rechte für die (organisati-ons-)interne Verarbeitung und selbstverständlich eine Protokollierung dieser können integriert werden.

4. Technische Metadaten: Dokumentieren die zur Ressource gehörenden Datei-en und ihre Charakteristika. Diese Angaben sind oft auf einem hoch detaillier-



ten Level, der nicht nur über das Format, sondern auch über den physikali-schen Aufbau in der Datei Aufschluss gibt. Technische Metadaten bilden die Voraussetzung für die Langzeitarchivierung.

5. Rechte-Management-Metadaten: Beinhalten die Historie der Verhandlungen vor der Einpflege des Dokumentes in das Archiv sowie alle Copyright-Angaben und Lizenzbedingungen für die Distribution. Außerdem wird fest-gehalten, welche Aktionen in Verbindung mit welchen Akteuren auf dem Do-kument ausgeführt werden dürfen (vgl. [PMDO01]).

6. Marketing- oder handelsspezifische Metadaten: Sollen die kommerzielle Dist-ribution von Ressourcen unterstützen. Hier sollten neben dem Preis und dem eigentlichen Vertreiber Informationen über die Vertriebsgeschichte gehalten werden. Auch bieten sich diese Metadaten für die Anreicherung von werbe-wirksamen Zusatzangaben an.

7. Metadaten zur Langzeitarchivierung: Knüpfen an dem Ansatz der technischen Metadaten an, jedoch ist neben den Formatinformationen auch die zugehörige Systemumgebung (User Agent, Betriebssystem etc.) relevant, um Ressourcen in ferner Zukunft (mindestens über 50 Jahre) zugänglich zu machen. Für die Langzeitarchivierung existieren nach [BOR06] zwei Ansätze, Emulation und Migration. Die genannten Metadaten dienen bei Emulationsbestrebungen der Entwicklung geeigneter Werkzeuge, wogegen bei der Migration neue Res-sourcen entstehen, deren Herkunft, Entstehungsgeschichte und technischer Wandel in den Metadaten zur Langzeitarchivierung dokumentiert werden.

8. Accessibility-Metadaten: Dienen der Spezifikation von Zugriffsmodalitäten zu Ressourcen sowie der Ausweisung bezüglich der Adaptierbarkeit (Anzeige-transformierbarkeit, Steuerungsflexibilität) für die Unterstützung aller Nutzer mit besonderen Bedürfnissen. Des Weiteren werden Accessibility-Metadaten genutzt, um äquivalente Alternativen zu einer primären Ressource in Bezie-hung zu setzen. Anhand der Charakteristika von alternativ angebotenen Res-sourcen kann es Endbenutzern garantiert werden ein für sie zugängliches Exemplar zu finden.

Die Beschreibung der einzelnen Kategorien zeigt, dass eine eindeutige Abgrenzung nur sehr schwer möglich ist. Metadatenkategorien hängen in ihrer Funktionsweise prinzipiell immer von anderen Kategorien ab. Die Zuordnung von spezifischen Funk-tionen ist häufig nicht genau einer Kategorie zuweisbar. Eine offene Frage in Bezug auf die aufgestellten Definitionen bleibt jedoch: Was ist eine Ressource? Der Wandel der Zeit hat definitiv auch den Begriff der Ressource einem Wandel unterzogen. Vom gedruckten Buch über eBooks bis hin zur multime-dialen Publikation mit einer Vielzahl von Dateien ist heutzutage alles auf dem Markt vertreten. Im Weiteren wird vom Autor folgende Einschränkung festgelegt: Wenn in dieser Ar-beit von einer Ressource gesprochen wird, handelt es sich im entsprechenden Kon-text um eine Manifestation oder einen Item gemäß FRBR Model und RDA, unabhängig davon, ob die Ressource eine Aggregation oder eine Einzelressource ist.



2.4 Metadatenstandards Da Prozesse in digitalen Bibliotheken automatisiert oder zumindest teilautomatisiert ablaufen, stellt sich die Frage nach maschinenlesbaren Datenstrukturen und damit auch die Frage nach Metadatenstandards sowie der Interoperabilität dieser Stan-dards. Metadatenstandards definieren die Formalisierung von Metadaten für die Archivie-rung in und den Austausch zwischen Organisationen. Das bedeutet, sie stellen das Grundgerüst (Framework) für die Daten bereit. Dabei unterscheidet man in der Praxis zwischen

1. Internformaten: Metadaten die innerhalb eines Systems für die Archivierung und Administration genutzt werden und

2. Austauschformaten: Dienen zur Unterstützung der Interoperabilität zwischen heterogenen Systemen.

Standards für interoperable Metadaten haben die Aufgabe, Metadaten aus unter-schiedlichen Quellen nutzbar zu machen. Sie umfassen dazu folgende Aspekte:

• Semantik: Beschreibt die Bedeutung, die in der Regel von Normierungsgre-mien festgelegt wird.

• Datenmodell: Festlegung der Struktur der Metadaten (Grammatik) o Daten: Sind die Informationen, die über eine Ressource hinterlegt wer-

den (vgl. [EVE04] Inhalte, Werte)

• Syntax: Dient dazu, die entsprechend dem Datenmodell generierten Aussa-gen zu repräsentieren (Beispiel für ein Repräsentationsformat ist XML).

Die Semantik wird durch Konstrukte des Datenmodells abgebildet. Das Datenmodell wird wiederum durch syntaktische Konstrukte repräsentiert. Die syntaktischen Kon-strukte werden schließlich aus Zeichen eines vereinbarten Zeichensatzes zusam-mengesetzt. Um Metadaten verschiedener Quellen sinnvoll verarbeiten zu können, muss weltweit eindeutig gekennzeichnet werden, um welche Semantik, welches Datenmodell und welche Syntax es sich handelt. Hierzu ist ein Identifikationsmechanismus erforder-lich, wie ihn z. B. die URIs (Uniform Resource Identifier) bereitstellen. Im Folgenden wird eine überblicksartige Vorstellung der für diese Arbeit relevanten Metadatenstandards vorgenommen. Für die eigentlich notwendige Verständniserlan-gung zu den einzelnen Metadatenformaten hat sich der Autor für die Integration ei-nes Metadatenstandardkompendiums im Anhang entschlossen. Im Anhang A sind für den Leser umfangreiche Ausführungen mit zugehörigen Referenzwerken für ei-nen vertiefenden Einblick ausgewiesen. Das Kompendium diskutiert des Weiteren wie und ob die einzelnen Metadatenstandards die vorgestellten Arten von Metadaten abdecken.

1. Maschinelles Austauschformat für Bibliotheken (MAB): Austauschformat im deutschsprachigen Raum, dessen Entwicklung eingefroren wurde und in den nächsten Jahren durch MARC 21 ersetzt wird.

2. MARC 21: Ist das aus dem anglo-amerikanischen Bibliothekswesen stam-mende und auch international abgestimmte Machine-Readable Cataloging (MARC) Format. Es existieren MARC 21 Formate für Bibliographic Data, Au-



thority Data, Classification Data, Community Information und Holdings Data. MARC 21 ist das weltweit am häufigsten eingesetzte Austauschformat zwi-schen Bibliotheken. MARC 21 zeichnet sich insbesondere durch die opti-mierte Feingranularität in Bezug auf bibliotheksrelevante Metadaten aus.

3. Metadata Object Description Schema (MODS) ist ein XML-basiertes Derivat von MARC, was sich als Austauschformat durch seine Einfachheit im Ver-gleich zu MARC 21 (sowie MARCXML) und der wiederum guten Abdeckung im Bereich von deskriptiven Metadaten für die Bibliotheksdomäne gegen-über Dublin-Core-Metadaten hervorhebt.

4. Dublin Core (DC): Umfasst Metadaten, die ihre Stärken in der Verwendung im Semantic Web besitzen. In Bibliotheken sind DC-Metadaten bislang vor-rangig für den Austausch mit Nicht-Bibliothekssystemen (z. B. Serviceprovi-dern gemäß OAI-PMH) im Einsatz. Durch die Einführung des RDA Element Sets könnte sich dies jedoch in den kommenden Jahren ändern.

5. Pica+/Pica3: Ist ein in Deutschland weit verbreitetes Internformat. Es zeich-net sich insbesondere durch seine hohe Feingranularität aus. Modellarisch und syntaktisch ist es dem MARC-Standard nahe. Pica+ und Pica3 werden u. a. im Online Public Access Catalogue (OPAC) eingesetzt.

6. Online Information eXchange (ONIX): Ist ein Metadatenformat zum Aus-tausch von bibliografischen Metadaten und Produktdaten zwischen Verla-gen, Buchhändlern, Bibliotheken, sowie weiteren involvierten Dienstleistern. ONIX zeichnet sich insbesondere durch die hoch auflösenden handelsspezi-fischen Metadaten aus, welche den Standard für die Beteiligten im kommer-ziellen Sektor interessant macht.

7. XMetaDiss: Umfasst Hochschulschriften-spezifische Metadaten und wird als Austauschformat zwischen der DNB und Universitätsbibliotheken verwen-det. XMetaDiss basiert auf dem Dublin Core Metadata Element Set und ist durch die Anreicherung mit weiteren Metadatenformaten zu internationalen Standards kompatibel. Bislang deckt das Format ausschließlich die Be-schreibung von Dissertations- und Habilitationsschriften ab. Für die Übertra-gung weiterer Publikationstypen auf Hochschulschriftenservern kommt das erweiterte Format XMetaDissPlus zum Einsatz.

8. Extensible Metadata Platform (XMP): Ist ein Adobe-Standard für die Erstel-lung, Verarbeitung und den Austausch von Metadaten. Dabei wird der Me-tadatensatz in einer Ressource (zumeist in der betroffenen Datei) integriert, wodurch Applikationen unabhängig vom Archivierungssystem einen Zugriff auf die zugehörigen Metadaten haben.

9. Preservation Metadata Implementation Strategies (PREMIS): Beinhalten Langzeitarchivierungsmetadaten gemäß dem Archivierungsprozess im OAIS Reference Model. Es legt einen besonderen Wert auf Angaben zur Existenz-fähigkeit (viability), Darstellbarkeit (renderability), Verständlichkeit (un-derstandability), Authentizität (authenticity) und zur Identität (identity) von Objekten. Die Kernmetadaten umfassen außerdem administrative und tech-nische Metadaten, wie Rechte- und Struktur-Metadaten.

10. Langzeitarchivierungsmetadaten für elektronische Ressourcen (LMER): Um-fassen Metadaten in einem Repository, die Informationen über die Langzeit-archivierung einer Ressource und den zugehörigen administrativen



Metadaten bereitstellen. LMER folgt einem Modulkonzept für die Kombinati-on mit weiteren Standards.

11. Metadata Encoding and Transmission Standard (METS): Ist vorrangig ein Standard für die Abdeckung deskriptiver und administrativer Metadaten so-wie von Struktur-Metadaten im Archivierungssystem. Da METS jedoch als eine Art Metadatencontainer fungiert und mit beliebigen Metadatenstan-dards angereichert werden kann, stellt sich METS als ein optimales Format zur Langzeitarchivierung genau wie für den Metadaten- und Ressourcen-austausch dar.

12. XML Formatted Data Unit (XFDU): Beschreibt wie Daten, Metadaten und zugehörige Software in einem Information Package gemäß dem OAIS Refe-rence Model gekapselt werden können, um den Informationstransfer und die Archivierung zu optimieren. Die Empfehlungen liegen jedoch nur lückenhaft in Form eines Red Book vor, was ihren praktischen Einsatz derzeit noch nicht ermöglicht.

Auch wenn die Metadatenstandards als voneinander relativ losgelöst erscheinen, verdeutlicht die Diskussion der Metadatenkategorienabdeckung, dass ein sinnvoller und vor allem optimierter Praxiseinsatz nur durch die Kombination von Metadaten-standards erreicht werden kann.

2.5 Zusammenfassung In diesem Kapitel wurde die prinzipielle Unabhängigkeit der Ressource und der Me-taebene (zugehörige Metadaten) verdeutlicht, jedoch auch auf deren Zusammenge-hörigkeit für das Funktionieren des digitalen Dokumentenverarbeitungsprozesses hingewiesen. Homogene Metadaten sind auf struktureller genau wie inhaltlicher Ebene der Aus-gangspunkt für die Erhöhung der Interoperabilität zwischen Bibliotheken, Archiven, Verlagen, Dienstleistungsunternehmen und natürlich auch den Konsumenten. Meta-datenstandards berücksichtigen die Bedürfnisse aller Parteien gemäß ihrer Domäne.

Metadaten werden sich in den Umgebungen am besten bewähren, für die sie geschaffen wurden [EVE99].

Neben den Strukturen für die Ausweisung von Metadaten sind die Verwendung eines einheitlichen Vokabulars und von Normdaten entscheidend, um Metadaten aus der Bibliothek zum Produzenten und Endbenutzer zu tragen. Interoperabilität und Kon-sistenz stehen bei der Verbreitung von Metadaten immer im Vordergrund.


Metadatenanreicherung im digitalen Publikationsprozess Modellierung der Prozesse in digitalen Bibliotheken

3 Modellierung der Prozesse in digitalen Bibliotheken Nachdem das vorangegangene Kapitel die Vorgehensweisen in einer Bibliothek (Be-schaffung, Erschließung, Sammlung und Bereitstellung) bereits grundlegend betrach-tet und in den Kontext der Metadatenanreicherung gesetzt hat, soll in diesem Kapitel anhand von Modellen die Betrachtungsweise verfeinert werden. Zusätzlich wird auf die Thematik des Metadatenaustausches zwischen Institutionen eingegangen, um im weiteren Verlauf die Funktionseinordnung der am Publikationsprozess partizipieren-den Parteien zu verdeutlichen.

3.1 Die digitale Bibliothek Bevor die eigentliche Prozessmodellierung eingeführt wird, soll an dieser Stelle die Begrifflichkeit der digitalen Bibliothek kurz beleuchtet werden. Digitale Bibliotheken sind durch die Digital Library Federation definiert als:

Organizations that provide resources including the specialized staff to select, structure, offer intellectual access to, interpret, distribute, preserve the integrity of, and ensure the persistence over time of collections of digital works so that they are readily and economically available for use by a defined community or set of communities. [DLF00]

Diese Definition deckt sich bedingt mit den in dieser Arbeit eingeführten Konzepten, da gegenwärtig neben den digitalen Ressourcen auch nicht-digitale Ressourcen in digitalen Bibliotheken verwaltet werden. Bei den angesprochenen Communities han-delt es sich um Benutzer, die sich außerhalb der Bibliothek befinden und das digitale Archivierungssystem in Anspruch nehmen.

Autor

Bibliothek

Verlag

Konsument

Handel

Bibliothekar

Abbildung 3.1: Beteiligte Rollen im Publikationsprozess Unter Betrachtung der ausschließlichen digitalen Ressourcenverarbeitung würde sich der Prozess in einer digitalen Bibliothek wie folgt gestalten: Der Autor erstellt eine Publikation im Dokumentenerstellungsprozess mittels einer Auswahl von Autorenwerkzeugen und möchte sein Ergebnis entweder direkt in der digitalen Bibliothek der Allgemeinheit zugänglich machen oder seine Publikation über einen Verlag veröffentlichen. Der Verlag wird gegebenenfalls diverse Überarbeitungen an der Ressource vorneh-men, um sie in den Vertrieb und damit in den Handel aufnehmen zu können. Deut-sche Verlage sind allerdings dazu verpflichtet, von jeder Veröffentlichung Exemplare an die Deutsche Nationalbibliothek abzugeben. Copyright TU Dresden, Alexander Haffner 18


In der Bibliothek kommen gemäß der Definition der Digital Library Federation die Bib-liothekare als Personal zum Tragen, um Ressourcen zu erschließen und zu archivie-ren. Der Konsument erhält durch die angebotene Schnittstelle der digitalen Bibliothek ei-nen Zugang zur Suche nach und zu digitalen Ressourcen selbst. Falls die Ressource aus rechtlichen Gründen nur bibliografisch in der Bibliothek aufgeführt ist, muss der Konsument die Ressource im Handel erwerben. Entgegen der aufgeführten Definition der digitalen Bibliothek soll im Prozess aus Gründen der Praxisnähe neben dem digitalen Werk auch die Einpflege der Druck-version betrachtet werden. Der Autor bzw. der Verlag sind bei Publikationen von Druckversionen verpflichtet, zwei physische Kopien in der zuständigen Bibliothek zu hinterlegen, wodurch der Konsument in der Lage ist, durch Direktausleihe die Res-source in der Bibliothek zu beziehen. Die Druckversionen wie auch digitale Ressour-cen stehen außerdem für den Konsumenten im Handel zum Kauf bereit. Das letzte Kapitel zeigte, dass für die Archivierung eingereichter Publikationen (un-abhängig von der Form dieser) bereits Metadaten vom Autoren bzw. durch den Ver-lag mitgeliefert werden müssen, um den Bibliothekar und sein Wirken im Archivierungssystem zu unterstützen und Metadaten für die Zugänglichkeitsgestal-tung für den Konsumenten unumgänglich sind.

3.2 Open Archival Information System (OAIS) Reference Model Das Open Archival Information System (OAIS) Reference Model [OAIS02] wurde vom Consultative Committee for Space Data Systems für die Langzeitarchivierung von Informationen entwickelt. Das Modell bezieht im Kontext die Produzenten der zu archivierenden Informationen und die Betreiber des Archivierungssystems ein. Ein Referenzmodell stellt eine Abstraktion der Kernkonzepte, deren Beziehungen, und deren Schnittstellen sowohl zueinander als auch zur externen Umgebung dar [RAU07]. Das OAIS Reference Model dient insbesondere der Erläuterung der Pro-zessstrukturen zur Integration von Langzeitarchivierungsstrategien im Archivierungs-system. Das OAIS Reference Model basiert auf einem Information Model.

Abbildung 3.2: Objekte im OAIS Information Model



Die Abbildung verdeutlicht, dass im Prozess sowohl nicht-digitale als auch digitale Objekte verarbeitet werden können. Man fasst diese als Data Object zusammen. Ein Data Object wandelt sich nur in ein Information Object, wenn die zugehörige Knowledge Base und Representation Information (z. B. ASCII-Standard) vorhanden sind. Als Knowledge Base wird in diesem Zusammenhang die Wissensbasis einer Person gesehen. So kann ein Leser beispielsweise die Daten eines englischsprachi-gen Dokumentes nur in Information wandeln, wenn er des Lesens und der engli-schen Sprache mächtig ist. Information Objects bewegen sich in gekapselter Form als Information Packages durch das OAIS. Ein Information Package besitzt drei essentielle Bestandteile: die Content Information, die Preservation Description Information (PDI) und die Packa-ging Information.

Abbildung 3.3: Information Package im OAIS Information Model Das Data Object und die Representation Information als das eigentliche Information Object gehören zur Content Information. Die PDI besteht aus Angaben zur Herkunft, dem Kontext (Beziehung zu anderen Informationen etc.), Referenzen (Identifiern wie ISBN) und zur Beständigkeit (Checksummen etc.). Die Content Information und die PDI werden durch die Packaging Information (Manifest, Package-Identifier etc.) zu-sammengehalten. Zusätzlich werden im Archivierungssystem noch deskriptive Infor-mationen zu den Information Packages gehalten, um diese suchen und auffinden zu können. Das Modell unterscheidet drei Arten von Information Packages:

• Submission Information Packages (SIP): werden vom Produzenten an das Ar-chiv gesendet

• Archival Information Packages (AIP): werden im Archiv aufbewahrt • Dissemination Information Packages (DIP): werden vom Archiv zum Konsu-

menten gereicht Im AIP muss die umfangreichste und detaillierteste PDI hinterlegt sein. In den SIPs werden zumeist nur mangelhafte beschreibende Informationen hinterlegt, auch kön-nen SIPs unterschiedlich strukturiert sein. Aus einem SIP kann neben einem AIP,



auch eine Aufnahme des SIPs in ein AIP oder die Aufspaltung des SIPs in mehrere AIPs vorgenommen werden. Ein DIP wird vor der Auslieferung an die Bedürfnisse des Konsumenten angepasst. Neben dem Information Model existiert noch ein Functional Model.

Abbildung 3.4: OAIS Functional Model Das Functional Model lässt sich in sieben funktionale Entitäten einteilen [BAL06]. Die Funktion der einzelnen Entitäten im Prozess wird im Folgenden vorgestellt. Die Enti-tätsbeziehungen sind in Abbildung 3.4 visuell verdeutlicht.

1. Ingest: Nimmt ein SIP vom Produzenten entgegen und sichert dessen Quali-tät; ergänzt das SIP um deskriptive Informationen (Erschließung) und wandelt es in ein AIP, das zum Archival Storage zur Einpflege gereicht wird; registriert deskriptive Informationen im Data Management

2. Archival Storage: Empfängt das AIP vom Ingest Process und realisiert dessen Speicherung; ständige Überprüfung und Sicherung der physischen Daten auf den Speichermedien; Datenrettung und Katastrophenplanung; Übergabe ei-nes AIP auf Anfrage zum Access

3. Data Management: Betrieb und Verwaltung der Datenbank für deskriptive und Systeminformationen; Antwort auf Anfragen der Access-Entität; Einpflege von deskriptiven Informationen aus Ingest; Reporterstellung

4. Administration: Deckt die Aktivitäten zur akkuraten Funktionsweise des Sys-tems ab; Aushandlung der Submission-Richtlinien mit den Produzenten sowie allgemeiner Richtlinien und Standards für das Gesamtsystem; Überprüfung der eingereichten Publikationen auf Standardeinhaltung; Systemkonfigurati-onsmanagement; Archival Information Updates; Zugangskontrollen; automati-sche Generierung von Dissemination Request aus gespeicherten Suchanfragen; Customer Service

5. Preservation Planning: Absicherung der Zugänglichkeit entgegen technologi-schen Änderungen; Überwachung der Zielgruppen auf Anforderungsänderun-gen, Technologien, Standards und Plattformen; Aufnahme von neuen



Features und Entnahme von alten; Entwicklung von Langzeitarchivierungs-strategien und -standards; Definition von zeitgemäßen Packaging-Designs und Migrationsplänen

6. Access: Suche und Datenabruf der archivierten Informationen; Koordination der Access-Aktivitäten in einem einzigen User Interface (Such-, Report- und DIP-Anfragen); Generierung der DIPs aus AIPs; Auslieferung an den Konsu-menten

7. Common Services: Die Entität unterliegt allen anderen und umfasst Betriebs-system-Services und Security-Services

Es zeigt sich, dass die benannten Funktionalitäten in den einzelnen Entitäten jeweils eine Kombination aus Aufgaben durch Menschenhand und automatisierten Prozes-sen des Systems sind. Die Besonderheit des Modells liegt in der Einbeziehung des Preservation Plannings, was die Zugänglichkeit der Informationen über lange Zeit gewähren soll. Hierfür sind Migrationsstrategien als kostengünstige und effiziente Vorgehensweisen vorgese-hen. Man unterscheidet vier Arten von Migration:

• Refreshment: Umkopieren des AIP auf dem Speichermedium • Replication: Erzeugen eines weiteren Replikates des AIP • Repackaging: Erzeugen einer Kopie des AIP, wobei Content Information und

PDI unverändert bleiben und die Packaging Information angepasst wird • Transformation: Erstellen eines neuen AIP mit abgeänderten Content Informa-

tion oder PDI, wobei versucht wird, die volle Information des Inhaltes aus dem originalen AIP zu bewahren.

Die Formulierung bei der Transformation weist bereits auf die Problematik der Migra-tion für neue Technologien und Standards hin. In dieser Arbeit soll auf die Risiken verlustbehafteter Migration bei der Langzeitarchivierung nicht eingegangen werden. Interessierte Leser können sich ausführlich über die Thematik in [BOR06] informie-ren. Im Folgenden wird sich diese Arbeit mit der Gestaltung und Konformität der einzel-nen Information Packages und der Anreicherung von PDI beschäftigen, um ein Op-timum bei der Metadatenintegration zu erlangen. Das Modell macht keine Aussagen zu Content-Packaging-Techniken. Am OAIS Re-ference Modell angelehnte Standards für die konforme Paketgestaltung sind METS, XML Formatted Data Unit (XFDU), MPEG-21 DIDL für multimediale Ressourcen und IMS Content Packaging. PREMIS deckt sich insbesondere mit den im OAIS Referen-ce Model enthaltenen Charakteristika für die Entscheidungsfindung der Langzeitar-chivierungsstrategien [BAL06].

3.3 Harvesting Die Open Archives Initiative (OAI) ist eine Initiative von Betreibern von Archivie-rungssystemen, deren Ziel es ist, die archivierten elektronischen Publikationen im Internet besser auffindbar und nutzbar zu machen. Das Konzept des Harvestings setzt dabei am Harvester an. Der Harvester ist ein so genannter Service Provider, der über eine einzige Schnittstelle Nutzern einen Zu-gang zum Archivbestand verschiedenster Archivierungssysteme bietet.



Das OAI Protocol for Metadata Harvesting (OAI-PMH) ermöglicht in diesem Zusam-menhang, weltweit Metadaten zwischen Organisationen zu teilen oder von verschie-denen Institutionen Daten einzusammeln und selbst weiterführende Dienstleistungen auf diesen Daten anzubieten [EPH05]. Das OAI-Protokoll liegt derzeit in der Version 2.0 vor. Beim Prinzip des Harvesting wird in Anbieter von (digitalen Exemplaren und) Meta-daten, den Data Provider und darauf aufbauenden Dienstleistern (Service Provider) unterschieden. Der Service Provider fragt in regelmäßigen Abständen die Metadaten der Data Provider ab und speichert diese in seiner lokalen Datenbank. Laut [OAIPMH02] werden die Provider wie folgt definiert

• Data Providers are administer systems that support the OAI-PMH as a means of exposing metadata; and

• Service Providers use metadata harvested via the OAI-PMH as a basis for building value-added services.

Resultierend stellt ein Endnutzer nur eine Anfrage auf der lokalen Datenbank des Service Providers, um über allen Ressourcen der Data Provider suchen zu können. Die Suche wird zumeist mittels eines Webinterfaces vorgenommen.

Data Provider

Data Provider

Data Provider

Service Provider

HTTP Anfrage XML

Nutzer

Abbildung 3.5: Prozess des Harvesting mittels OAI-PMH nach [MÜL01] Der funktionale Ansatz ist ähnlich dem des OAIS Reference Model. Data Provider halten in ihrem Repository so genannte Items. Der Begriff Item wird in diesem Zu-sammenhang nicht konform zu RDA verwendet. Ein Item ist eine Art Container für Ressourcen, wobei jeder Item einen oder mehrere Records von Metadaten zugewie-sen bekommen kann. Ein Item benötigt mitunter mehrere Records, da jedes Metada-tenformat in einem eigenem Record gehalten werden muss. Die Integration von beliebigen Metadatenformaten im Repository ist somit denkbar. Für den Austausch zwischen Providern ist es jedoch notwendig, dass die Metadatenformate untereinan-der abgestimmt sind. Aus Gründen der Interoperabilität wird Dublin Core als kleinster gemeinsamer Nenner von allen Datenprovidern unterstützt [EPH05]. Für eine qualita-tiv hochwertige Weiterverarbeitung findet häufiger MARCXML Einsatz. OAI-PMH Anfragen werden von Service Providern als HTTP-Requests ausgedrückt. OAI-PMH ermöglicht es, Daten von Data Providern selektiv abzufragen. Service Pro-



vider können beispielsweise auf Basis von Set-Hierarchien die für sie relevanten Da-ten anfordern.

A set is an optional construct for grouping items for the purpose of selective harvesting. [OAIPMH02]

Insgesamt existieren sechs verschiedene OAI-Requests: • Identify(): Informationen über das Repository • ListSets(): Hierarchieaufbau der Items und Sets des Repositorys • ListIdentifiers([until], [from], [set]): Liste der eindeutigen Bezeichner von Da-

tensätzen (nur Header nicht Datensatz selbst) – selektiv möglich • ListMetadataFormats([identifier]): Verfügbare Metadatenformate zu einem

Item • ListRecords([until], [from], [set], metadataPrefix): Metadatensätze des Ar-

chives • GetRecord(identifier, metadataPrefix): Metadatensatz eines Items

Laut Deutscher Initiative für Netzwerkinformation e.V. (DINI) empfiehlt es sich für Da-ta Provider, eine Strukturierung der Archive sowohl nach formalen als auch nach in-haltlichen Kriterien vorzunehmen. Die inhaltliche Beschreibung soll sich an den Sachgruppen der Deutschen Nationalbibliothek orientieren. Die formalen Unterglie-derungen beziehen sich auf die Publikationsform und den technischen Dokumenttyp. Resultierend sollten Sets in vier unterschiedlichen Gliederungsansätzen aufgeführt werden:

• einer inhaltlichen Gliederung (ddc), • einer Gliederung gemäß der Publikationsform (pub-type), • einer Gliederung nach Dokumenttypen (doc-type) und • einer Gliederung nach der qualitativen inhaltlichen Begutachtung (status).

Die Antworten der Data Provider werten mittels HTTP-Responses formuliert und im XML Response Format ausgedrückt. Im XML Response Format werden entspre-chend der Anfrage passende Antworten in XML serialisiert. Wie gezeigt, ist für die Funktionsweise des Ansatzes der Austausch der eigentlichen Metadaten (Records) essentiell. Ein Record kann neben Header-Informationen und dem metadata-Element, in dem die tatsächlichen Metadaten enthalten sind, auch noch ein about-Element besitzen. Im about-Element sind Metadaten über den Metadatensatz des Records (beispielsweise Daten zum Rechtemanagement, Provenance Statements) gespeichert. Dadurch ist eine verbesserte Verwaltung für den Service Provider er-möglicht. Unter dem Namen OAI Object Re-Use and Exchange (OAI-ORE) wurden ergänzend zu OAI-PMH Verfahren geschaffen, um die innere Struktur der Objekte und die Be-ziehung zu anderen Objekten in einer maschinell lesbaren Resource Map abzubil-den. Mit OAI-ORE soll auch das Wiederverwenden und das veränderte Zusammensetzen von publizierten Inhalten vereinfacht werden. In der Praxis trifft man heutzutage oft auf so genannte aggregierende oder kumulati-ve Data Provider, welche neben ihrer eigentlichen Rolle als Data Provider auch die Rolle eines Service Providers für eine ausgewählte Zahl von anderen Data Providern übernehmen. Abschließend soll darauf hingewiesen werden, dass der Ansatz des Harvesting ge-genüber Protokollen wie dem Z39.50-Protokoll, einen hohen Performancevorteil bei der Übertragung großer Datenmengen aufweist.



3.4 Open Archives Initiative Object Reuse and Exchange (OAI-ORE) Der durch Open Archives Initiative Object Reuse and Exchange (OAI-ORE) im Okto-ber 2008 definierte Standard [ORE08] zielt auf die Beschreibbarkeit und Austausch-barkeit von logisch zusammengehörenden Einheiten im Web ab. Eine solche Einheit kann verteilte Ressourcen unterschiedlichster Formate und Medientypen enthalten. Typische Beispiele sind untereinander verlinkte HTML-Seiten, wissenschaftliche Publikationen in alternativen Formaten mit Sekundärliteratur oder ein Journal, das eine Zahl an Ausgaben besitzt und jede Ausgabe eine Anzahl an Artikeln umfasst. OAI-ORE spezifiziert diese logischen Einheiten als Aggregationen, die wiederum Ressourcen bestimmten Typs aggregieren. Die Ressourcen besitzen bestimmte Ag-gregations-interne und –externe Beziehungen.

The goal of these standards is to expose the rich content in these aggrega-tions to applications that support authoring, deposit, exchange, visualization, reuse, and preservation.

Aggregationen gestatten Crawler-basierten Suchmaschinen semantische Zusam-menhänge zu erkennen, optimierte Navigationsmechanismen in Browsern anzubie-ten oder Archivierungsstrategien in bzw. interoperable Austauschverfahren zwischen Repositories für die gesamte Aggregation zu finden. Das nachfolgend vorgestellte ORE Data Model setzt auf der Architektur des World Wide Web [WAR04] auf und nutzt RDF-Konzepte [RDF04] sowie RDF Vocabulary [RDFS04] nach. Im ORE Abstract Data Model existieren prinzipiell vier Typen von Entitäten:

• Aggregationen als eine Ressource vom Typ ore:Aggregation, die über eine URI-A identifiziert wird,

• aggregierte Ressourcen in Aggregationen, die über eine URI-AR identifiziert werden,

• die Resource Map (ReM) mit dem Typ ore:ResourceMap, welche eine Aggre-gation, ihre aggregierten Ressourcen und weitere Ausdrücke sowie Beziehun-gen beschreibt. Eine ReM wird über eine URI-R identifiziert.

• Proxy vom Typ ore:Proxy als Platzhalter für Aggregationen und eine in Bezie-hung stehende aggregierte Ressource.

Eine ReM muss über einen RDF-Graph und entsprechende RDF-Tripel seine Bezie-hung zur Aggregation deklarieren, Metadaten zu dieser ReM und der Aggregation spezifizieren sowie die Beziehungen der in der Aggregation enthaltenen Ressourcen (Aggregation Graph) ausdrücken. Außerdem kann die ReM Beziehungen der Aggre-gation oder in der Aggregation enthaltene Ressourcen zu externen Ressourcen defi-nieren. Abbildung 3.6 verdeutlicht die in der ReM ausgedrückten Beziehungen. Eine Aggre-gation kann abhängig von der Art der Serialisierung durch mehrere ReMs wie im Beispiel beschrieben werden. Die Metadaten können in Form von Literalen oder wie-derum in Tripeln spezifiziert sein. Die Beziehungen einer Aggregation zu einer ande-ren Aggregation oder einem anderen Objekt (beispielsweise über eine DOI oder eine URN) können die Prädikate rdfs:seeAlso oder dessen Sub-Property ore:similarTo tragen. Das Prädikat ore:similarTo drückt aus, dass die andere Ressource einen ähnlichen Inhalt zur Aggregation besitzt, wohingegen rdfs:seeAlso schwächerer Na-tur ist und beispielsweise eine Referenz darstellt.



Außerdem besteht die Möglichkeit in einer ReM, zusätzliche Tripel zu der ReM, einer Aggregation, den aggregierten Ressourcen oder anderen in Beziehung stehenden Ressourcen oder Literalen zu zuweisen. Über rdf:type wird im Beispiel der semanti-sche Typ der Ressource ausgedrückt. T-1 bedeutet, dass es sich um den Typ „Arti-kel“ handelt und T-2 weist darauf hin, dass die Ressourcen vom Typ „Text“ sind. Des Weiteren definiert die Beziehung R-1, dass A-1 ein Teil der Ressource B ist. Für de-taillierte Ausführungen zu den RDF-Ausdrücken und korrespondierenden URIs zu den Ressourcen aus dem Beispiel sei der Leser auf die tabellarischen Übersichten in Anhang E verwiesen.

ReM-2

ReM-1

A-1

AR-1

AR-2

AR-3

ore:aggregates

ore:aggregates

ore:aggregates

X Y

dcterms:creator

dcterms:modified

dc:rights

dcterms:creator

A-2DOI-1

ore:describes

ore:describes

ore:similarTordfs:seeAlso

T-1

B

rdf:type

R-1

T-2

rdf:type

rdf:type

rdf:type

Abbildung 3.6: Primärbeziehungen in einer Aggregation gemäß OAI-ORE Im weiteren Verlauf wird verdeutlicht, wie durch eine Resource Map Beziehungen zwischen aggregierten Ressourcen und anderen Resource Maps oder Aggregatio-nen ausgedrückt werden können. Im einfachsten Falle kann eine aggregierte Ressource Bestandteil in einer Vielzahl von Aggregationen sein. Des Weiteren besteht die Möglichkeit, Aggregationen zu verschachteln. Da jede Ressource im OAI-ORE Abstract Model auch eine Aggrega-tion sein kann, ist es lediglich notwendig, jede Aggregation über eine zugehörige ReM sichtbar zu machen. Abbildung 3.7 illustriert ein einfaches Beispiel einer ge-schachtelten Aggregation.



ReM-2

ReM-1 A-1

AR-1

AR-2

AR-3

ore:aggregates

ore:aggregates

ore:aggregates

ore:describes

ReM-3

ore:describes

ore:describes

AR-N

AR-M

AR-Y

AR-X

ore:aggregates

ore:aggregates

ore:aggregates

ore:aggregates

Abbildung 3.7: Geschachtelte Aggregationen gemäß OAI-ORE Ein weiteres Konzept des Abstract Model besteht im Einsatz von Proxies. Proxies erlauben es, Zusammenhänge in einem bestimmten Kontext (Aggregations-intern oder -extern) zu beschreiben. Beispielsweise kann eine Reihenfolge von aggregier-ten Ressourcen in der Aggregation festgelegt werden oder die Abstammung einer Ressource aus einer anderen Aggregation definiert werden. An dieser Stelle soll das Konzept jedoch nicht vertiefend betrachtet werden. Für Interessenten sei auf [ORE08] verwiesen. Resource Maps können in verschiedenen Formaten wie Atom XML, RDF/XML, RDFa, n3, turtle und anderen RDF-Serialisierungsformaten ausgedrückt werden. Im Entstehungsprozess dieser Arbeit hat sich der Autor unter anderem mit Atom XML auseinander gesetzt. Atom XML liegt ein viel versprechendes Konzept zu Grunde. Es musste jedoch festgestellt werden, dass es nicht in der Lage ist, genauso umfangrei-che und ausgereifte Definitionen wie mittels RDF/XML zu treffen. Das für OAI-ORE entwickelte Vokabular stellt eine maschinenlesbare Verarbeitung sicher. In diesem Zusammenhang wurde durch die OAI ein Vokabular für die Entitä-ten und für deren Beziehungen untereinander spezifiziert. Im Vokabular wurde eine Reihe von Ausdrücken aus dem Vokabular der DCMI und RDF übernommen.


Metadatenanreicherung im digitalen Publikationsprozess Anforderungen und Analyse

4 Anforderungen und Analyse In diesem Kapitel werden Anforderungen für Barrierefreiheit in der digitalen Biblio-thek für eine Zugangsgewährung durch Benutzer mit besonderen Bedürfnissen er-hoben. Anhand von exemplarisch ausgewählten digitalen Publikationsformen wird erläutert, wie Barrierefreiheit bei der Ressourcenproduktion erreicht werden kann. Nachfolgend werden Analyseergebnisse bezüglich der Prozessabläufe ausgewählter Bibliotheken detailliert vorgestellt, um im weiteren Verlauf der Arbeit einen gemein-samen optimierten Prozess auf Basis der im vorangegangenen Kapitel eingeführten Modelle und dem Ist-Stand der Prozessabläufe in den Bibliotheken zu modellieren.

4.1 Barrierefreiheit in der digitalen Bibliothek In diesem Kapitel wird verdeutlicht, was Barrierefreiheit in digitalen Bibliotheken be-deutet. Doch bevor dieser Schritt gegangen wird, soll der Begriff der Barrierefreiheit kurz de-finiert werden. Im Englischen spricht man in diesem Kontext von Accessibility, was im Deutschen neben Barrierefreiheit auch mit „Zugänglichkeit“ übersetzt wird. Accessibi-lity ist in der ISO TS 16071 aus dem Jahre 2002 wie folgt definiert:

Usability of a product, service, environment or facility by people with the widest range of capabilities

Wenn man die Bibliothekswelt betrachtet, stellt sich die Frage, wer die in diesem Kontext betroffenen Personen sind. Prinzipiell stehen Besucher mit besonderen Bedürfnissen im Fokus von Barrierefrei-heit. In Bibliotheksumgebungen bedeutet dies primär, allen Besuchern einen adäqua-ten Zugang zu gewähren. In der traditionellen Bibliotheksumgebung sind Barrieren vor allem baulicher und gestaltungstechnischer Natur, die es Besuchern mit Mobili-tätseinschränkungen nicht erlauben, die Angebote angemessen zu nutzen. Beispiele sind fehlende Blindenleitsysteme, sehgeschädigtengerechte Arbeitsplätze, zu hohe Regale für Rollstuhlfahrer etc. Barrieren in der digitalen Bibliothek umfassen mangelnde Zugänglichkeit aufgrund von barrierehaltigen Benutzerschnittstellen zum digitalen Bibliothekssystem oder den digitalen Ressourcen selbst. Allerdings kann Barrierefreiheit auch Benutzern ohne Behinderung von Vorteil sein. Insbesondere wenn sich diese Benutzer in einem Kontext befinden, in dem sie durch Hardwarebegrenzungen (portable Geräte mit kleinen Displays, Bandbreitenein-schränkungen etc.) und/oder Umweltgegebenheiten (eingeschränkte Beleuchtung, Geräuschkulisse etc.) nur teilweise Informationen über die Benutzerschnittstelle aus den Ressourcen gewinnen können. Aus Sicht des Autors dieser Arbeit betrifft Barrierefreiheit jedoch nicht nur die Kon-sumentenseite, sondern genauso die Zugänglichkeitsgewährung für Produzenten und Angestellte der Bibliothek. Bei einer durchschnittlichen Quote von 10% an be-hinderten Menschen in unserer Bevölkerung sind unter sämtlichen Akteuren Betrof-fene zu finden. Da sich der quantitativ größte Teil der betroffenen Akteure in der Konsumentengruppe befindet, wird sich diese Arbeit aus Umfangsgründen auf diese konzentrieren.



In unserer gegenwärtigen Wissensgesellschaft nehmen Bibliotheken eine zentrale Stellung ein. Resultierend übernehmen sie auch die soziale Verantwortung, allen Menschen dieser Gesellschaft einen adäquaten Zugang zu bieten. Barrierefreiheit ist in unserer immer weiter alternden Gesellschaft auch als zwingendes Qualitätsmerk-mal gegenüber konkurrierenden Institutionen zu sehen. Daher ist es nahe liegend, dass öffentliche Institutionen, zu denen eine Bibliothek schließlich gehört, vom Ge-setzgeber zur Umsetzung von Barrierefreiheit gezwungen werden. Die Barrierefreie Informationstechnik-Verordnung (BGBl. I S. 2654) trat am 17. Juli 2002 in Kraft und verpflichtet Behörden der Bundesverwaltung, behinderten Menschen einen Zugang durch die gemäß der Verordnung vorgeschriebene Gestaltung von Angeboten der Informationstechnik (Intranetauftritte und -angebote sowie grafische Programmober-flächen) anzubieten. Die grundlegenden Aspekte für die barrierefreie Gestaltung sollen an dieser Stelle aufgeführt werden, um dem Leser zu verdeutlichen, was dies in der Praxis bedeutet.

1. Für jeden Audio- oder visuellen Inhalt sind geeignete äquivalente Inhalte be-reitzustellen, die den gleichen Zweck oder die gleiche Funktion wie der ori-ginäre Inhalt erfüllen.

2. Texte und Grafiken müssen auch dann verständlich sein, wenn sie ohne Farbe betrachtet werden.

3. Markup-Sprachen (insbesondere HTML) und Stylesheets sind entsprechend ihren Spezifikationen und formalen Definitionen zu verwenden.

4. Sprachliche Besonderheiten wie Wechsel der Sprache oder Abkürzungen sind erkennbar zu machen.

5. Tabellen sind mittels der vorgesehenen Elemente der verwendeten Markup-Sprache zu beschreiben und in der Regel nur zur Darstellung tabellarischer Daten zu verwenden.

6. Internetangebote müssen auch dann nutzbar sein, wenn der verwendete Benutzeragent neuere Technologien nicht unterstützt oder diese deaktiviert sind.

7. Zeitgesteuerte Änderungen des Inhalts müssen durch die Nutzerin/den Nut-zer kontrollierbar sein.

8. Die direkte Zugänglichkeit der in Internetangeboten eingebetteten Benutzer-schnittstellen ist sicherzustellen.

9. Internetangebote sind so zu gestalten, dass Funktionen unabhängig vom Eingabegerät oder Ausgabegerät nutzbar sind.

10. Die Verwendbarkeit von nicht mehr dem jeweils aktuellen Stand der Technik entsprechenden assistiven Technologien und Browsern ist sicherzustellen, soweit der hiermit verbundene Aufwand nicht unverhältnismäßig ist.

11. Die zur Erstellung des Internetangebots verwendeten Technologien sollen öffentlich zugänglich und vollständig dokumentiert sein, wie z. B. die vom World Wide Web Consortium entwickelten Technologien.

12. Der Nutzerin/dem Nutzer sind Informationen zum Kontext und zur Orientie-rung bereitzustellen.

13. Navigationsmechanismen sind übersichtlich und schlüssig zu gestalten. 14. Das allgemeine Verständnis der angebotenen Inhalte ist durch angemesse-

ne Maßnahmen zu fördern. Es ist ersichtlich, dass die Techniken in erster Linie auf die Gestaltung barrierefreier Websites als vorrangig gebräuchliche Nutzerschnittstelle abzielen. Allerdings ist bei genauerer Betrachtung festzustellen, dass die Kriterien auch eine Vielzahl von Be-dingungen für die Gestaltung von barrierefreien Publikationen umfassen.



Aus der Sicht des Autors ist es daher unumgänglich, neben einem barrierefreien Webinterface dem Benutzer auch barrierefreie Ressourcen bei der Dokumentendist-ribution anzubieten. Hierfür muss der Nutzer bereits während der Exploration seiner Suchergebnisse über die Qualität der verschiedenen Manifestationen eines Werks hinsichtlich der Barrierefreiheit Rückschlüsse ziehen können. Diese Rückschlüsse auf Barrierefreiheit müssen für Leser durch die Präsentation geeigneter Metadaten gezogen werden können. Perspektivisch muss es Konsumen-ten auch möglich sein, vorselektierte und vor allem profilgerechte Angebote für einen spezifischen Nutzungskontext gemäß seinen Bedürfnissen nachzunutzen. Das Ziel dieser Arbeit ist folglich, Metadaten zur Ausweisung von Barrierefreiheit ein-zuführen und im Dokumentenverarbeitungsprozess einer digitalen Bibliothek und ih-rer partizipierenden Organisationen zu integrieren.

4.2 Digitale Publikationen Ein digitales Archivierungssystem zeichnet sich insbesondere durch seinen Bestand an in ihm befindlichen digitalen Publikationen aus. Diese digitalen Publikationen ent-sprechen Exemplaren einer Manifestation zu einer gegebenen Expression in einem Werk. In diesem Abschnitt soll daher diskutiert werden, wie diese Publikationen ges-taltet werden können, um besonderen Benutzerbedürfnissen und damit Prinzipien der Barrierefreiheit gerecht zu werden. Die kostengünstigste Integration von Accessibility in einem Mainstream-Workflow verlangt die Umsetzung von Barrierefreiheit während der Ressourcenproduktion [CWA07]. Jegliche nachträgliche Aufbereitung ist mit einem explizit steigenden Auf-wand verbunden. Da nicht jeder Produzent in der Lage ist, Barrierefreiheit für alle vorstellbaren Ziel-gruppen zu integrieren, gilt es in erster Linie optimierte Strukturen in der primären Ressource anzulegen, um ausgewählte Bestandteile durch Dritte mit Alternativres-sourcen anzureichern. Resultierend gilt es, eine kollaborative Autorenumgebung zu schaffen, in der die Mitwirkung der eigentlichen Autoren mit Accessibility-Experten organisatorisch optimiert wird. Vorrangig wird es sich bei primären Ressourcen um ePrint-Angebote handeln, durch die eine Zitierfähigkeit gemäß einer gedruckten Manifestation gegeben ist. Optimierte Strukturen in der primären Ressource unterstützen insbesondere ausge-reifte Navigationsmechanismen in der Ressource, die Nutzer mit und ohne Behinde-rung bei der Nachnutzung zu Gute kommen. Außerdem ermöglichen strukturierte Ressourcen eine automatisierte Überführung der Dokumente in Alternativversionen im selben oder in einem zusätzlichen Medientyp. Wie optimierte Strukturen für Pro-zessunterstützung im Detail auszusehen haben, muss zwischen Archivbetreibern und Produzenten abgestimmt werden [CWA07]. Da Text und Grafik für diverse Nutzergruppen nicht zugänglich sind, stellt sich die Herausforderung, diese Medien durch eine layoutspezifische Anpassung zu persona-lisieren bzw. geeignete Alternativen in gleicher oder zusätzlicher Medienform für eine anwendbare Nutzungsmodalität bereitzustellen. Alternativen in gleicher Medienform könnten beispielsweise Text in einfacher Spra-che sein, der vor allem Dyslexikern bei der Verständnisgewinnung nützt. Eine Alter-native könnte aber selbstverständlich auch ein Dokument mit exakt demselben Inhalt



sein, das aus Gründen der Langzeitarchivierung und einer zukünftigen Zugänglich-keitsgewährung in ein zeitgemäßes Format migriert werden musste. Alternativen in zusätzlicher Medienform wären beispielsweise Audio für die Zugäng-lichkeitsgewährung sehgeschädigter Leser oder Video zur Bereitstellung von Über-setzungen in Gebärdensprache. Insbesondere Gebärdensprachanbindung weist ein hohes Potential bei der Unterstützung gehörloser Menschen auf, da geschriebener Text eine Fremdsprache für die genannte Zielgruppe darstellt. Gehörlose Menschen verwenden laut [PET05] Gebärden als ihre Muttersprache. Besonders Audio als Alternativmedium führt eine Reihe von Vorteilen in der Nutzung durch Mainstream-Nutzer nach sich. Der extrem ansteigende Verkauf von Hörbü-chern beweist, dass die Akzeptanz und Nutzung durchaus gegeben ist. Der Konsu-mentenkreis entdeckte dabei die Vorzüge des ortsungebundenen Konsums (beispielsweise im Auto). Alternativversionen können entsprechend der Bedürfnisse einzelner Nutzer (on de-mand) bei der Distribution ausgeliefert werden, um die Modalität der geplanten Inter-aktion im aktuellen Kontext zu ermöglichen [HAF08]. Im Kapitel 5.1 wird diesbezüglich erläutert wie Metadaten die Identifikation von adäquaten Ressourcen oder Ressourcenteilen gemäß der angestrebten Interaktionsmodalität ausweisen können. Im Folgenden soll das Portable Document Format (PDF) als am weitesten verbreite-ter ePrint-Vertreter vorgestellt und bezüglich Gestaltungsmöglichkeiten zur barriere-freien Publikation diskutiert werden. Als multimedialer Ressourcenstandard sollen Digital Talking Books (DTB) im DAISY-Format eingeführt werden. DTBs finden eben-falls weltweit eine immer höhere Verbreitung und unterstützen gezielt die Bedürfnisse behinderter Leser, wobei zusätzlich eine zukünftige Etablierung auf dem Mainstream-Markt beabsichtigt wird.

4.2.1 PDF-Dokumente Portable Document Format (PDF) ist das weltweit im Internet am häufigsten einge-setzte Format für ePrint-Medien, was seine Relevanz unumstritten macht. Daher soll in diesem Abschnitt eine Einführung zu PDF und ein Einblick zu dessen barrierefreier Gestaltung gegeben werden. PDF kann plattformübergreifend mit entsprechenden Viewern exakt gleich wiederge-geben werden (WYSIWYG-Format), was auch darauf hinweist, warum es bislang hauptsächlich als Austauschformat und zum Druck verwendet wird. PDF liegt derzeit in der sechsten Auflage als Version 1.7 vor und ist seit 1. Juli 2008 als ISO 32000-1:2008 ein offener Standard. Die zuvor standardisierten Formate sind:

• PDF/X (ISO 15930) Format für die Übermittlung von Druckvorlagen • PDF/A (ISO 19005-1:2005) Format für die Langzeitspeicherung, basierend auf

PDF Version 1.4 • PDF/E (ISO 24517-1:2008) Format für technische Dokumente aus den Berei-

chen Ingenieurwesen, Architektur und Geo-Informationssysteme Mittlerweile sind auch eine Reihe von Features zur Weiterbearbeitung der Dokumen-te (Notizen, Kommentare, Transformation in andere Formate) durch das Format zu-gelassen, vorausgesetzt der Autor lässt dies über die Dokumentenrechte zu. In digitalen Bibliotheken ist dies nicht immer der Fall.



Eine PDF-Datei kann in gewisser Art als Container gesehen werden, in dem diverse Objekte abgelegt sind. Objekte sind z. B. Schriftinformationen und Encodings, Sei-tenlayout- und Seitenobjektinformationen wie beispielsweise Paragraphen, Bilder und Formularelemente. PDF/UA ist ein weiterer noch in Bearbeitung befindlicher Standard für Universal Ac-cessibility. Er wird Richtlinien für den Aufbau eines barrierefreien Dokuments im PDF-Format enthalten. 2008 lag ein Draft in der Version 1.0 vor, welcher allerdings bis zum Abschluss dieser Arbeit nicht öffentlich zugänglich war. In Hinsicht auf die Gewährung von Barrierefreiheit spielen verschiedene Faktoren eine wichtige Rolle.

Structured information is the first big step towards high-quality accessible infor-mation. A document whose internal structure can be defined and its elements isolated and classified, without losing sight of the overall structure of the docu-ment, is a document that can be navigated. [CWA07]

Strukturierte Informationen erhält man durch die akkurate Auszeichnung von Objek-ten gemäß der logischen Struktur des Dokumentes. Auch bei PDF spricht man im Zusammenhang von Objektauszeichnungen von Tagging und daher von Tagged-PDF. Das Tagging ist prinzipiell ähnlich zu der Auszeichnung in XHTML. Es wird eine hierarchische Struktur durch die ebenengerechte Verwendung von Überschriften und darunter liegenden Paragraphen, Tabellen, Listen, Grafiken etc. und sogar Multime-diainhalten erzeugt. PDF bietet neben den XHTML-typischen Konstrukten noch Kap-selungen für eine Anzahl von Objekten durch die Auszeichnung von Book über Chapter über Seiten und Sections an. Durch die Strukturierung und die Angabe einer Lesereihenfolge ist es einerseits mög-lich, eine entsprechende Navigationsstruktur im Dokument aufzubauen und anderer-seits einer assistiven Technologie (z. B. Screenreader, verschiedene Arten von Eingabegeräten) den Zugriff und die Verarbeitung zu ermöglichen. Dies funktioniert für Screenreader natürlich nur, wenn auf Pixelschriften verzichtet wird und definierte Schriften eingebettet werden, damit der Text auch als solcher erkannt wird. Eine wei-tere Problematik besteht in der Integration von Objekten, die aus verschiedenen Gründen durch einen speziellen Nutzerkreis nicht erschließbar sind. Beispielsweise sind Bilder, Videos etc. für blinde Menschen im Objekt-Tag über ein Attribut mit einer alternativen Bildbeschreibung zu versehen. Ein weiterer wichtiger Aspekt liegt in der Fähigkeit der Skalierbarkeit von Dokumen-ten, die durch die Struktur und die eingebetteten Schriften schon grundlegend gege-ben ist. PDF bietet für Endgeräte mit kleinen Displays eine Reflow-Option an, die den Text auf dem Bildschirm entsprechend umbricht. Für sehbehinderte Leser ist der ge-genläufige Ansatz relevant, die Vergrößerung von Schriften. Das Reflow vermeidet das horizontale Scrollen. Analoges gilt für Grafiken. Durch die Einbindung von Vek-torgrafiken können diese beliebig und qualitativ verlustfrei skaliert werden. Der Autor dieser Arbeit musste jedoch feststellen, dass es im Gegensatz zu körper-behinderten und sehgeschädigten Menschen für hörgeschädigte Leser in PDF keine wirklichen Unterstützungsmöglichkeiten gibt. Eine Möglichkeit wäre die Verwendung von einfacher Sprache, was am jeweiligen Dokumentautor liegt. Da keine funktions-tüchtigen Synthesewerkzeuge für Gebärdensprache existieren, wäre eine zweite Möglichkeit, Gebärdenvideos als Alternativmedien zum Text zu synchronisieren, was durch den PDF-Standard jedoch nicht zugelassen wird.



In der Praxis gibt es zwei Ansätze, Barrierefreiheit in PDF-Dokumenten zu realisie-ren. Einerseits kann der Autor während der Erstellung in seinen Office-Applikationen die Strukturierung (über Formatvorlagen) der Dokumente, Sprachauszeichnungen und die Alternativbeschreibungen integrieren. Für die Dokumentenerstellung in La-TeX-Umgebungen gestaltet sich dies jedoch schwieriger [SCH07]. Durch Programme zur Übernahme der Strukturen in das zu erzeugende PDF ist au-tomatisch die Basis für die Barrierefreiheit im Ergebnisdokument gesichert. Bislang wurde die Überführung immer durch das mitinstallierte Acrobat Plug-In "PDFMaker" im Autorenwerkzeug realisiert. Mittlerweile existieren wie in OpenOffice erste Export-filter, die diese Funktionalität ohne Adobe Acrobat umsetzen. Für Microsoft Office ist dies jedoch aus kartellrechtlichen Gründen verboten. Der zweite Ansatz ist die Nacharbeit des barrierehaltigen Dokumentes in Adobe Ac-robat. Für den Autor empfiehlt sich, mindestens auf die Version 7 zurückzugreifen. Es soll erwähnt sein, dass die Überarbeitung auch zumeist bei zuvor barrierefreien und im Anschluss überführten Dokumenten vorgenommen werden muss. Die Strukturen können in Acrobat nachträglich automatisch (mäßige Qualität) und von Hand angelegt werden. Außerdem sind Lesezeichen, Festlegung der Tabreihen-folge und Sprachauszeichnung einzubinden. Es sei darauf hingewiesen, dass die Überarbeitung sehr zeitintensiv ist. Bei der Verschlüsselung muss darauf geachtet werden, dass die Funktion „für Sehgeschädigte zugänglich machen“ ausgewählt wurde, da sonst Screenreader keinen Zugang zum Dokument erhalten. Jedes barrierefreie Tagged-PDF kann mit Acrobat 9 wiederum in Formate wie Micro-soft Word oder RTF zurück transformiert werden. Hierdurch ist die Umsetzung der Richtlinien auch für nicht-behinderte Dokumentennutzer von großem Interesse. Ac-robat 9 ist derzeit die einzige Software, die PDF 1.7 und verschiedene Adobe-Erweiterungen unterstützt. Die Metadatenanreicherung kann und sollte durch den Autor im Autorenwerkzeug über die Dokumenteneigenschaften vorgenommen werden, um diese direkt im XMP abzulegen. Adobe räumt Entwicklern teilweise das Recht ein, eigene Anwendungen zur Generie-rung und Bearbeitung von PDF-Dokumenten zu entwickeln. Adobe behält sich zwar das Copyright über die Spezifikationen vor, ermöglicht somit aber die Filterentwick-lung für die Integration im Dokumentenverarbeitungsprozess.

4.2.2 Digital Talking Book Ein Digital Talking Book (DTB) ist ein elektronisches Buch, das nicht nur sprechen (talking), sondern auch einen elektronischen Text mit Bildern enthalten kann. Prinzi-piell gibt es drei Ausprägungsformen des DTB:

1. XML-basierte Textversion, 2. Textversion mit zugehörigem Audioäquivalent, 3. Audioversion mit wenig oder keinem Text.

DTBs dienen der Unterstützung blinder, seh-, körper- und lernbehinderter Menschen sowie Menschen mit Leseschwäche. Die Erfahrungen der letzten Jahre untermauern das Potential von sprechenden Büchern für die Unterstützung der genannten Leser-gruppen. In der Vergangenheit befanden sich sprechende Bücher auf analogen Ton-trägern. Die heutigen DTBs sind durch ihre digitale Form gegenüber herkömmlichen analogen Tonträgern erheblich zugänglicher und vor allem komfortabel navigierbar.



Die gesprochene Sprache kann durch einen menschlichen Erzähler oder syntheti-sche Sprache integriert sein. Der enthaltene Text ist im DTBook-Format hinterlegt und kann für einen blinden Nutzer auf seiner Braillezeile ausgegeben werden, woge-gen ein sehbehinderter Leser eine individuelle Schriftgrößenanpassung auf Basis von CSS vornehmen kann. Über den standardmäßigen Einsatz von Bildern in Büchern hinaus können zusätzli-che Abbildungen auch Leser mit Leseschwächen hervorragend unterstützen. Durch die erweiterten globalen und lokalen Navigationsmechanismen ist eine Explo-ration der DTB-Inhalte stark an die Nutzerbedürfnisse angepasst [KER01]. Zusätzlich können im Buch Präsentationen angepasst, Lesezeichen und Markierungen gesetzt, Stichwortsuche durchgeführt und Wortbuchstabierung ausgeführt werden. Das DTB wird im Volksmund auch als DAISY-Buch bezeichnet. DAISY steht als Ab-kürzung für Digital Accessible Information System. Das DTB ist der Nachfolger des DAISY 2.02 Standards. Die Spezifikation eines DTBs ist in ANSI/NISO Z39.86-2005 festgehalten. Die Spezifikation wird auch als DAISY 3 bezeichnet. Für das Abspielen der DTBs sind so genannte Playback Devices notwendig. Auf dem Markt befinden sich von portablen bis hin zu Desktopapplikationslösungen verschie-denste Umsetzungen mit variierender Funktionalitätsimplementierung. Um einen Überblick über die im DTB enthaltenen und demzufolge durch die Play-back Devices nachnutzbaren Funktionalitäten zu erhalten, verdeutlicht die nachfol-gende Tabelle die zugelassenen DTB-Bestandteile.

Name Inhalt Package File Genau eine Datei (*.opf), die von Open eBook Publication Structure 1.2 abgelei-

tet ist • PACKAGE IDENTITY: eindeutiger Identifier der Aggregation • METADATA: hält die zur Gesamtressource gehörigen Metadaten (DCMI

Metadata Terms, DTB ID Scheme, X-Metadata) • MANIFEST: weist die enthaltenen Dateien mittels (href, MIME-Tyoe, id)

des DTB aus (Distribution File ist kein Bestandteil) und spezifiziert ihre Beziehung zueinander, außerdem werden Fallback-Deklarationen für nicht unterstützte Medien spezifiziert

• SPINE: spezifiziert eine lineare Lesereihenfolge (der SMIL-Files) • TOURS (optional): alternative Lesereihenfolgen • GUIDE (optional): Verweise zu fundamentalen Strukturelementen wie

Inhaltsverzeichnis, Vorwort etc. Textual Content File

Ein DTB kann einen Teil oder den gesamten Text einer Publikation als XML 1.0 Datei(-en) konform zur dtbook-2005-1.dtd enthalten (ermöglicht Playern word spelling on demand, Stichwortsuche, feingranulare Navigation, Ausgabe des Textes auf Braillezeilen, Überführung in Großschrift), zusätzlich können modula-re Erweiterungen für Spezialinhalte wie beispielsweise Mathematik in der DTD spezifiziert werden. In der XML-Datei werden Elemente über IDs gekennzeich-net, um diese als bei der Synchronisation zu Audio zu referenzieren.

Audio Files Audiodateien mit durch Menschen gesprochener oder synthetischer Sprache als Aufzeichnung des Dokumenteninhaltes. Audiodateien können in einem DTB in einem oder unterschiedlichen Formaten vorliegen. Unterstützt werden MPEG-4 AAC, MPEG-1/2 Layer III (MP3), Linear PCM - RIFF WAVE Format, außerdem können Annotationen zum DTB als Audiodateien hinterlegt werden

Image Files Bilder in JPEG, PNG oder SVG Format für die Darstellung auf Bildschirmen Synchronization Files

Synchronisation von Text, Bild und Audio mittels einer Untermenge von SMIL 2.0 (dtbsmil-2005-1.dtd). Ein Synchronisation Point ist eine Referenzierung von URIs im Textual Content File und der zugehörigen Stelle in einem Audio File (durch Datei- und Zeitangabe). Synchronisation Points können für die Navigati-



on über ihren Identifier verwendet werden. Die Synchronisation sollte auf Para-graph-, Satz- oder sogar Wortlevel stattfinden. Über customTest ist der Produ-zent auch in der Lage, ausgewählte Strukturen (Seitenzahlen, Annotationen etc.) überspringen bzw. präsentieren zu lassen. Außerdem ist es über escape-Definitionen dem Nutzer möglich Strukturen verlassen zu können. Metadaten zu jedem SMIL-File werden über dtb:generator, dtb:totalElapsedTime und dtb:uid angegeben.

Navigation Control File

Reflektiert die hierarchische Struktur (Kapitel, Abschnitte, Unterabschnitte) des DTBs zur globalen Navigation, sowie für den direkten Zugang zu ausgewählten Elementen wie Seitenzahlen, Annotationen, Abbildungen etc. Der Navigation Control File für XML Applikationen (NCX) ermöglicht dynamische Sichten. Im DTB existiert genau ein NCX, der konform zur ncx-2005-1.dtd sein muss und als erweitertes Inhaltsverzeichnis angesehen werden kann. <!ELEMENT ncx (head, docTitle, docAuthor*, navMap, pageList?, navList*)> Metadaten zur DTB-Struktur können aus dem NCX entnommen werden.

Bookmark/Highlight File

XML-Format für den Export und Import von Lesezeichen und Markierungen (farbliche Unterlegung von Text, Text- oder Audioannotationen).

Resource File Kann alternative oder zusätzliche Informationen zu Media-Bestandteilen eines DTBs angeben. Hinterlegung erweiterter Navigationsinformationen für die Orien-tierung im Dokument

Distribution Infor-mation File

Spezifiziert die Verteilung von DTB-Ressourcen auf Medien (beispielsweise CDs). Mehrere DTBs könnten auf einem Medium abgelegt werden bzw. kann sich ein DTB über mehrere Medien erstrecken. Neben der Allokation der Res-sourcen sind auch Informationen zu Ausgaben bei Medienwechsel referenziert.

Presentation Styles Separate Haltung von Style (Trennung Inhalt und Präsentation) mittels CSS und XSLT. Neben Präsentationen für verschiedene Displaygrößen können auch die Präsentation für Print, Audio oder für eine Braillezeile spezifiziert werden.

Tabelle 4.1: Zusammenfassung der Features eines DTB gemäß ANSI/NISO Z39.86-2005

4.2.2.1 DTB Metadaten Dem Package File sind vorrangig deskriptive Metadaten des DTBs zu entnehmen. Neben dem globalen Identifikator sind im Metadata-Tag die beschreibenden Metada-ten der Ressource. Hierfür wird auf die DCMI Metadata Terms zurückgegriffen. Laut ANSI/NISO Z39.86-2005 Standard sind im DTB alle durch Dublin Core spezifizierten Elemente zugelassen, wogegen in der Praxis zumeist ausschließlich das Dublin Core Metadata Element Set eingesetzt wird. Bibliografische Metadaten sollten laut [MOB08] für den Leser zusätzlich in einem Audiofile ausgewiesen werden, was in deutschen Blindenbibliotheken auch umgesetzt wird (vgl. Kapitel 4.3.3.3). Zusätzlich existieren die X-Metadata im DTB. Dieser eigens für das DTB entwickelte Metadatensatz spezifiziert Informationen zum Multimediatyp des DTBs (audioOnly, audioNCX, audioPartText, audioFullText, textPartAudio, textNCX), die verwendeten Medien (audio, text und image) sowie Angaben über die Quelle, von der das DTB abgeleitet ist. Außerdem werden an dieser Stelle die Vorleser (narrator), der DTB-Produzent und weiterführende Angaben zur Produktion (Version, Änderungen etc.) aufgeführt. Zusätzlich wird die Gesamtlaufzeit des DTB in den X-Metadata gehalten und der eingesetzte Audiostandard definiert. Das DTB ID-Scheme im Metadatenbereich ist für die Zusammensetzung einer URN gedacht, um Kollisionen weltweit zu vermeiden. Selbstverständlich lassen sich im Manifest des Package Files auch zusätzliche tech-nische Metadaten und im Spine Struktur-Metadaten der Manifestation entnehmen.



In der Navigationsdatei (NCX) des DTB sind zusätzlich Metadaten zur Navigationstie-fe (Ebenen des Buches), dem verwendeten Autorenwerkzeug und der Anzahl navi-gierbarer Seiten hinterlegt. In den SMIL-Dateien kann wiederum das Generierungswerkzeug angegeben werden und die vor Abspielbeginn dieser Datei verstrichene Zeit definiert werden. Die Zeit ist dabei auf ein lineares Abspielen des DTB von Beginn an bezogen. Die Navigationsdatei sowie alle SMIL-Dateien müssen zusätzlich mit derselben ID wie der Package File ausgewiesen sein, damit die gemeinsame Zugehörigkeit zu einem DTB ersichtlich ist. Die durch den Medibus-Leitfaden [MOB08] vorgeschlagenen Metadaten weichen von den im ANSI/NISO Z39.86-2005 Standard spezifizierten Datensätzen ab. Stattdes-sen orientieren sich die Metadaten am veralteten DAISY 2.0.2 Standard [DAY01] und dessen Metadaten. Da der Leitfaden derzeit nur als Entwurf für die Umsetzung im deutschsprachigen Raum vorliegt, wird sich der Autor dieser Arbeit auf die im ANSI/NISO Z39.86-2005 aufgeführten Metadaten konzentrieren. Der Autor beabsich-tigt aber, bei der Weiterentwicklung des Leitfadens engagiert mitzuwirken, um eine Optimierung für die Überführung der Metadaten zwischen Bibliotheken zu erreichen. Im Anhang B dieser Arbeit befindet sich außerdem eine tabellarische Übersicht der im ANSI/NISO Z39.86-2005 und DAISY 2.0.2 Standard spezifizierten Metadaten. Die Struktur-Metadaten können vorrangig aus dem NCX entnommen werden. Im NCX sind nicht nur die eigentlichen Ressourcen wie im Manifest aufgeführt, sondern auch die logische Beziehung der Ressourcen und ihrer Inhaltskomponenten zuein-ander ausgewiesen. Auch dem Resource File und dem Distribution Information File können Strukturinformationen entnommen werden. Das Spine spezifiziert die enthal-tene standardmäßige Lesereihenfolge. Durch die Feingranularität in den Textual Content Files und durch die Verwendung von SMIL sind jegliche Abhängigkeiten op-timal nachvollziehbar. Metadaten, die in den Bereich der administrativen Metadaten fallen, überschneiden sich mit den bereits angesprochenen deskriptiven Metadaten. Angaben zu internen Verarbeitungsprozessen werden durch Bibliotheken nicht in der Ressource, sondern im eigentlichen Bibliothekssystem hinterlegt. Außerdem sind den Dateien Angaben zum Erstellungszeitpunkt und zum verwendeten Produktionswerkzeug zu entneh-men. Technische Metadaten sind prinzipiell ableitbar, da neben MIME-Type auch die For-matversionen zugänglich sind. Rechte-Management-Metadaten spielen wie in allen digitalen Publikationen eine im-mer größere Rolle. Da die Rechtslage von DTBs von Land zu Land variiert, sind kei-ne präzisen Mechanismen im Standard spezifiziert. Prinzipiell können Rechte jedoch mittels Dublin Core in der Metadatensektion hinterlegt werden bzw. durch eine zu-sätzliche Audiodatei für den Nutzer bequem zugänglich gemacht werden. [SUL07] weist explizit auf die Schwierigkeiten des landesgrenzenübergreifenden Austausches von DTBs hin, wofür bislang noch keine Lösungen für die Rechteregulierung gefun-den wurden. Bezüglich einer internationalen Vereinheitlichung werden allerdings be-reits erste Schritte unternommen. So fand unter anderem am 24. und 25. Juli 2008 in Washington D.C. ein Expertentreffen mit Vertretern renommierter Organisationen zu diesem Thema statt.



Marketing- oder handelsspezifische Metadaten finden keinen Einsatz im DTB, da der kommerzielle Vertrieb bislang nur in ausgewählten Ländern [SUL07] erlaubt ist. Auch Metadaten zur Langzeitarchivierung haben sich noch nicht etabliert. Allerdings sollen alle Blindenbibliotheken Deutschlands durch den [MOB08] dazu verpflichtet werden, die Audiodateien für zukünftige Migrationen im unkomprimierten Zustand zu archivie-ren.

4.2.2.2 SMIL 3.0 und SMIL 3.0 DAISY-Profile Ende 2008 wurde die Überarbeitung des W3C-Standards zur interaktiven und zeit-gesteuerten Medienpräsentation im Internet fertiggestellt. Die Synchronized Multime-dia Integration Language (SMIL 3.0) ist als Mediensynchronisationssprache in anderen XML-Formaten wie XHTML und SVG integrierbar. Die neuen Funktionalitä-ten gegenüber SMIL 2.1 umfassen unter anderem eine Reihe erweiterter Accessibili-ty-Features [SMIL08]. Im Zuge der SMIL 3.0 Entwicklungen wurde auch ein eigenes DAISY-Profil [DAIP08] geschaffen. Da der aktuelle DAISY-Standard noch auf SMIL 2.0 basiert, hält die überarbeitete dritte Version eine Reihe von zusätzlichen Möglichkeiten bereit. So ist es beispielsweise im SMIL 3.0 DAISY-Profile möglich, jedes Element mit dem Media-Accessibility-Module zu versehen, wodurch alternative Beschreibungen hinterlegt sowie die Reihenfolge bei der Nutzung durch assistive Technologien festgelegt wer-den können. Zusätzlich zu Audio, Text und Bild ermöglicht das DAISY-Profile die Integration von Video sowie Textstreams und Animationen. Textstreams erlauben es, Text samt zu-gehöriger Timing-Infomation auszulagern und Teile des Textes zeit- und ereignisab-hängig beispielsweise als Untertitel für Video zu präsentieren. Die neu eingeführten Medien könnten sich insbesondere positiv für hörgeschädigte und leseschwache Be-nutzer auswirken. Durch die verschiedenen Time Container ist eine verbesserte Medienwiedergabe in Abhängigkeit von aufgetretenen Ereignissen realisierbar. Durch das switch-Konstrukt ist es außerdem möglich, für den Nutzer relevante Medienströme auszuwählen und personalisiert zu präsentieren. Die XHTML-Attribute role und state tragen unter ande-rem dazu bei. Das role-Attribut erlaubt es, Elementen eine semantische Bedeutung zuzuweisen, um anhand der definierten Rolle einen Rückschluss über Präsentation und die Elementverwendung zuzulassen. Das state-Attribut verleiht einem SMIL-Dokument eine komplexere Logik, über die während der Laufzeit Entscheidungen zum Kontrollfluss getroffen werden können. Außerdem existiert ein Metainformation-Module, welches nicht nur erlaubt, dem ge-samten Dokument Metadaten zuzuweisen, sondern auch einzelnen Elementen. In der Augustausgabe des monatlichen DAISY-Newsletter wurde bereits ein geplan-tes Projekt zur Überarbeitung der ANSI/NISO Z39.86 Spezifikation angekündigt.

The revised Standard will address both authoring (master creation) and distribu-tion requirements. [DAIN08]

4.2.2.3 Weiterführende DAISY-Projekte Da es gegenwärtig nicht möglich ist, aus den Textual Content File einen Braille-Druck zu erzeugen, wurde das Projekt Braille in DAISY ins Leben gerufen. Grund dafür ist die problematische Abbildung von Schriftzeichen (ASCII-Code) in sprachab-hängiges Braille. Daher wird im Projekt die Bereitstellung eines Vokabulars für das



Braille-Editing, sowie die Entwicklung eines Drucker-unabhängigen, nicht-proprietären und universellen "embosser ready" Braille-Format angestrebt. Zusätzlich soll ein Framework für die automatische Überführung implementiert werden. MathML in DAISY soll insbesondere für die Zugänglichkeitsgestaltung von mathema-tischen Inhalten in DTBs sorgen. Eine besondere Herausforderung in diesem Kontext liegt in der Entwicklung einer entsprechen barrierefreien multimodalen Interaktions-strategie. Im Projekt DAISY Online Delivery (DOD) beschäftigt man sich mit Thematiken wie der Gestaltung von Infrastrukturen der Anbieter, rechtlichen Grundlagen und Proto-kollspezifikationen. Das im Projekt zu spezifizierende Protokoll soll die Interaktions-weise zwischen Serviceanbieter und DAISY-Lesegerät oder Player definieren, um eine Online-Übertragung zu realisieren. [EBE08] entwickelte auf Basis des SMIL 3.0 DAISY Profiles eine erweiterte DAISY-Spezifikation, die Medien für die Nutzung behinderter Zielgruppen speziell auszeich-net. Die erweiterte Spezifikation dient einer personalisierten Wiedergabe des DTB in einem auf Flash basierenden Web-Player. Ein weiteres interessantes Projekt ist das Urakawa-Projekt, welches die Entwicklung des DAISY SDK - Multimedia Authoring Toolkits verfolgt. Bislang beschäftigte sich das Projekt vorrangig mit der Erstellung strukturierter Videos mit Captioning und Sub-titling Funktionalitäten sowie interaktivem TV-Design (beispielsweise für DVDs), kon-zentriert sich jedoch nunmehr ausschließlich auf DTB-Produktionen im DAISY-Format. Basierend auf dem noch jungen Toolkit wurde bereits ein Werkzeug (Obi) für die Produktion von DAISY 3 audio-only Büchern und ein Werkzeug (Tobi) für die Produktion von DAISY 3 Volltextbüchern implementiert.

4.3 Prozesspartizipierende Organisationen

4.3.1 Deutsche Nationalbibliothek (DNB) Die Deutsche Nationalbibliothek (DNB) ist die zentrale Archivbibliothek und das nati-onalbibliografische Zentrum Deutschlands. Die DNB hat in ihrer Rolle deutschlandweit eine einzigartige Funktion. Sie besitzt die Aufgabe, lückenlos alle deutschen und deutschsprachigen Publikationen ab 1913, im Ausland erscheinende Germanica und Übersetzungen deutschsprachiger Werke so-wie die zwischen 1933 und 1945 erschienenen Werke deutschsprachiger Emigranten zu sammeln, dauerhaft zu archivieren, umfassend zu dokumentieren, bibliografisch zu verzeichnen sowie der Öffentlichkeit zur Verfügung zu stellen [DNB08]. Die DNB (vor 2006 Deutsche Bibliothek) setzt sich aus insgesamt drei Einrichtungen an verschiedenen Standorten zusammen. Die erste dieser drei befindet sich in Leip-zig (gegründet 1912), eine weitere in Frankfurt am Main (gegründet 1947), sowie dem Deutschen Musikarchiv in Berlin (gegründet 1970), welches jedoch in absehba-rer Zukunft nach Leipzig umziehen wird. Die DNB kooperiert eng mit allen nationalen und vielen internationalen Bibliotheken und Organisationen. Sie setzt sich unter anderem stark für Standardisierung und Normierungsprozesse im Bibliothekssektor ein und übernimmt somit eine zentrale Rolle in Deutschland bei der Entwicklung, Einführung und Anwendung verschiedens-ter Regelwerke und Standards.



Bislang werden alle Publikationen in der DNB formal nach den Regeln für die alpha-betische Katalogisierung (RAK) und zum großen Teil auch inhaltlich nach den Re-geln für den Schlagwortkatalog (RSWK) sowie der Dewey-Dezimalklassifikation (DDC) erschlossen.

4.3.1.1 ILTIS Als zentrales Erschließungsinstrument findet das Integrierte Literatur-, Tonträger- und Musikalien-Informationssystem (ILTIS) in der DNB Einsatz. Die ILTIS-Architektur besteht derzeit noch aus drei grundsätzlichen Komponenten. Perspektivisch sind jedoch größere Restrukturierungen im Fokus der Entwicklung. Die ILTIS-Architektur umfasst ein Central Bibliographic System (CBS), welches für die gesamte DNB zum Einsatz kommt und resultierend nicht nur den Geschäftsgang kontrolliert, sondern auch die kompletten Katalogisierungsinformationen hält. Die zweite Komponente ist ein PICA Search & Index (PSI) Stand Alone System, welches den Katalog der DNB und des Deutschen Musikarchivs sowie der Zeitschriftendaten-bank in sich repliziert und nach außen über verschiedene Schnittstellen zugänglich macht. Und als letzte Komponente existiert ein Local Bibliographic System (LBS4) in Leipzig und eines in Frankfurt am Main. Die Lokalsysteme beinhalten jeweils ein Er-werbungs-, Katalogisierungs- und Ausleihmodul für den jeweiligen Standort und bie-ten Nutzern einen Zugriff auf den lokalen Online Public Access Catalogue (OPAC) an. Die Erschließung durch die DNB-Mitarbeiter erfolgt mittels des Katalogisierungs-Client WinIBW auf dem CBS. WinIBW erlaubt Bibliothekaren, ihren vollen Arbeitsauf-gaben komfortabel nachzugehen. Für die Katalogisierung wird durch die Bibliotheka-re das Katalogisierungsformat PICA3 verwendet. PICA+ als Internformat ist lediglich für die interne Verarbeitung vorgesehen und wird aus PICA3 automatisiert generiert. Neben dem intern verwendeten PICA-Standard können für den Datenaustausch di-verse Austauschformate wie MARC 21, MAB2 und Dublin Core generiert werden.

4.3.1.2 Kataloge der DNB Es gibt zwei Arten von Katalogen in der DNB, den regulären Katalog und die Deut-sche Nationalbibliografie. Die Deutsche Nationalbibliografie weist den fertig erschlossenen Bibliotheksbestand der DNB aus und verzeichnet somit alle in Deutschland erschienenen Veröffentli-chungen entsprechend der bibliografischen Erstverzeichnung. Die Deutsche Natio-nalbibliografie wird in regelmäßigen Abständen um neu hinzugekommene Einträge ergänzt. Die enthaltenen Einträge werden seit 2004 bis auf wenige Ausnahmen nach Sachgruppen gemäß der Dewey-Dezimalklassifikation (DDC) klassifiziert. Die Deutsche Nationalbibliografie wird offiziell in Reihen aufgegliedert. Im Folgenden sind die inhaltlich gegliederten Reihen aufgelistet.

• Reihe A: Monografien und Periodika des Verlagsbuchhandels • Reihe B: Monografien und Periodika außerhalb des Verlagsbuchhandels • Reihe C: Karten • Reihe H: Hochschulschriften • Reihe M: Musikalien und Musikschriften • Reihe T: Musiktonträgerverzeichnis



Der eigentliche Katalog der DNB umfasst selbstverständlich auch die Deutsche Nati-onalbibliografie, allerdings ist dieser Katalog auch eine Art Arbeitsinstrument. Das bedeutet, dass in diesem Katalog auch Voranmeldungen und in der Erschließung befindliche Ressourcen bzw. Einträge, die noch nicht in die Deutsche Nationalbiblio-grafie übernommen wurden, ausgewiesen werden. Die zugrunde liegende Datenbank für beide Kataloge ist online zu Recherchezwe-cken als Katalogdatenbank ILTIS für Nutzer frei zugänglich. Die in ILTIS enthaltenen Datensätze sind für die eindeutige Identifizierbarkeit bezüglich der Mitwirkenden und der Schlagworte mit Normdatensätzen verknüpft. Neben dem freien Katalogzugriff wird auch ein kostenpflichtiger Erwerb der Deutschen Nationalbibliografie als Druck-version, HTML und PDF angeboten, welche zu definierten Zeitpunkten reihenabhän-gig publiziert werden. Normdaten sind ein wesentliches Instrument für die Erschließung von Ressourcen und daher ein essentieller Bestandteil der DNB-Kataloge. In diesem Zusammenhang baute die DNB drei Arten von Normdatensätzen auf, die im bibliothekarischen Be-reich sowie beim Aufbau von Wissens- und Informationssystemen im außerbibliothe-karischen Sektor Nachnutzung finden.

• Die Gemeinsame Körperschaftsdatei (GKD) umfasst deutsche und ausländi-sche Körperschaftsnamen gemäß RAK-WB und chronologische und hierarchi-sche Relationen sowie weitere Angaben, die die repräsentierten Körperschaften charakterisieren. Zurzeit enthält die GKD mehr als 1 Million Datensätze.

• Die Personennamendatei (PND) umfasst gemäß RAK-WB angesetzte Perso-nennamen zu vorrangig im deutschsprachigen Raum erschlossenen Werken und dient als Bezugsdatei bei der internationalen Kooperation. Zurzeit befin-den sich 2,6 Millionen Namen in der PND.

• Die Schlagwortnormdatei (SWD) bietet einen normierten, terminologisch kon-trollierten Wortschatz an. Sie enthält Ansetzungs- und Verweisungsformen von Schlagwörtern, die nach den RSWK festgelegt wurden. Die Schlagwörter umfassen alle Fachgebiete und Schlagwortkategorien. Sie werden mittels ISO-Ländercode, ISO-Sprachencode und den Notationen der SWD-Sachgruppen klassifiziert.

Die GKD, PND und SWD sind sowohl online im Rahmen der ILTIS-Datenbank über das Web-basierte Z39.50-Gateway als auch auf der Normdaten-CD-ROM der DNB verfügbar. In einem Kooperationsprojekt der DNB, OCLC und der Library of Congress wird der-zeit eine internationale Normdaten-Kooperation überprüft und schrittweise verwirk-licht. Das VIAF-Projekt sieht vor, die nationalen Normdateien über eine Konkordanzdatei virtuell zu einer internationalen Normdatei (Virtual International Au-thority File) zu verbinden. Normdaten werden in den nationalen Normdateien verteilt und arbeitsteilig erstellt und gehalten. Über die Konkordanzdatei VIAF sind sie wie in einer gemeinsamen physischen Datei weltweit recherchierbar und stehen für die Endnutzerrecherche, den internationalen Datentausch über OAI-Schnittstellen und die gemeinsame Datennutzung zur Verfügung [DNB08].

4.3.1.3 Abgabe von Pflichtexemplaren Der gesetzliche Sammelauftrag der DNB umfasst in Deutschland veröffentlichte Me-dienwerke auf der Grundlage des Pflichtexemplarrechts. Copyright TU Dresden, Alexander Haffner 40


Im Sinne des Pflichtexemplarrechtes heißt ein Exemplar einer Veröffentlichung Pflichtexemplar, welches an bestimmte Bibliotheken abgegeben werden muss. Ablie-ferungspflichtige Medienwerke sind:

• Veröffentlichungen in Papierform, Mikroformen und Tonträger

• Körperliche Medienwerke auf elektronischen Datenträgern

• Digitale Netzpublikationen Der Sammelauftrag der DNB zieht für gewerbliche und nicht-gewerbliche Verleger in Deutschland eine kostenlose Abgabe ihrer Veröffentlichungen an die DNB nach sich. Resultierend sind Verleger von Veröffentlichungen in Papierform, Mikroformen und als Tonträger sowie Verleger körperlicher Medienwerke auf elektronischen Datenträ-gern zur Abgabe zweier Pflichtexemplare an einen regionalbedingt zuständigen Standort der DNB verpflichtet. Die Erschließung und Aufnahme in den Katalog wird am jeweiligen Standort durch-geführt. Nachfolgend soll kurz die Erschließung nicht-musikalischer Exemplare disku-tiert werden. Es existiert ein Referat für den Erwerb, welches das physische Exemplar von den Verlagen einfordert und gegebenenfalls Mahnungen bei Verzug der Ablieferung ver-sendet. Bei Eintreffen des Exemplars wird zuerst eine Formalerschließung durch das zustän-dige Referat vorgenommen. Prinzipiell wird eine komplette Neuerschließung durch die DNB umgesetzt. Verleger haben jedoch die Möglichkeit, kostenpflichtig Voran-meldungen von Neuerscheinungen bei der Marketing- und Verlagsservice des Buch-handels GmbH (MVB) im Verzeichnis lieferbarer Bücher (VLB) anzukündigen. Dieser Datensatz wird durch die DNB vor Erscheinen der Publikation in den Katalog über-nommen, mit Angaben zur DDC angereichert und nach dem Erwerb in der DNB als Basis für die Erschließung verwendet. Nichtsdestotrotz entsprechen die Voranmel-dungen meist nicht den gewünschten Ansprüchen der DNB, was eine Nachbearbei-tung des Datensatzes unumgänglich macht. Da Verlage nicht verpflichtet sind, eine Voranmeldung im VLB vorzunehmen, muss in der Praxis dieser generische Ansatz in der DNB verfolgt werden. Das VLB ist primär dazu gedacht, Händlern eine Recher-chemöglichkeit für bereits lieferbare und in Zukunft lieferbarer Publikationen zu bie-ten. Nachdem das für die Publikation zuständige Referat die Formalerschließung fertig gestellt hat, wird durch das Referat Sacherschließung eine weitere Anreicherung gemäß der gängigen Regelwerke vorgenommen. Während des Erschließungsprozesses werden die angesetzten Angaben immer mit Normdaten verknüpft. Für die prozedurale Organisation in der DNB hinterlegt jeder beteiligte Mitarbeiter eine Statusangabe im PICA-Datensatz, um den Fortschritt der Erschließung auszuweisen. Alle Erschließungsinformationen werden dabei in das CBS und somit in den Zentralkatalog eingepflegt. Nach Beendigung der Erschließung ist der Datensatz zur Publikation in einem Zu-stand, der die Aufnahme in die Deutsche Nationalbibliografie erlaubt. Außerdem wird der Datensatz auch dem MVB für eine akkurate Aufnahme in das VLB zur Verfügung gestellt.



Da die extrem hohe Zahl an Neuerscheinungen stetig wächst, werden derzeit Be-strebungen für eine kooperative Neuerschließung mit den Verbünden sowie für eine gemeinsame Normdatenerhebung unternommen. Im Anschluss an die Erschließung werden die Publikationen in das Magazin einge-pflegt. Jedes nicht-musikalische Exemplar wird zur Erstarchivierung in Frankfurt am Main und zur Zweitarchivierung in Leipzig bzw. umgekehrt hinterlegt. Deutschspra-chige Veröffentlichungen des Auslands, Übersetzungen aus dem Deutschen und fremdsprachige Germanica werden prinzipiell in Leipzig erschlossen und archiviert. Musikalien und Tonträger werden ausschließlich im Deutschen Musikarchiv er-schlossen und archiviert, welches das Zweitexemplar an die Musikalien- und Tonträ-gersammlung der DNB Leipzig zur Archivierung übergibt.

4.3.1.3.1 Ablieferung von Netzpublikationen Zum Sammelgebiet Netzpublikationen gehören alle Darstellungen in Schrift, Bild und Ton, die in öffentlichen Netzen zugänglich gemacht werden [DNB08]. Beispiele hier-für sind elektronische Zeitschriften, eBooks, Hochschulschriften, Digitalisate, Musik-dateien oder auch Webseiten und dynamische Applikationen. Für die Sammlung, Erschließung und Archivierung von Netzpublikationen ist die DNB bestrebt, komfortable Ablieferungsverfahren für die Verleger und Autoren anzubieten. Derzeit umfasst dieses Verfahren die einzelobjektbezogene Sammlung mit Entspre-chung zum Printbereich, wobei jede abgrenzbare Publikation als eigenständiges Werk betrachtet und erschlossen wird. In einem weiteren Schritt werden automati-sierte Verfahren (Crawler) zur Sammlung ganzer Gruppen von Objekten entwickelt. Für die Ablieferung von Netzpublikationen stehen aktuell prinzipiell zwei Möglichkei-ten zur Verfügung.

1. Ablieferung über ein Webformular 2. Ablieferung über OAI-Harvesting

Für die Ablieferung ist es gestattet, Dokumente in verschiedenen Formaten einzurei-chen, wobei über eine Präferenzregelung Dokumentformate ausgewiesen werden, deren Existenz und Zugreifbarkeit gemäß der Langzeitarchivierung garantiert wird. Derzeit präferiert die DNB die Abgabe von PDF, wobei auch die Abgabe von HTML, PS, XML-basierten Formaten, TXT, sowie LaTeX und Office-Dokumenten akzeptiert und die Langzeitarchivierung zugesichert wird. Netzpublikationen die aus mehr als einer Datei bestehen (z. B. HTML-Seiten mit Bil-dern, oder multiple Formate), müssen der DNB prinzipiell in gepackter Form (Archiv-datei) zur Verfügung gestellt werden. In der Archivdatei wird eine Startseite benötigt, die ein Benutzer als erste anwählen kann, um von dieser Datei aus explorativ alle anderen gelieferten Inhalte der Veröffentlichung erreichen zu können. Dies ist nur durch relative Pfadangaben in den Dateien der Archivdatei für das DNB-Archivierungssystem realisierbar, da ansonsten keine Transferfähigkeit gegeben ist. Netzpublikationen werden analog zu gedruckten Publikationen in der Deutschen Na-tionalbibliografie sowie im Katalog der DNB verzeichnet.

4.3.1.3.1.1 Ablieferung mittels des interaktiven Webformulars Für die Ablieferung von monografischen und periodischen Netzpublikationen sowie für Online-Hochschulschriften steht ein auf den Publikationstyp angepasstes interak-



tives Webformular zur Verfügung. Bei der Ablieferung mittels des Webformulars müssen die Angaben zu jeder Publikation manuell eingetragen werden. Die vorzu-nehmenden Angaben sind abhängig von der Publikationsart und für Benutzer des Webformulars in ausführlichen Anleitungen ([AMNW08], [APNW08], [AOHS08]) fest-gehalten. Bei der Ablieferung von periodischen Netzpublikationen wird prinzipiell zwischen Erstmeldung/-lieferung und Folgemeldung/-lieferung unterschieden. Folgemeldungen werden einer Erstmeldung zugeordnet. Nur Publikationen, die innerhalb der nächsten fünf Jahre aktualisiert werden, gelten als Periodika. Ansonsten sind diese Publikatio-nen als Monografien auszuweisen. Ein Periodika weist zeitschriftentypische Struktu-ren (Jahrgang, Band, Heft etc.) auf. Eine Monografie kann zwar auch zu einem Gesamtwerk gehören, wobei es sich jedoch um eine Serie oder um ein mehrteilig begrenztes Werk handelt, was allerdings nicht den Charakteristika einer periodischen Publikation gleich kommt. Bei der Ablieferung von Monografien ist neben den bibliografischen Angaben zur Formal- und Sacherschließung die Datei direkt hochzuladen bzw. durch die Angabe einer URL die Abholung der Datei durch die DNB zu veranlassen. Für die zeitverzögert einzureichenden periodischen Netzpublikationen ist zwar auch eine URL oder ein Persistent Identifier der Originalversion anzugeben, jedoch wird bislang der Transfer nicht automatisch ausgelöst, sondern muss durch den Publizie-renden mittels des File-Transfer-Protocol (FTP) an die Adresse ftp://deposit.d-nb.de/ manuell übertragen werden. Des Weiteren muss der Abliefernde für Monografien und periodische Netzpublikatio-nen die Zugriffsrechte auf das Original im Ursprungsserver festlegen. Hierfür könnte beispielsweise eine kostenpflichtige Zugriffsberechtigung in Frage kommen. Eben-falls müssen die Rechte des Archivexemplars der DNB (z. B. nur im Lesesaal) be-stimmt werden. Die angegebenen Metadaten werden sofort in PICA3 transformiert, um in den Kata-log der DNB aufgenommen zu werden. Anschließend werden die Datensätze immer durch Mitarbeiter der DNB überprüft und an die Erschließungsvorschriften ange-passt, um in die Deutsche Nationalbibliografie aufgenommen werden zu können. Die Ablieferung von Online-Hochschulschriften kann ausschließlich durch die zu-ständige Universitätsbibliothek durchgeführt werden. Die bei der Abgabe von Online-Hochschulschriften vorgenommenen Angaben im Formular werden durch das Sys-tem automatisch in XMetaDiss gewandelt, die daraufhin in PICA3 überführt werden und in den regulären Geschäftsgang der DNB einfließen. Auch hier findet eine ma-nuelle Kontrolle der Datensätze statt. Originalexemplare von Online-Hochschulschriften werden prinzipiell vom Archivsystem der Universitätsbibliothek anhand der URL abgeholt. Da der dauerhafte Zugriff der Ressource auf dem Ur-sprungsserver ebenfalls gesichert werden soll, wird jeder Online-Hochschulschrift ein Persistent Identifier in Form eines Uniform Resource Name (URN) zugewiesen. Unabhängig von der Art der Netzpublikation werden alle Netzpublikationen auf dem Archivserver der DNB abgelegt. Der Archivserver (deposit.d-nb.de) dient als Bereitstellungssystem inklusive Rechte-verwaltung und zur Gewährleistung der Langzeitarchivierung.


ftp://deposit.d-nb.de/


Nach der Übernahme einer Publikationskopie auf den Archivserver findet ein Viren-check und die Berechnung eines MD5-Hashcodes statt, der es erlaubt, die Identität von Dokumentkopien in Relation zu der archivierten Referenzversion zu ermitteln. Alle Netzpublikationen, die in der DNB archiviert werden, benötigen einen Uniform Resource Name (URN). Der URN ist ein Persistent Identifier, der eine Netzpublikati-on auf Dauer und unabhängig vom Ort der Speicherung auf dem Archivserver ein-deutig identifiziert und adressiert. Die DNB betreibt einen URN-Resolver, der alle registrierten URNs verzeichnet. Der Resolver führt die Benutzer zu den Ablageorten (URLs) der jeweiligen Netzpublikation. Den Benutzern steht immer ein Zugriff auf die archivierten Netzpublikationen in Le-sesälen der DNB zur Verfügung. Die Leseplätze für Netzpublikationen haben keinen Internetanschluss und es besteht keine Möglichkeit, die Netzpublikationen auf einem Speichermedium außer Haus zu bringen. Bei Ausdrucken werden die urheberrechtli-chen Bestimmungen beachtet.

4.3.1.3.1.2 Ablieferung mittels OAI-Harvesting Mittels des OAI-Harvesting-Ansatzes wird eine Ablieferung von Netzpublikationen mit möglichst geringem Aufwand angestrebt und durch die DNB bevorzugt in Anspruch genommen. Die Ablieferung über OAI-Schnittstellen eignet sich besonders für größe-re Datenmengen. Für das OAI-Harvesting muss der Ablieferer als Data Provider ein OAI-Repository bereitstellen. Durch die DNB sind obligatorische Katalogisierungsangaben für die Ablieferer vorgeschrieben. Die Übertragung zur DNB wird durch ein Metadaten-Kernset unter Nutzung ausgewählter Metadatenformate ermöglicht. Ein Metadaten-Kernset erlaubt die Standardisierung der Metadatenelemente und garantiert folglich die Interoperabilität zwischen Data Provider und Service Provider. Des Weiteren soll das Metadaten-Kernset die Vereinfachung der Integration zwin-gend notwendiger Metadaten für die Deutsche Nationalbibliografie sichern und eine Langzeitarchivierung elektronischer Ressourcen ermöglichen. Seit April 2008 steht eine OAI-Schnittstelle zur Ablieferung eines Metadaten-Kernsets im Format ONIX for Books 2.1 (Rev. 03) für monografische Netzpublikatio-nen bereit [MKFO08]. Neben einer Vielzahl von obligatorisch anzugebenden Metada-tenelementen, sind zusätzlich eine Reihe fakultativer Metadatenelemente angebbar, um den übertragenen Datensatz zu verfeinern.

• Obligatorische Metadaten: Adresse der elektronischen Publikation zur Abho-lung, Adresse der elektronischen Publikation, Angaben zum Inhalt durch DDC-Sachgruppe der Deutschen Nationalbibliografie oder Warengruppen-Systematik des Deutschen Buchhandels, Art der elektronischen Ressource, Erscheinungsdatum, Rechte / Zugriff auf das Original, Rechte / Zugriff und Benutzungsbeschränkungen auf das Archivexemplar in der DNB, Titel, Verlag / verlegende Stelle, Verlagsort,

• Fakultative Metadaten: Angaben zum Inhalt durch weitere Klassifikationen / Thesauri, Ausgabebezeichnung, Autor, beteiligte Personen, Bemerkungen, beteiligte Organisationen, hierarchische bibliografische Relationen (Gesamt-werk), Hochschulschriftenvermerk, Standardnummer.



Für die Teilnahme am OAI-Verfahren können sich interessierte Ablieferer registrieren lassen, woraufhin die DNB in regelmäßigen Abständen nach Neuerscheinungen an-hand des letzten Abrufdatums auf dem registrierten Data-Repository sucht. Im Anschluss an die Übertragung der Metadatensätze an die DNB werden diese Da-tensätze intern weiterverarbeitet. Weiterverarbeitet bedeutet, dass eine Überführung nach PICA3 stattfindet, um die Daten in ILTIS einzupflegen und die zumeist rudimen-tären Metadaten durch Mitarbeiter überprüfen und anreichern zu lassen. Anhand der enthaltenen Ressourcenadresse im Metadatensatz wird eine Abholung der Netzpub-likation ausgelöst, um ein Archivexemplar in der DNB zu archivieren. Neben der OAI-Schnittstelle für monografische Netzpublikationen existiert bereits seit 2005 eine weitere OAI-Schnittstelle für Online-Hochschulschriften. Als gemeinsamer Metadatenstandard für den Austausch von Online-Hochschulschriften wird durch die DNB XMetaDiss vorgeschrieben. Bislang sind die Universitätsbibliotheken lediglich zur Abgabe von Dissertationen und Habilitationen verpflichtet, wobei ebenfalls obligatorische und fakultative Angaben vorzunehmen sind. Die mittels XMetaDiss abgegebenen personenbezogenen Daten werden bei der Ablieferung in die Personennamendatei (PND) aufgenommen. Resultierend müssen die Universitätsbibliotheken ein Repository mit einer OAI-Schnittstelle anbieten und selbstverständlich diese an die DNB melden, um als Data Provider fungieren zu können. Um der DNB die Arbeit zu erleichtern, muss ein Set zur formalen Einschränkung auf Dissertationen und Habilitationsschriften im Reposi-tory vorhanden sein. In der Zukunft wird durch die DNB auch beabsichtigt, weitere auf Universitätsservern bereitstehende Publikationen zu harvesten. Hierfür würde das Format XMetaDissPlus Einsatz finden. Die an die DNB übertragenen Metadaten in XMetaDiss werden für die Verarbeitung im internen Geschäftsgang der DNB in PICA3 gewandelt, um in ILTIS aufgenommen werden zu können. Für periodische Netzpublikationen existiert bislang keine OAI-Schnittstelle. Allerdings ist auch eine solche in der DNB in Planung. Ebenfalls ist eine OAI-Schnittstelle für die Abholung von Normdaten im Gespräch.

4.3.1.4 Datensatzübernahme aus der DNB Die Deutsche Nationalbibliografie samt PND, GKD und SWD stehen in der ILTIS-Datenbank zur Verfügung, die über eine Anzahl von Mechanismen von der DNB in Form von Metadaten in Austauschformaten bezogen werden können. Eine selektive Datenübernahme einzelner Datensätze ist einerseits über den Daten-shop oder andererseits über DDB-online möglich. Des Weiteren ist ein Zugriff über OAI-PMH fast fertig gestellt. Als der Vorläufer zur OAI-Schnittstelle steht außerdem ein FTP-Zugang bereit, der vorrangig für den Datenbezug durch Bibliotheken dient. Diese Angebote richten sich insbesondere an Kunden, die beabsichtigen, die biblio-grafischen Datensätze maschinell weiterzuverarbeiten. Die Dienste sind kostenpflich-tig und erfordern eine Anmeldung bei der DNB. DDB-online ist die ursprüngliche Möglichkeit für registrierte Anwender in der ILTIS-Datenbank über ein Z39.50-Gateway als Webinterface Datensätze zu recherchieren und selektiert herunterzuladen. Außerdem erlaubt die Z39.50-Schnittstelle Client-Anwendungen wie WinIBW einen direkten Zugriff auf die ILTIS-Datenbank und eine Übertragung selektierter Datensätze in das jeweilige Lokalsystem. Als Nachteil von



DDB-online kann der fehlende Zugriff auf die Daten des Deutschen Musikarchivs sowie die Verwendung von MAB2 als einziges Austauschformat zur Datenübernah-me genannt werden. Der Datenshop bietet registrierten Anwendern die Möglichkeit, webbasiert (mittels des OPAC-Portales) im kompletten Katalog der DNB zu recherchieren und sowohl eine Auswahl aus einzelnen Treffern als auch ganze Trefferlisten als Metadatensätze herunterzuladen. Im Angebot sind die Datenformate MAB2, MABxml, MARC 21 so-wie Dublin Core (oai_dc) [DNBDS08]. Die praktisch auftretende Problematik mit dem Datenshop ist, dass bei einer Datenübernahme ein Applikationswechsel stattfinden muss. Mittels der Z39.50-Schnittstelle und dem entsprechenden Client konnten die Mitarbeiter von DNB-fremden Bibliotheken in einer einzigen Anwendung ihren Auf-gaben nachkommen. Die aus dem Datenshop heruntergeladenen Metadaten müs-sen in diesem Falle nachträglich mit der Client-Applikation wieder in das Lokalsystem eingespielt werden. Mittlerweile wurde in der DNB auch eine Möglichkeit geschaffen, Datensätze der Deutschen Nationalbibliografie selektiv über OAI-PMH zu beziehen, wodurch die DNB der Rolle als Data Provider gerecht wird. Das OAI-Repository der DNB ist über die OAI-Schnittstelle (http://services.d-nb.de/oai/repository) für autorisierte Service Provider zu erreichen, wobei der Harvester sich in einer Endlosschleife immer wieder selbst aufruft (führt dabei einen ListRecords-Befehl aus). Dem Abfragebefehl wird über einen Parameter jeweils der Zeitpunkt des letztmaligen Aufrufs mitgegeben. Auf diese Weise ist gewährleistet, dass keine Änderung verpasst wird, sich Änderungen zeitnah in der Datenbank des Service Providers widerspiegeln, keine für den Service Provider irrelevanten Daten transportiert werden und keine Daten doppelt übertragen werden. Das praktische Angebot der OAI-Schnittstelle für Dritte ist entwicklungstech-nisch bislang noch nicht vollständig für eine Freigabe abgeschlossen. So ist bei-spielsweise der Geschäftsgang für Titel-Änderungen noch nicht abschließend konzipiert. Außerdem werden derzeit Verhandlungen über Nutzungskonditionen ge-führt. Mittels OAI-PMH ist es zwar möglich, anhand spezifizierter Charakteristika der Metadaten Sets als Harvester zu beziehen, jedoch ist es für den Bezug einzelner Records immer notwendig, deren Identität zu kennen. Es ist jedoch nicht möglich, eine Recherche über Metadaten selbst durchzuführen, um Records anhand ihres Inhaltes zu selektieren. So können beispielsweise nicht alle Werke von Schiller se-lektiv geharvestet werden, es sei denn der Data Provider hat diese in einem Set zu-sammengefasst. Search/Retrieve via URL (SRU) ist ein auf der Z39.50-Schnittstelle basierender Standard, der im Rahmen der Initiative Z39.50 International Next Generation (ZING) entwickelt wurde. Mit Hilfe dieses Standards kann die selektive Abfrage anhand von Metadatensatzinhalten über eine Anfrage in der Contextual Query Language (CQL) gewährt werden. Die Antwort wird daraufhin wie bei OAI-PMH in XML über ein HTTP-Response versendet. Aktuell arbeitet man in der DNB an einem Tool namens ISBN2SRU, welches anhand der Eingabe einer ISBN eine SRU-Anfrage beim Ge-meinsamen Bibliotheksverbund (GBV) stellt. Laut einer Ankündigung auf dem Web-log der DNB soll es für den Anfang möglich sein, Anfragen an den Gemeinsamen Verbundkatalog (GVK), den Katalog der Library of Congress und den der DNB zu stellen. Prinzipiell möglich sind jedoch alle Datenbanken, die eine SRU-Anfrage er-lauben und Dublin Core zurückgeben. Eine Ausnahme bilden derzeit die Verbünde, welche sich die Reihen der deutschen Nationalbibliografie in bestimmten Zeitabständen per File-Transfer-Mechanismen herunterladen. Der FTP-basierte Metadaten-Download steht in den gleichen Aus-Copyright TU Dresden, Alexander Haffner 46

http://services.d-nb.de/oai/repository


tauschformaten wie im Datenshop zur Verfügung, wobei die Verbünde bislang alle ihre Metadaten in MAB2 beziehen. Es soll darauf hingewiesen werden, dass trotz der Nutzung von PICA-Systemen in allen Organisationen nie ein Austausch über PICA3 stattfinden würde, da dieses nur ein Internformat ist. Außerdem unterscheiden sich die PICA-Formate der DNB und der Verbünde. Die FTP-basierte Metadatenvertei-lung soll perspektivisch durch die OAI-Schnittstelle ersetzt werden.

4.3.2 Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dres-den (SLUB) Die Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) ging aus der ehemaligen Sächsischen Landesbibliothek und der ehemaligen Universitätsbibliothek der Technischen Universität Dresden hervor. Die Sächsische Landesbibliothek hat ihre Ursprünge bereits im Jahre 1556, als sie von Kurfürst Au-gust als private Sammlung ins Leben gerufen wurde. Im Jahre 1788 wurden die bis dahin archivierten Werke auch der Öffentlichkeit zugänglich gemacht. Die Universi-tätsbibliothek wurde nachfolgend im Jahr 1828 als Wissensportal sowie Lern- und Arbeitsort für Forschung, Lehre und Studium gegründet. Durch die Zusammenführung der beiden Bibliotheken verschmolzen auch deren Be-stände. Heute handelt es sich dabei um einen Gesamtbestand von ca. 9 Millionen Medieneinheiten mit einer einzigartigen Ressourcenvielfalt. Somit bildet die SLUB eine der größten wissenschaftlichen Bibliotheken Deutschlands. Neben Druckschriften werden vor allem Bild- und Tonträger, wertvolle Altbestände, Handschriften und immer mehr elektronische Ressourcen archiviert. Die SLUB ist außerdem eine Sondersammelgebietsbibliothek für Zeitgenössische Kunst ab 1945, Fotografie, Industriedesign und Gebrauchsgrafik sowie Technikgeschichte. Ähnlich der Sammelverpflichtung der DNB ist die SLUB als Regionalbibliothek des Freistaates Sachsen beauftragt, alle in der Region erscheinenden Druckerzeugnisse, die für die Öffentlichkeit bestimmt sind (Pflichtexemplare), zu sammeln und zu archi-vieren. In zunehmendem Maße gehören dazu auch Tonträger und elektronische Me-dien [SLUB08]. Durch breitorientierte Projekte werden in der SLUB außerdem verschiedenste Druck-ressourcen für die Präsentation im Internet digitalisiert und erschlossen. Für die Formalerschließung von im Hause physisch vorhandenen Medien werden in der SLUB Katalogeinträge nach den RAK-WB angesetzt. In der SLUB findet zusätz-lich eine Sacherschließung entsprechend der thematischen Klassifikation nach der Regensburger Verbundklassifikation (RVK) statt. Die RVK ist nicht wie die RSWK für eine vollständige Sacherschließung vorgesehen, sondern dient vielmehr dazu, Medien fachlich für die Katalogisierung zu ordnen und auch entsprechend im Archiv bzw. im Freihandbereich aufzustellen. Das heißt, bei der RVK handelt es sich um eine universelle Aufstellungssystematik. Die RVK umfasst 34 Systematiken für einzelne Fächer, die durch ihre Verfeinerun-gen eine Zuweisung zu bestimmten Fachgebieten unterstützt. Für interessierte Leser stehen die Systematiken auf dem Portal RVK-Online [RVKO08] bereit. Die Signatu-ren der Bücher bzw. Medien bestehen aus den Lokalkennzeichen (Standortnum-mern) und den so genannten Notationen. Die Notation gibt in verschlüsselter Form Auskunft darüber, zu welchem Sachgebiet ein Buch gehört.



Eine vollständige Sacherschließung gemäß RSWK wird durch das Personal der SLUB ausschließlich für die Sondersammelgebiete vorgenommen.

4.3.2.1 Südwestdeutscher Bibliotheksverbund (SWB) Die SLUB ist Mitglied des Südwestdeutschen Bibliotheksverbundes (SWB), wobei erwähnt sein soll, dass diese geografisch gesehen ferne Zugehörigkeit historischen Ursprunges ist. Der SWB bietet als OAI Service Provider Endnutzern eine zentrali-sierte Suche im SWB-Online-Katalog. Bei entsprechenden Rechten wird auch ein unmittelbarer Zugriff auf digitale Ressourcen oder Teile von diesen Endbenutzern gewährt. Für nicht-digitale Ressourcen werden entsprechend lediglich die Formal- und Sacherschließungskriterien wiedergegeben. Die Vorteile des Verbundkataloges liegen in der Nachnutzbarkeit bereits eingepfleg-ter Werke. Im SWB wird von allen aktiven Teilnehmern bei der Einpflege nach RAK-WB und RVK erschlossen, daher kann der Metadatensatz von bereits aufgeführten Einträgen sofort für die eigene Katalogisierung mittels der WinIBW-Software über-nommen werden. Im Lokalsystem der SLUB muss daraufhin nur noch der Inhaus-bestand angehängt werden. Zusätzlich ist im Katalog des SWB ein Fremddatenbereich mit in der DNB und in in-ternationalen Bibliotheken, wie beispielsweise der Britischen Nationalbibliothek, hin-terlegten Katalogeinträgen integriert. Diese Datensätze enthalten zumeist Titelaufnahmen mit RVK-abweichenden Sacherschließungsangaben. Die Datensätze werden durch die Bibliotheken genauso übernommen, jedoch bei Existenz eines ent-sprechenden Exemplars gemäß RVK für die zusätzlich eigene Kategorisierung im Bestand des SWB nachträglich angereichert. Resultierend wird der Fremdbestand sekundär gegenüber dem Eigenbestand des SWB bei der Bestandrecherche durch die Bibliothekare verwendet. Eine Reihe von Fremddatenbeständen werden dem SWB über MARC 21 durch Data Provider zur Verfügung gestellt, die daraufhin für die weitere interne Verarbeitung in PICA gewandelt werden. Falls der Bibliothekar in beiden Beständen keinen adäquaten Titeleintrag findet, muss er die Ressource im Verbundkatalog unter Zuhilfenahme der WinIBW-Software nach RAK-WB und RVK eigenständig katalogisieren. Hierbei ist der Bibliothekar in der Lage, den gesamten Normdatenbestand des SWB nachzunutzen. Auch hat die SLUB das ehrgeizige Ziel, ihren restlichen Zettelkatalogbestand bis 2013 vollständig im digitalen Katalogisierungssystem eingepflegt zu haben. An dieser Stelle soll auch darauf hingewiesen werden, dass es nicht nur Bibliotheka-ren möglich ist, im Verbundkatalog Eintragungen vorzunehmen, sondern es auch Verlagen und Buchhändlern gestattet ist, Datensätze einzupflegen. Die im Verbundsystem durch alle teilnehmenden Parteien vorgenommenen Eintra-gungen werden in periodischen Abständen automatisch über nicht-OAI-spezifische sondern FTP-basierte Download-Mechanismen in das Lokalsystem der SLUB über-nommen. Im Lokalsystem können wiederum die in der SLUB existierenden Exempla-re für die Inventarisierung angehängt werden. Die Inventarisierung der Exemplare der SLUB ist für das Verbundsystem nicht sichtbar. Der SWB weiß lediglich, dass ein Bestand in der SLUB existiert. Hingegen ermöglicht der OPAC des Lokalsystems auch eine Einsicht auf den aktuellen SLUB-Bestand. Nachträgliche Anreicherungen zur Ansetzung dürfen nur im Verbundsystem des SWB vorgenommen werden.



4.3.2.2 Zeitschriftendatenbank (ZDB) Die Zeitschriftendatenbank (ZDB) ist die deutschlandweit zentrale Katalogisierungs-stelle für Titel fortlaufender Sammelwerke, d. h. Zeitschriften, Zeitungen, eJournals usw., aus allen Ländern, in allen Sprachen und ohne jede zeitliche Einschränkung [ZDB08]. Die in der SLUB vorgenommene Katalogisierung unterliegt diesbezüglich einer Aus-nahme, da die Katalogisate primär in der ZDB eingepflegt und nachträglich in den Verbundkatalog des SWB übernommen werden. Die Katalogisierung in der ZDB wird durch das Personal der SLUB ebenfalls über die WinIBW-Software vorgenommen. Als Internformat der ZDB kommt ZETA zum Einsatz, was als verbindliches Format für alle Teilnehmer gilt. Die Datenlieferungen (Export) durch die ZDB an die regionalen Verbundsysteme er-folgt wöchentlich im Maschinellen Austauschformat für Bibliotheken (MAB2), worauf-hin die Datensätze durch den Verbundkatalog auch dem Lokalsystem der SLUB zur Verfügung gestellt werden.

4.3.2.3 LIBERO Als Lokalsystem kommt in der SLUB LIBERO [LIB08] zum Einsatz. LIBERO umfasst Module wie den Benutzerkatalog OPAC, sowie verschiedenste Funktionen zur Kata-logisierung, Ausleihe, Management, Benutzerverwaltung und die angesprochenen Schnittstellen zur Verbundkatalogisierung. LIBERO besitzt eine Schnittstelle, um Datensätze des Verbundkataloges in das Lo-kalsystem zu transferieren. Bei der Übertragung wird nicht nur der eigentliche Daten-satz in LIBERO geladen, sondern auch die damit verknüpften Datensätze. Da das Verbundsystem des SWB auf Basis von PICA-Datensätzen fungiert, wird für die Übernahme in LIBERO aktuell eine Überführung von PICA3 nach MAB2 und per-spektivisch nach MARC 21 vorgenommen. Einzelne Datensätze, die noch nicht über den periodischen Download übertragen wurden, können mittels der WinIBW-Software auch über Knopfdruck sofort in LIBERO eingespielt werden. Die Normdaten bei der Katalogisierung werden dem Bibliothekar im WinIBW-Benutzerinterface bereitgestellt. Die Normdaten werden dabei der regionalen PND und GKD und der überregionalen SWD des Verbundes entnommen. Es handelt sich um regionale Normdaten, da der SWB derzeit noch über einen eigenen Normdaten-bestand für die PND und GKD verfügt, der sich nicht hundertprozentig mit dem der DNB deckt. Grund dafür ist die vorherige Existenz des regionalen Bestandes der PND und GKD gegenüber des überregionalen der DNB. Allerdings sind diesbezüg-lich Projekte in Planung, um eine schnellstmögliche Integration der überregionalen Normdatenbestände der DNB im Verbundsystem des SWB zu integrieren. In LIBERO werden keine elektronischen Ressourcen abgelegt, sondern im Katalog-eintrag ausschließlich Referenzen auf persistente Identifikatoren in externen Archi-vierungssystemen vermerkt. Das bedeutet, LIBERO nimmt für Endnutzer genau genommen die Rolle eines Service Providers mittels des OPAC ein. Da LIBERO selbst keine eigenen digitalen Ressourcen archiviert und der nachfol-gend beschriebene Hochschulschriftenserver nur für Hochschulschriften vorgesehen ist, werden angefertigte Digitalisate durch die SLUB im Verbundssystem katalogisiert und mittels des Göttinger Digitalisierungszentrums (GDZ) archiviert. Das GDZ bietet hierfür ein Dokumentenmanagementsystem an, das einerseits eine kollaborative Ar-beit zwischen beteiligten Organisationen erlaubt, eine Anreicherung der Digitalisate



durch deskriptive Metadaten sowie Struktur-Metadaten ermöglicht (werden in METS zur Verfügung gestellt) und selbstverständlich die Langzeitarchivierung und entspre-chend persistente Zugänglichkeit anbietet. Das zugrunde liegende System trägt den Namen Goobi (Göttingen online-objects binaries), welches in den kommenden Jah-ren weiterentwickelt und etabliert werden soll. Für weitere elektronische Ressourcen des SLUB-Bestandes wie beispielsweise eBooks, umfasst die derzeitige Vorgehensweise lediglich den Erwerb einer lizenzier-ten Zugriffsberechtigung über die URN der Ressource auf dem Archivierungssystem des Verlages oder einer Agentur. Im Laufe der Umstellung auf OPUS (vgl. Kapitel 4.3.2.5) ist es geplant, erworbene digitale Ressourcen redundant im hauseigenen Archivierungssystem abzulegen. Die Verknüpfung von elektronischen Ressourcen und äquivalenten Druckversionen wird noch nicht auf Katalogisierungsebene, wie durch RDA vorgeschlagen, realisiert. Stattdessen wird jede nicht-digitale sowie digitale Ressource als eigenständige Aus-gabe betrachtet, was die Einpflege zweier Katalogisate im Verbundkatalog nach sich zieht. Allerdings wird im LIBERO aus Gründen der Benutzerfreundlichkeit in Katalogeinträ-gen zu Druckversionen, die ein elektronisches Äquivalent im Hochschulschriftenser-ver besitzen, ein Verweis auf die digitale Ressource hinterlegt.

4.3.2.4 Hochschulschriftenserver (HSSS) In der SLUB existiert neben LIBERO noch ein DINI-zertifizierter Dokumenten- und Publikationsserver, über den Autoren und Wissenschaftler der TU Dresden sowie andere Einrichtungen im Raum Dresden, Dokumente in elektronischer Form der Bib-liothek übermitteln können [DEDS08]. Der Hochschulschriftenserver (HSSS) dient der Publikation, dem Nachweis und der langfristigen Archivierung wissenschaftlicher Dokumente. Vorerst war der HSSS für die elektronische Abgabe von Dissertationen und Habilita-tionen entwickelt worden. Mittlerweile werden außerdem Diplom-, Magister-, Master-arbeiten, Forschungsberichte, Proceedings, Preprints, Zeitschriftenartikel und Studien entgegengenommen und archiviert. Die erste Version des HSSS wurde im Jahr 2000 in Betrieb genommen, jedoch 2005 nach steigenden Anforderungen komplett restrukturiert. Zur Weiterentwicklung des Dokumenten- und Publikationsservers der SLUB wurde das Projekt Dresden Enter-prise Document Server (DEDS) gegründet. Ziel dieses Projektes ist die Entwicklung einer universellen und skalierbaren Dokumentenserversoftware. Sie basiert auf den Enterprise Java Standards und Technologien [DEDS08]. Der HSSS ist so gesehen nur eine Beispielinstanz für die Anwendung des DEDS. Der HSSS nutzt als internes Metadatenformat eine erweiterte Dublin-Core-Spezifikation [DEDS08], die für den Austausch mit Dritten auf gemeinsam ausge-handelte Metadatensätze abgebildet wird. Für das problemlose Veröffentlichen elektronischer Publikationen im HSSS werden durch die SLUB diverse Hinweise zur Unterstützung für die formale Gestaltung und technische Aspekte gegeben. Trotzdem ist im Erstellungsprozess immer eine Hete-rogenität bezüglich der Autorenumgebungen und der grundlegenden Dokumenten-gestaltung festzustellen. Derzeit gibt es an der SLUB noch keine spezifischen Richtlinien oder Templates, die gezielt ein einheitlicheres Publizieren aus verschie-denen Autorenumgebungen heraus an der TU Dresden unterstützen. Aus Sicht des



interviewten Personales wäre dies jedoch eine anzustrebende Vorgehensweise, die sich z. B. an der Humboldt-Universität zu Berlin bewährt hat. An dieser Stelle möchte der Autor dieser Arbeit darauf hinweisen, dass durch die Zu-hilfenahme geeigneter Autorenanleitungen neben der formalen Vereinheitlichung auch dokumentspezifische strukturelle Harmonisierungen erreichbar sind. Durch identische Strukturen und entsprechend zugrunde liegendem Markup ist eine auto-matisierte Weiterverarbeitung der Dokumente gegeben. Zusätzlich könnte eine Auto-renanleitung die Autoren dazu anhalten, ihre Publikationen gemäß Basisanforderungen barrierefrei zu gestalten. Der HSSS setzt sich aus einem Kernsystem und vier Webanwendungen zusammen: DEDS-Publish, DEDS-Access, DEDS-Admin und einem Gateway zur Bereitstellung der Metadaten für Dritte. Die Einpflege der Dokumente findet mittels eines Webinterfaces (MetadatenGenera-tor) im DEDS-Publish durch die Publizierenden statt. Dabei nimmt der Publizierende neben dem Dokumentenupload auch die Metadatenanreicherung vor. Für die Ein-pflege werden bibliografische Metadaten zur Dokumentenart, zur Sprache, zum Titel und zum Autor aufgenommen. Für die Sacherschließung muss ein Abstract angefer-tigt und Schlagworte vergeben werden. Nach der Eintragung findet eine erste auto-matisierte Validierung auf Vollständigkeit statt. Durch den HSSS können neben der für alle Dokumente vorgeschriebenen Version im PDF-Format auch die im Autoren-werkzeug erstellten Quelldateien und zusätzliche Programm- und Multimedia-Dateien archiviert werden. Im Anschluss wird der Datensatz zur Publikation durch das Personal der SLUB im DEDS-Admin nochmals auf formale Vollständigkeit geprüft und mit weiteren Metada-ten zur Klassifikation gemäß RVK und DDC angereichert. Da der HSSS ein DINI-zertifizierter Publikationsserver ist, muss aus Internationalisierungsgründen nach der DDC und einer beliebigen weiteren Klassifikation erschlossen werden. Außerdem sind zusätzliche frei wählbare Schlagwörter zugelassen, da diverse innovative und fachspezifische Ansätze nicht ausreichend über die genormten Klassifikationen er-fasst werden können. Die Formalkriterien werden nur bedingt nach RAK-WB ange-setzt. Da es sich bei den Ausnahmen jedoch nur um die Titelangabe handelt, ist dies zwar suboptimal für die Weiterverarbeitung und für den Metadatenaustausch mit Drit-ten, jedoch insgesamt vertretbar. Grund dafür ist die freie Wahl des Autors über die Aufnahme seines Titels im Katalog. Beispielsweise können so eigentliche Zusätze zum Titel im Einheitstitel aufgenommen werden. Die Angaben zu Autoren werden für die Präsentation im OPAC nach RAK-WB angesetzt und für die zukünftig konsistente Verwendung in die Personennormdatei des SWB übernommen. Die zur elektroni-schen Publikation gehörenden Druckversionen werden nicht im HSSS, sondern im Verbundkatalog katalogisiert. Der zuständige SLUB Mitarbeiter initiiert des Weiteren den Metadatenexport. Neben den Metadatenexportschnittstellen besteht auch die Möglichkeit, den Metadatensatz als E-Mail zu versenden. Mit der endgültigen Freigabe wird das Dokument veröffent-licht und im Dokumenten- und Publikationsserver zur Verfügung gestellt. Daraufhin ist über die Rechercheanwendung DEDS-Access eine Suche anhand der Kombination von Metadaten und Volltext möglich. Treffer werden durch die Angabe der Metadaten, den zugehörigen Dateien und der notwendigen User Agents präsen-tiert.



Die gültige Adressierbarkeit und damit verbundene Zitierfähigkeit wird durch die Ver-gabe eines Persistenten Identifikators (PI) realisiert. Konkret wird jedem veröffentlich-ten Dokument eine URN zugewiesen [DEDS08]. Eine URN verweist auf mindestens eine URL des Gesamtobjektes, über die ein Objekt adressiert wird beziehungsweise über eine Liste von URLs zu verschiedenen Kopien des Objektes oder sogar bloß zu Teilobjekten [PI08]. Für die Vergabe einer URN ist es zwingend notwendig, dass die Ressource in der DNB katalogisiert ist oder wird. Für die automatische Vergabe der URN durch die DNB wird durch den HSSS xEpicur verwendet, um URN-relevante Daten an die DNB zu übermitteln. Im DEDS-Gateway befindet sich eine erweiterbare Sammlung von Schnittstellen zum Metadatenexport. Als validierter OAI Data Provider stellt der HSSS über OAI-PMH Metadatensätze weltweit zur Verfügung. Als Standardformat wird im HSSS OAI-DC zum Austausch verwendet. Für die regelmäßige Auslieferung von Metadaten an die DNB wird XMetaDiss und für die Auslieferung an den SWB XMetaDissPlus einge-setzt. Die DNB initiiert im Anschluss an die Metadatentransferierung zusätzlich den Download der zugehörigen Ressource. Eine Ressourcenaggregation wird für die Übertragung gemäß DNB-Bestimmungen in einem im HSSS kreierten Containerfor-mat übersendet. Die an den SWB übertragenen Hochschulschriften-Metadaten wer-den durch die beschriebenen Mechanismen im Anschluss dem Lokalsystem der SLUB zur Verfügung gestellt. Dieser Umweg muss genommen werden, da zwischen dem HSSS und LIBERO keine direkte Verbindung besteht. Für das Bibliotheksportal Sachsen als weiteren Service Provider wurde eine eigene Lösung über HTTP-GET Anfragen und XML-basierten Antworten umgesetzt, da das Portal kein OAI Service Provider ist. Zusätzlich existiert eine Exportfunktion für RefWorks [REFW08] und eine RSS-Feed Schnittstelle mit im HSSS neu erschienenen Publikationen. Um die Webcrawler von Internetsuchmaschinen zu unterstützen, wird ein speziell aufbereiteter HTML-basierter Index aller Dokumente bereitgestellt.

4.3.2.5 Online Publikationsverbund der Universität Stuttgart (OPUS) Der Online Publikationsverbund der Universität Stuttgart (OPUS) ist ein dem HSSS ähnlicher Publikationsserver, der sich jedoch einer weiteren Verbreitung erfreut. Mit ca. 70 nutzenden Universitätsbibliotheken findet das System deutschlandweit Ein-satz. In Bezug auf die Funktionalität für die Einpflege, Archivierung und Zugriffsgestaltung sind der HSSS und OPUS sich insgesamt sehr ähnlich. Intern wird im OPUS ebenfalls für die Metadatenverarbeitung auf ein erweitertes Dublin Core Element Set aufgesetzt. Die aktuelle Version OPUS 3.1 stellt auch eine OAI-Schnittstelle bereit, über die Metadaten in den Formaten DC simple, XMeta-DissPlus, XMetaDiss und xEpicur ausgegeben werden können. Zusätzlich steht eine Importfunktionalität von PICA-Metadaten zur Verfügung. Für die Systemimplementierung wird in OPUS auf PHP zurückgegriffen, wobei über eine konfigurierbare Schnittstelle beliebige SQL-Datenbanken betrieben werden können. OPUS nutzt derzeit für die Abfrage von im HSSS befindlichen Metadatensätzen eine ähnliche HTTP-GET Anfrage wie das Bibliotheksportal Sachsen, die ebenfalls über eine XML-basierte Nachricht vom HSSS beantwortet wird.



Zum jetzigen Zeitpunkt steht bereits fest, dass OPUS in der SLUB den HSSS aus Gründen der Harmonisierung zwischen Universitätsbibliotheken ablösen soll. Aller-dings findet diese Ablösung in nicht absehbarer Zukunft statt, da die SLUB eine auf ihre Bedürfnisse abgestimmte Version abwartet. Da OPUS genau wie der HSSS Open-Source-Projekten unterliegen, werden mit ho-her Wahrscheinlichkeit jedoch beide Systeme nach der Ablösung in der SLUB in ih-ren Communities weiter vorangetrieben.

4.3.2.6 Barrierefreie Internetangebote Sächsischer Bibliotheken Auch die Thematik der Barrierefreiheit ist in der SLUB kein Fremdwort. Neben einem sehgeschädigtengerechten Arbeitsplatz im Haus, setzte man sich intensiv mit der barrierefreien Gestaltung des Webangebotes auseinander. Im Rahmen des Hochschul- und Wissenschaftsprogramms der Bund-Länder-Kommission erfolgte im Projekt „Barrierefreie Internetangebote Sächsischer Biblio-theken“ an allen beteiligten Hochschulbibliotheken eine BIK-basierte Evaluation der Webangebote. Die Evaluation wurde durch Kompetenzträger der DZB Leipzig vorge-nommen. Anschließend wurden aufgedeckte Defizite gemäß den Ansprüchen der Barrierefrei-heit beseitigt und weiterführende Schulungen des Personals zur Sensibilisierung und zukünftigen Integration von Barrierefreiheit im Webangebot durchgeführt. Die Zugänglichkeit von in der SLUB elektronisch publizierten Dokumenten wurde in [ROE05] näher betrachtet. [ROE05] verdeutlichte dabei ebenfalls den Mangel an Richtlinien und Templates bezüglich einer einheitlichen Dokumentenerstellung. Diese unterstützenden Angebote für Autoren würden insbesondere die qualitativ hochwerti-ge Gestaltung von barrierefreien Ressourcen absichern. Des Weiteren wurden in [ROE05] die Vorteile einer qualitativen Validierung von eingereichten Dokumenten diskutiert. Allerdings wurde nicht auf die Unterstützungsmöglichkeiten behinderter Leser durch die Bereitstellung multimedialer Angebote eingegangen. Hingegen wer-den die Vorteile der Markup-basierten Sprachen (beispielsweise Dissertation Markup Language (DiML)) im Autorenprozess bezüglich des gesamten Dokumentenverarbei-tungsprozesses verdeutlicht.

4.3.3 Deutsche Zentralbücherei für Blinde zu Leipzig (DZB) Die Deutsche Zentralbücherei für Blinde zu Leipzig (DZB) besitzt in ihrer Rolle als Bibliothek eine besondere Funktion. Sie dient seit ihrer Gründung 1894 der Versor-gung blinder und sehbehinderter Menschen mit Literatur und Information in geeigne-ter Form. Die DZB soll mit über 8000 Nutzern in dieser Arbeit als Vertreter der Blindenbibliotheken im deutschsprachigen Raum dienen.

4.3.3.1 In der DZB bereitgestellte Medien Da es für sehgeschädigte Leser nicht einfach möglich ist, eine Zeitung oder ein Buch in herkömmlich gedruckter Form zu lesen, sind spezielle Techniken notwendig, um ihnen einen adäquaten Zugang zu gewähren. Louis Braille ermöglichte mittels seiner entwickelten Punktschriftnotation, der so genannten Brailleschrift, den ersten taktilen Zugang zu gedruckter Literatur. Die Notation hat sich über die Jahre bewährt und genießt bis heute große Bedeutung.



Der Punktschrift-Bestand der DZB umfasst alle Bereiche der schöngeistigen Litera-tur, neben Romanen und Erzählungen auch Dramen und Lyrik sowie Kinderliteratur [DZB08]. Für sehbehinderte Leser bewies sich der Großdruck als geeignete Publikationsopti-on. Der vergrößerte Schriftgrad sowie der angepasste Zeilenabstand bilden eine Er-leichterung für die Lesbarkeit von Literatur durch sehbehinderte Benutzer. Mit der Einführung analoger Medienträger wie Tonbänder und Kassetten, die das Aufzeichnen von Information ermöglichten, kamen sehgeschädigte Nutzer erstmals in den Genuss, sich von einem Vorleser aufgelesene Inhalte anzuhören. Im Wandel der Zeit etablierte sich der Computer wie in der gesamten Gesellschaft als nicht mehr wegzudenkendes Arbeitsmittel. Durch diesen Wandel sind seit 1992 eine Vielzahl elektronischer Publikationen veröffentlicht worden. Daher wird der Verleih analoger Datenträger zum 1. Januar 2010 vollständig eingestellt [MED08]. Derzeit befinden sich noch 8000 Exemplare im DZB-Bestand, die schrittweise digitalisiert werden. Als elektronische Publikationsform für die Buch- und Zeitschriftenerstellung setzten sich DTBs im DAISY-Format durch. Die Bedeutung der digitalen Hörbücher hat sich in den letzten Jahren rasant erhöht, da es beispielsweise für im Alter erblindete Men-schen nicht mehr notwendig ist, die Brailleschrift zu erlernen. Die DZB bot Mitte 2008 circa 5500 DTBs zur Ausleihe an. Musik war und ist für viele Blinde ein wichtiger Bestandteil ihrer Erlebniswelt [DZB08]. Die Braillenotenübertragung besitzt daher in der DZB eine lange Tradition. Die Be-sonderheit von Braillenotenschriften im Vergleich zu normalen Noten ist die lineari-sierte Darstellungsform. Im Jahr 2003 enstand das durch das Bundesministerium für Arbeit und Soziales (BMAS) geförderte Projekt DaCapo. Gegenstand des Projektes war es, einen leistungsfähigen computergestützten Braillenotenübertragungsservice (Rückübertragung aus der Blindennotenschrift und Übertragung in Blindennoten-schrift – auch via Scan) zu etablieren. Als digitale Formate für die Übertragung von Noten kommen die Auszeichnungssprachen MusicXML und CapXML zum Einsatz. Als blindengerechte Notation wird BrailleMusicXML verwendet. Allerdings wurde die BrailleMusicXML-Datenstruktur dahingehend erweitert, dass sich Noten für Sehende und Braillenoten in ihr speichern lassen. In der Fortsetzung des Projektes (DaCa-po II) ist es das Ziel, mit Schwarzdruckverlagen zusammenzuarbeiten, um Noten-quellen der Verlage effizient in den Notenübertragungsprozess einfließen zu lassen. Außerdem sollen in Zukunft die Noten mit einer Suchmaschine gefunden werden können. Mitte des Jahres 2008 standen über 5500 Musikalientitel zum Verleih bereit. Neben dem Produktionszentrum für Blindenschrift und Hörbücher (beinhaltet auch Studios zur Aufnahme von DTBs mit menschlicher Sprache) und den Übertragungs-service für Blindenschriftnoten, beherbergt die DZB auch ihren hauseigenen Verlag. Dadurch ist wie bei herkömmlichen Verlagen auch ein kommerzielles Interesse ne-ben der eigentlichen Bibliothekstätigkeit vorhanden. Der Verkauf umfasst Punkt-schriftliteratur, Reliefanfertigungen (beispielsweise geografische Karten), ausgewählte DAISY-Hörbücher, Großdruck, Zeitschriften, TV-Programmservice via Telefon, Musikalien und einiges mehr.

4.3.3.2 Metadatenverwaltung Für die Zusammenführung und Archivierung von verarbeitungsprozessbezogenen Daten (bibliografische Metadaten zu aufbereiteten Ressourcen, Metadaten zur Pro-duktion, physische und technische Inventarisierungsmetadaten und vertriebsrelevan-te Daten) wird in der DZB ein zentralisiertes System betrieben. Copyright TU Dresden, Alexander Haffner 54


Für die Realisierung wurde in der DZB ein eigenes Datenbanksystem entwickelt. Das Lokalsystem basiert auf einem Microsoft SQL Server, der folglich auf die Bedürfnisse der DZB abgestimmt ist. Dadurch ist es möglich, alle Vorgänge im Haus effizient mit-einander zu verbinden. Aufgrund der umfangreichen Metadaten, die im Lokalsystem angelegt werden, wäre ein Export bzw. eine Bereitstellung als Data Provider auf einem hohen Niveau reali-sierbar. Derzeit sind jedoch noch keine externen Exportfunktionalitäten implemen-tiert, da ein entsprechendes organisatorisches Rahmenwerk unter den Bibliotheken fehlt. In den folgenden Abschnitten wird beschrieben, auf welche Weise Metadaten in das Lokalsystem während der Produktion des DTBs, der Katalogisierung und des Aus-leih- und Verteilungsbetriebes eingebracht werden.

4.3.3.3 DTB-Produktion Die Produktion von DTBs ist rechtlich gesehen auf Basis des Urhebergesetzes §45a begründet:

Zulässig ist die nicht Erwerbszwecken dienende Vervielfältigung eines Werkes für und deren Verbreitung ausschließlich an Menschen, soweit diesen der Zu-gang zu dem Werk in einer bereits verfügbaren Art der sinnlichen Wahrneh-mung auf Grund einer Behinderung nicht möglich oder erheblich erschwert ist, soweit es zur Ermöglichung des Zuganges erforderlich ist.

Resultierend ist ein Überführen eines Schwarzdruckbuches in ein DTB nicht geset-zeswidrig, solange es durch Leser genutzt wird, deren sinnliche Wahrnehmung kei-nen Zugang zur Originalversion erlaubt und kein kommerzieller Hintergrund existiert. Da einige Verlage die nicht-gewerbstätige Verbreitung der DZB nicht als solche er-achten, stehen der DZB häufiger keine digitalen textuellen Quelldokumente zur Ver-fügung. Das führt dazu, dass einem Großteil der DZB-Produktionen vorgelesene Inhalte aus Schwarzschriftbüchern in Audiodateien zugrunde liegen und eine zuge-hörige Navigationsstruktur erzeugt wird, aber keine textuellen Inhalte zugewiesen sind. In den letzten Jahren umfasst der Bestand der DZB jedoch auch immer mehr Volltextbücher mit synchronem Audio zum Text. Dieses Kapitel soll die Produktion von DTBs in der DZB näher beschreiben und durchgeführte Metadatenanreicherungen aufzeigen. DTBs werden derzeit ausschließlich im DAISY 2.02 Format unter Zuhilfenahme des Dolphin Publishers (ehemals EasePublisher) erzeugt. Der Dolphin Publisher ist ein professionelles Autorenwerkzeug für die DTB-Erstellung im DAISY 2.0.2 und ANSI/NISO Z39.86 Standard. Das Werkzeug erlaubt es, Textda-teien, HTML-Dateien und Microsoft Word Dokumente als textuelle Quellressourcen zu importieren, um diese in dtbook-Dateien zu transformieren und automatisiert mit generierter synthetischer Sprache zu synchronisieren. Außerdem enthält die Soft-ware Funktionalitäten zur Aufnahme menschlicher Sprache. In der DZB werden die Sprecheraufnahmen im Studio vorgenommen. Um die Auf-nahmen qualitativ hochwertig zu verarbeiten, wird in der DZB auf MAGIX Samplitude zurückgegriffen. Das Recording, Mixing, Editing und Mastering wird somit außerhalb des DTB-Autorenwerkzeugs vorgenommen. Die unkomprimierten Dateien aus Samp-litude werden resultierend in Dolphin Publisher bereits fertig bearbeitet importiert. Für die Langzeitarchivierung bewahrt die DZB die unkomprimierten Aufnahmen auch im hauseigenen Archivierungssystem auf, wandelt sie jedoch für die Auslieferung auf



CD mittels des DTB-Autorenwerkzeuges in das MP3-Format um. Dadurch ist es möglich, Gesamtspielzeiten von 40 Stunden auf nur einer CD abzulegen. Über die interne Sprachaufnahme des Dolphin Publishers ist es möglich, ausgewähl-te Textabschnitte feingranular mit Sprache zu versehen (narrate text as you go). Bei der Importierung externer Audiodateien hingegen ist die Synchronisation zu Text mit hohem Aufwand verbunden. Durch den Dolphin Publisher können zusätzlich Fußnoten, Randbemerkungen (Side-bars), Produktionsanmerkungen und Seitenzahlen in das DTB integriert werden. Auch werden erste Mechanismen für die Integration von Kopierschutzeinbindungen angeboten. Die Struktur des Buches kann selbstverständlich durch den Produzenten spezifiziert, aber auch automatisiert auf Basis des zugrunde liegenden Textes generiert werden. Mit entsprechenden textuellen Vorlagen ist somit prinzipiell mit geringem Zeitauf-wand ein Volltextbuch erzeugbar. Ausgewählte Metadaten werden durch das Autorenwerkzeug automatisch abgeleitet und in die Publikation integriert. Hierzu gehören unter anderem die Hierarchietiefe der globalen Navigation, die Laufzeit, Anzahl der CDs, Audioformat, Datumsangaben der Produktion und navigierbare Seiten. Bibliografische Angaben zu Autoren, Spre-chern etc. müssen durch den Produzenten integriert werden. Im Dolphin Publisher steht dafür eine Funktionalität bereit, jedoch verläuft der Metadatenanreicherungs-prozess in der DZB aufgrund der modularen Abteilungsaufgliederung etwas anders. Die durch das Autorenwerkzeug erzeugten Metadaten wie auch Angaben zu den Sprechern werden zusätzlich vom zuständigen Mitarbeiter in das lokale Datenbank-system eingepflegt. Wie im folgenden Abschnitt beschrieben, pflegt der zuständige Bibliothekar ebenfalls durch ihn erhobene Metadaten in das Lokalsystem ein. Nach der Fertigstellung des DTBs legt der zuständige Mitarbeiter das Buch auf dem lokalen Archivierungssystem ab. Im Anschluss wird über den DAISY-Regenerator ein aus dem Datenbanksystem er-zeugter XML-File mit allen notwendigen Metadaten in das DTB eingespielt. Eigentlich war der Regenerator für die Überführung von DAISY 2.0 DTBs in DAISY 2.02 vorge-sehen und wird somit in seiner Funktion durch die DZB abgewandelt verwendet. Nach der Metadatenanreicherung wird mittels des DAISY 2.02 Validators noch ein-mal die Validierung der Gesamtressource vorgenommen, um sie nach erfolgreicher Validierung als „fertig gestellt“ zu markieren und für die finale Archivierung zu über-nehmen sowie für den Brennvorgang freizugeben. Des Weiteren soll erwähnt werden, dass eine zusätzliche bzw. alternative Metada-tenproduktion mit einer erhöhten Zugänglichkeit für sehgeschädigte Leser mittels der Aufnahme als Audiodateien stattfindet. Die auditiven Metadaten enthalten:

• Allgemeines zum DTB: Angaben zum Urheberrecht und ausführliche Informa-tionen zur Vorlage (bibliografische Angaben und Klappentexte), wobei insbe-sondere auf die Vollständigkeit gegenüber der Quellvorlage eingegangen wird,

• Angaben zur Produktion: welche Einrichtung dieses DTB produziert hat und gegebenenfalls welche Vorlage (z. B. Kassetten, ältere Aufnahme, Fremdmit-schnitt) verwendet wurde sowie Sprecherangaben und Gesamtspielzeit,



• zur Struktur des DTB: DTB-Typ, Gliederung der ersten Buchebene, Anzahl der insgesamt auftretenden Buchebenen und Buchzusatzhierarchieebenen, Navi-gationsmöglichkeiten und strukturelle Abweichungen gegenüber der Vorlage.

Da die DZB ihre Materialien nicht online vertreibt, ist es auch nicht notwendig, URNs von der DNB anzufordern, um dementsprechend das ID-Scheme im DTB zu bele-gen. Da sich diese Arbeit vorrangig mit der Verarbeitung von digitalen Ressourcen be-schäftigt, wird in diesem Kapitel auch nicht auf die Produktion von Punktschriftpubli-kationen eingegangen. Interessenten ist diesbezüglich ein Besuch in der DZB wärmstens zu empfehlen.

4.3.3.4 Bibliografische Metadatenanreicherung Die deskriptiven Metadaten für die Katalogisierung von DTBs im DAISY-Format und Punktschriftliteratur werden in der DZB durch den zuständigen Bibliothekar ange-setzt. Derzeit existiert noch keine Implementierung in der DZB, um in der DNB existierende Metadatensätze automatisiert in das Lokalsystem der DZB zu importieren. Stattdes-sen ist der Bibliothekar gezwungen, die Metadaten der zumeist gedruckten Vorlagen manuell anhand der ISBN im Online-Katalog der DNB zu suchen. Bei einer erfolgrei-chen Auffindung übernimmt der Bibliothekar die dort hinterlegten Metadaten per Co-py&Paste. Für den Fall das kein entsprechender Metadatensatz im Katalog der DNB vorhanden ist (beispielsweise bei Eigenproduktionen), setzt der Bibliothekar die Me-tadaten für die Formalerschließung nach RAK-WB selbst an. Die Metadaten für die Sacherschließung werden, falls vorhanden, ebenfalls durch den Bibliothekar über-nommen, ansonsten durch einen hauseigenen Lektor ergänzt. Als zusätzliche Metadaten für DTBs im DAISY-Format hinterlegt der Bibliothekar alle gemäß Standard notwendigen Angaben, die nicht durch das Produktionszentrum spezifiziert worden sind, wie beispielsweise die hauseigene Bestellnummer, sowie den durch Medibus überwachten eindeutigen Identifikatoren in Form einer Arbeits-gruppennummer (AG.Nr.). Eine Angabe zu den Nutzungsrechten wird nur über die Audioaufnahme realisiert und nicht durch den Bibliothekar oder Produzenten explizit in textueller Form hinzu-gefügt. Auch werden bislang keine Metadaten zu Revisionen der DTBs oder damit verbundenen Versionierungsvermerken angegeben. Es ist insgesamt zu bemerken, dass nur ein Teil der Elemente des Dublin Core Me-tadata Element Sets und der X-Metadata durch die DZB spezifiziert wird. Auslieferungen der DTBs an den Leser basieren auf einem Bestellprinzip (telefonisch oder per E-Mail), woraufhin den Lesern ein Exemplar aus dem verfügbaren Bestand zugesendet wird. Die Bestandsinventarisierung (administrative Metadaten) wird da-bei durch den Bibliothekar vorgenommen. Falls der angeforderte DTB-Titel nicht ver-fügbar ist, muss der Leser sich, gemäß einem Warteschlangenprinzip aller Interessenten, gedulden. Um diesem Engpass zukünftig aus dem Weg zu gehen, soll ein zusätzliches Burn-on-Demand in der DZB zum Tragen kommen. Gegenwärtig wird lediglich ein Festbestand gebrannt. Die Inventarisierung der produzierten und verliehenen DTBs wird wie alle anderen Metadaten zu DTBs im Lokalsystem der DZB archiviert.



Bei der Ansetzung weiterführender Metadaten (zusätzlich zur Vorlage) zu Punkt-schriftliteratur werden Angaben zu der Anzahl der Bände (Punktschriftbücher, auf die sich ein Buch aufgrund der extremen Platzbeanspruchung erstreckt), der physischen Form (beispielsweise Festeinband, Broschüre, Relief), die Art der Braillenotation und des Brailledruckes, sowie einer Bestellnummer für den Verleih vorgenommen. Die folgende Tabelle weist entsprechende Braillenotationen aus. Abkürzung Braillenotation bu buchstäblich kh alte Kurzschrift/einseitig/Handschrift kzp alte Kurzschrift /Zwischenpunktdruck rke reformierte Kurzschrift /einseitig rkzp reformierte Kurzschrift/Zwischenpunktdruck rkzz reformierte Kurzschrift /Zwischenzeilendruck s Text auch in Schwarzschrift ve Vollschrift einseitig Vzp Vollschrift Zwischenpunktdruck vzz Vollschrift Zwischenzeilendruck

Tabelle 4.2: Metadatenansetzung für eingesetzte Braillenotation Für DTBs oder Punktschrift als Verkaufsexemplare wird jeweils anstelle der eigentli-chen Bestellnummer für die Ausleihe eine Bestellnummer für den Verkauf (BNV) auf-geführt und eine Preisinformation hinzugefügt. Diese Angaben könnten daher als handelsspezifische Metadaten betrachtet werden. Die DZB reicht derzeit lediglich Pflichtexemplare erstellter Punktschriftliteratur bei der DNB ein. In der DNB werden diese neu erschlossen bzw. die übermittelten Metada-ten auf den prozessspezifischen Kontext angepasst. Für DTBs und weitere in der DZB bereitgestellte Medien existiert keine Abgabeverpflichtung, wodurch diese Ex-emplare auch nicht in der DNB erfasst werden. Zusammenfassend ist festzustellen, dass die DZB gemäß der in dieser Arbeit einge-führten Metadatenklassifikation deskriptive Metadaten zu allen Publikationen hält. Struktur-Metadaten zu DTBs können nur aus den archivierten Exemplaren abgeleitet werden. Struktur-Metadaten zu Druckschriftbänden umfassen ausschließlich die An-zahl der Bände. Administrative Metadaten dienen vorrangig der digitalen und physi-schen Archivierung und der Ressourcenausleihe. Technische Metadaten werden nicht explizit ausgewiesen, lassen sich jedoch aus den Formaten der digitalen Publi-kationen entnehmen. Metadaten für das Rechtemanagement sind zumeist nur auditiv in DTBS verfügbar, was aber dem angesprochenem Publikum gerecht wird. Metada-ten zur Langzeitarchivierung werden nur bedingt gehalten, könnten jedoch prinzipiell ergänzt werden.

4.3.4 Mediengemeinschaft für blinde und sehbehinderte Menschen e.V. Im September 2004 schlossen sich die „Arbeitsgemeinschaft der Blindenhörbüche-reien e.V.“, die „Arbeitsgemeinschaft der Blindenschriftdruckereien und -bibliotheken e.V.“ und die „Mediengemeinschaft für Blinde und Sehbehinderte e.V.“ zur „Medien-gemeinschaft für blinde und sehbehinderte Menschen e.V. (Medibus)“ zusammen. Produzenten und Bibliotheken, die blindengerechte Medien herstellen und verbreiten sowie die landesweit tätigen Verbände der Blindenselbsthilfe im deutschsprachigen Raum sind dadurch in einem einzigen Verein organisiert [MED08].



Medibus soll in dieser Arbeit als einzelne partizipierende Organisation in sofern her-vorgehoben werden, da durch die Vereinigung der Produzenten sehgeschädigtenge-rechter Ressourcen eine zentralisierte Einheit als Kooperationspartner für die DNB entstehen kann.

4.3.4.1 DTB-Produktionskoordination Medibus strebt in naher Zukunft einen DTB-Bestand von 30.000 Büchern an. Natür-lich soll auch weiterhin eine verstärkte Produktion in anderen Formaten wie bei-spielsweise eText oder eine Ausweitung der Angebote in Brailleschrift sowie Großdruck vorgenommen werden. Der Dachverband Medibus nimmt einerseits eine koordinierende und andererseits eine beratende Position gegenüber seinen Mitgliedern ein. Hierzu gehört unter ande-rem die Empfehlung einzusetzender Standards bei der Produktion von sehgeschä-digtengerechten Medien. Aktuell wird an der Entwicklung einheitlicher und verbesserter Verfahren zur Herstellung zugänglicher Literatur im deutschsprachigen Raum gearbeitet. Dabei wird insbesondere Wert auf einen konsistenten DTB-Bestand im DAISY-Format unter allen Blindenbibliotheken gelegt. Für die Vereinheitlichung der Produktion wird durch die Mitglieder gemeinsam ein Leitfaden für Medibus-OK-Bücher [MOB08] entwickelt. Der Leitfaden enthält neben Richtlinien zur Erstellung der DTBs auch Regeln für die Metadatenauszeichnung in DTBs. Aus Sicht des Autors dieser Arbeit weist der Leitfaden den richtigen Weg für die Zu-kunft, zeigt jedoch eine zu starke Orientierung auf blinde Leser und nutzt nicht die im ANSI/NISO Z39.86-2005 angebotenen Möglichkeiten zur Optimierung der Barriere-freiheit und internationalen Interoperabilität genügend nach.

4.3.4.2 Der Zentralkatalog, das Archiv und die DTB-Distribution Der Ansatz der konsistenten DTB-Erstellung wurde gewählt, um den Aufbau eines gemeinsamen Archivs verschiedener zugänglicher Ausgabeformate zu realisieren. Folglich könnten Ressourcen über eine zentrale Einheit in konsistenter Qualität für Nutzer zugänglich gemacht werden. Des Weiteren wäre eine semi-automatisierte Langzeitarchivierungsstrategie anwendbar. Derzeit wird noch an einem zentralisierten Modell für den Austausch von DTBs in-nerhalb von Medibus gearbeitet. Insgesamt wird das Ziel verfolgt, dass im deutsch-sprachigen Raum jeder Nutzer auf jedes Buch in einfacher Weise schnell zugreifen kann. Der Medibus-Katalog (http://medibus.blista.de) bietet Nutzern bereits eine zentrali-sierte Recherchemöglichkeit mit stetig wachsendem Angebot über allen Medibus an-gehörenden Blindenbibliotheken. Der physische Zugriff ist vorerst über dezentrale Bestellvorgänge angedacht. Das bedeutet, dass ein Leser bei seiner (lokalen) Blindenbibliothek bestellt und für den Fall, dass das Werk an dieser nicht vorrätig ist, wird über bibliotheksinterne Fernlei-hen eine Ausleihe für den Leser ermöglicht. Allerdings sind auch erste Techniken im Bereich von Download und Streaming in Entwicklung, jedoch sind vor einer Inbe-triebnahme die urheberrechtlichen Rahmenbedingungen zu klären. Eine potentielle Möglichkeit bestünde in einem Abschluss einer entsprechenden Zielvereinbarung mit dem Börsenverein des Deutschen Buchhandels.


http://medibus.blista.de/


Die zentralisierte Archivierung des gesamten DTB-Bestandes auf einem System soll laut Aussage des Medibus-Vorsitzenden Herrn Wendling perspektivisch ebenfalls die Ausleihe der DTBs zentralisieren. Durch Burn-on-Demand-Mechanismen könnte re-sultierend an alle Nutzer zeitnah eine Auslieferung stattfinden.

4.3.4.3 Medibus und Metadaten Der globale Medibus-Katalog stellt ein hohes Potential für die einheitliche Haltung aller Metadaten bereit. Für die praktische Umsetzung soll der bibliografische Teil der Metadaten für eine zu veröffentlichende Publikation nach der notwendigen Produk-tionsgenehmigung und vor der eigentlichen Produktion durch Bibliothekare von Me-dibus erstellt werden. Grund dafür ist, dass nicht alle DTB-Produzenten über Fach-personal aus dem Bibliothekssektor verfügen und somit fehlerhafte Ansetzungen umgangen werden können. Bislang wurden noch keine Absichten erklärt, den bibliografischen Metadatensatz des Ursprungswerkes von der DNB zu beziehen, obwohl diese Herangehensweise für eine national konsistente Metadatenbereitstellung zwingend notwendig wäre. Des Weiteren ist ein Softwarewerkzeug für die Hinzufügung, Bearbeitung und Vali-dierung der Metadaten in den zu publizierenden Ressourcen in Entwicklung. Das so genannte Medi-Meta-Tool soll es ermöglichen, manifestationsspezifische Metadaten an Medibus durch den Produzenten zurückzumelden. Derzeit erfolgt die Rückmel-dung nach der Fertigstellung einer DTB-Produktion durch die Blindenbibliotheken an Medibus über E-Mail-Verkehr. In der DZB würden somit höchstwahrscheinlich bibliografische Metadaten zu einem Werk in das Lokalsystem übernommen werden und Metadaten zur Manifestation durch die DZB lediglich hinzugefügt werden. Die zusätzlichen Metadaten könnten somit zuerst (in der elektronischen Ressource) validiert werden, um sie anschließend an Medibus zu übersenden. Für kleinere Bibliotheken bzw. DTB-Produzenten soll das Tool die direkte Einpflege der bibliografischen Metadaten in das DTB realisieren und die Validierung und den Export der zusätzlichen Metadaten des DTBs an Medi-bus direkt übernehmen. Bislang sind die Blindenbibliotheken ausschließlich zur Meldung von Punktschriftlite-ratur an die DNB verpflichtet. Medibus hingegen muss der Meldepflicht aller aufberei-teten Werke gegenüber der VG Wort nachkommen. Das Kapitel 6 wird verschiedene Ansätze zu Metadatenaustauschstrategien diskutie-ren, die unter der Einbeziehung von Medibus automatisierte und vor allem wohl strukturierte Metadatenverarbeitungsprozesse realisieren können.


Metadatenanreicherung im digitalen Publikationsprozess Barrierefreiheit und Metadaten

5 Barrierefreiheit und Metadaten Barrieren in Bibliotheksumgebungen können für betroffene Benutzergruppen schnell unüberwindbar werden. Menschen mit besonderen Bedürfnissen sind bei der Nach-nutzung von barrierehaltigen Ressourcen zumeist auf die Hilfe Dritter oder techni-scher Hilfsmittel angewiesen. Dadurch möchten sich diese Benutzer lieber im Vorfeld über das Angebot informieren, um sich auf die resultierende Vorgehensweise einzu-stellen. Das Potential von barrierefreien Ressourcen wurde im Abschnitt 4.2 bereits hervorgehoben. Nun stellt sich die Frage, wie man diese in die Bibliothek einbinden und vor allem für den Leser auffindbar und nachnutzbar machen kann. Anhand des Suchverhaltens eines Benutzers soll im Folgenden diskutiert werden, wie eine Suchanfrage und Suchergebnisexploration im Allgemeinen vollzogen wird und wie die Auffindung von barrierefreien Ressourcen hierbei einbezogen werden kann. Die Suche mittels der primären bibliografischen Einträge hat sich für Benutzer der digitalen Bibliothekskataloge bewährt. Auch Menschen mit besonderen Bedürfnisen können entsprechend ihrem Sprachumfang diesen Sucheinstieg nutzen und von ihm profitieren. Die Grundvoraussetzung ist jedoch, dass die Bibliothek eine zugängliche Benutzerschnittstelle für die Suche und Ergebnispräsentation anbietet. Der Schritt der Suchergebnispräsentation ist besonders interessant, da man zumeist als Benutzer nach beschreibenden Attributen zu einem Werk sucht. Resultierend werden verschiedene Expressionen und zugehörige Manifestationen angezeigt. Zu diesen Manifestationen kann ein klassisches Regalexemplar, ein PDF-Dokument, eine verkürzte Hörbuchversion auf Audio-CD, ein DTB und eventuell noch weitere Manifestationen gehören. Ein Leser mit besonderen Anforderungen, kann sich seiner Wünsche gegenüber der Manifestation bewusst sein und möchte daher die für die barrierefreie Nachnutzung relevanten Informationen über die entsprechenden Mani-festationen präsentiert bekommen. Diese Informationen werden im Folgenden als Accessibility-Metadaten eingeführt. Der gegenläufige Ansatz zur klassischen Suche besteht in der Vorselektion eines Expressions- und/oder Manifestationstyps mit definierten Eigenschaften. Als blinder Leser würde man sich beispielsweise prinzipiell gegen in Schwarzschrift gedruckte Ressourcen entscheiden. Ein sehbehinderter Leser könnte in Hinsicht auf gedruckte Ressourcen eine Mindestschriftgröße bzw. für elektronische Ressourcen die Schrift-skalierbarkeit als Einschränkungskriterium formulieren. Hörgeschädigte Benutzer hingegen ziehen Ressourcen mit einfacher Sprache unabhängig von der physischen Präsentation oder digitale Medien mit synchronisierter Gebärdensprache vor. Ab-hängig von der Tatsache, ob zusätzlich nach bibliografischen Attributen gesucht wurde, wird eine eingeschränkte Manifestationsauswahl zu einem Werk bzw. einer Liste von Werken zur Exploration dem Nutzer als Suchergebnis präsentiert. Man spricht bei dieser Vorgehensweise auch von profilspezifischer Suche. Die Verwen-dung von Benutzerprofilen kann außerdem zur Adaptierung der Ressource selbst und zur Adaptierung der Benutzerschnittstelle beim Konsum der Ressource nachge-nutzt werden. Folglich ist festzuhalten, dass alle alternativen Expressionen bzw. Manifestationen unterschiedlicher Expressionen zu einem Werk zueinander in definierten Beziehun-gen stehen müssen. Dieser Ansatz reflektiert die im FRBR Model spezifizierten Kon-zepte. Der hier verfolgte Ansatz verlangt zusätzlich, dass jede Manifestation bzw.



deren Einzelressourcen weiterführend mit für sie relevanten Accessibility-Metadaten versehen sind. In diesem Kapitel soll in Anlehnung an diesen Gedankengang zuerst ein Blick auf standardisierte Metadatenformate zur Auszeichnung von Barrierefreiheit geworfen werden, um diese im Weiteren mit dem Entitätskonzept aus RDA und dem FRBR Model zu verbinden. Zusätzlich wird ein in dieser Arbeit entwickelter Strukturierungs-ansatz für Manifestationen eingeführt. In diesem Strukturierungsansatz können logi-schen Struktureinheiten einzelne Dateien oder Teile dieser sowie Accessibility-Metadaten zugewiesen werden. Abschließend wird eine mögliche Serialisierung der Metadaten für den Austausch zwischen Bibliothekssystemen konzipiert und disku-tiert.

5.1 Accessibility-Metadaten

5.1.1 IMS AccessForAll Meta-data (ACCMD) IMS AccessForAll Meta-data (ACCMD) beschreibt Accessibility-Properties eines Lernobjektes (Resource Profile), wobei zusätzlich noch ein IMS Learner Information Package Accessibility for LIP (ACCLIP) die Anforderungen zur Barrierefreiheit eines Lerners beschreibt (User Profile). Das verfolgte Ziel ist es, die Lernumgebung durch die Spezifikationen an die Bedürfnisse des Benutzers anpassen zu können. Accessibility-Metadaten können im Allgemeinen für zwei Accessibility-bezogene Zwecke verwendet werden [ACCMD04]:

1. um die Einhaltung von Accessibility-Spezifikationen oder Accessibility-Standards zu definieren oder

2. um die Auslieferung von Ressourcen zu ermöglichen, die den Nutzerbedürf-nissen und –einstellungen gerecht werden.

Die AccessForAll Meta-data Spezifikation deckt dabei nur den zweiten Aspekt ab. Das bedeutet, dass anhand der ACCMD einer Ressource überprüft wird, ob sie fähig ist, den Angaben des ACCLIP gerecht zu werden.

The AccessForAll Meta-data specification groups resources into two possible categories: primary resources and equivalent alternative resources. [ACCMD04]

Primary Resources sind die Default-Ressourcen. Metadaten der Primary Resource umfassen die Ausweisung der Modalität für die Ressourcennutzung, Steuerungs- und Anzeigeadaptierbarkeit und die Existenz von äquivalenten Alternativversionen. Da es Produzenten von Primary Resources oft am notwendigen Fachwissen fehlt bzw. sie nicht genügend Verständnis für Barrierefreiheit aufbringen, werden die not-wendigen Accessibility-Metadaten in der Praxis wohl eher durch Mitarbeiter der ar-chivierenden Organisation bzw. durch Produzenten barrierefreier Alternativressourcen hinzugefügt. Equivalent Alternative Resources stellen die gleiche Semantik und ein ähnliches Verhalten in alternativer Form bereit. Die Produzenten dieser Ressourcen sind mit den Accessibility-Anforderungen vertrauter und daher die Metadaten dementspre-chend detailliert auf das ACCLIP abgestimmt.

Equivalent alternative resources are of two types: supplementary and non-supplementary. [ACCMD04]

Wie der Name es schon verrät, reichert eine Supplementary Resource seine zugehö-rige Primary Resource an (z. B. wenn ein Video ergänzende Captions enthält), wo-gegen eine Non-Supplementary Resource eine Ersetzung darstellt. In den Metadaten



der alternativen Ressourcen wird festgehalten, welche Modalität der Primary Resour-ce ersetzt wird und mittels welcher Modalität die Equivalent Alternative Resource selbst konsumiert werden kann. Resultierend kann eine Primary Resource jeweils mehrere Equivalent Alternative Resource referenzieren und folglich über alternative Modalitäten zugänglich gemacht werden. Ablauftechnisch gesehen, können durch die Resource Profiles der Primary Resour-ces Materialien mit angemessener Adaptierbarkeit (gemäß einem gegebenen Kon-text) bzw. mit benötigter Accessibility-Unterstützung gefunden werden. Gegebenenfalls muss die Steuerung und Anzeige der Ressourcen auf die Nutzerbe-dürfnisse angepasst werden. Falls keine Nutzung durch Anpassung der Primary Re-source möglich ist, muss auf die alternativen Ressourcen, die sich mit den Anforderungen des ACCLIP decken, ausgewichen werden. Das zugrunde liegende Information Model ist im Anhang C.1 anhand eines UML-Diagrammes verdeutlicht. Dem UML-Diagramm können die Beziehungen zwischen Primary Resource und Equivalent Alternative Resources entnommen werden. Die Nutzungsmodalitäten einer Primary Resource werden anhand von Attributen ausgewiesen. Mittels der Evaluation and Report Language (EARL) wird die Reprä-sentationstransformationsfähigkeit (display transformability) und Kontrollflexibilität (control flexibility) einer Primary Resource spezifiziert. Bezüglich der Equivalent Alternative Resources wird dargestellt, ob das Äquivalent eine Supplementary oder Non-Supplementary Resource ist, wobei jeweils der Bezug zur Primary Resource bzw. zu einem spezifizierten File dieser geschaffen wird. Die angebotenen Alternativen werden prinzipiell in drei Arten unterschieden: Alternativen zu auditivem, textuellem und visuellem Inhalt, wobei die einzelnen Arten mit alterna-tiven Inhalten angereichert werden bzw. über Eigenschaftsangaben ihre Zugänglich-keit definieren. Für die syntaktische Umsetzung der Spezifikation wird auf XML-Bindings zurückge-griffen. An dieser Stelle soll jedoch darauf hingewiesen werden, dass ACCMD kein Cross-Domain Metadatenstandard ist, sondern vorrangig auf Lehrmaterialien und den ent-sprechenden Lernkontext ausgelegt ist.

5.1.2 Dublin Core AccessForAll (DC-AfA) Benutzer haben besondere Bedürfnisse, die aus der Wahl eines bestimmten Endge-rätes, eines User Agents, Umgebungsgegebenheiten und/oder aus einer Behinde-rung resultieren können, wobei der Kontext der Lernumgebung nur ein exemplarisches Zugriffsszenario im digitalen Dokumentenkonsum darstellt. Die Dublin Core Metadata Initiative stellte sich entsprechenderweise in den letzten sieben Jahren hohe Ansprüche, um einen kontextübergreifenden Metadatensatz für die Auszeichnung von Accessibility zu erschaffen. Insbesondere mit dem verstärkten Aufkommen von Informationen auf mobilen Endgeräten wuchs in vielen DC-Communities das Interesse an Metadaten für adaptierbare, transformierbare und al-ternative Inhalte sowie der Beschreibung individueller Benutzer und Nutzungskontex-ten. Die Accessibility Working Group betrachtete während ihrer anfänglichen Arbeit alle existierenden DC-Terms, wobei sie feststellen musste, dass diese nicht ausreichend für die Auszeichnung der Barrierefreiheit von Ressourcen geeignet sind.



AccessForAll is a new strategy for matching resources to the needs and prefer-ences of individual users… AccessForAll is a general accessibility strategy and the task for the DC community is to develop application profiles so AccessForAll can be realised across all domains in an interoperable way. [AFA08]

Die ursprüngliche Arbeit zu AccessForAll entstand im Adaptive Technology Resource Centre der University of Toronto und durch das IMS Global Learning Consortium in der AccessForAll Meta-data und Accessibility for LIP Spezifikation. AccessForAll wird für den Lernkontext 2008 durch die ISO JTC1 im ISO/IEC 24751 standardisiert. Im Oktober 2008 wurden bereits die ersten drei Teile verabschiedet. Diese Teile umfassen neben einer Einführung die Beschreibung von Nutzerbedürf-nissen und Einstellungen für digitale Ressourcen sowie eine Vorschrift für die Res-sourcenbeschreibung selbst. Teil 4 und 5 werden sich mit der Beschreibung von nicht-digitalen Ressourcen, Teil 6 und 7 mit der Beschreibung von Events und Orten und Teil 8 mit Sprachen auseinandersetzen, um passende Gegebenheiten zu defi-nierten Nutzerbedürfnissen anbieten zu könnnen.

The term has been carefully re-modeled from the ISO/IEC version to be used in conjunction with existing DC terms. [AFANE08]

Der besondere Nutzen von DC-AfA resultiert aus dem bereits weit verbreiteten Ein-satz von DC-Metadaten. DC-AfA kann in die bestehenden Schemas eingebunden werden. Grund dafür ist, dass alle DC-Metadaten zum DC Abstract Model kompatibel sind. Das Accessibility-Modul könnte somit leicht in neuen Domänen integriert wer-den und der Unterstützung der Nutzerbedürfnisse bei der Auswahl und Adaption von angebotenen Ressourcen und Inhalten dienen.

In other contexts, there are specifications and standards for the structuring, en-coding and organisation of content that aim to improve the accessibility of that content. The AccessForAll approach is concerned only with description of the resource making explicit any accessibility characteristics, and the exploitation or re-use of metadata in both local and distributed environments. [AFANE08]

Im Rahmen der Entwicklung der Term-Empfehlung wurde auf Basis des DCMI Abs-tract Model ein Application Profile Abstract Model erstellt, um zukünftige Application Profiles daran auszurichten. Das entsprechende UML-Diagramm befindet sich im Anhang C.2. Beabsichtigt ist die Generierung eines Personal Needs and Preferences Profile (PNP) und ein Profil für Ressourcencharakteristika namens Digital Resource Description (DRD). Im Zentrum des Application Profile Abstract Model steht die Ressource, wobei das Modell nicht explizit ausweist, welche der Ressourcen die primäre Ressource ist. Stattdessen wird davon ausgegangen, dass ein Zugriff auf eine Ressource stattfindet und gemäß der Nutzerbedürfnisse eine Alternative oder Zusätze gesucht bzw. An-passungen vorgenommen werden sollen. Jeder Ressource werden ein Format (Accessibility-Format), ein Typ (Art der Accessi-bility-Unterstützung), eine Sprache, eine Reading-Rate und ein Education-Level zu-geordnet. Bezüglich der Flexibilität (keyboard only control, mouse only control, variable font size, variable font face, variable foreground colour, variable background colour, variable cursor, variable highlight, variable layout, variable reading rate, struc-tured presentation) werden Aussagen über Adaptierbarkeit und Steuerbarkeit hinter-legt. Mittels Support-Tool ist es möglich, Werkzeuge zu spezifizieren, die auf die Ressource angewandt werden können.



Der Grundgedanke ist jedoch mittels des globalen Accessibility-Tags (im Application Profile Access Model noch als Adaptability ausgewiesen, wurde durch die Arbeits-gruppe im aktuellen Draft ersetzt) eine Aussage zur Barrierefreiheit der Ressource (allTextual, auditoryOnly, hapticOnly, visualOnly, brailleOnly, tactileOnly, olfactoryOn-ly, hazard) allgemein zu treffen, um zusätzlich jeder Ressource über AccessMode eine oder mehrere Benutzungsmodalitäten (auditory, tactile, textual, visual, braille, haptic, olfactory, flashing hazard, sound hazard, ornamental content) zuzuweisen. Über Role wird entsprechend festgehalten welche Modalität durch den AccessMode ersetzt wird. Mittels hasFormat/isFormatOf kann die Ressource ausweisen, ob eine zweite Res-source mit dem selbem Inhalt, aber in einem anderen Format existiert. Strukturelle Abhängigkeiten können über hasPart/isPartOf definiert werden. Somit ist es möglich, eine Ressource als Komponente einer anderen auszuweisen. Weitere strukturelle Beziehungen können über hasAdaptationOf/isAdaptationOf festgelegt werden. Re-sultierend ist indirekt die primäre Ressource erschließbar, wobei Adaptierungen als von dieser abgeleitet ausgewiesen werden. Da die Terms des AfA Accessibility Metadata Modules derzeit lediglich als Draft vor-liegen, ist es schwierig, konkrete Aussagen zur Qualität im praktischen Einsatz zu schlussfolgern. Aus Sicht des Autors dieser Arbeit stellt der Entwurf jedoch ein viel-versprechendes Konzept dar, das kontextübergreifend etabliert werden kann. Das Internet Scout Projekt Collection Workflow Integration System (CWIS, http://scout.wisc.edu/Projects/CWIS/) ist ein erstes Projekt, das versucht, die Acces-sibility-Metadaten in ein digitales Bibliotheksportal zu übernehmen, um potentiellen Nutzern das Auffinden von adäquaten Ressourcen zu erleichtern.

5.2 Metadaten zur Aggregation In dieser Arbeit wurde bereits eingeführt, dass entsprechend dem FRBR Model prin-zipiell von Werken ausgegangen wird. Das folgende Konzept wird diese Idee aufgrei-fen, um über allen Expressionen zu einem Werk einen gemeinsamen Sucheinstieg zu schaffen und die gegebenen Manifestationen aller Expressionen in untergeordne-ter Art zueinander in Beziehung zu setzen. Der Ansatz für die Beziehungsspezifikati-on soll dabei ebenfalls auf Metadatenebene geschehen.

work: Angels & demons / Dan Brown

expression 1: original edition …

expression 5: Illuminati / Überset-zung aus dem Ameri-kanischen von Axel Merz

expression 2: audio book / nar-rated by Richard Poe

expression 3: Braille print

expression 4: Digital Talking Book / narrated by Jack Fox

manifestation 1a: Angels & demons / Dan Brown. New York, Pocket Books c2000. 430 p : maps : 25 cm. ISBN: 0671027352

manifestation 1b: Angels & demons : [ebook] / Dan Brown. New York, Atria Books 2004. com-puter file : 899 KB : Adobe PDF. ISBN: 0743412397

manifestation 4a: Angels & demons [sound recording] / Dan Brown. Washington, D.C. : National Library Service for the Blind and Physically Handi-capped, Library of Congress, 2006. (APH, recording studio, 17 hours, 27 minutes) DB 51799

Abbildung 5.1: Beispiel für die Entitätsaufgliederung nach dem FRBR Model


http://scout.wisc.edu/Projects/CWIS/


Abbildung 5.1 verdeutlicht anhand von Dan Browns Bestseller Angels and Demons wie eine Aufgliederung gemäß der Entitäten des FRBR Model aussehen kann. Das Werk bietet für alle Expressionen einen gemeinsamen Einstiegspunkt, wobei Expressionen als die intellektuelle bzw. künstlerische Realisierung eines Werkes in-terpretiert werden. Expressionen unterscheiden sich durch den Inhalt (Originaltext, gekürzte Ausgabe, Übersetzung) sowie nach der Ausdrucksform (auditive Repräsen-tation, multimediale Repräsentation). Die erste Expression bildet die durch Dan Brown realisierte Textform ab, welche in zwei verschiedenen physischen Umsetzungen als Manifestation vorliegt. Die Mani-festation 1a entspricht einem gedruckten Buch und Manifestation 1b stellt die physi-sche Umsetzung derselben Expression in PDF dar. Zu dieser Expression werden auch alle textuellen Manifestationen zugeordnet, die als Resultat einer Transformati-on während einer Migration für die Langzeitarchivierung aus einer zur Expression zugehörigen Manifestation erzeugt wurden. Die zweite Expression ist in auditiver Form und daher eine eigenständige Realisierung. Veröffentlichungen in Brailleschrift werden vom FRBR Model als Übersetzungen betrachtet und resultierend sind die Punktschriftversion wie auch die Übersetzung durch Axel Merz ins Deutsche, eigen-ständige Expressionen. Ebenfalls wird ein DTB im DAISY-Format als unabhängige Expression betrachtet, da es eine multimediale Realisierung des Werkes ist. Die vierte Ebene des FRBR Model (nicht im Beispiel enthalten) spezifiziert das ei-gentliche Exemplar. Somit können u. a. Aussagen zu verschiedenen Standorten der Druckversionen in Bibliotheken getroffen werden oder verschiedene digitale Kopien des DTB aufgeführt werden. Für die Ausweisung von Barrierefreiheit müssen nun Beziehungen zwischen Mani-festationen geschaffen werden, um beispielsweise festzuhalten, welche Manifestati-on bei der Erstellung des DTB als Vorlage diente. Derzeit existiert noch kein Metadatenstandard, der die Entitätsbeziehungen des FRBR Model adäquat repräsentiert. Im Laufe der Entwicklung von Resource Descrip-tion and Access (RDA) kamen erste Bestrebungen auf, die Konzepte in Form von Metadaten auszudrücken. So soll das MARC 21 Format durch die RDA/MARC Wor-king Group überarbeitet werden, um den neuen Ansprüchen durch RDA gerecht zu werden. Ebenfalls bemüht sich die DCMI/RDA Task Group, die Konzepte aus dem FRBR Model und aus RDA in unterschiedlichen Domänen mittels DC-Metadaten zu integrieren. Da bislang kein allumfassender RDA-konformer Metadatenstandard veröffentlicht wurde, wird in dieser Arbeit vorerst versucht, grundlegende Entitätsbeziehungen aus dem FRBR Model mit Hilfe eigener Definitionen zu spezifizieren. Des Weiteren wird ein Ansatz zum Einsatz von Accessibility Metadaten in Kombination mit Struktur-Metadaten vorgestellt, woraufhin eine mögliche Serialisierung mittels XML diskutiert wird.

5.2.1 Metadaten für die Entitätsbeziehungen gemäß dem FRBR Model Aufgrund des Fehlens von Metadatenstandards zur Definition von Entitätsbeziehun-gen gemäß dem FRBR Model, hat sich der Autor dieser Arbeit dazu entschieden, diese mittels einer eigenen Festlegung zu formulieren. Die Definition der Beziehungen soll ausschließlich zwischen verschiedenen Ebenen vorgenommen werden, wobei die Beziehungen bidirektional, d. h. von jeder Entität aus, zu spezifizieren sind.



Folglich muss ein Werk als solches typisiert sein und ihm zugeordnete Expressionen als dessen Realisierung ausweisen. Es ist wichtig, dass die entsprechenden Entitä-ten mit Hilfe ihrer Identifikatoren eindeutig ausgewiesen werden. <entity id="work01" type="work">

<isRealizedThrough entity="expression01-01"/>

<isRealizedThrough entity="expression01-02"/>

</entity>

Die Beziehung zwischen einem Werk und einer Manifestation, die dieses Werk ver-körpert, darf laut [RDA08] auch ohne die Bestimmung einer zugehörigen Expression spezifiziert werden. Dieser Fall soll in dieser Arbeit ausgeschlossen werden, da Ex-pressionen in Bezug auf die Erhöhung eines barrierefreien und gebrauchstauglichen Zugriffs von hohem Vorteil sind. Eine Expression muss ebenfalls in der Beschreibung als solche ausgewiesen wer-den. Zusätzlich sind das übergeordnete Werk zu referenzieren und der Expression zugehörige Manifestationen als physikalische Verkörperungen zu listen. <entity id="expression01-01" type="expression">

<isRealizationOf entity="work01"/>

<isEmbodiedIn entity="manifestation01-01-01"/>


</entity>

Eine Manifestation muss ebenso ihren Typ deklarieren und sich als Verkörperung einer Expression ausweisen. Außerdem sind die zu ihr existierenden Exemplare zu spezifizieren. <entity id="manifestation01-01-01" type="manifestation">

<embodies entity="expression01-01"/>

<isExemplifiedBy entity="item01-01-01-01"/>

<isExemplifiedBy entity="item01-01-01-02"/>

</entity>

Ein Exemplar definiert wiederum seinen Typ gemäß der Vorgabe und nimmt Bezug zu seiner übergeordneten Manifestation. <entity id="item01-01-01-01" type="item">

<exemplifies entity="manifestation01-01-01"/>

</entity>

Die Beziehungsausweisungen unter Werken, unter Expressionen oder unter Mani-festationen sowie unter Items sollen nicht mit dem hier definierten Metadatensatz vorgenommen werden, sondern auf standardisierten Metadatensätzen basieren. Im Folgenden wird für die Ausweisung von Accessibility-Beziehungen unter Manifestati-onen auf Accessibility-Standards und deskriptive Metadaten zurückgegriffen. Wenn im weiteren Verlauf dieser Arbeit Bezug zu den hier eingeführten Metadaten genommen wird, wird der Autor dieser Arbeit von FRBR-Metadaten sprechen. Die gemäß RDA anzusetzenden Metadaten sollten zu den einzelnen Entitäten über eine Referenz zu entsprechenden Dateien mit Metadaten in Bezug gebracht werden. Syntaktisch ist für die Referenzierung ein mdRef-Element eingeführt worden. <mdRef uri="/metadata/file.xml" mdType="MARCXML"/>



Für die akkurate Auffindung ist jeweils die Lokation der zugehörigen Datei in absolu-ter oder relativer Form zu hinterlegen sowie die Art der referenzierten Metadaten an-zugeben. Falls die Metadaten direkt in den Entitätselementen integriert werden sollen, kann dies über ein mdWrap-Element realisiert werden.

5.2.2 Verknüpfung von Struktur-Metadaten und Accessibility-Metadaten Neben der Spezifikation von Entitätsbeziehungen unter den FRBR-Entitäten müssen zusätzlich Möglichkeiten geschaffen werden, die die innere Organisation von Mani-festationen ausdrücken. Den feingranularen Struktureinheiten können somit weiter-führende deskriptive Metadaten sowie Accessibility-Metadaten zugewiesen werden. Außerdem können Beziehungen zu Equivalent Alternative Resources und Teilen die-ser ausgedrückt werden. Struktur-Metadaten dienen der Beschreibung der inneren Ordnung einer Ressource. Für nicht-digitale Manifestationen wurden bislang keine Strukturangaben erhoben, da beispielsweise ein Buch nicht in eine Reihe einzelner Blätter zerfallen würde. Im Ge-gensatz ist es bei elektronischen Manifestationen notwendig, Seitenabbildungen oder Textdateien in eine Ordnung zu bringen. Struktur-Metadaten finden vorrangig auf physikalischer Ebene Einsatz. Das bedeutet, Struktur-Metadaten schaffen eine Ordnung auf Dateiebene. In dieser Arbeit wurden zusätzlich Metadaten auf logischer Ebene entwickelt, die durch die Kombination mit physikalischen Strukturen eine hoch feingranulare Strukturierung der Manifestation erlauben.

Ressource

toc.html

chapter1.html

chapter2.html

image21.gif

chapter3.html

Paragraph 2.1

Paragraph 2.2

Abbildung 2.1

Paragraph 2.3

Physikalische Struktur

Logische Struktur Manifestation

Abbildung 5.2: Beispiel für die innere Ordnung einer Manifestation Die Abbildung 5.2 verdeutlicht, dass eine Manifestation eine Aggregation von Res-sourcen sein kann, die gemäß dem FRBR Model keine eigenen Entitäten darstellen. Diese Dateien sind durch die physikalische Struktur als zur Struktureinheit „Ressour-ce“ zugehörig ausgewiesen. Ihre Reihenfolge (von oben nach unten) reflektiert ent-sprechend die inhaltliche Ordnung. Jedes Element der physikalischen Ebene entspricht ebenfalls einer Struktureinheit, die in weitere logische Struktureinheiten aufgegliedert werden kann. Im Beispiel wird die Datei chapter2.html gemäß ihrer In-haltsstruktur in logische Bestandteile zerlegt. Neben drei Paragraphen enthält das Kapitel außerdem eine Abbildung, welche auf physikalischer Ebene durch die Datei image21.gif repräsentiert wird. Die Ordnung der Struktureinheiten ist ebenfalls nach-vollziehbar und entspricht der Lesereihenfolge des Dokumentes.



Es ist nicht zwingend notwendig, dass die physikalische Struktur immer als erste Ebene repräsentiert wird. Es ist gut denkbar, eine Manifestation zuvor logisch zu gliedern, um den resultierenden Struktureinheiten jeweils ein Subset an physikali-schen Struktureinheiten zuzuweisen, welche auf der Folgeebene wiederum in logi-sche Cluster zerlegbar sind. Es zeigt sich jedoch am Beispiel der eingebundenen Abbildung in der Datei chap-ter2.html, dass eine Unterscheidung nach physikalischen Strukturebenen und logi-schen Strukturebenen zu Überschneidungen führt. Der entwickelte Strukturierungs-ansatz und die vorgestellte Serialisierung (vgl. Kapitel 5.2.3) werden sich daher nur auf logische Struktureinheiten beziehen, denen Dateien bzw. Teile von Dateien zu-gewisen werden können. Wozu sollen die vorgestellten Struktureinheiten einer Manifestation in der Praxis die-nen? Einerseits ist die Ordnung und folglich die Lesereihenfolge für die Distribution gesichert. Andererseits erlauben Struktureinheiten eine Assoziation zu weiterführen-den Metadatensätzen. Im Weiteren werden Betrachtungen zur Anreicherung von Struktureinheiten mittels Accessibility-Metadaten und deskriptiven Metadaten vorge-nommen. Bei Betrachtung einer Manifestation und derer Accessibility-Metadaten werden An-gaben zur Adaptierbarkeit (display transformability, control flexibility etc.) häufiger für eine gesamte Manifestation gelten. Hingegen sind Zugriffsmodalitäten immer von den Einzelinhalten abhängig und somit in den Struktureinheiten einer Manifestation unterschiedlich. Der größte Vorteil, der sich jedoch aus dem vorgestellten Ansatz ergibt, liegt in der partiellen Ressourcenassoziation. Primary wie auch Equivalent Alternative Resour-ces sind in feingranulare Bestandteile zerlegbar, die zueinander in Beziehung gesetzt werden können.

Ressource

Paragraph 2.1

Paragraph 2.2

Abbildung 2.1

Paragraph 2.3

Primary Resource Equivalent Alternative Resources

Digital Talking Book

book.smil id=“p22“

id=“i21“

Gebärdenvideo

video2.mpg begin=“30s“ end =“54s“

Taktile Grafik für Stiftplatte

img21_alt.gif

Chapter 3

Chapter 2

Chapter 1

ToC

Abbildung 5.3: Assoziation von Struktureinheiten unterschiedlicher Manifestationen Das Beispiel aus Abbildung 5.3 enthält wiederum die vorgestellte Strukturierung der Ressource aus Abbildung 5.2, wobei die physikalischen Struktureinheiten durch logi-sche ersetzt wurden. Der logischen Struktureinheit zum Paragraph 2.2 und der Ab-bildung 2.1 werden jeweils zwei alternative Äquivalente zugewiesen.



Im Falle des Paragraphen 2.2 handelt es sich bei beiden Alternativen um ersetzende Inhalte einer weiteren Manifestation zum selben Werk. Für das Bild steht einerseits ein Bild mit zusätzlich synchronisierten Textinformatio-nen als Struktureinheit in einem DTB zur Verfügung sowie eine losgelöste taktile Grafik, die eventuell in einer Blindenbibliothek bezogen werden kann. Laut RDA wäre diese taktile Grafik keine eigenständige Manifestation des zugehörigen Werkes. Je-doch ist es durch Accessibility-Metadaten möglich, eine solche Equivalent Alternative Resource direkt einer Primary Resource zuzuweisen. Im Rahmen der Serialisierung wird dieser Sonderfall näher betrachtet. In der Primary Resource selbst wird der logischen Struktureinheit zum Bild außerdem die Datei „image21.gif“ (vgl. Abbildung 5.2) zugewiesen. Es soll darauf hingewisen werden, dass die Accessibility-Metadaten der Primary Re-source nicht direkt die physikalischen Bestandteile der Equivalent Alternative Re-source referenzieren, sondern auf die zugehörigen Metadaten der entsprechenden Struktureinheiten verweisen müssen. Um die hinter diesem Konzept stehende Idee zu verdeutlichen, soll nachfolgend ein praktisches Beispiel erläutert werden. Ein Abonnent einer Tageszeitung bekommt jeden Tag eine gedruckte Version dieser Zeitschrift in seinen Briefkasten zugestellt. Diese Zeitschrift entspricht einer Manifes-tation einer textuellen Expression. Mit seinem Zeitschriftenabonnement erhielt der Kunde ebenfalls eine Zugriffsberechtigung auf die elektronischen Versionen dieser Zeitschrift. Die Ausgaben der Zeitschrift stehen elektronisch im PDF-Format und als Multi-HTML-Seite sowie als Digital Talking Book im DAISY-Format zur Verfügung. Die PDF-Version und die Multi-HTML-Ausgabe sind ebenfalls Manifestationen der textuellen Expression. Die DAISY-Version gehört als Manifestation einer eigenen Expression an, die deren multimedialen Charakter ausdrückt. Logisch würde sich jede Manifestation in erster Ordnung in inhaltsabhängige Sektio-nen wie Lokalteil, Wirtschaftsteil, Sportteil etc. aufgliedern. Die zweite logische Struk-turierung würde nach Artikeln in jedem Teil der ersten Ebene vorgenommen werden. Auf der letzten und feingranularsten Ebene würde ein Artikel in Struktureinheiten wie Textabschnitte und andere Elemente wie Abbildungen oder Tabellen aufgegliedert werden. Bezüglich der physikalischen Strukturierung unterscheiden sich die elektronischen Manifestationen. So besteht die PDF-Version aus nur einer Datei, wohingegen in der HTML-Version jeder Artikel in einer separaten Datei gehalten wird und in einem Voll-text-DTB zu jedem Artikel ein Textabschnitt des Textual Content Files und eine Au-diodatei gehören. Basierend auf der jeweiligen physikalischen Strukturierung werden den logischen Struktureinheiten der Manifestationen auf unterschiedlichen Ebenen Dateien zugeordnet. Die logischen Struktureinheiten der Manifestationen sind dabei identisch. Folglich sind die Artikel aller Manifestationen sowie die feingranularen Struktureinheiten in diesen logisch zueinander assoziierbar. Eine Ausnahme stellt die Einbeziehung eines gekürzten Artikels bzw. eines Artikels in einfacher Sprache dar, da dieser nicht zum herkömmlichen äquivalenten Artikel auf feingranularer Strukturebene in Bezug gebracht werden kann. Zur Unterstützung der Barrierefreiheit ist es wichtig, Accessibility-Metadaten zur je-weiligen Manifestation hinzuzufügen. In diesem Sinne stellt sich die Frage, welche der Manifestationen die Primary Resource darstellt. Soll es die Druckversion der



Zeitschrift sein? Durch den Autor dieser Arbeit wird festgelegt, dass eine Primary Re-source immer die elektronische Version ist, die dem gedruckten Original, falls ein solches vorhanden ist, am nähesten kommt und demzufolge als Vorlage für den Druck genutzt wurde. In unserem Beispiel ist das die PDF-Version. Analog zur Ver-wendung von IMS AccessForAll Meta-data (ACCMD) gilt es, dieser Primary Resour-ce Zugriffsmodalitäten sowie die Display Transformability und die Control Flexibility zuzuweisen. Gleiches gilt für jede der Manifestation unterliegenden Struktureinhei-ten, wobei sich resultierend die Accessibility-Metadaten von einer allgemeinen zu einer exklusiveren Spezifikation verfeinern. Die alternativen Manifestationen als Equivalent Alternative Resource müssen zuerst ausweisen, für welche Manifestation sie die Alternativversion darstellen und welche Charakteristika sie von der Primary Resource unterscheiden. So ist beispielsweise festzulegen, wodurch eine bestimmte Zugriffsmodalität der Primary Resource in der Equivalent Alternative Resource zu-gänglich gemacht wird. Ein analoges Vorgehen ist für alle unterliegenden Struktur-einheiten zu wählen, welche wiederum zu unterliegenden Struktureinheiten der Primary Resource in Beziehung stehen. Eine Ausnahme bilden Equivalent Alternative Resources, die keiner Manifestation zugehören. Ein gutes Beispiel ist eine ausführliche alternative Bildbeschreibung, die im Nachhinein im Archiv eingepflegt wurde und von Struktureinheiten der Primary Resources wie auch von Struktureinheiten der Equivalent Alternative Resources als zusätzliche Zugänglichkeitsmöglichkeit ausgewiesen werden kann. Es soll festgelegt werden, dass solche Inhalte immer unabhängig der FRBR-Entitäten in externen Equivalent Alternative Resources gehalten werden. Resultierend sind Mechanismen zu definieren, die es einer Primary Resource und einer Equivalent Alternative Re-source gestattet, eine Struktureinheit dieser externen Equivalent Alternative Resour-ce zu referenzieren. Zur Verdeutlichung des Gesamtkonzeptes soll ein Nutzungsbeispiel eines Benutzers für die bereits vorgestellte Zeitschrift beim Lesen in der Straßenbahn beschrieben werden. Da der Benutzer am Morgen vergaß, seine Zeitung mitzunehmen, ent-schließt er sich auf seinem Arbeitsweg dazu, die elektronische Version auf seinem PDA zu lesen. Eigentlich ist er es gewohnt, die PDF-Version gelegentlich an seinem Rechner zu lesen. Die Accessibility-Metadaten zur PDF-Version weisen ihn jedoch darauf hin, dass diese Datei aufgrund der Layouterhaltung keinen Reflow unterstützt und dadurch für sein kleines Display ungeeignet ist. Die HTML-Version ist durch ihre Charakteristik entsprechend den Accessibility-Metadaten ideal für seine Bedürfnisse und somit für seinen PDA geeignet. Der Leser exploriert den Inhalt anhand einer Splash-Page, die ein hierarchisches Inhaltsverzeichnis enthält. Der Leser navigiert zu einem Artikel in einer bestimmten Kategorie und liest diesen auf seinem Display. Anschließend kehrt er auf die Splash-Page zurück, um einen zweiten Artikel auszu-wählen. Nach dem Bezug des Artikels sieht der Benutzer anhand der Scrollleiste, dass dieser Artikel erheblich länger ist. Aufgrund dieser Tatsache möchte der Leser diesen nicht auf seinem kleinen PDA-Display lesen. Stattdessen entscheidet er, die-sen Artikel auditiv konsumieren zu wollen. Durch diese Auswahl wird der Leser zum selben Artikel in der DTB-Manifestation geführt. Nun liegt die Argumentation nahe, dass der Leser sich schon zu Beginn für die DAISY-Version hätte entscheiden können. Als Gegenargument kann jedoch ange-führt werden, dass diese eventuell keine textuellen Ausführungen enthält. Die Einbeziehung der externen Equivalent Alternative Resources zu bestimmten Struktureinheiten verschiedenster Manifestationen ermöglicht die übergreifende Ac-cessibility-Erhöhung durch nachträglich angereicherte Inhalte. Dieser Ansatz wird bei Copyright TU Dresden, Alexander Haffner 71


der Modellierung des Gesamtprozesses in Kapitel 6 bei der kollaborativen Accessibi-lity-Anreicherung nachgenutzt, um eigentliche Manifestationen gemäß ihrem Copy-right nicht zu verletzen, es jedoch zu ermöglichen, jenen auf verschiedensten Ebenen neue Inhalte hinzuzufügen. Es soll darauf hingewiesen werden, dass in dieser Arbeit ausschließlich Strukturie-rungsansätze für textbasierte Publikationen eingeführt wurden. Die adäquate Struktu-rierung für Manifestationen abweichenden Werktyps, wie beispielsweise kartografischen Ressourcen, ist in weiterführenden Untersuchungen zu betrachten. Der Gesamtansatz zeigt, dass eine Vielzahl von Metadaten zu einem Werk und des-sen Manifestationen angereichert werden können. In der Praxis ließe sich die feing-ranulare Strukturierung einzig und allein wirklich effizient mittels automatisierter Generierungsprozesse der Alternativressourcen umsetzen. Falls Manifestationen durch die Produzenten komplett unabhängig erstellt werden, ist es nur sehr schwierig und vor allem mit hohem Aufwand verbunden, die insgesamt möglichen Metadaten nachträglich zu spezifizieren. Wie eine solche automatisierte Erzeugung realisiert werden kann, wird ebenfalls bei der Modellierung des Gesamtprozesses im Kapitel 6 diskutiert.

5.2.3 Serialisierung der Metadaten Für die Aggregation von Manifestationen eines Werkes soll ein gemeinsames Archi-val Information Package (AIP) gemäß dem OAIS Reference Model als unterstützen-de Komponente zum Einsatz kommen. Folglich können alle physikalischen Bestandteile (Dateien) und die Katalogisierungsinformationen zu RDA in Form von Metadaten miteinander vereinigt werden. Zusätzlich wird in diesem Kapitel vorge-stellt, wie Accessibility-Metadaten in den Metadatensatz einbezogen werden und wie die eingeführte Strukturierung für Manifestationen mit Hilfe von Metadaten umsetzbar ist. Die Untersuchungen zur Findung eines existierenden Standards für die Realisierung der vorgestellten Konzepte zielten zu Beginn auf eine Nachnutzung von METS ab, was jedoch Probleme bei der feingranularen Strukturabbildung hervorrief sowie bei der Assoziation der Struktureinheiten. Eine Serialisierung mittels RDF/XML würde mit Abstand das höchste Zukunftspoten-tial an den Tag legen. Für eine Spezifikation der vorgestellten Konzepte ist jedoch anzuraten, ein Komitee zu gründen, dass nicht nur existierende Metadatenstandards wie MARC 21 in RDF abbildet, sondern auch Schemas und Vokabularien definiert, die einerseits auf die Bibliotheksdomäne abgestimmt sind und andererseits in Onto-logien für das Semantic Web außerhalb von Bibliotheken mit einfließen können. Der Autor dieser Arbeit musste sich aus Günden der Umfangsbegrenzung gegen die Re-alisierung mittels RDF-Konzepten entschließen. Jedoch soll an dieser Stelle betont werden, dass eine Abbildung der Katalogdaten in Kombination mit Normdaten in On-tologie-basierten Repräsentationen für externe Organisationen wie Suchmaschinen-betreiber eine optimale Voraussetzung für zukünftige Semantic Web Entwicklung bietet. Somit sollte dies für eine kommerzielle Vermarktung durch Bibliotheken im Auge behalten werden. Die nachfolgend vorgestellte Serialisierung ist rein XML-basiert. Es werden teilweise etablierte Standards in die Metadatenbeschreibung aufgenommen und teilweise ei-gene Metadatenkonstrukte neu definiert. Die Grundlage für die Serialisierung bilden die FRBR-Metadaten zur Entitätsbeziehungsbeschreibung.



Da für deutsche Bibliotheken in Zukunft die Nutzung von MARC 21 als Austausch-format festgelegt wurde, ist der Standard eventuell auch für die RDA-konforme de-skriptive Entitätsbeschreibung zu erwarten. Im Folgenden werden resultierend deskriptive Datensätze mittels MARC 21 in das AIP eingebunden. Für die praktische Verwendung muss selbstverständlich auf MARCXML zurückgegriffen werden, um die Integration im XML-basierten Format zu gewähren. Für die Inbetriebnahme eines globalen Kataloges wird zu untersuchen sein, ob der aktuelle MARC 21 Standard bzw. zu erwartende Nachfolger den Ansprüchen sämtlicher Publikationsformen be-züglich des Metadatenumfanges gerecht werden wird. Entsprechend ist es gestattet, Entitäten und Struktureinheiten mehrere Metadatensätze in verschiedenen Formaten zuzuordnen. Ausgangspunkt soll ein Wurzelelement für den Metadatensatz sein. In Anbetracht der Tatsache, dass es sich um ein AIP handelt, welches primär auf RDA-konformen Daten basieren muss, entschloss sich der Autor, ein aip-rda-Element einzuführen. <aip-rda>

…

</aip-rda>

Entitätselemente der FRBR-Metadaten bilden die Kindelemente dieses Wurzelele-mentes. Der Leser sei darauf hingewiesen, dass aus Gründen der Übersichtlichkeit an dem aip-rda-Element wie auch an allen Elementen der Folgebeispiele keine Namespaces zu finden sind. Das Datenmodell in Anhang C.1 verdeutlicht jedoch, welche Elemen-te aus ACCMD unverändert übernommen wurden. Bei Betrachtung der Entität „Werk“ ist festzustellen, dass an diesem globalen Zu-griffspunkt neben den Referenzen zu existierenden Expressionen nur deskriptive Me-tadaten von Nöten sind. Der Identifikator bezieht sich auf kein physisches Element, jedoch muss er weltweit einzigartig sein, um das Werk anhand dieser ID von anderen zu unterscheiden. Ein Beispiel kann wie folgt aussehen. <entity id="work01" type="work">

<isRealizedThrough entity="expression01"/>

<isRealizedThrough entity="expression02"/>

<mdRef uri="/metadata/work01.xml" mdType="MARCXML"/>

</entity>

Wie bereits beschrieben kann das mdRef-Element wiederholt werden und durch mdWrap-Elemente ersetzt werden, um die Metadaten direkt im FRBR-Metadatensatz zu integrieren. Für ein Werk ist es nicht notwendig, Accessibility-Metadaten zu spezi-fizieren, da die Spezialisierung hinsichtlich der Barrierefreiheit erstmalig auf Expres-sionsebene geschieht. Die Beziehungsausweisung von Werken untereinander soll nicht über die Accessibili-ty-Metadaten geschehen. Bei ausführlich angesetzten RDA-konformen Metadaten sind derartige Beziehungen aus den deskriptiven Metadaten ableitbar. Eine Expression muss ebenfalls RDA-konforme deskriptive Metadaten referenzieren. Bezüglich der deskriptiven Metadaten besitzt die Sprachausweisung insbesondere ein hohes Gewicht, da eine Sprache, derer man nicht mächtig ist, für die Allgemein-heit die größte Barriere darstellt. Bezüglich der Accessibility-Metadaten hat sich der Autor für eine Übernahme der IMS AccessForAll Meta-data (ACCMD) entschieden.



Auf Expressionsebene soll keine Unterscheidung nach Primary Resource oder Equi-valent Alternative Resource vorgenommen werden, da diese Ebene eine abstrakte Ebene repräsentiert. Stattdessen muss jede Expression ausschließlich ihre Zugriffs-modalitäten ausweisen. Aus diesem Grunde wurde neben dem resourceDescription-Element aus dem ACCMD-Standard ein expressionDescription-Element im accessi-bility-Element eingeführt, in dem über Attribute die Zugriffsmodalitäten spezifizierbar sind. Das folgende Beispiel verdeutlicht die Verwendung der Accessibility-Metadaten in einem integrierten Wrapper. Analog zu den deskriptiven Metadaten kann an dieser Stelle auch ein accRef-Element als Verweis zu einer externen Datei mit den entspre-chenden Metadaten integriert werden. <entity id="expression01-01" type="expression">

<isRealizationOf entity="work01"/>



<mdRef uri="/metadata/expression01-01.xml" mdType="MARCXML"/>

<accWrap>

<accessibility>

<expressionDescription hasVisual="true" hasAuditory="false"

hasText="true" hasTactile="false"/>

</accessibility>

</accWrap>

</entity>

Manifestationen müssen ebenfalls durch die in RDA spezifizierten deskriptiven Meta-daten in regulärer Form beschrieben werden. Angaben bezüglich Abhängigkeiten unter den Manifestationen sowie deren Adaptierbarkeit und Zugänglichkeit werden im hier vorgestellten Ansatz ausschließlich durch Accessibility-Metadaten spezifiziert. Es ist jedoch zu erwarten bzw. es wäre zu begrüßen, wenn die Beziehungen von Manifestationen zueinander in Zukunft mittels festen Vokabulars durch RDA auch in Hinsicht auf Beziehungen gemäß der Barrierefreiheit deklarierbar wären. Die Spezifikation der ACCMD geht prinzipiell davon aus, dass nur digitale Ressour-cen mit demselben Inhalt in verschiedenen Verkörperungen vorliegen. Eine dieser Ressourcen fungiert dabei immer als Quelldokument (bzw. als Vorlage) zur Generie-rung aller weiteren Ressourcen. In der Praxis kann dieser Ansatz nicht in einer digita-len Bibliotheksumgebung angewandt werden. Grund dafür ist, dass es nicht nur eine Primary Resource in einem Werk geben darf und Equivalent Alternative Resources wiederum selbst Equivalent Alternative Resources ausweisen dürfen. Außerdem kann eine Manifestation Equivalent Alternative Resources in Form von Supplementa-ry Resources enthalten. Außerdem kann es externe Equivalent Alternative Resour-ces geben, die nicht direkt zu einer Manifestation gehören, sondern dem Werk zugeordnet sind. Zu einem Werk kann neben der originalen textuellen Manifestation auch eine gekürz-te Version vorliegen. In diesem Falle unterscheiden sich die Inhalte und eine direkte Assoziation, insbesondere auf feingranularer Ebene, ist nur schwer umsetzbar. Da-her sollte die originale und gekürzte Manifestation gemäß der Accessibility-Metadaten als Primary Resource behandelt werden. Die Beziehung zwischen den Manifestationen ist folglich über die deskriptiven Metadaten aus dem Vermerk „Mani-festation B ist gekürzte Version von Manifestation A“ ableitbar. Falls trotzdem eine



semantische Assoziation (beispielsweise auf Kapitel- oder Artikelebene) stattfinden soll, ist bei der Art der Äquivalenz in den Accessibility-Metadaten der Vermerk über die gekürzte Struktureinheit zu hinterlegen. Auch definiert die ACCMD Übersetzungen von Ressourcen als Equivalent Alternative Resources. Aus Sicht des Autors dieser Arbeit soll jede Sprache mindestens eine eigene Primary Resource spezifizieren, um Assoziationen zu tatsächlichen Equiva-lent Alternative Resources in der gleichen Sprache zuzulassen. Der Bezug zu Mani-festationen unterschiedlicher Sprachen ist ebenfalls durch deskriptive Metadaten ableitbar. Für eine Manifestationsassoziation müssen der Übersetzer und die Mani-festation, die der Übersetzung als Vorlage diente, in den deskriptiven Metadaten der übersetzten Manifestation spezifiziert werden. Eine weitere Schwierigkeit tritt bei der Bestimmung einer Primary Resource aus einer Anzahl von Manifestationen einer Expression auf. Falls eine Expression beispiels-weise in einer gedruckten Version, einer PDF-Repräsentation und durch eine Multi-HTML-Seitendarstellung verkörpert ist, stellt sich auch hier die Frage, welche Mani-festationen als Äquivalent gelten soll. Falls eine digitale Version exakt der Druckrep-räsentation entspricht, ist diese als Primary Resource anzusehen. Falls diese im Geringsten voneinander abweichen, sind beide als Primary Resources zu verstehen. Im Allgemeinen ist aber immer eine digitale Ressource als Primary Resource auszu-weisen, da so eine feingranulare Assoziation zu Equivalent Alternative Resources ermöglicht wird. Falls nur eine Druckversion verfügbar ist und beispielsweise ein DTB nachträglich erzeugt wurde, ist das DTB als alternatives Äquivalent zur primären Druckversion zu definieren. In einem solchen Beispiel ist abzuwägen, in wie weit eine Structural Map für beide Manifestationen generiert werden kann, da diese Generie-rung nicht automatisch erfolgen kann, sondern durch einen Menschen nachträglich angereichert werden muss. Im Zusammenhang mit der Modellierung eines erweiter-ten Prozessmodells wird die manuelle und automatische Accessibility-Metadaten-Anreicherung vertieft diskutiert. Durch ACCMD ist es außerdem nicht gestattet, Equivalent Alternative Resources weitere Equivalent Alternative Resources zuzuweisen. In der Praxis ist dies jedoch oft der Fall. Das wohl am häufigsten auftretende Beispiel ist die Zuweisung einer neuen Manifestation, die durch eine Migration entstanden ist. Falls ein DTB als Equi-valent Alternative Resource zu einer textuellen Manifestation existiert und dieses DTB in einen zeitgemäßen Standard migriert wurde, ist diese Manifestation ein Äqui-valent eines Äquivalentes. Das nachfolgend vorgestellte Konzept wird nicht wie durch ACCMD vorgeschrieben Primary Resources und Equivalent Alternative Resources ausweisen. Stattdessen wird eine Verallgemeinerung ähnlich dem Ansatz aus DC-AfA umgesetzt, in der von Ressourcen gesprochen wird, die ein Äquivalent besitzen (equivalentResource-Element) bzw. ein Äquivalent einer anderen Manifestation (equivaletOf-Element) sind. Eine Manifestation muss gemäß der ACCMD den notwendigen Umfang an Accessi-bility-Metadaten im accWrap-Element kapseln. Der folgende Code illustriert einen solchen Metadatensatz. <accessibility>

<resourceDescription>

<resource hasVisual="true" hasAuditory="false" hasText="true"

hasTactile="false">



<adaptability type="displayTransformability">

metadata/manifestation01-01-01_disTra</adaptability>

<adaptability type="controlFlexibility">

metadata/manifestation01-01-01_conFle</adaptability>

<adaptability type="other" other="newAdaptability">

metadata/manifestation01-01-01_newAda</adaptability>

<equivalentResource ref="manifestation01-01-02" type="…"/>


</resource>

</resourceDescription>

</accessibility>

Das Code-Beispiel aus einer Manifestationsentität würde einer Primary Resource entsprechen, da die Manifestation sich nicht als Equivalent Alternative Resource ei-ner anderen Manifestation deklariert. Zu Beginn müssen im neu eingeführten resour-ce-Element die Zugriffsmodalitäten ausgewiesen werden. Außerdem sind die Display Transformability und die Control Flexibility zu spezifizieren. Die Evaluation And Re-port Language (EARL) kann wie in ACCMD für die Angaben zur Adaptierbarkeit nachgenutzt werden. Es ist auch möglich, zusätzliche Aspekte der Adaptierbarkeit mittels abweichender Auszeichnungssprachen bzw. Vokabular zu integrieren. Das Beispiel soll verdeutlichen, dass eine Datei mit den entsprechenden Inhalten zur Adaptierbarkeit im AIP referenziert wird. Denkbar ist selbstverständlich auch eine extern befindliche Datei. Nachfolgend werden die zur Manifestation zugehörigen Equivalent Alternative Resources (äquivalente Manifestationen) deklariert, um dem System eine Suche nach adäquaten Alternativen zu ermöglichen. Hierfür wurden als Ergänzung zum ACCMD ein ref-Attribut und ein type-Attribut im equivalentResource-Element eingebunden. Das ref-Attribut referenziert die Equivalent Alternative Re-source anhand seiner ID und das type-Attribut weist mittels eines zu definierenden Vokabulars die Natur der Äquivalenz aus. Potentielle Typen wären Umsetzung in anderem Format, Umsetzung im gleichen Format und aktuellerem Standard etc. und die Art der Überführung (manuell, automatisch etc.). Eine Manifestation, die als Equivalent Alternative Resource agiert, soll durch das fol-gende Beispiel repräsentiert werden. <accessibility>

<resourceDescription>

<resource hasVisual="false"

hasAuditory="true" hasText="false" hasTactile="false">

<adaptability type="…">…</adaptability>


<equivalentOf ref="manifestation01-01-01" supplementary="false">

<content>

<alternativesToVisual>

<audioDescription type="standard" xml:lang="en"/>

</alternativesToVisual>

</content>

</equivalentOf>



</resource>

</resourceDescription>

</accessibility>

Die ACCMD sehen es prinzipiell nicht vor, Zugriffsmodalitäten und Angaben zur Adaptierbarkeit in Analogie zur Primary Resource explizit in Equivalent Alternative Resources auszuweisen. Der hier vorgestellte Ansatz wird dies jedoch umsetzen, um ein höheres Maß an Barrierefreiheit zu erreichen. Im Beispiel wird zur Manifestation wiederum ein Äquivalent im AIP deklariert und nachfolgend über ein eingeführtes equivalentOf-Element eine Primary Resource zur aktuell beschriebenen Ressource ausgewiesen. Da wie im weiteren Verlauf erläutert, eine Ressource nicht zwangsläu-fig nur eine Primary Resource besitzen muss, wird das content-Element im equiva-lentOf-Element gekapselt, um die Art der Ersetzung für die jeweilige Modalität der primären Ressource anzugeben. Hierfür kann der gesamte Umfang des content-Elements aus ACCMD eingesetzt werden. Es sei darauf hingewiesen, dass eine Mo-dalität auch durchaus in der Praxis durch die gleiche Modalität ersetzt werden kann. Dies tritt beispielsweise bei der Ersetzung der PDF-Repräsentation durch eine HTML-Version auf. Nachfolgend werden Betrachtungen für die feingranulare Strukturierung einer Mani-festation diskutiert. Im Zusammenhang der Serialisierungsentwicklung war der Autor bestrebt, das OAI-ORE-Konzept nachzunutzen. Aufgrund der in RDF notwendigen absoluten Angabe von Unique Resource Identifier (URI) zur Identifikation von Sub-jekten und Objekten wurde dieser Ansatz im Rahmen der Arbeit nicht umgesetzt. Weiterführende Untersuchungen sollten diese Thematik jedoch vertieft betrachten, um die relativen Angaben auch auf Manifestationsebene adäquat ausdrücken zu können und eine absolute Ausweisung auf Item-Ebene vorzunehmen. Für die interne Strukturrepräsentation muss in der eingeführten XML-Serialisierung eine Structural Map im Entitätselement der Manifestation integriert werden. Diese wird nicht nur wie im METS-Standard physikalische Beziehungen auf Dateiebene ausweisen, sondern, wie im letzten Kapitel diskutiert, logische Struktureinheiten de-klarieren. Für die Einbindung in der Serialisierung wurde durch den Autor ein ent-sprechendes structMap-Element festgelegt. <entity id="…" type="manifestation">

<embodies entity="…"/>

<isExemplifiedBy entity="…"/>

<mdRef uri="…" mdType="…"/>

<accWrap>…</accWrap>

<structMap>…</structMap>

</entity>

Die Structural Map reflektiert in ihrer XML-Serialisierung die hierarchische Struktur der in einer Manifestation enthaltenen Struktureinheiten. Die Hierarchie der Einheiten wird dabei über das hasPart-Element der DCMI Metadata Terms erzeugt. Eine Struk-tureinheit entspricht immer einem unit-Element, wobei nicht unterschieden wird, ob die Struktureinheit physikalischer oder logischer Natur ist. Prinzipiell sind alle Struk-tureinheiten als logische Bestandteile anzusehen, jedoch kann einer Einheit über das ref-Attribut eine Publikationsdatei im AIP, eine Referenz auf eine bestimmte Stelle in einer Datei oder einem Abschnitt in einer Datei zugewiesen werden. Der folgende



Code-Abschnitt zeigt eine Structural Map einer textuellen Manifestation einer Tages-zeitung, die in einer PDF-Datei gehalten wird. <structMap id="…">

<unit id="…" type="journal" label="Sächsische Zeitung - Dresden"

ref="sz20081206.pdf">

<hasPart>

<unit id="…" type="section" label="Lokalteil"

ref="news.pdf#nameddest=lo_sec">

<mdRef uri="/metadata/lose.xml" type="MARCXML"/>

<accWrap/>

<hasPart>

<unit id="…" type="article" label="Weihnachtsbaum schmückt den

Neustädter Advent" ref="news.pdf#nameddest=lo_sec_tree">

<mdRef uri="/metadata/lose_tree.xml" type="MARCXML"/>

<accWrap/>

<hasPart>

<unit id="…" type="h1"

ref="news.pdf#nameddest=lo_sec_tree_h1">

<accWrap/>

</unit>

<unit id="…" type="paragraph"

ref="news.pdf#nameddest=lo_sec_tree_p1">

<accWrap/>

</unit>

<unit id="…" type="image"

ref="news.pdf#nameddest=lo_sec_tree_img1">

<accWrap/>

</unit>

<unit id="…" type="paragraph"

ref="news.pdf#nameddest=lo_sec_tree_p2">

<accWrap/>

</unit>

</hasPart>

</unit>

<unit id="…" type="article" label="Blasewitz hat beste

Ärztedichte" ref="news.pdf#nameddest=lo_sec_doc">…</unit>

<unit id="…" type="article"

label="Geflügelzüchter freut sich auf das Weihnachtsgeschäft"

ref="news.pdf#nameddest=lo_sec_fowl">…</unit>

</hasPart>

</unit>



<unit id="…" type="section" label="Wirtschaftsteil"

ref="news.pdff#nameddest=ec_sec">…</unit>

<unit id="…" type="section" label="Sportteil"

ref="news.pdf#nameddest=sp_sec">…</unit>

</hasPart>

</unit>

</structMap>

Das Beispiel zeigt eine Zeitschrift mit drei logischen Sektoren (Lokalteil, Wirt-schaftsteil und Sportteil) sowie diversen zugeordneten Artikeln. Die entsprechend übergeordnete Unit in der Structural Map erlaubt wie jede Unit, einen Typ mittels des type-Attributes zu definieren und eine verbale Beschreibung durch das label-Attribut zu hinterlegen. Das ref-Attribut verweist aufgrund der Tatsache, dass es sich um eine Einzeldatei-Manifestation handelt, schon auf dieser Ebene auf die zugehörige PDF-Datei. In der ersten Ebene ist es nicht notwendig, deskriptive Metadaten und Acces-sibility-Metadaten zu referenzieren, da diese den Metadaten im Entitätselement ent-sprechen. Die drei untergeordneten Struktureinheiten werden in einem hasPart-Element gekap-selt. Für jeden der Teile kann ein eigener deskriptiver Metadatensatz spezifiziert werden. Ebenfalls sollten Accessibility-Metadaten zu jeder Unit angegeben werden. Im Beispiel weist die Datei-Referenz auf ein bestimmtes Inhaltselement in der PDF-Datei mittels seiner ID. Dieses Element reflektiert den Lokalteil der Zeitung und ent-spricht im Tagged PDF dem Wurzelelement aller Folgeinhalte (Artikel). Die Sektion (Lokalteil) kapselt wiederum Artikel, die eine ID, einen Typ, eine Be-schreibung und eine Referenz auf einen Abschnitt in der PDF-Datei besitzen. Eben-falls können für jeden Artikel deskriptive Metadaten sowie Accessibility-Metadaten angegeben werden. Ein Artikel wird für dieses Beispiel in die feingranularsten Struktureinheiten aufge-gliedert. Die Struktureinheiten entsprechen einer Überschrift, zwei Paragraphen und einer Abbildung. Aus Sicht des Autors dieser Arbeit ist es nicht notwendig, auf solch feingranularen Ebenen eine deskriptive Metadatenanreicherung zu erlauben. Jedoch ist es an dieser Stelle möglich, Accessibility-Metadaten anzugeben. Durch die Ac-cessibility-Metadaten können alternative Struktureinheiten anderer Manifestationen referenziert oder externe Struktureinheiten hinzugefügt werden, ohne einen Zugriff auf die eigentliche Ressource haben zu müssen. Die Accessibility-Metadaten für Struktureinheiten werden vollständig in Analogie zu denen der Manifestationen verwendet. Der einzige Unterschied ist, dass das equiva-lentResource-Element und das equivalentOf-Element jeweils auf die ID der entspre-chend zugehörigen Struktureinheit verweisen. In einer HTML-Repräsentation, in der die einzelnen Dateien Artikeln entsprechen, würde eine Referenzierung von Dateien erst auf der entsprechenden Ebene der Structural Map geschehen. Resultierend würden die unit-Elemente der ersten und zweiten Ebene kein ref-Attribut deklarieren. Für die Strukturierung eines gedruckten Buches würde analog gar keine Referenzierung zu Dateien stattfinden, da alle Struk-tureinheiten logischer Natur wären. Die Referenzierung von Struktureinheiten muss in einer Form geschehen, die zuerst die entsprechende Manifestation eindeutig identifiziert und nachfolgend die Struktur-



einheit mittels ihrer ID ausweist. Das folgende Beispiel verdeutlicht die syntaktische Realisierung für eine Equivalent Alternative Resource. <equivalentResource ref=”manifestation01-01-03#unit06458”/> Eine bislang nicht diskutierte Thematik stellt der Umgang mit Supplementary Resour-ces bei der Serialisierung dar. Durch die ACCMD werden zwei Arten von Equivalent Alternative Resources definiert. Einerseits existieren ergänzende (Supplementary Resources) und andererseits ersetzende (Non-Supplementary Resources) Ressour-cen. Des Weiteren muss für eine Zusammenführung mit den FRBR-Konzepten un-terschieden werden, ob eine Equivalent Alternative Resource Bestandteil einer Manifestation ist oder eine losgelöste Anreicherung über allen Manifestationen in ei-nem Werk (externe Equivalent Alternative Resource) repräsentiert. Das supplemen-tary-Attribut im equivalentOf-Element gibt an, ob die Equivalent Alternative Ressource eine ergänzende (Wert ist „true“) oder eine ersetzende (Wert ist „false“) Funktion einnimmt. Gemäß RDA darf es keine Manifestation im selben Werk geben, die eine andere Manifestation ergänzt. Das bedeutet, dass in den Accessibility-Metadaten der Manifestationsentität keine Aussagen über Supplementary Resources in einer Manifestation getroffen werden dürfen. Die Ausweisung der ergänzenden Inhalte innerhalb einer Manifestation muss in der Structural Map vorgenommen wer-den. Das nachfolgende Beispiel verdeutlicht eine Ausweisung eines Untertitels zu einem Videoabschnitt als Supplementary Resource innerhalb einer logischen Strukturein-heit der Structural Map einer Manifestation. <hasPart>

<par>

<unit id="…" type="video" ref="video5.avi#33s#67s"><accWrap/></unit>

<unit id="…" type="subtitle" ref="v5_sec1.rt"><accWrap/></unit>

</par>

<par>…</par>

</hasPart>

Für jedes Medium bzw. für jeden Medienabschnitt muss eine eigene Struktureinheit gebildet werden, die eine Datei oder einen Dateiabschnitt referenziert. Die im Bei-spiel ausgewiesene Referenz auf einen Videoabschnitt ist nicht standardkonform und müsste durch ein Resolversystem aufgelöst werden. Die Accessibility-Metadaten der beiden Struktureinheiten müssen sich entsprechend gegenseitig als Primary Resour-ce und Equivalent Alternative Resource referenzieren. Die Struktureinheit zum Unter-titel als Equivalent Alternative Resource muss als Supplementary Resource über das supplementary-Attribut deklariert werden. Für die syntaktisch valide Serialisierung und die Bildung einer übergeordneten logischen Struktureinheit wird ein par-Element eingeführt, welches parallel wiedergebbare Struktureinheiten in sich kapselt und so-mit die akkurate innere Ordnung der Struktureinheiten aufrecht erhält. Durch den hier vorgestellten Ansatz soll es gestattet sein, externe Equivalent Alter-native Resources außerhalb der entity-Elemente der FRBR-Metadaten im aip-rda-Element zu spezifizieren, um beispielsweise nachträglich angereicherte alternative Bildbeschreibungen zu allen Manifestationen bzw. zu bestimmten Struktureinheiten dieser in Beziehung zu setzen. Da RDA für diese Umsetzung keine Möglichkeiten vorsieht, musste der folgende Weg eingeschlagen werden.



Die Spezifikation externer Equivalent Alternative Resources ist in der Serialisierungs-vorschrift an die Gestalt der Entitätselemente angelehnt worden. Das folgende Code-Beispiel soll dies verdeutlichen. <extEar id="ear01">

<mdRef uri="/metadata/earMd01.xml" mdType="MARCXML"/>

<accWrap>

<resource hasVisual="…" hasAuditory="…"

hasText="…" hasTactile="…">

<adaptability type="…">…</adaptability>

<equivalentOf ref="…" supplementary="…"/>

<equivalentOf ref="…" supplementary="…"/>


</resource>

</accWrap>


</extEar>

Somit dürfen neben den entity-Elementen auch beliebig viele extEar-Elemente im aip-rda-Element auftreten. Jeder externen Equivalent Alternative Resource kann wiederum ein deskriptiver Metadatensatz, globale Accessibility-Metadaten und eine Structural Map zugewiesen werden. In den Accessibility-Metadaten werden u. a. alle Primary Resources bzw. Struktureinheiten dieser durch die Equivalent Alternative Resource referenziert. Die Structural Map erlaubt wie bereits vorgestellt eine feingra-nulare Strukturierung der externen Equivalent Alternative Ressource. Beispielsweise könnte ein Untertitel zeitabhängig in geordnete Struktureinheiten zerlegt werden. Je-de Struktureinheit ist mittels ihrer eindeutigen ID durch externe Struktureinheiten als Äquivalent referenzierbar. Eine Referenzierung von externen Equivalent Alternative Resources oder Struktureinheiten dieser muss analog zur Referenzierung von Struk-tureinheiten in Manifestationsentitäten über die Kombination der ID der externen Equivalent Alternative Resource und einer entsprechenden Struktureinheit vorge-nommen werden. Es wurde verdeutlicht, dass in den FRBR-Metadaten Manifestationen digitaler und nicht-digitaler Natur ausgezeichnet werden können. Die Auszeichnung findet dabei immer auf eine relative Art statt, ohne auf die absolute Positionierung einzelner Ex-emplare einzugehen. Für die Spezifikation einzelner Items ist die Überführung der relativen Angaben aus der zugehörigen Manifestation in der Item-Entität notwendig. Für nicht-digitale Ressourcen kann direkt auf eine Manifestation Bezug genommen werden. Im Rahmen der Administration gilt es, deren Archivierungsort, deren Her-kunft, eventuelle Ausleihrestriktionen etc. zu spezifizieren. Für digitale Ressourcen ist es wichtig, die in den Manifestationen auftretenden Da-teien im Entitätselement des Items mit absoluten Pfaden bzw. URIs wie DOI oder URN zu assoziieren. Außerdem müssen administrative sowie technische Metadaten zu einzelnen Dateien in Beziehung gesetzt werden. Ebenso muss für alle zur Mani-festation gehörigen Dateien eine Zugriffsrechtsspezifikation definiert sein. Da es archivierungssystemabhängig ist, welche Standards für administrative Metada-ten, technische Metadaten, Rechte-Management-Metadaten und Metadaten zur Langzeitarchivierung eingesetzt werden, ist es an dieser Stelle aus Sicht des Autoren



nicht sinnvoll, eine Serialisierungsvorschrift für die Integration in Item-Entitäten zu entwickeln, ohne diese an die entsprechenden Standards anzulehnen. Für Metada-ten zur Langzeitarchivierung sollte jedoch versucht werden, PREMIS in der Item-Entität und Manifestation-Entität zu integrieren. Die bislang vernachlässigten Marketing- oder handelsspezifischen Metadaten kön-nen ebenfalls mit den vorgestellten Konzepten assoziiert werden. Für den kommer-ziellen Vertrieb ist es primär interessant, Preisangaben, Vertreiberinformationen und die Vertriebsgeschichte zu hinterlegen. Diese Angaben können alle als zur Manifes-tation zugehörig ausgewiesen werden, was eine potentielle Einbindung ähnlich zu deskriptiven Metadaten nahe legt.


Metadatenanreicherung im digitalen Publikationsprozess Modellierung eines erweiterten Prozessmodells für das digitale Publizieren

6 Modellierung eines erweiterten Prozess-modells für das digitale Publizieren Die in diesem Kapitel vorgestellte Modellierung eines erweiterten Prozessmodells zielt darauf ab, einen Teil der bislang vorgestellten Konzepte miteinander zu vereinen und weiterführende Ansätze zu ergänzen, um das Modell auf den praktischen Ein-satz auszurichten. Das erweiterte Prozessmodell wird von der Ressourcenerstellung durch den Autor ausgehen, potentielle Eingriffe durch Verleger diskutieren, bibliothekarische Mitwir-kung bei der Katalogisierung und Archivierung optimieren und die Zugänglichkeit und Distribution der Ressourcen benutzerfreundlich gestalten. Um diesen hochgesteck-ten Zielen gerecht werden zu können, muss das Modell anhand geeigneter Teilas-pekte diskutiert werden, um einen in sich stimmigen Gesamtprozess zu bilden. Die Ausführungen gehen dabei vom Archivierungssystem aus. Das Archivierungs-system wird insbesondere hinsichtlich der Katalogisierung und Metadatenanreiche-rung betrachtet. Aufbauend werden geeignete Einpflegemechanismen von Ressourcen in das Archivierungssystem eingeführt, welche aus Ansätzen der Res-sourcengenerierung und Ressourcentranskription resultieren. Weiterführend wird beschrieben, wie die archivierten Metadaten und Ressourcen Lesern geeignet zu-gänglich gemacht werden, um spezifischen Nutzerbedürfnissen nachzukommen.

6.1 Katalogisierung, Metadatenanreicherung und Archivie-rung Eine einheitliche Katalogisierungsvorschrift für die akkurate Ansetzung von deskripti-ven Metadaten zu Publikationen unterschiedlichster Medientypen und Formate ist neben dem Einsatz von festen Vokabular für wiederkehrende Ansetzungen und der Verwendung von Normdaten die Basis eines erweiterten Prozessmodells. Angesetzte Katalogisate und die dazu generierten Metadaten sind für den Bezug durch international agierende Service Provider bereitzustellen. Folglich muss nicht nur eine nationale Katalogisierungsvorschrift angewendet werden, sondern die An-setzung zu international vorgenommenen Ansetzungen kompatibel gestaltet sein. Bislang wird in deutschen Bibliotheken bei der Formalerschließung die RAK-WB ver-wendet. Die RAK-WB sind jedoch nur teilweise auf internationale Katalogisierungs-standards abgestimmt. Beispielsweise ist eine Abbildung der verwendeten Begrifflichkeiten in RAK-WB nach AACR2 nicht eindeutig möglich. Mit der Einführung von RDA und der Entwicklung von zu verwendendendem Vokabular (RDA Value Vo-cabularies) soll diese Hürde für die Formal- und Sacherschließung überwunden wer-den und eine Harmonisierung zwischen Katalogisierern weltweit erreicht werden. Für die Ansetzung von deskriptiven Metadaten zu einem zu erschließenden Exemp-lar, ist durch die Bibliothekare eine Prüfung auf Existenz eines zugehörigen Werkes im Bibliografiebestand vorzunehmen. Die Exemplar-Entität kann dadurch konform zu RDA zum Werk angesetzt werden. Folglich benötigen Katalogisierer eine virtuell zentralisierte Recherchemöglichkeit über weltweit erschlossene Werke, um diesen Exemplare anzuhängen bzw. bei fehlender Übereinstimmung ein eigenes Werk so-wie Expressionen und Manifestationen in den Datenbestand einzupflegen.



Die weltweit existierenden Werke in nur einem Recherchesystem zugänglich zu ma-chen, bedarf einer hierarchisch strukturierten Organisation von Bibliotheken, Katalo-gisierern und Katalogen, um einen gemeinsamen vertrauenswürdigen Metadatensatz zu generieren und zu pflegen. Die Begrifflichkeit der Vertrauenswürdigkeit umfasst in diesem Kontext insbesondere Regelkonformität und Eindeutigkeit. Schlussfolgernd ist die Grundvoraussetzung einer global konsistenten Katalogisie-rung eine funktionierende Organisation der Bibliothekenstruktur auf internationaler und nationaler Ebene. Dabei darf es ausschließlich vertrauenswürdigen Katalogisie-rern jedes Landes oder von Länderverbünden gestattet sein, in den globalen Katalog Daten einzupflegen. Auf nationaler Ebene muss der globale Katalog für die Katalogi-sierung dupliziert werden, um Anreicherungen durch unterliegende Bibliotheksstruk-turen nachvollziehbar und prüfbar zu machen. Die Einpflege in den globalen Katalog würde entsprechend nur im Anschluss an eine Prüfung durch den national vertrau-enswürdigen Katalogisierer ausgelöst werden. Wie kann eine organisatorische Bibliothekenstruktur in Deutschland Gestalt anneh-men und wer ist in der Lage, die Rolle des vertrauenswürdigen Katalogisierers für die Einpflege in die internationale digitale Bibliothek zu übernehmen? Aktuell ist die DNB für die Erstellung der Deutschen Nationalbibliografie als vertrau-enswürdiger bibliografischer Nachweis erscheinender Publikationen im deutschspra-chigen Raum verantwortlich. Die im Kapitel 4.2 vorgestellte Analyse der exemplarischen partizipierenden Organisationen verdeutlichte bereits den stetig stei-genden Umfang an Neuerscheinungen. Es ist daher fragwürdig, ob eine einzige Bib-liothek dem Anspruch des zu erwartenden Aufgabenumfanges nachkommen kann. Der Autor dieser Arbeit schlägt für die Bildung eines national vertrauenswürdigen Katalogisierers die kooperative Neuerschließung durch die DNB und die Bibliotheks-verbünde (Gemeinsamer Bibliotheksverbund (GBV), Kooperativer Bibliotheksver-bund Berlin-Brandenburg (KOBV), Nordrhein-westfälischer Bibliotheksverbund, Hessisches BibliotheksInformationsSystem (HeBIS), Südwestdeutscher Bibliotheks-verbund (SWB), Bibliotheksverbund Bayern (BVB)) vor. Außerdem ist die Mitwirkung der Betreiber der Zeitschriftendatenbank (ZDB) bei der kollaborativen Neuerschlie-ßung anzustreben. Im Folgenden wird in dieser Arbeit unter dem Namen „Deutscher Katalogisierungsverbund (DKV)“ Bezug zur vorgeschlagenen Vereinigung genom-men. Resultierend müssen die dezentralen Katalogisierungssysteme harmonisiert und virtuell und/oder physisch zentralisiert werden. Für die Kooperation ist ein Ab-gleich der Normdaten (vgl. Kapitel 4.3.2.1 Bestrebungen für die Erschaffung eines Virtual International Authority File) und des gesamten Bestandes notwendig. Des Weiteren gilt es, den Katalogbestand RDA-konform zu überführen, um die Einpflege neuer Entitäten im Bestand durch Katalogisierer zu gestatten und die Übertragbarkeit des nationalen Katalogs in den globalen zu sichern. Die Zuständigkeit der DNB für die gesamte Neuerschließung sollte entsprechend fachspezifisch auf die partizipierenden Organisationen des DKV aufgeteilt werden. Eine fachspezifische Aufteilung bei der Erschließung und Überprüfung von Katalogi-saten vermeidet die Überschneidung bei Ansetzungen zu Werken. Das Replikat des globalen Kataloges würde mit hoher Wahrscheinlichkeit durch die Infrastruktur der DNB bereitgestellt werden. In regelmäßigen Abständen kann sich dieses, wie alle weltweit existierenden nationalen Kopien des globalen Kataloges, Neueintragungen über eine OAI-Schnittstelle in das lokale Katalogisierungssystem vom primären globalen Katalog laden. Aufgrund der extrem hohen anfallenden Da-tenmengen ist die Nachnutzung der OAI-Harvesting-Mechanismen die am besten



geeignete Strategie, da nicht nach Inhalten der Metadaten differenziert wird, sondern festgestellt werden muss, welche Datensätze geändert wurden bzw. hinzugekommen sind, um diese im lokalen Replikat zu integrieren. Entgegengesetzt müssen alle Da-tensätze des globalen Katalogreplikates des DKV gemäß eines Data Providers für den primären globalen Katalog für das Harvesting bereitstehen, um die national vor-genommenen Anreicherungen in das primäre internationale System zu übernehmen. Jedes Mitglied des DKV sollte ein eigenes Lokalsystem betreiben, welches für die Erschließung von Publikationen der jeweiligen fachspezifischen Themengebiete Verwendung findet. Die DKV-Mitglieder müssen vor jeder Ansetzung im nationalen Katalogreplikat des globalen Kataloges nach Entitäten suchen, die der Manifestation entsprechen bzw. Entitäten finden, die das zugehörige Werk reflektieren. Die Suche auf dem Replikat des globalen Kataloges ist mittels einer Client-Anwendung wie Wi-nIBW oder mittels Search/Retrieve via URL (SRU) über die Z39.50-Schnittstelle rea-lisierbar. Bei der Verwendung von SRU wird eine Antwort wie bei OAI-PMH in XML über ein HTTP-Response versendet. Das bedeutet, dass die Suche nicht zwangsläu-fig in einer Client-Applikation integriert werden muss, sondern ebenfalls webbasiert implementiert werden kann. Derzeit wird in der DNB an einer Software gearbeitet, die anhand der Eingabe einer ISBN eine SRU-Anfrage beim Gemeinsamen Bibliotheks-verbund (GBV) stellt. Basierend auf einer Erweiterung dieser softwaretechnologi-schen Lösung können beliebige Anfragen auf den Inhalten der Metadatensätze im globalen Katalogreplikat gestellt werden. Falls ein Metadatensatz eines Werkes zur Suchanfrage gefunden wurde, wird der zum Werk gehörige Metadatensatz komplett in das Lokalsystem des DKV-Mitgliedes übernommen, um eine weitere Anreicherung vorzunehmen. Falls kein entsprechender Metadatensatz gefunden werden konnte, muss im Lokalsystem ein neuer Datensatz zum zu erschließenden Werk und allen FRBR-Entitäten RDA-konform angesetzt werden. Die Anreicherungen in den Lokal-systemen der DKV-Mitglieder werden dem Replikat des globalen Kataloges nach Vollendung der Erschließung über eine OAI-Schnittstelle zum Harvesting bereitge-stellt. Der geharvestete Metadatensatz muss vor der Übernahme aus dem nationalen Replikat des globalen Kataloges in den primären globalen Katalog auf Kollisionen mit dem entsprechenden Metadatensatz zum Werk überprüft werden. Solche Kollisionen können auftreten, wenn ein anderer vertrauenswürdiger Katalogisierer auf nationaler Ebene während der Bearbeitungszeit durch das DKV-Mitglied Änderungen an dem entsprechenden Metadatensatz vorgenommen hat. In diesem Falle wäre das DKV-Mitglied zu einer Überarbeitung des Metadatensatzes gezwungen. DKV-Mitglieder sind jeweils für ein bestimmtes Set von Datensätzen des Replikates des globalen Kataloges verantwortlich. Die Sets müssen entsprechend in den Kata-logen für ein akkurates Harvesting und somit einen selektiven Metadatenbezug aus-gezeichnet sein. Als potentielle Zugehörigkeitscharakteristik von Werken zu einem Set kann eine international angewandte Klassifikation wie die Dewey Decimal Classi-fication (DDC) dienen. Folglich ist ein DKV-Mitglied immer für ein gesamtes Werk und alle enthaltenen Manifestationen in unterschiedlichsten Publikationsformen zu-ständig. Für die Ansetzung von deskriptiven sowie aller weiteren Arten von Metada-ten muss es speziell geschultes Personal für die einzelnen Publikationsformen geben. Es ist außerdem abzuwägen, ob die Sacherschließng weiterhin durch ein ge-sondertes Referat vorgenommen werden soll. Für ausgewählte Publikationen sollten zusätzliche externe Experten bei der Erschließung beitragen. Ausgewählte Publikati-onen können Veröffentlichungen aus Sondersammelgebieten sein, für die besondere Hilfe bei der Sacherschließung benötigt wird, wie auch Medienformen, die auf die Nachnutzung durch einen bestimmten Leserkreis (bspw. Gehörlose) abzielen.



Die organisationstechnisch unterliegenden Bibliotheken, wie Landes-, Staats- und Universitätsbibliotheken (beispielsweise SLUB), könnten ebenfalls mittels WinIBW oder über SRU auf dem nationalen Replikat des globalen Katalogs suchen, um den Datensatz des Werkes bei Übereinstimmung mit der zu archivierenden Manifestation in ihr Lokalsystem zu laden bzw. einen Exemplareintrag direkt im Replikat einzupfle-gen. Die Eintragung von zusätzlichen Exemplaren, ganz gleich ob im Lokalsystem oder im Replikat des globalen Kataloges, muss strikten Regeln folgen, da somit kei-ne nachträgliche Prüfung durch ein DKV-Mitglied notwendig ist. Bei der Neuanset-zung von Entitäten, die nicht ausschließlich ein Exemplar betreffen, ist der geänderte Datensatz zum Werk durch eine OAI-Schnittstelle dem zuständigen DKV-Mitglied zum Harvesting und zur anschließenden Prüfung bereitzustellen. Im Falle, dass der Metadatensatz den Ansprüchen der aufzubauenden Bibliografie entspricht, kann die-ser in das Replikat des globalen Kataloges eingepflegt werden. Falls Überarbeitun-gen am Datensatz notwendig sind, müssen diese durch das zuständige DKV-Mitglied gegebenenfalls in Kooperation mit dem Metadatenbereitsteller vorgenommen wer-den. Neben Staats-, Landes und Universitätsbibliotheken muss es selbstverständlich allen anderen Bibliotheken Deutschlands gestattet sein, einen Abgleich und eine Einpflege erweiterter und neuer Datensätze entsprechend dem vorgestellten Prüfungsverfah-ren vorzunehmen. Als vereinfachte Alternative zu eventuell nicht vorhandenen Client-Applikationen bzw. zur OAI-Schnittstelle kann für die Metadatensuche und Metada-tenrückmeldung auf ein webbasiertes Benutzerinterface zurückgegriffen werden. Voranmeldungen von Neuerscheinungen beim Marketing- und Verlagsservice des Buchhandels GmbH (MVB) im Verzeichnis lieferbarer Bücher (VLB) müssen eben-falls an die DKV-Mitglieder RDA-konform übermittelt werden. Im Replikat des globa-len Kataloges ist bei den entsprechenden Entitäten zu vermerken, dass es sich um Ankündigungen eines komplett neuen Werkes oder von einzelnen neu erscheinen-den Manifestationen zu einem existierenden Werk handelt. Da die Abgabe der Pflichtexemplare in gedruckter Form an die DNB bislang zumeist eine Zeitverzögerung nach sich zieht und die Abgabe digitaler Ressourcen eine zu-sätzliche Sicherung für die Langzeitarchivierung bietet, sollte jeder Verlag durch den Gesetzgeber gezwungen sein, zum Veröffentlichungszeitpunkt eine dem Druck zu-grunde liegende digitale Version für die Archivierung beim DKV abzugeben. Verle-ger, deren Voranmeldung bereits im Katalog aufgenommen wurde, können das publizierte Exemplar an den Datensatz anhängen, wohingegen für nicht-vorangemeldete Publikationen der gesamte Datensatz durch den Verlag anzusetzen ist. Für die Ansetzung müssen Verleger ähnlich wie Bibliothekare durch eine soft-waretechnologische Lösung unterstützt werden. Der angesetzte Metadatensatz mit dem Vermerk zur digitalen Ressource muss anschließend an ein DKV-Mitglied ge-sendet und durch dieses überprüft werden. Für die Ansetzung von nachträglich zu-gesandten Pflichtexemplaren in Papierform oder auf Datenträgern ist nicht der Verleger, sondern ausschließlich der Bibliothekar im DKV verantwortlich. Die Meldung und Abgabe von fortlaufenden Publikationen sowie anderen Publikati-onsformen muss nach einem ähnlichen Prinzip realisiert werden. An dieser Stelle soll außerdem die Rolle von Medibus besonders hervorgehoben werden. Medibus als deutschlandweit zuständiger Katalogisierer und perspektivisch zentralisierter Langzeitarchivierer von sehgeschädigtengerechter Literatur muss die unter seiner Schirmherrschaft erstellten Ressourcen an die DKV-Mitglieder vor-schriftsgerecht melden. Prozesstechnisch gesehen, würde eine produzierende Orga-



nisation wie die DZB eine Absichtserklärung zu produzierenden Publikationen bei Medibus anmelden, woraufhin Medibus eine Recherche zur Existenz des Werkes im Replikat des globalen Kataloges vornimmt. Mit der Produktionsgenehmigung muss Medibus den entsprechenden bibliografischen Metadatensatz (Basis aus DKV über-nommen und selbst angereichert) dem Produzenten bereitstellen. Dieser Metadaten-satz muss bei der Produktion digitaler Ressourcen wie DTBs in das Exemplar Publikationsstandard-konform integriert werden. Im Anschluss an die Ressourcen-produktion muss der Metadatensatz zum Exemplar für die Einpflege im globalen Ka-talog RDA-konform mit Details zur produzierten Ressource angereichert werden. Produzenten wie die DZB sind in der Lage, dies im Haus eigenständig umzusetzen, wohingegen andere Produzenten die vollständig RDA-konforme Ansetzung in Ko-operation mit Medibus vornehmen sollten. Der RDA-konforme Metadatensatz kann vollständig oder teilweise (nur sehgeschädigtengerechte Ressourcen) durch die DZB im eigenen lokalen Katalogsystem nachgenutzt werden, um verschiedene Typen von Manifestationen zu einem Werk auszuweisen. Die zum globalen Katalog konforme Ansetzung für das gesamte Werk samt RDA Value Vocabularies für sehgeschädig-tengerechte Publikationen sind letztendlich durch Medibus und speziell geschultes Personal abzusichern. Dadurch soll eine minimierte Nachkontrolle durch das zustän-dige DKV-Mitglied erreicht werden. Der Metadatensatz selbst und gegebenenfalls die elektronische Ressource sind dem DKV über eine OAI-Schnittstelle zum Harvesting zur Verfügung zu stellen. Produzenten hörgeschädigtengerechter, dyslexikergerechter oder anderer Spezialli-teratur sollten sich analog zu Medibus hierarchisch organisieren, um Metadatenan-reicherungen auf höchstem Niveau für ihre publizierten Manifestationen im globalen Katalog bereitzustellen. Nicht-professionell publizierenden Anwendern muss eine Webanwendung zur Verfü-gung stehen, die es auf intuitive Art erlaubt, möglichst viele Metadaten standardkon-form anzusetzen. Die Webanwendung würde somit die aktuell angebotene formularbasierte Publikationseinpflege ablösen und die Verwendung zusätzlicher Software vermeiden. Es soll auch hier möglich sein, im Replikat des globalen Kata-logs zu suchen, um gegebenenfalls Anreicherungen vorzunehmen. Der wohl am häufigsten auftretende Fall wird jedoch die Ansetzung neuer Werke zu eigenen Pub-likationen sein. Die angesetzten Daten sind auch in diesem Fall durch ein DKV-Mitglied vor der endgültigen Einpflege zu überprüfen. Bislang wurde primär die Ansetzung der deskriptiven Metadaten diskutiert. Das Kapi-tel 2.3 verdeutlichte, dass für einen funktionierenden Archivierungsprozess außer-dem eine Reihe weiterer Arten von Metadaten notwendig sind. Rechte-Management-Metadaten und Marketing- oder handelsspezifische Metadaten können analog zu den deskriptiven Metadaten durch den Produzenten oder Verleger bei der Anmeldung der Publikation hinterlegt werden. Die Ansetzung von administrativen Metadaten, technischen Metadaten und Metada-ten zur Langzeitarchivierung liegen im Verantwortungsbereich des Archivbetreibers und somit des DKV. Die Anreicherung muss durch den DKV lokal vorgenommen und die Metadaten im AIP (vgl. Kapitel 5.2.3) hinterlegt werden. Bei der Recherche auf dem Replikat des globalen Kataloges durch Dritte ist durch den DKV festzulegen, welche dieser Metadaten für externe Organisationen sichtbar sein dürfen. Das Kapitel 5.2 hob außerdem die besondere Bedeutung von Struktur-Metadaten und Accessibility-Metadaten hervor. Entsprechend muss diskutiert werden, welche



prozesspartizipierenden Organisationen für die Anreicherung dieser Metadaten ver-antwortlich sind. Struktur-Metadaten sind bei der Nachnutzung einer vereinbarten Ressourcenerstel-lungsvorschrift bzw. Templates (vgl. Kapitel 6.2) aus einem Exemplar ableitbar. Eine manuelle nachträgliche Strukturierung einer Manifestation ist zum Teil sehr schwierig bis unmöglich, da die zugrundeliegenden digitalen Publikationen diverse Grundvor-aussetzungen erfüllen müssen. Für digitale Ressourcen, die diesen Grundvorausset-zungen nicht genügen sowie für nicht-digitale Ressourcen, muss es einpflegenden Verlegern, Bibliothekaren oder sogar externen Experten mittels zugeschnittener Software ermöglicht werden, die nachträgliche manuelle Strukturierung bequem durch visuelle Unterstützung vorzunehmen und die Kontrolle der automatisch gene-rierten Strukturierung benutzerfreundlich zu überprüfen. Eine softwaretechnische Umsetzung zur manuellen Strukturierung muss es dem Me-tadatenanreichernden ebenfalls ermöglichen, Assoziation zwischen Manifestationen und Zugriffsmodalitäten zu Manifestationen als Minimum an Accessibility-Metadaten zu definieren. Außerdem muss es möglich sein, den definierten Struktureinheiten Bestandteile von Primary Resources und Equivalent Alternative Resources sowie den vollen Umfang an Accessibility-Metadaten zuweisen zu können. Des Weiteren sollte eine Möglichkeit bestehen, den Struktureinheiten erweiterte deskriptive Meta-daten (beispielsweise zu Publikationsteilen wie Artikeln) zuordnen zu können. Da es Produzenten von Primary Resources zumeist am notwendigen Fachwissen bezüglich Barrierefreiheit fehlt, empfiehlt es sich, Accessibility-Metadaten durch Ac-cessibility-Experten des Verlags, der archivierenden Organisation bzw. durch externe Experten wie Produzenten barrierefreier Alternativressourcen ansetzen zu lassen. Es ist offensichtlich, dass die Strukturierung und entsprechende Metadatenanreiche-rung bei manueller Ansetzung, nicht auf dem im Kapitel 5.2 beschriebnen feingranu-laren Niveau stattfinden kann. Das nachfolgende Kapitel wird sich unter anderem mit der automatisierten Generierung von Equivalent Alternative Resources beschäftigen, durch die während der Generierung alternativer Manifestationen eine automatisierte Accessibility-Metadatenanreicherung erreicht wird. Für sämtliche Organisationen, die mit dem DKV interagieren, ist es zwingend not-wendig, sich an die Submission-Richtlinien bei der Metadatenanreicherung sowie bei der Pflichtexemplarbereitstellung zu halten. Im Anschluss an die Übernahme des Metadatensatzes in das Replikat des globalen Kataloges ist eine Abholung von Netzpublikationen einzuleiten. In einem nationalen Archivierungssystem, ähnlich dem existierenden der DNB, sind Archivexemplare aller Publikationen zu hinterlegen. Die physische Ablagestruktur sollte an die hard- und softwaretechnischen sowie organisatorischen Gegebenheiten (Schemas zur allge-meinen Ablage etc.) angepasst werden. Logisch gesehen werden die Publikationen zu den entsprechenden Archival Information Packages (AIP) durch die Exemplar-Entitäten im Metadatensatz assoziiert. Die Übernahme von Archivexemplaren in ein System auf internationaler Ebene ist aus Sicht des Autors dieser Arbeit fragwürdig, da die Langzeitarchivierung im nationalen Archivsystem gesichert wird. Auf internati-onaler Ebene ist die Sammlung der Metadaten von primärer Bedeutung, da diese die Zusammenführung der national vorhandenen physischen Bestände ermöglicht. Abbildung 6.1 zeigt exemplarische partizipierende Organisationen, die Ressourcen und zugehörige Metadaten im Archivierungssystem des DKV einpflegen (ingest). Aus Gründen der Übersichtlichkeit werden die Systeme des DKV als Einzelsystem (Rep-



likat des globalen Katalogs) illustriert. Neben der Anreicherung der verschiedenen Arten von Metadaten übernehmen die ausgewiesenen Accessibility-Experten (AE) während der Einpflege die Anreicherung von Accessibility-Metadaten und falls durch den Verleger oder Archivbetreiber gewünscht, auch eine feingranularere Strukturie-rung von Manifestationen sowie deren Struktureinheitenassoziation. Des Weiteren weist die Abbildung die Archivierung (archival storage) der Ressourcen aus. Der durch das Archivierungssystem vollzogene OAI-basierte Metadatenaustausch zum primären globalen Katalog und zu unterliegenden Katalogisierern soll über die Schnittstellen des Service Providers und des Data Providers verdeutlicht sein. Ein entsprechendes Metadatenaustauschformat muss durch die Administration des Ar-chivierungssystems für die beteiligten Organisationen festgelegt sein. Ein potentielles Austauschformat wurde in Kapitel 5.2.3 vorgestellt. Ein Endnutzer der seine Recher-che im globalen Katalog durchführt, profitiert insbesondere vom ausgeführtem Har-vesting, da er so über eine einzige Benutzerschnittstelle eine Suche auf den weltweit verfügbaren Katalogen vornehmen kann und einen Bezug der Ressourcen über die Distributionsfunktionalität (access) des Archivierungssystems auslösen kann.

MVB

Verlag X

Medibus

DZB

SLUB

Archivierunssystem des DKV

ingest

cataloguing by RDA

accessibility enrichment

unabhängiger Autor

access archival storage

data provider

service provider

AE

AE

AE

AEAE

AE

AE

Endbenutzer

…

…

Abbildung 6.1: Beteiligte Organisationen bei der Metadatenanreicherung im Archivie-rungsprozess des DKV Die im Archivierungssystem ausgewiesenen Entitäten weisen eine Konformität zu den Prinzipien des OAIS Reference Model auf. Die Entitäten Data Management, Administration und Preservation Planning wurden in Abbildung 6.1 aus Gründen der Übersichtlichkeit nicht explizit dargestellt, obwohl sie für das Funktionieren des Archi-vierungssystems integriert sein müssen und für die Aufbewahrung von Ressourcen gemäß der Langzeitarchivierung essentiellen Charakter besitzen. Kapitel 6.4 diskutiert eine Erweiterung des vorgestellten Konzeptes bezüglich einer nachträglichen Anreicherung von Accessibility-Metadaten durch beliebige Benutzer. Der Ansatz zur kollaborativen Accessibility gestattet die Zuweisung von externen Equivalent Alternative Resources zu einzelnen Struktureinheiten der Manifestatio-nen, ohne das Copyright dieser Manifestation zu verletzen. Die Voraussetzung für die nachträgliche Anreicherung ist jedoch eine feingranulare Strukturierung der ein-gepflegten Manifestationen.



6.2 Ressourcenproduktion und Einpflege Die Produktion von Ressourcen bezieht sich auf die Gestaltung einer Manifestation und der Generierung einzelner Exemplare. Bezüglich der Einpflege werden Ansätze zur unterstützten Metadatenanreicherung und zur automatisierten Generierung von Equivalent Alternative Resources und Aspekte zur Einpflege der Publikationen und der Metadaten in Form von Information Packages im Archivierungssystem diskutiert. Die Produktion von textbasierten Ressourcen wird prinzipiell durch einen Autor unter Zuhilfenahme eines Autorenwerkzeuges vorgenommen. Diese textuellen Ressour-cen bilden fast immer die Basis für die Generierung von weiteren Manifestationen. Ein Buch kann anhand der digitalen Vorlage gedruckt werden, für die Produktion ei-ner Multimediapräsentation können zusätzliche Inhalte angereichert oder ein Hör-buch anhand des zugrunde liegenden Textes aufgelesen werden. Die hier diskutierten Publikationsprozesse werden immer von textbasierten Ressour-cen ausgehen, so dass in dieser Arbeit keine Publikationsformen wie Film, Bilder, Karten etc. im Sinne eines Werkes betrachtet werden. Für die qualitativ hochwertige Produktion von Publikationen ist ein Autor angehalten, sich an Richtlinien für die normkonforme Publikationserstellung zu halten. Diese Normen können die Vorgabe eines zu verwendenden Autorenwerkzeuges, Layout-richtlinien durch den Verlag oder Strukturierungsvorschriften umfassen. Im kommer-ziell orientierten Verlagswesen wird ein Autor zwar nie die letzten Überarbeitungen vornehmen, jedoch ist die Einhaltung gewisser Regeln bei der Erstellung von Publi-kationen für eine minimierte Nachbearbeitung von hoher Bedeutung. Ein Autor, der seine Publikation nicht kommerziell verlegen lässt, ist für die Qualität seiner Publika-tion selbst verantwortlich, was die Unterstützung durch Autorenregeln umso wichtiger macht. Was sollten Regelwerke für Autoren beinhalten? Neben Hinweisen zur prinzipiellen logischen Gestaltung von Publikationstypen muss ein Regelwerk für die Erstellung textbasierter digitaler Ressourcen Angaben über das Layout (Lesbarkeit etc.) und die Strukturierung des Textes treffen. Außerdem muss der Autor zur Integration von Me-tadaten in der Publikation verpflichtet werden. Für die praktische Umsetzung dieser Anforderungen gilt es, dem Autor im Umgang mit seinem Autorenwerkzeug zu assis-tieren. Eine solche Assistenz würde unter anderem die Generierung akkurat struktu-rierter Texte und die Generierung fachspezifischer Inhalte wie Formeln, Diagramme etc. umfassen. Wenn Regelwerke von Verlagen, Universitäten und/oder Bibliotheken für die Autoren bereitgestellt werden, ist eine einheitliche Qualität der digitalen Publi-kationen gewährleistbar. Die Autorenrichtlinien dürfen neben Regeln zur Erhöhung der Dokumenten-gebrauchstauglichkeit Aspekte der Barrierefreiheit nicht vernachlässigen. Die akkura-te Textstrukturierung und Generierung von Spezialinhalten ist hierfür insbesondere von Wichtigkeit. Außerdem müssen Regeln für die Einbindung alternativer Beschrei-bungen für visuelle Inhalte eingebunden sein. Es gilt in der Praxis nicht nur Produ-zenten von traditionellen Publikationen durch Autorenrichtlinien zu unterstützen. Ebenso müssen Vorschriften wie [MOB08] für die Produktion von alternativen Res-sourcen bereitstehen, um auch für diese Manifestationen einheitliche Qualität über den zugrundeliegenden Standard hinaus zu garantieren. Durch die akkurate Einhal-tung der Richtlinien ist eine Trennung von Layout und Inhalt möglich und folglich ein automatisierter Export in sekundäre Formate in hoher Qualität realisierbar.



Auf dem Markt platzierte Autorenwerkzeuge sind bereits in der Lage, einen automati-sierten Export in sekundäre Formate zu unterstützen. Der am häufigsten eingesetzte Exportfilter nimmt die Überführung textbasierter Publikationen in PDF vor. Durch ei-nen Export in PDF ist es dem Publizierenden möglich, die erstellte Publikation lay-outgetreu zu distribuieren und die enthaltenen bibliografischen Metadaten im XMP-Format im PDF zu integrieren. Zusätzlich besitzen Autorenwerkzeuge eine Reihe weiterer Exportfilter, die es beispielsweise gestatten, die Publikation in eine webge-rechte Form zu transkribieren. In diesem Zusammenhang sollen zwei Open-Source-Projekte vorgestellt werden, die Autorenwerkzeugserweiterungen für die Transkription von XML-basierten Office-Dokumenten in DTBs ohne die Nutzung von teuren DAISY-Produktionswerkzeugen erlauben. OpenDocument To DAISY DTBook (odt2dtbook) [OTD08] ist eine Erweiterung für den OpenOffice.org Writer. Das Plug-in ermöglicht den Export von ODF v1.1 Doku-menten in DTBs im ANSI/NISO Z39.86-2005 Standard und die Einbindung von ma-thematischen Inhalten im MathML Standard [MML03]. Das Plug-in nutzt die Vielfalt von Accessibility-Features des ODF v1.1 Standards nach, um eine qualitativ hoch-wertige Generierung eines DAISY DTBook XML Files zu garantieren. Autorenrichtli-nien für die Erstellung barrierefreier Dokumente in der OpenOffice.org Applikation finden sich in [ODFAG07]. Weiterführende Ergänzungen für die Generierung sowie die Nutzung von Templates mit unterstützten Formatvorlagen für die beabsichtigte Transformation des Dokumentes in das DAISY-Format durch das odt2dtbook-Plug-in sind explizit in [OTDIM08] festgehalten. Bislang können durch das Plug-in (Version 1.1.0) ausschließlich textuelle DTBs erzeugt werden. Es ist jedoch beabsichtigt, in zukünftigen Versionen Sprache zu integrieren und somit eine Generierung von Voll-textbüchern zu gestatten. Das Pendant zum odt2dtbook-Plug-in aus dem Hause Microsoft ist der Open XML to DAISY XML Translator bzw. das Save as DAISY XML Add-in [OXDT08]. Das Add-in ist für Microsoft Word 2007, 2003 und XP verfügbar. Die Entwicklung des Translators wird in einer Kooperation durch Microsoft, Sonata Software Ltd. und dem DAISY Consortium vorangebracht. Das Add-in ermöglicht es, Office-Open-XML-basierte Textdateien in DAISY DTBook XML Files umzuwandeln. Die Version 1.4 von Save As DAISY XML ist wie das odt2dtbook-Plug-in in der Lage, rein textuelle DAISY XML Files mit MathML-Unterstützung zu generieren. Die Entwicklergruppe kündigte be-reits für Ende 2008 die Veröffentlichung der Version 2.0 an, welche auch die Gene-rierung von DTB-Volltextbüchern durch eine integrierte Text-to-Speech-Engine realisieren soll. Zu Beginn 2009 ist die neue Version jedoch noch nicht verfügbar, was daher an dieser Stelle keine Aussagen über die Qualität der generierten Res-sourcen zulässt. Microsoft bietet ebenfalls eine Autorenunterstützung durch Richtli-nien [DTAG08] und die Bereitstellung von Templates mit unterstützten Formatvorlagen an. Zusätzlich werden durch das Add-in Features im Autorenwerk-zeug eingebunden, die die barrierefreie Auszeichnung von Dokumentinhalten be-günstigen. Beide Translatoren verlangen die strikte Einhaltung der Autorenrichtlinien und die Nachnutzung der angebotenen Templates mit den unterstützten Formatvorlagen für die akkurate Transkription der Quelldokumente. Die generierten DAISY XML Doku-mente können durch zusätzliche Software in eine braillegerechte Form überführt oder als Basis für die Volltextbuchgenerierung verwendet werden.



Im Oktober 2008 wurde außerdem ein Save As DAISY XML Feature für Adobe InDe-sign CS4 veröffentlicht. Eine durch das DAISY Consortium vorangebrachte Entwicklung ist die DAISY Pipeli-ne [DPIP08]. Die DAISY Pipeline ist ebenso ein Open Source Projekt, das das Ziel verfolgt, leicht und effizient in den digitalen Publikationsprozess integriert werden zu können. Die softwaretechnologische Umsetzung enthält Validierungskomponenten für verschiedene Formate, Transformationsfilter und Mechanismen zur Inhaltsanrei-cherung wie die Generierung von synchronisierter synthetischer Sprache zu DAISY DTBook XML Files. Prozesstechnisch betrachtet, werden der Pipeline in Autoren-werkzeugen generierte Quelldokumente (unterstützt werden derzeit die Formate RTF, (X)HTML, Word 2003 XML) als Input zur Verfügung gestellt, welche in ein DAISY-Master-Dokument (DAISY DTBook XML File) transformiert werden. Aus dem DAISY-Master-Dokument ist es möglich, gedruckte sowie elektronische Braillereprä-sentationen oder verschiedene DTB-Ausprägungen generieren zu lassen. Außerdem stellt die Software Migrationsfilter für die Überführung von DTBs in aktuelle DAISY-Formate bereit. Diese Funktion garantiert die Sicherung der zukünftigen Zugänglich-keit der Publikationen gemäß Strategien der Langzeitarchivierung. Während der Testphase der DAISY Pipeline durch den Autor dieser Arbeit musste festgestellt werden, dass keine Autorenanleitungen für die Gestaltung adäquater Quelldokumen-te für die Transformation in der Pipeline vorlagen, was zu einer erhöhten Fehlerrate führte. Dieser Fakt verdeutlicht die Notwendigkeit von Autorenrichtlinien und Templa-tes für die automatisierte Generierung von Equivalent Alternative Resources aus ei-nem digitalen Quelldokument. Die vorgestellten Transformationstechnologien sollen dazu dienen, dem Leser einen exemplarischen Einblick in Lösungsansätze zur automatisierten Generierung von Alternativversionen zu geben. Resultierend muss geklärt werden, wie die alternativen Exemplare der verschiede-nen Manifestationen zu einem gemeinsamen Werk in ein Archivierungssystem wie das Repository des DKV mit entsprechenden Metadaten eingepflegt werden können. Im Kapitel 6.1 wurde verdeutlicht, dass einpflegende Organisationen dem Archivie-rungssystem ein Submission Information Package (SIP) gemäß des OAIS Reference Model zur Verfügung stellen müssen. Das SIP sollte optimalerweise die generierten digitalen Exemplare und alle zugehörigen Arten von Metadaten, entsprechend den durch die Administration des Archivierungssystems vorgeschriebenen Vorschriften (SIP-Gestaltung bezüglich Ressourcenanordnung/-referenzierung, Metadatenseriali-sierungsstandard und Metadatenkernset), beinhalten. Für die Einpflege alternativer Exemplare zu einem Werk müssen folglich Softwarepa-kete innerhalb der publizierenden Organisationen bereitstehen, die eine Ansetzung der Metadaten und eine Generierung eines SIP mit den zugehörigen Ressourcen ermöglichen. Primär gilt es, für die Metadatenansetzung die FRBR-Entitäten RDA-konform zu spezifizieren. Hierfür würden durch den Metadatenanreichernden vorran-gig deskriptive Metadaten angesetzt werden. Die Ansetzung von Struktur-Metadaten bezüglich der inneren Ordnung von Dateien einer Manifestation wäre ebenfalls relativ unkompliziert realisierbar. Allerdings ist es wünschenswert, eine logische Strukturie-rung der Manifestation vorzunehmen. Dadurch können einzelnen logischen Struktur-einheiten Dateien oder Teile dieser zugeordnet werden. Bei der Einhaltung von Autorenrichtlinien kann eine logische Struktur in einzelnen Dateien auf Basis der Textstrukturierung in der Datei automatisiert bestimmt werden. Resultierend müssten



durch den Metadatenanreichernden die übergeordneten Strukturebenen für die Mani-festation und deren Struktureinheiten manuell definiert werden. Anhand regelkonformer Dateien kann ebenfalls ein Teil der Accessibility-Metadaten (Zugriffsmodalitäten, Adaptierbarkeit) zu den Struktureinheiten automatisiert be-stimmt werden. Die Schwierigkeit, die jedoch mit diesem Ansatz einhergeht, liegt in der Assoziation von Struktureinheiten unterschiedlicher Manifestationen. Die Mani-festationen selbst sind manuell mit überschaubarem Aufwand durch Accessibility-Metadaten in Beziehung setzbar. Jedoch ist eine manuelle Assoziation der feingra-nularen Struktureinheiten der Manifestationen trotz automatisierter Ressourcengene-rierung mit einem nicht akzeptablen Zeitaufwand verbunden. Aus diesem Grund soll im Folgenden ein Ansatz vorgestellt werden, welcher die au-tomatisierte Anreicherung von Struktur-Metadaten und Accessibility-Metadaten für alternative Exemplare verschiedener Manifestationen automatisiert ermöglicht. Der Ansatz wird die Generierung der Equivalent Alternative Resources und deren Meta-daten Server-seitig vornehmen. Die Server-seitige Generierung ist nicht zwingend notwendig, gestattet es jedoch, auch nicht-professionellen Publizierenden ihre Res-sourcen in alternativen Formen für die Konsumenten anzubieten. Ein SIP würde folglich nur ein Exemplar enthalten, welches der Primary Resource entspricht. Zusätzlich müssten dem SIP bereits Metadaten angereichert worden sein bzw. besteht für Publizierende die Möglichkeit, diese bei der Einpflege unter Zuhilfe-nahme einer Webanwendung nachträglich anzureichern. Bevor die automatisierte Metadatenanreicherung diskutiert wird, soll ein existierender Prototyp für die Server-seitige Generierung von Equivalent Alternative Resources vorgestellt werden. DAISY4DSpace [RIB08] ist ein an der Universität Barcelona ent-wickeltes System, dem das international weit verbreitete digitale Repository DSpace [DSPA08] zugrunde liegt. DSpace ist Gegenstand der Entwicklung eines durch das Massachusetts Institute of Technology (MIT) und Hewlett Packard (HP) ins Leben gerufenem Open-Source-Projektes. DAISY4DSpace profitiert von der bereits um-fangreich implementierten Funktionalität des Archivierungssystems und der Zugäng-lichkeit des Quellcodes. Aufbauend wurde an der Universität Barcelona eine Integration der DAISY Pipeline und der in ihr enthaltenen Transformationsfilter in DSpace als Importfilter (Mediafilter) integriert. Einzupflegende Quelldokumente müs-sen ebenfalls auf Basis von durch Accessibility-Experten erzeugten Templates in festgelegten Autorenwerkzeugen produziert werden. [RIB08] sieht perspektivisch die Einpflege von Ressourcen aus Microsoft Word und OpenOffice.org Writer sowie DTBook XML Files vor. Die Transformation kann im Anschluss an den Upload der Ressource durch den Archivbetreiber (Administrator) ausgelöst werden. Die Ergeb-nisse müssen vor einer Freigabe (Transformation des SIP in ein AIP) durch den Ad-ministrator und im optimalen Falle auch durch den Autor in einem abgestimmten Workflow validiert werden. [RIB08] weist als alternative Ressourcen neben DTBs ex-plizit XHTML und PDF-Dokumente in Großschrift als nützliche Ressourcen für den Konsum durch Endnutzer mit besonderen Bedürfnissen aus. Als offene Aspekte der Betrachtungen zu DAISY4DSpace hob die Autorin den Mangel an Metadaten zur Assoziation der Manifestationen und die Ungewissheit über die Ausweisung einer primären Ressource hervor. Nachfolgend wird dies unabhängig vom DSpace-Repository durch den Autor dieser Arbeit konzeptionell diskutiert. Ein SIP kann folglich das Quelldokument, welches autorenregelkonform im Autoren-werkzeug erzeugt wurde sowie den gesamten Metadatensatz zu den anzusetzenden Entitäten enthalten. Falls durch den Einpflegenden nicht der vollständige Metadaten-



satz im SIP integriert wurde, was dem praktischen Vorgehen in der Realität weitaus näher kommt, muss das Archivierungssystem bei der Einpflege den Metadatenanrei-chernden durch ein Assistenzsystem unterstützen, um den vollständigen Metadaten-satz anzureichern. Ein entsprechendes Assistenzsystem muss dem Einpflegenden primär erlauben, die deskriptiven Metadaten RDA-konform anzusetzen. Weiterfüh-rend sollte es ihm gestattet sein, Marketing- und handelsspezifische Metadaten an-zureichern. Bei der Ansetzung von Rechte-Management-Metadaten muss der Einpflegende festlegen, welche Ressourcen durch die Filter im Archivierungssystem generiert werden sollen und welche Benutzer welche Art von Zugriff zu einer gene-rierten Ressource bekommen dürfen. Eine beispielhafte Rechtevergabe könnte ein eingereichtes Exemplar als Word-Dokument betreffen, welches nur für den Publizie-renden und das Personal des Archivierungssystems zugreifbar ist, eine generierte PDF-Version wäre für alle Benutzer frei oder gegen ein Entgelt konsumierbar und ein DTB für registrierte Nutzer mit besonderen Bedürfnissen frei zugänglich. Administrative und technische Metadaten sowie Metadaten zur Langzeitarchivierung wären nicht durch den Einpflegenden, sondern durch das Personal des Archivbetrei-bers nachträglich anzureichern. Jedoch ist der Einpflegende (gegebenenfalls durch die Unterstützung eines Accessibility-Experten) für die Anreicherung der Struktur-Metadaten und der Accessibility-Metadaten verantwortlich. Die Struktur-Metadaten können für jede im SIP enthaltene Datei aufgrund der vorge-nommenen Textstrukturierung automatisiert erkannt werden. Für jede Datei einer Manifestation wird eine übergeordnete Struktureinheit gebildet, die manuell durch den Metadatenanreichernden zueinander in Beziehung zu setzen sind. Das ref-Attribut im Metadatensatz einer Struktureinheit weist immer auf das erste Element der entsprechenden Ebene im Dokument bzw. auf das Parent-Element aller unterlie-genden Elemente. Die Referenzierung der Elemente in den zugrunde liegenden Da-teien wird über einen Verweis auf die name-Attribute oder id-Attribute der Elemente realisiert. Diese Attribute werden prinzipiell von den meisten Autorenwerkzeugen in-tegriert. Anhand der Art der enhaltenen Elemente kann eine Zugriffsmodalität auto-matisiert spezifiziert werden. Übergeordnete Struktureinheiten besitzen folglich die Zugriffsmodalitäten aller untergeordneten Struktureinheiten. Außerdem ist durch den Typ der eingepflegten Ressource und der zugehörigen Erstellungsvorschrift die Adaptierbarkeit ableitbar. Bei multimedialen Ressourcen wie DTBs muss neben der Textstruktur auch die syn-chrone Multimediaanreicherung auf Struktureinheiten abgebildet werden. Durch die Verwendung von standardisierten Synchronisationssprachen wie SMIL sind Struktur-Metadaten ebenfalls durch einen Parsing-Prozess automatisiert ableitbar. Für nicht automatisiert erschließbare Struktur-Metadaten, wie die logische Zusam-menführung von Dateien eines File-Bundles (bspw. HTML-Dateien, MP3-Dateien in einem Hörbuch), muss dem Einpflegenden eine Benutzerschnittstelle zur manuellen Strukturdefinition bereitgestellt werden. Diese Strukturen würden somit die überge-ordneten logischen Struktureinheiten bilden. Die Benutzerschnittstelle für die manuel-le Struktur-Metadaten-Ansetzung sollte Beziehungen für den Benutzer visuell aufbereiten, um weniger erfahrenen Publizierenden die Möglichkeit zur intuitiven Ressourceneinpflege zu geben. Falls nicht-professionelle Benutzer nicht in der Lage sind, die Metadatenanreicherung eigenständig vorzunehmen, sollte dies durch den Bibliothekar bzw. den Accessibility-Experten des Archivierungssystems nachgeholt werden.



Im Anschluss an die Strukturierung der Manifestation kann der Publizierende zu den definierten Struktureinheiten erweiterte deskriptive Metadaten ansetzen, die als Ver-feinerung zu den Metadaten der Manifestation angesehen werden können und zur Auffindung spezieller Teile (z. B. Artikel) in einer Manifestation dienen sollen. Falls ein Publizierender die Generierung alternativer Ressourcen wünscht, muss an-hand der Rechte-Management-Metadaten entschieden werden, welche Ressource für Endbenutzer die Rolle der Primary Resource einnimmt. Für die Generierung wäre dies selbstverständlich das eingepflegte Quelldokument. Wenn das Quelldokument jedoch für die Öffentlichkeit nicht sichtbar sein soll, muss eine alternative Primary Resource für den Bezug durch Endbenutzer deklariert werden. Die vorrangig auftre-tende Primary Resource im hier vorliegenden Fall wäre die layouterhaltende digitale Repräsentation und somit die PDF-Manifestation. Bei der automatisierten Generierung von Equivalent Alternative Resources durch die im Archivierungssystem integrierten Filter können aufbauend auf den Struktur-Metadaten und den Accessibility-Metadaten der tatsächlichen Primary Resource für jede alternative Manifestation in Analogie Struktur-Metadaten und Accessibility-Metadaten angelegt werden. Bei der Generierung der alternativen Ressourcen müs-sen durch die Filter den in den Ressourcen enthaltenen Elementen wiederum Identi-fikatoren (id-Attribute, name-Attribute) zugeordnet werden und/oder Anker integriert werden, um die Struktur-Metadaten zu diesen in Beziehung zu setzen. Da die äqui-valente Version durch den Generierungsprozess im Archivierungssystem ihren Ur-sprung nachvollziehen kann, ist es möglich, durch Accessibility-Metadaten die Beziehung von Primary Resource und Equivalent Alternative Resource für jede Struktureinheit auszuweisen. Nachfolgend muss eine Kontrolle der generierten Ressourcen und der Metadatenan-reicherung in einem abgestimmten Workflow durch Personal des Archivierungssys-tems, Accessibility-Experten, Spezialisten für enthaltenen Content in ausgewählten Präsentationsformen (z. B. Mathematik für Blinde), dem Publizierenden und gegebe-nenfalls dem Autor der Primary Resource ausgelöst werden. In diesem Workflow müssen den Beteiligten definierte Aufgaben zugewiesen sein, um die Sicherung der festgelegten Richtlinien durch die Administration des Archivierungssystems für eine akkurate Katalogisierung, Langzeitarchivierung und Zugänglichkeit der Ressourcen zu wahren. In diesem Workflow müssen außerdem durch das Personal des Archivie-rungssystems bzw. durch das System selbst die administrativen und technischen Metadaten sowie Metadaten zur Langzeitarchivierung nachträglich zu den Item-Entitäten angereichert werden. Mit Abschluss des Workflows zur Einpflege ist eine Transformation des angereicher-ten SIP in ein AIP und die Übergabe an das Archival Storage sowie die Übernahme der Metadaten in das Data Management System durch das Personal des Archivie-rungssystems auszulösen. Der Service zur Transformation von Equivalent Alternative Resource ist als ein be-sonderes Qualitätsmerkmal eines Archivierungssystems anzusehen. Für kommerziell orientierte publizierende Organisationen kann dies einen erhöhten Absatz nach sich ziehen, was eine Aufwandsentschädigung für den Archivbetreiber gerechtfertigt. Es soll darauf hingewiesen werden, dass das vorgestellte Konzept ebenfalls auf Ar-chivierungssysteme angewandt werden kann, die die Rolle eines Zulieferers (Data Provider) für das Archivierungssystem des DKV einnehmen. Hierzu würden zum Bei-spiel Universitätsbibliotheken gehören, die folglich ein SIP mit fast konformen Meta-daten an den DKV weiterleiten können. Abweichungen der Metadaten zu den



Vorschriften des DKV bzw. erweiterte Ressourcengenerierungen müssten entspre-chend der geführten Diskussion durch den Abliefernden und das DKV-Mitglied kolla-borativ bearbeitet werden.

6.3 Zugänglichkeitsgewährung zu Ressourcen Bezüglich der Zugänglichkeitsgewährung sind die Suche nach Ressourcen und de-ren Auffindung sowie der Datenabruf der archivierten Ressourcen und deren Kon-sum durch einen Endbenutzer zu betrachten. Die Ressourcensuche ist durch Benutzer primär auf Basis von bibliografischen Me-tadaten zu einem Werk vorzunehmen, da der Umfang von Publikationen im globalen Katalog ein alle Erwartungen übersteigendes Ausmaß annehmen wird. Für jede Suchanfrage muss die Access-Entität gemäß dem OAIS Reference Model eine An-frage beim Data Management des Archivierungssystems stellen. Als Resultat der Suchanfrage wird dem Benutzer eine geordnete Trefferliste mit Werken in der Benut-zeroberfläche präsentiert. Werke, die die größte Übereinstimmung zu den Suchkrite-rien aufweisen, müssen an oberster Stelle angezeigt werden. Falls Werke den gleichen Grad der Übereinstimmung besitzen, sollen die Werke zusätzlich nach der Häufigkeit der Aufrufe aller Benutzer in der Trefferliste platziert werden. Die konzi-pierte hierarchische Exploration und Präsentation von Entitäten innerhalb eines Wer-kes zur Suchanfrage wird im Kapitel 8 detailliert vorgestellt. Wenn ein Nutzer nicht nur auf Basis von bibliografischen Daten sucht, sondern be-stimmte Zugangsmodalitäten oder einen bestimmten Manifestationstyp für seinen Konsum voraussetzt, kann es passieren, dass Werke, die der Charakteristik der ge-stellten bibliografischen Suchanfrage entsprechen, nicht in die Trefferliste aufge-nommen werden, da diese Werke den ergänzenden Suchkriterien nicht gerecht werden. Es empfiehlt sich, diese dynamisch auf Nutzeranfrage nachträglich in der Trefferliste anzeigen zu lassen. Da der Suchende in seiner Suchanfrage bestimmte Manifestationen ausschließt, dürfen diese Entitäten bei der Exploration einer Werk-präsentation nicht eingeblendet werden. Es muss dem Benutzer jedoch eine Option geboten werden, über die er ausgeblendete Manifestationen anzeigen lassen kann. Die hierarchische Exploration der Entitäten zu einem Werk soll unabhängig von der Art der Suchanfrage beibehalten werden, da in vielen Fällen zu einem Werk mehr als eine Manifestation den Suchkriterien gerecht werden und eine Vielzahl von Exempla-ren zu diesen existieren können. Eine Unterstützung für Endbenutzer der digitalen Bibliothek entsteht durch die Integ-ration von Benutzerprofilen. Ein Benutzerprofil kann Auskunft über die Bedürfnisse eines Benutzers geben, die bei jeder Suchanfrage und beim Ressourcenbezug ent-sprechend einfließen müssen. Der Benutzer ist somit einerseits in der Lage, eine Mi-nimierung der anzuzeigenden Entitäten in der Suchergebnispräsentation zu erzwingen und andererseits digital publizierte Exemplare beim Konsum an seine Nutzerbedürfnisse automatisiert anpassen zu lassen. Benutzerprofile sollten in jeder digitalen Bibliotheksumgebung erstellt werden kön-nen. Im Archivierungssystem des DKV trüge die Einbeziehung von Nutzerprofilen aufgrund des Ressourcenumfangs im globalen Katalog insbesondere zur Erhöhung der Gebrauchstauglichkeit bei. Ein Benutzerprofil kann bei Einverständnis des Be-nutzers bei der Erstanmeldung anhand eines Fragenkataloges erhoben werden. Das Einverständnis des Benutzers ist insbesondere wichtig, um dessen Persönlichkeits-rechte zu wahren. Selbstverständlich muss es einem Benutzer gestattet sein, jeder-



zeit Änderungen an seinem Profil vornehmen zu können. Außerdem bietet es sich an, Benutzer mehrere Profile zu ihrer Person anlegen zu lassen. Unterschiedliche Profile ermöglichen es, sich auf unkomplizierte Weise unterschiedlichen Umge-bungsgegebenheiten anzupassen. Ein Anwendungsbeispiel für unterschiedliche Be-nutzerprofile zu einer Person könnte ein Profil für den Desktop-Arbeitsplatz und ein weiteres für das Mobiltelefon sein. Im Allgemeinen müssen in einem Benutzerprofil Angaben zu den temporären Umge-bungsbedingungen (z. B. Beleuchtung, Geräuschpegel, verwendete Hard- und Soft-ware) und den Fähigkeiten des Benutzers gesammelt werden. Aufbauend auf diesen Informationen können Rückschlüsse für die Verwendung des Benutzerinterfaces der digitalen Bibliothek und für den Konsum der Ressourcen gezogen werden. Bezüglich der Zugänglichkeit (Accessibility) unterscheidet das Accessibility for LIP Information Model [ACCLIP03] als exemplarische Spezifikation für die Erstellung von Benutzerprofilen nach der Adaptierbarkeit und Inhaltszugreifbarkeit. Die Adaptierbar-keit deckt die Präferenzen für die Darstellung der Inhalte (display) und die bevorzug-ten Interaktionstechniken auf den Inhalten (control) ab. Die Zugreifbarkeit bezieht sich insbesondere auf die Zugriffsmodalitäten der Inhalte (content information). Des Weiteren werden in der Profilspezifikation die von einem Benutzer beherrschten Sprachen gehalten, um Ressourcen mit nicht zugänglichem Inhalt aufgrund der Sprachbarriere zu umgehen. Entsprechend können bei der Suche Ressourcen anhand ihrer Metadaten in der Suchergebnispräsentation aufgeführt werden, die diesen Ansprüchen gerecht wer-den. Für den adäquaten Konsum eines Werkes kann es notwendig sein, Bestandteile verschiedener Manifestationen nutzen zu müssen. Daher muss der Endbenutzer in-formiert werden, welche der Manifestationen einen optimalen Einstiegspunkt für sei-nen Konsum bildet. Falls in der Manifestation Struktureinheiten existieren, die nicht den im Nutzerprofil spezifizierten Bedürfnissen entsprechen, müssen diese durch Adaption an die Gegebenheiten des Benutzers angepasst werden oder durch das System durch Struktureinheiten in Equivalent Alternative Resources ersetzt werden. Auf Basis des Benutzerprofils kann ebenfalls über die Anspruchsberechtigung eines Konsumenten für den Zugriff auf eine Ressource entschieden werden, da diverse Ressourcen für ausgewählte Nutzergruppen (z. B. blinde Menschen) mit erweiterten Zugriffsrechten versehen sind. Organisatorisch betrachtet, sind diese Nutzergruppen für den Nachweis der Zugehörigkeit zu diesen Gruppen gegenüber dem Bibliotheks-betreiber verpflichtet, um rechtliche Aspekte zu wahren. Für die tatsächliche Verwendung von Benutzerprofilen in einer digitalen Bibliothek empfiehlt es sich, eine Spezifikation zu entwickeln, die an die Gegebenheiten in Bib-liotheksumgebungen angepasst ist. Es sei darauf hingewiesen, dass ein erfolgrei-ches Integrieren von Benutzerprofilen nur an die Verwendung konsistenter Metadatenanreicherungen in festgelegten Standards und unter Verwendung festen Vokabulars für die archivierten Ressourcen angeschlossen werden kann. Die vorselektierten digitalen Ressourcen werden in der Praxis zumeist in verschiede-nen Formaten vorliegen. Für den Konsum dieser Ressourcen sind Viewer und Player notwendig, die die akkurate Repräsentation archivierter Ressourcen erlauben. Um Endbenutzern die Suche nach den entsprechenden Viewern und Playern für den Ressourcenkonsum zu ersparen, ist die Integration von webbasierten Repräsentati-onstechnologien durch den Bibliotheksbetreiber anzuraten. Ein dadurch zusätzlich positiv beiwirkender Aspekt ist die Kontrolle des Ressourcendownloads und somit einer erhöhten Copyright-Einhaltung. Eine Reihe kommerziell orientierter Archivie-



rungssystembetreiber (z. B. ACM beim Vertrieb der Online Books) setzt bereits auf webbasierte Repräsentationstechnologien. Allerdings muss sichergestellt sein, dass die Zugänglichkeit für alle potentiellen Benutzer über das angebotene Interface ge-wahrt bleibt. Für die Wiedergabe von multimedialen Ressourcen kann Audio- und Videostreaming Einsatz finden. [EBE08] zeigte dies, unter der Verwendung eines barrierefreien Interfaces zum Abspielen von DTBs. Für den hier vorgestellten Kontext muss ein webbasierter Viewer jedoch nicht nur einen Manifestationstyp wiedergeben können, sondern alle archivierten Ressourcen-standards und -formate unterstützen. Vielmehr muss der Viewer in der Lage sein, zwischen alternativen Inhalten (Struktureinheiten einzelner Ressourcen) wechseln zu können, um die Zugänglichkeit für den Benutzer zu garantieren. Folglich muss der Viewer den gesamten Umfang der Struktur-Metadaten und Accessibility-Metadaten interpretieren und diese zu den Angaben des Benutzerprofils abgleichen können. Bei der Wiedergabe von multimedialen Inhalten ist der Viewer außerdem für das Zeitma-nagement verantwortlich. Das bedeutet, falls eine Equivalent Alternative Resource eine längere Laufzeit als die Primary Resource hat, muss gewartet werden, dass beide Ressourcen vollständig wiedergegeben wurden, bevor zur nächsten Einheit übergegangen werden kann. Dieser Fall kann beispielsweise bei Synchronisation von Gebärdensprache zu Audio oder Video auftreten. Im Falle einer nutzerprofilunabhängigen Repräsentation können keine Equivalent Alternative Resources automatisch präsentiert werden. Der Benutzer muss folglich eine Anfrage stellen um Struktureinheiten alternativ präsentieren zu lassen. Eine sol-che Anfrage kann in einem webbasierten Viewer beispielsweise durch das Fokusie-ren einer Einheit geschehen, woraufhin Alternativen angezeigt werden und zur Auswahl bereit stehen. Unter der Verwendung von Benutzerprofilen kann der Benutzer darauf hingewiesen werden, falls eine der Struktureinheiten nicht seinen Bedürfnissen entspricht. Diese Information muss selbstverständlich in einer ihm zugänglichen Form gegeben wer-den. Anschließend kann semi-automatisch auf die für ihn am besten geeignete Res-source weitergeleitet werden. Ein komplett automatisches Weiterleiten (ohne Initiierung des Benutzers) sollte vermieden werden, da dies zum Lost-in-Hyperspace-Problem führen kann. Falls primäre oder alternative Ressourcen (ganze Manifestationen oder einzelne Struktureinheiten) nicht in einer digitalen Repräsentation vorliegen, muss dem End-benutzer zu diesen eine Bezugsinformation gegeben werden. Falls beispielsweise eine taktile Grafik als Alternative zu einer Struktureinheit in einer Manifestation exis-tiert, wäre es sinnvoll, die Bezugsinformation im Viewer anzugeben. Prinzipiell entsprechen die durch den Viewer genutzten Ressourcen und die zugehö-rigen Metadaten dem Dissemination Information Package (DIP). In wie weit ein DIP durch die Access-Entität zur Wiedergabe in einem webbasierten Viewer tatsächlich aus einem AIP geformt werden muss, wäre im praktischen Einsatz zu klären. Aller-dings liegt die Vermutung nahe, dass ein DIP identisch zum AIP ist. Für den Downlo-ad einzelner Manifestationen oder einem Mix aus diesen muss unbedingt ein DIP gebildet werden, welches gegenüber dem AIP minimiert wurde. Der webbasierte Viewer kann ebenfalls Einsatz für die nachfolgenden Konzepte der kollaborativen Accessibility finden. Durch einen webbasierten Viewer ist die Anrei-cherung von Accessibility-Metadaten zu Struktureinheiten benutzerfreundlich und intuitiv vorzunehmen.



6.4 Kollaborative Accessibility Barrierefreiheit kann kaum für alle vorstellbaren Zielgruppen in einer Publikation durch den Produzenten integriert werden. Auch ist eine nachträglich durchgeführte Überarbeitung ausschließlich durch Archivbetreiber aufgrund des damit verbundenen Aufwandes illusorisch. Folglich müssen Lösungen gefunden werden, die es nicht am Publikationsprozess beteiligten Organisationen bzw. Personen erlauben, Anreiche-rungen zur Erhöhung der Barrierefreiheit von Werken vorzunehmen. Im Kapitel 6.1 wurde bereits erläutert, dass externe Accessibility-Experten kollabora-tiv zur Optimierung der Metadatenanreicherung beitragen können. Der Einsatz von Accessibility-Experten ist jedoch immer mit einem Kostenaufwand verbunden, der insbesondere für Publizierende, die keinen zusätzlichen Gewinn durch die Anreiche-rung erwarten können, oft nicht akzeptabel ist. Entwicklungen des World Wide Web zeigen, dass Endbenutzer gegenwärtig immer häufiger in die Rolle von Mitwirkenden rücken. Prozentual gesehen ist das zwar zu-meist ein geringer Teil der Benutzer, jedoch in Summe aller tatsächlich Mitwirkenden ein sehr großer Benutzerkreis. Am Beispiel von Wikipedia lässt sich am eindrucksvollsten verdeutlichen, wie Web 2.0 Communities kollaborativ eigene Informationen qualitativ hochwertig verbreiten. Weniger als fünf Prozent der Endbenutzer wirken bei der Erstellung neuer Artikel bzw. bei der Kontrolle und Überarbeitung bereits veröffentlichter Artikel mit. Trotzdem sind in der englischsprachigen Version bereits 2,7 Millionen Artikel eingepflegt wor-den und in der deutschsprachigen fast 0,9 Millionen. Der Ansatz zur kollaborativen Accessibility setzt ebenfalls auf dem Engagement und dem Wissen von Endbenutzern auf. Der Begriff „Kollaborative Accessibility“ oder auch „Social Accessibility“ zielt auf die Mitwirkung einer offenen Community zur Er-höhung der Barrierefreiheit von existierenden Inhalten im Internet ab [TAK08]. Für die Überführung dieser Konzepte auf digitale Bibliotheken ist es insbesondere wichtig, dem Endbenutzer eine Benutzerschnittstelle anzubieten, in der er alternative Inhalte zu Ressourcen hinzufügen kann, ohne ein tiefgründiges Wissen über Metada-ten besitzen zu müssen [HAF08b]. Als Benutzerschnittstelle für kollaborative Accessibility kann der webbasierte Viewer nachgenutzt werden. Da es bereits möglich ist, Struktureinheiten einer Manifestation auswählen und zu Struktureinheiten anderer Manifestationen wechseln zu können, ist das Hinzufügen neuer Inhalte zu diesen Struktureinheiten technisch relativ einfach zu ermöglichen. Somit kann unter Zuhilfenahme eines im Webinterface integrierten Editors alternativer Inhalt zu einer speziellen Struktureinheit und gegebenenfalls zu deren Equivalent Alternative Resources angereichert werden. Diese alternativen In-halte würden im AIP gemäß der vorgestellten Serialisierung als externe Equivalent Alternative Resources auf Metadatenebene behandelt werden. Die inhaltlichen Anreicherungen müssen für die Kompatibilität durch den Editor kon-form zu bewährten Formatstandards angelegt werden. Das trivialste Beispiel für die inhaltliche Anreicherung im Rahmen der kollaborativen Accessibility ist die Angabe einer alternativen Bildbeschreibung in Textform für eine Pixeldarstellung. Falls diese Grafik eine mathematische Formel enthalten würde, könnte der alternative Inhalt auch die mathematische Formel in einer MathML-Repräsentation enthalten. Beide Anreicherungen würden zu einer erhöhten Zugänglichkeit für blinde Nutzer beitragen.



Außerdem können die alternativen Inhalte bei der durch Suchmaschinen durchge-führten Volltextsuche einbezogen werden. Der Vorteil des Metadateneinsatzes und insbesondere von externen Equivalent Al-ternative Resources im Metadatensatz liegt darin, dass die Copyright-Bestimmungen der zugrunde liegenden Manifestation nicht verletzt werden. Ein Zugriff auf die Datei-en der Manifestation, wie bei herkömmlichen Ansätzen zur Accessibility-Erhöhung, in denen die Informationen direkt in ein Exemplar integriert werden, kann vermieden werden. Eine zusätzliche Funktion kann darin bestehen, dass Benutzer Struktureinheiten markieren und einen Kommentar zu benötigten Zugangsbedingungen hinterlegen können. Beim Konsum aufgetretene Zugangsprobleme können so der Öffentlichkeit bekannt gemacht werden. Einerseits entsteht somit ein Bewusstsein (Awareness) für die besonderen Bedürfnisse von Benutzern und anderseits können freiwillige Mitwir-kende gezielt diese Stellen überarbeiten. Außerdem wird es Autoren und Verlegern sichtbar gemacht, wo ihre Fehlerquellen bei der Ressourcenproduktion liegen. Dies kann insbesondere zur Sensibilisierung und zukünftigen Fehlervermeidung führen. Die Voraussetzung für die vorgestellten Anreicherungen ist allerdings immer eine feingranulare Strukturierung der eingepflegten Manifestationen. Ein weiterführender Ansatz kann Benutzern nicht nur erlauben, Inhalte zu einzelnen Struktureinheiten hinzuzufügen, sondern eigene Struktur-Metadaten anzulegen, d. h. die feingranulare logische Strukturierung einer Manifestation vorzunehmen, um gezielt Accessibility-Metadaten und Equivalent Alternative Resources zu diesen in Beziehung zu setzen. Eine Realisierung im Rahmen der kollaborativen Accessibility müsste auf eine ähnli-che Softwareunterstützung wie für professionelle Metadatenanreichernde zurückgrei-fen. Qualitätssicherung ist ein zentrales Anliegen in einem Archivierungsprozess. Der An-satz der kollaborativen Accessibility soll dazu beitragen, die Qualität insgesamt zu erhöhen, jedoch muss dies auch gesichert sein. Für die Erstellung von Equivalent Alternative Resources muss es auch für die Mitwir-kenden der kollaborativen Accessibility Autorenrichtlinien geben, um eine hohe Res-sourcenqualität zu garantieren. Des Weiteren muss der Editor diverse Validierungsmöglichkeiten anbieten, um Fehler vor dem Einpflegen zu vermeiden. Außerdem müssen vorgenommene Änderungen immer durch weitere Benutzer überprüft werden, um deren erwartete Qualität zu bestätigen. Es empfiehlt sich au-ßerdem, dass ein Autor oder Publizierender die Geschehnisse zu seinem Werk re-gelmäßig kontrolliert, um Änderungen zu bestätigen bzw. selbst Eingriffe vorzunehmen. Letztendlich ist für die Erlangung einer hohen Qualität jedoch auf das Können der Community zu vertrauen. Eine zusätzliche Hilfe für potentielle Anreicherungen zu einem Werk, kann ein zu diesem Werk bzw. zu einer Manifestation zugeordnetes Forum bilden. Wikipedia zeigt, dass Diskussionen, die neben dem eigentlichen Artikel geführt werden, zur Qualitätssteigerung dieses Artikels beitragen. In einer digitalen Bibliothek kann die-ses Forum nicht nur Themen zur inhaltlichen Anreicherung umfassen, sondern auch zur Inhaltsdiskussion. Eine Inhaltsdiskussion kann insbesondere dazu dienen, eine Publikation einer breiteren Zielgruppe zu öffnen.


Metadatenanreicherung im digitalen Publikationsprozess Komponente zur Einpflege von DTBs

7 Komponente zur Einpflege von DTBs Eine Teilaufgabe dieser Arbeit war die Realisierung einer Konzeption und prototypi-schen Implementierung einer webbasierten Anwendung für die Einpflege von Digital Talking Books (DTB). Der in diesem Zusammenhang konzipierte Prototyp lehnt sich an den Ist-Stand des Austausches von DTBs im DAISY-Format und entsprechenden Metadaten zwischen Produzenten der DTBs (beispielsweise der DZB Leipzig) und Medibus an. Der aktuelle Austausch von DTBs wird über den Versand von Festplatten realisiert, und entsprechende Metadaten werden zu definierten Zeitpunkten über E-Mail-Verkehr zwischen Organisationen ausgetauscht. Der nachfolgende Abschnitt wird eine Reihe von nicht-funktionalen und funktionalen Anforderungen spezifizieren, die den Ist-Stand zeitnah optimieren können, ohne die im letzten Kapitel vorgestellten innovativen Konzepte einzubinden.

7.1 Anforderungen

7.1.1 Nicht-funktionale Anforderungen Da Medibus beabsichtigt, die zentrale Rolle für die Katalogisierung von sehgeschä-digtengerechten Materialien im deutschsprachigen Raum einzunehmen, gilt es, eine Infrastruktur zu erschaffen, die es Produzenten, Bibliothekaren und Endnutzern er-möglicht, ihren Wünschen und Aufgaben nachzugehen. Insbesondere sind kollabo-rierende Tätigkeiten zwischen Bibliothekaren und Produzenten zu sichern. Aufgrund der Tatsache, dass Endbenutzer und höchst wahrscheinlich auch ein Teil des Personals unter einer Sehschädigung leiden, ist neben Aspekten der Gebrauchstauglichkeit (Usability) insbesondere auch auf eine barrierefreie Benutzer-schnittstelle der zu entwickelnden Anwendung zu achten. Ein weiterer Aspekt ist die kostengünstige und effiziente Realisierung des Produktes sowie dessen Betrieb. Das Produkt muss an die aktuellen Arbeitsschritte der produ-zierenden und bibliothekarischen Partner angelehnt sein. Das bedeutet, dass Mitar-beiter ihren herkömmlichen Tätigkeiten nachgehen können, wobei sie durch die Software in ihrer Effektivität unterstützt werden. Ein weiterer Punkt ist die Schaffung von Interoperabilität zwischen partizipierenden Organisationen. Der Informationsaustausch muss in maschinenlesbarer Sprache ge-schehen, um eine automatische Weiterverarbeitung auslösen zu können. Für den Autor dieser Arbeit ist dabei insbesondere die Meldung von Publikationen an die Me-dibus und die DNB im Fokus. Bezüglich der Gewährung von Rechten ist sicherzustellen, dass das Copyright der DTBs eingehalten wird und durch Sicherheitsmechanismen nur autorisierten Anwen-dern ein Zugriff in bestimmten Bereichen der Applikation und zu den archivierten DTBs gestattet ist.

7.1.2 Funktionale Anforderungen Die funktionalen Anforderungen sollen prozessorientiert diskutiert werden. Zu Beginn einer Veröffentlichung eines DTB im DAISY-Format muss jeder Produzent dieses bei Medibus beantragen. Hierfür ist es wichtig, Medibus über die zugrunde



liegende Manifestation zu informieren. Diese Beantragung sollte webbasiert über ein Formular geschehen. Medibus ist daraufhin verpflichtet, die Beantragung zu prüfen. Bei Genehmigung der Produktion soll Medibus den Produzenten einen akkuraten bibliografischen Metada-tensatz zur Verfügung stellen. Die Produktionsbestätigung und der Metadatensatz müssen einer Sicht für den jeweiligen Produzenten zu entnehmen sein. Medibus soll-te den entsprechenden Metadatensatz „falls vorhanden“ in der DNB einkaufen bzw. ihn selbst normkonform (RAK-WB bzw. RDA) ansetzen. Anschließend muss Medibus diesen Metadatensatz konform zum ANSI/NISO Z39.86-2005 Standard aufbereiten und dem Produzenten bereitstellen. Diese Aufgaben sind jedoch bis auf den Upload des Metadatensatzes unabhängig und somit nicht Teil der Applikation. Ebenfalls ist der eigentliche Produktionsprozess unabhängig von den hier angestell-ten Überlegungen. Jeder Produzent nutzt individuelle Technologien, um ein DTB den Medibus-Anforderungen entsprechend aufzubereiten. Teil der Aufbereitung soll die Integration des durch Medibus bereitgestellten Metadatensatzes im DTB sein. Der Produzent wäre nach Abschluss der DTB-Produktion dazu verpflichtet, sein DAISY-Buch in der Webapplikation hochzuladen. Nachfolgend muss sich eine Prüfphase durch Medibus anschließen. In dieser muss das Buch auf Einhaltung der Produktionsrichtlinien untersucht werden. Zum größten Teil würde diese Untersuchung manuell stattfinden. Die Applikation könnte lediglich teilweise durch Validierungskomponenten automatisiert beitragen und dem Prüfer ein Feedback beispielsweise zu Syntaxverletzungen geben. Wird das DAISY-Buch durch Medibus als einwandfrei eingestuft, müssen die im DTB enthaltenen Metadaten extrahiert und einerseits im lokalen Datenbanksystem einge-pflegt und zudem eine Transformation in MARC 21 ausgelöst werden, um die Meta-daten für die DNB über eine OAI-Schnittstelle zum Harvesting bereitzustellen. Das DTB selbst muss nach der Freischaltung auf dem Archivierungsserver auch für berechtigte Endnutzer zugänglich gemacht werden. Wünschenswert ist daher eine Erweiterung des aktuell verwendeten webbasierten Katalogsystems um eine Down-load-Funktion oder einen Streaming-Server-Zugang.

7.2 Umsetzung Da mit den Verantwortlichen von Medibus nur bedingt ein Kontakt und ein entspre-chender Wunsch nach der Integration der zu entwickelnden Applikation zustande gekommen ist und sich der Fokus dieser Arbeit während der Entstehung auf die Pro-zessmodellierung ausrichtete, setzt die entstandene prototypische Implementierung nur einen Teil der spezifizierten Anforderungen um. Auch sollen aus Umfangsgrün-den in diesem Abschnitt zugrunde liegende Technologien und Konzepte nur beiläufig erwähnt werden. Für weiterführende Informationen ist der Leser aufgefordert, exter-ne Quellen zu Rate zu ziehen bzw. sich mit dem Quellcode der Applikation vertraut zu machen. Für die Entwicklung der Webapplikation wurde ein Framework der Java Platform En-terprise Edition (J2EE) eingesetzt. Das Framework JavaServer Faces (JSF) basiert auf Servlets und JSP-Technologien. JSF erlaubt es, Komponenten für Benutzer-schnittstellen in Webseiten komfortabel einzubinden und die Navigation der Sichten zu definieren. In JSF-Anwendungen wird zur Strukturierung zwischen Modell, Aus-gabe und Steuerung unterschieden, was dem Prinzip des Model-View-Controller-



Modells (MVC) entspricht. Ein Vorteil von JSF ist die Java-API zur Kontrolle der Be-dienelemente. Dies schließt auch die Behandlung von Ereignissen, die Validierung der Eingabe und Navigation sowie die Unterstützung für Internationalisierung ein. In Anlehnung an die aufgestellten Anforderungen wurde eine Applikation realisiert, die als Ausgangspunkt einen Upload der opf-Datei eines produzierten DTBs erlaubt. Die hochgeladene Datei wird durch die Applikation geparsed und der enthaltene In-halt dem Benutzer angezeigt. Im Folgeschritt stehen dem Benutzer drei Sichten zu Verfügung, in denen die Meta-daten der hochgeladenen Datei komfortabel überarbeitet werden können. In der ers-ten Sicht werden allgemeine bibliografische Angaben zur Ressource präsentiert. Hierzu gehören die Angabe des Titels, die Angabe von Mitwirkenden, Informationen über das DAISY-Buch (Verleger, Erscheinungszeitpunkt, Format, Sprache, ISBN) sowie Angaben zur Sacherschließung und zum Copyright. In der zweiten Sicht kön-nen zusätzliche Informationen zum DTB hinterlegt werden. Diese umfassen die Sprecher, Produzenten und technische Details wie Art des DTB, Spielzeit, verwende-te Medien, Audioformat und Audiokompression sowie Angaben zum Revisionsver-lauf. Die dritte Sicht erlaubt es, Angaben über das zugrunde liegende Ursprungswerk zu spezifizieren. Falls dieses Werk in Form einer Manifestation bzw. als Exemplar vorliegt, können unter anderem Verlag, ISBN und Format angegeben werden. Aus jeder der drei Sichten zur Metadatenanreicherung ist es dem Anwender möglich, die resultierende (überarbeitete) opf-Datei auf seinem Lokalsystem zu speichern, die Metadaten in eine Datenbank für die Katalogisierung aufzunehmen und den Metada-tensatz nach MARC 21 zu überführen. Ein durch den Autor dieser Arbeit entwickeltes Mapping von Metadaten des ANSI/NISO Z39.86-2005 Standards auf Metadatenele-mente in MARC 21 ist in Anhang D zu finden. Es sei darauf hingewiesen, dass den Metadatenelementen des DTBs teilweise Attribute hinzugefügt wurden, um die Aus-weisung von Normdaten einzubinden.

opf-Datei speichern

Datensatz in DB schreiben

Metadaten nach MARC 21 trans-

formieren

opf-Datei Upload

Metadaten zum Ursprungswerk

Allgemeine Metadaten

DTB-spezifische Metadaten

Abbildung 7.1: Visualisierung des prozeduralen Ablaufs anhand der umgesetzten Sichten Bezüglich der Erhöhung der Gebrauchstauglichkeit und Übersichtlichkeit werden bei Eingabefeldern, die n-mal wiederholbar sind, nur diejenigen eingeblendet, die bereits ausgefüllt wurden. Zusätzliche Eingabefelder können dynamisch durch den Benutzer eingeblendet werden. Um Screenreader-Nutzern einen optimierten Zugriff zu bieten, wurden ausschließlich standardkonforme Oberflächenelemente verwendet und Attri-bute zur Steigerung der Barrierefreiheit angereichert.


Metadatenanreicherung im digitalen Publikationsprozess Präsentation von Metadaten

8 Präsentation von Metadaten In diesem Kapitel wird ein auf Endnutzerbedürfnisse abgestimmtes Präsentations-konzept für die gebrauchstaugliche Darstellung von Metadaten vorgestellt. Die Prä-sentation weist primär die bezüglich RDA relevanten Angaben aus. In zweiter Ordnung soll es Endbenutzern möglich sein, Informationen über die Barrierefreiheit von Publikationen zu erschließen. Die Präsentation muss insbesondere an die gestellte Suchanfrage des Nutzers an-gepasst werden und die Suchergebnisse in einer überschaubaren Darstellung prä-sentieren. Außerdem muss es Benutzern erlaubt sein, eine weiterführende Recherche auf verschiedenen Informationsebenen explorativ durchzuführen. Was versteht man in diesem Zusammenhang unter verschiedenen Informationsebe-nen? Durch RDA und Metadatenaustauschformate ist die Globalisierung von Katalo-gen der nächste zu erwartende Schritt in digitalen Bibliotheken. Service Provider werden nicht mehr bloß Kataloge von einigen wenigen Archivierungssystemen verei-nigen, sondern haben die Chance, weltweit verfügbare Angebote miteinander zu ver-schmelzen und in einer einzigen Suchergebnispräsentation Benutzern darzustellen. Resultierend gilt es, Ebenen einer Suchergebnispräsentation zu entwickeln, die es gestatten, durch angepasste Detaillierungsgrade auf jeder Ebene den Nutzern für den jeweilig durchgeführten Explorationsschritt Informationen von Interesse anzuzei-gen. Betrachtet man die aktuelle Suchergebnispräsentation deutscher Bibliotheken, fällt auf, dass prinzipiell zwei Informationsebenen für Benutzer präsentiert werden. In der ersten Ebene wird eine Trefferliste ausgegeben, die alle Manifestationen enthält, die durch den Suchalgorithmus mit den Suchbegriffen in Bezug gebracht werden konn-ten. Auf der zweiten Ebene ist es Benutzern möglich, eine begrenzte deskriptive In-formationsangabe zu einer bestimmten Manifestation einzusehen. Gegebenenfalls existiert eine dritte Ebene, in der beispielsweise weiterführende Angaben zum Autor bezogen werden können. Aufgeführte Trefferlisten können bei einem globalisierten Katalog folglich sehr schnell eine unüberschaubare Größe annehmen, was zu einer verminderten Gebrauchs-tauglichkeit bei der Auffindung gesuchter Manifestationen führt. Aktuell ist es Benut-zern möglich, ihre Trefferliste durch die „erweiterte Suche“ zu individualisieren. Jedoch ist damit nicht immer zwangsläufig eine Minimierung der Trefferliste garan-tiert. Wie bereits in dieser Arbeit verdeutlicht, ist die größte Barriere für jeden Leser die Sprache von Manifestationen. Eine Sprache, derer man nicht mächtig ist, unterbindet jeglichen Konsum der in ihr verfassten Publikationen. Resultierend sollte ein Benut-zer die durch ihn präferierten Sprachen an das System übermitteln. Nichtsdestotrotz muss der Benutzer informiert werden, dass Werke in verschiedenen Sprachen zur vorgenommenen Suchanfrage aufgefunden wurden. Eine Aufgliederung nach Sprachen erlaubt es, ein Werk auf zweiter Ebene nach den vorhandenen Sprachen zu ordnen, um dem Werk Manifestationen der jeweiligen Sprache zuweisen zu können. Die Trefferliste der ersten Informationsebene weist somit nur noch Werke entsprechend den Suchkriterien aus (vgl. Kapitel 6.3), was die Anzahl der Ergebnisse erheblich minimiert. Falls zuvor eine Sprachpräferenz festge-legt wurde, müssen die Titel der gelisteten Werke nicht in der Originalsprache, son-dern in der entsprechend vorgegebenen Sprache präsentiert werden. Gleiches gilt



bei der Verwendung von Suchbegriffen aus einem bestimmten Sprachraum. Das System personalisiert somit automatisiert die Trefferliste in der ersten Informations-ebene auf die Benutzersprache. Auf der zweiten Ebene würden alle Titel des Werkes in der jeweiligen Sprache und mit einem Verweis, um welche Sprache es sich han-delt, angezeigt werden. Da es zu jedem Werk in einer bestimmten Sprache nun auch eine Vielzahl von Mani-festationen geben kann, gilt es, diese personalisierbar zu präsentieren. Es soll ein ähnliches Prinzip wie bei den Sprachen vorliegen. Ein Benutzer soll über alle existie-renden Manifestationen informiert werden, ganz gleich, ob er diese konsumieren möchte oder nicht. Daher sollen alle Manifestationen der entsprechenden Sprache eines Werkes, falls in der Suchanfrage nicht anders festgelegt wurde, in einer Tref-ferliste auf dritter Ebene dargestellt werden. Um diese Liste anzupassen und folglich in ihrer Gebrauchstauglichkeit zu erhöhen, wurden drei Mechanismen zur Selektion und Umordnung der Trefferliste auf dritter Ebene eingeführt. Als erstes soll es Benutzern möglich sein, Treffer zu einer bestimmten Expression anzeigen zu lassen. Falls beispielsweise ein Benutzer ausschließlich an rein textuel-len oder rein auditiven Manifestationen Interesse hat, kann er die Suchergebnisse auf diese minimieren. Als zweite Option soll dem Benutzer ermöglicht werden, Manifestationen ein- und auszublenden, die nicht seinem Benutzerprofil entsprechen. Insbesondere für Men-schen mit besonderen Bedürfnissen ist es damit leicht möglich, adäquate Manifesta-tionen aufzufinden. In diesem Nutzungskontext ist es aus Sicht des Autors dieser Arbeit wichtig, den Benutzern auch mitzuteilen, welche Manifestationen verfügbar sind, die jedoch nicht ihre Bedürfnisse abdecken. Falls eine direkte Suche nach Ma-nifestationen beginnt, welche nur die passenden Treffer anzeigt, würden Nutzer mit besonderen Bedürfnissen nicht feststellen können, welche Informationen ihnen ent-gehen, weil sie nicht in einer zugänglichen Form vorliegen. Als dritte Möglichkeit soll ein Benutzer Zusammenhänge bzw. Beziehungen zwischen Manifestationen einer Sprache präsentiert bekommen. Durch eine Umordnung und Strukturierung können Manifestationen, die eine Alternativversion einer anderen Ma-nifestation bilden, als zueinander zugehörig ausgewiesen werden. Um den Benutzern die potentielle Bezugsform der Exemplare einfach und schnell zu vermitteln, wurde neben einem Vermerk der Medienform in der textuellen Titelaus-weisung auch ein Icon zu Beginn des Titels eingebunden. Eine weitere offene Frage war, wie mit sekundären Werken umgegangen werden soll, die zu dem Werk bzw. zu Manifestationen dieses Werkes in Beziehung stehen. Als sekundäre Werke können Publikationen wie Buchrezensionen, Biografien zum Autor, weiterführende Literatur etc. aufgeführt werden. Diese in Beziehung stehen-den Werke können für den Benutzer unter einem separierten Punkt in der dritten In-formationsebene präsentiert werden. Beim Betreten der dritten Informationsebene sollte nur ein Hinweis zur Existenz dieser Werke angezeigt werden. Die Werktitel sind erst auf Anfrage des Benutzers zu präsentieren und gehören somit eigentlich zur vierten Ebene. Die bibliografischen Angaben der entsprechenden Werke können durch die Verfolgung von Verweisen in einer analogen Darstellung wie zum Primär-werk erschlossen werden. Die vierte Informationsebene zum Werk kann durch die Auswahl einer speziellen Manifestation erreicht werden. Auf dieser Ebene werden wie auf der zweiten Informa-tionsebene in derzeitigen Bibliothekssuchsystemen deskriptive Metadaten zur jewei-



ligen Manifestation ausgewiesen. Im Laufe der RDA-Einführung in Bibliotheken ist durch den Service Provider zu klären, welche deskriptiven Metadaten für den Benut-zer tatsächlich von Interesse sind, um diese in einer übersichtlichen Präsentation zu visualisieren und allen Benutzern zugänglich zu machen. Die fünfte Ebene beherbergt zwei verschiedene Metadatenrepräsentationen. Einer-seits sollen in dieser Informationsebene Angaben zu Exemplaren angeboten werden und andererseits soll dem Benutzer erlaubt sein, die Accessibility-Metadaten einer Manifestation einzusehen. Da diese spezifischen Metadaten für einen Benutzer erst von Interesse werden, wenn er sich für den Konsum der Manifestation entschieden hat, sind diese Metadaten auf der fünften und untersten Ebene hinterlegt. Nachfolgend wird anhand eines Mock-up eine potentielle Präsentation gezeigt.

Abbildung 8.1: Mock-up einer Metadatenpräsentation



Das Beispiel aus Abbildung 8.1 zeigt eine exemplarische Suchergebnispräsentation, der die Suchanfrage zu „Dan Brown“ als Autor zugrunde liegt. Die Suchanfrage ist auf Englisch vorgenommen worden, was dazu führt, dass alle Werke, die von Dan Brown verfasst wurden, mit englischen Titeln in der ersten Informationsebene ange-zeigt werden. In der zweiten Informationsebene wird zum Werk „Angels & demons“ dem Benutzer vermittelt, dass Manifestationen in den Sprachen Englisch, Deutsch, Spanisch, Französisch und Türkisch aufgefunden wurden. Zu jeder Sprache wird der Titel des Werkes in der entsprechenden Sprache ausgewiesen. Auf der dritten Infor-mationsebene befinden sich neben der gefundenen Trefferliste zu den Manifestatio-nen der jeweiligen Sprache eine Anzahl von Schaltflächen, um die Personalisierung der Trefferliste vorzunehmen. Die verwendeten Schaltflächen sind:

• show all • textual representation • auditory representation • braille representation • multimedia representation • sign language representation • representations matching my needs (entsprechend einem angelegten Nutzer-

profil) • relationships among manifestations of this work (Zuordnung von Equivalent

Alternative Resources zu Primary Resources) Außerdem ist der Verweis zu in Beziehung stehenden Werken in der dritten Informa-tionsebene aufgeführt, dem im Beispiel in einer untergeordneten Ebene ein sekundä-res Werk zugeordnet ist. In der vierten Informationsebene sind die deskriptiven Metadaten zur ungekürzten Hörbuchversion zu sehen sowie ein Verweis zu existie-renden Exemplaren und den Accessibility-Metadaten, welche der fünften Informati-onsebene entsprechen. Die fünfte Informationsebene wurde für das Mock-up nicht entworfen. Bezüglich der Präsentation von Exemplarinformationen würde es sich empfehlen, eine Subebene einzubinden, auf der ein jeweiliges Exemplar mit einem Archivierungsort in Verbin-dung gebracht wird, um auf einer nächsten Ebene Detailinformationen zum Bezug, zur Verfügbarkeit etc. darzustellen. Die Präsentation von Accessibility-Metadaten sollte eine begrenzte hierarchische Gestaltung genießen, da Endnutzer mit der Mas-se an Metadaten, die durch die Strukturierung in Struktureinheiten anfallen, wohl überlastet wären. Barrierefreiheit ist für Endnutzer eher in Hinsicht auf die gesamte Manifestation von Interesse. Auch ist es zwingend notwendig, ein Vokabular für die Ausweisung der Accessibility-Metadaten einzubinden, das für Endbenutzer gut ver-ständlich ist. Die Präsentation setzt die durch [FRBR98] geforderte hierarchische Exploration um, welche es Nutzern gestattet, Ressourcen intuitiver zu finden, zu identifizieren, aus-zuwählen und zu beziehen. Für eine Implementierung in einem marktreifen Bibliothekssystem sind weiterführen-de Untersuchungen durchzuführen, die die Adaption, der Suchergebnispräsentation für profilgestützte Suche sowie spezialisiertere Sucheanfragen optimieren. Die Um-setzung der Benutzerschnittstelle müsste benutzerzentriert in Entwicklungszyklen stattfinden, die durch begleitende Evaluationen die tatsächliche Gebrauchstauglich-keit beweisen. Aus Umfangsgründen musste in dieser Arbeit darauf verzichtet wer-den.


Metadatenanreicherung im digitalen Publikationsprozess Schlussbetrachtungen

9 Schlussbetrachtungen Digitale Bibliotheken genießen in der heutigen Informationsgesellschaft eine stetig wachsende Bedeutung. Informationen digital zu verbreiten, beeinflusst den Wissens-transfer wie wahrscheinlich keine andere Technologie zuvor. Nun gilt es, diese In-formationen für Menschen nachhaltig zu archivieren, diese auffindbar und über nicht absehbare Zeit für jeden Interessenten zugänglich zu machen. Diese Arbeit beschäftigte sich insbesondere mit Bibliotheken, als die für die Informa-tionsaufbewahrung verantwortlichen Archive. Neben Aspekten der Aufbewahrung stand der Metadaten- und Ressourcenaustausch zwischen digitalen Archivierungs-systemen im Fokus der Untersuchungen. Ausgehend von aktuell eingesetzten und in Zukunft zu verwendenden Katalogisierungsstandards wurden Arten von Metadaten spezifiziert. Hinsichtlich der Annäherung an eine globalisierte Bibliothek für alle und damit verbundenen Aspekten für die Erhöhung der Barrierefreiheit wurden innovative Konzepte zur Verwendung von deskriptiven Metadaten, Struktur-Metadaten und Ac-cessibility-Metadaten entwickelt. Als Schwerpunkt wurden außerdem die in Bibliothe-ken stattfindenden Prozessabläufe analysiert. Hierbei zeigte sich, dass die dezentralen Prozesse zur Beschaffung, Erschließung, Archivierung und Bereitstel-lung von Ressourcen auf dem Weg zum globalen Katalog einer partiellen Zentralisie-rung unterzogen werden müssen. Im Rahmen der erweiterten Metadatenanreicherung wurden Ansätze für deskriptive Metadaten entwickelt, die es gestatten, die durch RDA geforderten primären Enti-tätsbeziehungen für Gruppe 1 Entitäten entsprechend dem FRBR Model auszudrü-cken. Zur Beschreibung der inneren Ordnung von Manifestationen wurde unter Zuhilfenahme von Struktur-Metadaten ein Ansatz weg vom Datei-basiertem Vorge-hen, hin zur logischen Strukturierung von Manifestationen geschaffen. Eine logische Strukturierung erlaubt die Übernahme der Struktur einer Manifestation auf weitere Manifestationen derselben Expression bzw. desselben Werkes und eine individuelle Zuweisung von Dateien bzw. Teilen dieser zu einzelnen Struktureinheiten auf unter-schiedlichen Strukturebenen. Die Ansetzung von Accessibility-Metadaten, die bislang in Bibliotheken außen vor blieb, kann resultierend nicht nur zu einer Manifestation zugeordnet werden, sondern feingranular für Struktureinheiten spezifiziert werden. Die feingranulare Metadatenauszeichnung findet insbesondere bei der Ressourcen-zusammenstellung für den Konsumenten Nachnutzung. Somit ist eine Rezeption entsprechend individueller Nutzerbedürfnisse sichergestellt. In einem erweiterten Prozessmodell wurden technologisch und organisatorisch not-wendige Abstimmungen auf nationaler und internationaler Ebene vorgestellt, um der Etablierung eines globalen Kataloges durch Bibliotheken gerecht werden zu können. Als Grundvoraussetzung für die Qualitätssicherung wurden Empfehlungen für die Ressourcenproduktion und die kollaborative Einpflege in ein Archivierungssystem gegeben. Bezüglich der Zugänglichkeitsgewährung für Endbenutzer wurden Konzep-te zur Präsentation von Suchergebnissen in einem globalisierten Katalog entwickelt und Ansätze zur adaptierbaren webbasierten Ressourcenpräsentationen und nach-träglichen Metadatenanreicherung eingeführt. Resümierend ist festzustellen, dass die entwickelten Konzepte zukunftsweisend für digitale Bibliotheken der nächsten Generation sind. Die während der Einführung von RDA zu erwartenden Metadatenstandards werden mit Sicherheit in Hinblick auf die Serialisierung von den hier vorgestellten Techniken abweichen. Nichtsdestotrotz ist der Ansatz zur logischen Strukturierung von Manifes-


Metadatenanreicherung im digitalen Publikationsprozess Schlussbetrachtungen

tationen innovativ und bislang im Rahmen der Ressourcenerschließung nicht be-rücksichtigt. Durch die Allgemeingültigkeit der Konzepte ist das Strukturierungsver-fahren in Kombination mit der Anreicherung von Accessibility-Metadaten auf zu erwartende Formate übertragbar und somit auch in standardisierten deskriptiven Me-tadatenformaten wiederverwendbar. Während der Inbetriebnahme der RDA-konformen Metadaten und der in dieser Ar-beit vorgestellten Erweiterungen müssen softwaretechnologische Lösungen für die gebrauchstaugliche Metadatenanreicherung entwickelt werden. Diesbezüglich wie auch für die Ressourcenpräsentation empfiehlt es sich, den vorgestellten Konzepten zu folgen und webbasierte Ansätze zu wählen, um den Entwicklungen des Web 2.0 gerecht zu werden. Des Weiteren sieht der Autor dieser Arbeit durch die absehbare Veränderung des Angebotes eine wachsende Nachfrage durch Endbenutzer. Insbesondere multimedi-ale Ressourcen und Metadaten, die deren Benutzbarkeit und Zugänglichkeit auswei-sen, werden neue Nutzungskontexte zulassen. Hierbei sei insbesondere der mobile Informationskonsum betont. Die entstehende Nachfrage wird eine kommerzielle Ressourcenverbreitung durch die Archivierungssysteme nach sich ziehen. Resultie-rend wird das Interesse der Produzenten an den kommerziellen Distributionswegen steigen und dazu führen, dass zukünftig Ressourcen qualitativ hochwertig gemäß den Bedingungen des Archivbetreibers bereitgestellt und akkurat im System durch Metadaten angereichert werden.


Metadatenanreicherung im digitalen Publikationsprozess Literaturverzeichnis

Literaturverzeichnis [AACR08] Homepage of the Anglo-American Cataloguing Rules. Verfügbar unter

http://www.aacr2.org/ (besucht 9. Januar 2009). [ACCLIP03] IMS Learner Information Package Accessibility for LIP Information

Model, Version 1.0 Final Specification. Verfügbar durch das IMS Global Learning Consortium unter http://www.imsglobal.org/accessibility/acclipv1p0/imsacclip_infov1p0.html (besucht 9. Januar 2009), Juni 2002.

[ACCMD04] IMS AccessForAll Meta-data, Version 1.0 Final Specification. Verfügbar durch das IMS Global Learning Consortium unter http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html (besucht 9. Januar 2009), Juli 2004.

[AFA08] DC AccessForAll metadata. DCMI Accessibility Wiki, verfügbar unter http://dublincore.org/accessibilitywiki/ (besucht 9. Januar 2009).

[AFANE08] Accessibility Term Proposal. DCMI Accessibility Wiki, verfügbar unter http://dublincore.org/accessibilitywiki/NewElementProposal (besucht 9. Januar 2009).

[AMNW08] Ausführliche Anleitung für die Ablieferung von monografischen Netzpubli-kationen über das Webformular. Deutsche Nationalbibliothek, verfügbar unter http://www.d-nb.de/netzpub/ablief/np_mono_ausf.pdf (besucht 9. Januar 2009), 8. Oktober 2008.

[AOHS08] Ausführliche Anleitung zur Ablieferung von Online-Hochschulschriften. Deutsche Nationalbibliothek, verfügbar unter http://www.d-nb.de/netzpub/ablief/hss_abgabelang.htm (besucht 9. Januar 2009), 6. Oktober 2008.

[APNW08] Ausführliche Anleitung für die Ablieferung von periodischen Netzpublikati-onen über das Webformular und FTP-Upload. Deutsche Nationalbiblio-thek, verfügbar unter http://www.d-nb.de/netzpub/ablief/np_zs_ausf.pdf (besucht 9. Januar 2009), 19. August 2008.

[BAL06] Ball, A.: Briefing Paper: the OAIS ReferenceModel, Verfügbar unter http://www.ukoln.ac.uk/projects/grand-challenge/papers/oaisBriefing.pdf (besucht 9. Januar 2009), February 2006.

[BOR06] Borghoff, U. M. ; Rödig, P.; Scheffczyk, J.; Schmitz, L.: Long-Term Preser-vation of Digital Documents - Principles and Practices. Springer Verlag, 2006.

[CAP03] Caplan, P.: Metadata Fundamentals for all Librarians. ALA Editions, 2003. [CRO04] Croissant, C.R.: MARC21 und die anglo-amerikanische Katalogisierungs-

praxis. Verfügbar unter http://www.bibliothek-saur.de/2004_1/011-035.pdf (besucht 9. Januar 2009), 2004.

[CWA07] Document Processing for Accessibility. CEN Workshop Agreement, CWA 15778, Februar 2007.

[DAIP08] SMIL 3.0 DAISY Profile, World Wide Web Consortium, verfügbar unter http://www.w3.org/TR/SMIL3/smil-daisy-profile.html (bsucht 9. Januar 2009), 2008.

Copyright TU-Dresden, Alexander Haffner 110

http://www.aacr2.org/

http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html

http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html

http://dublincore.org/accessibilitywiki/

http://dublincore.org/accessibilitywiki/NewElementProposal

http://www.d-nb.de/netzpub/ablief/np_mono_ausf.pdf

http://www.d-nb.de/netzpub/ablief/hss_abgabelang.htm

http://www.d-nb.de/netzpub/ablief/hss_abgabelang.htm

http://www.d-nb.de/netzpub/ablief/np_zs_ausf.pdf

http://www.ukoln.ac.uk/projects/grand-challenge/papers/oaisBriefing.pdf

http://www.w3.org/TR/SMIL3/smil-daisy-profile.html


[DAIN08] DAISY Newsletter. Augustausgabe, verfügbar unter http://www.daisy.org/news/newsletters/planet-2008-08.shtml (besucht 9. Januar 2009), August 2008.

[DAY01] DAISY 2.02 Specification. DAISY Consortium, verfügbar unter http://daisy.org/publications/specifications/daisy_202.html (besucht 9. Ja-nuar 2009), Februar 2001.

[DCAM07] DCMI Abstract Model. DCMI, verfügbar unter http://dublincore.org/documents/2007/06/04/abstract-model/ (besucht 9. Januar 2009), 4. Juni 2007.

[DEDS08] Wendel, H.; Rothe, T.: Der Dokumenten- und Publikationsserver der SLUB Dresden – Dokumentation System DEDS 2008. verfügbar unter http://digital.slub-dresden.de/fileadmin/groups/homepage/Dateien/documentation-hsss.pdf (besucht 9. Januar 2009) ,SLUB Dresden, 2008

[DLF00] DLF draft strategy and business plan - Public version 2.0. Verfügbar unter http://www.diglib.org/about/strategic.htm (besucht 9. Januar 2009), 25. September 2000.

[DNB08] Deutsche Nationalbibliothek. Website verfügbar unter http://www.d-nb.de (besucht 9. Januar 2009).

[DNBDS08] Website des Datenshop. DNB, verfügbar unter https://portal.d-nb.de/metadataShop.htm (besucht 9. Januar 2009).

[DPIP08] Daisy Pipeline GUI. Website verfügbar unter http://sourceforge.net/projects/daisymfcgui (besucht 9. Januar 2009).

[DSPA08] DSpace. Website verfügbar unter http://www.dspace.org/ (besucht 9. Januar 2009).

[DTAG08] Authoring Guidelines for Open XML to DAISY XML Translator, Sonata Software Limited, Microsoft Corporation und DAISY Consortium, verfügbar unter http://internap.dl.sourceforge.net/sourceforge/openxml-daisy/Daisy_Translator_Authoring_Guidelines_26september2008.docx (besucht 9. Januar 2009), 26. September 2008.

[DUB07] Frodl, C.; Fischer, T.; Baker, T.; Rühle, S.: Deutsche Übersetzung des Dub-lin-Core-Metadaten-Elemente-Sets Version 1.1. verfügbar unter http://www.dublincore.org/documents/dces/ (besucht 9. Januar 2009), September 2008.

[DZB08] Deutsche Zentalbücherei für Blinde zu Leipzig. Website, verfügbar unter http://www.dzb.de/ (besucht 9. Januar 2009).

[EBE08] Eberius, W.: Multimodale Erweiterung und Distribution von Digital Talking Books. Diplomarbeit, Institut für Angewandte Informatik, TU Dresden, 2008.

[EPH05] Elektronisches Publizieren an Hochschulen: Inhaltliche Gestaltung der OAI-Schnittstelle - Empfehlungen. Deutsche Initiative für Netzwerkinformation e.V., Arbeitsgruppe „Elektronisches Publizieren“ DINI Schriften 2-de Ver-sion 2.0, September 2005.

[EVE99] Eversberg, B.: Was sind und was sollen Bibliothekarische Datenformate - Überarbeitete und erweiterte Neuausgabe. WWW-Version mit Ergänzun-gen, verfügbar unter http://www.allegro-c.de/formate/formate.htm (besucht 9. Januar 2009), Universitätsbibliothek der TU Braunschweig, 1999.


http://daisy.org/publications/specifications/daisy_202.html

http://www.diglib.org/about/strategic.htm

http://www.d-nb.de/

https://portal.d-nb.de/metadataShop.htm

https://portal.d-nb.de/metadataShop.htm


[EVE04] Eversberg, B.: Zur Zukunft der Katalogisierung – jenseits von RAK und AACR. Österreichischer Bibliothekartag, Linz, verfügbar unter http://www.biblio.tu-bs.de/allegro-test/formate/zk.htm (besucht 9. Januar 2009), 22.September 2004.

[EVE07] Eversberg, B.: Wie katalogisiert man ein Buch? Ein Leitfaden nicht nur für Einsteiger. UB Braunschweig, verfügbar unter http://www.allegro-c.de/regeln/rak-einf.htm (besucht 9. Januar 2009), 2007.

[FRAD07] IFLA Working Group on Functional Requirements and Numbering of Au-thority Records (FRANAR): Functional Requirements for Authority Data - A Conceptual Model. Draft, verfügbar unter http://www.ifla.org/VII/d4/franar-conceptual-model-2ndreview.pdf (besucht 9. Januar 2009), 1. April 2007.

[FRBR98] IFLA Study Group on the Functional Requirements for Bibliographic Re-cords: Functional Requirements for Bibliographic Records. Final Report, verfügbar auf der IFLA Website unter http://www.ifla.org/VII/s13/frbr/frbr.pdf (besucht 9. Januar 2009), München, K.G. Saur, 1998.

[FRO08] Frodl, C.: Was man über Metadaten wissen muss. Vortag zum AKEP-DNB-Workshop-Metadaten, 22. Februar 2008.

[HAF08] Haffner, A.; Weber, G.: Integration of Accessible Documents into Digital Li-braries of Tomorrow, Proc. Accessible Design in a Digital World (22.-24.September 2008, York, UK), University of York, 2008.

[HAF08b] Haffner, A.; Weber, G. (2008) Enabling Accessible Resource Access via Service Providers. Proceedings Adaptive Content Processing Conference 2008 (06.-07. November 2008, Amsterdam, Netherlands), EUAIN.

[HEE00] Heery, R.; Patel, M.: Application profiles: mixing and matching metadata schemas. Verfügbar unter http://www.ariadne.ac.uk/issue25/app-profiles/ (besucht 9. Januar 2009), 24. September 2000.

[HEN06] Henze, G.; Croissant, C.: Katalogisierungskulturen in den USA und Deutschland – ein Vergleich. Forum, GNARP-Konferenz, Frankfurt am Main, verfügbar unter http://www.ub.uni-frankfurt.de/messe/symposium2006/henze_dt.pdf (besucht 9. Januar 2009), 6. Oktober 2006.

[KER01] Kerscher, G.: Theory Behind the DTBook DTD. Verfügbar unter http://www.daisy.org/publications/docs/theory_dtbook/theory_dtbook.html (besucht 9. Januar 2009), September 2001.

[KLU99] Kluge, F.: Etymologisches Wörterbuch der deutschen Sprache, bearb. von E. Seebold, Berlin / New York 1999, 23. Aufl. -- W. Pfeifer: Etymologisches Wörterbuch des Deutschen. 3 Bde. Berlin 1989 (München, DTB 1995). -- H. Birkhan: Etymologie des Deutschen, Bern 1985. [ISBN 3-261-03206-5]. -- E. Seebold: Etymologie. Eine Einführung am Beispiel des Deutschen. München 1981 [ISBN 3-406-08037-5].

[KMM08] Konkordanz MAB2 – MARC 21. Deutsche Nationalbibliothek, verfügbar unter http://www.d-nb.de/standardisierung/formate/konkordanz.htm (be-sucht 9. Januar 2009), 2008.

[KUR06] Kurth, M.: Basic Dublin Core Semantics. DC 2006 Tutorial 1, verfügbar un-ter http://dublincore.org/resources/training/dc-2006/Tutorial1.pdf (besucht 9. Januar 2009), 3. Oktober 2006.


http://www.biblio.tu-bs.de/allegro-test/formate/zk.htm

mailto:[email protected]

http://www.allegro-c.de/regeln/rak-einf.htm

http://www.allegro-c.de/regeln/rak-einf.htm

http://www.ariadne.ac.uk/issue25/app-profiles/

http://www.ub.uni-frankfurt.de/messe/symposium2006/henze_dt.pdf

http://www.ub.uni-frankfurt.de/messe/symposium2006/henze_dt.pdf

http://www.daisy.org/publications/docs/theory_dtbook/theory_dtbook.html

http://www.d-nb.de/standardisierung/formate/konkordanz.htm


[LIB08] LIBERO Homepage. Verfügbar unter http://www.libero.de (besucht 9. Januar 2009).

[LMER05] Langzeitarchivierungsmetadaten für elektronische Ressourcen (LMER). Referenzbeschreibung Version: 1.2, DNB, verfügbar unter http://www.d-nb.de/standards/pdf/lmer12.pdf (besucht 9. Januar 2009), 7. April 2005.

[MARC08] MARC 21 Formats. Library of Congress, verfügbar unter http://www.loc.gov/marc/marcdocz.html (besucht 9. Januar 2009).

[MED08] Mediengemeinschaft für blinde und sehbehinderte Menschen e.V. (Medi-bus). Website unter http://www.medibus.info (besucht 9. Januar 2009).

[MEN05] Menne-Haritz, A.: METS: Überblick und Anleitung. Verfügbar unter http://www.loc.gov/standards/mets/METSOverview.v2_de.html (besucht 9. Januar 2009), Juli 2005.

[METS08] METS Schema, & Documentation. Library of Congress, verfügbar unter http://www.loc.gov/standards/mets/mets-schemadocs.html (besucht 9. Ja-nuar 2009).

[MKFO08] Lieferung von Metadaten für Netzpublikationen an die Deutsche National-bibliothek Metadaten-Kernset im Format ONIX (OAI-Schnittstelle). DNB, verfügbar unter http://www.d-nb.de/netzpub/info/pdf/metadaten_kernset_extern.pdf (besucht 9. Januar 2009), 2008.

[MML03] Mathematical Markup Language (MathML). Version 2.0 (Second Edition) W3C, verfügbar unter http://www.w3.org/TR/MathML2/ (besucht 9. Januar 2009), 21. Oktober 2003.

[MOB08] Leitfaden für Medibus-OK-Bücher (MOB), Medibus-Standard im deutsch-sprachigen Raum. Leitfaden - Version 2, 2008.

[MODS08] Metadata Object Description Schema (MODS). Library of Congress, ver-fügbar unter http://www.loc.gov/standards/mods/ (besucht 9. Januar 2009).

[MXML08] MARC 21 XML Schema (MARCXML). The Library of Congress' Network Development and MARC Standards Office, verfügbar unter http://www.loc.gov/standards/marcxml/ (besucht 9. Januar 2009).

[MÜL01] Müller, U.: OAi-Protokoll: Data Provider, Service Provider. Humboldt-Universität zu Berlin, 26. Januar 2001.

[NEU07] Neuroth, H.; Liegmann, H.; Oßwald, A.; Scheffel, R.; Jehn, M.: nestor Handbuch: Eine kleine Enzyklopädie der digitalen Langzeitarchivierung. 2007.

[NIL07] Nilsson, M.: DCMI Basic Syntaxes Tutorial. DC 2007, verfügbar unter http://www.dc2007.sg/T2-BasicSyntaxes.pdf (besucht 9. Januar 2009), Singapore, 2007.

[OAIPMH02] The Open Archives Initiative Protocol for Metadata Harvesting. Protocol Version 2.0, verfügbar unter http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm (besucht 9. Januar 2009), 14. Juni 2002.

[OAIS02] Reference Model for an Open Archival Information System (OAIS), Blue Book, CCSDS 650.0-B-1, verfügbar unter http://public.ccsds.org/publications/archive/650x0b1.pdf (besucht 9. Januar 2009), January 2002.


http://www.libero.de/

http://www.loc.gov/marc/marcdocz.html

http://www.loc.gov/standards/mets/METSOverview.v2_de.html

http://www.loc.gov/standards/mets/mets-schemadocs.html

http://www.loc.gov/standards/mods/

http://www.loc.gov/standards/marcxml/

http://public.ccsds.org/publications/archive/650x0b1.pdf


[OBP06] ONIX for Books Product Information Message Product Record Format. Re-lease 2.1, EDitEUR Jointly with Book Industry Study Group, New York, and Book Industry Communication, London, 3 Januar 2006.

[ODFAG07] Open Document Format v1.1 Accessibility Guidelines. Version 1.0, Committee Draft, OASIS, verfügbar unter http://docs.oasis-open.org/office/office-accessibility/v1.0/cd01/ODF_Accessibility_Guidelines-v1.0.odt (besucht 9. Januar 2009), 15. Oktober 2007.

[ORE08] Open Archives Initiative Object Reuse and Exchange (OAI-ORE) - Specification. Verfügbar unter http://www.openarchives.org/ore/ (besucht 9. Januar 2009).

[OTD08] OpenDocument To DAISY DTBook (odt2dtbook). Website verfügbar unter http://odt2dtbook.sourceforge.net (besucht 9. Januar 2009).

[OTDIM08] Spiewak, V.: Odt2dtbook Instruction Manual. Verfügbar unter http://odt2dtbook.sourceforge.net/support/Odt2dtbook_Instruction_Manual.pdf (besucht 9. Januar 2009), 18. Oktober 2008.

[OXDT08] Open XML to DAISY XML Translator - Save as DAISY XML Add-in. Web-site verfügbar unter http://sourceforge.net/projects/openxml-daisy/ (be-sucht 9. Januar 2009).

[PET05] Petrie, H.; Weber, G.; Fisher, W.: Personalisation, interaction and navigation in rich multimedia documents for print-disabled users. IBM Systems Jour-nal, 44 (3), 2005, 629-636.

[PI08] Persistent Identifier - EPICUR: Uniform Resource Name (URN) - Strategie der Deutschen Nationalbibliothek. Verfügbar unter http://www.persistent-identifier.de/?link=3352 2008 (besucht 9. Januar 2009).

[PMDO01] Preservation Metadata for Digital Objects: A Review of the State of the Art. A White Paper by the OCLC/RLG Working Group on Preservation Metadata, 31. Januar 2001.

[PRE07] PREMIS Data Dictionary for Preservation Metadata. Version 2.0, PREMIS Editorial Committee, verfügbar unter http://www.loc.gov/standards/premis/v2/premis-2-0.pdf (besucht 9. Januar 2009), März 2008.

[RAK02] Regeln für die alphabetische Katalogisierung in wissenschaftlichen Biblio-theken (RAK-WB). 2., überarbeitete Ausgabe, Deutsche Nationalbiblio-thek, verfügbar unter http://www.d-nb.de/standardisierung/pdf/rak_4_erg.pdf (besucht 9. Januar 2009), 2002.

[RAU07] Rauber, A.: Vorstellung des Referenzmodells für Langzeitarchivierung, Symposium "Digitale Langzeitarchivierung". 18. April 2007.

[RDA08] Resource Description and Access (RDA). JSC's Full Draft of RDA, verfüg-bar unter http://www.rdaonline.org/constituencyreview/ (besucht 9. Januar 2009), November 2008.

[RDF04] Klyne, G.; Carroll, J.: Resource Description Framework (RDF): Concepts and Abstract Syntax, W3C Recommendation, verfügbar unter http://www.w3.org/TR/rdf-concepts/ (besucht 9. Januar 2009), 10. Februar 2004,

[RDFS04] Brickley, D.; Guha, R.V.: RDF Vocabulary Description Language 1.0: RDF Schema, W3C Recommendation, verfügbar unter


http://www.openarchives.org/ore/

http://www.d-nb.de/standardisierung/pdf/rak_4_erg.pdf

http://www.d-nb.de/standardisierung/pdf/rak_4_erg.pdf

http://www.w3.org/TR/rdf-concepts/


http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ (besucht 9. Ja-nuar 2009), 10. Februar 2004,

[REFW08] RefWorks Homepage. Verfügbar unter http://www.refworks.com/ (besucht 9. Januar 2009).

[RIB08] Ribera, M.; Golkhosravi, M.: An automated workflow to publish accessible scientific papers: integrating Daisy Pipeline within DSpace. Proceedings Adaptive Content Processing Conference 2008 (06.-07. November 2008, Amsterdam, Netherlands), EUAIN.

[ROE05] Rößner, S.: Accessibility von Diensten und Beständen der Sächsischen Landesbibliothek – Staats- und Universitätsbibliothek Dresden. Diplomar-beit, Institut für Angewandte Informatik, TU Dresden, 2005.

[RSWK07] Regeln für den Schlagwortkatalog RSWK. 3. überarbeitete und erweiterte Auflage auf dem Stand der 4. Ergänzungslieferung, Februar 2007.

[RVKO08] RVK-Online. Universitätsbibliothek Regensburg, verfügbar unter http://www.bibliothek.uni-regensburg.de/rvko_neu/ (besucht 9. Januar 2009).

[SCH07] Schalitz, B.: Accessibility-Erhöhung von LaTeX-Dokumenten, Diplomarbeit, Institut für Angewandte Informatik, TU Dresden, 2007.

[SLUB08] Homepage der Sächsische Landesbibliothek - Staats- und Universitätsbib-liothek Dresden, verfügbar unter http://www.slub-dresden.de (besucht 9. Januar 2009).

[SMIL08] Synchronized Multimedia Integration Language (SMIL 3.0). W3C, verfügbar unter http://www.w3.org/TR/SMIL3/ (besucht 9. Januar 2009), Dezember 2008.

[SUL07] Sullivan, J.: Study on Copyright Limitations and Exceptions for the Visually Impaired. WIPO, 2007.

[TAK08] Takagi, H.; Itoh, T.; Kawanaka, S.; Kobayashi, M.; Asakawa, C.: Social Ac-cessibility: Achieving Accessibility through Collaborative Metadata Author-ing. Proceedings of Tenth International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS 2008), 193-100.

[UML07] Umlauf, K.: Einführung in die Regeln für den Schlagwortkatalog RSWK. Humboldt-Universität zu Berlin, verfügbar unter http://www.ib.hu-berlin.de/~kumlau/handreichungen/h66/ (besucht 9. Januar 2009), 2007.

[WAR04] Jacobs, I.; Walsh, N.: Architecture of the World Wide Web, Volume One. World Wide Web Consortium, verfügbar unter http://www.w3.org/TR/webarch/ (besucht 9. Januar 2009), 15 Januar 2004.

[XFDU07] XML Formated Data Unit (XFDU), Structure and Construction Rules. Draft recommended standard, CCSDS 661.0-R-1, red book, verfügbar unter http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%206610R1/Attachments/661x0r1.pdf (besucht 9. Januar 2009), Januar 2007.

[XMP05] Extensible Metadata Platform (XMP) Specification - Adding Intelligence to Media. Adobe Systems Incorporated, verfügbar unter http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf (besucht 9. Januar 2009), September 2005

[ZDB08] Zeitschriftendatenbank (ZDB). Website verfügbar unter http://www.zeitschriftendatenbank.de/ (besucht 9. Januar 2009).


http://www.refworks.com/

http://www.bibliothek.uni-regensburg.de/rvko_neu/

http://www.slub-dresden.de/

http://www.w3.org/TR/SMIL3/

http://www.ib.hu-berlin.de/%7Ekumlau/handreichungen/h66/

http://www.ib.hu-berlin.de/%7Ekumlau/handreichungen/h66/

http://www.w3.org/TR/webarch/

Metadatenanreicherung im digitalen Publikationsprozess Abkürzungsverzeichnis

Abkürzungsverzeichnis AACR Anglo-American Cataloguing Rules ACCLIP IMS Learner Information Package Accessibility for LIP ACCMD IMS AccessForAll Meta-data AIP Archival Information Package BVB Bibliotheksverbund Bayern CBS Central Bibliographic System CCSDS Consultative Committee for Space Data Systems CQL Contextual Query Language DAISY Digital Accessible Information System DAM Digital Asset Management DC Dublin Core DCMI Dublin Core Metadata Initiative DC-AfA Dublin Core AccessForAll DC-Lib DC-Library Application Profile DDC Dewey-Dezimalklassifikation DEDS Dresden Enterprise Document Server DINI Deutsche Initiative für Netzwerkinformation e.V. DIP Dissemination Information Package DKV Deutscher Katalogisierungsverbund DNB Deutsche Nationalbibliothek DTB Digital Talking Book DZB Deutsche Zentralbücherei für Blinde zu Leipzig EARL Evaluation and Report Language FRBR Functional Requirements for Bibliographic Records FRAD Functional Requirements for Authority Data FRANAR Functional Requirements and Numbering of Authority Records FTP File Transfer Protocol GBV Gemeinsamer Bibliotheksverbund GDZ Göttinger Digitalisierungszentrum GKD Gemeinsamen Körperschaftsdatei HeBIS Hessisches BibliotheksInformationssystem HSSS Hochschulschriftenserver HTML Hypertext Markup Language IFLA International Federation of Library Associations and Institutions



ILTIS Integriertes Literatur-, Tonträger- und Musikalien-Informationssystem ISBD International Standard Bibliographic Description ISBN International Standard Book Number J2EE Java Platform Enterprise Edition JSF JavaServer Faces JSP JavaServer Pages KOBV Kooperativer Bibliotheksverbund Berlin-Brandenburg LBS Local Bibliographic System LCC Library of Congress Classification LCSH Library of Congress Subject Headings LMER Langzeitarchivierungsmetadaten für elektronische Ressourcen MAB Maschinelles Austauschformat für Bibliotheken MARC Machine-Readable Cataloging Medibus Mediengemeinschaft für blinde und sehbehinderte Menschen e.V. METS Metadata Encoding and Transmission Standard MODS Metadata Object Description Schema MVC Model-View-Controller-Modell NCX Navigation Control File für XML Applikationen NISO National Information Standards Organization OAI Open Archives Initiative OAI-ORE OAI Object Re-Use OAI-PMH OAI Protocol for Metadata Harvesting OAIS Open Archival Information System OCLC Online Computer Library Center ONIX Online Information eXchange OPAC Online Public Access Catalogue OPUS Online Publikationsverbund der Universität Stuttgart PDF Portable Document Format PDI Preservation Description Information PICA Project of Integrated Catalogue Automation PND Personennamendatei PREMIS Preservation Metadata Implementation Strategies PS PostScript PSI PICA Search & Index RAK Regeln für die alphabetische Katalogisierung RAK-ÖB Regeln für die alphabetische Katalogisierung in Öffentlichen Bibliotheken



RAK-WB Regeln für die alphabetische Katalogisierung in Wissenschaftlichen Bibliotheken RDA Resource Description and Access RDF Resource Description Framework RLG Research Libraries Group RSWK Regeln für den Schlagwortkatalog RTF Rich Text Format RVK Regensburger Verbundklassifikation SIP Submission Information Package SKOS Simple Knowledge Organisation System SLUB Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden SMIL Synchronized Multimedia Integration Language SOH Serials Online Holdings SPS Serials Products and Subscriptions SRN Serials Release Notification SRU Search/Retrieve via URL SWN Südwestdeutscher Bibliotheksverbund SWD Schlagwortnormdatei URL Uniform Resource Locator URN Uniform Resource Name VIAF Virtual International Authority File XFDU XML Formatted Data Unit XHTML Extensible HyperText Markup Language XML Extensible Markup Language XMP Extensible Metadata Platform ZDB Zeitschriftendatenbank ZING Z39.50 International Next Generation


Metadatenanreicherung im digitalen Publikationsprozess Abbildungsverzeichnis

Abbildungsverzeichnis Abbildung 2.1: FRAD Model Abbildung 3.1: Beteiligte Rollen im Publikationsprozess Abbildung 3.2: Objekte im OAIS Information Model Abbildung 3.3: Information Package im OAIS Information Model Abbildung 3.4: OAIS Functional Model Abbildung 3.5: Prozess des Harvesting mittels OAI-PMH Abbildung 3.6: Primärbeziehungen in einer Aggregation gemäß OAI-ORE Abbildung 3.7: Geschachtelte Aggregationen gemäß OAI-ORE Abbildung 5.1: Beispiel für die Entitätsaufgliederung nach dem FRBR Model Abbildung 5.2: Beispiel für die innere Ordnung einer Manifestation Abbildung 5.3: Assoziation von Struktureinheiten unterschiedlicher Manifestationen Abbildung 6.1: Beteiligte Organisationen bei der Metadatenanreicherung im Archi-

vierungsprozess des DKV Abbildung 7.1: Visualisierung des prozeduralen Ablaufs anhand der umgesetzten

Sichten Abbildung 8.1: Mock-up einer Metadatenpräsentation Abbildung A1: Einteilung der Datengruppen im Katalogkartenmuster der Library of

Congress Abbildung A2: Beispieldatensatz für MARC 21 Abbildung A3: Resource Statement Abbildung A4: Dublin Core Abstract Model Abbildung A5: Beispiel für strukturierte Angaben in XMP Abbidlung A6: PREMIS Data Model Abbildung A7: Konzeptuelle Sicht auf eine XFDU Abbildung C1: IMS AccessForAll Meta-data (ACCMD) Information Model als UML-

Diagramm Abbildung C2: Dublin Core AccessForAll (AfA) Application Profile Abstract Model

als UML-Dagramm


Metadatenanreicherung im digitalen Publikationsprozess Tabellenverzeichnis

Tabellenverzeichnis Tabelle 4.1: Zusammenfassung der Features eines DTB gemäß ANSI/NISO

Z39.86-2005 Tabelle 4.2: Metadatenansetzung für eingesetzte Braillenotation Tabelle A1: Deutsche Übersetzung des MARC-Vokabulars Tabelle A2: Kodierung des MARC-Vorspanns Tabelle A3: Übersicht über die Top-Level-Elemente von MODS Tabelle A4: Dublin-Core-Metadata-Elements Tabelle A5: Beschreibung der Einträge des ONIX-Product-Record-Format 2.1

Revision 03 Tabelle A6: Zugehörigkeit der Produkteinträge zu den Arten von Metadaten Tabelle B1: DTB-Metadaten im OPF-File gemäß ANSI/NISO Z39.86-2005 Tabelle B2: DTB-Metadaten in SMIL-Dateien gemäß ANSI/NISO Z39.86-2005 Tabelle B3: DTB-Metadaten im NCX-File gemäß ANSI/NISO Z39.86-2005 Tabelle B4: DTB-Metadaten im NCC-File gemäß DAISY 2.02 Spezifikation Tabelle B5: DTB-Metadaten in SMIL-Dateien gemäß DAISY 2.02 Spezifikation Tabelle B6: DTB-Mastermetadaten in SMIL-Dateien gemäß DAISY 2.02 Spezifi-

kation Tabelle D1: Konkordanz von Metadaten des ANSI/NISO Z39.86-2005 Standard

zu MARC 21 Tabelle E1: RDF-Tripel Tabelle E2: URIs zu den Subjekten, Prädikaten und Objekten



A Metadatenstandardkompendium A.1 Maschinelles Austauschformat für Bibliotheken (MAB) Das Maschinelle Austauschformat für Bibliotheken (MAB) wurde von der Deutschen Bibliothek und der Arbeitsstelle für Bibliothekstechnik als erstes nationales Aus-tauschformat konzipiert. Das heutige Format ist vorrangig MAB2, eine 1995 einge-führte und vollkommen überarbeitete Version seines Vorgängers von 1973. MAB setzt bei der Katalogisierung, für einen deutschen Standard nahe liegend, auf die Regeln zur Alphabetischen Katalogisierung (RAK). Das Format liegt derzeit in der zweiten Version als MAB2 vor und besteht insgesamt aus fünf Teilformaten, die folgende Typen von Daten auszeichnen:

1. Bibliografische Daten (MAB -Titel), 2. Personennamen (MAB -PND), 3. Körperschaftsnamen (MAB -GKD), 4. Schlagwörter (MAB -SWD) und 5. Lokaldaten (MAB -Lokal)

MAB2 wird als Austauschformat zwischen einer Vielzahl von deutschen Bibliotheken eingesetzt. Neben deskriptiven Metadaten können in MAB2 auch administrative und ein Minimum an technischen Metadaten spezifiziert werden. Ein ähnliches, allerdings international etablierteres Austauschformat ist MARC 21 und wird nach seiner Einführung 2009 in den nächsten Jahren den Gebrauch von MAB2 im deutschen Bibliothekswesen ablösen. MAB2 warf über die Anwendungsdauer diverse Probleme bei der Handhabe auf. Da beispielsweise keine Unterfelder wie in MARC 21 vorgesehen waren, gestaltet sich die Beschreibung der an Facettenreichtum gewinnenden Ressourcen höchst schwie-rig. Die für das Mapping zwischen MAB2 und MARC 21 erforderlichen Überführungsre-geln wurden in Form einer Konkordanz [KMM08] durch die Deutsche Nationalbiblio-thek veröffentlicht. Somit ist es Dritten bzw. Entwicklern möglich, den existierenden Katalogisierungsbestand bestehender Informations- und Archivierungssysteme nach der offiziellen Umstellung auf MARC 21 zu portieren. Aufgrund der Einstellung des Formates und dem bereits festgelegten Umstieg auf MARC 21 wird an dieser Stelle nicht vertiefend auf MAB2 eingegangen.

A.2 MARC 21 Machine-Readable Cataloging (MARC) ist ein Metadatenformat mit bibliothekarischer Geschichte. Bereits in den 60er Jahren entwickelte Henriette Avram an der Library of Congress einen ersten bibliografischen Datensatz. Dieser war im Prinzip eine Ablei-tung der bis dahin verwendeten Beschriftungstechnik für Katalogkarten. Bereits 1965 stellte die Library of Congress eine Expertengruppe zusammen, die sich mit der elektronischen Ablage beschäftigte. Schon damals kam der Gedanke auf, die biblio-grafischen Metadaten nicht nur in gedruckter, sondern auch in elektronischer Form auszutauschen. Copyright TU-Dresden, Alexander Haffner 121


Nach ersten Erfolgen des Metadatenformats in den USA fand man auch in der Nati-onal Library of Canada Interesse an den neuen Verfahren. Im Weiteren fand MARC großen Anklang in Japan, Australien, Russland und Großbritannien sowie einigen weiteren europäischen Ländern. MARC ist aufgrund seiner hohen Granularität der weltweit am häufigsten eingesetzte Metadatenstandard zum Austausch von Informationen zwischen Bibliotheken. Allein die Mitglieder des Online Computer Library Center (OCLC) mit mehr als 60.000 Bib-liotheken aus 112 Ländern verwenden MARC als Austauschformat. An dieser Stelle soll auch erwähnt werden, dass eine Reihe von Bibliotheken MARC sogar als Intern-format verwendet. MARC 21 ist das Resultat aus der Kombination der amerikanischen und der kanadi-schen MARC-Formate (USMARC und CAN/MARC). MARC 21 basiert auf dem ANSI- Standard Z39.2 bzw. der ISO 2709. MARC 21 und sollte als Over-all-Format dienen sowie den außernordamerikanischen Bibliotheken den Umstieg erleichtern, um inter-national die Harmonisierung der Metadatenverwendung in Bibliotheken voranzutrei-ben. Prinzipiell bietet MARC 21 die in Kapitel 2.2.1 geforderte standardisierte Datenstruk-tur, d. h. es ist ein regelwerksneutrales Datenmodell. Die Inhalte können nach ver-schiedenen Katalogisierungsregeln erschlossen werden. Die Inhalte der meisten zurzeit existierenden MARC-Datensätze sind nach den Bestimmungen der Anglo-American Cataloguing Rules 2 (AACR2) erschlossen worden [CRO04]. Es ist natür-lich genauso möglich, die RAK in MARC 21 zur Katalogisierung heranzuziehen. Im Laufe der Umstellung auf Resource Description and Access (RDA) wird MARC 21 für eine optimale Abdeckung und Kompatibilität zu RDA durch die RDA/MARC Working Group weiter verfeinert. Es existieren MARC 21 Formate für:

1. Bibliographic Data: Dient als Träger für bibliografische Informationen (gemäß Formalerschließung) über gedruckte und handschriftliche Textmaterialien, Computerdateien, Karten, Musik, fortlaufende Sammelwerke, visuelle Materia-lien und gemixte Materialien. Bibliografische Daten sind im Allgemeinen Titel, Angaben zu Mitwirkenden, Anmerkungen, Verleger und Informationen über die physikalische Erscheinung der Ressource.

2. Authority Data: Umfasst Name Authorities (Normdaten zu Personen und Kör-perschaften sowie Normansetzungen von Person+Werk, also eine Art Ein-heitssachtitel). Die Name Authorities werden im amerikanischen Raum gleichermaßen für Formal- und Sacherschließung genutzt. Es gibt für diese zwei Bereiche keine unterschiedlichen Ansetzungen wie in Deutschland. In Deutschland hingegen werden Zugriffspunkte eher der Sacherschließung zu-geordnet. Subject Authorities und Subject Subdivision Authorities (Refine-ments) bilden die amerikanische Schlagwortnormdatei ab und enthalten die Library of Congress Subject Headings (LCSH). In Deutschland werden die Normdaten für Personennamen, Körperschaften und Schlagwörter durch die Deutsche Nationalbibliothek in Normdateien bereitgestellt.

3. Classification Data: Klassifikation mittels Kennziffern, die die zugehörige Rub-rik in einem assoziierten Schema (Library of Congress Classification (LCC) Schema, Dewey Decimal Classification (DDC) Schema) formulieren.

4. Community Information: Nicht-bibliografische Einträge mit Details zur Be-schreibung des Serviceanbieters. Hierzu gehören u. a. Kontaktdaten, techni-



sche Ausstattung, angebotene Programme und Events sowie eventuell anfal-lende Gebühren.

5. Holdings Data: Liefert kopiespezifische Informationen für den Bestand und die Lokalisierung von Publikationen in der Bibliothek oder Organisation (Ablage-ort, Anzahl der Kopien, Chronologie etc.). Holdings Data kann in einem sepa-raten Record gehalten werden und mit der bibliografischen Information verlinkt werden bzw. kann beispielsweise in einem Verbundkatalog zu einem biblio-grafischen Eintrag für jede archivierende Organisation ein separater Holding-Record existieren.

Im Folgenden soll am Beispiel der Bibliographic Data das praktische Vorgehen für die Verwendung erläutert werden. Das MARC-Format ist eng an das herkömmliche verwendete Muster für die Beschrif-tung von Katalogkarten der Library of Congress angelehnt.

Abbildung A1: Einteilung der Datengruppen im Katalogkartenmuster der Library of Congress [CRO04] Im MARC-Format wird jede Gruppe von Informationen durch eine dreistellige Katego-rienummer gekennzeichnet, wobei die erste Ziffer eine allgemeine Gruppierung aus-weist. Im Folgenden wird die Gruppierung mit den zugehörigen bibliografischen Informatio-nen vorgestellt:

• 0XX Kontrollfelder, Identifikations- und Steuerdaten: u. a. Identifikationsnum-mer, letzte Transaktionszeit, physische Beschreibung (007 für Bücher, sonst 008), Identifikationsnummer der Library of Congress und des nationalen Bib-liotheksystems, ISBN, Bestellnummer, Copyright, katalogisierende Stelle, Pub-likationsort, Sprachangaben, Signatur und Klassifikationsnummer

• 1XX Haupteintragung: Personenname, Körperschaftsname, Kongressname, Einheitstitel



• 2XX Informationen, die der Titelseite zu entnehmen sind (Titel und bibliografi-sche Beschreibung): u. a. Abkürzung des Titels, Key Title bei fortlaufenden Sammelwerken), Einheitstitel, Übersetzung, title and statement of responsibili-ty (Titel gefolgt von Angaben über beteiligte Personen oder Körperschaften, in Vorlageform), Titelvarianten (auch ehemalige), Ausgabenvermerk und Er-scheinungsvermerk.

• 3XX Angaben über die physische Erscheinung der Vorlage: u. a. physische Beschreibung (Umfang, Maßangaben etc.), Erscheinungsfrequenz und Er-scheinungsverlauf (nur bei Zeitschriften), Mediumsart, Spielzeit, Verkaufspreis und Verfügbarkeit

• 4XX Serienangabe/Gesamttitelangaben in Vorlageform („series statements“)

• 5XX Fußnoten: u. a. allgemeiner Natur, bibliografische Nachweise, Inhaltsan-gabe, Zugriffsrechte, Qualität, Zielgruppe, geografisches Einzugsgebiet sowie Besitzer- und Rechteinformationen

• 6XX Schlagwörter: Personenname, Körperschaftsname, Einheitstitel, Sach-schlagwörter, Gebietskörperschaften/Geografika, Angaben zur literarischen Gattung usw.

• 7XX Nebeneintragungen (Zusätzliche Zugriffspunkte): u. a. Gesamttitelanga-ben in normierter Form, Serien-Nebeneintragungen („series tracings“), Linking (Hauptwerk, Unterwerk, Übersetzungen etc.)

• 8XX Serien-Nebeneintragungen (Gesamttitel), elektronischer Zugriff: u. a. Ge-samttitelangaben in normierter Form, übergeordneter Titel etc.

• 9XX Lokale Daten: nicht standardisiert und somit durch jede Bibliothek indivi-duell einsetzbar

Dabei sind die Kategorien 1XX bis 8XX in Klartext, wogegen 0XX in kodierter Form (Codes) angegeben werden muss. Das folgende Vokabular wurde für die Elemente des Datenformats eingeführt: field Feld bzw. Kategorie fixed field Feld fester Länge, Festfeld variable-length field

Feld variabler Länge

tag streng genommen die Nummer, die am Anfang des Feldes steht und das Feld iden-tifiziert, also „Kategorienummer”; im alltäglichen Gebrauch wird tag aber so verwen-det, als sei es gleichbedeutend mit field

code Code subfield Unterfeld subfield code Unterfeldkennung subfield delimi-ter

Unterfeldtrennzeichen

Tabelle A1: Deutsche Übersetzung des MARC-Vokabulars Die Felder (fields) des Formats können von fester oder variabler Länge sein. Die Fel-der variabler Länge dürfen sich aus mehreren Unterfeldern (subfields) zusammen-setzen. Unterfelder werden voneinander durch Unterfeldkennungen (subfield codes) abgesetzt. Diese Unterfeldkennungen geben sich durch das vorangestellte Unterfeld-trennzeichen (subfield delimiter) zu erkennen.



Alle Felder außer 000 bis 009 besitzen ein oder zwei Indikatoren, die direkt hinter den Feldnummern erscheinen. Diese Indikatoren üben abhängig vom Feld verschie-dene Funktionen aus und können mit definierten Werten belegt werden.

245 00 $a Semantic Web $b Grundlagen $c Pascal Hitzler

Feld/Tag

Indikator 1 Unterfeld 2 Unterfeld 1

Unterfeld-kennung Unterfeldtrennzeichen

Unterfeld 3

Indikator 2

Abbildung A2: Beispieldatensatz für MARC 21 Außer den Kategorien existieren zwei weitere Bestandteile: der Vorspann (Leader) und das Inhaltsverzeichnis (Directory). Das Inhaltsverzeichnis enthält alle Anweisungen für die Ortung bestimmter Daten innerhalb des Metadatensatzes. Der Vorspann von 24 Byte (Stellen 00 bis 23) enthält kodierte Angaben allgemeiner Natur. Dabei wird jede Stelle entweder mit einem Code belegt oder freigelassen. 00-04 Angaben zur Länge des Datensatzes 05 Satzstatus (Record status) 06 Materialtyp der Vorlage (Buch, Musikdruck, Tonaufzeichnung, projiziertes Medium usw.) 07 Bibliografische Ebene (Monografie oder fortlaufendes Werk) 08 Erfassungstiefe 09 Zeichenkodierung (verwendete Syntax) 10 Indikatorlänge 11 Unterfeldkennungslänge 12-16 Datenanfangsadresse (Länge von Vorspann und Inhaltsverzeichnis) 17 Encoding Level (Fülle der bibliografischen Information und/oder Inhaltsbezeichnung) 18 Katalogisierungsform (AACR2, ISBD, RAK etc.) 19 Art des mehrbändig begrenzten Werkes 20-22 Angaben zum Inhaltsverzeichnis (Directory map) 23 Prinzipiell nicht definiert, kann aber Dateikennzeichen (Titelsatz/Normsatz/Bestandssatz)

enthalten

Tabelle A2: Kodierung des MARC-Vorspanns Auf den Vorspann folgen die nummerierten Felder von 000 bis 999. Von diesen 1000 Feldern ist allerdings nur ein Bruchteil definiert und im Alltagsgebrauch eingesetzt. Aufgrund des immensen Umfanges von MARC 21 wird für die genaue Verwen-dungsweise der einzelnen MARC 21 Formate an dieser Stelle auf die entsprechen-den Standards [MARC08] verwiesen. Neben der herkömmlichen Syntax von MARC 21 wurde durch das Network Deve-lopment and MARC Standards Office der Library of Congress auch ein Framework für den Umgang mit MARC-Datensätzen in XML veröffentlicht. Das Framework soll insbesondere die Aspekte der Flexibilität und Erweiterbarkeit des Formates gestat-ten. Das Framework umfasst Komponenten wie Schemas, Stylesheets, und Soft-waretools [MXML08]. Die Beschreibung zu Hitzlers Buch würde in der MARCXML-Syntax beispielsweise wie folgt aussehen:



<?xml version="1.0" encoding="UTF-8" ?> <collection xmlns="http://www.loc.gov/MARC21/slim"> <record> <leader>…</leader> <controlfield tag="xxx">…</controlfield> … <datafield tag="245" ind1="0" ind2="0"> <subfield code="a">Semantic Web</subfield> <subfield code="b">Grundlagen</subfield> <subfield code="c">Pascal Hitzler</subfield> </datafield> … </record> </collection>

Außer einem Stylesheet für die Transformation nach HTML veröffentlichte die Grup-pe auch Stylesheets für die Transformation nach MODS und Dublin Core. Es soll jedoch betont werden, dass MARC 21 der weltweit gebräuchlichste und wohl am meisten ausgereifte Metadatenstandard für Bibliotheken ist, allerdings existiert eine Problematik, auf die noch kurz eingegangen werden soll. Die Erschließung von mehrteiligen bzw. mehrbändigen Werken wird in der anglo-amerikanischen Praxis „Analyse“ (analysis) genannt. Die AACR2 beschreiben insge-samt fünf Verfahren für die Analyse bzw. Erschließung von mehrteiligen Werken.

• Analytical added entries (Zusätzliche Zugriffspunkte zur Erschließung der Tei-le, analytische Nebeneintragung): einfacher Zugriffspunkt besteht bloß aus dem Titel des Teiles - title added entry, zweiteiliger Zugriffspunkt besteht aus zusammengesetzter Ansetzungsform (Namen des Verfassers, gefolgt vom Ti-tel des Teils) - name-title added entry

• Analysis of monographic series and multipart monographs (die sogenannte full analysis, d. h. das Erstellen von Einheitsaufnahmen für die Teile eines mehr-teiligen Werks)

• Note area (Angabe der Teile in einer Fußnote): keine normierte Angabe zu den Bestandteilen

• „In“ analytics (z. B. eine Einheitsaufnahme für einen Artikel, der in einer Zeit-schrift erschienen ist. Diese Form der Analyse hat Ähnlichkeiten mit der Er-schließung von unselbständigen Werken gemäß den RAK)

• Multilevel description (mehrstufige Beschreibung) Die drei erstgenannten Verfahren sind die in der Praxis eingesetzten und reichen von einer einfachen Auflistung der enthaltenen Werke in einer Fußnote bis zu der Erstel-lung einer vollständigen Einheitsaufnahme für jedes Werk, das in dem Gesamtwerk enthalten ist. Es liegt im Ermessen des Katalogisierers, welche der drei Formen der Analyse er in einem bestimmten Fall anwenden möchte. Allerdings ruft diese Freistel-lung Konsistenzprobleme unter den einzelnen Bibliotheken hervor, welche es durch RDA und den angepassten MARC 21 Standard abzufangen gilt. MARC 21 ist auf die Auszeichnung deskriptiver Metadaten zugeschnitten. Struktur-Metadaten werden hingegen für Ressourcen, die Aggregationen darstellen, nicht un-terstützt. Administrative Metadaten sind für nicht-digitale Ressourcen ausreichend und für digitale Ressourcen begrenzt enthalten, wobei an dieser Stelle der Übergang zu technischen Metadaten fließend ist. Allerdings war es auch nie vorgesehen, tech-nische Metadaten in MARC 21 zu integrieren, da prinzipiell zusätzliche Metadaten-



standards an dieser Stelle Einsatz finden sollten. Das gleiche gilt für Rechte-Management-Metadaten und Marketing- oder handelsspezifische Metadaten. Meta-daten zur Langzeitarchivierung sind in MARC 21 nicht integriert.

A.3 Metadata Object Description Schema (MODS) Das Metadata Object Description Schema (MODS) ist ein XML-basierter Metadaten-standard, welcher für die Beschreibung deskriptiver Metadaten vorgesehen ist. MODS bildet eine Kompromisslösung zwischen MARC mit seiner extrem hohen Komplexität und dem für viele Anwendungen zu einfachen Dublin Core. Der Anstoß für die Entwicklung von MODS kam aus der Bibliotheksumgebung, die den aufkommenden XML-Boom im Internet bemerkte und das Potential für ein dem-entsprechendes Metadatenaustauschformat sah. MODS sollte lediglich die Schlüsselfelder von MARC enthalten. Das bedeutet, eine Reihe von Feldern des MARC-Formats können nicht nach MODS überführt werden. Auch trennte man sich von der Aufteilung nach Feldern und Unterfeldern, was sich sehr zum Vorteil der Lesbarkeit auswirkt. Für die Tags selbst werden Ausdrücke in durch Menschen lesbarer Sprache verwendet. Im Juni 2002 wurde das erste XML-Schema durch das Network Development and MARC Standards Office der Library of Congress veröffentlicht und zum Test frei ge-geben. Seit 2008 liegt das XML-Schema in der Version 3.3 vor. Offiziell sind es je-doch nur wenige Dutzend Literaturverwaltungssysteme, die MODS aktuell einsetzen. Die Top-Level Elemente sollen an dieser Stelle nur genannt werden. Sie sind mit Subelementen untersetzt und durch Attribute charakterisierbar. Für Details sei auf das entsprechende Schema [MODS08] verwiesen. Title Info Language Note Location Name Physical description Subject Access conditions Type of resource Abstract Classification Part Genre Table of contents Related item Extension Origin Information Target audience Identifier Record Info

Tabelle A3: Übersicht über die Top-Level-Elemente von MODS Insgesamt lässt sich die Ableitung vom MARC-Format deutlich erkennen, wobei die Vereinfachung für den nicht-bibliothekarischen Erschließer durchaus von Vorteil er-scheint. Auch wird über das Authority-Attribut bei einer Reihe von Elementen eine Beziehung zu Normdatendateien geschaffen. Über Identifier sind die einzelnen Elemente ein-deutig identifizierbar und untereinander referenzierbar. MODS deckt deskriptive Metadaten prinzipiell ausreichend ab, aber in Bezug auf die bibliothekarisch gewünschte Feingranularität für die Ressourcenbeschreibung und die Definition von Zugriffspunkten ist MODS wahrscheinlich nicht genügend geeignet. Es ist auch möglich, die Struktur einer Ressource ansatzweise zu beschreiben. Für die Administration sind Metadaten für den Regalbestand sowie für die digitale Archi-vierung vorgesehen. Auch werden Metadaten für die Rechteverwaltung einbezogen. Hingegen sind keine Angaben zu Marketing- oder handelsspezifische Metadaten und Metadaten für die Langzeitarchivierung integriert. Da keine Festlegungen der Library of Congress bezüglich der Überschneidungen zwischen MARC und MODS getroffen wurden, ist MODS nicht nur eine Untermenge



von MARC, sondern definiert sogar Elemente, die in MARC nicht verankert sind. Somit ist die bidirektionale Transformation verlustbehaftet. Zur Konvertierung zwischen Dublin Core, MARC und MODS werden durch die Libra-ry of Congress eine Reihe von XSLT-Skripten zur Verfügung gestellt. In den Vereinigten Staaten werden Diskussionen geführt, ob MODS in den Bibliothe-ken Einsatz finden soll. Die Antwort des Autors dieser Arbeit fällt dazu relativ klar aus. Wenn MODS Einsatz finden sollte, dann nur an der Seite von MARC 21. RDA wird eine Reihe von Feinheiten für die Erschließung hervorbringen, die für die Lang-zeitarchivierung in einer Bibliothek und für die Annäherung an Endnutzerbedürfnisse essentiell sein werden. Außerdem wird MARC 21 im Gegensatz zu MODS sehr de-tailliert auf RDA abgestimmt sein. Als Austauschformat zwischen Bibliotheken und nicht-bibliothekarischen Dienstleistern ist MODS durchaus vorstellbar, da es durch die Ableitung von MARC doch nahe an der in Bibliotheken verwendeten Struktur liegt und für domänenfremde Nutzer einfacher zu handhaben ist.

A.4 Dublin Core Die Dublin Core Metadata Initiative (DCMI) engagiert sich seit 1994 für die Integra-tion von Metadaten im Internet. Anlass war das Erkennen der immer größeren Infor-mationsflut im Internet und der damit auftretenden Problematik der Archivierung und Auffindung von Ressourcen sowie der Interoperabilität von zugehörigen Metadaten. Aus dieser Intention heraus entwickelte die Organisation den Dublin-Core-Metadatenstandard für die Beschreibung von digitalen Ressourcen. Die DCMI ist nicht nur die größte internationale Vereinigung auf dem Gebiet Metadatenstandardi-sierung, sie ist außerdem unabhängig und offen. Das bedeutet jeder Interessierte kann sich an der Arbeit beteiligen und die Entwicklung beeinflussen. Der Unterschied der Dublin-Core-Metadaten (DC-Metadaten) zu anderen sollte in seiner Einfachheit liegen, d. h. jeder soll sie anwenden können.

Metadata consists of statements we make about resources to help us find, iden-tify, use, manage, evaluate, and preserve them. [KUR06]

Resultierend stellt sich natürlich die Frage, wie ein solches Statement aussehen kann.

resource value

property

statement Diplomarbeit creator = Alexander Haffner

beschreibt

Alexander Haffner

creator

Abbildung A3: Resource Statement Metadata-Statements beschreiben Ressourcen, wobei ein Statement eine Property (Element) und einen zugehörigen Value beinhaltet. Eine Property repräsentiert eine Charakteristik einer Ressource. Im Beispiel wird eine Aussage über den Autor dieser Diplomarbeit getroffen. Das Metadata-Framework der DCMI setzt sich aus einem Datenmodell, einem Voka-bularmodell und einem Profile-Modell sowie einem Set an Metadaten-Formaten zu-sammen.



Das DCMI Abstract Model [DCAM07] stellt ein kohärentes Datenmodell dar und dient als Basis für zukünftige DCMI-Entwicklungen. Es definiert Ressourcen in Form von semantischen Beziehungen unter Classes, Properties und Values, sowie einem Mo-dell für DCMI Descriptions und zusammengehörigen Descriptions in Description Sets als Record. Eine Description besteht aus einem oder mehreren Statements, wobei eine Descrip-tion genau eine Ressource (1:1 Principle) beschreiben kann. Allerdings kann eine Ressource in der realen Welt durch mehrere Descriptions beschrieben werden. So könnte eine Aussage über ein Gemälde und über seinen Maler getroffen werden wol-len. Diese Zusammensetzungen nennt man Description Sets. Description Sets sind für den Austausch zwischen Softwareapplikationen in Form von Metadata-Records vorgesehen.

Abbildung A4: Dublin Core Abstract Model nach [NIL07] Die Darstellung zeigt, dass die Description genau einer Ressource über deren URI zugeordnet wird. Außerdem werden die Properties eines Statements über URIs ein-deutig identifiziert. Bei Values unterscheidet man zwischen Literal Values und Non-literal Values. Literal Values sind Strings in einer lexikalischen Form (Syntax Encoding Scheme) und mit definierter Sprache (Text, Zahl etc.). Non-literal Values sind physikalische, digitale oder konzeptionelle Entitäten (Personen, Dokumente, Events, etc.). Non-literal Va-lues können in einer separaten Beschreibung als Statement beschrieben werden, wobei ein Statement Multiple Value Strings, ein Vocabulary Encoding Scheme und eine Value URI enthalten kann. Ein Surrogate steht als Platzhalter bereit und kann mit einer für ihn validen Description verlinkt werden. Das DCMI Abstract Model selbst ist syntaxunabhängig. Die DCMI empfiehlt zum Ausdrücken von DC-Metadaten in einer Anwendung den Einsatz von XML, HTML/XHTML oder Resource Description Framework (RDF) Meta- und Link-Elementen. Es stellt sich an dieser Stelle die Frage, warum verschiedene Syntaxen Copyright TU-Dresden, Alexander Haffner 129


angeboten werden. Die Integration der DC-Metadaten soll in verschiedenen Kontex-ten ermöglicht werden und dem Entwickler eine Auswahl der Implementierung für die Anpassung an sein System bieten. Man unterscheidet die DC-Metadatenformate prinzipiell zwischen DC Simple und DC Qualified. DC Simple beinhaltet die 15 Kernelemente. Diese sind im Dublin Core Metadata Element Set 1.1 in der NISO Z39.85-2007 bzw. in der ISO 15836 standardisiert. Die-se Elemente machen lediglich von den Value Strings Gebrauch. DC Qualified hingegen macht von allen Features des DCMI Abstract Model Gebrauch. Dies beinhaltet Element Refinements und Value Encoding Schemes (Vo-cabulary Encoding Schemes und Syntax Encoding Schemes). Ein Element Refine-ment ist beispielsweise die Angabe eines alternativen Titels zum eigentlichen Titel und somit eine Sub-Property. Das Vocabulary Encoding Scheme wird als Indikator einer Class eines Values genutzt (beispielsweise ist ein Value aus der LCSH – Normdatei). Ein Syntax Encoding Scheme zeigt, wie der Value String strukturiert ist (beispielsweise als Datum 2008-10-31). Qualified DC-Metadaten sind in den DCMI Metadata Terms festgehalten. Das Dublin Core Metadata Element Set stellt dabei ebenfalls eine Untermenge in den DCMI Metadata Terms dar. In der folgenden Tabelle wird ein Überblick über die 15 Elemente des Dublin Core Metadata Element Set gegeben. Bezeichnung Erläuterung contributor Mitwirkende/-r: Person, Organisation oder Dienst coverage Geltungsbereich: räumliches Thema und räumliche Verwendbarkeit (Ort), zeitliches

Thema (Epochenbezeichnung, Zeitangabe oder Zeitraum), Rechtsraum (Name einer Verwaltungseinheit oder ein geografischer Ort für die oder den die Ressource gilt)

creator Urheber: Person, Organisation oder Dienst, mit wesentlicher Verantwortlichkeit für die Erschaffung der Ressource

date Zeitangabe: ein Zeitpunkt oder eine Zeitspanne im Zusammenhang mit einem Ereig-nis im Entwicklungsprozess der Ressource

description Beschreibung der Ressource: Zusammenfassung, Inhaltsverzeichnis, grafische Dar-stellung oder eine Freitextbeschreibung

format Format: Dateiformat, Datenträger oder der Umfang (Größe, Laufzeit etc.) der Res-source (MIME-Typ verwenden)

identifier Identifikator: eindeutige Referenz auf die Ressource innerhalb eines gegebenen Kon-texts (ISBN/ISSN, URL/PURL, URN, DOI etc.)

language Sprache der Ressource (kontrolliertes Vokabular wie RFC 4646 empfohlen) publisher Verleger: Verantwortlicher für die Verfügbarkeit der Ressource relation Beziehung zu verwandter Ressource (Angabe über Identifier) rights Rechte: Rechteinformationen über unterschiedliche Eigentumsrechte (einschließlich

Schutz-und Urheberrechte) an der Ressource. source Quelle: Ressource von der die beschriebene Ressource teilweise oder vollständig

abgeleitet ist (Angabe über Identifier) subject Thema: Stichwörter, Schlagwörter oder Notationen (formales Klassifikationsschema

verwenden) title Titel: Name der Ressource type Typ: Art oder Gattung der Ressource (Angabe beispielsweise mittels DCMI Type

Vocabulary)

Tabelle A4: Dublin-Core-Metadata-Elements vgl. [DUB07] Das Dublin Core Metadata Element Set entspricht den traditionellen deskriptiven Me-tadaten und deckt die Basiselemente für eine Archivierung ab.



Die Application Profiles stellen den Schlüssel für die praktische Anwendung von DC-Metadaten in verschiedensten Domänen dar.

Application profiles consist of data elements drawn from one or more name-space schemas combined together by implementers and optimised for a par-ticular local application. [HEE00]

Durch Application Profiles können DC-Metadaten in Verbindung mit nicht-DC-Metadaten verwendet werden. Im Profil wird festgelegt, welche Elemente aus wel-chem Namespace eingesetzt werden dürfen. Dadurch erreicht man innerhalb der Anwender-Community einen hohen Grad an Interoperabilität. Die Nachnutzung exis-tierender und etablierter DC-fremder Metadatenstandards erleichterte vielen Com-munities die Annäherung an DC-Metadaten. Zur Unterstützung der Belange von Bibliotheken existiert das DC-Library Application Profile (DC-Lib), was allerdings seit August 2004 nur als Working Draft vorliegt. Die Entwicklung des DC-Lib wurde durch die DCMI-Libraries Working Group vorgenom-men und durch diverse Konflikte (fehlende URIs, die in Application Profiles für alle Elemente wie in Dublin Core zwingend sind) bei der Integration von MODS-Elementen gebremst. Wofür soll das DC-Lib Bibliotheken und zu ihnen in Beziehung stehenden Organisa-tionen dienen?

• als Austauschformat zwischen Systemen, die unterschiedliche Metadatenfor-mate und -standards nutzen,

• die automatische (regelmäßige) Übernahme von Metadaten (Harvesting) von Datenquellen innerhalb und außerhalb der Bibliotheksdomäne ermöglichen,

• Unterstützung bei der einfachen Erstellung von Bibliothekskatalogeinträgen für Ressourcen aus einer Vielfalt von Systemen,

• für die Bereitstellung von MARC-Datensätzen für Dritte mittels Konvertierung nach DC,

• nicht bibliothekarischen Organisationen die Chance geben, ihre Metadaten auf einen einfachen bibliothekarischen Satz zu mappen.

Im DC-Lib finden sich Definitionen für die zugelassenen Elemente, Qualifiers, Sche-mes und Values aus Dublin Core. Zusätzlich werden Library Domain Elements aus anderen Namespaces (MODS Elements) und Application Profiles (z. B. DC-Education: Audience) sowie ausgewählte Refinements nachgenutzt. DC-Lib ist unabhängig von Regelwerken für die Katalogisierung und kann somit für Ansetzungen gemäß AACR2 oder RAK-WB verwendet werden. Die daraus folgende Interoperabilitätsproblematik soll durch das RDA Element Set behoben werden, was eine Weiterentwicklung des DC-Lib nicht praxisrelevant macht. Nach einem Treffen 2007 zwischen dem Joint Steering Committee, Vertretern von Dublin Core und Semantic Web Communities wurde die DCMI/RDA Task Group ins Leben gerufen. Das RDA Element Set soll insbesondere für die Durchsetzung der mittels RDA angesetzten Metadaten im Internet sorgen. Somit erhält die Bibliotheks-welt ein Application Profile, was optimal auf die Erschließung und den Metadatenaus-tausch durch DC-Metadaten zugeschnitten ist. Außenstehende Internet Communities haben des Weiteren die Möglichkeit diese Metadaten maschinell zu verarbeiten und qualitativ hochwertig nachnutzen zu können. Für eine einfache Anwendbarkeit wur-den Elemente für die Attribute der Entitäten und für Beziehungen definiert. Für die Elemente sind Unterelemente (sub-elements) und Untertypen (sub-types) für eine



Verfeinerung spezifiziert. Für Inhalte wird ein Vokabular festgelegt, um einheitliche Datensätze zu erheben. DC-Metadaten bieten eine Reichweite von den 15 primitiven Elementen des DC Ele-ment Sets bis zu ausgeklügelten Application Profiles für jede Domäne und jede Art von Metadaten. Durch das zugrunde liegende Abstract Model ist die Konsistenz bei der Verwendung hervorragend gegeben. Auch die syntaktische Freiheit ist für den praktischen Einsatz von Nutzen. Aus Sicht des Autors empfiehlt es sich jedoch nur bedingt, DC-Metadaten als Intern-format in einem Archivierungssystem und als Austauschformat zwischen solchen einzusetzen. Die benötigte Feingranularität, die von Bibliotheken gefordert ist, stellt sich nicht dar. Dies könnte sich durch die Verbreitung des RDA Element Sets än-dern. Bislang existieren für den Metadatenaustausch zwischen Bibliotheken besser geeignete Standards wie MARC 21. Die Stärke von DC-Metadaten liegt viel mehr in der Verbreitung von Metadaten im Internet. Für die Informationsanreicherung in Fremdsystemen wie Suchmaschinen steht durchaus ein großer Markt offen. Die automatisierte Verarbeitung, die dem Se-mantic Web zugrunde liegt, profitiert insbesondere von den vorgestellten Konzepten.

A.5 Pica+/Pica3 Das Project of Integrated Catalogue Automation (PICA) beabsichtigte bereits 1969 die gemeinsame Katalogisierung zwischen der Königlichen Bibliothek der Niederlan-de und einer Reihe von Universitätsbibliotheken im holländischen Raum. OCLC-PICA war der europäische Anbieter von Bibliothekssoftware und -dienst-leistungen (z. B. WorldCat, Netlibrary), der aus einer Kooperation der holländischen PICA-Stiftung und dem US-amerikanischen Online Computer Library Center (OCLC) hervorgegangen ist. Der Zusammenschluss OCLC-PICA war für Europa, den Mittle-ren Osten und Afrika zuständig. 2007 wurde OCLC-PICA komplett von OCLC über-nommen. OCLC hat derzeit fast 60.000 Mitglieder weltweit und dementsprechend viele Bibliothekssysteme im Einsatz. Das bekannteste OCLC-Produkt in Deutschland ist der Online Public Access Catalo-gue (OPAC) als ein öffentlich zugänglicher digitaler Bibliothekskatalog. Diese Pica-Software wird unter anderem von der Deutschen Nationalbibliothek und den Biblio-theksverbünden GBV, HeBIS und SWB eingesetzt. Das in der Pica-Software standardmäßig verwendete Metadatenformat ist Pica+ bzw. dessen Repräsentation Pica3 zur Katalogisierung. Die Metadatenformate sind reine Internformate und nicht für den Austausch zwischen Bibliothekssystemen vorgese-hen. Die Pica-Formate sind keine normierten Standards und damit auch nicht vollständig öffentlich zugänglich. Prinzipiell ist Pica modelltechnisch und syntaktisch nah an MARC 21 angelehnt, allerdings mit 30.000 Properties weitaus umfangreicher und feingranularer. Der auffälligste Unterschied gegenüber MARC 21 ist das vierstellige Feldtag zu Beginn eines jeden Datensatzes. In der Deutschen Nationalbibliothek wird der interne Datenbestand in Pica+ gehalten und über Pica3 in Austauschformate transformiert. Da es sich bei Pica+ und Pica3 um Internformate und nicht um Austauschformate handelt, ist es nicht notwendig, es in dieser Arbeit ausführlich zu diskutieren. Es nimmt für die vorgestellten Konzeptionen nur eine nebenläufige Rolle ein. Copyright TU-Dresden, Alexander Haffner 132


A.6 Online Information Exchange (ONIX) Online Information eXchange (ONIX) ist ein Datenformat zum Austausch von biblio-grafischen Metadaten und Produktdaten, welches sich von Seiten des Buchhandels etabliert hat. Das XML-basierte Format wird von EDItEUR (http://www.editeur.org) kontinuierlich an Marktanforderungen angepasst und als ONIX-Standard veröffent-licht. EDItEUR selbst umfasst 90 Mitglieder aus 17 Ländern, was das internationale Durchsetzen des Formates beweist. Die Standards „ONIX for books“ und „ONIX for serials“ umfassen Metadaten für Bü-cher und Sammelwerke, die den Austausch zwischen Verlagen, Buchhändlern, Bib-liotheken sowie weiteren involvierten Dienstleistern unterstützen und eine automatische Weiterverarbeitung der Daten in der jeweiligen Organisation ermögli-chen. Die Übertragung der Informationen zu Monografien findet immer in einer „ONIX for Books product information message“ statt. Diese beginnt prinzipiell mit der Auswei-sung des XML-Formates und der ONIX-Dokumenttypdefinition (seit Version 2.1 auch als XML-Schema). Die eigentliche Nachricht besteht aus einem Header und einer nichtlimitierten Anzahl von Produkteinträgen. <?xml version="1.0"?> <!DOCTYPE ONIXMessage SYSTEM "http://www.editeur.org/onix/2.1/reference/onix international.dtd"> <ONIXMessage> <Header> Message header data elements </Header> <Product> Product information data elements for product 1 </Product> <Product> Product information data elements for product 2 </Product> <Product> … </Product> </ONIXMessage>

Der Message-Header enthält Einträge für die Spezifikation und somit Identifikation des Absenders und der zugehörigen Sendezeit (obligatorisch). Die Adressdaten des Absenders und die Angaben zum Adressaten sind optional. Für die Angabe von Sprache, Währung etc. können an dieser Stelle Default-Werte für die nachfolgenden Produkteinträge festgelegt werden. Der Hauptteil der Nachricht enthält ein oder mehrere Products, Main Series, und/oder Subseries, wobei deren Reihenfolge irrelevant ist. In ONIX gibt es zwei Möglichkeiten der XML-Auszeichnung. Einerseits können wie verdeutlicht ausgeschriebene Referenz-Tags und andererseits zu jedem Tag eine alternative Kurzform (beispielsweise <FromCompany> entspricht <m174>) verwen-det werden. Die Informationen zu einem Produkt werden anhand von 26 relativ klar abgetrennten Produktgruppen angegeben. Die folgende Tabelle weist die Produktgruppen und zu-gehörige Produkteinträge aus, wobei der Autor zu jeder Gruppe eine Kurzbeschrei-bung zur Übersichtsgewinnung des Standards hinzugefügt hat.



Gruppe Inhalt Erklärung PR1 Record reference

number, type and source

einzigartige und permanente Referenznummer, Notification oder Update Type (Vorankündigung, Entfernung, Erweiterungen etc.), Quellenangabe

PR2 Product numbers Artikelnummer, wobei bevorzugt EAN-13 einzusetzen ist, jedoch keine Restriktionen über Auftreten und Kombinationen vorliegen (ISBN-10, EAN.UCC-13/ISBN-13, UPC, herausgeberspezifisch, ISMN, DOI; Product Identifier Composite, Barcode)

PR3 Product form Primärform (physisches Format), Details der Form, Features, Ver-packungsart, Anzahl einer Form, Contained Item Container (gibt Auskunft über alle enthaltenen unterschiedlichen Ressourcenfor-men, jeder Item benötigt Product Identifier oder Product Form Co-de), Warenklassifikation

PR4 Epublication detail Wenn PR3 eine digitale Ressource ausweist, Angabe des Formates oder das es sich um ein Package mit unterschiedlichen Medien handelt (Spezifikation in PR23), Version- und Quellenangabe

PR5 Series Eine Reihe von Produkten, die unter einem gemeinsamen Titel lau-fen (kein Einzelprodukt, keine ISBN), ein Produkt kann zu mehreren Series gehören, neben Serientitel, Contributor etc. muss das Pro-dukt eine Nummer in der Serie bekommen

PR6 Set Ähnlich zu Series, wird aber als Einzelartikel behandelt (eine Artikel-nummer), ein Set kann in Subsets aufgegliedert sein, es gibt einen Haupttitel und optionale Untertitel als Composite, Produkte können wiederum zu mehreren Sets gehören

PR7 Title Title Composite aus Titel, Untertitel, Originaltitel bei Übersetzungen, früherer Titel, Kurzformen etc., Work Identifier, Websitereferenzen, Dissertationsausweisung

PR8 Authorship Contributor Composite führt Mitwirkende der Erstellung. Definiert Gruppen von Personen und Einzelpersonen, können eine Reihen-folge erhalten, Rollen und Namen zugewiesen bekommen, neben Titel, Beruf und Biografie kann eine Person auch die Zugehörigkeit zu einer Organisation erhalten, außerdem können Angaben zur Region und zu weiterführenden Informationen angehängt werden

PR9 Conference Konferenz(-en) mit der/denen das Produkt in Beziehung steht (Funk-tion, Name, Abkürzung, Nummer, Datum, Ort, bei Nutzung von Se-ries Thementitel), es können auch Angaben zu Sponsoren und weiterführenden Materialien hinterlegt werden

PR10 Edition Ausgabe (auch Braille und Großdruck spezifizierbar), Auflagen- und Versionsnummer, für religiöse Texte wurde ein eigenes Composite eingeführt

PR11 Language Spezifiziert die Sprache des Produktes und des Werkes aus dem es übersetzt ist, da Sprache im Message-Header spezifiziert werden kann, hier vorrangig für Überschreibung zu nutzen, auch Untertitel, Audiosprache etc. auszeichenbar

PR12 Extents and other content

Weiterführende Informationen, die nur auf manche Ressourcenfor-men zutreffen (z. B. Seitenzahl, Laufzeit von Audio + Dateigröße, Abbildungsaufführung, Kartenmaßstab)

PR13 Subject Laut ONIX-Standard nicht zwingend, dafür in der Praxis meistens zwingend, ein oder mehrere Hauptschlagwörter (BISAC oder ande-res Schema) mit Hauptkategorie, Kategorie und Version, weitere Schlagwörter auch aus anderen Schemas hinzufügbar, auch Perso-nen, Körperschaften und Orte können hier als Schlagwörter integ-riert werden

PR14 Audience Beabsichtigtes Publikum, ONIX-Code ist abgeleitet von BISAC und BIC, weitere Schemas einbindbar, Präzisierung durch genaues Al-ter, Schulform, Berufsausbildung etc.

PR15 Descriptions and other supporting

Beschreibende oder Bezug nehmende Texte zum Produkt (ToC, Reviews, Volltext etc.), für externe Links Angabe des Formats, Au-



text tors, Titels, Identifier etc. PR16 Links to image /

audio / video files Verlinkung auf enthaltene Medien unter Angabe des Typs, Format, Bildauflösung, Linktyp (URL, DOI), verlinkte Datei, zusätzliche Text-informationen für den Download, Dateiänderungsdetails und Websi-te zum Item

PR17 Prizes Preise und Auszeichnungen, die dem Produkt verliehen wurden, Angabe von Name, Jahr, Land, Platzierung und Jury

PR18 Content items Inhaltseinträge (Kapitel, Headings etc.), Nummerie-rung/Lesereihenfolge in der Hierarchie (beispielsweise 2.12.3), Text-eintragidenitifier, Gesamtseitenzahl, Start- und Endseite von Text-einträgen, Eintrag zu in Bezug stehender Website, Komponententi-tel, Mitwirkende, Schlagwörter, Personen, in Beziehung stehende Medien (Bilder, Audio, Video)

PR19 Publisher Konsistente Verlagsangaben auf Basis von Schemas, Name, Marke, Impressum, Verlage unter Angabe des validen Namens, der Rolle, weiterführende Website, Veröffentlichungsort

PR20 Publishing status, dates and copy-rights

Veröffentlichungs- und/oder Handelsstatus, Bekanntmachungsda-tum für die Öffentlichkeit, genaues Erscheinungsdatum, es können mehrere Copyrights als Composite angegeben werden, wobei ein Copyright Aussagen zum Jahr und Inhaber trifft

PR21 Territorial rights and other sales restrictions

Angaben für Verkaufsrestriktionen in bestimmten Län-dern/Territorien, dabei können einerseits die Rechte (Nicht-/Exklusivrechte) angegeben werden bzw. Verbote für den Verkauf, Angaben zu landesspezifischen Verlagen für äquivalente Produkte, zusätzlich können auch nicht territorialgebundene Verkaufsrestrikti-onen festgelegt werden, Angabe von Verkaufsstellen

PR22 Dimensions Maßangaben wie Höhe, Breite, Tiefe, Gewicht etc. unter Angabe der zugehörigen Einheit

PR23 Related products Zum Produkt in Bezug stehende Produkte, hierfür ist die Art der Beziehung (alternatives Format, Vorgänger, Übersetzung etc.), ein Identifier und die Form anzugeben

PR24 Supplier, availabil-ity and prices

Valide Anbieter mit Kontaktdaten und seinen Marktrechten. Anbieter können Verkaufsabteilung des Verlags, Dritte, die die Bestellvollzie-hung für den Verlag abwickeln, Großhändler oder andere Mittels-männer sein (Rollen), Angabe von Preis (pro Menge und für welchen Käuferkreis, Steuer), Bestellnummer, SAN (in UK und US), Rücknahmebedingungen, Verfügbarkeit, neue Anbieter bei Entfer-nung aus Sortiment, Lieferzeiten, vorrätige/bestellbare Quantität ggf. an entsprechenden Ort, Verpackungsquantität, Altersbeschränkun-gen, Bonus- und Rabattangebote, Neuauflageninformationen

PR25 Market representa-tion

Information über einen Handelsvertreter oder einen lokalen Heraus-geber (Agenturidentifier, Beziehung zum Produkt) in einem näher beschriebenen Markt (territoriales Gebiet, Marktrestriktionen, Pro-duktstatus, lokale Erscheinungstermine), kann insbesondere für importierte Produkte verwendet werden

PR26 Sales promotion information

Angaben zu Werbekampagnen, der entsprechenden Kontaktperson, Informationen zu Neuerscheinungen, Nachdrucken, Verkaufszahlen und Produktbeziehung über Buchclub

Tabelle A5: Beschreibung der Einträge des ONIX-Product-Record-Format 2.1 Revi-sion 03 In Tabelle A6 wird durch den Autor ein Bezug der Produkteinträge zu den definierten Metadatenklassen geschaffen. Deskriptive Metadaten PR1, PR2, PR5, PR6, PR7, PR8, PR9, PR10, PR13, PR14, PR15,

PR17, PR19, PR23 Struktur-Metadaten PR3, PR4, PR5, PR6, PR11, PR12, PR16, PR18, PR22, PR23 Administrative Metadaten PR8, PR10, PR20, PR22, PR23 Technische Metadaten PR4



Rechte-Management-Metadaten

PR20; PR21, PR24

Marketing- oder handelsspe-zifische Metadaten

PR24, PR25, PR26

Metadaten zur Langzeitar-chivierung

nicht abgedeckt

Tabelle A6: Zugehörigkeit der Produkteinträge zu den Arten von Metadaten Auch hier lässt sich trotz der klaren Trennung der einzelnen Produkteinträge sehen, dass eine eindeutige Zuordnung zu der eingeführten Klassifikation der Metadaten nicht immer möglich ist. Das Auftreten der in den Produkteinträgen enthaltenen Tags ist zum Teil zwingend und zum Teil optional. Die Restriktionen werden im Standard [OBP06] definiert, wo-bei vorweg genommen werden soll, dass das jeweilige Auftreten stark von der Tag-Kombination abhängig ist. Für fortlaufende Sammelwerke wie Zeitschriften existiert eine Familie von XML-Formaten für den Austausch von Informationen über Sammelwerke und deren Sub-skription. Subskription ist ein Verfahren für die Bestellungssammelmeldung eines Werkes, schon vor seinem Erscheinen (besonders bei mehrbändigen Werken). Für die Abnahmeverpflichtung erhält der Subskribent eine Ermäßigung von 10–20 % (Subskriptionspreis) des späteren Ladenpreises. Hierfür werden die Prinzipien und eine Reihe von Elementen aus ONIX for books wiederverwendet. Die Entwicklung wurde durch EDItEUR und NISO (US National Information Standards Organization) gemeinsam vorangebracht. Bislang gibt es drei Nachrichtenarten, die sich jedoch noch in Entwicklung befinden.

1. SPS (Serials Products and Subscriptions) is a format for communicating in-formation about serial subscription products, with or without price information, and optionally including subscription information relating to a particular sub-scriber.

2. SOH (Serials Online Holdings) is a format for communicating electronic serials holdings details from publication access management systems to user librar-ies.

3. SRN (Serials Release Notification) is a format for communicating information about the publication or electronic availability of one or more serial releases.

In SPS wird zwischen <PhysicalVersionScope> und <OnlineVersionScope> unter-schieden. Es können jeweils die Auflagendetails (Start-, Endauflage etc.) des Sam-melwerkes und die (Einzel-)Preise und deren Gültigkeitsbedingungen angegeben werden. Für die Online-Publikation können zusätzlich Informationen zum Hosting System, dem Online-Herausgeber, der Website über die ein Zugang zum Content ermöglicht wird und Paketdetails, die neben den Formaten auch Informationen zu der Art und Vollständigkeit von Einzelartikeln geben. SOH besteht aus vier Hauptbestandteilen: den Coverage Statements, Embargos, Angaben zu den zugehörigen Print Resources und Overall Holdings of a Content Hosting System. Das SRN-Format definiert Informationen über physische Publikationen oder elektro-nische Verfügbarkeit von Serials. Es können existierende Versionen und in der Zu-kunft zu veröffentlichende Releases ausgewiesen werden. Angaben zu enthaltenen Einträgen wie Artikeln sind neben der Gesamtbeschreibung möglich.



Diese Kurzbeschreibung der einzelnen Nachrichtentypen zeigt auf den ersten Blick Überschneidungen auf. Aus Sicht des Autors werden die bislang veröffentlichten ONIX-Standards für Sammelwerke (SPS 0.91, SOH 1.0, SRN 0.92) den Marktan-sprüchen noch nicht gerecht. Sie werden in dieser Arbeit nicht weiter verfolgt. Es soll jedoch darauf hingewiesen werden, dass zur Harmonisierung bereits erste Schritte unternommen werden. Das ONIX Serials Coverage Statement ist eine XML-Struktur, die für die Einbettung in die Nachrichtentypen vorgesehen ist. Das Covera-ge Statement dient insbesondere der einheitlichen Darstellung von Auflagechroniken. Dabei können bereits publizierte sowie in der Zukunft zu publizierende Auflagen be-schrieben werden. Außerdem ist es mittels „ONIX for Licensing Terms“ möglich, Lizenzbedingungen auszudrücken. Das Network Development and MARC Standards Office ist das verantwortliche Zent-rum für Standardisierung und Planungen im Umgang mit Metadaten der Library of Congress. Im September 2004 entstand im Rahmen dieser Arbeitsgruppe das ONIX to MARC 21 Mapping (http://www.loc.gov/marc/onix2marc.html). Dahinter verbirgt sich ein Stylesheet, was auf Basis von ONIX Release 2.1 aus dem Jahr 2003 eine Transformation in MARC 21 vornimmt. In der vorliegenden Version findet keine voll-ständige Transformation statt. So werden beispielsweise keine ONIX Composite Tags überführt. Mitunter gestaltet es sich auch schwierig, die Kompatibilität durch ein Mapping zwischen den beiden Standards zu schaffen. So existieren keine Möglich-keiten in MARC, Informationen zu verkaufsrelevanten Details zu hinterlegen. Nichts-destotrotz wird dieses offene Stylesheet an dieser Stelle genannt, da das Potential für zukünftige Anpassungen durchaus gegeben ist. Zusammenfassend ist festzuhalten, dass ONIX ein Metadatenformat mit extremer Marktnähe ist. Die Bedürfnisse der insbesondere kommerziell interessierten Organi-sationen werden in Bezug auf die wirtschaftliche und rechtliche Ebene abgedeckt. Auch auf deskriptiver Ebene macht das Format einen sehr guten Eindruck, obwohl von verschiedenen Seiten (u. a. vom Network Development and MARC Standards Office) die Kritik laut wird, dass ONIX den Bibliotheksansprüchen nicht gerecht wird. Nachholbedarf zur Vereinheitlichung besteht definitiv für die strukturelle Ausweisung von Sammelwerken. Auch müsste der Standard für die Erhöhung des Informations-gehaltes auf technischer Metadatenebene insbesondere in Hinblick auf Langzeitar-chivierung mit dritten Standards kombiniert werden.

A.7 XMetaDiss Die Deutsche Nationalbibliothek (DNB) und das Projekt „Dissertationen Online“ ent-wickelten ein spezielles Metadatenformat für Online-Hochschulschriften. XMetaDiss umfasst Hochschulschriften-spezifische Metadaten und wird als Austauschformat zwischen der DNB und Universitätsbibliotheken verwendet. XMetaDiss verwendet eine XML-Syntax und erlaubt seit Anfang 2005 die Metada-tenübertragung an die DNB mittels des OAI-PMH. Außerdem ist der Metadatensatz zu internationalen Standards kompatibel, was es erlaubt, Metadaten zu deutschen Online-Hochschulschriften in internationale Suchmaschinen einzubeziehen. Datenelemente in XMetaDiss basieren auf dem Dublin Core Metadata Element Set, wobei diverse Erweiterungen vorgenommen werden mussten, um dem vollen Anfor-derungsumfang gerecht zu werden. So wurde zusätzlich das Metadatenset der Net-worked Digital Library for Theses and Dissertations ETD-MS (Electronic Theses and



Dissertations Metadata Set), das Metadatenset zur Langzeitarchivierung auf Basis der New Zealands National Library Preservation Metadata und ein Set zur Erfassung von personenbezogenen Daten (XMetaPers) in XMetaDiss eingebunden. Für Metadaten zu Hochschulschriften, die an die DNB übermittelt werden, ist XMeta-Diss verbindlich für alle bereitstehenden Übertragungsverfahren. Während in Dublin Core die einzelnen Datenelemente fakultativ sind, sind in XMetaDiss die für den Ge-schäftsgang der DNB notwendigen Datenelemente obligatorisch. Prinzipiell ist der Verfasser der Hochschulschrift verpflichtet, bei der elektronischen Abgabe seiner Arbeit meist formulargestützt zugehörige Metadaten zur Publikation an seiner Uni-versitätsbibliothek anzugeben. Durch zuständige Mitarbeiter der Universitätsbiblio-thek werden die angegebenen Metadaten geprüft und weiterführend angereichert. XMetaDiss liegt seit 2003 in der Version 1.5 vor und deckt bislang ausschließlich die Beschreibung von Dissertations- und Habilitationsschriften ab. Bezüglich des Umfangs des formalen Metadatensatzes muss ein Hochschulschrif-tentitel enthalten sein, welcher mit einem Zusatz versehen werden kann. Des Weite-ren müssen Angaben zu Autoren beinhaltet sein. Die Angaben zu einem Autor bilden eine zusammengehörige Elementgruppe, die als Ganzes n-Mal wiederholbar ist und in der gegebenenfalls weiterführende Informationen zur Person und ihrem Werde-gang hinterlegt sein können. Bezüglich des Promotionsverfahrens sind Mitwirkende, wie Gutachter und Betreuer zu nennen, das Datum der Fertigstellung, Abgabe, An-nahme und Erstveröffentlichung der Pflichtexemplare aufzuführen. Außerdem ist für die Integration der Metadaten in den Geschäftsgang der DNB die Definition von Klassifikationen und Thesaurus notwendig. Hierfür müssen die DDC-Sachgruppen der Deutschen Nationalbibliografie angegeben werden bzw. können weitere klassifikatorische und/oder verbale Angaben zur Inhaltserschließung der Publikation hinterlegt werden. Zusätzlich können optional ein Inhaltsverzeichnis und ein Abstract integriert werden. In Hinsicht auf die Distribution der Hochschulschrift sind die verbreitende Stelle mit detaillierten Angaben und ein Abholort (URL) zu spezifizieren, um die Herkunft der Publikation wahren und den Transfer sichern zu können. Mittels des Publikationstyps werden die überwiegend enthaltenen Inhalte der elektronischen Ressource klassifi-ziert. Zudem sind das Dateiformat und die Größe für alle enthaltenen Dateien (falls es sich um ein Mehr-Dateien-Dokument handelt) anzugeben sowie Standards zu de-nen die Ressource konform geht. Da XMetaDiss lediglich zur Beschreibung von Dissertations- und Habilitationsschrif-ten gedacht war, wurde am Bibliotheksservice-Zentrum Baden-Württemberg für die Beschreibung und Übermittlung weiterer Publikationstypen aus Hochschulschriften-servern innerhalb des Südwestdeutschen Bibliotheksverbundes (SWB) eine Erweite-rung von XMetaDiss zu XMetaDissPlus vorgenommen. XMetaDissPlus ist mit Ausnahme der Erweiterung vollständig kompatibel und kongruent zu XMetaDiss. Neben Identifikatoren beschriebener Ressourcen sind in XMetaDiss auch Angaben über die Herkunft und Beziehungen zu anderen Ressourcen zu spezifizieren (wird benötigt von, ist Teil von, wird referenziert von, ist anderes Format etc.). Auch müssen in XMetaDiss rechtliche Bedingungen und Zugriffsrechte (für das Ur-sprungsexemplar in der Universitätsbibliothek und das Archivexemplar in der DNB) festgelegt werden.



In Bezug auf die Abdeckung der definierten Metadatenkategorien weist XMetaDiss durch die Einbeziehung externer Metadatenformate ein hohes Potential auf. Neben deskriptiven Metadaten können administrative Metadaten samt technischer Metada-ten und Metadaten zur Langzeitarchivierung definiert werden. Auch müssen Anga-ben zu Copyright und Zugriffsrechten als Rechte-Management-Metadaten hinterlegt werden. Das interne Management von Ressourcen spielt insbesondere bei Mehr-Dateien-Dokumenten eine Rolle. Struktur-Metadaten sind durch die Verwendung ei-nes definierten Containers für die Ressourcen ableitbar.

A.8 Extensible Metadata Platform (XMP) Extensible Metadata Platform (XMP) stellt ein durch Adobe publiziertes Standardfor-mat dar, was für die Erstellung, Verarbeitung und den Austausch von Metadaten vor-gesehen ist. Der Standard wurde entwickelt, um verschiedenen Applikationen einen gemeinsamen Zugriffspunkt auf den zu einer Datei zugehörigen Metadatensatz an-zubieten. XMP kann neben dem PDF-Format auch in TIFF, JPEG, JPEG 2000, GIF, PNG, HTML, AI (Adobe Illustrator), SVG/XML, PSD (Adobe Photoshop), PostScript bzw. EPS und DNG eingebunden werden.

For PDF files, the XMP Packet is embedded in a metadata stream contained (beginning with PDF 1.4). [XMP05]

Die Vorschrift zur Integration von XMP im jeweiligen Dateiformat wird in den entspre-chenden Spezifikationen der Formate erläutert. [XMP05] weist explizit darauf hin, dass die Definition der Begrifflichkeit Metadaten immer im Kontext des für das Dokument vorgesehenen Workflows betrachtet werden muss. So können beispielsweise eigentliche Inhaltsbestandteile wie die verwendeten Schriftarten auch nützliche Metadaten sein. XMP sieht ein Data Model und ein Storage Model für die Metadatenverarbeitung vor. Das zugrunde liegende Datenmodell ist ähnlich dem von Dublin Core. Es wird zur Beschreibung der Ressource (lediglich eine Datei, keine Aggregationen von Dateien) unter Zuhilfenahme von Property-Value-Paaren verwendet, die über Schemas in Be-ziehung stehen, welche zumeist auf einen speziellen Dateityp oder Workflow zuge-schnitten sind. Die Datentypen für die Values der XMP-Properties können prinzipiell in drei Basiska-tegorien aufgeteilt werden: Simple Types, Structures und Arrays [XMP05]. Ein Simple Type beinhaltet lediglich einen literal Value. Ein Structure Type kann mehrere Felder beinhalten, die in einer Bag gekapselt werden. Beispielsweise würde eine maximale Seitengröße aus Höhe, Breite und Maßeinheit bestehen. Ein Feld kann dabei auch selbst wieder ein Structure Type oder Array sein.

Abbildung A5: Beispiel für strukturierte Angaben in XMP



Der Unterschied zwischen Structure Type und Array liegt in der Tatsache, dass die Felder anstelle der Namen (wie stDim:w) nur mit einer Ordnungsnummer versehen sind. Arrays werden nach unordered (irrelevante Reihenfolge, beispielsweise Stich-wörter), ordered (relevante Reihenfolge, beispielsweise Autoren) und alternative (aus denen nur ein Value gewählt werden darf, beispielsweise Sprachalternativen) unter-schieden. Property Qualifiers stellen individuelle Property Values dar, die an Property Values der oberen Ebene angehängt werden können (Properties of Properties). Zum Bei-spiel können die Felder der dc:creator mit einem dc:role versehen werden, um die Rolle der einzelnen Mitwirkenden zu spezifizieren. Ein besonderer Property Qualifier ist der Language Qualifier (xml:lang), der konform zur RFC 3066 Notation ist und an eine Property mit einem String-Value angehangen wird. Dadurch ist es möglich, die entsprechend in einer Applikation voreingestellte Sprache dem Nutzer ausgeben zu lassen. Das Storage Model bestimmt, wie die zum Data Model konformen Daten physisch gehalten werden. Die XMP-Metadaten werden syntaktisch in einem XML-Stream se-rialisiert. Als Notation wird Resource Description Framework (RDF) verwendet. Die serialisierten Daten werden mit Hilfe von Packet Wrappern eingehüllt, um im zu-gehörigen File integriert zu werden. Dabei darf zu einer Ressource nur genau ein Packet existieren. Es wird für jedes Dateiformat eine unterschiedliche Verfahrens-weise genutzt. Es ist auch möglich, die Metadaten in einer separaten Datei zu spei-chern, allerdings entspricht dies nicht dem eigentlichen Konzept von XMP. Für die Serialisierung in XML ist das äußerste XML-Element (x:xmpmeta element) empfohlen aber laut Standard optional. Das bedeutet, dass der Metadatensatz direkt mit dem RDF-Element eingeleitet werden kann. Das RDF-Element beinhaltet ein oder mehrere rdf:Description-Elemente. Diese Elemente können für die Strukturie-rung von Elementen verwendet werden. Jedes Description-Element kann ein oder mehrere XMP-Properties enthalten. <x:xmpmeta xmlns:x='adobe:ns:meta/'> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:format>application/pdf</dc:format> <dc:title> <rdf:Alt> <rdf:li xml:lang="x-default">XMP - Extensible Metadata Platform</rdf:li> <rdf:li xml:lang="en-us">XMP - Extensible Metadata Platform</rdf:li> <rdf:li xml:lang="fr-fr">XMP - Une Platforme Extensible pour les Métadonnées</rdf:li> </rdf:Alt> </dc:title> <dc:subject> <rdf:Bag> <rdf:li>metadata</rdf:li> <rdf:li>schema</rdf:li> <rdf:li>XMP</rdf:li> </rdf:Bag> </dc:subject> </rdf:Description> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/"> <xmp:CreateDate>2002-08-15T17:10:04Z</xmp:CreateDate> </rdf:Description>



<rdf:Description> … </rdf:Description> </rdf:RDF> </x:xmpmeta>

In einer RDF-Description werden alle Metadaten zu ein und demselben Namespace mit identischen Präfixen hinterlegt. Der entsprechende Namespace wird dabei als Attribut angegeben. XMP umfasst ein Subset von RDF, für Detailinformationen sei der Leser auf [XMP05] verwiesen. Beispielsweise wird das about-Attribut nicht für die Identifikation der Res-source verwendet. Der XMP Packet Wrapper ermöglicht die Nutzung der XMP-Metadaten durch Soft-ware, die das Format der Datei selbst nicht versteht. Durch den Einsatz von Markern ist die Software in der Lage, den Metadatensatz zum Beispiel in Bytecode zu erken-nen und ihn somit weiterzuverarbeiten oder anzupassen. Ein Wrapper kann prinzi-piell mehrere Packets enthalten, wovon jedoch nur eines den aktuellen Stand des Files ausweist. <?xpacket begin="…" id="W5M0MpCehiHzreSzNTczkc9d"?> … <?xpacket end="…"?>

Schemas sind vordefinierte Sets von Metadata-Property-Definitionen, die in XMP standardmäßig zugelassen sind und einen Großteil notwendiger Semantik abdecken. Diese Schemas sind erweiterbar, sollten jedoch aus Interoperabilitätsgründen in der empfohlenen Form verwendet werden. Verwendete Schemas sind:

Dublin-Core-Schema (DCMI Element Set) XMP-Basic-Schema: Basisinformationen (u. a. URL, Datumsangaben der Er-

stellung und Änderung des Dokumentes sowie des Metadatensatzes, Identi-fier, Autorenwerkzeug)

XMP-Rights-Management-Schema: Rechtemanagement (u. a. Rechte-existenz, Online-Zertifikat, Besitzer, Nutzungsbedingungen)

XMP-Media-Management-Schema: für Digital-Asset-Management-Systeme, kurz DAM (u. a. Referenz zum Original, Historie, Version, Angaben zum Ma-nagementsystem und dem Management der Ressource)

XMP-Basic-Job-Ticket-Schema: Workflowinformationen (Verweis zu Jobanga-ben)

XMP-Paged-Text-Schema: Erscheinungsbild (von Text) im Dokument (u. a. Seitengröße und -anzahl, verwendete Schriftarten und Farben, Angaben für Platzhalter)

XMP-Dynamic-Media-Schema: spezifiziert Properties, die von der Adobe Dy-namic Media Group genutzt werden (u. a. Videoframerate und -größe, Pixel- und Farbinformationen, Audioinformationen, Kompression, Zeitangaben – z. B. zur Aufnahme sowie Modifikation, Genre, Copyright)

Adobe-PDF-Schema: speziell in PDFs verwendete Properties (Stichworte, PDF-Version, Produzent)

Photoshop-Schema: Metadaten für in Photoshop erzeugte Grafiken Camera-Raw-Schema: spezifiziert Properties für Bilder im Camera Raw Mode

(basiert auf DNG - Digital Negative Format)



EXIF-Schemas: Metadatenstandard für die Beschreibung von Bilddateien, wird in vielen Digitalkameras eingesetzt

Die aufgeführten Schemas sind Kernschemas. Für Properties sollte immer zuerst versucht werden, entsprechende Einträge in diesen Schemas zu finden. Falls das nicht der Fall sein sollte und die Anwendung auf diese Informationen angewiesen ist, kann man eigene Custom-Schemas entwickeln. Der große Vorteil von XMP liegt neben der Erweiterbarkeit in der Einbettung der Me-tadaten in den Ressourcen. Die Erweiterbarkeit um eine Vielzahl von standardisier-ten Metadatensätzen ruft bei dementsprechend getroffenen Absprachen zwischen Organisationen (vom Produzent bis zum Konsument) ein hohes Potential für im Do-kumentenverarbeitungsprozess befindliche Applikationen hervor. Somit wäre auch eine komplette Abdeckung der definierten Metadatenklassen denkbar. Die Einbet-tung der Metadaten in den Ressourcen sichert die Aufrechterhaltung und stetige An-passung bei Objektveränderungen. Aus den integrierten Metadaten können nicht nur Informationen für Katalogsysteme gewonnen werden, sondern auch Informationen aus dem Katalog in die Ressource zur Qualitätsaufwertung zurückgeschrieben wer-den.

A.9 Metadaten zur Langzeitarchivierung Der Grundgedanke, warum Metadaten zur Langzeitarchivierung spezifiziert werden, liegt in der Tatsache, dass ein Archivierungssystem Methoden zur Langzeitarchivie-rung (Emulation und Migration) einer Ressource bereitstellen muss. Die Metadaten sollen einen Ausgangspunkt für die Entscheidungsfindung bieten.

Für eine funktionstüchtige Strategie zur Langzeitarchivierung elektronischer Dokumente ist die Erfassung von geeigneten technischen Metadaten unerläss-lich. [DNB08]

Langzeitarchivierungsmetadaten sind nicht für die Katalogisierung vorgesehen, son-dern für die administrative Aufrechterhaltung und Zugänglichkeitsgewährung der im Repository befindlichen Ressourcen. Somit werden die Metadaten auch nicht im Ka-talog, sondern im Depotsystem abgelegt. An dieser Stelle soll auch erwähnt werden, dass eine Langzeitarchivierung nur unter Einverständnis des Autors bzw. des Verlages durchgeführt werden darf. Nähere In-formationen finden sich hierzu im DINI-Zertifikat Dokumenten- und Publikationsservi-ce 2007.

A.9.1 Preservation Metadata: Implementation Strategies (PREMIS) Preservation Metadata: Implementation Strategies (PREMIS) wurde 2003 mit Unter-stützung der Research Libraries Group (RLG) und des Online Computer Library Cen-ter (OCLC) gegründet. Im Rahmen von PREMIS steht die Standardisierung von Vorgehensweisen zur Langzeitarchivierung in digitalen Archivierungssystemen im Vordergrund. Dabei wer-den insbesondere alternative Strategien für die Erstellung und Nutzung von Enco-dings sowie der Speicherung und dem Management von Langzeitarchivierungs-metadaten untersucht. PREMIS baut hierfür auf den Ergebnissen der Preservation Metadata Working Group (PMWG) auf.



Das in PREMIS veröffentlichte Framework kann als eine Umsetzung der Metadaten-konzepte gemäß dem OAIS Reference Model angesehen werden. Die erarbeiteten Metadaten sind an deren Strukturen des Archivierungsprozesses angepasst. Das Kernset an Langzeitarchivierungsmetadaten, welches im Data Dictionary fest-gehalten ist, beinhaltet notwendige Informationen für die Aufbewahrung von digitalen Objekten im Repository. Es wird ein besonderer Wert auf Angaben zur Existenzfä-higkeit (viability), zur Darstellbarkeit (renderability), zur Verständlichkeit (understan-dability), zur Authentizität (authenticity) und zur Identität (identity) gelegt. Kernmetadaten bedeutet in diesem Zusammenhang, dass die Metadaten auf jedes Objekt anwendbar und in jedem Repository verwendbar sind. Natürlich gibt es auch hier Ausnahmen, da diverse Metadaten auf vereinzelte Ressourcen nicht anwendbar sind. Des Weiteren spielen Angaben zur Herkunft und Historie des digitalen Objektes (Provenance Metadaten), die originale sowie aktuell nutzbare technische Umgebung und Rechte-Metadaten für Zugriffsberechtigungen eine große Rolle. Auch sind Struk-tur-Metadaten für Zusammengehörigkeiten von Ressourcen und Teilen von ihnen einbezogen. All diese Metadaten dienen der Entscheidung für adäquate Langzeitarchivierungsme-thoden. Nach der Revision der ersten Auflage des Standards wurde 2007 das überarbeitete PREMIS Data Dictionary for Preservation Metadata in der Version 2.0 eingeführt. Das PREMIS Data Dictionary wurde bereits 2005 im Rahmen des Digital Preservati-on Awards und 2006 beim Society of American Archivists Preservation Publication Award ausgezeichnet. Die meisten Metadaten können maschinell und damit automatisch zu den Ressour-cen hinzugefügt werden und somit einen normgerechten und hoch effizient erhobe-nen Datensatz anbieten. Das Data Dictionary ist allerdings datenstrukturunabhängig und orientiert sich am im Framework enthaltenen Datenmodell. Das zugrunde liegende Datenmodell unter-scheidet fünf Entitäten.

Abbidlung A6: PREMIS Data Model [PRE07] Die Karrees stellen die fünf verschieden Entitäten und die Pfeile die Beziehungen zwischen den Entitäten dar. Die Intellectual Entity ist ein Satz von Inhalten, die aus Gründen des Managements und der Beschreibbarkeit als ein Gesamtobjekt gesehen wird. Eine Intellectual Entity



kann dabei andere Intellectual Entities beinhalten und kann eine oder mehrere digita-le Repräsentationen besitzen. Das Object entspricht einer Ressource, wobei es eine Einheit von digitalen Ressour-cen (Aggregation) oder eine Einzelressource sein kann. Ein Object hat wiederum drei Untertypen von Entitäten. Für technische Metadaten kommen File (Bytesequenz mit Charakteristika wie Format, Größe, letzte Modifikation etc.) und Bitstream (bestimmte Daten im File, beispielsweise die Audiospur in einem Video) zum Einsatz. Für das akkurate Rendering werden Struktur-Metadaten in der Representation Entität ver-wendet. Eine Event-Entität ist eine Aggregation von Metadaten über Aktionen im Repository. Hierzu gehören Modifikationen von digitalen Objekten in Kombination mit Schlüssel-elementen für die Herkunftsnachvollziehung, Beziehungserstellungen und Bezie-hungsänderungen, sogar Aktionen die lediglich Validierungen und Integritätchecks durchführen. Aus statistischen Gründen sind auch Distributionsanfragen für ein Sys-tem relevant. Prinzipiell unterscheidet man bei der Identifikation zwischen linkingE-vent-Identifier bei Events, die sich auf ein Objekt beziehen (z. B. bei Validierung) und relatedEventIdentification wenn ein Event zwei Objekte miteinander verbindet (z. B. durch Migration). Außerdem wird das Ergebnis der durchgeführten Aktion im Event gespeichert. Ein Agent kann eine Person, Organisation oder Software sein. Diese werden jedoch mittels des Data Dictionaries nicht näher beschrieben. Es wird nur ausgedrückt, dass ein Agent ein Event auf einem Objekt ausgeführt hat bzw. mit Rechten zu einem Ob-jekt versehen ist. Rights sind Geltendmachungen von einem oder mehreren Rechten bzw. Zugriffsges-tattungen zu einem Objekt und/oder Agenten. Die PREMIS Rights-Statements sind jedoch hauptsächlich dafür vorgesehen, Repositories die Möglichkeit zu gewähren herauszufinden, ob Aktionen automatisch ausgeführt werden dürfen. Das PREMIS Data Dictionary definiert Semantic Units, die es ermöglichen, die im Modell beschriebenen Konzepte zu kodieren und im Repository zu hinterlegen. Eine Semantic Unit des Data Dictionary bezieht sich auf eine Entität. So ist eine Semantic Unit eine Art Property zur Beschreibung der Entität. Ein Beispiel wäre die Größe ei-nes Objektes, die durch eine Sematic Unit, d. h. als Property ausgedrückt und durch einen enthaltenen Value untersetzt wird. Die Semantic Units haben unabhängig von der Entität eine einheitliche Syntax und Struktur. Im PREMIS Data Dictionary sind Semantic Units für Objekte, Events, Agenten und Rechte spezifiziert. Für die Intellectual Entity ist keine Abdeckung integriert worden, da diese durch eine Vielzahl von deskriptiven Metadaten hervorragend abgedeckt ist. Instanzen von Object, Event, Agent und Right Statements werden über einen struktu-rierten Identifier erkannt. Die Sicherung der Persistenz des Identifiers ist Aufgabe des Repositories und wird nicht durch das Data Dictionary spezifiziert. Objekte und Agen-ten dürfen multiple Identifier haben. Die Identifier können für die Etablierung von Be-ziehungen zwischen Objekten verwendet werden. Für die Beziehung zwischen Semantic Units einigte man sich nach längerer Recher-che von existierenden Beziehungsdefinitionen auf drei Basisgruppen: Strukturbezie-hungen (Struktur der Objektteile), Ableitungsbeziehung (Ergebnis von Replikation oder Transformation) und Abhängigkeitsbeziehungen (ein Objekt benötigt ein ande-



res Objekt wie CSS, DTD etc. zur Unterstützung seiner Funktion, Auslieferung oder Inhaltszusammengehörigkeit). Für die Anwendung der im Data Dictionary spezifizierten Semantic Units sei der Le-ser auf [PRE07] hingewiesen. Zur Unterstützung der Implementierung des Data Dic-tionary in digitalen Repositories veröffentlichte die Working Group auch eine Reihe von XML-Schemas. Mit der Version 2.0 des PREMIS Data Dictionary wurde durch die PREMIS Maintenance Activity der Library of Congress ein Mechanismus etabliert, über den kontrollierte Vokabulare registriert werden können. Diese können durch die Semantic Units verwendet und in die PREMIS-Schemas eingebunden werden. Auch werden von der PREMIS Community Empfehlungen für die praktische Integra-tion der Konzepte in Langzeitarchivierungssysteme gegeben. Zusätzlich existieren vereinzelte Semantic Units zur Erweiterbarkeit und somit auch zur Integration PREMIS-fremder Metadaten.

A.9.2 Langzeitarchivierungsmetadaten für elektronische Ressourcen (LMER) Da nur bedingt Metadatenschemas existierten, die speziell den Bedürfnissen der Langzeitarchivierung gerecht wurden, entwickelte man in der Deutschen Nationalbib-liothek (DNB) im Jahre 2005 einen eigenen Standard. Langzeitarchivierungsmetada-ten für elektronische Ressourcen (LMER) setzen auf den Ansätzen von PREMIS sowie dem Preservation Metadata: Metadata Implementation Schema der National Library of New Zealand auf. Das Schema dient als Basis für das Datenmodell. Auf syntaktischer Ebene wird in LMER auf XML gesetzt. Somit kann LMER als allein stehendes Austauschformat wie auch als Bestandteil anderer XML-Formate in einer großen Vielfalt nachgenutzt werden. Um die Integration in andere Archivierungs- und Austauschformate zu optimieren, wurde ein Modularisierungskonzept verfolgt. Ein Kern von Metadaten (eigentliches LMER) deckt übergreifend alle Dateiarten ab, wohingegen technische Metadaten zu bestimmten Dateiarten in einem extra Feld (xmlData) gehalten werden. In diesem Feld können beliebige technische Metadaten eines anderen Schemas aufgenommen werden. Diese technischen Metadaten spezifizieren u. a. eine Systemumgebungsbeschrei-bung zur Dateiart und der zu ihr kompatiblen Hard- und Software. Die technischen Metadaten zu den bestimmten Dateiarten sollten von LMER unabhängig sein und sind daher in einem separaten Modul abgelegt. Auch die Erlangung dieser Metada-ten sollte durch ein zentrales und internationalisiertes File Format Registry System unterstützt werden. Die dort abgelegten Metadaten würden somit die zu den Dateiar-ten, d. h. dem Dateityp und der Dateiversion, kompatible Systemumgebung ausge-ben können. LMER ist durch seine Syntax in beliebige XML-basierte Metadatenstandards integ-rierbar. Allerdings ist bei der Kombination der Formate immer Obacht auf Über-schneidungen der Metadateninformationen zu geben. In [LMER05] wird am Beispiel der Integration von LMER in Metadata Encoding and Transmission Standard (METS) eine Empfehlung ausgesprochen, redundante Daten zu vermeiden und diese aus-schließlich im Hauptformat, in diesem Falle METS, zu integrieren und nichtredundan-te Daten aus dem Hauptformat heraus zu referenzieren. Analog zum Metadata Implementation Schema von Neuseeland gliedert sich LMER in:



1. Objekt: Metadaten, die sich übergreifend auf alle Ressourcen (Teildateien) ei-nes Objektes (Aggregation) beziehen (Objektidentifier und -bezeichnung, URN als Persistent Identifier zu den bibliografischen Metadaten, Basis-URL des Ob-jektes, registriertes Format, Checksumme, Gruppenzugehörigkeiten, Objekt-version, zeitliche Angaben zu Objekt und Metadaten, Ersteller, Einstiegsdatei, Dateianzahl, Status, Kommentar).

2. Prozess: Metadaten zu technischen Veränderungen an einem Objekt oder einzelnen Datein. Ein Prozess ist entweder ein Unterabschnitt von Objekt oder von Datei und kann in diesen jeweils mehrfach vorkommen. Für jede Ände-rung gibt es einen eigenen Prozess-Abschnitt (Informationen zum alten Objekt und den alten Metadaten, Veränderungsgrund, -schritte und –genehmigung, Ergebnisstatus, Kommentar).

3. Datei: Metadaten für jede Datei des Objektes. Die Charakteristiken setzen sich aus allgemeinen Feldern (für jeden Dateityp gleich) und aus spezifischen (z. B. die Framerate für Videos - zumeist aus anderen Schemas) zusammen. Für jede zum Objekt gehörende Datei gibt es einen eigenen Datei-Abschnitt. (Da-teiidentifier, -größe, -bezeichnung, Erstellungsdatum, relatives Verzeichnis im Objekt, Checksumme, Format mit MIME-Typ und Referenz zu Datenbank, Au-torenwerkzeug, Viewer, Verweise zu anderen (abhängigen) Dateien des Ob-jektes - linkedTo, Kommentar, Kategorie, xmlData - zu Kategorie gehörige technische Metadaten, die jedoch über nicht-LMER-Schemas definiert sind).

4. Metadaten Modifizierung: Protokollierung der Veränderungen von LMER-Metadaten. Es werden keine Änderungen in Metadaten berücksichtigt, die sich nicht in der gleichen Datei befinden. (Änderer, Zeitpunkt, modifiziertes Feld, Werte vor der Änderung, Kommentar).

Der Standard stellt eine Reihe von Metadaten für die Langzeitarchivierung bereit. Die Entscheidungsfindung für die passende Methode (Emulation oder Migration) liegt immer beim Menschen, kann aber durch die Dokumentenerstellungsgeschichte ma-schinell beeinflusst werden. Für Emulationen ist aus Sicht des Autors der notwendige Informationsbedarf, insbe-sondere durch das in Beziehung stehende File Format Registry System und deren Umgebungsbeschreibung, gegeben. Allerdings stellt sich in Betracht der Migrationen die Frage, ob der Standard an dieser Stelle eine ausreichende Abdeckung bietet. Zumeist verursacht Migration ein verlustbehaftetes Ergebnis [BOR06]. Bei der Migra-tion können Inhalts-, wie auch Formatierungsinformationen verloren gehen. Die Hoff-nung ist aber, dass mit zukünftigen Migrationsstrategien eine Ressourcenaufwertung erreicht werden kann. LMER bietet aus Sicht des Autors allerdings nicht genügend Optionen, um diese Differenzierungen zwischen Versionen exakt genug vornehmen zu können.

A.10 Metadata Encoding and Transmission Standard (METS) Der Metadata Encoding and Transmission Standard (METS) ist ein weiterer XML-basierter Standard, der durch das Network Development and MARC Standards Of-fice der Library of Congress entwickelt wird. Der Standard deckt deskriptive und ad-ministrative Metadaten sowie Struktur-Metadaten zur Ressourcenbeschreibung in digitalen Bibliotheken ab.



METS ist außerdem eine Initiative der Digital Library Federation. METS kann für die Unterstützung der Verwaltung von Objekten in einer digitalen Sammlung sowie auch für den Austausch solcher Objekte mit anderen Sammlungen (oder der Übermittlung an Endnutzer) verwendet werden. Ein METS-Dokument kann zudem im Kontext des OAIS Reference Model für die langfristige Erhaltung digitaler Aufzeichnungen entwe-der als Liefereinheit (Submission Information Package - SIP), Archivierungseinheit (Archival Information Package - AIP) oder Bereitstellungseinheit (Dissemination In-formation Package - DIP) eingesetzt werden [MEN05]. Der Vorteil von METS liegt in der detaillierten Aufführung der Struktur von Aggregati-onen und ihren Ressourcen. Hierfür wird einerseits ihr Ablageort festgehalten und zueinander in Beziehung gesetzt, und auf der anderen Seite können deskriptive Me-tadaten, die beispielsweise in anderen Formaten aufgenommen wurden, zu den Ressourcen oder sogar nur zu Teilen von ihnen in Bezug gebracht werden. METS als offener Standard wurde aus der Bibliotheksszene heraus ins Leben geru-fen, was seine Praxistauglichkeit untersetzt. Die zugrunde liegenden Konzepte der Modularität und Erweiterbarkeit spielen sich gegenseitig zu, da durch die Integration dritter normierter Metadatensätze in Form von Modulen eine extreme Mächtigkeit des Formates entsteht. Die technischen Metadaten in METS sind insbesondere auf die Ansprüche der Lang-zeitarchivierung in einem digitalen Archiv abgestimmt. Sie sollen dabei den Betreiber unterstützen, die entsprechende Langzeitarchivierungsstrategie zu finden und den Migrationsverlauf zu dokumentieren [MEN05]. Bei einem genaueren Blick auf den Aufbau von METS lässt sich dieses Bild verdeut-lichen. Ein METS-Dokument besteht laut [MEN05] aus 7 Hauptabschnitten:

1. Kopfteil (METS Header): Enthält Metadaten, die das jeweilige METS-Dokument selbst beschreiben, einschließlich der Angaben zum Bearbeiter oder Herausgeber des METS-Dokumentes

2. Deskriptive Metadaten: Abschnitt kann Verweise auf ein externes Dokument (z. B. MARC-Datensatz), wie auch in das METS-Dokument eingebettete An-gaben oder beides enthalten. Es können auch mehrere externe und interne Erschließungspakete verwendet werden.

3. Administrative Metadaten: Abschnitt liefert Informationen über die Herstellung und Speicherung von Dateien, über Urheberrechte und über die digitalisierte Vorlage. Außerdem werden hier Angaben zur Herkunft der Digitalisate erfasst (z. B. Master-Derivat-Verhältnis sowie Migrationsverlauf). Die administrativen Metadaten können extern oder in das METS-Dokument integriert werden.

4. File Section: Auflistung aller Dateien mit Inhalten des digitalen Objektes (Ag-gregation). Zusammengehörige Dateien werden als zusammengehörig aus-gewiesen und gegenüber alternativen Objektversionen abgegrenzt.

5. Structural Map: Bildet den inneren Aufbau des digitalen Objektes ab und ver-knüpft Strukturelemente mit Dateien, aus denen der Inhalt des digitalen Objek-tes besteht, sowie mit deren Metadaten.

6. Strukturverknüpfungen (Structural Links): Erlaubt es den Erstellern von METS-Dokumenten das Vorhandensein von Hyperlinks zwischen einzelnen Knoten des im Strukturabschnitt dargestellten hierarchischen Aufbaus des digitalen Objekt zu beschreiben. Diese Funktion ist besonders für die Archivierung von Webseiten gedacht.



7. Verhalten (Behavior): An dieser Stelle können ausführbare Aktionen mit den Inhalten in METS-Objekten verknüpft werden. Hierfür werden Verhaltens-Elemente und deren Schnittstellen definiert. Das Mechanism-Element wird da-zu verwendet, auf ein Modul mit ausführbarem Programmcode zu verweisen.

Detailinformationen zu den Elementen der vorgestellten Abschnitte sowie deren Verwendung im METS-Dokument finden sich auf der Library of Congress Website im vordefinierten XML-Schema von METS [METS08]. Zusätzlich wird eine Reihe von Extension-Schemas für METS empfohlen. Für den Einsatz deskriptiver Metadaten wird Dublin Core, MODS, MARCXML und VRA Core vorgeschlagen, wobei an dieser Stelle natürlich genauso gut auch eine Referenz auf einen binären Datensatz wie PICA gesetzt werden kann. Für administrative Metada-ten werden textMD, NISO Metadata for Images in XML (NISO MIX) und Schemas für PREMIS empfohlen. Des Weiteren existieren Schemas für audiovisuelle Inhalte, Rechtemanagement und Ankündigungen. TextMD ist ein XML-Schema, was detaillierte technische Metadaten für textbasierte digitale Objekte bereitstellt. Hierfür sind Properties zur Encoding-Information (Quali-tät, Plattform, Software, Agent), Character-Information (Zeichensatz und -größe, By-tereihenfolge und -größe, Zeilenenden), enthaltenen Sprachen und Schriften, Markup-Information, processing and textual notes, technischen Anforderungen für den Druck und die Darstellung am Computer sowie Seitenreihenfolge und Ab-laufsteuerung definiert. Das METS-Abstract-Model sowie die XML-Serialisierung gemäß des METS-XML-Schema stellen lediglich die Minimalanforderungen dar, welche für den jeweiligen Anwendungsfall angepasst werden müssen. Die Verwendung von Extension Sche-mas sollte genauso dokumentiert werden wie die Nutzung optionaler Elemente und Attribute in METS. Das METS-Profile-Schema bietet eine standardisierte Möglichkeit eine solche Dokumentation zu erstellen, in dem sie eine Grobstrukturierung vorgibt und sicherstellt, dass alle wesentlichen Bereiche eines METS-Dokuments in der Do-kumentation berücksichtigt werden. [NEU07]. Durch den Einsatz von Profilen soll es Entwicklern und Autoren erleichtert werden, METS in ihre Systeme zu integrieren. Auf der offiziellen METS-Homepage ist eine Vielzahl verifizierter METS-Profile veröf-fentlicht. Diese umfassen Vorgaben zur Beschreibung verschiedenster Medien mit zumeist standardisierten Strukturen und vorgegebenem Vokabular. Nach dieser kurzen Einführung in METS verdeutlicht sich bereits, dass METS Quali-täten zur Vereinigung aller Arten von Metadaten für digitale Ressourcen aufweist. Als Metadatencontainer ist es nicht nur für die Langzeitarchivierung hervorragend geeig-net, sondern bietet auch eine Unterstützung bei der Metadaten- und Ressourcenver-teilung.

A.11 XML Formatted Data Unit (XFDU) Die Idee hinter XML Formatted Data Unit (XFDU) stammt wie auch das OAIS Refer-ence Model aus dem Consultative Committee for Space Data Systems (CCSDS). XFDU stellt eine Empfehlung bereit, die beschreibt wie Daten, Metadaten und zuge-hörige Software in einem Information Package gemäß dem OAIS Reference Model gekapselt werden können, um den Informationstransfer und die Archivierung zu op-timieren.



Eine XFDU ist auf den ersten Blick nur ein Package Interchange File (Manifest und Dateien in einer Kapsel). Dateien und XFDUs können allerdings auch außerhalb des Package Interchange Files als referenzierte Objekte einbezogen werden. Die XFDU kann somit physisch als ein ZIP-Archiv vorliegen und extern referenzieren, wodurch die referenzierten Elemente auch zur eigentlichen XFDU gehören. Das bedeutet die XFDU wird insgesamt als logische Entität gesehen.

The term 'XML Formatted Data Unit' or 'XFDU' is to be understood as referring to not only the Package Interchange File and those files contained within, but also to all the external files and packages referenced from within the included Manifest file. [XFDU07]

Anhand der folgenden Darstellung soll dieses Prinzip illustriert werden.

Abbildung A7: Konzeptuelle Sicht auf eine XFDU Das Manifest Document beschreibt die Beziehungen zwischen Dateien und weist ihre Position im Package Interchange File oder externe Referenzen aus. Die Dateien können wiederum Daten oder Metadaten enthalten. Das Manifest selbst kann eben-falls Daten- und Metadatafiles enthalten. Die XFDU, der Package Interchange File und das Manifest sind laut Spezifikation High-Level-Entitäten. Wenn man sich nun die Implementierung eines XFDU Manifestes anschaut, zeigt sich das zugrunde liegende logische Konzept eines XFDU Package bzw. Package Interchange Files. Der Package Header eines Manifests enthält Metadaten zum ge-samten XFDU Package (deskriptive, administrative und technische Metadaten). Die Information Package Map beschreibt die innere Hierarchie des XFDU Package. Die Hierarchie bildet sich über die Schachtelung so genannter Content Units. Content Units beinhalten Pointer zu Data Objects und zu deren zugehörigen Metadaten. Des Weiteren ist eine Content Unit in der Lage auf eine externe XFUD zu referenzieren. In der Data Object Section werden alle Data Objects gelistet. Vorrangig ist das die Referenz auf die entsprechenden Dateien und ihre Bytestreams. Zusätzlich können Informationen über deren Validierung und Transformation hinterlegt werden. In der Metadata Section können die Metadaten zu allen Items des XFDU Package global gehalten werden oder durch die Referenzierung einzelner Metadata Objects für se-parate Items (Content Units, Data Objects) spezifiziert werden. Die vorgegebenen Metadaten sind an das OAIS Reference Model angelehnt, wobei in der Spezifikation keine Aussagen über die Erweiterbarkeit entsprechend etablierter Standards ge-macht werden. Zu jeder Content Unit können außerdem in der Behavior Section eine



Sammlung von Verhaltensobjekten angelegt werden, die als Aktionen auf der Con-tent Unit ausführbar sein sollen. Die XFDU-Empfehlungen liegen derzeit noch als Red Book vor. Die Fertigstellung und Überführung in ein Blue Book sind noch nicht abzusehen. Aufgrund der mangel-haften Ausführung der Empfehlungen sollen sie an dieser Stelle nur erwähnt werden und bei den Betrachtungen in dieser Arbeit nicht praktisch einfließen.



B DAISY-Metadaten B.1 Metadaten in Digital Talking Books gemäß ANSI/NISO Z39.86-2005

B.1.1 Publikationsmetadaten in OPF Präfix Label Schema Auftreten

dc title - obligatorisch

dc creator - obligatorisch (wenn ein Autor bekannt ist)*

dc subject - optional - empfohlen dc description - optional* dc publisher - obligatorisch dc contributor - optional* dc date ISO 8601 obligatorisch

dc type Dublin Core Type Vocabulary optional*

dc format - obligatorisch dc identifier - obligatorisch dc source ISBN optional - empfohlen dc language ISO 639-1/ISO 3166 obligatorisch* dc relation - optional* dc coverage - optional* dc rights - optional* dtb sourceDate ISO 8601 optional - empfohlen dtb sourceEdition - optional - empfohlen dtb sourcePublisher - optional - empfohlen dtb sourceRights - optional - empfohlen

dtb sourceTitle - optional (obligatorisch falls der Originaltitel ab-weichend ist)

dtb multimediaContent Structure Guide obligatorisch dtb multimediaType RFC2046 obligatorisch dtb narrator - optional - empfohlen* dtb producer - optional - empfohlen* dtb producedDate ISO 8601 optional dtb revision - optional dtb revisionDate ISO 8601 optional dtb revisionDescription - optional dtb totalTime SMIL clock obligatorisch dtb audioFormat - optional - empfohlen*

Tabelle B1: DTB-Metadaten im OPF-File gemäß ANSI/NISO Z39.86-2005 * = diese Elemente können mehrmals auftreten

B.1.2 Metadaten in SMIL Präfix Label Schema Auftreten

dtb uid - obligatorisch dtb generator - optional



dtb totalElapsedTime SMIL clock optional - empfohlen

Tabelle B2: DTB-Metadaten in SMIL-Dateien gemäß ANSI/NISO Z39.86-2005

B.1.3 Navigationsmetadaten im NCX Präfix Label Schema Auftreten

dtb uid - obligatorisch dtb depth - obligatorisch dtb generator - optional - empfohlen dtb totalPageCount - obligatorisch dtb maxPageNumber - obligatorisch

Tabelle B3: DTB-Metadaten im NCX-File gemäß ANSI/NISO Z39.86-2005

B.2 Metadaten in DAISY 2.02 Dokumenten

B.2.1 Metadaten in NCC.HTML Präfix Label Schema Auftreten

ncc charset - obligatorisch dc contributor - optional* dc coverage - optional*

dc creator - obligatorisch (wenn ein Autor bekannt ist)*

dc date ISO 8601 obligatorisch ncc depth - optional - empfohlen dc description - optional* ncc files - optional - empfohlen

ncc footnotes - obligatorisch (wnn Fußno-ten verwendet werden)

dc format - obligatorisch ncc generator - optional - http-equiv - optional dc identifier - obligatorisch ncc kByteSize - optional dc language ISO 639-1/ISO 3166 obligatorisch* ncc maxPageNormal - optional - empfohlen ncc multimediaType - optional - empfohlen ncc narrator - optional - empfohlen* ncc pageFront - obligatorisch ncc pageNormal - obligatorisch ncc pageSpecial - obligatorisch

ncc prodNotes - obligatorisch (wenn durch den Produzenten Anmer-kungen hinterlegt sind)

ncc producedDate ISO 8601 optional ncc producer - optional dc publisher - obligatorisch dc relation - optional* ncc revision - optional ncc revisionDate ISO 8601 optional dc rights - optional* ncc setInfo k of n obligatorisch (wenn sich



ein DTB über mehrere Trägermedien erstreckt)

ncc sidebars - obligatorisch (wenn Side-bars verwendet warden)

dc source ISBN optional - empfohlen ncc sourceDate ISO 8601 optional - empfohlen ncc sourceEdition - optional - empfohlen ncc sourcePublisher - optional - empfohlen ncc sourceRights - optional

ncc sourceTitle - optional (obligatorisch falls der Originaltitel ab-weichend ist)

dc subject - optional - empfohlen* dc title - obligatorisch ncc tocItems - obligatorisch ncc totalTime hh:mm:ss obligatorisch dc type - optional*

Tabelle B4: DTB-Metadaten im NCC-File gemäß DAISY 2.02 Spezifikation * = diese Elemente können mehrmals auftreten

B.2.2 Metadaten in SMIL Präfix Label Schema Auftreten

dc format - obligatorisch ncc generator - optional dc identifier - optional - empfohlen ncc timeInThisSmil SMIL clock optional - empfohlen - title - optional dc title - optional ncc totalElapsedTime SMIL clock optional - empfohlen

Tabelle B5: DTB-Metadaten in SMIL-Dateien gemäß DAISY 2.02 Spezifikation

B.2.3 Master SMIL Metadaten Präfix Label Schema Auftreten

dc format - obligatorisch ncc generator - optional dc identifier - obligatorisch ncc timeInThisSmil SMIL clock optional - empfohlen dc title - obligatorisch

Tabelle B6: DTB-Mastermetadaten in SMIL-Dateien gemäß DAISY 2.02 Spezifikation



C Accessibility-Metadaten C.1 IMS AccessForAll Meta-data (ACCMD) Abstract Model

Abbildung C1: IMS AccessForAll Meta-data (ACCMD) Information Model als UML-Diagramm




Abbildung C2: Dublin Core AccessForAll (AfA) Application Profile Abstract Model als UML-Diagramm

C.2 Dublin Core AccessForAll (AfA) Abstract Model


D Konkordanz DTB-Metadaten - MARC 21 DC-Metadaten MARC 21

Tag Attr. Feld Ind1 Ind2 Teilfeld Beschreibung

Gemeinsame Metadaten für das Digital Talking Book und die Originalversion dc:Title 245 0 0 a Titel ohne zusätzliche Angaben

a Personenname (Nachname, Vorname) auth 0 Authority Record Control Numbertype 2 Normdateiquelle*

dc:Creator oder dc:Contributor

role

700 1

4 Bestimmt die Rolle der Person • creator: entspricht einem Autoren • contributor: gibt die jeweilige Rolle der Mitwirkung an

a Körperschaftsname auth 0 Authority Record Control Numbertype 2 Normdateiquelle*

dc:Creator oder dc:Contributor

role

710 1

4 Bestimmt die Rolle der Körperschaft • creator: entspricht einer Autorenrolle • contributor: gibt die jeweilige Rolle der Mitwirkung an

dc:Language 041 1 a Sprache dc:Description 520 a Unformatierte Zusammenfassung des Inhaltes

a Schlagwort (es wird angenommen, dass alle Schlagworte thematischer Natur sind) auth 0 Authority Record Control Number

dc:Subject

type

650 7

2 SchlagwortquelleMetadaten für das Digital Talking Book

8 a Herstellerspezifische Produktnummer in der DZB entspricht diese der Bestellnummer

024

3 a Medibus AG.Nr.

dc:Identifier

020 a International Standard Book Number dc:Publisher b Verlag/Herausgeber (hier ohne Normdatenbezug, für Normdatenintegration zusätzlich über

Feld 710 als „contributor“ und mit entsprechender „role“ spezifizieren) dc:Date bzw.

260

c Erstellungszeitpunkt



dtb:producedDate

dtb:producer f Produzent/Hersteller (hier ohne Normdatenbezug, für Normdatenintegration zusätzlich über Feld 710 als „contributor“ und mit entsprechender „role“ spezifizieren)

a Personenname eines Sprechers (Nachname, Vorname) auth 0 Authority Record Control Number: type 2 Normdateiquelle*

dtb:narrator

role

700 1

4 Die Rolle weist die Mitwirkung als Sprecher aus dtb:narrator 511 a Eintragung für synthetische Sprache dc:Format 856 q Elektronisches Format dtb:multimediaType 500 a Art des DTB (audioOnly, audioNCX, audioPartText, audioFullText, textPartAudio, textNCX) dtb:multimediaContent 516 a Art(-en) der enthaltenen elektronischen Medieninhalte dtb:totalTime 306 a Gesamtspielzeit

3 Ausweisen, dass sich das Feld auf Audio bezieht dtb:audioFormat 538 a Angabe des Formates (Format: mp3) 3 Ausweisen, dass sich das Feld auf Audio bezieht dtb:audioCompression 538 a Angabe der Kompression (Kompressionsrate: 128)

250 a Eigentlich Edition Statement, aber unter der Annahme, dass mit jeder Revision eine neue Auflage erstellt wurde

dtb:revision

843

z Revisionsnummer* dtb:revisionDate 843 d Zeitpunkt der letzten Überarbeitung dtb:revisionDescription

843 n Beschreibung zu den Überarbeitungen

dc:Rights 540 a Bestimmungen zu den Nutzungskonditionen und zum Kopierschutz Metadaten zur Originalversion dc:Source z Angabe der ISBN dtb:sourceTitle t Angabe des Titels dtb:sourcePublisher und dtb:sourceDate

c Angabe des herausgebenden Verlages und des Erscheinungszeitpunktes

dtb:sourceEdition b Auflage dtb:sourceRights r Copyright* dtb:sourceType

534

e Beschreibung der physikalischen Art der Ursprungsmanifestation (Druck, eBook etc. optio-nal auch Größenangaben)


Metadatenan

Cop

reicherung im digitalen Publikationsprozess

yright TU-Dresden, Alexander Haffner 158

dtb:sourceFormat m

Angabe zum Material der Originalversion bei elektronischen Versionen Angabe des Formates

Zusätze, die nicht in der opf-Datei des DTB enthalten sind, aber in MARC 21 aufgenommen werden sollten 042 a Authentication Coode:

• dc weist aus, dass der Datensatz aus Dublin Core gewonnen wurde • dtb weist aus, dass der Datensatz aus DTB-Metadaten gewonnen wurde

a Computer File Characteristics in der Form: Computer data (52 files : 524 mb) 300 a Anzahl der CD’s c Durchmesser der CD (11,5 cm) f Art der Verpackung (Box) g Verpackungsgröße (Höhe, Breite, Tiefe)

Die mit * gekennzeichneten Beschreibungen weisen auf Teilfelder hin, die nicht im MARC 21 Format enthalten sind. Diese Teilfelder wurden durch den Auror dieser Arbeit hinzugefügt, um ein vollständiges Mapping zu erreichen.

Tabelle D1: Konkordanz von Metadaten des ANSI/NISO Z39.86-2005 Standard zu MARC 21


E Beispiele für RDF-Tripel in OAI-ORE Subjekt Prädikat Objekt

<ReM-1> ore-describes <A-1> <ReM-1> dcterms:creator <X> <ReM-1> dcterms:modified “literal“ <ReM-1> dc:rights “literal“ <ReM-2> ore-describes <A-1> <A-1> dcterms:creator <Y> <Y> foaf:name “literal“ <A-1> rdf:type <T-1> <A-1> <R-1> <B> <A-1> rdfs:seeAlso <A-2> <A-1> ore:similarTo <DOI-1> <A-1> ore-aggregates <AR-1> <A-1> ore-aggregates <AR-2> <A-1> ore-aggregates <AR-3> AR-1 rdf:type <T-2> AR-2 rdf:type <T-2> AR-3 rdf:type <T-2>

Tabelle E1: RDF-Tripel ReM-1 http://www.dlib.org/dlib/february06/smith/aggregation.xml ReM-2 http://www.dlib.org/dlib/february06/smith/aggregation.rdf A-1 http://www.dlib.org/dlib/february06/smith/aggregation AR-1 http://www.dlib.org/dlib/february06/smith/02smith.html AR-2 http://www.dlib.org/dlib/february06/smith/pg1-13.html AR-3 http://www.dlib.org/dlib/february06/smith/pg1-13.pdf DOI-1 Info:doi/10.1045/february-2006-smith R-1 http://purl.org/dc/terms/isPartOf T-1 http://purl.org/eprint/types/JournalArticle T-2 http://purl.org/dcmitype/Text B http://www.dlib.org dcterms:creator http://purl.org/dc/terms/creator dcterms:modified http://purl.org/dc/terms/modified dc:rights http://purl.org/dc/elements/1.1/rights foaf:name http://xmlns.com/foaf/0.1/name rdfs:seeAlso http://www.w3.org/2000/01/rdf-schema#seeAlso ore.similarTo http://ww.openarchives.org/ore/terms/similarTo Tabelle E2: URIs zu den Subjekten, Prädikaten und Objekten
