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

[Thomas Berger]

Lieber Herr Eversberg,

>> Ich dachte, gerade die UTF-8 Umwandlung passiert erst im nachgelagerten
>> Export, also duerfte es egal sein, was die Importparameter treiben.
>>
> Nein, die u-Befehle aus den Exportparametern, die werden schon in der
> Importphase abgewickelt (uconv() in import.c). Das hat interne Gründe,
> es wird so abgehandelt wie ein "insert" in FLEX, wo es ja auch so ist.
> Nur wurde bei FLEX später der "xcode u" geschaffen und dazu set U0.
> Probleme entstehen dabei, wenn ein Zeichen, z.B. 225 f. das scharfe s,
> zugleich ein UTF-Anfangscode ist. Dann geht was daneben beim zweiten
> Zugriff, also nach der o.a. Art mit k-Befehl. Das muß also da noch
> raus...

D.h. die ueber die Exportparameter eingebundenen u-Befehle wirken
nicht beim Export, sondern im durch die Importparameter
realisierten Import (nach der Datensatzbestimmung und y-Befehlen,
aber bei jedem Zugriff)? Warum dann nicht eine analoge u-Tabelle in
die Importparameter einbinden, das wuerde es vielleicht klarer machen.

Ich bin mir uebrigens nicht sicher, ob es viel hilft, die UTF-8->
Ostwest-Umwandlung so frueh im Import durchzufuehren.



>> 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.
> Das Regelwerk ist kein Teil des StGB!

Nun, die meisten Einrichtungen wuerden derzeit behaupten, dass sie
"nach RAK-WB" katalogisieren, und da kommt das Konzept der Ordnungshilfe
durchaus vor (und die Syntax mit Winkelklammern auch). Wir werden sehen,
wie das ab Mai sich in den Sprachregelungen niederschlaegt, denn
dann wird man ja weiterhin irgendwie "nach RAK-WB" katalogisieren,
aber mit Daten, die keine Ordnungshilfen enthalten (110 $g heisst
dann "identifizierender Zusatz") und ganz gewiss keine Winkelklammern...



>> 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)
>>
> Das sagt sich leicht. Aber die Separierung der Ortsnamen wurde ganz
> bewußt so gemacht, um gezielte Recherchen z.B. nach Stichwort und
> Ortssitz machen zu können.

Ja, und "Sitz der Koerperschaft" war ein riesiges Desiderat. Momentan
gibt es dafuer aber kein allegro-Datenfeld und es geht darum, aus
der GND irgendwie zum Altbestand kompatible Daten herzuzaubern.
Unmoeglich ist es jedenfalls, mit den bisherigen Feldern auszukommen
und dennoch alle sinnvollen Neuerungen irgendwie mitzunehmen, dafuer
sind die alten Normdatenkategorien, die ja auch vor ca. 20 Jahren
das letzte Mal mit Verstand betrachtet worden sind, selber zu
schlecht.



>> 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
> Das ist der Fall.

sowohl im Import als im Export sehe ich Kontruktionen
e"▼" oder e"▼irgendwas". Also werden Datenfelder an irgendeiner
Stelle abgeschnitten, ohne dass analysiert wurde, ob dahinter
noch etwas interessantes steht.


>> Dringend abraten moechte ich (vgl. die Mail von gestern) die GND-
>> Nummer in #89G fuer die GKD-Nummer zu importieren!
>>
> Einverstanden, aber wohin damit? Sie wissen immer gut, was Sie *nicht*
> wollen, aber mit konstruktiven Vorschlägen halten Sie sich zurück, um
> dann, wenn einer welche macht, sogleich Bedenken anzumelden.

Ich habe in meinen Anwendungen #89 (Spatium) bereits fuer die EKI
verbraten, allerdings ist das ja auch ein Fall, wo die Art des
Identifiers (welcher Verbund) vorne hineincodiert ist.

Alle MARC 035 sind sehr interessante Identnummern, allerdings
muss man $a von $z (obsolete Nummern) unterscheiden (vgl. Mail von gestern).
Und DE-101 ist laengst nicht so spannend wie DE-588 oder DE-588a/b/c.

Nimmt man alle mit, so koennten #89, #892, ... bis #899 gute
Kandidaten sein. Allerdings will man m.E. in allegro Praeferenzen
setzen, schliesslich hat die erste der - ansonsten aquivalenten
Identnummern - bei Updates eine ziemliche Bedeutung. Und wenn man
gezielt die (DE-588)-Identnummer ziehen will, muss man im Fall
von Wiederholungskategorien deutlich mehr arbeiten, als wenn die
Nummern durch "¶" getrennt in /einer/ Kategorie zusammengefasst
sind.


> Ich frage mich vielmehr, wie persistent wohl die Nummer in der 001 sein
> wird, während in der URI die SWD-IdNummer verwendet wird!! Also welche

Sie koennen ja an 003 ablesen, dass 001 die PICA-PPN aus ILTIS ist,
also eher eine uninteressante Nummer.

Die GND-Nummer ist fuer Altsaetze identisch mit der frueheren jeweiligen
Normdatennummer (fuer PND: ohnehin identisch mit der PICA-PPN).
Daher auch die Konstruktion:
#035   ▼a(DE-588)9043-8
#035   ▼z(DE-588b)9043-8▼9v:zg

D.h. GND-Satz mit Nr. 9043-8 ist legitimer Nachfolger des GKD-Satzes
mit Nummer 9043-8.

Gerade bei Koerperschaften wird es natuerlich ab Juni zu grossen Mengen
Umlenkungen kommen, wenn SWD- und GKD-Koerperschaften datentechnisch
zusammengelegt werden.

Fuer ab April neu enstehende GND-Saetze wird es eine Identnummer ohne
Bindestriche geben (die identisch mit der PICA-PPN ist).

Irgendwo ist das auch alles mal dargelegt worden, scheint aber die
aktuelle Verwuerflung der DNB-Homepage nicht ueberlebt zu haben.



> soll dann in die #00, um als V14-Nummer zu dienen?

Naja, wenn Sie darauf bestehen, dass #00 /auch/ als V14-Nummer dienen
soll, dann ist es berechtigt. Vermutlich sollte man aus der Fremddaten-
001 (lokale Identnummer) irgendetwas machen, was in die allegro-#00
fliesst. Fuer Verknuepfungen sollte #00 jedoch stets nachrangig sein.

viele Gruesse
Thomas Berger