[Allegro] GND-Import noch diese Woche

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Wir gehen in dieser Woche den GND-Import an. Wie Berger schon
> vorschlug, ist es wegen der Zahl der Anwender wohl sinnvoll, mit einem
> Import in die alte A-Struktur zu beginnen (#3n, #4n usw.)
> Wer anderes benötigt, kann vorläufig entweder dann daraus exportieren
> oder aus den Importparametern seine eigenen ableiten.
> Gibt es Wünsche, Fingerzeige oder Einwände?

Es sollte beruecksichtigt werden, dass die GND eine eigene neue
Normdatei ist, d.h. es waere unguenstig, #89G, #89S und #89T
fuer echte GND-Identifier (die  mit "(DE-588)") zu nutzen und
es muss daher eine neue Kategorie her (erwuenscht ist allerdings
wohl, eventuelle Identifier mit Praefixen DE-588a, DE-588b und
DE-588c ohne dieses Praefix in die zugehoerigen #89G/S/T zu leiten).

Weil MARC21 tendenziell wesentlich flexibler ist, was /Systeme/
von Identifiern angeht, schlage ich vor, die neu zu schaffende
Kategorie nicht nur fuer GND-Nummern zu definieren, sondern allgemein
fuer "(...)"-gepraefixte MARC-Identifier einzurichten, die
Primaerschluessel- und Uebernahmeschluesselroutinen muesste dann allerdings
"(DE-588)" in "GND" oder etwas anderes geeignetes umwandeln (Mittelfristig
sollten die Standardparameter auf i5=__ umgestellt werden, also die V23-
Methodik mit beliebigen Zeichenketten als Ersetzungsschluessel, die allerdings
dann von "_..._" umschlossen sein muessen).

[Die Kategorie sollte mehrere Identifier, durch das uebliche "¶" getrennt,
aufnehmen koennen, der Import sollte regeln, dass der ~wichtigste~ davon
als erster kommt, bzw. eher unwichtige, wie ILTIS-PPNs, sollten erst gar
nicht importiert werden. Das darueber hinaus gehende wichtigste Desiderat
fuer noch eine Kategorie waere nach meiner Einschaetzung eine Sammel-
kategorie fuer nicht die mehr gueltige Identnummern, die mit im GND-Satz
transportiert werden (bereits frueher auch in PND und GKD-Saetzen): Man
kann sie nicht als echte Alternativ-Identnummern behandeln, da evtl. ein
Vorgaengersatz mit dieser Nummer in der Datenbank vorhanden ist, aber mit
diesen Daten hat man dann zumindest die Information vorliegen, die man fuer
spaetere Bereinigungen benoetigt].

Die GND wird nur in UTF-8 codiertem MARC21 ausgeliefert werden (mit vollem
Unicode-Repertoire, also auch originalschriftliche und RTL-Felder sind zu
erwarten), das Ankuendigungsschreiben
<
http://www.dnb.de/SharedDocs/Downloads/DE/DNB/service/rundschreibenUmstellungUTF8.pdf
>
ist etwas vage, es koennte sich um NFD-codierte Daten handeln (cf. den
Unicode Standard Annex #15 <
http://www.unicode.org/reports/tr15/tr15-35.html#Norm_Forms >)

D.h. der Importvorgang sollte nicht nur per u-Tabelle eine Umsetzung
nach allegro-Ostwest durchfuehren, sondern nachgelagert auch noch analog
Protypersetzungen isolierte Diakritika nach Moeglichkeit zum Grundbuchstaben
ziehen. (Oder vor der u-Umsetzung allerhand globale Ersetzungen in den
UTF8-codierten Daten vornehmen).
Rohmaterial fuer die Umsetzung finden Sie hier
< svn.gymel.com/repos/allegro/charsets/trunk/ow-protyp.cpt >
bzw. als fertige Exportparameterdatei
< http://svn.gymel.com/capgen/produkt/impdir/i-protyp.apt >

Nach meiner Erinnerung gibt es allerdings Probleme (Interferenzen zwischen
u-Befehlen und Ersetzungen?), wenn man alles in die Exportparameterdatei
fuer import.exe packt, insofern braucht es eine Verlagerung der
Protyp-Zusammenfassungen in einen dem import nachgelagerten, eigenen
SRCH-Lauf.

viele Gruesse
Thomas Berger