Verlautbarung 310 zur allegro-Entwicklung 2019-04-11
-----------------------------------------
MARC und kein Ende?! - Ein neuer FLEX für MARC-Import
-----------------------------------------------------
Vorrede
-------
Es hat Bestrebungen gegeben, von MARC wegzukommen: zuerst UniMarc,
dann Dublin Core, dann MARCXML, dann BibFrame. Alles für die Katz,
MARC21 ist heute das einzige Format, das weltweit verstanden wird und
ohne welches kein System irgendwo einen Fuß in die Tür kriegen kann.
[Mehr dazu unten in einer "Historischen Notiz"]
Wer nur das Wichtigste wissen will, kann weiterlesen unten im
Abschnitt "Verbesserung des MARC-Imports".
Hintergrund
-----------
Die allegro-Entwicklung hat sich fast von Beginn an nicht auf EIN
Format festgelegt, sondern vier Konstrukte geschaffen, mit denen das
System weltoffen sein kann (womit nicht allein die Bibliothekswelt
anvisiert ist):
1. Die "Konfiguration" (.cfg) legt fest, welche Felder mit welchen
Eigenschaften man intern (innerhalb der Datenbank) verwendet.
Das kann auch MARC sein, muß aber nicht: Es gibt dafür $m.cfg.
(OK, nicht exakt das Magnetband-MARC in der Ausprägung des
Dateityps .mrc, aber das macht auch sonst wohl kein System so,
sondern es geht nur um die Feldstruktur.)
2. Die Import-Sprache (.aim), mit der man jedes Fremdformat in das
eigene (der eigenen .cfg entsprechende) Format wandeln kann, um
fremde Daten in die eigene Umgebung zu überführen. Das können
auch Daten sein, die ganz anders aussehen als MARC.
3. Die Exportsprache (.apr), die aus den eigenen, internen, der
.cfg entsprechenden Daten jede andere Struktur erzeugen kann,
auch MARC21 (Ausprägung .mrk, wandelbar mit MARCEDIT in .mrc).
Nicht nur das, auch Karten, Listen, Displaytexte, sortierbare
Dateien und sogar der Index der Datenbank wird mit der Exportsprache
hergestellt.
4. Die Skriptsprache FLEX (.flx), mit der sowohl Importe wie auch Exporte
durchführbar sind. Zwar nicht alle Strukturen, die man mit 2. und 3.
beherrschen kann, aber doch sehr viele, und in einer sehr viel
einfacheren, nicht so kryptischen Weise. FLEX dient in erster Linie
dem bequemen, flexiblen Programmieren von Vorgängen, also von
Funktionen aller Art, die das Kernsystem gar nicht hat, etwa den
gesamten Komplex der Geschäftsgänge sowie auch die schnelle online-
Übernahme von Fremddaten, ad hoc einzeln über das Internet.
Dieses ganze Konzept ist jedoch "proprietär" und entspricht keinen
gängigen, der Fachwelt vertrauten Standards. So etwas wird in der
Informatik nicht gern gesehen. Da müssen allegro-Anwender aber
mit leben - und auf Dauer wollen das eben auch nicht alle und
emigrieren sonstwohin. Das ist OK - das Grundgesetz garantiert auch
die freie Wahl der Software, mit der man leben will. Die freie Wahl
des Formats jedoch ist eine andere Frage: Das erste steht uns frei,
beim zweiten sind wir Knechte (Faust I) - außer eben bei allegro.
Jedenfalls sind mit dem Konzept auch viele Datenbanken möglich
geworden, die mit MARC oder überhaupt mit Bibliotheken gar nichts zu
tun haben. Wie letztens, als Extremfall, die Datenbank für die
polnische Sprache.
Genug der Vorrede und Hintergründeleien, zum Thema jetzt:
Verbesserung des MARC-Imports
-----------------------------
Es gibt zwar die Importparameter marc21.aim, jedoch sind sie kein
Allheilmittel in dem Sinne, daß das Thema MARC-Import damit
umfassend gelöst wäre: Das Programm import.exe erstellt damit eine
Datei im Externformat .alg, und die muß man anschließend per Update
einspeisen oder mit a99 einlesen ("Weitere externe Datei laden").
Das macht den Vorgang etwas schwerfälliger als er sein sollte,
und nicht alle Anwender kriegen das auf Anhieb gebacken.
Dieser Mißstand gab den Anstoß zu einer Verbesserung. Es wurde ein
FLEX geschaffen, der zwar nicht ganz alleine eine .mrc-Datei
einlesen kann, aber er spannt das Import-Programm für diese
Aufgabe mit ein, ohne daß man dieses und hernach noch das Update-
Programm selber anwerfen muß - man braucht sie gar nicht zu kennen!
Der FLEX heißt marcimp.flx. Für die eigentliche Datenwandlung nutzt
er import.exe und die Parameter marc21.aim. Weil nun aber MARC-
Daten inzwischen in zwei Geschmäckern vorliegen: UTF-8-Codierung
bzw. MARC8-Codierung, gibt es nun auch zwei Parameterdateien:
marc21.aim für MARC8
marc21ut.aim für UTF-8
Welche zu nehmen ist, kann der marcimp.flx selber erkennen, denn
die MARC-Datei hat dann einen Indikator 'a' an der Position 9 (d.h.
das 10. Zeichen ist ein 'a'). Der Unterschied zwischen beiden
Parameterdateien ist nur eine Liste von internen Zeichenwandlungs-
Befehlen, alles andere ist gleich. Leider konnte man es noch nicht
eleganter lösen. Falls also mal Änderungen nötig sind, müssen beide
.aim-Dateien in gleicher Weise geändert werden. Kommentar steht drin.
Und so läuft nun ein MARC-Import ab:
1. Man erhält von sonstwo eine .mrc-Datei und loadet sie down
in den Download-Ordner oder egal wohin.
2. Man gibt in a99 dies ein: X marcimp
Der Rest ist weitgehend intuitiv und erfordert keine Parameter-
oder FLEX-Kenntnisse oder Aktionen außerhalb von a99:
3. Man wird aufgefordert, die zu wandelnde Datei auszuwählen in
einem Windows-üblichen Auswahlfenster, das einem exakt die
.mrc-Dateien anzeigt. Man muß nur den richtigen Ordner ansteuern
und darin dann die Datei auswählen.
4. Dann startet marcimp.flx den Import mit den richtigen Parametern,
dabei entsteht eine Datei marcdat.alg [braucht man nicht zu wissen]
5. Es folgt die Frage, ob man die Daten nun einlesen will, was man
i.d.R. mit ja beantwortet.
6. Kurz darauf hat man die Daten alle im Offline-Speicher, d.h. mit
Alt+q kann man sie besichtigen, bei Bedarf korrigieren und dann
speichern. Oder manmacht das am Ende der a99-Sitzung mit
"Datei / Daten in Bearb. alle speichern"
aber a99 fragt sonst auch selber am Ende, ob das geschehen soll.
Das ist alles.
Man holt sich die notwendigen 3 Dateien mit diesen Befehlen:
X gf marc21.aim Parameter für MARC8-Codierung
X gf marc21ut.aim Parameter für Unicode UTF-8
X gf marcimp.flx der FLEX, der die Arbeit macht
und schon kann's losgehen mit X marcimp
Nebenbei sieht man: Das oben beschriebene allegro-Gesamtkonzept
macht es unnötig, eine neue Programmversion zu erstellen und zu
installieren - ein paar Dateien genügen. Diese Grundidee verfolgt
übrigens auch FOLIO, nur sieht das dann im Detail sehr anders aus,
und MARC-Daten werden immerhin intern gehalten, *zusätzlich*
zu den eigentlichen Arbeitsdaten, die keinem Standard folgen.
Historische Notiz
-----------------
Die erste MARC-Version entstand in den 1960er Jahren bei der LC.
1971 wurde es nationale Norm in den USA, 1973 internationaler
Standard für den Austausch von Bibliotheksdaten. MARC21 kam
1999 als überarbeitete und aktualisierte Fassung heraus, ohne
Änderungen in den Grundzügen.
Die "21" sollte besagen, es handle sich um DAS Format für das
21. Jahrhundert. Davon ist noch kaum ein Fünftel verstrichen,
aber Konkurrenz ist weit und breit keine in Sicht.
Bibliotheken sind, so scheint es bis heute, mit MARC unfreiwillig
aber unauflöslich verheiratet. Was ja auch seine Vorteile hat,
wer wollte das bestreiten!