Kap. 4 : Bibliotheksdaten - Vor- und Umfeld

Kap. 6: Entwurfsgrundsätze

Die einzelnen Datenelemente, die in Bibliotheksdaten vorkommen können, haben höchst unterschiedliche Eigenschaften und Funktionen. Eine schlichte Einteilung in numerische, Zeichenketten- (mit fester oder variabler Länge) und Datumsfelder, die auf der Ebene D6 reichen würde , ist auf der inhaltlich-funktionalen Ebene D7 ungenügend. Hier wird versucht, ein geeignetes Raster für die Charakterisierung auf dieser Ebene aufzustellen.
Konflikte können auftreten, wenn ein Element mehr als eine Funktion hat, zumal wenn es um einerseits beschreibende, andererseits indexrelevante Funktionen geht. Es gibt daher gerade in den Austauschformaten MAB und MARC einige scheinbare Redundanz, z.B. wenn Namen doppelt erfaßt werden: einmal in Vorlageform (Typ D), zum zweitenmal in Ansetzungsform (Typ A) für die Indexierung.

In Grün und mit  (x)  gekennzeichnet erscheinen diejenigen Typen, bei denen Normdaten zum Einsatz kommen können.

A  Ansetzungsdaten und Normdaten (x)
Relevant für Ordnung und Zugriff (Indexierung)

Dies sind Elemente, deren Schreibweise (= "Ansetzung") durch Regelwerke normiert wird, z.B. "Regeln für die Alphabetische Katalogisierung (RAK)" und "Regeln für den Schlagwortkatalog (RSWK)"

Zumindest Namen mußten früher schon in einer einheitlichen Form erfaßt werden, wenn man z.B. in der Lage sein wollte, alle vorhandenen Werke eines Verfassers mit einem Zugriff aufzufinden. Wenn man Katalogkarten oder Literaturlisten produziert, werden diese Datenelemente für die Ordnung herangezogen.

A1. Normdaten
Personen- und Körperschaftsnamen (Normdateien wie PND, GKD, LCNA), Schlagwörter (Thesaurus, sog. "kontrolliertes Vokabular" wie SWD oder LCSH), Einheitssachtitel, Serientitel, Sachgruppe  (nicht auf einzelnes Dokument bezogen).
Sog. "Mehrdateisysteme" speichern im Dokumentsatz nur die Identnummer eines "Stammsatzes" oder "Normsatzes", z.B. für Personen oder Körperschaften. Diese Sätze stehen dann oftmals in eigenen Dateien ("authority files"), auf die sich dann die Identnummern beziehen. Ein Normsatz ("authority record") enthält in der Regel eine Hauptansetzungsform, Verweisungsformen und Synonyme dazu, sowie oftmals Hinweise auf andere Sätze (z.B. übergeordnete oder frühere/spätere Formen).

A2. Ansetzungsdaten
Angaben, für die es zwar keine Stammdaten gibt, deren Schreibweise aber präzisen Normierungsregeln folgt, die durch Vereinheitlichung für eine zweifelsfreie und konsistente Ordnung ermöglichen sollen.
Bei Online-Katalogen merkt man immer mehr, daß z.B. Erscheinungsorte, Verlagsnamen und Erscheinungsjahre ebenfalls normiert werden müss(t)en (anders als beim Zettelkatalog), wenn man sie für Zugriffe benutzen will. Die Regeln (RAK) sahen dies bisher noch nicht konsequent vor.Die Verbindung zwischen den Normdateien ("authority files") und den eigentlichen Buchdaten leisten Verknüpfungsdaten (siehe V), in der Regel  Identifikationsnummern.
Einige Elemente werden zusätzlich in ihrer "Vorlageform", so wie sie im Buch stehen, erfaßt; siehe D.
 

B  Bestandsabhängige (bibliotheksspezifische) Daten

(soweit katalogrelevant, ansonsten siehe G; oft in eigenen "Exemplarsätzen")

B1. (Summarische) Bestandsangaben (bei Zeitschriften), Lückenangaben

B2. Standortangaben und Besitzvermerke (Signaturen, Sonderstandorte)

B3. Exemplardaten

B4. Verfügbarkeit (z.B. "vermißt", "Dauerleihgabe", "nicht verleihbar")
 

C  Codierte Angaben
(soweit inhaltlich relevant, ansonsten siehe E)

Beispiele:

• Dokumententyp (Zeitschrift, Report, Dissertation, Bibliographie, Festschrift, Wörterbuch, ...)
• Medium (Buch, Mikrofilm, Diskette, Ton-/Videokassette, Karte, Noten, ...)
• Erscheinungs-/Herstellungsland; Provenienz
• Geographischer Code
• Sprache des Textes
• Erscheinungsjahr etc.
• Code für einen historischen Zeitraum, normierte Datumsangaben (z.B. Tagungsdatum, Vertragsdatum)
• Mathematische Angaben: Koordinaten, Maßstabsangaben etc. (Karten); solche Angaben kann man in codierter oder normierter Form speichern, damit für bestimmte Programmieraufgaben der Umgang mit diesen Elementen erleichtert wird (Indexierung, Auswertungen, Selektionen etc.)Einige Formate (MAB, MARC) haben Felder fester Länge ("fixed fields") für solche Daten.

D  Deskriptive Daten (ISBD)  (x)
(inhaltsbezogen, nur für einzelnen Datensatz relevant)

Es gibt viele unterschiedliche Elemente, erfaßt werden im wesentlichen:

Sachtitel-, Verfasser-, Erscheinungs-, Ausgabe- u. Umfangsangaben, und zwar meist in der "Vorlageform", d.h. so, wie diese Dinge wirklich im Buch stehen ("Vorlageform" im Unterschied zur "Ansetzungsform", siehe A).

Ferner gibt es ergänzende Angaben wie z.B. diverse "Fußnoten".

D1. Retrieval-relevante Daten. Solche Elemente werden oft indexiert, also für das Retrieval aufbereitet, auch wenn es keine normierenden Ansetzungsregeln gibt. In manchen Fällen gibt es zusätzlich ein Ansetzungsfeld, das ausgefüllt wird, wenn die Beschreibungsform nicht für's Retrieval geeignet ist.

D2. Rein deskriptive Daten. Diese sind nur als beschreibende Angaben nützlich.Diese zwei Arten von Elementen lassen sich nicht ganz exakt voneinander abgrenzen. Insbes. Kommentare (RAK: Fußnoten) gehören hierher.

E  EDV-spezifische Daten
(meist auf einzelnen Datensatz bezogen; nicht inhaltlich relevant, nur für Verarb.; ansonsten siehe C, V)

E1. Steuerzeichen (z.B. Satz- und Feldbegrenzungen; Verarbeitungscodes z.B. f. Kartendruck; Nichtsortiercode)
Auch Elemente der Satzbeschreibung (z.B. Längenangaben, sog. "directory", Kategorienummern, Teilfeldkennung)

E2. Datums- und Uhrzeitangaben (Erfassung, Änderung)
 

G  Geschäftsgangsdaten
(nicht katalogrelevant, keine bibliographischen Daten, meist auf Vorgänge bezogen und nur temporär)

es gibt eine große Zahl von möglichen Datenelementen für die Bereiche

G1. Benutzung (Ausleihangaben, Benutzerdaten)

G2. Erwerbung (Bestell- und Rechnungsangaben, Lieferantendaten)

G3. Statistikdaten
 

H  Hilfsdaten

H1. Satzbezogen: z.B. Nebeneintragungs-Vermerke

H2. Satzunabhängig: siehe-Verw., siehe-auch-Hinweise, Pauschalverweisungen
 

I  Identifikationsnummern

I1.  Systemübergreifende Nummern (ISBN, ISSN, CODEN)

I2.  Systemeigene oder -abhängige Nummern (LC, BNB, DB, ZDB, GKD, Pica, OCLC, NMN)
 

K  Klassifikationsdaten (x)

K1. Überörtliche Notationssysteme (UDK, DDC, LC, DB-Sachgruppe)

K2. Lokale Klassifikationsdaten (Katalogsystematik, Aufstellungssignatur)
 

S  Schlagwortdaten, verbale Sacherschließung  (x)

S1. Überörtliche Daten (u.U. als Id-Nummern: LC, RSWK, PRECIS)

S2. Lokale Erschließungsdaten (Schlagwort, Thesaurusbegriff, Stichwort)
 

T  Textdaten
(Text des Dokuments)

T1. Volltext oder Auszüge aus dem Dokument, Zitate

T2. Abstract

T3. Inhaltsverzeichnis (s.a. D : Fußnoten)
 

V  Verknüpfungsdaten - Verbindungen zwischen Datenfeldern oder -sätzen

V1. Verknüpfungen bibliographischer Natur (oft in Fußnoten)

• Ausgabe <==> Originalwerk

• Titel <==> früherer/späterer Titel, Teilung/Vereinigung...

V2. Verknüpfungen datentechnischer Natur: Verknüpfungen zwischen Dateien und innerhalb von Dateien
(oft nur für den Programmierer als solche "sichtbar")

• Band <==> übergeordnete Gesamtheit (mehrbänd. Werk, Serie; evtl. mehrere Hierarchiestufen)
• Name <==> zugehörige Titeldaten (siehe A, D.)
• Schlagwort <==> zugeordnete Dokumente
• Verknüpfungen zwischen zusammengehörigen Feldern innerhalb eines Datensatzes.

(Beispiele: "$-Verweisungen" im Pica-Format, "Montagetechnik" im SWB-Format, Felder in anderen Schriften in USMARC)

X  Austauschbezogene Daten (eXchange)

(relevant für Bibliotheken, die sich gegenseitig mit Daten beliefern)

• Satzstatus (CIP, Neuaufnahme, Korrektursatz)

• Angaben über Herkunft und Eigenschaften der Daten

• Nachricht für Empfänger des Austauschsatzes.

Spezifische Datentypen des Anwenders

x heißt: hier können auch Identifikationsnummern vorkommen, die sich auf andere Dateien oder Fremddatenbestände beziehen (z.B. Namensdaten: GKD; fortlaufende Sammelwerke: ZDB). Die Software muß dann mit einer "Verknüpfungstechnik" ausgestattet sein.

5.1 Zum Thema Austauschformat - Internformat

Die ersten Formate mit Normcharakter waren die Austauschformate MARC (MAchine-Readable Cataloging, ab 1968) und MAB1 (Maschinelles Austauschformat für Bibliotheken, Version 1, ab 1972). Diese hatten zunächst das Ziel, die jeweiligen nationalbibliographischen Daten per Magnetband transportieren zu können. Nur sehr wenige Institutionen konnten überhaupt mit solchen Daten arbeiten. Online-Systeme existierten noch nicht, alle Verarbeitungen fanden als Stapelproduktion statt, Daten wurden nicht menügesteuert erfaßt, sondern an geräuschvollen, fernschreiberähnlichen Maschinen "abgelocht"! Die EntwicklerInnen verdienen alle Anerkennung für ihre Leistungen, denn die DV-Systeme der sog. 2. Generation jener Zeit erscheinen aus heutiger Sicht steinzeitlich. Produkte von der Qualität der Deutschen Bibliographie oder der Library of Congress Catalog Cards sind aber auch mit heutiger Hard- und Software noch nicht mühelos zu erstellen. Das ist nicht so sehr eine Frage des Formates, sondern es handelt sich nun einmal um komplexe Produkte. Die Erwartungen der heutigen Bibliothekswelt gehen jedoch bekanntlich darüber weit hinaus. Sind deshalb MAB und MARC als "Steinzeitformate" abzutun? Aus mehreren Gründen nicht:

• Die Formate wurden kontinuierlich ausgebaut und verfeinert sowie ausführlich dokumentiert.

• Nicht mehr nur die Nationalbibliotheken, sondern auch die bedeutenden Verbundeinrichtungen bedienen sich der Standardformate für den Austausch. Sie haben auch an der Weiterentwicklung mitgearbeitet und viele neue Anforderungen und Erfahrungen eingebracht.

• Es liegen ungeheuer viele Daten in diesen Formaten vor. Bibliothekspersonal ist allenthalben durch den ständigen Umgang damit auf diese Strukturen eingeschworen. In vielen lokalen Datensystemen hat man aus diesen Gründen und mangels anderer offizieller Normen die Austauschformate auch als Internformat für die lokale Verarbeitung übernommen, oder dies wird sogar als Bedingung in Ausschreibungen verlangt. Die Frage ist daher berechtigt, ob die ursprünglich als Magnetband-Austauschformate konzipierten MAB und MARC denn den Ansprüchen heutiger Online-Systeme wirklich noch entsprechen. Ein Austauschformat ist schließlich so etwas wie ein Möbelwagen: man muß darin alles, was vorkommt, transportieren können, und zwar in großen Mengen, ohne Rücksicht auf Sinn und Zweck. Das sind aber nicht die Forderungen, die man an ein Alltagsfahrzeug stellt. Die folgenden Anmerkungen sollen dem Leser Anregungen für eine eigene Einschätzung geben.

Seit 1998 ist die Notwendigkeit anerkannt, zumindest Richtlinien für die Indexierung von Katalogdaten zu formulieren. Zu dem Zweck hat die "Konferenz für Regelwerksfragen" mittlerweile eine Arbeitsgruppe eingesetzt.

Lokale Systeme brauchen oft zusätzliche Elemente, die im Standard nicht vorgesehen sind, weil sie für einen Austausch nicht relevant sind. Notgedrungen schafft man sich Abhilfen, indem man neue Datenfelder selbst definiert. Das gilt in besonderem Umfang für Geschäftsgangsdaten der Bereiche Ausleihe und Erwerbung, die von den Austauschformaten prinzipiell nicht abgedeckt werden. Betroffen sind Daten von Benutzern und Lieferanten, Bestelldaten, Ausleihparameter, Fristen, Gebühren, Statistikdaten - alles das ist nicht normiert und mußte an vielen Stellen jeweils neu konzipiert werden.

Die Austauschformate enthalten andererseits aus lokaler Sicht recht viel Redundanz und lokal gar nicht benötigte Angaben. Der Möbelwagenfahrer fragt ja auch nicht, ob alles, was er transportiert, am Zielort wirklich gebraucht wird. Er bringt's erstmal hin. Aus Gründen der Speicherökonomie ist Redundanz unerwünscht, d.h. man muß fragen, ob man alle Elemente eines MAB- oder MARC-Satzes aufbewahren will, und ob man sie in genau dieser Form aufbewahren will.

Da es aus diesen Gründen für lokale Systeme in der Regel einen Verlust von Effizienz (Rechenleistung und Speicherplatz) bedeutet, die Daten im Austauschformat zu verwalten, wird oftmals intern eine andere Form verwendet, nach außen aber so getan, als habe man MAB. Das ist völlig legitim. Solange es möglich ist, Austauschdaten im Standardformat zu übernehmen und selbst abzugeben, solange man also in diesem Sinne kompatibel ist, kann das System in seinem Innern durchaus ganz andere Wege gehen. Man geht immer mehr dazu über, komfortable Erfassungs- und Bearbeitungsprogramme (Editoren) zu entwickeln, die das zugrundeliegende Kategoriesystem am Bildschirm überhaupt nicht mehr sichtbar machen. Erstens ist dies jedoch ein großer Programmieraufwand (mit Standard-Datenbanksoftware kommt man da nicht aus), und zweitens: je größer die strukturellen Unterschiede zwischen Oberfläche und Innenwelt und zwischen Lokalformat und Austauschformat sind, umso schwieriger sind selbstverständlich die Umwandlungen zwischen diesen Strukturen, umso größer auch die Gefahr von "Reibungsverlusten", und umso mehr wird qualifiziertes Personal benötigt, um diese Dinge zu beherrschen. Das gleichzeitige Arbeiten mit zwei oder mehr Formaten stellt beträchtliche Anforderungen an den Bearbeiter und erhöht den Einarbeitungsaufwand für neue Mitarbeiter. Vor allem diese Problematik mag die treibende Kraft sein, wenn allen anerkannten Schwierigkeiten und Defiziten zum Trotz immer wieder nach "echten" MAB-Systemen gerufen wird. Aber dienen die Kataloge letztendlich der Bequemlichkeit des Bearbeiters? Und wer fährt einen Möbelwagen als Privatfahrzeug, nur weil er ihn gelegentlich mal als solchen braucht?