[rak-list] MARC ohne Deskriptionszeichen?

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Rohde, liebe Liste,

[ich habe laenger gezoegert, diese Mail abzuschicken, weil sie beim
Schreiben eine eigene Dynamik entwickelt hat, aber sei's drum]

ich habe just in den letzten Tagen an einem Export von Bibliotheksdaten
nach MARC21 (nicht "D-MARC") herumgedoktort, aber Sie bringen die
Sache mit diesem Beispiel schoen auf den Punkt:

> 500 Ursprünglich ersch.: London : Gray, 1871

> Was fällt auf? Die Verlagsangabe entspricht mit Ortsname Spatium Doppelpunkt
> Spatium Verlagsname (evt. noch Komma Spatium Jahreszahl) genau den Regeln, die
> uns bekannt sind. [...]

und

> Grundsatz in unseren Katalogen ist doch gerade, dass wir strukturierte Daten
> haben und diesen Strukturen Regeln zugrunde liegen. Und gerade in eigentlich
> unstrukturierten Fussnoten tut es meineserachtens Not, doch bei Bedarf eine
> gewisse Struktur zu haben, die durch die Regeln, in diesem Fall ISBD, vorgegeben
> sind. [...]

Ich sehe hier ein grundsaetzliches Versagen zumindest von Datenmodell
und Datenformats, das das simultane Zurueckfallen auf das unspezifischste aller
Datenfelder und die ISBD als Mutter aller Deskriptionsregeln erzwingt.
Und wenn ich nicht alle (gleichartigen) Daten gleichartig strukturieren
kann, dann ist die Strukturierungsmoeglichkeit fuer die verbleibenden
Faelle schnell fragwuerdig: Wenn doch nicht alle Verlage als solche
erfasst sind, ist die unspezifische Stichwortsuche ueber alle Felder
u.U. die angemessenere Form, sich dem Katalog zu naehern...

Mir faellt auf, dass MARC21 noch hypertropher als MAB ist, alles moegliche
und unmoegliche wird akribisch mit Unterfeldzeichen getag(g)t.

Andererseits ist es wirklich nur ein Tagging, im Fliesstext eines Datenelements
wird markiert, dass hier nun eine bestimmte Art Information beginnt. Darauf
kann dann etwas anderes folgen und dann wieder dieselbe Art, dann wird wieder
das entsprechende Tag gesetzt. Oder aber es folgt nichts anderes, zwei
gleichartige Informationen folgen aufeinander, dann wird kein weiteres Tag
gesetzt (ich denke jetzt ausnahmsweise nicht an den notorischen Brei in
Feld 245, sondern an 3XX oder 7XX). Es ist mir inzwischen absolut unklar, wozu
das ganze nutzen soll, denn mit "Daten" hat das alles wenig zu tun, an die
kommt man einfacher, wenn man das MARC-Tagging verwirft und die
ISBD-Interpunktion analysiert (die ist natuerlich nicht dafuer gedacht,
aber recht tragfaehig).

Und drittens bleibt dort, wo es interessant wird, naemlich bei Bezuegen
zu anderen Ausgaben, Werken etc. noch viel haeufiger nur der Ausweg
in die unspezifische Fussnote, wo es ueberhaupt keine weitere Auszeichnungs-
moeglichkeit gibt und auch das Notieren von ISBD-Interpunktion durch die
Katalogisierer ueberhaupt keinen Wert hat, denn nicht einmal die einleitende
Wendung, die aussagt, welcher Art die folgende Aussage ist, laesst sich
als solche kennzeichnen.

Das sind jetzt natuerlich Aussagen ueber MARC und auch nichts neues. Mir
daemmert aber immer mehr, dass man mit MARC noch weniger Datenverarbeitung
betreiben kann als mit MAB. Und angesichts der Tatsache, dass man sich
da seit 40 Jahren in die Tasche luegt (dass naemlich durch Katalogisierung
mit dem Computer irgendeine Form von Bibliotheks-Daten entstanden seien),
sehe ich auch die Chancen auf ein brauchbares Regelwerk zu unseren
Lebzeiten zunehmend pessimistischer: Die Aufgabe, ein "modernes" Regelwerk
zu schaffen, das bei "bekannten" Materialien moeglichst AACR-Kompatibel
(wegen des Personals) und MARC-Kompatibel (wegen der Altdaten) sein soll,
und gleichzeitig an der "Ueberwindung" von MARC zu arbeiten, ist ja schon
geradezu muenchhausensch im Ausmass. Wenn man nun aber bedenkt, dass die
AACR2 zeitlich lange nach MARC entstanden sind und MARC gewiss im Blick
hatten, und dass MARC, je genauer man hinsieht, sich als ueberwaeltigende
Form Hoeheren Unfugs entpuppt, dann ist die Aufgabe also, ausgehend von
einer nicht wirklich eingestandenen doppelten Verankerung im
Vor-Datenverarbeitungszeitalter Regelwerk und Datenformat gleichzeitig
zu modernisieren (das wollten wir hier ja auch und glaubten, uns durch
Rekurs auf angelsaechsische Entwicklungen geschickt um die Arbeit
druecken zu koennen), wobei aber erschwerend hinzukommt, dass die als
erhaltenswert und zu beruecksichtigend angesehene "Substanz" (der Output
der gesamten Profession in den letzten Jahrzehnten) ein Popanz ist, der
mit seiner "etablierten Praxis" nur den Blick auf die durch Regelwerk
und Datenformat zu loesenden Aufgaben verstellt.

Moeglicherweise waere es zielfuehrender, die abgebrochenen Kartenkataloge
erneut zu scannen, zu ocerisieren und mit diesen ISBD-basierenden Texten
ein zweites Mal den Einstieg ins Computerzeitalter zu versuchen (Google
laesst gruessen).

Ganz im Ernst: Wir haben ein paar konzeptionelle Dokumente, die internationalen
Konsens gefunden haben (Statement of Principles, die *Konzepte*, die in
den ISBD behandelt werden) und wir haben Ansetzungsregeln und grosse
Normdateien fuer Personen und Koerperschaften. Das halte ich alles fuer
solide. Was aber Titeldaten angeht, so haben bislang Regelwerke und Daten-
formate Hand in Hand daran gearbeitet, mit moeglichst viel intellektuellem
Input einen Output zu produzieren, der voellig defizitaer ist (Abkuerzungen,
umformulierte Titel, unterschlagene Herausgeber, fehlende Struktur,
fehlende oder ungeeignete Verknuepfungspardigmen, Ueber- und
Unterdifferenzierungen, verschlafene Entwicklungen, kodifizierte
Irrtuemer usf.). Da, wo unsere Kataloge brauchbar sind, waeren sie es
vermutlich auch, wenn es nur fuenf Datenfelder gaebe und statt der
deskriptiven Portionen unserer Regelwerke waeren wir mit einem
"Content Standard", der vor allem festschreibt, welche Aspekte zu
beschreiben sind und das Wie der Angelegenheit nicht so wichtig nimmt,
sogar besser bedient.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk6qtLsACgkQYhMlmJ6W47PQ7gP+KJuc86mUWo3MXaprBFOyTuec
7dDWMUv0bUudEHudgJZk07+rx3oazd73tGIqp/o6/Cc2Dnb0WFIzJpZV0NbA73lj
092WvI+sDTjtzVLBphkBFUxomwU86doV3IpRyJokb/eewt2xN12u+UUGkkE31A2w
pOMaBHI4A2YTrRWQLc8=
=Bxg5
-----END PGP SIGNATURE-----