AW: [mab-list] MABXML

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> > 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).
> Wieso? Es GIBT doch bereits Konvertierungen von MAB nach MARC, zumal bei der DB,
> deshalb meinte ich, es waere dann einfacher, diese zu nutzen und dann MARCXML
> daraus zu machen, anstatt umgekehrt.

"einfacher" ist kontextabhaengig. Meine MAB-Daten zur DB zu schicken
und daraus MARC machen zu lassen, ist gewiss einfach, aber was ist, 
wenn die DB dafuer inakzeptable Gebuehren nimmt (oder mich ob dieses
Ansinnens, sie als universellen EDV-Dienstleister einzuspannen, nur
scheel anguckt)? Darauf, mir ihre Konvertierungs-Software zu
ueberlassen,
ist die DB vermutlich auch nicht eingestellt. D.h. in der bestehenden
Welt bin ich letztendlich immer darauf angewiesen, mir einen eigenen
Exportfilter MAB -> MARC zu basteln, was eine durchaus nichttriviale
Angelegenheit ist, wie jeder weiss, der das einmal versucht hat.

MABXML gibt nun die Moeglichkeit, (mittels eines einfachen Konverters,
der hoffentlich Open Source und auch sonst ganz frei sein wird, sonst
schreibe ich eben einen und veroeffentliche ihn unter der GPL) sehr
sehr einfach von MAB zu MABXML zu kommen und dann mittels
Standardsoftware
und oeffentlichen Stylesheets zu MARCXML. Von diesen Stylesheets
behaupte
ich, dass sie am Ende ihrer Entwicklung besser von MAB nach MARC
umsetzen
koennen, als jeder derzeit existierende proprietaere Filter.
Rudimentaere
Stylesheets, die sagen wir einmal zu 80% korrekt arbeiten, sind sehr
schnell geschrieben (ich habe letztes Jahr einmal einen von MARCXML nach 
MAB geschrieben, das hat mich zwar zwei Tage gekostet, es waren aber
auch meine ersten Gehversuche mit XSL).

 
> > 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.
> Aber genau das koennen Sie mit XML ja eben nicht loesen.

Man muss hier unterscheiden zwischen Dingen, die in MAB ueberhaupt
nicht strukturiert sind, da kann man natuerlich nichts machen, und
solchen - und ich denke, darauf wollte Herr Kett hinaus - solchen,
die in MAB verborgen oder obskur strukturiert sind: Man muss ein
gegebenes Feld MAB 902 sehr genau analysieren um die interne Struktur
dieses konkreten Feldes aus mehreren Moeglichkeiten zu bestimmen.
Analoge Suenden finden sich auch in MARC, z.B. ist ja fast ein
standing joke, welche Qualen man auf sich nehmen muss, um den
Bibliographischen Sachverhalt zu ermitteln, der hinter einem
vorliegenden Feld 245 $b verborgen ist.

 
> > 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,
> Schoene Vision.

Immerhin haben wir Tools (vulgo Bibliothekssysteme), die aus
Benutzereingaben
akzeptables MAB erzeugen koennen, mit MABXML kann man naechstes Jahr
dann
auch den Acrobat Reader nehmen (kein Scherz, die benoetigte
Adobe-Software
fuer den Bereitsteller kostet aber wohl recht viel).

 
> > Wird an anderen Stellen MAB auch als
> > Internformat genutzt?
> >
> Z.B. noch beim SWB (dort arg verfremdet), frueher beim HBZ und noch an vielen
> Spezial- und Institutsbibliotheken in NRW.

Richtig ist: Seit 2000 beim HBZ ("Katalogisierung in MAB" war nach 
meiner Erinnerung ein Auswahlkriterium bei der Wahl des Verbundsystems,
allerdings hat man sich recht schnell davon verabschiedet, die
Katalogisierer mit Periodengruppen rechnen zu lassen. Frueher
existierende
Kinderkrankheiten bei der Z39.50-Schnittstelle deuten darauf hin,
dass intern mit einem recht gesunden Mix aus MAB-Feldnummern und
Unterfeldern wann immer angebracht gearbeitet wird, Beispiel war
z.B. ein Teilfeld fuer den Preis in MAB 540. Die anderen Aleph-500
Systeme im deutschsprachigen Raum duerften aehnlich gestrickt sein.

[
Man moege mich korrigieren: Hierzulande (in Deutschland oder im
Bibliothekswesen) kaempft man meist mit ueberalterten Systemen
und der Wille zum Datenexport wird zwar viel geaeussert, mangels
Interessenten aber selten konsequent realisiert. Insofern gab
es wohl in der Vergangenheit mehrere "Unfaelle", wo am Ende
der Lebensdauer eines Systems die existierenden Daten nur mit
Ach und Krach in das abloesende System hinuebergehebelt werden
konnten. Mit Neid blickte man daher auf die USMARC-Katalogisierungswelt,
wo "in MARC" katalogisiert und gespeichert wird und stellte sich
vor, dass man diese Migrationsmuehen auf immer los wird, wenn man
"in MAB" speichert (und katalogisiert). Die hierfuer eingesetzten
Syteme speichern natuerlich immer noch "in MARC" (mit MAB-Nummern)
und die Katalogisierer katalogisieren immer noch wie vorher (mit
angenaeherten MAB-Nummern).
]

Die "Spezial- und Institutsbibliotheken in NRW" hingegen benutzen eines
der unsaeglichen sogenannten PC-MAB's, d.h. ein - ich will Frau Muennich
nicht zu nahe treten - ein von den dbi-Materialien 130 inspiriertes
System dreistelliger Nummern, das im wesentlichen deshalb fuer "MAB"
gehalten wird, weil das Fussnotenfeld die Nummer 501 traegt.

viele Gruesse
Thomas Berger

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