[Allegro] Zum Thema GND, 4: Erste Vorversion des Imports

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Man braucht das aktualisierte  import.exe, weil das DNB-MARC einen ganz
> kleinen Mangel hat: Einen dort nicht hingehörigen Code 0a am Satzende,
> dank dessen dann die Längenangabe im Header des Satzes um 1 zu kurz ist.
> Ab Satz 2 kam daher nichts Brauchbares mehr raus...

Erstaunlich, nicht wahr: Ich habe zwar nie die CHF 58,- locker gemacht
um ein PDF von 7 Seiten zu kaufen, daher folgendes mit einer gewissen
Unsicherheit: ISO 2709 regelt nur die Codierung eines Records,
insofern koennte man argumentieren, dass beliebiger Text zwischen Records
legal ist (und das Erkennen des Record-Anfangs bilateraler Verabredungen
bedarf). Es duerfte allerdings klar sein, dass es keine ausser der
speziell auf die hiesige Situation angepassten Programme gibt, von denen
a priori klar waere, dass sie diese MARC-Daten auch nur einlesen koennen
(wie stand es mit MARCEdit?). M.W. wird aber in den "hiesigen Strukturen"
alles in MARCXML abgewickelt, da spart man sich den ganzen Krampf mit
dem Directory (man kann MABXML und MARCXML etc. mit Windows-Bordmitteln
in eine menschenlesbare /und/ importfreundlichere, MAB-Diskette-artige
Struktur umwandeln, naemlich
### Header
001 Ident
002 ...
...

### naechster Satz


Die Sache mit dem Zeilenbruch hat natuerlich Tradition, auch die MAB2-Daten
der DNB haben stets einen im Standard nicht erwaehnten Extra-Zeilenbruch
zwischen den Saetzen und niemand hat sich je beschwert...


> Es stehen Kommentare in den Parametern zu deren Wie und Warum.

Ich finde dort:

>>>
  Das mit #uko ist ein Trick!
  Wuerde man mit k6n den Inhalt nochmals einlesen, kõme eine zweite
   UTF-Umwandlung, und dabei ginge z.B. das scharfe s kaputt, weil es den
ASCII-Code 225 hat
<<<

d.h. wenn stimmt, was da steht, dann waere das

>>>
#4n        Lebensdaten von #4n abschneiden
k4n
e"▼d"
<<<

etwas weiter oben heikel.

Ist es wirklich so, dass ein k-Befehl k6n fuer eine echte Kategorie #6n
alles(?) noch einmal umcodiert, hingegen kko fuer die Anwendervariable
#uko nicht?

Ich dachte, gerade die UTF-8 Umwandlung passiert erst im nachgelagerten
Export, also duerfte es egal sein, was die Importparameter treiben.



> Etliche Felder werden in ihrer Form noch nicht komplett und so noch
> nicht optimal sein, aber wir wollen auch nicht zu schnell alles
> festschreiben.

Ich denke, man will ja auch die traditionellen RAK-Ansetzungen
irgendwie emulieren, d.h. es muss ausgetueftelt werden, welche
Bestandteile der Ansetzungsfelder in Winkelklammern gesetzt
werden sollten...

Spaetere Schritte koennten beinhalten, #4n und #6n mit den
Original-Unterfeldern zu beschicken, dann muessen aber fuer eine
Uebergangszeit Anzeige und Indexparameter die Winkel drumrum
setzen.

Weil die RAK nicht weiterentwickelt werden, die RDA noch nicht
fertig geschrieben sind, geschweige denn uebersetzt und eingefuehrt,
haengt die GND derzeit ja bis auf weiteres in der Luft: Formatbedingt
gibt es keine Winkelklammern mehr, das verbindliche Regelwerk
schreibt natuerlich noch welche vor. Den Verbuenden duerfte das
egal sein, da dort alle Personen, Koerperschaften und RSWK-
Erschliessungen mit den Normdateien verknuepft sind und die
Titeldaten Ende April komplett umgesetzt werden. Alle anderen
Datenbanken haben allerdings das Problem, einen Mix aus
Altansetzungen (ggfls. nur als Text oder in lokalen Normsaetzen)
und AACR-artigen GND-Ansetzungen harmonisieren zu muessen: Das
duerfte noch einige Jahre so bleiben...

Konkret muesste man beispielsweise wohl MARC 551 (R), wenn sie als Ort
gekennzeichet ist, zur Koerperschaftsansetzung ziehen (und nicht als
#3nr in einen Koerperschaftssatz pfeffern)


> Noch nicht berücksichtigt sind einige 035-Nummern, die Felder 005 und
> 008, 040, 667 und 913. Ferner einige Unterfelder in den anderen
> Bereichen. Importiert wird, andersrum gesagt, was die bisherigen
> Normsätze des A-Formats spezifizieren und umfassen - soweit wir es
> überhaupt einschätzen können, wie die praktische Nutzung draußen
> "im Felde" aussieht.


Ich denke, in Bezug auf Unterfelder tut gnd.aim bereits zu viel:
Inzwischen hat sich ja die Einschaetzung durchgesetzt, dass im
Datenfeld die Unterfeldzeichen gefolgt vom jeweiligen Code eine
Art von "Tagging" darstellen und eine Interpretation als /Datenfeld/
oft daneben liegt. Insofern ist die im Feld vorgegebene Reihenfolge
aller Inhalte extrem wichtig und muss unbedingt erhalten bleiben
(und manche Unterfelder koennen mehrfach vorkommen).
Die Importsprache bietet da wenig Moeglichkeiten, die Exportsprache
ist m.E. das bessere Werkzeug, um /in/ einem Feld zu verschoenen.

Vielleicht waere jetzt auch die Gelegenheit, die "allegro-Sachgruppen"
friedlich sterben zu lassen, soweit ich weiss handelt es sich um
ein Erschliessungssystem, das nicht wirklich dokumentiert und deutlich
nicht gepflegt ist, moeglicherweise eines der TU Braunschweig aus
Zeiten vor Eintritt in den damaligen "PICA-Verbund"...

Dringend abraten moechte ich (vgl. die Mail von gestern) die GND-
Nummer in #89G fuer die GKD-Nummer zu importieren!

viele Gruesse
Thomas Berger