[Allegro] Import-Parameter fuer MARC21

[Michael Lackhoff]

Lieber Herr Berger, liebe Liste,

> Jedenfalls sind mir MARC21-Daten aus Kooperationsprojekten oder
> aehnlichem, wo man also Fremddaten moeglichst reich importiert,
> damit man sie so stehen lassen kann, nie begegnet.

Mir in letzter Zeit immer haeufiger, urspruenglich natuerlich bei Daten,
die aus den USA kommen, mittlerweile aber z.B. auch aus dem GBV und dem
SWB. Mein aktuelles Problem besteht z.B. darin, die Daten, der UB
Tuebingen, die eben im MARC-Format als open data freigegeben sind,
zunaechst in einen Vufind-Fremddaten-Uebernahme-Index zu werfen (was
trivial ist) und dann die gefundenen Treffer in eine Allegro-Datenbank
zu uebernehmen (vielleicht baue ich auch direkt eine zweite
Allegro-Datenbank auf, die ueber Alt-a nutzbar ist, ist ja letztlich
dasselbe Konvertier-Problem).
Aber auch bei der Arbeit sind in den letzten Wochen jede Menge neue
Datenlieferungen in MARC reingekommen, nachdem es lange wirklich fast
nichts in dem Format gab. Leider kann ich den Konverter nicht verwenden,
da wir als Ziel nicht Allegro sondern ein selbstgestricktes Format
verwenden.

> Privat-Feldern transportieren. Insofern wird man dann erst recht
> mehrere "MARC"-Importparameter vorhalten muessen und hoffen,
> dass die Anwender dann stets die geeigneten einsetzen...

Die bisherigen Erfahrungen bei der Arbeit sind, dass das ganz gut ueber
Vererbung geht, weshalb ich ja auch bei der Umsetzung fuer Allegro
lieber Perl verwende. Sie haben mit analyze ja auch ein maechtiges
Werkzeug, um solche Varianten zu erschlagen, bleiben dabei auch viel
naeher an Allegro, haben aber gleichzeitig den Nachteil, dass Sie sich
z.B. um die Eindeutigkeit von Variablen und Sprungmarken sorgen muessen.
D.h. es gibt auf jeden Fall Wege, die Varianten mit vertretbarem
Pflegeaufwand zu erschlagen.

> Import, der "alle Codesysteme" kann, ist illusorisch (der Mechanismus
> ist ja gerade deshalb so indirekt, damit er jederzeit um Alternativen
> erweitert werden kann), bleibt also der Import, der die von der
> relevanten Community hauptsaechlich genutzten Codelisten beruecksichtigt,
> der ist dann - nach Regelwerksumstellung? - evtl. 1:1 in Bezug auf
> diese Codes...

Solrmarc hat da ein ganz nettes System aus Mapping-Tabellen. Natuerlich
muessen die auch gepflegt werden aber z.T. gibt es da schon was und z.T.
kann man sich entsprechende Listen ueber ein Script aus im Web
verfuegbaren Quellen zusammenbauen -- oder man beschraenkt sich
zunaechst -- wie Sie es ja auch schreiben -- auf die in den eigenen
Daten vorkommenden Codes, dann ist das durchaus beherrschbar. Mir ist es
jedenfalls lieber, wenn ich etwas Arbeit mit der Pflege von normierten
Listen habe, als wenn ich z.B. bei den Sprachen "dt.", "de", "ger",
"deutsch" und "deu" nebeneinander in derselben Datenbank finde...

Viele Gruesse
Michael Lackhoff