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

[Bernhard Eversberg]

Am 03.04.2012 12:24, schrieb Thomas Berger:

>>>>
>    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.
>
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...

>
>> 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...
>
Ja, und das ist nicht ganz leicht, weil die abschließende Klammer
nicht stets ans Feldende gehängt werden kann.

> Spaetere Schritte koennten beinhalten, #4n und #6n mit den
> Original-Unterfeldern zu beschicken,
beinhalten? Was für'n Bein? Achso, umfassen ...
> ... dann muessen aber fuer eine
> Uebergangszeit Anzeige und Indexparameter die Winkel drumrum
> setzen.
>
Man kommt von Hundertsten ins Tausendste.

> 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!

> ... 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...
>
Ich denke, was war den Verantwortlichen auch klar, aber da muß
man eben durch, wenn man keine Halbherzigkeiten will, sondern eine
nachhaltige Lösung.

> 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.

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

> (und manche Unterfelder koennen mehrfach vorkommen).
Ja, das ist hochelegant und besonders leicht handhabbar.

> Vielleicht waere jetzt auch die Gelegenheit, die "allegro-Sachgruppen"
> friedlich sterben zu lassen, ...
"zu entsorgen", meinen Sie.

> 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"...
>
Eher in formaler Hinsicht ein Vorschlag, der lokaler Betreuung und
Anpassung bedurft hätte. Aber geringen Anklang fand.

> 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 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
soll dann in die #00, um als V14-Nummer zu dienen?

B.E.


B.E.