Anwenderleitfaden für Encoded Archival Description

Anwenderleitfaden für
Encoded Archival Description (EAD)
Version 1.0
herausgegeben von der Society of American Archivists und der Library of Congress
Chicago, 1999
übersetzt und bearbeitet von Sebastian Barteleit, Rainer Jacobs und Anke Löbnitz
mit Unterstützung des Bundessprachenamtes
Inhaltsverzeichnis
Vorwort
2
Dank
Von der Arbeitsgruppe Encoded Archival Description
Von der Geschäftsführerin der Society of American Archivists (SAA)
5
7
Verwendung dieses Handbuchs
Überblick über den Anwenderleitfaden
Überblick über den EAD-Implementierungsprozess
Grundlegende Konventionen
9
12
14
Kapitel 1 EAD im Kontext: Archivische Erschließung und SGML
17
Kapitel 2 Verwaltungstechnische Überlegungen
32
Kapitel 3 Erzeugen von EAD-Findbüchern
48
Kapitel 4 Das Authoring von EAD-Dokumenten
139
Kapitel 5 Die Veröffentlichung von EAD-Dokumenten
159
Kapitel 6 Konzepte von SGML und XML
177
Kapitel 7 EAD-Verknüpfungselemente
202
Anhang
243
2
Vorwort
Encoded Archival Description (EAD) hat weltweit das Interesse von Archivaren,
Bibliothekaren, Softwareentwicklern und Informationstechnikern gewonnen und ihre
Phantasie angeregt. Und zwar deswegen, weil EAD der erste Datenstrukturstandard
ist, der mit Hilfe des archivischen Standardzugangwerkzeugs – dem Findbuch – die
Bereitstellung von ausführlichen Informationen zu Archivbeständen über das Internet
unterstützt. Die weltweite Bereitstellung ermöglicht die Recherche in Findbüchern mit
einer Effizienz und Gründlichkeit, die vor nur fünf Jahren noch fast unvorstellbar war.
Darüber hinaus erlaubt EAD es, digitalisierte Bilder in Findbücher einzubetten bzw.
digitalisiertes Archivgut und Findbücher miteinander zu verknüpfen, was Benutzern
die sukzessive Navigation durch immer detailliertere Informationsschichten erlaubt.
Die Herausgabe des EAD-Anwenderleitfadens bildet den letzten Abschnitt der
Dokumentation für EAD Version 1.0, zu der auch die EAD-Dokumenttyp-Definition
(DTD) und die EAD-Tag-Library gehören. Zwar wurde der Leitfaden als Letztes
herausgegeben. Er stellt jedoch den Teil der Dokumentation dar, den
Administratoren und Archivare, die EAD implementieren möchten, zuerst nutzen
sollten. Der Leitfaden hat den Zweck, von verschiedenen Gesichtspunkten her in
EAD einzuführen – vom verwaltungsmäßigen, technischen und, was am wichtigsten
ist, archivischen Gesichtspunkt – und er soll den von Archivaren geäußerten Bedarf
an Schulung und Beratung decken. Viele Fragen, die im Laufe der Entwicklung und
Implementierung von EAD entstanden sind – wie zum Beispiel, ob sich Findbücher
eines bestimmten Archivs in EAD abbilden lassen bis hin zu Detailfragen zur
Verwendung bestimmter EAD-Elemente – werden im Leitfaden erörtert.
Da die derzeit international angewandten Erschließungsverfahren so stark
voneinander abweichen, und sich die Aufstellung von Patentregeln nicht empfiehlt,
schreibt der Leitfaden kein bestimmtes Kodierverfahren vor. Vielmehr werden die
Vor- und Nachteile verschiedener Wege veranschaulicht und erörtert. Außerdem wird
nicht versucht, einen Inhaltsstandard für Findbücher festzulegen, wenngleich die
Entwickler von EAD gleichwohl hoffen, dass die Dokumentation einen Beitrag zu
einem künftigen internationalen Inhaltsstandard für Archivierungszwecke leisten wird.
Der Wunsch, Findbücher im Internet zu veröffentlichen, ist nicht der einzige Grund für
die Anwendung von EAD. EAD ist durch eine stabile und trotzdem flexible
hierarchische Struktur auf Findbücher in beliebiger Ausführung anwendbar. Die
gleichen Datenelemente, die ein „hochwertiges“ Online-Findbuch ausmachen, sind
ebenso für ein Findbuch gültig, dass aus einer Datenbank oder einem
Textverarbeitungsprogramm erzeugt oder auf Papier ausgedruckt wurde. Einer der
Grundsätze des Leitfadens ist es, dass Archivare ihre Erschließungspraxis gründlich
prüfen müssen, um Benutzern verständliche, hilfreiche Bestandsinformationen
anbieten zu können.
Es darf nicht vergessen werden, dass EAD eine laufend weitergeführte Arbeit ist und
wahrscheinlich immer sein wird. Das Internet, EAD, archivische
Erschließungsverfahren und die digitale Technik entwickeln sich dynamisch in einem
Umfeld, das zunehmend zur Standardisierung gedrängt wird. Die EAD-Version 1.0
bildete den Abschluss der fünfjährigen Prüf- und Verbesserungstätigkeit, die mit dem
Berkeley Finding Aid Project begann. Und in dem Maße, wie wir mehr darüber
3
erfahren, wie Benutzer Findbücher im Web einschätzen und nutzen, wird weiter
daran gearbeitet werden müssen.
4
Dank
Von der Arbeitsgruppe Encoded Archival Description
Wir, die Mitglieder der Arbeitsgruppe Encoded Archival Description der SAA,
möchten den vielen Institutionen und Personen, die uns bei der Erstellung des EADAnwenderleitfadens unterstützt haben, danken. Ausführlichere Dankesworte für die
Gesamtentwicklung von Encoded Archival Description sind in der EAD-Tag-Library
zu finden.
Ein großer Dank gebührt dem Council on Library and Information Resources (CLIR)
(früher Council on Library Resources) und seiner Geschäftsführerin Deanna Marcum
dafür, dass sie für die Society of American Archivists Gelder zur Weiterentwicklung
der EAD-DTD und zur Erstellung des Anwenderleitfadens, Beta-Version, zur
Verfügung stellten. Die Entwicklung des Anwenderleitfadens begann mit einem
Treffen des Bentley Fellowship Finding Aid Team1 im November 1995 in der Library
of Congress. An dem Treffen, dass von der National Digital Library betreut wurde,
nahm auch Anne J. Gilliland-Swetland teil, die kürzlich zur Verfasserin des
Anwenderleitfadens ernannt wurde.
An einer Sitzung im Januar 1996, die von der University of California, Los Angeles,
betreut (und von CLIR finanziert) worden war, nahmen neben Gilliland-Swetland und
Thomas A. La Porte auch einige Mitglieder des Bentley-Teams teil (Michael J. Fox,
Steven L. Hensen, Kris Kiesling, Daniel Pitti und Janice E. Ruth). Auf dieser Sitzung
wurde das Fundament für den Anwenderleitfaden gelegt, und die Verfasser erhielten
ein Rahmengerüst und allgemeine Anhaltspunkte für die geplanten Arbeiten. Um den
Sachstand und eventuelle Probleme des Entwurfs des Anwenderleitfadens zu
überprüfen, wurde im April 1996 an der University of California, Berkeley, eine zweite
von CLIR finanzierte Sitzung abgehalten. An dieser Sitzung nahmen GillilandSwetland und La Porte teil, ferner das gesamte Bentley-Team (mit Ausnahme von
Steven DeRose), Randall Barry von der Library of Congress sowie Tim Hoyer und
Jack Von Euw von der Bancroft Library.
Im Frühjahr 1998, als die Herausgabe der Version 1.0 der EAD-DTD und die
Veröffentlichung der EAD-Tag-Library bevorstanden, stellte sich heraus, dass eine
Überarbeitung der Beta-Version des Anwenderleitfadens erforderlich war, um die
inzwischen erfolgten zahlreichen Änderungen einzuarbeiten. Dem Institute of
Museum and Library Services (IMLS) wurde im Auftrag der Society of American
Archivists und der Bentley Historical Library, University of Michigan, die sich bereit
erklärt hatte, die Überarbeitungssitzungen zu betreuen, ein Antrag vorgelegt, diese
Überarbeitungsarbeiten zu ermöglichen. Diesem Antrag wurde stattgegeben. Einige
Mitglieder der EAD-Arbeitsgruppe der Society of American Archivists, nämlich Jackie
M. Dooley, Michael J. Fox, Steven L. Hensen, Kris Kiesling, Bill Landis und Janice E.
Ruth, zusammen mit Greg Kinney von der Bentley Historical Library, trafen sich im
November 1998 in Ann Arbor (US-Bundesstaat Michigan), um die Überarbeitung zum
Abschluss zu bringen.
1
Die Entwicklung von EAD ist auf der offiziellen Webseite zu EAD nachzulesen, die von der Library of Congress gehostet wird,
<http://www.loc.gov/ead>. Zum ursprünglichen Bentley-Team gehörten Stephen J. DeRose (INSO, früher Electronic Book
Technologies), Jackie M. Dooley (University of California, Irvine), Michael J. Fox (Minnesota Historical Society), Steven L.
Hensen (Duke University), Kris Kiesling (Harry Ransom Humanities Research Center, University of Texas, Austin), Daniel Pitti
(University of Virginia, früher University of California, Berkeley), Janice E. Ruth (Library of Congress Manuscript Division),
Sharon Gibbs Thibodeau (National Archives and Records Administration) und Helena Zinkham (Library of Congress Prints and
Photographs Division).
5
Die Arbeitsgruppe ist daher dem IMLS, der Society of American Archivists, der
Bentley Historical Library und der University of Michigan für ihre Unterstützung für die
Erstellung dieses Dokuments sehr dankbar. Besonders zu schätzen wissen wir die
beständige Unterstützung und Ermutigung von Francis X. Blouin und William
Wallach, Direktor bzw. Abteilungsleiter der Bentley Historical Library, und ihrer
Mitarbeiter (insbesondere Diane Hatfield), die alle wohlwollend in Kauf nahmen, dass
wir sie in den vergangenen Jahren so oft im Zusammenhang mit den EAD-Arbeiten
aufgesucht haben.
Die Überarbeitung des Entwurfs wurde von Jackie M. Dooley und Bill Landis von der
University of California, Irvine, betreut. Mitglieder der EAD-Arbeitsgruppe der SAA2
und des Technical Subcommittee on Descriptive Standards3 der SAA lieferten
Rückmeldungen zu einem vorläufigen Entwurf. Ein späterer Entwurf wurde von
Elizabeth Dow, Chris Powell und Kathleen Roe geprüft. Ihre detaillierten
Rückmeldungen waren von entscheidender Bedeutung zur Verbesserung vieler
Abschnitte. Teresa Brinati, Director of Publications der Society of American
Archivists, übernahm das redaktionelle Management und ist für die endgültige
Erstellung und Veröffentlichung des Werks verantwortlich.
Die Arbeitsgruppe dankt der University of California, Irvine, für ihre Unterstützung
und Beaufsichtigung des Projekts sowie der Society of American Archivists und ihrer
Geschäftsführerin, Susan Fox, für die stetige Unterstützung dieser Arbeit und allen
anderen Arbeiten, die mit der Entwicklung und Verbreitung von EAD in Verbindung
stehen.
Arbeitsgruppe „Encoded Archival Description”
Society of American Archivists
April 1999
2
Die EAD-Arbeitsgruppe der Society of American Archivists besteht aus den Mitgliedern des Bentley Fellowship Finding Aid
Team (außer DeRose) sowie Randall Barry (Library of Congress Network Development and MARC Standards Office), Wendy
Duff (University of Toronto), Ricky Erway (Research Libraries Group), Anne Gilliland-Swetland (University of California, Los
Angeles), Bill Landis (University of California, Irvine), Eric Miller (OCLC Online Computer Library Center), Meg Sweet (Public
Record Office, United Kingdom), Robert Spindler (Arizona State University) und Richard Szary (Yale University).
3
Das Technical Subcommittee on Descriptive Standards der Society of American Archivists wird von Bill Landis (University of
California, Irvine) geleitet und umfasst außerdem Nicole Bouché (Yale University), Donna DiMichele (Mashantucket Pequot
Museum and Research Center), Susan Potts McDonald (Emory University), Dennis Meissner (Minnesota Historical Society) und
Alden Monroe (Alabama Department of Archives).
6
Von der Geschäftsführerin der SAA
Die EAD-Arbeitsgruppe, die SAA-Verantwortlichen für die kontinuierliche Entwicklung
und Erhaltung von EAD, hat lange und hart daran gearbeitet, Archivaren die drei
Hauptdokumente zu EAD, Version 1.0, zur Verfügung zu stellen. Dies sind die
Dokumenttyp-Definition, die EAD-Tag-Library und der EAD-Anwenderleitfaden.
Einzelne Mitglieder der Arbeitsgruppe haben auf unterschiedliche Weise zur
Erstellung der Dokumentation beigetragen. Sie haben Entwürfe geschrieben oder
redigiert, internationale Perspektiven eröffnet bzw. Änderungen und Überarbeitungen
geprüft.
Innerhalb der Arbeitsgruppe haben indessen acht engagierte Personen die
Hauptrolle gespielt, Version 1.0 von EAD zu entwickeln. Jeder dieser SAA-Mitarbeiter
hat sich seit den Anfängen von EAD damit befasst und vielfältige Beiträge geliefert
und hat verschiedene Abschnitte der Version 1.0 der Tag-Library und des EADAnwenderleitfadens erstellt. Darüber hinaus verdient jeder einzelne von Ihnen
Anerkennung für seine Mitarbeit in folgenden Bereichen:
Jackie Dooley redigierte den Anwenderleitfaden. Sie behielt stets die unterschiedlich
zusammengesetzte Zielgruppe von EAD im Blick und fügte unzählige Entwürfe von
Kapiteln und Abschnitten zu einem ausführlichen Dokument zusammen, das sowohl
EAD-Neuanwendern als auch EAD-Fachleuten von Nutzen sein wird. Als
Vorsitzende des SAA Publications Board ermöglichte Jackie auch die Herausgabe
der Tag-Library.
Michael Fox steuerte sein umfassendes Wissen über Erschließungsverfahren nicht
nur vom Standpunkt eines Archivars, sondern auch von dem eines Bibliothekars und
Museumsexperten bei. Er hielt die Gruppe über XML und andere technische
Entwicklungen auf dem Laufenden. In seiner Rolle als Verbindungsmann zwischen
der Arbeitsgruppe und dem International Council on Archives Committee on
Descriptive Standards konnte er die Gruppe über internationale Belange informieren.
Steve Hensen war nicht nur der „Erfahrene“ und das Gewissen der archivischen
Erschließung; er hat sich auch außerdienstlich, aber höchst erfolgreich bei der
Mittelbeschaffung für die Gruppe betätigt. Die Anträge auf Zuschüsse, die er im
Auftrag der SAA an die Delmas Foundation und an das Institute of Museum and
Library Services gerichtet hat, sicherten die Finanzierung von zwei entscheidenden
Sitzungen, die die Mitglieder der EAD-Arbeitsgruppe in die Lage versetzten, die DTD
zu überarbeiten und den Anwenderleitfaden zu entwerfen. Außerdem koordinierte er
die abschließenden Redaktionsarbeiten an der Tag-Library.
Kris Kiesling, die Vorsitzende der Arbeitsgruppe seit deren Gründung im Jahr 1995,
spielte in allen Phasen der Dokumentationstätigkeit eine entscheidende
Führungsrolle. Sie koordinierte die Bemühungen und setzte anspruchsvolle
Fertigstellungstermine durch. Außerdem war sie von großer Bedeutung für die
Gründung der Runden Tisch-Gespräche über EAD bei der SAA.
Bill Landis brachte, als er 1997 zu der Arbeitsgruppe stieß, nicht nur eine neue
Perspektive mit, sondern auch Humor und Begeisterung. Er sammelte die vielen
Beispiele, die in der Tag-Library als Anleitung für die Kodierung dienen, und wirkte
bei der Überarbeitung des Anwenderleitfadens mit.
7
Daniel Pitti, Leiter des ursprünglichen Berkeley Finding Aid Project, war für die
umfangreichen Überarbeitungen und Erprobungen der DTD zuständig. Er hielt die
Gruppe über SGML/XML auf dem Laufenden und war für einige Implementierer von
EAD als Berater und Mentor tätig.
Janice Ruth brachte ihre beträchtlichen redaktionellen und schriftstellerischen
Fähigkeiten bei der Erstellung der Tag-Library und des Anwenderleitfadens zur
Geltung. Ihre redaktionelle Perspektive war besonders maßgebend bei der
Konzeption des Leitfadens, und sie war in vielen Fällen das institutionelle Gedächtnis
der Gruppe, was frühere Schritte der EAD-Dokumentation betraf.
Helena Zinkham wirkte bei den Vorbereitungen zur Erstellung von Version 1.0 der
Tag-Library als Katalysator, indem sie zahllose Einzelheiten aufspürte und immer
wieder prüfte, ob auch nichts vergessen worden war.
Die SAA würdigt das Vorstellungsvermögen, den Fleiß und das ungewöhnliche
Engagement all dieser Mitarbeiter im Archivarsberuf. Ihre führende Rolle ist
lebendige archivische Geschichte.
Susan Fox
Geschäftsführerin
Society of American Archivists
April 1999
8
Verwendung dieses Handbuchs
Überblick über den Anwenderleitfaden
Der Anwenderleitfaden - Encoded Archival Description (EAD) soll Archivaren,
Handschriftenkuratoren und sonstigen Fachleuten, die mit der Erschließung von
Archivgut, Handschriften und anderweitigen wissenschaftlichen Primärquellen
befasst sind, folgende Informationen liefern:4
•
•
•
•
•
•
Erläuterung der Entstehung und Funktionsweise von EAD und dessen Rolle
für die archivische Erschließung (Kapitel 1)
Anleitung bei verwaltungstechnischen Problemen und anderen Fragen der
Implementierung von EAD (Kapitel 2)
Überblick über den Einsatz von EAD-Tags einschließlich einer Anleitung zur
Verwendung von erforderlichen und anderen Schlüsselelementen (Kapitel 3)
Vergleichender Überblick über Werkzeuge und Verfahren zum Authoring und
zur Veröffentlichung von Dokumenten (Kapitel 4 und Kapitel 5)
Grundlegende Konzepte von SGML und XML im Zusammenhang mit EAD
(Kapitel 6)
Genaue Anweisungen zur Verwendung der Verknüpfungselemente von EAD
(Kapitel 7).
Zusätzlich zu dem beschreibenden Text bietet der Leitfaden verschiedene nützliche
Anhänge:
•
•
•
•
•
•
•
Auflistung der empfohlenen Elemente, die ein kodiertes Findbuch mindestens
enthalten muss,5 unter besonderer Beachtung von Elementen, die für die
softwaregestützte Validierung eines EAD-Findbuchs nötig sind (Anhang A)
Crosswalks (Entsprechungsstabellen) zwischen EAD und drei verwandten
Erschließungsstandards: MARC, ISAD(G) und Dublin Core (Anhang B)
Häufig gestellte Fragen (FAQs) (Anhang C)
Prüfliste für die Implementierung (Anhang D)
Beispiele von EAD-kodierten Findbüchern (Anhang E)
Glossar der Fachbegriffe (Anhang F)
Bibliografie zu EAD, SGML, XML und archivischer Erschließung sowie
wichtige Thesauri und Erschließungsregeln (Anhang G).
Der Anwenderleitfaden soll neben potenziellen Anwender von EAD auch diejenigen
unterstützen, die aktiv Erschließungsinformationen, die gemeinhin in archivischen
Findbüchern enthalten sind, kodieren. Deshalb werden sowohl vom Standpunkt des
Managements als auch von dem der Kodierung aus gesehen die verschiedenen
Stufen und Ebenen der Implementierung von EAD und die damit
zusammenhängenden Tätigkeiten behandelt. Außerdem soll der Anwenderleitfaden
einer breiten Zielgruppe, die sich u. a. aus Verwaltungspersonal, Mittelgebern,
Managern und Leitern, Archivaren und Bibliothekaren, Findbuchkodierern,
Programmierern und Systemadministratoren zusammensetzt, helfen, über die
4
Das Glossar in Anhang F erläutert die Bedeutung von Fachbegriffen und Akronymen, die im Anwenderleitfaden erwähnt
werden. Viele Begriffe werden außerdem in den einzelnen Abschnitten näher erläutert.
Der Begriff „Findbuch" bezeichnet im gesamten Dokument die Arten von archivischen Suchwerkzeugen, die allgemein als
Inventare und Register bekannt sind (Vgl. dazu Übersetzungsanmerkung Seite 20.). EAD wurde zwar für Findbücher optimiert
der Aufbau von EAD schließt jedoch seinen Einsatz für andere Arten von Findmitteln und die Weiterentwicklung im Hinblick auf
neue Arten archivischer Such- und Zugriffswerkzeuge nicht aus.
5
9
Anwendung von EAD zu entscheiden und die Prozesse und Folgen, die die
Einführung einer EAD-Kodierung mit sich bringt, einschätzen zu können. Diejenigen,
die ein möglichst umfassendes Verständnis von EAD benötigen, werden
wahrscheinlich alle Kapitel so gründlich wie nötig durcharbeiten und umsetzen.
Andere mit weniger ausführlichem und speziellerem Bedarf werden sich u. U. auf
bestimmte Kapitel konzentrieren.
Kapitel 1 erläutert EAD im größeren Zusammenhang der archivischen Erschließung
und der Erschließungsstandards. Die Wahl von SGML wird begründet. Die
Beziehungen zwischen EAD, SGML, HTML und XML werden erklärt. Die Beziehung
zwischen EAD und der General International Standard Archival Description
(ISAD(G)) wird umrissen. Die auch weiterhin große Bedeutung von MARCTitelaufnahmen wird geklärt. Kapitel 1 sollte diejenigen durcharbeiten, die die
Anwendung von EAD in Betracht ziehen. Möglicherweise ebenso relevant ist es für
Programmierer und Systemadministratoren.
Kapitel 2 konzentriert sich auf die Organisation von EAD-Projekten. Es behandelt
Themen wie die Beziehung zwischen EAD und den Aufträgen und Zielsetzungen von
Institutionen, die Bedeutung von festgelegten Prioritäten und Ressourcen, Personalund Ausbildungsfragen, den Arbeitsablauf bei der Kodierung sowie Probleme bei der
Umwandlung von Altdaten. Außerdem behandelt Kapitel 2 die möglichen Vorteile
einer Fremdvergabe sowie einer Zusammenarbeit mit Partnerinstitutionen in
Kooperationsprojekten. Kapitel 2 ist für Verwaltungsmitarbeiter von größtem Nutzen.
Kapitel 3, der Kern des Anwenderleitfadens, beschreibt detailliert alle wichtigen EADElemente, die notwendig sind, um ein kodiertes Findbuch zu erstellen. Dieses Kapitel
gemeinsam mit der EAD-Tag-Library angewendet werden, wobei es einer seiner
Hauptzwecke darin besteht, Elemente der Tag-Library im Zusammenhang mit
archivischer Erschließung zu erläutern. Die wichtigsten Komponenten von EAD
werden in einer logischen Abfolge vorgestellt, begonnen wird mit jenen, die einen
Bestand als Ganzes beschreiben. Danach folgen diejenigen, die „Komponenten“
oder Teile eines Bestandes beschreiben. Es werden verschiedene Themen
diskutiert: die Bedeutung konsistenter Erschließungsverfahren vor der EADKodierung bis hin zu speziellen Fragen zur Auszeichnungstiefe. Im letzten Abschnitt
wird die Verwendung von EAD-Elementen für Metadaten, die das Findbuch selbst
beschreiben, vorgeführt. Kapitel 3 ist für Mitarbeiter und Führungspersonen, die
selbst kodieren oder Kodierprogramme einsetzen, von zentraler Bedeutung. Wenn
Sie sich mit EAD und den verschiedenen im Anwenderleitfaden behandelten Fragen
und Empfehlungen – insbesondere den Empfehlungen für die Erstellung von
Erschließungsrichtlinien und Arbeitsabläufen – vertraut gemacht haben, werden sie
den Anwenderleitfaden nicht mehr oft benötigen. Dann wird es in vielen Fällen
hilfreicher sein, unmittelbar auf die Tag-Library zurückzugreifen.
Kapitel 4 befasst sich mit Fragen zum „Authoring“ von EAD-kodierten Dokumenten,
bei dem Software zur SGML-Kodierung von Findbuchdokumenten eingesetzt wird.
Zu dem Kapitel gehören eine vergleichende Abhandlung spezifischer
Softwarealternativen und Lösungsansätze, Überlegungen zu spezieller SGML- bzw.
XML-Software, die Beziehung zwischen MARC-Daten und EAD-Findbüchern,
Kodierprobleme, die die Darstellung beeinflussen und das Dateimanagement.
10
Kapitel 5 beschreibt Möglichkeiten für die Veröffentlichung und Bereitstellung von
EAD-Dokumenten im World Wide Web. Hier werden Themen wie Software zum
Suchen und Finden von Archivalien, Stylesheets und ihre Verwendung bei der
Online-Darstellung und beim Ausdruck, Server-/Client-gestützte Verbreitung und
Veröffentlichung, Ausdruck von kodierten Findbüchern und Fragen der
Systemadministration in Bezug auf kleine und große SGML-Server behandelt.
Kapitel 6 konzentriert sich auf grundlegende SGML- und XML-Konzepte im Kontext
von EAD. Eine umfassende Kenntnis dieser Themen ist zwar nicht für alle EADKodierer oder Projektbeauftragten erforderlich. Einschlägige Grundkenntnisse sind
jedoch für all diejenigen von entscheidender Bedeutung, die für Planung und
Verwaltung von Systemen zuständig sind. Zu den behandelten Themen gehören
Rolle und Struktur der DTD, Verschachtelung und Vererbung bei SGML,
Zeichenvorräte, Elemente, Attribute, Entitäten (besonders Formal Public Identifiers),
Elemente mit und ohne Inhalt, allgemeine Informationen zu Präsentation und Stil bei
SGML und XML sowie die Auswirkungen einer bevorstehenden vollständigen
Implementierung von XML auf SGML im Allgemeinen und von EAD im Besonderen.
Die Kapitel 4, 5 und 6 sind aufgrund der Aufgaben vor allem für Programmierer und
Systempersonal von Interesse (Wahl der Software, Verwaltung von EAD-Servern
und -Systemen und Verständnis für die technischen Aspekte von SGML und XML).
Kapitel 7 bietet schließlich detaillierte Informationen zur Verwendung der EADVerknüpfungselemente, mit denen die Möglichkeiten von Hypertext und Navigation
verbessert werden. Verschiedene nützliche interne und externe
Verknüpfungsmöglichkeiten werden beschrieben, z. B. Benutzung des Elements
Digital Archival Object für die Verknüpfung von Findbüchern mit digitalisiertem
Archivgut. Dieses Kapitel ist äußerst wichtig für Kodierer und Programmierer, die die
vielseitigen und komplexen Verknüpfungsmöglichkeiten von EAD einsetzen wollen.
11
Überblick über den EAD-Implementierungsprozess
Dieser Abschnitt enthält einen kurzen Überblick über den Implementierungsprozess
und ist die Grundlage für alle folgenden Kapitel. Anders als der „Überblick über den
Anwenderleitfaden“, in dem Implementierungsaspekte in der Reihenfolge ihrer
Behandlung in Kapitel 1 bis 7 erörtert wurden, befasst sich dieser Abschnitt mit den
Schritten der Implementierung und zwar in der Reihenfolge, in der Archive
folgerichtig damit konfrontiert werden können.
Zu den wesentlichen Phasen der EAD-Implementierung und ihrer jeweiligen
Komplexität lassen sich folgende drei Fragen stellen:6
•
•
•
Sollen wir EAD implementieren?
Wie erzeugen wir elektronische Findbücher?
Wie verbreiten wir elektronische Findbücher?
Die Entscheidung einer Institution, EAD zu implementieren, wird zumindest teilweise
von praktischen Überlegungen beeinflusst. Dazu gehören so fundamentale Fragen
wie z. B., ob die Institution bereits ein Erschließungsprogramm, mit dem sich
Findbücher erzeugen lassen, die intern und hinsichtlich aufkommender nationaler
bzw. internationaler Standards konsistent sind, besitzt oder die Voraussetzungen für
die Einführung einer solchen Software hat. Andere Fragen drehen sich um Auftrag,
Zielsetzung und Zielgruppe der Institution sowie darum, ob die EAD-Implementierung
Auftrag und Zielsetzung fördern und der Zielgruppe dienen wird.
Für viele Institutionen sind die Ressourcen ausschlaggebend: Haben wir das
Personal, die technische Kompetenz sowie die Hard- und Software, um EAD zu
implementieren? Falls nicht, gibt es ein gemeinsames Programm, an dem wir uns
beteiligen oder das wir entwickeln können, um den Aufwand auf mehrere
Institutionen zu verteilen? Da Archivmitarbeiter ständig über Änderungen, z. B. über
die Weiterentwicklung der DTD, unvermeidliche Softwareaktualisierungen und
andere Neuerungen, die technologische Werkzeuge mit sich bringen, auf dem
Laufenden gehalten werden müssen, sollte man schließlich über die Frage
nachdenken, ob die Institution in der Lage ist, ein EAD-Programm langfristig
aufrechtzuerhalten.
Ist einmal die Entscheidung zugunsten der Implementierung von EAD gefallen, sind
u. a. folgende wichtigen Hürden bei der Erzeugung von EAD-kodierten Findbüchern
zu bewältigen:
•
•
•
Evaluierung der im jeweiligen Archiv üblichen Erschließungsverfahren, um
konsistente Lösungen für die Umwandlung vorhandener Findbücher und zum
Authoring neuer Findbücher in EAD zu entwickeln.
Entscheidungsfindung über Regeln und Bestimmungen für
Erschließungskonventionen und -stil, Auszeichnungstiefe, Zuweisung von
Begriffen aus Normdaten sowie Beziehung zwischen EAD-kodierten
Findbüchern und MARC-Titelaufnahmen.
Wahl einer geeigneten Software zum Authoring von EAD-Dateien.
6
Fox, Michael: Implementing Encoded Archival Description: An Overview of Administrative and Technical Considerations, in:
American Archivist 60 (1997) 2, S. 330-343, S. 342.
12
•
•
Beschaffung (Download) der benötigten offiziellen Dateien, z. B. EAD-DTD
und anderer Dateien für spezielle Softwareanwendungen und
ordnungsgemäßes Laden dieser Dateien in die vor Ort vorhandene
Umgebung.
Validierung von EAD-Dateien mit Hilfe von SGML-Parsern.
Schließlich müssen sich die Mitarbeiter des Archivs mögliche Verfahren für die
Veröffentlichung und Verbreitung von elektronischen Findbüchern überlegen, um sie
für Benutzer bereitzustellen. Genau wie für das Authoring von kodierten Findbüchern
gibt es auch hier eine Vielfalt von Szenarios und Software, vom einfachen
Verknüpfen von Findbüchern mit einer Webseite bis hin zum Einsatz von
leistungsfähigen (und oft kostspieligen) Suchmaschinen, die es Benutzern
erleichtern, geeignete Materialien aufzufinden. Alle Verbreitungsszenarios erfordern
für die Interpretation der EAD-Kodierung für die öffentliche Darstellung und
Recherchierbarkeit eine Kombination von Umwandlungsskripten und/oder
Stylesheets. Daneben müssen ggf. auch Überlegungen zur Erstellung von
Ausdrucken elektronischer Findbücher angestellt werden.
13
Grundlegende Konventionen
Zum Verständnis zahlreicher Aspekte dieses Anwenderleitfadens müssen Sie einige
grundlegende SGML-Konventionen verstehen. Dieser Abschnitt dient dazu als kurze
Einführung. Genauere Angaben über SGML im EAD-Zusammenhang finden Sie in
Kapitel 6.
Elemente: Die EAD-Struktur besteht aus Datenfeldern, die als Elemente bezeichnet
werden. Jedes Element erhält einen eindeutigen Namen, eine Abkürzung und eine
Definition gemäß der EAD-Tag-Library. EAD-Elemente werden durch kurze
alphanumerische Ausdrücke oder Tag-Namen dargestellt, die in spitzen Klammern
(< >) stehen.
Wenn im Anwenderleitfaden ein Element zum ersten Mal vorgestellt wird, sind
sowohl sein Elementname als auch sein Tag-Name angegeben. Danach wird das
Element nur noch mit seinem Tag-Namen bezeichnet. Beispielsweise sind bei der
ersten Erwähnung eines bestimmten Elements sowohl der Elementname Laufzeit
(Date of the Unit) als auch sein Tag-Name <unitdate> angegeben. Später wird das
Element nur noch mit seinem Tag-Namen <unitdate> erwähnt.
Einige EAD-Elemente sind als Hüllenelemente bekannt. Vor dem Einfügen von Text
müssen sie ein weiteres Element enthalten. Ein Beispiel für ein Hüllenelement ist
Gegenstände (Scope and Content) <scopecontent>. <scopecontent> muss ein
Element namens Abschnitt (Paragraph) <p> enthalten, bevor Text eingegeben
werden kann. Die meisten Elemente können entweder andere Elemente oder Text
enthalten, aber nicht Beides.
Jedes Textstück ist in einem kodierten Findbuch von einem oder mehreren EADTags umgeben. Bisweilen ist eine bestimmte Information in mehreren Schichten von
Tags verschachtelt. Die Beispiele des Anwenderleitfadens zeigen, wie der
Findbuchtext zwischen dem Start- und dem End-Tag jedes Elements erscheint, z. B.:
<date>1957</date>
Dabei ist <date> für das Element der Start-Tag, „1957“ der Findbuchtext und </date>
der End-Tag. Anders als HTML, bei dem End-Tags wie bei <p> entfallen können,
erlaubt SGML kein Weglassen von Tags. Jedes Element muss mit einem End-Tag
abgeschlossen werden.
Der Begriff Subelement erscheint im Zusammenhang mit dem weitergefassten
Elternelement. Beispielsweise werden Archiv (Repository) <repository>, Provenienz
(Origination) <origination> und alle weiteren Elemente, die innerhalb von Element
Erschließungsangaben (Descriptive Identification) <did> verfügbar sind, als <did>Subelemente bezeichnet. Jedes EAD-Element mit Ausnahme von <ead> ist ein
Subelement eines oder mehrerer Elternelemente (<ead> ist das höchstrangige
Element oder auch Dokumentelement in der EAD-DTD und hat daher keine
Elternelemente).
Attribute: Die meisten EAD-Elemente lassen sich mit Hilfe von Attributen
modifizieren. Attribute spezifizieren zumeist die Bedeutung eines Elements. Einige
Attribute werden allerdings auch zur Steuerung von Darstellung oder
Recherchefunktionalitäten verwendet. Das Element Datum (Date) <date> kann z. B.
14
zur Kodierung von Datumsangaben verwendet werden, mit Ausnahme von denen,
die mit der Laufzeit von Archivgut zusammenhängen (für diese wird <unitdate>
verwendet). In einigen Fällen ist es erwünscht, anzugeben, was für eine Art von
Datum kodiert wird, z. B. Geburtsdaten, Erscheinungsdaten oder Übernahmedaten.
Dies geschieht mit Hilfe von Attributen. Bei der Verwendung von Attributen werden
innerhalb des Start-Tags des Elements der Attributname und sein Wert genannt:
<date type="publication">
Im vorstehenden Beispiel ist „date“ der Tag-Name, „type“ der Attributname and
„publication“ der Attributwert. Reihenfolge und Syntax sind stets gleich: Tag-Name,
gefolgt vom Attributnamen, einem Gleichheitszeichen und schließlich dem
Attributwert in Anführungszeichen. Mehrere Attribute können innerhalb des StartTags eines Elements nacheinander aufgeführt werden.
Im Anwenderleitfaden werden Attributnamen stets durchgehend in
GROSSBUCHSTABEN geschrieben. Attributwerte erscheinen in Anführungszeichen.
Wird ein Attributname jedoch innerhalb eines Beispiels genannt, erscheint er in
Kleinbuchstaben, um an die Darstellung in einem kodierten Dokument angepasst zu
sein (wie im Beispiel oben).
EAD verwendet sehr häufig Attribute, von denen die meisten optional sind (die
einzigen erforderlichen Attribute sind Stufe (LEVEL) innerhalb von <archdesc> und
Typ (TYPE) innerhalb von <dsc>. Vor allem die Attribute ermöglichen es, die Anzahl
der in EAD benötigten Elemente zu begrenzen. Die Entwickler haben so weit wie es
möglich war allgemeine Elementnamen geschaffen, um Begriffe der archivischen
Fachterminologie zu vermeiden, die in bestimmten Institutionen oder auf
internationaler Ebene unterschiedliche Bedeutung haben können. EAD ermöglicht
es, speziellere Begriffe in einem Attribut auszudrücken. Zum Beispiel gibt es in
Komponente (Component) <c> das Attribut LEVEL, das die Stufe – d.h. eine
bestimmte Komponente ob nun Serie, Untergruppe oder Teilserie – innerhalb der
Hierarchie eines Bestandes bezeichnet, weshalb in EAD keine gesonderte Serien-,
Untergruppen- bzw. Teilserien-Elemente definiert werden mussten. Alle Attribute sind
vollständig in der EAD-Tag-Library definiert.
DTD: Die Struktur eines validen EAD-kodierten Findbuchs wird von der EADDokumenttyp-Definition (DTD) bestimmt. Die DTD legt die Elemente fest und
bestimmt die Reihenfolge, in der sie verwendet werden können, ob sie wiederholt
werden können und welche Attribute es für jedes Element gibt. Die EAD-DTD ist
recht anpassungsfähig und eignet sich für viele Arten von „Altdaten“;7 sie regt aber
auch die Archivare dazu an, ihre Erschließungsverfahren zu standardisieren. Diese
Flexibilität bewirkt, dass es oft mehrere Möglichkeiten zur Kodierung der gleichen
Information gibt. In einem solchen Fall werden im Anwenderleitfaden die Optionen
bei der Behandlung des Elements zusammen mit ihren Vor- und Nachteilen
vorgestellt.
Beispiele: Zu jedem der beschriebenen Elemente enthält der Leitfaden Beispiele für
die Auszeichnung. Es ist zu beachten, dass diese Beispiele das erklärte Element
7
Der Begriff „Altdaten” dient zur Beschreibung von Findbüchern, die vor der Entwicklung von EAD geschaffen wurden.
Derartige Findbücher müssen oft, um sich der hierarchischen Struktur und den Datenelementen von EAD anzupassen, in
gewissem Maße umstrukturiert werden.
15
betreffen und ggf. erforderliche Elternelemente nicht mit einbeziehen. Drei vollständig
kodierte Findbücher sind in Anhang E aufgeführt. Die EAD-Tag-Library enthält
ebenfalls ein oder zwei Verwendungsbeispiele für die meisten Elemente.
16
Kapitel 1: EAD im Kontext: Archivische Erschließung und SGML
1.1. Einführung................................................................................................................................... 18
1.2. Die Entwicklung von archivischen Erschließungsstandards ...................................................... 20
1.3. Die Entwicklung der archivischen Informationstechnik im Internet ............................................ 22
1.4. Warum SGML? ........................................................................................................................... 24
1.5. Was ist XML?.............................................................................................................................. 26
1.6. Beziehung zwischen MARC und EAD ........................................................................................ 27
1.7. Sonstige Informationen zu EAD.................................................................................................. 29
1.7.1. Literatur ................................................................................................................................ 29
1.7.2. Webseiten ............................................................................................................................ 29
1.7.3. Aus- und Weiterbildungsmöglichkeiten ................................................................................ 30
17
1.1. Einführung
Encoded Archival Description (EAD) ist ein Datenstrukturstandard zur Bewahrung
der Hierarchie und zur Bezeichnung des Inhalts von Findmitteln zu Archivbeständen
aus aller Welt. EAD ermöglicht die Verbreitung dieser Findbücher über das Internet
und stellt, indem es eine stabile, nicht proprietäre Datenspeicherumgebung
bereitstellt, aus der Daten ggf. zu anderen Softwareumgebungen übertragen werden
können, auch ihre weitere Verfügbarkeit sicher. Technisch gesehen handelt es sich
bei EAD um eine Dokumenttyp-Definition (DTD) zur Kodierung von archivischen
Findbüchern, die nach den Syntaxregeln der Standard Generalized Markup
Language (SGML) und der Extensible Markup Language (XML) geschrieben wurde.
Die EAD-Tag-Library8 enthält Namen und Definition aller in der DTD definierten
Datenelemente. Der EAD-Anwenderleitfaden enthält Erklärungen und Anleitungen
für Archivare, um die DTD bei der Kodierung von Findbücher adäquat und effektiv
anwenden zu können. Diese drei Dokumente (die DTD, die Tag-Library und der
Anwenderleitfaden) bilden die Gesamtdokumentation zu EAD Version 1.0.
Im ersten Kapitel wird EAD in den größeren Zusammenhang anderer archivischer
Standards gestellt. Es wird erklärt, warum SGML als technische Umgebung für EAD
gewählt wurde. In diesem Kapitel wird hervorgehoben, dass die Entwicklung von
EAD zwar in den USA den Anfang nahm und die Struktur in den
Erschließungsverfahren dieses Landes verwurzelt ist, die Entwickler von EAD jedoch
wichtige Konzepte der Internationalen Grundsätze für die archivische Verzeichnung
(ISAD(G)9, sowie Konzepte nationaler Erschließungsstandards, wie die kanadischen
Rules for Archival Description (RAD)10, berücksichtigt haben. Außerdem wurde den
EAD-Elementen eine sprachneutrale Nomenklatur beigegeben, um terminologische
Unterschiede zu umgehen und auf diese Weise die internationale Anwendung und
Akzeptanz der DTD zu fördern.
Der EAD-Entwicklungsprozess ist an anderer Stelle ausführlich dokumentiert
worden.11 Ein Aspekt ist jedoch im Rahmen des Anwenderleitfadens hervorzuheben,
und zwar die Tatsache, dass sowohl die gedanklichen Grundlagen als auch die
strukturellen Eigentümlichkeiten von EAD fest in archivischen Grundsätzen,
Traditionen und Theorien verwurzelt sind. Die EAD-Entwickler analysierten
archivische Findbücher sowie die Erschließungsgrundsätze gemäß dem o. g.
Rahmenwerk (ISAD(G)), den RAD sowie dem Dokument Archives, Personal Papers,
and Manuscripts (APPM).12 Aus all diesem entwickelten und formulierten sie eine
Reihe von Gestaltungsgrundsätzen, die konzeptionell so ausgerichtet sind, dass
EAD auch künftig an die Realitäten vergangener und aktueller Theorie und Praxis
angepasst werden kann.13
8
Encoded Archival Description Tag Library, Version 1.0, ed. by Society of American Archivists, Chicago 1998.
ISAD(G). General International Standard Archival Description, adopted by the Ad Hoc Commission on Descriptive Standards
des International Council on Archives, Stockholm, Schweden, 21. –23. Januar 1993, Ottawa 1994.
<http://www.archives.ca/ica/cds/isad(g)e.html>..
10
Rules for Archival Description, prepared by the Planning Committee on Descriptive Standards of the Bureau of Canadian
Archivists, Ottawa 1990.
11
Vgl. Pitti, Daniel V.: Encoded Archival Description. The Development of an Encoding Standard for Archival Finding Aids, in:
American Archivist 60 (1997) 2, S. 268-283. Siehe außerdem die Hintergrundinformation zur Encoded Archival Description
Official Web Site, Internet-Adresse: <http://www.loc.gov/ead/>.
12
Hensen, Steven L.: Archives, Personal Papers, and Manuscripts. A Cataloging Manual for Archival Repositories, Historical
2
Societies, and Manuscript Libraries, Chicago 1989.
13
Encoded Archival Description Tag Library, Version 1.0, S. 1-3.
9
18
Ein wichtiger Grundsatz besagt, dass EAD sowohl die Erzeugung neuer Findbücher
als auch die Konversion vorhandener Daten (auch als Altdaten bezeichnet)
ermöglicht. EAD ist flexibel genug dafür. Zugleich soll es jedoch die strukturelle
Einheitlichkeit der Findbücher fördern, weil die Entwickler der Ansicht sind, dass die
Einhaltung eines konsistenten Datenmodells den erfolgreichen Austausch von
Dokumenten zwischen den verschiedenen Archiven erhöht und eine größere
Standardisierung der Findbücher im Allgemeinen eine positive Entwicklung darstellt.
Ein weiterer wichtiger Entwurfsgrundsatz lautet dahingehend, dass obwohl ein
großes und vielfältiges Spektrum an archivischen Erschließungsdaten existiert, EAD
dazu bestimmt ist, Daten zur Unterstützung von Erschließung, Steuerung,
Navigation, Indexierung und Online-Präsentation bzw. Ausdruck aufzubereiten. Es
dient jedoch nicht dazu, notwendige Daten zum Einlagern, Ausheben und
Reponieren von Archivalien im Rahmen des Bestandsmanagements zu erfassen und
zu verwalten.
19
1.2. Die Entwicklung von archivischen Erschließungsstandards14
Archive, Bibliotheken, Museen und andere Kultureinrichtungen haben den Zweck,
Aufzeichnungen über die Tätigkeit des Menschen zu erhalten und zu schützen und
sie für Forschung, Studium und zum Zweck der Beweisführung bereitzustellen. Zur
Wahrnehmung dieser Aufgabe haben Archive seit langem viel Mühe darauf
verwendet, die vorhandenen Bestände zu ordnen und zu verzeichnen und sie
erstellten gleichförmige Findbücher, mit deren Hilfe Benutzer gewünschte Materialien
auffinden können. Bis vor kurzem waren viele Findbücher jedoch noch nicht
veröffentlicht und standen nur innerhalb eines Archivs zur Verfügung. Schon seit
langem suchen Archivare nach einem kostengünstigen und effizienten Mittel, um ihre
Unterlagen einen größeren Bekanntheitsgrad zu verschaffen.
In den USA beispielsweise haben einige Archive Kurzbeschreibungen ihrer Bestände
erstellt und veröffentlicht. Während der Weltwirtschaftskrise der 1930er Jahre
finanzierte die US-Regierung eine Bestandserfassung von historischen
Aufzeichnungen als Arbeitsbeschaffungsmaßnahme. Ende der 1950er Jahre wurden
dann systematischere Bemühungen eingeleitet, um landesweit Kurzbeschreibungen
von Unterlagen zusammenzustellen. Durch die 1959 begonnene Erstellung des
National Union Catalog of Manuscript Collections,15 auf die 1961 die Veröffentlichung
von Hamers bahnbrechendem Guide to Archives and Manuscripts in the United
States16 folgte, wurden Standort und allgemeiner Inhalt der
Handschriftensammlungen der beteiligten Archive bekannt.17
So hilfreich diese papiergestützten Projekte auch waren, ermöglichte es Ende der
1970er Jahre erst das MARC-AMC-Format den Archiven, Bestandsangaben über
nationale bibliografische Systeme weiter zu verbreiten. Die sich durch die
Anwendung von MARC AMC 18 erstellten Titelaufnahmen machten es möglich, die
Archivbestände mit der gleichen Flexibilität und Genauigkeit wie veröffentlichte
Materialien zu durchsuchen. Trotz der Fortschritte von MARC AMC konnten die
MARC-Titelaufnahmen nur Kurzinformationen über Bestände, nicht jedoch alle Daten
eines detaillierten Findbuchs aufnehmen. Sie konnten allerdings auf vorhandene
detaillierte papiergestützte Findbücher verweisen. Es war indessen weiterhin
problematisch, dass die ausführlichen Papierfindbücher noch nicht Teil einer
gemeinsamen Online-Umgebung waren. Dies war besonders unbefriedigend, da
mittlerweile viele Findbücher mit Hilfe von Textverarbeitungs- oder
Datenbanksystemen erstellt wurden.
Wenn in den USA auch zahlreiche Archive das MARC-AMC-Format verwendeten,
taten die meisten europäischen Institutionen dies nicht und arbeiteten statt dessen
auf die Entwicklung von ISAD(G) hin, das 1993 vom International Council on
Archives (ICA) eingeführt wurde. ISAD(G) legt 26 Elemente fest, „die sich
miteinander kombinieren lassen, um [auf beliebiger Ebene] eine archivische Einheit
14
Dieser Abschnitt wurde teilweise auf der Grundlage der folgenden Abhandlung erstellt: Hensen, Steven L.: 'NISTF II' and
EAD: The Evolution of Archival Description, in: American Archivist 60 (1997) 2, S. 284-297.
15
Library of Congress, Descriptive Cataloging Division, Manuscripts Section: National Union Catalog of Manuscript Collections.
Washington 1959-1993.
16
Hamer, Philip: Guide to Archives and Manuscripts in the United States, New Haven 1961.
17
Auch in anderen Ländern wurden wichtige Union-Listen erstellt. In Kanada z. B. war die umfassendste Veröffentlichung dieser
Art vgl. Public Archives of Canada: Union List of Manuscripts in Canadian Repositories = Catalogue collectif des manuscrits
archives canadiennes, ed. by Robert S. Gordon, Ottawa 1968.
18
Zugriffsbegriffe aus Normansetzungen bestehen aus Normdaten wie Personen-, Familien- und Körperschaftsnamen,
geografischen Namen, Themenansetzungen, Form- und Genresansetzungen usw., die gemäß Standards oder Regeln gebildet
werden oder einem/einer angesetzten Thesaurus bzw. Liste entnommen werden.
20
zu beschreiben“.19 ISAD(G) bietet auch zahlreiche Definitionen für Begriffe der
Archivterminologie und formuliert vier allgemeine Grundsätze, um Archivare mit der
mehrstufigen Verzeichnung vertraut zu machen. Hauptmotiv für die Entwicklung
dieses Standards war die Erkenntnis, dass ein gewisses Maß an Konsistenz bei der
Erschließung erforderlich sein würde, um den Austausch und die Recherche von
archivischen Informationen in archivübergreifenden und internationalen
Verbundsystemen zu ermöglichen.
EAD ist ein speziellerer Strukturstandard als ISAD(G), weil es sich auf einen
bestimmten Typ eines archivischen Findbuchs konzentriert, der im
Anwenderleitfaden auch als Inventar* oder Register** bezeichnet wird. Wie bereits
erwähnt, analysierten die Entwickler von EAD den Standard ISAD(G) genau und
stellten sicher, dass seine Elemente in die EAD-Datenstruktur aufgenommen werden
konnten.20 Darüber hinaus ist EAD mit den Grundsätzen von ISAD(G) im Hinblick auf
die mehrstufige Verzeichnung voll kompatibel. Die Übereinstimmung der
Datenstrukturen von ISAD(G) und EAD ist ein wichtiger Grund für das international
starke Interesse an EAD.
Archivare, denen eine hierarchischen Datenstruktur wie EAD implementieren wollen
und denen es an Kenntnissen über die mehrstufige Verzeichnung fehlt, werden
feststellen, dass ISAD(G) einen wichtigen Rahmen für die Entscheidungsfindung im
Zusammenhang mit EAD bieten kann.
19
ISAD(G), Regel I.2.
A.d.Ü.. englische Fassung: „inventory“. „Inventory“ ist definiert als ein Findbuch, das mindestens eine Auflistung der Serien zu
einem Bestand enthält. Vgl. A glossary of Archival and Records Terminology, ed. by Richard Pearce-Moses,
<http://www.archivists.org/glossary/term_details.asp?DefinitionKey=390>.
**
A.d.Ü.: original: „register“. „Register“ ist definiert als Dokument, dass eine Liste von Einträgen enthält. Vgl. A glossary of
Archival and Records Terminology, <http://www.archivists.org/glossary/term_details.asp?DefinitionKey=1053>. Inventory und
register sind spezielle Formen von Findmitteln (finding-aid).
20
Gegenüberstellung der Datenelemente von ISAD(G) und EAD siehe Anhang B.
*
21
1.3. Die Entwicklung der archivischen Informationstechnik im Internet21
Die Entwicklung von EAD zusammen mit der Wachstum des Internets versetzt
nunmehr Archive weltweit in die Lage, Informationen über ihre Bestände leichter zu
verbreiten. Es lassen sich Systeme erstellen, mit deren Hilfe Benutzer alle Bestände
eines einzigen Archivs (und bei Verbundsystemen sogar von mehreren Archiven)
durchsuchen können, um Quellen zu jedem beliebigen Interessengebiet zu ermitteln
und aufzufinden. Außerdem können Benutzer in einigen Umgebungen jetzt im Falle
einer breit angelegten Suche nach Themen oder Namen über Hyperlinks von der
MARC-Titelaufnahme zu EAD-Findbüchern und weiter zu Digitalisaten von Archivgut
navigieren.
Diese neue Entwicklung bietet uns die Gelegenheit, neue Konzepte dafür zu
entwickeln, wie wir Benutzern – sowohl langjährigen Archivnutzern als auch ganz
neuen Zielgruppen – Informationen liefern können. Die Archivare haben schnell
erkannt, dass das Internet die Möglichkeit zur elektronischen Verbreitung von
Findbüchern bot, und viele richteten rasch Gopher zu diesem Zweck ein. Die
Ergebnisse dieser Versuche waren verlockend, aber letztlich entmutigend. Die
Gophersoftware konnte Findbücher nur als einfache Textdateien verwalten, denen es
an struktureller und typografischer Formatierung sowie an wichtigen Besonderheiten
wie z. B. Fußnoten fehlte. Dadurch wurde es schwierig, in umfangreicheren
Findbüchern zu navigieren. Dazu kam, dass es keinen Mechanismus gab, um die
Findbücher mit entsprechenden MARC-Titelaufnahmen zu verknüpfen. Benutzer, die
den Online-Katalog eines Archivs durchsuchten, mussten daher den Katalog
verlassen und sich auf der Gopherseite anmelden, um zu prüfen, ob es ein Findbuch
gab (für Personen, die auch nach der Bereitstellung von Web-gestützten OnlineKatalogen noch Gopher verwendeten, entfiel dieses besondere Problem).
Die Entstehung des World Wide Web Anfang der 1990er Jahre bot gegenüber
Gopher bedeutende Vorteile. Die Hyper Text Markup Language (HTML), die SGML
DTD (Dokumenttyp-Definition für Standard Generalized Markup Language), in der
Web-gestützte Dokumente z. Z. kodiert werden, lieferte den Mechanismus zur
Darstellung von Findbüchern mit zusätzlichen typografischen Nuancen und
Navigationstechniken. Das Wesen des World Wide Web – die Fähigkeit zum
Erzeugen von dynamischen Hyperlinks zwischen Dokumenten, die an verschiedenen
Orten gespeichert sind – und die Entwicklung von Web-gestützten Online-Katalogen
ermöglichten es, eine MARC-Titelaufnahme mit den dazugehörigen Findbüchern zu
verknüpfen.
Es wurde jedoch bald erkennbar, dass auch HTML erhebliche Grenzen hat. Das
Hauptproblem besteht darin, dass HTML nur die prozedurale Kodierung zur
Erleichterung einer verbesserten Anordnung und Gestaltung bietet. Logische
Dokumentstrukturen oder -inhalte lassen sich nicht aussagekräftig kodieren.
Beispielsweise lassen sich verschiedene Schriftgrößen für Überschriften oder
Kursivdruck für formale Titel mit Hilfe von HTML mühelos darstellen. HTML kann
jedoch keine „scope and content note“ von einer Kurzbiografie, keinen
Personennamen von einem geografischen Namen oder einen Titel von einem Datum
unterscheiden. Daher ist HTML nicht in der Lage, die komplexen Inhalte und
Strukturen von archivischen Findbüchern sichtbar darzustellen oder dauerhaft zu
21
Die Abschnitte 1.3 bis 1.5 stützen sich teilweise auf Daniel V.: Encoded Archival Description. The Development of an
Encoding Standard for Archival Finding Aids, in: American Archivist 60 (1997) 2, S. 268-283.
22
speichern. Das bedeutet, dass HTML weder eine technisch hochentwickelte Suche
oder Navigation ermöglichen noch die Beständigkeit von Daten sicherstellen oder die
künftige Migration von Daten erleichtern kann. Dazu kommt noch, dass Grundregeln
und -struktur von HTML zwar verhältnismäßig stabil sind, die zugehörige
Entwicklungsumgebung jedoch recht flüchtig und eigentümlich ist und nicht die
Verbindlichkeit eines Standards besitzt, die für erfolgreichen Informationsaustausch
und Datenmigration von wesentlicher Bedeutung ist.
23
1.4. Warum SGML?
Bei seiner Tätigkeit als Leiter des Berkeley Finding Aid Project, dem Vorläufer von
EAD, stellte Daniel Pitti fest, dass SGML einen viel versprechenden Rahmen zur
Überwindung der Mängel von Gophern und HTML darstellte, um archivische
Findbücher über das Internet zu verbreiten. SGML ermöglicht nicht nur die
vollständige strukturelle und inhaltliche Kodierung. In ihrem inhärent hierarchischen
Ansatz zur Datenstruktur bildet sie auch die Informationshierarchien ab, die seit
langem eine grundlegende Eigenschaft der archivischen Erschließung sind.
Außerdem haben Archivare durch die frühere Implementierung von Standards wie
MARC AMC und den verschiedenen, bereits genannten nationalen Inhaltsstandards
den Wert von gemeinsam genutzten offenen Standards kennen gelernt. Daher
musste es SGML sein, weil SGML ein Standard (ISO 8879) und offen ist (in dem
Sinne, dass sie unabhängig von einer bestimmten gruppenspezifischen oder
proprietären Softwareanwendung ist), und man kann eine SGML-Anwendung
entwerfen, die sich speziell auf die Eigenschaften von archivischen Findbüchern
konzentriert, anstatt ein in höherem Maße generalisiertes, für einen anderen
Dokumenttyp entworfenes Schema nutzen zu müssen.
Ein Beispiel für ein besonders generalisiertes Schema ist die Text Encoding Initiative
(TEI), ein internationales Gemeinschaftsprojekt zur Entwicklung einer SGML-DTD für
wissenschaftliche Texte.22 Pitti prüfte TEI genau, weil es sich um eine bedeutende
geisteswissenschaftliche DV-Initiative handelte. Schließlich stellte er jedoch fest,
dass ihre Ziele mit den Bedürfnissen von Findbüchern nicht vereinbar waren. Das
kam daher, dass TEI zur Kodierung von literarischen und anderen Texten gedacht
war, und solche Dokumente unterscheiden sich erheblich von der Art beschreibender
Metadaten, wie es archivische Findbücher sind. Daher enthält TEI viele Elemente,
die in EAD nicht benötigt werden. Noch wichtiger war: für Findbücher benötigte
Schlüsselelemente stehen in TEI nicht zur Verfügung. EAD wurde jedoch so
gestaltet, dass es mit TEI so weit wie möglich kompatibel war. Die grundlegende TEIHeader-Struktur wurde in EAD aufgenommen,23 und die Elementnamen und Attribute
weichen so wenig wie möglich voneinander ab. Darüber hinaus hat es eine aktive
Kommunikation zwischen den Entwicklern von EAD und TEI gegeben, um zu
gewährleisten, dass EAD weiterhin ein kompatibler Teil des größeren Universums
von geisteswissenschaftlichen DV-Initiativen bleibt.
Wie oben erwähnt, ist SGML inhärent hierarchisch. EAD spiegelt die Fähigkeit einer
gut entworfenen SGML-DTD wider, die intellektuellen und physischen Teile eines
vorwiegend textgestützten Dokuments als gesonderte Felder oder Elemente zu
identifizieren und dann Bestandteile oder Subelemente darin zu schachteln. Diese
Verschachtelungsfähigkeit ermöglicht es Kodierern eines Findbuchs (und damit auch
Benutzern, die das kodierte Findbuch online nutzen), zuerst mit Elementen auf hoher
Ebene zu arbeiten, die einen Überblick über das Findbuch bieten, und dann nach
und nach detailliertere Teile zu entfalten. Umgekehrt kann es eine spezielle BrowserSoftware ermöglichen, ein EAD-Findbuch unmittelbar auf Einzelstück- oder
Aktenebene zu durchsuchen und dann die Suche zu erweitern oder in einen
bestimmten Zusammenhang zu stellen, indem er andere Einzelstücke untersucht, die
auf gleicher Ebene enthalten sind, oder sich in der Hierarchie weiter nach oben zu
22
23
Weitere Angaben siehe die Homepage der Text Encoding Initiative, <http://www-tei.uic.edu/orgs/tei/>.
Der EAD-Header <eadheader> ist in Abschnitt 3.6.1 erläutert.
24
bewegen, z. B. zu Elementen wie „Scope and content note“ für eine bestimmte Serie
oder einen ganzen Bestand.
Der Grundsatz der Vererbung ermöglicht es SGML den in der Hierarchie weiter unten
stehenden Elementen, die in weiter oben stehenden Elementen enthaltenen
Informationen zu vererben. Das entspricht der ISAD(G)-Regel zur der
Nichtwiederholung von Informationen.24 Das bedeutet, dass bei der Kodierung
Erschließungsdaten, die bereits auf höherer Ebene in das Findbuch erfasst wurden,
nicht wiederholen müssen. Die Vererbung ist in Kapitel 3 und insbesondere in den
Abbildungen in Abschnitt 3.5.2.5 erläutert.
24
ISAD(G), Regel 2.4.
25
1.5. Was ist XML?
1996 gründete das World Wide Web Consortium die XML-Arbeitsgruppe, um
mehrere Spezifikationen erstellen zu lassen, damit auch andere SGML-DTD als
HTML im Web eingesetzt werden konnten.25 Dies war erforderlich, weil HTML eine
inhaltlich ausgerichtete Kodierung von Daten nicht unterstützen konnte.
Um über das Web verbreitet werden zu können, vereinfacht XML einige komplexe
Züge von SGML. EAD enthielt nur wenige komplexe Funktionen dieser Art und ließ
sich mühelos so gestalten, dass es zu XML passte. Der volle Umfang der
Auswirkungen von XML auf die Implementierung von EAD ist in Abschnitt 4.3.2 und
in Kapitel 6 behandelt.
XML wurde 1998 vom World Wide Web Consortium als Web-Standard eingeführt.
Version 5.0 des Browsers Internet Explorer von Microsoft unterstützt XMLDokumente, und Anfang 1999 hatte Netscape XML in die Beta-Versionen seiner
nächsten Browser-Ausgabe eingearbeitet.
25
Die offizielle Bezeichnung für die XML-Spezifikation lautet Extensible Markup Language.
26
1.6. Beziehung zwischen MARC und EAD
Wie bereits in Abschnitt 1.2 erwähnt, sind MARC-Titelaufnahmen für Archivgut
Zusammenfassungen von detaillierteren Informationen, die im Allgemeinen in
Findbüchern enthalten sind. Diese Zusammenfassung ist erforderlich, weil eine
MARC-Titelaufnahme eine Längenbegrenzung hat, die nur eine Beschreibung auf
Bestandsebene ermöglicht. Viele Archivare haben sich deshalb die Frage gestellt, ob
die Katalogisierung mit MARC redundant oder unnötig geworden ist, da es jetzt EAD
gibt. Dies ist zwar eine logische Frage. Es ist jedoch zu beachten, dass die
Aufnahme von Bestandsangaben in integrierten Online-Katalogen es vielen
Benutzern ermöglicht, archivische Quellen viel leichter zu finden, als es sonst der Fall
wäre. Bis die Recherchemöglichkeiten für Archivgut auf Cross-Domain-Ebene weiter
als derzeit entwickelt sind, kann der Wert von archivischen Informationen (so kurz
gefasst diese auch sein mögen) in diesen integrierten Systemen, um die Nutzer von
Bibliothekskatalogen auf Primärquellen hinzuweisen, gar nicht hoch genug
eingeschätzt werden.
Einige Fragen zur Koexistenz von MARC und EAD rühren von zwei Aspekten der
Implementierung von MARC her, die einigen Archivaren Sorgen bereitet haben:
erstens die Tatsache, dass eine MARC-Titelaufnahme nur eine Zusammenfassung
und nicht das vollständige Findbuch darstellt, und zweitens die Tatsache, dass die
Erstellung einer MARC-Titelaufnahme einen zusätzlichen ressourcenintensiven
Arbeitsschritt bei der Erschließung von Archivgut bedeutet. EAD versucht diese
beiden Probleme zu lösen, indem es die Beziehungen zwischen den MARCDatenelementen und den zugehörigen Entsprechungen innerhalb der kodierten
Findbücher identifiziert. Dies wird durch die Spezifizierung von Encodinganalogs für
EAD-Elemente erreicht, die unmittelbar bestimmten MARC-Feldern entsprechen
(Näheres siehe Abschnitt 3.5.3.1).
Die Verwendung von Encodinganalogs bietet für Archive die Möglichkeit, die EADKodierung und die Katalogisierung mit MARC in einem einzigen Arbeitsschritt
zusammenzufassen, indem ausgehend von EAD automatisch eine elementare
MARC-Titelaufnahme erzeugt wird. Auch das Gegenteil ist möglich, indem eine
MARC-Titelaufnahme in ein EAD-Findbuch importiert wird, um
Erschließungsangaben auf Bestandsebene sowie kontrollierte Zugriffspunkte zu
einem vorhandenen Bestandsverzeichnis∗ hinzuzufügen. Beide Arbeitsschritte lassen
sich mit Hilfe eines Programmskripts (weitere Angaben siehe Abschnitt 4.3.4)
durchführen. Eine aus einem EAD-Findbuch exportierte MARC-Titelaufnahme könnte
in ein größeres MARC-System hochgeladen werden, z. B. RLIN, OCLC oder einen
Online-Katalog vor Ort. Archive, die dieses Verfahren anwenden, haben dann immer
noch die Möglichkeit, die sich daraus ergebenden MARC-Titelaufnahmen weiter zu
bearbeiten, und zwar unter Verwendung der gewöhnlich verwendeten MARCgestützten Bearbeitungssoftware. Automatische Abläufe für diese Prozesse sind
noch nicht entwickelt worden. Wenn Sie diese Möglichkeit näher erkunden möchten,
∗
A.d.Ü: Im Originaltext wird der Begriff „container list“ verwendet. „Container list“ wird als Teil des Findbuchs definiert, in dem
grob der Inhalt eines Behälters angegeben ist. Die Liste kann den Titel der im Behälter enthaltenen Serie aufführen oder das
erste und letzte Einzelstück, ohne die Einzelstücke oder Verzeichnungseinheiten einzeln zu benennen. Container list
unterscheidet sich damit von dem ebenfalls existierenden Begriff folder list, einer Liste, die den gesamten Inhalt eines Behälters
beschreibt. Zu den Begriffen vgl. A Glossary of Archival and Records Terminology,
<http://www.archivists.org/glossary/term_details.asp?DefinitionKey=2645>. Der Begriff wird im Folgenden mit
Bestandsverzeichnis übersetzt. Das Bestandsverzeichnis ist zu verstehen als eine Auflistung aller Verzeichnungseinheiten
eines Bestandes gemäß seiner Klassifikation und damit Hauptbestandteil eines Findbuchs. Vgl. Anweisung für die archivarische
Tätigkeit des Bundesarchivs, Richtlinien für die Erschließung von Schriftgut, Stand 18.12.2003, Abschnitt 5.6., S. 62.
27
seien Sie jedoch auf die MARC-EAD-Gegenüberstellung in Anhang B, mit deren Hilfe
Sie Konkordanzen zwischen Datenelementen identifizieren können, hingewiesen.
EAD bietet zwar eine weitaus flexiblere und detailliertere Datenstruktur für die
archivische Erschließung als MARC. EAD ist jedoch ein Datenstrukturstandard und
kein Dateninhaltsstandard und schreibt daher keine unbedingt einzuhaltenden
Inhaltsformate für seine Elemente vor. Möglicherweise stellt dies einen erheblichen
Nachteil für den Informationsaustausch dar. Eine Standardisierung des Inhalts der
beschreibenden EAD-Elemente lässt sich jedoch erreichen, wenn Archive oder
Archivverbünde spezielle Dateninhaltskonventionen oder “gängige Arbeitsverfahren”
entwickeln und sich daran halten. Der Inhalt von EAD-Elementen mit
Encodinganalogattributen kann auf Grundlage eines Dateninhaltsstandards wie RAD
oder APPM oder eines Datenwertstandards wie Library of Congress Name Authority
File (LCNAF) oder Library of Congress Subject Headings (LCSH) spezifiziert werden.
28
1.7. Sonstige Informationen zu EAD
Außer der offiziellen EAD-Dokumentation, die die Tag-Library und den
Anwenderleitfaden umfasst, stehen für Personen, die gern mehr über EAD erfahren
möchten, noch andere Quellen zur Verfügung.
1.7.1. Literatur
Die zum Thema EAD veröffentlichte Literatur nimmt langsam zu. Anfang 1999
befanden sich Sonderausgaben mehrerer Bibliotheks- und Museumsfachzeitschriften
im Planungsstadium. Die erste bedeutende Artikelreihe über EAD wurde in der
Sommer- und der Herbstausgabe des American Archivist (Bd. 60, Nr. 3 und 4)
veröffentlicht. Es handelte sich dabei um Sonderhefte, die ausschließlich das Thema
EAD behandelten.26
Die Sommerausgabe (Context and Theory) enthält sechs Artikel, die von Mitgliedern
des EAD-Entwicklungsteams verfasst wurden und Hintergrundinformationen zu
folgenden Themen enthalten: Aspekte der Geschichte der archivischen Erschließung
und von Informationssystemen, die den Kontext darstellen, in dem EAD entwickelt
wurde; die Beschaffenheit von strukturierten Informationen im Allgemeinen und der
Struktur von EAD im Besonderen; organisatorische und technische Fragen, die vor
der Implementierung von EAD bedacht werden müssen; schließlich die Bedeutung
von EAD als neuem Standard für die archivische Erschließung.27
Die Herbstausgabe (Case Studies) enthält sechs Fallstudien, die von den “ersten
Anwendern” von EAD erstellt wurden, d. h. von Archivaren bei Institutionen, die EAD
implementierten, als es sich noch in der Entwicklung befand, und zwar vor der
Veröffentlichung der DTD Version 1.0 im August 1998. In der ersten Fallstudie ist der
Prozess des „Neustrukturierung“ von Findbüchern beschrieben, um diese der EADDatenstruktur anzupassen und das Verständnis der Benutzer im Web zu erhöhen.
Dieser Artikel ist u. U. für einen Archiv, das die Implementierung von EAD in Betracht
zieht, als Einstieg am besten geeignet.28 Die anderen fünf Artikel enthalten
Einzelheiten zu Software, Hardware und Kodierungsmöglichkeiten, die von
bestimmten Institutionen bei der Implementierung von EAD angewendet wurden. Die
Fallstudien sind möglicherweise von besonderem Interesse, nachdem Sie Kapitel 1
bis 3 des Anwenderleitfadens gelesen haben, da die Bedeutung der von den
verschiedenen Institutionen getroffenen Entscheidungen dann besser verständlich
ist.
1.7.2. Webseiten
Von den vielen Seiten im World Wide Web, die nützliche Informationen über EAD
enthalten, sind die beiden folgenden Webseiten von besonderer Bedeutung:
26
Die Artikel in diesen beiden Ausgaben wurden wie folgt neu herausgegeben: Dooley, Jackie M. (Ed.): Encoded Archival
Description. Context, Theory, and Case Studies, Chicago 1998.
27
Mehrere dieser Artikel dienten bei der Erstellung verschiedener Abschnitte des Anwenderleitfadens als Grundlage. Siehe die
betreffenden Fußnoten.
28
Meissner, Dennis: First Things First: Reengineering Finding Aids for Implementation of EAD, in: American Archivist 60 (1997)
3, S. 372-387.
29
The Encoded Archival Description Official Web Site, die von der Library of Congress
gehostet wird, ist der offizielle Bereitstellungsort der EAD-DTD-Dateien. Diese Seite
enthält auch Hintergrundinformationen zur Entwicklung von EAD, Hinweise zur
Anmeldung als Abonnent der EAD Listserv sowie Beschreibungen wichtiger EADImplementierungsseiten einschließlich bedeutender Gemeinschaftsprojekte. Die
Seite ist zugänglich auf: <http://www.loc.gov/ead/>.
The EAD Help Pages, die vom EAD Roundtable of the Society of American Archivists
betreut werden, enthalten eine große Vielfalt an nützlichen Informationen und
zahlreiche Links zu anderen hilfreichen Seiten. Im Besonderen sind enthalten:
Werkzeuge und Hilfedateien, ferner Erstellungs- und Veröffentlichungssoftware, die
von verschiedenen EAD-Implementierern genutzt wird; Literatur über SGML und
XML sowie eine Hilfe-Einrichtung, in der Anwender um Hilfestellung bei der Lösung
spezieller Fragen bitten können. Die Seite ist zugänglich auf:
<http://jefferson.village.virginia.edu/ead/>.
Weitere gut gepflegte Webseiten zu EAD, SGML und XML sind in der Bibliografie in
Anhang G aufgeführt.
1.7.3. Aus- und Weiterbildungsmöglichkeiten
1996 begann die Research Libraries Group damit, den Mitarbeitern der beteiligten
Bibliotheken EAD-Workshops anzubieten. 1997 tat die Society of American Archivists
das Gleiche. Bei diesen zweitägigen Workshops werden Archivare in die wichtigsten
Struktur- und Inhaltselemente von EAD eingeführt und nehmen an zahlreichen
praktischen Übungen teil, die die Lehrgangsteilnehmer befähigen, in ihren Archiven
ihre Findbücher an EAD anzupassen. Für einige SAA-Workshops ist eine offene
Anmeldung möglich (auf diese Veranstaltungen wird im zweimonatlich
erscheinenden Newsletter Archival Outlook29 und anderen archivfachlichen Medien
hingewiesen). Andere Workshops werden dagegen von regionalen
Archivgesellschaften, lokalen Konsortien oder Einzelinstitutionen finanziert.30
Außerdem bietet die University of Virginia als Teil ihres jährlichen, im Sommer
stattfindenden Rare Book School Program einen fünftägigen EAD-Lehrgang an.31
Daneben haben auch andere Organisationen EAD-Lehrgänge finanziert.
Wie es meist in der Erwachsenenbildung der Fall ist, kann die Teilnahme an einem
Workshop besonders hilfreich für das Kennenlernen eines neuen Standards sein,
insbesondere eines Standards, der sich mit seiner Informationstechnik auf dem
neuesten Stand der Technik stützt. Das Zusammenwirken eines gut informierten
Ausbilders und einer Gruppe von Lehrgangsteilnehmern, die wissbegierig sind und
ihre Erfahrungen gern miteinander teilen, kann dazu beitragen, viele Aspekte von
EAD klarer erscheinen zu lassen und Vertrauen in die eigenen Fähigkeiten
aufzubauen.32 Andererseits ist unbedingt zu beachten, dass einige Zeit vergehen
muss, bis man einen neuen Standard voll und ganz beherrscht. Ein Workshop kann
lediglich die Grundlagen vermitteln und zum richtigen Einstieg verhelfen. Der EADAnwenderleitfaden kann den Unterricht unterstützen und ergänzen und den
29
Archival Outlook, ed. by Society of American Archivists erscheint sechsmal jährlich.
Um weitere Informationen zur Betreuung eines EAD-Workshops zu erhalten, ist folgende Stelle zu kontaktieren: SAA
Education Office. E-Mail: [email protected]. Tel.: 312/922-0140. Fax: 312/347-1452. Postanschrift: Society of American
Archivists, 527 S. Wells Street, 5th floor, Chicago, IL 60607 USA.
31
Informationen stehen online zur Verfügung, <http://www.virginia.edu/oldbooks/>.
32
Weitere Fragen zur Ausbildung werden aus verwaltungstechnischer Sicht in Abschnitt 2.5.2 behandelt.
30
30
Anwender zu weiteren Quellen hinführen, die ihm den Erwerb von zunehmend
anspruchsvollen Kenntnissen ermöglichen.
31
Kapitel 2: Verwaltungstechnische Überlegungen
2.1. Einführung................................................................................................................................... 33
2.2. Aufgaben und Zielsetzungen ...................................................................................................... 34
2.3. Ressourcen................................................................................................................................. 36
2.4. Planung....................................................................................................................................... 37
2.5. Wichtige Tätigkeiten bei der Implementierung ........................................................................... 38
2.5.1. Wahl und Implementierung von Hard- und Software ........................................................... 38
2.5.2. Personalqualifikation ............................................................................................................ 39
2.5.3. Kodierung neuer Findbücher................................................................................................ 39
2.5.4. Konversion vorhandener Findbücher ................................................................................... 40
2.5.4.1. Priorisierung................................................................................................................... 41
2.5.4.2. Änderungsstrategien ..................................................................................................... 42
2.5.4.3. Konversionsverfahren.................................................................................................... 42
2.5.5. Sonstige laufende Tätigkeiten.............................................................................................. 44
2.5.6. Öffentlichkeitswirksame Maßnahmen .................................................................................. 44
2.6. Fremdvergabe............................................................................................................................. 46
2.7. Kooperationsprojekte .................................................................................................................. 47
32
2.1. Einführung33
Bei der Implementierung von EAD müssen die gleichen programmatischen und
verwaltungstechnischen Fragen überdacht werden, die bei der Evaluierung jedes
neuen Vorhabens, besonders einer neuen Technologie auftreten. Die Entscheidung,
EAD in das Werkzeugarsenal eines Archivs zur Erstellung und Veröffentlichung von
Findbüchern aufzunehmen, macht es erforderlich, sich bestimmten grundlegenden
verwaltungstechnischen Fragen zu stellen und diese zu bedenken:
•
•
•
•
•
•
•
Potential der neuen Technik für die Erfüllung der Aufgaben und Zielsetzungen
der Institution
Verfügbarkeit von Ressourcen, möglicherweise aus neuen Quellen
Sorgfältige Planung vor der Implementierung
Vorhandensein bestimmter Hard- und Software für EAD
Personalbedarf für die Kodierung neuer Findbücher und die Konversion von
Altdaten, einschließlich Ausbildungsbedarf
Möglichkeiten bei der Gestaltung von Arbeitsabläufen
Möglichkeiten der Fremdvergabe und Kooperationsprojekte
Neben den Anleitungen in Kapitel 2 kann die Prüfliste für die Implementierung in
Anhang D den Archiven bei der Planung für die EAD-Implementierung von Nutzen
sein.
33
Dieses Kapitel beruht teilweise auf Fox, Michael: Implementing Encoded Archival Description: An Overview of Administrative
and Technical Considerations, in: American Archivist 60 (1997) 2, S. 330-343.
33
2.2. Aufgaben und Zielsetzungen
EAD ist eine recht komplexe Technologie. Ihre Anwendung ist nur dann sinnvoll,
wenn der mögliche Nutzen den Zielsetzungen der Institution entspricht. Um dies zu
beurteilen, ist es u. U. von Vorteil, sich auf die in Kapitel 1 beschriebenen
Haupteigenschaften von EAD zu konzentrieren. Um diese Überlegungen
zusammenzufassen, wird EAD wie folgt definiert:
•
•
•
Ein Datenstrukturstandard für Findbücher, der eine vielfältige Nutzung der
darin enthaltenen Informationen, ihren Austausch und ihre langfristige
Zugänglichkeit ermöglicht
Ein Datenübertragungsformat, mit dessen Hilfe Archive Findbücher
elektronisch – u. a. über das Internet – für auswärtige Benutzer und Benutzer
vor Ort zugänglich machen können
Eine Technologie, die sich auf Standards stützt, plattformunabhängig ist und
leistungsfähige Werkzeuge für die Recherche, Darstellung und Navigation
einsetzt
Die Antworten auf einige zielgerichtete Fragen zur vorhandenen bzw. möglichen
Zielgruppe des Archivs sowie zur Art und Weise, in der die vorhandenen Findbücher
erstellt und genutzt werden, bieten Anhaltspunkte für die Entscheidungsfindung.
Ehrlichkeit ist erforderlich. Personen, die schon früher technisch hochentwickelte
Erschließungsstandards bzw. -techniken angewandt haben, u. U. insbesondere
MARC AMC, dürfte dieser Prozess jedoch vertraut sein.
•
•
•
•
•
•
•
•
•
•
•
Ist die digitale Verbreitung sowohl von Metadaten zu Beständen als auch von
Digitalisaten von Archivgut selbst eine wichtige Zielsetzung Ihrer Institution?
Wie könnte die Verbreitung von recherchierbaren elektronischen Inventaren
zu dieser Zielsetzung passen?
Sind auswärtige Benutzer eine Zielgruppe?
Ist es eine Priorität der Institution, neue Zielgruppen zu gewinnen, z. B. Lehrer
und Schüler?
Wer benutzt z. Z. die Findbücher?
Wie häufig und auf welche Weise werden die Findbücher genutzt (um
Kontextinformationen zu Beständen zu erhalten, um Signaturen zu ermitteln,
um Kopien für Benutzer herzustellen)?
Wie viele Findbücher gibt es?
In wie viel verschiedenen Formaten (sowohl inhaltlichen als auch technischen
Formaten) liegen diese Findbücher vor?
Wie würden Sie Ihre Findbücher in Bezug auf Nutzbarkeit, Qualität und
Vollständigkeit beurteilt werden?
Wären Sie bereit, Ihre Findbücher in ihrem aktuellen Zustand elektronisch
bereitzustellen, auch wenn sie nicht optimal sind?
Falls nicht, welches Ausmaß an Änderung wäre erforderlich?
Die Antworten auf solche Fragen dürften hilfreich dafür sein, festzustellen, ob die
langfristigen Vorteile von EAD die Mühen der Implementierung lohnen. Zusätzlich ist
sorgfältig zu bedenken, dass für viele Archive beim Einsatz von neuen Technologien
die Einhaltung von Standards ein zunehmend wichtiges strategisches Ziel ist.
Standards werden als Versicherung betrachtet, die Investitionen in Datenerstellung
und -technik schützen, da sie es ermöglichen, einen breiteren und vielfältigeren
34
Markt zu nutzen, während sie gleichzeitig die Möglichkeiten verbessern, Daten in
künftige Systeme zu migrieren (eine unausweichliche Notwendigkeit). Für
Entscheidungsträger wie Bibliotheks- und Archivdirektoren, die diesen Weg
eingeschlagen haben, liefert der von Archivaren und Bibliothekaren gewährleistete
Standardisierungsaspekt von EAD eine überzeugende Begründung für die
Einführung von EAD.
35
2.3. Ressourcen
Es genügt nicht, die Vorteile einer Implementierung von EAD zu beurteilen.
Besonders wünschenswerte Projekte müssen auch gegenüber anderen wichtigen
Aktivitäten abgewogen werden, wenn Prioritäten festgelegt und begrenzte
Ressourcen vorhanden sind. Solche Planungsentscheidungen unterliegen
zahlreichen örtlichen Einflussgrößen. Eine davon sind die relativen Kosten der
Implementierung selbst. Wie bei den meisten Vorhaben von Institutionen sind die
Hauptkosten Personalkosten. Wichtige Aufgaben sind in Abschnitt 2.5 kurz
beschrieben.
Die erforderlichen Investitionen in Hardware und -software hängen sehr stark von der
vorhandenen Ausstattung ab. Archive, die bereits in der Lage sind, Findbücher in
maschinenlesbarer Form zu erstellen und Informationen über das Internet zu
verbreiten, sind besonders geeignet, EAD-Kodierung zu implementieren.
Andererseits muss ein Archiv, das seine Erschließung noch nicht automatisiert hat
bzw. das World Wide Web für seine Dienstleistungsangebote noch nicht nutzt, stark
in Hard- und Software investieren, um EAD implementieren zu können. Solche
Institutionen müssen ggf. das Potential der EAD-Datenstruktur für die Verbesserung
der bestehenden Erstellungspraxis von Findbüchern nutzen und Partner für eine
gemeinschaftliche Implementierung von EAD suchen.
Die Kosten der Software zum Authoring von Findbüchern bewegen sich je nach
gewählter Vorgehensweise bei der EAD-Kodierung zwischen geringfügig und
erheblich. Die Software zur Veröffentlichung von EAD-Findbüchern weist ein breites
Kostenspektrum auf, je nachdem, welcher Lösungsansatz gewählt wird. Kapitel 4
und Kapitel 5 bieten ausführliche Informationen über Szenarios, die derzeit für die
Erstellung und Veröffentlichung von Findbüchern zur Verfügung stehen.
Die Implementierung einer neuen Technologie lässt sich eventuell für vorhandene
Ressourcen als Fass ohne Boden beschreiben. Trotzdem ist es wichtig, das
vorhandene Potenzial zum Einsparen von Ressourcen zu erkennen. Da EAD die
Elemente von Findbüchern definiert und wirksame Mittel zur Anordnung und
Darstellung dieser Elemente anbietet, können sich Anwender Kosten und Kraft
sparen, die aufgebracht werden müssten, wenn man die Findbuchgestaltung selbst
entwerfen müsste, ganz zu schweigen von den Einsparungen öffentlicher Gelder, die
die Qualitätsverbesserung von Findbüchern mitbringen kann. Diese Überlegungen
sind besonders für ein neues Archiv oder für ein Archiv, das seine Arbeitsweise
professionalisieren möchte, wichtig. Aber auch lange existierende Archive finden bei
EAD wahrscheinlich gute Anregungen zur Erhöhung der Gesamteffizienz ihrer
Erschließungsverfahren.
Darüber hinaus haben viele Archive eindrucksvoll gezeigt, dass die EADImplementierung enorme Möglichkeiten eröffnet, neue Finanzierungsquellen
aufzuspüren. Die Anwendung von EAD hat Archiven eine standardisierte Möglichkeit
zur Integration von Findbüchern (und von digitalisiertem Archivgut) in digitale Archive
und Bibliotheken gegeben. Dadurch hat sich das öffentliche Profil von derartigen
Institutionen verbessert, und potenzielle Geldgeber haben Vertrauen in die
Nachhaltigkeit ihrer Investitionen gewonnen.
36
2.4. Planung
Wenn kostspielige Missgriffe vermieden werden sollen, ist Planung äußerst wichtig.
Deshalb sind vor der Kodierung des ersten Findbuchs zahlreiche Probleme zu lösen.
In allen sechs Fallstudien, die von den ersten EAD-Anwendern verfasst und in der
1997er Herbstausgabe des American Archivist34 veröffentlicht wurden, wird
nachdrücklich von der Notwendigkeit zu planen gesprochen, und eine wohlüberlegte
Überprüfung des Status quo ist ein guter Anfang. Dies sind einige der Fragen, die
sich für potenzielle Anwender stellen:
•
•
•
•
Welche Rolle spielen die Findbücher im Nachweis- und Zugriffssystem Ihrer
Institution?
Wirken Titelaufnahmen zu Beständen und Findbücher bei einer integrierten
Suche zusammen?
Überlappt sich ihr Inhalt auf ergänzende und nicht auf redundante Weise?
Werden sie angesichts ihrer inhärenten Wechselbeziehung so effizient wie
möglich erstellt?
Da die Einführung einer neuen Technologie möglicherweise zu vielfältigen
Veränderungen in den Arbeitsabläufen führt, ist eine breite Überprüfung des
gesamten Erschließungsumfeldes durchaus lohnend. Vielleicht stellen wir z. B. fest,
dass die Möglichkeit, dass Benutzer auf tief erschlossene elektronische Findbücher
zugreifen können, es uns ermöglicht, die Länge und Detailtiefe von MARCTitelaufnahmen auf Bestandsebene neu zu durchdenken.
Was jedoch am wichtigsten ist: EAD bietet die Möglichkeit, Struktur und Darstellung
der Findbücher an sich zu überdenken. Meissner hat beschrieben, wie die Minnesota
Historical Society vor dem Hintergrund der Struktur und den Elementen von EAD ihre
Findbücher einer Bewertung unterzogen hat, bevor sie mit der Auszeichnung
begann.35 Zu diesem Prozess gehörte es, dass grundlegende Fragen zum Zweck
von Findbüchern, zu ihrer Verständlichkeit für Benutzer ohne die Hilfe von
Archivaren, zu ihrer Beziehung zu MARC-Titelaufnahmen auf Bestandsebene sowie
zu ihrem Erscheinungsbild gestellt wurden. Diese Aspekte wurden im Hinblick auf
den Informationsgehalt der Findbücher ausgewertet, ferner hinsichtlich der
Findbuchwahrnehmung durch Benutzer im Lesesaal und wie sich der Fernzugriff auf
die Findbuchbenutzung auswirken könnte. Praktisch jedes Archiv wird feststellen,
dass es sich einem solchen Prozess unterziehen muss. Es muss ermitteln, wie seine
Findbücher zu EAD passen, die relevanten Elemente heraussuchen und ihre
Anordnung innerhalb eines Findbuchs optimieren. Darüber hinaus kann eine
gründliche Prüfung von EAD Hinweise auf neue Verfahren liefern, wie Daten, die bis
jetzt in einer fast ausschließlich lokalen Umgebung nicht benötigt wurden, verarbeitet
und dargestellt werden können.
34
Neu: Dooley, Jackie M. (Ed.): Encoded Archival Description. Context, Theory, and Case Studies, Chicago 1998.
Meissner, Dennis: First Things First: Reengineering Finding Aids for Implementation of EAD, in: American Archivist 60 (1997)
3, S. 372-387.
35
37
2.5. Wichtige Tätigkeiten bei der Implementierung
Niemand, der in der Verwaltung tätig ist, wird davon überrascht sein, dass für die
EAD-Implementierung die Personalkosten der größte Ausgabeposten eines Archivs
sein werden. Auch sollte verständlich sein, dass die tatsächlichen Kosten – da sie
sich besonders nach den örtlichen Gegebenheiten richten – hier nicht aufgeführt
werden können. Dafür werden die wichtigsten Tätigkeiten beschrieben, die ggf. im
Zusammenhang mit der Implementierung anfallen, um einen Anhaltspunkt zur
Ermittlung der Arten von Personalausgaben zu geben, die u. U. notwendig sind. Die
vollständige Beschreibung dieser Aktivitäten wirkt zunächst vielleicht unermesslich
oder sogar entmutigend und übersteigt möglicherweise die Möglichkeiten vieler
Archive. Mit Bedacht und Planung sind die Aufgaben jedoch zu bewältigen.
2.5.1. Wahl und Implementierung von Hard- und Software
Mitarbeiter müssen die Erfordernisse an Hardware und Software beurteilen und
sodann die Werkzeuge wählen, beschaffen und installieren. Wie in Kapitel 4 und
Kapitel 5 beschrieben, gibt es viele Möglichkeiten zur Erstellung von EAD-kodierten
Findbüchern und für deren Bereitstellung für Benutzer. Da bis jetzt noch keine
betriebsbereiten Systeme zur Verfügung stehen,36 müssen die Archive ihre Systeme
selbst aus einem Gemisch von Komponenten zusammensetzen, und es dauert eine
gewisse Zeit, um die verfügbaren Möglichkeiten zu beurteilen und Entscheidungen
zu treffen. Wie es bei der Technik immer der Fall ist, wird dieser Prozess durch die
rasche Entwicklung auf dem IT-Markt zusätzlich verkompliziert. Die Wahl einer
geeigneten Software ist damit wie das Schießen auf ein bewegliches Ziel.
Soll die Implementierung von EAD im Rahmen eines gemeinsamen Projekts
mehrerer Archive oder eines anders gearteten Gemeinschaftsvorhabens erfolgen,
müssen einerseits die für die Entscheidungsfindung in einem
Gemeinschaftsvorhaben entstehenden gemeinsamen Kosten berücksichtigt werden.
Einerseits müssen voraussichtlich zahlreiche externe Fachleute zu Rate gezogen
werden, andererseits kann man durch die gemeinsame Nutzung von Hard- und
Software und im Bereich der Systemadministration Kosten einsparen.
Technologiegestützte Vorhaben sind immer dynamisch und unterliegen ständiger
Beurteilung und Überarbeitung. Je nach den gewählten Optionen37 bewegt sich das
Spektrum der technischen Fachkenntnisse, die für die elektronische Verbreitung von
Findbüchern erforderlich sind, zwischen bescheiden und umfangreich. Archivare sind
findige Leute, und viele, die EAD am Anfang der Entwicklung implementiert haben,
sind ihre Vorhaben mit vorhandenem Personal angegangen, das dabei neue
Kenntnisse erworben hat. Archive, denen eigenes IT-Personal unterstützend zur
Verfügung steht, u. U. aus einer anderen Abteilung der Institution, können diese
Ressourcen möglicherweise nutzen, insbesondere im Hinblick darauf, dass das
Archiv an einem breiteren Vorhaben zur Entwicklung von digitalen Bibliotheken
beteiligt wird. Der Kauf von externen Dienstleistungen ist oft eine gangbare
Alternative, besonders für routinemäßige Tätigkeiten wie die Konfiguration von
Arbeitsplatzrechnern und Servern oder die Installation und Konfiguration von
36
Die Software „Internet Archivist”, erhältlich bei Interface Electronics, scheint als betriebsbereites System vielversprechend zu
sein (wenn auch einige wünschenswerte Funktionen eines solchen Systems im Frühjahr 1999 noch nicht installiert waren).
Weitere Informationen sind auf der Webseite der Firma zu finden, <http://www.interface.com/ead>. Weitere Angaben siehe
Abschnitt 4.2.2.2.
37
Siehe Abschnitt 5.2, in dem einige Optionen beschrieben sind.
38
Standardsoftware wie z. B. Web-Browsern. Suchmaschinen für SGML-Datenbanken
sind jedoch Fremdpersonal u. U. weniger vertraut. Derartige Dienstleistungen sind
daher möglicherweise schwieriger zu finden oder kostspieliger zu erwerben.
2.5.2. Personalqualifikation
Der Bedarf an Personalaus- und –weiterbildung kann bei der Einführung eines neuen
technischen Standards leicht unterschätzt oder übersehen werden. Die Mitarbeiter,
die mit EAD arbeiten sollen, müssen nicht nur gute Kenntnisse von Struktur und
Inhalt von EAD an sich erwerben, sondern auch die Anwendung spezieller
Softwarepakete zur Erstellung, Umwandlung und Überarbeitung von Findbüchern
beherrschen. Dazu muss stets ein erhebliches Maß an Zeit und Energie aufgewendet
werden.
Wie üblich reichen die Ausbildungsmöglichkeiten von der Anmeldung bei offiziellen
Kursen oder Workshops bis zur Bereitstellung von schriftlichen Unterlagen über EAD
oder Softwarehandbüchern für selbständigere Mitarbeiter. Wie bereits erwähnt, ist
das Dokument Encoded Archival Description Tag Library, Version 1.038 , ein wichtiger
Begleiter des EAD-Anwenderleitfadens. Weitere nützliche Unterlagen sind als
Ausdruck oder im World Wide Web verfügbar. Einige davon sind in Anhang G
zusammengestellt. Die im American Archivist39 veröffentlichten Fallstudien zur
Implementierung beschreiben viele Möglichkeiten zur kooperativen eigenständigen
Fortbildung, die besonders im großen oder konsortiellem Umfeld zielführend sind.
Gleich ob nun EAD gemeinschaftlich eingeführt werden soll oder nicht, werden
offizielle Workshops die Zusammenarbeit mit anderen Archiven vor Ort fördern und
als Starthilfe für den Implementierungsprozess dienen.
Bei Ausbildungsprogrammen von archivischen Studiengängen hat man damit
begonnen, EAD in die Lehrpläne über archivische Erschließung und digitale Archive
aufzunehmen. Das wird dazu führen, dass sich der Arbeitsmarkt allmählich mit
Bewerbern füllt, die die notwendigen Voraussetzungen für die EAD-Implementierung
mitbringen. Solche frischgebackenen Absolventen werden trotzdem oft eine
Weiterbildung in Bezug auf die Hardware- und Softwareumgebung eines bestimmten
Archivs benötigen. In einigen Fällen werden auch bereits angestellten Archivaren
Lehrgänge auf Hochschulebene im Rahmen der zunehmend beliebter werdenden
Fernstudienprogramme von Universitäten angeboten.
2.5.3. Kodierung neuer Findbücher
Ein Erfolgskennzeichen der neuen Technologie liegt in der Fähigkeit, neue
Aktivitäten in vorhandene Betriebsabläufe einzubinden und deutlich Vorteile zu
erbringen, ohne die laufende Arbeitsbelastung bedeutend zu erhöhen. Die
vorstehend beschriebenen Planungs- und Managementmaßnahmen sind zwar
umfangreich, sie stellen jedoch eine anfängliche Investition in Zeit dar, die nicht
wiederholt zu werden braucht bzw. höchstens mit der gleichen Intensität weiterlaufen
muss. Die wirkliche Mehrarbeit entsteht voraussichtlich bei den laufenden Aktivitäten,
hauptsächlich bei der Kodierung von Findbüchern und der damit
zusammenhängenden Pflege der IT-Infrastruktur. Die effizienteste Implementierung
wird daher die sein, bei der diese Aktivitäten im Verhältnis 1:1 unmittelbar in
38
39
Encoded Archival Description Tag Library, Version 1.0, ed. by Society of American Archivists, Chicago 1998.
Neu: Dooley, Jackie M. (Ed.): Encoded Archival Description. Context, Theory, and Case Studies, Chicago 1998.
39
vorhandene Aufgaben eingegliedert oder die letztgenannten einfach ersetzt werden
können.
Heutzutage erstellen die meisten Archive gedruckte Findbücher mit Hilfe von
Textverarbeitungs- oder Datenbanksoftware. Wenn es möglich ist, Findbücher
weiterhin auf diese Art zu erstellen und sie später umzuwandeln oder anstelle des
Textverarbeitungssystems einen SGML-Editor zu verwenden, wirkt sich dies u. U.
nur minimal auf den Arbeitsablauf aus. Der Nettoeffekt solcher Veränderungen kann
nach der Implementierung sogar in größerer Effizienz und insgesamt weniger
Arbeitsaufwand bestehen. Meissner berichtet vom Einsatz von StandardTextverarbeitungstemplates, die bei der Minnesota Historical Society den Zeitbedarf
für das Eingeben von Bestandsverzeichnissen und das anschließende Beseitigen
von Dateneingabefehlern gesenkt haben.40
In späteren Kapiteln ist beschrieben, wie zahlreiche Entscheidungen bei der
Kodierung getroffen werden müssen, von denen abhängt, wie arbeitsintensiv dieser
Prozess ist. Eine wichtige Überlegung betrifft die Tiefe der Auszeichnung, ein
Problem, das in den Fallstudien über die Library of Congress, Harvard und Yale in
der Zeitschrift The American Archivist ausführlich erörtert wurde. Die entwickelten
Verfahren reichen von einer minimalen Inhaltsbenennung, die sich auf strukturelle
Elemente von Findbüchern konzentriert, bis zu Versuchen einer detaillierteren
Auszeichnung, bei denen Eigennamen jedes Mal getaggt werden, wenn sie in einem
Findbuch auftreten. Lacy und Mitchell beschreiben z. B. die zahlreichen HypertextLinks, die in Findbüchern der Library of Congress eingebettet sind.41 Wie bei vielen
Erschließungsverfahren bringt ein Mehraufwand bei der Auszeichnung die
Möglichkeit einer erhöhten Leistungsfähigkeit bei der Recherche.
2.5.4. Konversion vorhandener Findbücher
Die Konversion vorhandener Findbücher ist mit zusätzlichen Problemen verbunden.
Wenn ein Archiv seine Findbücher „umkonzipiert“ hat und durch die Nutzung von
EAD optimiert hat, ist die Kodierung von Erschließungsangaben zu neu zu
verzeichnenden Beständen verhältnismäßig einfach. Die Auszeichnung bereits
vorhandener Findbücher jedoch – je nach ihrem Format und Zustand – ist komplexer.
Hier sind Entscheidungen von mindestens dreierlei Art zu treffen, mit denen
Institutionen, die die Katalogisierung mit MARC implementiert und die damit
verbundene Konversion eines Katalogs durchgeführt haben, bereits vertraut sein
dürften:
•
•
Priorisierung: Wie setzt ein Archiv Prioritäten angesichts der Tatsache, dass
die Konversion vorhandener Daten noch längere Zeit dauern wird?
Änderungsstrategien: Wie viel Überarbeitung ist machbar, um den in der
Institution üblichen Verfahren Genüge zu tragen bzw. die Nutzung von EAD zu
optimieren?
40
Daniel V.: Encoded Archival Description. The Development of an Encoding Standard for Archival Finding Aids, in: American
Archivist 60 (1997) 2, S. 268-283, hier S. 386. Beispiele für andere Verfahren lassen sich über die EAD-Help-Pages finden,
<http://jefferson.village.virginia.edu/ead>.
41
Lacy, Mary A. / Mitchell, Anne: EAD Testing and Implementation at the Library of Congress, in: American Archivist 60 (1997)
3, S. 420-435, hier S. 424.
40
•
Konversionsverfahren: Welches ist das beste Verfahren zur Konversion
vorhandener Findbücher, und zwar sowohl der Findbücher in
Textverarbeitungs- oder Datenbankformaten als auch solcher, die nur in
Papierform vorhanden sind?
2.5.4.1. Priorisierung
Die meisten Archive werden sich vor die Aufgabe gestellt sehen, eine hohe Anzahl
vorhandener Findbücher (als Altdaten bezeichnet) auf EAD umzustellen. Viele davon
sind mit speziellen Verfahren erstellt worden und redaktionell überarbeitet und mit
handgeschriebenen Anmerkungen versehen. Wie bei jedem Konversionsprojekt
heißt auch hier die erste Frage: „Wo soll man beginnen?“, besonders wenn die
Ressourcen für die Konversion begrenzt sind. Bei dieser Entscheidung sind zwei
grundlegende Fragen zu berücksichtigen:
1. Welche Findbücher sind am dringlichsten umzuwandeln?
2. Welche Findbücher sind am leichtesten umzuwandeln?
Um festzustellen, für welche Findbücher Ihres Archivs die Konversion am wichtigsten
oder am dringlichsten ist, ist zu überlegen, welche Findbücher Bestände mit
folgenden Merkmalen beschreiben:
•
•
•
•
•
•
die wichtigsten Bestände oder Überlieferungsbereiche
die häufigsten genutzten Bestände
Bestände, die öfter oder effizienter genutzt würden, besonders von neuen
oder auswärtigen Benutzern, wenn sie online zur Verfügung stünden und
elektronisch recherchiert werden könnten
Bestände, die an einem anderen Aufbewahrungsort gelagert sind
Bestände, die auf mehrere Archive in einer oder mehreren Institutionen verteilt
sind und für die ein übergreifendes „virtuelles Findbuch” von Nutzen wäre
Bestände, die sich auf andere, bereits online verfügbare digitale Materialien
beziehen.
Außerdem ist zu berücksichtigen, dass einige Findbücher ein größeres Potenzial als
andere für einen verbesserten Zugriff bieten, z. B. solche, deren Inhalt bei einer
Textsuche nach Schlagwörtern oder Sätzen mehr Informationen erbringen. Das
Durchsuchen eines Bestandsverzeichnisses mit langen Listen von
Korrespondentennamen oder Beschriftungen von Fotos würde z. B. den Namensoder Objektzugriff bedeutend verbessern, während das bei einer Liste, die
hauptsächlich eine Aufzählung von Kistennummern, Bandtiteln und Laufzeit, die oft
bei der Beschreibung von Vorgängen oder andere amtlichen Aufzeichnungen
verwendet werden, wahrscheinlich nicht der Fall ist.
Unter die Findbücher, die schnell und einfach umzuwandeln sind, fallen mit
Sicherheit solche, die ursprünglich bereits in digitalem Format erstellt wurden, und
zwar entweder mit Textverarbeitungssoftware oder einem Datenbanksystem. Wie
schnell und leicht diese Konversion unter Verwendung eines Skriptwerkzeugs oder
eines Skripttemplates sein wird, richtet sich nach folgenden zwei Hauptfaktoren:
41
•
•
ob die Elemente der Findbücher einheitlich formatiert wurden (d. h. als Felder
in einer Datenbank oder mit Hilfe eines Textverarbeitungstemplate) und wie
konsistent diese Formatierung bei allen Findbüchern in digitalem Format ist
ob die Dateien mit derselben Version der Datenbank- bzw.
Textverarbeitungssoftware erstellt wurden, im Unterschied dazu, dass Dateien
in verschiedenen Softwareumgebungen existieren. Bei Letzterem wäre für
jede Dateiart eine eigenes Konversionsverfahren erforderlich.
2.5.4.2. Änderungsstrategien
Durch Überprüfung der bestehenden Findbücher im Zusammenhang mit EAD kann
man sich einen guten Eindruck davon verschaffen, wie schwierig sie zu kodieren sein
werden und welche Änderungsprobleme bevorstehen. Bei Elementen auf höherer
Ebene sind die strukturellen Änderungen u. U. verhältnismäßig leicht, z. B. das
Bündeln der Grunddaten, die den gesamten Bestand beschreiben, im Bereich <did>
oder das Zusammentragen verschiedenartiger verwaltungstechnischer und
zugriffsbezogener Informationen im Bereich <admininfo>. Andererseits ist die Frage
zu stellen: Soll Zeit dazu verwendet werden, Informationen dieser Art in Findbüchern
aufzunehmen, die solche Informationen noch nicht enthalten? Sollen
Bestandsverzeichnisse kodiert werden, die keine kontextuellen biografischen
Angaben oder Angaben zu Themenbereich und Inhalt enthalten, oder wird der
Anwender es für ratsam halten, den Zugriff zu solchen Findbüchern vorerst nur für
Benutzer vor Ort freizugeben, bis diese Findbücher so verbessert worden sind, dass
sie über das Internet genutzt werden können, ohne dass eine vorherige Beratung
nötig ist? Bei der Beantwortung dieser Fragen sind Überlegungen zu den örtlichen
Gegebenheiten, z. B. der Zugriffsbedarf von Benutzern auf Findbücher, eine Hilfe.
2.5.4.3. Konversionsverfahren
Welches das geeignetste und erfolgversprechendste Verfahren bei der Konversion
von bestehenden Findbüchern zu EAD-Findbüchern sein wird, hängt von Format und
Zustand ab. Findbücher, die elektronisch mit Hilfe von Textverarbeitungs- oder
Datenbanksystemen erstellt wurden, können von Hand mit EAD-Tags versehen
werden, automatisch umgewandelt werden oder – was am wahrscheinlichsten ist –
unter Anwendung einer Kombination beider Methoden kodiert werden. Findbücher,
die nur auf Papier vorhanden sind, müssen zuerst in elektronische Form gebracht
werden, entweder durch Eingabe oder durch Scannen und OCR (Optical Character
Recognition).
Wenn der Einsatz von OCR in Betracht gezogen wird, ist die Lesbarkeit der
gedruckten Daten ein wichtiges Kriterium. Ein gedrucktes Findmittel mit klarem
Schriftbild ohne komplexe Formatierung oder die Fotokopie eines Findbuchs, das auf
einer guten, relativ modernen Schreibmaschine erstellt wurde, kann normalerweise
mit OCR erfolgreich in ein digitales Format gebracht werden. Ein Findbuch, das mit
einer älteren Schreibmaschine erstellt wurde oder nur als schlechter Durchschlag
oder mangelhafte Fotokopie vorliegt, muss jedoch mit ziemlicher Sicherheit
abgeschrieben werden. Die erneute Eingabe ist ggf. auch bei Findbüchern
42
vorzuziehen, die zwar für OCR geeignet sind, jedoch in Anordnung und Formatierung
stark schwanken oder inkonsistent sind.42
Druckfindbücher, die am leichtesten umzuwandeln sind, haben folgende
Eigenschaften: (1) sauberes getipptes Original oder Durchschlag mit einheitlicher
Schrift und klarem Schriftbild, (2) gleichmäßige Schreibdichte im gesamten
Dokument ohne oder mit nur wenig handgeschriebenen Berichtigungen oder
Anmerkungen, (3) einheitliche Formatierung im gesamten Findbuch (gleichmäßiger
Abstand, Tabulatoren und/oder Spalten im gesamten Dokument, insbesondere in
Inhaltsverzeichnissen). Umfangreiche Findbücher, die in diese Kategorie fallen, sind
für eine frühzeitige Konversion geeignet, da sie schneller als viele kürzere
Findbücher umzuwandeln sind.
Druckfindbücher, die schwieriger umzuwandeln sind, haben mehrere der folgenden
Eigenschaften: (1) uneinheitliche Formatierung (uneinheitliche Tabulatoren oder
Abstände, besonders in Inhaltsverzeichnissen, unregelmäßige Spalten), (2) schwer
zu lesendes Schriftbild aufgrund von Durchschlägen oder unregelmäßiger Schrift und
Schriftart, (3) zahlreiche Anmerkungen oder Berichtigungen im ganzen Dokument,
einschließlich handgeschriebener Anlagen und Listen, die dem Findbuch beigefügt
sind.
Zu den am schwierigsten umzuwandelnden Druckfindbüchern gehören vorläufige
oder noch unvollständige Listen, Inventare von Nachlassgebern oder Händlern sowie
Karteien. Im Allgemeinen stellen solche Dokumente keine vollständigen oder auf
andere Weise voll zufrieden stellende Findbücher dar, und jedes Archiv muss sich
entscheiden, ob es den Aufwand betreiben will, diese Findbücher mit ihrem
derzeitigen Zustand umzuwandeln, oder ob es warten soll, bis ein vollständiges
Findbuch erstellt werden kann. Das Umwandeln solcher Daten mag den meisten
Archivaren verhasst sein. Es lässt sich jedoch bereits festzustellen, dass viele
Benutzer es erwarten, dass alle Findbücher online verfügbar sind, wie unvollständig
oder unvollkommen sie auch sein mögen. Dies kann wiederum dazu führen, dass
sich an der Bereitwilligkeit von Archivaren, qualitativ minderwertigere Findbücher
elektronisch bereitzustellen, im Laufe der Zeit etwas ändert.
Nachdem die Altdaten in ein digitales Format umgewandelt worden sind, wird sich
die Art und Weise, wie die Daten aufbereitet werden, und die Schwierigkeit dieses
Prozesses nach den Eigenschaften der Daten richten. Wie bereits erwähnt, bestimmt
die Konsistenz der Daten, in welchem Umfang EAD-Tags mit Hilfe von Makros oder
anderen automatisierten Prozessen eingefügt werden können und – falls eine
Fremdvergabe dieser Arbeit in Betracht gezogen wird – ob ein externer Dienstleister
die Bedeutung verschiedener Arten von Informationen erkennen kann. Wie in Kapitel
4 im Einzelnen beschrieben, enthalten einige Textverarbeitungssoftwarepakete
Skripte oder Makrosprachen, mit deren Hilfe Anwender bestimmte Prozesse
automatisieren können. In vielen Fällen werden jedoch uneinheitliche Formatierung
oder Erschließungsverfahren den Umfang begrenzen, in dem Archive ihre
Findbücher auf diese Weise mit Tags versehen können. Es ist daher mit großer
Wahrscheinlichkeit davon auszugehen, dass Mitarbeiter einige Zeit für die manuelle
Überarbeitung einiger Teile der Findbücher benötigen.
42
Die folgende Taxonomie für die Umwandlung der Daten wurde von Jack Von Euw von der Bancroft Library, University of
California at Berkeley, entwickelt.
43
Die Detailtiefe des Taggens ist eine weitere wichtige Überlegung bei der
Datenumwandlung, und es gibt u. U. Gründe, für die Konversion von Altdaten andere
Verfahren als für die Kodierung neuer Findbücher anzuwenden. So könnten sie
beispielsweise bestimmte Aspekte der neuen Findbücher anders organisieren, um
bestimmte EAD-Datenelemente deutlicher zu kennzeichnen (beispielsweise, wenn
bei den Altdaten nicht klar zwischen biografischen Informationen und „Scope and
Content Notes“ unterschieden wird oder wenn Einzelheiten zur Übernahme und
archivischen Bearbeitung vermischt worden sind). Es kann entweder praktikabel oder
unpraktikabel sein, dass bei einem EAD-Konversionsprojekt alle alten Findbücher in
dieser Detailtiefe neu bearbeitet werden, und es muss sorgfältig überlegt werden,
welche Änderungen vorgenommen werden sollen. Ein sorgfältiges Durchlesen von
Kapitel 3, in dem die Bedeutung bestimmter Gruppen von EAD-Tags im Einzelnen
beschrieben ist, kann bei der Entscheidungsfindung bzgl. des Schwerpunkts der
Änderung helfen.
2.5.5. Sonstige laufende Tätigkeiten
Wenn mit der Implementierung begonnen wurde, muss das Projekt auf geeignete
Weise gemanagt werden. Beschaffung von Geräten, Abschluss von
Dienstleistungsverträgen, Verhandlungen mit Partnern sowie Einstellung, Betreuung
und/oder Aus-/Weiterbildung von Mitarbeitern sind wichtige Aufgaben. Für eine
laufende EAD-Maßnahme werden Mitarbeiter benötigt, die Findbücher auszeichnen,
prüfen und erproben, Dateien auf Rechnerserver laden und managen sowie
zugehörige Bilddateien bearbeiten. Für alle ausgelagerten Arbeiten ist die
Qualitätskontrolle entscheidend.
Wenn die Findbücher elektronisch mit einem Online-Katalog verknüpft werden sollen,
müssen die Verknüpfungsdaten (im USMARC-Feld 856) jeder entsprechenden
MARC-Titelaufnahme als Zeiger zum elektronischen Findbuch hinzugefügt werden.
Wie in Abschnitt 5.3.2.3 beschrieben, kann das Archiv auch beabsichtigen, eine
HTML-Version jedes EAD-Findbuchs auch für Benutzer mit Web-Browsern
bereitzustellen, die SGML oder XML nicht unterstützen. Ist das der Fall, muss ein
Prozess zur Umwandlung der EAD-Dateien in HTML entwickelt und implementiert
werden.
Viele, die EAD implementieren, bieten schließlich auf ihren Webseiten erläuternde
Materialien an, in denen beschrieben wird, was Findbücher sind, wie sie verwendet
werden und welche Verfahren es gibt, um online auf sie zuzugreifen.43 Dies ist eine
wichtige Hilfestellung für Benutzer elektronischer Archivangebote. Sie trägt dazu bei,
dass sie sich auch ohne Beratung zurecht finden und dass sie in den angebotenen
Findbüchern navigieren können. Der Text solcher Online-Benutzerschulungen muss
selbstverständlich erstellt, kodiert, geladen und gepflegt werden.
2.5.6. Öffentlichkeitswirksame Maßnahmen
Schließlich wird es fast mit Sicherheit erwünscht sein, einen Teil des Personals dazu
einzusetzen, die mit EAD gewonnenen Ergebnisse wichtigen Zielgruppen bekannt zu
machen, da Projekte mit „digitalen Archiven“ Attraktivität besitzen. Zu solchen
Zielgruppen gehören möglicherweise der Beirat oder die übergeordnete Dienststelle,
43
Ausgezeichnete Beispiele solcher Webseiten, so z. B. die der Library of Congress und der Yale University, sind zugänglich
über die EAD-Help-Pages, <http://www.archivists.org/saagroups/ead/>.
44
hauseigene Kuratoren oder Kuratoren von Bildungseinrichtungen sowie potenzielle
Geld- oder Archivgutgeber.
45
2.6. Fremdvergabe
Die Vergabe von Aufträgen an externe Dienstleister ist ein beliebtes Verfahren für
bestimmte Projekte und kann für einige Bereiche im Rahmen der Implementierung
von EAD geeignet sein. Die Entscheidung zwischen der Durchführung im eigenen
Hause und der Ausgliederung besteht für gewöhnlich darin, für Geld Zeit zu kaufen:
Die Durchführung im Hause mag zwar die Ausgaben senken, benötigt aber kostbare
Personalressourcen. In einigen Institutionen ist es u. U. leichter, besondere Mittel wie
Zuschüsse, Spenden oder Sonderhaushaltsmittel für bestimmte Projekte wie z. B. die
Implementierung von EAD zu erhalten, als zusätzliches Personal einzustellen.
Bestimmte Aufgaben wie das Kodieren von Findbüchern, das Installieren und
Verwalten von Datenbanken und die Pflege von Webservern eignen sich besonders
gut für eine Fremdvergabe.
Das Engagement des Stammpersonals ist entscheidend für verschiedene Bereiche
dieses Prozesses. Die Ausgliederung der Planung und Aufsicht ist schwierig, wenn
nicht sogar unmöglich, auch wenn externe Berater in der Anfangsphase sehr hilfreich
sein können. Außerdem entstehen durch den Vertragsabschluss selbst
administrative Kosten. Bestimmte Fähigkeiten sind erforderlich: (1) Kenntnis der
Thematik, (2) Fähigkeit zur Formulierung der Zielsetzungen der Institution und deren
Umsetzung in klar definierte Lieferantenleistungen, (3) Vertrautheit mit
Vertragsverhandlungen und (4) Verständnis für die Dynamik der
Vertragsüberwachung, besonders wo es um Qualitätskontrolle geht. Für eine
erfolgreiche Zusammenarbeit müssen Lieferfirma und Auftraggeber klar und genau in
ihren Zielsetzungen und Anforderungen übereinstimmen. Dies ist – angesichts des
von EAD gebotenen breiten Spektrums an Möglichkeiten der Auszeichnung von
Findbüchern – sicherlich besonders bei der Fremdvergabe der EAD-Implementierung
von Bedeutung. Die in diesem Bereich getroffenen Entscheidungen haben
unmittelbaren und möglicherweise erheblichen Einfluss auf den Zeitaufwand zur
Kodierung eines Findbuchs und damit auf die Umstellungskosten.
46
2.7. Kooperationsprojekte
Die Bedeutung von Partnerschaften für eine gemeinsame Implementierung von EAD
wurde bereits mehrmals in diesem Kapitel erwähnt, u. a. im Zusammenhang mit der
Zusammenlegung von Ressourcen, der gemeinsamen Nutzung von Fachkenntnissen
und von gemeinsamen Aus- und Fortbildungsveranstaltungen. Die ersten EADImplementierer, sowohl große als auch kleine Institutionen, haben im Rahmen von
Kooperationen und anderen gemeinsamen Vorhaben Anleitung, Unterstützung und
Finanzierung erhalten. Zu den Beispielen aus der Anfangsphase gehören die
innerinstitutionelle Zusammenarbeit in Harvard, Yale und der Library of Congress
sowie multiinstitutionelle Projekte wie das Online Archive of California (das die neun
Campus der University of California und zahlreiche andere kulturelle
Aufbewahrungsstätten im US-Bundesstaat California umfasst) und das American
Heritage Virtual Archive Project (mit UC Berkeley, Duke, Stanford und Virginia).44
Andere Archivare denken vielleicht, dass solche Archive große und personell gut
besetzte Institutionen sind, für die die Anwendung von EAD eine Kleinigkeit ist. In
vielen Fällen umfassen diese Projektgruppen indessen einen losen Verbund
kleinerer Arbeitsgruppen (lediglich jeweils eine bis drei Personen), deren Personal
genau so dünn auf verschiedene Zuständigkeitsbereiche verteilt ist wie in
zahlreichen kleinen, selbständigen Archiven.
Die Art und Weise, in der Mitglieder von Kooperationen zusammenarbeiten konnten,
um sich auf die Implementierung von EAD vorzubereiten und sie schließlich
durchzuführen, legt ein Kooperationsmodell nahe, das auch von anderen Stellen
nutzbringend angewendet werden kann. Die Herangehensweise ist insbesondere
geeignet für Planung, Beschaffung von Hardware und Software, Dokumentation,
Ausbildung und technische Unterstützung. Wie in Kapitel 4 und 5 beschrieben,
können Lösungen für die Erstellung und Veröffentlichung von EAD-Findbüchern
kostspielig und äußerst schwierig sein. Die gemeinsame Implementierung dieser
Projektteilbereiche kann daher besonders bei kleineren Archive über eine
grundsätzliche Durchführbarkeit entscheiden. Außerdem sollte der zusätzliche
Nutzen, sich durch die Teilnahme an einem groß angelegten Gemeinschaftsprojekt
mit mehr nach außen in Erscheinung tretenden Institutionen öffentlich zu profilieren,
insbesondere für kleine Archive nicht unterbewertet werden. Wenn erst einmal eine
große Institution oder ein Zusammenschluss die EAD-Implementierung in die Wege
geleitet hat, kann es recht einfach sein, weitere Partner hinzuzugewinnen.45
Andererseits muss man natürlich berücksichtigen, dass eine Tätigkeit im Rahmen
eines Zusammenschlusses zusätzliche Belastungen mit sich bringt. Eine breitere
Erörterung von Problemen und Optionen, um einen Konsens zu erzielen, benötigt
unweigerlich mehr Zeit, da mehr Partner und Interessen beteiligt sind. Eine starke
Führung und fundierte Fachkenntnisse sind stets für eine solche Gruppe bedeutend.
Wenn Projektleiter die Organisation nicht im Griff haben, für die Interessen
bestimmter Partner voreingenommen oder in anderer Hinsicht ungeeignet sind, kann
das Projekt in Schwierigkeiten geraten. Wenn sich schließlich nicht alle Partner eines
Gemeinschaftsprojekts aktiv beteiligen und ihren nötigen Beitrag leisten, kommt es
unausweichlich zu Frustrationen, denn Trittbrettfahrer kosten letztlich alle anderen
Beteiligten Zeit und Geld.
44
Webseiten für diese Projekte lassen sich über die EAD-Help-Pages aufrufen, <http://www.archivists.org/saagroups/ead/>.
Das Projekt Online Archive of California der University of California, um nur ein Beispiel zu nennen, weist auf alle in diesem
Abschnitt genannten möglichen Vorteile einer Zusammenarbeit hin.
45
47
Kapitel 3: Erzeugen von EAD-Findbüchern
3.1. Einführung................................................................................................................................... 49
3.2. Zusammenstellen von Daten für ein Findbuch ........................................................................... 51
3.3. Evaluierung von Erschließungsverfahren ................................................................................... 54
3.3.1. Analyse der Struktur bestehender Findbücher .................................................................... 54
3.3.2. Konsequente Strukturierung von EAD-Dokumenten ........................................................... 55
3.3.3. Verwendung von Inhaltsstandards und Normdateien .......................................................... 56
3.4. Mehrstufige Verzeichnung .......................................................................................................... 59
3.5. Aufbau eines EAD-Findbuchs..................................................................................................... 62
3.5.1. Erschließung des „Ganzen”: Informationen auf Bestandsebene <archdesc> ..................... 63
3.5.1.1. Grundlegende Erschließungsangaben: das hochrangige <did> ................................... 64
3.5.1.2. Verwendung der <did>-Subelemente............................................................................ 68
3.5.1.3. Begriffe aus Normansetzungen <controlaccess> (Controlled Access Headings)......... 74
3.5.1.4. Verwaltungstechnische Informationen <admininfo> (Administrative Information) ........ 74
3.5.1.5. Entstehungsgeschichte <bioghist> (Biographical Sketches and Agency Histories) ..... 81
3.5.1.6. Gegenstände <scopecontent> (Scope and Content Notes) ......................................... 84
3.5.1.7. Allgemeine Text-, Formatierungs- und Verknüpfungselemente.................................... 85
3.5.2. Erschließung der „Teile”: Geschachtelte Komponenten ...................................................... 88
3.5.2.1. Was ist eine Komponente (Component <c>)? .............................................................. 89
3.5.2.2. Nicht nummerierte bzw. nummerierte Komponenten <c> bzw. <c01> ......................... 92
3.5.2.3. Inhalt der Komponenten ................................................................................................ 93
3.5.2.4. Informationen zu Lagerungsort und Behälter <container> (Container)....................... 103
3.5.2.5. Formatierung von Erschließungsangaben untergeordneter Komponenten <dsc>
(Description of Subordinate Components) ............................................................................... 107
3.5.3. Begriffe aus Normansetzungen <controlaccess> (Controlled Access Headings) ............. 116
3.5.3.1. Verwendung von Attributen in <controlaccess>-Subelementen ................................. 117
3.5.3.2. Personen-, Körperschafts- und Familiennamen sowie geografische Namen
<persname>, <corpname>, <famname>, <geogname> (Personal Name, Corporate Name,
Family Name, Geographic Name) ............................................................................................ 119
3.5.3.3. Genre- und Formbegriffe <genreform> (Genre/Physical Characteristic) .................... 120
3.5.3.4. Funktion/Beruf <function> / <occupation>................................................................... 121
3.5.3.5. Gegenstand <subject> / <title>.................................................................................... 121
3.5.3.6. Gruppierte Begriffe aus kontrolliertem Vokabular ....................................................... 122
3.5.3.7. Kontrolliertes Vokabular außerhalb von <controlaccess>........................................... 123
3.5.4. Zusätzliche Erschließungsangaben <add> (Adjunct Descriptive Data)............................. 125
3.5.4.1. Bibliografien <bibliography> (Bibliographies) .............................................................. 126
3.5.4.2. Aktenplan <fileplan> (File Plans) und und Verweis auf andere Findbücher und
<otherfindaid> (Other Finding Aids) ......................................................................................... 126
3.5.4.3. Indizes <index> (Indexes) ........................................................................................... 127
3.5.4.4. Ähnliche bzw. separierte Materialien <relatedmaterial> und <separatedmaterial> .... 128
3.5.5. Erschließungsangaben, die in keine bestimmte Kategorie fallen: Sonstige
Erschließungsangaben <odd> (Other Descriptive Data ) ............................................................ 130
3.6. Hinzufügen von Metadaten zum Findbuch ............................................................................... 131
3.6.1. EAD-Header <eadheader> ................................................................................................ 131
3.6.1.1. EAD-Identifikator <eadid> (EAD-Unique File Identifier) .............................................. 132
3.6.1.2. Dateibeschreibung <filedesc> (File Description)......................................................... 133
3.6.1.3. Kodierung <profiledesc> (Profile Description)............................................................. 135
3.6.1.4. <revisiondesc> (Änderung der Kodierung).................................................................. 135
3.6.1.5. Beispiel für ein kodiertes <eadheader>-Element ........................................................ 137
3.6.2. Vorspann <frontmatter> (Front Matter) .............................................................................. 138
48
3.1. Einführung
Wenn EAD auch eine neue Entwicklung darstellt, die aus der
Informationstechnologie des späten 20. Jahrhunderts stammt, so beruhen doch
Struktur und damit auch die Fähigkeit der Archivare, EAD anzuwenden, fest auf
bewährten Grundsätzen der archivischen Ordnung und Verzeichnung. Ein großer
Teil der Angaben, die für die Erstellung eines guten EAD-Findbuchs wesentlich sind,
besteht aus Daten, die Archivare routinemäßig während des Prozesses der
Übernahme, Ordnung und Verzeichnung von Archivgut erzeugt haben. In diesem
Kapitel soll gezeigt werden, dass Vieles, was im Zusammenhang mit EAD steht,
Archivaren vertraut ist. Die Verfasser hoffen, dass Archivare erfahren, was viele von
ihnen nach der Teilnahme an einem EAD-Ausbildungsworkshop entdeckt haben:
dass es nämlich verhältnismäßig einfach ist, sich das intellektuelle Gerüst und die
Tagging-Struktur von EAD anzueignen.
Trotzdem sind einige im Anwenderleitfaden erwähnte Begriffe,
Erschließungsverfahren und Kodierkonzepte wahrscheinlich neu, und es erscheint
zunächst sinnvoll finden, das Kapitel ganz zu lesen, um die Struktur von EAD
allgemein zu verstehen, und dann nochmals zu lesen, um sich die Einzelheiten zu
bestimmten Elementen anzueignen. Größtenteils stellt der Anwenderleitfaden zwar
die Implementierung von den technischen Gesichtspunkte der DTD-Struktur und der
Elementeauswahl getrennt dar, einige Überlappungen lassen sich jedoch nicht
vermeiden. Überall in Kapitel 3, wo sich ein technischer Begriff oder ein
Implementierungsaspekt auf die Erörterung eines oder mehrerer Elemente bezieht,
findet sich eine kurze Erklärung. Ein Querverweis führt den Leser zu einer
ausführlicheren Erörterung des Themas an einer anderen Stelle des
Anwenderleitfadens.
Die nächsten drei Abschnitte dieses Kapitels beinhalten einen Überblick über EAD im
Kontext archivischer Erschließung:
•
•
•
Abschnitt 3.2 enthält eine kurze Beschreibung, wie Archivare Informationen
über das von ihnen verwaltete Archivgut erfassen
Abschnitt 3.3 untersucht die Wechselbeziehungen, die in EAD zwischen
Lösungsansätzen für das Taggen, der Detailtiefe der Auszeichnung und
gängigen Arbeitsverfahren bei der Erschließung bestehen
Abschnitt 3.4 behandelt das Konzept der mehrstufigen Verzeichnung, die für
die Struktur von EAD von zentraler Bedeutung ist.
Abschnitt 3.5, der Kern des Kapitels, beschreibt schrittweise den Prozess der
Erstellung eines EAD-Findbuchs, wobei der Schwerpunkt auf der Beziehung
zwischen den Teilen eines Findbuchs, die den meisten Archivaren vertraut sind, und
den entsprechenden Elementen und Attributen von EAD liegt. Wenn mehrere
Kodierungsmöglichkeiten bestehen, werden die Vor- und Nachteile jeder Möglichkeit
erörtert. Es wird geraten, beim Lesen dieses Abschnitts auch die entsprechenden
Elementbeschreibungen und Beispiele in der EAD-Tag-Library nachzuschlagen.
Abschnitt 3.6 erklärt schließlich, wie Metadaten oder bibliografische Angaben über
das Findbuch selbst aufgenommen werden. Dies ist wesentlich für die
Veröffentlichung von Findbüchern im World Wide Web.
Bis man Struktur und Tags von EAD sicher beherrscht, wird man beim Kodieren von
Findbüchern gelegentlich im vorliegenden Kapitel nachschlagen wollen. Beim
49
Auffinden der benötigten Informationen wird man dabei von der Abschnittsgliederung
unterstützt. Es kann auch zweckmäßig sein, in Anhang A – (Empfohlenes
Mindestmaß an Elementen für Findbücher)– nachzulesen, um die Verwendung
bestimmter EAD-Elemente mit bewährten Erschließungsverfahren in Verbindung zu
setzen.
50
3.2. Zusammenstellen von Daten für ein Findbuch
Das Erstellen eines Findbuchs ist ein beschreibender Prozess, der u. U. beginnt,
bevor ein Bestand in einem Archiv eintrifft.46 Wenn Sie z. B. Handschriftenkurator
oder Archivar in einem Archiv sind, das Bestände übernimmt, stellen Sie, wenn Sie
die Materialien hinsichtlich eines möglichen Ankaufs prüfen, wahrscheinlich wichtige
Daten zu Ursprung, Herkunft sowie Überlieferung zusammen. Sie lernen u. U. den
Urheber bzw. Geber der Aufzeichnungen oder Papiere kennen, erfahren etwas über
den Zusammenhang, in dem die Materialien entstanden sind, und sammeln aus
weiterführender Literatur, Gesprächen und Nachforschungen Informationen über
Ordnung, Umfang und Inhalt. Ein Vermerk, in dem die Recherchen des Kurators
zusammengefasst sind, wird erstellt, abgelegt und möglicherweise vergessen, bis
nach Monaten oder Jahren die Materialien durch Stiftung, Hinterlegung, Ankauf oder
Weitergabe in der betreffenden Institution eintreffen. Der Kurator zieht dann die
Notizen hervor und vergleicht sie mit den ihm vorliegenden Materialien.
Wahrscheinlich prüft er auch Abgabelisten* und rechtliche Dokumente, z. B. die
Schenkungsurkunde oder den Kaufvertrag. Bei diesem Prozess beginnen Archivare
mit der Erstellung einer rudimentären Bestandsbeschreibung oder vorläufigen Titel,
die Einiges von dem Inhalt des künftigen Findbuchs enthalten:
•
•
•
•
•
•
•
•
•
•
•
Wie lautet der Bezeichnung oder Titel des Bestandes?
Wer hat das Material in welchem Zusammenhang erstellt?
Welche Laufzeit hat das Material?
Welchen Umfang hat das Material?
Welche Archivaliengattungen oder Formate sind vorhanden?
Wie gelangte das Material in die Zuständigkeit oder den Besitz des Archivs?
Von welcher Person oder Quelle stammte die Neuzugang unmittelbar?
Bestehen Einschränkungen hinsichtlich Benutzung oder Veröffentlichung?
Wurde dem Material zum Nachweis innerhalb des Archivs eine eindeutige
Bestandssignatur zugewiesen?
Welcher Lagerungsort ist vorgesehen?
Sind Materialien für die Abgabe an andere Abteilungen des Archivs separiert
worden?
Je mehr Informationen in dieser Phase gewonnen werden können, desto besser,
insbesondere wenn sie auf mündlichen Aussagen beruhen und nicht aufgezeichnet
sind. Diese erste Erschließung auf Bestandsebene erscheint dem Archivar u. U. eher
als Bestandskontrollinstrument denn als Zugriffswerkzeug. Das Zusammenstellen
und Erfassung der Informationen stellt jedoch eine Investition in die archivische
Erschließung dar, die erheblichen Nutzen bringt, da die Daten aufgesplittet und dann
mühelos den entsprechenden EAD-Datenkategorien zugeordnet werden können.
Ausgehend von dieser allerersten Erfassung von Ankaufs- und Zugangsdaten kann
der Verfasser des Findbuchs grundlegende Erschließungsangaben zu dem
gesamten Bestandes extrahieren (wovon später in Abschnitt 3.5.1.1 als
„hochrangiges <did>“ die Rede sein wird) , indem er damit beginnt, wichtige
Informationen darüber zusammenzustellen, wie der Bestand erworben wurde und
unter welchen Bedingungen er vom Archiv verwaltet und von Benutzern genutzt
werden kann. Diese „administrativen Informationen” (die in Abschnitt 3.5.1.4 weiter
46
Im gesamten Kapitel wird der Begriff „Bestand” verwendet, um einen Komplex archivischer Materialien zu bezeichnen, z. B.
einen Provenienzbestand, einen Nachlass oder eine Sammlung.
*
A.d.Ü: Original „packing lists“.
51
erörtert werden) werden künftige Leser des Findbuchs unterstützen, auf den Bestand
zuzugreifen und die aufgefundenen Daten zu nutzen.
Zu Beginn der Bestandsbearbeitung werden weitere Informationen
zusammengestellt, die sich für die Aufnahme in ein EAD-Findbuch eignen. Um mehr
über die Materialien zu erfahren, recherchiert man ggf. die Biografie,
Behördengeschichte oder Körperschaftschronologie und verfasst einen Spickzettel,
auf den man bei der Bearbeitung zurückgreifen kann und der die wichtigsten Daten
und Ereignisse im Leben einer Persönlichkeit bzw. in der Geschichte einer
Organisation enthält. Wie in Abschnitt 3.5.1.5 vorgeschlagen, kann diese
Bearbeitungshilfe zu einem öffentlich zugänglichen Nachschlagewerkzeug werden,
wenn sie als Kurzbiographie oder Behördengeschichte in ein EAD-Findbuch
aufgenommen wird, die Benutzern zusätzliche Informationen zu Provenienz liefern
und helfen, das Archivgut in seinen Entstehungskontext einzuordnen. Auch
Bibliografien, z. B. eine während der Recherche erstellte Literaturliste, und andere
Arten von „einschlägigen Erschließungsinformationen“ (siehe Abschnitt 3.5.4), lassen
sich mit EAD ohne weiteres erfassen.
Während der gesamten Bearbeitung setzt man das Lesen weiterführender Literatur
und die Suche in externen Informationsquellen fort. Das nächste Stadium des
Ordnens und Verzeichnens beinhaltet indessen die Analyse der vorhandenen
Bestandsordnung und -struktur, um die wichtigsten Teile zu identifizieren und
festzustellen, wie diese Teile in kleinere Komponenten aufgeteilt worden sind bzw.
werden könnten. Ist die Ordnung einmal festgelegt, verschiebt sich der
Arbeitsschwerpunkt auf die Gliederung, also in Bezug darauf, wie die Materialien
innerhalb der übergeordneten Komponenten abgelegt werden sollen (alphabetisch,
chronologisch usw.). Während der Bestandsanalyse werden für einen
Bearbeitungsvorschlag wahrscheinlich Informationen zur bestehenden Gliederung
und Ordnung vermerkt, in dem in großen Zügen beschrieben wird, wie die
verschiedenen Teile im Hinblick auf die späteren Recherchemöglichkeiten aufbereitet
werden sollen. Indem der Bearbeitungsvorschlag sowohl die ursprüngliche als auch
die vorgesehene Bestandsstruktur umreißt, bildet er die Grundlage für den Aufbau
eines mehrstufigen EAD-Findbuchs, das, wie in Abschnitt 3.4 beschrieben, eine
Kurzbeschreibung des Gesamtbestandes darstellt, auf die zunehmend
Detailbeschreibungen der Teile folgen.
Während man sich durch den Bestand arbeitet, beginnt man damit,
Komponentenbeschreibungen zu erstellen. Dies dient zwei wichtigen Zwecken: die
Beziehung der Komponenten zueinander und zum gesamten Bestand
wiederzugeben sowie jeder Komponente Schlüsselinformationen zuzuweisen, z. B.
Titel, Laufzeit, Ort, Umfang u. a.. In Abschnitt 3.4 wird die Beziehung Bestand –
Komponente behandelt, während in Abschnitt 3.5.2 der Frage nachgegangen wird,
wie die Komponentenbeschreibungen in ein EAD-Findbuch integriert werden.
Während die Komponentenbeschreibungen erstellt werden, werden vielleicht
gleichzeitig wichtigste inhaltliche Schwerpunkte des Bestandes vermerkt. Die Art der
Materialien wird bezeichnet, interessante Personen und Organisationen werden
aufgelistet, und es wird das Vorhandensein von Findbüchern zu verwandtem Material
und Zugriffswerkzeugen notiert. All dies sind wichtige Angaben, die ihren
festgelegten Platz in der EAD-Struktur haben, wie spätere Abschnitte dieses Kapitels
zeigen werden.
52
Beim Durchlesen folgender Abschnitte werden Sie bemerken, dass EAD viel von
dem enthält, was ständig auf dem Gebiet der archivischen Ordnung und
Verzeichnung getan wird. Es ist jedoch zu beachten, dass EAD mehr als eine
Struktur zur Abbildung gängiger Erschließungsverfahren ist. Es hat vielmehr das
Potenzial zur Verbesserung dieser Verfahren. EAD zwingt Archivare zu kritischerem
Nachdenken über ihre Erschließungsverfahren und regt dazu an, in einen
vorgegebenen festen Rahmen örtliche, nationale und internationale Verfahren
einzubringen. Darüber hinaus bahnt EAD den Weg dafür, dass Findbücher in einer
Online-Umgebung dynamischer werden, und bietet Möglichkeiten zum Aufbau von
Findbuch-Datenbanken, die von zahlreichen Archiven genutzt werden, wobei mehr
oder weniger EAD-Elemente verwendet werden. Gleichzeitig helfen uns
unterschiedlich erstellte Findbücher mehr darüber zu erfahren, wie Benutzer diese
Werkzeuge wahrnehmen und sie nutzen.
53
3.3. Evaluierung von Erschließungsverfahren
EAD ist eine komplexe Struktur, die, wenn sie in vollem Umfang genutzt wird, einem
Archiv die Möglichkeit bietet, Findbücher auf unendlich viele Arten zu erstellen, zu
durchsuchen und kundenspezifisch aufzubereiten. Viele dieser Verfahren sind recht
neuartig und manche noch gar nicht vorhersehbar. Die Möglichkeiten dies
umzusetzen, hängt grundsätzlich von einer konsistenten und umfassenden
Kodierung des Findbuchinhalts ab. Durch wohlüberlegte Nutzung der EAD-Tags für
den Inhalt lässt sich ein äußerst flexibles Findbuch erstellen, entweder als lineares
Dokument, mit dessen Erstellung wir vertraut sind, oder als strukturierter
recherchierbarer Datenbestand.
3.3.1. Analyse der Struktur bestehender Findbücher
In dem Eifer, diese neue Technologie zu nutzen, stürzen sich einige Archive in die
Konversion alter bzw. in die Erstellung neuer Findbücher ohne viel Rücksicht darauf,
ob ihre vorhandenen Findmittel hochwertige oder vollständige
Erschließungsangaben enthalten oder ob sie die erforderlichen Kontextinformationen
liefern, die von Benutzern für die Interpretation der Materialien benötigt werden.
Aufgrund der Notwendigkeit, Mittel zu bekommen und Personal auf dem Gebiet EAD
zu schulen, entscheiden sich diese Archive u. U. dafür, die vorhandenen Findbücher
in ihrer gegenwärtigen Form zu taggen, mit der Absicht, später Berichtigungen
vorzunehmen. Realistisch gesehen, ist die Wahrscheinlichkeit, dass eine solche
Berichtigung tatsächlich stattfindet, jedoch gering. Nichtstandardisierte Findbücher
werden auf bestimmte Art und Weise erfasste Erschließungsangaben online zur
Verfügung gestellt, die unerfahrene Archivbenutzer ohne archivarische Fachberatung
nicht zufriedenstellend deuten können. Weil EAD die Möglichkeit schafft, einzelne
Findbücher in institutionenübergreifende Findbuch-Datenbanken mit zahlreichen
Findbüchern zu integrieren, können in einer solchen Datenbank inhaltliche oder
strukturelle Inkonsistenzen auftreten, die schwierig zu finden oder zu korrigieren sind.
Daher ist es äußerst wichtig, dass kodierte Findbücher für auswärtige Benutzer, die
online sie benutzen, klar und verständlich sind. Ist dies nicht der Fall, ist nichts damit
gewonnen, die Findbücher derart zu kodieren und zu verbreiten. Einige Benutzer
können sogar durch sie abgeschreckt werden. Bevor versucht wird, ein EAD-Projekt
in Angriff zu nehmen, sollte man die verschiedenen in Kapitel 2 und Anhang D
erörterten Probleme berücksichtigen und bestehende Verfahren zur
Findbucherstellung sorgfältig analysieren. Was den letztgenannten Punkt betrifft, ist
jede Einzelinformation und ihre derzeitige Position innerhalb der Findbuchstruktur zu
prüfen. Dann ist festzustellen, ob diese Information in mehr als ein EADDatenelement gehört. Ist dies der Fall, ist es u. U. am besten, die Daten auf
geeignete Weise auf die entsprechenden Elemente aufzuteilen, um die langfristige
Nutzbarkeit der Information sicherzustellen. Auch muss man sich fragen, welche
Funktion eine Information in dem Findbuch hat und ob sie auch in einer OnlineUmgebung verständlich ist, wo kein Archivar beratend zu Seite steht. Wenn die
Information in einem Findbuch nicht hinreichend selbsterklärend ist oder zum
Verständnis beiträgt, sollte sie entweder überarbeitet werden, bevor sie online
verfügbar gemacht wird oder wegfallen.
Ebenso wichtig ist es, die Vollständigkeit von Findbüchern zu überprüfen. Oftmals hat
ein Archiv für einen Bestand nur ein Bestandsverzeichnis. Eine solche Liste kann
sich innerhalb der betreffenden Institution als Recherchewerkzeug eignen, in einer
54
Online-Umgebung jedoch völlig nutzlos sein, weil ihm der Kontext, wie z. B.
Kurzbiografie, Behördengeschichte und eine Zusammenfassung des Inhalts, fehlt.
Diese entscheidende, wenn auch nur kurze Information in das kodierte Findbuch
aufzunehmen, nimmt u. U. etwas Zeit in Anspruch. In jedem Fall wird sich die Mühe
jedoch für Archiv und für dessen Benutzer lohnen. Bisherige Annahmen, inwieweit
Benutzer die in unseren Findbüchern enthaltenen Informationen verstehen können,
sollten überdacht werden. Sogar unbedeutend erscheinende Einzelheiten wie die
Titel der verschiedenen Findbuchabschnitte sollten man in einem neuen Licht
betrachten.
3.3.2. Konsequente Strukturierung von EAD-Dokumenten
Wenn EAD sein volles Potenzial entfalten soll, müssen Archivare damit beginnen, bei
der Erschließung „optimale Arbeitsverfahren” anzuwenden. Das heißt, dass neben
den Empfehlungen des Anwenderleitfadens und der EAD-Tag-Library nationale und
internationale Datenstruktur- und Dateninhaltsstandards angewendet werden
müssen. Ein internationaler Datenstrukturstandard ist ISAD(G),47 eine (wie in den
Abschnitten 1.1 und 3.4 erläutert) internationale Richtlinie zur mehrstufigen
Verzeichnung von Archivgut, die den Erschließungsangaben in EAD-Findbüchern
ähnelt. ISAD(G) besteht aus zwei großen Abschnitten: (1) einem Abschnitt, in dem
die wichtigsten Datenelemente oder Informationskategorien zur Erschließung einer
archivischen Einheit oder ihrer Komponenten benannt sind, und (2) ein Abschnitt mit
Regeln, die die hierarchische Beziehung zwischen dem Ganzen und seinen Teilen
aufzeigen. Was die Daten zum Findbuch betrifft, so ist ISAD(G) ist nicht wie EAD. Es
bietet jedoch ein nützliches Modell für die Ermittlung wichtiger Elemente sowie der
Informationsbandbreite, die Archive auf jeder hierarchischen Stufe zusammentragen
können.
Es dürfen allerdings nicht nur nationale und internationale Standards hinzugezogen,
es muss auch bei der Erstellung von Findbüchern vor Ort konsequent vorgegangen
werden, indem z. B. bestimmte Findbuchschlüsselelemente definiert werden oder
das Verfahren zur Komponentenverzeichnung standardisiert wird. In der Regel
schreibt EAD nicht vor, dass Elemente in einer bestimmten Reihenfolge angeordnet
werden. Allerdings unterstützt es eine logische Abfolge von Informationen, wie dies in
späteren Abschnitten dieses Kapitels beschrieben wird. Wie in MARC, so sind auch
bei EAD nur wenige Elemente zur Erstellung eines gültigen EAD-Dokuments
erforderlich.48 Wenn nur die erforderlichen EAD-Elemente verwendet werden, heißt
das jedoch nicht, dass die MARC-Titelaufnahme oder das kodierte Findbuch eine
gute oder ausreichende Abbildung des Bestandes bietet. Es ist durchaus möglich,
ein valides EAD-Dokument zu erstellen, das nur leere Elemente enthält.49 Die
Erstellungssoftware für SGML kann nur prüfen, ob die erforderlichen Elemente
vorhanden sind und bestimmte Elemente in der richtigen Reihenfolge stehen. Es gibt
keine „MARC-Polizei“ und es wird auch keine „EAD-Polizei“ geben. Jedes Archiv ist
selbst dafür verantwortlich, sicherzustellen, dass jedes Findbuch bestimmte
Schlüsselelemente enthält und die Elemente wie vorgesehen verwendet werden.
47
ISAD(G). General International Standard Archival Description, adopted by the Ad Hoc Commission on Descriptive Standards
des International Council on Archives, Stockholm, Schweden, 21. – 23. Januar 1993, Ottawa 1994.
48
Diese erforderlichen Elemente sind in Fettdruck in Anhang A aufgeführt. Es ist zu beachten, dass die erforderlichen
Elemente für sich genommen noch kein vollständiges Findbuch bilden.
49
Ein leeres Element besteht aus einem Start-Tag und einem End-Tag, enthält aber keine(n) Text bzw. Daten.
55
Eine sorgfältige Lektüre des Anwenderleitfadens und der EAD-Tag-Library dürfte zu
einer verantwortungsbewussten und angemessenen Verwendung der EAD-Elemente
beitragen. Beide Dokumente haben den Zweck, die Auseinandersetzung mit EAD
und die Anwendung zu fördern, die von der DTD zugelassenen Schlüsseloptionen zu
bezeichnen und Anhaltspunkte zu möglichen Kosten und Vorteilen verschiedener
Lösungsansätze zu liefern. Es ist im Rahmen der Entwicklung von EAD noch zu früh,
für alle Archive eine verbindliche Reihenfolge der Elemente zu fordern oder einen
bestimmten Grad bzw. eine bestimmte Auszeichnungstiefe zu empfehlen. Es muss
weiter untersucht werden, wie die Kodierung Darstellung und
Recherchemöglichkeiten beeinflusst, und es müssen weitere Beiträge und
Rückmeldungen aus den Archiven zusammengetragen werden. Im Augenblick
kommt es darauf an, die Elemente zu verwenden, über die Archivare zu einem
gewissen Konsens gelangt sind (so wie es im Anwenderleitfaden und einschlägigen
externen Standards empfohlen wird), dass Elemente und Attribute gemäß der DTD
verwendet werden und dass die Daten in jedem Element mit der Beschreibung des
betreffenden Elements übereinstimmen.
In Anhang A und den späteren Abschnitten des Anwenderleitfadens wird ein Satz
von etwa 30 Elementen benannt, die mindestens für eine nützliche und logische
Bestandsbeschreibung benötigt werden. Wenn auch die Verwendung dieser
Elemente keine Garantie für die Qualität der Informationen gibt, wird zumindest
sichergestellt, dass die wichtigsten Teile eines Findbuchs für Benutzer zur Verfügung
stehen. Zwar sollten alle Findbücher zumindest die in Anhang A genannten EADElemente umfassen, es ist jedoch stets möglich, weitere Elemente aufzunehmen und
zusätzliche Informationen in ein Findbuch einzuarbeiten.
3.3.3. Verwendung von Inhaltsstandards und Normdateien
Es ist unbedingt zu beachten, dass EAD zwar eine standardisierte Struktur für
Informationen über Findbücher und die in ihnen beschriebenen Bestände liefert, dass
es jedoch in seiner gegenwärtigen Form nicht die Anwendung von Standards zur
Feststellung und Eingabe des Inhalts unter Verwendung von Standard-Normdateien
vorschreibt. Das optimale Verfahren zur Gewährleistung der Einheitlichkeit des
Inhalts in EAD-Elementen besteht darin, die für ein Archiv relevanten
Inhaltsstandards zu Landes-, Berufs- oder Themenbezeichnungen für kontrollierte
Zugriffspunkte in Findbüchern verwendet werden. Beispielsweise sind bestimmte
Namenselemente und die Titel von Verzeichnungseinheiten gemäß den
Erschließungsregeln und -konventionen wie den Folgenden aufzubauen:
•
•
•
•
•
Anglo-American Cataloguing Rules, 2nd Edition
Archives, Personal Papers, and Manuscripts
Graphic Materials
Rules for Archival Description
Library of Congress Name Authority File
Beim Kodieren bestimmter Personen- oder Körperschaftsnamen oder geografischer
Namen, Funktionen, Berufe, Themen oder Gattungen und Formen sind kontrollierte
Vokabulare wie die Folgenden zu verwenden:50
50
Die vollständigen bibliografischen Titel für jede der nachstehend aufgeführten Normdateien findet sich im Abschnitt Thesauri
und Regeln für die archivische Erschließung im Anhang G.
56
•
•
•
•
•
•
•
•
•
•
•
•
Art and Architecture Thesaurus
Canadian Subject Headings
Dictionary of Occupational Titles
Thesaurus for Graphic Materials
Library of Congress Subject Headings
Medical Subject Headings
Moving Image Materials: Genre Terms
National Council on Archives Rules for Construction of Personal, Corporate,
and Place Names
Revised Nomenclature for Museum Cataloging
Thesaurus of Geographic Names
Union List of Artists' Names
UNESCO Thesaurus
Jedoch ist auch hier ein Kompromiss zwischen dem Zeitaufwand für die Identifikation
und Eingabe der zulässigen Datenform einerseits und den sich daraus ergebenden
langfristigen Vorteilen für die Benutzung andererseits zu schließen. Die
Möglichkeiten der zur Verfügung stehenden Software haben u. U. einen Einfluss
darauf, wie dieser Zielkonflikt beurteilt wird, wenn auch nicht außer Acht gelassen
werden darf, dass sich die technischen Möglichkeiten im Laufe der Zeit ändern.
Vielleicht entscheidet sich das Archiv bzw. die verwahrende Einrichtung dafür, dass
für wichtige, nicht jedoch für weniger wichtige Zugriffspunkte in kodierten
Findbüchern standardisierte Daten verwendet werden sollen, insbesondere dann,
wenn das verwendete System übergeordnete Elemente durchsucht und darstellt. So
könnten z. B. die Bestandsbezeichnung und -laufzeit sowie Personen-,
Körperschafts- und Ortsnamen, die in der „Scope and Content Note“ auf höchster
Stufe erscheinen (und die wichtigsten Aspekte des Bestandes wiedergeben), in
normierter Form erfasst werden, nicht jedoch die Namen, die auf niedrigeren Stufen
in Findbüchern auftreten.
Archivare könnten sich allerdings auch dafür entscheiden, kontrollierte
Zugriffsspunkte wie Namen und Themen nur dort einzufügen, wo diese Namen bzw.
Themen in den erschlossenen Materialien erscheinen, und zwar auf der Stufe der
Serie, der Akte oder sogar des Einzelstücks. Diese Lösung hat den Vorteil, dass
Benutzer bei ihren Recherchen unmittelbar zu einschlägigen Materialien in einem
Findbuch geführt werden. Für Archive, die bereits begriffskontrollierte
Themeneinträge und zusätzliche Einträge für ihre MARC-Titelaufnahmen erstellen,
bedeutet es keine Mehrarbeit, die gleichen Begriffe in den Findbüchern anzugeben.
Diese und andere Fragen zur Verwendung von Begriffen aus kontrollierten
Vokabularen werden im Einzelnen in Abschnitt 3.5.3 erörtert.
In Abschnitt 5.3.5 sind Möglichkeit beschrieben, wie EAD-kodierte Findbücher mit
anderen Standards in Beziehung gesetzt werden können, und zwar durch
Verwendung von Encodinganalogs. Encodinganalogs sind Attribute für EADElemente, die in Typ und Funktion den Feldern oder Teilfeldern anderer
Datenstrukturstandards wie beispielsweise MARC entsprechen. Encodinganalogs
sind in EAD aufgenommen worden, um den Austausch von Findbuchdaten mit
Systemen zu ermöglichen, die die einschlägigen nationalen und internationalen
Datenstrukturstandards verwenden. Wie in Abschnitt 1.6 beschrieben, besteht für
Archive, die in großem Ausmaß in die Katalogisierung mit MARC investieren, ein
möglicher Vorteil darin, eine skelettartige MARC-Titelaufnahme aus dem kodierten
57
Findbuch zu extrahieren oder umgekehrt ausgehend von einer exportierten MARCTitelaufnahme das Gerüst für ein kodiertes Findbuch aufzubauen.
58
3.4. Mehrstufige Verzeichnung
Wie in Abschnitt 3.2 erwähnt, stellen Archivare meist Informationen zusammen, die
sowohl die Archivguteinheit als Ganzes als auch ihre einzelnen Komponenten
beschreiben. EAD unterstützt die verschiedenen Verzeichnungsstufen, die für die
meisten Findmittel von zentraler Bedeutung sind und die hierarchischen Ebenen der
Materialien abbilden.
Die Struktur von EAD wurde unabhängig von technischen Gesichtspunkten. Die
Entwickler konzentrierten sich weithin auf den Findbuchinhalt, d. h., auf die Arten von
Informationen, die über einen Archivgutkomplex vermittelt werden. Die Gruppe war
zwar einig darin, dass die Struktur zu gegebener Zeit in SGML übertragen werden
muss. Ein großer Teil der Untersuchung bestand jedoch vornehmlich darin, die
strukturellen Komponenten der archivischen Verzeichnung zu entwirren und zu
identifizieren. Dabei wurde festgestellt, dass auf allen Verzeichnungsstufen eines
Findbuchs die gleichen Arten von Informationen immer wiederkehren. Steve DeRose,
der SGML-Berater der Gruppe, sah sich ein Findbuch an und bemerkte, dass dieses
Dokument tatsächlich drei Findbücher enthalte: eins, das den Bestand als Ganzes
beschreibe, eins, das die großen Unterlagengruppen innerhalb des Bestandes
beschreibe, und eins, das die Akten bzw. Einzelstücke innerhalb der Gruppen
beschreibe.51 Das führte zur Konzipierung verschiedener Sichtweisen eines Bestand,
wie er in einem Findbuch dargestellt sind.
Ein typisches Findbuch enthält zwei oder drei Sichtweisen eines Bestandes, die sich
jeweils auf den gleichen Archivgutkomplex beziehen, jedoch in unterschiedlicher
Detailtiefe. Auf der ersten Stufe wird der gesamte Bestand ganz allgemein
beschrieben. Dies ist normalerweise ein Überblick über die vorhandenen
Materialarten, es wird auf erwähnte bedeutende Persönlichkeiten und Themen
hingewiesen, und es werden Informationen zu Provenienz und
Benutzungsbedingungen geliefert. Diese erste Stufe enthält ggf. eine Kurzbiografie
oder Behördengeschichte sowie eine „Scope and Content Note“, die den Bestand in
seiner Gesamtheit beschreibt.
Die nächste Stufe konzentriert sich möglicherweise Materialgruppen innerhalb des
Bestandes, die jeweils genauer als auf der ersten Stufe beschrieben werden. Dabei
werden weitere spezifische Materialarten sowie Personen und Themen
hervorgehoben. Diese Verzeichnung auf mittlerer Stufe kann in einem Findbuch
innerhalb des Ganzen als Beschreibung von Serien oder Teilserien vorgenommen
werden. Je nach der Komplexität des Bestandes und den in einer Institution üblichen
Verfahren ist diese Verzeichnung u. U. unnötig.
Schließlich kann jede Akte oder möglicherweise jedes Einzelstück beschrieben
werden. Diese Verzeichnung nimmt oft die Form eines Bestandsverzeichnisses an, in
der die Hierarchie der Materialien genau erkennbar ist und die von Benutzern zur
Bestellung von Archivgut benutzt wird.
Wie in späteren Abschnitten dieses Kapitels ausführlicher erläutert, umfasst das als
Archivische Erschließung <archdesc> (Archival Description) bezeichnete Element
diese sich entfaltenden, hierarchischen Stufen, indem es zuerst einen Überblick des
Ganzen und anschließend genauere Ansichten der Teile bzw. Komponenten <c>
51
Gespräche des Bentley Fellowship Finding Aid Team, Juli 1995.
59
(Components) (siehe Abschnitt 3.5.2) bietet. Die Verzeichnungsangaben der Teile
sind in einem oder mehreren Elementen mit der Bezeichnung Erschließungsangaben
untergeordneter Komponenten <dsc> (Description of Subordinate Components)
(siehe Abschnitt 3.5.2.5) gebündelt, die den Ansichten auf mittlerer Stufe und auf
Akten-Stufe (siehe oben) entsprechen. Zur Erschließung des gesamten Bestandes
sind auf der Stufe <archdesc> Datenelemente auf allen <c>-Stufen innerhalb <dsc>
verfügbar bzw. wiederholbar (siehe Bild 3.4a). Zudem werden Informationen von den
vorangehenden höheren Stufen auf jede nachfolgende Stufe vererbt.
<ead>
<eadheader>
<frontmatter>
<archdesc> (LEVEL-Attribut ist erforderlich)
<did>
<admininfo>
<bioghist>
<scopecontent>
<organization>
<arrangement>
<note>
<dao>
<daogrp>
<controlaccess>
<add>
<odd>
<dsc> (TYPE-Attribut ist erforderlich)
<c01> (LEVEL-Attribut ist möglich)
<did>
<admininfo>
<bioghist>
<scopecontent>
<organization>
<arrangement>
<note>
<dao>
<daogrp>
<controlaccess>
<add>
<odd>
<c02>
Bild 3.4a. Hochrangiges Modell der Encoded Archival Description (EAD) DTD.
60
Im Sinne des Konzepts der mehrstufigen Verzeichnung wurden in EAD die
Grundgedanken und Ziele zweier weiterer bedeutender archivischen Standards
integriert: ISAD(G) sowie die kanadischen Rules for Archival Description (RAD). Wie
in Abschnitt 3.3.2 erwähnt, bietet ISAD(G)52 ein Verfahren, mit dem sich zuerst ein
ganzer Komplex von archivischen Materialien erfassen lässt und dann zur
Verzeichnung der Teile des Bestandes oder der Sammlung übergegangen wird,
wobei die gleichen Verzeichnungsbereiche oder Elemente wie auf der höchsten
Stufe verwendet werden. Alle Verzeichnungsangaben, dargestellt in einer Hierarchie,
bilden zusammen die „mehrstufige Verzeichnung“. Diese Beziehung des Ganzen zu
seinen Teilen ist auch RAD zu Grunde gelegt, einem nationalen
Dateninhaltsstandard, der die Struktur von ISAD(G) abbildet. In RAD heißt es: „Die
Verzeichnung des Bestandes als Ganzem stellt die höchste oder erste Stufe der
Verzeichnung dar. Die Verzeichnung der Teile bilden tiefere Verzeichnungsstufen.
Der Bestand ist in diesen Regeln eine Gruppe von Erschließungsangaben, die ihn
als dynamisches und organisches Ganzes zeigen, das sich aus Serien
zusammensetzt. Diese wiederum bestehen aus Akten, die ihrerseits u. U.
Einzelstücke enthalten. Jedes dieser Teile wird zum Gegenstand einer Verzeichnung
(bzw. hat das Potenzial, dazu zu werden), was zu vielen Verzeichnungsangaben
führt, die hierarchisch verknüpft werden müssen, um die Struktur (Teil – Ganzes)
eines Bestandes deutlich zu machen.“53
Die ISAD(G) und RAD enthaltenen Regeln sind für vollständige Findbuchsysteme
einschließlich archivischer Inventare und Register, MARC-Titelaufnahmen,
Datenbanken und andere Erschließungsmechanismen, die Archivare anwenden,
gedacht.
52
ISAD(G), Abschnitt 1.0.
Rules for Archival Description, prepared by the Planning Committee on Descriptive Standards of the Bureau of Canadian
Archivists, Ottawa 1990, Abschnitt 1.0A1.
53
61
3.5. Aufbau eines EAD-Findbuchs
In den vorangegangenen Abschnitten wurde versucht, eine theoretische Grundlage
für die detailliertere Betrachtung der EAD-Elemente in Abschnitt 3.5 zu schaffen. Die
Reihenfolge, in der die Elemente behandelt werden, entspricht nicht unbedingt
derjenigen, in der Bearbeiter die verschiedenen Teile eines Findbuchs konzipieren.
Sie folgt auch nicht streng der Struktur der EAD-DTD, in der vorgeschrieben ist, dass
ein valides EAD-Dokument*54 mit dem äußersten EAD-Tag <ead> beginnen muss,
auf das zuerst Metadaten (im zwingend vorgeschriebenen EAD-Header
<eadheader> und optionalen Titelseiten, bezeichnet als Front Matter <frontmatter>Elemente) und dann die archivische Erschließung <archdesc> (siehe Bild 3.4a)
folgen. Wir haben uns statt dessen entschlossen, mit <archdesc> zu beginnen, da
dieses Element den größten Teil des Findbuchs bildet und die Informationen enthält,
mit deren Aufnahme in Inventare und Register Archivare am besten vertraut sind.
Bevor wir uns eingehend mit <archdesc> befassen, ist es vielleicht von Nutzen,
Einiges zu den anderen hochrangigen Elementen zu sagen, die vor <archdesc> in
einem kodierten Findbuch auftreten.
Das Dokumentelement <ead> umfasst alle anderen Elemente. Es zeigt einem
Computer an, dass das, was folgt, eine maschinenlesbare Version eines Findbuchs
ist, die mit Hilfe der als Encoded Archival Description bekannten SGMLDokumenttyp-Definition kodiert wurde. Wenn das Attribut AUDIENCE (Zielgruppe) in
<ead> auf „external“ gesetzt wird, wird der Inhalt sämtlicher Subelemente dargestellt,
sofern deren Attribut nicht auf „internal“ gesetzt ist. Das Element <ead> hat auch ein
Attribut namens RELATEDENCODING*, das zur Festlegung eines anderen
Kodiersystems, z. B. MARC, Dublin Core oder ISAD(G), dienen kann, mit dem viele
EAD-Elemente unter Verwendung des Attributs ENCODINGANALOG in Beziehung
gesetzt werden können. <eadheader> und <frontmatter>, die anderen beiden
hochrangigen Elemente innerhalb von <ead>, werden in Abschnitt 3.6 am Ende des
vorliegenden Kapitels im Einzelnen behandelt.
Das erforderliche Element <eadheader> ist ein wesentlicher Teil eines gut kodierten
Findbuchs. Es enthält Metadaten zu Titel, Bearbeiter und Erstellungsdatum des
Findbuchs, Angaben über die Sprache, in der das Findbuch erstellt wurde, und
Einzelheiten zu seiner Kodierung. Das optionale Element <frontmatter> enthält
Subelemente, die zur Generierung ansprechend formatierter Titelseiten und anderen
Vorseiten, wie z. B. Danksagungen und Einführungen, verwendet werden können.
Da EAD eine große Flexibilität bzgl. der Reihenfolge von Informationen innerhalb von
<archdesc> zulässt, werden im Anwenderleitfaden die Subelemente von <archdesc>
in der Reihenfolge erörtert, wie die Informationen möglicherweise in einem OnlineFindbuch vorkommen. Diese Reihenfolge entspricht wahrscheinlich nicht immer
genau der, in der Archivare die Informationen in Findbücher aufnehmen und
zusammen stellen. Wie in Abschnitt 3.2 erwähnt, können die Informationen für Teile
eines Findbuchs über einen langen Zeitraum gesammelt worden sein. Beim
Bearbeiten eines insbesondere großen und komplexen Bestandes erstellen
Archivare beim Ordnen und Gliedern u. U. Beschreibungen von getrennten und
möglicherweise nicht zusammenhängenden Teilen. Für die Anordnung dieser
*
A.d.Ü.: Original: „EAD-Instance“.
Im Sprachgebrauch von SGML ist „Instanz" der Begriff, mit dem ein bestimmtes, SGML-kodiertes Dokument, z. B. ein
einzelnes, EAD-kodiertes Findbuch, bezeichnet wird.
*
A.d.Ü.: = verwandte Kodierung.
54
62
Informationen in einer für Benutzer „logischsten” Reihenfolge soll der
Anwenderleitfaden behilflich sein.
3.5.1. Erschließung des „Ganzen”: Informationen auf Bestandsebene
<archdesc>
Beim Durchlesen folgender Abschnitte, in denen die Verwendung bestimmter EADElemente behandelt wird, ist es ggf. hilfreich, die EAD-Tag-Library zur Hand zu
haben. Der Anwenderleitfaden bietet Möglichkeiten und Ratschläge für die
Verwendung wichtiger Elemente und Attribute, und die Tag-Library ergänzt diese
Ausführungen, indem sie jedes Element definiert, alle zur Verfügung stehenden
Attribute nennt und getaggte Beispiele aufführt. Wenn Sie Schwierigkeiten haben,
den Beispielen in den nachstehenden Abschnitten zu folgen, sollten Sie die
grundlegenden Konventionen im Abschnitt „Benutzung dieses Handbuchs“ nochmals
durchlesen.55
Bei einigen Kodierbeispielen wurden einige der vorgeschriebenen Elemente
weggelassen, falls sie den Inhalt des Begleittexts verschleiern würden. Wenn Sie
unsicher sind, wo ein Element verfügbar ist oder welche Elternelemente erforderlich
sind, sollten Sie in der EAD-Tag-Library nachschlagen.
Wie in Abschnitt 3.5 angemerkt, heißt das EAD-Element, das den Text des
archivischen Findbuchs umfasst, <archdesc>. In ihm sind alle beschreibenden
Elemente enthalten. Das Element <archdesc> ist eine Hülle. Es hält die anderen
Elemente wie in einer Verpackung zusammen. Zudem bezeichnet das für
<archdesc> erforderliche Attribut LEVEL (Ebene, Stufe) die höchste
Verzeichnungsstufe innerhalb des Findbuchs. LEVEL steht normalerweise auf
„Fonds” (Bestand), „collection” (Sammlung) oder „record group” (Unterlagengruppe).
Gelegentlich bezieht sich ein Findbuch nur auf eine „series“ (Serie), „subgroup“
(Untergruppe), „subseries“ (Teilserie), „file“ (Verzeichnungseinheit/Akte) oder „item“
(Einzelstück), dann können diese Werte ebenfalls für das Attribut LEVEL von
<archdesc> gewählt werden. EAD lässt zwar diese Fälle zu, der Anwenderleitfaden
geht jedoch davon aus, dass die meisten Inventare und Register eine grundlegende
Beschreibung des Bestandes, der Sammlung oder der Unterlagengruppe enthalten,
bevor die einzelnen Komponenten beschrieben werden, und dass das Attribut
LEVEL von <archdesc> daher die höchste Stufe in der Hierarchie des Bestandes
abbilden sollte. Niedrigere Stufen in der Hierarchie werden identifiziert, indem das
Attribut LEVEL in den Komponentenangaben entsprechend eingestellt wird, wie in
Abschnitt 3.5.2 beschrieben.
In <archdesc> gibt es mehrere weitere Attribute, mit denen Informationen zum
gesamten Findbuch gesteuert oder bereitgestellt werden können:
•
Wird das Attribut AUDIENCE (Zielgruppe) auf „external“ gesetzt, kann der
Text in sämtlichen <archdesc>-Subelementen von allen Benutzern gelesen
werden, sofern das Attribut nicht bei bestimmten Subelementen auf „internal“
gesetzt wurde und der Server vor Ort nicht die Fähigkeit besitzt, den
betreffenden Text für Benutzer außerhalb des Archivs unsichtbar zu machen.
55
Zu bestimmten technischen Fragen, die die Kodierung betreffen, ist auch in späteren Kapiteln nachzuschlagen. Siehe
beispielsweise Abschnitt 4.3.5 zur Verwendung von Heading <head>, Whitespace und Interpunktion.
63
•
•
•
•
In ähnlicher Weise gilt Folgendes: Ist MARC das einzige Encodinganalog, das
für Elemente in dem Findbuch verwendet wird, kann das Attribut
RELATEDENCODING in <archdesc> auf „marc“ gesetzt werden. Dieser Wert
gilt dann für alle Subelemente.
Das Attribut LANGMATERIAL gibt die Sprache der Bestandsmaterialien an.
Der Anwenderleitfaden empfiehlt, den entsprechenden aus drei Buchstaben
bestehenden Kode für die betreffende Sprache zu verwenden (siehe ISO 6392, Codes for the Representation of Names of Languages).
Einige Archive haben Bestände, für die der Rechtsstatus der Materialien durch
Gesetz geregelt ist. Um diese Tatsache zu vermerken, kann das Attribut
LEGALSTATUS verwendet werden.
Das Attribut TYPE in <archdesc> gibt an, ob es sich bei dem Findbuch um ein
Inventar oder ein Register handelt.
Ein <archdesc>-Start-Tag, der alle vorstehend genannten Attribute enthält, kann so
aussehen (die Attribute können beliebig angeordnet werden):
<archdesc audience="external" relatedencoding="marc"
langmaterial="eng" legalstatus="public" level="fonds"
type="register">
Nachdem diese Informationen in <archdesc> angegeben wurden, führt man einige
Bestandsgrundangaben an. Dazu verwendet man das Element
Erschließungsangaben <did> (Descriptive Identification).
3.5.1.1. Grundlegende Erschließungsangaben: das hochrangige <did>
Die Elemente, die im Element Erschließungsangaben <did> zur Verfügung stehen,
sind die wichtigsten Bausteine für jede Stufe bei einem Findbuch mit mehrstufiger
Verzeichnung. Diese wichtigen Elemente beantworten Fragen wie die Folgenden:
•
•
•
•
•
•
In welchem Archiv wird das Material aufbewahrt?
Wer hat das Material erstellt?
Wie lautet der Titel des Materials?
Wann wurde das Material erstellt?
Wieviel Material ist vorhanden?
Was ist der Gegenstand des Materials?
Da sich diese Fragen auf alle Stufen eines Archivgutkomplexes beziehen, vom
Bestand, der Unterlagengruppe oder Sammlung bis hin zum Einzelstück, steht <did>
auf allen Verzeichnungsstufen zur Verfügung. Ein einmaliges Auftreten von <did> ist
vorgeschrieben (normalerweise als erstes Element innerhalb von <archdesc>).
Bestimmte Elemente innerhalb von <did> sind es jedoch nicht, da nicht alle Elemente
auf jeder Erschließungsstufe benötigt werden. Wenn beispielsweise Provenienz
<origination> (Origination) oder Archiv <repository> (Repository) für einen ganzen
Archivgutkomplex einmal genannt worden ist, muss es auf Serien- oder Aktenebene
u. U. nicht wiederholt werden.
Einer der Vorteile der Informationsbündelung in <did> liegt darin, dass dieses
Element eine Hülle für all die Informationen in einer Online-Umgebung darstellt, die
für die Recherche nach zusammenhängenden Informationsteilen zu einer
bestimmten Verzeichnungseinheit von entscheidender Bedeutung dafür sind, dass
64
Benutzer ihre Rechercheergebnisse korrekt interpretieren können. Es fördert u. U.
auch die Anwendung zweckdienlicher Erschließungsverfahren, indem es Archivare
daran erinnert, auf allen Erschließungsebenen die gleichen grundlegenden Daten zu
erfassen.
Das erste Auftreten von <did>, das für einen bestimmten Archivgutkomplex die
höchste Erschließungsstufe darstellt, dürfte es Benutzern, ohne dass sie allzu tief in
das Findbuch einsteigen müssen, ermöglichen, festzustellen, ob die Materialien für
die Recherche von Interesse sind. Um das Auffinden und Beurteilen von Quellen zu
erleichtern, muss das erste <did>, das im Folgenden als „hochrangiges <did>“
bezeichnet wird, folgenden Elemente, die weiter unten ausführlich behandelt werden,
enthalten:
•
•
•
•
•
•
Archiv <repository> (Repository)
Provenienz <origination> (Origination)
Titel der Verzeichnungseinheit <unittitle> (Title of the Unit)
Laufzeit<unitdate> (Date of the Unit)
Physische Beschreibung <physdesc> (Physical Description)
Zusammenfassung <abstract> (Abstract)
Das hochrangige <did> in seiner elementaren Form könnte daher etwa so aussehen
(die Reihenfolge der <did>-Subelemente wird von dem jeweiligen Archiv usw.
bestimmt):
<did>
<repository>Harry Ransom Humanities Research
Center</repository>
<origination>Stoppard, Tom</origination>
<unittitle>Nachlass Tom Stoppard</unittitle>
<unitdate>1944-1995</unitdate>
<physdesc>68 Kisten (8,5 lfm)</physdesc>
<abstract>Die Schriften des britischen Dramaturgen
Tom Stoppard (geb. 1937)umfassen seine gesamte Laufbahn und
bestehen aus zahlreichen Entwürfen für seine Stücke, vom
bekannten <title render="italic">Rosencrantz and Guildenstern
Are Dead</title> bis hin zu einigen nie veröffentlichten
Stücken, Korrespondenz, Fotografien und Plakaten sowie
Materialien aus Bühnen-, Fernseh- und Rundfunkproduktionen aus
aller Welt.</abstract>
</did>
Weitere Elemente wie Identifikator der Einheit / Signatur <unitid> (ID of the Unit) und
Lagerungsort <physloc> (Physical Location) sollten ebenfalls aufgenommen werden,
wenn das Archiv den Materialien eine eindeutige Kennung (ggf. eine
Zugangsnummer) zuweist und der Lagerungsort des gesamten Bestandes in dem
Findbuch angegeben ist. Es ist auch zu empfehlen, dem hochrangigen <did> eine
Kopfzeile/Überschrift <head> (Heading) zu geben und es genau mit verschiedenen
Subelementen und ENCODINGANALOG-Attributen zu versehen. Dadurch können
Suchmaschinen eine Kurzbeschreibung des Bestandes auffinden, oder die
Fortschreibung einer nur als Gerüst vorhandenen MARC-Titelaufnahme kann
erleichtert werden. Jedes dieser Subelemente und Attribute wird, wie bereits
erwähnt, in den nachstehenden Abschnitten erklärt. Ein vollständig kodiertes <did>
könnte so aussehen:
65
<did>
<head>Kurzbeschreibung der Schriften von Tom Stoppard</head>
<repository>
<corpname> The University of Texas at Austin
<subarea>Harry Ransom Humanities Research
Center</subarea>
</corpname>
</repository>
<origination>
<persname source="lcnaf" encodinganalog="100">Stoppard,
Tom</persname>
</origination>
<unittitle encodinganalog="245">Nachlass Tom Stoppard,
</unittitle>
<unitdate type="inclusive">1944-1995</unitdate>
<physdesc encodinganalog="300">
<extent>68 Kisten (8,5 lfm)</extent>
</physdesc>
<unitid type="accession">R4635</unitid>
<physloc audience="internal">14E:SW:6-8</physloc>
<abstract>Die Schriften des britischen Dramaturgen Tom
Stoppard (geb. 1937)umfassen seine gesamte Laufbahn und
bestehen aus zahlreichen Entwürfen für seine Stücke, vom
bekannten <title render="italic">Rosencrantz and
Guildenstern are Dead</title> bis hin zu einigen nie
veröffentlichten Stücken, Korrespondenz, Fotografien und
Plakaten sowie Materialien aus Bühnen-, Fernseh- und
Rundfunkproduktionen aus aller Welt.</abstract>
</did>
Eine solche Detailauszeichnung mit Subelementen und Attributen wird für die
höchste Stufe einer mehrstufigen Verzeichnung empfohlen, ist jedoch
möglicherweise auf Komponentenebene weder erforderlich noch erwünscht.
Umgekehrt sind Subelemente von <did>, z. B. Behälter <container> (Container),
Bemerkung<note> (Note), Digitales Archivobjekt <dao> (Digital Archival Object) oder
Gruppe digitaler Archivobjekte <daogrp> (Digital Archival Object Group) im
hochrangigen <did> oft unnötig. Das Subelement <container> wird in Abschnitt
3.5.2.4 behandelt. Die letztgenannten drei Elemente sind kurz in der Erörterung des
hochrangigen <did> erwähnt und werden in den Abschnitten 3.5.1.7 und 7.3.6
ausführlicher erläutert.
Für alle Subelemente in <did> steht das Attribut LABEL zur Verfügung. Dieses
Attribut funktioniert etwa so wie das Element Kopfzeile/Überschrift <head> (das
anstelle von LABEL für Elemente außerhalb von <did> verwendet wird, siehe
Abschnitt 3.5.1.7.1), und zwar insofern, als es zur Erzeugung von Druck- oder
Darstellungskonstanten verwendet werden kann. Die <did>-Subelemente haben statt
des Subelements <head> ein Attribut LABEL, weil die in den <did>-Subelementen
enthaltenen Informationen meist nur kurz sind – oft nur wenige Wörter – im
Gegensatz zu Elementen wie <scopecontent> und <bioghist>, die meist längere
Textpassagen enthalten. Wenn jedes <did>-Subelement <head> enthielte, wäre
auch ein Absatz <p> (Paragraph) erforderlich, um den Text des Elements
einzugeben. Dadurch würde sich der Taggingaufwand für so kleine
Informationsmengen praktisch verdoppeln.
66
Das Attribut LABEL ist beim höchstrangigen <did> von besonderem Nutzen, um
Benutzer bei der Interpretation der Bestandskurzbeschreibung zu unterstützen,
wogegen LABEL oder <head> an anderer Stelle in dem Findbuch möglicherweise
seltener benötigt wird. Die folgende Auszeichnung:
<did>
<repository label="Repository:">
<corpname> The University of Texas at Austin
<subarea>Harry Ransom Humanities Research
Center</subarea>
</corpname>
</repository>
<origination label="Creator:">
<persname source="lcnaf" encodinganalog="100">Stoppard,
Tom</persname>
</origination>
<unittitle label="Title:">Nachlass Tom Stoppard
<unitdate type="inclusive">1944-1995</unitdate>
</unittitle>
</did>
kann unter Verwendung eines Stylesheets folgende Darstellung bewirken:
Archiv:
The University of Texas at Austin
Harry Ransom Humanities Research Center
Nachlassgeber: Stoppard, Tom
Titel:
Nachlass Tom Stoppard, 1944-1995
Ein Stylesheet ist eine Textdatei oder eine Ausgabespezifikation, die von einem
Datenverarbeitungssystem auf ein kodiertes Findbuch angewandt wird und dazu
dient, die Darstellung bzw. Formatierung des Dokuments zu steuern.56 Stylesheets
legen fest, wie die einzelnen Elements in ihrem jeweiligen Kontext innerhalb des
Dokuments ausgegeben werden sollen. Jedem Element können bestimmte
Darstellungsarten, z. B. Schriftgrad, Schriftart und Farbe, zugewiesen werden. Ein
Stylesheet kann anstelle des Attributs LABEL wie im obigen Beispiel auch dazu
verwendet werden, um vorhergehende Zeichen oder Abstände in ein Element
einzufügen. Mit einem Stylesheet kann die Darstellungs- oder Formatierungsart des
Elements, je nachdem, an welcher Stelle des Findbuchs es auftritt, geändert werden.
Beispielsweise soll beim hochrangigen <did> das Element <unittitle> der Sammlung
oder des Bestandes in einer gesonderten Zeile, in einer bestimmten Schriftgröße und
–art erscheinen. Außerdem soll das Wort „Titel“, gefolgt von einem Komma,
vorangestellt werden. An anderer Stelle in dem Findbuch soll das Element <unittitle>
einer Komponente in derselben Zeile in einem kleineren Schriftgrad als bei dem
höherrangigen <unittitle> erscheinen. Mit Hilfe des Stylesheets lassen sich diese
Einstellungen vornehmen, ohne dass wie bei einem Textverarbeitungs- oder HTMLDokument Formatierungskodes „verdrahtet“ werden müssen.
Das Weglassen von „Formatierungsanweisungen“ aus den Daten ermöglicht es, das
Aussehen sämtlicher Findbücher lediglich durch Ändern des Stylesheets zu
verändern. Es darf jedoch nicht vergessen werden, dass Benutzer das Stylesheet
des Erstellers durch eine anderes ersetzen kann. Durch Verwendung des Attributs
56
Weitere Informationen zu Stylesheets siehe Abschnitt 5.3.3.
67
LABEL lässt sich u. U. besser sicherstellen, dass zugewiesene Wörter unabhängig
von dem damit verwendeten Stylesheet bei dem Findbuch verbleiben.
Es ist auch zu beachten, dass mehrere Stylesheets für Findbücher verwendet
werden können. Es kann beispielsweise eine Vorlage für die Online-Darstellung und
eine weitere für Druckfindbücher verwendet werden. Durch das Erstellen von EADFindbüchern ist eine Trennung zwischen dem Inhalt des Textes und seiner
Darstellung möglich. Dadurch kann der gleiche Text auf verschiedene Art und Weise
verarbeitet oder formatiert werden.
3.5.1.2. Verwendung der <did>-Subelemente
3.5.1.2.1. Archiv <repository> (Repository)
In der verteilten Online-Umgebung, in der zahlreiche EAD-Findbücher bereitgestellt
werden, ist die Nennung des Archivnamens im Findbuch von entscheidender
Bedeutung. Diese Information wurde in gedruckte Findbücher möglicherweise nicht
aufgenommen. Das Element <repository> bezeichnet die Institution bzw.
Dienststelle, die für die Benutzung der Materialien zuständig ist. Wie in dem Beispiel
mit Tom Stoppard in Abschnitt 3.5.1.1 können die Elemente Körperschaftsname
<corpname>57 (Corporate Name) und Nachgeordneter Bereich <subarea>
(Subordinate Area) innerhalb von <repository> verwendet werden. Diese genaue
Auszeichnung erlaubt ein flexibles Darstellen und Recherchieren der Informationen.
(Der Name der Stamminstitution soll z. B. in der Schriftart Times New Roman, 18
Punkt, Fettdruck und der Name des Archivs in Times New Roman, 14 Punkt,
Fettdruck erscheinen, oder die Möglichkeit zur Beschränkung von Recherchen auf
Bestände in bestimmten Abteilungen oder anderen Organisationsbereichen einer
Institution soll leichter gestaltet werden.)
Es ist zu beachten, dass das Archiv, das die Benutzung der Materialien ermöglicht,
zumeist auch die Institution ist, bei der die Materialien aufbewahrt werden. Ist das
jedoch nicht der Fall, so sind der Name und andere sachdienliche Informationen über
den Lagerungsort in das Element <physloc> aufzunehmen.
3.5.1.2.2. Provenienz <origination> (Origination)
Im Element <origination> ist die Einzelperson, Familie bzw. Organisation angegeben,
die für die Erstellung, Sammlung oder Zusammenstellung der beschriebenen
Materialien vor deren Eingliederung in ein Archiv zuständig war. Wie im Fall
<repository> ist es auch hier möglich, bestimmte Namenselemente (Personenname,
(Personal Name <persname>, Familienname, Family Name <famname> oder
Körperschaftsname, Corporate Name <corpname>) in das Element <origination>
einzubetten, um eine genauere Spezifizierung zu erreichen. Darüber hinaus kann mit
dem Attribut ROLE angegeben werden, ob der Ersteller der Nachlassgeber, ein
Sammler war oder in Bezug auf die Materialien eine andere Funktion hatte. Wie
bereits in Abschnitt 3.5.1.1 erwähnt, ist es auch möglich, diese Information durch
Verwendung des Attributs LABEL in <origination> zu erfassen und das Wort
„Nachlassgeber“ bzw. „Sammler“ vor oder nach dem Text in <origination> erscheinen
zu lassen. Beispielsweise könnte folgende Auszeichnung:
<origination label="creator">Mary Hutchinson</origination>
57
Erläuterung von Elementen zu kontrolliertem Vokabular siehe Abschnitt 3.5.3.
68
zusammen mit den Anweisungen eines Stylesheets zu einer der folgenden
Ausgaben führen:
Nachlassgeber: Mary Hutchinson
Mary Hutchinson, Nachlassgeber
Zusätzlich zum Attribut LABEL hat das Element <origination>, wie viele andere EAD
Elemente auch, ein Attribut ENCODINGANALOG, mit dessen Hilfe ein MARC- oder
sonstiges Auszeichnungsfeld angegeben werden kann, auf das sich dieses Element
bezieht (in diesem Fall das MARC-100-Feld). Beide folgenden Optionen sind in EAD
gültig, die letzte ist jedoch genauer:
<origination encodinganalog="100" label="creator">Mary
Hutchinson</origination>
<origination label="creator">
<persname encodinganalog="100">Mary
Hutchinson</persname>
</origination>
Es ist auch möglich, die Daten unter <persname> umzukehren (Hutchinson, Mary),
um die Formatierung eines MARC-100-Feldes für die Recherche anzupassen. Mit
dem Attribut NORMAL lässt sich das gleiche Ergebnis erzielen:
<origination label="creator">
<persname encodinganalog="100" normal="Hutchinson,
Mary">Mary Hutchinson</persname>
</origination>
Weitere Informationen über „Namen”-Subelemente sind in der Erklärung des
Elements <controlaccess> in Abschnitt 3.5.3 enthalten.
3.5.1.2.3. Titel der Verzeichnungseinheit <unittitle> (Title of the Unit)
Archivare weisen Beständen normalerweise Titel zu, weil keine bibliografische
Einheit wie etwa eine Titelseite vorhanden ist, von der Informationen für
Verzeichnungszwecke übernommen werden können. Das Element <unittitle> dient
dazu, auf jeder Verzeichnungsstufe den originalen oder archivisch gebildeten Titel
der Materialien anzugeben. Nationale Inhaltserschließungsstandards wie APPM oder
RAD liefern Archivaren oft eine Anleitung zur Titelbildung für archivische Materialien.
Beim hochrangigen <did> ist <unittitle> der Titel des Bestandes oder möglicherweise
der Titel einer Teilgruppe oder Serie, je nachdem, welches die höchste
Verzeichnungsstufe in dem Findbuch ist. Enthält der Titel des Archivgutkomplexes
den Orginaltitel, kann es erwünscht sein, das Element Title <title> für Darstellungsoder Recherchezwecke in <unittitle> einzubetten, z. B. so:
<unittitle encodinganalog="245">Stuart Johnsons Sammlung von
<title>Alice in Wonderland</title> Memorabilia</unittitle>
Diese Auszeichnung ermöglicht Darstellung oder Ausdruck des Titels „Alice in
Wonderland“ auf jede vom Archiv gewünschte Art und Weise, z. B. in Kursivdruck,
69
durch Verwendung des Attributs RENDER innerhalb von <title> oder eines
Stylesheets. Außerdem wird dadurch die Suche nach der Phrase „Alice in
wonderland“ bei einer Recherche mit <unittitle> oder <title> sowie – durch
Verwendung des Attributs ENCODINGANALOG – der Export des Textes im Element
<unittitle> in eine MARC-Titelaufnahme für den archivischen Bestand erleichtert.
3.5.1.2.4. Laufzeit <unitdate> (Date of the Unit)
Die Angabe des Zeitraums, über den sich ein Bestand erstreckt, gilt als
Grundbestandteil der meisten Findbücher. In EAD lassen sich die Laufzeitangaben
der Materialien mit Hilfe von <unitdate> in <unittitle> einbetten. Das Element
<unitdate> steht auch außerhalb von <unittitle> zur Verfügung. Daher sind beide
nachstehenden Beispiele gültig. Es ist zu beachten, dass <unitdate> ein optionales
Attribut TYPE hat, mit dem angegeben werden kann, ob es sich bei den
Laufzeitangaben um einen Zeitraum, mehrere Datumsangaben oder ein Einzeldatum
handelt.
<unittitle>Stuart Johnson Sammlung von <title>Alice in
Wonderland</title> Erinnerungsstücken, <unitdate type="inclusive">
1905-1928</unitdate></unittitle>
<unittitle>Stuart Johnson Sammlung von <title>Alice in
Wonderland</title> Erinnerungsstücken, </unittitle>
<unitdate type="inclusive">1905-1928</unitdate>
Jedes Archiv muss eines der o. g. Kodierverfahren in Bezug auf die relative
Anordnung von <unittitle> und <unitdate> wählen und sowohl innerhalb eines
einzelnen Findbuchs als auch bei allen Findbüchern einheitlich vorgehen. Die
nationalen Erschließungsstandards können in dieser Hinsicht Unterstützung bieten.
Archivare, die ihre Materialien mit Hilfe von APPM (Archives, Personal Papers and
Manuscripts) katalogisieren, sind daran gewöhnt, Laufzeit- und andere
Datumsangaben für einen Archivgutkomplex als Teil des Titels anzusehen, während
Anwender von RAD (Rules for Archival Description) solche Angaben als gesondertes
Datenelement im Bereich Erstellungszeitraum (Dates of Creation Area)58 behandeln.
In beiden Fällen können <unittitle>- und <unitdate>-Informationen zusammen
dargestellt werden.
Das Element <unitdate> hat auch ein Attribut NORMAL, mit dessen Hilfe
Laufzeitangaben in standardisierter Form möglich sind: JJJMMTT (Jahr, Monat, Tag).
Bei einheitlicher Verwendung erleichtert dieses Attribut die Suche nach
Laufzeitangaben. Diese sind in Findbüchern jedoch in einer Vielzahl von Formaten
vorhanden, wie folgende Beispiele zeigen:
März 17, 1946
17. März 1946
1946 März 17
ca. 1946
1946?
1940er
o.D.
undatiert
58
Rules for Archival Description, Abschnitt 1.4.
70
Aus diesem Grund ist die zusätzliche Auszeichnung zur Bereitstellung
standardisierter Laufzeitangaben für Recherchezwecke u. U. zu zeitraubend.
3.5.1.2.5. Physische Beschreibung <physdesc> (Physical Description)
Archivare beschreiben den Umfang ihrer Bestände auf verschiedene Weise, z. B. mit
Längen- oder Raummaßen (lfm oder m³), der Anzahl von Kisten oder anderen
Behältern oder der Anzahl der Gegenstände. Oft handelt es sich hierbei um eine
ganz einfache Formulierung, manchmal ist es auch eine Reihe von Aussagen, mit
denen verschiedene Formate von Materialien innerhalb eines Bestand bezeichnet
werden. In anderen Fällen enthält die physische Beschreibung eines Bestandes auch
Angaben über das Verfahren seiner Herstellung.
In das Element <physdesc> kann eine kurze Angabe zum Umfang der Materialien
ohne Verwendung von Subelementen aufgenommen werden:
<physdesc>45 Kubikmeter</physdesc>
<physdesc>3800 Fotographien</physdesc>
In vielen Fällen genügt diese Stufe der Auszeichnung. Mit Subelementen, z. B.
Umfang <extent> (Extent) und Genre oder Form <genreform> (Genre/Physical
Characteristic) sowie den Attributen in <physdesc> kann die Verzeichnung jedoch
noch viel genauer gestaltet werden:
<physdesc encodinganalog="300">45 Kubikmeter</physdesc>
<physdesc>
<extent>3800</extent> <genreform>schwarz/weiße Abzüge
(Fotografien)</genreform>
</physdesc>
<physdesc>
<extent>46</extent> <genreform>Tonaufnahmen</genreform>
</physdesc>
Was ist der Nutzen einer solchen zusätzlichen Kodierung? Wenn Informationen
detailliert kodiert werden, wird die Möglichkeit zur Bearbeitung und
Wiederverwendung der Daten verbessert. Bei einer Recherche können Benutzer ggf.
nach einer bestimmten Art von Fotografien suchen, z. B. Albuminabzüge,
Salzpapierabzüge oder handkolorierte Abzüge. Dies ist zwar auch über ein
Schlagwort möglich. Die Treffergenauigkeit wird jedoch durch Suchen von Begriffen
dieser Art in einem <physdesc>- oder <genreform>-Element erhöht.
3.5.1.2.6 Zusammenfassung <abstract> (Abstract) bzw. Bemerkung <note>
(Note)
In einer Online-Umgebung kann es für Benutzer äußerst hilfreich sein, wenn auf der
ersten oder zweiten Seite eines Findbuchs eine kurze Aussage zum Kontext und
Inhalt eines Archivgutkomplexes steht. Solche Informationen können Benutzer dabei
unterstützen, den Wert des Bestandes ihre jeweilige Forschungsfrage schnell zu
erkennen. Zu diesem Zweck wurde das Element <abstract> geschaffen. Im
71
hochrangigen <did> ist <abstract> u. U. eine Mischung aus einer Skizze zur
Provenienzstelle und einer „Scope and Content Note“. Mit anderen Worten, es kann
eine kurze Aussage zur Provenienz oder zum Sammler der Materialien sowie eine
sehr allgemeine Zusammenfassung der Themenschwerpunkte enthalten. Eine
Zusammenfassung muss möglichst kurz sein, kann jedoch einschlägige
Informationen enthalten. Die Elemente Entstehungsgeschichte <bioghist> (Biography
or History) und Gegenstände <scopecontent> (Scope and Content), die in den
Abschnitten 3.5.1.5 und 3.5.1.6 beschrieben sind, werden für ausführlichere
Informationen verwendet.
<abstract>Das Archiv enthält Aufzeichnungen, die zumeist aus den
Jahren vor 1837 stammen, als das Archidiakonat aus der
Gerichtsbarkeit von York in die von Lincoln wechselte. Die meisten
Dokumente entstanden bei den halbjährlichen Visitationen des
Archidiakons und den in seinem Gerichtshof verhandelten Fällen,
wobei die frühesten aus dem 16. Jh. datieren. Das Archidiakonat von
Nottingham wurde mit der Grafschaft Derby [aus der Diözese
Lichfield] vereinigt, um die Diözese Southwell zu bilden.</abstract>
Das Element <abstract> kann leicht mit dem Element <note> verwechselt werden,
das ebenfalls in <did> verfügbar ist. Das Element <note> darf nicht für
beschreibende Zusammenfassungen verwendet werden. Es dient vielmehr zur
Angabe von Quellen zu Zitaten (z. B. eine Fußnote), für kurze erklärende Aussagen
oder Hinweise für Benutzer oder zu anderen Zwecken, z. B. dazu, die Grundlage
einer Behauptung anzugeben. Normalerweise sollte das allgemeine Textelement
<note> nicht verwendet werden, wenn ein spezifischeres, strukturelles EAD-Element
geeigneter ist.
<note><p>Bemerkung für Recherchen: Zur Anforderung von Materialien
bitte Lagerungsort und Kistennummer(n) (s. u.) angeben.</p></note>
Im hochrangigen <did> könnte ein <note>-Element auch dazu verwendet werden,
Benutzer darauf hinzuweisen, dass die im hochrangigen <did> beschriebenen
Materialien eine Komponente eines größeren Archivgutkomplexes bilden, der in
gesonderten EAD-Instanzen erfasst werden musste, weil es Schwierigkeiten beim
Parsen und Herunterladen einer einzigen großen Findbuchdatei für den gesamten
Bestand bzw. die Unterlagengruppe gab. Die Erstellung und Verknüpfung mehrerer
gesonderter Findbücher für einen einzigen großen Bestand ist in Verbindung mit dem
Element Archivischer Nachweis <archref> (Archival Reference) in Abschnitt 7.3.3
genauer beschrieben.
Aufgrund seiner Eignung für erläuternde Bemerkungen steht das Element <note>
auch außerhalb von <did> zur Verfügung (siehe Erläuterung in Unterabschnitt
3.5.1.7.3).
3.5.1.2.7. Identifikator der Einheit / Signatur <unitid> (ID of the Unit)
Zu Kontroll- und Zitierzwecken weisen Archivare Verzeichnungseinheiten oft
eindeutige Kennnummern oder alphanumerische Zeichenfolgen zu. Zu solchen
Kennungen gehören Zugangs-, Abgabe-, Klassifizierungs- oder
Eintragungsnummern in einem Verzeichnis oder Katalog. Das Element <unitid> dient
zur Kodierung solcher Nummern. Es darf nicht mit <physloc> oder <container>
72
verwechselt werden, mit denen der Lagerungsort oder der Behälter des Materials
kodiert wird.
In <unitid> stehen zwei Attribute zur Verfügung, die nirgendwo anders in EAD
verfügbar sind und nur im hochrangigen <did> verwendet werden sollten:
COUNTRYCODE und REPOSITORYCODE. COUNTRYCODE liefert den dem
Standard ISO 3166 Codes for the Representation of Names of Countries
entnommenen eindeutigen Kode für das Land, in dem das Archivgut aufbewahrt
wird. REPOSITORYCODE enthält einen weiteren eindeutigen Kode. Dieser
entstammt der offiziellen Archivkodeliste eines Landes, in dem sich das Archiv
befindet. Er wird für das Archiv angegeben, das für die Kontrolle der Erschließung
der Materialien verantwortlich ist.59 Beide Attribute beziehen sich speziell auf die
ISAD(G)-Bezugskodes im Identity Statement Area60 und gewährleisten die
Eindeutigkeit von <unitid> in einer multinationalen Findbuch-Datenbank. Falls
erwünscht, können die Attributwerte von einem Stylesheet so gesteuert werden, dass
der Name des Landes und des Archivs als Teil der <unitid>-Information dargestellt
bzw. ausgedruckt wird. Auf der höchsten Erschließungsstufe könnte ein <unitid> so
aussehen:
<unitid countrycode="gbr" repositorycode="067">ES</unitid>
3.5.1.2.8. Lagerungsort <physloc> (Physical Location )
Einige Findbücher enthalten Informationen über den Lagerungsort von Materialien
innerhalb des Archivs. Diese Information wird mit Hilfe des Elements <physloc>
kodiert, das sich auf eine Stelle in einem Regal bezieht oder besagt, dass ein
Bestand an einem anderen Ort aufbewahrt wird und Benutzer darauf hinweist, dass
die Materialien u. U. nicht sofort zur Verfügung stehen.
<physloc>14E:SW:6-8</physloc>
<physloc>Die Mary Hutchinson Papiere werden an einem anderen Ort
aufbewahrt. Die Bereitstellung der Materialien ist 24 Stunden zuvor
anzufordern.</physloc>
<physloc> kann wiederholt werden. Daher können bei Bedarf beide Arten von
Informationen bereitgestellt werden. Beschließt das Archiv, den Lagerungsort im
Regal für seine eigenen Zwecke in die Findbücher aufzunehmen, kann die
Information kodiert, jedoch durch Verwendung des Attributs AUDIENCE dem
öffentlichen Zugriff entzogen werden, wenn der eingesetzte Server in der Lage ist,
als „internal“ kodierte Informationen zu unterdrücken, wenn er die EAD-Dateien zu
Benutzern überträgt:
<physloc audience="internal">14E:SW:6-8</physloc>
59
Wenn das betreffende Land keine offizielle Liste hat, darf dieses Attribut nicht verwendet werden. Bei US-Archiven ist der
Kode folgendem Dokument zu entnehmen: USMARC Code List for Countries, prepared by Network Development and MARC
Standards Office, Washington 1993.
60
ISAD(G), Abschnitt 3.1.
73
3.5.1.2.9. Digitales Archivobjekt <dao> (Digital Archival Object) und Gruppe
digitaler Archivobjekte <daogrp> (Digital Archival Object Group)
Eine der herausragenden Eigenschaften von EAD ist es, Findbücher mit digitalen
Bildern der erfassten Materialien verknüpfen zu können. Dafür gibt es zwei
besondere Verknüpfungselemente, <dao> und <daogrp>. Das Element <dao> wird
zum Zeigen auf Bilder verwendet, und <daogrp> dient dem Bündeln mehrerer
Versionen desselben Bildes (z. B. eine Thumbnailansicht und eine
Benutzungskopie). Da diese Elemente an vielen Stellen eines Findbuchs auftreten
können, sind sie zusammen mit anderen einsetzbaren Elementen in Abschnitt 3.5.1.7
behandelt. Verschiedene Aspekte zu ihrer Verwendung finden sich auch in der
Erläuterung von Verknüpfungselementen in Abschnitt 7.3.6 .
3.5.1.3. Begriffe aus Normansetzungen <controlaccess> (Controlled Access
Headings)
In einem Findbuch können Hunderte von Namen und Themen vorkommen. Die
wichtigsten von ihnen, die sich auf den Gesamtbestand beziehen oder dessen
inhaltlichen Schwerpunkte hervorheben, kann man hervorheben, indem man sie
unter <archdesc> im Element Begriffe aus Normansetzungen <controlaccess>
(Controlled Access Headings) zusammenfasst. Diese Normbegriffe stimmen oft mit
denen in den Feldern 1xx, 6xx und 7xx der MARC-Titelaufnahme für den
betreffenden Bestand überein. Aufgrund ihres Wertes als Suchbegriffe werden sie
von manchen Archiven am Anfang eines Findbuchs angeordnet, gleich hinter dem
hochrangigen <did>, so dass Benutzer, die bei einer Recherche in dem Bereich
<controlaccess> landen, sich gleich in der Nähe der Zusammenfassung befinden, die
im hochrangigen <did> steht. Einige dieser Titel können auch in Subelementen von
<did> eingebettet werden, wie in Abschnitt 3.5.1.1 beschrieben.
Ansetzungskontrollierte Zugriffsbegriffe und ihre Anordnung und Verwendung in
EAD-Findbüchern sind in Abschnitt 3.5.3 im Einzelnen beschrieben.
3.5.1.4. Verwaltungstechnische Informationen <admininfo> (Administrative
Information)
Findbücher enthalten häufig Informationen zur Übernahme, Bestandsgeschichte,
Bearbeitung und Verwaltung von Archivgut. Aussagen zu den Bedingungen der
Benutzung, der Verwendung und Vervielfältigung, der Verfügbarkeit von Mikrofilmen
oder anderen Konversionsformen können ebenfalls Teil der Findbücher sein,
Benutzern wesentliche Angaben darüber zu liefern, wie sie zu den archivischen
Materialien Zugang erhalten und sie nutzen können. Das Element
Verwaltungstechnische Informationen <admininfo> (Administrative Information) ist
geeignet, um derartige Informationen eines Findbuchs zusammenzustellen. Dieses
optionale Hüllenelement ist für Hintergrundinformationen bestimmt, die ggf. von
Benutzern benötigt werden, um Zugriff auf das Archivgut zu erhalten, es einordnen
zu können und die darin enthaltenen Informationen zu nutzen. Das Element
<admininfo> kann auch Angaben enthalten, die Archive beim Bestandsmanagement
unterstützen.
Auf der höchsten Ebene innerhalb von archivischer Erschließung <archdesc>
(Archival Description) kann <admininfo> dazu dienen, Informationen zum
Bestandsmanagement für den gesamten Archivgutkomplex bereitzustellen.
74
<admininfo> kann auch auf <c>-Ebene verwendet werden, um Informationen zu
einer Teilgruppe, Serie bzw. Teilkomponente zu liefern. Anders als die <did>Subelemente kann <admininfo> nicht unmittelbar Text, sondern nur andere Elemente
enthalten. Zu den innerhalb von <admininfo> verfügbaren Subelementen gehören
Kopfzeile/Überschrift <head>, Absatz <p> und Liste <list> sowie neun
inhaltsspezifische Elemente:
•
•
•
•
•
•
•
•
•
Beschreibung der Zugänge <acqinfo> (Acquisition Information)
Bestandsgeschichte <custodhist> (Custodial History)
Benutzungsbeschränkungen <accessrestrict> (Restrictions on Access)
Benutzungsbedingungen <userestrict> (Restrictions on Use)
Konversionsformen <altformavail> (Alternate Form Available)
Zitierweise <prefercite> (Preferred Citation)
Bewertung <appraisal> (Appraisals)
Zugänge <accruals> (Accruals)
Bearbeitungsinformationen <processinfo> (Processing Information)
Jedes dieser Subelemente ist in den folgenden Abschnitten beschrieben. Die
Verwendung der allgemeinen Textelemente wird in Abschnitt 3.5.1.7 erläutert.
Wie alle Elemente auf der <did>-Ebene ist <admininfo> rekursiv, d.h., ein
<admininfo>-Element kann ein weiteres <admininfo>-Element enthalten. Diese
Eigenschaft ist nützlich, wenn für verschiedene Teile eines Bestandes
unterschiedliche Gruppen von <admininfo>-Einzelheiten benötigt werden, z. B.
mehrere Zugangsnummern. Die Rekursivität erleichtert auch die Verwendung
mehrerer Kopfzeilen oder Unterüberschriften innerhalb von <admininfo>. Kopfzeilen
sind unter Berücksichtigung der Benutzerkenntnisse zu erstellen. Benutzer können u.
U. mit dem Elementnamen oder der archivischen Terminologie nichts anfangen.
Außerdem kann <admininfo> wiederholt werden. Daher können für Benutzer
entscheidende Informationen, etwa Benutzungsbeschränkungen, am Anfang der
bereitgestellt werden, wogegen Informationen, die vor allem für Archivmitarbeiter von
Nutzen sind, z. B. wann und von wem der Bestand bearbeitet wurde, nach
<scopecontent> oder an einer anderen Stelle im Findbuch zur Verfügung gestellt
werden können.
Das Daten zum Element <admininfo> können nicht nur in spezifischen
Subelementen sondern auch in ein oder mehreren <p>-Elemente erfasst werden.
Das kann sinnvoll sein, wenn sich bei der Konversion von Altdaten aus einem
vorhandenen Text spezifische Teile administrativer Informationen nicht ohne
Weiteres herausziehen lassen. Dieses Verfahren führt allerdings dazu, dass man es
anschließend mit einem recht undifferenzierten Textblock mit sehr eingeschränkten
Möglichkeiten zur Verarbeitung oder Wiederverwendung zu tun hat. Dagegen wird
durch individuelles Taggen der innerhalb <admininfo> verfügbaren
inhaltsspezifischen Elemente wird die Nutzbarkeit der Informationen in einer OnlineUmgebung beträchtlich erhöht. Jedes <admininfo>-Subelement enthält ein
optionales Element <head> und die erforderlichen <p>-Elemente, in die Text
eingegeben werden kann.
Enthält ein Element standardmäßige Textstücke, die sich auf verschiedene
Findbücher beziehen, ist die Verwendung eines Zeigerelements zu Textbausteinen in
Erwägung zu ziehen, die außerhalb des Findbuchs gespeichert sind (weitere
75
Einzelheiten siehe Abschnitt 6.5 über Entitäten). Diese Vorgehensweise eignet sich
besonders für Texte, die später Änderungen unterworfen sein können, z. B. Anschrift
des Archivs, Benutzungsbestimmungen oder Hinweise zum Bestellen von
Mikrofilmkopien.
Kein <admininfo>-Subelement ist vorgeschrieben, und alle <admininfo>Subelemente sind wiederholbar. Einige von ihnen, z. B. <acqinfo>, <accessrestrict>,
<userestrict> und <prefercite>, können in jedem Findbuch von Nutzen sein, während
andere u. U. nur für bestimmte Bestände benötigt werden. Die Subelemente können
zwar innerhalb von <admininfo> in beliebiger Reihenfolge stehen. In sämtlichen
Findbüchern ist jedoch konsequent eine Reihenfolge einzuhalten. Es ist zu
überlegen, ob die für Benutzer (und nicht für die Archivmitarbeiter) wichtigsten
Elemente an erster Stelle anzuordnen sind. Beispielsweise könnten in einem
Element <admininfo> die Subelemente <accessrestrict> und <altformavail> sofort auf
das hochrangige <did> folgen. Später, nach <scopecontent> oder an anderer Stelle
des Findbuchs, könnte ein weiteres Element <admininfo> geöffnet werden, das die
Subelemente <appraisal> und <processinfo> enthält. Die in diesem Abschnitt
verwendete Reihenfolge der Subelemente ist ein Vorschlag. Für die jeweilige
Umgebung können auch andere logische oder durch die Darstellung bestimmte
Überlegungen wichtiger sein.
Jedes Subelement hat die Attribute AUDIENCE und ENCODINGANALOG. Das
Attribut AUDIENCE kann auf „internal“ gesetzt werden, um die Darstellung
bestimmter Elemente auf Archivmitarbeiter zu beschränken (es ist jedoch zu
beachten, dass die Fähigkeit zum Unterdrücken der Darstellung dieses Attributs von
der eingesetzten Software abhängt, wie an anderer Stelle bereits erwähnt). Das
Attribut ENCODINGANALOG kann dazu verwendet werden, um die <admininfo>Subelemente mit entsprechende Datenelemente in MARC oder anderen
Kodiersystemen in Beziehung zu setzen. (Zu den MARC- und ISAD(G)Entsprechungen siehe die Crosswalks in Anhang B.)
3.5.1.4.1. Beschreibung der Zugänge <acqinfo> (Acquisition Information) und
Bestandsgeschichte <custodhist> (Custodial History )
Die Verfahren in Archiven zur Erfassung von Angaben zur Bestandsgeschichte sowie
zur Dokumentation des Zugangs von Archivgut sind sehr unterschiedlich. Bei EAD
stehen diese Informationen in den folgenden zwei Subelementen von <admininfo>:
•
•
Beschreibung der Zugänge <acqinfo> (Acquisition Information)
Bestandsgeschichte <custodhist> (Custodial History)
Im Element <acqinfo> werden Informationen zur unmittelbaren Provenienz und zu
den Umständen kodiert, unter denen die Materialien übernommen wurden (Stiftung,
Übertragung, Kauf oder Depositum). Es kann zweckmäßig sein, weitere Einzelheiten
der Übernahme mit Hilfe von Elementen innerhalb von Absatz <p> zu
dokumentieren. Beispielsweise kann eine Zugangsnummer oder ein Kennzeichen
der abgebenden Person als <num type="donor"> und der Name der abgebenden
Person mit <persname> oder <corpname> getaggt werden, wobei das Attribut ROLE
entsprechend zu setzen ist:
76
<acqinfo>
<p>Der Bestand, <num type="accession">77-135</num>, wurde
dem Archiv übergeben, und zwar
<date type="accession">1977</date> von <persname
role="donor">Georgia O'Keeffe</persname>.</p>
</acqinfo>
Das Element <custodhist> kann nicht nur zur Dokumentation der unmittelbaren
Provenienz der Materialien in <acqinfo>, sondern auch zur Kodierung von
Informationen über die bisherige Bestandsgeschichte dienen. Diese Angaben
wurden bisher oft in der Entstehungsgeschichte <bioghist> oder unter Gegenstände
<scopecontent> aufgenommen. <custodhist> enthält einen Bereich zur Beschreibung
sowohl des konkreten Besitzes als auch des geistigen Eigentümers der Materialien
sowie von Veränderungen bzgl. des Besitzes und/oder Aufbewahrungsorts, die für
die Autorität, Integrität und Interpretation der Materialien von Bedeutung sein können.
Ein Archivgutkomplex ist beispielsweise von verschiedenen Stellen innerhalb einer
Körperschaft aufbewahrt und ergänzt worden, oder Familienunterlagen sind von
einer Generation zur nächsten weitergegeben worden. Wenn Benutzer diese
Bestandsgeschichte kennen, kann dies bei der Interpretation der Materialien eine
Hilfe sein und sich auf die Beurteilung der Authentizität der Materialien auswirken.
(Zu Zugängen und Bewertung siehe auch Abschnitt 3.5.1.4.5, zu Informationen zu
von dem Bestand separierten Materialien siehe Abschnitt 3.5.4.4.)
<custodhist>
<p>Die Unterlagen der Ocean Falls Corporation wurden von
Pacific Mills Ltd. und deren Nachfolgern aufbewahrt, bis Werk
und Standort 1973 von der Provinzialregierung von B.C.
übernommen wurden. 1976 wurden die Unterlagen zur Ocean Falls
Public Library geschafft, die mit der Neuordnung in der
gegenwärtigen Form begann. Das Projekt wurde jedoch aus
Geldmangel nicht abgeschlossen, und der Bestand lag im Keller
der Bibliothek, bis die Crown Corporation, B.C. Cellulose,
1980 die Schließung des Werks bekannt gab. Mehrere Jahre lang
wurden die Unterlagen vernachlässigt und von einem
Aufbewahrungsort zum anderen verschoben, als Gebäude
abgerissen wurden. Durch diese Vernachlässigung entstanden
Wasserschäden und erhebliche Verluste. Als 1986 der endgültige
Abriss des Ocean Falls Werks bekannt gegeben wurde, trug eine
Gruppe von Kuratoren vom Royal British Columbia Museum das
zusammen, was von dem Bestand noch übrig war. Diese Reste
wurden Ende 1986 vom Provincial Archives übernommen.</p>
</custodhist>
Es wird empfohlen, den Anfang des Findbuchs nicht mit zu ausführlichen Aussagen
zur Übernahme bzw. Bestandsgeschichte zu verkomplizieren, da sie für Benutzer
beim erstmaligen Zugriff wahrscheinlich nicht sofort von Interesse sind. Es sollten nur
die Informationen bereitgestellt werden, die Benutzer benötigen, um sich vom
Bestand zunächst einen Eindruck zu verschaffen und festzustellen, ob er für die
jeweilige Fragestellungen geeignet ist. Ausführlichere Aussagen zur Übernahme
bzw. Bestandsgeschichte lassen sich besser nach Informationen anordnen, die für
die Benutzer von größerem Interesse sind, z. B. Angaben in Scope and Content
<scopecontent> und Component <c> (siehe Abschnitte 3.5.1.6 bzw. 3.5.2).
77
3.5.1.4.2. Benutzungsbeschränkungen <accessrestrict> (Restrictions on
Access) und Benutzungsbedingungen <userestrict> (Restrictions on Use)
Aufgrund von Vereinbarungen mit Nachlassern, der Schutzbedürftigkeit des Inhalts
oder des Zustands von Materialien, außerhäuslicher Lagerung oder gesetzlichen
Regelungen kann die Benutzung von Archivgut beschränkt sein. Das Element
<accessrestrict> (Restrictions on Access) enthält Informationen zu Bedingungen, die
die Verfügbarkeit der in dem Findbuch beschriebenen Materialien beeinflussen. Das
Element kann auch dazu verwendet werden, das Fehlen solcher Beschränkungen
auszudrücken.
<accessrestrict>
<p>Dieser Bestand steht für Recherchen zur Verfügung, mit
Ausnahme einer Kiste mit Bändern und Tagebüchern, die bis
zum Tode von Plunkett oder bis die Familie Plunkett
ausdrücklich ihre Genehmigung zur Nutzung erteilt hat,
versiegelt bleibt. </p>
</accessrestrict>
Nachdem Benutzer die archivischen Materialien eingesehen haben, kann es
Beschränkungen zur Weitverwendung der Informationen für Zitate,
Veröffentlichungen oder sonstiger Wiedergabe geben. Diese können im Element
Restrictions on Use <userestrict> angegeben werden. Die Benutzungsbedingungen
können vom Archiv, vom Nachlassgeber oder durch eine gesetzliche Bestimmung
festgelegt werden. Mit dem Element <userestrict> kann auch das Nichtvorliegen
solcher Beschränkungen ausgedrückt werden.
<userestrict>
<p>Die Materialien sind gemeinfrei. </p>
</userestrict>
<userestrict>
<head>Besitz und literarische Rechte</head>
<p> Der Bestand Gertrude Stein und Alice B. Toklas ist das
Eigentum der Beinecke Rare Book and Manuscript Library, Yale
University. Literarische Rechte, einschließlich Copyright,
gehören den Verfassern oder deren gesetzlichen Erben oder
Rechtsnachfolgern. Für weitere Informationen wenden Sie sich
bitte an den zuständigen Kurator.</p>
</userestrict>
3.5.1.4.3. Konversionsformen <altformavail> (Alternative Form Available)
Es ist für Benutzer von Vorteil, zu wissen, dass ein Bestand oder Teile davon in
mehreren Formaten zur Verfügung stehen und dass man sie ggf. in einem anderen
Format als dem des Originals benutzen muss oder dass man die Materialien nutzen
kann, ohne das Archiv aufzusuchen. Das Vorhandensein von Kopien – Mikroformen,
Digitalisaten, Videokopien von Filmen oder Faksimiles von Papierdokumenten – kann
im Element <altformavail> angegeben werden. Informationen zu den Kopien
umfassen z. B. das Format, ihren Umfang, ihre Kennnummer oder ihren Kode, ihren
Lagerungsort und die Stelle bzw. das Verfahren zum Anfordern von Kopien. Wurden
nur Teile der Materialien vervielfältigt, kann <altformavail> auf Komponentenebene
(Component <c>) verwendet werden und sollte eine kurze Aussage darüber
enthalten, welche Teile die Kopie enthält. Existieren Kopien in mehr als einem
Format, z. B. Mikroformkopien und auch elektronische Kopien, können für jedes
78
Format gesonderte <altformavail>-Elemente verwendet werden, wobei mit dem
Attribut TYPE zwischen ihnen unterschieden wird.
<altformavail type="microfilm">
<p>Die Korrespondenzserie steht auf Mikrofilm über die
Fernleihe zur Verfügung.</p>
</altformavail>
<altformavail>
<p>Der handgeschriebene Originalentwurf von <title
render="italic">Women in Love</title> ist äußerst
empfindlich. Benutzer müssen eine Fotokopie benutzen, soweit
keine Sonderregelungen getroffen worden sind.</p>
</altformavail>
3.5.1.4.4. Zitierweise von Materialien <prefercite> (Preferred Citation)
Archive empfehlen häufig Standardangaben zum Zitieren ihrer Bestände. Diese
können im Element <prefercite> genannt werden. Der Text kann ein Beispiel einer
allgemeinen Zitierweise für das Archiv enthalten, oder das Beispiel bezieht sich
spezifisch auf die erfassten Materialien. Wenn es unterschiedliche Zitierweisen für
verschiedene Originaldaten oder Publikationsarten gibt, sind Beispiele aller
Zitierweisen für einen Bestand anzuführen. Eine andere Möglichkeit besteht darin,
ein Zeigerelement aufzunehmen, um eine Entitätsdatei aufzurufen, in der die
empfohlene Zitierweise des Archivs aufgeführt ist (Entitäten sind in Abschnitt 6.5
behandelt).
<prefercite>
<p>[Signatur der Einheit]. California Gold Rush Mining Towns,
BANC PIC 1987.021 -- PIC, The Bancroft Library, University of
California, Berkeley.</p>
</prefercite>
3.5.1.4.5. Zusätzliche Zugänge <accruals> (Accruals), Bewertung und
Bearbeitung <appraisal> (Appraisals)
Die für Behörden und Körperschaften zuständigen Archive erhalten oft Neuzugänge
zu Gruppen oder Serien von Unterlagen. Handschriftenarchive erhalten ebenfalls
bisweilen persönliche Unterlagen in mehreren Teilabgaben, insbesondere dann,
wenn noch zu Lebzeiten des Gebers mit den Abgaben begonnen wurde. Ein Archiv
möchte vielleicht darauf hinweisen, dass weitere Ergänzungen zu einem Bestand zu
erwarten sind. Das Element Accruals <accruals> enthält Informationen über zu
erwartende Neuzugänge der zu beschreibenden Materialien mit Datum, Häufigkeit
oder Umfang bzw. der Angabe, dass keine weiteren Zugänge erwartet werden. Diese
Angaben können für Benutzer hilfreich sein, können aber auch vom Archiv selbst als
Nachweis- und Planungsinstrument für Neuzugänge verwendet werden.
<accruals>
<p>Ergänzungen zu den Unterlagen des Department of Game and
Fish sind jährlich zu erwarten. </p>
</accruals>
Archive dokumentiert in Findbüchern u. U. Bewertungsentscheidungen. Das Element
Appraisal <appraisal> enthält Angaben zur Bewertung und damit zur weiteren
Bearbeitung der Unterlagen. Es kann zur Beschreibung von ursprünglichen
79
Bewertungen sowie Neubewertungen dienen, die zu bedeutenden Teilkassationen
bzw. zur Aussonderung von Materialien führten. Es empfielt sich,
Bewertungsentscheidungen dann zu dokumentieren, wenn Benutzer Anhaltspunkte
dafür haben könnten, bestimmte Materialien in dem betreffenden Archiv zu finden,
entweder weil sie diese vor deren Übernahme kannten oder weil sie vor einer
Neubewertung bereits in einem Findbuch beschrieben waren. Ggf. können in den
Elementen Separiertes Material <separatedmaterial> (Separated Materials), Ordnung
<organization> (Organization) bzw. Gliederung <arrangement> (Arrangement) in
anderen Teilen des Findbuchs zusätzliche Informationen über Nachkassationen und
sich dadurch ergebende Änderungen in der Ordnung und Gliederung der Materialien
bereitgestellt werden.
<appraisal>
<head>Bewertung:</head>
<p>Die Patientenakten psychiatrisch-psychologischer
Einrichtungen sind ein wichtiges Instrument zur
Dokumentation bedeutender Entwicklungen in den
psychiatrisch-psychologischen Gesundheitsdiensten New Yorks,
insbesondere von Therapien und Behandlungen,
Forschungsarbeiten über Art und Ursache von psychischen
Krankheiten, Entwicklung von Diagnosekriterien und
Erfahrungen von Patienten dieser Einrichtungen und deren
Angehörigen.</p>
<p>Das Staatsarchiv wird die Akten von allen Patienten vor
1920 übernehmen. Hinsichtlich der Patientenakten nach 1920
wird es repräsentative, vollständige Beispiele von folgenden
Einrichtungen erhalten: Binghamton, Pilgrim, Central Islip,
Kings Park, Buffalo, Middletown, St. Lawrence, Mohawk Valley
und Manhattan Psychiatric Center. Das Office of Mental
Health wird Patientenakten von Pilgrim, Central Islip, Kings
Park und Mohawk Valley auf Mikrofilm kopieren und dem
Staatsarchiv Mikrofilm-Originalkopien zusenden. In den
Beispielen sind spezifische Patientengruppen und
Behandlungen enthalten, wie es in dem genauen
Bewertungsbericht festgelegt wurde. Auch ein geografische
Abdeckung wurde gewährleistet. Die Auswahl ist notwendig, da
über 3115 m³ Patientenakten vorhanden sind, die weder auf
Mikrofilm kopiert noch weiter in Papierform aufbewahrt
werden können. Aufnahme- und Entlassungsbücher für alle
Patienten werden vom Staatsarchiv aufbewahrt, um
sicherzustellen, dass Kerninformationen zu allen Patienten
aller Einrichtungen erhalten bleiben.</p>
</appraisal>
3.5.1.4.6. Bearbeitungsinformationen <processinfo> (Processing Information)
Archivische Findbücher enthalten für den beschriebenen Bestand oft den Namen des
Bearbeiters und das Bearbeitungsdatum.61 Archivare können sich auch dafür
entscheiden, routinemäßige Bearbeitungsvorgänge über diese elementaren
Informationen hinaus zu dokumentieren. Das Element <processinfo> kann auch zur
Kodierung verschiedener Informationen dienen, die die Übernahme, Erschließung,
Bestandserhaltung oder sonstige Maßnahmen zur Aufbereitung der Materialien für
Recherchezwecke betreffen.
61
Wenn der Bearbeiter auch der Ersteller des Findbuchs ist, ist zu überlegen, ob der Name dieser Person im Element
<filedesc> des <eadheader> wiederholt werden sollte (siehe Abschnitt 3.6.1.2).
80
<processinfo>
<head>Bearbeitungsinformationen</head>
<p>Diese Unterlagen wurden zuerst 1977 von Lydia Lucas
geordnet und bearbeitet. 1993 überarbeite Michael Fox
Anordnung der Unterlagen, bevor sie auf Mikrofilm kopiert
wurden.</p>
</processinfo>
Bei elektronische Unterlagen eignet sich u. U. das Element <processinfo> am besten
zur Beschreibung von Dateiumwandlungen, Datenmigrationen und anderen
Bestandserhaltungs- und Konservierungsmaßnahmen. Allerdings eignet sich das
Element nur zur Erfassung von Angaben zu den Konversionsformate, die für die
Benutzung anstelle der Originale angeboten werden (derartige Formate werden in
<altformavail> kodiert; siehe Abschnitt 3.5.1.4.3).
<processinfo>
<head>Bearbeitungsinformationen</head>
<p>Duderstadt erstellte viele seiner Reden und andere
Dokumente mit Hilfe von MORE 3.0, einem Konturierungs/Textverarbeitungsprogramm für Apple-Rechner, das nicht mehr
im Handel erhältlich ist und auch nicht mehr unterstützt
wird. Bei der Bearbeitung des Bestandes wurden die MOREDateien in WordPerfect-Dateien umgewandelt.</p>
</processinfo>
3.5.1.5. Entstehungsgeschichte <bioghist> (Biographical Sketches and Agency
Histories)
Häufig finden sich in Findbüchern skizzenhafte Kontextinformationen über die
Entstehung oder Zusammenstellung eines Archivgutkomplexes – in Form einer
Kurzbiografie oder Behördengeschichte –, die Hintergrundinformationen über die
Einzelperson, Familie oder Organisation liefern, die die Materialien erstellt bzw.
gesammelt hat. Die Informationen können als narrativer Text und/oder in einer
chronologischen Auflistung vorliegen, die Datumsangaben zusammen mit einem
oder mehreren Ereignissen tabellarisch darstellt. In EAD werden solche
Kontextinformationen im Element <bioghist> kodiert.
Es gibt mehrere Kodierungsmöglichkeiten. Soll die Kurzbiografie in narrativer Form
erstellt werden, könnte das optionale Element <head>, gefolgt von mehreren
Absätzen <p>, verwendet werden. Innerhalb von <p> können die Zugriffsbegriffe
<persname>, <famname>, <corpname>, und <occupation> sowie Datumsangaben
kodiert werden. Eine solche detaillierte Inhaltskodierung könnte von Nutzen sein,
wenn sie Einstiege, z. B. den Name der Vorgängerbehörde, die in anderen Teilen
des Findbuchs oder in <controlaccess> nicht zusammengestellt sind (siehe Abschnitt
3.5.3). Es darf jedoch nicht vergessen werden, dass es ratsam ist, nur die Textteile
auszuzeichnen, die sich auf Informationen in dem Bestand selbst beziehen, so dass
Benutzer keine irrelevanten Rechercheergebnisse erhalten.
81
<bioghist>
<head>Geschichte der Organisation</head>
<p><title render="italic">The Quest</title> wurde im Herbst
1965 von <persname>Alexis Levitin</persname> gegründet. Zur
Redaktion und zum Redaktionsausschuss gehörten ursprünglich
Studenten, die – wie Levitin – an der <corpname>Columbia
University</corpname> studierten. Levitin schuf ein
literarisches Magazin, das einen zu eng definierten
Schwerpunkt zu vermeiden versuchte und Schriftsteller vieler
verschiedener Richtungen zu guten schriftstellerischen
Leistungen anregen wollte.<blockquote><p>"Wir erwarten
(lesen Sie den Eintrag zum Magazin im<title
render="italic">Directory of Little Magazines</title>) vom
Künstler nicht nur eine gut gestaltete Struktur, sondern
innerhalb dieser auch kreative und aussagekräftige Gedanken
zu den wesentlichen Wahrheiten unserer
Existenz."</p></blockquote></p>
<p>Nachdem Levitin 1968 New York verließ, um in Dartmouth zu
lehren, wurde der größte Teil der redaktionellen Arbeit am
Magazin von <persname>David Hartwell</persname> und
<persname>Tom Beeler</persname> weitergeführt, die
schließlich Ende 1969 das Magazin Levitin abkauften.
Hartwell und Beeler hatten den Namen <title
render="italic">Quest</title> nie gemocht und benannten es
um in <title render="italic">The Little Magazine</title>.
Unter diesem Titel erschien es im Frühjahr 1970 zum ersten
Mal.</p>
<p>Nach Beelers Weggang im Jahr 1971 ruhte die finanzielle
Last für das weitere Erscheinen des Magazins auf David
Hartwell, der mit einem ständig wechselnden Redaktionsteam
und den Mitgliedern des Redaktionsausschusses
weiterarbeitete.</p>
</p>Während seiner gesamten Erscheinungsdauer von 21 Jahren
veröffentlichte <title render="italic">The Quest</title>
bzw. <title render="italic">The Little Magazine</title> neue
Dichtung und Kurzbelletristik, vor allem von jungen
amerikanischen Schriftstellern. Die Auflage lag nie über
1000 Exemplaren. Selbst bei landesweitem Vertrieb durch
</persname> Bernhard DeBoer</persname> aufgrund der rasch
ansteigenden Produktionskosten erschien die Zeitschrift Ende
der 1970er Jahre immer unregelmäßiger. Ende des Jahrzehnts
war Hartwell stark in der Herausgabe von Science Fiction
engagiert, konnte jedoch die Zeitschrift mit Hilfe des aus
Freiwilligen bestehenden Redaktionsausschusses fortsetzen.
Schließlich kam das Ende, und mit der Herausgabe von Bd. 15,
Nr. 3-4 im Jahr 1987 stellte <title render="italic">The
Little Magazine</title> sein Erscheinen ein.</p>
</bioghist>
Sollen die Kontextinformationen statt dessen als strukturierte Chronologie dargestellt
werden, steht hierfür das Element Chronologische Liste <chronlist> (Chronology List)
innerhalb von <bioghist> zur Verfügung. Das Element <chronlist> enthält das
Hüllenelement Chronologischer Eintrag <chronitem> (Chronology Item), in dem ein
Datum mit einem oder mehreren Ereignissen gebündelt wird:
82
<bioghist>
<head>Bemerkungen zur Biographie</head>
<chronlist>
<chronitem>
<date>1919, 14. Dez.</date>
<event>Geboren<geogname>San Francisco,
Calif.</geogname>(Aufgrund von Zweifeln an
der Verlässlichkeit dieser Angabe wird
Jacksons Geburtsjahr von einigen Stellen
auch als 1916 angegeben.)</event>
</chronitem>
<chronitem>
<date>1940</date>
<eventgrp>
<event>A.B.,<corpname>Syracuse
University</corpname>,<geogname>Syracus
e, N.Y.</geogname></event>
<event>Heirat <persname>Stanley Edgar
Hyman</persname></event>
</eventgrp>
</chronitem>
</chronlist>
</bioghist>
Das Element <bioghist> ist rekursiv (d. h., es kann in sich selbst verschachtelt sein).
Wie bereits erwähnt, ermöglicht die Rekursivität das Bündeln der Teile einer
logischen Komponente des Findbuchs und gleichzeitig eine gesonderte
Identifizierung von Subkomponenten. Beispielsweise enthält das Findbuch zu allen
Unterlagen des Verlags Alfred A. Knopf Inc. drei Abschnitte mit
Kontextinformationen.62 Sowohl Alfred als auch Blanche Knopf engagierten sich stark
in der Leitung des Verlags, und die Unterlagen enthalten viele persönliche Briefe und
Informationen über ihre sonstigen Interessen und Reisen. Daher ist es sinnvoll, dass
das Findbuch die Verlagsgeschichte selbst sowie gesonderte Kurzbiografien von
Alfred und Blanche Knopf enthält. Die Auszeichnung könnte wie folgt aussehen:
<bioghist>
<bioghist encodinganalog="545">
<head>Verlagsgeschichte</head>
<p>Der Verlag Alfred A. Knopf Inc. wurde 1915
gegründet...</p>
</bioghist>
<bioghist encodinganalog="545">
<head>Kurzbiografie von Alfred Knopf</head>
<p><persname encodinganalog="700" source="lcnaf"
normal="Knopf, Alfred A., 1892-1984">Alfred Knopf
</persname>....</p>
</bioghist>
<bioghist encodinganalog="545">
<head>Kurzbiografie von Blanche Knopf</head>
<p><persname encodinganalog="700" source="lcnaf"
normal="Knopf, Blanche W., 1894-1966"> Blanche Knopf
</persname>....</p>
</bioghist>
</bioghist>
62
Dieser Bestand befindet sich im Harry Ransom Humanities Research Center an der University of Texas, Austin.
83
Diese Auszeichnung ermöglicht die Verwendung mehrerer <head>-Elemente für die
Formatierung (<head> ist innerhalb eines einzelnen Elements nicht wiederholbar)
sowie eine Extraktion der drei Abschnitte für einzelne MARC-545-Felder zu
biografischen oder historischen Daten und weitere Einträge zu Alfred und Blanche
Knopf, wenn dies gewünscht wird. Zu Attributen von Namenselementen siehe auch
Abschnitt 3.5.3.1.
3.5.1.6. Gegenstände <scopecontent> (Scope and Content Notes)
Findbücher enthalten oft einen Abschnitt, in dem Themenbereiche und Inhalt der
erfassten Materialien zusammengefasst sind. Dabei werden Form und Ordnung der
Materialien sowie darin vorkommende bedeutende Personen, Organisationen,
Ereignisse, Orte und Themen genannt. Im Allgemeinen werden solche Abschnitte als
„Scope and Content Notes“ bezeichnet. In EAD sind sie in <scopecontent> kodiert. In
diesem Element lassen sich <organization> (die Art der Aufteilung der Materialien in
kleinere Einheiten, z. B. Serien) und <arrangement> (Reihenfolge der Ablage der
Materialien, z. B. alphabetisch, chronologisch oder numerisch) gesondert kodieren.
Die Elemente <organization> und <arrangement> stehen nicht nur in
<scopecontent> zur Verfügung, sondern auch innerhalb von <archdesc>, um
Findbücher erstellen zu können, in denen diese Informationen an anderer Stelle
erscheinen soll. Wie bei <bioghist> und anderen Elementen auf <did>-Ebene, ist es
auch möglich, verschiedene Zugriffspunkte in <scopecontent> zu kodieren, z. B.
<persname>, <subject> und <genreform>.
<scopecontent>
<head>Gegenstände zum Bestand</head>
<scopecontent encodinganalog="520">
<p>Die Unterlagen der Detroit Japanese American
Citizens League <abbr>(JACL)</abbr> dokumentieren vor
allem gesellschaftliche Aktivitäten dieser ethnischen
Gruppe in Detroit. Einige Akten betreffen die
andauernden Auswirkungen der Umsiedlung amerikanischer
Bürger mit japanischer Abstammung während des 2.
Weltkriegs.</p>
<organization><p>Die Unterlagen bestehen aus drei
Serien: Sachakten, Fotografien und
Sammelalben.</p></organization>
</scopecontent>
<p>Die Serie Sachakten umfasst Schriften von 1947 bis 1995,
die Sitzungsprotokolle der Ortsgruppe in Detroit enthält und
Bankette, Vorbereitungen für verschiedene Zusammenkünfte und
Beziehungen zur nationalen JACL-Organisation dokumentiert.
Diese Serie enthält auch Exemplare des Rundschreibens der
Ortsgruppe sowie des Blattes <title render="italic">The
Beacon</title>, einer monatlich in Detroit erscheinenden
Zeitschrift über die Beziehungen von Nisei zu in den USA
geborenen Amerikanern. Die unter Verschiedenes
zusammengestellten Ordner enthalten zumeist Briefe sowie
andere Unterlagen der JACL aus Detroit, die u. U. unter
Minutes and Treasurer's Reports nochmals vorhanden sind.
Peter Fujiokas Briefe sind ebenfalls verfügbar und unter
seinem Namen abgelegt.</p>
84
<p>Fotografien von Banketten, Picknicks, Konferenzen,
Kinderfesten und anderen Aktivitäten sind in der Serie
Fotografien abgelegt. Personen auf diesen Fotos sind zumeist
nicht bezeichnet. Die Fotos sind jedoch im Allgemeinen
beschriftet und nach Ereignissen geordnet. In Ordnern
gelagerte Fotos sind auf Kennzeichnungen auf der Rückseite
zu prüfen. Einige Aufnahmen wurden den Sammelalben
entnommen, um in der Ausstellung <title render="quoted">From
Manzanar to Motor City. A History of Michigan's Japanese
American Community</title> zu erscheinen. Sie sind mit einer
Nummer versehen, auf der das Album vermerkt ist, aus dem das
Bild stammt.</p>
<p>Die Serie Sammelalben zeigt am deutlichsten die
Aktivitäten der Detroiter JACL-Ortsgruppe. Die meisten Alben
enthalten Informationen zu allen Aktivitäten der Ortsgruppe,
während andere sich auf Jugendgruppen und den Golfklub
konzentrieren. Jedes Album enthält Fotos und Dokumente zu
Ereignissen und Veröffentlichungen und wurde soweit möglich
nicht verändert. Materialien, die separiert worden sind,
wurden in Ordnern gelagert. Einige in den Sammelalben
enthaltene Materialien finden sich auch in der Serie
Sachakten.</p>
</scopecontent>
Wie <bioghist> ist auch <scopecontent> rekursiv, was die Verwendung mehrerer
<head>-Elemente erleichtert und – über das Attribut ENCODINGANALOG – das
Extrahieren eines zusammenfassenden Absatzes aus einer längeren Scope and
Content Note ermöglicht, die für das Feld 520 einer MARC-Titelaufnahme verwendet
werden kann.
3.5.1.7. Allgemeine Text-, Formatierungs- und Verknüpfungselemente
Die meisten EAD-Elemente dienen der Auszeichnung struktureller Bestandteile eines
Findbuchs. Für die zusammenhängende Formatierung eines Dokuments sind jedoch
auch einige allgemeine Text-, Formatierungs- und Verknüpfungselemente
erforderlich. Dazu gehören <head>, <p>, <blockquote>, <emph>, <list> und
verschiedene andere Elemente. Subelemente innerhalb von <p> bieten weitere
Möglichkeiten zur Formatierung, Verknüpfung und Kontrolle des Vokabulars. Im
vorliegenden Abschnitt werden nicht alle genannten Elemente behandelt. Sie sollten
jedoch wissen, dass sie zur Verfügung stehen, und sich über ihre richtige
Verwendung in der EAD-Tag-Library unterrichten. Verknüpfungselemente und
Elemente zur Tabellendarstellung sind im Einzelnen in Kapitel 7 bzw. Abschnitt
4.3.5.4 beschrieben.
Im Anwenderleitfaden wird hervorgehoben, dass es erwünscht ist, einige
Formatierungselemente bei der Auszeichnung wegzulassen und die OnlineDarstellung dem Stylesheet zu überlassen. (Weiteres zu Stylesheets siehe Abschnitt
5.3.3). Eine gute Faustregel besagt, dass dieses Vorgehen am besten ist, wenn der
Inhalt eines Elements in allen Findbüchern (oder in allen Findbüchern einer
bestimmten Art) konsequent auf bestimmte Weise (z. B. in Kursivdruck) dargestellt
werden soll. Soll andererseits ein einzelnes Wort in einem Absatz besonders
behandelt (z. B. in Kursivdruck gesetzt) werden, ist das geeignete
Formatierungselement (bei Kursivdruck <emph>) zu verwenden.
85
Die meisten EAD-Subelemente für Text und Formatierung sind optional. Ein
gewisses Maß an allgemeiner Textauszeichnung ist jedoch erforderlich. Ein Grund
dafür ist, dass die SGML-Syntax darauf ausgelegt ist, jedes Element so zu
definieren, dass es entweder andere Elemente oder Text enthält, aber nicht Beides.
Deshalb muss <p> geöffnet werden, damit Text in <scopecontent> eingegeben
werden kann, da <scopecontent> nicht unmittelbar Text enthalten kann (Text wird in
SGML als „parsed character data“ oder PCDATA bezeichnet).
3.5.1.7.1. Kopfzeile/Überschrift <head> (Heading)
Kopfzeilen/Überschriften werden in Findbüchern oft dazu verwendet, Textblöcke zu
bezeichnen. Das Element <head> ist für alle Elemente auf <did>-Ebene verfügbar, z.
B. <admininfo> und <scopecontent> sowie für alle <c> Komponenten und viele
andere Elemente, bei denen eine Überschrift sinnvoll ist. Wird <head> verwendet,
muss es als erstes Subelement vor <p> oder einem anderen Subelement
erscheinen. Die Darstellung von Überschriften lässt sich leicht mit einem Stylesheet
steuern. Das vorliegende Kapitel enthält zahlreiche Beispiele für die Verwendung von
<head>, beispielsweise in den Abschnitten 3.5.1.5 und 3.5.3.7.
Unter bestimmten Umständen ist es nicht ratsam, <head> für kopfzeilenähnliche
Informationen zu verwenden. Wie in Abschnitt 3.5.1.1 erläutert, verwenden <did>Subelemente ein LABEL-Attribut anstelle von <head>. <head> darf auch keinesfalls
verwendet werden, wenn ein genaueres EAD-Strukturelement wie <unittitle> besser
geeignet ist, wie in Unterabschnitt 3.5.2.3.1.1 beschrieben.
3.5.1.7.2. Abschnitt <p> (Paragraph)
Das Element Abschnitt <p> wird verwendet, um das zu bezeichnen, was wir als
einfachen Absatz verstehen – ein oder mehrere Sätze, die eine logische
Textpassage bilden. Ein Absatz kann eine Unterteilung eines längeren Textes sein
oder allein stehen. Normalerweise ist er am Schriftbild erkennbar: oft erscheint vor
und nach ihm eine Leerzeile, der Text beginnt auf einer neuen Zeile, und der erste
Buchstabe des ersten Wortes ist häufig eingerückt und/oder durch Großbuchstaben
hervorgehoben.
Das Element <p> ist ein wichtiges, häufig verwendetes Element. Innerhalb von mehr
als 30 EAD-Elementen steht es zur Verfügung und ist oft auch vorgeschrieben.
Anders als die meisten Elemente kann es sowohl Text als auch andere Elemente
enthalten. Mehr als 30 Subelemente sind in <p> verfügbar, einschließlich aller derer,
die in <controlaccess> (in Abschnitt 3.5.3 beschrieben) verfügbar sind. Ein Vorteil der
Verfügbarkeit dieser Elemente innerhalb von <p> besteht darin, dass Namen,
Objekte sowie Genre- und Formbegriffe sowohl in der Originalsprache als auch in
ihrer ansetzungskontrollierten Formen kodiert werden und zum Recherchieren und
Auffinden bereitgestellt werden können. Das Letztgenannte ist mit Hilfe des Attributs
NORMAL möglich.
<p><persname source="lcnaf" normal="Knopf, Alfred A.,
1892-1984">Knopf</persname> begann 1908 sein Studium am <corpname
source="lcnaf" normal="Columbia College (Columbia University)">
Columbia College</corpname>, wo er Interesse für Geschichte
und Literatur entwickelte.</p>
86
In <p> sind auch mehrere allgemeine textbezogene Subelemente verfügbar, z. B.
Abkürzung <abbr> (Abbreviation ), Hervorhebung <emph> (Emphasis), Erweiterung
<expan> (Expansion), Zeilenumbruch <lb> (Line Break ), Liste <list> (List) und
Tabelle <table> (Table ). Bisweilen ist es besser, die Darstellung solcher
Formatierungen durch das Stylesheet vornehmen zu lassen. In anderen Fällen ist es
zweckmäßiger, sie in die Auszeichnung zu integrieren. Einige dieser Elemente
können auch die Recherche erleichtern. Wird im folgenden Satz z. B. <abbr>
verwendet, lässt sich die Auffindbarkeit von Bezugnahmen auf ISAD(G) erhöhen.
<p>In der General International Standard Archival Description
<abbr>ISAD(G)</abbr> ...</p>
In <p> gibt es auch eine Anzahl von Zitier- und Verknüpfungselementen, darunter
Archivischer Nachweis <archref> (Archival Reference), Bibliographischer Nachweis
<bibref> (Bibliographic Reference), Erweiterter Zeiger <extptr> (Extended Pointer),
Nachweis <ref> (Reference ), and Titel <title> (Title) (die Verknüpfungselemente sind
in Kapitel 7 beschrieben). Die Verwendung von <title> in <p> ist insbesondere für
Darstellungs- und Recherchezwecke von Nutzen. Es ist beispielsweise nicht möglich,
die Darstellung jedes Titels (<title>) individuell innerhalb von <p> von einem
Stylesheet steuern zu lassen, da dieses nicht zwischen dem Titel eines
Zeitschriftenartikels, der in Anführungszeichen zu setzen ist, und dem Titel eines
Romans, der in Kursivdruck dargestellt werden sollte, unterscheiden kann,
unterscheiden kann. Zur Steuerung der Darstellung wäre das Attribut RENDER
erforderlich:
<title render="italic">Alice in Wonderland</title>
Es ist zu beachten, dass, innerhalb eines Elementes, sofern kein anderes
strukturelles Subelement verwendet wird, oft <p> oft vorgeschrieben ist, damit Text
eingegeben werden kann. Beispielsweise sind beide nachstehenden Beispiele gültig.
Das zweite ist in seiner Auszeichnung jedoch genauer, da das Subelement
<acqinfo> eingefügt wurde:
<admininfo>
<p>Die Unterlagengruppe wurde von der Detroit Japanese
American Citizens League im Februar 1998 übergeben.
Kennzeichen der abgebenden Stelle ist 8691</p>
</admininfo>
<admininfo>
<acqinfo>
<p>Die Unterlagengruppe wurde von der Detroit Japanese
American Citizens League im Februar 1998 übergeben.
Kennzeichen der abgebenden Stelle ist 8691</p>
</acqinfo>
</admininfo>
87
3.5.1.7.3. Bemerkung <note> (Note)
Wie in Abschnitt 3.5.1.2.6 erwähnt, ist <note> an vielen Stellen, wo <did> es nicht ist,
verfügbar, und zwar wegen seiner Eignung als Texterläuterung. Das Element <note>
kann innerhalb sämtlicher <did>-Elemente (<admininfo>, <bioghist>,
<scopecontent>, <c>, Beschreibende Zusatzdaten <add> (Adjunct Descriptive Data )
und Sonstige Erschließungsangaben <odd> (Other Descriptive Data) sowie innerhalb
der <admininfo>-Subelemente, der allgemeinen Textelemente und der
Verknüpfungselemente verwendet werden. Falls es für Druckfindbücher gewünscht
wird, können <note>-Elemente als Fußnoten am unteren Seitenrand angeordnet
werden. In einer Online-Umgebung können sie entweder am Ende eines Dokuments
zusammengestellt oder in den Text eingebettet werden. Die Attribute ACTUATE und
SHOW können zur Unterdrückung der Online-Darstellung von <note>-Elementen
verwendet werden, bis diese von Findbuchnutzern aufgerufen werden. Einzelheiten
zur Verwendung dieser Attribute sind in Abschnitt 7.4.1 beschrieben.
3.5.1.7.4. Digitales Archivobjekt <dao> (Digital Archival Object)
Die Online-Umgebung erleichtert das Einbinden von digitalisiertem Archivgut, das in
ein Findbuch eingebettet oder mit ihm verknüpft wird. EAD stellt viele
Verknüpfungselemente bereit, die Elemente <dao> und <daogrp> sind jedoch für
digitale Bilder zu dem im Findbuch beschriebenen Bestand bestimmt. Diese
Digitalisate sind möglicherweise Bilder, Audio- oder Videoclips, Bilder von Textseiten
oder elektronische Transkriptionen von Text. Die Elemente <dao> und <daogrp> sind
– wie in Unterabschnitt 3.5.1.2.9 erwähnt – in <did> verfügbar, jedoch auch in einer
Anzahl anderer EAD-Elemente, darunter <bioghist>, <scopecontent> und <c>. In
eine Kurzbiografie könnten z. B. Fotos des Nachlassgebers oder andere Bilder von
Objekten sein, die sich auf ein Ereignis oder eine Handlung aus dem Leben des
Nachlassgebers beziehen. Thumbnails oder Clips von Materialien aus dem Bestand
könnten in einer „Scope and Content Note“ oder innerhalb von Komponenten verlinkt
oder direkt in sie eingebettet werden. Diese könnten den Inhalt ganzer Akten
darstellen, ausgewählte und oft verwendete Objekte oder Objekte sein, die
empfindlich sind und nicht im Original verwendet werden dürfen. Hinweise zur
Verwendung von <dao> und <daogrp> sind in Abschnitt 7.3.6 enthalten.
3.5.2. Erschließung der „Teile”: Geschachtelte Komponenten
Wenn Archivare allgemein das „Ganze“ eines Unterlagenkomplexes beschrieben
haben, verlagert sich der Tätigkeitsschwerpunkt meist auf die Verzeichnung eines
oder mehrerer Teile des Bestandes (siehe die Erläuterungen zur mehrstufigen
Verzeichnung in Abschnitt 3.4). In EAD werden diese Teile als Komponenten <c>
(Components) bezeichnet. Im Folgenden erörtern wir die Eigenschaften von
Komponenten und behandeln z. B. folgende Fragen:
•
•
•
•
Was genau ist eine Komponente?
Wo muss eine Komponentenbeschreibung beginnen und wo muss sie enden?
Was ist der Unterschied zwischen nummerierten und nicht nummerierten
EAD-Komponenten?
Können die gleichen aussagekräftigen Inhalt-Tags, mit denen ein Bestand als
Ganzes verzeichnet habe, zur Verzeichnung der Komponenten verwendet
werden?
88
•
•
Wie nimmt man Informationen über die Aufteilung von Materialien in
bestimmte Kisten und Ordner in die Findbücher auf?
Wie kann man Komponentenangaben gruppieren, um sie als Serienerfassung
oder Komponentenliste zu verwenden?
Archivare, denen der Aufbau hierarchischer Findbücher geläufig ist, und
insbesondere solche, die mit ISAD(G) und RAD vertraut sind, kennen die Antworten
auf diese Fragen. Wie bei ISAD(G) erben die Komponenten in EAD die Informationen
von den Verzeichnungsangaben des Ganzen und auch von denen höher stehender
Komponenten. Auf jeder Stufe können die gleichen grundlegenden Datenelemente
verwendet werden.
3.5.2.1. Was ist eine Komponente (Component <c>)?
Eine Komponente kann eine leicht zu erkennende Verzeichnungseinheit sein, z. B.
eine Serie, Teilserie oder Akte63, ein Einzelstück oder, wie die nachstehenden
Beispiele zeigen, eine beliebige Ebene oder Stufe in der Erschließungshierarchie.
Komponenten sind nicht innerhalb des Elements <archdesc> geschachtelt, sondern
normalerweise auch ineinander. Archivare einigen sich z. B. darauf, dass Serien
Teile oder Komponenten von Sammlungen, Beständen oder Unterlagengruppen
sind. In ähnlicher Weise gehören Teilserien nicht nur zu ihrer Elternserie, sondern
auch zu ihrer „Großelternserie”. Die Teilserien wiederum setzen sich aus Archivalien
zusammen, die sich ihrerseits wieder aus Archivalien oder Einzelstücken
zusammensetzen. Die Verzeichnung jeder einzelnen Komponente erbt die
Verzeichnungsangaben ihrer Eltern, Großeltern, Urgroßeltern usw.. Auch von Akten
innerhalb der Hierarchie, die eine intellektuelle Gruppierung ohne eine bestimmte
archivfachliche Bezeichnung darstellen, werden Angaben zu Erschließungsebenen
oder -komponeten vererbt werden.
Zum Beispiel können beim Gliedern persönlicher Unterlagen eines
Romanschriftstellers können mehrere Unterlagengruppen oder -serien identifiziert
werden. Eine davon wird als Literaturserie und die andere als Sammelalben
bezeichnet. In der Literaturserie werden die Materialien nach ihrem Genre
zusammengestellt, so dass alle Unterlagen zu Büchern und Kurzgeschichten sowie
die Artikel des Schriftstellers gruppiert werden. Je nach der Größe und Bedeutung
der Gruppierungen kommen die drei Kategorien („Artikel“, „Bücher“ und
„Kurzgeschichten und andere Schriften“) als Teilserien in Betracht und werden in
dem Findbuch als solche bezeichnet. Diese Teilserien oder Schriftgutarten können
weiter nach Titel, Laufzeit oder einem anderen Ordnungskriterium geordnet werden,
wobei nach Bedarf zusätzliche Zwischenüberschriften zur Vervollständigung der
Klassifizierung eingefügt werden können. Die Detailtiefe der Klassifizierung spiegelt
oft die Menge des Materials in der jeweiligen Kategorie wider. Je mehr Material
vorhanden ist, desto wahrscheinlicher müssen Unterkategorien angelegt werden.
Jede Erschließungskategorie und -unterkategorie ist eine Komponente. In einem
Findbuch sieht diese Schachtelung wie folgt aus:64
63
Der Begriff „Akte“ bezeichnet hier eine Einheit archivischer Materialien, nicht den Inhalt eines konkreten Behälters, so z. B.
eines Ordners.
64
Alle Beispiele in Abschnitt 3.5.2 und den zugehörigen Unterabschnitten stammen (in Bearbeitungen) aus: Ruth, Janice E.:
Encoded Archival Description. A Structural Overview, in: American Archivist 60 (1997) 2, S. 310-329.
89
LITERATURSERIE, 1943-1970, o.D.
Artikel, 1951-1966
Bücher
Raising Demons (1957)
Kritiken, 1956-1957, o.D
Honorarangaben, 1956-1969
The Road Through the Wall (1948), 1947-1970, o.D.
Kurzgeschichten und andere Schriften
"The Lottery"
Dramaturgische Bearbeitungen
Korrespondenz, 1949-1953, 1967-1970
Drehbücher und
Fernsehspiele, o.D.
Royalty statements, 1950-1953, 1964-1970
"Lover's Meeting," o.D.
SAMMELALBEN, 1933-1968
Spiele aus der Kollegezeit, 1933-1937
"The Lottery," 1949-1952
In diesem stark verkürzten und fiktiven Beispiel sind Literaturserie und Sammelalben
Komponenten auf Serienebene in einer Schriftensammlung der Romanschriftstellerin
Shirley Jackson.65 Die Komponente Literaturserie beginnt mit dem Wort
„Literaturserie“ und endet nach dem Eintrag „Lover‘s Meeting“. Man könnte denken,
dass die Komponente auf der ersten Zeile endet, nach der Laufzeitangabe zur
Literaturserie. Das ist jedoch nicht der Fall. Die Verzeichungsangaben der
Komponente auf Serienebene umfasst die Angaben aller ihrer Teilkomponenten und
nicht nur Titel und Laufzeit der Serie. Die Komponenten-Tags für die Serie sehen so
aus:
<c>LITERATURSERIE, 1943-1970, o.D
Artikel, 1951-1966
Bücher
Raising Demons (1957)
Kritiken, 1956-1957, o.D.
Honorarangaben, 1956-1969
The Road Through the Wall (1948), 1947-1970, o.D.
Kurzgeschichten und andere Schriften
"The Lottery"
Dramaturgische Bearbeitungen
Korrespondenz, 1949-1953, 1967-1970
Drehbücher und Fernsehspiele, o.D.
Honorarangaben, 1950-1953, 1964-1970
"Lover's Meeting," o.D.</c>
<c>SAMMELALBEN, 1933-1968
Spiele aus der Collegezeit, 1933-1937
"The Lottery," 1949-1952</c>
Sowohl Literaturserie als auch Sammelalben enthalten Teilkomponenten, die am
Anfang und am Ende mit <c> bzw. </c> getaggt werden (siehe nächste Darstellung).
In der Literaturserie hat das Archiv drei Teilkategorien gebildet; zwei davon (Bücher
und Kurzgeschichten) sind weiter unterteilt worden.
65
Dieser Bestand wird in der Library of Congress aufbewahrt.
90
Bei der Kodierung einer Teilkomponente ist darauf zu achten, wo ihre Verzeichnung
beginnt und wo sie endet. Bei den Artikeln der Schriftstellerin Jackson hat der
Findbucherstellende entschieden, dass außer einer Laufzeitangabe keine weitere
Angabe zum Akteninhalt erforderlich ist. Folglich beginnt die Komponente vor dem
Wort „Artikel“ und endet nach der Laufzeitangabe „1951-1966“. Für die Bücher und
Kurzgeschichten wurden weitere Verzeichnungsebenen für erforderlich gehalten, um
Benutzer bei der Recherche von Material zu einem bestimmten Werk von Shirley
Jackson zu unterstützen. Daher beginnt die Komponente Bücher genau vor dem
Wort „Bücher“, endet jedoch erst nach den Laufzeitangaben für das Werk „The Road
Through the Wall“. Auf gleiche Weise beginnt die Komponente Kurzgeschichten
genau vor dem Wort und endet nach den Daten für „Lover's Meeting“.
Der Prozess des Kennzeichnens des Anfangs und des Endes der einzelnen
Verzeichnungskomponenten wird in der gesamten Hierarchie in absteigender
Reihenfolge wiederholt, wie nachstehend gezeigt ist. Es ist zu beachten, dass die
Verzeichnungsangaben einer niedrigeren Komponente die Angaben aller ihrer
Vorfahren erbt, so dass Benutzer, die den Komponententitel „Drehbücher und
Fernsehspiele, o.D.“ lesen, die Hierarchie nach oben verfolgen und daraus erkennen
können, dass die Verzeichnungseinheit Drehbücher und Fernsehspiele zu
dramaturgischen Bearbeitungen von „The Lottery“ enthält, einer Kurzgeschichte, die
in der Literaturserie der Schriften von Shirley Jackson steht.
<c>LITERATURSERIE, 1943-1970, o.D.
<c>Artikel, 1951-1966</c>
<c>Bücher
<c>Raising Demons (1957)
<c>Kritiken, 1956-1957, o.D.</c>
<c>Honorarangaben, 1956-1969</c></c>
<c>The Road Through the Wall (1948), 1947-1970,
o.D.</c></c>
<c>Kurzgeschichten und andere Schriften
<c>"The Lottery"
<c> Dramaturgische Bearbeitungen
<c>Korrespondenz, 1949-1953,
1967-1970</c>
<c> Drehbücher und Fernsehspiele,
o.D.</c></c>
<c>Honorarangaben, 1950-1953,
1964-1970</c></c>
<c>"Lover's Meeting," o.D.
</c></c></c>
<c>SAMMELALBEN, 1933-1968
<c> Spiele aus der Collegezeit, 1933-1937</c>
<c>"The Lottery," 1949-1952</c></c>
Es ist zu beachten, dass alle Komponenten unabhängig von ihrer Stellung innerhalb
der Hierarchie mit dem gleichen allgemeinen Elementnamen und Tag kodiert sind.
Zwar bezeichnet jede Komponente einen hierarchisch spezifischen Abschnitt der
beschriebenen Materialen, es wurde jedoch in EAD nicht versucht, verschiedenen
Komponententtypen oder -stufen eindeutige Elementnamen zu geben. Alle werden
einfach als <c> getaggt. Das heißt nicht, dass, wenn es um die Darstellung oder
Recherche eines Findbuchs geht, jedes <c> die gleiche Bedeutung hat oder mehrere
<c> nicht differenziert werden sollen. Eine solche Differenzierung ist mit dem Attribut
LEVEL möglich, das, wie in Abschnitt 3.5.1 erläutert, den Wert „collection“, „fonds“,
„recordgrp“, „series“, „subgrp“, „subseries“, „file“, „item“ bzw. „otherlevel“ (Sammlung,
91
Bestand, Unterlagengruppe, Serie, Untergruppe, Teilserie, Akte, Einzelstück bzw.
sonstige Ebene) hat. Es wird empfohlen, dem höchstrangigen <c> ein Attribut LEVEL
zuzuordnen. Die Tags vor „LITERATURSERIE“ und „SAMMELALBEN“ könnten
demzufolge zu <c level=“series“> erweitert werden. An anderen Stellen kann das
Attribut verwendet werden, wenn das Archiv es zu Recherche-, Darstellungs-,
Navigations- oder sonstigen Zwecken für nützlich hält. Da viele Komponenten
keinem der für LEVEL verfügbaren spezifischen Werte entsprechen, wäre wenig
damit gewonnen, alle als „otherlevel“ zu bezeichnen.
3.5.2.2. Nicht nummerierte bzw. nummerierte Komponenten <c> bzw. <c01>
Die Benutzung des allgemeinen <c> zum Taggen von Komponenten (siehe obiges
Beispiel) ist durchaus gültig, und die meisten Erstellungswerkzeuge für SGMLDateien haben keine Schwierigkeiten, bei der Erstellung des codierten Findbuchs die
geschachtelte Hierarchie zu verfolgen. Für den menschlichen Verstand ist dies
jedoch u. U. problematischer. Beim Taggen oder Korrekturlesen von kodierten
Dokumenten vor deren Veröffentlichung oder Verbreitung kann man sich leicht in
einer Unmenge von <c>-Tags verirren.
Zur Lösung dieses Erstellungs- und Bearbeitungsproblems bietet EAD alternativ ein
Kodierungsschema mit nummerierten Komponenten (<c01>, <c02>, <c03> usw.) an,
das eine Schachtelung von bis zu zwölf Komponentenebenen unterstützt. Oft wird
die erste Serie in einem Bestand zum ersten <c01> in dem EAD-Findbuch. Das erste
<c02> ist nicht die zweite Serie des Bestandes, sondern die nächste hierarchische
Ebene im ersten <c01>.
Es ist von entscheidender Bedeutung, zu erkennen, dass die Nummern keine
intellektuelle Bedeutung haben und ihre Werte nicht absolut sind. Mit anderen
Worten, eine bestimmte nummerierte <c>-Ebene bezieht sich stets auf verschiedene
Ebenen, und zwar sowohl in einem einzelnen Findbuch als auch in sämtlichen
Findbüchern. <c02> kann in einem Teil eines Findbuchs eine Akte sein, anderswo
dagegen eine Teilserie. Wie bei den nicht nummerierten Komponenten werden
inhaltliche Unterschiede zwischen den Komponenten mit Hilfe des Attributs LEVEL
bezeichnet. Im folgenden Beispiel wird der oben dargestellte Abschnitt des
Findbuchs zur Schriftensammlung von Shirley Jackson mit nummerierten
Komponenten gezeigt:
92
<c01 level="series">LITERATURSERIE, 1943-1970, o.D.
<c02>Artikel, 1951-1966</c02>
<c02>Bücher
<c03>Raising Demons (1957)
<c04>Kritiken, 1956-1957, o.D.</c04>
<c04>Honorarangaben, 1956-1969
</c04></c03>
<c03>The Road Through the Wall (1948), 1947-1970,
o.D.</c03></c02>
<c02>Kurzgeschichten und andere Schriften
<c03>"The Lottery"
<c04>Dramaturgische Bearbeitungen
<c05>Korrespondenz, 1949-1953,
1967-1970</c05>
<c05>Drehbücher und Fernsehspiele,
o.D.
</c05></c04>
<c04>Honorarangaben, 1950-1953,
1964-1970</c04></c03>
<c03>"Lover's Meeting," o.D.</c03></c02></c01>
<c01 level="series">SAMMELALBEN, 1933-1968
<c02>Spiele aus der Collegezeit, 1933-1937</c02>
<c02>"The Lottery," 1949-1952</c02></c01>
Nach Ansicht vieler EAD-Anwender sind nummerierte <c> leichter zu verwenden.
Einige ziehen jedoch nicht nummerierte <c> vor, und zwar hauptsächlich deshalb,
weil der Aufwand für das Neutaggen geringer ist, wenn bei der Bearbeitung Fehler
festgestellt werden oder wenn auf einer beliebigen Ebene über der untersten Ebene
eine weitere Erschließungsebene eingefügt werden muss. Andererseits haben EADAnwender festgestellt, dass ihre Suchmaschinen geschachtelte, nicht nummerierte
<c> nicht verarbeiten konnten, was zu Rechercheschwierigkeiten führte.
Aus diesem Grund empfiehlt der Anwenderleitfaden die Verwendung von
nummerierten <c>. Welche Vorgehensweise auch gewählt wird, innerhalb derselben
Verzeichnungsangaben untergeordneter Komponenten <dsc> (Description of
Subordinate Components), einem in Abschnitt 3.5.2.5 beschriebenen Element, kann
nicht zwischen nummerierten und nicht nummerierten <c> abgewechselt werden.
3.5.2.3. Inhalt der Komponenten
Wir haben nun erklärt, was Komponenten sind, und haben festgestellt, wie wertvoll
ihre Nummerierung für das Korrekturlesen und andere Zwecke ist. Als Nächstes
wollen wir beschreiben, wie der Inhalt einzelner Komponenten vollständig kodiert
wird. Wir halten uns dabei an das Verfahren zum Erfassen von Informationen auf
höchster Verzeichnungsebene und konzentrieren uns zunächst auf die Verwendung
des vorgeschriebenen <did>-Elements und seiner Subelemente, um eine
angemessene Kurzbeschreibung jeder Komponente <c> zu gewährleisten. Vieles
von dem, was in Abschnitt 3.5.1.2 über die <did>-Subelemente gesagt wurde, gilt
auch für die Angaben zu den <c>-Komponenten und wird an dieser Stelle nicht
wiederholt. Getaggte Beispiele zeigen, wie alle Elemente verwendet werden, die
unter <archdesc> (siehe Abschnitt 3.5.1) beschrieben worden sind. Zusätzliche
Erläuterungen weisen auf spezifische Attribute und Anwendungsmöglichkeiten hin,
die weiter oben bei der Behandlung von <archdesc> nicht beschrieben wurden.
93
3.5.2.3.1. Kurzbeschreibung der einzelnen Komponenten-<did> (Descriptive
Identification)
Wie bereits erwähnt, werden auf höchster Verzeichnungsebene erfasste
Informationen von den untergeordneten Komponenten geerbt. Bestimmte <did>Subelemente, z. B. <repository> und <origination>, sind daher auf
Komponentenebene selten erforderlich. Dagegen werden andere <did>Subelemente wie <unittitle>, <unitdate>, <physdesc> und <container> innerhalb von
Komponenten häufig dazu genutzt, um Detailangaben zu niedrigeren hierarchischen
Ebenen zu kodieren. Diese Elemente können durch Elemente ergänzt werden, die
keine <did>-Subelemente sind, z. B. <scopecontent>, <arrangement> und
<organization> oder vielleicht sogar <admininfo> und <bioghist>. Eine typische
Verwendung einiger solcher Elemente geht aus dem nachstehenden Beispiel einer
Serienbeschreibung hervor, die einem Findbuch der Minnesota Historical Society
über Unterlagen der Game and Fish Commission des US-Bundesstaats Minnesota
entnommen wurde, zuerst ohne EAD-Kodierung und dann mit Tag-Beispielen:66
Vorstrafenverzeichnis, 1916-1927. 3 Bände.
Jeder Eintrag enthält: Datum des Protokolls, Name und Anschrift
der festgenommenen Person, Tatort, Datum der Festnahme,
Straftat, Name des Richters, Ergebnis der Gerichtsverhandlung,
Geldstrafen und Gerichtskosten, ggf. Dauer der Haft, Name des
Gefängnisdirektors und ggf. Bemerkungen. Zu den Straftaten
gehörten Jagen oder Fischen während der Schonzeit oder in
Gebieten mit Jagd- bzw. Fischereiverbot, Überschreiten der
zugelassenen Jagd-/Fangquoten, Fangen zu kleiner Fische,
verbotene Arten der Fischerei, z. B. Treibnetz- oder
Dynamitfischerei, verbotene Jagdarten wie Jagen bei Nacht mit
Beleuchtung, Jagen von Nutzgeflügel, Fischen oder Jagen ohne
Angel- bzw. Jagdschein und andere mit der Jagd im
Zusammenhang stehende, gegenüber Personen gegangene
Straftaten, z. B. Betrug oder Körperverletzung.
66
Die Beispiele in diesem Abschnitt über Komponenten enthalten nicht unbedingt alle möglichen bzw. erforderlichen Elemente.
Die Beispiele sollen die Verwendung bestimmter Elemente veranschaulichen. Ein vollständiges Taggen wäre dabei störend. Es
ist auch zu beachten, dass Laufzeitangaben unterhalb der Serienebene (<c01>) nicht besonders kodiert sind. Da eine große
Vielfalt von Datumsformaten bei Findbüchern verwendet wird (siehe auch Unterabschnitt 3.5.1.2.4), ist der Nutzen einer
Kodierung von Laufzeitangaben auf Akten- oder Einzelstückebene für Recherchezwecke fraglich. Vollständig getaggte
Beispiele sind in Anhang E enthalten.
94
<c01 level="series">
<did>
<unittitle>Record of Prosecutions, <unitdate>1916-1927.
</unitdate></unittitle>
<physdesc>
<extent>3 Bände.</extent>
</physdesc>
</did>
<scopecontent>
<p> Jeder Eintrag enthält: Datum des Protokolls, Name und
Anschrift der festgenommenen Person, Tatort, Datum der
Festnahme, Straftat, Name des Richters, Ergebnis der
Gerichtsverhandlung, Geldstrafen und Gerichtskosten, ggf.
Dauer der Haft, Name des Gefängnisdirektors und ggf.
Bemerkungen. Zu den Straftaten gehörten Jagen oder Fischen
während der Schonzeit oder in Gebieten mit Jagd- bzw.
Fischereiverbot, Überschreiten der zugelassenen Jagd/Fangquoten, Fangen zu kleiner Fische, verbotene Arten der
Fischerei, z. B. Treibnetz- oder Dynamitfischerei, verbotene
Jagdarten wie Jagen bei Nacht mit Beleuchtung, Jagen von
Nutzgeflügel, Fischen oder Jagen ohne Angel- bzw. Jagdschein
und andere mit der Jagd im Zusammenhang stehende, gegenüber
Personen gegangene Straftaten, z. B. Betrug oder
Körperverletzung.<p>
</scopecontent>
</c01>
Eine Serienkomponente aus einer Handschriftensammlung, z. B. der
Schriftensammlung von Shirley Jackson, würde in ähnlicher Weise kodiert werden.
Das nächste Beispiel veranschaulicht jedoch nicht nur die Ähnlichkeit des
Kodierverfahrens bei amtlichen und persönlichen Unterlagen, sondern auch die sich
entfaltende Hierarchie von EAD, indem gezeigt wird, wie auf die
Erschließungsangaben zu einer Serienkomponente unmittelbar die
Erschließungsangaben ihrer Teilkomponenten folgen kann.
95
LITERATURSERIE, 1943-1970, o.D. (LITERATURSERIE)
Briefe, handgeschriebene Entwürfe, Honorarangaben, Drucksachen,
Notizen, Drehbücher, Recherchematerial, Fernsehspiele und verschiedene
Gegenstände und Anlagen mit Bezug auf Bücher und Kurzgeschichten von
Jackson. Alphabetisch nach Materialart und darin alphabetisch nach Titel
oder Thema geordnet. Erscheinungsjahre von Büchern sind in Klammern
angegeben.
Artikel, 1951-1966
Bücher
Raising Demons (1957)
Kritiken, 1956-1957, o.D.
Honorarangaben, 1956-1969
The Road Through the Wall (1948), 1947-1970, o.D.
Kurzgeschichten und andere Schriften
"The Lottery"
Dramaturgische Bearbeitungen
Briefe, 1949-1953, 1967-1970
Drehbücher und Fernsehspiele, o.D.
Honorarangaben, 1950-1953, 1964-1970
"Lover's Meeting," o.D.
96
<c01 level="series">
<did>
<unittitle>Literaturserie, <unitdate>1943-1970, o.D.
</unitdate></unittitle>
</did>
<scopecontent>
<p>Briefe, handgeschriebene Entwürfe, Honorarangaben,
Drucksachen, Notizen, Drehbücher, Recherchematerial,
Fernsehspiele und verschiedene Gegenstände und Anlagen mit
Bezug auf Bücher und Kurzgeschichten von Jackson.</p>
<arrangement><p>Alphabetisch nach Materialart und darin
alphabetisch nach Titel oder Thema geordnet. Erscheinungsjahre
der Bücher sind in Klammern angegeben. </p></arrangement>
</scopecontent>
<c02><did><unittitle>Artikel, 1951-1966
</unittitle></did></c02>
<c02><did><unittitle>Bücher
</unittitle></did>
<c03><did><unittitle><title render="italic">
Raising Demons </title>(1957)</unittitle></did>
<c04><did><unittitle>Kritiken, 1956-1957,
o.D.</unittitle></did></c04>
<c04><did><unittitle>Honorarangaben,
1956-1969</unittitle></did></c04></c03>
<c03><did><unittitle><title render="italic">The
Road Through the Wall </title>(1948), 1947-1970,
o.D. </unittitle></did></c03></c02>
<c02><did><unittitle>Kurzgeschichten und andere Schriften
</unittitle></did>
<c03><did><unittitle><title
render="quoted">The
Lottery</title></unittitle></did>
<c04><did><unittitle>Dramaturgische
Bearbeitungen </unittitle></did>
<c05><did><unittitle>Briefe,
1949-1953,
1967-1970</unittitle></did></c05>
<c05><did><unittitle>Drehbücher und
Fernsehspiele, o.D.
</unittitle></did></c05></c04>
<c04><did><unittitle>Honorarangaben,
1950-1953, 1964-1970</unittitle>
</did></c04></c03>
<c03><did><unittitle><title render="quoted">
Lover's Meeting, </title>o.D.
</unittitle></did></c03>
</c02>
</c01>
97
3.5.2.3.1.1. Titel der Verzeichnungseinheit <unittitle> (Unit Title) bzw. Laufzeit
<unitdate> (Unit Date)
In den vorstehenden Beispielen ist zu beachten, dass alle Komponenten das
vorgeschriebene <did>-Element sowie <unittitle> enthalten. Dieses ist zwar optional,
seine Verwendung innerhalb jedes <did> wird jedoch empfohlen. Zum gängigen
Erschließungsverfahren gehört auch, dass das <unitdate> für jede Komponente
aufgenommen wird. Wie bereits in Unterabschnitt 3.5.1.2.4 erwähnt, kann <unitdate>
entweder inner- oder außerhalb von <unittitle> stehen. In den USA sind viele
Archivare – insbesondere diejenigen, die mit Hilfe von APPM katalogisieren – der
Ansicht, dass Laufzeitangaben ein Teil des Titels sind, wogegen die
Erschließungsregeln im Großbritannien vorschreiben, dass <unitdate> außerhalb von
<unittitle> stehen muss. Die drei folgenden Beispiele sind im Rahmen von EAD
gültig. Es ist jedoch wichtig, dass jedes Archiv ein Verfahren wählt und dieses dann
auch konsequent anwendet:
<c04>
<did>
<unittitle><unitdate>1950-1961</unitdate></unittitle>
</did>
</c04>
<c04>
<did>
<unitdate>1950-1961</unitdate>
</did>
</c04>
<c04>
<did>
<unittitle>1950-1961</unittitle>
</did>
</c04>
Es ist zu beachten, dass keinesfalls <head> anstelle von <unittitle> verwendet
werden darf. Das Element <head> wird für die Titelbezeichnung eines Textabschnitts
innerhalb des Findbuchs verwendet, z. B. „Contents List“ oder „Scope and Content
Note“. <head> darf nie zur Bezeichnung einer Archivalieneinheit oder Komponente
verwendet werden. Zum Beispiel:
RICHTIGE CODIERUNG:
<c01 level="series"><did><unittitle>I.
Briefe</unittitle></did></c01>
Im obigen Kodierbeispiel wurden die „Briefe” ordnungsgemäß als Titel der ersten
Serie bezeichnet. Die nachstehende Kodierung darf nicht angewendet werden. Sie
erzeugt lediglich eine Überschrift für die erste Komponente, bezeichnet jedoch nicht
den Inhalt der Komponente:
FALSCHE KODIERUNG:
<c01 level="series"><head>I. Briefe</head></c01>
Es ist zu beachten, dass es nicht nötig ist, <head> zum Taggen des gesamten
Textes zu verwenden, der in einem Browser dargestellt werden soll. Mit einem
geeigneten Stylesheet dürfte es möglich sein, sowohl <head> als auch <unittitle> für
98
diesen Zweck zu verwenden. Angaben zur richtigen Verwendung von <head> siehe
Unterabschnitt 3.5.1.7.1.
Allgemein gilt: Um den Inhalt der zu beschreibenden Materialien zu bezeichnen ist
nie ein allgemeines Element zu verwenden, wenn ein spezifisches Element verfügbar
ist.
3.5.2.3.1.2. Physische Beschreibung <physdesc> (Physical Description)
Im hochrangigen <did> werden der Gesamtumfang des Bestandes sowie sonstige
allgemeine Erschließungsangaben zum ganzen Bestand erfasst (siehe
Unterabschnitt 3.5.1.2.5). Für die Komponentenbeschreibung können die Vorteile
folgender vier <physdesc>-Subelemente genutzt werden:
•
•
•
•
Maße <dimensions> (Dimensions),
Umfang <extent> (Extent ),
Genre oder Form <genreform> (Genre/Physical Characteristics),
Physische Erscheinung <physfacet> (Physical Facet).
Einige dieser Elemente können weiter unterteilt sein. In Museen und Archiven, in
denen dreidimensionale Gegenstände aufbewahrt oder Materialien auf
Einzelstückebene beschrieben werden, gelten die <physdesc>-Subelemente
zweifellos als äußerst geeignet für die detaillierte Kodierung auf der Ebene der
Einzelstücke.
Das Subelement <dimensions> kann zur Aufnahme der Größe eines Gegenstands in
einer beliebigen, vom Archivar zu wählenden Maßeinheit dienen. Mit dem Attribut
UNIT kann die Maßeinheit, z. B. Zoll oder Zentimeter mit dem Attribut TYPE die
jeweilige Abmessung, z. B. Höhe oder Umfang, angegeben werden.
<dimensions>80 x 50 cm.</dimensions>
<dimensions>
<dimensions type="height" unit="inches">25</dimensions> x
<dimensions type="width" unit="inches">38.5</dimensions>
</dimensions>
Das Subelement <physfacet> dient zum Kodieren von Informationen zur
Beschaffenheit der Materialien, beispielsweise Farbe, Ausführung, Kennzeichen,
Werkstoffe, Material oder Herstellungsverfahren. <physfacet> wird insbesondere
dazu verwendet, die Beschaffenheitsmerkmale aufzunehmen, von denen die
Benutzbarkeit der Materialien abhängt. Auch hier wird mit dem Attribut TYPE
angegeben, welcher Aspekt der äußeren Beschaffenheit bezeichnet wird. Das
Element <physfacet> hat wie auch die in Abschnitt 3.5.3 beschriebenen Elemente für
den kontrollierten Zugriff ein Attribut SOURCE, das den Thesaurus oder ein
sonstiges kontrolliertes Vokabular bezeichnet, dem der Begriff entnommen wird.
99
<physfacet type="sealdesc">Abgerundetes Oval, ein Eichhörnchen, das
auf einem Baum sitzt, an dessen Fuß ein schlafender Löwe
liegt.</physfacet>
<physfacet type="medium">Papier, an der Rückseite mit Leinen
verstärkt.</physfacet>
<physfacet type="scale">4 Ketten* : 1 Zoll.</physfacet>
Unterabschnitt 3.5.1.2.5 enthält Beispiele, die die Verwendung von <extent> und
<genreform> veranschaulichen. Ein hochgradig detailliertes <physdesc> auf
Einzelstückebene könnte so aussehen:
<physdesc>
<physfacet type="medium">Pergament, mit eingelegten
Papierblättern </physfacet>
<extent>3 Papierblätter; 1 Pergament auf Papierblatt; 175
Blätter, 4 Einlagen, 2 Pläne, Pergament; 4
Papierblätter</extent>
<dimensions>230 x 163 mm.</dimensions>
<physfacet type="binding">Modern, nicht später als
1824.</physfacet>
<physfacet type="foliation">i-iv, 1-20, 20*, 21-37, 37*, 38116, 116*, 117-180 (Foliierung aus dem 15. Jhdt.: 1-84, auf
ff 125-158, 11-60).</physfacet>
</physdesc>
3.5.2.3.1.3. Zusammenfassung <abstract> (Abstract)
In Unterabschnitt 3.5.1.2.6 haben wir festgestellt, dass eine Zusammenfassung
(<abstract>) innerhalb des hochrangigen <did> oft aus längeren
Erschließungsangaben in <bioghist> und <scopecontent> extrahiert worden ist. Ein
<did> auf Komponentenebene enthält als Zusammenfassung z. B. bestimmte
Merkmale der Einzelkomponente. Diese Information beinhaltet im Allgemeinen
Aspekte von <arrangement>, <bioghist>, <physdesc> und <scopecontent>, die nicht
umfangreich genug sind, um sie unter den genannten Elementen gesondert zu
taggen. Es kann einfacher sein, <abstract> zu verwenden, es ist allerdings genauso
gültig, <did> zu schließen und <scopecontent> und <p> außerhalb von <did> zu
verwenden.
<c02>
<did>
<container type="box">2</container>
<unittitle>Juli 1925-Juni 1927</unittitle>
<abstract>Umfasst eine nicht erläuterte
Zusammenstellung ausgewählter Festnahmen im Okt.
1923 bis 1925. Es handelt sich u. U. um Personen,
die ihre Geldstrafen nicht gezahlt haben.</abstract>
</did>
</c02>
*
A.d.Ü.: Original: chains.
100
3.5.2.3.1.4. Identifikator der Einheit/Signatur <unitid> (ID of the Unit) und
Lagerungsort <physloc> (Physical Location)
Im Zusammenhang mit dem hochrangigen <did> haben wir festgestellt, dass einige
Archive nicht nur die empfohlenen Elemente <repository>, <origination>, <unittitle>,
<unitdate>, <physdesc> und <abstract>, sondern auch <unitid> und <physloc> in die
Beschreibung zum gesamten Bestand aufnehmen (siehe die Abschnitte 3.5.1.2.7
und 3.5.1.2.8). Diese beiden Elemente können auch auf Komponentenebene
verwendet werden, wenn sich die Informationen von denen im hochrangigen <did>
unterscheiden. Ein Bestand kann z. B. mit einer bestimmten Zugangs- oder
Bestellnummer bezeichnet werden, und jede Komponente innerhalb des Bestandes
kann eine von dieser Elternnummer abgeleitete Signatur erhalten. Oder aber der
Bestand besteht aus einer Gruppe von Teilen, von denen jedes eine gesonderte
Signatur erhält, auch wenn der gesamte Bestand keine Signatur hat.
<c04>
<did>
<unittitle>Gruppen (einschl. Belafonte Singers), Nr.
916-925 (F)</unittitle>
<unitid>LOS 13074, Nr. 767-987</unitid>
</did>
</c04>
Im hochrangigen <did> kann in <physloc> eine Magazinbezeichnung, ein Regal oder
eine Adresse außerhalb der betreffenden Institution als Lagerungsort angegeben
werden. Das gleiche gilt für <c> <did> <physloc>, in dem Lagerungsorte für
Komponenten angegeben werden können, die sich von denen des übrigen
Bestandes unterscheiden, z. B. für besonders große Gegenstände oder Filme,
Tonaufnahmen oder andere Archivaliengattungen, die oft gesondert gelagert werden.
<c06>
<did>
<unittitle><title render="italic">Women in Love
</title>, </unittitle>
<physdesc>Probeseiten </physdesc>
<physloc>(Entnommen und in der Küche
abgelegt)</physloc>
</did>
</c06>
Das meiste Archivgut befindet sich in Ordnern, Kisten und/oder Regalen. Diese
Informationen zum Lagerungsort werden oft in ein Findbuch aufgenommen. Sie
werden jedoch nicht mit Hilfe von <physloc> kodiert. Vielmehr wird ein weiteres
<did>-Subelement, nämlich <container>, zur Bezeichnung der unterschiedlichen
Typen von Lagerungsbehältern und die laufende Nummer für diese Behälter
verwendet. Da diese Informationen unter <container> von ganz anderer Art als die
übrigen Informationen in einem Findbuch sind, wird die Funktion von <container>
und seine Beziehung zur intellektuellen Auszeichnung in Abschnitt 3.5.2.4 erörtert.
3.5.2.3.2. Erweiterte Erschließungsangaben von Komponenten
Wie bereits festgestellt wurde, stehen alle Elemente, mit denen der Bestand als
Ganzes beschrieben werden kann, auch für die Beschreibung der Komponenten zur
Verfügung. Das heißt, dass neben den <did>-Subelementen auch <admininfo>,
101
<bioghist> und <scopecontent> (siehe Abschnitte 3.5.1.4 bis 3.5.1.6) verwendet
werden können. Ebenfalls verfügbar sind <arrangement> und <organization> (in
Abschnitt 3.5.1.6 im Zusammenhang mit <scopecontent> behandelt und im letzten
Beispiel unter 3.5.2.3.1 auf Komponentenebene gezeigt) sowie <add> (siehe
Abschnitt 3.5.4).
Jedes dieser Elemente kann verwendet werden, wenn die Erschließungsangaben
der Komponenten von denen des Elternbestandes abweichen oder für die
Erschließung auf Elternebene weitere Detailinformationen erforderlich sind. Bisweilen
ist es sinnvoll, solche Daten auf der Komponentenebene zu kodieren, auf die sie sich
unmittelbar beziehen, z. B. auf Teilgruppen-, Serien-, Akten- oder Einzelstückebene.
Informationen über Benutzungsbeschränkungen können beispielsweise an den
Stellen eines Bestandsverzeichnisses erscheinen, an denen Einzelstücke mit
Benutzungsbeschränkungen beschrieben sind.
<c01 level="series">
<did>
<unittitle>Search Files</unittitle>
</did>
<c02 level="file">
<did>
<unittitle>College of Engineering Dean Search
<unitdate type="single">1986</unitdate>
</unittitle>
<physdesc>
<extent>2 Ordner</extent>
</physdesc>
</did>
<admininfo>
<accessrestrict><p>Sperrfrist bis <date
type="restrict"
normal="20100101">1. Januar
2010</date></p></accessrestrict>
</admininfo>
</c02>
</c01>
In einem solchen Fall werden in <accessrestrict> die allgemeine Art der
Benutzungsbeschränkung und das Ende der Sperrfrist angegeben. Spezifisches
Taggen der Informationen darüber, wie lange ein Bestand für die Benutzung gesperrt
ist, erleichtert das automatische Aktualisieren von Findbüchern bei Ablauf der
Sperrfrist.
Ein <scopecontent>-Element auf <c>-Ebene könnte aus einem kurzen Absatz
bestehen, in dem Themen und Art der Materialien einer bestimmten Serie
beschrieben sind. In anderen Fällen lohnt es sich u. U. zu einer Akte oder einem
Einzelstück, umfangreichere Erschließungsangaben im Element <abstract> innerhalb
von <did> aufzunehmen. Oft richtet es sich nach Art und Umfang des zu kodierenden
Textes, ob <scopecontent> und nicht <arrangement>, <organization> oder
<abstract> verwendet wird. Beim Taggen eines Findbuchs und sämtlicher
Findbücher eines Archivs ist Einheitlichkeit anzustreben. Das trägt zur Verbesserung
des Systemdesigns und der Benutzerfreundlichkeit bei.
Wie in Unterabschnitt 3.5.1.7.4 erwähnt, stehen auch die Elemente <dao> und
<daogrp> auf der <c>-Ebene zur Verfügung. Sie können dazu verwendet werden,
102
um den gesamten Inhalt einer Akte einzubetten oder Verknüpfungen zu
ausgewählten Stücken in einer Akte zu schaffen, vor allem wenn die Unterlagen oft
bestellt werden oder zu empfindlich sind, um im Original vorgelegt zu werden. In
Abschnitt 7.3.6 ist im Einzelnen beschrieben, wie dabei vorzugehen ist.
3.5.2.4. Informationen zu Lagerungsort und Behälter <container> (Container)
Nach den Angaben zur Ordnung eines Bestandes können weitere Angaben zur
Lagerung der Materialien im Archiv folgen. Zumeist befinden sich die Materialien in
Kisten und Ordnern, oder sie sind auf Mikrofilm reproduziert oder elektronisch
gespeichert. Diese Informationen zu Verpackung oder Lagerung, die manchmal
durch eine Kontroll- oder Zugangsnummer und keiner konkreten Behälternummer
ausgedrückt wird, helfen den Mitarbeitern dabei, die benötigten Archivalieneinheiten
aufzufinden. Bisweilen tragen diese Informationen zwar dazu bei, Benutzern einen
Eindruck vom Umfang der Materialien, was für die Beurteilung der Unterlagen
hinsichtlich der jeweiligen Forschungsfrage von Interesse sein kann. In der Regel
dienen sie jedoch für die Bestellung von Materialien.
Wenn Behälter- oder Kontrollnummern hinzugefügt werden, wird die Funktion eines
Findbuchs dahingehend erweitert, dass es nicht nur als Einstiegswerkzeug in den
Inhalt der Materialien, sondern auch für die Bezeichnung des Lagerungsorts dient. In
herkömmlichen papiergestützten Findbüchern werden beide Funktionen häufig
typografisch mit Hilfe von Spalten umgesetzt. Die Erschließungsangaben erscheinen
auf einer Seitenhälfte, und die Auflistung von Behälternummern, Mikrofilmnummern
oder sonstigen Kontrollnummern erscheint auf der anderen, wie man im nächsten
Beispiel, bei dem Behälternummern in die zuvor gezeigte geschachtelte Hierarchie
eingefügt wurden, sehen kann. Die Behälterinformationen werden auf die gleiche
Weise wie die übrigen Informationen vererbt. Auch wenn jede Behälternummer nur
einmal im Findbuch erscheint, gehen Archivare davon aus, dass Leser intuitiv
wissen, dass die Behälternummer bei allen folgenden Komponenten, bis die nächste
Behälternummer genannt wird, gleich bleibt. Zu den einzelnen Behältern sind
bisweilen auch Ordnernummern aufgeführt, wodurch parallel zur Inhaltshierarchie
eine geschachtelte Hierarchie der Angaben zum Lagerungsort erzeugt wird.
Bei diesen nebeneinander stehenden inhaltlichen und lagerungsortbezogenen
Hierarchien kommt es für gewöhnlich an verschiedenen Stellen zu einer
Verschiebung bzw. Unterbrechung. Das kommt daher, dass ein einziger Behälter nur
selten alle Materialien enthält, die in einer hochrangigen Komponente beschrieben
werden. Es wäre sinnvoll, Behälter nur teilweise zu füllen, um Materialien, die als
verschiedene Komponenten beschrieben sind, physisch voneinander zu trennen.
Wenn man das nachstehende Beispiel mit früheren Beispielen vergleicht, wird man
feststellen, dass sich die zuvor festgelegten Komponentenangaben über mehrere
Behälter erstrecken und ein einzelner Behälter Materialien enthalten kann, die
inhaltlich gesehen zu verschiedenen Komponenten gehören. Die Komponente
Literaturserie beginnt z. B. in Behälter 46 und endet in Behälter 48, während die
Komponente Bücher in Behälter 46 beginnt und am Anfang von Behälter 47 endet.
Dagegen enthält Behälter 47 Materialien verschiedener Teilkomponentenebenen,
nämlich der Teilkomponenten Bücher und Kurzgeschichten.
103
46
47
48
49
50
LITERATURSERIE, 1943-1970, o.D.
Artikel, 1951-1966
Bücher
Raising Demons (1957)
Kritiken, 1956-1957, o.D.
Honorarangaben, 1956-1969
The Road Through the Wall (1948), 1947-1970,
o.D.
Kurzgeschichten und andere Schriften
"The Lottery"
Dramaturgische Bearbeitungen
Korrespondenz, 1949-1953, 19671970
Drehbücher und Fernsehspiele, o.D.
Honorarangaben, 1950-1953, 19641970
"Lover's Meeting," o.D.
SAMMELALBEN, 1933-1968
Spiele aus der Collegezeit, 1933-1937
"The Lottery," 1949-1952
SGML kann mehrere parallele Hierarchien nicht effizient verarbeiten. Daher mussten
sich die Entwickler von EAD überlegen, für welche Hierarchie die DTD optimiert
werden sollte. Es schien klar zu sein, dass die inhaltliche Anordnung wichtiger und
beständiger ist als die physische Ablage und dass daher Behälterinformationen
gegenüber der inhaltlichen Hierarchie zweitrangig sein sollten und nicht umgekehrt.
Mit anderen Worten, die Kisten und Ordner, in denen sich das Archivgut befindet,
sind nicht die Komponenten eines Bestandes. Serien, Teilserien, Akten, Einzelstücke
usw. sind Komponenten. Die Angaben zu Behältern und Verpackungen sind lediglich
Zusatzinformationen, die das Wiederauffinden der Komponenten unterstützen.
Demzufolge hat jede neue Behälterangabe keinen Einfluss darauf, wo eine
Komponente anfängt oder aufhört.
Bei der EAD-Kodierung „folgen“ die Behälterinformationen der inhaltlichen Struktur.
Sie werden als Teil der Erschließungsangaben zur ersten Komponente in dem
betreffenden Behälter getaggt. Das nachstehende Beispiel veranschaulicht dieses
Konzept. Es zeigt auch, wie das Attribut TYPE im Zusammenhang mit <container>
verwendet wird. Die Verwendung von TYPE wird zur Bezeichnung der Art des
Lagerungsbehälters dringend empfohlen. Typische Werte sind z. B. "box" (Kiste),
"folder" (Ordner) und "reel" (Filmbüchse). Beinhaltet eine zugewiesene Nummer die
Bezeichnung von Kiste und Ordner, kommt der Attributwert "box-folder" (KisteOrdner) in Betracht. Es ist zu beachten, dass in dem Beispiel die für eine
ordnungsgemäße Auszeichnung erforderlichen <did>- und <unittitle>-Tags
weggelassen wurden, um die Ordnung der <container>-Tags hervorzuheben.
104
<c01 level="series">LITERATURSERIE, 1943-1970, o.D.
<c02><container type="box">46</container>
Artikel, 1951-1966</c02>
<c02>Bücher
<c03>Raising Demons (1957)
<c04>Kritiken, 1956-1957, o.D.</c04>
<c04><container type="box">47</container>
Honorarangaben, 1956-1969</c04></c03>
<c03>The Road Through the Wall (1948), 1947-1970,
o.D.</c03></c02>
<c02>Kurzgeschichten und andere Schriften
<c03>"The Lottery"
<c04>Dramaturgische Bearbeitungen
<c05>Korrespondenz, 1949-1953, 19671970</c05><c05>Drehbücher und
Fernsehspiele, o.D.</c05></c04>
<c04><container type="box">48</container>
Honorarangaben, 1950-1953, 1964-1970
</c04></c03>
<c03>"Lover's Meeting," o.D. </c03></c02></c01>
<c01>SAMMELALBEN, 1933-1968
<c02><container type="box">49</container>Spiele aus der
Collegzeit, 1933-1937</c02>
<c02><container type="box">50</container>"The Lottery,"
1949-1952</c02></c01>
Die Verteilung von Komponenten auf verschiedene Behälter wird noch deutlicher,
wenn man sich ein Szenario vorstellt, bei dem die tiefstrangige Komponente sich in
mehr als einem Behälter befindet. Das folgende Beispiel zeigt, was geschehen
könnte, wenn es fünf Ordner mit Kritiken zum Werk Raising Demons gäbe, die nicht
alle in Behälter 46 untergebracht werden könnten. In diesem fiktiven Fall stellt der
rechts von der Behälternummer 47 erscheinende Text nicht eine neue Komponente
dar, sondern lediglich eine zusätzliche Angabe zum Umfang der vorigen
Komponente („Kritiken, 1956-1957, o.D.“). (Anmerkung: Bei der Konversion
vorhandener Findbücher darf nicht davon ausgegangen werden, dass alle
typografischen Einrückungen den Anfang einer neuen Komponente anzeigen. In
einigen Fällen – wie in diesem Beispiel – bildet der eingerückte Text einfach die
Fortsetzung der vorherigen Komponentenverzeichnungsangaben.)
Behälternummern
Inhalt
LITERATURSERIE, 1943-1970, o.D.
46
47
Artikel, 1951-1966
Bücher
Raising Demons (1957)
Kritiken, 1956-1957, o.D.
(2 Ordner)
(3 Ordner)
Honorarangaben, 1956-1969
Nachstehend sieht man, wie dieser Abschnitt kodiert wird, damit ersichtlich ist, dass
die Komponente <c04> „Kritiken“ sich auf die Behälter 46 und 47 erstreckt. Es ist zu
beachten, dass hier die für eine ordnungsgemäße Auszeichnung erforderlichen
Elemente <did>, <unittitle> und <physdesc> weggelassen wurden.
105
<c01 level="series">LITERATURSERIE, 1943-1970, o.D.
<c02><container>46</container>
Artikel, 1951-1966</c02>
<c02>Bücher
<c03>Raising Demons (1957)
<c04>Kritiken, 1956-1957, o.D.
<extent>(2 Ordner)</extent>
<container>47</container><extent>
(3 Ordner)</extent></c04>
<c04>Honorarangaben, 1956-1969</c04></c03>
</c02></c01>
Wie die beiden vorangegangenen Beispiele veranschaulichen, kann EAD
herkömmliche Verfahren, die Behälternummern in zahlreichen Findbüchern
erscheinen lassen, Rechnung tragen, in dem es ermöglicht, dass Behälternummer
nur an der Stelle des Findbuchs auftreten, an der die Auflistung des Inhalts des
Behälters beginnt. Archivare waren bisher der Ansicht, dass diese Vorgehensweise
ausreichte und von Lesern implizit verstanden wurde. Leider wurde das Vermögen
der Leser, auf vererbte Behälterinformationen zu schließen, beeinträchtigt, als man
damit gekann, Findbücher in elektronischer Umgebung zu verbreiten. Während
früher Leser rasch eine Textseite durchlesen oder zu einer früheren Druckseite
zurückblättern konnten, müssen sie heute durch eine elektronische Datei, die auf
dem PC des Lesers u. U. nicht wie ursprünglich vom Ersteller formatiert erscheint,
scrollen oder springen.
Bei der Anwendung von EAD ist es wichtig, sich nicht darauf festzulegen, die
Formatierung der in Papierform vorhandenen Findmittel nachzubilden. Einige
Änderungen können erforderlich sein, um Findbuchinformationen in elektronischer
Form auswärtigen Benutzern verständlich zu machen, denen oft keine Archivare
beratend zur Verfügung stehen. Beispielsweise haben einige EAD-Anwender den
Schluss gezogen, dass zur Unterstützung auswärtiger Benutzer die Behälternummer
für jede Komponente dargestellt werden sollte. Andere finden diese Lösung zu
arbeitsintensiv. Ihnen missfällt die sich daraus ergebende wiederholte Darstellung,
und sie sind nicht davon überzeugt, dass die Vorteile den durch das zusätzliche
Taggen vergrößerten Dateiumfang überwiegen. Wie bei jeder Entscheidung zum
Tagging müssen Archive nicht nur die aktuelle Darstellung von und das Navigieren in
Online-Findbüchern berücksichtigen, sondern auch überlegen, ob sie Informationen
in einem EAD-Dokument unmittelbar oder später für verschiedene andere Zwecke
verändern bzw. wiederverwenden möchten.
Ein solcher unmittelbarer Zweck könnte darin bestehen, kurze Trefferlisten für
Materialien in mehreren Beständen in Bezug auf ein bestimmtes Thema oder einen
bestimmten Begriff zu erstellen. Es wäre zwar schon hilfreich, wenn diese Art der
Recherche den Leser zu einer Liste von Beständen führte. Man stelle sich aber vor,
wie erfreut der gleiche Leser wäre, wenn er eine Liste erhielte, die nicht nur den
Bestand bezeichnete, sondern auch den Behälter angäbe und
Komponentenangaben innerhalb dieses Bestandes enthielte. Die Leichtigkeit, mit der
ein Rechnersystem solche Ergebnisse erbringen kann, hängt in gewissem Grade von
der expliziten EAD-Kodierung ab, da Rechner nicht die vielen impliziten
Verbindungen zwischen Daten herstellen können, die Menschen routinemäßig
herstellen. Während ein Mensch folgern kann, dass sich eine Kistennummer solange
auf alle folgenden Einträge bezieht, bis eine neue Kistennummer angegeben wird,
106
hat ein Rechner viel mehr Mühe damit, einen solchen Schluss zu ziehen. Für eine
verbesserte Datenverarbeitung sollte daher in Betracht gezogen werden, die
Behälterinformationen für jede Komponente erneut zu kodieren. Eine andere
Möglichkeit besteht darin, das Attribut PARENT zu verwenden, das in Verbindung mit
den Elementen <container> und <physloc> zur Verfügung steht (siehe Abschnitt
7.2.5).
Wie bei vielen Aspekten der EAD-Implementierung sollte der zu erwartende Nutzen
einer Kodierung von Behälterinformationen zu jeder Komponente gegenüber den
Kosten einer solchen Maßnahme abgewogen werden. Außerdem muss die Fähigkeit
des Systems berücksichtigt werden, Informationen zu unterdrücken, die nicht
dargestellt oder durchsucht werden sollen. Beispielsweise kann es erwünscht sein,
die Behälterinformationen im kurzen „Trefferlisten“-Format, jedoch nicht auf jeder
Zeile des elektronischen Findbuchs darzustellen. Wahrscheinlich könnte ein
Stylesheet erstellt werden, mit deren Hilfe ein Lagerungsort und Behälter nur beim
ersten Auftreten dargestellt wird. Die Fähigkeit zur Unterstützung solch zusätzlicher
Skripte ist allerdings vermutlich von einem Browser zum anderen verschieden. Eine
ansprechendere (aber auch schwierigere) Lösung besteht darin, am oberen
Bildschirmrand eine dynamische oder laufende Titelzeile erzeugen zu lassen, in der
die Behälter- und Komponentendaten auf höherer Ebene dargestellt werden und die
sich beim Navigieren durch die Findbücher entsprechend aktualisieren. Da die
Fähigkeit zur Erzeugung derartiger Darstellungen sich u. U. nach der Detailtiefe der
Kodierung richtet, sollten Archivare erwägen, ob sie Daten in höherem Maße
kodieren sollten, als es die derzeit verfügbare Software unterstützt oder es die
jeweiligen Bedürfnisse erfordern.
3.5.2.5. Formatierung von Erschließungsangaben untergeordneter
Komponenten <dsc> (Description of Subordinate Components)
In den vorangegangenen Abschnitten wurde gezeigt, wie in einem EAD-Findbuch die
hierarchische Struktur eines archivischen Bestandes erfasst werden kann, wobei
jede Komponente die Erschließungsangaben der übergeordneten Komponente erbt.
Man kann sich dies als stetigen, jedoch veränderlichen Fluss vorstellen, bei dem die
Informationen von <archdesc> hinunter zu den verschiedenen <c> fließen, wobei die
Tiefe entsprechend der Anzahl der geschachtelten Komponenten in der gesamten
Hierarchie zu- bzw. abnimmt. Bevor die Informationen vom Ganzen zu den Teilen
nach unten strömen, müssen sie jedoch zuerst durch ein weiteres Element fließen,
das als Erschließung untergeordneter Komponenten <dsc> (Description of
Subordinate Components) bezeichnet wird. Dieses Element ist ein
Formatierungskonstrukt, nicht unähnlich einem Aquädukt, das den Informationsfluss
entlang mehrerer möglicher Wege lenkt, um die unterwegs zu erwartende Navigation
zu ermöglichen.
Das Element <dsc> muss geöffnet werden, bevor ein <c>-Element eingefügt werden
kann. <dsc> ist ein erforderliches Hüllenelement, das die untergeordneten <c>Elemente in <archdesc> umgibt und den Computer auf die besonderen
Formatierungs- und Strukturierungsmöglichkeiten hinweist, die ggf. erscheinen, wenn
der Informationsfluss seinen Verlauf ändert. Wie in früheren Abschnitten erörtert,
bestehen die Erschließungsangaben des Ganzen aus kurzen Textpassagen in den
hochrangigen <did>-Subelementen, gefolgt von längeren Aussagen, die als
<admininfo>, <bioghist>, <scopecontent>, <organization> und <arrangement>
107
kodiert sind. Bei den meisten der letztgenannten Elemente ist das Inhaltsmodell ein
<head>, das Benutzer bei der Interpretation der Daten unterstützt, gefolgt von Text,
der sich aus <p> oder verschiedenen Typen von <list> zusammensetzt. Wenn auch
<admininfo>, <bioghist>, <scopecontent> und andere fließtext-basierte Elemente auf
<c>-Ebene verfügbar sind, so ist es doch eine übliche Praxis beim Erstellen von
Findbüchern, dass die meisten Angaben auf Komponentenebene aus
verhältnismäßig kurzen <did>-ähnlichen Informationen in eingerückten Spalten oder
Feldern bestehen.
Die Notwendigkeit, solche Altformate zu verarbeiten, bewog die EAD-Entwickler zur
Einführung von <dsc>, um folgende Funktionen zu erfüllen:
•
•
•
Bezeichnung der Art der Informationsdarstellung
Beschränkung der Stellen im EAD-Dokument, an denen bestimmte Elemente
zur tabellarischen Darstellung, z. B. <drow> und <dentry>, verfügbar sind
(siehe die Erörterung von EAD-Tabellen in Abschnitt 4.3.5.4)
Als Verfahren zur Einschränkung von Recherchen innerhalb eines Findbuchs
entweder auf die Erschließungsangaben des übergeordneten Ganzen oder
die Erschließungsangaben der untergeordneten Teile.
Ein Attribut TYPE ist im Zusammenhang mit <dsc> erforderlich, um die Richtung des
Informationsflusses zu bestimmen. Dabei sind folgende vier Werte möglich:
•
•
•
•
kombiniert (Combined)
analytischer Überblick (Analytic overview)
tief gehend (In-depth)
sonstiger Typ (Othertype).
Der beste (und vom Anwenderleitfaden empfohlene) Fluss besteht darin, das Attribut
TYPE auf "combined" zu setzen. Damit wird auf eine Informationsfolge ähnlich der in
Bild 3.5.2a gezeigten hingewiesen, in der auf die Angaben zu einer Serie oder
Teilserie unmittelbar die Angaben der Komponenten folgen.
108
Literaturserie, 1943-1970, o.D.
Korrespondenz, Manuskriptentwürfe, Honorarangaben, Drucksachen, Bemerkungen,
Abrisse, Forschungsmaterial, Fernsehspiele und verschiedene Einzelstücke und
Anlagen zu Büchern und Kurzgeschichten von Jackson. Alphabetisch geordnet nach
Materialtyp und alphabetisch darin gegliedert nach Titel und Themen.
Veröffentlichungsdaten der Bücher sind in Klammern angegeben.
Artikel, 1951-1966
Bücher
Raising Demons (1957)
Kritiken, 1956-1957, o.D
Honorarangaben, 1956-1969
The Road Through the Wall (1948), 1947-1970, o.D.
Kurzgeschichten und andere Schriften
"The Lottery"
Dramaturgische Bearbeitungen
Korrespondenz, 1949-1953, 1967-1970
Drehbücher und Fernsehspiele, o.D.
Royalty statements, 1950-1953, 1964-1970
"Lover's Meeting," o.D.
Bild 3.5.2.5.a. Kombiniertes Modell <dsc type="combined">
Formatierte Erschließungsangaben zu Serien
109
<dsc type=“combined“
<c01 level=“series“>
<did>
<unittitle>Literaturserie, <unitdate>1943-1970,
o.D. </unitdate><unittitle>
</did>
<scopecontent>
<p> Korrespondenz, Manuskriptentwürfe, Honorarangaben,
Drucksachen, Bemerkungen, Abrisse, Forschungsmaterial,
Fernsehspiele und verschiedene Einzelstücke und Anlagen zu
Büchern und Kurzgeschichten von Jackson. </p>
<arrangement><p> Alphabetisch geordnet nach Materialtyp und
alphabetisch darin gegliedert nach Titel und Themen.
Veröffentlichungsdaten der Bücher sind in Klammern angegeben.
</arrangement></p>
</scopecontent>
<c02><did><unittitle> Artikel, 1951-1966</unittitle></did></c02>
<c02><did><unittitle>Bücher</unittitle></did>
<c03>><did><unittitle><title> render=“italic“> Raising
Demons</title>(1957)</unittitle></did>
<c04><did><unittitle>Kritiken, 1956-1957,
o.D.</unittitle></did></c04>
<c04><did><unittitle>Honorarangaben, 1956-1959,
o.D.</unittitle></died></c04></c03>
<c03><did><unittitle><title> render=“italic“> The Road Through
the Wall </title>(1948), 1947-1970,
o.D.</unittitle></did></c03><c02>
<c02><did><unittitle>Kurzgeschichten und andere
Schriften</unittitle></did></c02>
<c03><did><unittitle><title render=“quoted“>The
Lottery</title></unittitle></did>
<c04><did><unittitle>Dramaturgische
Bearbeitungen</unittitle></did>
<c05><did><unittitle>Korrespondenz, 1949-1953, 19671970</unittitle></did></c05>
<c05><did><unittitle>Drehbücher und Fernsehspiele,
o.D.</unittitle></did></c05></c04>
<c04><did><unittitle>Honorarangaben, 1950-1953, 19641970</unittitle></did></c04></c03>
<c03><did><unittitle><title> render=“quoted“>Lover’s Meeting,
</title>o.D.</unittitle></did></c03>
</c02>
</c01>
<dsc>
Bild 3.5.2.5.b. Kombiniertes Modell <dsc type="combined">
Formatierte Erschließungsangaben zu Serien
110
Das Modell analytic overview (type="analyticover") dient zur Kodierung eines
Überblicks zu hochrangigen Komponenten, z. B. wenn nacheinander jede Serie (und
möglicherweise Teilserie) eines Bestandes einzeln auf ihrer höchsten Ebene
beschrieben und gemeinsam dargestellt wird (siehe Bild 3.5.2.5c und Bild 3.5.2.5d).
Mit anderen Worten, ein <c01> wird geöffnet, die erste Serie kurz erfasst und das
<c01> geschlossen, ohne dass seine Teilkomponenten erfasst worden sind. Dann
wird das zweite <c01> geöffnet, die zweite Serie kurz erfasst und dieses <c01>
geschlossen. Auf die gleiche Weise werden alle folgenden <c01>-Teilkomponenten
bearbeitet. Wie beim Modell "combined" werden die Angaben zu jeder Serie unter
Verwendung der <c>- bzw. <c01>-Tags kodiert, wobei das Attribut LEVEL auf
"series" steht.
Das Modell in-depth (type="in-depth") ist für die Kodierung einer Inhaltsliste getrennt
von allen narrativen Serienangaben bestimmt. Jede Serie, Teilserie, Akte oder
Einzelstück in der Inhaltsliste wird als rekursive, geschachtelte Komponente getaggt,
u. U. mit einem optionalen Attribut LEVEL, das so eingestellt ist, dass es die
hierarchische Stellung innerhalb des Bestandes oder Unterlagengruppe bezeichnet.
(Siehe Bild 3.5.2.5e und 3.5.2.5f)
Der letzte Wert für <dsc>, othertype (type="othertype"), wird bei Modellen verwendet,
die keinem der drei spezifisch festgelegten Formate entsprechen und denen der
Archivar eine beliebige geeignete Bezeichnung geben kann.
Innerhalb eines einzigen EAD-Findbuchs kann <dsc> mit unterschiedlichen TypWerten spezifiziert werden. Die Kodierung eines <dsc type="analyticover">, gefolgt
von einem <dsc type="in-depth">, findet man oft in älteren Findbüchern. Dieses
Verfahren mit zwei <dsc> hat Vor- und Nachteile. Es eignet sich für konventionelle
Strukturen, ohne dass Text verschoben oder erneut eingegeben werden muss.
Außerdem bleibt dabei die Eigenschaft der konventionellen Struktur erhalten, alle
Erschließungsangaben zu den Komponenten auf höchster Ebene an einer Stelle zu
sammeln, so dass ein Benutzer sie rasch durchlesen kann. Es wäre umständlicher,
ein langes auf Papier gedrucktes Findmittel durchzublättern oder durch ein
elektronisches Findbuch zu scrollen oder zu springen, um alle Angaben auf höchster
Ebene zu finden, die unter einem kombinierten <dsc> kodiert sind.
Das oben beschriebene Verfahren mit zwei <dsc> hat andererseits auch Nachteile.
Da die gleichen Komponenten auf erster Ebene (<c01>) öfter als einmal (zuerst im
analytischen Überblick und dann in der In-Depth- (tief gehenden) Darstellung) kodiert
werden, kann dies einen Rechner verwirren, der gleichartige Informationen zu
verarbeiten versucht. Je nachdem, wie hochentwickelt die Such- und
Verarbeitungsmöglichkeiten eines Systems sind, kann das Verfahren mit zwei <dsc>
die Fähigkeit einschränken, eine Beziehung zwischen der Erschließungsangaben zu
<c01> und den Erschließungsangaben von dessen Teilen darzustellen. Die nächste
Generation von Web-Browsern bietet vielleicht eine Lösung mit Hilfe von Skripten,
mit denen alle Serienangaben in einem kombinierten <dsc> untergebracht und
dargestellt bzw. ausgedruckt werden können. In einem solchen Szenario könnte die
Funktionalität des analytischen Überblicks erhalten bleiben, ohne dass die
natürlichen hierarchischen Erschließungsangaben eines Bestandes auf zwei <dsc>
aufgeteilt werden müssen.
111
Bis dahin können Archivare, die das Verfahren mit zwei <dsc> anwenden, eventuell
aus den Serienangaben im analytischen Überblick Hypertextlinks in die
Erschließungsangaben der Komponenten im In-Depth-<dsc> bereitstellen, anstatt
die gleichen Komponenten der höchsten Ebene zweimal zu codieren.
Behälternummer
1
2
3-12
13-19
Serien
Tagebuch und Tagebuchnotizen, 1932-1934, o.D.
Ein Tagebuch aus der Oberschule und ein undatiertes,
einseitiges Tagebuchfragment geführt durch Jackson.
Chronologisch angeordnet.
Familienunterlagen, 1938-1965, o.D.
Erhaltene Briefe, Notizen, Karten. Alphabetisch angeordnet
nach Korrespondent und darin chronologisch.
Korrespondenz 1936-1970, o.D.
Erhaltene Briefe und gelegentliche Kopien von abgesendeten
Briefen, Telegrammen und Postkarten und verschiedene
Anlagen. Alphabetisch angeordnet nach Korrespondent und
darin chronologisch.
Literaturserie, 1943-1970, o.D.
Korrespondenz, Manuskriptentwürfe, Honorarangaben,
Drucksachen, Bemerkungen, Abrisse, Forschungsmaterial,
Fernsehspiele und verschiedene Einzelstücke und Anlagen zu
Büchern und Kurzgeschichten von Jackson. Alphabetisch
geordnet nach Materialtyp und alphabetisch darin gegliedert
nach Titel und Themen. Veröffentlichungsdaten der Bücher sind
in Klammern angegeben.
Bild 3.5.2.5.c. Analytisches Überblicksmodell <dsc type="analyticover">
Formatierte Darstellung von Serien
112
<dsc type="analyticover">
<head>Serienangaben</head>
<thead><row><Behälternummern</entryXentry>Serien
</entry></row></thead>
<c01 level="series">
<did>
<container>1</container>
<unittitle>Tagebuch und Tagebuchnotizen, <unitdate>1932-1934,
o.D. </unitdate></unittitle>
</did>
<scopecontent><p> Ein Tagebuch aus der Oberschule und ein
undatiertes, einseitiges Tagebuchfragment geführt durch Jackson. </p>
<arrangement><p> Chronologisch angeordnet.</p></arrangement>
</scopecontent>
</c01>
<c01 level="series">
<did>
<container>2</container>
<unittitle>Familienunterlagen, <unitdate> 1938-1965, o.D.
</unitdate></unittitle>
</did>
<scopecontent><p>Erhaltende Briefe, Bemerkungen und Karten</p>
<arrangement><p>Alphabetisch Anordnung der Familienmitglieder,
darin chronologisch.</p></arrangement> </scopecontent>
</c01>
<c01 level="series">
<did>
<container>3-12</container>
<unittitle>Korrespondenz, <unitdate> 1936-1970, o.D.
</unitdate></unittitle>
</did>
<scopecontent><p> Erhaltene Briefe und gelegentliche Kopien von
abgesendeten Briefen, Telegrammen und Postkarten und verschiedene
Anlagen.</p><arrangement><p> Alphabetisch angeordnet nach
Korrespondent und darin chronologisch </p></arrangement>
</scopecontent>
</c01>
<c01 level="series">
<did>
<container>13-19</container> <unittitle>Literaturserie,
<unitdate>1943-1970, o.D.</unitdate></unittitle>
</did>
<scopecontent><p> Korrespondenz, Manuskriptentwürfe, Honorarangaben,
Drucksachen, Bemerkungen, Abrisse, Forschungsmaterial, Fernsehspiele
und verschiedene Einzelstücke und Anlagen zu Büchern und
Kurzgeschichten von Jackson.</p><arrangement><p> Alphabetisch
geordnet nach Materialtyp und alphabetisch darin gegliedert nach
Titel und Themen. </p></arrangement><p> Veröffentlichungsdaten der
Bücher sind in Klammern angegeben </p></scopecontent>
</c01>
</dsc>
Bild 3.5.2.5d. Analytisches Überblicksmodell <dsc type="analyticover">
Kodierte Darstellung von Serien
113
LITERATURSERIE, 1943-1970, o.D.
Behälternummern Inhalt
46
Artikel, 1951-1966
Bücher
Raising Demons (1957)
Kritiken, 1956-1957, o.D
Honorarangaben, 1956-1969
47
The Road Through the Wall (1948), 1947-1970, o.D.
Kurzgeschichten und andere Schriften
"The Lottery"
Dramaturgische Bearbeitungen
Korrespondenz, 1949-1953, 1967-1970
Drehbücher und Fernsehspiele, o.D.
48
Honorarangaben, 1950-1953, 1964-1970
"Lover's Meeting," o.D.
Bild 3.5.2.5e. In-Depht-Modell <dsc type="in-depth"> Formatiertes
Bestandsverzeichnis
114
<dsc type="in-depth">
<head>Bestandsverzeichnis</head>
<thead><row valign="top">
<entry colname="1">Behälternummern</entry><entry
colname="2">Inhalte</entry></row></thead>
<c01 level="series">
<did>
<unittitle>Literaturserie, <unitdate type="inclusive">19431970, o.D.</unitdate></unittitle>
</did>
<c02><did><container>46</container><unittitle>Articles, 19511966</unittitle></did></c02>
<c02><did><unittitle>Bücher</unittitle></did>
<c03><did><unittitle><title render="italic">Raising
Demons</title> (1957)</unittitle></did>
<c04><did><unittitle>Kritiken, 1956-1957,
o.D.</unittitle></did></c04>
<c04><did><unittitle>Honorarangaben,
1956-1969</unittitle></did></c04>
</c03>
<c03><did><container>47</container><unittitle>
<title render="italic">The Road Through the Wall</title>
(1948), 1947-1970, o.D </unittitle></did></c03></c02>
<c02><did><unittitle>Kurzgeschichten and other writings
</unittitle></did>
<c03><did><unittitle><title render="quoted">The
Lottery</title></unittitle></did>
<c04><did><unittitle>Dramaturgische
Bearbeitungen</unittitle></did>
c05><did><unittitle>Korrespondenz, 1949-1953,
1967 - 1970</unittitle></did></c05>
<c05><did><unittitle>Drehbücher und Fernsehspiele,
o.D.</unittitle> </did></c05></c04>
<c04><did><container>48</container><unittitle>Honorarangaben, 1950-1953, 1964-1970</unittitle></did></c04>
</c03>
<c03><did><unittitle><title render="quoted">Lover's
Meeting, </title> o.D.</unittitle></did></c03>
</c02>
</c01>
[...]
</dsc>
Bild 3.5.2.5f. In-Depth Modell <dsc type = "in-depth">
Kodiertes Bestandsverzeichnis
115
3.5.3. Begriffe aus Normansetzungen <controlaccess> (Controlled Access
Headings)
Die meisten Archivare haben sich daran gewöhnt, in MARC-Titelaufnahmen zur
Erschließung ihrer Bestände Zugriffsbegriffe aus kontrollierten Vokabularien zu
verwenden. Sie gewährleisten standardisierte Formen von Personen- und
Körperschaftsnamen, geografischen Namen, Themen, Genre- und Formbegriffen
und anderen Zugriffsbegriffen und erleichtern dadurch das Auffinden in
bibliografischen Datenbanken. In EAD können solche formellen Zugriffsbegriffe in
<controlaccess> gruppiert oder in dem gesamten Findbuch verteilt verwendet
werden. Einige dieser Elemente für Zugriffsbegriffe wurden bereits im
Zusammenhang mit <origination>, <physdesc>, <bioghist> und <scopecontent>
erwähnt (siehe Unterabschnitte von Abschnitt 3.5.1).
Das Element <controlaccess> ist ein Hüllenelement, in dem wichtige Zugriffs- bzw.
Einstiegsbegriffe für die erfassten Materialien zusammengestellt sind und das eine
Suche über kontrolliertes Vokabular der Findbücher eines Rechnernetzwerks
ermöglicht und damit eine ähnliche Aufgabe wie die zusätzlichen Einträge und
Schlagwörter in einer Titelaufnahme erfüllt (Felder 1XX, 6XX und 7XX in MARC). In
einem Findbuch können hunderte von Namen und Themen vorkommen. Die
bedeutendsten davon werden bei der Bearbeitung und als angesetzte
Zugriffsbegriffe gekennzeichnet. Auf <controlaccess>-Subelemente beschränkte
Findbuchrecherchen erhöhen die Wahrscheinlichkeit des Auffindens von relevanten
Quellen zu einem bestimmten Thema, da die Zugriffsbegriffe vermutlich in sämtlichen
Findbüchern konsequent eingegeben wurden. In EAD sollten die gleichen
angesetzten Zugriffsbegriffe für den Bestand wie in der MARC-Titelaufnahme kodiert
werden. In <controlaccess> sind folgende Elemente enthalten (sie sind nachstehend
in der Reihenfolge ihrer Erläuterung aufgeführt):
•
•
•
•
•
•
•
•
•
•
Personenname <persname> (Personal Name)
Körperschaftsname <corpname> (Corporate Name)
Familienname <famname> (Family Name)
Geographische Bezeichnung <geogname> (Geographic Name)
Name <name> (Name)
Genre oder Form <genreform> (Genre/Physical Characteristic)
Funktion <function> (Function)
Beruf <occupation> (Occupation)
Gegenstand <subject> (Subject)
Titel <title> (Title)
Das Element <controlaccess> kann unmittelbar in <archdesc> verwendet werden,
um Zugriffsbegriffe für einen ganzen Bestand zu liefern. Es kann auch in den <c>Elementen zur Bereitstellung von Einstiegen zu bestimmten Komponenten eines
Bestandes dienen. Beide Vorgehensweisen haben ihre Vor- und Nachteile. Die
Gruppierung aller Zugriffselemente in einem Eltern-Element <controlaccess> in
<archdesc> erleichtert das Suchen, Darstellen und Browsen von Zugriffsbegriffen.
Der mögliche Nachteil besteht darin, dass die Recherche – insbesondere bei einem
großen Bestand – ziemlich ungenau ist. Die Rechercheergebnisse sagen Benutzern
nur, dass es an irgendeiner Stelle des Bestandes Materialien gibt, die sich auf den
Suchbegriff beziehen. Werden andererseits <controlaccess>-Elemente in mehrere
<c> gestellt, gelangen Benutzer dadurch an spezifischere Stellen in dem Findbuch.
116
<controlaccess> kann sogar für Erschließungsangaben auf Einzelstückebene
verwendet werden, wenn das bei einem bestimmten Bestand die geeignetste Ebene
für die Bereitstellung von Zugriffen ist. Die derarti tiefe Verwendung von
<controlaccess>-Begriffen innerhalb eines Findbuchs kann jedoch den Nachteil
haben, dass diese Verfahrensweise zeitaufwändiger und damit kostspieliger ist.
Das archivische Prinzip der mehrstufigen Verzeichnung, das SGML-Konzept des
Vererbens und das EAD-Element <controlaccess> können zusammen ein
hochentwickeltes Einstiegssystem ergeben. Notwendig ist hierfür eine sehr
leistungsstarke Suchmaschine, um das Taggen voll auszunutzen, sowie zusätzliche
Kosten für die Auszeichnung des Textes. Jede Institution muss Kosten und Nutzen
der Detailtiefe beim Kodieren unter Berücksichtigung der Verfügbarkeit geeigneter
Recherche- und Darstellungsverfahren, Umfang und Quellenwert eines Bestandes
auf der einen Seite sowie der Kosten für eine komplexere Auszeichnung auf der
anderen Seite gegeneinander abwägen. Bei vielen Beständen und für viele Archive
wird es am zweckmäßigsten sein, alle kontrollierten Zugriffsbegriffe in <archdesc> zu
bündeln.
3.5.3.1. Verwendung von Attributen in <controlaccess>-Subelementen
Der Inhalt jedes <controlaccess>-Subelements lässt sich mit Hilfe von Attributen
spezifizieren. Keines der Attribute ist vorgeschrieben. Ihr Einsatz erhöht jedoch die
Genauigkeit und Wiederverwendbarkeit von Informationen.
Mit dem Attribut SOURCE werden die Grundlagen eines bestimmten normierten
Begriffs oder die Regeln bezeichnet, die zur Bildung dieses Begriffs herangezogen
wurden. Für jedes in <controlaccess> verfügbare Zugriffs-Subelement stellt das
Attribut SOURCE eine halbgeschlossene Liste dar.67 Die Quellenliste enthält
Akronyme für verschieden Quelldokumente:
•
•
•
Thesauri, z. B. Art & Architecture Thesaurus (aat) und Thesaurus for Graphic
Materials I and II (lctgm und gmgpc);
Ansetzungslisten, z. B. Library of Congress Name Authority File (lcnaf), Union
List of Artists Names (ulan), National Council on Archives Rules for
Construction of Personal, Corporate, and Place Names (ncarules);
Katalogisierungsregeln, z. B. Anglo-American Cataloging Rules, 2nd ed.
(aacr2), Archives, Personal Papers, and Manuscripts (appm) und Rules for
Archival Description (rad).
Wenn der/die geeignete Thesaurus, Ansetzungsliste oder Katalogisierungsregel nicht
in der halbgeschlossenen Liste enthalten ist, die in der EAD-Tag-Library aufgeführt
ist, kann ein Kode dafür im Attribut OTHERSOURCE angegeben werden (das
Attribut SOURCE wird auf den Wert "other" eingestellt, und dann wird der Kode für
das verwendete Quelldokument im Attribut OTHERSOURCE angegeben). Es ist zu
beachten, dass „örtlich verwendete Begriffe“ als möglicher Typ in OTHERSOURCE
kodiert werden kann. Wie auch bei einem Online-Katalog wird jedoch die Effektivität
der findbuch- oder archivübergreifenden Suche durch ein Übermaß an örtlich
verwendeten Begriffen stark herabgesetzt.
67
Eine vollständige Liste der Werte für das Attribut SOURCE ist enthalten in: Encoded Archival Description Tag Library, Version
1.0, ed. by Society of American Archivists, Chicago 1998, S. 29.
117
Das Attribut AUTHFILENUMBER kann zur Angabe einer
Ansetzungsdatensatznummer für einen Namen oder Begriff dienen. Bei Verwendung
von AUTHFILENUMBER ist auch das Attribut SOURCE zu verwenden, um die
Normdatei zu bezeichnen, der die Datensatznummer entnommen wurde. Das Attribut
AUTHFILENUMBER ermöglicht es u. U., einen Ansetzungsdatensatz dynamisch in
ein Findbuch einzubinden, um Querverweise für das Recherchieren verfügbar zu
machen. Dies ist von besonderem Nutzen, wenn z. B. eine Person in einem
Archivgutkomplex eine Rolle spielt, da <persname> nicht innerhalb von <subject>
kodiert werden kann (siehe auch Abschnitt 3.5.3.5).
Das Attribut ROLE steht in <corpname>, <famname>, <persname>, <geogname>,
<name> und <title> zur Angabe der Beziehung des bezeichneten Objekts zu den
Materialien zur Verfügung. Beispiele für diese Verwendung sind in Abschnitt 3.5.3.2
enthalten.
Das Attribut ENCODINGANALOG gibt ein Feld oder einen Bereich eines anderen
Kodiersystems an, das mit einem EAD-Element oder -Attribut vergleichbar ist. Das
Abstimmen von Elementen eines Systems mit denen eines anderen kann zur
Schaffung einer individuellen Eingabeschnittstelle beitragen, mit der vergleichbare
Informationen in bibliografischen Aufnahmen und Findbüchern kodiert werden
können.
ENCODINGANALOG-Attribute können auch zur Kennzeichnung von
Zugriffsbegriffen für Darstellungszwecke verwendet werden. Was vielleicht am
wichtigsten ist: es ist u. U. möglich, ausgehend von einem Findbuch eine kurze
MARC-Auszeichnung auf der Grundlage von ENCODINGANALOG-Werten zu
erzeugen.
MARC-Encodinganalogs sind in der EAD-Tag-Library für jedes wichtige Element
angegeben.68 Die Bezeichnung des in Beziehung gesetzten Kodiersystems kann auf
zwei Arten angegeben werden. Erstens ist das mit dem Attribut
RELATEDENCODING in <archdesc> möglich, dessen Wert von jedem
ENCODINGANALOG-Attribut in dem gesamten Findbuch geerbt wird.
<archdesc langmaterial="eng" level="collection“
"relatedencoding="marc">
<controlaccess>
<head>Themen</head>
<subject encodinganalog="650" source="lcsh">
Fischereirecht und -gesetze -- Minnesota.</subject>
</controlaccess>
</archdesc>
Wenn innerhalb von <archdesc> mehrere Kodiersysteme angegeben werden sollen,
kann der Name des jeweiligen Kodiersystems bei jedem Auftreten des
ENCODINGANALOG-Wertes kodiert werden. Ist MARC das in Beziehung gesetzte
Kodiersystem, ist der Wert für das ENCODINGANALOG-Attribut die betreffende
MARC-Feldnummer.
68
Anhang B enthält außerdem die Crosswalks von USMARC zu EAD.
118
<archdesc langmaterial="eng" level="collection">
<controlaccess>
<head>Themen</head>
<subject encodinganalog="marc650" source="lcsh">
Fischereirecht und -gesetze -- Minnesota </subject>
</controlaccess>
</archdesc>
<archdesc langmaterial="eng" level="collection">
<controlaccess>
<head>Zugriffsbegriffe</head>
<controlaccess>
<head>Themen</head>
<subject encodinganalog="marc650"
source="lcsh"> Fischereirecht und -gesetze -Minnesota </subject>
</controlaccess>
</controlaccess>
<dsc type="combined">
<c01 level="series" encodinganalog="isad3.1.4">
<did><unittitle>Korrespondenz</unittitle></did>
</c01>
</dsc>
</archdesc>
3.5.3.2. Personen-, Körperschafts- und Familiennamen sowie geografische
Namen <persname>, <corpname>, <famname>, <geogname> (Personal Name,
Corporate Name, Family Name, Geographic Name)
Findbücher enthalten zahlreiche Personen-, Körperschafts- und Familiennamen
sowie geografische Namen. Für jede dieser Namensarten gibt es ein entsprechendes
EAD-Element, das sich jeweils auf bestimmte MARC-Felder bezieht.
Das Element <persname> wird zur Bezeichnung des Eigennamens einer Person
verwendet, einschließlich mehrerer oder aller Vornamen, Nachnamen, Titel und
zusätzlichen Namen sowie Geburts- und Sterbedaten:
<persname encodinganalog="600" source="lcnaf">
Ferry, Dexter Mason, 1833-1907.</persname>
<persname encodinganalog="600" source="lcnaf"
role="correspondent">Mason, Darius.</persname>
Das Element <corpname> wird zur Bezeichnung des Eigennamens einer
Organisation oder einer Personengruppe verwendet, die als Einheit handelt.
Beispiele hierfür sind Namen von Gesellschaften, Institutionen, Handelsfirmen,
gemeinnützige Organisationen, Regierungen, Regierungsdienststellen, Projekten,
Programmen, religiösen Gremien, Kirchen, Konferenzen, Sportwettkämpfen,
Ausstellungen, Expeditionen, Fachmessen und Schiffen. Das Element <subarea>
kann, falls gewünscht, zur genauen Kodierung der untergeordneten Teile einer
Körperschaft verwendet werden. Es ist nicht erforderlich, das Attribut SOURCE
innerhalb des Elements <subarea> zu wiederholen:
119
<corpname encodinganalog="610" source="lcnaf"
role="subject"> University of Detroit.
<subarea encodinganalog="610">
Department of Chemistry. </subarea>
</corpname>
<corpname encodinganalog="610" source="lcnaf">
University of Detroit.
<subarea encodinganalog="610">Department of Mathematics.
</subarea>
</corpname>
Mit dem Element <famname> wird der Eigenname einer Personengruppe
bezeichnet, die einen Haushalt bildet oder untereinander eng verwandt ist,
einschließlich einzelner Familien und Familiengruppen:
<famname encodinganalog="600" source="lcnaf">
Patience Parker Familie.</famname>
<famname encodinganalog="600" source="lcnaf">
Parker Familie.</famname>
Mit dem Element <geogname> wird der Eigenname eines Ortes, einer Landschaft
oder eines politischen Zuständigkeitsbereichs bezeichnet:
<geogname encodinganalog="651" source="lcsh">
Chinatown (San Francisco, Calif.)</geogname>
<geogname encodinganalog="651" source="lcsh">
Appalachian Mountains.</geogname>
<geogname encodinganalog="651" source="lcsh">
Baltimore (Md.)</geogname>
Das Element <name> kann anstelle eines der vier spezifischen Namenselemente
verwendet werden, wenn nicht bekannt ist, welche Art von Name zu beschreiben ist,
wenn eine größere Genauigkeit nicht erforderlich oder es zu kostspielig ist oder wenn
es nicht zweckmäßig ist, die Kodierer für die Unterscheidung der genaueren
Namensarten zu schulen. <name> könnte z. B. in <indexentry> verwendet werden,
wenn es nicht klar ist, ob der Name „Bachrach“ sich auf eine Person oder ein
Fotografenunternehmen bezieht. <name> ist zwar technisch gesehen innerhalb von
<controlaccess> gültig; aufgrund der Unschärfe des Elements <name> und der darin
enthaltenen Daten ist <name> jedoch weit weniger geeignet als die spezifischeren
Eigennamenelemente.
3.5.3.3. Genre- und Formbegriffe <genreform> (Genre/Physical Characteristic)
Benutzer versuchen bisweilen, einen Einstieg zu Beständen über die Art der in ihnen
enthaltenen Unterlagen zu finden, in dem sie z. B. nach Tagebüchern, Fotografien
oder Ansichts- bzw. Grußkarten suchen. Das Element <genreform> wird zur
Kodierung solcher Unterlagenarten verwendet, indem Ausführung oder Technik ihres
Inhalts (Gattung), Informationsart oder Objektfunktion (Form) oder äußere Merkmale
bezeichnet werden:
<genreform encodinganalog="655" source="gmgpc">
Bauzeichnungen.</genreform>
<genreform encodinganalog="655" source="aat">
Fotografien. </genreform>
120
3.5.3.4. Funktion/Beruf <function> / <occupation>
Begriffe für Tätigkeitsbereiche und Organisationsprozesse, bei denen das Archivgut
entstand, werden in <function> kodiert. Solche Begriffe bieten oft nützliche Einstiege,
insbesondere bei Unterlagen von Körperschaften, Behörden oder Institutionen:
<function encodinganalog="657" source="aat">
Strafvollzug.</function>
<function encodinganalog="657" source="aat">
Verurteilung.</function>
Begriffe für Tätigkeiten, Berufe, Gewerbe, Geschäftsführung oder
Nebenbeschäftigungen, die in den Materialien in bedeutendem Umfang eine Rolle
spielen, kodiert man in <occupation>:
<occupation encodinganalog="656" source="aat">
Dramaturgen. </occupation>
<occupation encodinganalog="656" source="aat">
Bibliothekare. </occupation>
3.5.3.5. Gegenstand <subject> / <title>
Findbücher enthalten weit und eng gefasste Begriffe zur Bezeichnung von Themen,
mit denen die beschriebenen Materialien zusammenhängen oder die in ihnen
behandelt werden. Diese werden in <subject> kodiert. Es ist jedoch zu beachten,
dass Personen-, Körperschafts- und Familiennamen sowie geografische Namen, die
Thema der Unterlagen sind, als <persname>, <corpname>, <famname> bzw.
<geogname> ausgezeichnet werden. In solchen Fällen kann das Attribut ROLE den
Wert "subject" gestellt werden, um anzugeben, dass ein Name einen thematischen
Bezug zu den Materialien hat (eine andere Möglichkeit besteht darin, mit
ENCODINGANALOG das betreffende MARC-Feld anzugeben):
<subject encodinganalog="650" source="lcsh">
Ausländer- und Volksverhetzungsgesetze, 1798.</subject>
<subject encodinganalog="650" source="lcsh">
Freiwilliges Exil der Amerikanischen Konföderation,</subject>
<persname encodinganalog="600" source="lcnaf" role="subject">
Williams, Robert Franklin, 1925- </persname>
In vielen Findbüchern kommen formale Bezeichnungen von Werken, z. B.
Monografien, Reihen oder Gemälden vor. Zum Kodieren solcher Informationen kann
<title> verwendet werden. Das Attribut RENDER in <title> ist besonders nützlich, um
anzugeben, wie ein Titel dargestellt werden soll, z. B. in Kursivdruck oder in
Anführungszeichen. Titel, die Thema von Briefen oder anderen Materialien eines
Bestandes sind, sind als <title> mit dem Attribut ROLE (mit dem Wert „subject”) zu
kodieren. Untertitel solcher Werke werden nicht gesondert kodiert. In <date>
innerhalb von <title> kann ein Erscheinungsjahr kodiert werden.
<title encodinganalog="630" role="subject" render="italic">
Huckleberry Finn</title>
<title> darf nicht für die gebildeten Titel von Verzeichnungseinheiten, z. B. Serienoder Aktentiteln, verwendet werden. Dafür ist <unittitle> das richtige Element.
121
3.5.3.6. Gruppierte Begriffe aus kontrolliertem Vokabular
Schlagwörter und erklärender Text können unter Verwendung von <head>, <note>
und <p> in <controlaccess> aufgenommen werden. Mehrere Formatierungselemente
wie <list>, <table> und <blockquote> sind ebenfalls verfügbar. Es ist jedoch auch
möglich (und oft auch besser), die Darstellung eines Blocks von Zugriffsbegriffen
über ein Stylesheet zu steuern.
Das Element <controlaccess> ist rekursiv. Dadurch können geschachtelte
Zugriffsbegriffe in Einheiten gruppiert und gekennzeichnet werden, die für Nutzer in
ein Online-Umgebungen hilfreich sein können. Ein Archiv entscheidet sich z. B.
dafür, Begriffe entsprechend äquivalenter MARC-Felder zu gruppieren (600:
Personennamen, 650: Themen, 655: Form und Gattung). Wenn das Archiv
gesonderte MARC-Titelaufnahmen für verschiedene Formate von Materialien erstellt,
die innerhalb eines Bestandes in verschiedenen Serien oder anderen Gruppen, z. B.
Fotografien oder Tonaufnahmen, angeordnet sind, können gesonderte,
geschachtelte <controlaccess>-Elemente zur Gruppierung der Begriffe für jede
einzelne Unterlagenart geöffnet werden. Das folgende Beispiel zeigen
Gruppierungen von <controlaccess>-Begriffen auf der Grundlage von äquivalenten
MARC-Feldern:
<controlaccess>
<head>Zugriffsbegriffe</head>
<controlaccess>
<head>Personennamen</head>
<persname encodinganalog="600" source="lcnaf">
Anderson, Jane, 1929-1937.</persname>
<persname encodinganalog="600" source="lcnaf">
Smith, Charles Spencer, 1852-1923.</persname>
</controlaccess>
<controlaccess>
<head>Organisationen</head>
<corpname encodinganalog="610" source="lcnaf">
African Methodist Episcopal Church.</corpname>
</controlaccess>
<controlaccess>
<head>Themen</head>
<subject encodinganalog="650" source="lcsh">
Klerus -- USA.</subject>
<subject encodinganalog="650" source="lcsh">
Ausbildung -- USA.</subject>
</controlaccess>
<controlaccess>
<head>Beiträge von:</head>
<persname encodinganalog="700" source="lcnaf">
Smith, Charles S. (Charles Spencer), Jr.</persname>
<persname encodinganalog="700" source="lcnaf">
Smith, Christine Shoecraft.</persname>
</controlaccess>
<controlaccess>
<head>Materialformen</head>
<genreform encodinganalog="655" source="aat">
Fotografien.</genreform>
</controlaccess>
</controlaccess>
122
3.5.3.7. Kontrolliertes Vokabular außerhalb von <controlaccess>
Wie bereits erwähnt, wird normalerweise nur ein kleiner Teil der in einem Bestand
vorhandenen Namen und Themen in <controlaccess> kodiert. Normalerweise sind es
die als besonders wichtig angesehenen Namen bzw. Themen. EAD ermöglicht auch
das Indizieren mit großer Detailtiefe außerhalb von <controlaccess>, und alle zehn
oben behandelten Elemente für Zugriffsbegriffe sind in verschiedenen textbezogenen
Elementen, darunter auch in <p>, verfügbar. Namen, Themen, Genre- und
Formbegriffe und andere Begriffe können in direkter Reihenfolge der natürlichen
Sprache in Fließtext getaggt werden, und wo es erwünscht ist, kann zusätzlich mit
dem Attribut NORMAL eine in einem kontrollierten Vokabular enthaltene Version des
Namens bzw. Begriffs für Recherchezwecke angegeben werden.
Das folgende Beispiel zeigt die In-Depth-Auszeichnung von Namen, Themen sowie
Genre- und Formbegriffen in einer Bemerkung zur Entstehungsgeschichte und eines
Bestandsverzeichnisses:
123
<archdesc level="collection">
<bioghist>
<p><persname normal="Winchell, Alexander">Alexander
Winchell</persname> war Professor für <subject>
Geologie</subject> und <subject>Paläontologie
</subject> an der <corpname>University of Michigan
</corpname>, Leiter des <corpname>Michigan
Geological Survey</corpname> und Kanzler der
<corpname>Syracuse University</corpname>, am
bekanntesten war er jedoch als beliebter Dozent und
Schriftsteller für wissenschaftliche Themen sowie
als Methodist, der daran arbeitete, traditionelle
religiöse Glaubensinhalte mit den Entwicklungen des
19. Jhdts. auf den Gebieten der
<subject>Evolutionsbiologie</subject>,
<subject>Kosmologie</subject>, <subject>
Geologie</subject> und <subject>Paläontologie
</subject> in Einklang zu bringen.
... </p>
</bioghist>
<dsc type="in-depth">
<c01 level="series">
<did>
<unittitle><genreform
normal="diaries">Berichte
über geologische Expeditionen und
Reisen</genreform> </unittitle>
</did>
<c02>
<did>
<container>23</container>
<unittitle>Expedition zum
<geogname>Lake Superior
</geogname><unitdate>1867</un
itdate>
</unittitle>
</did>
</c02>
<c02>
<did>
<container>23</container>
<unittitle>Exkursion nach
<geogname>Neuengland
</geogname><unitdate>18671868</unitdate> </unittitle>
</did>
</c02>
</c01>
</dsc>
</archdesc>
124
Bis jetzt besteht noch kein Konsens über Nutzen und Zweckmäßigkeit einer derart
ausführlichen Auszeichnung von Eigennamen in narrativen Teilen und dem
Bestandsverzeichnis von Findbüchern. Zum Spektrum der Praxis gehören:
•
•
•
•
Auszeichnung jedes Auftretens und jeder Variante von Personen- und
Körperschaftsnamen
Auszeichnung eines Auftretens jedes Namens in einem Findbuch
Auszeichnung nur der Namen, die häufig in einem Bestand vorkommen
Keine Auszeichnung von Namen außerhalb von <controlaccess>
Einige Institutionen kodieren Zugriffsbegriffe, ohne das Attributs NORMAL für die
standardisierte Version des Namens. Sie überlassen es statt dessen den
Suchmaschinen, Kombinationen von Vor- und Zunamen in einem einzigen Tag zu
finden, oder zwingen Benutzer, bei der Suche nach verschiedenen Versionen eines
Namens kreativ zu sein. Wird ein Name bei jedem Auftreten getaggt, kann dies
Benutzer bzw. die Suchmaschine, die Treffer melden, sogar verwirren. Das häufige
Auftreten eines Namens in einer Kurzbiografie kann z. B. die Vermutung nahe legen,
dass ein Bestand stärker in Bezug auf einen Suchbegriff relevant ist, als es bei der
Gesamtsubstanz des Bestandes wirklich der Fall ist. Oder es geschieht das
Entgegengesetzte: ein Bestand mit vielen Informationen zu einer Persönlichkeit wird
in den Suchergebnissen zu niedrig bewertet, weil diese Persönlichkeit nur mit den
Anfangsbuchstaben ihres Namens und nicht mit ihrem vollen Namen bezeichnet wird
oder weil ihr Name in einem großen Teil des Findbuchs implizit enthalten ist.
Der Wert der Kodierung von Zugriffsbegriffen innerhalb von narrativen Teilen und
den Bestandsverzeichnissen von Findbüchern ist eine Frage, deren Klärung weitere
Forschungsarbeiten zur Bedürfnissen und Suchstrategien von Benutzern, den
Fähigkeiten von Suchmaschinen und den Fortschritten von Recherchen in natürlicher
Sprache erforderlich sind. Letztlich muss jede Institution eigene Verfahren
entwickeln, bis zu welcher Ebene sie Zugriffsbegriffe außerhalb von <controlaccess>
auszeichnen will, und zwar auf der Grundlage der derzeit angewandten Verfahren,
des Wertes eines Bestandes für die Benutzung und des verfügbaren Personals. Ist
es wichtiger, wenige Findbücher mit großer Detailtiefe zu kodieren oder zahlreiche
Findbücher online zur Verfügung zu stellen, bei denen weniger Zugriffspunkte kodiert
sind?
3.5.4. Zusätzliche Erschließungsangaben <add> (Adjunct Descriptive Data)
Häufig versehen Archivare Findbücher mit zusätzlichen Zugriffswerkzeugen, die
einen Bestand u. U. nicht so direkt beschreiben wie mit Hilfe von <scopecontent>
oder anderen <archdesc>-Elementen. Zu solchen Werkzeugen gehören Aktenpläne,
Bibliografien, Indizes und Listen von ähnlichen oder dem Bestand entnommenen
Materialien. Das Element Adjunct Descriptive Data <add> ist ein Hüllenelement für
solche Informationen. Es steht in <archdesc> und auch in <c> zur Verfügung, um
eine Anordnung solcher Informationen auf beliebiger Ebene zu ermöglichen. Die
<add>-Subelemente sind nachstehend aufgeführt:
125
•
•
•
•
•
•
Bibliographie <bibliography> (Bibliography)
Aktenplan <fileplan> (File Plan)
Index <index> (Index)
Verweis auf andere Findbücher <otherfindaid> (Other Finding Aid)
Ähnliches Material <relatedmaterial> (Related Material)
Separiertes Material <separatedmaterial> (Separated Material)
Innerhalb jedes dieser Subelemente stehen allgemeine textbezogene
Auszeichnungsmöglichkeiten, z. B. Bibliographischer Nachweis <bibref> Block Quote
<blockquote>, Kopfzeile/Überschrift <head>, Liste <list>, Absatz <p> und Tabelle
<table> zur Verfügung. Bezieht sich ein Werkzeug auf das gesamte Findbuch, ist es
am Ende von <archdesc> nach allen <c> zu kodieren. Bezieht es sich jedoch nur auf
eine Komponente, kann es innerhalb des betreffenden <c> eingefügt werden. Ein
Aktenplan kann sich beispielsweise auf alle Komponenten eines Findbuchs, ein
Index von Briefautoren jedoch nur auf eine Serie von Briefen beziehen.
3.5.4.1. Bibliografien <bibliography> (Bibliographies)
Findbücher können Verweise auf Werke jeder Art enthalten, z. B. Bücher, Artikel,
Fernseh- oder Rundfunksendungen oder Webseiten, enthalten, die im
Zusammenhang mit der Benutzung der Materialien von besonderem Interesse sein
könnten, oder die von den Materialien handeln oder sich darauf stützen. Zur
Gruppierung solcher Angaben kann das Element <bibliography> verwendet werden.
Es enthält wiederum Subelemente für Textformatierungen (<list>, <table>),
Verlinkungen (<archref>, <extref>) oder einfach fortlaufenden Text (<p>). Innerhalb
von <bibliography> ermöglicht <bibref> das Taggen von Informationen zu
Veröffentlichungen (<edition>, <imprint>) sowie zu Zugriffspunkten (<persname>,
<corpname>).
<bibliography>
<head>Bibliographie</head>
<bibref><title>Jahresberichte</title>.
New York: National Association for the Advancement of
Colored People. 1910- .</bibref>
<bibref>Finch, Minnie. <title>The NAACP, Its Fight
for Justice</title>. Metuchen, N.J.: Scarecrow Press, 1981.
</bibref>
<bibref>Hughes, Langston. <title>Fight for Freedom:
The Story of the NAACP</title>. New York: Norton,
1962.</bibref>
</bibliography>
3.5.4.2. Aktenplan <fileplan> (File Plans) und und Verweis auf andere
Findbücher und <otherfindaid> (Other Finding Aids)
In den Archiven von Körperschaften und Behörden werden oft
Klassifizierungsschemata angewendet, die zum Ordnen, Lagern und Recherchieren
von Materialien entwickelt wurden. Das Element <fileplan> kann zum Kodieren von
Aktenplänen verwendet werden, die von den ursprünglich für die Erstellung oder
Zusammenstellung der Materialien verantwortlichen Personen oder Organisationen
verwendet wurden.
126
<fileplan>
<head>Dateiindex - Central Records - Irvine Campus</head>
<note><p>7. Änderung: März 1985</p></note>
<table>
<tgroup cols="2">
<tbody>
<row>
<entry>100-149</entry>
<entry>Universitätsangelegenheiten</entry>
</row>
<row>
<entry>150-299</entry>
<entry>Personal</entry>
</row>
<row>
<entry>300-399</entry>
<entry>Verwaltungsmaßnahmen
und -vorgänge</entry>
</row>
[...]
</tbody>
</tgroup>
</table>
</fileplan>
Mit dem Element <otherfindaid> werden zusätzliche oder alternative Findmittel zu
den betreffenden Materialien benannt, z.B. Karteien, Listen von Gebern oder
Händlern oder vom Nachlassgeber/Sammler der Materialien erstellte Listen. Dieses
Element weist lediglich auf das Vorhandensein solcher Werkzeuge außerhalb des
Findbuchs hin, es wird jedoch nicht zur Kodierung von deren Inhalten verwendet.
<otherfindaid>
<p>Die Kartei des Nachlassgebers, die die
Erschließungsangaben der Einzelstücke enthält, befindet sich
in Kiste 16.</p>
</otherfindaid>
3.5.4.3. Indizes <index> (Indexes)
Das Element <index> dient zum Kodieren von Listen mit Schlüsselbegriffen und
Zeigern, die erstellt wurden, um den Einstieg in die Materialien zu erleichtern. In
einigen Fällen sind Begriffe und Namen, die an anderen Stellen des Findbuchs zu
finden sind, einfach in <index> zusammengestellt. <index> kann auch der einzige Ort
sein, wo der Name oder Begriff zu finden ist, z. B wenn die Briefe in einer Akte mit
dem Titel „Briefe, R-T“ enthalten sind und die Namen der einzelnen Verfasser nicht
eigens im Bestandsverzeichnis genannt sind. Innerhalb von <index> enthält
<indexentry> die gleichen Zugriffselemente, die in <controlaccess> zur Verfügung
stehen und dazu dienen können, Ansetzungsinformationen in den Index
aufzunehmen, und zwar über die Attribute SOURCE und ENCODINGANALOG
(siehe Abschnitt 3.5.3.1). Ein leeres Verknüpfungselement, <ptr>, und <ref>, ein
Verknüpfungselement, das auch Text enthalten kann, können Benutzer ebenfalls zur
richtigen Akte im Bestandsverzeichnis führen (weitere Angaben zu diesen
Verknüpfungselementen siehe Abschnitt 7.2.1).
127
<index>
<head>Index der Briefautoren</head>
<indexentry>
<corpname>A.P. Watt & Son</corpname>
<ref>47.5</ref>
</indexentry>
<indexentry>
<corpname>Abbey Theatre</corpname>
<ptrgrp>
<ref>47.5</ref>
<ref>55.5</ref>
</ptrgrp>
</indexentry>
<indexentry>
<persname>Achurch, Janet</persname>
<ptrgrp>
<ref>32.5</ref>
<ref>32.6</ref>
</ptrgrp>
</indexentry>
<indexentry>
<persname>Adam, Ronald, 1896-1979</persname>
<ref>32.4</ref>
</indexentry>
<indexentry>
<corpname>American Mercury</corpname>
<ref>47.6</ref>
</indexentry>
</index>
3.5.4.4. Ähnliche bzw. separierte Materialien <relatedmaterial> und
<separatedmaterial>
Im Rahmen der Bearbeitung eines Bestandes erstellen Archivare oft Listen von
Unterlagen, die kassiert oder einer anderen Institution (z. B. einer gesondert
verwalteten fotografischen Abteilung) zugeleitet wurden. Außerdem kann das Archiv
eine Liste von Beständen bereitstellen, die sich mit ähnlichen Themen befassen,
Materialien von gleichem Format enthalten oder aus dem gleichen geografischen
Gebiet oder der gleichen politischen oder sozialen Ära stammen. EAD unterscheidet
zwischen an anderen Orten gelagerten Materialien, die aufgrund ihre Provenienz mit
den beschriebenen Materialien verwandt bzw. nicht verwandt sind.
Mit dem Element <relatedmaterial> werden Informationen zu Materialien kodiert, die
weder konkret noch logisch zu den in dem Findbuch beschriebenen Materialien
gehören noch durch Provenienz, organisches Anwachsen der Bestände oder
Nutzung mit diesen in Bezug stehen, jedoch trotzdem für einen Benutzer von
Interesse sein könnten. Eine Liste ähnlicher Materialien könnte auch andere
Bestände umfassen, die in demselben Archiv oder in anderen Archiven aufbewahrt
werden.
128
<relatedmaterial>
<head>Ähnliches Material</head>
<p>Schriften bedeutender NAACP-Aktivisten und Unterlagen von
NAACP-Abteilungen und -Angehörigen sind nachstehend
aufgeführt.</p>
<relatedmaterial>
<head>Sammlung von Personalunterlagen</head>
<archref>Ella Baker. State Historical Society of
Wisconsin, Archives Division (Papers, 19591965).</archref>
<archref>Mary McLeod Bethune. Dillard University,
Amistad
Research Center (Papers, 1923-1942).</archref>
<archref>W.E.B. Du Bois. New York Public Library,
Schomburg Center for Research in Black Culture
(Papers, 1912-1966, Hauptteil 1942-1948). </archref>
<archref>William Hastie. Harvard University, Law
School Library (Papers, 1916-1976, Hauptteil 19371976).</archref>
<archref>Thurgood Marshall. Library of Congress,
Manuscript Division (Papers, 1949-1991, Bulk 19611991).</archref>
</relatedmaterial>
<relatedmaterial>
<head>NAACP Abteilung und andere Unterlagen</head>
<archref>NAACP Legal Defense and Education Fund.
Library of Congress, Manuscript Division.</archref>
<archref>NAACP Cleveland Branch. Western Reserve
Historical Society. (Records, 1924-1967).</archref>
<archref>NAACP Montgomery Branch. New York Public
Library, Schomburg Center for Research in Black
Culture. (Minutes, 1954-1955).
</archref>
</relatedmaterial>
</relatedmaterial>
Das Element <separatedmaterial> dient dagegen der Kodierung von Angaben zu
Materialien, die aufgrund ihrer Provenienz eine Beziehung zu den in dem Findbuch
beschriebenen Unterlagen haben, jedoch entweder vom Archiv oder von einer
anderen Stelle physisch getrennt wurden, und zwar entweder vor oder nach der
Übernahme durch das Archiv.
<separatedmaterial>
<head>Gesondert katalogisierte Materialien</head>
<list>
<item>Ausgewählte Druckwerke wurden in den Buchbestand der
Bancroft Library überführt.</item>
<item>Fotografien wurden in den Bildbestand der
Bancroft Library überführt.</item>
<item>Filme und Tonaufnahmen wurden in die Microforms
Division der Bancroft Library überführt.</item>
<item>Ausgewählte Landkarten wurden in den Kartenraum
überführt.</item>
</list>
</separatedmaterial>
129
3.5.5. Erschließungsangaben, die in keine bestimmte Kategorie fallen: Sonstige
Erschließungsangaben <odd> (Other Descriptive Data )
Die Entwickler von EAD konnten nicht für jede Art von Informationen, die ggf. in den
Findbüchern verschiedener Institutionen – insbesondere im internationalem Rahmen
– zu finden sind, ein spezifisches Element festlegen. Außerdem schien es
zweckmäßig, ein allgemeines Mehrzweckelement zu schaffen, um die Konversion
alter Findbücher zu erleichtern, bei denen es ohne umfangreiche Neustrukturierung
nicht möglich gewesen wäre, bestimmte Informationen voneinander abzugrenzen,
die zweckmäßiger mit EAD-Elementen wie <bioghist>, <scopecontent> oder
<admininfo> zu kodieren wären, wie das nachstehende Beispiel zeigt.
Das Element Sonstige Erschließungsangaben <odd> wurde für solche Fälle
geschaffen. Es wird jedoch empfohlen, wenn immer möglich, Informationen mit Hilfe
spezifischer Elemente zu kodieren, da es bei der Verwendung von <odd> zu
unspezifischen Auffindungs- bzw. Darstellungsergebnissen mit nachteiligen Folgen
kommen kann.
<odd>
<p>Annie Montague Alexander, Förderin der University of
California, gründete 1908 das Museum of Vertebrate Zoology und
stattete es mit einer Stiftung aus. Diese Schriften, die das
Museum 1965 an die Bancroft Library übergab, bestehen
hauptsächlich aus Briefen von Joseph Grinnell, dem ersten
Direktor des Museums. In den Schriften werden Pläne zu seiner
Gründung sowie Sammlungsgrundsätze, Personal, Ausgaben,
Feldstudien usw. behandelt. Es sind auch einige Briefe von
leitenden Universitätsangehörigen und anderen Mitgliedern des
Museumspersonals sowie verschiedene Briefe von
Regierungsbeamten, Sammlern und Händlern vorhanden, die Miss
Alexanders Interesse am Sammeln zoologischer Präparate zeigen.
Verwandte Materialien sind in den offiziellen Unterlagen des
Museums enthalten, die zum gleichen Zeitpunkt an das
University Archives übergeben wurden.</p>
<p>Weitere, im Feb. 1967 übernommene Schriften haben die
Bestellnummer 67/121c erhalten.</p>
</odd>
130
3.6. Hinzufügen von Metadaten zum Findbuch
Die Elemente, mit denen ein Archivgutkomplex beschrieben wird (der Text des
Findbuchs) sind in <archdesc> gebündelt. In einer Online-Umgebung ist es auch
wichtig, Metadaten aufzunehmen, mit denen das Findbuch selbst am Anfang der
elektronischen Datei beschrieben wird. Es kann auch erwünscht sein, eine Titelseite
und einleitende Informationen zum Findbuch aufzunehmen. EAD deckt diesen
Bedarf mit <eadheader> bzw. <frontmatter>. Der Inhalt der beiden Elemente bezieht
sich auf das Findbuch an sich und nicht auf die darin beschriebenen archivischen
Materialien.
3.6.1. EAD-Header <eadheader>
In der Papierumgebung war es nicht immer notwendig, formelle Beschreibungsdaten
über das Findbuch in ein Findbuchdokument aufzunehmen. Derartige Informationen
sind jedoch eine zentrale Komponente eines EAD-Findbuchs, das in einer
maschinenlesbaren Umgebung steht. Das Element <eadheader> umfasst
verschiedene Metadaten zum Findbuch, die der eindeutigen Bezeichnung jeder
einzelnen EAD-Instanz dienen, und zwar mit Hilfe eines eindeutigen
Identifizierungskodes für das Dokument, bibliografischer Informationen (z. B.
Ersteller, Titel und Herausgeber des Findbuchs) und durch den Nachweis wichtiger
Überarbeitungen der EAD-Datei. Das Element <eadheader> und mehrere seiner
Subelemente sind vorgeschrieben, und die einheitliche Erfassung der Informationen
in einigen dieser Elemente ist äußerst wichtig.
Das Element <eadheader> wurde nach dem Header-Element der Text Encoding
Initiative (TEI)69 gestaltet, um bei den Metadaten verschiedener Dokumentarten
Einheitlichkeit zu fördern. Die Reihenfolge der Elemente richtet sich nach der EADDTD, wobei davon ausgegangen wird, dass, wenn alle Ersteller von Findbüchern
eine einheitliche Reihenfolge der Metadatenelemente einhalten, die Suche nach
Findbuchtitel, Datum, Sprache oder Archiv genauere Ergebnisse liefert. Daher ist
<eadheader> ein vorgeschriebenes Hüllenelement mit vier Subelementen, die in
folgender Reihenfolge erscheinen müssen: <eadid>, <filedesc>, <profiledesc> und
<revisiondesc>.
Zusätzlich hat <eadheader> einige wichtige Attribute:
•
•
•
Das Attribut AUDIENCE ist auf "internal" zu setzen, sofern nicht die
Informationen im Header zur Erzeugung einer öffentlichen Darstellung
verwendet werden sollen, z. B. in Form einer Titelseite für das Findbuch.
Der Bearbeitungsstand des Findbuchs kann mit dem Attribut
FINDAIDSTATUS angezeigt werden, das auf "unverified-partial-draft"
(ungeprüft – Teilentwurf), "unverified-full-draft" (ungeprüft – vollständiger
Entwurf) oder "edited-full-draft" (bearbeitet – vollständiger Entwurf) gesetzt
werden kann.
Für das Element <eadheader> kann ein Attribut ENCODINGANALOG
unabhängig von demselben Attribut innerhalb von <archdesc> angegeben
werden, da auf diese Weise die Header-Informationen besser auf eine Gruppe
von Metadatenelementen abgestimmt werden können, die speziell dazu
69
Die Text Encoding Initiative ist ein internationales Projekt mit geisteswissenschaftlichem Hintergrund mit dem Zweck, eine
Serie von DTDs zur Kodierung von literarischen oder wissenschaftlichen Texten zu entwickeln, die Gegenstand von Studien
sein könnten, vgl. <http://www.uic.edu/orgs/tei/p3/doc/p3.html> (A.d.Ü.: Webseite nicht mehr existent).
131
•
dienen, im Internet nach elektronischen Ressourcen zu suchen, z. B. Dublin
Core, MARC oder ISAD(G).
Für die Sprachkodierung von EAD-Instanzen werden die in ISO 639-2
festgelegten „Codes for the Representation of Names of Languages“
verwendet. Das Attribut LANGENCODING ist stets auf "ISO 639-2" zu setzen.
Ein <eadheader>-Start-Tag mit vollständiger Inhaltsbezeichnung für diese Attribute
könnte so aussehen:
<eadheader audience="internal" encodinganalog="Dublin Core"
findaidstatus="edited-full-draft" langencoding="ISO 639-2">
Da mit <eadheader> die bibliographischen Angaben zum Findbuch vollständ erfasst
werden, kann damit auch eine Titelseite für das Findbuch erzeugt werden. Es muss
jedoch stets berücksichtigt werden, dass die Reihenfolge, in der die Elemente kodiert
werden, nicht beliebig ist und Stylesheets u. U. nicht fähig sind, die Elemente für die
Ausgabe umzuordnen. Wird eine ansprechend formatierte Titelseite mit in
bestimmter Reihenfolge dargestellten bzw. ausgedruckten Informationen gewünscht,
ist dazu das Element <titlepage> unter <frontmatter> zu verwenden (siehe Abschnitt
3.6.2).
Ein Beispiel für ein vollständig kodiertes <eadheader> enthält Abschnitt 3.6.1.5.
3.6.1.1. EAD-Identifikator <eadid> (EAD-Unique File Identifier)
Das Element <eadid> ist ein vorgeschriebenes Subelement von <eadheader>, mit
dem eine eindeutige Identifikation für eine EAD-Instanz angegeben wird. Der Aspekt
der „Eindeutigkeit“ ist sehr wörtlich gemeint. Denn der in jedem <eadid>-Element
enthaltene Wert muss sich von allen anderen <eadid> in anderen Findbüchern
unterscheiden, damit sich jede elektronische Datei von allen anderen unterscheidet.
Dies soll nicht nur innerhalb der Bezeichnungskonventionen einer bestimmten
Institution gelten, sondern idealerweise für sämtliche Findbücher, die irgendwann in
einem institutionenübergreifenden Verbundkatalog vereinigt werden.
Dieser eindeutige Identifikator kann vollständig im Text des <eadid>-Elements oder
als Kombination des Elementtextes und eines Wertes des Attribut SYSTEMID, mit
dem das Archiv bezeichnet wird, kodiert werden. Auf diese Weise kann eine spezielle
Bezeichnung, z. B. „M32“, die von mehreren Archiven verwendet werden kann, durch
das Hinzufügen einer Institutionsbezeichnung im Attribut, z. B. dem im NUC (National
Union Catalog) verzeichneten Symbol für ein US-amerikanisches Archiv, eindeutig
gemacht werden.
In <eadid> können folgende drei Kategorien von Bezeichnungen verwendet werden:
•
•
•
Lokale Identifikatoren,
Namen von elektronischen Dateien,
SGML-Katalogeinträge.
Lokale Identifikatoren, wie Signaturen, werden am besten in Verbindung mit einer
örtlichen Identifikation im Attribut SYSTEMID verwendet.
132
Dateinamen können entweder in Form eines Uniform Resource Identifier* (URI) oder
einer Bezeichnung wie z. B. ein Purl (Persistent Uniform Resource Locator)
verwendet werden. (Probleme im Zusammenhang mit der Bezeichnung von Dateien
siehe Abschnitt 5.4).
Die dritte Option besteht in einer SGML-Katalogdatei, die die EAD-Instanz auf
gleiche Weise bezeichnet, wie eine allgemeine externe Entität zitiert wird (weitere
Informationen zu Entitäten siehe Abschnitt 6.5). Das schließt die Verwendung eines
Formal Public Identifier (FPI) ein, der als Form einer SGML-Zitatation betrachtet
werden kann. Die Option mit der SGML-Katalogdatei hat zwei Vorteile. Erstens
enthält der Elementtext ausreichende Informationen, um den in dem Findbuch
beschriebenen Bestand eindeutig zu bezeichnen, anstatt lediglich eine nicht
eindeutige Nummer oder einen nicht eindeutigen Dateinamen anzugeben. Zweitens
kann die SGML-Entität über einen Eintrag in einer externen SGML-Katalogdatei mit
der Speicherstelle im Rechner verknüpft werden. Auf diese Weise braucht ein
aktueller Dateiname, der sich im Laufe der Zeit ändern kann, nicht in der EADInstanz „fest verdrahtet“ oder in sie eingebettet zu werden. Damit wird es unnötig, die
einzelnen Findbücher zu aktualisieren, wenn sich Namen oder Speicherstellen von
EAD-Dateien ändern.70 Leider erkennt XML das SGML-Katalogkonzept nicht. Daher
gilt der Wert einer Katalogdatei als Surrogat für einen spezifischen Dateinamen im
<eadid> (oder für eine beliebige Entitätsreferenz) nicht für XML-Systeme.
3.6.1.2. Dateibeschreibung <filedesc> (File Description)
Bibliografische Informationen zum Inhalt des kodierten Findbuchs sind im
vorgeschriebenen Element <filedesc> gebündelt, in dem Titel, Untertitel, Provenienz
und Herausgeber des Findbuchs in einer Reihe von Subelementen kodiert sind.
Das vorgeschriebene Subelement <titlestmt> schließt u. U. Titel und Untertitel des
kodierten Findbuchs, den Namen der Herkunftsstelle und den Namen des
Auftraggebers (in dieser Reihenfolge) ein. Das vorgeschriebene Element
<titleproper> innerhalb von <titlestmt> sollte ein formaler Titel des Findbuchs selbst
sein, z. B. „Bestandsverzeichnis des Nachlasses von Tom Stoppard im Harry
Ransom Humanities Research Center” oder „Nachlass Tom Stoppard, 1944-1995:
Ein Bestandsverzeichnis seiner Unterlagen im Harry Ransom Humanities Research
Center”.71 Das Element <titleproper> hat mehrere Attribute. Die nützlichsten darunter
sind vielleicht EXTENT und PUBSTATUS. Das Attribut EXTENT gibt an, ob das
Findbuch alle Materialien oder nur einen Teil davon beschreibt, während
PUBSTATUS einen Hinweis darauf enthält, ob das Findbuch veröffentlicht wurde
oder nicht. Ein vollständig kodiertes <titlestmt> könnte so aussehen:
*
A.d.Ü.: = einheitlicher Bezeichner für Ressourcen.
Eine Beschreibung des Aufbaus von Formal Public Identifier (FPI) zur Verwendung in einem SGML-Katalog für das American
Heritage Virtual Library Project und das Online Archive of California findet sich in Encoded Archival Description Retrospective
Conversion Guidelines. A Supplement to the EAD Tag Library and EAD Guidelines,
<http://sunsite.berkeley.edu/amher/upguide.html>.
71
Es ist unbedingt zu beachten, dass ein solcher Titel für das Findbuch selbst von dem Titel für den archivischen Bestand, der
in <did><unittitle> kodiert ist, abweicht. (siehe Abschnitt 3.5.1.1).
70
133
<titlestmt>
<titleproper pubstatus="pub" extent="all">Nachlass Tom
Stoppard, 1944-1995</titleproper>
<subtitle> Ein Bestandsverzeichnis seiner Unterlagen im
Harry Ransom Humanities Research Center </subtitle>
<author>Findbuch erstellt von K. Mosley</author>
</titlestmt>
Weitere bibliografische Elemente innerhalb von <filedesc> sind <editionstmt>,
<publicationstmt>, <seriesstmt> und <notestmt>, die in der angegebenen
Reihenfolge verwendet werden müssen. Alle sind optional und werden von vielen
Archiven selten oder nie benutzt.
Institutionen können sich nur selten den Luxus leisten, mehr als eine Auflage eines
Findbuchs herauszugeben. Wenn jedoch zusätzliche Materialien übernommen und in
den Bestand eingegliedert werden und das Findbuch daher erweitert und aktualisiert
werden muss, bietet <editionstmt> die Möglichkeit, Informationen zur Auflage des
Findbuchs aufzunehmen. Die Leichtigkeit, mit der Findbücher im Web veröffentlicht
und überarbeitet werden können, regt vielleicht zu häufigeren Aktualisierungen oder
neuen Versionen an.
In einer Papierumgebung haben die Archive ihre Findbücher u. U. nicht als
„veröffentlicht“ betrachtet, da sie normalerweise in Aktenschränken und -ordnern im
Archiv standen. In der Internet-Umgebung werden Findbücher jedoch als
Veröffentlichungen angesehen. Das Element <publicationstmt> enthält Informationen
zur Veröffentlichung oder Verbreitung des kodierten Findbuchs und kann Name und
Anschrift des Archivs, das Datum der Veröffentlichung und andere einschlägige
Angaben umfassen. Der vollständige Text von <publicationstmt> kann in <p> stehen,
oder die Informationen können mit Hilfe von <publisher>, <address> und <date>
genauer kodiert werden:
<publicationstmt>
<p>Harry Ransom Humanities Research Center, 1996</p>
</publicationstmt>
<publicationstmt>
<publisher>Harry Ransom Humanities Research Center,
</publisher>
<date type="publication">1996</date>
</publicationstmt>
Jedes Auszeichnungsverfahren ist gleichermaßen gültig. Es darf jedoch nicht
vergessen werden, dass eine spezifische Inhaltsbezeichnung die Flexibilität bei der
Verarbeitung der Daten erhöht.
Wird das kodierte Findbuch als Teil einer Publikationsreihe veröffentlicht, kann diese
Information in <seriesstmt> kodiert werden. Wie <publicationstmt> kann auch <p>
anstelle von spezifischen Elementen verwendet werden, oder der Titel der Serie
kann spezifisch mit <titleproper> und die Seriennummerierung mit <num> kodiert
werden:
134
<seriesstmt>
<p>Stuffatoria unite, vol. 65</p>
</seriesstmt>
<seriesstmt>
<titleproper>Stuffatoria unite, </titleproper>
<num>vol. 65</num>
</seriesstmt>
Das Element <notestmt> kann eine Reihe von <note>-Elementen enthalten, die
jeweils ein Stück beschreibende Information zum Findbuch enthalten. Diese
Verwendung von <note> unterscheidet sich von derjenigen in <did>, wo <note> für
erläuternde und nicht für beschreibende Texte zu den betreffenden archivischen
Materialien bestimmt ist.
3.6.1.3. Kodierung <profiledesc> (Profile Description)
Während <filedesc> bibliografische Informationen zum intellektuellen Inhalt des
Findbuchs enthält, sind in <profiledesc> Informationen zur Erstellung der kodierten
Version des Findbuchs gebündelt, z. B. der Name des Kodierers, Ort und Datum der
Kodierung sowie die eingesetzte Version von EAD. Der Ersteller und der Kodierer
des Findbuchs können dieselbe Person sein oder auch nicht. Das richtet sich nach
den Arbeitsabläufen in der Institution und danach, ob das Findbuch neu ist oder aber
konvertierte Altdaten enthält. Es ist u. U. wichtig, zwischen Ersteller und Kodierer zu
unterscheiden, insbesondere wenn die Kodierung von einem Dritten vorgenommen
wurde und nicht den Kodierungsgrundsätzen der Institution entspricht, in der das
Findbuch erstellt wurde.
Das Element <profiledesc> ist nicht vorgeschrieben, seine Verwendung wird jedoch
empfohlen, da es von der erste Version des Findbuchs an eine Versionskontrolle
ermöglicht. Mit dem Element <profiledesc> kann/können auch die Sprache(n)
aufgenommen werden, in der das Findbuch selbst geschrieben wurde, und zwar
innerhalb der Elemente <langusage> und <language>. Diese Informationen können
es Suchmaschinen ermöglichen, die Suche auf Findbücher in bestimmten Sprachen
zu beschränken.
<profiledesc>
<creation>Findbuch wurde in EAD V1.0 von Kris Kiesling mit
Hilfe von Author/Editor V.3.5 kodiert, <date>4. November
1998</date>.
</creation> <langusage>Findbuch erstellt in
<language>Englisch</language> und
<language>Spanisch</language>.</langusage>
</profiledesc>
3.6.1.4. <revisiondesc> (Änderung der Kodierung)
Seit langem besteht in Archiven die Notwendigkeit, die verschiedenen neuen
Versionen eines Findbuchs und der Art der Änderungen festzuhalten und bei der
Pflege von EAD-Findbüchern ist das nicht anders. Das letzte <eadheader>-Element,
<revisiondesc>, enthält Informationen zu den Änderungen an dem kodierten
Findbuch.
135
Das Element <revisiondesc> dient der Dokumentation von wesentlichen Änderungen
an einem Findbuch, beispielsweise von Änderungen, die sich aus dem
Hinzukommen von Archivgut oder aus der Migration des Findbuchs von einer EADVersion zur nächsten ergeben. Wie <profiledesc> ist auch <revisiondesc> nicht
vorgeschrieben, jedoch empfohlen. Es ist indessen nicht notwendig (bzw.
empfohlen), kleinere Überarbeitungen oder typografische Änderungen zu vermerken,
die nach dem Kodieren des Findbuchs vorgenommen wurden. Wie die anderen
<eadheader>-Elemente ist auch <revisiondesc> nach der TEI-DTD gestaltet, die
empfiehlt, Änderungen zu nummerieren und in umgekehrter chronologischer
Reihenfolge aufzuführen (die letzte Änderung steht an erster Stelle):
<revisiondesc>
<change>
<date>23. Januar 2000</date>
<item>2. Findbuch von Jackie Dooley von EAD V1.0
in V2.0 umgewandelt</item>
</change>
<change>
<date>17. März 1999</date>
<item>1. Findbuch überarbeitet, um zusätzliches
Material aufzunehmen, das im Dezember 1998
übernommen wurde, und erneut von Bill Landis
kodiert</item>
</change>
</revisiondesc>
Für neue Versionen eines Findbuchs kann es auch erforderlich sein, die
Informationen in anderen <eadheader>-Elementen zu ändern. Zeitraumangaben in
<titleproper> müssen u. U. erweitert werden, bei umfangreichen Änderungen kommt
ggf. eine neue Version in Betracht, und Ersteller bzw. Erstellungsdatum des
kodierten Findbuchs müssen in <profiledesc> aktualisiert werden. Der Inhalt des
<eadheader> muss gründlich überprüft werden, wenn <revisiondesc> verwendet
wird.
136
3.6.1.5. Beispiel für ein kodiertes <eadheader>-Element
Es folgt ein Beispiel für ein vollständig kodiertes <eadheader>-Element:
<eadheader audience="internal" langencoding="ISO 639-2"
findaidstatus="edited-full-draft">
<eadid systemid="dlc"
encodinganalog="856">loc.mss/eadmss.ms996001
</eadid>
<filedesc>
<titlestmt>
<titleproper>Shirley Jackson</titleproper>
<subtitle>Ein Verzeichnis ihres Nachlasses
der Library of Congress</subtitle>
<author>Erstellt von Grover Batts.
Überarbeitet und erweitert von Michael
McElderry unter Mitwirkung von Scott
McLemee</author>
</titlestmt>
<publicationstmt>
<date>1993</date>
<publisher>Manuscript Division, Library of
Congress
</publisher>
<address>
<addressline>Washington, D.C. 205404860</addressline>
</address>
</publicationstmt>
<notestmt>
<note>
<p>Überarbeitet, vollständig</p>
</note>
</notestmt>
</filedesc>
<profiledesc>
<creation>Findbuch kodiert von: Library of Congress
Manuscript Division, <date>1996.</date>
</creation>
<langusage>Findbuch erstellt in
<language>Englisch.</language>
</langusage>
</profiledesc>
<revisiondesc>
<change>
<date>1997</date>
<item>Kodierung überarbeitet</item>
</change>
</revisiondesc>
</eadheader>
137
3.6.2. Vorspann <frontmatter> (Front Matter)
Einige Archive veröffentlichen ausgewählte Findbücher als Monografien oder in
anderer Form. Auch wenn Ihr Archiv dieses Verfahren nicht anwendet, möchten Sie
u. U. für eine Online-Veröffentlichung eine formelle Titelseite für Ihre codierten
Findbücher erstellen. Das Element <frontmatter> ist ein Hüllenelement mit zwei
Subelementen, die Strukturen für Veröffentlichungen, <titlepage> und <div>,
bereitstellen.
Das Element <titlepage> dient zum Gruppieren von bibliografischen Angaben zu
einem kodierten Findbuch, darunter <titleproper>, <subtitle>, <author>, <sponsor>,
<publisher> und <date>. Anders als viele andere <eadheader>-Elemente können
diese Elemente in jeder Reihenfolge verwendet werden, die für die Formatierung
oder Reihenfolge der Informationen gewünscht ist. Außerdem lassen sich mit
<titlepage> Bilder, Institutionenlogos oder andere Grafiken einbinden. Bei
Verwendung von <frontmatter> sollte <titleproper> dem <titleproper>-Element
entsprechen, das in <eadheader> <filedesc> und <titlestmt> verwendet wurde.
Das Element <div> ist ein allgemeines textbezogenes Element, mit dem ein Zugriff
zu Textformatierungselementen wie <head>, <p> und <list> möglich ist. Es eignet
sich zum Kodieren von Vorworten, Danksagungen, Einführungen und weiteren
Einleitungsteilen.
Viele EAD-Anwender haben festgestellt, dass <frontmatter> nicht erforderlich ist, weil
sie stattdessen zufriedenstellende Online-Ergebnisse erzielen, indem sie
ausgewählte Elemente aus <eadheader> darstellen lassen.
138
Kapitel 4: Das Authoring von EAD-Dokumenten
4.1. Der Authoring-Prozess ............................................................................................................. 140
4.1.1. Auswahl der Authoring-Software........................................................................................ 140
4.1.2. Beschaffung der EAD-DTD ................................................................................................ 140
4.1.3. Kodierung des Findbuchs .................................................................................................. 140
4.1.4 Validierung des EAD-Dokuments........................................................................................ 140
4.2. Optionen für Authoring-Software .............................................................................................. 142
4.2.1. Texteditoren und Textverarbeitungssysteme..................................................................... 142
4.2.2. Native SGML/XML-Editoren............................................................................................... 143
4.2.2.1. Lineare Editoren .......................................................................................................... 143
4.2.2.2. Editoren mit Baumstruktur ........................................................................................... 144
4.2.3. Textkonverter ..................................................................................................................... 145
4.2.4. Datenbanken ...................................................................................................................... 147
4.3. Technische Probleme beim Authoring...................................................................................... 149
4.3.1. Struktur der EAD-DTD ....................................................................................................... 149
4.3.2. Vergleich SGML – XML...................................................................................................... 150
4.3.2.1. Änderungen in den DTD-Dateien ................................................................................ 150
4.3.2.2. Unterscheidung zwischen Groß- und Kleinbuchstaben .............................................. 151
4.3.2.3. Die XML-Deklaration ................................................................................................... 151
4.3.2.4. Leere Elemente ........................................................................................................... 151
4.3.3. Syntaxanalyse .................................................................................................................... 152
4.3.4. Datenaustausch zwischen MARC-Titelaufnahmen und EAD-Findbüchern....................... 152
4.3.5. Auswirkungen verschiedener Kodierfunktionen auf die Ausgabe...................................... 153
4.3.5.1. Whitespace .................................................................................................................. 153
4.3.5.2. Zeichensetzung ........................................................................................................... 154
4.3.5.3. Kopfzeilen / Überschriften ........................................................................................... 155
4.3.5.4. Tabellendarstellung ..................................................................................................... 156
4.4. Dokumentenkontrolle ................................................................................................................ 157
4.4.1. Einheitliche Kodierung ....................................................................................................... 157
4.4.2. DTD-Konformität ................................................................................................................ 157
4.4.3. Dateinamen und Speicherstellen ....................................................................................... 157
4.4.4. Versionskontrolle................................................................................................................ 158
4.4.5. Datensicherheit .................................................................................................................. 158
139
4.1. Der Authoring-Prozess
Der als „Authoring“ bezeichnete Vorgang, SGML-Auszeichnung auf Dokumente
anzuwenden, umfasst mehrere Arbeitsschritte. Sie sind nachstehend
zusammengefasst, in späteren Abschnitten von Kapitel 4 im Einzelnen und an
anderer Stelle des Anwenderleitfadens beschrieben.
4.1.1. Auswahl der Authoring-Software
Für das Authoring von EAD-Findbüchern stehen viele Softwareprodukte zur
Verfügung. Zuerst muss man sich für eine bestimmte Anwendung entscheiden.
Dieser Entscheidungsprozess umfasst eine sorgfältige Abwägung von Möglichkeiten,
Kosten und Eignung für die jeweilige technische Ausstattung des Archivs sowie
Eignung für das Erzeugen neuer Findbücher oder das Umwandeln von Findbüchern,
die bereits in maschinenlesbarer Form vorhanden sind. Erhältliche
Softwareanwendungen sind in Abschnitt 4.2 beschrieben.
4.1.2. Beschaffung der EAD-DTD
Unabhängig davon, welche Software verwendet wird, muss ab einem bestimmten
Punkt des Authoring-Prozesses ein Exemplar der EAD-DTD zur Hand sein. Einige
Softwarefirmen fügen ihrer Software ein Exemplar der DTD bei. Die DTD kann auch
von der Encoded Archival Description Official Web Site der Library of Congress72
heruntergeladen werden. Einige SGML/XML-Authoring-Werkzeuge wandeln die DTD
in eine interne, firmeneigene Struktur um, mit der eine wirksamere Bedienung
innerhalb des betreffenden Produkts möglich ist. Beispiele sind die Regeldateien von
Author/Editor und die logischen Dateien von WordPerfect. Jeder Softwarehersteller
stellt eine Software zum Umwandeln der DTD in das eigene binäre Format zur
Verfügung. Die umgewandelten Dateien für diese Anwendungen stehen auch auf der
Webseite73 EAD Help Pages zur Verfügung und können anstelle der DTD
heruntergeladen werden.
4.1.3. Kodierung des Findbuchs
Zur Auszeichnung eines Findbuchs können verschiedene Verfahren angewendet
werden, je nach den in der betreffenden Institution üblichen Arbeitsabläufen, der
Software, dem Personal, den zu erwartenden Kosten und dem technischen
Entwicklungsstand. Der Status eines bestimmten Dokuments kann ebenfalls einen
Einfluss auf die anzuwendenden Verfahren haben, das sich z. B. danach richtet, ob
das zu kodierende Dokument ein neuerstelltes Findbuch, ein vorhandenes, noch
nicht maschinenlesbares Findbuch oder ein vorhandenes elektronisches Findbuch
ist. Die damit zusammenhängenden verwaltungstechnischen Fragen sind in
Abschnitt 2.5 behandelt. Kapitel 3 enthält ausführliche Kodieranweisungen.
4.1.4 Validierung des EAD-Dokuments
Zur Sicherstellung von Konformität, ordnungsgemäßer Bearbeitung und der
Möglichkeit des Datenaustauschs muss das kodierte Dokument mit den
Spezifikationen der DTD verglichen werden, um zu gewährleisten, dass die
Auszeichnung dem EAD-Standard entspricht. Dieser Prozess umfasst zwei
72
73
Encoded Archival Description Official Web Site, <http://www.loc.gov/ead/>.
EAD Help Pages, <http://www.archivists.org/saagroups/ead/>.
140
Arbeitsschritte: Syntaxanalyse und Validierung. Sie können entweder von einem in
die Authoring-Software integrierten Syntaxanalysator oder von einem gesonderten
Programm durchgeführt werden. Die Syntaxanalyse ist ausführlich in den
Abschnitten 4.3.3 und 6.2.4 beschrieben.
141
4.2. Optionen für Authoring-Software
Für die Erstellung von EAD-Dokumenten kommen viele unterschiedliche
Softwareanwendungen in Betracht. Im vorliegenden Abschnitt werden entsprechend
ihrer Funktionsweise vier große Kategorien von Authoring-Werkzeugen
beschrieben:74
•
•
•
•
Texteditoren und Textverarbeitungssysteme
native SGML/XML-Editoren
Textkonverter
Datenbanken.
Im Überblick werden die einzelnen Typen und ihre jeweilige Funktionsweise erklärt:
Es werden beispielhaft, zum Zeitpunkt der Erstellung des Anwenderleitfadens
erhältliche Produkte genannt und die allgemeinen Vor- und Nachteile jedes
Verfahrens erläutert. Der Markt ist z. Z. sehr dynamisch. XML- und XML-konforme
Software tritt als potenziell bedeutender Faktor in verschiedenen Umgebungen auf,
einschließlich Officepaketen, Verwaltungssoftware für relationale Datenbanken und
Anwendungen für den Internethandel.75
Um eine ansprechende gedruckte Version des Findbuchs für die öffentliche
Benutzung zu erstellen, sind weitere Schritte notwendig, da das Dokument alle
erforderlichen EAD-Tags, jedoch keine Anweisungen für die Formatierung oder
Präsentation enthält. Es gibt mehrere Möglichkeiten, darunter die Verwendung von
Stylesheets, die mit Formatierungssprachen wie XSL und DSSSL erstellt wurden und
auf der Grundlage von EAD-Findbüchern zur Spezifizierung des Layouts von
Druckfindbüchern dienen können. Informationen über Stylesheets siehe Abschnitt
5.3.3. Informationen über das Ausdrucken siehe Abschnitt 5.3.4.
4.2.1. Texteditoren und Textverarbeitungssysteme
Da ein SGML-Dokument als einfache Textdatei vorliegt, kann ein EAD-Findbuch
unter Verwendung jeder Software eingegeben werden, die ein Dokument im ASCIIFormat ausgeben kann. Dazu gehören Texteditoren, die zusammen mit dem
Betriebssystem geliefert werden, z. B. DOS Editor, Windows Notepad oder die mit
Macintosh SimpleText bezeichneten Programme. Auch Textverarbeitungssysteme
können verwendet werden. Die Dateien müssen jedoch im ASCII-Format und nicht in
dem nativen Format des Textverarbeitungssystems gespeichert werden.
Vorteile: Geringe Kosten, leichte Verfügbarkeit und Nutzerfreundlichkeit sind die
Hauptvorzüge dieser Produkte.
Nachteile: Texteditoren und Textverarbeitungssysteme haben keine eingebaute
Kenntnis der EAD-DTD-Regeln und damit auch kein Verfahren, mit dem die
Einhaltung dieser Regeln geprüft werden kann. Man muss sich daher auf die EADKenntnisse des Kodierers verlassen, um die ordnungsgemäße Verwendung von
Datenelementen und Attributen sicherzustellen. Zur Validierung des Dokuments
muss eine gesonderte Anwendung eingesetzt werden. Einige solcher Anwendungen
74
Andere Kategorien wären sicherlich ebenfalls möglich.
Informationen zu zahlreichen Softwareprodukten – sowohl handelsüblichen Produkte als auch Freeware – sowie zu den
spezifischen, in diesem Kapitel genannten EAD-Dateien finden sich auf den EAD Help Pages, die auf
<http://www.archivists.org/saagroups/ead/> verfügbar sind. Neue Informationen werden aufgenommen, wenn weitere Produkte
erhältlich sind. Genauere Informationen zu zahlreichen Produkten vgl. Cover, Robin: The SGML/XML Webpage,
<http://www.oasis-open.org/cover>.
75
142
sind als Freeware erhältlich, z. B. NSGMLS und XML-spezifische
Syntaxanalysatoren von Microsoft, IBM und anderen Firmen.
Beim Erstellen eines EAD-Dokuments mit Hilfe eines Textverarbeitungssystems
muss besonders auf die Verwendung bestimmter Zeichen und Symbole geachtet
werden. Beispielsweise haben die Zeichen &, <, >, " und ' für SGML-Prozessoren
eine besondere Bedeutung, da sie entweder zum Text oder zur Auszeichnung
gehören können, und es ist notwendig, diese Fälle zu unterscheiden. Es ist möglich,
diese und andere „nicht standardmäßige“ Zeichen, z. B. Buchstaben, die mit
diakritischen Zeichen, mittels Entitätsreferenzen (siehe Abschnitt 6.5.2.1) in ein EADDokument aufzunehmen. Der Authoring-Prozess kann jedoch durch die manuelle
Eingabe von Entitätszeichenfolgen bedeutend verlangsamt werden. Wird ein
Textverarbeitungssystem zur Erzeugung einer EAD-Instanz verwendet, ist besonders
darauf zu achten, dass für die oben genannten nicht zur lateinischen Schrift
gehörigen Buchstaben und Symbole eine Entitätsreferenz auf das entsprechende
ISO-Zeichen eingefügt wird, anstelle der herstellerspezifischen Codierungen, die
Textverarbeitungssysteme normalerweise zur Darstellung solcher Zeichen
verwenden. Es ist auch erforderlich, den „Prolog“ der EAD-Instanz manuell zu
erzeugen (Informationen zum EAD-Prolog siehe Abschnitt 6.2.3).
4.2.2. Native SGML/XML-Editoren
Es sind viele Softwarepakete erhältlich, die eigens für das Authoring von SGML/XMLDokumenten wie z. B. EAD-Instanzen bestimmt sind. Diese Produkte lassen sich
nach Betriebssystemen unterscheiden, für die sie verfügbar sind, ferner nach ihrer
Fähigkeit zum Erzeugen von Dokumenten in SGML und/oder XML oder aber nach
dem „look and feel“.
In Bezug auf das letztgenannte Kriterium stellen einige Softwaretypen den Text der
EAD-Instanz linear dar, wobei sowohl die Auszeichnung als auch der Inhalt des
Findbuchs als kontinuierlicher Textblock erscheinen. Bei anderen
Softwareanwendungen erscheint die Auszeichnung in einem Fenster in Form einer
Baumstruktur, die die Hierarchie und Schachtelung der Elemente zeigt, und der Text
des Findbuchs erscheint in einem parallelen Fenster. Nachstehend sind
Softwareanwendungen beider Typen beschrieben, wobei der Schwerpunkt auf
denjenigen Anwendungen liegt, die derzeit von Archivaren zur Erstellung von EADDokumenten eingesetzt werden.
4.2.2.1. Lineare Editoren
Author/Editor, ursprünglich von SoftQuad entwickelt, aber jetzt von Interleaf
vertrieben, ist ein weit verbreiteter, für diese Produktkategorie typischer Editor. Er ist
als Version für Windows und Macintosh erhältlich, führt eine fortlaufende DTDValidierung durch, hat standardmäßige Ausschneide- und Einfügefunktionen, eine
Rechtschreibungprüfung, einen Thesaurus und eine eigene Makrosprache. Er hat
nur begrenzte Funktionalitäten und verwendet seine internen
Formatierungsmöglichkeiten dazu, um aus einem EAD-Dokument Druckfindbücher
zu erstellen. Mit dem Quark-Express-Desktop-Publisher kann er außerdem akkurat
formatierte Dokumente ausgeben. Für Author/Editor muss eine DTD in ein internes
Regeldateiformat übersetzt werden (ead.rls, erhältlich auf den EAD Help Pages76).
76
EAD Help Pages, <http://www.archivists.org/saagroups/ead/>.
143
Ab Version 6.0 wurden in die Textverarbeitungssoftware WordPerfect von Corel
SGML-Authoring-Fähigkeiten integriert. Auch hierfür muss die DTD in eine interne
Struktur in Form einer „logischen“ Datei umgewandelt werden (ead.lgc, erhältlich auf
den EAD Help Pages). Außerdem umfasst sie die standardmäßigen
Textänderungsmöglichkeiten, die man bei einem Textverarbeitungssystem erwartet.
Für das Ausdrucken eines Findbuchs in einem für öffentliche Benutzung geeigneten
Format (ohne Tags und mit geeigneter Seitengestaltung) ist die Funktion „styles“ in
WordPerfect erforderlich.
4.2.2.2. Editoren mit Baumstruktur
Die Firma Interface Electronics bietet Internet Archivist an, ein eigens für EAD77
entwickeltes Authoring-Paket. Die Struktur des zu kodierenden Dokuments wird in
einem Fenster als Baum oder Hierarchie dargestellt, während der Inhalt der
einzelnen Elemente und der dazugehörigen Attribute in Textfenstern innerhalb des
Hauptrahmens erscheint. Das Paket beinhaltet die Umwandlung in HTML und bietet
einfache Druckfunktionen.
Die Software ADEPT Editor von ArborText stellt in ähnlicher Weise die
Elementstruktur als Baum in einem Nebenfenster und den Text des EAD-Dokuments
im Hauptfenster dar. Wie auch andere Produkte dieser Kategorie bietet sie ein
umfangreiches Spektrum an Textverarbeitungsfunktionen und hat von allen
erhältlichen Werkzeugen wahrscheinlich die vollständigste Ausstattung mit
Spezialfunktionen für das Authoring in SGML. Das Format sowohl der
Bildschirmdarstellung als auch des Ausdrucks der SGML-Instanz wird von zwei
getrennten Stylesheets gesteuert, die gemäß der FOSI
(Formatierungsausgabespezifikation) erstellt wurden (Sprachen für Stylesheets sind
in den Abschnitten 5.3.1 und 5.3.3 beschrieben). ADEPT Editor ist für die meisten
Betriebssysteme erhältlich, z. B. Windows, Macintosh, Unix und OS/2. Diese
Software gehörte zu den ersten im Handel erhältlichen Authoring-Paketen, die eine
XML-Funktion hatten.
Ähnliche Produkte in dieser Gruppe sind beispielsweise Framework + SGML von
Adobe und XML Pro von Vervet. Aufgrund der zunehmenden Bedeutung von XML
statten Firmen wie SoftQuad (mit XMetaL) und Macromedia (mit Dreamweaver 2)
ihre HTML-Editoren mit XML-Bearbeitungsfunktionen aus.
Vorteile: Beide Typen von nativen Editoren (lineare Editoren und Editoren mit
Baumstruktur) weisen viele nützliche Eigenschaften auf, die sie als attraktive Wahl
erscheinen lassen. Die Software „kennt“ SGML im Allgemeinen und die verwendete
DTD im Besonderen. Da die Software die DTD unmittelbar enthält, erlaubt sie die
ständige Validierung eines Dokuments während des Authoring-Prozesses. Die
Spezialanwendungen bieten zahlreiche Möglichkeiten, wie man sie von einem
kompletten Textverarbeitungssystem erwartet, darunter eine Rechtschreibprüfung,
einen Thesaurus, Makros, interne Formate zur Steuerung der Textdarstellung sowie
Templates. Sie verwalten auch Entitäten und erzeugen den Prolog eines Dokuments.
77
Weitere Angaben sind auf der Webseite der Firma vgl. <http://www.interface.com/ead>.
144
Native Editoren stetzen zwar voraus, dass Anwender allgemeine Kenntnisse über die
Struktur und Anwendung einer bestimmten DTD besitzen. Die Eingabeaufforderung
und Pull-Down-Menüs unterstützen jedoch bei der Auswahl von Elementen und der
Zuweisung von Attributen. Sie helfen Kodierern auch dabei, Zeichen- und DateiEntitäten einzufügen und zu verwalten. In gewisser Weise liegt der Schwerpunkt in
der anfänglichen Dateneingabephase. Sobald das Dokument fertiggestellt ist, sind
keine weiteren Arbeiten erforderlich, außer dass noch eine benutzerfreundliche
Version des Verzeichnisses ausgedruckt werden muss.
Nachteile: Kodierer müssen gewisse Kenntnisse über die DTD besitzen, wenn auch
die Bedienung der Software selbst im Allgemeinen nicht komplexer als die einer
normalen Officeanwendung ist. Wahrscheinlich müssen Kodierer sich diese
Kenntnisse jedoch selbst aneignen, da Ausbildungseinrichtungen vor Ort für derartig
spezialisierte Werkzeuge wahrscheinlich keine Lehrgänge anbieten. Außerdem sind
möglicherweise die Softwarekosten bei einigen Produkten ein wesentlicher Faktor.
Alle diese Anwendungen liegen im Preisbereich von Spezialanwendungen und nicht
von normalen Produkten, wobei die Preise bei 450 US-$ beginnen. Allerdings
gewährt Corel für WordPerfect beim Einsatz der Software für Ausbildungszwecke
erhebliche Rabatte.
Zur Erstellung von ansprechend formatierten Druckfindbüchern sind oft zusätzliche
Arbeitsschritte und Funktionen und u. U. zusätzliche Software erforderlich. Native
Editoren eignen sich besser für die Erstellung bzw. Bearbeitung neuer bzw.
vorhandener Findbücher, die noch nicht in elektronischer Form vorliegen, als für die
Umwandlung vorhandener elektronischer Dateien. Das liegt daran, dass bei solchen
Editoren für die Kodierung vorhandener maschinenlesbarer Texte ein großer
Aufwand beim Ausschneiden und Einfügen betrieben werden muss, nachdem die
Datei im Editor geöffnet worden ist. Das kann letztlich zeitraubender (und somit
kostspieliger) sein, als den Text neu einzugeben.
4.2.3. Textkonverter
Textkonvertierungssoftware dient dem Umwandeln vorhandener maschinenlesbarer
Texte aus ihrem ursprünglichen Format in ein kodiertes Dokument, das einer
bestimmten DTD entspricht. Zu dieser Kategorie gehören Werkzeuge, die
Quelldokumente in einem bestimmten Dateiformat verarbeiten können, z. B.
Microsoft Word Rich Text Format (RTF), oder aber eine spezifische DTD-Struktur zu
Grunde legen, die auf allgemeine oder spezielle SGML-fähige Programmiersprachen
sowie Makrosprachen für die Textverarbeitung ausgelegt sind.
Bei der Textumwandlung wird stets von der Annahme ausgegangen, dass das
Quelldokument Informationen enthält, mit deren Hilfe die Konvertierungssoftware
Äquivalente zwischen Texten oder Kodes im Originaldokument und vergleichbaren
EAD-Elemente erkennen kann. Zu solchen Informationen gehören
Formatierungsdaten wie Zeichensetzung, Großschreibung, Setzen von Tabulatoren
und Einrücken von Text, Textverarbeitungsformate oder sonstige
Auszeichnungskodes, z. B. Elemente aus einer anderen SGML-DTD oder aus
MARC-Tags. Im Allgemeinen gilt: Je konsequenter diese Kennzeichen im
Quelldokument verwendet werden, desto zuverlässiger und vollständiger ist die
Umwandlung. Es darf nicht davon ausgegangen werden, dass diese Verfahren auf
alle möglichen elektronischen Texte angewendet werden können, die keine solchen
konsistenten Kennzeichen enthalten.
145
Die Software SGML Author for Word von Microsoft ist ein allgemeines Werkzeug
zum Umwandeln von Dokumenten in SGML-Dokumente, die in der Word für
Windows erstellt wurden. Es führt die Umwandlung mit Hilfe von WordFormatierungen und Templates durch. In einem Word-Template für Dokumente
werden Textformatierungen und EAD-Elemente einander zugeordnet. Dann wird in
der SGML-Author-Software eine Verknüpfung zwischen jeder Formatierung und dem
entsprechenden EAD-Tag hergestellt. Diese Entsprechungen werden in einer
Assoziationsdatei gespeichert. Bei der Eingabe des Findbuchs in ein WordDokument werden die festgelegten Formatierungen auf den Text angewendet.
Während des Umwandlungsprozesses liest die Software die Assoziationsdatei und
kodiert den Text des Dokuments mit den entsprechenden SGML-Tags. Die Software
TagPerfect von der finnischen Firma Delta Computers bietet vergleichbare
Funktionen zum Umwandeln von Word-Dokumenten in SGML.
Als Alternative zu diesen kommerziellen Lösungen kann man ein
Konvertierungsprogramm auch selbst erstellen. Dafür gibt es drei allgemeine
Kategorien von Werkzeugen, die sich in der Komplexität des Aufwandes und der
Leistungsfähigkeit der verwendeten Sprachen unterscheiden. Am einfachsten sind
die internen Makrosprachen von Word und WordPerfect zu lernen und anzuwenden,
und einige Archive haben mit Erfolg für die Umwandlung von Dokumenten
eingesetzt. Die Makroprogrammiersprache in Version 8.0 von WordPerfect bietet
Spezialfunktionen, mit denen sich SGML-spezifische Probleme lösen lassen. Mit
Word97 hat Microsoft seine Makrosprache von WordBasic auf Visual Basic for
Applications umgestellt. Die Makros, die mit diesen Werkzeugen geschrieben werden
können, können im Spektrum zwischen sehr einfach und technisch hochentwickelt
liegen.
Einige Spezialprogramme wurden eigens dafür entwickelt, strukturierten Text in
SGML-Dokumente umzuwandeln. Dazu gehören DynaTag von der INSO Corporation
und Balise von der Firma AIS Software. Diese Programme arbeiten mit einer
komplexen Syntax und wurden für erfahrene Programmierer erstellt. Balise
beispielsweise soll der Sprache C++ sehr ähnlich sein.
Ein weiteres Umwandlungsprogramm, das irgendwo zwischen diesen beiden Polen
liegt, ist Perl. Als weit verbreitete und gut dokumentierte Programmiersprache wurde
Perl speziell für die Art von Textbearbeitung entworfen, die für die Umwandlung
vorhandener Findbücher in EAD-Findbücher erforderlich ist. Perl wurde in mehreren
Archiven angewendet, deren Mitarbeiter über die nötigen technischen Kenntnisse
verfügen. Es ist zwar möglich, ein Einführungshandbuch für Perl zu erwerben, um
diese Programmiersprache zu erlernen. Man sollte sich jedoch darüber im Klaren
sein, dass man eine gewisse Zeit braucht, um Perl zu beherrschen.
Vorteile: Mit Hilfe von Textkonvertern können vorhandene, maschinenlesbare
Dateien und vertraute Software eingesetzt werden, vorausgesetzt, dass die
vorliegenden Dateien so strukturiert sind, dass eine Umwandlung möglich ist. Da
dieselbe Software für die Erstellung von Findbüchern wie auch für die Erstellung
anderer Officedokumente eingesetzt wird, können die Kosten für eine neue
Softwareausstattung eingespart werden. Auch wird keine bzw. erheblich weniger Zeit
für das Erlernen einer neuen Anwendung benötigt, was die Akzeptanz bei den
Mitarbeitern erhöht. Bei einem Szenario mit nachträglicher Umwandlung wird implizit
146
davon ausgegangen, dass die Autoren von Dokumenten höchstens minimale
Kenntnisse der zugrunde liegenden DTD-Struktur haben müssen. Außerdem sind
keine zusätzlichen Arbeitsschritte zur Erstellung von Druckfindbüchern für den
öffentlichen Gebrauch erforderlich, da das Originaldokument wahrscheinlich mit Hilfe
eines Textverarbeitungssystems erstellt worden ist. Die Textkonvertierung ist für ein
Archiv möglicherweise ein effektives Verfahren zur Kodierung von bereits in
elektronischer Form vorliegenden Altdaten und kann sich auch als Teil der
Arbeitsabläufe für die Erstellung neuer Findbücher eignen.
Nachteile: Es ist zwar anzunehmen, dass, wenn ein nativer Editor verwendet wird,
gleich zu Beginn des Authoring-Prozesses Personalkosten (Aufwände in Verbindung
mit der Einarbeitung in spezielle Software und die EAD-DTD) entstehen. Ähnliche
Kosten treten jedoch sowohl vor als auch nach der Arbeit mit Textkonvertern auf.
Zunächst müssen die Quelldokumente sorgfältig im Voraus formatiert werden, um die
spätere Umwandlung zu erleichtern. Und die Entwicklung der
Umwandlungsprogramme selbst kann einen ausgedehnten, sich ständig
wiederholenden Entwurfsprozess erforderlich machen. Die Umwandlung an sich mag
mehr oder weniger automatisch ablaufen. Manuelle Eingriffe oder Manipulationen
könnten aber nach der Umwandlung notwendig sein. Einige Textkonverter reagieren
u. U. empfindlich auf Abweichungen in Quelldokumenten, entweder weil sich die
organisatorische Struktur von archivischen Beständen unterscheidet oder weil sich
die Findbuchformate im Laufe der Zeit ändern. Anpassungsmaßnahmen in der
Programmierung können sich als notwendig erweisen. Um sicherzustellen, dass bei
den automatisierten Prozessen tatsächlich das gewünschte Ergebnis erzielt wird,
muss eine sorgfältige Qualitätskontrolle stattfinden.
4.2.4. Datenbanken
Einige Archive erstellen und speichern Erschließungsinformationen mit Hilfe gängiger
Software für relationale Datenbankmanagementsysteme (DBMS). Diese
Vorgehensweise ist u. U. besonders attraktiv für Archive, die in einem DBMS
gespeicherten Bestandsmanagementdaten mit den dazugehörigen, normalerweise in
Findbüchern enthaltenen beschreibenden Metadaten verknüpfen möchten. In diesem
Szenario kann die EAD-Kodierung bei der Erzeugung von Exporten aus dem
Datenbanksystem auf Text angewendet werden, der in der Datenbank gespeichert
ist. Dabei wird vorausgesetzt, dass die Feldstruktur der Datenbank den EADElementen entspricht und die Software in der Lage ist, Exporte in Form eines EADDokuments zu erzeugen. Ein mögliches Szenario kann darin bestehen,
Bestandsverzeichnisse und vielleicht auch Erschließungsangaben zu Serien mit
einem DBMS zu erstellen, längere fortlaufende Texte wie Kurzbiografien oder
Gegenstände dagegen in ein Textverarbeitungssystem einzugeben.
Das Programm Gencat von Eloquent Software ist ein proprietäres DBMS, das den
Datenexport in viele verschiedene Formate – auch in EAD – ermöglicht. Einige
Archive haben bereits eigene Anwendungen zum Exportieren von Daten aus
Datenbanken programmiert. Dazu sind jedoch recht fortgeschrittene
Programmierkenntnisse erforderlich. Ein potenziell komplexes, jedoch höchst
kritisches Problem beim Entwerfen einer solchen Datenbank besteht in der
Entwicklung einer Architektur, die die für EAD kennzeichnende mehrstufige
hierarchische Struktur der Komponenten eines archivischen Bestandes unterstützt.
Die Herausforderung kann zum Teil auch darin liegen, dass viele archivische
147
Datenbanksysteme sehr „flach“ sind, also nur die Bildung von ein oder zwei
Hierarchieebenen zulassen.
Die Nutzung von Datenbanken wird möglicherweise künftig weiter verbreitet und
leichter sein, wenn die Hersteller von relationalen Datenbanken wie Oracle, SyBase
und andere ihre Produkte mit XML-Funktionen ausstatten, wie sie es angekündigt
haben.
Vorteile: Die Nutzung eines DBMS kann für Institutionen vorteilhaft sein, die bereits
erheblich in solche Anwendungen investiert haben. Sie kann auch für Institutionen
wertvoll sein, die beschreibende Metadaten, wie sie in EAD-Findbüchern
vorkommen, mit anderen Anwendungen, z. B. Bestands- oder
Dokumentenmanagementsystemen, austauschen müssen.
Nachteile: Für die Programmierung einer solchen Datenbank und das Exportieren
ihrer Daten in EAD sind u. U. hochspezielle Schulungsmaßnahmen bzw. Kenntnisse
erforderlich. Außerdem kann bei der Umwandlung einer „flachen“ Datenbankstruktur
in EAD die Fähigkeit von EAD zum Abbilden von archivischen Hierarchien nur
teilweise genutzt werden.
148
4.3. Technische Probleme beim Authoring
In diesem Abschnitt werden die folgenden technischen Probleme behandelt, soweit
sie sich auf das Authoring von EAD-Dokumenten beziehen:
•
•
•
•
•
Struktur der EAD-DTD und der zugehörigen Dateien
EAD als SGML- und als XML-DTD
Syntaxanalyse zur Prüfung von EAD-Instanzen auf Konformität mit der DTD
Datenaustausch zwischen MARC-Titelaufnahmen und EAD-Findbüchern
die verschiedenen Auswirkungen von Kodierfunktionen auf die Ausgabe.
4.3.1. Struktur der EAD-DTD
Die EAD-Dokumenttyp-Definition (DTD) ist eine wesentliche Komponente des
Authoring-Prozesses. Als Dokument ist die DTD gemäß einer vom SGML-Standard
festgelegten strengen Syntax aufgebaut. Für Dateimanagementzwecke sind die
Komponenten der EAD-DTD modular auf die Datei ead.dtd und vier andere
zugehörige Dateien verteilt, die zusammen als Einheit arbeiten. Zwei davon (siehe
unten) werden nicht benötigt, wenn das Findbuch mit EAD in XML kodiert wird. Alle
fünf Dateien sind einfache Textdokumente im ASCII-Format, die mit
Textverarbeitungssoftware gelesen und bearbeitet werden können. Sie sind wie folgt
bezeichnet:
•
•
•
•
•
ead.dtd
eadbase.ent
eadnotat.ent
eadchars.ent
eadsgml.dcl
ead.dtd Dies ist die Kerndatei der EAD-DTD. Sie ist kurz und enthält die
Versionsgeschichte der DTD sowie Entitätsreferenzen zum Aufrufen der anderen
Dateien der EAD-Pakets. Sie enthält außerdem drei bedingte Abschnitte, mit denen
die folgenden Funktionalitäten aktiviert bzw. deaktiviert werden: XML-Kompatibilität,
XLink-Funktion und die spezielle Funktionen der EAD-Tabellenelemente. Die
Benutzung dieser Funktionenalitäten ist beschrieben in den Abschnitten: 4.3.2.1
(XML-Kompatibilität), 4.3.5.4 (Tabellendarstellung) und 7.2.4 (XLink-Funktion).
eadbase.ent Dies ist die größte Datei der Gruppe und enthält die SGML-Regeln für
EAD.
eadnotat.ent Diese Datei referenziert die verschiedenen Notationsdateien
(Nichttextdateien), die in einem EAD-Dokument verwendet werden können. Dazu
gehören gängige Bilddateiformate wie GIF, JPEG, TIFF und MPEG (weitere
Informationen zu Notationsdateien siehe Unterabschnitt 6.5.2.4.2).
eadchars.ent Diese Datei referenziert auf die verschiedenen Zeichenvorräte, die in
einem EAD-Dokument verwendet werden können. Alle Zeichenvorräte sind mit ihren
Standard-ISO-Kennungen bezeichnet. Diese Datei wird nicht benötigt, wenn das
Dokument in XML erstellt wird, bei dem standardmäßig der Unicode-Zeichenvorrat
(oder eine Untermenge davon) verwendet wird (weitere Informationen zu
Zeichenvorräten siehe Abschnitt 6.5.2.1).
149
eadsgml.dcl Dies ist die SGML-Deklarationsdatei, in der verschiedene Eigenschaften
der DTD festgelegt sind, die ggf. einer Verarbeitungsanwendung bekannt sein
müssen. Während viele DTD eine Standard-SGML-Deklaration verwenden, setzt
EAD eine eigene Version der Deklaration ein. Bei einigen Softwareanwendungen
steht der Text der Deklaration am Anfang jeder SGML-Instanz. Alle XML-Dokumente
verwenden eine standardmäßige Deklaration, für sie wird diese Datei nicht benötigt.
4.3.2. Vergleich SGML – XML
EAD ist so geschrieben, dass es entweder auf SGML oder auf XML abgestimmt
werden kann. Die Form der DTD und der zugehörigen Dateien, die auf der EADHomepage der Library of Congress erhältlich sind, enspricht SGML. Im Allgemeinen
kann man XML als Untermenge von SGML betrachten; es gibt jedoch fünf
Abweichungen bei XML, die berücksichtigt werden müssen, damit ein EADDokument XML-konform ist. Diese Abweichungen sind besonders zu beachten, wenn
es darum geht, vorhandene SGML-Versionen von Dokumenten in XML
umzuwandeln.
4.3.2.1. Änderungen in den DTD-Dateien
Soll die DTD zusammen mit XML-Anwendungen, z. B. Validierungsprozessoren,
eingesetzt werden, muss zuerst eine Änderung an der Datei „ead.dtd“ vorgenommen
werden. Am Ende der Datei gibt es einen Abschnitt „SGML EADNOTAT AND
EADCHARS INCLUSION/EXCLUSION“. Am Ende dieses Abschnitts steht die
Entitätsreferenz „<!ENTITY % sgml 'INCLUDE' >". Um die SGML-Kompatibilität
„auszuschalten” und die XML-Kompatibilität „einzuschalten”, ist ,INCLUDE’ in
,IGNORE’ zu ändern.
Bei der Durchführung dieser Änderung ist darauf zu achten, dass der erläuternden
Kommentar in diesem Abschnitt der DTD-Datei darauf hinweist, dass „bei XML die
Datei eadnotat.ent in der Deklarations-Untermenge [der] jeweiligen Instanz
aufzurufen ist“. Das bedeutet, dass die Datei „eadnotat.ent“ explizit als Entität im
Prolog jeder EAD-Instanz deklariert werden muss, die Verknüpfungen mit
Notationsdaten (Nichttextdaten) wie z. B. Grafikdateien enthält (der Dokumentprolog
ist allgemein in Abschnitt 6.2.3 behandelt). Bei XML-Instanzen muss daher der
Prolog EAD-kodierter Findbüchern wie folgt lauten:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN"
"ead.dtd"
[
<!ENTITY % eadnotat PUBLIC "-//Society of American
Archivists//DTD eadnotat.ent (Encoded Archival Description (EAD)
Notation Declarations Version 1.0)//EN" "eadnotat.ent">
%eadnotat;
]>
Es ist zwar nicht erforderlich, die Notationsdatei „eadnotat.ent“ zu deklarieren, wenn
das Findbuch keine Verknüpfung mit Notationsdaten, z. B. Grafikdateien, enthält. Es
ist jedoch am sichersten, sie in allen Fällen als Standardvorgabe einzufügen. Es ist
zu beachten, dass die Uniform Resource Identifiers* (URI), in diesem Fall einfache
*
A.d.Ü.: = einheitlicher Bezeichner für Ressourcen.
150
Dateinamen für die Dateien „ead.dtd“ und „eadnotat.ent“, genau auf die
Speicherstelle dieser beiden Dateien in dem System vor Ort verweisen müssen. Ihr
Inhalt kann daher – je nach den örtlichen Speicherverfahren für die DTD und die
zugehörigen Dateien – von den o. g. Beispielen abweichen.
4.3.2.2. Unterscheidung zwischen Groß- und Kleinbuchstaben
Die Auszeichnung in SGML unterscheidet nicht zwischen Groß- und
Kleinbuchstaben. Um jedoch die Kompatibilität mit den Spezifikationen des UnicodeZeichenvorrats sicherzustellen, wird bei der Auszeichnung in XML zwischen Großund Kleinbuchstaben unterschieden. Die EAD-DTD schreibt vor, dass zwecks XMLKonformität alle Element- und Attributnamen in Kleinbuchstaben zu schreiben sind.
Einige SGML-Authoring- bzw. -Syntaxanalyse-Anwendungen schreiben solche
Namen automatisch in Großbuchstaben. Die dabei entstehenden Dateien müssen so
bearbeitet werden, dass alle Attribut- und Elementnamen in Kleinbuchstaben
erscheinen, wenn diese Dateien in einem XML-konformen System verwendet werden
sollen. Ein Umwandlungsmakro für Microsoft Word ist auf den EAD Help Pages78
erhältlich.
4.3.2.3. Die XML-Deklaration
Die Deklaration, dass es sich um eine XML-Datei handelt, muss am Anfang jeder
XML-Instanz stehen. Die Deklaration weist drei Komponenten auf: die verwendete
XML-Version, die Angabe, ob eine externe DTD wie etwa EAD verwendet wird, und –
optional – das angewendete Kodierschema für Unicode-Zeichen (z. B. UTF-8). Eine
typische XML-Deklaration könnte so aussehen:
<?xml version="1.0" standalone="no" encoding="UTF-8"?>
4.3.2.4. Leere Elemente
Schließlich unterscheiden sich SGML und XML bzgl. der Auszeichnungssyntax für
Elemente, die in der DTD als „leer“ deklariert werden, d. h. Elemente, die weder
andere Elemente noch PCDATA enthalten. Die entsprechenden EAD-Elemente sind
<lb>, <extptr>, <extptrloc>, <ptr> und <ptrloc>. Mit Ausnahme von <lb>, einer
Formatierfunktion, sind es alles Verknüpfungselemente, die Attributwerte verwenden,
um auf andere Speicherstellen oder Dateien zu verweisen. In SGML erfordern leere
Elemente nur einen Start-Tag (<lb>). XML fügt eine weitere Form hinzu, die als LeerElement-Tag bezeichnet wird und die Syntax <lb/> hat. In XML-Systemen ist
entweder der Leer-Element-Tag (<lb/>) oder Start- und End-Tag (<lb></lb>) gültig.
Im XML-Standard ist jedoch festgelegt, dass „aus Gründen der Interoperabilität“der
Leer-Element-Tag zu verwenden ist. Die Bedeutung dieser Aussage ist zwar
zugegebenermaßen vage. Es ist letztlich jedoch am einfachsten, in XMLDokumenten die Syntax des Leer-Element-Tags (<lb/>) anzuwenden.
78
EAD Help Pages, <http://www.archivists.org/saagroups/ead/>.
151
4.3.3. Syntaxanalyse
Es ist unerlässlich, ein EAD-Dokument auf Konformität mit den Spezifikationen der
DTD zu prüfen. Das muss regelmäßig während des Authoring-Prozesses geschehen,
um bei der Kodierung aufgetretene Fehler zu finden. Und es muss als letzter
Arbeitsgang vor der Veröffentlichung eines kodierten Findbuchs durchgeführt
werden. Dieser Prozess ist als Syntaxanalyse bekannt und kann auf verschiedene
Art und Weise erfolgen (weitere technische Informationen zur Syntaxanalyse siehe
Abschnitt 6.2.4). Native SGML- und XML-Editoren sowie Programme wie
WordPerfect und Framemaker + SGML haben eingebaute Syntaxanalysatoren, die
eine ständige Prüfung auf DTD-Konformität durchführen. Es gibt auch zahlreiche
eigenständige Syntaxanalysatoren, die kostenlos erhältlich sind. James Clarks
Programm gilt als eines der besten für SGML, es kann auch für XML konfiguriert
werden.79 Weitere kostenlose XML-Syntaxanalysatoren sind von IBM/Lotus,
DataChannel und Microsoft erhältlich. Bei XML-Syntaxanalysatoren muss man ein
wenig Vorsicht walten lassen, da einige von ihnen nur Validatoren sind. Das heißt,
dass sie XML-Dateien nur auf „Wohlgeformtheit“ und nicht auf Konformität mit der in
Betracht kommenden DTD prüfen.
4.3.4. Datenaustausch zwischen MARC-Titelaufnahmen und EAD-Findbüchern
Zahlreiche Archive (besonders in den USA) erstellen nicht nur elektronische
Findbücher, sondern auch MARC-Titelaufnahmen für jeden in einem EAD-Findbuch
beschriebenen Bestand, und möglicherweise ergeben sich durch einen
Datenaustausch zwischen diesen beiden elektronischen Dateien Vorteile bei den
Arbeitsabläufen (die Beziehung zwischen Titelaufnahmen und Findbüchern ist in
Abschnitt 1.6 beschrieben). Die Migration von Daten kann in beiden Richtungen
vorgenommen werden: von dem Findbuch zur MARC-Titelaufnahme und umgekehrt.
Das richtet sich nach Faktoren wie der Beziehung der Findbuchdaten zu der MARCTitelaufnahme, der Reihenfolge ihrer Erstellung und den Arbeitsabläufen in der
betreffenden Institution. Zwei Verfahren des Datenaustauschs sind derzeit möglich.
Die Betriebssysteme von Windows und Mac OS ermöglichen die Datenübertragung
von einer Anwendung zur anderen (über die Zwischenablage bzw. das Scrapbook),
und daher ist es einfach, Text durch Ausschneiden und Einfügen zwischen einer
Titelaufnahme und einem Findbuchdokument zu übertragen. Man braucht lediglich
die Katalogbearbeitungssoftware und die EAD-Authoring-Anwendung gleichzeitig in
getrennten Fenstern auf dem Desktop zu öffnen und die gewünschten Informationen
zu übertragen. Das kann von besonderem Nutzen sein, wenn das vorhandene alte
Findbuch nur ein Bestandsverzeichnis enthält und mit dem Inhalt einer MARCTitelaufnahme kombiniert werden kann, die zusammengefassende,
Kontextinformationen enthält, z. B. eine Scope and Content Note.
Bei einigen Archiven ist ein stärker automatisiertes Verfahren erforderlich, um große
Mengen solcher Daten im Stapelverarbeitung zu übertragen. Eine Möglichkeit
besteht darin, ein eigenes Programm für die Umwandlung der Daten von MARC in
EAD oder umgekehrt zu schreiben. Es ist auch möglich, die von der Library of
Congress entwickelte MARC-DTD zu verwenden. Ein einfaches DOS-Programm von
Logos Research80 wandelt Titelaufnahmen vom MARC-„Übertragungsformat“ in die
79
Das SP-Programm von James Clark ist verfügbar unter: <http://www.jclark.com>.
Die MARC-Quellen von Logos Research sind verfügbar unter: <http://www.logos.com/marc> (A.d.Ü.: Webseite nicht mehr
existent).
80
152
MARC-DTD-Struktur und umgekehrt um. Außerdem bietet die Library of Congress
zwei kostenlose Programme in Perl an, um Titelaufnahmen zwischen diesen beiden
Formaten umzuwandeln.81 Nachdem eine MARC-Titelaufnahme in die MARC-DTDStruktur umgewandelt worden ist, können die Daten mit einer entsprechenden
Anwendung von der MARC-DTD-Syntax in die geeignete EAD-Syntax umgewandelt
werden. Derartige Umwandlungen lassen sich mit verschiedenen Werkzeugen
durchführen, z. B. mit einem XSL-Prozessor in Verbindung mit einem XSL-Stylesheet
(XSL und Stylesheets werden in Abschnitt 5.3.3.2 behandelt). Eines dieser
Werkzeuge ist PatML, ein Freeware-Produkt von IBM.82
Vielleicht ermöglicht es die Weiterentwicklung des xml:namespace-Standards,
Informationen in eine einzelne EAD-Instanz aufzunehmen, die in mehr als einer DTD
kodiert wurden. Dadurch steht u. U. künftig eine dritte Option offen, mit der MARCDaten in MARC-DTD-Struktur unmittelbar in die EAD-Instanz übernommen werden
können, ohne zuerst die Umwandlung in das EAD-Format vornehmen zu müssen.
4.3.5. Auswirkungen verschiedener Kodierfunktionen auf die Ausgabe
Wenn sich auch die Auszeichnung mit EAD auf die Bezeichnung von Inhalt und
Struktur des Findbuchs konzentriert, so gibt es doch einige Aspekte der Kodierung,
die die Ausgabe von Dokumenten – sowohl online als auch als Druckfindbuch –
beeinflussen können. Dazu gehören Whitespace, Zeichensetzung, Schlagwörter,
Tabellen und bestimmte andere Elemente und Attribute.83 Bei der Anwendung der
folgenden Empfehlungen muss man sich dessen bewusst sein, dass es aus Gründen
der Einheitlichkeit von Findbüchern in Verbundkatalogen von Findbüchern
erforderlich sein kann, bestimmte Änderungen durchzuführen, um die
Systemerfordernisse zu erfüllen.
4.3.5.1. Whitespace
Bereiche in einem EAD-Dokument, die aufgrund eines Leerzeichens (z. B. zwischen
Wörtern), eines Tabulators, eines Returns oder eines Zeilenvorschubs keinen Text
enthalten, können eine Bedeutung haben. Solche Bereiche sind als Whitespace
bekannt, der in SGML innerhalb des Textes eines Dokuments erhalten bleibt, wenn
auch nicht unbedingt in der Auszeichnung, und zwar aufgrund von komplexen
Spezifikationen. Dagegen muss ein XML-Prozessor alle Zeichen, auch Whitespace,
an eine Anwendung weitergeben, in der diese Zeichen u. U. nicht erhalten bleiben.
Wir können die Art der Verarbeitung heutiger Texte durch künftige Prozessoren nicht
voraussehen. Sowohl bei SGML als auch bei XML ist es daher ratsam, den Text
nicht durch Einfügen von Whitespace – außer zwischen Wörtern – in das Dokument
zu formatieren, sondern die Darstellung vollständig von einem Stylesheet steuern zu
lassen. Zwei Beispiele mögen zeigen, wie SGML und XML mit Whitespace umgehen.
81
Die Programme für MARC der Library of Congress stehen zur Verfügung unter:
<http://www.loc.gov/marc/marcdtd/usermanual.html>.
82
Informationen über PatML vgl. <http://alphaworks.ibm.com/tech/patml>.
83
In Abschnitt 4.3.5.3 werden die Auswirkungen der Elemente <head> und <emph> sowie der Attribute LABEL und RENDER
auf die Darstellung beschrieben.
153
Wird Text in folgender Form in eine SGML-Authoring-Anwendung eingegeben:
<p>1. November:
Die Tätigkeit der Kommission begann ... </p>
so ist damit nicht gewährleistet, dass eine Wiedergabesoftware wie etwa ein Browser
den Text tatsächlich so darstellt:
1. November:
Die Tätigkeit der Kommission begann ...
Bei der z. Z. verfügbaren Software ist es viel wahrscheinlicher, dass die sechs
Zwischenräume zu einem einzigen Zwischenraum komprimiert werden. Es gibt
jedoch Fälle, in denen darauf geachtet werden muss, dass zumindest ein
Zwischenraum zwischen Wörtern erscheint. Das trifft auf Inline-Elemente zu,
insbesondere wenn sie geschachtelt sind. Man betrachte das folgende Beispiel:
<p>Der Film, <title render="italic">Shakespeare in
Love</title>, erhielt den Academy Award für den besten Film.</p>
Ohne den Zwischenraum vor dem <title>-Start-Tag und nach dem </title>-End-Tag
könnte der Text wie folgt wiedergegeben werden:
Der Film,Shakespeare in Love, erhielt den Academy Award für den besten Film.
Wo vorauszusehen ist, dass in einem bestimmten Fall Zwischenräume erforderlich
sind (wie z. B., wenn <unitdate> stets auf <unittitle> folgt) und eine einheitlich gültige
Formatregelung anwendbar ist, kann ein Stylesheet zum Einfügen von erforderlichem
Whitespace eingesetzt werden. Leider sind nicht alle Fälle so einfach
vorauszusehen. Wie im obigen Beispiel kann z. B. nicht gewährleistet werden, dass
nach jedem Auftreten von <title> ein Zwischenraum erforderlich ist, wenn <title>
innerhalb eines <p> vorkommt. In solchen Fällen sollte die Auszeichnung einen
einzigen Zwischenraum nach dem Inline-Element enthalten. Damit ist man in jedem
Fall auf der sicheren Seite. Die Verarbeitungssoftware reduziert zusätzlichen
Whitespace in der Regel auf einen einzigen Zwischenraum. Es wäre jedoch noch
problematischer, von seinem System zu erwarten, Zwischenräume einzufügen, wo
keine sind.
4.3.5.2. Zeichensetzung
Satzschlusszeichen, die am Ende des Textes innerhalb eines Elements erscheinen,
können in den Textkörper des Dokuments eingegeben oder von einem Stylesheet
gesetzt werden. Es ist ratsam, Punkte am Ende vollständiger Sätze einzugeben. Im
Übrigen ist von Fall zu Fall zu entscheiden.
Die Zeichensetzung innerhalb eines Textabsatzes muss in Form von Daten
eingegeben werden. Satzzeichen wie Doppelpunkte und Kommata, die zwischen
EAD-Elementen zwecks leichteren Erkennens oder aus Gründen der
Übersichtlichkeit gesetzt werden, können zweckmäßiger von einem Stylesheet
geliefert werden. Diese Vorgehensweise ermöglicht es, Änderungen an derartigen
Formatierungen später mit einem Minimum an Aufwand lediglich durch Änderungen
des Stylesheets durchzuführen.
154
Mit der Formatierungssprache XSL kann die Reihenfolge der Elemente umgestellt
werden. Solche Textumstellungen können sich auch auf die Zeichensetzung bei der
Ausgabe auswirken. Elemente, die ursprünglich in einer bestimmten Reihenfolge
eingegeben und durch Satzzeichen getrennt wurden, können bei der Darstellung in
eine andere Reihenfolge gebracht werden. Bei der folgenden Auszeichnung kann die
eingebettete Zeichensetzung im Element <unittitle>
<unittitle>Unterlagen,<unittitle><unitdate>1975-1997</unitdate>
in einem Fall ordnungsgemäß wie folgt dargestellt werden:
Unterlagen, 1975-1997
Wenn dieser Text jedoch „außerhalb der Zeile“ präsentiert wird, steht ein
überflüssiges Satzzeichen da:
Title: Papers,
Dates: 1975-1997
Daher ist es besser, diese Zeichensetzung für Darstellungszwecke von einem
Stylesheet vornehmen zu lassen. In einigen Fällen – wie beim Element <persname>
im folgenden Beispiel – sollte die Zeichensetzung innerhalb der Auszeichnung
eingegeben werden. Der Grund besteht darin, dass nicht immer vorhersehbar ist, ob
auf ein <persname>-Element in einem <p> stets ein Komma folgt. Außerdem ist es
unwahrscheinlich, dass dieser Text nochmals zu Darstellungszwecken angefordert
wird. Da der Text aber zur Indexerstellung extrahiert werden könnte, ist es ratsam,
das zweite Komma außerhalb des <persname>-Elements zu setzen, so dass es nicht
ungewollt als Teil des Namens behandelt wird:
<p>Der Autor, <persname altrender="bold">Bill Smith</persname>,
wurde 1912 geboren.</p>
4.3.5.3. Kopfzeilen / Überschriften
Das Element <head>, das in EAD an vielen Stellen verfügbar ist, und das Attribut
LABEL, das nur in den <did>-Subelementen verfügbar ist, bieten zwei Verfahren zur
Aufnahme von Text, mit dem bestimmten Abschnitten eines Findbuchs eine
Bezeichnung oder eine Überschrift zugewiesen wird.84 Die Phrase „Gegenstände des
Bestandes”) am Anfang eines <scopecontent>-Elements ist ein Beispiel für eine
solche Überschrift. Allerdings kann es langfristig vorteilhaft sein, solche
Darstellungen über ein Stylesheet zu bewirken, anstatt die Überschrift tatsächlich
mittels <head> oder LABEL in dem Findbuch zu kodieren, da das Stylesheet eine
Änderung aller Überschrifteninformationen erlaubt.
Andererseits kann der Inhalt einer Überschrift in einem bestimmten Findbuch auf
eine Weise eindeutig sein, wie es ein Stylesheet nicht erkennen kann bzw. wie es
aus anderen Textteilen im Dokument nicht hervorgeht; dann lässt sich <head> ideal
einsetzen.85
84
Der Unterschied zwischen <head> and LABEL ist in Abschnitt 3.5.1.1 beschrieben.
Es ist zu beachten, dass die gleichen Vor- und Nachteile von Stylesheets auch im Zusammenhang mit dem Element <emph>
und dem Attribut RENDER zu verzeichnen sind.
85
155
4.3.5.4. Tabellendarstellung
Findbücher präsentieren Daten oft in Spalten oder Tabellen. Typische Beispiele sind
nach Jahr und Ereignis geordnete tabellarische Aufstellungen biografischer Daten
oder die Anordnung von Kisten- und Ordnernummern bzw. Mikrofilmrollennummern
und Behälternummern bei Bestandsverzeichnissen. Solche Darstellungen kann man
als Kalkulationstabellen betrachten: eine Reihe von Zellen, die Daten in einem
Raster von Zeilen und Spalten enthalten. Elemente wie <date> und <event>
definieren die Daten, die die Informationen in jeder „Zelle” einer Tabelle bilden. Sie
werden dann in ein <chronlist>-, <list>- oder <table>-Element eingefügt. Die
gewünschte tabellarische Aufmachung auf der Grundlage dieser Auszeichnung kann
durch ein Stylesheet festgelegt werden. Dann muss nicht eigens angegeben werden,
dass jedes <event> eine gesonderte Zelle bedeutet.
Innerhalb des <dsc>-Elements hat EAD indessen ein optionales Modell für Tabellen,
in dem die ausdrückliche Spezifikation für jede Zelle erforderlich ist, wobei <drow>und <dentry>-Tags vor und hinter ihnen angeordnet werden. Die Erfahrungen mit
EAD haben jedoch gezeigt, dass zweckmäßige Tabellendarstellungen in <dsc> und
anderen Bereichen eines Findbuchs mit Hilfe von Stylesheets erzeugt werden
können, wodurch diese zusätzliche Ebene der Tabellenauszeichnung überflüssig
wird. Tabellen können mit den Formatierungssprachen Cascading Style Sheets
(CSS) und Extensible Style Language (XSL) erzeugt werden
(Formatierungssprachen siehe Abschnitt 5.3.3). Daher ist das Tabellenmodell mit
<drow> und <dentry> nicht standardmäßig in der EAD-DTD enthalten und wird auch
nicht im Anwenderleitfaden im Einzelnen behandelt, allerding ist seine Anwendung in
der Tag-Library dokumentiert.86
Wenn man das Tabellenlayout aufrufen möchte, muss der Abschnitt der Datei
ead.dtd geändert werden, der den Titel "<!-- TABULAR DSC
INCLUSION/EXCLUSION -->" trägt. Dies kann auf zwei Arten geschehen:
•
•
Änderung des Wertes ,IGNORE’ in der Entität <!ENTITY % tabular 'IGNORE'
> in ,INCLUDE’;
Änderung des Wertes ,INCLUDE’ in der Entität <!ENTITY % nontabular
'INCLUDE'> in ,IGNORE’.
86
Encoded Archival Description Tag Library, Version 1.0, ed. by Society of American Archivists, Chicago 1998, S. 33-35, 108109, 115-116.
156
4.4. Dokumentenkontrolle
Im Laufe der Erstellung von EAD-Dokumenten werden die Konsistenz der Daten und
ein effektives Management der verschiedenen elektronischen Dateien rasch zu
bedeutenden organisatorischen Aufgaben. Diese fallen in fünf größere Kategorien:
•
•
•
•
•
Einheitliche Kodierung
DTD-Konformität
Dateinamen und Speicherstellen
Versionskontrolle
Datensicherheit.
4.4.1. Einheitliche Kodierung
Sie sollten nicht nur die in der EAD-Tag-Library und im Anwenderleitfaden
enthaltenen Anleitungen beherrschen, sondern auch Richtlinien für vor Ort „erprobte
Arbeitsverfahren“ entwickeln, die Festlegungen zu EAD-Elementen und -Attributen,
deren Beziehungen zueinander, der Reihenfolge, in der sie zur Strukturierung eines
vollständigen Findbuchs verwendet werden sollen, der Detailtiefe beim Taggen von
Eigennamen u. ä. treffen. Unabhängig davon welche Software zur Kodierung von
Findbüchern verwendet wird, lässt sich die Einheitlichkeit beim Kodieren mit Hilfe von
Templates verbessern.
4.4.2. DTD-Konformität
Verschiedene Arten von SGML-Software können bei der ordnungsgemäßen
Kodierung helfen, indem sie festlegen, wie und wo ein Kodierer bestimmte Elemente
und Attribute verwenden darf. Außerdem lässt sich eine fertige Datei auf SGMLKonformität prüfen, indem sie mit einen SGML-Syntaxanalysator geprüft wird.
4.4.3. Dateinamen und Speicherstellen
In dem Maße, wie die Anzahl von EAD-Dokumenten von wenigen Dutzend auf
hunderte oder gar tausende anwächst, wird die sich dadurch ergebende Menge von
elektronischen Dateien ohne geeignetes Management zu einem Problem. Es gibt
dann EAD-Dokumentdateien, Entitätsdateien mit Texten und Bildern,
Stylesheetdateien und die EAD-DTD-Dateien selbst, und für alle ist ein sorgfältiges
Dateienmanagement erforderlich.
Abschnitt 5.4 behandelt die Auswirkungen des Änderns von Dateinamen,
Strukturschemata für Dateiverzeichnisse oder Webseiten auf den
Veröffentlichungsprozess und beschreibt verschiedene Möglichkeiten zur Lösung
solcher Probleme, z. B. SGML-Kataloge, Handles und URLs. Gutes
Dateimanagement beginnt jedoch schon während des Authoring-Prozesses mit der
systematischen Zuweisung eines Standardnamensprotokolls für Dateien und einer
logischen Verzeichnisstruktur zum Anordnen der Dateien auf dem Rechner.
Außerdem wird eine Art System benötigt – eine Datei, ein Index oder sogar eine
Datenbank – , mit dem sich die verwendeten Namen nachverfolgen und eindeutigen
und aussagekräftigen Bezeichnungen der Bestände verbinden lassen, die im
elektronischen Findbuch beschrieben sind. Dies ist erforderlich, um ein vernünftiges
Management zu gewährleisten und den ordnungsgemäßen Systembetrieb für das
Kodieren, Darstellen und Recherchieren zu ermöglichen.
157
4.4.4. Versionskontrolle
Lange vor der Entwicklung von EAD gehörte es in Archiven zur Routine, vorhandene
Findbücher zu aktualisieren, um neu in die Bestände eingefügte Materialien
aufzunehmen, verbesserte Arbeitsverfahren anzuwenden oder die
Erschließungsangaben auf den neuesten Stand zu bringen. Daher sind sich
Archivare bewusst, wie wichtig es ist, frühere Versionen eines Findbuchs zu
dokumentieren, damit Anfragen zu diesen Versionen beantwortet werden können. In
dem Maße, wie Findbücher mit EAD-kodiert werden und in größerer Menge zur
Verfügung stehen, kann sich die Häufigkeit neuer Versionen erhöhen, was sowohl
auf die wenig aufwendige Erstellung dieser neuen Versionen als auch auf
Rückmeldungen von Benutzern zurückzuführen ist. Daher ist es wichtig, bei den
Archivmitarbeitern ein Bewusstsein für den Wert solcher Aufzeichnungen zu
schaffen.
In diesem Zusammenhang ist u. U. das Subelement <revisiondesc> innerhalb von
<eadheader> von Nutzen (weitere Informationen siehe Abschnitt 3.6.1.4). Eine
Dokumentation der für die Kodierung entwickelten Arbeitsabläufe ist ebenfalls
hilfreich.
4.4.5. Datensicherheit
Wie alle wichtigen Dateien sind auch die Findbuchdateien regelmäßig zu sichern.
Mindestens ein Satz Sicherungskopien ist an einem anderen Ort zu lagern.
Außerdem sollte man auf dem System Virenschutzprogramme verwenden. Benutzer
sollten nur Lesezugriff auf Kopien von Findbuchdateien und niemals Lese-/SchreibZugriff auf die Originaldateien erhalten.
158
Kapitel 5: Die Veröffentlichung von EAD-Dokumenten
5.1. Überblick über den Veröffentlichungs-Prozess ........................................................................ 160
5.2. Recherche von Erschließungsinformationen............................................................................ 161
5.2.1. Auflistung auf einer Webseite ............................................................................................ 161
5.2.2. Verknüpfung von Findbüchern mit MARC-Titelaufnahmen ............................................... 162
5.2.3. Software für Volltextsuche ................................................................................................. 163
5.3. Bereitstellung von Erschließungsinformationen ....................................................................... 165
5.3.1. Textdarstellung durch Browser .......................................................................................... 165
5.3.2. Optionen für die Übertragung des Dateiformats ................................................................ 166
5.3.2.1. SGML-Format .............................................................................................................. 166
5.3.2.2. XML-Format................................................................................................................. 167
5.3.2.3. HTML-Format .............................................................................................................. 168
5.3.3. Formatierungssprachen ..................................................................................................... 169
5.3.3.1. Cascading Style Sheets (CSS).................................................................................... 170
5.3.3.2. Extensible Style Language (XSL)................................................................................ 170
5.3.3.3. Document Style Semantics and Specification Language (DSSSL) ............................ 171
5.3.3.4. Format Output Specification Instance (FOSI) ............................................................. 172
5.3.3.5. Proprietäre Formatierungssprachen............................................................................ 172
5.3.3.6. Beispiele für Stylesheets ............................................................................................. 172
5.3.4. Ausdruck von EAD-Dokumenten ....................................................................................... 173
5.4. Dateimanagement..................................................................................................................... 175
159
5.1. Überblick über den Veröffentlichungs-Prozess
Die EAD-Kodierung eines Findbuchs ist der erste wichtige Arbeitsschritt für die
elektronische Bereitstellung von Erschließungsinformationen zu einem archivischen
Bestand. Danach kann das kodierte Findbuch veröffentlicht werden. In diesem
Kapitel werden drei wesentliche Aspekte der elektronischen Veröffentlichung von
Findbüchern behandelt:
•
•
•
Recherche von Erschließungsinformationen – wie Benutzer auf der Suche
nach bestimmten Informationen im World Wide Web einschlägige Findbücher
zu Beständen auffinden
Bereitstellung von Erschließungsinformationen – wie Archive Browser,
Dateiformate (SGML, XML oder HTML) und Stylesheets verwenden können,
um EAD-Dateien darzustellen
Dateimanagement – wie Institutionen diese elektronischen Dokumente
benennen, ordnen und verwalten.
160
5.2. Recherche von Erschließungsinformationen
Eines der Hauptziele von EAD besteht darin, es Benutzern zu ermöglichen,
einschlägige Bestände zu erkennen und darin bestimmte Unterlagen zu finden. Als
Erstes muss ein Archiv ein Werkzeug bereitstellen, mit der sich Findbücher
auffinden, durchsuchen und darstellen lassen. Es gibt zwar eine Vielfalt von
Verfahren für Bereitstellung und Zugang, darunter Zusammenstellungen von
Beständeinformationen auf CD-ROM oder Bereitstellung über eine Client-ServerAnwendung über ein Local Area Network (LAN). Heutzutage entscheidet man sich
jedoch meist dafür, die Browser-Technologie anzuwenden, entweder über das World
Wide Web oder über ein lokal vorhandenes Intranet. Derzeit sind drei Verfahren (die
auch miteinander kombiniert werden) üblich, um Zugang zu Findbüchern zu bieten:
•
•
•
Auflistung von Findbüchern auf einer Webseite
Verknüpfung von Findbüchern mit MARC-Titelaufnahmen in Online-Katalogen
Angebot eines Direktzugangs zu den Daten über Software für Volltextsuche.
5.2.1. Auflistung auf einer Webseite
Für Archive mit Zugang zu einer Webseite ist es die einfachste Art der
Veröffentlichung, HTML kodierte Standard-Webseiten mit Verweisen auf Bestände zu
erstellen, für die es EAD-Findbücher gibt. Die Verweise können die Form kurzer
Einträge haben (z. B. in einem Archivführer). Sie können in einen erläuternden oder
bibliografischen Text über einen Aspekt der Bestände der Institution eingebettet sein
und sie können als einfache Bestandslisten dargestellt werden, die nach Bearbeiter,
Archiv, Überlieferungsgebiet oder Themen sortiert sind. Beispiele für diesen
Lösungsansatz reichen von einfachen Listen, die die Bezeichnungen der in der
Institution aufbewahrten Beständen enthalten, über nach größeren Themenbereichen
geordneten Bestandsgruppen bis hin zu Listen mit kurzen Bemerkungen zum Inhalt
jedes Bestandes in der Art einer kommentierten Bibliografie. Der Einstieg in die
Findbücher kann durch Anwahl eines Hyperlinks auf der Webseite erfolgen, mit dem
sich das EAD-Dokument aufrufen und in den eigenen Browser laden lässt. Bei
diesem Szenario kann der Inhalt mehrerer Findbücher nicht gleichzeitig durchsucht
werden. Wenn man ein Findbuch auf den eigenen Rechner heruntergeladen hat,
kann man allerdings die Suchfunktionen des Browsers nutzen, um den Inhalt des
Dokuments nach Stichwörtern abzufragen.
Damit das Archiv alle Dateien im Web unterbringen kann, erfordert dieses Verfahren
viel Speicherplatz auf der Webseite. Außerdem müssen die Mitarbeiter in der Lage
sein, HTML kodierten Seiten zu erstellen.
Vorteile: Wenn Zugang zu einer Webseite besteht, ist dieses Verfahren
verhältnismäßig leicht und kostengünstig.
Nachteile: Das Einzige, was anfangs Benutzer zum Inhalt eines Bestandes erfahren,
sind die Informationen, die auf der Seite mit dem Link zum Bestand zur Verfügung
stehen. Das kann die Auswahl einschlägiger Findbücher ziemlich mühselig machen.
161
5.2.2. Verknüpfung von Findbüchern mit MARC-Titelaufnahmen
Viele Archive in den USA benutzen MARC-basierte Online-Kataloge als Einstieg in
ihre Bestände. Eine zunehmende Anzahl solcher Kataloge verfügen mittlerweile über
Webschnittstellen. Sie sind damit eine weitere Möglichkeit zur Benutzerbereitstellung
von Findbüchern.
Zum USMARC-Format gehört auch Feld 856, das zur Aufnahme eines Verweises auf
eine externe elektronische Ressource dient, z. B. ein EAD-kodiertes Findbuch, das
sich auf den in der entsprechenden MARC-Titelaufnahme beschriebenen Bestand
bezieht. Feld 856 kann für diese Ressource eine URL (Uniform Resource Locator)
enthalten. Webschnittstellen zu Online-Katalogen geben die URL als Hyperlink
wieder, die bei Anwahl im Browser die zugehörige Datei, in diesem Fall ein Findbuch,
darstellt. Archive, die einen URN (Uniform Resource Name) verwenden, können
ihren global eindeutigen Identifikator als „Handle” in Feld 856 aufnehmen.
856 42
$3 finding aid $d eadpnp $f pp9960001 $g
urn:hdl:loc.pnp/eadpnp.pp996001 $u
http://hdl.loc.gov/loc.pnp/eadpnp.pp996001
856 42
$ 3 Eine elektronische Version des Inventars
dieses Bestandes ist erreichbar unter $u
http//www.mnhs.org/library/findaids/00020.xml
Bild 5.2.2a Zwei Beispiele des USMARC 856-Feldes. Das erste enthält einen
URN ($g) gefolgt von einer URL ($u). Das zweite Beispiel enthält nur eine
URL ($u).
Vorteile: Die technischen Erfordernisse für diese Vorgehensweise sind
verhältnismäßig gering und kostengünstig, wenn der betreffende Online-Katalog über
eine Webschnittstelle verfügt. Die MARC-Titelaufnahme muss durch Eingabe der
entsprechenden Verknüpfungsdaten in das MARC-Feld 856 ergänzt werden.
Außerdem wird auf einem über das Web zugänglichen Server Platz für die EADDateien benötigt.
Bei diesem Verfahren werden bereits vorhandene Indizes des Online-Katalogs, die
Informationen zum Kontext und Inhalt jedes Bestandes enthalten, genutzt. Dieses
Verfahren ahmt vorhandene zweistufige Findbuchsysteme nach, bei denen Benutzer
zuerst den Katalog nach Namens-, Orts- oder Themenschlagwörtern eines
Bestandes durchsuchen und dann zu einem Findbuch in einer gesonderten Datei
geführt werden, um genauere Informationen zu bekommen. Mit der Einführung von
MARC-Katalogen in vielen Archiven wurde der erste Teil dieses Prozesses (das
Nachschlagen im Online-Katalog) automatisiert. Mit dem Online-Zugang zu EADDateien wird dies in dem Maße, wenn die MARC-Aufnahme dynamisch mit dem
Online-Findbuch verknüpft wird, zu einem vollständig elektronischen Prozess.
Nachteile: Bei diesem Szenario wird vorausgesetzt, dass MARC-Titelaufnahmen für
Bestände sowie ein über das Web zugänglicher Online-Katalog zur Verfügung
stehen. Die Kosten für das Erstellen von MARC-Titelaufnahmen bzw. für das
Installieren eines Online-Katalogs mit dem einzigen Zweck, Findbücher zugänglich
zu machen, können recht hoch sein. Es können dann auch laufende Kosten für die
Pflege der Verknüpfungen zwischen der Titelaufnahme und der EAD-Datei entstehen
(Abschnitt 5.4 enthält eine Erörterung zum Dateimanagement).
162
Die Verwendung eines Katalogs als Weg zu Findbüchern bietet viele Sucheinstiege
in den Bestand. Benutzer können allerdings immer noch nicht im vollen Text des
Findbuchs suchen. Ob dies ein Nachteil oder ein Vorteil ist, ist Ansichtssache.
Einerseits wird es als nicht voll zufriedenstellend angesehen, da eine Volltextsuche
durch den reichhaltigen Inhalt einer oder mehrerer Findbücher nicht möglich ist.
Andererseits wird das Argument angeführt, dass die knappe Katalogbeschreibung,
bei der die Zugriffsbegriffe eine standardisierte Form haben, eine nützliche
Filterfunktion ausübt, da sie die Suchergebnisse auf die Aspekte des Bestandes
beschränkt, die als ausreichend wichtig für die Aufnahme in eine Übersicht
angesehen werden. Dies kann aus vielen Gründen einem Bombardement mit
zahlreichen irrelevanten Treffern vorzuziehen sein, wie es bei einer Volltextsuche in
großen Findbuchdateien vorkommen kann. Die Ergebnisse einer solchen Abfrage
lassen sich damit vergleichen, dass man versuchen würde, aus einem spritzenden
Hydranten einen Schluck Wasser zu trinken.
5.2.3. Software für Volltextsuche
Das technisch anspruchsvollste und komplexeste Verfahren besteht darin, mit Hilfe
spezieller Suchsoftware eine Volltextsuche über mehrere Findbücher gleichzeitig zu
anzubieten. Mit diesen Werkzeugen können Benutzer den gesamten Inhalt mehrerer
Findbücher gleichzeitig durchsuchen, wobei es die EAD-Auszeichnung ermöglicht,
Suchanfragen auf bestimmte Datentypen, wie z. B. Titel, Laufzeit oder Namen,
einzuschränken. Die zunehmende Verbreitung des XML-Standards lässt die Anzahl
solcher Systeme ansteigen, die in der Lage sind, EAD-kodierte Dateien verarbeiten
zu können.
Die Anwendungen, die in diese große Gruppe fallen, bieten deart vielfältige
Funktionen, dass sie sich nur schwer in exakte Kategorien aufteilen lassen. Sie
reichen von Basisprodukten für Authoring und Webbereitstellung mit Such- und
Abfragefunktionen bis hin zu komplexen Dokumentenmanagementsystemen mit
vielfältigen Funktionen, die normalerweise an große Unternehmen verkauft werden
und die große Datenmengen verarbeiten können und über hochentwickelte
Veröffentlichungsfunktionen verfügen. Viele dieser Systeme sind sehr kostspielig.
Trotzdem können sie sich für große Forschungsinstitutionen mit einer Großzahl
elektronischer Texte oder für Verbünde eignen, die Online-Dienste gemeinsam
anbieten. Außerdem bieten viele Firmen für Schulungszwecke beim Einsatz ihrer
Softwäre erhebliche Rabatte, so dass die Softwarekosten eines Archivs beträchtlich
gesenkt werden können.
Die Suchmaschine Enigma von der Firma Insight, Inc., die Suchmaschine InQuery
vom Center for Intelligent Information Retrieval, die Textdatenbank BASIS von Open
Text und das Softwarepaket Dual Prism von AIS Software unterstützen die
elektronische Veröffentlichung von SGML- und XML-Dateien. Andere Anwendungen
bieten Dokumentenmanagementsoftware, z. B. das System Livelink von Open Text,
Live Publish von der Folio Products Division of Open Market, das System Epic von
Arbortext und die Produktfamilie DynaText von INSO, zu der DynaTag sowie eine
Web-Veröffentlichung-Komponente mit der Bezeichnung DynaWeb gehören.
Um auf diese Weise Zugriff auf die eigenen Bestände zu erlauben, muss ein Archiv
die Software installieren, mit der sich die Dateien kodieren und formatieren lassen,
die dann auf einem über das Web zugänglichen Server dargestellt werden
163
(Informationen zur Verwendung von Stylesheets bei der Formatierung von
Dokumenten siehe Abschnitt 5.3). Zu jedem dieser Produkte gehört eine
Suchschnittstelle, die von den Archiven teilweise oder ganz auf jeweiligen
Bedürfnisse angepasst werden kann. Bei einer typischen Abfrage geben Nutzer
Suchbegriffe ein, die an den Server weitergegeben werden. Der Server führt die
Abfrage durch und leitet dem Browser des Nutzers die Ergebnisse zu, wobei er
normalerweise zu jedem einschlägigen Bestand eine Kurzinformation liefert. Der
Nutzer oder die Nutzerin kann sodann die gewünschten Findbücher anwählen und
nacheinander herunterladen. Dieser Prozess gleicht den Auflistungen von
Buchkurztiteln, die viele Online-Kataloge anbieten, wenn eine Suche zu
Mehrfachtreffern geführt hat.
Vorteile: Der Hauptvorzug dieses Verfahrens besteht darin, dass Benutzer eine
Volltextsuche in mehreren Findbüchern gleichzeitig durchführen können, die
entweder von einem Archiv oder, wie bei einem Verbundkatalog, von mehreren
Institutionen stammen. Eine Abfrage kann Informationen über den Teil eines
Bestandes liefern, der für einen bestimmten Benutzer von Bedeutung ist, jedoch
innerhalb des Bestandes nicht umfangreich genug ist, dass er in der kurzen MARCTitelaufnahme erwähnt wird. Zahlreiche Findbücher enthalten wertvolle Informationen
zu Themen, die Benutzer auf diese Weise durchsehen können. Die Suchschnittstelle
kann so strukturiert sein, dass sie die Recherche in spezifischen inhaltsbezogenen
Auszeichnungen ermöglicht, z. B. eine Suche nach sämtlichen Daten in einem
<corpname>-Element. Nutzer werden dann dazu aufgefordert, ihre Suchanfrage auf
„Namen von Organisationen“ zu beschränken. Dieses Verfahren bietet einen
mühelosen, integrierten Einstieg in viele Bestände.
Nachteile: Suchmaschinen sind verhältnismäßig kostspielig und erfordern für ihre
Programmierung und Pflege fortgeschrittene DV-Kenntnisse. Wie bereits in Abschnitt
5.2.2 erwähnt, kann eine Volltextsuche die Trefferquote erhöhen, die Genauigkeit
vieler Suchergebnisse ist jedoch geringer. Die Art der Abfrageschnittstelle, Typ und
Detailtiefe der Kodierung sowie die Darstellung der Ergebnisse sind weitere
theoretische und praktische Themenkomplexe, die in diesem frühen Stadium der
Anwendung von EAD noch nicht hinreichend geklärt sind. Weitere Erfahrungen mit
der Datenrecherche werden helfen, Probleme bei der Verständlichkeit der
Ergebnisse für Benutzer ausfindig zu machen und Erfordernisse der
Suchschnittstelle und der Ergebnisdarstellung stärker zu berücksichtigen. Dadurch
lassen sich wiederum die Systeme weiterentwickeln.
164
5.3. Bereitstellung von Erschließungsinformationen
Ein wichtiger Schritt bei der „Veröffentlichung“ von Findbüchern ist die Übertragung
von Findbuchdateien zum Browser des Benutzers in einem Format, das von diesem
dargestellt werden kann. Ein Archiv hat mehrere technische Optionen, um dieses zu
bewerkstelligen. Die Möglichkeiten werden von der Webtechnologie bestimmt und
hängen von drei Faktoren ab, die miteinander in Beziehung stehen:
•
•
•
Aspekte der Textdarstellung durch den Browser
das zum Browser des Nutzers übertragene Dateiformat
die Verwendung von Stylesheets zur Steuerung der Dokumentendarstellung
5.3.1. Textdarstellung durch Browser
Die EAD-Auszeichnung bezeichnet nur Struktur und Inhalt des Dokuments, nicht
jedoch seine Darstellung auf der ausgedruckten Seite oder auf dem Bildschirm. Um
sie darstellen zu können, muss für die Formatierung der Datei ein eigenes Verfahren
angewendet werden. Die Lösung besteht in einem Stylesheet, d. h., einer Gruppe
von Anweisungen, in denen festgelegt ist, wie die EAD-Datei formatiert werden soll.
Die Formatierung lässt sich entweder im Archiv auf das Findbuch anwenden, bevor
es zum Nutzer übertragen wird, oder erst im Browser des Nutzers. Im letztgenannten
Fall wird das Stylesheet (das aus einer einfachen Textdatei besteht) zusammen mit
dem EAD-Dokument zum Browser übertragen, wo es anschließend verarbeitet wird.
Bevor wir etwas über Stylesheets und ihre Formate lernen, soll der Frage
nachgegangen werden, wie ein Browser SGML-, XML- oder HTML-kodierte
Textdateien verarbeiten könnte, um sie ordnungsgemäß darzustellen. In einem
typischen Szenario liest der Browser zunächst das Kodierschema des Dokuments
und interpretiert seine Struktur als Baum, wobei das Dokumentelement (siehe Bild
6.2.1b), z. B. <ead> oder <html>, die Basis des Baums ist. Beispielsweise hat der
Baum eines EAD-Dokuments zwei oder drei dickere Äste (<eadheader>,
<frontmatter> (optional) und <archdesc>). Der Ast <archdesc> teilt sich in <did>,
<scopecontent> und weitere Äste und Zweige, die sich weiter teilen, bis man
schließlich zu den „Knospen“ oder Blättern am Ende der Zweige gelangt, wo sich der
Text über den Findbuchinhalt befindet. Ein Beispiel für die grafische Darstellung
eines solchen Baums bietet sich im Windows Explorer des Betriebssystems
Windows, in dem die hierarchischen und geschachtelten Laufwerke, Verzeichnisse,
Unterverzeichnisse und Dateien auf dem PC des Anwenders dargestellt werden.
Nachdem der Baum aufgebaut worden ist, vergleicht der Browser die Datei mit der
DTD, um die Konformität zu prüfen. Eine Darstellungs-Engine im Browser bereitet
dann den Text jedes Knotens für die Darstellung auf, wobei Eigenschaften wie die
Anordnung auf dem Bildschirm sowie Größe, Art und Farbe der Schrift gesteuert
werden. Dabei werden bestimmte Regeln eingehalten, die von einem Stylesheet
festgelegt sind.
Die Formatierungsregeln (d. h. das Stylesheet) für HTML-Dokumente sind im
Browser fest verdrahtet. Mit anderen Worten, sie gehören zur Programmierung der
Browser-Software. Die Darstellung der einzelnen HTML-Elemente im Navigator oder
Internet-Explorer wird so im Voraus von Netscape oder Microsoft (auf leicht
unterschiedliche Weise) bestimmt. Dies ist möglich, weil es nur etwa 80 HTML-Tags
gibt, deren Darstellung vorher festgelegt werden muss.
165
Die standardmäßige Darstellung kann jedoch durch eine externe Stylesheetdatei
außer Kraft gesetzt werden, die die Darstellungs-Engine im Browser veranlasst, das
Dokument auf andere Weise anzuzeigen. Diese externen Stylesheets sind für HTMLDateien optional. Sie sind jedoch vorgeschrieben, wenn das zum Browser
übertragene Dokument mit XML oder SGML kodiert ist. Das ist darauf
zurückzuführen, dass eine Formatierungsfunktion für Elemente nach diesen
Schemata nicht in den Browser integriert ist. Diese Formatierung kann nicht im
Voraus festgelegt werden, da die Anzahl der Elemente, die von derzeitigen und
künftigen DTD in SGML oder XML definiert werden könnten, praktisch unendlich ist.
Aus diesem Grund muss ein Stylesheet verwendet werden.
5.3.2. Optionen für die Übertragung des Dateiformats
Ebenso wie viele Verfahren für das Authoring von EAD-kodierten Findbüchern
angewendet werden können, kann die elektronische Übertragung zu Nutzern auf
verschiedene Art und Weise erfolgen. Ein wesentlicher Faktor zur Unterscheidung
der Verfahren ist das Dateiformat, in dem das Dokument übertragen wird. Es gibt drei
Möglichkeiten: SGML, XML und HTML. Die Wahl der Methodologie für das
Stylesheet wird vom gewählten Dateiformat bestimmt.
5.3.2.1. SGML-Format
Da EAD als SGML-gestützte Anwendung ihren Anfang nahm und EAD-Dateien im
SGML-Format erstellt und gespeichert werden, erscheint es vernünftig, Benutzern
die Dokumente in ihrer ursprünglichen EAD-Kodierung zu senden. Leider haben sich
die Softwareentwickler dazu entschlossen, die SGML-Funktion nicht unmittelbar in
ihre Web-Browser einzubauen, was zumindest teilweise auf die technische
Komplexität zurückzuführen ist, die von der großen Flexibilität des Standards
herrührt. Weder der Netscape Navigator noch der Microsoft Internet Explorer können
die Struktur einer EAD-Datei in SGML-Syntax interpretieren. Man kann jedoch ein
Zusatzprogramm installieren, und zwar entweder Panorama Publisher von Interleaf
(früher von SoftQuad vertrieben) oder MultiDoc Pro von Citec, das in
Zusammenarbeit mit dem Browser eine SGML-Datei darstellen kann. Der Browser
des Benutzers ist so konfiguriert, dass bei Empfang einer SGML-Datei die
Hilfeanwendung in den Browser geladen wird, die die Datei interpretiert, den
Dokumentbaum aufbaut und die Darstellung konfiguriert.
Um SGML-Ausgaben von EAD-kodierten Findbüchern über das Web zu verbreiten,
müssen die EAD-Dateien zusammen mit den erforderlichen Stylesheets87,
Navigatoren und EAD-DTD-Dateien auf einen Server mit Webzugang geladen
werden. Die Nutzer müssen die Software von Panorama oder MultiDoc Pro auf ihre
Rechner geladen und ihren Browser ordnungsgemäß so konfiguriert haben, dass
dieser mit der Software zusammenzuarbeitet. Den EAD-Dokumenten werden
spezifischen Stylesheets zugeordnet, und zwar entweder eine in einer Katalogdatei
auf dem Server bereitgestellte Verknüpfung (siehe Unterabschnitt 6.5.2.4.1) oder mit
Hilfe der Verarbeitungsanweisung, die in jedes Findbuch eingebettet ist, und die auf
die entsprechende Stylesheetdatei verweist (ebenfalls auf dem Server gespeichert).
Verarbeitungsanweisungen (Processing Instructions (PI)) sind eine SGML-Funktion,
87
Weiteres zu Panorama- Stylesheets siehe Abschnitt 5.3.3.5. Panorama Publisher und MultiDoc Pro verwenden die gleiche
Formatierungssprache.
166
um in ein Dokument Informationen einzufügen, die für die Verarbeitung durch eine
proprietäre Softwareanwendung und nicht durch einen Syntaxanalysator bestimmt
sind.
Vorteile: Panorama und MultiDoc Pro bieten eine sehr effziente Darstellung des
Findbuchs, einschließlich eines nützlichen Navigators, der eine visuelle Straßenkarte
des Dokuments liefert, dem Nutzer den Bestand besser verständlich macht und bei
der hochentwickelten, in die Software integrierten Suche Unterstützung bietet.
Dadurch, dass das gesamte Dokument mit seiner vollständigen, strukturellen SGMLKodierung auf dem Rechner des Nutzers übertragen wird, sind eine rasche und
leistungsfähige Suche durch die Inhalte sowie ein schnelles Navigieren durch das
heruntergeladene Dokument möglich.
Nachteile: Leider ist – anders als manches andere Web-Darstellungsprogramm oder
Plug-In – keine dieser Anwendungen kostenlos erhältlich. Nutzer müssen sie
erwerben, um sich die bereitgestellten Findbücher anzeigen lassen zu können. Für
Nutzer, die nur gelegentlich Findbücher einsehen wollen oder u. U. nicht die Zeit oder
das Geld für den Erwerb dieser Software aufwenden wollen, ist dies als allgemeines
Webverbreitungsverfahren nur begrenzt hilfreich. In abgeschlossenen Umgebungen,
z. B. in einem einzelnen Archiv, einer Bibliothek oder einem Campus, ist dieses
Szenario möglicherweise besser anwendbar, da hier alle Nutzer mit der
Darstellungssoftware ausgestattet werden können. (Dieses könnte dann nicht nur zur
Darstellung von Findbüchern, sondern auch von anderen SGML-kodierten
Dokumenten, z. B. wissenschaftlichen Texten, verwendet werden.) Dazu kommt
noch, dass die von jedem Produkt verwendete Formatierungssprache zwar über
einen robusten Editor zur Verfügung steht, beide Produkte jedoch proprietär sind. Für
diese Veröffentlichungs-Umgebungen entwickelte Formatierungsspezifikationen sind
in anderen Systemen nicht nutzbar.
5.3.2.2. XML-Format
XML wurde entwickelt, um die Leistungsfähigkeit und Funktion von SGML im World
Wide Web bereitzustellen. EAD-Dokumente können XML-konform erstellt werden
(Einzelheiten siehe Abschnitt 4.3.2). In diesem Veröffentlichungs-Szenario speichert
das Archiv die EAD-kodierten Findbücher im XML-Format (und nicht in ihrem
ursprünglichen SGML-Format) auf einem Server mit Webzugang. Jede EAD-Instanz
umfasst eine Verarbeitungsanweisung, die auf die Speicherstelle des Stylesheets für
ihre Darstellung verweist. Nachdem ein Findbuch auf den Rechner des Nutzers
heruntergeladen worden ist, verwendet der Browser die auf dem Archiv-Server
bereitgestellte zugehörige Stylesheetsdatei (die entweder in CSS- oder XSL-Syntax
geschrieben ist, Näheres siehe Abschnitte 5.3.3.1 und 5.3.3.2) und verwendet dann
seine Darstellungs-Engine, um das Findbuch ordnungsgemäß anzuzeigen.
Vorteile: Wie bei SGML kann der Browser die strukturelle Auszeichnung in EAD voll
nutzen, um eine schnelle, leistungsfähige Suche im Inhalt des Dokuments
durchzuführen. Anders als bei SGML ist jedoch keine Hilfsanwendung erforderlich,
da alle benötigten Funktionen im Standard-Web-Browser enthalten sind. Der
Endnutzer braucht keine Zusatzsoftware.
167
Nachteile: Der hauptsächlichste Nachteil dieser Lösung besteht darin, dass zur Zeit
der Erstellung des Anwenderleitfadens die XML-Funktion nur im Internet-Explorer 5.0
zur Verfügung stand. Netscape will die nächste Ausgabe seines Navigators mit der
XML-Fähigkeit ausstatten. Nutzer mit älteren Browsern können Panorama Publisher
oder MultiDoc Pro als Hilfsanwendung einsetzen, um XML-Dokumente auf die
gleiche Weise darzustellen, wie sie SGML-Dateien verarbeiten. Es wird noch einige
Jahre dauern, bis eine hinreichende Anzahl von Internet-Nutzern neuere BrowserVersionen verwenden, die XML-Dateien unmittelbar verarbeiten können. Bis dahin
müssen die Archive ein anderes Übertragungsverfahren, – wahrscheinlich im HTMLFormat – anwenden.
5.3.2.3. HTML-Format
Angesichts der in Kapitel 1 gelieferten Begründung für die Kodierung von
Findbüchern in SGML oder XML mag es merkwürdig erscheinen, dass HTML als
Übertragungsformat für EAD-Findbücher vorgeschlagen wird. Es ist jedoch auf die
Verwendung des Ausdrucks „Übertragungsformat” zu achten: HTML ist ein nützliches
Werkzeug für die Verbreitung und Präsentation von Texten und Bildern. Dies sind
seine ursprünglich beabsichtigten Zwecke und hier liegen seine Stärken, trotz seiner
erheblichen Mängel als Datenspeicherungsformat.
Die Erfahrungen von Bibliotheken und Archiven bei der Verbreitung von MARCTitelaufnahmen bieten eine informative Analogie. Diese Institutionen wissen zwar
weiterhin die zahlreichen Vorteile des Erstellens, Speicherns und Durchsuchens von
Titelaufnahmen im MARC-Format zu schätzen. Sie haben jedoch rasch
Webschnittstellen für ihre Online-Kataloge eingerichtet, über die Titelaufnahmen im
HTML-Format zu Nutzern übertragen werden. Niemand hat jedoch ernsthaft
vorgeschlagen, MARC nicht mehr anzuwenden und Katalogdaten unmittelbar in
HTML zu erstellen. Denn dabei ginge die Möglichkeit verloren, gezielt in bestimmten
Datenfeldern, z. B. Verfasser, Titel oder Thema, zu recherchieren. Ein solches
Vorgehen würde die Recherche in Beständen sowie die langfristige Nutzbarkeit der
Titelaufnahmen als strukturierte Daten und nicht als undifferenzierter Text erheblich
beeinträchtigen.
Es ist möglich, aus Beidem das Beste zu machen, indem die Findbücher EAD-kodiert
und dann mit Hilfe von HTML veröffentlicht werden. Dazu muss die Auszeichnung
des Findbuchs von EAD auf die HTML-Syntax umgestellt werden. Dieser technisch
als „Transformation“ bezeichnete Prozess kann im Archiv auf zweierlei Art erfolgen.
Mehrere der weiter oben beschriebenen Veröffentlichungs-Systeme, darunter
DynaWeb und Dual Prism, können eine HTML-Version eines Findbuchs in Echtzeit
zu dem Zeitpunkt erzeugen, zu dem der Nutzer die Datei anfordert. Dies ist als
dynamische Transformation bekannt. An die jeweiligen Anforderungen angepasste
Skriptdateien – in Programmiersprachen wie Perl – arbeiten mit SGML-fähigen
Suchmaschinen zusammen, um die HTML-Version „on the fly“ zu erstellen, wobei die
Skriptdatei als Stylesheet dient, um die Daten von einem Tag-Satz auf den anderen
umzustellen. Eine weitere Softwareoption in dieser Kategorie ist die Web-ServerSoftware (IIS) von Microsoft, bei der zur Umwandlung einer XML-Datei in eine HTMLDatei ein Stylesheet in XSL verwendet werden kann. Anschließend kann die Datei
mit Hilfe der Active-Server-Page-Technologie zu Nutzern übertragen werden. Mit
zunehmender Ausgereiftheit der XML-Werkzeuge kann eine solche HTML168
Transformation sowohl auf den Rechnern der Nutzer als auch auf dem Server des
Archivs stattfinden.
Eine andere Möglichkeit besteht darin, dass ein Findbuch vom Archiv auf HTML
umgestellt und auf dessen Server gespeichert wird, bevor die Datei von einem
Nutzer angefordert wird. Zu den z. Z. angewendeten Umwandlungsverfahren
gehören Textverarbeitungsmakros, in Perl geschriebene Skriptdateien und
Transformationssoftware wie z. B. der XSL Processor von Microsoft. Die AuthoringSoftware Internet Archivist hat einen integrierten SGML/HTML-Konverter. Das
Problem bei solchen a-priori-Transformationen besteht darin, dass einige Funktionen
des Stylesheets verloren gehen. Muss die Dokumentstruktur verändert werden, wird
die mit SGML kodierte Originaldatei aktualisiert und die HTML-Version neu erzeugt.
Bei diesem Szenario muss daher jedes Findbuch einzeln erneut bearbeitet werden.
Andererseits entsprechen bei der dynamischen Transformation die Ergebnisse, die
Benutzer auf ihren Browsern angezeigt bekommen, den jeweils neuesten Versionen
der Findbücher, ohne dass die Dokumente einzeln erneut bearbeitet werden
müssen.
Vorteile: Die Übertragung von Findbüchern im HTML-Format löst das unmittelbare
Problem, dass derzeit noch nicht alle Nutzer SGML- bzw. XML-Dateien lesen
können. HTML-Dokumente können mit jedem Browser angezeigt werden, ohne dass
zusätzliche Maßnahmen nötig sind. Da Standard-HTML-Tags verwendet werden,
muss kein zusätzliches Stylesheet erstellt werden.
Nachteile: Sofern die Zugangs- und Abfrageumgebung es dem Nutzer nicht
ermöglicht, in dem EAD-kodierten Originaldokument zu recherchieren, geht die
Möglichkeit der strukturierten Suche verloren. Diese Beschränkung wird bestehen
bleiben, solange die Datei auf den Rechnern der Nutzer nur die
Darstellungsauszeichnung von HTML enthält. Ein weniger bedeutender potenzieller
Nachteil ist es, dass die Archivmitarbeiter sowohl die HTML-Syntax als auch die
Transformationssprache kennen müssen, um diese Übertragungsmöglichkeit zu
nutzen. Dadurch, dass sowohl eine SGML- oder XML-Quelldatei als auch eine
HTML-Darstellungsdatei zu jedem Findbuch gespeichert wird, erhöht sich der
Speicherplatzbedarf, und möglicherweise verdoppelt er sich sogar. Durch Pflege und
Aktualisierung von jeweils zwei Versionen zu jedem Dokument ergeben sich
zusätzliche Kosten. Für die Verarbeitung werden Dateimanagement und
Arbeitsabläufe komplizierter.
5.3.3. Formatierungssprachen
Es gibt mehrere standardisierte „Sprachen” zum Schreiben von Stylesheets, darunter
Cascading Style Sheets (CSS), Extensible Style Language (XSL), Document Style
Semantics and Specification Language (DSSSL) und Format Output Specification
Instance (FOSI). Manche Softwareprodukte verwenden proprietäre
Formatierungssprachen. XSL und DSSSL können nicht nur als
Formatierungssprachen, sondern auch zur Transformation von Dateien von einem
Kodierschema zum anderen eingesetzt werden, wie weiter oben beschrieben.
Ein Archiv hat zwar viele verschiedene Findbücher, wahrscheinlich werden jedoch
nur wenige Stylesheets benötigt, jeweils für jedes Findbuchformat (z. B. eine Vorlage
für kleine Bestände und eine für komplexere Findbücher oder eine für
Schriftgutbestände und eine für Mikrofilme). Ein großes Potenzial gibt es für die
169
gemeinsame Entwicklung und Nutzung von Stylesheets durch mehrere Institutionen,
wobei Archive Stylesheets aus einem Pool von Modellen entnehmen und ggf. für ihre
Zwecke anpassen. Die sich so ergebende Standardisierung der Gestaltung von
Findbüchern sowohl innerhalb einzelner Archive als auch im gesamten Archivwesen
könnte stark dazu beitragen, bei Benutzern das Verständnis für diese komplexen
Informationswerkzeuge zu verbessern und Vertrautheit zu schaffen. Außerdem
würde eine gemeinsame Entwicklung und Nutzung die Verbreitung von Findbüchern
erleichtern. Für die gemeinsame Nutzung von Stylesheets ist es jedoch erforderlich,
dass innerhalb einzelner Archive und im gesamten Archivwesen eine wesentliche
Übereinstimmung über das Formats besteht, in dem Findbücher kodiert und
dargestellt werden sollen. Dazu müssen natürlich Entscheidungen über das Layout
am Bildschirm oder als Druckfindbuchseite getroffen werden. Die Verwendung bzw.
das Nichtverwendung bestimmter EAD-Elemente wird sich auf die gemeinsame
Nutzung auswirken, insbesondere wenn es um Altdaten geht.
5.3.3.1. Cascading Style Sheets (CSS)88
Die CSS-Spezifikation wurde ursprünglich als Verfahren für Web-Autoren entwickelt,
um die „Standard”-Darstellung von HTML-Dateien in Browsern zu ändern. Die erste
Version von CSS, auch als Stufe 1 bekannt, konzentrierte sich auf grundlegende
Präsentationsangelegenheiten, z. B. Seitenränder, Einrückungen und
Schriftartmerkmale, wie z. B. Größe, Hervorhebung, Familie und Farbe. Anfänglich
war die Unterstützung für CSS beim Netscape-Navigator und beim MicrosoftInternet-Explorer begrenzt und nicht immer vorhanden.
Im Mai 1998 wurde die robustere Stufe 2 vom World Wide Web Consortium (W3C)
als offizielle Web-Empfehlung verabschiedet. Microsoft und Netscape kündigen für
ihre nächsten Softwareausgaben volle Unterstützung für Stufe 2 an, die erheblich
erweiterte Formatierungsmöglichkeiten wie Tabellen sowie Spezifikationen für die
Druckausgabe von Findbüchern und Bildschirmdarstellungen bietet.
Die Funktionsweise ist einfach. Wenn der Browser den Dokumentbaum erzeugt,
wendet er CSS-Formate auf Elemente in der Reihenfolge an, wie sie im Dokument
vorkommen. Diese Formate können entweder auf XML- oder auf HTML-Dokumente
angewendet werden, und zwar entweder durch Einbettung der Formatspezifikationen
unmittelbar in das Dokument oder durch Verknüpfung der kodierten Datei mit einer
gesonderten Stylesheetdatei über einen HREF-Link oder eine
Verarbeitungsanweisung im Findbuch.
5.3.3.2. Extensible Style Language (XSL)89
XSL wurde vom World Wide Web Consortium (W3C) eigens für die Anwendung im
Zusammenhang mit XML entwickelt und verabschiedet. Diese Sprache umfasst
Funktionen von CSS und DSSSL (siehe Abschnitt 5.3.3.3). Die erste Ansätze zur
XSL erschienen im November 1997 als W3C-Mitteilung, darauf folgte im August 1998
der erste Arbeitsentwurf. Die endgültige Verabschiedung von XSL als offizielle
Empfehlung wird nicht vor Sommer 1999 erwartet.*
88
Vgl. Informationen des World Wide Web Consortium zu Cascading Style Sheets: <http://www.w3.org/Style>.
Vgl. Informationen des World Wide Web Consortium zur Extensible Style Language: <http://www.w3.org/Style>.
Informationen zu diesem Thema ebenfalls unter Cover, Robin: The SGML/XML Webpage, <http://www.oasis-open.org/cover>.
*
A.d.Ü.: XSL wurde 2001 verabschiedet.
89
170
Die Anhänger von XSL beschreiben sie als Formatierungssprache, die robuster als
CSS und für den Einsatz bei komplexeren Darstellungssituationen geeignet ist. Mit
Sicherheit ist die Musterabgleich- und Formatierungssyntax bei XSL höher entwickelt
als bei CSS, wenn damit auch eine höhere Komplexität einhergeht. XSL kann nicht
nur zur Formatierung, sondern auch zur Transformation von Daten von einer Syntax
zur anderen dienen.
XSL wendet Formate anders an als CSS. Wenn der Dokumentbaum aufgebaut
worden ist, erzeugt XSL einen zweiten Baum, den Ausgabebaum. Daher kann sich
die Struktur der Ausgabe von der der Quelle unterscheiden. Der Leser kann sich z.
B. dafür entscheiden, den Lagerungsort <physloc> eines Gegenstandes vor seinem
Titel <unittitle> darstellen zu lassen, auch wenn <physloc> in der EAD-Instanz auf
<unittitle> folgt. Ein XSL-Stylesheet kann die Elemente im Ausgabebaum neu
anordnen, ohne dass das Quelldokument geändert werden muss, anschließend
werden die Formate auf den Ausgabebaum angewendet. Diese Eigenschaft von XSL
ermöglicht es auch, die Daten an anderen Stellen in der Darstellung zu wiederholen,
z. B. durch Extrahieren von Überschriften, um ein gesondertes Inhaltsverzeichnis zu
erzeugen, wobei die Überschriften auch an der Stelle ihres Auftretens im Findbuch
dargestellt werden. XSL bewirkt die Darstellung entweder mit Hilfe eigener
detaillierter Formatobjektspezifikationen oder durch Anwendung der einfacheren
Darstellungssprache HTML. Dies alles ist bei CSS, wo die Formatierung unmittelbar
auf den Dokumentbaum angewendet wird, nicht möglich.
Das verhältnismäßig lange Verabschiedungsverfahren für XSL hat indessen die
Entwicklung von Anwendungssoftware, einschließlich der Einbindung von XSL in den
Internet Explorer 5.0 von Microsoft, nicht gehemmt. Mehrere experimentelle
Werkzeuge sind erhältlich, darunter XT und Jade von James Clark, die XSL-Engine
von Koala und der „technologische Vorgriff“ MSXSL von Microsoft.
5.3.3.3. Document Style Semantics and Specification Language (DSSSL)90
DSSSL wurde von der SGML-Gemeinschaft als Alternative zu den vorhandenen
herstellerabhängigen Formatierungssprachen entwickelt, die früher der Standard in
der SGML-Veröffentlichungs-Industrie waren. Zwar hat sich DSSSL nie in größerem
Rahmen durchgesetzt, es gibt jedoch nichtkommerzielle Anwendungen wie das
Programm Jade von James Clark, die DSSSL zur Erzeugung von Ausgaben in vielen
verschiedenen Formaten verwenden. Außerdem wurde DSSSL offiziell als ISOStandard verabschiedet. Wie XSL kann auch DSSSL als Transformationssprache
verwendet werden. Sie hat auch als Grundlage für zahlreiche andere Aspekte von
XSL gedient.
90
Vgl. Informationen des World Wide Web Consortium zur Document Style Semantics and Specification Language:
<http://www.w3.org/Style> und weitere Informationen vgl. Cover, Robin: The SGML/XML Webpage, <http://www.oasisopen.org/cover>.
171
5.3.3.4. Format Output Specification Instance (FOSI)91
Die FOSI wurde als Formatierungssprache zur Anwendung im Zusammenhang mit
der CALS-DTD des US-Verteidigungsministeriums entwickelt, hat sich jedoch
außerhalb der Rüstungsindustrie kaum durchsetzen können. FOSI wird derzeit in der
von Arbortext vertriebenen Software Adept eingesetzt.
5.3.3.5. Proprietäre Formatierungssprachen
Zusätzlich zu Sprachen auf der Grundlage von offenen Standards gibt es proprietäre
Formatierungsspezifikationen bestimmter Softwareprodukte. Dazu gehören die von
der Synex Corporation entwickelte Formatierungssprache, die von der Software
Panorama Publisher von Interleaf eingesetzt wird, und die Software MultiDoc Pro von
Citec. Wenn ein Archiv SGML-Dateien zu Nutzern dieser Anwendungen überträgt,
muss es geeignete Stylesheets (und Navigatordateien, die „Inhaltsverzeichnisse“ für
den Browser erzeugen) erstellen und dabei die interaktive Editorfunktion verwenden,
die in Panorama Publisher und MultiDoc Pro eingebaut ist. Proprietäre
stylesheetähnliche Funktionen, mit denen sich auch SGML- und XML-Dateien in
HTML-Dateien transformieren lassen, sind auch in Serversoftware wie DynaText,
DynaWeb, Livelink und Balise integriert.
5.3.3.6. Beispiele für Stylesheets
Stylesheets in CSS-, XSL- oder DSSSL-Syntax sind einfache Textdokumente, die
aus einer Anzahl von zweiteiligen Regeln bestehen. Im ersten Teil jeder Regel ist das
Element bzw. sind die Elemente in dem Dokument beschrieben, auf das sich die
Regel bezieht. Diese Assoziation kann auf dem Namen des Elements, seiner
Stellung im Dokument oder seiner Beziehung zu Elternelementen oder
Subelementen, Attributwerten oder anderen Eigenschaften beruhen. Der zweite Teil
jeder Regel ist eine Anweisung, mit der ein Aspekt der Darstellung des genannten
Elements spezifiziert wird, z. B. seine Anordnung auf dem Bildschirm oder der Seite,
der Schriftgrad, die Hervorhebung (Fett- oder Kursivdruck) oder die Farbe.
Aus den folgenden Beispielen ist ersichtlich, wie Regeln für Stylesheets in den
verschiedenen Sprachen geschrieben werden, um das Format für die Darstellung der
Laufzeitangaben in einem Findbuch festzulegen. Die Anweisungen des Stylesheets
legen fest, dass die Laufzeit des Archivguts in einer gesonderten Zeile erscheinen
soll, und zwar in der Schriftart Times New Roman, Schriftgrad 12, Farbe marineblau,
mit dem vorangestellten Wort „Dates:“.
Im ersten Beispiel wird eine XSL-Regel zur Definition der Darstellung mit Hilfe von
XSL-Formatobjekten angewendet:92
91
Robin Covers SGML/XML Web Page bietet weitere Informationen zu Format Output Specification Instance,
<http://www.oasis-open.org/cover/gov-apps.html#fosi>.
92
Die angewendete Syntax entspricht dem XSL-Arbeitsentwurf vom 16. Dezember 1998. Dieser kann sich vor der endgültigen
Verabschiedung von XSL durch das World Wide Web Consortium noch ändern.
172
<xsl:template match="archdesc[@level='collection']/did/
unitdate[@type='inclusive']"
<fo:block color="navy" font-size="12 pt" font-family="times
new roman">
Dates:
<xsl:apply-templates/>
</fo:block>
</xsl:template>
Im zweiten Beispiel wird eine XSL-Regel zur Definition der Darstellung unter
Anwendung der HTML-Formatierungskonventionen verwendet. Technisch gesehen,
handelt es sich hier um eine Transformation von XML in HTML, da ein XSLProzessor bei Anwendung dieser Regel eine mit HTML kodierte Ausgabe bewirkt:93
<xsl:template match="archdesc[@level='collection']/did/
unitdate[@type='inclusive']"
<P><FONT color="navy" face="times new roman" pointsize="12">
Dates:
<xsl:apply-templates/>
</FONT></P>
</xsl:template>
Im dritten Beispiel werden die Konventionen von Stufe 2 der Spezifikation Cascading
Style Sheets angewendet:
archdesc[level="collection"] > did >
unitdate[type="inclusive"]
{color: navy; font-family: times new roman; font-size: 12 pt}
archdesc[level="collection"] > did >
unitdate[type="inclusive"]:before
{content: "Dates:"}
5.3.4. Ausdruck von EAD-Dokumenten
EAD verbessert den Zugang zu Beständen indem es elektronische Versionen von
Findbüchern erstellen hilft. Gleichzeitig werden Archive jedoch weiterhin Ausdrucke
von Findbüchern für Sponsoren und die Mitarbeiter vor Ort sowie für andere Zwecke
anfertigen müssen. Dabei gibt es viele Möglichkeiten, deren Umsetzung teilweise von
der jeweiligen Authoring-Umgebung abhängt. Wie bereits erwähnt, verfügen native
Editoren teilweise über Druckfunktionen, andernfalls ist ein zusätzliches
Softwarepaket erforderlich, um ansprechend formatierte Druckfindbücher zu
erstellen.
SGML-Druckanwendungen können normalerweise gemeinsam mit jeder SGMLInstanz eingesetzt werden und sind nicht auf Dateien beschränkt, die mit Hilfe von
zugehörigen Authoring-Werkzeugen desselben Herstellers erzeugt wurden, obleich
die beiden Softwarepakete stark gebündelt sein können. SGML Author for Word von
Microsoft kann jedes beliebige SGML-Dokument in eine Word-Datei umwandeln, und
zwar auf die gleiche Art und Weise, wie diese Software eine Umwandlung in
umgekehrter Richtung von Word in SGML durchführt. Auch Formatierungssprachen
und andere Textverarbeitungssysteme können verwendet werden. Derzeit wird u. a.
93
Die Syntax dieses Beispiels entspricht dem XSL-Arbeitsentwurf vom 16. Dezember 1998. Dieser kann sich vor der
endgültigen Verabschiedung von XSL durch das World Wide Web Consortium noch ändern.
173
auch der DSSSL-Standard zur Erstellung von Druckfindbüchern aus SGMLAnwendungen eingesetzt. Sowohl CSS als auch XSL beinhalten die Fähigkeit zur
Erstellung von Ausdrucken, jedoch sind noch keine Implementierungen von CSS
bzw. XSL erschienen.
Institutionen, die HTML-Versionen ihrer EAD-Dokumente erstellen, könnten die
HTML-Datei als Ausgangspunkt für die Erstellung eines Druckfindbuchs verwenden.
Die Ausgabe erfolgt dann nicht über die Druckfunktion des Browsers, der
normalerweise begrenzte Formatierungsfähigkeiten besitzt, sondern durch den
Import der HTML-Datei in ein Textverarbeitungssystem (weitere Angaben zur
Verwendung von HTML-Dateien siehe Abschnitt 5.3.2.3). Mit derzeit verfügbaren
Versionen von Word lassen sich z. B. HTML-Dokumente importieren, die Tags
entfernen und das Ergebnis in ein Textverarbeitungsformat umwandeln. Wenn keine
besseren Lösungen vorhanden sind, kann man einfach die Tags aus der ASCIISGML-Datei entfernen und das Dokument manuell formatieren. FreewareProgramme in Perl sind erhältlich, mit denen die Auszeichnungen aus SGMLDokumenten herausgenommen werden können.94 Mit der Authoring-Software
Internet Archivist lässt sich auch eine einfach formatierte ASCII-Ausgabe einer EADDatei erzeugen. Andere Authoring-Werkzeuge, z. B. Author/Editor, ADEPT Editor
und XMetaL, sowie das Browser-Plug-In Panorama Publisher sind ebenfalls in der
Lage, ansprechend formatierte Druckfindbücher aus kodierten Findbüchern zu
erstellen.
94
Informationen zu Freeware-Perl-Programmen auf die Webseite über Perl: <http://www.perl.com>.
174
5.4. Dateimanagement
Wie beim Authoring-Prozess ist ein effizientes lokales Dateimanagement wichtig für
die ordnungsgemäßig funktionierende Veröffentlichungsanwendung für EADDateien. Verwendung und Funktion von Stylesheets, Katalogdateien,
Umwandlungsprogrammen und anderen Programmen und die Reihenfolge der
internen Arbeitsabläufe – alles muss dokumentiert werden. Die Versionskontrolle von
Dokumenten einschließlich eines schriftlichen Revisionsnachweises ist von
entscheidender Bedeutung, wenn Dateien auf verschiedene Weise bearbeitet
werden.
Standardisierte Konventionen zur Dateibezeichnung für die interne Speicherung
sowie Verfahren wie Datenbanken zur Dateiverwaltung und PURL-Resolver oder
Handleserver zur Pflege von beständigen Dateinamen im Internet sind für eine
langfristig stabile Programmadministration und dauerhafte Zugänglichkeit der Dateien
von entscheidender Bedeutung. Im World Wide Web kennt man das frustrierende
Erlebnis, dass man einen Hyperlink auf einer Webseite angewählt hat und den
Hinweis erhält, dass die Datei unauffindbar sei. Dieses Problem kann viele Ursachen
haben. Eine der häufigsten besteht darin, dass Ersteller Dateien inzwischen an
anderer Stelle gespeichert haben, ohne die Links zu aktualisieren, was zu ins Leere
laufenden Verlinkungen führt.
Ein einziges Online-Verzeichnis kann zahlreiche Dateien enthalten. Daher ist es eine
sinnvolle Lösung, einen Index oder ein anderes Instrument einzurichten, das die
Speicherstellen von Dateien auf dem Server und im Verzeichnis festhält. Dadurch
werden die in einem Hypertext-Link enthaltenen Informationen auf einen Verweis auf
eine unveränderliche Stelle (einen Server) begrenzt. Dort werden die Angaben zu
vielen Dateien vorgehalten werden und können – wenn sich die Speicherstellen oder
–systeme ändern – gleichzeitig aktualisiert werden. In SGML ist dies über eine
Konvention, den SGML-Katalog, möglich. Da Bilder, Texte und andere Dokumente
als Entitäten deklariert und mit ihrem Namen (nicht mit einer Adresse) in einem
SGML-Dokument genannt werden können, lassen sich Einzelheiten zu
Speicherstellen in einer externen, zentralen Katalogdatei speichern. Leider hat XML
diese Funktion nicht, so dass es erforderlich ist, dass alle Entitäten sowohl einen
relativen Entitätsnamen als auch eine spezifische Adresse in Form eines URI
enthalten.
Auch andere Lösungen sind denkbar, darunter PURL-Resolver und Handleserver,
die beide im Wesentlichen die gleiche Funktionsweise haben.
Beim Purl-Verfahren (Purl = Persistent uniform resource locator) wird eine Software
eingesetzt, die von OCLC entwickelt und kostenlos verwendet werden kann.95 Es
funktioniert wie folgt: Beim Erzeugen von Links in Webdokumenten bettet der
Bearbeiter einen PURL in das Dokument ein, anstatt eine herkömmliche URL
(Uniform Resource Locator) zu verwenden. Der PURL enthält die Internetadresse
des PURL-Servers und einen eindeutigen Namen für das Dokument, Bild oder
sonstige Objekt, das referenziert wird, und nicht die absolute Internetadresse des
Dokuments. Wenn der Link angewählt wird, schickt er eine Nachricht zum Resolver,
bei dem die vollständige Adresse für das externe Objekt gespeichert ist und der die
Abfrage dorthin umleitet. Auf dem Resolver werden absolute Internetadressen
95
Informationen zur PURL-Strategie <http://purl.oclc.org>.
175
vorgehalten, so dass dort Massenaktualisierungen von Informationen, z. B.
Namensänderungen von Servern und Verzeichnissen, möglich sind. Bei Einbettung
dieser Adressen in einzelne Dateien wäre bei Adressieränderungen die
Überarbeitung zahlreicher Einzeldokumente erforderlich.
Dieses Verfahren hat jedoch seine Grenzen. Die PURL-Software von OCLC läuft nur
auf bestimmten UNIX-Plattformen. Außerdem unterstützt die Namenskonvention mit
PURL nicht effizient Links zu bestimmten Stellen in einem Dokument, sondern nur
zum Dokument als Ganzem.
Handles sind eine Implementierung von Uniform Resource Names (URN), die von
der Corporation for National Research Initiatives (CNRI)96 entwickelt wurden.
Handles sind universell einheitliche Identifikatoren, die in einer „Namensautorität”
verzeichnet sind, etwa in der Art, wie ISBN für veröffentlichte Bücher derzeit verteilt
und registriert werden. Wenn in einem kodierten Dokument ein Handle für die
Adresse einer Ressource verwendet wird, muss ein Handleserver diesen Handle in
eine tatsächliche Adresse auflösen, bei der die gewünschte Ressource aufgefunden
werden kann. Handles und Handleserver sind eine verhältnismäßig neue
Entwicklung. Archivare, die sich für diese Lösung interessieren, finden weitere
Angaben auf der Webseite The Handle System.
96
Weitere Informationen siehe CNRI, The Handle System Webseite: < http://purl.oclc.org >.
176
Kapitel 6: Konzepte von SGML und XML
6.1. Einführung................................................................................................................................. 178
6.2. SGML-Dokumente .................................................................................................................... 179
6.2.1. Dokumenttyp-Definition (DTD) ........................................................................................... 179
6.2.2. SGML-Deklaration.............................................................................................................. 180
6.2.3. Dokumentinstanz................................................................................................................ 181
6.2.4. Sicherstellung der Regelkonformität .................................................................................. 182
6.3. Elemente................................................................................................................................... 183
6.4. Attribute..................................................................................................................................... 186
6.5. Entitäten.................................................................................................................................... 190
6.5.1. Parameterentitäten............................................................................................................. 191
6.5.2. Allgemeine Entitäten .......................................................................................................... 192
6.5.2.1. Zeichenentitäten .......................................................................................................... 192
6.5.2.2. Das Deklarieren von Entitäten im Dokumentprolog .................................................... 194
6.5.2.3. Interne Entitäten .......................................................................................................... 196
6.5.2.4. Externe Entitäten ......................................................................................................... 197
6.5.2.4.1. Extern gespeicherte zu parsende Daten .................................................................. 197
6.5.2.4.2. Extern gespeicherte nicht zu parsende Daten ......................................................... 200
177
6.1. Einführung
Um ein grundlegendes Verständnis für wichtige technische Grundlagen zu vermitteln,
bietet dieses Kapitel einen Überblick über einige wichtige Konzepte von SGMLgestützten Informationssystemen. Unterschiede zwischen SGML und XML werden
angesprochen, wo sie relevant sind.97 Sie werden ausgehend von der EAD-DTD
untersucht, wobei die meisten Beispiele unmittelbar der DTD entnommen sind.
Außerdem bietet das Kapitel Folgendes:
•
•
einen Ausgangspunkt, von dem aus man – wenn man sich dazu bereit fühlt –
weitere Informationen über SGML und XML aneignen kann
Hintergrundinformationen zu Wechselbeziehungen zwischen SGML und XML
und zu Entwicklungen, die Anwender benötigen, um die Möglichkeiten der in
Kapitel 7 beschriebenen EAD-Verknüpfungselemente zu verstehen.
Vielleicht finden einige beim ersten Durchlesen, dass Kapitel 6 zu technisch oder zu
kompliziert ist. Möglicherweise ist einiges von seinem Inhalt nicht sofort von Nutzen,
wenn man an EAD ohne oder mit begrenzten Kenntnissen über die elementare
Computertechnik herangeht. Wenn man jedoch mit der praktischen Seite der EADKodierung vertrauter ist und das Kapitel nochmals vornimmt, ist es u. U. eine größere
Hilfe. So wie man nicht unbedingt den chemischen Vorgang beim Backen verstehen
muss, um einen Apfelkuchen zuzubreiten, vorausgesetzt, man kennt die Zutaten und
mischt sie in der richtigen Reihenfolge, so werden die meisten Archivare ein EADkodiertes Findbuch ohne detaillierte Kenntnisse von SGML oder XML erstellen
können.
Andererseits kann es sein, dass andere dieses Kapitel als zu grundlegend
empfinden, wenn sie weitergehende Informationen zu SGML- oder XML-Systemen
benötigen. Der Anwenderleitfaden enthält eine umfassende Bibliographie mit
ausführlichen Quellen- und Literaturangaben, die im Falle weitergehenden
Informationsbedarfs zur Verfügung stehen (siehe die Fußnoten dieses Kapitels sowie
den Abschnitt zu SGML/XML im Literaturverzeichnis in Anhang G).
97
Im gesamten Kapitel wird vorausgesetzt, dass es sich um eine SGML-Umgebung handelt, sofern XML nicht ausdrücklich
erwähnt ist.
178
6.2. SGML-Dokumente
Der SGML-Standard (ISO 8879) stellt eine Metasprache dar, die die Komponenten
eines SGML-Dokuments definiert.98 Zu diesen Komponenten gehören:
•
die Dokumenttyp-Definition (DTD), in der die Auszeichnung für eine bestimmte
Kategorie von Dokumenten angegeben ist
die SGML-Deklaration, die technische Informationen zur
Verarbeitungssoftware enthält
die Dokumentinstanz, die aus einem Prolog und dem Textkörper des
Dokuments besteht.
•
•
6.2.1. Dokumenttyp-Definition (DTD)
Eine Dokumenttyp-Definition bietet eine formelle, von Menschen und Maschinen
lesbare Spezifikation der Elemente, die in einer bestimmten Dokumentenkategorie
vorkommen können, sowie die zur Darstellung dieser Elemente anwendbaren
Auszeichnung. Die Elemente haben eine logische, hierarchische Beziehung
zueinander, die in der DTD festgelegt ist. Diese enthält auch ein formelles Regelwerk
für die Reihenfolge und Häufigkeit, in der die Elemente auftreten dürfen. Bild 6.2.1a
zeigt das Konzept von SGML als Metasprache.
SGML: Spezielle Regeln zur Erstellung einer DTD
EAD DTD: Definiert die Auszeichnung
und Regeln für ein kodiertes Findbuch.
•
•
•
Elementdeklarationen
Attributdeklarationen
Parameterentitätsdeklarationen
EAD Dokumenteninstanz: Ein Prolog
(eine Dokumenttypdeklaration und alle
Entitätsdeklarationen inbegriffen)
gefolgt von mit Auszeichnungen
kodiertem Dateninhalt.
Andere DTDs: Zum Beispiel die TEIDTD, die die Auszeichnung und
Regeln für kodierte wissenschaftliche
Texte definiert.
Andere Dokumenteninstanzen:
Zum Beispiel eine TEIDokumenteninstanz.
98
Einen detaillierten Überblick über SGML bietet: C. M. Sperberg-McQueen und Lou Burnard (Eds): A Gentle Introduction to
SGML (= Kapitel 2 der Text Encoding Initiative Guidelines), <http://www-tei.uic.edu/orgs/tei/sgml/teip3sg> (A.d.Ü.: Webseite
nicht mehr existent.).
179
Die Datenstrukturen von SGML beruhen auf der Annahme, dass der Inhalt eines
Dokumenttyps, etwa ein Findbuch, als Reihe von Hierarchien beschrieben werden
kann. Ein Bestand kann z. B. Serien enthalten. Diese wiederum können Akten
beinhalten, und die Akten können sich aus einzelnen Dokumenten zusammensetzen.
Bei SGML werden diese Eltern-Kind-Beziehungen in der DTD ausgedrückt. Die
Beziehungen von Elementen zueinander lassen sich als Baum mit einer Wurzel und
einem zentralen Stamm vorstellen, der sich in immer dünnere Äste verzweigt, an
deren äußersten Enden Knospen wachsen. Bild 6.2.1b zeigt dieses Konzept am
Beispiel des Anfangs der hierarchischen Struktur von EAD. Die Basis dieser
Baumstruktur wird im Sprachgebrauch von SGML als Dokumentelement bezeichnet.
Bei einem EAD-Dokument wird sie vom Start-Tag <ead> dargestellt, der – als
Baumwurzel – den Beginn des Textkörpers einer kodierten Instanz anzeigt.
<eadheader>
<eadid>
<filedesc>
und so weiter
<titlepage>
<ead>
Dokumentelement
<frontmatter>
<div>
<archdesc>
Eltern : Kind
Eltern : Kind
<did>
<admininfo>
und so weiter
Die übrigen in
der EAD-DTD
definierten
Elemente.
Eltern : Kind
Bild 6.2.1b. EAD in einer hierarchischen Baumstruktur
6.2.2. SGML-Deklaration
Die SGML-Deklaration liefert technische Informationen zu SGML-Anwendungen, wie
z. B. Authoring- und Veröffentlichungs-Software, sowie darüber, wie SGML in der
DTD und im kodierten Dokument angewendet wird. Dazu gehören der grundlegende
Zeichenvorrat und die besonderen Funktionen von SGML, z. B. OMITTAG oder
SHORTREF99, die zugelassen werden müssen. Während bei den meisten SGMLAnwendungen der Einsatz einer vorgegebenen SGML-Standarddeklaration mit der
Bezeichnung Concrete Reference Syntax (CRS) vorausgesetzt wird, kann eine
bestimmte DTD auch eine individuell gestaltete Deklaration verwenden. EAD
verwendet eine solche speziell angepasste SGML-Deklaration, die sich in der Datei
eadsgml.dcl befindet.100 Der XML-Standard erlaubt andererseits solche
Modifikationen nicht, sondern verlangt die Verwendung seiner eigenen impliziten
SGML-Deklaration. Infolgedessen erfordern, wie in Abschnitt 4.3.1 erwähnt, EADDokumente in XML nicht die Verwendung der Datei eadsgml.dcl. Die eadsgml.dclDatei enthält eine SGML-Deklaration, die die CRS derart modifiziert, dass sie der in
XML verwendeten impliziten Deklaration so nahe wie möglich kommt. Das war bei
EAD erforderlich, damit eine einzelne DTD mit den lediglich in Abschnitt 4.3.2.1
99
Weitere technische Informationen zur SGML-Deklaration vgl. Goldfarb, Charles F.: The SGML Handbook, Oxford 1990,
S. 450-475.
Informationen zu der EAD-DTD und den zugehörigen Dateien siehe Abschnitt 4.3.1.
100
180
genannten geringfügigen Änderungen sowohl in SGML- als auch in XML-Systemen
verwendet werden konnte.
6.2.3. Dokumentinstanz
Die einzelnen Dokumentinstanzen müssen mit einem Prolog beginnen, in dem die
DTD genannt ist, gemäß der sie erstellt wurden und der die verwendete SGMLDeklaration referenziert. Ausnahme davon sind XML-konforme Dateien, wo die
SGML-Deklaration implizit ist und nicht geändert werden kann. Nach dem Prolog
besteht der Textkörper einer einzelnen Dokumentinstanz gemäß einer bestimmten
DTD nur aus zwei Arten von Informationen:
•
•
Daten, mit denen Informationen mitgeteilt werden (bei EAD sind dies im
allgemeinen Textdaten)
eine Auszeichnung, die Anweisungen an eine Software enthält, mit der der
Text bearbeitet wird, um ihn für eine Suche mit Indizes zu versehen oder ihn
für Ausgabegeräte aufzubereiten (z. B. zwecks Bildschirmanzeige oder
Ausdruck) oder umzuwandeln (z. B. für einen Sprachsynthesizer).
Der Prolog sämtlicher EAD-kodierter Dokumentinstanzen muss mit folgender
Dokumenttyp-Deklaration beginnen:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN">
Die Zeichenfolge <!DOCTYPE kennzeichnet das Nachfolgende als DokumenttypDeklaration, die nicht mit der ähnlichen Bezeichnung „Dokumenttyp-Definition“
verwechselt werden darf. Die Dokumenttyp-Deklaration referenziert die von der
Dokumentinstanz angewendete DTD. Sofort nach der Zeichenfolge <!DOCTYPE
kommt der Dokumenttypname, der vom SGML-Standard als die MindestZeichenfolge definiert wird, die eindeutig für den zu deklarierenden Dokumenttyp
stehen kann, in diesem Fall „ead“. Bei einem SGML-System kann der
Dokumenttypname entweder in Groß- oder in Kleinbuchstaben geschrieben sein. Da
XML jedoch zwischen Groß- und Kleinbuchstaben unterscheidet und die EAD-DTD
vorschreibt, dass alle Element- und Attributnamen in Kleinbuchstaben zu schreiben
sind, ist es stets am sichersten, den Dokumenttypnamen in Kleinbuchstaben zu
schreiben, um sicherzustellen, dass die Dateien auf jeden Fall funktionieren.
Nach der Bezeichnung des Dokumenttyps muss die Instanz ihre DTD nun für die
Verarbeitungsanwendungen verfügbar machen. Dies kann auf zwei Arten
geschehen. Die gesamte DTD kann in die DOCTYPE-Deklaration selbst, und zwar in
die so genannte Deklarationsteilmenge, eingebettet werden. Der Inhalt der
Deklarationsteilmenge wird am Anfang durch eine öffnende eckige Klammer ([) und
am Ende durch eine schließende eckige Klammer (]) begrenzt.101 Häufiger jedoch
wird die DTD aus Effizienzgründen in einer externen Datei gespeichert, die die
DOCTYPE-Definition an dieser Stelle referenziert, wie in der vorstehend gezeigten
EAD-DOCTYPE-Deklaration. Die Referenz kann aus einem Formal Public Identifiers*
(FPI) bestehen, vor dessen Text das Schlüsselwort PUBLIC steht. Eine andere
Möglichkeit besteht darin, einen speicherstellenspezifischen Systemidentifikator zu
verwenden, vor dem das Schlüsselwort SYSTEM steht. Die Vorteile von öffentlichen
101
Entitätsdeklarationen sind auch in der Deklarationsteilmenge enthalten. Einzelheiten siehe Abschnitt 6.5.2.2.
A.d.Ü.: = formelle öffentliche Identifikatoren
*
181
Identifikatoren und Systemidentifikatoren sowie einer Kombination daraus sind in
Unterabschnitt 6.5.2.4.1 behandelt.
6.2.4. Sicherstellung der Regelkonformität
Jede SGML-fähige Softwareanwendung, mit der die Verarbeitung einer SGMLDokumentinstanz erfolgen soll, überprüft, ob das Dokument folgende Eigenschaften
erfüllt:
•
•
es referenziert eine SGML-konforme DTD
es folgt dieser DTD bzgl. seiner Auszeichnung.
Eine valide Dokumentinstanz wendet die Auszeichnung in der von ihr referenzierten
DTD an. XML lässt wohlgeformte Dokumentinstanzen zu, die keine DTD
referenzieren, jedoch den Regeln der XML-Spezifikation entsprechen müssen.
Archivare, die die EAD-DTD im XML-Modus anwenden, erstellen
Dokumentinstanzen, die sowohl wohlgeformt als auch valide sind.
Bei SGML-gestützten Systemen wird der Prozess, mit dem ein Dokument auf
Konformität mit der referenzierten DTD geprüft wird, als „Parsing“ (Syntaxanalyse)
bezeichnet. Dabei wird Komplexes in seine Komponenten zerlegt. Die ParsingAnwendung in einem SGML-System führt mehrere Arbeitsschritte nacheinander
durch. Normalerweise liest die Anwendung – falls vorhanden – zuerst die SGMLDeklaration und prüft dann die DTD selbst auf SGML-Konformität. Dann liest oder
parst sie die Auszeichnung des Dokuments, erweitert Text-Entitäten und trennt den
Text von der Auszeichnung. Das Dokument wird anschließend in eine Baumstruktur
umgewandelt, so dass die Anwendung es in der letzten Phase validieren kann,
indem es seine Struktur mit der der DTD vergleicht. Einfach ausgedrückt, wird beim
Parsen die Auszeichnung identifiziert, und bei der Validierung wird diese
Auszeichnung mit der DTD verglichen.
182
6.3. Elemente
Elemente sind die wichtigsten Bausteine für die von einer DTD spezifizierten
Auszeichnung. Elemente – in Form der sie darstellenden Tags – bilden das Gerüst
für eine kodierte, SGML-konforme Dokumentinstanz. Dieses Gerüst umgibt Textoder andere Daten, die den Informationsinhalt des Dokuments bilden, der einer
Zielgruppe bereit gestellt werden soll.
Die Elementdeklaration in einer DTD besteht aus der Zeichenfolge <!ELEMENT, auf
die ein Elementname und ein Inhaltsmodell folgen, wie im nachstehenden Beispiel zu
sehen ist.
<!ELEMENT
element_name content_model>
Der Elementname bildet den Kern jedes Tags, der den Inhalt eines Elements in einer
bestimmten Instanz eines kodierten Dokuments begrenzt. Der SGML-Standard legt
fest, dass ein Tag durch eine öffnende spitze Klammer (<) bezeichnet wird, auf die
der Text des Elementnamens und dann eine schließende spitze Klammer (>) folgen,
und dass es zwei Tags für jedes Element mit Inhalt gibt: einen Start-Tag und einen
End-Tag. In ihrer einfachsten Form sind diese Tags mit einer wichtigen Ausnahme
gleich: der End-Tag hat zwischen der öffnenden spitzen Klammer und dem
Elementnamen einen Schrägstrich (/).
Start-Tag:
End-Tag:
<element_name>
</element_name>
Der Start-Tag kann eine komplexere Form haben, weil er von Attributen (in Abschnitt
6.4 behandelt) näher bezeichnet sein kann, während End-Tags nicht auf diese Weise
erweitert werden können.
Die Beziehung zwischen Elementdeklarationen und den Tags zeigen folgende
Beispiele mit zwei recht einfachen Elementdeklarationen aus der EAD-DTD, wie sie
in der Instanz eines kodierten Dokuments verwendet werden. Bild 6.3a enthält die
EAD-DTD-Deklarationen für die Elemente EAD <ead> und Change <change>:
<!ELEMENT ead (eadheader, frontmatter?, archdesc)>
<!ELEMENT change (date, item+)>
Bild 6.3a. Elementdeklarationen aus der EAD-DTD
Der Elementname für jedes Element gemäß der EAD-DTD dient zur Konstruktion von
Tags in Dokumentinstanzen, wie das folgende Beispiel zeigt:
Start-Tag:
<ead>
<change>
End-Tag:
</ead>
</change>
Der Inhaltsmodell-Teil einer Elementdeklaration in einer SGML-DTD gibt drei
Eigenschaften des Elements an:
•
•
•
Welche Art von Daten können im Element auftreten?
Welche Reihenfolge muss ggf. bei diesen Daten eingehalten werden?
Wie oft können oder müssen Subelemente innerhalb des Elements auftreten?
183
Die Reihenfolge des Auftretens im Inhaltsmodell der Elementdeklaration wird von
folgenden Symbolen bestimmt:
,
|
()
Komma
Vorgeschriebene Reihenfolge (zuerst x, dann y)
Senkrechter Strich Keine vorgeschriebene Reihenfolge (entweder x oder y)
Runde Klammern Inhaltsgruppen innerhalb des größeren Inhaltsmodells
Die zulässige Häufigkeit von Subelementen wird von den folgenden
Häufigkeitsindikatoren festgelegt, die unmittelbar nach dem Namen eines
bestimmten Elements oder nach einer Inhaltsgruppe, begrenzt durch runde
Klammern, erscheinen können:
+
?
*
Leerzeichen
Pluszeichen
Fragezeichen
Sternchen
Vorgeschrieben, kann nur einmal auftreten
Vorgeschrieben, kann einmal oder auch öfter auftreten
Wahlweise, kann gar nicht oder nur einmal auftreten
Wahlweise, kann gar nicht, einmal oder auch mehrmals auftreten
Beide Elemente gemäß der Deklaration in Bild 6.3a sind Beispiele für ein
Inhaltsmodell, das nur andere Elemente enthalten kann, die als Subelemente
bezeichnet werden. Die erste Elementdeklaration in Bild 6.3a gibt an, dass das
Element Encoded Archival Description <ead> ein einziges Subelement EAD Header
<eadheader> enthalten muss, auf das möglicherweise ein einziges, wahlweises
Subelement Front Matter <frontmatter> und dann ein einziges vorgeschriebenes
Subelement Archival Description <archdesc> folgen. In der zweiten
Elementdeklaration steht, dass das Element Change <change> ein einziges
vorgeschriebenes Subelement Date <date> enthalten muss, gefolgt von einem oder
mehren Subelementen Item <item> (Verwendung dieser und anderer EAD-Elemente
sowie Beispiele für ihre Verwendung in kodierten Findbüchern siehe Kapitel 3).
Die vorstehenden Beispiele für Elementdeklarationen zeigen, wie ein Inhaltsmodell
nur für Elemente aussieht, d. h., dass diese Elemente nur andere Elemente als Inhalt
haben können. Natürlich können nicht alle in der EAD-DTD deklarierten Elemente
diesem Inhaltsmodell folgen, da wir in der Lage sein müssen, die Textdaten eines
archivischen Findbuchs irgendwo in den EAD-kodierten Dokumentinstanzen
unterzubringen. Ein SGML-gestütztes Kodierschema wie EAD verwendet den
Ausdruck PCDATA (parsed character data*), um anzuzeigen, dass geparste
Zeichendaten in dem Inhaltsmodell für ein Element zulässig sind. Sie sehen den Text
eines Findbuchs vielleicht nicht als „geparste Zeichendaten“ an. Das ist er jedoch für
ein SGML-fähiges Softwarepaket, nachdem der Findbuchtext Teil eines EADkodierten Dokuments geworden ist. Jeder Text, den das Inhaltsmodell für ein
Element als PCDATA definiert, muss von der Software geparst werden, um
festzustellen, ob es sich nicht um Auszeichnung handelt. Die Software kann nicht
automatisch davon ausgehen, dass es sich bei diesem Elementinhalt um
Auszeichnung handelt oder nicht, daher muss sie seine Komponenten auflösen.
SGML-gestützte Inhaltsmodelle verwenden den Ausdruck CDATA (character data**),
um der Verarbeitungssoftware mitzuteilen, dass an bestimmten Stellen zulässige
Daten in keinem Fall Auszeichnung enthalten und daher nicht geparst werden
*
A.d.Ü.: = Geparste Zeichendaten.
A.d.Ü.: = Zeichendaten
**
184
müssen, um validiert zu werden. Ein häufiges Beispiel für die Verwendung von
CDATA, das in Abschnitt 6.4 erläutert wird, ist das Nennen von Attributwerten, die nie
andere Auszeichnungs- oder Zeichenentitäten enthalten können.
Das Element Zusammenfassung <abstract> ist ein Beispiel für ein gemischtes
Inhaltsmodell, das sowohl Textdaten als auch andere Elemente oder Auszeichnung
enthalten kann. Das folgende Beispiel zeigt das in der EAD-DTD festgelegte
Inhaltsmodell für <abstract>:
<!ELEMENT
abstract (#PCDATA | ptr | extptr | emph | lb |
abbr | expan| ref | extref | linkgrp |
bibref | title | archref)*>
Diese Elementdeklaration besagt, dass für <abstract> kein bestimmter Inhalt
vorgeschrieben ist. Das Element kann geparste Zeichendaten oder beliebige der
genannten Elemente in jeder Reihenfolge und so oft wie erforderlich enthalten. Bei
einem EAD-Dokument heißt das, dass Text und die genannten Tags in jeder
gewünschten Zusammenstellung zwischen dem Start-Tag <abstract> und dem EndTag </abstract> untergebracht werden können (weitere Angaben zur Verwendung
von <abstract> siehe Abschnitt 3.5.1.2.6).
In einem SGML-gestützten Auszeichnungssystem können entweder – wie oben
beschrieben – Elemente mit Inhalt oder aber leere Elemente definiert werden. Die
meisten in der EAD-DTD definierten Elemente enthalten entweder andere Elemente
oder Text. Einige enthalten beides. Dann spricht man von „gemischtem Inhalt“.
Einige andere, z. B. das Element Pointer <ptr>, sind als EMPTY* definiert. Die
Deklaration für dieses Element gibt das folgende Inhaltsmodell an:
<!ELEMENT
ptr
EMPTY>
Leere Elemente können keinen Text oder andere Elemente enthalten und erhalten
nur den Start-Tag, nicht den End-Tag. Die SGML-Verarbeitungssoftware weiß, dass
sie nicht nach einem End-Tag suchen muss (Informationen zur XML-Syntax für leere
Elemente siehe Abschnitt 4.3.2.4). Die Möglichkeit, in einem SGML-System leere
Elemente deklarieren zu können, hat vor allem den Vorteil, die Attribute solcher
Elemente zugänglich zu machen. Das ist besonders bei Elementen nützlich, mit
denen ausgehend von einer bestimmten Stelle in einem Dokument sowohl interne
als auch externe Verknüpfungen erstellt werden können. Ein solches Element könnte
z. B. dazu dienen, Querverweise zwischen verschiedenen Stellen eines Findbuchs
oder eine Verknüpfung zu Digitalisaten von Materialien des im Findbuch
beschriebenen Bestandes herzustellen. Kapitel 7 enthält kodierte Beispiele und eine
ausführliche Erläuterung der Verknüpfungsmöglichkeiten in EAD.
*
A.d.Ü.: = leer.
185
6.4. Attribute
Attribute ermöglichen es in einem SGML-gestützten Kodiersystem, Informationen
hinzuzufügen, um ein Element näher zu bezeichnen, beispielsweise den Typ eines
Elements anzugeben, ihm einen eindeutigen Identifikator zuzuordnen oder
Anweisungen zu seiner Verarbeitung bzw. Darstellung zu geben. Attribute werden in
einer DTD auf ähnliche Weise wie Elemente deklariert. Sie werden mit der
Zeichenfolge <!ATTLIST bezeichnet und haben Werte, die von der Attributdeklaration
festgelegt sein können oder auch nicht. Mögliche Werte für Attribute mit festgelegtem
Wertebereich sind in der Attributdeklaration angegeben und zwingen Kodierer, die
Werte aus einer geschlossenen Liste auszuwählen. Werte für Attribute mit nicht
festgelegtem Wertebereich werden im Allgemeinen in der DTD mit einem CDATAInhaltsmodell angegeben. Hierbei können Kodierer jeden beliebigen Wert eingeben.
Attribute beziehen sich immer auf ein zuvor in einer DTD deklariertes Element. Mit
anderen Worten, der SGML-Standard lässt es nicht zu, dass ein Attribut ohne ein
Element, das es näher bezeichnet, definiert wird. Attribute liefern Metainformationen
zum Dateninhalt eines bestimmten Elements und können in einem SGML-gestützten
Kodiersystem nur hinter Start-Tag des Elements erscheinen. Attribute werden wie
folgt in Start-Tags gesetzt:
<element_name
attribute_name="attribute_value">
Zum Beispiel:
<c level="series">
Das Element Component, das zwischen dem Start-Tag <c> und dem End-Tag </c>
steht, enthält in seinen Subelementen und den darin befindlichen Textdaten eine
Vielzahl an Identifizierungs- und Kontextinformationen über eine bestimmte
Komponente der archivischen Verzeichnung. Das Attribut LEVEL bei dieser
Komponente ist das Mittel, das die EAD-DTD für die Kodierung der
Metainformationen zur Stufe einer bestimmten Komponente (Bestand, Serie, Akte,
Einzelstück) innerhalb der umfassenden kodierten archivischen Verzeichnung
vorsieht.
Eine Attributdeklaration in einer DTD besteht aus der Zeichenfolge <!ATTLIST,
gefolgt von einem das Bezugselement bezeichnenden Elementnamen, dem
Attributnamen, der Angabe des zulässigen Attributwertes oder der zulässigen
Attributwerte und schließlich einem Vorgabewert oder einem Attributtyp.
<!ATTLIST
element_name
ATTRIBUTE_NAME
value(s)
type_or_default>
186
Bild 6.4a zeigt zwei Beispiele für EAD-Element- und Attributdeklarationen:
1. <! ELEMENT editionstmt (edition | p)+>
<!ATTLIST editionstmt
id
ID
altrender
CDATA
audience
(external | internal)
endodinganalog CDATA
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
2. <!ELEMENT archdesc (runner*, did, (admininfo | bioghist |
controlaccess | odd | scopecontent |
organization | arrangement | add | dsc |
dao | daogrp | note)*>
<!ATTLIST archdesc
id
altrender
audience
type
othertype
level
otherlevel
langmaterial
legalstatus
otherlegalstatus
encodinganalog
relatedencoding
ID
#IMPLIED
CDATA
#IMPLIED
(external | internal) #IMPLIED
(inventory | register |
othertype)
#IMPLIED
CDATA
#IMPLIED
(series | collection | item |
otherlevel | recordgrp
subgrp | subseries)
#REQUIRED
CDATA
#IMPLIED
CDATA
#IMPLIED
(public | private |
otherlegalstatus)
#IMPLIED
CDATA
#IMPLIED
CDATA
#IMPLIED
CDATA
#IMPLIED
Bild 6.4a. EAD-DTD Element- und Attributdeklaration für <editionstmt> und
<archdesc>. Die drei Spalten in der Attributdeklaration stellen in der
Reihenfolge den Namen des Attributs, das Inhaltsmodell und die Angabe des
Wertes dar.
Das Attribut LEVEL für das Element Archival Description <archdesc> liefert ein gutes
Beispiel für festgelegte und nicht festgelegte Wertebereiche (siehe die zweite
Attributdeklaration in Bild 6.4a). Die Attributdeklaration liefert die folgende
geschlossene Liste von möglichen Werten für dieses Attribut, wodurch die
Wahlmöglichkeiten eingeschränkt sind: collection, file, fonds, otherlevel, recordgrp,
series, subgrp, subseries. Eine geschlossene Werteliste erleichtert bei SGLMgestützten Authoring-Systemen die Eingabe dieser Werte (weitere Informationen
zum Authoring mit EAD siehe Kapitel 4). Außerdem wird dadurch die einheitliche
Verwendung von Attributwerten für bestimmte wichtige Informationsarten durch die
verschiedenen Archive usw. gewährleistet, was für Verbund-Datenbanken von
kodierten Findbüchern wesentlich sein kann. Es gibt jedoch noch andere zulässige
Namen, die einige Archive für verschiedene Stufen der archivischen Verzeichnung
verwenden können. Die o. g. Liste ist zwar geschlossen, ein möglicher Wert ist
jedoch OTHERLEVEL, ein anderes Attribut, das in der DTD mit einem CDATAInhaltsmodell deklariert ist, was bedeutet, dass sein Wertebereich nicht festgelegt ist
(die Kodierung des Attributs LEVEL in <archdesc> ist in Abschnitt 3.5.1
beschrieben).
187
Wenn Attributwerte innerhalb von Tags kodiert werden, werden sie von einem
SGML-fähigen Verarbeitungssystem als literale Werte behandelt. Dieser Ausdruck
bezeichnet eine Zeichenfolge zwischen einfachen (') oder doppelten (")
Anführungszeichen, die bei der Verarbeitung nicht weiter zerlegt wird. Kodierer
können z. B. nicht eine Entitätsreferenz als Inhalt eines Attributwerts verwenden und
erwarten, dass die Verarbeitungssoftware diese Entität erkennt und auflöst (Entitäten
werden in Abschnitt 6.5 behandelt).
Attributwerte können von SGML-fähiger Software auf verschiedene Art und Weise
behandelt werden:
•
•
•
•
Sie können für Endnutzer in Text umgewandelt werden.
Sie können zur Steuerung der Formatierung verwendet werden.
Sie können dazu verwendet werden, den Text mit Indizes zu versehen.
Sie können zur Herstellung von internen oder externen Verknüpfungen
dienen.
Bei der einzelnen Dokumentinstanz darf nicht außer Acht gelassen werden, dass –
anders als die Textdaten, die in vielen Elementen enthalten sind – die tatsächlichen
Datenwerte von Attributen dem Endnutzer der kodierten Dokumentinstanz nicht
unmittelbar zur Verfügung stehen. Damit bestimmte Attributwerte für Endnutzer
dargestellt werden können (z. B. der Wert des Attributs LANGMATERIAL von
<archdesc> oder der Wert des Attributs LABEL eines <did>-Subelements), muss ein
System bzw. ein Stylesheet verwendet werden, mit dem Attributwerte zur Darstellung
umgewandelt werden können (Weiteres über Stylesheets siehe Abschnitt 5.3.3).
Vom technischen Standpunkt betrachtet, besteht der auffallendste Unterschied
zwischen Attributen und Elementen darin, dass Elemente, wie wir gesehen haben,
entweder Text oder andere Elemente, Attribute dagegen nie andere Elemente
enthalten können. Attributwerte werden, wie weiter oben erwähnt, als CDATA und
nicht als PCDATA ausgedrückt, so dass eine SGML-fähige Verarbeitungssoftware,
die versucht, eine kodierte Dokumentinstanz zu validieren, diese Attributwerte nicht
zu analysieren braucht, um weitere Auszeichnungen zu suchen. Auch gibt es, wie
der Leser aus den Attributdeklarationsbeispielen in Bild 6.4a entnehmen kann,
innerhalb der Attributdeklaration kein Mittel, mit dem die Reihenfolge der Attribute
beeinflusst werden kann. In einem EAD-kodierten Dokument können daher die
deklarierten Attribute für jeden beliebigen Tag in jeder gewünschten Reihenfolge
gesetzt werden, wogegen die Elemente in der Reihenfolge zu kodieren sind, die ggf.
von den Elementdeklarationen in der DTD vorgegeben ist.
Die Beispiele in Bild 6.4a veranschaulichen die Vielfalt der Attributwerte, die in einer
DTD deklariert werden können. Das Attribut ALTRENDER, das es ermöglicht, der
Verarbeitungssoftware die bevorzugte Wiedergabe für die Ausgabe mitzuteilen, hat
einen CDATA-Wert. Das heißt, dass ihr Wertebereich nicht festgelegt ist und man
jeden beliebigen Wert zuordnen kann. Das Attribut AUDIENCE dagegen ist auf einen
von zwei in einer geschlossenen Liste angegebenen Werte begrenzt, nämlich
entweder „internal“ oder „external“. Das Attribut ID hat einen ID-Wert, das ist ein
SGML-Begriff für eine Zeichenfolge, die mit einem Groß- oder Kleinbuchstaben
beginnt, keinen Whitespace enthält und nur aus alphanumerischen Zeichen,
Unterstrichen (_), Bindestrichen (-), Doppelpunkten (:) und Punkten (.)
zusammengesetzt ist. Außerdem muss bei Attributen mit ID-Wert der Wert innerhalb
188
einer bestimmten kodierten Dokumentinstanz eindeutig sein, und es kann nur ein
einziges derartiges Attribut in jedem Element geben.
Bei den <!ATTLIST-Beispielen in Bild 6.4a sind die Attributtypen am Ende jeder
Attributdeklarationszeile angegeben. Die meisten Attribute in der EAD-DTD sind als
IMPLIED* deklariert, was bedeutet, dass einzelne SGML-gestützte Systeme Werte
für sie implizieren können, falls die Werte nicht anders deklariert sind, dass aber die
DTD ihre Verwendung nicht erzwingt. Beim Beispiel der <!ATTLIST-Deklaration für
<archdesc> fällt auf, dass das Attribut LEVEL als REQUIRED** deklariert ist. Das
bedeutet, dass ein Syntaxanalysator eine EAD-Instanz nicht validiert, wenn dieses
Attribut fehlt.
*
**
A.d.Ü.: = inbegriffen.
A.d.Ü.: = erforderlich.
189
6.5. Entitäten
Entitäten ermöglichen es, einen abgekürzten Namen zu deklarieren, der als Ersatz
für etwas anderes dient. Dieses „Andere“ kann verschiedener Art sein:
•
•
•
eine lange oder kurze Textpassage, die aus Textbausteinen besteht und
innerhalb der Dokumentinstanz häufig wiederholt wird
eine andere Dokumentinstanz
eine Datei in einem Datenformat, das von SGML-fähiger Software überhaupt
nicht erkannt werden kann (z. B. Bild- und Multimedia-Dateien,
Datenbankobjekte und proprietäre Textverarbeitungsdateiformate).
Ist eine Entität innerhalb einer Dokumentinstanz deklariert worden, kann der
abgekürzte Namen so oft wie erforderlich verwendet werden. Wenn die
Verarbeitungssoftware auf den abgekürzten Namen stößt, erweitert sie die
Abkürzung auf das Dokument usw., das die Entitätsdeklaration referenziert. Wie sich
die Entitätserweiterung verhält, wird hauptsächlich von der Verarbeitungssoftware
bestimmt. Der Software können allerdings oft mit Hilfe der Auszeichnung
Anweisungen erteilt werden. Dies wird ausführlich in Kapitel 7 über
Verknüpfungselemente behandelt.
Deklaration:
<!ENTITY tp-address PUBLIC "-//ABC University::Special
Collections Library//TEXT (Titelseite: Name und Adresse)//EN"
"tpspcoll.sgm">
Expansion:
<list type="simple">
<head>Adresse des Archivs </head>
<item>Special Collections Library</item>
<item>ABC University</item>
<item>Main Library, 40 Circle Drive</item>
<item>Ourtown, Pennsylvania</item>
<item>17654 USA</item>
</list>
Bild 6.5a. Beispiel für eine Entitätsdeklaration, gefolgt von
der Entitätserweiterung.
Goldfarb und Prescod liefern eine hilfreiche, wenn auch vielleicht zu stark
vereinfachte Analogie für Entitäten. Sie schlagen vor, sich eine Entität als Kasten mit
Etikett vorzustellen. Der Kasten enthält einen bestimmten Text oder Daten, während
das Etikett (der abgekürzte Name) die Möglichkeit bietet, mit einer kurzen
Bezeichnung auf den Kasten hinzuweisen.102 Entitäten können einfach bis komplex
sein, in jedem Fall eröffnen sie wirksame Wege zu mehr Effizienz, zur Vermeidung
von Redundanzen und zur Einarbeitung von Nicht-SGML-Daten in kodierte
Dokumentinstanzen.
Es gibt zwei Arten von Entitäten: Parameterentitäten und allgemeine Entitäten.
102
Goldfarb, Charles F. / Prescod, Paul: The XML Handbook, Upper Saddle River 1998, S. 478.
190
6.5.1. Parameterentitäten
Parameterentitäten bieten eine gute Einführung in die Grundlagen der
Entitätensyntax. Wir werden uns jedoch nicht lange mit ihnen befassen, weil sie nur
in DTDs (entweder unabhängigen DTDs wie EAD oder DTDs, die in die
Deklarationsteilmenge einer Dokumentinstanz eingebettet sind) und nicht im
Textkörper von Dokumentinstanzen auftreten können. Im Allgemeinen werden
Parameterentitäten – wie auch bei EAD – von DTD-Erstellern verwendet, um häufig
verwendete Element- und Attributdeklarationen in einem Inhaltsmodell zu bündeln,
das in einer DTD leicht wieder verwendet oder sogar in mehreren DTDs angewandt
werden kann. Bei Parameterentitätsdeklarationen in DTDs ist gemäß folgender
Formel zu verfahren:
<!ENTITY
%
entity_name entity_value>
Parameterentitäten müssen in DTDs deklariert werden, bevor sie an anderer Stelle
im Text der DTD referenziert werden können. Der Ersteller einer DTD weist wie folgt
auf eine Parameterentität hin:
%entity_name;
Das folgende Beispiel zeigt, wie eine Parameterentitätsdeklaration einer EAD-DTD
aussehen kann:
<!ENTITY
%
a.common
'id
altrender
audience
ID
CDATA
(external | internal)
#IMPLIED
#IMPLIED
#IMPLIED'>
Ausgehend von früheren Attributbeispielen werden Sie vielleicht feststellen, dass die
vorstehende literale Zeichenfolge in einfachen Anführungszeichen dem Inhalt einer
<!ATTLIST-Deklaration verdächtig ähnlich sieht, und das ist sie auch. Dieses Beispiel
einer Entitätsdeklaration besagt einfach, dass immer wenn eine Anwendung, die
diese DTD liest, auf die Referenz „%a.common;“ stößt, die Attributliste einsetzen
muss, die zwischen den einfachen Anführungszeichen in dem obigen Beispiel steht.
Diese bestimmte Parameterentität wird in der gesamten EAD-DTD häufig
referenziert, da die Attribute ID, ALTRENDER und AUDIENCE für die genauere
Bezeichnung der meisten EAD-Elemente verfügbar sind. Das allererste, im Abschnitt
„Deklarationen der EAD-Elemente“ der EAD-DTD deklarierte Element erscheint wie
folgt:
<!ELEMENT
<!ATTLIST
ead (eadheader, frontmatter?, archdesc)>
ead
%a.common;
relatedencoding
CDATA
#IMPLIED>
Wenn ein SGML-fähiges Softwarepaket auf diese Parameterentitätsreferenz stößt,
erweitert sie die Referenz, so dass wenn beim Kodieren ein <ead>-Tag verwendet
wird, vier Attribute für diesen Tag zur Verfügung stehen, und zwar
RELATEDENCODING plus die drei Attribute, die in der Entitätsdeklaration
„a.common“ festgelegt sind. Diese Erweiterung der Entitätsreferenz ist einer der
Arbeitsschritte, den alle SGML-fähigen Softwarepakete durchführen müssen, bevor
sie einen SGML-konformen kodierten Text verarbeiten können.
191
Zum Schluss ist noch eine Bemerkung zu dem vorstehenden Beispiel zu machen,
das eine wichtige Eigenschaft von Entitäten veranschaulicht. Das Beispiel zeigt die
Deklaration für eine interne Entität, d. h., der Text für die Erweiterung der
Entitätsreferenz wird als Teil der Entitätsdeklaration selbst deklariert. Wenn diese
Deklaration eine Text- oder Datendatei referenziert hätte, die außerhalb der Datei mit
der Referenz gespeichert ist (ein Beispiel dafür werden wir bald kennen lernen), wäre
das ein Beispiel für die Deklaration einer externen Entität.
Das Prozent-Zeichen (%) in der Entitätsdeklaration und am Anfang der
Entitätsreferenz in den vorstehenden Beispielen identifiziert diese Entitäten als
Parameterentitäten und nicht als allgemeine Entitäten.
6.5.2. Allgemeine Entitäten
Wie in Abschnitt 6.5.1 erwähnt, können Parameterentitäten nur in DTDs verwendet
werden. Kodierern von Dokumentinstanzen, die eine SGML-DTD anwenden, stehen
auch so genannte allgemeine Entitäten zur Verfügung. Diese sind komplizierter als
Parameterentitäten, weil sie innerhalb einer kodierten Dokumentinstanz
verschiedene Funktionen haben können. In den folgenden vier Unterabschnitten
werden die Typen von allgemeinen Entitäten erläutert, die für EAD-Anwender
verfügbar sind, sowie die Art und Weise, in der einige dieser Entitäten in einer
Dokumentinstanz deklariert werden müssen. Unterabschnitt 6.5.2.1 befasst sich mit
Entitäten, die nicht einzeln in der Dokumentinstanz deklariert sind, weil es
Zeichenentitäten sind, die entweder als Teil der EAD-DTD definiert sind, wenn sie im
SGML-Modus genutzt wird, oder – bei XML – als Teil der XML-Spezifikation selbst.
Unterabschnitt 6.5.2.2 behandelt die Deklaration von Entitäten als Teil des Prologs
zu einer Dokumentinstanz. Unterabschnitt 6.5.2.3 erläutert interne Entitäten, bei
denen der Inhalt der Entitätserweiterung als Teil der Entitätsdeklaration bereitgestellt
wird. Unterabschnitt 6.5.2.4 behandelt externe Entitäten, die Adressen von externen
Dateien zur Erweiterung der Entität enthalten.
6.5.2.1. Zeichenentitäten
Die einfachste Form von Entitäten sind die, die mit Hilfe von eadchars.ent integriert
werden, einer zur EAD-DTD gehörigen Datei (weitere Informationen der zur EADDTD und dan dazugehörigen Dateien siehe Abschnitt 4.3.1). Diese Zeichenentitäten
sind in standardisierten Zeichenentitätsvorräten gemäß ISO (International Standards
Organization)103 definiert und im Allgemeinen für Zeichen und Symbole bestimmt (z.
B. Umlaute, das Copyright-Symbol (©) oder griechische Buchstaben)), die nicht auf
der normalen englischen Tastatur vorhanden sind. Als Voreinstellung bezeichnet die
EAD-DTD die folgenden zehn ISO-Zeichenvorräte:
Added Latin 1
Added Latin 2
Greek Symbols
Alternative Greek Symbols
Greek Letters
Monotoniko Greek
Diacritical Marks
Numeric and Special Graphics
Publishing
General Technical
103
Robin Covers SGML/XML Web Page liefert weitere Informationen zu ISO-Zeichenentitätsvorräten: <http://www.oasisopen.org/cover/topics.html#entities>.
192
Es ist zu beachten, dass die Zeichenentitätsreferenzen in der EAD-DTD nicht selbst
diese Zeichenentitäten für die Verwendung in EAD-Instanzen zur Verfügung stehen.
Diese Zeichenvorräte müssen im verwendeten SGML-System verfügbar sein, damit
sie in EAD funktionieren. Es sollte deshalb mit dem Systemadministrator des Archivs
besprochen werden, wenn beabsichtigt wird, Zeichenentitäten in kodierten
Findbüchern zu verwenden.
In SGML werden typografische und grafische Sonderzeichen mit
Entitätsdeklarationen für SDATA (specific character data*) dargestellt, die die
Abkürzungen enthalten, die in Zeichenentitätsreferenzen innerhalb kodierter
Dokumente verwendet werden. Diese Entitätsdeklarationen erscheinen in den
Mapping-Tabellen für SGML-ISO-Zeichenentitäten. Diese Tabellen müssen im
verwendeten System verfügbar sein, wenn gewünscht wird, dass Zeichen
referenziert werden, die nicht auf der Tastatur vorhanden sind. In EAD-Instanzen
kann man Zeichenentitäten wie folgt referenzieren:
&#abbreviation;
Als Alternative zur SDATA-Abkürzung kann auch die Dezimalzahl verwendet werden,
die zu dem Zeichen in dem gerade verwendeten ISO-Zeichenentitätsvorrat gehört,
z. B.:
gewünschtes Zeichen od. Symbol
©
Zeichenentitätsreferenz
ISO-SDATA-Abkürzung
ISO-Dezimalkodereferenz
&#copy;
&#169;
XML verwendet Unicode, um das Zeichenentitätsschema von SGML auf der
Grundlage von SDATA zu ersetzen. Unicode umfasst alle diakritischen Zeichen,
Symbole und anderen Zeichen in einem einzigen Zeichenentitätsvorrat.
Goldfarb und Prescod liefern folgende Erklärung:
Wenn Sie englischer Muttersprachler sind, benötigen Sie u. U. nur die 52 Groß- und
Kleinbuchstaben, einige Satzzeichen und einige Zeichen mit Akzenten. Dieser Bedarf wird
durch den weit verbreiteten 7-Bit-ASCII-Zeichenvorrat abgedeckt. Er hat gerade genug
Zeichen (128) für alle Buchstaben, Symbole, einige Zeichen mit Akzenten und einige
andere Sonderzeichen. ASCII ist sowohl ein Zeichenvorrat als auch eine Zeichenkodierung.
Es legt fest, welcher Zeichenvorrat verfügbar ist und wie die Zeichen als Bits und Bytes zu
kodieren sind.
Der Zeichenvorrat von XML ist Unicode, eine Art erweitertes ASCII. Unicode umfasst
tausende nützlicher Zeichen aus Sprachen der ganzen Welt. Die ersten 128 Zeichen von
Unicode sind jedoch mit ASCII kompatibel, und es gibt eine Zeichenkodierung von Unicode,
UTF-8, die mit dem 7-Bit-ASCII kompatibel ist. Das heißt, dass auf Bit- und Byte-Ebene die
ersten 128 Zeichen von UTF-8 Unicode und 7-Bit-ASCII gleich sind. Dank dieser
Eigenschaft von Unicode können Autoren Standard-Volltexteditoren verwenden, um XML
unmittelbar zu erzeugen.104
*
A.d.Ü.: = Sonderzeichendaten.
Goldfarb, Charles F. / Prescod, Paul: The XML Handbook, Upper Saddle River 1998, S. 37.
104
193
Ein Zeichen oder Symbol kann referenziert werden, indem entweder der ihm in
Unicode zugeordnete Dezimalkode oder der alphanumerische Hexadezimalkode wie
folgt angegeben wird:
Dezimal:
Hexadezimal:
&#somenumber;
&#xsomenumber;
gewünschtes Zeichen oder Symbol
©
Zeichenentitätsreferenz
Unicode Dezimalreferenz
Unicode Hexadezimalreferenz
&#xA9;
&#169;
SGML und SGML-Systeme können in ihrer derzeitigen Gestalt die Hexadezimalreferenzen nicht erkennen, XML-Systeme dagegen schon. Außerdem erkennen
SGML-Systeme nur die numerischen Unicode-Referenzen für die 128 Zeichen von
7-Bit-ASCII. Es wird z. Z. daran gearbeitet, den SGML-Standard dahingehend zu
modifizieren, dass er den gesamten Unicode-Zeichenvorrat erkennt. Die Anwender
von EAD, die SGML-Software verwenden, müssen die ISO-SDATA-Abkürzungen
verwenden, wenn sie Zeichenentitätsreferenzen in ihre EAD-Instanzen einbauen
wollen. Wenn XML-konforme Mapping-Tabellen verfügbar sind, werden diese
mühelos gegen die SGML-ISO-Tabellen im System ausgetauscht werden können,
ohne dass die Auszeichnung geändert werden muss.
Ein weiterer erwähnenswerter Punkt ist die Tatsache, dass Sonderzeichen zwar mit
Hilfe von SDATA-Abkürzungen oder dezimalen bzw. hexadezimalen Referenzen in
EAD-Dokumente eingefügt werden können, zahlreiche Suchmaschinen jedoch nicht
nach diesen Entitätsreferenzen suchen können, wodurch eine Suche ggf.
ergebnislos verläuft. Bis Unicode bei allen Softwarepaketen zur Kodierung,
Verarbeitung und Übertragung kodierter Instanzen zum Standard wird, wird es
Unterschiede dabei geben, wie unterschiedliche Softwareprodukte Sonderzeichen
ausgeben. Ein Archiv muss sich klar machen, wie wichtig es ist, diese Sonderzeichen
zu indexieren und darzustellen, besonders angesichts der Schwierigkeit, sie während
der verschiedenen Phasen der Auszeichnung und Bereitstellung von kodierten
Findbüchern zu erhalten.
6.5.2.2. Das Deklarieren von Entitäten im Dokumentprolog
Alle anderen allgemeinen Entitäten, die in kodierten Dokumentinstanzen verwendet
werden sollen, müssen deklariert werden, indem für jede Entität eine
Entitätsdeklaration in der DOCTYPE-Deklaration am Anfang der EAD-Instanz
eingefügt wird. Wie in Abschnitt 6.2.3 erwähnt, erscheint die Deklarationsteilmenge in
eckigen Klammern ([ und ]) am Ende der DOCTYPE-Deklaration. Da Whitespace in
SGML-Deklarationen keine Bedeutung hat, besagt eine gängige typografische
Konvention, unmittelbar nach der öffnenden eckigen Klammer und unmittelbar vor
der schließenden eckigen Klammer eine neue Zeile zu beginnen, damit Dateien mit
kodierten Instanzen leichter lesbar sind. Bild 6.5.2.2a zeigt einen Prolog zu einer
EAD-Instanz, in dem eine externe allgemeine Entität deklariert wird:
194
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN"
<!ENTITY brblmain SYSTEM
"http://www.myserver.edu/entities/brblmain.sgm">
]>
[
Deklaration der
allgemeinen Entität
Bild 6.5.2.2.a Eine allgemeine Entitätsdeklaration innerhalb der EAD-DeklarationsTeilmenge
Die DOCTYPE- und die ENTITY-Deklaration in Bild 6.5.2.2a enthalten in
Anführungszeichen stehende externe Identifikatoren. Externe Identifikatoren können
entweder öffentliche Identifikatoren oder Systemidentifikatoren sein. Öffentliche
Identifikatoren bieten eine Form von Bestimmungsadresse, die nicht für irgendein
System spezifisch ist. Bei der Verwendung eines öffentlichen Identifikators stützt man
sich darauf, dass das SGML-System die nichtspezifische Adresse in eine spezifische
auflöst, mit der die referenzierte Datei gefunden wird. Öffentliche Identifikatoren sind
im SGML-Standard (ISO 8879) spezifiziert, wogegen die Syntax für FPI105, eine
Teilmenge der öffentlichen Identifikatoren, im Standard ISO 9070 festgelegt ist. Für
EAD ist es nicht erforderlich, dass alle öffentlichen Identifikatoren FPI sind.
Wird ein öffentlicher Identifikator (erkennbar am Schlüsselwort PUBLIC) verwendet,
kann darauf ein Systemidentifikator in Form eines URI für die Ressource folgen. Ein
URI ist ein breiteres Konstrukt, das als Teilmenge die eher bekannte URL (Uniform
Resource Locator) enthält.106 URL und – allgemeiner betrachtet – URI sind die
Adressierfunktionen, die Verweise auf Ressourcen im World Wide Web ermöglichen.
Das Schlüsselwort SYSTEM steht anstelle von PUBLIC vor einem externen
Identifikator, wenn nur ein URI und kein öffentlicher Identifikator für die betreffende
Datei angegeben ist. Beide Schlüsselwörter sind wichtige Komponenten von
Dokumenttyp-Deklarationen und Deklarationen für externe Entitäten. Die Vorteile von
öffentlichen Identifikatoren, Systemidentifikatoren und der gemeinsamen
Verwendung von beiden sind in Unterabschnitt 6.5.2.4.1 behandelt.
Entitäten wie in Bild 6.5.2.2a werden weiter unten im Einzelnen behandelt. Sobald
eine Entität in der Deklarationsteilmenge einer Dokumentinstanz deklariert worden
ist, kann sie in der Dokumentinstanz selbst überall dort referenziert werden, wo
gemäß der DTD eine Auszeichnung zulässig ist (allerdings nicht dort, wo der Inhalt
als CDATA deklariert worden ist). Die in Bild 6.5.2.2a deklarierte Entität wird wie folgt
referenziert:
&brblmain;
105
Eine ausführliche, eher technisch gehaltene Abhandlung zu Formal Public Identifiers bietet DeRose, Stephen J.: The SGML
FAQ Book. Understanding the Foundation of HTML and XML, Dordrecht, Boston und London 1997, S. 211-212 und Goldfarb,
Charles F.: The SGML Handbook, S. 382-390.
106
Das World Wide Web Consortium pflegt eine ausgezeichnete Webseite mit maßgeblichen Informationen zu Definitionen und
zur laufenden Weiterentwicklung von URI, URL und FPI, <http://www.w3.org/Addressing/>.
195
6.5.2.3. Interne Entitäten
Wie bereits erwähnt, treten die in Dokumentinstanzen verwendbaren allgemeinen
Entitäten in zwei verschiedenen Grundtypen auf: interne und externe Entitäten.
Allgemeine interne Entitäten sind die einfachsten. Sie enthalten die referenzierte
Inhaltserweiterung unmittelbar als Teil der Entitätsdeklaration. Allgemeine interne
Entitäten enthalten Text und befinden sich immer innerhalb der zu parsenden
Instanz. Deklarationen für allgemeine interne Entitäten in der Deklarationsteilmenge
einer Dokumentinstanz beginnen mit der Zeichenfolge <!ENTITY, gefolgt von dem
Entitätsnamen sowie dem in einfachen oder doppelten Anführungszeichen
stehenden Entitätsinhalt, wie im folgenden Beispiel:
<!ENTITY
entity_name
"specification_of_content">
Es ist zu beachten, dass die Schlüsselwörter PUBLIC und SYSTEM bei
Deklarationen für interne Entitäten nicht erforderlich sind. Interne Entitäten sind nur
bei Text, der in einem bestimmten kodierten Findbuch mehrmals vorkommt sinnvoll.
Sie können von anderen Dokumentinstanzen aus nicht referenziert werden. Ein
Archiv verwendet z. B. eine allgemeine interne Entität bei der Kodierung eines
Findbuchs, in dem der Name der Organisation, deren Unterlagen in dem Findbuch
beschrieben sind, lang, komplex und anfällig für typographische Fehler ist. In einem
solchen Fall kann eine Entität in der Dokumenttypdeklaration wie folgt deklariert
werden:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" [
<!ENTITY stuffsoc "Society for the Preservation, Beautification,
and General Betterment of the Stufftown Memorial Stuffatorium">
]>
In der EAD-Instanz kann dann diese deklarierte Entität an zahlreichen Stellen wie
folgt referenziert werden:
<origination><corpname>&stuffsoc;</corpname></origination>
[...]
<prefercite><head>Preferred Citation</head><p>[identification
of item], &stuffsoc; Records, Stufftown Memorial Stuffatorium,
Stufftown, NS.</p></prefercite>
[...]
<bioghist><p>Die &stuffsoc; wurde 1872 vom Stadtrat von Stufftown
gegründet und zu Beginn mit einem Fonds ausgestattet, um Betriebsund Anschaffungskosten zu decken, und zwar durch die Freigiebigkeit
von ... </p></bioghist>
Jede SGML-fähige Software, die bei der Verarbeitung auf diese Entitätsreferenzen
stößt, kann sie vor der Verarbeitung der kodierten Instanz zum vollen Text, der in der
Entitätsdeklaration steht, erweitern.
196
6.5.2.4. Externe Entitäten
Allgemeine externe Entitäten sollen, wenn ein SGML-fähiges Softwarepaket die
betreffende Dokumentinstanz verarbeitet, entweder geparst oder nicht geparst
werden. Wenn die Entität auf Dateien mit SGML-Zeichendaten verweist, z. B. einen
langen, sich häufig wiederholenden Auszeichnungsabschnitt, sollten angestrebet
werden, dass der Parsingprozess sowohl die Dokumentinstanz als auch den Text der
externen Entität umfasst. In anderen Fällen ist es nicht erwünscht, dass Dateien mit
externen Referenzen zusammen mit der kodierten Instanz validiert werden. Beispiele
hierfür sind Entitäten, die externe SGML-Dokumentinstanzen referenzieren, die
wiederum andere EAD-kodierte Findbücher oder mit einer anderen DTD kodierten
Text enthalten. Ein anderes Beispiel sind Entitäten, die Nicht-SGML-Dateien
referenzieren (z. B. Bilder, im GIF- oder JPEG-Format oder MPEG-Videodateien).
In den folgenden beiden Unterabschnitten sind die Entitätsdeklarationen genau
beschrieben, die zur Spezifizierung von zu parsenden bzw. nicht zu parsenden
Daten dienen.
6.5.2.4.1. Extern gespeicherte zu parsende Daten
Zuerst befassen wir uns mit extern gespeicherten und EAD-kodierten Daten, die als
Teil der Dokumentinstanz geparst werden sollen, in der sie referenziert werden.
Diese externen Entitätsreferenzen gleichen allgemeinen internen Entitätsreferenzen,
mit dem Unterschied, dass in der literalen, in Anführungszeichen stehenden
Zeichenfolge die externe Speicherstelle der in die Dokumentinstanz
aufzunehmenden Datei angegeben werden muss. Dies kann mit Hilfe von
öffentlichen Identifikatoren und/oder Systemidentifikatoren geschehen.
Eine derartige Verwendung von Entitäten kann ein Archiv beim Management von
häufig zu aktualisierenden Informationen unterstützen, die an vielen Stellen in
kodierten Findbücher auftreten. Anstatt solche Informationen als Teil jeder EADInstanz einzugeben, kann man sie auch als gesonderte Datei speichern und in jeder
Instanz mit einer Entitätsreferenz auf sie verweisen. Bild 6.5.2.4.1a enthält ein
Beispiel für eine Kontaktinformation, die als gesonderte Datei tpncdsp.sgm
gespeichert ist, so dass sie als Entität in jedem Findbuch des Archivs referenziert
werden kann. Bei der Aktualisierung dieser einzigen Datei – z. B. wenn sich die
Vorwahl des Archivs ändert – ändert sich die Kontaktinformation in allen kodierten
Findbüchern des betreffenden Archivs. Wäre die Ortsvorwahl in jeder der
Einzeldateien fest kodiert worden, wäre eine solche Aktualisierung weitaus
arbeitsintensiver.
197
<list type="simple">
<head>Kontaktinformation </head>
<item>Rare Book, Manuscript, and Special Collections
Library</item>
<item>Duke University</item>
<item>P.O. Box 90185</item>
<item>Durham, North Carolina</item>
<item>27708-0185 USA</item>
<item>Telefon: 919/660-5822</item>
<item>Fax: 919/660-5934</item>
<item>Email: [email protected]</item>
<item>URL: http://scriptorium.lib.duke.edu/</item>
</list>
Bild 6.5.2.4.1a. Inhalt der Datei tpncdsp.sgm
Es folgt ein Beispiel für eine Entitätsdeklaration, mit der die Datei tpncdsp.sgm
ausschließlich unter Verwendung eines öffentlichen Identifikators referenziert wird:
<!ENTITY tp-ncd-spcoll PUBLIC "-//Duke University::Rare Book,
Manuscript, and Special Collections Library//TEXT (Titelseite: Name
und Adresse)//EN">
Diese Form der Entitätsdeklaration ist nur in SGML-Systemen gültig. In XML muss
zusätzlich ein Systemidentifikator angegeben werden, wie folgendes Beispiel zeigt, in
dem ein relativer URI verwendet wird:
<!ENTITY tp-ncd-spcoll PUBLIC "-//Duke University::Rare Book,
Manuscript, and Special Collections Library//TEXT (Titelseite: Name
und Adresse)//EN" "tpncdsp.sgm">
Schließlich könnten die Informationen in Bild 6.5.2.4.1a als Entität deklariert werden,
indem nur ein Systemidentifikator verwendet wird. Diese Vorgehensweise ist auch in
XML gültig. Im nachstehenden Beispiel ist der Systemidentifikator als absoluter URI
angegeben:
<!ENTITY tp-ncd-spcoll SYSTEM
"http://scriptorium.lib.duke.edu/eadfiles/tpncdsp.sgm">
Ob nun ein Systemidentifikator (ein relativer oder absoluter URI) oder ein öffentlicher
Identifikator (entweder ein FPI oder ein weniger formeller lokaler öffentlicher
Identifikator) verwendet wird, richtet sich vor allem nach dem System bzw. den
Systemen, in dem bzw. denen denen kodierte Findbuchdaten gespeichert und
übertragen werden (das entsprechende Dateimanagement ist in Abschnitt 5.4
beschrieben). Die Verwendung eines relativen URI, der nicht die vollständige
Adresse der referenzierten Datei angibt, die mit dem verwendeten
Übertragungsprotokoll beginnt (beispielsweise http://), setzt voraus, dass alle
referenzierten Dateien sich in einer stabilen Verzeichnisstruktur befinden,
unabhängig von dem Server, auf dem sie abgelegt sind. An dieser Stelle ist
anzumerken, dass die Verwendung von relativen URI für Administratoren von
Verbund-Datenbanken mit kodierten Findbüchern problematisch sein kann. Archive,
die beabsichtigen, ihre Findbücher in solche Gemeinschaftsprojekten einzubringen,
sollten sich vor einer Entscheidung für relative URI mit dem Systemadministrator der
Verbund-Datenbank beraten. Die Verwendung von absoluten URI bedeutet einen
198
Mehraufwand bei der Datenpflege, wenn die referenzierten Dateien auf einem neuen
Server abgelegt werden, da die Adresse jedes einzelnen URI überarbeitet werden
muss. In den meisten Fällen lässt sich diese Arbeit allerdings mit Hilfe eines
einfachen Programms mit der Funktion „Suchen und Ersetzen“ erleichtern.
Für die Verwendung eines öffentlichen Identifikators wird das Vorhandensein einer
SGML-Katalogdatei107 vorausgesetzt, die ein System verwenden kann, um diesen
öffentlichen Identifikator in einen URI abzubilden oder aufzulösen. Die Stärke eines
auf öffentliche Identifikatoren gestützten Dateimanagementsystems beruht darin,
dass das Umspeichern von Dateien auf demselben oder auf andere Server mühelos
durch das Ändern einer einzigen Adresse in der Katalogdatei möglich ist, anstatt die
Entitätsreferenz in jeder EAD-Instanz ändern zu müssen. Die Planung der
Eigenschaften künftiger Speicher- und Übertragungssysteme muss sorgfältig
überlegt werden, wenn darüber entschieden wird, welche Art der Adressierung
gewählt werden soll. Abschnitt 7.5 enthält eine ausführliche Abhandlung der
verschiedenen Möglichkeiten zum Einfügen von Dateiadressen in Deklarationen für
externe Entitäten.
Bei der Referenzierung von Dateien mit kodierten Auszügen, z. B. wie in dem
Beispiel in Bild 6.5.2.4.1a, besteht ein wichtiger Unterschied zwischen SGML- und
XML-Systemen. Bei SGML-Systemen kann jede Textpassage zur weiteren
Verwendung exzerpiert werden, vorausgesetzt, sie wurde mit derselben DTD wie die
Dokumentinstanz kodiert, in der die Datei als Entität referenziert wird. Bei XML ist es
zusätzlich erforderlich, dass die exzerpierte Textpassage „wohlgeformt” ist, d. h.,
dass sie ein einziges Elternelement hat. Das Beispiel in Bild 6.5.2.4.1a erfüllt diese
Forderung von XML, da die Tags <list> und </list> alle anderen Informationen in der
Datei umschließen. Würden die Tags <list> und </list> dagegen entfernt, würde diese
Datei der XML-Forderung nach Wohlgeformtheit nicht mehr entsprechen.
Alle Deklarationen für allgemeine externe Entitäten – gleichgültig, ob für sie einen
öffentlicher Identifikator oder einen Systemidentifikator verwenden – können in
kodierten Dokumentinstanzen auf die gleiche Weise referenziert werden, wie es für
allgemeine interne Entitäten gezeigt wurde (siehe Unterabschnitt 6.5.2.3). Das
verdeutlicht folgendes Beispiel:
<publisher>Rare Book, Manuscript, and Special Collections
Library<lb>
Duke University<lb>
Durham, North Carolina</publisher>
&tp-ncd-spcoll;
107
Weitere Informationen zur SGML-Katalogdatei und zur formellen FPI-Struktur sind in Encoded Archival Description
Retrospective Conversion Guidelines. A Supplement to the EAD Tag Library and EAD Guidelines, Abschnitt VI (Naming and
Declaring Referenced External Entities) enthalten, vgl. <http://sunsite.berkeley.edu/amher/upguide.html#VI>. Diese Richtlinien
wurden sowohl im American Heritage Virtual Archive Project als auch im Online Archive of California Project angewendet.
199
6.5.2.4.2. Extern gespeicherte nicht zu parsende Daten
Die zweite Art von externen Entitätsreferenzen verweist auf Dateien mit Daten, die
nicht zusammen mit der Dokumentinstanz geparst werden sollen. Wie bereits
erwähnt, gibt es zahlreiche Gründe dafür, die Parsersoftware nicht den Inhalt der
referenzierenten Entität auflösen zu lassen. Zwei wichtige Gründe dafür sind, dass
die referenzierte Datei entweder nicht aus Textdaten besteht, die eine SGML-fähige
Software erkennen würde (z. B. Bilder im GIF-Format) oder dass die referenzierte
Datei zwar von SGML erkennbare Zeichendaten enthält, sie aber nicht Teil der
betreffenden Dokumentinstanz sein soll, z. B. ein anderes EAD-kodiertes Findbuch
oder ein literarischer Text, der mit Hilfe der TEI-DTD kodiert wurde.
Der SGML-Standard gibt an, dass für Entitätsdeklarationen, die nicht geparst werden
sollen, das Schlüsselwort NDATA zu verwenden ist, gefolgt von einem
Notationsnamen, der der Anwendersoftware den Typ der externen Datei angibt, den
die Entitätsdeklaration referenziert. Eine Notationsdeklaration entweder in der DTD
oder im Prolog einer EAD-Instanz gibt einen Notationsnamen und einen FPI für den
Typ einer referenzierten NDATA-Datei an und muss auftreten, bevor eine allgemeine
externe Entität deklariert werden kann. Die Datei endnotat.ent, eine der zur EADDTD gehörigen Dateien, umfasst eine Reihe von Standard-Notationsdeklarationen.
Sie liefert Notationen für SGML sowie verschiedene weit verbreitete Nicht-SGMLDatentypen, darunter HTML, JPEG, MPEG, XML, PCX, GIF und TIFF. Da diese
Notationen in der EAD-DTD deklariert sind, kann man externe Entitäten im Prolog
der Dokumentinstanz deklarieren, die solche Dateien referenzieren. Jede
Notationsdeklaration enthält einen Notationsnamen, der benötigt wird, um
Entitätsreferenzen zu dem betreffenden Dateityp zu erzeugen.
Notationsdeklarationen haben die gleiche Format wie Deklarationen für allgemeine
externe Entitäten. Bild 6.5.2.4.2a zeigt die Notationsdeklaration für GIF-Dateien in
der EAD-DTD:
Notationsname
<!NOTATION gif PUBLIC "+//ISBN 0-7923-9432-1::Graphic
Notation//NOTATION CompuServe Graphic Interchange Format//EN">
Bild 6.5.2.4.2a. EAD- Notationsdeklaration für GIF-Dateien
Beim Kodieren der Findbücher eines Archivs soll vielleicht ein GIF-Bild des
Archivsiegels oder des Archivgebäudes eingefügt werden. Dies ist möglich, indem in
der Deklarationsteilmenge des Prologs jeder EAD-Instanz eine Deklaration für eine
allgemeine externe Entität erzeugt wird. Diese Entitätsdeklaration muss, wie bereits
erwähnt, eine Adresse für die Bilddatei auf dem verwendeten Server enthalten,
wobei ein öffentlicher und/oder ein Systemidentifikator zu verwenden ist. Eine
Deklaration für eine allgemeine externe Entität, bei der ein absoluter URI als
Systemidentifikator dient, kann für den oben beschriebenen Zweck so aussehen:
200
<!ENTITY lcseal SYSTEM
"http://lcweb2.loc.gov/sgmlstd/panorama/lcseal.gif" NDATA gif>
Es folgt ein Beispiel für eine Entitätsdeklaration für den gleichen Zweck, und zwar mit
einem öffentlichen Identifikator und einem Systemidentifikator, in diesem Fall einem
relativen URI:
<!ENTITY dukeseal PUBLIC "-//Duke University::Rare Book,
Manuscript, and Special Collections Library//NONSGML
(dukeseal)//EN""dukeseal.gif" NDATA gif>
Mit dem NDATA-Schlüsselwort, das auf den URI folgt, wird der SGML-fähigen
Verarbeitungssoftware mitgeteilt, dass die referenzierte Datei Daten enthält, die nicht
zusammen mit der EAD-Instanz verarbeitet werden sollen. Indem der deklarierte
Notationsname für einen Datentyp nach dem NDATA-Schlüsselwort angegeben wird,
erhält die Software einen Hinweis darauf, wie sie diese Daten, die sie nicht
analysieren soll, verarbeiten kann.
Da diese Entität außerhalb der betreffenden Dokumentinstanz steht und nicht als Teil
von ihr geparst werden soll, wird auf sie im Dokument nicht unter Verwendung des
Formats für Entitätsreferenzen – was in Unterabschnitt 6.5.2.4.1 erläutert wurde –
verwiesen. Es wird vielmehr eines der Verknüpfungselemente von EAD zusammen
mit einem Attribut ENTITYREF verwendet, um eine Referenz auf die externe Entität
zu erzeugen (die externen Verknüpfungselemente und -attribute von EAD sind in
Abschnitt 7.3 im Einzelnen beschrieben).
201
Kapitel 7: EAD-Verknüpfungselemente
7.1. Einführung................................................................................................................................. 203
7.1.1. Struktur von Links............................................................................................................... 203
7.1.2. Merkmale von Links ........................................................................................................... 204
7.1.2.1. Zieladresse .................................................................................................................. 205
7.1.2.2. Umfang ........................................................................................................................ 205
7.1.2.3. Quelladresse................................................................................................................ 206
7.1.2.4. Inhalt ............................................................................................................................ 207
7.1.3. Verwendung von Verknüpfungselementen ........................................................................ 207
7.2. Interne Verknüpfungen ............................................................................................................. 209
7.2.1. Zeiger <ptr> (Pointer) und Verweis <ref> (Reference) mit Attribut Ziel TARGET ............. 209
7.2.2. Das nichtverknüpfende Bündelungselement Pointer Group <ptrgrp> ............................... 211
7.2.3. Gruppierung von Verweisen <linkgrp> (Linking Group) als Bündelungselement für Ort des
Zeigers <ptrloc> (Pointer Location) und Ort des Verweises<refloc> (Reference Location) ........ 212
7.2.4. Die Attribute XLINK:FORM und INLINE............................................................................. 213
7.2.5. Das Attribut PARENT bei den Elementen Behälter <container> und Lagerort <physloc>
(Physical Location) ....................................................................................................................... 214
7.3. Externe Verknüpfungen ............................................................................................................ 218
7.3.1. Das Attribut ENTITYREF ................................................................................................... 218
7.3.2. Das Attribut HREF.............................................................................................................. 219
7.3.3. Archivischer Nachweis <archref> (Archival Reference), Bibliographischer Nachweis
<bibref> (Bibliographical Reference) und Titel <title> (Title)........................................................ 220
7.3.3.1. Allgemeine Verwendung von <archref>, <bibref> und <title> ..................................... 221
7.3.3.2. Verwendung von <archref> zur Aufgliederung großer Findbücher ............................. 222
7.3.4. Externer Zeiger <extptr> (Extended Pointer) und Externer Verweis <extref> Extended
Reference .................................................................................................................................... 223
7.3.5. Gruppierung von Verweisen <linkgrp> (Linking Group) als Bündelungselement für Ort des
Externen Zeigers <extptrloc> (Extended Pointer Location) und Ort des Externen Verweises
<extrefloc> (Extended Reference Location) ................................................................................ 224
7.3.6. Digitale Archivobjekte <dao>, <daogrp> und <daoloc>..................................................... 225
7.3.7. Das Attribut XPOINTER ..................................................................................................... 227
7.4. Eigenschaften von Links........................................................................................................... 229
7.4.1. Die Attribute ACTUATE, SHOW und BEHAVIOR.............................................................. 229
7.4.2. Die Attribute ROLE, TITLE, CONTENT-ROLE und CONTENT-TITLE.............................. 231
7.5. Management von externen Links.............................................................................................. 234
7.5.1. Verwendung von ENTITYREF ........................................................................................... 235
7.5.2. Verwendung von HREF ..................................................................................................... 237
7.5.3. Kombination der beiden Verfahren .................................................................................... 238
7.6. Beispiele für optimal kodierte Verknüpfungselemente ............................................................. 239
202
7.1. Einführung
Bei der Kodierung von Findbüchern erfüllen Verknüpfungselemente die drei
folgenden Funktionen:
•
•
•
Sie erleichtern den Einsatz von Hypertext und bieten einen Navigationspfad,
der von Nutzern genutzt werden kann, anstatt die kodierten Informationen in
einer Dokumentinstanz linear durchzugehen.
Sie ermöglichen es, ein Textdokument mit Multimedia-Funktionen zu
versehen, und zwar durch Einbindung von Nichttextinformationen wie Grafiken
oder Tondateien.
Sie stellen außerdem Verbindungen zu externen Textdokumenten her.
7.1.1. Struktur von Links
In einem SGML-gestützten Kodierschema wie EAD werden Verknüpfungselemente
und Attribute zur Herstellung der gewünschten Links benötigt. Der Link selbst hat
zwei Funktionen. Er ist erstens die mit Hilfe eines Verknüpfungselements erstellte
Deklaration, dass eine Beziehung zwischen der in einem Element kodierten
Information und der an einer anderen Stelle verfügbaren Information besteht, und
zweitens eine Adresse oder der Name einer Ressource, die in eine Adresse
aufgelöst werden kann, für das Ziel des zu erstellenden Links, das als Wert eines
Attributs im Verknüpfungselement angegeben wird.
<link destination = "adress">
Linkelement
Linkattribut
Ziel
Bild 7.1a. Teile eines Verknüpfungselements
Bezeichnete Elemente innerhalb von kodierten Dokumenten oder auch ganze
Dokumente können als Ressourcen in einem Link dienen, und zwar entweder als
Quellen oder als Ziele. Wird ein Link durch Einfügen eines Verknüpfungselements in
einem kodierten Findbuch erstellt, dient das Element im Allgemeinen als
Quellenresource für den Link. Jedes Verknüpfungselement hat eine Gruppe von
Verknüpfungsattributen, die weitere Informationen zum Link liefern. Einige dieser
Attribute geben Adressen für die Zielressource des Links an, wogegen andere
Angaben darüber enthalten, wie sich der Link verhalten soll, wenn die
Dokumentinstanz an ein Ausgabegerät übergegeben wird. Die Funktion
verschiedener Verknüpfungsattribute wird weiter unten im Zusammenhang mit den
EAD-Verknüpfungselementen beschrieben, mit denen sie zusammen eingesetzt
werden können.
Es ist unbedingt zu beachten, dass die Software die Werte der Verknüpfungsattribute
und die Anweisungen im Stylesheet interpretieren muss, um die
Verknüpfungsmöglichkeiten konkret umzusetzen. Version 1.0 von EAD wurde eigens
darauf ausgelegt, Verknüpfungen nach den Definitionen von XLink- und XPointer-
203
Spezifikationen zu unterstützen, die z. Z. im Entwurf vorliegen.108 Es gibt jedoch
derzeit keine kommerziellen Softwarepakete, die bestimmte, in EAD verfügbare
Verknüpfungsattribute implementieren. Die Ausführungen dieses Kapitels beziehen
sich auf die allgemeinen Funktionen der verschiedenen Verknüpfungselemente und
-attribute in EAD und nicht auf die Einzelheiten, wie ein bestimmtes
Übertragungssystem diese kodierten Links übersetzt oder implementiert. Das Kapitel
enthält allerdings einige Empfehlungen zu Attributen, die Archivare wenigstens
anwenden sollten, wenn sie in EAD-kodierten Findbüchern Links erstellen.
7.1.2. Merkmale von Links
Die folgenden 15 EAD-Elemente können zur Erstellung von Links verwendet werden:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Archivischer Nachweis <archref> (Archival Reference)
Bibliografischer Nachweis <bibref> (Bibliographic Reference)
Digitales Archivobjekt <dao> (Digital Archival Object)
Gruppe digitaler Archivobjekte <daogrp> (Digital Archival Object Group)
Ort des digitalen Archivobjekts <daoloc> (Digital Archival Object Location)
Externer Zeiger <extptr> (Extended Pointer)
Ort des Externen Zeigers <extptrloc> (Extended Pointer Location)
Externer Verweis <extref> (Extended Reference)
Ort des Externen Verweises <extrefloc> (Extended Reference Location)
Gruppierung von Verweisen <linkgrp> (Linking Group)
Zeiger <ptr> (Pointer)
Ort des Zeigers <ptrloc> (Pointer Location)
Verweis <ref> (Reference)
Ort des Verweises <refloc> (Reference Location)
Titel <title> (Title).
Dreizehn davon managen Links unmittelbar. Die zwei restlichen (<daogrp> und
<linkgrp>) sind Hüllenelemente, die mehrere verwandte Links zusammenfassen.
Diese 15 Elemente haben einige wichtige Eigenschaften.
Konzeptuell hat jeder Link vier Facetten, von denen jede nur zwei oder drei Werte
haben kann. Verschiedene Verknüpfungselemente besitzen verschiedene
Kombinationen dieser Facettenwerte. In jedem Fall wird der für die Kodierung eines
Findbuchs das geeignete Verknüpfungselement anhand dieser Merkmale und
aufgrund anderer Überlegungen, die weiter unten in diesem Kapitel behandelt
werden, ausgewählt. Die wichtigen Eigenschaften von Links sind nachstehend
aufgeführt.
Zieladresse
Umfang
Quelladresse
Inhalt
Intern oder extern
Einfach, ortsangebend oder erweitert
Inline oder Out-of-line
Leer oder Text enthaltend
(Siehe Abschnitt 7.1.2.1)
(Siehe Abschnitt 7.1.2.2)
(Siehe Abschnitt 7.1.2.3)
(Siehe Abschnitt 7.1.2.4)
Attribute spielen bei Verknüpfungselementen eine sehr wichtige Rolle. TARGET,
HREF und ENTITYREF dienen dazu, Zieladressen für Links anzugeben. ACTUATE,
108
Weitere Informationen zu XLink und XPointer, den Verknüpfungs- und Adressierungsspezifikationen, die gleichzeitig mit XML
entwickelt werden, finden sich auf der Webseite des World Wide Web Consortium, <http://www.w3.org/TR/WD-xlink> für XLink
und <http://www.w3.org/TR/WD-xptr> für XPointer.
204
SHOW und BEHAVIOR bestimmen gemeinsam, wie die Verarbeitungssoftware Links
für Nutzer darstellt. ROLE, TITLE, CONTENT-ROLE, CONTENT-TITLE und andere
für die Verknüpfungselemente von EAD spezifische Attribute enthalten weitere
Angaben über die Art von Links oder die an ihnen beteiligten Ressourcen.
7.1.2.1. Zieladresse
Links können in Bezug auf eine kodierte Dokumentinstanz entweder intern oder
extern sein. Beim Kodieren eines Findbuchs wird z. B. ein interner Link an einer
geeigneten Stelle im Element Erschließungsangaben untergeordneter Komponenten
<dsc> verwendet, um den Text einer Zugriffsbeschränkung zu referenzieren, der auf
Bestandsebene kodiert wurde. Innerhalb desselben Findbuchs wird z. B. ein externer
Link verwendet, um einen Zeiger auf das kodierte Findbuch eines Bestandes mit
verwandten Materialien zu erstellen. Ein externer Link kann auch einen Zeiger zum
Digitalisat eines Fotos oder eines anderen Gegenstandes, das sich in dem Bestand
befindet, liefern.
7.1.2.2. Umfang
Alle Beispiele für Links im vorigen Abschnitt beziehen sich auf Einweglinks, denen
der Nutzer nur in Richtung Quelle-Ziel folgen kann, wie aus Bild 7.1.2.2a hervorgeht.
<accessrestrict id=“restric1“><p>Die Benutzung von einigen
Materialien in diesem Bestand ist eingeschränkt
...<p></accessrestrict>
[andere mögliche Elemente und Text]
<c01 level=“series“><did>[...]</did>
<scopecontent>
[...]
<p><ref target=“restrict1“>Die Benutzung zu der Korrespondenz in
diesen Serien wurde zurvor zwischen dem Geber und seinem Sohn als
eingeschränkt festgelegt.</ref><p>
</scopecontent>
</c01>
Bild 7.1.2.2a. Ein Einweglink.
Bei der Kodierung kann ein Link zu und von einer Zieladresse erzeugt werden, indem
man zwei Einweglinks erstellt, denen Nutzer in jeweils entgegengesetzter Richtung
folgen können, wie Bild 7.1.2.2b es veranschaulicht.
<c02 level=“series“><did> <unittitle>Serie 4: Korrespondenz,
<unitdate>1948-1969</unitdate></unittitle></did>
<c03 level=“file“><did id=“s04.001“><unittitle>Aardvark Projekt,
<unitdate>1951-1955</unitdate>
<ptr target=s09.001“></unittitle></did>
</c03></c02>
[andere mögliche Elemente und Text]
<c02 level=“series“><did> <unittitle> Serie 9: Thematische Akten,
<unitdate>1946-1976</unitdate></unittitle></did>
<c03 level=“file“><did id=“s09.001“><unittitle>Aardvark Projekt,
<unitdate>1951-1955</unitdate>
<ptr target=“s04.001“></unittitle><did>
</c03></c02>
Bild 7.1.2.b. Zwei Einweglinks, die Links zum Ziel hin und davon weg erstellen
205
Die Richtung, in der man den Links folgt, ist in beiden Bildern mit Pfeilen angegeben.
Einige Softwareanwendungen unterstützen es, einem Link in Richtung Quelle-Ziel
und zurück zur Quelle zu folgen, ohne dass dazu zwei Einweglinks kodiert werden
müssen.
Die vorliegende Erläuterung der Links konzentriert sich auf einfache Links, da sie von
allen SGML-fähigen Softwareanwendungen unterstützt werden. Die meisten Links,
die bei der Kodierung einer EAD-Instanz erzeugt werden, sind einfache Links. Sie
haben folgende Eigenschaften:
•
•
•
Die Quellenressource für den Link wird mit einem Verknüpfungselement
erstellt.
Ein Verknüpfungsattribut liefert für jedes Verknüpfungselement nur ein
einziges Ziel.
Jedem Link kann der Nutzer nur in einer Richtung – Quelle-Ziel – folgen.
Alle anderen Typen von Links gelten als erweiterte Links. Das Konzept der
erweiterten Links wird derzeit im Rahmen der Entwicklung von XLink, der
Verknüpfungskomponente von XML, erstellt und erweitert und wird hier daher nur
kurz behandelt. EAD hat eine Hauptkategorie von Verknüpfungselementen, die
immer erweitert sind. Es sind die dem Bündeln dienenden Verknüpfungselemente
<linkgrp> und <daogrp>. Sie werden später in Abschnitten 7.3.5 und 7.3.6 im
Einzelnen erläutert. Sie gelten als erweiterte Links, da sie selbst keine Zielressource
für den erstellten Link enthalten, sondern mehrere Elemente zur Ortsangabe
(<extrefloc>, <daoloc>) zusammenfassen, die ihrerseits die Adressen der
verschiedenen Ziele des Links enthalten. Das Attribut XLINK:FORM, das die
Bezeichnung jedes Verknüpfungselements als einfach, erweitert oder ortsangebend
enthält, wird in Abschnitt 7.2.4 behandelt.
7.1.2.3. Quelladresse
Unter einem Inline-Link versteht man einen Link, bei dem das Verknüpfungselement
im kodierten Dokument als eine der Ressourcen des Links beteiligt ist,
normalerweise als Quelle. Ein Out-of-line-Link ist ein Link, der nicht als Ressource an
dem zu erstellenden Link beteiligt ist. Dies ist ein neues und derzeit noch
vergleichsweise theoretisches Konzept, das als Teil der XLink-Spezifikation
entwickelt wird. Out-of-line-Links ermöglichen es, wenn ein entsprechend
ausgelegtes System sie unterstützt, einen Link zwischen zwei oder mehr externen
Dokumenten zu erstellen, die nicht unmittelbar bearbeitet werden können.109
Dadurch ließe sich z. B. die Entwicklung von Annotationsservern erleichtern, um
Kommentare in der Art von „Post-it-Notizen” für Webseiten zu verwalten. Eine
Anwendung dieser Technologie für Archivinformationsserver könnte darin bestehen,
Lehrern die Möglichkeit zu geben, ein Netzwerk von Verknüpfungen zwischen
kodierten Findbüchern – die außerhalb der Findbücher gespeichert und verwaltet
werden – zu schaffen, das speziell auf die Bedürfnisse von Schülern bzw. Studenten
zugeschnitten ist. Das Konzept der Out-of-line-Verknüpfung wird hier eingeführt,
damit Sie durch den Anwenderleitfaden schon etwas vertraut mit ihm gemacht
werden, wenn Sie in der XML-Literatur darauf stoßen, und die Optionen verständlich
109
Goldfarb, Charles F. / Prescod, Paul: The XML Handbook, S. 502-505.
206
sind, die es für den Wert des Attributs INLINE gibt (siehe Abschnitt 7.2.4). Für alle
praktischen Zwecke sollten die Anwender von EAD derzeit allerdings die
Standardvorgabe "true" für das Attribut INLINE verwenden, was bedeutet, dass es
sich um ein Inline-Link handelt.
7.1.2.4. Inhalt
Bisweilen dienen Verknüpfungselemente nur als Zeiger zu anderen Stellen. Es wird
weder ein Titel noch eine Erläuterung für den Link benötigt. In anderen Szenarien ist
ein erläuternder Text zu dem Link erforderlich. Für diesen Zweck sind bestimmte
Verknüpfungselemente vorgesehen. Nicht für die Aufnahme von erklärendem oder
beschreibendem Inhalt vorgesehene Verknüpfungselemente sind in der DTD als
EMPTY definiert (leere Elemente sind in Abschnitt 6.3 behandelt). Oft richtet sich die
Entscheidung für ein bestimmtes Element danach, ob eine Textbeschreibung
erforderlich ist oder nicht
7.1.3. Verwendung von Verknüpfungselementen
Die in EAD verfügbaren 15 Verknüpfungselemente sind in Tabelle 7.1.3a nach den
vorstehend beschriebenen Eigenschaften geordnet.110
Einfache Links
Erweiterte Links
Einfache Links sind
Inline-Links.
Erweiterte Links können entweder Inline- oder Outof-line-Links sein. Diese Links müssen mit Hilfe von
<linkgrp> oder <daogrp> gebündelt werden.
<refloc>
<ptrloc>
Mit Text <ref>
Leer
<ptr>
<archref>, <bibref>,
Mit Text <dao>111, <extref>,
Externe Links
<title>
Leer
<extptr>
Interne Links
<daoloc>, <extrefloc>
<extptrloc>
Tabelle 7.1.3a. EAD-Verknüpfungselemente geordnet nach wichtigen
Eigenschaften. Da die derzeit verfügbare Software die Verwendung
erweiterter Links im Allgemeinen nicht unterstützt, muss bei der EADImplementierung die Verwendung der im schattierten Bereich aufgeführten
Verknüpfungselemente mit dem Systemexperten beraten werden.
Wie oben erwähnt, weist jedes dieser Elemente112 auf das Vorhandensein eines
Links zwischen den kodierten Daten und den an anderer Stelle vorhandenen
Informationen hin. Diese „andere Stelle“ kann sich innerhalb desselben Findbuchs,
auf demselben Server oder auf einem anderen, über das Internet zugänglichen
Server befinden.
Die folgende Abhandlung erläutert die verschiedenen Verknüpfungsoptionen und
geht vom Einfachen zum Komplexen vor. Außerdem werden zuerst die
110
Die Liste in Bild 9 auf Seite 12 der (A.d.Ü.: englischen) Druckversion EAD-Tag-Library, Version 1.0, enthält zwei Fehler. Sie
bezeichnet irrtümlicherweise <ptrgrp> als 15. EAD-Verknüpfungselement. In Wirklichkeit dient <ptrgrp> als Bündelungselement
für andere Verknüpfungselemente, hat jedoch nicht die nötigen Attribute, um genau wie die anderen in der Liste genannten
Elemente zu funktionieren. Außerdem fehlt in der Liste in Bild 9 das Element <title>, das in EAD als Verknüpfungselement dient.
111
Es ist zu beachten, dass <dao> oft als leeres Element verwendet wird, jedoch auch <daodesc> enthalten kann, wenn der
Kontext für einen Link nicht von anderen Elementen geliefert wird. Das Element <dao> ist technisch gesehen kein leeres
Element, weil es nicht als solches in der EAD-DTD definiert ist.
112
Mit Ausnahme von <archref>, <bibref> und <title>, wie in Abschnitt 7.3.3 erwähnt.
207
Verknüpfungsoptionen beschrieben, die jedes SGML- oder XML-System unterstützen
dürfte. Anschließend werden kurz die komplexeren Optionen behandelt, die später
die derzeit noch unvollständigen und noch nicht implementierten Spezifikationen für
XLink und XPointer in XML nutzen werden. An dieser Stelle ist anzumerken, dass,
wenn die entsprechenden Spezifikation voll entwickelt ist und Software zu ihrer
Implementierung ohne Weiteres erhältlich ist, Version 1.0 der EAD-DTD dafür
gedacht war, vollkommen mit der XML-Kodierung kompatibel zu sein. Darüber, in
welchem Ausmaß ein bestimmtes Archiv viele der komplexeren
Verknüpfungsmöglichkeiten von EAD nutzen möchte, ist nach Beratung mit
Fachleuten mit den nötigen Kenntnissen über das lokale Übertragungssystem zu
entscheiden, das das Archiv für seine kodierten Findbücher zu nutzen beabsichtigt.
In der derzeitigen Umgebung beschränken sich die Möglichkeiten auf die
nachstehend beschriebenen einfacheren Verknüpfungsoptionen.
Es ist zu beachten, dass die Beispiele in den Abschnitten 7.2, 7.3 und 7.4 aufgrund
besserer Verständlichkeit nur die Verknüpfungselementattribute umfassen, die in den
einzelnen Unterabschnitten behandelt werden. Abschnitt 7.6 enthält mehrere
Beispiele optimal kodierter Verknüpfungselemente.
208
7.2. Interne Verknüpfungen
Durch interne Verknüpfungen können Nutzer nichtlinear durch die Informationen in
einem kodierten Findbuch navigieren. Es ist auch möglich, explizite Verbindungen
zwischen verwandten Informationen, die in verschiedenen Teilen eines Findbuchs
erscheinen, zu schaffen. Die folgenden Abschnitte informieren über die Verwendung
der Elemente und Attribute, die in EAD zur leichteren Erstellung von internen
Verknüpfungen verfügbar sind.
7.2.1. Zeiger <ptr> (Pointer) und Verweis <ref> (Reference) mit Attribut Ziel
TARGET
Interne Verknüpfungen innerhalb eines Dokuments, die einfachste Form der
Verknüpfung in EAD, werden mit Hilfe des Attributs TARGET geschaffen. Dieses nur
bei vier Elementen (<ptr>, <ptrloc>, <ref> und <refloc>) verfügbare Attribut
ermöglicht die Erstellung eines Links zu einem Ziel an anderer Stelle innerhalb
desselben Findbuchs. Ein Attribut TARGET muss einen "IDREF"-Wert haben, d. h.,
dieser Wert muss genau einem Wert entsprechen, der an anderer Stelle in
demselben kodierten Dokument als Attribut ID deklariert wurde. Diese Eins-zu-EinsÜbereinstimmung wird von der Syntaxanalysesoftware überprüft, wenn sie die
Dokumentinstanz validiert. Fehlt diese Übereinstimmung, meldet die Software einen
Validierungsfehler.
Das Attribut ID spielt bei internen Links eine entscheidende Rolle. Das Attribut
TARGET beim Verknüpfungselement zur Erstellung einer Quelle für einen internen
Link enthält den Wert des Attributs ID des Zielelements. Praktisch alle EAD-Elemente
haben ein Attribut ID und können daher Ziel eines internen Links sein. Wie bereits in
der allgemeinen Erläuterung der Attribute in Abschnitt 6.4 erwähnt, hat das Attribut ID
die Wertebezeichnung "ID", was bedeutet, dass sein Wert innerhalb einer
bestimmten kodierten Dokumentinstanz eindeutig sein muss. Jedes Text enthaltende
Element, das Ziel eines internen Links sein soll, muss einen eindeutigen Wert
erhalten, indem das Attribut ID in diesem Element verwendet wird. Nach Zuweisung
eines eindeutigen Wertes kann diese kodierte Information als Linkziel dienen.
Um einen internen Link zu erzeugen, ist wie folgt zu verfahren:
•
•
Mit Hilfe eines der vier internen Verknüpfungselemente, für die das Attribut
TARGET verfügbar ist, ist eine Quelle für die vom Link deklarierte Beziehung
zu erstellen.
Es ist eine Zieladresse (ein gültiger ID-Wert) für den Link zu erstellen, indem
das Attribut TARGET innerhalb des betreffenden Elements verwendet wird.
In Bild 7.2.1a wurde eine Bemerkung über Benutzungsbedingungen auf
Bestandsebene kodiert und für diese Notiz ein eindeutiger ID-Wert festgelegt. In
beiden nachstehenden Bildern wurden einige Elemente weggelassen, um sich auf
die Sachverhalte bzgl. der Links zu konzentrieren.
209
<archdesc level=“collection“ langmaterial=“eng“
Die Verwendung eines IDtype=“invontory“>
Attributs ermöglicht es, dass
<did>[...]</did>
diese Information Ziel eines
<admininfo>
Links wird.
<accessrestrict id=“restrict1“>
<head>Zugangsbedingungen</head>
<p>Dieser Bestand ist offen für alle Forscher allerdings mit
folgender Ausnahme: Serie 2 (Korrespondenz) enthält 15 Ordner mit
Studierendenzeugnissen die dem State Student Records Act unterliegen
und für 75 Jahre gesperrt sind (1968:042). Der erste dieser Ordner
wird für Forscher ab dem 1. Januar 2035 und der letzte ab dem 1.
Januar 1947 zugänglich sein.</p>
Bild 7.2.1a. Erstellung eines eindeutigen ID-Wertes
In Bild 7.2.1b wurde ein Verknüpfungselement dazu verwendet, eine Beziehung
zwischen einer Bemerkung über Benutzungsbedingungen auf Serienebene und der
in Bild 7.2.1a gezeigten Bemerkung auf Bestandsebene herzustellen. Bei dieser
Kodierung ist eine Wiederholung der Bemerkung über Benutzungssbedingungen auf
den verschiedenen Erschließungsebenen nicht erforderlich.
<dsc type=“combined“>
Linkquelle, die das <ptr><c01 level=“series“
Element verwendet. Das
<did>[...]</did>
Linkziel verwendet das
</c01>
TARGET-Attribut.
<c01 level=“series“>
<did>
<unittitle>Serie 2: Korrespondenz
<unitdate tpye =“inclusive“>1952-1975</unitdate></unittitle>
<physdesc><extent>1,34 lfm</extent></physdesc>
</did>
<scopecontent><p>Die Korrespondenzserie enthält...</p>
<arrangement><p> Der größte Teil des Inhalts der Serie traf im
Archiv in chronologischer Reihenfolge ein. Diese Ordnung wurde
beibehalten. Die einzige Ausnahme ist eine Akte mit
Studierendenzeugnissen, für die Zugangsbeschränkungen gelten. <ptr
target=“restrict1“> Diese Ordner wurden vorrübergehend in einen
Behälter innerhalb der Sammlung überführt, der mit einer
Zugangsbeschränkung versehen wurde.</p></arrangement>
</scopecontent>
</c01>
</dsc>
Bild 7.2.1b. Verwendung eines Linkattributs zur Erstellung eines Links zum
kodierten ID-Wert in Bild 7.2.1a
Um Nutzer auf das Vorhandensein eines Links hinzuweisen, könnte die Verwendung
des leeren Elements <ptr> dazu führen, dass bei der Darstellung des kodierten
Dokuments statt des <ptr> ein Link-Anzeige-Icon eingefügt wird. Wie ein solches
Icon dargestellt wird, richtet sich nach dem System oder der Darstellungssoftware
(Client-Browser, Stylesheet oder SGML-Server).
Der Link in Bild 7.2.1b hätte auch mit Hilfe des Elements <ref> deklariert werden
können, das entweder Text oder andere Elemente enthalten muss, wie aus dem
folgenden Beispiel mit einem neu kodierten Auszug aus Bild 7.2.1b hervorgeht. Bei
der Darstellung für Nutzer wird der Text innerhalb des <ref>-Elements wahrscheinlich
210
hervorgehoben, um das Vorhandensein des Links anzuzeigen, ähnlich wie es bei
einem HTML-Browser üblich ist.
<arrangement><p>Der größte Teil der Serie traf im Archiv in
chronologischer Reihenfolge ein. Diese Ordnung wurde beibehalten.
<ref target="restrict1"> Die einzige Ausnahme ist eine Akte mit
Studierendenzeugnissen, für die Zugangsbeschränkungen gelten.</ref>
Die entsprechenden Ordner wurden vorrübergehend in einen Behälter
innerhalb der Sammlung überführt, der mit einer Zugangsbeschränkung
versehen wurde.</p></arrangement>
7.2.2. Das nichtverknüpfende Bündelungselement Pointer Group <ptrgrp>
Bisweilen sollen mehrere interne Einweglinks an einer bestimmten Stelle im
kodierten Dokument erzeugt werden. Dafür müssen die Zeigerelemente gebündelt
werden. EAD sieht ein Bündelungselement für interne Links vor, das an beliebiger
Stelle eines Findbuchs verwendet werden kann (siehe Abschnitt 7.2.3), sowie ein
Element, mit dem interne Links nur von dem Tag Indexeintrag <indexentry> (Index
Entry) aus gebündelt werden können. Zum Bündeln einer Gruppe einfacher interner
Links innerhalb eines Indexeintrags ist ein nichtverknüpfendes Element erforderlich,
und zwar Gruppierung von Zeigern <ptrgrp> (Pointer Group). Dieses dient z. B. dazu,
einen Namensindex für eine chronologisch geordnete Korrespondenzserie
festzulegen. In Bild 7.2.2a enthält das kodierte Bestandsverzeichnis einen
eindeutigen ID-Wert für jedes <unittitle>. In Bild 7.2.2b wird <ptrgrp> innerhalb eines
Index von Korrespondenzpartnern verwendet, um mehrere einfache interne Links zu
den Akten zu bündeln, die Unterlagen von jedem im Index genannten
Korrespondenzpartner enthalten. Die Entscheidung darüber, welches
Verknüpfungselement in diesem Fall zu verwenden ist, richtet sich danach, ob es bei
der Darstellung erforderlich ist, den Text des Indexeintrags als Teil des Linkindikators
wiederzugeben (in diesem Fall ist <ref> zu verwenden) oder nicht (dann ist <ptr> zu
verwenden).
<c02 level="file"><did>
<unittitle id="corresp197306"><unitdate>
June-December 1973</unitdate></unittitle>
</did></c02>
<c02 level="file"><did>
<unittitle id="corresp1974"><unitdate>
1974</unitdate> </unittitle>
</did></c02>
<c02 level="file"><did>
<unittitle id="corresp197501"><unitdate>
January-August 1975</unitdate></unittitle>
</did></c02>
Bild 7.2.2a. Festlegung eindeutiger ID-Werte für mehrere Elemente.
211
<add>
<index>
<head>Index der Korrespondenzpartner</head>
[weitere mögliche Elemente und Text ...]
<indexentry><persname>Doe, Jane S.: </persname>
<ptrgrp>
<ref target="corresp197306">24 August 1973
</ref>
<ref target="corresp1974">28 February and
16 July 1974</ref>
<ref target="corresp197501">15 March 1975
</ref>
</ptrgrp></indexentry>
[weitere mögliche Elemente und Text ...]
</index>
</add>
Bild 7.2.2b. Verwendung eines Verknüpfungsattributs, um
Links zu den in Bild 7.2.2a kodierten ID-Attributwert zu
erstellen.
7.2.3. Gruppierung von Verweisen <linkgrp> (Linking Group) als
Bündelungselement für Ort des Zeigers <ptrloc> (Pointer Location) und Ort des
Verweises<refloc> (Reference Location)
Außerhalb des Tags <indexentry> können interne Links auch mittels des Elements
Linking Group <linkgrp> gebündelt werden.113 Die Verknüpfungselemente <refloc>
und <ptrloc> müssen zusammen mit <linkgrp> anstatt mit <ref> und <ptr> verwendet
werden. Ein weiterer Unterschied besteht darin, dass das Element <linkgrp>, anders
als <ptrgrp>, ein Verknüpfungselement ist. Der so erzeugte Link gilt als erweiterter
Link. Anders als in dem Beispiel in Bild 7.2.2b, in dem <ptrgrp> eine Gruppe
unabhängiger einfacher Links bündelt, erzeugt <linkgrp> konzeptuell bedingt einen
einzelnen Link mit dem Potenzial für mehrere Quell- und Zielressourcen, und zwar
durch Bündelung einer Gruppe von Elementen (<ptrloc> oder <refloc>), die nur als
Ortsidentifikator dienen und Adressen für die Ressourcen des erweiterten Links
enthalten. Das Element <linkgrp> dient zusammen mit <ptrloc> und <refloc> dazu,
erweiterte interne Links zu anderen Informationen in demselben kodierten Findbuch
zu erzeugen.
Im Allgemeinen ist die Verwendung von <linkgrp> auf Links einzuschränken, die ein
bestimmtes Element gemeinsam haben, wobei das Bündeln das mögliche
Zusammenwirken der Linkziele erhöht. Das Element <linkgrp> wird wahrscheinlich in
erster Linie zum Bündeln von externen Links (siehe Abschnitt 7.3.5) dienen. Die
derzeit erhältliche Software ist u. U. nicht in der Lage, <linkgrp> für Nutzer zwecks
Darstellung zu implementieren. Auch die Entwicklung von XLink einschließlich des
Konzepts der erweiterten Links ist noch nicht abgeschlossen. Archivare, die sich für
die Nutzung erweiterter Links in ihren Findbüchern interessieren, sollten die
Entwicklungsarbeiten an XLink verfolgen.114
113
In der Beschreibung von <linkgrp> auf Seite 172 der (A.d.Ü.: englischen) Druckversion EAD-Tag-Library, Version 1.0, steht,
dass dieses Element nur dazu verwendet werden kann, „um mehrere Out-of-line-Links zu aktivieren". Es ist zu beachten, dass
<linkgrp> auch zum Bündeln von Inline-Links (extern und intern) verwendet werden kann.
114
Aktuelle Informationen zur Entwicklung von XLink durch das World Wide Web Consortium vgl. <http://www.w3.org/TR/WDxlink>.
212
7.2.4. Die Attribute XLINK:FORM und INLINE
In EAD sind zwei Verknüpfungsattribute definiert, die zu diesem Zeitpunkt für
Dokumentinstanzen noch nicht benötigt werden. Wenn auch diese Attribute z. Z.
noch nicht von Nutzen sind, dienen sie doch der Einführung von Konzepten, die
Archivare, die an der Weiterentwicklung von XML interessiert sind, ggf. hilfreich
finden. Beide Attribute können für interne oder externe Verknüpfungen verwendet
werden, daher gilt diese Abhandlung – sowohl hier als auch in Abschnitt 7.3 – auch
für externe Links.
Die Begriffe „simple“*, „extended“** und „locator“*** sind Werte für das Attribut
XLINK:FORM, das für alle EAD-Verknüpfungselemente bedingt verfügbar ist und es
künftig der Software ermöglichen wird, zu erkennen, ob ein bestimmter Link von
einem Typ ist, der in der XLink-Spezifikation definiert ist. Dieses Attribut ist für die
XLink-Funktionalität in der EAD-DTD spezifisch und wird als bedingt verfügbar
bezeichnet, weil die XML-Funktionalität vor seiner Verwendung in der DTD-Datei
ead.dtd „eingeschaltet“ werden muss. Dazu müssen die Werte von zwei
Deklarationen für Parameterentitäten im Abschnitt „XLINK INCLUSION/EXCLUSION“
in der Datei ead.dtd bearbeitet werden. Wenn diese Datei von der offiziellen, von der
Library of Congress betreuten EAD-Website heruntergeladen worden ist, sind diese
Werte wie folgt kodiert:
<!ENTITY % xlink
<!ENTITY % noxlink
'IGNORE'
'INCLUDE'
>
>
Das bedeutet, dass die XLink-Funktion „ausgeschaltet“ ist. Das ist die
Standardvorgabe für die EAD-DTD, da der Großteil der SGML-Software den
Doppelpunkt (:) in dem Attributnamen XLINK:FORM nicht verarbeiten kann. Um die
XLink-Funktionalität zu aktivieren, wenn künftig die XML-Software genutzt werden
soll, müssen diese Parameterentitätsdeklarationen in der vor Ort vorhandenen Kopie
der Datei ead.dtd geändert werden, so dass sie folgendermaßen aussehen:
<!ENTITY % xlink
<!ENTITY % noxlink
'INCLUDE'
'IGNORE'
>
>
Der Wert dieses Attributs ist als FIXED deklariert und wird von der DTD für jedes
Verknüpfungselement eingestellt. Auch wenn die XLink-Funktion „ausgeschaltet“
bleibt, kann es Kodierern helfen, mit der Rolle der einzelnen Verknüpfungselemente
gemäß der Zuweisung durch dieses Attribut vertraut zu sein, um diese
Verknüpfungselemente nach Bedarf verwenden zu können. In Tabelle 7.2.4a sind die
15 EAD-Verknüpfungselemente nach dem festgelegten Wert ihres Attributs
XLINK:FORM zusammengestellt.
<archref>, <bibref>, <dao>, <extptr>,
<extref>, <ptr>, <ref>, <title>
xlink:form="extended" <daogrp>, <linkgrp>
xlink:form="locator"
<daoloc>, <extptrloc>, <extrefloc>, <ptrloc>, <refloc>
xlink:form=“simple"
Tabelle 7.2.4a. Festgelegte Werte für das Attribut XLINK:FORM von EADVerknüpfungselementen.
*
**
A.d.Ü.: = einfach.
A.d.Ü.: = erweitert.
A.d.Ü.: = ortsbezeichnend.
***
213
Das Attribut INLINE ist nicht spezifisch für die XLink-Funktion und wird daher nicht in
der Datei ead.dtd „eingeschaltet“ bzw. „ausgeschaltet“. INLINE hat entweder den
Wert "true" oder "false". Die Standardvorgabe ist "true", d. h., es handelt sich um
einen Inline-Link. Sofern Kodierer den Wert dieses Attributs nicht in "false" ändern
wollen, um anzugeben, dass es sich um einen Out-of-line-Link handelt, darf das
Attribut bei der Kodierung nicht verwendet werden (zu Inline- und Out-of-line-Links
siehe Abschnitt 7.1.2.3).
Das Attribut INLINE steht bei allen in Tabelle 7.2.4a aufgeführten einfachen und
erweiterten Links zur Verfügung. Bei erweiterten Links erscheint es, wenn es genutzt
wird, bei dem Bündelungselement, da INLINE keine Attributoption für die einzelnen
Zeigerelemente ist. Wie bereits erwähnt, müssen die Anwender von EAD dieses
Attribut derzeit nicht explizit kodieren. Die Standardvorgabe "true" wird empfohlen,
bis die XLink-Spezifikation und die Software, die Out-of-line-Links unterstützen kann,
weiter entwickelt ist.
7.2.5. Das Attribut PARENT bei den Elementen Behälter <container> und
Lagerort <physloc> (Physical Location)
Das Attribut PARENT* ist ein Sonderfall. Es steht nur bei den Elementen Behälter
<container> und Lagerort <physloc> zur Verfügung. Das Attribut PARENT
unterscheidet sich jedoch von den anderen EAD-Verknüpfungselementen darin, dass
für Benutzer kein Link erscheint. Es soll der Software Informationen über einen
„Eltern“-Behälter zugänglich machen, ohne dass diese wiederholt kodiert werden
müssen. Dieses Attribut gibt es, damit das Attribut ID zur Erzeugung eines Shortcuts
verwendet werden kann, wenn beispielsweise Angaben zu Kisten und Ordnern mit
Hilfe von <container> kodiert werden sollen.
Wie in Abschnitt 3.5.2.4 erwähnt, kann es vorkommen, dass Archivare die
Informationen zu Behältern und/oder Ordnern für jede Erschließungskomponente
(<c> oder <c0x>) unterhalb der Teilserienebene kodieren wollen, mit anderen
Worten, für solche hierarchischen Erschließungskomponenten, für die Kisten- und
Ordnernummern häufig in Druckfindbüchern angegeben sind. Ein Computer, der ein
kodiertes Dokument verarbeitet, kann aus der Formatierung einer Behälterliste nicht
intuitiv die gleiche Bedeutung entnehmen, wie dies ein Mensch kann. Durch die
Kodierung von Behälterinformationen für jede Komponente wird sichergestellt, dass
Bestandsverzeichnisdaten von Computern genutzt werden können, wenn es künftig
höher entwickelte Systeme zur Bearbeitung und Neuzusammenstellung von Daten
aus archivischen Findbüchern gibt. Werden diese Informationen für die einzelnen
Komponenten nicht kodiert, wird die weitere Verwendung der Daten in solchen
Systemen u. U. erschwert.
Ein Mensch ist z. B. ohne Weiteres in der Lage, dem folgenden Auszug aus einer
Behälterliste zu entnehmen, dass sich alle drei Ordner in Kiste 12 befinden:
Kiste
12
*
Ordner
1
2
3
Inhalt
Breakdance, 1989-1991
Fosse, Bob, 1980-1984
Jitterbug, 1938-1942
A.d.Ü.: = Eltern.
214
Das Problem entsteht, wenn diese Behälterliste in EAD kodiert wird, wie in Bild
7.2.5a gezeigt:
<c02 level="file"><did>
<container type="box">12</container>
<container type="folder">1></container>
<unittitle>Breakdance, <unitdate type="inclusive">
1989-1991</unitdate></unittitle>
</did></c02>
<c02 level="file"><did>
<container type="folder">2</container>
<unittitle><persname>Fosse, Bob</persname>,
<unitdate type="inclusive">1980-1984</unitdate>
</unittitle>
</did></c02>
<c02 level="file"><did>
<container type="folder">3</container>
<unittitle>Jitterbug, <unitdate type="inclusive">
1938-1942</unitdate></unittitle>
</did></c02>
[...]
Bild 7.2.5a. Kodierung von Behälterinformationen, die die Bearbeitung
und die Neuzusammenstellung von Daten erschweren kann.
Für einen Rechner, der diese Datei verarbeitet, befindet sich die
Verzeichnungseinheit „Fosse, Bob“ in einem Ordner, aber nicht in einer Kiste. Das
kommt daher, dass durch das Schließen von </c02> bei der vorangehenden
Verzeichnungsseinheit „Breakdance“ die Information über Kiste 12 von der weiteren
Verarbeitung bei den nachfolgenden Komponenten <c02> – ausgeschlossen wird.
Dies ist u. U. dann nicht problematisch, wenn EAD nur zur Erzeugung eines linearen
Online-Findbuchs angewendet wird. Es könnte jedoch künftig zu Problemen führen,
wenn die Anwendersoftware versucht, die Angaben zu Erschließungskomponenten
aus einem kodierten Findbuch zu extrahieren. Dies kann erforderlich sein, um
Benutzern als Ergebnis einer Suche eine Trefferliste mit Informationen zu mehreren
Beständen und Archiven auf Ordnerebene zu liefern. Ein solches Szenario besteht
derzeit bei Archiven oder Verbünden, die über einen guten Programmierer und eine
SGML-fähige Suchmaschine verfügen. Sogar bei der linearen Darstellung von
Findbüchern besteht jedoch bei einer Kodierung wie in dem obigen Beispiel die
Möglichkeit, dass die sich daraus resultierende Darstellung Nutzer dazu zwingt, den
Text ständig nach oben oder unten durchzuscrollen, um die Kistennummer für einen
bestimmten Ordner zu finden, und zwar besonders dann, wenn eine Kiste viele
Ordner enthält.
Falls das verwendete Übertragungssystem technisch in der Lage ist, das Attribut
PARENT zu unterstützen, kann die Kodierung <container type="Box"> bei allen
außer der ersten Komponente, die jeweils in eine neue Kiste gehört, weggelassen
werden, wobei der Computer trotzdem die nötigen Informationen erhält, um für jede
Erschließungskomponente die Behälterinformation vollständig und eindeutig
verarbeiten zu können. Bild 7.2.5b zeigt eine Neukodierung der Angaben in Bild
7.2.5a, die die Verwendung des Attributs PARENT zeigt:
215
<c02 level="file"><did>
<container id="box12" type="box">12</container>
<container type="folder">1</container>
<unittitle>Breakdance, <unitdate type="inclusive">1989-1991
</unitdate></unittitle>
</did></c02>
<c02 level="file"><did>
<container parent="box12" type="folder">2</container>
<unittitle><persname>Fosse, Bob</persname>,
<unitdate type="inclusive">1980-1984</unitdate></unittitle>
</did></c02>
<c02 level="file"><did>
<container parent="box12" type="folder">3</container>
<unittitle>Jitterbug, <unitdate type="inclusive">1938-1942
</unitdate></unittitle>
</did></c02>
[...]
Bild 7.2.5b. Verwendung des Attributs PARENT, um Behälterinformationen
eindeutig darzustellen.
Das Attribut PARENT wird in der EAD-DTD – genau wie das Attribut TARGET – mit
dem IDREF-Wert deklariert. Bild 7.2.5b veranschaulicht beim ersten Auftreten einer
neuen Kiste die Deklaration eines Wertes für ein Attribut ID des <container>-Tags,
die dann mittels des Attributs PARENT des <container>-Tags für jeden weiteren
Ordner in der betreffenden Kiste referenziert werden kann. Die Software, die ein auf
diese Weise kodiertes Dokument verarbeitet, hat nun Zugriff auf die
Behälterinformation für jede Erschließungskomponente in der betreffenden Kiste. Die
derzeit im Handel erhältliche Anwendersoftware kann das Attribut PARENT nicht
verwenden. Archive mit hauseigenen Fachleuten für die SGML-Programmierung sind
jedoch u. U. in der Lage, dieses Attribut zu nutzen, um das wiederholte Taggen von
Behälterinformationen zu vermeiden.
Für Übertragungssysteme, die die Verwendung des Attributs PARENT nicht
unterstützen, jedoch die Übertragung von Informationen unterdrücken können, die
mit dem auf „intern” geschalteten Attribut AUDIENCE kodiert wurden, zeigt Bild
7.2.5c eine alternative Kodierung der Daten aus Bild 7.2.5a. Dieses Verfahren liefert
die Behälterinformation für jede Erschließungskomponente, ohne das Attribut
PARENT zu verwenden. Da das Attribut AUDIENCE verwendet wird, konnte ein
Stylesheet erstellt werden, das eine lineare Darstellung des Findbuchs bewirkt, bei
der die immer wieder auftretenden Kistennummern für den Nutzer nicht zu sehen
sind.
216
<c02 level="file"><did>
<container type="box">12</container>
<container type="folder">1</container>
<unittitle>Breakdance, <unitdate type="inclusive">
1989-1991</unitdate></unittitle>
</did></c02>
<c02 level="file"><did>
<container type="box" audience="internal">12</container>
<container type="folder">2</container>
<unittitle><persname>Fosse, Bob</persname>,
<unitdate type="inclusive">1980-1984</unitdate>
</unittitle>
</did></c02>
<c02 level="file"><did>
<container type="box" audience="internal">12</container>
<container type="folder">3</container>
<unittitle>Jitterbug, <unitdate type="inclusive">1938-1942
</unitdate></unittitle>
</did></c02>
[...]
Bild 7.2.5c. Verwendung des Attributs AUDIENCE, um die sich
wiederholenden Behälterinformationen zu unterdrücken
und die Verarbeitung zu erleichtern.
217
7.3. Externe Verknüpfungen
Externe Verknüpfungen ausgehend von einem kodierten Dokument lassen sich auf
verschiedene Art und Weise erstellen. Die „sauberste“ SGML-Methode zum Erstellen
solcher Links besteht in der Verwendung von Deklarationen für allgemeine Entitäten
und Entitätsreferenzen (Abschnitt 6.5 bietet einen grundlegenden Überblick über
beide Verfahren). Ein anderer Lösungsansatz besteht darin, das Attribut HREF
unmittelbar in einem Verknüpfungselement zu verwenden, damit zur Festlegung
einer Adresse eines Links keine Entität deklariert werden muss. Das ideale Verfahren
ist u. U. eine Mischung, bei der EAD-kodierte Findbücher in einem SGML-System
gespeichert und gepflegt werden. Dieses kann einen SGML-Katalog nutzen, um
persistente Entitätsnamen mit Systemadressen, die sich beim Verschieben von
Dateien ändern können, zu paaren. Die Übertragung der Findbuchdaten kann über
ein XML-System erfolgen, in dem die Entitätsreferenzen „on the fly“ in einen HREFURI aufgelöst werden, der im Speicher des Nutzerbrowsers nur vorübergehend
abgelegt wird.
7.3.1. Das Attribut ENTITYREF
Anders als die internen Links, die in Abschnitt 7.2 behandelt wurden, deklarieren
externe Links eine Beziehung zwischen Informationen innerhalb einer EAD-Instanz
und einer anderen Datei oder einem Dokument, die bzw. das außerhalb der
betreffenden Instanz vorhanden ist. Das Attribut ID, das die Zieladresse für interne
Links liefert, ist daher nicht erforderlich. Eine Zieladresse für externe Links wird
erstellt, indem in der Dokumenttyp-Deklaration einer Dokumentinstanz eine
Deklaration für eine allgemeine externe Entität erzeugt wird. Diese
Entitätsdeklaration enthält spezifische Angaben darüber, wie ein SGML-fähiges
Verarbeitungssystem die Zieladresse des externen Links finden kann. Die
Entitätsdeklaration informiert außerdem das Verarbeitungssystem über das
Informationsformat, das es erwarten kann, wenn die Zieldatei vom System nicht
erkennbaren Text enthält.
Bild 7.3.1a zeigt zwei Deklarationen für allgemeine externe Entitäten in der
Dokumenttyp-Deklaration einer kodierten Findbuchinstanz:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" [
<!ENTITY tedschell SYSTEM
"http://www.archivesrus.gov/findaids/ead/ms045.sgm" NDATA sgml>
<!ENTITY schellpix SYSTEM
"http://www.myserver.edu /images/ms023_schell.gif" NDATA gif>]>
Bild 7.3.1a. Zwei Deklarationen für allgemeine Entitäten in einer
Dokumenttyp-Deklaration.
Die erste Deklaration enthält als Systemidentifikator einen absoluten URI auf einem
Server in einem fiktiven Staatsarchiv, und zwar für ein EAD-kodiertes Findbuch zu
den Papieren von Theodore R. Schellenberg. Die zweite Deklaration liefert einen
absoluten URI für ein GIF-Bild, das auf dem gleichen Server wie die kodierte
Dokumentinstanz gespeichert ist, in der der Link deklariert wird.
Abschnitt 6.5.2.4.2 enthält Informationen über Deklarationen von externen Entitäten
zu Dateien, die nicht zusammen mit der Dokumentinstanz geparst werden sollen. In
218
diesem Abschnitt wird die Verwendung von Verknüpfungselementen zur Erstellung
von Links innerhalb einer Dokumentinstanz zu diesen Dateien behandelt. Links zu
deklarierten Entitäten werden mit Hilfe eines Attributs ENTITYREF in dem gewählten
Verknüpfungselement erstellt. Die Wertebezeichnung in der EAD-DTD für das
Attribut ENTITYREF lautet ENTITY. Dies ist ein Schlüsselwort mit der Bedeutung,
dass der Attributwert validiert wird, wenn die kodierte Dokumentinstanz geparst wird.
Damit wird sichergestellt, dass für jedes verwendete Attribut ENTITYREF eine
Entitätsdeklaration vorhanden ist. Bild 7.3.1b zeigt ein Beispiel für zwei
Verknüpfungselemente mit Zieladressen zu den in Bild 7.3.1a deklarierten Entitäten:
<add>
<relatedmaterial>
<head>Related Collections</head>
<archref entityref="tedschell">
<origination>
<persname source="lcnaf" normal="Schellenberg, T. R., 1903-1970"
role="creator">T. R. Schellenberg</persname></origination>
<unittitle>Theodore R. Schellenbergs Papiere,
<unitdate type="inclusive">1938-1970</unitdate></unittitle>
<extptr entityref="schellpix">
<unitid type="collection number">MS-045</unitid>
<repository><name>Archives R Us</name></repository>
</archref>
[weitere mögliche Elemente und Text ...]
</relatedmaterial>
</add>
Bild 7.3.1b. Verwendung des Attributs ENTITYREF zur Erstellung von
Links.
In diesem Beispiel dient das Element Archival Reference <archref> mit einem Attribut
ENTITYREF zur Erstellung eines Links zu einem kodierten Findbuch für einen
verwandten Bestand. Das Element External Pointer <extptr> mit einem Attribut
ENTITYREF wird zur Erstellung eines Links zu einem Bild verwendet, das sich auf
den Bestand bezieht. Das Element <archref> wird in Abschnitt 7.3.3 näher erläutert,
und das Element <extptr> wird in Abschnitt 7.3.4 erläutert.
7.3.2. Das Attribut HREF
EAD bietet das Attribut HREF als Alternative zu ENTITYREF zur Erstellung einer
Zieladresse für externe Links an. Für Mitarbeiter, die die in HTML verfügbaren
Attribute kennen, sieht HREF recht vertraut aus.
Seit der Entwicklung des SGML-Standards haben das World Wide Web und das
HTML-Kodierschema, das seine Auszeichnungsgrundlage bildet, die Welt der
vernetzten Kommunikation im Sturm erobert. Die Vor- und Nachteile von HTML und
SGML sind in Kapitel 1 behandelt. Daher möge an dieser Stelle die Bemerkung
genügen, dass das Web einige Vereinfachungen von SGML eingeführt hat, die bei
den laufenden XML-Entwicklungsarbeiten noch eingearbeitet werden sollen. Eine
dieser Vereinfachungen besteht darin, das entitätsgestützte Verknüpfungsschema
mit der Möglichkeit auszustatten, das Attribut HREF zur unmittelbaren
Adressenreferenzierung zu nutzen. Version 1.0 der EAD-DTD unterstützt diese
Entwicklung in vollem Umfang.
219
Das Attribut HREF ist verhältnismäßig leicht anzuwenden. Es muss nur ein URI für
die Zielressource direkt innerhalb des Verknüpfungselements erstellt werden. Bild
7.3.2a zeigt eine Neukodierung des Beispiels für ENTITYREF in Bild 7.3.1b oben,
nur wird statt ENTITYREF das Attribut HREF verwendet. Das macht die in Bild 7.3.1a
gezeigten Entitätsdeklarationen unnötig. Es ist zu beachten, dass Kodierer weiterhin
die Wahl haben, entweder einen absoluten oder einen relativen URI zu verwenden,
um die Zieladresse zu erstellen (die Stärken und Schwächen dieser Optionen sind in
Abschnitt 6.5.2.4.1 beschrieben).
<add>
<relatedmaterial>
<head>Verwandte Bestände</head>
<archref href="http://www.archivesrus.gov/findaids/ead/ms045.sgm">
<origination>
<persname source="lcnaf" normal="Schellenberg, T. R., 1903-1970"
role="creator">
T. R. Schellenberg</persname></origination>
<unittitle>Theodore R. Schellenbergs Papiere,
<unitdate type="inclusive">1938-1970</unitdate></unittitle>
<extptr href="../images/ms023_schell.gif">
<unitid type="collection number">MS-045</unitid>
<repository><name>Archives R Us</name></repository>
</archref>
[weitere mögliche Elemente und Text ...]
</relatedmaterial>
</add>
Bild 7.3.2a. Verwendung des Attributs HREF zur Erstellung von Links.
Einige Vor- und Nachteile der Verwendung eines Verknüpfungsschemas, das sich
auf Entitäten oder auf das Attribut HREF stützt, werden in Abschnitt 7.5 behandelt.
Der wichtigste Faktor bei einer Entscheidung für das bei der Bildung einer
Zieladresse für einen Link zu verwendende Verknüpfungsattribut ist vielleicht das
Grundwissen über die Unterstützung von Verknüpfungen in dem System, mit dem die
Findbücher verbreitet werden sollen. Das Attribut HREF ermöglicht es nicht, die
gleiche Menge an Informationen zur Zielressource des Links bereitzustellen, wie es
bei dem entitätsgestützten Verfahren möglich ist. Es ist z. B. zu beachten, dass die
Entitätsdeklaration in Bild 7.3.1a der Software des Übertragungssystems spezielle
Informationen bezüglich der Nicht-SGML-Datenressource liefert, zu der ein Link
erstellt wird. Diese Spezialinformationen können bei Verwendung des Attributs HREF
nicht geliefert werden. Daher muss das betreffende Übertragungssystem versuchen,
diese Feststellungen auf der Grundlage des Dateitypsuffixes zu machen, das an den
Dateinamen angehängt ist (.gif).
7.3.3. Archivischer Nachweis <archref> (Archival Reference), Bibliographischer
Nachweis <bibref> (Bibliographical Reference) und Titel <title> (Title)
Die Elemente <archref>, <bibref> und <title> können in einem kodierten Findbuch
zahlreiche Funktionen haben. Die Erstellung von externen Links ist nur eine davon.
Im Unterschied zu <extptr> z. B., das nur als Verknüpfungselement dient, können die
o. g. Elemente auch für andere Aufgaben als das Deklarieren eines Links
herangezogen werden (Verwendung dieser Elemente für diese anderen Aufgaben
siehe Abschnitt 3.5.4). Archivare können <archref> beispielsweise zur Kodierung
eines Hinweises auf gesondert erfasstes Archivgut verwenden, das sich auf den
220
Bestand bezieht, für die gerade ein EAD-Findbuch erstellt wird. Wenn es für diesen
gesondert beschriebenen Bestand kein elektronisches Findbuch gibt, ist es unnötig,
die Verknüpfungsattribute in <archref> zu verwenden. In diesem Fall werden
<archref> und seine Subelemente dazu verwendet, nur einen beschreibenden Text
über den verwandten Bestand zu kodieren. In ähnlicher Weise bedient sich vielleicht
ein Archivar des Elements <bibref>, um einen Hinweis auf eine Veröffentlichung zu
geben, die mit dem zu verzeichnenden Bestand in Zusammenhang steht. Der
Einsatz der Verknüpfungsattribute richtet sich danach, ob ein elektronischer
bibliographischer Datensatz oder eine elektronische Version des veröffentlichten
Werkes als Ziel für einen Link vorhanden ist.
Im vorliegenden Abschnitt wird auch eine alternative Verwendung für <archref>
erörtert, die sich für einige Archive als nützlich erwiesen hat, wenn es darum geht,
große Bestandsbeschreibungen virtuell wieder zusammenzufügen, die für die
Kodierung aus praktischen Gründen in kleinere Komponenten unterteilt worden
waren.
7.3.3.1. Allgemeine Verwendung von <archref>, <bibref> und <title>
Die Bilder 7.3.1b und 7.3.2a zeigen zwei Möglichkeiten, wie die zur Verwendung im
Tag <archref> verfügbaren Attribute zur Erstellung eines Links zu
Erschließungsangaben von verwandten Beständen oder von Beständen separierten
Materialien bzw. für Hinweise auf andere Archivbestände in einer Bibliografie
eingesetzt werden können.
Das Element <bibref> kann in ähnlicher Weise zur Erstellung von Links entweder zu
Erschließungsangaben von Surrogaten oder zum tatsächlichen Text von
Veröffentlichungen dienen, die online zur Verfügung stehen. Beispielsweise kann ein
kodiertes Findbuch für die Schriften des Autors Paul Laurence Dunbar eine
Bibliografie seiner veröffentlichten Werken enthalten. Ein Teil seiner Lyrik steht als
vollständiger Text online zur Verfügung (kodiert in SGML unter Anwendung der TEIDTD), bereitgestellt von der American Verse Collection der Humanities Text Initiative
der University of Michigan.115 Bild 7.3.3a zeigt die Kodierung von bibliografischen
Nachweisen zu Dunbars Werken. Der erste Hinweis hat keinen Link, und der zweite
hat einen Link, der unmittelbar zu dem vollständigen, online verfügbaren Text führt:
115
Humanities Text Initiative, <http://www.hti.umich.edu/>.
221
<add>
<bibliography>
<head>Eine Bibliographie zu den Wreken von Paul Laurence
Dunbar</head>
[weitere mögliche Elemente und Text ...]
<bibref>
<persname role="author" source="lcsh">Dunbar, Paul Laurence,
1872-1906</persname>.
<title pubstatus="pub">The Best Stories of Paul Laurence
Dunbar</title>.
<imprint><geogname>New York</geogname> : <publisher>
Dodd, Mead & Company</publisher>, <date type="publication">
[1938]</date> </imprint>
</bibref>
[weitere mögliche Elemente und Text ...]
<bibref href="http://www.hti.umich.edu/bin/amvidx.pl?type=header&id=DunbaLyrLL">
<persname role="author" source="lcsh">Dunbar, Paul Laurence,
1872-1906</persname>.
<title pubstatus="pub">Lyrics of Lowly Life</title>.
<imprint><geogname>London</geogname> : <publisher>
Chapman & Hall, Ltd.</publisher>, <date type="publication">
1897</date></imprint>
</bibref>
[weitere mögliche Elemente und Text ...]
</bibliography>
</add>
Bild 7.3.3a. Verwendung von <bibref> zur Erstellung von Links und zu
anderen Zwecken.
Es ist zu beachten, dass bei diesem Beispiel das Attribut HREF zwar verwendet
wurde, man hätte jedoch ebensogut eine Entitätsdeklaration erzeugen können, die
den URI zu der Ressource enthält, und dann das Attribut ENTITYREF bei <bibref>
einsetzen können.
7.3.3.2. Verwendung von <archref> zur Aufgliederung großer Findbücher
Einige Implementierer von EAD haben Probleme beim Herunterladen von kodierten
Instanzen für Findbücher zu besonders großen, komplexen Beständen
Schwierigkeiten festgestellt. Diese vorwiegend technischen Schwierigkeiten wurden
von einem Archiv durch eine neuartige Verwendung des Tags <archref>
überwunden, mit dessen Hilfe Sammlungen oder Bestände, die zu
Kodierungszwecken unterteilt worden waren, wieder zusammen gefügt werden.
Das Public Record Office (PRO) – das als Nationalarchiv Großbritannien die
Unterlagen der britischen Ministerien, Gerichte und anderen öffentlichen Institutionen
gemäß dem Archivgesetz von 1958 und seinen Ergänzungen aufbewahrt – hat
dieses Problem mit vielen Findbüchern. Jeder Bestand umfasst alle überlieferten
Unterlagen eines Ministeriums aus zehn oder zwanzig Abteilungen, von denen jede
Dutzende von Unterlagenserien (oder, wie man beim PRO sagt, Klassen) mit bis zu
vielen tausend Dokumenten produziert, die für die Benutzung zu Verfügung stehen.
Allein der Umfang jedes Bestandes (ursprünglich als gesonderte EAD-Instanz
betrachtet) stellte die Archivare beim PRO vor Probleme: erstens bei der
Syntaxanalyse von Dateien mit einem Umfang von über 2,5 MByte unter
222
Verwendung gängiger Software, zweitens – und fundamentaler – bzgl. der Zeit, die
Benutzer für das Herunterladen der Dateien aus dem Internet benötigten.
Es wurde beschlossen, die Dateien aufzuteilen und mit Hilfe von <archref> zu
verknüpfen. Eine Elterndatei enthält die Daten der Bestands und der Teilbestände
(im Sprachgebrauch des PRO Ressort und Abteilungen). Gesonderte Dateien dienen
als Findbücher für jede Serie und ihre Komponenten. Der Tag <archref> dient dazu,
die Datei mit Bestand und Teilbeständen virtuell mit den Seriendateien, ihren
intellektuellen Untereinheiten, zu vereinigen und andersherum die Seriendateien mit
der Elterndatei zu verknüpfen.
7.3.4. Externer Zeiger <extptr> (Extended Pointer) und Externer Verweis
<extref> Extended Reference 116
Während <archref> und <bibref> unter bestimmten Umständen für externe
Verknüpfungen verwendet werden, können die Elemente <extptr> und <extref>
allgemein zur Erstellung von externen Links verwendet werden, wo immer sie in
einem kodierten Findbuch benötigt werden. Diese beiden Elemente haben genau die
gleiche Funktion. Der Unterschied zwischen ihnen entspricht dem zwischen <ptr>
und <ref>, wie dies in Abschnitt 7.2.1 beschrieben wurde. Ein leeres Element,
<extptr>, ist zu verwenden, wenn nur ein Verknüpfungs-Icon an der Stelle des
kodierten Dokuments eingesetzt werden soll, an der sich ein Link befindet. Das
Element <extref> muss entweder Text oder andere Elemente enthalten und ist zu
verwenden, wenn hervorgehobener Text auf einen Link hinweisen soll. Wie es bei
allen externen Verknüpfungselementen der Fall ist, kann das Attribut ENTITYREF
bzw. HREF zusammen mit <extptr> und <extref> verwendet werden, um eine
Zieladresse für den zu erstellenden Link zu liefern.
Bild 7.3.4a zeigt eine Entitätsdeklaration für Informationen auf der Webseite der
Nobel-Stiftung, um auf die Verleihung des Nobelpreises für Physik 1995 an Frederick
Reines hinzuweisen, dessen Schriften an anderer Stelle in einer EAD-Instanz
beschrieben sind.
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD ead.dtd
(Encoded Archival Description (EAD) Version 1.0)//EN" [
<!ENTITY nobelreines SYSTEM "http://www.nobel.se/laureates/physics1995.html" NDATA html>
]>
Bild 7.3.4a. Eine Entitätsdeklaration für eine externe Webseite.
Innerhalb des Textes der EAD-Instanz, möglicherweise in einem chronologisch
angeordneten biografischen Hinweis, dienen <extptr> und das Attribut ENTITYREF
dazu, einen Link zu den Informationen über Reines auf der Webseite der NobelStiftung zu erstellen, wie Bild 7.3.4b zeigt:
116
Durch den Begriff „extern“ bei den Namen dieser beiden Elemente darf sich der Leser nicht in die Irre führen lassen. Sie
dienen, wie es von dem festen Wert ihres Attributs XLINK:FORM bestimmt wird, zur Erzeugung von einfachen nicht externen
Links (weitere Angaben zu diesem Attribut siehe Abschnitt 7.2.4).
223
<bioghist>
<head>Biographical Note</head>
<chronlist>
[weitere mögliche Elemente und Text ...]
<chronitem>
<date>October 1995</date>
<event><extptr entityref="nobelreines">Verleihung des Nobelpreises
für Physik durch die Königlich Schwedische Akademie der
Wissenschaften</event>
</chronitem>
[weitere mögliche Elemente und Text ...]
</chronlist>
</bioghist>
Bild 7.3.4b. Verwendung von <extptr> zur Erstellung eines Links zu einer
deklarierten externen Entität.
Der Link in Bild 7.3.4b hätte auch mit Hilfe von <extref> deklariert werden können,
das entweder Text oder andere Elemente enthalten muss, wie aus dem kodierten
Beispiel unten ersichtlich ist. Wenn sie auch systemabhängig ist, wird die Codierung
wahrscheinlich die Hervorhebung des Textes im Element <extref> verwenden, um
auf das Vorhandensein eines Links hinzuweisen.
<chronitem>
<date>October 1995</date>
<event><extref entityref="nobelreines">Verleihung des Nobelpreises
für Physik durch die Königlich Schwedische Akademie der
Wissenschaften</extref></event>
</chronitem>
Schließlich hätte der Link in dem obigen Beispiel mit Hilfe des Attributs HREF erstellt
werden können, entweder isoliert oder gepaart mit einer Entitätsdeklaration, um den
URI für die Informationen über Reines auf der Webseite der Nobel-Stiftung
unmittelbar zu kodieren:
<chronitem>
<date>October 1995</date>
<event><extref href="http://www.nobel.se/laureates/physics1995.html"> Verleihung des Nobelpreises für Physik durch die
Königlich Schwedische Akademie der Wissenschaften </extref></event>
</chronitem>
7.3.5. Gruppierung von Verweisen <linkgrp> (Linking Group) als
Bündelungselement für Ort des Externen Zeigers <extptrloc> (Extended
Pointer Location) und Ort des Externen Verweises <extrefloc> (Extended
Reference Location)
Zusätzlich zur Verwendung des Elements <linkgrp> zur Erzeugung von mehrfachen
internen Quell- und Ziellinks (siehe Abschnitt 7.2.3) kann <linkgrp> auch zur
Erzeugung der gleichen Art von externen Links dienen. Wie in Abschnitt 7.2.3
erwähnt, gilt der mit Hilfe von <linkgrp> erstellte Link als erweiterter Link mit
mehrfachen Quell- und Zielressourcen, deren Adressen mittels eines der beiden
„zeigenden“ Elemente <extptrloc> bzw. <extrefloc> angegeben werden. Ein solcher
Link gilt als Inline-Link, wenn die innerhalb von <linkgrp> kodierte Information als
224
Quellressource für den Link dient. In Zukunft, wenn die XLink-Spezifikation weiter
entwickelt ist, dürfte es auch möglich sein, den Wert des Attributs INLINE auf "false"
zu setzen und Out-of-line-Links mit mehreren Adressen zu erzeugen, bei denen die
innerhalb von <linkgrp> kodierten Informationen weder als Quell- noch als
Zielressource im Link fungieren. <linkgrp> wird vor allem dazu dienen, Zeiger auf
verschiedene Versionen der gleichen Ressource zu bündeln oder eine Beziehung
zwischen verschiedenen Links auszudrücken, was technisch durch die Bündelung
unterstützt werden könnte.
Wie <extptr> und <extref> haben auch <extptrloc> und <extrefloc> genau die gleiche
Funktion. Der Unterschied zwischen ihnen besteht darin, dass Kodierer entweder
Text als Linkanzeiger aufnehmen möchten, dazu müssen sie <extrefloc> verwenden.
Oder man möchte dies nicht tun, dann ist <extptrloc> zu verwenden.
7.3.6. Digitale Archivobjekte <dao>, <daogrp> und <daoloc>
Die Elemente der <dao>-Reihe – Digitales Archivobjekt <dao> (Digital Archival
Object), Beschreibung digitaler Archivobjekte <daodesc> (Digital Archival Object
Description), Gruppe digitaler Group <daogrp> (ArchivobjekteDigital Archival Object )
und Ort des digitalen Archivobjekts <daoloc> (Digital Archival Object Location) – sind
in EAD verfügbar, um Links zu elektronischen Versionen zu den
Informationsressourcen von Archivbeständen zu erzeugen. Derzeit handelt es sich
dabei wahrscheinlich um Digitalisate von Originalmaterialien in anderem Format
(z. B. GIF-Bilder von Fotos, MPEG-Dateien von Analogaufnahemn oder mit TEI
kodierte Versionen von papiergestützten Texten). Künftig jedoch wird zunehmend
Archivgut bereits in digitalen Formaten erstellt werden.
Drei der vier o. g. Elemente sind Verknüpfungselemente. Das Element <daodesc>,
die einzige Ausnahme. Es dient dazu in einer Komponente (Component <c>)“ das
digitalen Objekts bzw die digitalen Objekte zu beschreiben, wenn <unittitle> oder
andere Element dazu nicht ausreichend sind. <daodesc> dient im Wesentlichen der
Erfassung des Titels für digitale Archivobjekte, falls dies nötig ist.117
Es ist wichtig, den Unterschied zwischen den Elementen der <dao>-Reihe und
anderen Elementen für externe Verknüpfungen die EAD ermöglicht, zu verstehen.
Die Elemente der <dao>-Reihe sind nur zu verwenden, wenn das Ziel des Links ein
Dokument ist, das aufgrund seiner Herkunft und Überlieferung zu dem Bestand
gehört, der in dem Findbuch mit den <dao>-Tags beschrieben wird. Links zu allen
anderen Materialien sind unter Verwendung der anderen Elemente für externe
Verknüpfungen zu erstellen (beispielsweise <extref> oder <extptr>, siehe hierzu
Abschnitt 7.3).
Mit dem Element <dao> lässt sich ein einfacher Link zu einer digitalen Version eines
beliebigen Dokuments aus einem Archivbestand erstellen. Das Element <daogrp>,
das zum Bündeln mehrerer Elemente <daoloc> zu verwenden ist, ermöglicht das
Erzeugen eines externen Links zu verschiedenen Versionen von digitalen Faksimiles
von Bestandsmaterialien (Abschnitt 7.1 enthält einen Überblick über diese
Verknüpfungskonzepte).
117
Vgl. Encoded Archival Description Tag Library, Version 1.0, S. 102.
225
Das Element <dao> mag zwar oft leer erscheinen, ist jedoch in der EAD-DTD nicht
als leeres Element deklariert. Das Inhaltsmodell für dieses Element gibt an, dass es
entweder kein oder ein Element <daodesc> enthalten kann. Daher sieht es oft so
aus, als ob es leer wäre; es ist aber technisch gesehen kein leeres Element wie
<ptr>, das in der DTD mit dem Inhaltsmodell EMPTY deklariert ist. Aus diesem
Grund muss es stets mit einem Start-Tag und einem End-Tag erscheinen,
unabhängig davon, ob es ein <daodesc> enthält oder nicht. Das gleiche gilt für
<daoloc>.
Archivare möchten z. B. Links zu Digitalisaten von zwei Fotos aus demselben Ordner
innerhalb eines Bestandes erzeugen. Bild 7.3.6a zeigt eine Entitätsdeklaration für
jedes dieser JPEG-Bilder:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd
(Encoded Archival Description (EAD) Version 1.0)//EN" [
<!ENTITY f0042_1 SYSTEM "http://www.myserver.edu/images/
fonds0042_image1.jpg" NDATA jpeg>
<!ENTITY f0042_2 SYSTEM "http://www.myserver.edu /images/
fonds0042_image2.jpg" NDATA jpeg>
]>
Bild 7.3.6a. Entitätsdeklarationen für zwei JPEG-Bilder.
Obwohl die anderen Teile des Bestandes nur bis auf Ordnerebene beschrieben sind,
hat man sich dazu entschlossen, den Ordner mit den beiden Originalaufnahmen auf
Einzelstückebene zu kodieren und Links zu den Digitalisaten zu erstellen, indem für
jedes Objekt ein <dao>-Tag verwendet wird, wie in Bild 7.3.6b zeigt:
<dsc type="combined">
[weitere mögliche Elemente und Text ...]
<c02 level="file"><did><unittitle>Fotographien,
<unitdate type="inclusive">1895-1928</unitdate></unittitle>
</did>
<c03 level="item"><did><unittitle>Examensporträt von John Smith,
<unitdate type="single" normal="18950528">28. Mai
1895</unitdate></unittitle>
<dao entityref="f0042_1"></dao></did></c03>
<c03 level="item"><did><unittitle>Hochzeit von John Smith und
Stella Jones, Windsor, Ontario, <unitdate type="single"
normal="18970606">6. Juni 1897</unitdate></unittitle>
<dao entityref="f0042_2"></dao></did></c03>
</c02>
[weitere mögliche Elemente und Text ...]
</dsc>
Bild 7.3.6b. Verwendung von <dao> zur Erstellung von Links zu
Digitalisaten von Fotos
Das Element <daogrp> wird anstelle von <dao> verwendet, wenn verschiedene
Versionen derselben Quelle gebündelt werden müssen. Angenommen, die in Bild
7.3.6b erstellten Links umfassen sowohl eine Thumbnails als auch ein größeres
Referenzbild für jeden Link. Um die Beziehung zwischen dem Dateienpaar für jedes
Bild eindeutig zu kodieren, wäre es erforderlich, <daogrp> zum Bündeln eines
Zeigers <daoloc> für jede verwandte Datei zu verwenden, wie bei der folgenden
Neukodierung:
226
<dsc type="combined">
[weitere mögliche Elemente und Text ...]
<c02 level="file"><did><unittitle>Photographs,
<unitdate type="inclusive">1895-1928</unitdate></unittitle>
</did>
<c03 level="item"><did><unittitle>John Smith
graduation portrait,
<unitdate type="single" normal="18950528">May 28, 1895
</unitdate></unittitle>
<daogrp>
<daoloc entityref="f0042_1thumb"></daoloc>
<daoloc entityref="f0042_1"></daoloc>
</daogrp>
</did></c03>
<c03 level="item"><did><unittitle>Wedding of John
Smith and Stella Jones, Windsor, Ontario, <unitdate type="single"
normal="18970606">June 6, 1897</unitdate></unittitle>
<daogrp>
<daoloc entityref="f0042_2thumb"></daoloc>
<daoloc entityref="f0042_2"></daoloc>
</daogrp>
</did></c03>
</c02>
[weitere mögliche Elemente und Text ...]
</dsc>
Bild 7.3.6c. Verwendung von <daogrp> zur Erstellung von Links zu
verwandten Versionen von Digitalisaten von Fotos.
7.3.7. Das Attribut XPOINTER
XPointer bezieht sich ganz allgemein auf eine Spezifikation für Zeiger auf bestimmte
Stellen innerhalb eines kodierten Dokuments (also nicht auf das Dokument als
Ganzes), und zwar mittels eines URI. Diese Spezifikation befindet sich z. Z. beim
W3C (World Wide Web Consortium) in der Entwicklung118 und stützt sich auf
Konzepte, die bereits in der (TEI)-DTD119 und in HyTime (ISO 10744:1992)120, einem
international Standard für Hypertext-Funktionen, umgesetzt sind. XPointer erzeugt
auf der Grundlage von kodierten Werten von ID-Attributen und/oder von
Anweisungen, die sich auf die SGML-Baumstruktur einer Dokumentinstanz stützen,
eine standardisierte Syntax zur Angabe von Stellen innerhalb von kodierten
Dokumentinstanzen. Dies könnte es ermöglichen, Links recht einfach zu oder von
bestimmten Stellen in externen Dokumenten zu erzeugen, die bei der Kodierung
nicht bearbeitet werden können (weil sie auf einem fremden Web-Server liegen). Die
Möglichkeiten, die XPointer bietet, bilden eine notwendige Vorstufe zur Erzeugung
der Out-of-line-Links (siehe Abschnitt 7.1.2.3). Wenn Sie sich für genauere Angaben
zur XPointer-Spezifikation interessieren, finden Sie entsprechende Informationen, die
118
Aktuelle Informationen zur Entwicklung von XPointer sind auf der Webseite des World Wide Web Consortium verfügbar,
<http://www.w3.org/TR/WD-xptr>.
119
Vgl. Kapitel 14 in Sperberg-McQueen, C. M. / Burnard, Lou (Eds.): Guidelines for Electronic Text Encoding and Interchange.
TEI P3, Text Encoding Initiative, 1994, <http://www.uic.edu/orgs/tei/p3/doc/p3.html> (A.d.Ü.: Webseite nicht mehr existent. )
120
Goldfarb, Charles / Newcomb, Steven R. / Kimber, W. Eliot / Newcomb, Peter J.: A Reader's Guide to the HyTime Standard,
<http://www.hytime.org/papers/htguide.html> und DeRose, Stephen J. / Durand, David G: Making Hypermedia Work: A User's
Guide to HyTime, Boston, Dordrecht und London 1994.
227
allerdings aufgrund der rasanten Entwicklung u.U. schon veraltet sind, in den meisten
im Handel erhältlichen Büchern über XML.121
Innerhalb von EAD ist XPOINTER ein Attribut, das bei allen "simple" und "locator"
Verknüpfungselementen verfügbar ist, wie aus Tabelle 7.2.4a hervorgeht. Dieses
Attribut ist einer der vorausschauenden Aspekte von EAD, der die endgültige
Erstellung der XLink- und XPointer-Spezifikationen von XML in nicht allzu ferner
Zukunft vorwegnimmt. In SGML-Systemen, die es implementieren können,
ermöglicht es das Attribut XPOINTER Kodierern – mit Hilfe der XPointer-Syntax zum
Erzeugen des Wertes für das Attribut –, einen Pfad für einen Link zu einer
bestimmten Stelle in einem externen kodierten Dokument zu erzeugen. Ein SGMLfähiges Übertragungssystem dürfte den Inhalt einer ENTITYREF-Zieladresse und
den Inhalt eines Attributs XPOINTER aus einem einzigen EAD-Verknüpfungselement
auflösen können, um „on the fly“ einen XML-konformen Link zu der bestimmten Stelle
in dem Dokument zu erstellen, die bei der Kodierung als Ziel des Links vorgesehen
war. Dadurch können Implementierer von EAD einige Stärken des LinkManagements des entitätsgestützten Verfahrens in SGML (siehe Abschnitt 7.5) und
gleichzeitig die Möglichkeiten von XPointer nutzen, wenn diese weiter entwickelt sind
und ein stabiles Stadium erreicht haben.
121
Eine hilfreiche, einfache Darstellung der Entwicklungsgrundlagen von XPointer findet sich bei Goldfarb, Charles F. / Prescod,
Paul: The XML Handbook, S. 511-15.
228
7.4. Eigenschaften von Links
Es gibt mehrere Verknüpfungsattribute, die stets verwendet werden sollten, um
weitere Informationen über Links, die innerhalb einer EAD-Instanz erstellt worden
sind, zu liefern. Die Verwendung der Attribute TARGET, ENTITYREF oder HREF
wird zwar technisch gesehen nicht von der DTD gefordert, sie muss jedoch wie oben
beschrieben erfolgen, damit ein Link funktionieren kann. Anders als die Attribute zur
Angabe eines Ziels sind die im vorliegenden Abschnitt behandelten Attribute insofern
wahlweise verwendbar, als ein Link technisch allein durch die Angabe einer
Zieladresse erstellt werden kann. Die Verwendung der Attribute ACTUATE und
SHOW wird jedoch empfohlen, um der Verarbeitungssoftware ein Minimum an
Anweisungen zu geben, wie sich Links innerhalb der betreffenden Instanz verhalten
sollen. Viele derzeit verwendete Übertragungssysteme sind u. U. nicht in der Lage,
die von diesen Attributen gelieferten Informationen umzusetzen. Es ist dennoch
zweckmäßig, Links explizit mit diesem Minimum an Anweisungen zu kodieren, die
dem System mitteilen, wie sie umzusetzen sind.
Die Verwendung der übrigen hier behandelten Attribute wird nur dann empfohlen,
wenn der Typ der zu erzeugenden Links oder die Software zur Übertragung des
kodierten Dokuments dies fordern. Alle erörterten Attribute in diesem Abschnitt
können sowohl für interne als auch für externe Links verwendet werden.
7.4.1. Die Attribute ACTUATE, SHOW und BEHAVIOR
Die Attribute ACTUATE und SHOW sind gemeinsam in Verknüpfungselementen zu
verwenden, um der Systemsoftware einen Hinweis darauf zu geben, wie die
Informationen, die das Ziel eines Links bilden, dargestellt werden sollen. Die Werte
für beide Attribute sind durch die DTD eingeschränkt, daher muss bei der Kodierung
einen Wert aus einer geschlossenen Liste ausgewählt werden.
ACTUATE definiert, wie Nutzer einem Link folgen. Der Wert "auto" bewirkt, dass das
System dem Link automatisch folgt, wenn Nutzer ihn erreichen, so z. B. die
Darstellung eines Bildes zu einem Online-Findbuch. Nutzer müssen dazu einen Link
weder anwählen noch aktivieren. Diese Funktionalität könnte im Zusammenhang mit
einem externen Link zu einem Bild nützlich sein, das als Illustration in einem Hinweis
zur Entstehungsgeschichte (<bioghist>) dargestellt werden soll. Der Wert "user" zeigt
an, dass Nutzer den Link auf irgend eine Weise aktivieren müssen, vielleicht durch
einen Mausklick oder ein Sprachkommando. Dies könnte beispielsweise zweckmäßig
sein, wenn das Linkziel ein interner „Siehe-auch“-Verweis oder ein externes
Findbuch für einen verwandten Bestand ist, die Nutzer entweder erkunden oder
außer Acht lassen wollen.
Das Attribut SHOW zeigt das vorgesehene Verhalten des Links nach seinem Aufruf
an. Es hat drei mögliche Werte. Der Wert "embed" zeigt an, dass die Zielressource
des Links anstelle des Verknüpfungselements in das kodierte Dokument einzubetten
ist, und wird im Allgemeinen zusammen mit dem Wert "auto" des Attributs ACTUATE
verwendet. Der Wert "replace" zeigt an, dass die Zielressource des Links den die
Quellressource des Links umgebenden Text in demselben Browserfenster ersetzen
soll, während der Wert "new" besagt, dass die Zielressource des Links in einem
neuen Browserfenster angezeigt werden soll. Alle drei Werte für SHOW werden im
Allgemeinen zusammen mit dem Wert "user" des Attributs ACTUATE verwendet.
229
In bestimmten Fällen bieten die eingeschränkten Wertebereiche der Attribute
ACTUATE und SHOW nicht ausreichend Anweisungen für eine bestimmte
Systemsoftware. In diesem Fall kann das Attribut BEHAVIOR, dessen Wertebereich
vollkommen uneingeschränkt ist, Anweisungen liefern, die die Systemsoftware bzgl.
des gewünschten Verhaltens des Links benötigt.
Bild 7.4.1a veranschaulicht die Verwendung der Attribute ACTUATE und SHOW in
einem internen Link, der den Nutzer darauf hinweist, dass an anderer Stelle in dem
Bestand Materialien über eine bestimmte Organisation vorhanden sind. Da das
Element <ref> verwendet wird, wird der Text zwischen Start- und End-Tag – je nach
System – wahrscheinlich auf eine bestimmte Weise hervorgehoben, wenn dieses
Dokument auf einem Bildschirm erscheint. Nutzer müssen den Link durch Wählen
des hervorgehobenen Textes aktivieren. Der Text im Zielbereich des Findbuchs
ersetzt den Text rund um die Linkquelle im Browserfenster. Es ist zu beachten, dass
ein ID-Attributwert auf der betreffenden Komponentenebene zugewiesen wurde, so
dass auch ein Querverweislink aus der Kodierung von Serie 4 in diesem Bestand
erstellt werden kann.
<c01 level="series">
<did><unitid>Series 1: </unitid>
<unittitle>Korrespondenz, <unitdate type="inclusive">
1946-1970</unitdate></unittitle>
<physdesc><extent>1,3 laufende Meter</extent>
</physdesc></did>
<c02 level="file" id="s1:agba">
<did><unittitle>Apple Growers Benevolent Association,
<unitdate type="inclusive">1950-1952</unitdate></unittitle>
<physdesc><extent>12 Einzelstücke</extent></physdesc>
</did>
<note><p>Siehe auch <ref target="s4:agba"
actuate="user" show="replace"> Materialien der AGBA </ref>
in Serie 4: Sachakten</p></note>
</c02>
[weitere mögliche Elemente und Text ...]
</c01>
Bild 7.4.1a. Verwendung der Attribute ACTUATE und SHOW,
um Eigenschaften des Links anzugeben.
In Bild 7.4.1b wird ein Link zu einem Bild des Nachlassgebers eines Bestandes mit
persönlicher Unterlagen eingerichtet, das die biografischen Bemerkung in den
Erschließungsangaben auf Bestandsebene illustrieren soll. Der Link wird so kodiert,
dass das System ihm automatisch folgt. Das Bild erscheint immer dann, wenn Nutzer
die biografischen Bemerkung lesen.
230
<bioghist>
<dao href="http://www.myserver.edu/images/ms452_port1.gif"
actuate="auto" show="embed"></dao>
<p>Sanford J. Archiviste, den eine 1945 gemachte Porträtaufnahme
aus seinen Unterlagen zeigt, war Mitte des 20. Jahrhunderts eine
bedeutende geistige Kraft in der Archivwelt von Nordamerika.
[...]</p>
[weitere mögliche Elemente und Text ...]
</bioghist>
Bild 7.4.1b. Verwendung der Attribute ACTUATE und SHOW zusammen
mit <dao>, um Eigenschaften des Links anzugeben.
Es ist zu beachten, dass <dao> zur Erstellung des Links gewählt wurde, weil das
Digitalisat, das Ziel, zu demselben Bestand gehört. Wenn es in dem Bestand keine
Fotos gäbe und der Archivar in einer anderen Quelle ein Bild für die Verwendung in
dem kodierten Findbuch gefunden hätte, wäre <dao> nicht angebracht gewesen. In
einem solchen Fall wäre entweder <extptr> oder <extref> der richtige Tag zur
Erstellung eines solchen Links, abhängig davon, ob Text in das
Verknüpfungselement aufgenommen werden soll oder nicht. In Bild 7.4.1c ist eine
Kodierung der Angaben aus Bild 7.4.1b zu sehen, bei der <extptr> als
Verknüpfungselement verwendet wird:
<bioghist>
<p><extptr href="http://www.archivists.org/famousFolk/
sanford.jpg" actuate="auto" show="embed"></p>
<p>Sanford J. Archiviste, den die obige Porträtaufnahme von 1945
zeigt(das Bild ist digital auf der Webseite der Society of American
Archivists verfügbar), war Mitte des 20. Jahrhunderts eine
bedeutende geistige Kraft in der Archivwelt von Nordamerika.
[...]</p>
[weitere mögliche Elemente und Text ...]
</bioghist>
Bild 7.4.1c. Verwendung der Attribute ACTUATE und SHOW zusammen
mit <extptr>, um Eigenschaften des Links anzugeben.
7.4.2. Die Attribute ROLE, TITLE, CONTENT-ROLE und CONTENT-TITLE
Diese Gruppe von Attributen liefert der Anwendersoftware und den Nutzern
zusätzliche Informationen über die Rolle einer Ressource in einem bestimmten Link.
In den meisten einfachen Links (d. h., in Einweglinks mit einer Quelle und einem Ziel)
sind die Rollen klar, und diese Attribute werden nicht benötigt. Bei erweiterten Links
müssen jedoch die Rollen ggf. für die Verarbeitungssoftware oder die Nutzer
angegeben werden. Für diesen Zweck gibt es diese Attribute. Bei erweiterten InlineLinks (die unter Verwendung von <daogrp> oder <linkgrp> zur Bündelung mehrerer
„zeigender“ Elemente erstellt wurden) kann es erforderlich sein, weitere
Informationen bereitzustellen, um die Rolle der externen Ressource zu verdeutlichen,
für die jedes „zeigende“ Element eine Adresse liefert.
In solchen Fällen werden die Attribute ROLE und TITLE in den „zeigenden“
Elementen dazu verwendet, Informationen über die Rolle der entfernt liegenden
Ressourcen in dem Link zu kodieren. Die Wertebereiche dieser Attribute sind von der
DTD nicht eingeschränkt. Daher müssen die Kodierer sicher sein, dass die
231
angegebenen Werte angesichts der angesprochenen Zielgruppe sinnvoll sind. Bei
ROLE ist die Zielgruppe die Anwendersoftware, bei TITLE sind des die Nutzer. Es ist
wichtig, dass dass man sich einige Kenntnisse über die Anforderungen des Systems
aneignet wenn man die kodierten Findbücher verbreiten will, bevor diese Attribute bei
den Kodierarbeiten verwendet werden. Die meisten im Handel erhältlichen Systeme
unterstützen diese Attribute noch nicht. Die nachstehenden Ausführungen sollen den
Implementierern von EAD einige Grundkenntnisse über den Zweck der Attribute
vermitteln, damit sie diese dann künftig, wenn die Systeme ihre Verwendung ohne
Weiteres unterstützen, richtig einsetzen können.
Das Attribut ROLE soll definieren, welche Rolle eine entfernte liegende Ressource
für die Anwendersoftware hat mit der eine EAD-Instanz verarbeitet werden soll.
Vielleicht wurde in einem bestimmten Übertragungssystem ein Stylesheet erzeugt,
das den Bildlinks ein bestimmtes Verhalten zuordnet, je nachdem, ob es sich um
„Thumbnails“ oder „Referenzkopien“ dieser Bilder handelt. Das Übertragungssystem
kann es verlangen, dass bei der Kodierung aller Bildlinks (sowohl einfacher als auch
erweiterter Bildlinks), die dieses Stylesheet verarbeitet, angegeben ist, welche Rolle
ein Bild spielen soll. Bild 7.4.2a zeigt die Kodierung einer Bildzusammenstellung,
wobei zu jedem Bild sowohl eine Thumbnaildatei als auch eine größere Verweisdatei
vorhanden ist. Der Tag <daogrp> dient zum Bündeln der Dateigruppe für jedes Bild.
Das Attribut ROLE bei jedem <daoloc>-Tag gibt der Verarbeitungssoftware die
Beziehung der Dateien zueinander in jedem <daogrp> an. Da <daogrp> nicht
rekursiv ist (also nicht in sich selbst geschachtelt sein kann), wird das Element
Sonstige Erschließungsangaben <odd> zum Bündeln der <daogrp>-Tags verwendet,
die die Bildzusammenstellung umfassen. Natürlich müssen dem Prolog der EADInstanz Entitätsdeklarationen für alle Bilder hinzugefügt werden (siehe Abschnitt 6.5),
um die Kodierung in diesem Beispiel gültig zu machen.
<odd>
<head>Image Sampler</head>
<p>Die folgenden Fotos zeigen die in diesem Bestand verfügbaren
Arten von Bildern.</p>
<daogrp>
<daoloc entityref="s1_img1-th" role="thumbnail" actuate="auto"
show="embed"> <daodesc><p>Ältestes vorhandenes Bild des
Gerichtsgebäudes von Lassen County (US-Bundesstaat Kalifornien),
aufgenommen im Jahr 1897.<ref target="s1:LCCph">Link zu der Stelle,
an der sich dieses Bild in der Sammlungsverzeichnung
befindet</ref></p></daodesc></daoloc>
<daoloc entityref="s1_img1" role="reference" actuate="user"
show="new"></daoloc></daogrp>
<daogrp>
<daoloc entityref="s3_img1-th" role="thumbnail" actuate="auto"
show="embed"><daodesc><p> Goldwaschen am Feather River,
Plumas County (Kalif.), ca. 1870. <ref target="s3:MINEph">Link zu
der Stelle, an der sich dieses Bild in der Sammlungsverzeichnung
befindet</ref></p></daodesc></daoloc>
<daoloc entityref="s3_img1" role="reference" actuate="user"
show="new">
</daoloc>
</daogrp>
[weitere mögliche Elemente und Text ...]
</odd>
Bild 7.4.2a. Verwendung des Attributs ROLE, um die Rolle eines Links
anzugeben.
232
Das Attribut TITLE soll Nutzern Informationen zur Rolle der entfernt liegenden
Ressource liefern. In vielen Fällen, wie auch bei der in Bild 7.4.2a dargestellten
Kodierung, sind diese zusätzlichen Informationen nicht erforderlich, da sich in der
Umgebung des Links bereits zahlreiche Hinweise finden. Da sich außerdem die
Verwendung von Thumbnails als Quelle für Links zu größeren Referenzbildern im
World Wide Web weit verbreitet hat, verstehen viele Nutzer dieses Verhalten und
stellen sich darauf ein. Daher wären derartige Zusatzinformationen überflüssig.
Findeten Kodierer jedoch, dass Zusatzinformationen zur Rolle der entfernt liegenden
Ressource in einem Link benötigt werden, kann das Attribut TITLE verwendet
werden. Wie die als Wert des Attributs kodierte Information für Nutzer dargestellt
wird, richtet sich höchstwahrscheinlich nach dem zur Verbreitung des kodierten
Findbuchs eingesetzten System.
Die beiden letzten im vorliegenden Abschnitt behandelten Attribute, CONTENTROLE und CONTENT-TITLE, sind ausschließlich für die Verwendung im
Zusammenhang mit erweiterten Links bestimmt. Sie liefern Zusatzinformationen zur
Rolle der lokalen Ressource im externen Link. Wie das Attribut ROLE soll auch
CONTENT-ROLE der Anwendersoftware Informationen liefern, während CONTENTTITLE, wie auch TITLE, den Nutzern weitere Angaben liefert. Bei allen Inline-Links,
die von den meisten EAD-Implementierern derzeit noch verwendet werden, wird die
Rolle der lokalen Ressource als Quelle des Links durch die Erstellung des Links
selbst verdeutlicht. In Zukunft ist das anders, wenn es Out-of-line-Links geben wird,
in denen die lokale Ressource nicht als Quelle oder Ziel beteiligt ist. Goldfarb und
Prescod schildern sogar ein Szenario, in dem die Werte von Attributen wie
CONTENT-TITLE und TITLE von technisch ausgereifter Anwendersoftware dazu
verwendet werden, Nutzern Klappmenüs zu bieten, in denen sie Quellen und Ziele
für Out-of-line-Links wählen können.122
122
Goldfarb, Charles F. / Prescod, Paul: The XML Handbook, S. 509-510.
233
7.5. Management von externen Links123
Auf den ersten Blick scheint EAD zwar eine verwirrende Vielzahl von Möglichkeiten
für die Erstellung und das Management von Links zu bieten. Man wird jedoch
wahrscheinlich ein standardisiertes Verfahren auswählen, das von den Grenzen bzw.
Möglichkeiten des Systems bzw. der Systeme abhängt, in dem bzw.denen Authoring
und Veröffentlichung von EAD-kodierten Findbüchern erfolgen soll. Sind diese
Entscheidungen einmal getroffen und dokumentiert, muss man sich nicht mehr mit
den verschiedenen Optionen für jeden zu erstellenden Link auseinandersetzen. Der
Wert von Richtlinien und Dokumentation für Links innerhalb von
Institutionsgebundenen oder gemeinschaftlichen Vorhaben darf nicht unterschätzt
werden. Die frühzeitige Festlegung und konsequente Umsetzung solcher Standards
beim Kodierungsprozess wird später das Verschieben von kodierten Findbüchern an
andere Speicherstellen und ihre Anpassung an neue Übertragungssysteme
erleichtern, da Standards die Funktionalität der Findbücher erhöhen und dadurch die
Kosten und Implementierungsprobleme reduzieren.
Interne Links innerhalb einer Dokumentinstanz sind ihrer Art nach ziemlich einfach
und erfordern kein besonderes Management, außer dass sichergestellt werden
muss, dass die Attribute ID und TARGET zueinander passen. Dies kann mit einer
abschließende Analyse der EAD-Instanz überprüft werden. Dieser Abschnitt
konzentriert sich ausschließlich auf Entscheidungen, die hinsichtlich der Kodierung
von Zieladressen für externe Links getroffen werden müssen, sowie indirekt auf die
mit den Entscheidungen verbundenen Konsequenzen für das Management der
Dateien, auf die die Links verweisen.
Bei der Verarbeitung von Links von den Findbüchern zu externen Ressourcen, z. B.
Text- oder Bilddateien wie den in Bildern 7.3.4a und 7.4.1c zeigt, muss die
betreffende SGML-Anwendung Folgendes wissen:
•
•
Welche besondere Software ist ggf. zum Lesen der Datei erforderlich?
Wo genau befindet sich die Datei auf dem lokalen Rechner, im Netzwerk oder
im Web?
Der zweite Punkt ist besonders schwerwiegend, da die Speicherstellen von Dateien
sich häufig ändern, wenn Server ausgetauscht oder Verzeichnisstrukturen
umkonfiguriert werden. Ein ständiges Problem der Datenpflege besteht darin,
sicherzustellen, dass solche Links im Laufe der Zeit aktuell und funktionstüchtig
bleiben. Dieses Problem nimmt mit jedem Link zu, der in ein kodiertes Findbuch
eingefügt wird.
Der Rest dieses Abschnitts befasst sich ganz allgemein mit den Optionen bei der
Adressierung von EAD-Links zu externen Dateien. Der Schwerpunkt liegt allerdings
besonders auf den Dateien, die auf Ihrem eigenen Server bzw. Ihren eigenen
Servern abgelegt sind. Hier gibt es grundsätzlich folgende Möglichkeiten:
Verwendung des Attributs ENTITYREF oder des Attributs HREF.
123
Der Text dieses Abschnitts lehnt sich mit dem Einverständnis des Verfassers an eine unveröffentlichte Untersuchung über
Möglichkeiten externer Links an, die von Alvin Pollock, Electronic Text Unit, University of California, Berkeley, verfasst wurde.
234
•
•
Die Verwendung des Attributs ENTITYREF stützt sich auf das indirekte
Management von expliziten externen Ressourcenadressen, entweder
außerhalb der kodierten Dokumentinstanz mit Hilfe eines öffentlichen
Identifikators oder am Anfang jeder kodierten Dokumentinstanz mittels eines
Systemidentifikators.
Die Verwendung des Attributs HREF beruht auf dem direkten Management
von expliziten externen Ressourcenadressen unmittelbar an der Quelle jedes
in einer kodierten Dokumentinstanz erstellten Links.
Die Stärken und Schwächen jedes Verfahrens werden erläutert. Keine dieser
Optionen ist absolut richtig oder falsch, weshalb keine von Ihnen ausschließlich
empfohlen wird. Über das anzuwendende Verfahren muss im Zusammenhang mit
den vorhandenen administrativen und technischen Gegebenheiten entschieden
werden.
7.5.1. Verwendung von ENTITYREF
Die vielleicht am weitesten verbreitete und technisch eleganteste
Linkmanagementstrategie, die in SGML-gestützten Systemen angewandt wird,
besteht darin, externe Dateien mit Hilfe eines (FPI)124 als Entitäten zu deklarieren
und dann das Attribut ENTITYREF zur Angabe des Namens einer deklarierten Entität
als Ziel eines Links zu verwenden, wie es in Bild 7.5.1a gezeigt wird.
<!ENTITY pageimage1 PUBLIC "-//University of California, Berkeley::
Bancroft Library//TEXT (US::CU-BANC::BANC MSS 92/894c::The Arequipa
Sanatorium Records::Letter page image 1)" NDATA gif>
<dao entityref="pageimage1"></dao>
Bild 7.5.1a. Eine Entitätsdeklaration nur mit einem öffentlichen Identifikator
(hier einem FPI), gefolgt von einem Verweis zur deklarierten Entität.
Bei diesem Verfahren gibt das Attribut ENTITYREF im Verknüpfungselement indirekt
die Speicherstelle der Ressource über einen Entitätsnamen und nicht über eine
absolute Rechneradresse wie z. B. eine URL an. Diese Vorgehensweise hat gewisse
Vorteile. Durch das Deklarieren einer Entität mittels eines FPI ist es möglich, eine
gesonderte Datei, z. B. eine SGML-Katalogdatei oder einen Handle-Server125, zu
verwenden, um je nach Art der Verarbeitungssoftware eine geeignete Adresse oder
Speicherstelle für die Ressource anzugeben. Diese Werkzeuge dienen als
Wegweiser zwischen den Entitätsnamen (die mühelos von jedem Punkt innerhalb
einer kodierten Dokumentinstanz aus referenziert werden können) und den Adressen
bzw. Speicherstellen, auf die sich diese Entitätsnamen beziehen. Wenn sich die
Speicherstellen von Ressourcen im Laufe der Zeit ändern, muss lediglich die SGMLKatalogdatei angepasst werden. Die einzelnen EAD-Instanzen, die die stabilen
Entitätsnamen zur Referenzierung der SGML-Katalogdatei enthalten, müssen nicht
überarbeitet werden.
124
125
Weitere Informationen zu öffentlichen Identifikatorn siehe Unterabschnitte 6.5.2.2 und 6.5.2.4.1.
Unterabschnitt 6.5.2.4.1 enthält weitere Informationen über SGML-Katalogdateien und Abschnitt 5.4 über Handle-Server.
235
Dieses Verfahren hat auch technische Nachteile. Web-Browser, die XML sowie XSLoder CSS- Stylesheets unterstützen, können nicht auf solche Entitätsnamen
zugreifen und sie auch nicht in explizite Ressourcenadressen wie z. B. eine URL
auflösen. Eine Spezialprogrammierung wäre erforderlich, um Behelfslösungen für
dieses Problem zu finden. Außerdem sind die Aufwände zur Erstellung eines
wohlgeformten FPI (wie ihn der Standard ISO 9070 fordert) für jede digitale
Ressource nicht unbedeutend.
Bei Systemen, die die Verwendung von FPI und Katalogdateien nicht unterstützen,
kann als Ergänzung oder anstelle eines FPI ein Systemidentifikator in einer
Entitätsdeklaration angegeben werden, wie aus Bild 7.5.1b hervorgeht. Wie bereits in
den Unterabschnitten 6.5.2.2 und 6.5.2.4.1 erörtert, dient ein Systemidentifikator zur
Angabe einer direkten Adresse in Form eines URI in der Entitätsdeklaration.
<!ENTITY pageimage1 PUBLIC "-//University of California, Berkeley::
Bancroft Library//TEXT (US::CU-BANC::BANC MSS 92/894c::The Arequipa
Sanatorium Records::Letter page image 1)"
"http://sunsite.berkeley.edu/arequipa/page1.gif"
NDATA gif>
<dao entityref="pageimage1"></dao>
Bild 7.5.1b. Eine Entitätsdeklaration mit öffentlichem Identifikator und
Systemidentifikator (hier einer absoluten URL), gefolgt von einem
Verweis zur deklarierten Entität.
Dieses Kombinationsverfahren liefert in der Entitätsdeklaration eine explizite
Ressourcenadresse, stützt sich aber trotzdem auf eine Übertragungsanwendung, die
auf diese Ressourcenadresse von ihrer Speicherstelle in einer Entitätsdeklaration am
Anfang einer Dokumentinstanz indirekt zugreifen kann. Aus diesem Grund ist dieses
Verfahren bei den derzeitigen XML-Anwendungen, die sich auf Web-Browser stützen
und mit XSL- oder CSS- Stylesheets arbeiten, um ihre Darstellung zu formatieren,
nicht möglich. Dies kann sich allerdings im Zuge der Weiterentwicklung von XSL und
der zugehörigen Anwendersoftware ändern.
Außerdem kann es die Verwendung von Systemidentifikatoren in
Entitätsdeklarationen erfordern, dass die einzelnen EAD-kodierten Dateien
überarbeitet werden, wenn sich die Speicherstelle einer bestimmten Ressource auf
dem Server ändert, was die Vorzüge der Verwendung von Entitäten zur Angabe
indirekter Dateiadressen in Findbüchern zunichte macht. Dieser mögliche Nachteil
lässt sich mit Hilfe der Funktion „Suchen und Ersetzen“ der meisten gängigen
Texteditoren und auch durch sorgfältige Planung der Verzeichnisstrukturen auf dem
(Server bzw. den Servern, auf dem die Dateien liegen, teilweise ausgleichen.
236
7.5.2. Verwendung von HREF
Die Verwendung des Attributs HREF unmittelbar an der Quelle jedes Links, um eine
Zieladresse zu bilden, wie in Bild 7.5.2a veranschaulicht, macht den Umweg über
das Verfahren mit ENTITYREF, das für einige Anwendungen problematisch sein
kann, unnötig. Die z. Z. frei erhältliche Web-Browser-Technologie kann mühelos mit
Links umgehen, die mit dieser Option kodiert wurden. Die Kodierung ist viel leichter,
besonders für Archive mit wenig technischer Erfahrung oder begrenzten Ressourcen,
die u. U. die Implementierung von EAD auf sich allein gestellt durchführen. Bei dieser
Option wird keine SGML-Katalogdatei benötigt. Wenn sich die Speicherstelle einer
Zielressource ändert, müssen die Verknüpfungselemente in allen Findbuchinstanzen
entsprechend angepasst werden, was in den Findbüchern eines Archivs leicht mit
Hilfe einer übergreifenden „Suchen-und-Ersetzen“-Funktion durchgeführt werden
kann. Schließlich werden Kodierer, die im Gebrauch von HTML erfahren sind,
feststellen, dass die HREF-Notation leichter zu lesen und anzuwenden ist.
<dao href="http://sunsite.berkeley.edu/arequipa/page1.gif">
</dao>
Bild 7.5.2a. Externer Link, erstellt ohne Entitätsdeklarationen
unter direkter Verwendung des Attributs HREF (hier mit Angabe eines
absoluten URL).
All diese Vorzüge scheinen zwar klar für dieses Verfahren zu sprechen. Es hat
jedoch entscheidende Nachteile. Wie bei allen Web-Anwendungen stellt die laufende
Aktualisierung von Verweisen zu Dateiadressen ein großes Problem der Datenpflege
dar. Dieser Prozess kann durch einige Werkzeuge unterstützt werden, die z. Z. den
Web-Administratoren zur Verfügung stehen und mit denen sich schadhafte Links
finden lassen. Die Pflege lokaler Dateien kann weiter dadurch erleichtert werden,
dass nur der Dateiname selbst ("page1.gif") im Attribut HREF eingebettet ist. Der
Dateipfad ("http://sunsite.berkeley.edu/ arequipa/") dagegen wird in einem Stylesheet
angegeben. Dabei ist zu jedoch beachten, dass diese Option aufgrund der
Schwierigkeiten bei der Pflege von Adresseninformationen für externe Ressourcen
größere Risiken birgt, wenn es um die Austauschbarkeit von Findbüchern und die
Implementierung von Verbunddatenbanken für Findbücher geht.
Bei der Verwendung von HREF genügt es nicht, einfach eine URL oder einen
Systemidentifikator anzugeben. Die Verarbeitungssoftware benötigt zusätzliche
Anweisungen hinsichtlich der Darstellung der Ressource. Soll das Bild an der Stelle,
wo der Link auftritt, in das Findbuch eingefügt werden, oder soll es einen Hyperlink
zu einer externen Textdatei geben, wie etwa einem Eintrag in einem elektronischen
biografischen Nachschlagewerk? Wenn keine standardmäßig vorgegebene Option
für alle Links gilt, muss die Art der Darstellung mit Hilfe der Attribute SHOW und
ACTUATE angegeben werden.
237
7.5.3. Kombination der beiden Verfahren
Diese Möglichkeit umfasst das entitätsgestützte und das HREF-gestützte Verfahren
zur Kodierung von URLs für externe digitale Ressourcen. Diese Kombination
ermöglicht zwar beide Adressieroptionen und erlaubt es einer Verarbeitungssoftware,
darüber zu entscheiden, welche Adressieroption verwendet werden soll. Es ist jedoch
zu beachten, dass die Kombination bei einigen SGML-gestützten Systemen zu
Indexierungsproblemen geführt hat. Dieses Verfahren sorgt offensichtlich für eine
Redundanz bzgl. der URL sowohl in der Entitätsdeklaration als auch an der Stelle,
wo sich der Link selbst befindet.Dadurch dürfte es mit Sicherheit zu erhöhtem
Kodierungsaufwand bei den Findbüchern und zu einer erhöhten Komplexität bei der
Überarbeitung kommen, wenn sich die URL ändern. Trotz allem ist dies u. U. die
flexibelste Option im Hinblick auf die Austauschbarkeit sowie auf die
Geschwindigkeit, mit der heutzutage Änderungen in den Informationsmanagementund Übertragungstechnologien stattfinden. Im Idealfall dürfte das Einfügen einer URL
sowohl in die Entitätsdeklaration als auch in das Verknüpfungselement selbst dafür
sorgen, dass der größte Teil der Anwendersoftware imstande ist, die
Ressourcenadressen soweit wie möglich zu verarbeiten und die anderen zu
ignorieren.
<!ENTITY pageimage1 PUBLIC "-//University of California, Berkeley::
Bancroft Library//TEXT (US::CU-BANC::BANC MSS 92/894c::The Arequipa
Sanatorium Records::Letter page image 1)"
"http://sunsite.berkeley.edu/arequipa/page1.gif"
NDATA gif>
<dao entityref="pageimage1"
href="http://sunsite.berkeley.edu/arequipa/page1.gif">
</dao>
Bild 7.5.3a. Entitätsdeklaration mit öffentlichem Identifikator und
Systemidentifikator (hier einer absoluten URL), gefolgt von einem Link, der
einen Verweis zur deklarierten Entität sowie eine hart kodierte
HREF Adresse umfasst.
238
7.6. Beispiele für optimal kodierte Verknüpfungselemente
Die folgenden Beispiele veranschaulichen eine optimale Kodierung von internen und
externen EAD-Links. Wie definieren wir den Begriff „optimal“? Im Rahmen des
Leitfadens bedeutet er das Mindestmaß an Informationen über einen Link, das
erforderlich ist, damit der Link in den meisten Veröffentlichungs-Systemen für
Findbücher effizient funktioniert. Die Forderungen bzgl. der optimalen Kodierung von
Links in EAD sind in eigentlich ganz einfach. Jeder Link ist mit folgenden
Informationen zu versehen:
•
•
einer Adresse für das vorgesehene Ziel bzw. die vorgesehenen Ziele
grundlegende Angaben darüber, wie sich der Link bei der Verarbeitung durch
die Anwendersoftware verhalten soll.
Die Wahlmöglichkeiten zur Erfüllung dieser Forderungen sind begrenzt. Das dürfte
die optimale Kodierung von Links in EAD-Dokumenten erleichtern. Für interne Links
gibt es bzgl. der ersten Anforderung nur eine Option: es ist die Verwendung des
Attributs TARGET. Für externe Links gibt es zur ersten Anforderung drei Optionen:
es sind entweder ENTITYREF, HREF oder es sind beide Attribute zu verwenden.
Weitere Informationen zu den Problemen im Zusammenhang mit diesen
Entscheidungen sind Abschnitt 7.5 zu entnehmen. Die zweite Anforderung ist
ebenfalls leicht zu erfüllen, indem in sämtlichen kodierten Links sowohl ACTUATE als
auch SHOW verwendet wird. Diese beiden Attribute liefern gemeinsam ein
Mindestmaß an Informationen darüber, wie sich die Links in dem System, das sie
zwecks Darstellung für den Nutzer verarbeitet, verhalten sollen. Das Attribut ROLE
ist zwar nicht für alle Fälle zu empfehlen, kann jedoch, wie in Bild 7.4.2a gezeigt,
dazu dienen, der Anwendersoftware eindeutig die Rolle jedes der Links mitzuteilen,
die unter Verwendung eines der erweiterten Verknüpfungselemente <daogrp> oder
<linkgrp> gebündelt werden (das entspricht dem Bündeln der „Thumbnail-“ und
„Referenzansichten“ desselben Bildes). Die Mehrzahl der z. Z. im Handel erhältlichen
Softwarepakete kann zwar die Attribute ACTUATE, SHOW und ROLE nicht
verarbeiten, es ist trotzdem zweckmäßig, diese Informationen zu liefern, wenn Links
in kodierte Findbücher eingefügt werden.
Der Anwenderleitfaden enthält zwar Informationen zur optimalen Kodierung von
Verknüpfungsattributen. Er kann jedoch keine Aussagen darüber machen, wann und
wie viele Links zu erstellen sind. Diese Fragen müssen vor Ort geklärt werden, und
zwar vor dem Hintergrund der Fähigkeiten der Anwendersoftware hinsichtlich der
„Veröffentlichung” von kodierten Findbüchern sowie den Zielen, die das Archiv und
sein Sponsor für das anstehende Kodierungsvorhaben, setzen. Wenn allerdings
Links innerhalb der EAD-kodierten Findbücher erstellt werden sollen, ist es wichtig,
Richtlinien zu diesen Fragen vorzugeben, allen am Vorhaben Beteiligten die
entsprechende Dokumentation zur Verfügung zu stellen und die Vorgaben
konsequent auf alle kodierten Findbüchern, die im Laufe der Zeit im Rahmen des
Vorhabens erstellt werden, anzuwenden. Auf Dauer erleichtern Konsequenz,
Standardisierung und Dokumentation die Investitionen in der Kodierung und erhöhen
die Chancen, die unaufhaltsamen Fortschritte in der Hardware- und
Softwaretechnologie auch künftig für die Bearbeitung und Verbreitung von
Erschließungsdaten nutzen zu können.
239
Die folgenden Beispiele sind anderen Bildern weiter oben in diesem Kapitel
entnommen. Bei allen in diesen Beispielen erstellten Links handelt es sich um InlineLinks (siehe Unterabschnitt 7.1.2.3). Das Attribut INLINE wird nicht verwendet, da
sein Wert in der EAD-DTD mit "true" vorgegeben ist. Durch die Verwendung des
Attributs INLINE wären diese Beispiele im Hinblick auf optimale Kodierung nicht
wenigre anschaulich.
Bild 7.6a zeigt einen einfachen internen Link, der es Nutzern ermöglichen soll, den
Text einer auf Bestandsebene kodierten Bemerkung zur Benutzungsbeschränkung
zu prüfen, und zwar an einer Stelle in der Komponentenverzeichnung, wo die
Beschränkung gilt. Es ist zu beachten, dass durch die Verwendung des Wertes "new"
für das Attribut SHOW für den Text der Benutzungsbeschränkung ein neues Fenster
geöffnet wird, so dass der Benutzer nicht dadurch verwirrt wird, dass sich an der
alten Stelle innerhalb des Findbuchs etwas ändert (dazu würde es kommen, wenn
der Wert "replace" verwendet würde). Da <ref> verwendet wurde, wird die
Anwendersoftware den Text zwischen <ref> und </ref> wahrscheinlich hervorheben,
um den Nutzern mitzuteilen, dass ein Link vorhanden ist.
<archdesc level="collection" langmaterial="eng" type="inventory">
<did>[...]</did>
<admininfo>
[weitere mögliche Elemente und Text ...]
<accessrestrict id="restrict1">
<head>Benutzungsbeschränkungen</head>
<p> Dieser Bestand ist für Untersuchungen aller Forscher mit
folgender Ausnahme offen: Serie 2 (Korrespondenz) enthält 15 Ordner
mit Studierendenzeugnissen die dem State Student Records Act
unterliegen und für 75 Jahre gesperrt sind (1968:042). Der erste
dieser Ordner steht für Forscher ab dem 1. Januar 2035 und der
letzte ab dem 1. Januar 1947 für die Benutzung zur Verfügung.</p>
</accessrestrict>
[weitere mögliche Elemente und Text ...]
</admininfo>
[weitere mögliche Elemente und Text ...]
<dsc type="combined">
[weitere mögliche Elemente und Text ...]
<c01 level="series">
<did>
<unittitle>Series 2: Korrespondenz</unittitle>
[...]</did>
<scopecontent><p>Die Serie Korrespondenz enthält ...</p>
<arrangement><p> Der größte Teil des Inhalts der Serie traf im
Archiv in chronologischer Reihenfolge ein. Diese Ordnung wurde
beibehalten. <ref target="restrict1" actuat=“user“ show=“new“> Die
einzige Ausnahme ist eine Akte mit Studierendenzeugnissen, für die
Zugangsbeschränkungen gelten.</ref> Diese Ordner wurden
vorrübergehend in einen Behälter innerhalb der Sammlung überführt,
der mit einer Zugangsbeschränkung versehen wurde.</p></arrangement>
</scopecontent>
[weitere mögliche Elemente und Text ...]
</c01>
[weitere mögliche Elemente und Text ...]
</dsc>
</archdesc>
Bild 7.6a.
240
In Bild 7.6b wird ein externes Verknüpfungselement verwendet, mit dem Links zu
anderen Archivbeständen erstellt werden, um Nutzern den Zugriff auf ein Findbuch
zu einen verwandten Bestand mit persönlichen Unterlagen in einem anderen Archiv
zu ermöglichen. Außerdem dient hier ein einfacher externer Link dazu, ein Bild des
Nachlassergebers dieser externen Unterlagengruppe einzufügen. Aufgrund der
zugeordneten Attributwerte wird der verlinkt Text hervorgehoben, um Endnutzer auf
das Vorhandensein des Links aufmerksam zu machen. Das Bild erscheint
automatisch im Text des Verweises nach dem Titel des verwandten Bestandes.
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd
(Encoded Archival Description (EAD) Version 1.0)//EN" [
<!ENTITY tedschell SYSTEM "http://www.archivesrus.gov/
findaids/ead/ms045.sgm" NDATA sgml>
<!ENTITY schellpix SYSTEM "http://www.myserver.org/images/
ms023_schell.gif" NDATA gif>
]>
<ead audience="external">
[weitere mögliche Elemente und Text ...]
<add>
<relatedmaterial>
<head>Related Collections</head>
<archref entityref="tedschell" actuate="user" show="replace">
<origination label="Creator:">
<persname source="lcnaf" role="creator">Schellenberg, T. R.,
1903-1970</persname>
</origination>
<unittitle>Theodore R. Schellenbergs Papiere,
<unitdate type="inclusive">1938-1970</unitdate>
</unittitle>
<extptr entityref="schellpix" actuate="auto" show="embed">
<unitid type="collection number">MS-045</unitid>
<repository><name>Archives R Us</name>
</repository>
</archref>
[weitere mögliche Elemente und Text ...]
</relatedmaterial>
</add>
</ead>
Bild 7.6b.
Bild 7.6c zeigt die Verwendung von <daogrp> zur Bündelung der Paare von
Thumbnails und Referenzbildern zu jedem Einzelstück. Die Kodierung der Attribute
ACTUATE und SHOW in diesem Beispiel führt wahrscheinlich dazu, dass die
Thumbnails automatisch nach dem <unittitle> für jedes Einzelstück in den Text des
Findbuchs eingebettet wird, wogegen das größere Referenzbild in einem neuen
Browserfenster erscheint, wenn man den Link aktiviert.
241
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD
ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" [
<!ENTITY f0042_1 SYSTEM "../images/fonds0042_image1.jpg" NDATA
jpeg>
<!ENTITY f0042_2 SYSTEM "../images/fonds0042_image2.jpg" NDATA
jpeg>
<!ENTITY f0042_1tmb SYSTEM
"../images/fonds0042_image1_thumb.jpg" NDATA jpeg>
<!ENTITY f0042_2tmb SYSTEM
"../images/fonds0042_image2_thumb.jpg" NDATA jpeg>
]>
<ead audience="external">
[weitere mögliche Elemente und Text ...]
<dsc type="combined">
[weitere mögliche Elemente und Text ...]
<c01 level="series"><did> <unittitle>Series 3: Biographical
Information </unittitle>
[weitere mögliche Elemente und Text ...]
</did>
<c02 level="file"><did><unittitle>Fotographien,
<unitdate type="inclusive">1895-1928</unitdate></unittitle>
<physdesc><extent>5 Einzelstücke</extent></physdesc></did>
<c03 level="item"><did><unittitle>Examensporträt von John Smith,
<unitdate type="single" normal="18950528">28. Mai
1895</unitdate></unittitle>
<daogrp>
<daoloc entityref="f0042_1tmb" actuate="auto" show="embed"
role="thumbnail"></daoloc>
<daoloc entityref="f0042_1" actuate="user" show="new"
role="reference"></daoloc></daogrp></did></c03>
<c03 level="item"><did><unittitle>Hochzeit von John Smith
und Stella Jones, Windsor, Ontario, <unitdate type="single"
normal="18970606">6. Juni 1897</unitdate></unittitle>
<daogrp>
<daoloc entityref="f0042_2tmb" actuate="auto" show="embed"
role="thumbnail"></daoloc>
<daoloc entityref="f0042_2" actuate="user" show="new"
role="reference"></daoloc>
</daogrp></did></c03>
[weitere mögliche Elemente und Text ...]
</c02>
[weitere mögliche Elemente und Text ...]
</c01></dsc>
[weitere mögliche Elemente und Text ...]
</ead>
Bild 7.6c.
242
Anhang
Anhang A: Empfohlenes Grundgerüst an Elementen für Findbücher................................................. 244
Anhang B: EAD-Crosswalks................................................................................................................ 246
B.1. Von ISAD(G) zu EAD ............................................................................................................... 247
B.2. Von EAD zu ISAD(G) ............................................................................................................... 248
B.3. Von Dublin Core zu EAD.......................................................................................................... 249
B.4. Von USMARC zu EAD ............................................................................................................. 250
Anhang C: Häufig gestellte Fragen ..................................................................................................... 253
Anhang D: Prüfliste für die Implementierung....................................................................................... 259
Anhang E: Beispiele ............................................................................................................................ 263
Beispiel 1 ......................................................................................................................................... 263
Beispiel 2 ......................................................................................................................................... 276
Beispiel 3 ......................................................................................................................................... 281
Anhang F: Glossar............................................................................................................................... 285
Anhang G: Bibliografie......................................................................................................................... 292
Encoded Archival Description (EAD) ........................................................................................... 292
Standard Generalized Markup Language (SGML), Extensible Markup Language (XML) und
verwandte Technologien .............................................................................................................. 294
Archivische Erschließung ............................................................................................................. 297
Thesauri und Regeln für die archivische Erschließung................................................................ 299
243
Anhang A: Empfohlenes Grundgerüst an Elementen für Findbücher
Die auf der nächsten Seite aufgeführten EAD-Elemente stellen das empfohlene
Grundgerüst an Elementen für ein sehr einfaches EAD-Findbuch dar. Diese Liste
enthält sowohl die Elemente, die von der EAD-DTD für die Validierung gefordert
werden (in Fettdruck) und weitere ebenfalls wichtige Strukturelemente. Zusammen
entsprechen diese den „gängigen Elementen“ für eine einfache archivische
Erschließung. Bei dieser Liste von Elementen wird davon ausgegangen, dass die
archivische Erschließung auf Sammlungs-, Bestands- oder Serienebene beginnt.
Viele der aufgeführten Elemente sind aber auf allen Erschließungsebenen verfügbar.
Wie die geringe Anzahl der fett gedruckten Elementnamen zeigt, sind nur eine
Handvoll Elemente erforderlich, damit ein EAD kodiertes Findbuch anhand der DTDSpezifikationen validiert werden kann. Es ist jedoch zu beachten, dass ein nur aus
diesen Elementen bestehendes EAD-Dokument wohl kaum für ein richtiges Findbuch
ausreicht. Die Liste ist teilweise aus Gründen so kurz, die mit den SGML-Regeln zur
Erstellung von DTD zusammenhängen, und teilweise, weil die EAD-Entwickler
festgestellt haben, dass viele „Alt-Findbücher” nicht alle Datenelemente enthalten
oder nicht alle Datenelemente einheitlich verwendet wurden, und sie verhindern
wollten, dass für diese Findbücher nicht die Möglichkeit besteht, sie in EAD
umzuwandeln.
Die Schachtelung von Elementen wird nur aufgezeitgt, wo dies erforderlich ist, z. B.
bei <titleproper> innerhalb von <titlestmt> innerhalb von <filedesc>. Andererseits wird
das Element <unitdate> außerhalb von <unittitle> thematisiert, obwohl es durchaus
zulässig ist, <unitdate> innerhalb von <unittitle> zu kodieren.
Die Liste umfasst nur die für die Validierung erforderlichen Attribute (LEVEL bei
<archdesc> und TYPE bei <dsc>) sowie Attribute, die Entsprechungen in ISAD(G)
haben (LANGMATERIAL und LEGALSTATUS bei <archdesc>, COUNTRYCODE
und REPOSITORYCODE bei <unitid>, LEVEL bei <c>). Es wird empfohlen, die
Attribute ENCODINGANALOG, PARENT und ID konsequent zu verwenden, wenn
das betreffende System in der Lage ist, sie zu verarbeiten.
Die Liste zeigt auch die vorgeschriebene Reihenfolge innerhalb der Abschnitte eines
kodierten Findbuchs, wie sie von der EAD-DTD vorgegeben wird:
•
•
•
die <eadheader>-Subelemente,
das hochrangige <did> innerhalb von <archdesc>,
das Element <did> innerhalb von <c> oder <c0x>.
In allen anderen Fällen schreibt die DTD keine bestimmte Reihenfolge der Elemente
vor. Beispielsweise können sowohl die <did>-Subelemente als auch alle Elemente
auf gleicher Ebene wie das hochrangige <did> in jeder beliebigen Reihenfolge
kodiert werden (z. B. kann <scopecontent> vor <bioghist> und <admininfo> stehen).
Bei der Festlegung einer einheitlichen Reihenfolge der Findbuchelemente sollten
auch die Bedürfnisse der jeweiligen Zielgruppe berücksichtigt werden.
244
<ead>
<eadheader>
<eadid>
<filedesc>
<titlestmt>
<titleproper>
<author>
<publicationstmt>
<publisher>
<date>
<profiledesc>
<creation>
<langusage>
<language>
<archdesc> mit den Attributen LEVEL, LANGMATERIAL und LEGALSTATUS
<did>
<repository>
<corpname>
<origination>
<persname>, <corpname>, <famname> nach Bedarf
<unittitle>
<unitdate>
<physdesc>
<unitid> mit den Attributen COUNTRYCODE und
REPOSITORYCODE
<abstract>
<admininfo>
ggf. Subelemente
<bioghist>
<scopecontent>
<controlaccess>
ggf. Subelemente
<dsc> mit dem Attribut TYPE
<c0x> oder <c> mit dem Attribut LEVEL auf so vielen
Ebenen wie erforderlich
<did>
<container>
<unittitle>
ggf. weitere Subelemente
245
Anhang B: EAD-Crosswalks
Der vorliegende Anhang enthält vier „Crosswalks”, die ein Mapping der EADElemente mit Datenelementen ermöglichen, die in drei verwandten
Metadatenstandards oder -rahmen definiert wurden: ISAD(G), Dublin Core und
USMARC. Die Crosswalks erleichtern u. U. das Zuordnen von Daten zwischen
diesen Metadatenwerkzeugen, z. B. beim Exportieren von Daten aus EAD-kodierten
Findbüchern zur Erstellung von USMARC-Titelaufnahmen. Weitere Informationen zur
Beziehung zwischen EAD und den anderen Standards sind in verschiedenen
Abschnitten des Anwenderleitfadens enthalten.
Es handelt sich um folgende vier Crosswalks:
B.1. Von ISAD(G) zu EAD
B.2. Von EAD zu ISAD(G)
B.3. Von Dublin Core zu EAD
B.4. Von USMARC zu EAD
Bei der Zusammenstellung der Crosswalks wurde mit Bedacht vorgegangen. Es
wurden nur klar erkennbare Äquivalente zwischen Datenelementen aufgenommen.
Andere, grob vergleichbare Elemente, die die Anwender möglicherweise kennen,
wurden weggelassen, wenn die Übereinstimmung entweder nicht eindeutig oder
unsicher schien.
Werden zwei EAD-Elemente nebeneinander aufgeführt, bedeutet dies, dass das
zweite Element ein Subelement des ersten ist. Beispielsweise weist
"<controlaccess><persname>" darauf hin, dass das Element <persname> im
Element <controlaccess> zu schachteln ist.
Werden verschiedene EAD-Elemente in jeweils einer eigenen Zeile innerhalb einer
Tabellenzelle aufgeführt, bedeutet dies, dass alle aufgeführten Elemente mit dem
zugehörigen Datenelement aus dem anderen Metadatenwerkzeug gemappt werden
können.
246
B.1. Von ISAD(G)* zu EAD
ISAD(G)
3.1.1 Signatur(en)) (Reference code(s)
3.1.2 Titel (Title)
3.1.3 Entstehungszeitraum/Laufzeit (Dates of
creation)
3.1.4 Verzeichnungsstufe (Level of description)
3.1.5 Umfang (Menge oder Abmessungen) (Extent
of the unit)
3.2.1 Name der Provenienzstelle (Name of creator)
3.2.2 Verwaltungsgeschichte /Biographische
Angaben (Administrative/Biographical history)
3.2.3 Zeitraum der Materialzusammenstellung
(Dates of accumulation)
3.2.4 Bestandsgeschichte (Custodial history)
3.2.5 Direktübernahme von der Provenienzstelle
(Immediate source of acquisition)
3.3.1 Form und Inhalt (Scope and content)
3.3.2 Bewertung und Kassation
(Appraisal, destruction and scheduling)
3.3.3 Neuzugänge (Accruals)
3.3.4 Ordnung und Klassifikation (System of
arrangement)
3.4.1 Rechtsstatus (Legal status)
3.4.2 Zugangsbestimmungen (Access conditions)
3.4.3 Copyright/
Reproduktionsbestimmungen
(Copyright/Reproduction)
3.4.4 Sprache (Language of material)
3.4.5 Physische Beschaffenheit (Physical
characteristics)
3.4.6 Findhilfsmittel (Finding aids)
3.5.1 Aufbewahrungsort der Originale (Location of
originals)
3.5.2 Kopien bzw. Reproduktionen (Existence of
copies)
3.5.3 Verwandte
Verzeichnungseinheiten (Related units of
description)
3.5.4 Verwandtes Material (Associated material)
3.5.5 Veröffentlichungen (Publication note)
3.6.1 Anmerkungen (Note)
EAD
<unitid> Attribute COUNTRYCODE und
REPOSITORYCODE
<unittitle>
<unitdate>
<archdesc> und <c> Attribut LEVEL
<physdesc>, <extent>
<origination>
<bioghist>
<custodhist><date type="accumulation">
<custodhist>
<acqinfo>
<scopecontent>
<appraisal>
<accruals>
<arrangement>
<archdesc> Attribut LEGALSTATUS
<accessrestrict>
<userestrict>
<archdesc> Attribut LANGMATERIAL
<physdesc><physfacet>
<otherfindaid>
<odd>
<altformavail>
<relatedmaterial>
<separatedmaterial>
<bibliography>
<odd>
*
A.d.Ü.: Die Übersetzungen der Begriffliche aus ISAD(G) sind identisch mit denen der deutschen Fassung der 1. Auflage von
ISAD(G). Vgl. Internationale Grundsätze für die archivische Verzeichnung, übers. und bearb. von Rainer Brüning und Werner
Heegewaldt, (= Veröffentlichungen der Archivschule Marburg, 23) Marburg 1994.
247
B.2. Von EAD zu ISAD(G)
EAD
<accessrestrict>
<accruals>
<acqinfo>
<altformavail>
<appraisal>
<archdesc> und <c> Attribut LEVEL
<archdesc> Attribut LANGMATERIAL
<archdesc> Attribut LEGALSTATUS
<arrangement>
<bibliography>
<bioghist>
<custodhist>
<custodhist><date type="accumulation">
<odd>
<odd>
<origination>
<otherfindaid>
<physdesc> <extent>
<physdesc> <physfacet>
<relatedmaterial>
<scopecontent>
<separatedmaterial>
<unitdate>
<unitid> Attribute COUNTRYCODE und
REPOSITORYCODE
<unittitle>
<userestrict>
ISAD (G)
3.4.2 Zugangsbestimmungen (Access conditions)
3.3.3 Neuzugänge (Accruals)
3.2.5 Aufbewahrungsort der Originale (Immediate
source of acquisition)
3.5.2 Kopien und Reproduktionen (Existence of
copies)
3.3.2 Bewertung und Kassation (Appraisal,
destruction and scheduling)
3.1.4 Verzeichnungsstufe (Level of description)
3.4.4 Sprache (Language of material)
3.4.1 Rechtsstatus (Legal status)
3.3.4 Ordnung und Klassifikation (System of
arrangement)
3.5.5 Veröffentlichungen (Publication note)
3.2.2 Verwaltungsgeschichte / Biographische
Angaben (Administrative/Biographical history)
3.2.4 Bestandsgeschichte (Custodial history)
3.2.3 Zeitraum der Materialzusammenstellung
(Dates of accumulation)
3.6.1 Anmerkungen (Note)
3.5.1 Aufbewahrungsort der Originale (Location
of originals)
3.2.1 Name der Provenienzstelle (Name of
creator)
3.4.6 Findhilfsmittel (Finding aids)
3.1.5 Umfang (Menge oder Abmessungen)
Extent of the unit
3.4.5 Physische Beschaffenheit (Physical
characteristics)
3.5.3 Verwandte Verzeichnungseinheiten
(Related units of description)
3.3.1 Form und Inhalt (Scope and content)
3.5.4 Verwandtes Material (Associated material)
3.1.3 Enstehungszeitraum / Laufzeit (Dates of
creation)
3.1.1 Signatur(en) (Reference code(s))
3.1.2 Titel (Title)
3.4.3 Copyright / Reproduktionsbestimmungen
(Copyright/Reproduction)
248
B.3. Von Dublin Core zu EAD
In Tabelle B.3 sind die 15 Elemente von Dublin Core (DC) mit den EAD-Elementen
innerhalb von <eadheader> und <archdesc> gemappt. DC gilt seit 1999 als „in
Arbeit”. Daher kann sich das Mapping in Zukunft ändern.
Beim Mapping DC – EAD ist zunächst zu überlegen, welche „Ressource” durch die
Metadaten beschrieben werden: das Findbuch selbst oder der Bestand. Wird das
Findbuch beschrieben, so ist es am zweckmäßigsten, die DC-Elemente mit den
Subelementen von <eadheader> zu mappen. Wird demgegenüber eine DCTitelaufnahme für einen Bestand erstellt, sind die DC-Elemente mit den
Subelementen von <archdesc> zu mappen, von denen die meisten im hochrangigen
<did> zu finden sind.
Alle DC-Elemente sind in dieser Tabelle aufgeführt. Allerdings haben einige DCElemente in EAD keine eindeutige Entsprechung. Wenn eine Tabellenzelle keine
Angabe enthält, ist kein eindeutiges Äquivalent vorhanden.
DUBLIN CORE*
EAD <eadheader>
EAD <archdesc>
INHALT (CONTENT)
Abgedeckter räumlicher
<geogname> (geographisch)
und zeitlicher Bereich
<unitdate> (zeitlich)
(Coverage)
Inhaltliche Beschreibung <notestmt><note>
<abstract>
(Description)
126
Typ (Type)
<archdesc> mit dem Attribut LEVEL
Beziehung zu anderen
Ressourcen (Relation)
Quelle (Source)
Thema (Subject)
<notestmt><subject>
<controlaccess><subject>
Titel (Title)
<titleproper>
<unittitle>
GEISTIGES EIGENTUM (INTELLECTUAL PROPERTY)
Verfasser oder Urheber
<author>
<origination><persname>
(Creator)
<origination><corpname>
<origination><famname>
Weitere beteiligte
<author>
Personen und
Körperschaften
(Contributor)
Verleger oder
<publisher>
<repository>
Herausgeber
(Publisher)
Rechteverwaltung
(Rights)
INSTANTIIERUNG (INSTANTIATION)
Datum (Date)
<publicationstmt> <date>
<unitdate>
127
Format (Format)
Identifikation der
<eadid>
<unitid> mit den Attributen
Ressource (Identifier)
COUNTRYCODE und
REPOSITORYCODE
Sprache (Language)
<language>
<archdesc> mit dem Attribut
LANGMATERIAL
*
A.d.Ü.: Deutsche Übersetzung nach: <http://www.mpib-berlin.mpg.de/dok/metatagd.htm>.
Es wäre zweckmäßig, „archivisches Findbuch“ als Ressourcentyp festzulegen, wenn eine nummerierte Typenliste für Dublin
Core erstellt wird.
127
Das Datenformat eines EAD-Findbuchs ist entweder SGML oder XML.
126
249
B.4. Von USMARC zu EAD
Tabelle B.4 enthält nicht alle möglichen USMARC-Felder, mit denen EAD-Elemente
gemappt werden könnten, um eine ausschnitthafte USMARC-Titelaufnahme für
einen Bestand zu erzeugen. Sie konzentriert sich vielmehr auf die wichtigsten und
nützlichsten Felder. USMARC-Felder, die kodierte Daten enthalten, z. B. die Felder
Leader und Directory, sind nicht enthalten, da es unwahrscheinlich ist, dass derartige
Informationen in einem Findbuch in einem solchen Format bereitgestellt werden,
dass es unmittelbar in eine USMARC-Titelaufnahme importiert werden könnte oder
umgekehrt.
Es ist zu beachten, dass dieses Mapping zwischen einem EAD-Findbuch und einer
USMARC-Titelaufnahme, die den Bestand beschreibt, erfolgt. Es ist kein Mapping zu
einer USMARC-Titelaufnahme, die sich auf das Findbuch selbst bezieht.
In der Tabelle sind nur solche MARC-Felder aufgeführt, für die es ein unmittelbares,
logisches Gegenstück zu einem EAD-Element gibt. Hat ein EAD-Element ein
spezifischeres Subelement, das präziser zugeordnet werden kann (wie etwa
<acqinfo> innerhalb von <admininfo>), wird mit dem Subelement gemappt.
In der rechten Spalte (EAD) ist angegeben, wie ein Subelement unter bestimmten
Bedingungen innerhalb eines anderen Elements verwendet werden kann. In anderen
Fällen nennt diese Spalte mehrere mögliche Elemente, wobei es dem Archiv
überlassen ist, zu entscheiden, welches davon sich am besten für die zu
kodierenden Daten eignet.
Es ist äußerst zweckmäßig, die EAD-Daten, die im hochrangigen <did> oder in
anderen Elementen auf <did>-Ebene kodiert sind, z. B. <bioghist>, <scopecontent>
und <controlaccess>, mit den äquivalenten Feldern in USMARC-Titelaufnahmen zu
mappen. Da die Mehrzahl der Archive USMARC-Titelaufnahmen nur auf
„Bestandsebene” erstellt, ist ein Mapping ausgehend von detaillierteren
Komponenten von EAD-Findbücher zwar theoretisch durchführbar, es hat jedoch
wahrscheinlich nur einen geringen praktischen Wert.
Es ist zu beachten, dass EAD-Daten, die mit USMARC-Feldern, für die Normdaten
erforderlich sind gemappt werden, aus kontrolliertem Vokabular stammen müssen,
damit sie in eine gültige USMARC-Titelaufnahme importiert werden können.
250
MARC*
041 Sprachcode (Language)
100 Haupteintragung – Personenname (Main entry –
personal name)
110 Haupteintragung – Körperschaftsname (Main entry –
corporate name)
111 Haupteintragung – Kongressname (Main entry –
meeting name)
130 Haupteintragung – Einheitssachtitel (Main entry –
uniform title)
240 Formalsachtitel/Einheitssachtitel (Uniform title)
245 Sachtitel und Urheberangabe (Title statement)
300 Physische Beschreibung (Physical description)
340 Physisches Medium (Physical medium)
351 Organisation und Klassierung von Materialien
(Organization and arrangement)
500 Allgemeine Fußnote (General note)
506 Fußnote zur Zugangsbeschränkung für Dokumente
(Restrictions on access note)
510 Fußnote zu Zitaten/Referenzen (Citation/references)
520 Zusammenfassung etc. (Summary, etc.)
524 Fußnote zur bevorzugten Zitierform der
beschriebenen Dokumente (Preferred citation of
described materials)
530 Fußnote zu zusätzlich erhältlichen physischen
Publikationsformen (Additional physical form available)
536 Fußnote zur Finanzierung (Funding information)
540 Fußnote über die Bedingungen für die Benutzung
und Vervielfältigung (Terms governing use and
reproduction)
541 Fußnote zur unmittelbaren Beschaffungsquelle
(Immediate source of acquisition)
544 Fußnote zum Standort anderer Archivmaterialien
(Location of other archival materials)
545 Biografische oder geschichtliche Daten (Biographical
or historical data)
555 Fußnote zu Kumulativ-Register und
Rechercheinstrumenten (Cumulative index/finding aids)
561 Besitz- und Verwahrungsrechte (Ownership and
custodial history)
581 Publikationsfußnote über beschriebenes Material
(Publications about described materials)
583 Bearbeitungsvermerk (Action)
584 Zuwachs und Benutzungsfrequenz (Accumulation
and frequency of use)
600 Schlagworteintragung – Personenname (Subject –
personal name)
610 Schlagworteintragung – Körperschaftsname (Subject
– corporate name)
EAD
<archdesc> Attribut LANGMATERIAL
<origination><persname>
<origination><famname>
<origination><corpname>
<origination><corpname>
<unittitle>
<controlaccess><title>
<unittitle>
<physdesc>
<extent>
<physfacet>
<physdesc>
<physfacet>
<dimensions>
<organization>
<arrangement>
<archdesc> Attribut LEVEL
<odd>
<accessrestrict>
<bibliography>
<scopecontent> <abstract>
<prefercite>
<altformavail>
<sponsor>
<userestrict>
<acqinfo>
<separatedmaterial>
<bioghist> <abstract>
128
<custodhist>
<bibliography>
<processinfo>
<accruals>
<controlaccess><persname role="subject">
<controlaccess><famname role="subject">
<controlaccess><corpname role="subject">
*
A.d.Ü. Die Übersetzungen der Felder sind entnommen: Schweizerische Landesbibliothek: MARC21 – Handbuch in deutscher
Sprache, <http://ead.snl.admin.ch/web/marc21/dmarceinl1.htm>.
128
In einer USMARC-Titelaufnahme bedeutet eine Notiz in Feld 555, dass das EAD-kodierte Findbuch vorhanden ist, diesem
Feld jedoch kein bestimmtes EAD-Element entspricht.
251
611 Schlagworteintragung – Kongressname (Subject—
meeting)
630 Schlagworteintragung – Einheitssachtitel (Subject –
uniform title)
650 Schlagworteintragung – Sachschlagwort (Subject —
topical)
651 Schlagworteintragung – Geografischer Name
(Subject—geographic name)
655 Indexierungsbegriff – Genre/Form (Genre/form)
656 Indexierungsbegriff – Beruf (Occupation)
657 Indexierungsbegriff – Funktion (Function)
69x Indexierungsbegriff – Lokales Schlagwort (Local
subject access)
700 Nebeneintragung – Personenname (Added entry—
personal name)
710 Nebeneintragung – Körperschaftsname (Added
entry—corporate name)
711 Nebeneintragung – Kongressname (Added entry—
meeting name)
720 Nebeneintragung – Unkontrollierter Name (Added
entry—uncontrolled)
730 Nebeneintragung – Einheitssachtitel (Added entry-uniform title)
740 Nebeneintragung – nicht kontrollierter/analytischer
Titel (Added entry – uncont./related anal. title)
752 Nebeneintragung – Hierarchischer Ortsname (Added
entry – hierarchical place name)
852 Standort (Location)
<controlaccess><corpname role="subject">
<controlaccess><title role="subject">
<controlaccess><subject>
<controlaccess><geogname
role="subject">
<controlaccess><genreform>
<controlaccess><occupation>
<controlaccess><function>
<controlaccess><subject source="local">
<controlaccess><persname>
<controlaccess><famname>
<controlaccess><corpname>
<controlaccess><corpname>
<name>
<controlaccess><title>
<title>
<geogname>
<repository> <physloc>
252
Anhang C: Häufig gestellte Fragen
Die Antworten auf diese häufig gestellten Fragen sind bewusst kurz gehalten, da
weitere Informationen im gesamten Anwenderleitfaden enthalten sind. Bei Bedarf
können Sie in den angegebenen Abschnitten nachschlagen.
1. Warum wurde EAD in SGML geschrieben, und warum sollten Archive EAD
und nicht HTML verwenden, um die Findbücher über das World Wide Web zu
verbreiten?
Wie in Abschnitt 1.4 erläutert, ermöglicht es SGML, die Struktur und den
intellektuellen Inhalt von Dokumenten vollständig in einer nichtproprietären
Softwareumgebung zu kodieren. Als SGML-Dokumenttyp-Definition hat auch EAD
diese Eigenschaften. Außerdem unterstützt der inhärent hierarchische
Datenstrukturansatz von SGML die Informationshierarchien, die seit Langem ein
grundlegender Bestandteil der archivischen Erschließung sind. Daher ist die
Anwendung von EAD, das speziell zur Kodierung von archivischen Findbüchern
gemäß den Regeln von SGML geschrieben wurde, eine lohnende Investition für die
Findbuchdaten eines Archivs. Es werden dadurch nicht nur hochentwickelte
Recherche-, Darstellungs- und Navigationsverfahren ermöglicht, sondern es wird
auch die Bedeutung von Struktur und Inhalt der Findbuchdaten in vollem Umfang
wiedergegeben.
HTML ermöglicht demgegenüber nur die Kodierung von Merkmalen der visuellen
Präsentation, z. B. Schriftgrad, Fettdruck, Kursivdruck und Zeilenumbruch. Struktur
und Inhalt eines Findbuchs können nicht genutzt werden, wenn HTML zur Kodierung
verwendet wird. Die künftige Datenmigration wird nicht erleichtert, da die Bedeutung
von Datenelementen und ihre strukturellen Beziehungen nicht bewahrt werden.
Dadurch erhöht sich die Wahrscheinlichkeit, dass Daten – wenn eine Migration in
eine neue Softwareumgebung erforderlich wird – manuell neu formatiert oder
konfiguriert werden müssen. Weitere Angaben siehe Abschnitt 1.3.
2. Welchen Vorteil hat die Anwendung von EAD auf ein Findbuch gegenüber
der Erstellung einer lokalen Datenbankstruktur?
EAD bietet einen standardisierten Satz von Datenelementen für Findbücher, der von
Archivaren entwickelt wurde, die sich auf archivische Erschließung spezialisiert
haben. Die Entwickler von EAD haben dieses Verfahren unter Berücksichtigung von
Rückmeldungen ihrer Kollegen der USA sowie mehreren anderen Ländern
weiterentwickelt. EAD ist weit verbreitet und in dem Maße, wie Archivare
Erfahrungen mit EAD sammeln, wird sich die Anwendung von EAD vereinheitlichen
und es werden Softwareprodukte entwickelt werden, die die Implementierung leichter
und kostengünstiger gestalten. Was vielleicht am wichtigsten ist: es ist zu erwarten,
dass die Kenntnisse der Benutzer über archivische Erschließungsdaten zunehmen,
da immer mehr Archive die gleichen Kodierstrukturen und -regeln für die Erstellung
ihrer Bestandsfindbücher und deren weltweite Verbreitung über das World Wide Web
anwenden.
Vor der Entwicklung von EAD setzten bereits viele Archive selbstentwickelte
Software für relationale Datenbanken ein, um Findbücher für komplexe Bestände zu
erstellen und die leistungsfähigen Suchfunktionen und sich die Möglichkeiten einer
253
mühelosen Indexierung und Datenaktualisierung zunutze zu machen. Unabhängig
davon, welchen Wert solche internen Datenbanken für die einzelnen Archive gehabt
haben, fehlt ihnen doch die standardisierte Datenstruktur und die
Plattformunabhängkeit, die bei der Anwendung von EAD gewährleistet ist und die für
übergreifende Recherchen in den Findbüchern mehrerer Archive von wesentlicher
Bedeutung ist.
Die Anwendung von EAD schließt jedoch die Verwendung von Datenbanksoftware
für lokale Datenerfassung und –speicherung nicht aus. Archive, die bereits
Findbücher mit Software wie Access oder dBase erstellen, möchten u. U. ermitteln,
inwieweit ihre Datenbankfelder mit EAD-Elementen übereinstimmen, um dann die
notwendigen Änderungen zur Herstellung einer Kompatibilität durchzuführen und die
Fachkenntnisse eines Programmierers zu nutzen, um ein Umwandlungsskript zu
entwickeln, mit dem die Datenbankfelder EAD-Elementen zugeordnet werden
können (siehe Abschnitt 4.2.4). EAD kann dann die Grundlage für die Bereitstellung
der Findbücher für Nutzer dienen, wie es in Kapitel 5 beschrieben ist.
3. Warum war EAD erforderlich, obwohl das Kodierschema TEI (Text Encoding
Initiative) bereits zur Verfügung stand?
Wie in Abschnitt 1.4 erläutert, ist die TEI-Datenstruktur darauf ausgelegt, literarische
und wissenschaftliche Texte zu kodieren. TEI hat bereits große Akzeptanz im
Bereich der Geisteswissenschaften gefunden, umfasst indessen nicht viele der
speziellen Elemente, die in archivischen Findbüchern vorkommen, und hätte daher
die archivfachlichen Anforderungen nicht ausreichend abgedeckt. Andererseits ist
TEI aber ein ausgezeichnetes Kodierschema für Archive, die digitalisierte Versionen
wissenschaftlicher Texte kodieren möchten, die dann bei Bedarf mit EAD-kodierten
Findbüchern verknüpft werden können.
4. Wenn EAD angewandt wird, müssen dann trotzdem noch MARCTitelaufnahmen erstellt werden?
Abschnitt 1.6 bringt die Erstellung von MARC-Titelaufnahmen mit EAD in
Zusammenhang. Zum gegenwärtigen Zeitpunkt der EAD-Entwicklung bilden MARCTitelaufnahmen wichtige Metadaten für Navigationszwecke, da sie den Zugang zu
kodierten Findbüchern aus vorhandenen bibliografischen und anderen Systemen
leicht und zielgerichtet gestalten. Viele Benutzer beginnen ihre Quellenrecherche in
einem Online-Bibliothekskatalog, und es ist äußerst wichtig, archivische
Kurzinformationen in solchen integrierten bibliografischen Systemen vorzuhalten, um
diese Benutzer zu EAD-kodierten Findbüchern und dem darin beschriebenen
Archivgut hinzuführen.
5. Welche Beziehung besteht zwischen EAD und ISAD(G)?
ISAD(G) ist ein internationaler Standard, der einen Rahmen für die mehrstufige
archivische Verzeichnung bietet und als solide Grundlage zur Festlegung „erprobter
Arbeitsverfahren“ für die EAD-Kodierung von Findbüchern dienen kann. EAD ist ein
viel detaillierterer und spezifischerer Datenstrukturstandard, der unter
Berücksichtigung von ISAD(G) entwickelt wurde und daher auch mit ISAD(G)
kompatibel ist. Weitere Angaben siehe Abschnitt 1.2.
254
6. Wie gelingt der Einstieg in die EAD-Anwendung?
Kapitel 2 umreißt verschiedene verwaltungstechnische Fragen, die berücksichtigt
werden müssen, wenn die EAD-Anwendung in Betracht gezogen wird. Als
Ergänzung zu Kapitel 2 hilft die Prüfliste für die Implementierung in Anhang D bei
Entscheidungen hinsichtlich vieler organisatorischer Faktoren, die bei der Planung zu
berücksichtigen sind.
Die meisten Archive, die EAD anwenden wollen, sehen sich vor zwei
unterschiedliche Formen der Implementierungstätigkeit gestellt: die Erstellung neuer
und die Retrokonversion vorhandener Findmittel. Jede Implementierungsart bringt
ihre eigenen Herausforderungen mit sich. Obwohl man es gar nicht erwartet, ist die
Erstellung neuer Findbücher leichter als das Retrokonversion vorhandener. Der
Grund liegt darin, dass man – nachdem man die Datenstruktur von EAD verstanden
hat – bei der Neuerstellung überdenken kann, wie der Findbuchinhalt strukturiert
werden kann. Weitere Angaben siehe Abschnitte 2.5.3 und 2.5.4.
7. Welche Rechnerhard- und -software benötigt ein Archiv, um EAD
anzuwenden?
Weil EAD auf der plattformunabhängigen Metasprache SGML beruht, haben
Anwender hinsichtlich der Soft- und Hardware eine große Auswahl. Eine bestimmte
Umgebung wird nicht benötigt. Um Findbücher selbst kodieren zu können, benötigt
ein Archiv zumindest einen PC und eine geeignete Software zum Einfügen von EADTags in Findbuchdokumente. Wenn ein Archiv kodierte Findbücher im World Wide
Web verbreiten oder seine Findbücher in eine Verbund-Datenbank hochladen
möchte, benötigt es Netzanschluß und die Funktion, Daten in das Internet zu
übertragen. Wie es bei der meisten Hard- und Software der Fall ist, kann man um so
leistungsfähigere System anschaffen, je mehr Geld zur Verfügung steht. Eine
Implementierung von EAD ist jedoch schon mit minimalen Investitionen in Hard- und
Software möglich. In Kapitel 4 sind verschiedene Strategien für die Auswahl von
Authoring-Software beschrieben, und Kapitel 5 beschreibt mehrere Verfahren zum
Einstellen von Findbüchern in das Web.
8. Welche lokalen EAD-Konventionen muss ein Archiv voraussichtlich
entwickeln?
Wie in Abschnitt 3.3 beschrieben, wird empfohlen, dass jedes Archiv seine
vorhandenen Erschließungsverfahren auf grundsätzliche Übereinstimmung und
Kompatibilität mit EAD prüft, bevor es mit der Kodierung beginnt. Nach dieser
Analyse kann ein Archiv entscheiden, welche EAD-Elemente und -Attribute sich am
besten für die eigenen Erschließungsverfahren eignen, in welcher Reihenfolge die
Elemente für die Darstellung eines Findbuchs stehen müssen und welche
Formatierungsmerkmale in ein Stylesheet aufzunehmen sind, um Benutzern
übersichtliche und konsistente Findbücher zur Verfügung zu stellen. Insbesondere im
Rahmen von institutionenübergreifenden Gemeinschaftsprojekten ist es besonders
wichtig, diese Konventionen zu entwickeln.
255
Außerdem müssen Archive, die MARC-Titelaufnahmen erstellen, u. U.
Entscheidungen darüber treffen, wie für eine Kompatibilität zwischen MARCTitelaufnahmen und EAD-Findbüchern gesorgt werden kann und wie bisherige
Arbeitsabläufe geändert werden müssen, um Doppelarbeit zu vermeiden. Weitere
Angaben finden sich in Abschnitt 1.6.
9. Welche Schulungsmaßnahmen benötigen Archivmitarbeiter für die
Anwendung von EAD, und wo finden diese statt?
Die erforderliche Schulung richtet sich nach den Aufgaben, die Mitarbeiter im
Einzelnen wahrzunehmen haben. Mitarbeiter, die ermitteln sollen, welche EAD-Tags
in Findbüchern zu verwenden sind, müssen mit der EAD-Tag-Library und mit
Kapitel 3 des Anwenderleitfadens sehr gut vertraut sein. Seit 1998 bietet die Society
of American Archivists EAD-Workshops an. Dies tut auch die University of Virginia im
Rahmen ihres jeweils im Sommer stattfindenden Rare Book School Program.
Verbünde (darunter auch die Research Libraries Group) unterstützen oft Workshops
finanziell, um die Beteiligten zu Beginn eines EAD-Projekts zu schulen.
Mitarbeiter, die eine bestimmte Software zum Einfügen von EAD-Tags anwenden
sollen, benötigen natürlich eine Schulung in dem vom Archiv gewählten Programm.
Systemspezialisten müssen sich gründliche Kenntnisse über SMGL-Dateien und
-Systeme aneignen. Einige diesbezügliche Informationen sind in den Kapiteln 6 und
7 des Anwenderleitfadens enthalten.
Weitere Informationen siehe Abschnitte 1.7.3 und 2.5.2.
10. Wie lassen sich von Anfang an EAD-kodierte Findbücher einfach erstellen?
Die Antwort auf diese Frage richtet sich nach verschiedenen Faktoren, darunter den
vorhandenden Fachkenntnissen der Archivare, den derzeit zur Erstellung von
Findbüchern angewandten Verfahren, der vorhandenen IT-Ausstattung und den zur
Beschaffung der Software verfügbaren Geldmitteln. Verschiedene Möglichkeiten für
das „Authoring“ von EAD-Findbüchern (d. h., für den Einsatz von Software zur
Anwendung der EAD-Kodierung auf Findbücher) werden in Abschnitt 4.2 vorgestellt.
11. Welche Überlegungen müssen bei der Umwandlung vorhandener
Findbücher nach EAD angestellt werden?
Abschnitt 2.5.4 erläutert die Umwandlung vorhandener Findbücher, die häufig als
„Altdaten“ bezeichnet werden. Die Darstellung behandelt drei Hauptthemen:
Priorisierung vorhandener Findbücher, Überarbeitungsstrategien und
Retrokonversionsverfahren.
12. Wie sollten Archive vorhandene Findbücher für die Retrokonversion
priorisieren?
Wie in Abschnitt 2.5.4.1 beschrieben, muss jedes Archiv mehrere Voraussetzungen
prüfen und eigene Entscheidungen hinsichtlich der Priorisierung treffen. Die
Entscheidungsfindung kann darauf ausgerichtet sein, eine Balance zwischen zwei
256
Kernfragen zu finden: Welche Findbücher sind am wichtigsten und welche sind am
einfachsten und schnellsten umzuwandeln?
13. Kann EAD dazu dienen, dreidimensionale Materialien wie z. B. Museumsgut
zu beschreiben?
Natürlich kann es das. Wie in Unterabschnitt 3.5.2.3 erläutert, bietet EAD die
Möglichkeit zur Verzeichnung von Materialien auf Einzelstückebene, und zwar in
jeder vom Archiv für erforderlich befundenen Detailtiefe. Dies wurde frühzeitig von
einer Reihe von EAD-Implementierern erfolgreich durchgeführt.
14. Wie sollten Archive die Integrität ihrer kodierten Findbücher sicherstellen?
Abschnitt 4.4 beschreibt fünf Arten der „Integrität“, die zu berücksichtigen sind:
einheitliche Kodierung, DTD-Konformität, Dateinamen und -speicherstellen,
Versionskontrolle und Sicherheit. Die meisten dürften aufgrund der Erfahrungen mit
Erschließungsstandards und mit der Administration von Online-Systemen vertraut
sein.
15. Wie können Archive kodierte Findbücher ihren Nutzern zur Verfügung
stellen?
Kapitel 5 beschreibt verschiedene Szenarien für die „Veröffentlichung“ von EADFindbüchern, bzw. die Bereitstellung für die Benutzung. Die Möglichkeiten reichen
von einfachen und preiswerten bis zu komplexen und kostenintensiven Verfahren.
EAD-Findbücher können natürlich nicht nur online gestellt, sondern auch
ausgedruckt werden.
16. Welche Beziehung besteht zwischen EAD und den Bestrebungen zur
Einrichtung digitaler Archive und Bibliotheken?
Es ist zu erwarten, dass die Entwicklung großer Datenbanken von EAD-kodierten
Findbüchern, in denen Bestände zahlreicher Archive erfasst sind, und die
Verbreitung dieser Findbücher in vernetzten Systemen wie dem World Wide Web
allmählich dazu führt, dass sich eine kritische Masse von breit zugänglichen
archivischen Erschließungsdaten ansammelt. Hier werden die kodierten Findbücher
eine schlüssige intellektuelle Struktur bilden, wobei digitale Kopien historischer
Originalmaterialien oder „digitale Archivobjekte“ mit den Findbüchern verknüpft
werden können, in denen sie beschrieben sind. In einigen Umgebungen werden
auch Links von kodierten Findbüchern zu MARC-Titelaufnahmen erstellt werden, mit
denen Archivbestände auf einer zusammenfassenden Ebene beschrieben werden.
Auf diese Weise werden Benutzer von MARC-Titelaufnahmen zu kodierten
Findbüchern und von dort zu Digitalisaten von Archivgut navigieren können. Weitere
Szenarien, wie Benutzer Einstieg in kodierte Findbücher finden können, sind in
Kapitel 5 beschrieben.
17. Wo erhalten Archivare aktuelle Informationen zu Software, Werkzeugen,
Projekten und sonstigen neuen Entwicklungen zu EAD?
Es gibt im Wesentlichen drei Online-Fundstellen für derartige Informationen:
257
Die Encoded Archival Description Official Web Site, die vom Network Development
and MARC Standards Office of the Library of Congress gepflegt wird, ist die offizielle
Veröffentlichungsstelle für EAD-Dokumenttyp-Definitionsdateien. Diese Seite liefert
auch Hintergrundinformationen über die Entwicklung von EAD, Hinweise zur
Anmeldung am EAD-Listserv und Beschreibungen (mit Links) von zahlreichen EADImplementierungsseiten, darunter einige der wichtigsten Gemeinschaftsprojekte.
URL: <http://www.loc.gov/ead/>.
Die EAD-Hilfeseiten, die vom EAD Roundtable of the Society of American Archivists
betreut werden, enthalten viele nützliche Informationen und Links zu hilfreichen
Seiten. Angeboten werden Links zu (sowohl kommerziellen als auch von EADImplementierern kostenlos zur Verfügung gestellten) Werkzeugen und Hilfedateien,
Beschreibungen der Authoring- und Veröffentlichungs-Software, die von
verschiedenen EAD-Implementierungsseiten eingesetzt wird, Links zu nützlicher
Lektüre über SGML und XML sowie eine Hilfe-Einrichtung, in die Anwender
bestimmte Fragen eingeben können. Die Archivare werden aufgefordert, sich am
EAD Roundtable zu beteiligen und Beiträge zur Webseite zu liefern. URL:
<http://www.archivists.org/saagroups/ead/>.
Der EAD Listserv ist ein interaktives Forum, in dem Anwender das Neueste über
EAD erfahren und Fachleute um Rat fragen können. Hinweise zur Anmeldung finden
sich auf: <http://www.loc.gov/ead/eadlist.html>.
Weitere gut gepflegte Webseiten, die sich besonders mit EAD-, SGML- und XMLAnwendungen befassen, sind in der Bibliographie in Anhang G aufgeführt.
258
Anhang D: Prüfliste für die Implementierung
Die meisten Archive sehen sich beim Implementieren von EAD vor einen Prozess mit
mehreren Arbeitsgängen gestellt:
•
•
•
Retrokonversion alter Findbücher,
Erstellung neuer Findbücher,
Verbreitung der Findbücher im Web.
Jeder Arbeitsgang bringt besondere Herausforderungen mit sich, und wie bereits
ausführlicher in den Kapiteln 2, 4 und 5 erläutert, steht eine breite Palette von
Optionen zur Verfügung. Die folgende Prüliste soll bei Überlegungen unterstützen, in
welchem Rahmen EAD in seinem Archiv einsetzbar ist.129
1. Beurteilung der Rolle, die die Findbücher z. Z. bei der Benutzung und Recherche
spielen.
a. Wie werden die Findbücher z. Z. genutzt?
•
•
•
•
•
•
•
Wer nutzt sie?
Unter welchen Bedingungen werden sie genutzt?
Welche dieser Bedingungen spiegelt die höchste(n) Ebene(n) der Nutzung
wider?
Nach welcher Art von Daten wird am häufigsten in den Findbüchern gesucht?
Welche Arten von Anfragen können mit Hilfe der Findbücher effektiv
beantwortet werden und welche nicht?
Würden Online-Findbücher die derzeitige Effektivität beibehalten oder
möglicherweise sogar Verbesserungen in Bereichen bewirken, in denen die
Findbücher nicht so effektiv sind?
Würden Online-Findbücher neue Zielgruppen für die Findbücher erschließen?
b. In welchem Zustand befinden sich die Findbücher derzeit?
•
•
•
•
•
•
In welchem physischem Format liegen die Findbücher vor?
Wie vollständig sind sie? Wie groß ist das Vertrauen in die Richtigkeit der in
ihnen enthaltenen Informationen?
Wie einheitlich sind die Strukturkomponenten der Findbücher und die in ihnen
enthaltenen Daten? Wie deutlich sind die Komponenten gekennzeichnet?
Welche Richtlinien wurden bei der Erstellung der Findbücher zu Grunde
gelegt?
Wie viele Findbücher sollen sofort oder später auf EAD umgestellt werden?
Wie viele Seiten Text haben sie?
In welchen Zeitabständen werden z. Z. neue Findbücher erstellt?
c. Erstellt das betreffende Archiv z. Z. MARC-Titelaufnahmen, und falls ja, in
welcher Beziehung stehen diese zu den Findbüchern?
129
Diese Prüfliste beruht auf einer älteren Fassung, die von Helena Zinkham zur Verwendung in der Library of Congress Prints
and Photographs Division im Mai 1996 erstellt wurde.
259
2. Wie soll die Retrokonversion vorhandener Findbücher durchgeführt werden?
a. Wie soll die Retrokonversion vorhandener Findbücher priorisiert werden?
•
•
•
•
•
•
die wichtigsten Bestände
die am häufigsten (oder am seltensten) genutzten Bestände
Findbücher, die „am leichtesten“ umzuwandeln sind (die am wenigsten
überarbeitet werden müssen)
Findbücher, die effektiver genutzt werden könnten, wenn sie online verfügbar
wären
Bestände, die auf mehrere Archive verteilt sind, für die ein „virtuelles
Findbuch“ erstellt werden könnte
Bestände, die mit digitalen, online verfügbaren Materialien im Zusammenhang
stehen
b. Welche(s) Verfahren soll(en) bei der Retrokonversion angewendet werden?
•
•
•
Retrokonversion im eigenen Haus
Fremdvergabe an einen Dienstleister
Beteiligung an einem Gemeinschaftsprojekt, das über einen
Retrokonversionsdienst verfügt
3. Auf welche Weise soll Nutzern der Einstieg in die Findbücher ermöglicht werden?
a. Über Links von einem Web-gestützten Online-Katalog
b. durch Suche im Internet mittels Alta Vista oder Yahoo!
c. durch direkten Aufruf der Webseite der betreffenden Institution und
Durchsuchen der Findbücher
d. mit Hilfe einer Suchmaschine auf der Webseite der Institution
4. Welche Mittel werden benötigt, um EAD-kodierte Findbücher zu erstellen und im
Web zu veröffentlichen?
a. Welche Art und wie viel Personal wird benötigt?
b. Wie muss das Personal geschult werden?
c. Welche technische Unterstützung wird benötigt? Falls keine Unterstützung
innerhalb des Archivs zur Verfügung steht: gibt es innerhalb der
übergeordneten Institution eine Organisationseinheit, die Fachkenntnisse zur
Verfügung stellen kann, oder ist der Beitritt zu einem Verbund möglich, der
bereits SGML-/XML-Anwendungen nutzt? Besteht die Möglichkeit einer
gemeinsamen Systementwicklung oder der gemeinsamen Nutzung von
Ressourcen und Fachkenntnissen?
260
d. Welche Dokumente müssen beschafft werden und in welcher Zahl?
•
•
•
•
EAD-DTD-Dateien oder eigens kompilierte Versionen der DTD für bestimmte
Softwareanwendungen (Datei .rls für Author/Editor, Datei .lgc für WordPerfect)
EAD-Tag-Library
EAD-Anwenderleitfaden
Kodierungsrichtlinien für Tätigkeiten im Verbund
e. Welche lokalen Konventionen müssen entwickelt werden?
•
•
•
•
Standardformat, das bei allen Findbüchern eingehalten werden soll
standardmäßige Eingabe von Daten in spezifische Elemente
Stylesheets zur Steuerung der Darstellung der Findbücher
vorgeschriebene Formen für Einstiegsbegriffe, die durch StandardAnsetzungslisten nicht abgedeckt sind
f. Welche Art von Software wird zur Erstellung und für die Veröffentlichung neu
kodierter Findbücher benötigt? (Keine Institution benötigt sämtliche hier
aufgeführte Software):
• SGML-/XML-Authoring-Paket
• Textverarbeitungssoftware mit SGML-/XML-Funktionalitäten oder
nachrüstbaren Zusatzprogrammen für die Umwandlung
• Datenbank
• SGML-/HTML-Konverter oder HTML-Authoring-Werkzeug
• Umwandlungswerkzeuge wie Perl-Skripte oder Makros
• SGML-/XML-Syntaxanalysator
• SGML-/XML-Browser
• Software für das Authoring von Stylesheets
• Suchmaschine
g. Welche Hardware wird für Erstellung und Veröffentlichung der Findbücher
benötigt:
•
•
•
•
•
•
PC-Arbeitsplatz
Anschluss an das lokale Netzwerk
Internet-Zugang
Sicherheitseinrichtung
Server
Drucker
h. Wie soll die Qualitätskontrolle durchgeführt werden?
i. Wie sollen die kodierten Findbücher gepflegt und aktualisiert werden?
j. Wie soll die Serverwartung und –fehlerbehebung durchgeführt werden?
261
5. Kostenanalyse im Zusammenhang mit den o. g. Prozessen:
a. Welche Kosten können im Rahmen der vorhandenen Haushaltsmittel
abgedeckt werden?
b. Welche Kosten schaffen neue Ausgabenbereiche? Welche Kosten
entstehen nur einmal, welche sind laufend?
c. Welche Kosten werden im Laufe der Zeit abnehmen, welche werden
zunehmen?
d. Welche Kosten könnten durch externe Finanzierung (z. B. Drittmittel)
gedeckt werden?
e. Gibt es versteckte Kosten, die noch weiter geprüft werden müssen?
f. Besteht die Möglichkeit, dass es aufgrund der EAD-Implementierung in
anderen Bereichen zu Kosteneinsparungen kommt?
262
Anhang E: Beispiele
Jedes Archiv, das EAD implementiert, muss überlegen, wie es die Vielzahl der
verfügbaren EAD-Elemente zur Kodierung von Erschließungsinformationen zu
seinen Beständen nutzen will. Diese Entscheidungen werden aufgrund
verschiedener Faktoren getroffen, z. B. der z. Z. angewendeten
Erschließungsverfahren und der Art von Informationen, die normalerweise zu
Beständen erfasst werden, nationale oder formatbezogene Standards (z. B. RAD,
APPM oder Graphic Materials) und internationale Standards wie ISAD(G).
Im Anwenderleitfaden wird hervorgehoben, wie wichtig Einheitlichkeit und
Konsequenz bei der Wahl der grundsätzlich in den Findbüchern zu verwendenden
EAD-Tags als auch für den Dateninhalt für diese Tags sind. Alle drei Findbücher des
Anhangs enthalten das in Anhang A empfohlene Grundgerüst an
Findbuchelementen. Sie werden feststellen, wie vorteilhaft es ist, zu Beginn des
Kodierungsprojekts Entscheidungen über die mindestens zu verwendenden
Datenkomponenten und über die Konsistenz des Inhalts dieser Komponenten zu
treffen, um künftige Änderungen an den Daten zu erleichtern und eine größere
Flexibilität bei der Bereitstellung der Daten für Nutzer zu gewinnen.
Beispiel 1
Beispiel 1 beschreibt einen Bestand persönlicher Unterlagen auf Bestands-, Serien/Teilserien-, Akten- und (in einigen Fällen) Einzelstückebene. Dabei wird, um den
hierarchischen Aufbau dieser Erschließungsinformationen hervorzuheben, das
„kombinierte” <dsc>-Verfahren verwendet. Auf Aktenebene werden geschachtelte
Komponenten zur Erleichterung der Eingabe verwendet, und im gesamten Beispiel
dient das Attribut LEVEL dazu, eindeutig zu dokumentieren, wie die geschachtelten
Komponenten auf den einzelnen Ebenen „zueinander gehören“. In diesem Beispiel
werden auch Behälterinformationen (Kisten- und Ordnernummern) innerhalb jeder
einzelnen <c0x>-Komponente unterhalb der Serien-/Teilserienebene kodiert. Die
meisten Archive treffen ihre Entscheidungen zur Kodierung von
Behälterinformationen auf der Grundlage der Parameter des Systems, mit dem sie
ihre kodierten Findbücher Nutzern zur Verfügung stellen.
Hinsichtlich der Verwendung von Werten für das Attribut LABEL und <head>-Tags
sowie hinsichtlich der Daten in <eadheader> und <frontmatter> richtet sich dieses
Beispiel von der University of California in Irvine nach dem Dokument Encoded
Archival Description Retrospective Conversion Guidelines130, das vom Online Archive
of California angewendet wird. Bei ihren Entscheidungen über die Verwendung von
LABEL und <head> richten sich die Archive was die Bereitstellung von Informationen
betrifft nach den Möglichkeiten der lokalen Datenbanken, Verbund-Datenbanken und
Stylesheets.
Die Verarbeitungsanweisung <?filetitle>, die in diesem Beispiel direkt vor dem
<ead>-Start-Tag steht, dient dazu, an Nutzerschnittstellen des Online Archive of
California und der California Digital Library standardisierte, alphabetisierte
Ergebnislisten zu liefern.
130
Internetadresse: <http://sunsite.berkeley.edu/amher/upguide.html>.
263
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD ead.dtd
(Encoded Archival Description (EAD) Version 1.0)//EN" [
<!ENTITY hdr-cu-i-spcoll PUBLIC "-//University of California,
Irvine::Library::Dept. of Special Collections//TEXT (eadheader: name and
address)//EN" "hdrcuisp.sgm" --hdrcuisp.sgm-->
<!ENTITY tp-cu-i-spcoll PUBLIC "-//University of California,
Irvine::Library::Dept. of Special Collections//TEXT (Titelseite: Name und
Adresse)//EN" "tpcuisp.sgm" --tpcuisp.sgm-->
<!ENTITY ucseal PUBLIC "-//University of California,
Berkeley::Library//NONSGML (Siegel der University of California)//EN" ""
NDATA gif>
]>
<?filetitle Phelps (Edna) Collection>
<ead>
<eadheader langencoding="ISO 639-2" audience="internal">
<eadid type="SGML catalog">PUBLIC "-//University of California,
Irvine::Library::Dept. of Special Collections//TEXT (US::CU-I::MS-R43::Edna
Phelps Collection)//EN" "r43.sgm"</eadid>
<filedesc>
<titlestmt>
<titleproper>Findbuch zum Edna-Phelps-Bestand, <date>ca. 1810-1981 (größter
Teil ca. 1880-ca. 1910)</date></titleproper>
<author>Bearbeitet von Lynette Stoudt. Maschinenlesbares Findbuch erstellt
von William Landis</author></titlestmt>
<publicationstmt>
&hdr-cu-i-spcoll;
<date>© 1999</date>
<p>Die Regenten der University of California. Alle Rechte vorbehalten.
</p>
</publicationstmt>
</filedesc>
<profiledesc>
<creation>Maschinenlesbares Findbuch, erzeugt mit MS Word. Datum der
Erstellung: <date>Februar 1999.</date></creation>
<langusage>Erschließung in <language>Englisch.</language>
</langusage>
</profiledesc>
</eadheader>
<frontmatter>
<titlepage>
<titleproper>Findbuch zum Edna-Phelps-Bestand</titleproper>
<num>Bestandssignatur: MS-R43</num>
<publisher>Department of Special Collections
<lb>The UCI Libraries
<lb>University of California
<lb>Irvine, California</publisher>
&tp-cu-i-spcoll;
<list type="deflist">
<defitem>
<label>Bearbeitet von: </label>
<item>Lynette Stoudt</item></defitem>
<defitem>
<label>Datum der Fertigstellung: </label>
<item>Februar 1999</item></defitem>
<defitem>
<label>Kodiert von: </label>
<item>William Landis</item></defitem>
</list>
<p>© 1999 Die Regenten der University of California. Alle Rechte
vorbehalten.</p>
</titlepage>
</frontmatter>
<archdesc level="collection" langmaterial="eng">
264
<did>
<head>Zusammenfassung</head>
<unittitle label="Titel">Findbuch zum Edna-Phelps-Bestand,
<unitdate type="inclusive">ca. 1810-1981 </unitdate>
<unitdate type="bulk">(größter Teil ca. 1880-ca. 1910)</unitdate>
</unittitle>
<unitid label="Bestandssignatur" countrycode="US" repositorycode="CUI">MSR43</unitid>
<origination label="Provenienz">
<persname>Phelps, Edna W.</persname></origination>
<physdesc label="Umfang">
<extent>Anzahl der Behälter: 5 Dokumentekisten, 1 Ordner in
Übergröße.</extent>
<extent>lfm: 0,6</extent></physdesc>
<repository label="Archiv">
<corpname>University of California, Irvine. Library. Dept. of Special
Collections.</corpname>
<address>
<addressline>Irvine, California 92623-9557</addressline></address>
</repository>
<abstract label="Zusammenfassung">
Dieser Bestand enthält Fotografien, Briefe, Tagebücher und
Familiendokumente, die die Geschichte von mindestens vier Generationen der
Familien Phelps, Gulick, Davidson, Humiston, Gooch, Huntley, Schultz,
Willson und Turner aus den Jahren 1847-1978 dokumentieren. Der größte Teil
des Bestandes betrifft die Familie Gulick, ca. 1880-ca. 1920. Zum Bestand
gehören auch Sachakten und personenbezogene Akten von verschiedenen anderen
Familien und Orten in Tustin und Umgebung, ca. 1810-ca. 1981.
</abstract>
</did>
<admininfo>
<head>Verwaltungstechnische Informationen</head>
<accessrestrict>
<head>Zugänglichkeit</head>
<p>Der Bestand ist benutzbar.</p></accessrestrict>
<userestrict>
<head>Eigentumsrechte</head>
<p>Eigentumsrechte liegen bei der University of California. Die
literarischen Rechte bleiben bei den Nachlassern der Unterlagen und ihren
Erben. Genehmigung zur Reproduktion oder Veröffentlichung ist einzuholen
bei: Head of Special Collections and University Archives.
</p></userestrict>
<prefercite>
<head>Bevorzugte Zitierweise</head>
<p>Edna Phelps Collection. MS-R43. Department of Special Collections, The
UCI Libraries, Irvine, California.</p></prefercite>
<acqinfo>
<head>Informationen zur Übernahme</head>
<p>Schenkungen von Edna Phelps in den Jahren 1971, 1981 und
1984.</p></acqinfo>
<processinfo>
<head>Bearbeitungsinformationen</head>
<p>Vorläufige Ordnung einschließlich konservatorischer Maßnahmen, der
Erstellung von Fotokopien und des Aussonderns von Originaldokumenten
(Fotokopien und Zeitungsausschnitten) durch Laura Clark Brown 1997.
Bearbeitet von Lynette Stoudt, Februar 1999.</p></processinfo>
</admininfo>
<bioghist>
<head>Biografie</head>
<p>Edna Phelps sammelte Familienfotos, Briefe, Tagebücher und
Familienunterlagen, die bis zu vier Generationen auf ihre Vorfahren in
Plainview, Illinois, zurückgehen. Sie sammelte auch Materialien zur
Geschichte von Tustin und Umgebung aus der Zeit von ca. 1810-1981.</p>
265
<p>Neben dieser Sammeltätigkeit gab Edna Phelps Familientagebücher und schriften heraus und verfasste eine kurze Abhandlung, die zum Bestand
gehört und den Titel trägt: "One by One the Gulicks Came West". Edna führte
auch Interviews zur frühen Geschichte von Südkalifornien mit William
Huntley (ihrem entfernten Vetter) und George Bartley, dessen Familie sich
1882 in El Modena, Kalifornien, ansiedelte. 1968-1969 gab sie ein
unveröffentlichtes Werk von Helen Gulick Huntley und William M. Huntley
(entfernte Vettern von Edna) heraus, das den Titel "Tustin Scrapbook" trägt
und sich in der California State Library befindet.</p>
<p>Außer ihrer Faszination für die Familiengeschichte und die Geschichte
von Orange County ist nur wenig über Edna Phelps bekannt. Sie ist die
Urenkelin von Martin Nickolas Gulick, dem frühesten in diesem Bestand
erwähnten Mitglied ihrer Familie.</p>
<p>Martin Nickolas Gulick (1815-1900) war dreimal verheiratet. Seine erste
Hochzeit fand 1841 mit Eleanor Welch (Edna Phelps Urgroßmutter) statt. Mit
ihr hatte er drei Kinder: Mary Jane (Edna Phelps Großmutter), James Harvey
und Eleanor Matilda. Die kurze Ehe endete 1848 mit dem Tode von Eleanor
Welch Gulick. Zu den Familiennamen von Edna Phelps Tanten, Onkeln und
Vettern/Kusinen durch diese Ehe gehören: Barrett, Crouch, Davidson, Hewitt,
Huntley, Munger, Page, Palmer, Reid, Ruggles, Schultz, Scovil, Thompson,
Wichersham und Willson.</p>
<p>Martin N. Gulicks zweite Hochzeit fand 1850 mit Jane Vanarsdall statt.
Sie hatten keine Kinder. Jane starb 1857.</p>
<p>Seine dritte Hochzeit feierte er 1860 mit Annis C. Phelps. Sie hatten
fünf Töchter: Sadie, Alice, Olive, Hattie und eine weitere Tochter, die in
früher Kindheit starb. Nur zwei ihrer Töchter heirateten. Nach den
Informationen in diesem Bestand überlebten keine Enkel die frühe Kindheit.
Annis und ihre Töchter, die während längerer Zeit Ende des 19. Jhdts.
korrespondierten, schrieben einen Großteil der Gulickschen Briefe, die zum
Bestand gehören. Die Themen reichen von Beschreibungen von Kleidermustern
bis zu Erörterungen von Lebensumständen.</p>
<p>Die Ehe von Martin und Annis Gulick führte dazu, dass sich Mary Jane
Gulick (Edna Phelps Großmutter) und Louis Ransom Phelps (Halbbruder von
Annis C. Phelps) kennenlernten. Schließlich heirateten Mary und Louis. Zu
dieser Zeit wurde Mary aus unbekannten Gründen von ihrem Vater enterbt. Das
verbannte Paar lebte lange Zeit in Jerseyville, Illinois, und hatte nur
wenig Verbindungen mit der Familie Gulick. Ihr ältester Sohn (von zwölf
Kindern) war Ernest Phelps, Edna Phelps Vater. Edna hat möglicherweise
einen Teil ihrer Kindheit in Südkalifornien verbracht, da Dokumente in
diesem Bestand darauf hinweisen, dass ihre Großeltern 1904 ihren Eltern
dorthin folgten und sich in Pasadena ansiedelten. Viele Fotos der Familie
Phelps gehören zu diesem Bestand.</p>
<p>Der größte Teil der Familie Gulick begann nach Westen zu ziehen, als die
Preiskriege der Eisenbahnen um 1880 einen Boom einleiteten, woraufhin viele
Menschen aus dem Mittleren Westen nach Kalifornien zogen.
Arbeitsmöglichkeiten und geringere Lebenshaltungskosten waren nur zwei der
Anreize, die den Gulicks zum Umzug bewegten. Der wichtigste Aspekt war
jedoch wahrscheinlich das Wetter. Wie Eleanor Davidson (Edna Phelps Tante)
Anfang 1888 sagte, als sie mit dem Zug von Illinois in San Bernardino in
Kalifornien ankam: „Ich konnte kaum glauben, dass wir im Land des Sommers
waren, bis die Mädchen hinausgingen und Blumen und Orangen überall sahen
und es so warm war.“</p>
<p>Viele der Gulicks siedelten sich in Orange County und Umgebung an. Zu
ihren Berufen gehörten die Schädlingsbekämpfung in Obstgärten, die
Produktion von Walnüssen und das Predigen. Einer der Vettern galt als Hans
Dampf in allen Gassen. Er zog mit seiner Familie herum, je nachdem, in
welcher Stadt es gerade Arbeit gab.</p>
<p>In den Zwanziger Jahren des 20. Jahrhunderts, dem Zeitraum, in dem der
Großteil der Materialien dieses Bestandes endet, war in vielen Gebieten
Südkaliforniens ein Netzwerk von Verwandten von Edna Phelps – alles
Nachkommen der Gulicks – fest etabliert.</p>
</bioghist>
<scopecontent>
266
<head>Gegenstände</head>
<p>Der Bestand enthält Fotos, Briefe, Tagebücher und Familiendokumente, die
die Geschichte von mindestens vier Generationen der Familien Phelps,
Gulick, Davidson, Humiston, Gooch, Huntley, Schultz, Willson und Turner aus
den Jahren 1847-1978 dokumentieren. Der größte Teil des Bestandes betrifft
die Familie Gulick, ca. 1880-ca. 1920. Zum Bestand gehören auch Sachakten
und personenbezogene Akten zu anderen Familien und Orten in Tustin und
Umgebung, ca. 1810-ca. 1981.</p>
<p>Da sich ein Teil der Originalmaterialien dieses Bestandes in anderen
Institutionen befindet (z. B. Bowers Museum, Tustin Area Museum, Western
Association for the Advancement of Local History) oder von auswärtigen
Forschungsinstitutionen erworben wurde, sind viele Objekte Fotokopien von
Originalen. Wenn der Aufbewahrungsort eines Originals bekannt ist, ist dies
auf den Fotokopien vermerkt.</p>
<p>Der Bestandsakte der Special Collections zufolge wurden die
Rechercheakten von Helen Gulick Huntley erstellt. Sie bestehen aus handund maschinengeschriebenen Notizen, von denen viele um das Jahr 1960
entstanden. Außerdem gehört zum Bestand eine maschinengeschriebene
Biografie von Columbus Tustin, verfasst von Helen Gulick Huntley.</p>
</scopecontent>
<controlaccess>
<head>Begriffe aus Normansetzungen</head>
<p>Die folgenden Begriffe werden bei der Indizierung für diesen Bestand im
öffentlich zugänglichen ANTPAC-Katalog der University of California,
Irvine, verwendet.</p>
<controlaccess>
<head>Gegenstand</head>
<persname source="lcnaf">Phelps, Edna W.--Archives.</persname>
<geogname source="lcnaf">Orange County (Calif.)--Archival
resources.</geogname>
<famname source="lcsh">Gulick family--Archival resources.</famname>
<famname source="lcsh">Phelps family--Archival resources.</famname>
<geogname source="lcnaf">Tustin (Calif.)--Archival resources.</geogname>
</controlaccess>
<controlaccess>
<head>Weitere Beitragende</head>
<persname source="lcnaf">Huntley, Helen Gulick.</persname>
</controlaccess>
</controlaccess>
<add>
<relatedmaterial>
<head>Verwandte Bestände</head>
<p>Folgende Bestände in den Special Collections bei den UCI Libraries
enthalten verwandte Materialien:
<list>
<item>
<archref>
<unitid>MS-R24</unitid>,
<unittitle>Fotografien von Alice Gulick Gooch</unittitle>
<note><p>(Stiefgroßtante von Edna Phelps durch Martin N. Gulicks
dritte Ehe)</p></note>
</archref></item>
<item>
<archref>
<unitid>MS-R26</unitid>,
<unittitle>Fotografien von Quinn und Jesse Gulick</unittitle>
<note><p>(Vettern 2. Grades von Edna Phelps durch Martin N. Gulicks erste
Ehe)</p></note>
</archref></item>
</list></p></relatedmaterial>
</add>
<dsc type="combined">
<head>Bestandsverzeichnis</head>
267
<c01 level="series">
<did>
<unittitle>Serie 1. Fotografien, <unitdate type="inclusive">18551967.</unitdate></unittitle>
<physdesc>
<extent>0.2 lfm</extent></physdesc>
</did>
<scopecontent>
<p>Diese Serie enthält nur Schwarzweißfotos, sofern im Bestandsverzeichnis
nichts anderes vermerkt ist, und ist in zwei Teilserien gegliedert.</p>
</scopecontent>
<c02 level="subseries">
<did>
<unittitle>Teilserie 1.1. Personen, <unitdate type="inclusive">18551967.</unitdate></unittitle>
<physdesc>
<extent>0.1 lfm</extent></physdesc>
</did>
<scopecontent>
<p>Diese Teilserie umfasst Fotos von Familienangehörigen, Einzelpersonen
und Gruppen, Schulklassen und Freunden der Familie. Die Teilserie enthält
hauptsächlich Materialien der Familien Phelps und Gulick und ist
alphabetisch nach den Nachnamen oder dem Namen des/der dargestellten
Ortes/Institution geordnet.</p>
</scopecontent>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">1</container>
<unittitle><famname>Familie Bartley</famname>, <unitdate
type="inclusive">1882-1905 </unitdate></unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">2</container>
<unittitle><persname>Burston, Selina</persname>, <unitdate
type="single">1891</unitdate></unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">3</container>
<unittitle><famname>Familie Carson</famname>, <unitdate
type="single">1897</unitdate></unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">4</container>
<unittitle><persname>Chestnutwood, Mrs. A. J.</persname>,
<unitdate type="single">1870</unitdate></unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">5</container>
<unittitle><famname>Familie Davidson</famname>, <unitdate
type="single">1910</unitdate></unittitle>
268
</did>
</c03>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">6</container>
<unittitle><corpname>El Modena Elementary School</corpname>,
<unitdate type="single">ca. 1892</unitdate>, <unitdate
type="single">1893</unitdate>, <unitdate type="single">
1921</unitdate></unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">7</container>
<unittitle><famname>Familie Gooch</famname>, <unitdate
type="inclusive">1898-1908</unitdate></unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">8-12</container>
<unittitle><famname>Familie Gulick</famname>, <unitdate
type="inclusive">ca. 1875-1915</unitdate>, <unitdate
type="single">1967</unitdate></unittitle>
<physdesc>
<extent>(5 folders)</extent></physdesc>
</did>
</c03>
... [usw.]
<c03 level="file">
<did>
<container type="box">1</container>
<container type="folder">33</container>
<unittitle>Ohne Titel, <unitdate>nicht datiert</unitdate>
</unittitle>
</did>
<note>
<p>(Enthält 2 <genreform>Tintypes</genreform>)</p>
</note>
</c03>
</c02>
<c02 level="subseries">
<did>
<unittitle>Teilserie 1.2. Orte, <unitdate type="inclusive">18901920.</unitdate></unittitle>
<physdesc>
<extent>0.1 lfm</extent></physdesc>
</did>
<scopecontent>
<p>Diese Teilserie umfasst Aufnahmen von Orten in Orange County und anderen
Orten in Kalifornien sowie Bilder aus Kansas, Oklahoma und Illinois. Sie
ist alphabetisch nach Ortsnamen in Orange County, danach Kalifornien und
dann den übrigen USA geordnet.</p>
</scopecontent>
<c03 level="file">
<did>
<container type="box">2</container>
<container type="folder">1-5</container>
269
<unittitle><geogname>Orange County</geogname></unittitle>
</did>
<c04 level="file">
<did>
<container type="box">2</container>
<container type="folder">1</container>
<unittitle><corpname>Irvine Ranch</corpname>, <unitdate
type="single">ca. 1895</unitdate></unittitle>
</did>
</c04>
<c04 level="file">
<did>
<container type="box">2</container>
<container type="folder">2</container>
<unittitle><geogname>Laguna Beach</geogname> und <geogname>San Juan
Capistrano</geogname> Mission,
<unitdate>nicht datiert</unitdate></unittitle>
</did>
</c04>
<c04 level="file">
<did>
<container type="box">2</container>
<container type="folder">3</container>
<unittitle><geogname>Orange</geogname>, <unitdate
type="single">ca. 1905</unitdate>, <unitdate type="single">
1912</unitdate></unittitle>
</did>
</c04>
<c04 level="file">
<did>
<container type="box">2</container>
<container type="folder">4</container>
<unittitle><geogname>Santa Ana</geogname>, <unitdate
type="single">ca. 1910</unitdate></unittitle>
</did>
</c04>
<c04 level="file">
<did>
<container type="box">2</container>
<container type="folder">5</container>
<unittitle><geogname>Tustin</geogname>, <unitdate
type="inclusive">ca. 1890-1920</unitdate></unittitle>
</did>
</c04>
</c03>
<c03 level="file">
<did>
<container type="box">2</container>
<container type="folder">6</container>
<unittitle>Orte in Kalifornien</unittitle>
</did>
<c04 level="item">
<did>
<container type="box">2</container>
<container type="folder">6</container>
<unittitle><corpname>Buena Vista Rancho</corpname>,
<unitdate>nicht datiert</unitdate></unittitle>
</did>
</c04>
<c04 level="item">
<did>
<container type="box">2</container>
<container type="folder">6</container>
270
<unittitle><geogname>Corona</geogname>, <unitdate
type="single">ca. 1906</unitdate></unittitle>
</did>
</c04>
... [usw.]
<c04 level="item">
<did>
<container type="box">2</container>
<container type="folder">6</container>
<unittitle><geogname>Ukiah</geogname>, <unitdate>
nicht datiert</unitdate></unittitle>
</did>
</c04>
</c03>
<c03 level="file">
<did>
<container type="box">2</container>
<container type="folder">7</container>
<unittitle>USA</unittitle>
</did>
<c04 level="item">
<did>
<container type="box">2</container>
<container type="folder">7</container>
<unittitle><geogname>Kansas</geogname>, <unitdate>
nicht datiert</unitdate></unittitle>
</did>
</c04>
<c04 level="item">
<did>
<container type="box">2</container>
<container type="folder">7</container>
<unittitle><geogname>Plainview, Illinois</geogname>,
<unitdate type="single">ca. 1890</unitdate></unittitle>
</did>
</c04>
<c04 level="item">
<did>
<container type="box">2</container>
<container type="folder">7</container>
<unittitle><geogname>Tulsa, Oklahoma</geogname>,
<unitdate>nicht datiert</unitdate></unittitle>
</did>
</c04>
</c03>
<c03 level="file">
<did>
<container type="box">2</container>
<container type="folder">8</container>
<unittitle>Ohne Titel, <unitdate>nicht datiert</unitdate></unittitle>
</did>
</c03>
</c02>
</c01>
<c01 level="series">
<did>
<unittitle>Serie 2. Korrespondenz, <unitdate type="inclusive">18521978.</unitdate></unittitle>
<physdesc>
<extent>0.2 lfm</extent></physdesc>
</did>
271
<scopecontent>
<p>Diese Serie besteht aus handgeschriebenen Originalbriefen und Fotokopien
von Originalen. Einige Akten enthalten auch maschinengeschriebene Kopien
von Originalbriefen mit Notizen von Edna Phelps, in denen die Beziehungen
zwischen Personen und Orten beschrieben sind, die in den Briefen erwähnt
werden. Die Serie ist alphabetisch nach den Nachnamen der Verfasser
geordnet.</p>
</scopecontent>
<c02 level="file">
<did>
<container type="box">3</container>
<container type="folder">1</container>
<unittitle><persname>Alexander, M.A.</persname>, <unitdate
type="single">1877</unitdate></unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">3</container>
<container type="folder">2</container>
<unittitle><persname>Barr, Maria</persname>, <unitdate
type="single">1885</unitdate>, <unitdate type="single">1902
</unitdate></unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">3</container>
<container type="folder">3</container>
<unittitle><persname>Bartlett, Lanier</persname>, <unitdate
type="single">1958</unitdate></unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">3</container>
<container type="folder">4</container>
<unittitle><persname>Carson, Harlan Page</persname>, <unitdate
type="inclusive">1886-1932</unitdate></unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">3</container>
<container type="folder">5</container>
<unittitle><persname>Cochran, Winona Barr</persname>, <unitdate
type="single">1902</unitdate></unittitle>
</did>
</c02>
... [usw.]
<c02 level="file">
<did>
<container type="box">4</container>
<container type="folder">16</container>
<unittitle><persname>Utt, C.E.</persname>Züchter und Exporteur, Tustin,
Kalifornien, <unitdate type="single">1904</unitdate></unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">4</container>
272
<container type="folder">17</container>
<unittitle>Unbekannte Autoren, <unitdate type="inclusive">18881892</unitdate></unittitle>
</did>
</c02>
</c01>
<c01 level="series">
<did>
<unittitle>Serie 3. Sachakten, <unitdate type="inclusive">18471972. </unitdate></unittitle>
<physdesc>
<extent>0.1 lfm</extent></physdesc>
</did>
<scopecontent>
<p>Diese Serie enthält Tagebücher von Familienangehörigen, historische
Schriften über die Familien Gulick und Tustin sowie Ephemera. Ein Großteil
dieser Materialien besteht aus Fotokopien von Originalen. In einigen Fällen
sind diese Kopien sehr schlecht lesbar. Die Serie ist alphabetisch nach den
Nachnamen der Verfasser geordnet, falls er bekannt ist, ansonsten nach
Titel oder Genre der Materialien.
</p></scopecontent>
<c02 level="file">
<did>
<container type="box">4</container>
<container type="folder">18</container>
<unittitle><persname>Bartley, George</persname>. Transkriptionen der
Interviews von Edna Phelps, <unitdate type="inclusive">1971-1972</unitdate>
</unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">4</container>
<container type="folder">19</container>
<unittitle><persname>Davidson, Eleanor Gulick</persname>. "Short
diary of a journey from Plainview, Illinois to Santa Ana, California 18871888", Transkription von Edna Phelps, <unitdate type="single">Oktober
1971</unitdate>
</unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">4</container>
<container type="folder">20</container>
<unittitle><persname>Davidson, Sue and Laura</persname>. "Letters of Sue
and Laura Davidson to Aunt Ollie and Aunt Hattie (Gulick)". Es handelt sich
um Briefe, ausgewählt und herausgegeben von Edna Phelps und Ellen Lee,
<unitdate type="single">1981</unitdate></unittitle>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">4</container>
<container type="folder">21</container>
<unittitle>Erhebung und Bemessung von Steuern, Orange County, <unitdate
type="inclusive">1866-1875</unitdate></unittitle>
</did>
</c02>
... [usw.]
<c02 level="file">
273
<did>
<container type="box">5</container>
<container type="folder">11</container>
<unittitle>World's Columbian Commission Citrus Fruit Award, Weltausstellung
Chicago, <unitdate type="single">1893</unitdate>. Verliehen an
<persname>Martin N. Gulick</persname>.</unittitle>
<note>
<p>ORIGINAL DES PREISES BEFINDET SICH IM ORDNER XOS</p>
</note>
</did>
</c02>
<c02 level="file">
<did>
<container type="box">5</container>
<container type="folder">12</container>
<unittitle>Schriftstücke, ohne Titel, <unitdate>nicht datiert</unitdate>
</unittitle>
</did>
</c02>
</c01>
<c01 level="series">
<did>
<unittitle>Serie 4. Rechercheakten, <unitdate type="inclusive">ca. 18101981.</unitdate></unittitle>
<physdesc>
<extent>0.1 lfm</extent></physdesc>
</did>
<scopecontent>
<p>Diese Serie enthält historische Notizen zu Einwohnern, Orten und
Lebensumständen in Tustin und Umgebung. Sie ist in zwei Teilserien
gegliedert.</p>
</scopecontent>
<c02 level="subseries">
<did>
<unittitle>Teilserie 4.1. Biografische Notizen, <unitdate
type="inclusive">ca. 1810-ca. 1960.</unitdate></unittitle>
<physdesc>
<extent>0.1 lfm</extent></physdesc>
</did>
<scopecontent>
<p>Diese Teilserie enthält kurze historische Notizen einschließlich
Geburts-, Todes- und Eheschließungsdaten, Berufe und weitere Angaben zu
früheren Einwohnern von Tustin. Die meisten Notizen stammen von Helen
Gulick Huntley. Verschiedene andere biografische Notizen im gesamten
Bestand sind ebenfalls hier vermerkt. Die Teilserie ist alphabetisch nach
den Nachnamen der Personen geordnet.</p></scopecontent>
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">13</container>
<unittitle>Adams-Artz</unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">14</container>
<unittitle>Ballard-Butterfield</unittitle>
</did>
</c03>
... [usw.]
274
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">34</container>
<unittitle>Wall-Zeilian</unittitle>
</did>
</c03>
</c02>
<c02 level="subseries">
<did>
<unittitle>Teilserie 4.2. Sachthematische Notizen, <unitdate
type="inclusive">ca. 1850-1981
.</unitdate></unittitle>
<physdesc>
<extent>0.05 flm</extent></physdesc>
</did>
<scopecontent>
<p>Diese Teilserie enthält kurze historische Notizen zu Örtlichkeiten (z.
B. Banken, Kirchen, Häusern usw.) und Lebensumständen (z. B. Lohn,
Freizeit, Grundbesitz, Bewässerung usw.) in Tustin und Umgebung und ist
alphabetisch nach Themen geordnet.</p></scopecontent>
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">35</container>
<unittitle>Afro-amerikanische Einwohner</unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">35</container>
<unittitle>Banken</unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">35</container>
<unittitle>Gebäude</unittitle>
</did>
</c03>
... [usw.]
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">37</container>
<unittitle>Bewässerung</unittitle>
</did>
</c03>
<c03 level="file">
<did>
<container type="box">5</container>
<container type="folder">37</container>
<unittitle>Wood-Canyon-Höhle</unittitle>
</did>
</c03>
</c02>
</c01>
</dsc>
</archdesc>
</ead>
275
Beispiel 2
Dieses kurze Bestandsverzeichnis veranschaulicht eine Findbuchstruktur und ein
Kodierschema, das stark von der im betreffenden Archiv durchgeführten
Benutzerbefragung und deren Anforderungen an die Darstellung beeinflusst
wurde.131 In jedem Findbuch des Archivs ist ein Satz der wichtigsten <did>Datenelemente in Standardreihenfolge enthalten: <abstract>, <bioghist>,
<scopecontent>, <organization>, <controlaccess> und <admininfo>. Diese Elemente
werden in einer Reihenfolge wiedergegeben, die für Benutzer hilfreich ist, wenn sie
feststellen wollen, inwieweit ein bestimmter Bestand für ihre Forschungsfrage
relevant ist.
Die häufige Verwendung der Elemente <head> und <thead> und des Attributs
LABEL sorgt für eine deutliche visuelle Markierung der Datenelemente, wenn das
Findbuch auf dem Bildschirm dargestellt oder auf Papier ausgedruckt wird. Die
Markierung dient als Navigationshilfe und erleichtert insbesondere neuen Nutzern die
Orientierung. Mit gleicher Zielsetzung wurden Erklärungen für Nutzer in <unitloc>,
<controlaccess> und <dsc> aufgenommen. Dieses Archiv hat bei seinen EADFindbüchern sein bewährtes Verfahren angewendet, alle Zugriffspunkte
aufzunehmen, die in der Online-Titelaufnahme des Bestandes verwendet wurden.
Schließlich wird durch Verwendung des „kombinierten” <dsc>-Modells die
hierarchische Struktur der archivischen Materialien hervorgehoben.
Dieses Beispiel ist XML-konform und wendet die EAD-DTD im XML-Modus an, wobei
die in Abschnitt 4.3.2 beschriebenen Änderungen an der DTD berücksichtigt wurden.
131
Eine ausführlichere Beschreibung des Prozesses zur Entwicklung eines Kodiertemplates bei der Minnesota Historical
Society vgl. Meissner, Dennis: First Things First: Reengineering Finding Aids for Implementation of EAD, in: American Archivist
60 (1997) 3, S. 372-387.
276
<?xml version="1.0" standalone="no"?>
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD ead.dtd
(Encoded Archival Description (EAD) Version 1.0)//EN" "ead.dtd" [
<!ENTITY % eadnotat PUBLIC "-//Society of American Archivists//DTD
eadnotat.ent (Encoded Archival Description (EAD) Notation Declarations
Version 1.0)//EN" "eadnotat.ent"> %eadnotat;
<!ENTITY mhslogo SYSTEM "mhslogo.gif" NDATA gif>
]>
<ead audience="external">
<eadheader audience="internal" langencoding="ISO 639-2">
<eadid systemid="MnHi" source="DLC" type="url">39213.xml</eadid>
<filedesc>
<titlestmt>
<titleproper>Verzeichnis der Akten über Verstöße gegen die Jagdgesetze des
Game and Fish Departments bei der Minnesota Historical
Society</titleproper>
<author>Erstellt von Lydia Lucas.</author>
</titlestmt>
<publicationstmt>
<publisher>Minnesota Historical Society, St. Paul, MN</publisher>
<date>1996</date>
</publicationstmt>
</filedesc>
<profiledesc>
<creation>Findbuch kodiert von Kris Kiesling,
<date>Januar 1998.</date>
</creation>
<langusage>
<language>Findbuch geschrieben in Englisch.</language>
</langusage>
</profiledesc>
</eadheader>
<archdesc type="inventory" level="subgrp" langmaterial="eng">
<did>
<head>ÜBERSICHT ÜBER DIE AKTEN</head>
<repository label="Archiv:">
<corpname>Minnesota Historical Society</corpname>
</repository>
<origination label="Provenienz:">
<corpname>Minnesota. Game and Fish Department</corpname>
</origination>
<unitid label="Bestandssignatur:" countrycode="US" repositorycode="MnHi">
39213</unitid>
<unittitle label="Titel:">Akten über Verstöße gegen Jagdgesetze,
<unitdate label="Laufzeit:" type="inclusive">1908-1928</unitdate>
</unittitle>
<abstract label="Zusammenfassung:">Unterlagen über Verfahren und
Beschlagnahme von Eigentum aufgrund von Verstößen gegen die Jagdgesetze des
Bundesstaates.</abstract>
<physdesc label="Umfang:">0,7 m3 (7 Bände und 1 Ordner in 3 Kisten)
</physdesc>
<physloc label="Lagerungsort:">Aufbewahrungsort der Kisten siehe
Bestandsverzeichnis</physloc>
</did>
<bioghist>
<head>BEHÖRDENGESCHICHTE</head>
<p>Diese Unterlagen stammen von zwei Behörden, die aufeinander folgten: dem
Board of Game and Fish Commissioners of Minnesota (1891-1915) und dem Game
and Fish Department (1915-1931). Beide hatten ähnliche Aufgaben: Schutz,
Verbreitung und Zucht von Wild- und Fischarten, Aufstellung von Statistiken
und Durchsetzung der Jagd- und Fischereigesetze. Sie betrieben auch die
277
staatlichen Fischzuchtanstalten. Das Department wurde 1931 zur Division of
Game and Fish in dem neu gegliederten Conservation Department.</p>
</bioghist>
<scopecontent>
<head>Gegenstände</head>
<p>Unterlagen zu Strafverfahren bei Verstößen gegen die staatlichen Jagdund Fischereigesetze. Register von Gegenständen (Wild, Fische, Jagdwaffen
und/oder Gerät), die bei den Festgenommenen, die gegen die Gesetze
verstoßen hatten, am Tatort beschlagnahmt wurden.</p>
</scopecontent>
<organization>
<head>ORDNUNG DER AKTEN</head>
<p>Die Akten sind in folgende Teilbereiche gegliedert:</p>
<p>Strafverfahren, 1916-1927.</p>
<p>Beschlagnahmungen, 1908-1928.</p>
</organization>
<odd>
<head>FINDMITTEL</head>
<p>Eine gedruckte Version dieses Verzeichnisses ist im Archiv vorhanden.
Sie ist zu finden unter „Game and Fish Commission”.</p>
</odd>
<controlaccess>
<head>INDEXBEGRIFFE</head>
<note><p>Diese Akten sind unter folgenden Titeln im Katalog der Minnesota
Historical Society indexiert. Benutzer, die verwandte Materialien suchen,
sollten im Katalog nach diesen Indexbegriffen suchen.</p></note>
<controlaccess>
<head>Organizations:</head>
<corpname>Board of Game and Fish Commissioners of Minnesota.</corpname>
</controlaccess>
<controlaccess>
<head>Themen:</head>
<subject>Fishery law and legislation--Minnesota.</subject>
<subject>Game-law--Minnesota.</subject>
<subject>Law enforcement--Minnesota.</subject>
</controlaccess>
</controlaccess>
<admininfo>
<head>VERWALTUNGSTECHNISCHE INFORMATIONEN</head>
<accessrestrict>
<head>Benutzungsbeschränkungen:</head>
<p>Keine Benutzungsbeschränkungen.</p>
</accessrestrict>
<acqinfo>
<head>Informationen zur Übernahme</head>
<p>Diese Unterlagen wurden 1976 vom Dept. of Natural Resources mit der
Zugangsnummer 1976.32 übernommen.</p>
</acqinfo>
<processinfo>
<head>Bearbeitungsinformationen:</head>
<p>Diese Unterlagen wurden 1977 von Lydia Lucas geordnet und
verzeichnet.</p>
</processinfo>
</admininfo>
<dsc type="combined">
<head>BESTANDSVERZEICHNIS</head>
<c01 level="series" id="s01">
<did>
<unittitle>Strafverfahren, <unitdate>1916-1927.</unitdate></unittitle>
<physdesc>3 Bände.</physdesc>
</did>
<scopecontent>
278
<p> Jeder Eintrag enthält: Datum des Protokolls, Name und Anschrift der
festgenommenen Person, Tatorte, Datum der Festnahme, Straftat, Name des
Richters, Ergebnis der Gerichtsverhandlung, Geldstrafen und Gerichtskosten,
ggf. Dauer der Haft, Name des Gefängnisdirektors und ggf. weitere
Bemerkungen. Zu den Straftaten gehörten Jagen oder Fischen während der
Schonzeit oder in Gebieten mit Jagd- bzw. Fischereiverbot, Überschreiten
der zugelassenen Jagd-/Fangquoten, Fangen zu kleiner Fische, verbotene
Arten der Fischerei, z. B. Treibnetz- oder Dynamitfischerei, verbotene
Jagdarten wie Jagen bei Nacht mit Beleuchtung, Jagen geschützter Vögel,
Fischen oder Jagen ohne Angel- bzw. Jagdschein sowie jagdbezogene
Straftaten gegenüber Personen, z. B. Betrug und Tätlichkeiten.</p>
</scopecontent>
<thead>
<row>
<entry>Lagerungsort</entry>
<entry>Kiste</entry>
<entry>Inhalt</entry>
</row>
</thead>
<c02>
<did>
<physloc>112.I.8.1B-1</physloc>
<container type="box">1</container>
<unittitle>August 1916-Juni 1922</unittitle>
</did>
</c02>
<c02>
<did>
<unittitle>Juli 1922-Dezember 1926</unittitle>
</did>
</c02>
<c02>
<did>
<unittitle>Januar-Dezember 1927</unittitle>
</did>
</c02>
</c01>
<c01 level="series" id="s02">
<did>
<unittitle>Beschlagnahmungen,
<unitdate>Dezember 1908-Januar 1928.</unitdate>
</unittitle>
<physdesc>4 Bände und 1 Ordner.</physdesc>
</did>
<scopecontent>
<p>Jeder Eintrag enthält: Nummer (laufende Nummern für jedes Jahr), Name
des Gefängnisdirektors, Ort, Name der Person, von der Gegenstände
beschlagnahmt wurden, Grund der Beschlagnahmung, Absender und Empfänger,
soweit es um den illegalen Versand von Wildbret ging, Bezeichnung der
beschlagnahmten Gegenstände (Fische, Wildbret, Schusswaffen und/oder
Gerät), Verbleib der beschlagnahmten Gegenstände, ggf. Käufer, empfangener
Betrag sowie ggf. weitere Bemerkungen.</p>
</scopecontent>
<thead>
<row>
<entry>Lagerungsort</entry>
<entry>Kiste</entry>
<entry>Inhalt</entry>
</row>
</thead>
<c02>
<did>
<physloc>112.I.8.1B-2</physloc>
279
<container type="box">2</container>
<unittitle>Dezember 1908-Juli 1917</unittitle>
</did>
</c02>
<c02>
<did><unittitle>August 1917-Oktober 1923</unittitle>
</did>
</c02>
<c02>
<did>
<physloc>112.I.8.2F-1</physloc>
<container type="box">3</container>
<unittitle>Oktober 1923-Juni 1925</unittitle>
</did>
</c02>
<c02>
<did>
<unittitle>Juli 1925-Juni 1927</unittitle>
</did>
<note>
<p>Enthält eine nicht erläuterte Zusammenstellung ausgewählter
Beschlagnahmungen für Oktober 1923 bis 1925. Möglicherweise handelt es sich
um Personen, die ihre Strafe nicht gezahlt haben.</p>
</note>
</c02>
<c02>
<did>
<unittitle>Juli 1927-Januar 1928.</unittitle>
<physdesc>1 Ordner.</physdesc>
</did>
<note>
<p>S. 1-37, aus einem ansonsten leeren Band entnommen.</p>
</note>
</c02>
</c01>
</dsc>
</archdesc>
</ead>
280
Beispiel 3
Beispiel 3 zeigt die Erschließungsverfahren, die im Public Record Office (Britisches
Nationalarchiv) für staatliche Unterlagen angewendet werden. Es werden ein
Bestand und eine Teilserie davon beschrieben. Bei der Festlegung der EADElemente für diese Erschließung wurde der Standard PROCAT Cataloguing
Guidelines (1998) zu Grunde gelegt, der sich auf ISAD(G) stützt und spezifisch für
das Public Record Office ist. Dieses Beispiel enthält sowohl auf Bestands- als auch
auf Serienebene die mindestens zu verwendenden fünf Erschließungselemente, die
von ISAD(G) empfohlen werden. Es bietet außerdem auf beiden Ebenen in den
<admininfo>-Elementen eine Auswahl von Angaben der Art, wie sie dieses Archiv
normalerweise dokumentiert.
281
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD ead.dtd
(Encoded Archival Description (EAD) Version 1.0)//EN" "ead.dtd" [
<!ENTITY prologo SYSTEM "prologo.gif" NDATA gif>
]>
<ead>
<eadheader>
<eadid>es.sgm</eadid>
<filedesc>
<titlestmt>
<titleproper>Akten des Atomic Weapons Research Establishments</titleproper>
</titlestmt>
<editionstmt>
<edition>1. Ausgabe</edition>
</editionstmt>
<publicationstmt>
<publisher>Public Record Office, Kew</publisher>
<date>1998</date>
</publicationstmt>
</filedesc>
<profiledesc>
<creation>Findbuch erstellt vom PRO-Redaktionsmitarbeitern, Dezember
1998</creation>
<langusage>
<language>Englisch</language>
</langusage>
</profiledesc>
</eadheader>
<frontmatter>
<titlepage>
<titleproper>Akten des Atomic Weapons Research Establishments</titleproper>
<publisher>
<extptr entityref="prologo">
</publisher>
<publisher>Public Record Office</publisher>
<date>1998</date>
<p>© Das Copyright für dieses Findbuchs liegt bei der Krone.</p>
</titlepage>
</frontmatter>
<archdesc level="fonds" legalstatus="public" langmaterial="eng" id="ES">
<did>
<unitid label="Verweis" countrycode="GBR" repositorycode="067">ES</unitid>
<unittitle>Akten des Atomic Weapons Research Establishments</unittitle>
<origination label="Provenienz">
<corpname>Atomic Weapons Research Establishment, 1954-1973</corpname>
</origination>
<unitdate label="Laufzeit">1944-1986</unitdate>
<physdesc>
<extent>5</extent>
<genreform>Serie</genreform>
</physdesc>
<repository label="Verfügbar im">
<corpname>Public Record Office, Kew</corpname>
</repository>
<abstract>Akten des 1954 gegründeten Atomic Weapons Research
Establishments, die Forschungsarbeiten und Tests an den Atomwaffen von
Großbritannien durchführt.
</abstract>
</did>
<admininfo>
<accessrestrict>
<head>Zugangsbestimmungen</head>
<p>Für 30 Jahre geschlossen, soweit nicht anders angegeben.</p>
282
</accessrestrict>
<acqinfo>
<head>Abgebende Stelle</head>
<p>
<corpname>Ministry of Defence, 1947-, ab 1994</corpname>
</p></acqinfo>
</admininfo>
<scopecontent>
<head>Gegenstände</head>
<p>Akten des 1954 gegründeten Atomic Weapons Research Establishments, die
Forschungsarbeiten und Tests an den Atomwaffen von Großbritannien
durchführt.</p>
<p>Akten über den Aufbau von Aldermaston und die ersten dort durchgeführten
Arbeiten (Rowley-Bestand) befinden sich in ES 1. Berichte über Bomben
(Serie Bombs (B)) in ES 2, Berichte über die Auswirkungen von Atomwaffen
auf Strukturen (Serie Effects (E)) in ES 3, Berichte über Bombentests
(Serie Trials (T)) in ES 5 und Einfache Berichte (Serie Ordinary (O)) in ES
4.</p>
</scopecontent>
<bioghist>
<head>Behördengeschichte</head>
<p>Das Atomic Weapons Research Establishment wurde Ende der 1940er Jahre
vom Ministry of Supply gegründet. 1950 übernahm dieses Ministerium den
Standort Aldermaston für die Arbeit an Atomwaffen. Weitere
Forschungsarbeiten am britischen Atomwaffenprogramm, die beim Armament
Research Establishment in Kent durchgeführt wurden, wurden im gleichen Jahr
nach Aldermaston verlagert. 1954 wurde der Standort Aldermaston durch den
UK Atomic Energy Authority Act zum Hauptsitz der Weapons Group of the
United Kingdom Atomic Energy Authority bestimmt. Außenstellen des
Hauptsitzes in Aldermaston befanden sich in Woolwich Common, Foulness und
Orfordness.</p>
<p>Aufgaben des Atomic Weapons Research Establishments waren
wissenschaftliche und technische Forschungen über Atomwaffen und der Test
der britischen Atombomben.</p>
<p>Die ersten Tests fanden in Australien und im Pazifikraum statt und nach
1958 – gemäß dem US/UK Agreement for Cooperation in the Use of Atomic
Energy for Mutual Defence Purposes – in der unterirdischen Teststelle in
Nevada, USA.</p>
<p>Entsprechend dem Atomic Energy Authority (Weapons Group) Act 1973 wurde
die Weapons Group dem britischen Verteidigungsministerium unterstellt.</p>
</bioghist>
<add>
<relatedmaterial>
<head>Verwandte Materialien</head>
<p>Akten zu Atomwaffentests befinden sich in ADM 1, ADM 116, AIR 2, AIR20,
AIR 27, AVIA 65, DEFE 7 und WO 32.</p>
<p>Fotokopien von Belegen, die der Australian Royal Commission into
United Kingdom Nuclear Weapons Testing in Australia übergeben wurden,
befinden sich in DEFE 16.</p>
<p>Weitere Materialien über britische Forschungsarbeiten auf dem Gebiet der
Atomenergie befinden sich in AB.</p>
</relatedmaterial>
</add>
<controlaccess>
<head>Begriffe aus Normansetzungen</head>
<geogname>Aldermaston, Berkshire SU 5965</geogname>
<geogname>Vereinigte Staaten von Amerika</geogname>
<subject>Atomwaffen</subject>
<subject>UK Atomic Energy Authority Act 1954 c32</subject>
<subject>Atomic Energy Authority (Weapons Group) Act 1973 c4</subject>
<subject>US/UK Agreement for Cooperation in the use of Atomic Energy for
Mutual Defence Purposes 1958</subject>
</controlaccess>
283
<dsc type="combined">
<c level="series" id="ES-c4">
<did>
<unitid label="Verweis">ES 4</unitid>
<unitid label="Vorheriger Verweis">Ordinary (O)</unitid>
<unittitle>Atomic Weapons Research Establishment: Einfache
Berichte</unittitle>
<unitdate label="Laufzeit">1953-1970</unitdate>
<physdesc>
<extent>1258</extent>
<genreform>Berichte, Bände</genreform>
</physdesc>
</did>
<admininfo>
<appraisal>
<head>Bewertung</head>
<p>Der Gesamtkomplex der Berichte ist überliefert. Soweit Berichtsnummern
fehlen, wurden keine Berichte herausgegeben.</p>
</appraisal>
<accruals>
<head>Neuzugänge</head>
<p>Die Serie wird laufend durch Neuzugänge ergänzt.</p>
</accruals>
</admininfo>
<scopecontent>
<head>Gegenstände</head>
<p>Die Serie Einfache Berichte umfasst die Forschungstätigkeit der meisten
Abteilungen von AWRE und verschafft einen Gesamteindruck von den jährlichen
Arbeiten. Sie betreffen die Grundlagenforschung und die Instrumentierung,
mit Ausnahme der Tests zur Waffenwirkung (ES 3) und der Arbeiten in
Übersee, die in den Berichten über Bombentests (ES 5) behandelt werden.
Viele Stücke des Bestandes enthalten Fotografien und Pläne. In der
Einzelstückerschließung weisen Klammern darauf hin, dass
sicherheitsrelevanter Text herausgenommen wurde.</p>
</scopecontent>
<arrangement><head>Ordnung</head>
<p>Nummerierte Berichtsserien für jedes Jahr.</p>
</arrangement>
<controlaccess>
<head>Begriffe aus Normansetzungen</head>
<subject>Atomwaffen</subject>
</controlaccess>
</c>
</dsc>
</archdesc>
</ead>
284
Anhang F: Glossar
Absatz: Die grundlegende Texteinheit in einem SGML-Dokument.
Altdaten: Findbücher, die vor der Implementierung von EAD erstellt wurden. Solche
Findbücher müssen oft in gewissem Umfang umstrukturiert werden, um sie der
hierarchischen Struktur und den Elementen von EAD anzupassen.
Attribut: Benennt Eigenschaften eines Elements, die je nach dem Kontext, in dem
sie auftreten, verschiedene Werte haben können. Attribute verändern die Bedeutung
der Elemente, auf die sie sich beziehen. Beispiele für EAD-Attribute sind STATUS,
LEVEL und TYPE. Einige Attribute bestimmen die Wiedergabe von Zeichen, z. B.
RENDER. Die meisten EAD-Attribute sind nicht vorgeschrieben.
Auszeichnungssprache: Ein formelles Verfahren, um ein Dokument oder eine
Sammlung digitaler Daten mit einer Markierung zu versehen, um die Struktur des
Dokuments oder der Datei und den Inhalt seiner bzw. ihrer Datenelemente
anzugeben. Diese Auszeichnung liefert dem Rechner auch Informationen darüber,
wie ausgezeichnete Dokumente zu verarbeiten und darzustellen sind.
Authoring-Software: Computerprogramme, die beim Einfügen, Lesen und
Bearbeiten von SGML-Tags helfen. Hochentwickelte Authoring-Software kann auch
die Anwendung der Regeln einer DTD sicherstellen. Siehe auch Parser.
Bearbeitungssoftware: Siehe Authoring-Software.
Cascading Style Sheets (CSS): Formatierungssprache, mit der sich die
Wiedergabe von HTML- und XML-Dokumenten steuern lässt, und zwar durch
Festlegung von Darstellungsmerkmalen wie Schriftart, Farbe und Schriftgrad sowie
Textformatierungen wie Einrücken, Seitenränder und Tabellen. Siehe auch
Stylesheet.
CDATA: Siehe Zeichendaten.
Document Style Semantics and Specification Language (DSSSL): Eine Sprache
zur Erstellung von Stylesheets, um die Formatierung von SGML-Dokumenten
anzugeben oder diese in ein anderes Format umzuwandeln. Ein internationaler
Standard (ISO/IEC 10179:1996). Siehe auch Stylesheet.
Dokumentelement: Das höchstrangige Element in einer DTD. Bei EAD ist <ead>
das Dokumentelement. (Bisweilen wird der Begriff „Wurzelelement“ verwendet, wenn
das Dokumentelement gemeint ist. Dieser ist aber kein korrekter SGML-Begriff.)
Dokumentinstanz: Siehe Instanz.
Dokumenttyp-Definition (DTD): Die formellen Spezifikationen und Definitionen der
Strukturelemente und der Auszeichnung, die bei der Kodierung bestimmter
Dokumenttypen in SGML verwendet werden sollen.
285
Dokumenttyp-Deklaration: Liefert der SGML-Authoring- und -VeröffentlichungsSoftware technische Informationen darüber, wie SGML in der DTD und dem
kodierten Dokument angewendet werden soll.
DSSSL: Siehe Document Style Semantics and Specification Language (DSSSL).
EAD-Instanz: Siehe Instanz.
Einfacher Text: Im ASCII-Format kodierter Text. Als solcher ist er
softwareunabhängig und kann von praktisch jeder Softwareanwendung importiert,
gelesen und exportiert werden.
Element: Komponente der von einer Dokumenttyp-Definition festgelegten Struktur,
die in einer Dokumentinstanz durch beschreibende Auszeichnung erkennbar ist,
normalerweise mit einem Start-Tag <...> und einen End-Tag </...>.
Elementname: Der vollständige Name eines SGML-Elements, z. B. Date of the Unit.
Siehe auch Tag-Name.
Elternelement: Ein Element, das andere, als Subelemente bezeichnete, Elemente
enthalten kann. Siehe auch Subelement.
Entität: Eine SGML-Konvention, die es Kodierern erlaubt, in einer DokumenttypDefinition oder in der Deklarationsteilmenge einer SGML-Instanz einen abgekürzten
Namen anzugeben, der als Ersatz für etwas anderes dient, z. B. für eine aus
Textbausteinen bestehende Textpassage, ein anderes Dokument oder eine
Bilddatei.
Extensible Markup Language (XML): Eine vereinfachte Teilmenge von SGML, die
so ausgelegt ist, dass das allgemeine SGML im World Wide Web genauso wie HTML
gesendet, empfangen und verarbeitet werden kann. XML behält die hochentwickelte
Datenstruktur und Validierung von SGML bei, verzichtet jedoch auf viele der
Optionen, die die Entwicklung von SGML-Darstellungsprogrammen erschweren.
Extensible Style Language (XSL): Eine Sprache zur Erstellung von Stylesheets,
um XML-Dokumente in andere Formate umzuwandeln oder XML-Dokumente in
XML-fähigen Browsern darzustellen. Siehe auch Stylesheet.
Formal Public Identifier (FPI): Eine Textzeichenfolge, die als strukturiertes Zitat
eines SGML-Objekts wie etwa einer Entität, einer DTD oder eines Elements dient.
Ein FPI enthält den Namen seines Besitzers, die Klasse von Objekten, zu der das
zugehörige Objekt gehört (z. B. eine DTD oder eine Entität), eine allgemeine
Beschreibung des Objekts, seine Sprache und – wahlweise – seine Version.
Öffentliche Identifikatoren sind etwas anderes als Systemidentifikatoren, die ein
SGML-Objekt bezeichnen, indem sie ein systemspezifisches Merkmal zitieren, z. B.
eine URL oder einen Dateinamen, über den das Objekt in einem
Dateispeichersystem aufgefunden werden kann.
286
Formatierungselemente: Allgemeine Elemente, die die Darstellung eines
Dokuments beeinflussen, z. B. Absatz <p>, Hervorhebung <emph> (das das Attribut
RENDER zur Angabe von Darstellungsmerkmalen wie Fettdruck oder Kursivdruck
mit sich bringt) und Zeilenumbruch <lb>.
Geparste Zeichendaten (Parsable Character Data, PCDATA): Zeichen, die in
einem Teil eines SGML-Dokuments erscheinen, in dem der Text geparst und die
Auszeichnung erkannt wird und die nach der Syntaxanalyse als NichtAuszeichnungsdaten erkannt worden sind. In praktisch allen Fällen besteht der Text
eines kodierten Findbuchs aus PCDATA. Siehe auch Zeichendaten (CDATA).
Header: Eine Gruppe von SGML-Elementen, beispielsweise der EAD-Header
<eadheader>, in denen die Dokumentation (oder „Metadaten“) über den Text selbst
und seine Kodierung festgelegt wird. Kann sich auch auf Text beziehen, der so
kodiert ist, dass er am oberen Rand jeder Dokumentseite erscheint. Er darf nicht mit
dem EAD-Element <head> verwechselt werden, das zur Angabe einer
Kopfzeile/Überschrift für einen Textblock dient.
HTML: Siehe HyperText Markup Language.
Hüllenelement: Ein Element, das nur als Behälter für andere Elemente dient.
Hüllenelemente können Attribute haben, müssen jedoch eines oder mehrere
Subelemente enthalten, damit Text eingegeben werden kann.
Hyperlinks: Verknüpfungselemente, die ein nichtlineares Navigieren in und
zwischen digitalen Dokumenten sowie Verknüpfungen mit verwandten Objekten wie
Bild- oder Tondateien ermöglichen. Siehe auch Verknüpfungselemente.
HyperText Markup Language (HTML): Eine von SGML abgeleitete
Auszeichnungssprache zur Erstellung von Dokumenten für Anwendungen im World
Wide Web. Bei der die Kodierung mit HTML werden vor allem Formatierung und
Darstellung bezeichnet, nicht die intellektuellen oder hierarchischen Aspekte der
Dokumentstruktur, wie in EAD.
Inhaltsmodell: Bei SGML definiert es die Struktur und den Typ von Elementen und
Subelementen in einer DTD.
Instanz: Text und Tags (mit Ausnahme der DTD und der zugehörigen Dateien) eines
einzelnen, mit SGML kodierten Dokuments, z. B. eines einzelnen EAD-kodierten
Findbuchs. Siehe auch SGML-Dokument.
International Standards Organization (ISO): Das wichtigste Gremium für die
Erstellung internationaler Normen (Standards), bestehend aus Vertretern von
Staaten der ganzen Welt. Es überwacht die Entwicklung und Ratifizierung zahlreicher
Normen im Bereich des Fernmeldewesens und der Informationstechnik.
Internet: Ein weltweites „Netzwerk der Netzwerke“, das ursprünglich vom USVerteidigungsministerium entwickelt und vor allem für Wissenschaft und Forschung
genutzt wurde. Heute wird es auch für Handel, Unterhaltung sowie soziale und
287
gemeinschaftliche Zwecke verwendet. Vieles davon spielt sich im World Wide Web
ab, einem über das Internet bereitgestellten Dienst.
Konvention: Vereinbarte Verwendung beispielsweise eines Begriffs.
Leeres Element: Element, das weder PCDATA noch andere Elemente enthält.
Metasprache: Ein Regelwerk, in dem die Syntax eines Auszeichnungsschemas
formell beschrieben ist. SGML ist ein Beispiel für eine Metasprache bzw. es ist ein
Regelwerk zur Erstellung von Auszeichnungssprachen.
Multimedia: Digitale Materialien, Dokumente oder Produkte, z. B. Seiten im World
Wide Web oder CD-ROMs, die beliebige Kombinationen von Text, digitalen Daten,
unbewegten und bewegten Bildern, Animationen, Tönen und Grafiken zur Verfügung
stellen.
Öffentlicher Identifikator: Siehe (Formal Public Identifier, FPI).
Parser (Syntaxanalysator): Ein IT-Programm, das jedes mit einer SGMLDeklaration beginnende kodierte Dokument prüft, um festzustellen, ob das im
Dokument angewendete Taggen mit dem von der deklarierten DTD zugelassenen
Taggen konform ist. Er wird bisweilen als SGML-Konformitäts- oder Validierungsparser bezeichnet. Bei XML werden Anwendungen mit dieser Funktion
XML-Validatoren genannt.
PCDATA: Siehe Geparste Zeichendaten (Parsable Character Data, PCDATA).
Perl: Eine interpretierte Programmiersprache, die von vielen Rechnerplattformen
unterstützt wird und im Allgemeinen dazu dient, spezielle Skripte zur Verarbeitung
von Text für Anwendungen im World Wide Web zu entwickeln.
Plattform: Siehe Rechnerplattform.
Prolog: Der Dokumentprolog steht vor der Auszeichnung einer SGML-Instanz und
besteht aus der SGML-Deklaration (wahlweise bei SGML), einer XML-Deklaration
(erforderlich, falls die Instanz in XML kodiert ist) und der Dokumenttyp- (DOCTYPE-)
Deklaration, die eine DTD – vertreten durch einen FPI und/oder einen
Systemidentifikator – enthalten kann.
Rechnerplattform: Verwendete Rechnerhardware und -software (Betriebssystem
und Anwendungen), z. B. DOS/Windows, Macintosh oder UNIX.
Rekursivität: Rekursivität liegt bei SGML-Elementen vor, die eine oder mehr
Instanzen von sich selbst enthalten können. Siehe auch Schachtelung.
Schachtelung: Die Art und Weise, in der SGML-Subelemente innerhalb anderer
Elemente angeordnet sind, um ein mehrstufiges Dokument zu erzeugen. Siehe auch
Rekursivität.
288
SGML-Deklaration: Eine formelle, standardisierte Gruppe von Konstrukten, mit
denen einem Rechner mitgeteilt wird, welcher Zeichenvorrat, welche Begrenzer und
welche SGML-Funktionen bei einer SGML-Instanz verwendet werden.
SGML-Dokument: Eine Folge von Daten- und Auszeichnungszeichen, die optional
eine SGML-Deklaration enthält, auf die die verwendete DTD sowie eine kodierte
Dokumentinstanz, die den Spezifikationen dieser DTD entspricht, folgen. Siehe auch
Instanz.
Skript: In einer interpretierten Programmiersprache geschriebenes Programm wie
etwa Perl. Auch ein Begriff für eine Makro- oder Stapelverarbeitungsdatei, mit der
eine Reihe von Kommandos ohne Interaktion des Nutzers ausgeführt werden kann.
Standard Generalized Markup Language (SGML): Ein ISO-Standard (ISO 8879),
der zuerst von der Verlagsindustrie angewendet wurde. Dient zum Definieren,
Spezifizieren und Erstellen von digitalen Dokumenten, die systemunabhängig
übertragen, dargestellt, verknüpft und verarbeitet werden können.
Stylesheet: Ein ASCII-Textdokument, das an ein in SGML oder XML kodiertes
Dokument angehängt ist und Anweisungen zur Formatierung und Darstellung des
kodierten Dokuments oder zu seiner Umwandlung in ein anderes Format liefert.
Siehe auch Cascading Style Sheets (CSS), Document Style Semantics and
Specification Language (DSSSL), Extensible Style Language (XSL).
Subelement: Ein Element, das innerhalb eines oder mehrer anderer Elemente
verfügbar ist. In EAD ist jedes Element mit Ausnahme des Dokumentelements <ead>
ein Subelement eines oder mehrerer Elternelemente. Siehe auch Elternelement.
Systemidentifikator: Eine Zeichenfolge, die ein SGML-Objekt bezeichnet, indem sie
ein systemspezifisches Merkmal angibt, z. B. eine URL oder einen Dateinamen, über
den das Objekt in einem Dateispeichersystem aufgefunden werden kann.
Tag-Name: Ein kurzer, informeller, mnemotechnischer Name für ein SGML-Element.
Der Tag-Name eines Elements erscheint in spitzen Klammern, um Start-Tag und
End-Tag anzugeben. Beispielsweise ist <unitdate> der Tag-Name für das Element
Date of the Unit. Siehe auch Elementname.
Template: Ein vorher festgelegtes Formatmodell für Textverarbeitungs- oder SGMLAuthoring-Software, mit dem sichergestellt wird, dass die eingegebenen Daten einem
konsistenten Format- und Inhaltsschema entsprechen.
Text Encoding Initiative (TEI): Ein internationales Gemeinschaftsprojekt, um
allgemeine Richtlinien für ein Standardkodierschema für wissenschaftliche Texte zu
entwickeln.
289
Uniform Resource Identifier, URI: Eine gemäß der Syntax der Internet Engineering
Task Force RFC 2396 strukturierte Zeichenfolge, mit der eine Ressource im Internet,
z. B. eine Datei, ein herunterladbares Dokument oder ein Bild, bezeichnet wird. Es
gibt zwei Klassen von URIs: solche, die den Ort bzw. die Stelle angeben (Uniform
Resource Locators) und solche, die den Namen angeben (Uniform Resource
Names), z. B. PURL (Persistent URL). Siehe auch Uniform Resource Locator
(URL).
Uniform Resource Locator, URL: Eine gemäß der Syntax der Internet Engineering
Task Force RFC 1738 strukturierte Zeichenfolge, die die Speicherstelle einer
Ressource, z. B. einer Datei, eines Bildes oder eines herunterladbaren Dokuments,
im Internet angibt. Eine URL umfasst den Typ des Namensschemas (http, ftp, telnet,
news, file usw.), einen trennenden Doppelpunkt, den Standort des Hosts und einen
Pfad zur Ressource. URLs können entweder absolut (sie enthalten die gesamte
Adresse der Ressource) oder relativ sein (sie enthalten nur einen Teil der Adresse).
Teiladressen können verwendet werden, so lange die Verarbeitungssoftware die
vollständigen Speicherstellen auf der Grundlage des Zusammenhangs auflösen
kann. Relative URLs lassen eine gewisse Kürze bei der Dokumentation und der
dynamischen Erzeugung von Links zu. Sie minimieren auch Probleme, die auftreten
können, wenn hierarchische Bezeichnungssysteme oder Dateiadressen geändert
werden.
Unterscheidung zwischen Groß- und Kleinbuchstaben: Eine Eigenschaft einer
Software, die zwischen Groß- und Kleinbuchstaben unterscheidet. Eine
Suchmaschine, die zwischen Groß- und Kleinbuchstaben unterscheidet, würde die
Zeichenfolge „Kodierung“ nicht wiederfinden, wenn der Suchbegriff als „kodierung"
eingegeben worden wäre. Bei XML wird bei Tags zwischen Groß- und
Kleinschreibung unterschieden. Daher müssen alle Namen von EAD-Tags in
Kleinbuchstaben eingegeben werden.
Verknüpfungselemente: Elemente, die die Erstellung von Hypertextlinks innerhalb
einer SGML-Instanz oder von SGML-Instanzen zu anderen digitalen Objekten
ermöglichen. Siehe auch Hyperlink.
Vorgegebene Werte: Werte, die automatisch vom System geliefert werden, wenn
der Kodierer des Findbuchs keinen anderen Wert vorgibt.
Wiedergeben: Kodierte Daten auf die angegebene Art und Weise wiedergeben oder
darstellen.
Wurzelelement: Siehe Dokumentelement.
XLink (XML-Verknüpfungssprache): Dient zur Angabe von Konstrukten, die in
XML-Ressourcen eingefügt werden können, um Links zwischen Objekten zu
beschreiben. XLink wendet die XML-Syntax an, um Strukturen zu erzeugen, mit
denen sich die einfachen Einweg-Hyperlinks von HTML, aber auch höher entwickelte
Mehrwege-Links beschreiben lassen.
XML: Siehe Extensible Markup Language (XML).
290
XML-Verknüpfungssprache: Siehe XLink (XML-Verknüpfungssprache).
XSL: Siehe Extensible Style Language (XSL).
Zeichendaten (Character Data, CDATA): Zeichen, die in einem Teil eines SGMLDokuments erscheinen, in dem der Text nicht geparst und die Auszeichnung nicht
erkannt wird. Dazu gehören die Werte eines Attributs, deren Inhalt in einer DTD als
Zeichendaten definiert worden ist, oder der Inhalt eines ausgezeichneten CDATAAbschnitts eines Dokuments, der entsprechend begrenzt und als Zeichendaten
bezeichnet worden ist. CDATA ist nützlich, wenn Daten an eine Anwendung
weitergegeben werden sollen, ohne dass man sich mit den von einer Syntaxanalyse
hervorgerufenen Zeichenvorratsproblemen befassen muss, z. B. wenn sich im Text
eines Dokuments auch Rechnerkodeteile befinden. Die XML-Spezifikation verwendet
den Ausdruck „Zeichendaten“ in einem allgemeineren und etwas anderen Sinn als
SGML, wenn sie festlegt, dass „der Text, der nicht Auszeichnung ist, die
Zeichendaten des Dokuments dar[stellt]." Siehe auch Geparste Zeichendaten
(Parsable Character Data, PCDATA).
291
Anhang G: Bibliografie*
Encoded Archival Description (EAD)
American Heritage Project, <http://sunsite.berkeley.edu/amher/>.
Bouché, Nicole L.: Implementing EAD in the Yale University Library, in: American
Archivist 60 (1997) 1, S. 408-19.
DeRose, Stephen J.: Navigation, Access, and Control Using Structured Information,
in: American Archivist 60 (1997) 3, S. 298-309.
Dooley, Jackie M. (Ed.): Encoded Archival Description. Context, Theory, and Case
Studies, Chicago 1998.
(Artikel, die bereits in der Sommer- und Herbstausgabe 1997 im American Archivist veröffentlicht
wurden.)
Dow, Elizabeth H.: EAD and the Small Repository, in: American Archivist 60 (1997),
3, S. 446-455.
EAD Help Pages, <http://www.archivists.org/saagroups/ead/>.
(Gepflegt vom EAD Roundtable der Society of American Archivists)
Encoded Archival Description Retrospective Conversion Guidelines. A Supplement to
the EAD Tag Library and EAD Guidelines,
<http://sunsite.berkeley.edu/amher/upguide.html>.
(Gepflegt von der Electronic Text Unit, University of California, Berkeley, für das American Heritage
Virtual Archive Project und das Encoded Archival Description Project der University of California)
Encoded Archival Description Tag Library, Version 1.0, ed. by Society of American
Archivists, Chicago 1998.
Encoded Archival Description Official Web Site, <http://www.loc.gov/ead>.
(Gepflegt von der Library of Congress. Network Development and MARC Standards Office)
Encoding Standards for Electronic Aids. A Report by the Bentley Team for Encoded
Archival Description Development, in: Archival Outlook 10 (1996) Januar, S 10.
Fox, Michael: Implementing Encoded Archival Description: An Overview of
Administrative and Technical Considerations, in: American Archivist 60 (1997) 2,
S. 330-343.
Hensen, Steven L.: 'NISTF II' and EAD: The Evolution of Archival Description, in:
American Archivist 60 (1997) 2, S. 284-297.
Kiesling, Kris: EAD as an Archival Descriptive Standard, in: American Archivist 60
(1997) 2, S. 344-354.
Lacy, Mary A. / Mitchell, Anne: EAD Testing and Implementation at the Library of
Congress, in: American Archivist 60 (1997) 3, S. 420-435.
*
A.d.Ü.: Webressourcen wurden in den Fällen, wo es möglich war, aktualisiert.
292
McClung, Patricia: Access to Primary Sources: During and After the Digital
Revolution, <http://sunsite.berkeley.edu/FindingAids/EAD/ucb3.html>.
(Gehaltene Rede auf der Berkeley Finding Aids Conference, Berkeley, US-Bundesstaat Californien, 4.
– 6. April 1995)
Meissner, Dennis: First Things First: Reengineering Finding Aids for Implementation
of EAD, in: American Archivist 60 (1997) 3, S. 372-387.
Morris, Leslie A.: Developing a Cooperative Intra-institutional Approach to EAD
Implementation. The Harvard/Radcliffe Digital Findings Aids Project, in: American
Archivist 60 (1997) 3, S. 388-407.
Online Archive of California (OAC) Project. A Prototype Union Database of Encoded
Archival Finding Aids, <http://sunsite.Berkeley.edu/FindingAids/uc-ead/>.
Pitti, Daniel V.: Access to Digital Representations of Archival Material: The Berkeley
Finding Aid Project, in: RLG Digital Image Access Project. Proceedings from an RLG
Symposium held March 31 and April 1, 1995, Palo Alto, California, ed. by Patricia
McClung, Mountain View 1995, S. 73-81.
<http://sunsite.berkeley.edu/FindingAids/EAD/diap.html>.
Pitti, Daniel V.: Encoded Archival Description. The Development of an Encoding
Standard for Archival Finding Aids, in: American Archivist 60 (1997) 2, S. 268-283.
Pitti, Daniel V.: Settling the Digital Frontier. The Future of Scholarly Communication
in the Humanities, <http://sunsite.berkeley.edu/FindingAids/EAD/dpitti.html>.
(Abhandlung, vorgelegt auf der Berkeley Finding Aids Conference, Berkeley, US-Bundesstaat
Californien, 4. – 6. April 1995)
Ruth, Janice E.: Encoded Archival Description. A Structural Overview, in: American
Archivist 60 (1997) 2, S. 310-329.
Seaman, David: Multi-Institutional EAD. The University of Virginia’s Role in the
American Heritage Project, in: American Archivist 60 (1997) 2, S. 436-445.
293
Standard Generalized Markup Language (SGML), Extensible Markup Language
(XML) und verwandte Technologien
Alschuler, Liora: ABCD ... SGML: A User's Guide to Structured Information, London
und Boston 1995.
Barnard, David, u.a.: SGML-Based Markup for Literary Texts, in: Computers and the
Humanities 22 (1988), S. 265-276.
Barron, David: Why use SGML? Electronic Publishing Origination, in: Dissemination
and Design 2.1 (1989), S. 3-24.
Burnard, Lou / Sperberg-McQueen, C. M.: TEI Lite. An Introduction to Text Encoding
for Interchange. Dokument Nr TEI U 5, Juni 1995, <http://www.teic.org/Lite/teiu5_en.html>.
Busch, Joseph A.: SGML for Cultural Heritage Information, <http://www.oasisopen.org/cover/buschSGML.html>.
(Abhandlung, vorgelegt auf der Halbjahressitzung der American Society for Information Science
Minneapolis, US-Bundesstaat Minnesota, 24. Mai 1995.)
Coombs, James H. / Renear, Allen H. / DeRose, Steven J.: Markup Systems and the
Future of Scholarly Text Processing, in: Communications of the ACM 30 (1987), S.
933-947.
Cover, Robin: The SGML/XML Webpage, <http://www.oasis-open.org/cover>.
Current Cites Virtual Issue: SGML Information. <http://sunsite.berkeley.edu/SGML>
(Bibliografie der aktuellen Arbeiten, die dynamisch auf Anforderung erstellt wurden.)
DeRose, Stephen J.: The SGML FAQ Book. Understanding the Foundation of HTML
and XML, Dordrecht, Boston und London 1997.
DeRose, Stephen J. / Durand, David G: Making Hypermedia Work: A User's Guide to
HyTime, Boston, Dordrecht und London 1994.
Erickson, Janet C.: Options for Presentation of Multilingual Text. Use of the Unicode
Standard, <http://www.oasis-open.org/cover/ericksonUnicode.html>.
Goldfarb, Charles / Newcomb, Steven R. / Kimber, W. Eliot / Newcomb, Peter J.: A
Reader's Guide to the HyTime Standard,
<http://www.hytime.org/papers/htguide.html>.
Goldfarb, Charles F.: The SGML Handbook, Oxford 1990.
Goldfarb, Charles F. / Prescod, Paul: The XML Handbook, Upper Saddle River 1998.
Webseite The Handle System, <http://www.handle.net/>.
(Gepflegt von der Corporation for National Research Initiatives)
Herwijnen, Eric van: Practical SGML, Boston, Dordrecht und London, 21994.
294
Humanities Text Initiative Webseite, <http://www.hti.umich.edu/>.
(Gepflegt von der Humanities Text Initiative, University of Michigan.)
Ide, Nancy M. / Sperberg-McQueen, C. M.: The TEI. History, Goals, and Future, in:
Computers and the Humanities 29 (1995), S. 5-15.
International Organization for Standardization: ISO 8859-1: 1987 (E). Information
processing, 8-bit Single-Byte Coded Graphic Character Sets, Part 1: Latin Alphabet
No. 1, Genf 1987.
International Organization for Standardization: ISO 8879-1986 (E). Information
Processing, Text and Office Systems, Standard Generalized Markup Language
(SGML), Genf 1986.
International Organization for Standardization: ISO 8879:1986 / A1:1988 (E).
Information Processing, Text and Office Systems, Standard Generalized Markup
Language (SGML), Amendment 1, Genf 1988.
International Organization for Standardization: ISO/TR 9573-1988(E). Information
processing, SGML Support Facilities, Techniques for Using SGML, Genf 1988.
International Organization for Standardization and International Electrotechnical
Commission: ISO/IEC 10646-1: 1993. Information Technology, Universal MultipleOctet Coded Character Set (UCS), Part 1: Architecture and Basic Multilingual Plane,
Genf 1993.
International Organization for Standardization and International Electrotechnical
Commission: ISO/IEC 10744: 1992. Information Technology, Hypermedia/Timebased Structuring Language (HyTime), Genf 1992.
An Introduction to SGML. <http://www.pineapplesoft.com/reports/sgml/index.html>.
(Gepflegt von Benoît Marchal.)*
Langendoen, D. Terence, und Gary F. Simons: A Rationale for the TEI
Recommendations for Feature-Structure Markup, in: Computers and the Humanities
(1995), S. 191-209.
Maler, Eve / Abduloussi, Jeanne El: Developing SGML DTDs. From Text to Model to
Markup, Upper Saddle River 1996.
MARC DTDs Webseite. <http://lcweb.loc.gov/marc/marcsgml.html>.
(Gepflegt von der Library of Congress. Network Development and MARC Standards Office)
Pitti, Daniel V.: Standard Generalized Markup Language and the Future of
Cataloging, in: The Serials Librarian 25 (1995), S. 243-253 oder in: A Kaleidoscope
of Choices. Reshaping Roles and Opportunities for Serialists, ed. by Beth Holley und
Mary Ann Sheble, New York 1995.
*
A.d.Ü.: Webeite aktuell mit anderem Inhalt.
295
Price-Wilkin, John: A Gateway Between the World-Wide Web and PAT. Exploiting
SGML Through the Web, in: The Public-Access Computer Systems Review 5 (1994)
7, 5-27. <http://www.oasis-open.org/cover/pricewil.html>.
Price-Wilkin, John: Just-in-time Conversion, Just-in-case Collections. Effectively
Leveraging Rich Document Formats for the WWW, in: D-Lib Magazine (1997),
<http://www.dlib.org/dlib/may97/michigan/05pricewilkin.html>.
Publishing the Documents of the Future Today: XML and DynaText®. Inso White
Paper. Inso Corporation, <http://www.inso.com/dynatext/dtxtwp.htm>.
Rubinsky, Yuri, und Murray Maloney: SGML on the Web: Small Steps Beyond HTML,
Upper Saddle River 1997.
SGML: Getting Started; A Guide to SGML (Standard Generalized Markup Language)
and its Role in Information Management. Arbor Text White Paper. Arbor Text Inc.,
1995,
<http://www.arbortext.com/Think_Tank/SGML_Resources/Getting_Started_with_SG
ML/getting_started_with_sgml.html>.
The SGML Primer: SoftQuad's Quick Reference Guide to the Essentials of the
Standard. The SGML Needed for Reading a DTD and Marked-up Documents and
Discussing Them Reasonably, Toronto 1991,
<http://www.interleaf.com/Panorama/resources/PRIMER/primebody.html>.*
SGML Resources: SGML-Your Multi-Platform Publishing and Information
Management Solution, <http://www.sq.com/resources/sgml/index.html>.
(Gepflegt von SoftQuad, Inc.)*
Sperberg-McQueen, C. M. / Burnard, Lou (Eds.): Guidelines for Electronic Text
Encoding and Interchange. TEI P3, Text Encoding Initiative, 1994,
<http://www.uic.edu/orgs/tei/p3/doc/p3.html>.*
The Text Encoding Initiative Home Page, <http://www.uic.edu/orgs/tei>.
(Gepflegt von Wendy Plotkin und C. M. Sperberg-McQueen.)
Travis, Brian E. / Waldt Springer, Dale C.: The SGML Implementation Guide: A
Blueprint for SGML Migration, Berlin 1995.
von Hagen, Bill: SGML for Dummies, Foster City 1997.
Warmer, J., S. van Egmond: The Implementation of the Amsterdam SGML Parser.
Electronic Publishing Origination, in: Dissemination and Design 2.2 (1989), S. 65-90.
The Whirlwind Guide to SGML and XML Tools and Vendors.
<http://www.infotek.no/sgmltool/guide.htm>.*
(Gepflegt von Steve Pepper)
*
*
A.d.Ü.: Webseite nicht mehr existent.
296
World Wide Web Consortium (W3C) Webseite, <http://www.w3.org>.
Archivische Erschließung
Abraham, Terry: Oliver W. Holmes Revisited. Levels of Arrangement and Description
in Practice, in: American Archivist 54 (1991) 2, S. 370-377.
Bearman, David A.: The National Information Systems Task Force (NISTF) Papers,
1981-1984, Chicago 1987.
Bureau of Canadian Archivists: Toward Descriptive Standards. Report and
Recommendations of the Canadian Working Group on Archival Descriptive
Standards, Ottawa1985.
Duchein, Michel: Theoretical Principles and Practical Problems of Respect des Fonds
in Archival Science, in: Archivaria 16 (1983) S. 64-82.
Evans, Max: Authority Control: An Alternative to the Record Group Concept, in:
American Archivist 49 (1986) 2, S. 249-261.
Fox, Michael J. / Wilkerson, Peter L.: Introduction to Archival Organization and
Description, Los Angeles 1998.
Hamer, Philip: Guide to Archives and Manuscripts in the United States, New Haven
1961.
Hensen, Steven L.: Archival Description and New Paradigms of Bibliographic Control
and Access in the Networked Digital Environment, in: The Future of the Descriptive
Cataloging Rules, ed. by Brian E. C. Schottlaender. (= ALCTS Papers on Library
Technical Services and Collections, 6), Chicago 1998.
Hensen, Steven L.: Primary Sources, Research, and the Internet: The Digital
Scriptorium at Duke, in: First Monday. Peer Reviewed Journal on the Internet 2, Nr. 9
(1997), <http://www.firstmonday.dk/issues/issue2_9/hensen/>.
Hensen, Steven L.: Squaring the Circle: The Reformation of Archival Description in
AACR2, in: Library Trends (1988), S. 539-552.
Hensen, Steven L.: The Use of Standards in the Application of the AMC Format, in:
American Archivist 49 (1986) 4, S. 31-40.
Hickerson, H. Thomas: Archival Information Exchange and the Role of Bibliographic
Networks, in: Library Trends (1988), S. 553-571.
Holmes, Oliver Wendell: Archival Arrangement – Five Different Operations at Five
Different Levels, in: American Archivist 27 (1964) 1, S. 21-41.
Library of Congress, Descriptive Cataloging Division, Manuscripts Section: National
Union Catalog of Manuscript Collections. Washington 1959-1993.
Miller, Fredric M.: Arranging and Describing Archives and Manuscripts, Chicago
1990.
297
Public Archives of Canada: Union List of Manuscripts in Canadian Repositories =
Catalogue collectif des manuscrits archives canadiennes, ed. by Robert S. Gordon,
Ottawa 1968.
Walch, Victoria Irons (Ed.): Standards for Archival Description: A Handbook, Chicago
1994. <http://www.archivists.org/catalog/stds99/toc.html>.
Weissman, Ronald F. E.: Archives and the New Information Architecture of the Late
1990s, in: American Archivist 57 (1994) 4, S. 20-34. Duranti, Luciana: Commentary,
in: American Archivist 57 (1994), 4, S. 36-40.
Working Group on Standards for Archival Description: Archival Descriptive
Standards, in: American Archivist 52:4 (1990) und 53:1 (1990).
(Bericht der Working Group on Standards for Archival Description sowie einschlägige Darstellungen)
298
Thesauri und Regeln für die archivische Erschließung
Anglo-American Cataloging Rules, Chicago 21988.
Art & Architecture Thesaurus, New York 21994.
<http://www.ahip.getty.edu/aat_browser/>.*
Betz, Elisabeth W.: Graphic Materials: Rules for Describing Original Items and
Historical Collections, Washington 1982.
Canadian Subject Headings, ed. by Alina Schweitzer, Ottawa 1992.
Categories for the Description of Works of Art. The Getty Information Institute.
<http://www.getty.edu/research/conducting_research/standards/cdwa/>.
Cook, Michael, und Margaret Procter: A Manual of Archival Description, Aldershot
2
1989.
Dictionary of Occupational Titles, ed. by Department of Labor, Employment and
Training Administration, U.S. Employment Service, Washington 41991.
Hensen, Steven L.: Archives, Personal Papers, and Manuscripts. A Cataloging
Manual for Archival Repositories, Historical Societies, and Manuscript Libraries,
Chicago 21989.
ISAD(G). General International Standard Archival Description, adopted by the Ad Hoc
Commission on Descriptive Standards des International Council on Archives,
Stockholm, Schweden, 21. – 23. Januar 1993, Ottawa 1994.
<http://www.archives.ca/ica/cds/isad(g)e.html>.**
Library of Congress Name Authority File. Verfügbar online durch Anmeldung bei
OCLC oder RLIN (bibliografische Netzwerke).
Library of Congress Subject Headings, ed. by Cataloging Policy and Support Office,
Library Services, Washington 191996.
Matters, Marion E.: Oral History Cataloging Manual. Chicago 1995.
Medical Subject Headings, Washington 1998.
Moving Image Materials: Genre Terms, compiled by Martha M. Yee for the National
Moving Image Database Standards Committee, National Center for Film and Video
Preservation at the American Film Institute; coodinated by Motion Picture,
Broadcasting, and Recorded Sound Division, Library of Congress, Washington 1988.
*
A.d.Ü.: Webseite nicht mehr existent.
A.d.Ü. Webseite nicht mehr existent. Auch auf der Webseite des International Council on Archives steht eine Version der
ersten Auflage von ISAD(G) nicht zur Verfügung. Elektronisch aber noch verfügbar unter
<http://www.mclink.it/personal/MD1431/sito/isaargrp/isad(g)e.html>. Aktuelle Auflage: ISAD(G). General International Standard
Archival Description, Adopted by the Committee on Descriptive Standards Stockholm, Sweden, 19.-22. September 1999,
2
Ottawa 2000, <http://www.ica.org/biblio/cds/isad_g_2e.pdf>.
**
299
National Council on Archives Rules for Construction of Personal, Corporate, and
Place Names, <http://www.hmc.gov.uk/pubs/pubs.htm>.*
(Gepflegt vom National Council on Archives (UK)).
Revised Nomenclature for Museum Cataloging. A Revised and Expanded Version of
Robert G. Chenhall's System for Classifying Man-made Objects, ed. by James R.
Blackaby und Patricia Greeno, Nashville 1989.
Rules for Archival Description, prepared by the Planning Committee on Descriptive
Standards of the Bureau of Canadian Archivists, Ottawa 1990.
Smiraglia, Richard P.: Describing Music Materials. A Manual for Descriptive
Cataloging of Printed and Recorded Music, Music Videos, and Archival Music
Collections, Lake Crystal 31997.
Thesaurus for Graphic Materials, compiled by the Prints and Photographs Division,
Library of Congress, Washington 1995.
Thesaurus of Geographic Names, Version 1.0, Los Angeles 1997.
<http://www.ahip.getty.edu/tgn_browser/>.*
Unesco thesaurus. A structured list of descriptors for indexing and retrieving literature
in the fields of education, science, social science, culture, and communication,
compiled by Jean Aitchison, Paris 1977.
Union List of Artists' Names, Version 2.0. Los Angeles 1998.
<http://www.ahip.getty.edu/ulan_browser/>.*
USMARC Concise Format for Bibliographic Data. 1994
<http://lcweb.loc.gov/marc/bibliographic/ecbdhome.html>.
(Herausgegeben mit 3 Aktualisierungen bis Juli 1997. Gepflegt von der Library of Congress, Network
Development and MARC Standards Office)
USMARC Code List for Countries, prepared by Network Development and MARC
Standards Office, Washington 1993.
White-Hensen, Wendy: Archival Moving Image Materials. A Cataloging Manual,
Washington 1984.
*
A.d.Ü.: Webseite nicht mehr existent.
300