[Allegro] Routenplanung für die Höllenfahrt?

[Thomas Berger]

Lieber Herr Lackhoff, liebe Liste,

> Bessere Parameter waeren natuerlich eine vordergruendige Loesung, noch
> besser faende ich allerdings ein gut dokumentiertes Mapping, also eine
> genaue Beschreibung, was wie umzusetzen ist, insbesondere da, wo es kein
> einfaches 1:1 Mapping gibt. Z.B.: Wie ist mit in Allegro wiederholbaren
> Feldern umzugehen, die in MARC nicht wiederholbar sind? Wie ist mit
> redundanten Informationen umzugehen (Sprachbez., Ersch.Jahr, ISBN), wann
> genau sind welche Indikatoren und welche Leader-Flags zu setzen? Wie das
> vollkommen unterschiedliche Nicht-Sortier-Konzept umsetzen? usw...

Wenn ich Exportparameter schreibe, die eine Umsetzung ~moeglichst
vollstaendig~ erledigen sollen entsteht meist schnell ein Schematismus,
d.h. ein Satz von Unterprogrammen, die einzelne Felder oder Feldgruppen
unter einer sich entwickelnden Typologie (etwa intern wiederholt ->
extern wiederholt, Wiederholungsfeld -> Sammelfeld, differenziert
-> undifferenziert mit einleitender Wendung, ...)  behandlen.

Der Hauptteil so einer Parameterdatei ist dann recht schematisch
und versucht in ebenso schematischen Kommentaren das Zielformat
zu dokumentieren, damit maschinell die "Abdeckung" der Schnittstelle
dokumentiert werden kann:

...

   %= 500 <- #501,#434e    * General Note (R)
#nr dcv p"500|" =kn
#501. ++ v4,a dcv P>X Acv    % Nicht nach >V!
#434e P>X =cv

#uIS p"▼5" Acv
#429 p"L: " P>X acv      * Bestandsluecken

   %= 501 <- #524    * With Note (R)
#nr p"501|" =kn
#524. ++ dcv B"▼" p"¬Darin:¬ " P>X Acv

   %= 502 <- #501d    * Dissertation Note (R)
#501d p"502|" P>x =kn

   %= 504 <- n.a.    * Bibliography, etc. Note (R)
   %= 505 <- #434s   * Formatted Contents Note (R)
#434s p"505|" P>n =kn

...


Neue oder abweichende zu behandelnde Felder lassen sich dann
~einfach~ realisieren. Die Schwierigkeit ist aber, das richtige
Unterprogramm zu finden, die "Typologie" entstammt keinem
eigenstaendigen Analyseprojekt sondern ist eine Sammlung
halbwegs einheitlich aufzurufender "nuetzlicher Unterprogramme",
die waehrend der Programmierung der Schnittstelle entstanden ist

~Moeglichst vollstaendig~ kann man aus Sicht des Quell- oder Zielformats,
aus Sicht der gegebenen Quell- oder Zielanwendung definieren, "universell"
wird nie daraus. Wiederholbarkeiten oder syntaktische Konstrukte zur
Differenzierung (Teilfelder, Unterfelder, Nichtsortierzeichen) sind oft
nur ein Startpunkt, im konkreten Fall wichtiges ist u.U. erst durch
eine Binnensyntax ausgedrueckt, also fuer die universelle Situation
"ungeregelt". Zumindest hierzulande ist "das" Datenformat ohnehin
nur Diskussionsgrundlage, wenn das Zielsystem sagt, Feld Y ist
Pflicht, sonst "validiert es nicht", dann muss halt ein Feld Y mit
(oder moeglichst ohne) dem Brecheisen erzeugt werden. Noch haeufiger
aber die Aussage, Feld X ist zwar legal, wird von jedoch nicht
beruecksichtigt, dann muss fuer wichtiges, das ~eigentlich~ nach
X gehoert, individuell ein anderes Zielfeld gefunden werden (evtl.
sogar standardisiert, wir werden gewiss sowohl Exporte fuer
"internationales" MARC21 ("Discovery"-Systeme) als auch fuer
D-A-CH-MARC21 ("Bibliotheks"-Systeme) unterstuetzen muessen...

Ich halte alle Versuche, ein "Mapping" abstrakt zu dokumentieren,
fuer problematisch (und die Versuche es zu "definieren" fuer
aussichtslos), zumindest wenn das irgendwie tabellarisch oder
listenartig aussehen soll:

Jedes der beteiligten Formate kennt nur eine gewisse Granularitaet
der Adressierung (Feld, Unterfeld, Indikator, Codeposition) und
oft gibt es keine 1:1, 1:n, n:1-Umsetzung. Bei MAB(PICA,allegro,...)
<-> MARC21-Umsetzungen u.a. in den Authorities erfolgt eine Art
Transposition: Etwas primaer nach Funktion und dann nach Typ
organisiertes (8xx) wird umgesetzt in etwas nach Typ organisiertes
mit Kennzeichnungen der Funktion (5XX mit x Unterfeldern).
Auf Feldebene ist das nicht gut beschreibbar (ca. 20 Felder des
Quellformats gehen auf unterschiedliche Untermengen von 6 Feldern
des Zielformats), auf Unterfeldebene auch nicht (ich kann ja
nicht einmal sagen, dass Unterfeld "x" welches Feldes betroffen
ist, denn das haengt von einem anderen Datenelement ab. Das ist
natuerlich im *Zusammenhang* zu sehen und auch herzlich egal,
aber das Wissen darum, dass Unterfeld x in allen 6 infrage kommenden
Feldern die gleiche Bedeutung hat, ist wiederum im Rahmen einer
/Konkordanz/ nicht formalisierbar, ausser man legt eine noch zu
definierende Beschreibungssprache fuer abstrakte bibliothekarische
Datenformate zugrunde...)

Die interessantesten Dinge passieren ohnehin auf Binnenebene
(Behandlung von Namen, einleitenden Wendungen, "internen"
Wiederholbarkeiten) oder wenn Felder oder Codes nicht umgesetzt werden
koennen, sondern anhand der Situation des kompletten Datensatzes (bzw.
weiterer, damit verknuepfter Datensaetze) erst erschlossen werden muessen
(triviales Beispiel: die Codes "dies ist" in MAB 05X)

Typischerweise wird bei Verbesserungen der Schnittstelle die Konkordanz
nicht aktualisiert, und man weiss dann schnell nicht mehr, was
"massgeblich" sein soll.

Ich denke daher, dass der Ansatz einer "wartbaren" Schnittstelle mit
schematischen Kommentaren, aus denen maschinell "dokumentierende
Feldlisten" extrahiert werden koennen, nicht der verkehrteste ist:
Es entstehen daraus zwar nicht die eindrucksvoll-nichtssagenden
Konkordanztabellen der DNB, wohl aber Listen / Tabellen mit
Aussagen wie "Bei der Beschickung von Zielfeld X" sind die Quellfelder
A und B involviert"

viele Gruesse
Thomas Berger