Vb. XML

[Thomas Berger]

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

Lieber Herr Eversberg,

| Man wird, wie immer, abwarten muessen, wieviel Wahrheit in dieser
Sonder-Vb gesteckt hat.

wie immer vermutlich mehr als beabsichtigt :-)

| Wir haetten ja laengst einen XML-Export gemacht, wenn es das
| allgemein akzeptierte Schema fuer Katalogdaten schon gaebe. Ein
| selbstgstricktes mag noch so gut sein, es wuerde immer noch als
| "proprietaer" beschimpft und sich nicht durchsetzen koennen.

Auch wenn wir $A.CFG einmal NMN nennen, wird es wohl immer noch noch
"proprietaer" sein. Und was die Anwender daraus machen, ist wieder
eine andere Sache: Ein versierter Anwender ergaenzt die Kategorie,
die er braucht, in der Abfrageliste, ein weniger Versierter definiert
eine vorhandene fuer seine Zwecke "im Kopf" um. Anderes Beispiel: Diese
Woche fand ich z.B. irgendwo den Standort konsequent als "lokale
Bemerkung", wohl weil aus Zufall die Kategorie fuer "Standort" nicht
durch die Abfrageliste in der .CFG nicht praesentiert wurde.

Ich denke, es ist ein bibliothekarischer Irrtum, ueberhaupt nur an
etwas wie "allgemein akzeptiertes Schema fuer Katalogdaten" zu denken.
Der Irrtum kommt daher, dass wir des oefteren denken, es gaebe
"allgemein akzeptierte Regeln fuer Katalogisierung".

Der schiere Umfang der Regelwerke RAK oder AACR laesst uns vergessen,
dass es sich um die Formulierung eines Minimums handelt (obwohl:
von Herrn Popst wird kolportiert: "Sie duerfen mehr machen oder
auch weniger, Sie duerfen es bloss nicht anders machen"). Jede
Bibliothek (vermutlich selbst die mikroskopischste OeB) hat irgendwo
das Beduerfnis, eine auf den eigenen, speziellen Bestand zugeschneiderte
Spezialerschliessung zu leisten. Weil RAK so maechtig ist, wird das
dann "Sacherschliessung" genannt, egal was es ist, denn dort haben
sich die RSWK noch nicht so breit durchgesetzt (und DDC noch viel
weniger :-).

Umgekehrt sind die Austauschformate die Formulierung eines *Maximums*
(o.k. MARC erlaubt Transport von Buchstabenfeldern als Lokale
Zusatzinformation, da ist dann aber nichts standardisiert). Das
fuehrt dazu, dass die Spezifikationsdokumente fuer MAB gerade mal
in zwei Aktenordner passen und trotzdem jegliche Zusatzinformation
bereits beim Export vernichtet werden muss: Es handelt sich ueberspitzt
gesagt nur um die maximale Formulierung fuer den Transport des vom
Regelwerk vorgeschriebenen Minimums.

Ich finde, dass wir dringend Austauschformate benoetigen, die beim
Export dem Lieferanten die Freiheit lassen, das zu liefern, auf
was er Wert legt und das Verwerfen von subjektiv nutzlosen Daten
staerker auf die Importseite verlagern. Das Zauberwort fuer solche
Formate ist "eXtensible" (daher z.B. das "X" von "XML").

Was Nummern oder Texte angeht: Es ist schon endlos diskutiert
worden, dass "Title" oder "Titel" nur eine grobe Naeherung an das
darstellt, was MAB als "331" bezeichnet. Eine der wenig hinterfragten
Grundannahmen des Deutschen Bibliothekswesens ist die Identitaet
zwischen dem, was MAB als "331" bezeichnet und die RAK als "HST
in Vorlage- oder Mischform" (hier werde ich unsicher: Oder ist das
die Definition aus der MAB-Spezifikation, die es mit diesem Vokabular
in RAK ueberhaupt nicht gibt?). Vom im Verlauf der RAK-Weiterarbeit
entstehenden Glossar erwarte ich hier die terminologische Grundlage,
auf der man dann beginnen kann, das Verhaeltnis von RAK und MAB
ernsthaft zu untersuchen...

Ich behaupte nun aber auch, dass ein Katalogisierer, der die Felder
"331" (HST) und "335" (Zusatz) zur Verfuegung stehen hat, im Laufe
der Zeit anders katalogisieren wird als einer, der ein Feld #20 (HST :
Zusatz) plus evtl. #25 (auch Zusatz). Das Katalogisierungsformat tritt
hier in subtile Wechselwirkung mit den intellektuellen Vorgaengen
beim Katalogisieren, die zur Bestimmung des Sachtitels (und zur
Abgrenzung von Zusaetzen) fuehren: Der #20-Katalogisierer wird
im Zweifel die Zeichen " : " frueher setzen als der
331/335-Katalogisierer (bitte Widerspruch!).

Insofern ist jegliches Umsetzen von $A.CFG nach MAB (oder ein beliebiges
anderes Format) tendenziell schon mit der Vorspiegelung falscher (oder
zumindest leicht gewandelter) Bedeutung verbunden. Zwar trifft "331"
die Bedeutung wohl eher als "Title", aber nur #20 ist die wahre #20!
Es waere also auch dem Empfaenger gegenueber fairer zu sagen, "hier
ist meine #20 mit der ungefaehren Bedeutung 331 und der noch
ungefaehreren Bedeutung Title, entscheide selbst, ob es mit Deiner
Vorstellung von '331' genug uebereinstimmt (etwas anderes haben
wir aber nicht)".

Das hoert sich wie ein Aufruf zur Anarchie an, die Erfahrungen mit MAB
haben aber auch gezeigt, dass man aller Standardisierung zum Trotz
eigentlich fuer jeden Datenlieferanten einen eigens angepassten
Importfilter benoetigt...


| Das von der DB ist mir noch nicht genuegend etabliert - oder kann man
| schon von allgemeiner Akzeptanz reden?

Gewiss nicht, auch wenn ich vorhabe, die fuer allegro-NRW versprochenen
MAB-Export als Export nach MABXML zu realisieren.

Die Entwicklung von MABXML, soweit ich sie mitverfolgen konnte, war
allerdings ausserordentlich lehrreich: Man sieht, wie "trivial" MARCXML
ist (d.h. eine wie einleuchtend und schematische Umsetzung der ISO 2709-
Struktur in eine XML-Struktur) und versucht, dies fuer MAB ganz genau
so zu machen. Das Resultat war in den ersten Anlaeufen ein voelliges
Scheitern: All die MAB-Suenden der Vergangenheit, die sich letztendlich
wohl alle darauf zurueckfuehren lassen, dass man partout keine
Unterfelder wollte, und daher *ausserhalb* von ISO 2709 einen Haufen
verrueckter Steuerzeichen und des oefteren einen fatalen Mix aus
positionaler Codierung und Text in gleichen Feldern eingefuehrt hat,
machten eine Umsetzung ausserordentlich schwer. Und auch da, wo dann
vor einiger Zeit Unterfelder eingefuehrt wurden, ist es anders (und
schlimmer) als in MARC: Hier (speziell das fragwuerdige neue 671) hat
dann MAB den (von den allegro-Dialekten bekannten) Mix aus Text bzw.
Codierung ausserhalb von Unterfeldern und daran angehaengten
Unterfeldern.

Im Resultat ist MARCXML ein relativ typischer XML-Dialekt, d.h. man
hat die Tags mit den eingebetteten Attributen und die urspruenglichen
Feldinhalte als "Text" und es ist legitim, dass man ueberall zur
besseren Les- oder Transportierbarkeit Leerzeichen oder Zeilenbrueche
einfuegen kann, so wie man es mit *Text* halt macht: Bis auf die
voellig positional definierten Steuerfelder 00x ist die gesamte
Steuerstruktur von MARC auf sehr einfache Art nach XML umsetzbar
gewesen (weil MARC mit ISO 2709 auskommt). [Bislang hat MARCXML
aber noch nicht auf die in MARC21 neu eingefuehrten Nichtsortierzeichen
reagiert, die ja definitiv nichts mit ISO 2709 zu tun haben. D.h.
die Nichtsortierzeichen werden noch(?) als in die Texte eingebettete
Steuerzeichen transportiert, was nicht sehr "XML" ist. Sobald
die Nichtsortierzeichen in MARCXML explizit gemacht werden (was
eigentlich zu fordern ist), wird auch MARCXML Elemente mit sogenanntem
"mixed content" besitzen, allerdings viel harmloser als MABXML
und prinzipielle Probleme sehe ich da eigentlich nicht]

MABXML hingegen ist viel fragiler, an allen moeglichen Stellen *koennte*
(muss aber nicht, das haengt davon ab, ob soundsoviele Zeichen spaeter
ein anderer Code steht oder nicht) ein Spatium am Anfang eines Textes
(Elementinhalts) ein positional definierter Code sein. D.h. selbst eine
ganz typische Umformatierung von
~  <feld ...><unterfeld ...>Inhalt ...</unterfeld></feld>
zu
<feld ...>
~   <unterfeld>Inhalt ...</unterfeld>
</feld>
ist wegen der MAB-Eigentuemlichkeiten in MABXML je nach konkretem feld
ausserordentlich problematisch und tendenziell bedeutungszerstoerend!
Eine (noch ausstehende) Definition fuer ein "robustes" MABXML benoetigt
daher noch weitere Strukturelemente, was der Akzeptanz ("seht: es ist
eine 1:1-Umsetzung") ziemlich hinderlich sein wird.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAa9/sENVh3bB0lwMRAqASAKC+VyvDZMADLHGzJt5WaLZ9jmfQDACdG2Q/
w+sS0qGjJx27CuPdakIj0KM=
=y4kD
-----END PGP SIGNATURE-----