Was sind und was sollen

Bibliothekarische Datenformate

Akronyme wie MARC, MAB, UNIMARC und PICA sind den meisten Bibliothekaren geläufig. Was genau steckt dahinter? Es sind "Datenformate", Normen für die Strukturierung der Katalogdaten. In Datenbanken muß jede Einzelheit der Daten präzise geregelt sein, damit Computer überhaupt etwas Sinnvolles damit tun können.
Auf keinen Fall könnte da jede Bibliothek ihr eigenes System entwickeln, und außerdem wollen und müssen Bibliotheken zusammenarbeiten und Daten austauschen. Dazu wurden die Normen entwickelt.
Die Original-Dokumentationen der genannten Formate sind für Insider konzipiert, die jeden Tag damit umgehen, und deshalb für Außenstehende kaum verdaulich. Wer sich mit mehr als einem Format beschäftigen will, muß zudem erst einmal die sehr unterschiedlichen Begriffe und Konzepte verstehen. Weil es dafür wenig Hilfestellung gab, wurde die vorliegende Sammlung von Materialien geschaffen. Ein größerer Teil davon ist das Buch mit dem Titel "Was sind und was sollen Bibliothekarische Datenformate", das in dritter Auflage elektronisch vorliegt.
Es bietet einen theoretischen Überblick und Kurzporträts der wichtigsten Formate.

Dieser Teil, den Sie jetzt lesen, soll eine knappe, fast nur schlagwortartig-plakative, etwas anders als das Buch angelegte Übersicht über die Hauptprobleme und einige wichtige Aspekte bieten.

Sinn und Zweck der Formate

Probleme mit Bibliotheksdaten

Was soll ein Katalog (ein OPAC)?

Dazu mehr in der Publikation "Was ist und was soll Katalogisierung?"
Ein Katalog erschließt einen Bestand, der sich in einer oder mehreren Bibliotheken befindet.
Wenn es mehrere Bibliotheken sind, spricht man von einem Gesamt- oder Zentralkatalog.
Man muß unterschiedliche Arten von Zugriffen unterscheiden, für die es jeweils eigene Regelwerke und/oder auch Normdateien gibt:

Formale Zugriffe  (RAK § 101)

Sachliche Zugriffe

Die bibliothekarische Katalogisierung hat unter anderem zum Ziel, wenigstens mit einigen wenigen Kriterien ein wirklich sicheres Auffinden zu ermöglichen. Für die formalen Zugriffe ist das erreichbar, für die sachlichen nicht!
Die Prinzipien der bibliothekarischen Katalogisierung sind international relativ einheitlich, jedoch zuletzt diskutiert worden 1961 in Paris (Aufgaben des Katalogs) und 1969 in Kopenhagen (ISBD).
Mit Blick auf die jüngsten Entwicklungen (Internet, Metadaten) scheint es sinnvoll, wenn nicht vordringlich, über die Prinzipien neu zu diskutieren.
 

Was soll eine Bibliographie?

Im Unterschied zum Katalog versucht eine Bibliographie, existierende Dokumente zu einem Thema oder unter einem Aspekt zusammenzufassen, ohne Rücksicht darauf, wo sich diese konkret befinden.
Wichtige Typen mit unterschiedlichen Aufgaben (Themen, Aspekten) sind

Je nach den Aufgaben der Bibliographie wird mit unterschiedlichen Prinzipien und Regeln gearbeitet, z.T. ebenfalls mit Normdaten (z.B. "Deutsche Nationalbibliographie").

Die Datenbanken der Internet-Suchmaschinen sind eher den Bibliographien als den Katalogen zuzuordnen, entstehen jedoch typischerweise vollautomatisch, d.h. ohne intellektuelle Erschließungsarbeit. Die unvermeidlichen, bekannten Schwächen des Retrievals sollen in Zukunft durch Metadaten ausgeglichen werden, die den Online-Dokumenten von deren Verfassern beigefügt werden sollen. Wieweit diese sich an Prinzipien, Regelwerke und Normen halten werden, und an welche, bleibt abzuwarten. Zwar könnte man in den Metadaten ein Analogon zu den CIP-Aufnahmen in Büchern erblicken, die letzteren werden jedoch nicht von den Verfassern, sondern von der Nationalbibliothek angefertigt.
 

Katalog-Denkmodelle

OPACs arbeiten hinsichtlich der Zugriffsmöglichkeiten mit zwei grundsätzlich verschiedenen Denkmodellen: Manche, wie Pica oder allegro, vereinigen allerdings beides in einem Konzept.
Inhalt, Gestaltung, Präsentation und Funktionalität der Browsing-Register sind höchst unterschiedlich ausgeprägt und nicht normiert, genauso wenig die Gestaltung von Suchformularen. Insbesondere sagen die Katalogisierungsregeln bisher dazu nichts aus. In den Diskussionen über RAK2 wird jedoch darüber jetzt nachgedacht.
Welche Register man wie gestalten kann, hängt auch von der Datenstruktur, also vom Format ab.

Text-Retrievalsysteme, wie sie typischerweise in Harvest-Konfigurationen eingesetzt werden, können nur das Frage-Antwort-Modell realisieren. Auch Web-OPACs folgen fast alle dem Modell "Frage-Antwort".
Aus mehreren Gründen ist dieses allerdings problematisch:
 

Frage - Antwort (Retrievalsprache) Browsing (sortierte Listen)
Zeigt nur "Treffer" (oder was das System als solche ansieht) Zeigt auch Umfeld (Schreibweisen und Fehler!)
Zehntausend-Treffer-Problem Macht erkennbar, wo und wie man suchen sollte
Null-Treffer-Problem Fehler und Fehleinschätzungen werden sofort bewußt
Suggeriert falsches Vorstellungsbild von Daten und Computer: die Daten seien exakt und der Computer beantworte Fragen. Erleichtert realistische Einschätzung: die Daten sind unvollkommen  und die Suchmöglichkeiten begrenzt

Ein kleines Beispiel ist weiter unten zu sehen: Wie findet man Beethovens "Fünfte"?.

Grundsätzlich gilt immer:
Ein OPAC-System sucht und findet nur die Wörter, die man eingegeben hat,  nicht die Begriffe, die man gemeint hat.
Das letztere ist Utopie.
 

Die wichtigsten Datenformate

 
Name begründet Teile Austausch/Intern Felder Umfang Doku Haupt-Verbreitung
USMARC (jetzt MARC21) 1969 5 Austauschformat ~330 >1000 S. USA, Canada, Austr., UK
Unimarc 1977 2 Austauschformat ~200 >500 S. Europa
MAB1/MAB2" 1972 5 Austauschformat ~700 >700 S. Deutschland
BIS 197? 1 Internformat   ~500 S. Deutschland
1992 1 Internformat >1300 ~300 S. D, NL, F ...
ZDB (ZETA) 1980 1 Internformat   ~100 S. Deutschland
allegro 1981 1 Internformat   ~50 S. Deutschland+

Austauschformate wurden zwar für den Austausch, also den Transport zwischen Systemen, entwickelt, sie werden aber regelmäßig auch (abgewandelt und erweitert) als interne Arbeitsformate in Systemen verwendet - obwohl sie dafür nicht entwickelt wurden. Daher kann man nicht erwarten, daß sie sich optimal für diese Aufgabe eignen. Eine Norm für Intern- oder Arbeitsformate gibt es allerdings gar nicht - was soll man also tun?
Zum Umfang oder Grad der Detaillierung der Formate ist es überraschend schwierig, etwas Brauchbares auszusagen. Die Anzahl der Felddefinitionen besagt zu wenig, weil einerseits z.B. Pica dann enorm umfangreich erscheint (über 1300 Nummern), aber sehr viele der Kategorien sind nur Mehrfachfelder, andererseits die ungeheure Vielfalt von Unterfeldern im MARC-Format dann unberücksichtigt bleibt. Der Umfang der Dokumentation gibt vielleicht am ehesten einen Eindruck, allerdings sagt die Seitenzahl nichts darüber aus, wie kompakt die Seiten bedruckt sind, wie groß dabei der Anteil von Wiederholungen immer wiederkehrender Teilfelder und Standardformulierungen ist, und vor allem, ob und wie in der Praxis der definierte Standard auch tatsächlich ausgeschöpft wird. Sehr aufschlußreich ist die Auswertung von USMARC-Daten, die unter "Top 33" weiter unten vorgestellt wird.
 

1:1-Konvertierung unmöglich

Die aufgezählten Formate sind allesamt nicht in dem Sinne kompatibel, daß eine 1:1-Umwandlung möglich wäre.
D.h. ein schlichtes Umordnen der Felder mit Ersetzung der Tags durch andere reicht in keinem Falle aus, höchstens für eine ganz grobe erste Näherung.
Im Einzelnen fallen Detailaufgaben der folgenden Arten an: Mit Konzepten wie Konkordanztabellen kommt man hierbei in aller Regel nicht aus, es müssen vielmehr Umwandlungsprogramme geschrieben werden. Für das allegro-System wurde eine eigene Datenmanipulationssprache geschaffen, mit der Konvertierungen programmiert werden können. Dennoch bleiben in jedem Fall Unzulänglichkeiten, die sich durch kein Programm beseitigen lassen. Das liegt nicht an strukturellen Differenzen, sondern an den "philosophischen" Unterschieden der Regelwerke und der Katalogisierungspraxis. Auch dies illustriert unten das Beethoven-Beispiel.
Besonders die Schreibweise von Namen (z.B. transliterierte Namen aus dem Russischen) läßt sich nicht einwandfrei umwandeln, Schlagwörter lassen sich nicht von einer Sprache in die andere automatisch übersetzen, aber auch sonst gibt es viele Differenzen in Details.
Eine wichtige Konsequenz: Wenn Datenbanksysteme über die Schnittstelle Z39.50 kommunizieren, muß man mit unzuverlässigen Resultaten rechnen, wenn unterschiedliche Formate (und Katalogregeln!) an beiden Enden benutzt werden.
Diese Schnittstelle wurde geschaffen mit Blick auf USMARC und die amerikanischen Verhältnisse, wo es zwar viele verschiedene Datenbanksysteme gibt, aber die Daten doch alle in USMARC nach denselben Regeln gemacht sind.
 

Zweimal Beethovens "Fünfte"

Um einen praktischen Eindruck zu vermitteln, hier zwei Datensätze: der erste ein USMARC-Satz, der zweite ein allegro-Datensatz. Es handelt sich um Aufnahmen von Beethovens Sinfonien, gespielt vom Orchestre Révolutionnaire et Romantique unter John Eliot Gardiner.
Das Kernproblem: Die zahlreichen Aufnahmen tragen die unterschiedlichsten Titel, die von den Verlegern anscheinend nach Lust und Laune formuliert werden. Soll der Katalog sicheres Auffinden gewährleisten, ist daher gerade im Musikbereich eine Normierung zwingend notwendig. Weniger ausgeprägt als im Musikbereich, aber im Grundsatz genauso, gilt das auch für Bücher und andere Dokumente, die in mehr als einer Ausgabe publiziert worden sind. Nicht nur bei Übersetzungen ändert sich dann oft der Titel, der Inhalt aber bleibt derselbe, und diesen, nicht den konkreten Titel, will man meistens finden!

USMARC : Die Produktion auf 6 CDs wird als Sammelwerk angesehen, daher macht man eine Gesamtaufnahme der 9 Sinfonien in einem einzigen Datensatz (Auflistung in Feld 505):
(Zeilenumbrüche gibt es in den gespeicherten Daten nicht, sie sind hier nur zur besseren Lesbarkeit eingesetzt.)

00L cjm  2200661 a
001 AFG1786
007 sd|fsngnn|||ed
008 950103p19941991gw syn   dhiz       ger d
024 1 $a2894399002
028 00$a439 900-2$bArchiv Produktion
028a00$a439 901-2$bArchiv Produktion
028b00$a439 902-2$bArchiv Produktion
028c00$a439 903-2$bArchiv Produktion
028d00$a439 904-2$bArchiv Produktion
028e00$a439 905-2$bArchiv Produktion
028f00$a445 907-2$bArchiv Produktion
033 10$a199111--$a199210--$a199212--$a199303--$b5754$cL7
035   $a(Sirsi) u1240727
035a  $a(OCoLC)31757284
040   $aCPL$cCPL
041 0 $dger$egereng$hger$genggerfre
045 2 $bd1800$bd1824
100 1 $aBeethoven, Ludwig van,$d1770-1827.
240 10$aSymphonies
245 00$a9 symphonies$h[sound recording]$cBeethoven
260   $aHamburg$bArchiv Produktion ;$aNew York$bManufactured and
      marketed by PolyGram Classics & Jazz$cp1994
300   $a6 sound discs$bdigital, stereo.$c4 3/4 in
500   $aArchiv Produktion: 439 900-2 (439 901-2--439 905-2; 445 907-2)
500a  $aTitle from box
500b  $aWords of the last movement of the 9th symphony by
      Friedrich Schiller; sung in German
500c  $aCompact discs; 2 containers, in box
500d  $aProgram notes by Peter Czornyj, Nicholas Marston,
      Jonathan Del Mar, and Clive Brown, and text with English
      translation (40 p. : ill.) included
500e  $aIncludes interview with John Eliot Gardiner, in English,
      German and French, with musical excerpts (6th disc)
505 0 $aNo. 1 in C major, op. 21 (25:00) -- No. 2 in D major, op.
      36 (34:00) -- No. 3 in E-flat major, op. 55 : Eroica (45:00) --
      No. 4 in B-flat major, op. 60 (32:00) -- No. 5 in C minor, op.
      67 (32:00) -- No. 6 in F major, op. 68 : Pastoral (41:00) --
      No. 7 in A major, op. 92 (39:00) -- No. 8 in F major, op. 93
      (25:00) -- No. 9 in D minor, op. 125 (59:43)
511 0 $aOrchestre révolutionnaire et romantique, on original
      instruments ; John Eliot Gardiner, conductor ; with, in the
      9th symphony: Luba Orgonasova, soprano ; Anne Sofie von Otter,
      mezzo-soprano ; Anthony Rolfe Johnson, tenor ; Gilles
      Cachemaille, bass ; Monteverdi Choir
600 10$aSchiller, Friedrich,$d1759-1805$xMusical settings.$?UNAUTHORIZED
650  0$aSymphonies.
700 10$aSchiller, Friedrich,$d1759-1805.
700a10$aGardiner, John Eliot.$4cnd
700b10$aOrgonasova, Luba.$4voc$?UNAUTHORIZED
700c10$aOtter, Anne Sofie von.$4voc
700d20$aRolfe Johnson, Anthony.$4voc
700e10$aCachemaille, Gilles.$4voc$?UNAUTHORIZED
710 20$aOrchestre révolutionnaire et romantique.$4prf$?UNAUTHORIZED
710a20$aMonteverdi Choir.$4prf$
 

allegro : Es wird jede Sinfonie einzeln erfaßt, also 9 Datensätze angelegt. Gezeigt wird hier nur der für die "Fünfte":
(Beethoven und das Orchester sind hier durch Codes vertreten (_b bzw. _orr), weil mit Normdaten für die Namen gearbeitet wird, sog. authority records.)
Im Unterschied zu MARC sind hier zusätzlich die einzelnen Sätze jeder Sinfonie erfaßt, siehe Feld  81m.

20  Sinfonie 5 in c-moll
30m sy
30t c-moll
52  _b                        (Das Kürzel _b steht in diesem System für Beethoven, Ludwig van)
57d Gardiner, John Eliot
61i _orr                      (Das Kürzel _orr steht für Orchestre revolutionnaire et romantique.)
77z 31:47
81m 1: Allegro con brio 6:30
    2: Andante con moto 8:15
    3: Allegro 7:12
    4: Allegro 9:50
89o 67
90  cb 42,1-4
99e 19970107
99n 19951202

So lang der MARC-Satz auch ist, er kann die wichtigste Anforderung im Musikbereich nicht erfüllen: die schnelle und sichere Auffindung der "Fünften". Man müßte dafür das Feld 505 heranziehen und die Opusnummer 67 wissen! Wenn es sich aber um eine Einzelaufnahme handelt, wird keine 505 erfaßt, sondern die Opusnummer kommt dann zusammen mit dem Titel in 245 oder 240 - d.h. man muß Einzelwerke anders suchen als Sammelwerke. Das ist wie früher im Zettelkatalog, aber USMARC wurde ja auch ursprünglich zur Automatisierung der Zettelproduktion entwickelt...
Der allegro-Satz dagegen ermöglicht es, ein geordnetes Register anzubieten, das folgendermaßen aussieht:
(Man beachte die Verweisung in der ersten Zeile. Diese kommt aus einem "Stammsatz", der eigens für das Werk angelegt wurde, nicht für eine konkrete Ausgabe. In den Titelsätzen steht der Nebentitel "Schicksalssinfonie" normalerweise nicht immer mit drin, nur wenn er ausdrücklich auf dem Medium steht!)

     1   beethoven, ludwig van: schicksals-sinfonie -> beethoven, ludwig van: sinfonie   5
   3   beethoven, ludwig van: sinfonie   1 in c
   1   beethoven, ludwig van: sinfonie   1 in c <1 adagio molto allegro con brio
   3   beethoven, ludwig van: sinfonie   2 in d
   1   beethoven, ludwig van: sinfonie   2 in d <3>
   3   beethoven, ludwig van: sinfonie   3 in es eroica
   1   beethoven, ludwig van: sinfonie   3 in es eroica <allegro con brio>
   1   beethoven, ludwig van: sinfonie   3 in es eroica <marcia funebre>
   2   beethoven, ludwig van: sinfonie   4 in b
   1   beethoven, ludwig van: sinfonie   4 in b <2 adagio>
   7   beethoven, ludwig van: sinfonie   5 in c-moll
   4   beethoven, ludwig van: sinfonie   5 in c-moll <1 allegro con brio>
   5   beethoven, ludwig van: sinfonie   6 in f pastorale
   1   beethoven, ludwig van: sinfonie   6 in f pastorale <1 allegro ma non trop
   1   beethoven, ludwig van: sinfonie   6 in f pastorale <4 gewitter, sturm>

Auf einen Blick sieht man hier, daß 7 Ausgaben der Fünften vorhanden sind und 4 Ausgaben vom ersten Satz, man sieht diese hier aber auch gleich im Zusammenhang mit den anderen Sinfonien.
 

Die wichtigsten Datenfelder

Alle genannten Formate haben mehr als 100 Felddefinitionen, manche haben mehrere hundert, jedoch sind in jedem konkreten Datensatz nur ein Bruchteil davon wirklich besetzt. Viele Elemente treten in der Tat nur selten auf, andere werden aber in der Praxis der jeweiligen Bibliothek nicht in jedem Fall ausgefüllt. Instruktiv ist da eine Statistik, die aus einer sehr großen Datenmenge abgeleitet wurde. In Göttingen wurden sämtliche USMARC-Datensätze von Druckschriften der Library of Congress analysiert. Hier die Zusammenfassung der wichtigsten Ergebnisse:

TOP 33
The 33 most frequently used fields in LC USMARC data
Die 33 häufigsten Datenfelder in den Daten der Library of Congress
-----------------------------------------------------------------------------------------------

Basis: Auswertung Ende 1997 beim GBV in Göttingen. Es wurden 4.106.347 bibliographische USMARC-Datensätze ausgewertet. Diese enthielten 74.226.036 Datenfelder, im Durchschnitt sind das 18 Felder je Satz. Die Gesamtanzahl der Teilfelder wurde nicht ermittelt.

Nicht gewertet: Verwaltungskategorien, wie IdNummer, Erfassungsdatum, Zugangsnummer, erfassende Bibliothek etc., also alle Felder, die nicht als Metadaten im eigentlichen Sinne anzusehen sind.
(Das sind "Metadaten 2. Ordnung", weil sie nicht über das Dokument, sondern über dessen Datensatz etwas sagen.)

Alle anderen Kategorien kommen in weniger als 1% der Datensätze vor!
Es wäre aber ein voreiliger Schluß, diese seien unwichtig und könnten abgeschafft werden.

Tatsächlich verwendet sind in den Daten etwa 60 weitere Felder, nicht gerechnet die Verwaltungsdaten.

Am Rande bemerkt: die relativ neue Kategorie 856 (URL etc.) kam nur 56 mal vor.
Die Tabelle gibt in der rechten Spalte auch an, zu welchem Element des Dublin Core-Schemas für Metadaten man die Kategorie zuordnen kann. Zum Thema Dublin Core steht an anderer Stelle mehr.

 %    Z TAG  Element                                           "Dublin Core"
---------------------------------------------------------------------------
100%  Z 245  Titel                                             TITLE
      Z 260  Erscheinungsvermerk (Ort, Verlag, Jahr)           PUBLISHER
      Z 300  Physikalische Beschreibung (Seitenzahl etc.)      ???
        050  LoC Classification                                SUBJECT
               (Systematische Aufstellungssignatur der LoC)
      Z 008  Codes,                                            LANGUAGE
               u.a. Sprache des Textes,                        TYPE
               Erscheinungsland, -zeitraum, Dokumenttyp

?95%    650  Sachschlagwort                                    SUBJECT
             (es sind weniger als 100%, da wiederholbar!)

 72%  Z 100  Erster Verfasser                                  CREATOR

 67%  Z 020  ISBN                                              IDENTIFIER
        500  Fussnote (allg. Anmerkung)                        DESCRIPTION

 63%    082  Dewey Decimal Classification                      SUBJECT

 50%    043  Regionalschlüssel (Geographic Area Code)          COVERAGE

 49%    504  Bibliography note                                 DESCRIPTION

 43%  Z 700  Beteiligte Personen                               CONTRIBUTOR

 25%    651  Geographisches Schlagwort                         COVERAGE

 18%  Z 250  Ausgabevermerk (Auflage, Version)           ???
        710  Beteiligte Körperschaft                           CONTRIBUTOR
        490  Reihe/Serie (unkontrolliert)                      RELATION

 17%    440  Reihe/Serie (kontrollierte Ansetzung)             RELATION

 14%    600  Personenname als Schlagwort                       SUBJECT

  9.4%  740  Weitere Titel (Nebentitel etc.)                   TITLE

  8.2%  830  Titel eines übergeordneten Werkes (Einheitstitel) RELATION

  7.3%  110  Primärkörperschaft (Urheber des Werkes)           CREATOR

( 7%    041  Sprache des Textes -> 008'35-37 )                 LANGUAGE

  6%    610  Körperschaftsname als Schlagwort                  SUBJECT

  4%    520  Inhaltliche Zusammenfassung (kurzes Abstract)     DESCRIPTION

  3.8%  130  Einheitstitel als Haupteintragung                 TITLE

  3.3%  505  Band- oder Kapitelangaben (meist mehrbd)          DESCRIPTION

  2%  Z 111  Veranstaltung, meist Kongress (mit 711 : 2.5%)    ???

  1%    653  Freies (unkontrolliertes) Schlagwort              SUBJECT
        655  Gattung/Genre als Schlagwort                      SUBJECT
        630  Titel eines Werkes als Schlagwort                 SUBJECT
        060  Klassifikation der National Library of Medicine   SUBJECT
        810  Serientitel unter Körperschaftsname               RELATION
        730  Einheitstitel als Nebeneintragung                 TITLE
        533  Reprint-/Reproduktionsvermerk                     RELATION?

Das Z steht für "Zuverlässigkeit". Es besagt: wenn dieses Element bei einer Publikation vorkommt, dann ist es auch erfasst, und zwar konsistent. Nur auf solche Kategorien kann man sich bei einer Suche demnach mit einigem Vertrauen verlassen und bei ausreichender Kenntnis die Titel mit dem ersten Zugriff finden.  Die Sach-Kategorien fallen alle nicht hierunter!

Nicht für alle Kategorien gibt es einen Platz in den Dublin Core elements, obwohl diese auch und gerade mit Blick auf die wirklich wichtigen Datenelemente entwickelt wurden. Jedoch ist DC ein Minimalkonsens, und ein Minimum ist kein Optimum.
Dem Element DC.FORMAT  würde USMARC 516 "Type of computer file" entsprechen, dieses Feld wurde  allerdings von der LC überhaupt nicht verwendet. Angaben über den Dateityp kommen am ehesten in 538 "System details note" versteckt vor, dieses ist aber eine Fußnotenkategorie und als solche nicht normiert, tritt allerdings auch nur 574mal auf. Die LC hat eben erst wenige elektronische Materialien erfaßt.

Eine Entsprechung zum DC-Element RIGHTS gibt es bisher in USMARC nicht, jedenfalls nicht in den real existierenden Daten. (Das Tag 017 "Copyright Registration Number" kommt ganze 1171mal vor.)

Auch für das DC-Element SOURCE gibt es keine richtige Entsprechung, Angaben dieser Art finden sich am ehesten in Fußnoten, sind dort aber nicht als solche per Programm zu erkennen.

Summa summarum: aus MARC-Daten können nicht automatisch gute DC-Daten gemacht werden und noch weniger umgekehrt. (Mehr dazu im Kapitel über Dublin Core.)

USMARC-Daten sind bislang immer noch viel stärker als MAB in der Tradition und Denkweise der Zettelkataloge verwurzelt.


Bernhard Eversberg
UB Braunschweig, 1998-03-19, rev. 1999-01-25