[Allegro] Fremddaten per dnb.flx - was ist davon zu halten?

[Thomas Berger]

Lieber Herr Eversberg,

>> Moeglicherweise verwechseln Sie URI mit URN. Jedenfalls ist
>> jede URL ohnehin eine URI aber nicht jede URI gehoert in ein
>> Katalogisat, denn die ueberregionalen Identnummern dort sind
>> doch ein ganz anderes Kaliber.
>>
> Sicher. Na gut, machen Sie einen noch bessren Vorschlag. Sie bleiben
> immer bei der Kritik stehen.

Nun, wenn man #89D 123456 hat, dann hatte ich genuegend ausgebreitet,
dass http://d-nb.info/123456 redundant ist und meiner Ansicht nach
ueberhaupt nichts im Datensatz zu suchen hat. Daher werde ich Ihnen
auch kein "besseres" Feld als #89I vorschlagen koennen.


> Natürlich ist auch #89g extrem
> unglücklich, aber was ist Ihr Vorschlag? Er könnte ja nur besser sein
> als unser Ansatz, und wir würden ihn übernehmen. Ihr vieles Wenn und

Nun, sowohl #89*G*, als auch #89*N* und #89*D* sind gleichermassen
bereits mit Bedeutung versehen, die scheiden daher aus. Nach meinen
Erfahrungen mit den Importen und Update-Mechanismen bei HANS moechte
ich dringend davon abraten, eines der vorhandenen #89S, #89G oder #89T
zu recyclen (obwohl ja gerade bei #89T eine Kontinuitaet der Nummern
besteht und die Normdateien durch die konzertierte Umstellung nie
gleichzeitig existiert haben). Bleiben 14 Grossbuchstaben als
Folgebuchstaben uebrig, falls nicht informell bereits einige genutzt
werden. Wenn ich da einen Vorschlag machen wuerde, waere es der zu
wuerfeln...


> Aber ist ja alles hochinteressant, aber dann scheuen Sie doch nicht zurück vor
> einer Konklusion - oder leiden Sie daran, daß Ihnen ein
> gemachter Vorschlag umgehend neue Bauschmerzen bereitet?
> (Also das mephistophelische Syndrom: "... denn was entsteht, ist wert,
> daß es zugrundegeht"?)

Nun, es ist eher, wie alles mit allem zusammenhaengt: Es ist ja
nicht so, dass man fuer irgendetwas nur einen g'scheiten Folge-
buchstaben ausdenken muss und dann ist Ruhe im Karton...


> Ja, die Formatdoku ist extrem überarbeitungswürdig. Da ist noch ein
> weites Feld für konzertierte OpenSource-Anstrengungen. Nur wollten wir,
> wie schon oft betont, $A.CFG immer als Beispiel und Vorschlag zur je
> individuellen Aneignung verstehen, nicht als Norm. Ist natürlich
> unrealistisch. Die Geschichte hat längst gezeigt, daß nichts neben
> MARC auf lange Sicht bestehen kann, auch MAB mußte dran glauben.
> Nun jedoch ist LC auf dem Weg zu ganz neuen Ufern, sollen wir da
> vielleicht jetzt noch auf MARC umschwenken? Oder was?

Meine Meinung: "Oder was": Wenn man ein "modulares" Kategorien-
schema haette, koennte man z.B. speziell die GND 1:1 nach allegro
Uebernehmen, und zwar fuer alle Kategorienschemata und alle
Anwendungen: Einfach dazuschalten.

Oder ein paar Nummern kleiner: MARC organisisert die Daten
grundlegend anders, das wird allmaehlich erst klar. Z.B. ist
jeweils "was es ist" nie in Indikatoren oder Feldnummern hinein-
codiert, sondern wird als Code in einem parallelen Unterfeld (oft $2
oder $4) zum "Hauptinhalt" (typischerweise $a) mitgefuehrt. D.h.
das Format ist sehr flexibel, was (in heutiger Sprache) unterschiedliche
"Vokabulare" angeht. Beim Import nach "allegro" oder MAB muesste
man hingegen staendig den Datenfeldkatalog erweitern was schon
immer etwas problematisch war: Entweder das Format reagiert zu
langsam oder ungares, halbverstandenes wird kodifziert und ist
dann Jahrelang Ruine.

Import nach (oder gar Nachbildung in) allegro stellt uns vor die neue
Situation, dass Datenfelder (Wiederholungskategorien) fast
durchgehend erst noch /gefiltert/ werden muessen: Ich habe z.B.
alle Verweise auf einem Haufen und muss sie durchlaufen und jede
Codierung darauf ansehen, ob ich ueberhaupt verstehe was gemeint ist
(es koennte ja ein Verweis aus einem voellig fremden System sein) und
ob es die Sorte Verweis ist, die ich gerade benoetige. Nach meinen
ersten Erfahrungen ist die Importsprache darauf nicht gut vorbereitet
gewesen und in den Exportparametern wird es schnell unuebersichtlich.

Es scheint mir ausserdem, dass die GND-Einfuehrung nun eine Art Lawine
losgetreten hat, alles was damit in Beruehrung kommt, entwickelt
eine Tendenz, selbst MARCifiziert zu werden. Daher glaube ich
auch daran, dass die MAB-Abschaffung der DNB zum 1.7.2013 sehr
schnell sehr drastische Konsequenzen haben wird. Andererseits sehen
wir, dass die "Aleph-Verbuende" derzeit auf einem toten Pferd durch
die Praerie reiten, weil sie seinerzeit unbedingt Synergie dadurch
gewinnen wollten, dass das Austauschformat auch als Internformat
genutzt wird.

Wir brauchen eine Fortentwicklung von z.B. A.CFG, die nicht
unbedingt alles auf MARC21 trimmt, aber beruecksichtigt, dass
"flexiblere" Daten nun hereinkommen und auch herausgehen sollen,
d.h. solche indirekten, Codebasierten-Mechanismen von MARC
muessen abbildbar sein, sonst definiert man staendig neue lokale
Felder dazu und das ist noch weniger gangbar.


viele Gruesse
Thomas Berger