AW: [mab-list] MABXML

["Kett, Jürgen"]

Sehr geehrter Herr Eversberg,

Vielen herzlichen Dank für Ihre spontane Antwort. Sie haben ein paar sehr
Interessante Fragen ins Spiel gebracht.

> Abzuwarten bleibt natuerlich erst einmal, ob denn MAB 
> bestehen bleiben oder 
> zugunsten von MARC21 zum Auslaufmodell werden wird.
Leider hat die Umstiegsdiskussion dazu geführt, dass nur wenig über
Weiterentwicklungen diskutiert wird. Man wartet erst einmal ab. Ich halte
das für einen Fehler.  Egal wie die Entscheidung ausfällt: MAB wird noch
lange eine wichtige Bedeutung als Austauschformat inne haben. MABXML soll
ein Angebot sein an Kollegen, die nicht warten wollen (oder können) bis eine
Entscheidung gefallen ist. 

> Und selbst WENN es bestehen bleibt, ist die Frage, ob denn 
> nicht die Konversion 
> von MAB zu MARC21, die es auf jeden Fall geben muss, auch 
> genutzt werden kann, um 
> dann im zweiten Schritt MAR21-XML herzustellen, fuer alle 
> diejenigen, die dann 
> wirklich XML wollen. 
Ich stimme Ihnen vollkommen zu, dass es eine solche Konkordanz geben muss.
Aber: Gerade hierfür wäre ein gut strukturiertes Austauschformat als
Vermittler ein Segen (MAB2<->MABXML<->MARC21 bzw. MAB2<->MABXML<->MARCXML).
Genau hierfür hat ja die LoC auch ihr MARCXML eingesetzt. Ich bin aktuell
mit der Erstellung einer solchen Konkordanz beschäftigt und wünschte ich
hätte ein besser strukturiertes Ausgangsformat als MAB2.   

> Denn die muessen sich mit MARC21-XML 
> sowieso befassen und 
> werden froh sein, wenn sie nicht mit MABXML noch ein zweites 
> Schema beherrschen 
> muessen.
Ich bin mir nicht sicher, ob man MARCXML oder MABXML "beherrschen" muss. Der
Trend sollte dahin gehen, dass Software-Tools einem die Syntax-Arbeit
abnehmen, so dass der Bearbeiter nur noch mit einer Schnittstelle
konfrontiert ist, die weitestgehend unabhängig ist von den Details der
Syntax des zugrundliegenden Formats. Es ist die Aufghabe des
Verarbeitungsprogramms, aus den Eingaben des Benutzers eine korrekte Syntax
zu erzeugen und es ist die Aufgabe des Verarbeitungsprogramms, Datensätze so
zu präsentieren, dass sie für den Nutzer leicht zu lesen sind. Gerade für
XML gibt es Unmengen von Werkzeugen, die einem die Arbeit erleichtern
können.

> 
> Abgesehen von diesen Ueberlegungen stellt sich aber auch die 
> Frage, ob das 
> konventionelle MAB dann, wenn es MABXML gibt, bestehen 
> bleiben soll, falls es 
> ueberhaupt bestehen bleibt, oder dadurch laengerfristig 
> voellig abgeloest werden 
> sollte.


> 
> Wenn Sie irgendwelche Katalogisierer fragen, die jetzt mit 
> MAB umgehen, werden 
> Sie nicht viel Beifall ernten: MAB liest sich, kennt man 
> einmal die Nummern, extrem viel schneller als derselbe 
> Datensatz in XML. 
Siehe oben ("... es ist die Aufgabe des Verarbeitungsprogramms, Datensätze
so zu präsentieren, dass sie für den Nutzer leicht zu lesen sind.")

> Es entsteht also das witzige 
> Paradoxon, dass man eine menschenlesbare Form des Datensatzes 
> hat, die aber keiner wird lesen wollen, weil die vermeintlich 
> kryptische Form mit den Nummern 
> soviel bequemer, kompakter, uebersichtlicher ist, mit nur 
> ganz wenig Gewoehnung. 
Ich würde mich ja gerne mit diesen Lorbeeren schmücken, aber MABXML ist
bisher keineswegs besser lesbar als MAB2. Ich denke auch nicht, dass ein
Austauschformat eine wirkliche Menschenlesbarkeit erreichen kann. Selbst
wenn man "sprechende" Bezeichnungen wie "Autor" oder "ID" wählt, kann die
tatsächliche Semantik eines Felds nur durch begleitende Informationen
verstanden werden. Darum halte ich "Codes" wie z.B. die MAB2-Feldnummern für
gar nicht so verkehrt.  

> Man wird also mittels XSLT wieder aus 
> MABXML die alte Form machen muessen, um der 
> Praxis genuege zu tun.
Ich habe weiter oben geschrieben "... es ist die Aufghabe des
Verarbeitungsprogramms, aus den Eingaben des Benutzers eine korrekte Syntax
zu erzeugen..."). Diese Aussage setzte natürlich voraus, dass dem
Katalogisierer eine passende Eingabeschnittstelle zu Verfügung gestellt
wird. Diese kann sich optisch an MAB2 anlehnen oder völlig anders aussehen. 

Genau genommen sollten Bibliothekssysteme überhaupt nicht direkt auf einem
Austauschformat aufsetzen, sondern über ein geeignetes Internformat
verfügen. D.h. Daten werden über eine Maske eingegeben, im Internformat
gespeichert und für den Datenaustausch in das Austauschformat konvertiert
(siehe auch weiter unten). 
In Der Deutschen Bibliothek beispielsweise arbeiten wir intern
ausschliesslich mit den PICA-Formaten. Wird an anderen Stellen MAB auch als
Internformat genutzt?   

> Hinsichtlich Speicheroekonomie ist die alte Form unschlagbar, 
> auch wenn das 
> keinen mehr interessiert und belaechelt wird, wenn man darauf 
> hinweist. Aber 
> hantieren Sie mal mit 15 Millionen Daten und vergleichen Sie 
> dann. Als 
> Anhaltspunkt koennen Sie nehmen: 15 Millionen konventionelle 
> MARC-Saetze des 
> alten VK haben wir hier auf einem handelsueblichen PC in 6.5 
> Stunden indexiert. M.E. muessen wir, solange unsere 
> Datenbanken unablaessig wachsen, um Effizienz 
> bemueht sein.
Hier sprechen sie wirklich einen Knackpunkt an. Für mich ist die Frage: Ist
es sinnvoll ein Format für alle Anwendungsfälle zu suchen? 

MABXML ist ein reines Austauschformat (so wie MAB2 per Definiton auch). Es
ist nicht darauf ausgelegt auch als Internformat zu fungieren. Also besteht
für MABXML auch gar keine Anforderung, besonders gut für die Speicherung und
Indexierung geeignet zu sein.  Jede Institution sollte selbst entscheiden
welches Internformat sie einsetzt. In der Regel wird ein solches Format
durch das jeweils eingesetzte System (PICA, Aleph, etc.) vorgegeben. 

Der Kommunikationsweg sollte sein: Internformat A <-> Austauschformat <->
Internformat B. Das Austauschformat sollte nur gewährlweisten, dass es alle
Daten ohne Informationsverlust transportieren kann und dass eine Konverision
in andere Formate kein Problem ist. (Und an dieser Stelle haben sowohl MAB2
als auch MARC21 große Schwächen.)

Das Internformat dagegen sollte an die Anforderungen des jeweiligen
Bibliothekssystems angepasst sein (d.h. speichereffizient und angereicht mit
Informationen, die für das spezielle System wichtig sind).   

> 
> Eine weitere Frage ist, ob man XML-Daten als solche dann 
> innerhalb von 
> Datenbanken halten wird. Benchmark-Ergebnisse bei der 
> Untersuchung von nativen 
> XML-Datenbanken raten davon eher ab, ganz klar wegen 
> bescheidener Performance.
Da bin ich ganz Ihrer Meinung (siehe oben). Es ist in der Regel nicht zu
empfehlen, ein Austauschformat (insbesondere eines in XML) als Internformat
einzusetzen.

> 
> MfG B.E.
Noch einmal vielen Dank und beste Grüße
Jürgen Kett


> 
> 
> 
> 
> 
> Bernhard Eversberg
> Universitaetsbibliothek, Postf. 3329, 
> D-38023 Braunschweig, Germany
> Tel.  +49 531 391-5026 , -5011 , FAX  -5836
> e-mail  B.Eversberg at tu-bs.de  
> ----------------------------------------------------------------------
> Zum Austragen aus dieser Liste senden Sie bitte eine Mail an 
> majordomo at ddb.de mit unsubscribe mab-list im Textfeld.
> 

----------------------------------------------------------------------
Zum Austragen aus dieser Liste senden Sie bitte eine Mail an
majordomo at ddb.de mit unsubscribe mab-list im Textfeld.