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

[Thomas Berger]

Lieber Herr Lackhoff, liebe Liste,

> Das wohl eher nicht, was ich mir aber vorstellen koennte waere ein
> (wiederholbares) Feld, das beliebige Inhalte transportieren kann, die in
> irgendeinem anderen Format einen Sinn ergeben. Das koennte so aussehen,
> dass in einem Unterfeld das Format steht, in einem weiteren das
> (Sub-)Feld und in einem dritten der eigentliche Nutzinhalt:
> #kkx$aMARC21 $b 245a $c Das Liebesleben der Maikaefer
> Wobei natuerlich fuer $a und $b eine gewisse Normierung anzustreben ist.
> Damit kann man dann fast schon "linked data" realisieren.

Hm. Diese Tier war auch bekannt als "MARC-Park-Feld"...
Die Sache duerfte allerdings schnell ueberlaufen ...

Ich sehe - sogar unabhaengig von MARC21 oder einem Park-Feld -  ein
Problem bei Aktualisierungen: Sagen wir, #8eff enthaelt mehrere
URLs, einige zu Kataloganreicherungen aus Fremddaten und andere
zu Rezensionen, die ich selber ermittelt habe oder aus anderer
Quelle beziehe. Oder - wenn die RDA ausgebrochen sind und es
keine einheitlichen Standards mehr zur Anzahl der angesetzten
Personen mehr gibt - es kommen Verfasser aus Fremddaten und ich
habe noch allerhand Beitraeger ergaenzt: In diesen Faellen kommt
irgendwann eine Aktualisierung aus Fremddaten, oder ich besorge
mir die, und ich will in den #8e's alle gewesenen Anreicherungen
austauschen durch die tendenziell umfangreicheren neuen. Dabei
aber nicht meine Mehrarbeit vernichten.

Die Update-Aufgabe ist also, die vorhandenen k #8e'-Wiederholungen
einer gewissen Provenienz auszutauschen gegen die m Wiederholungen
aus einem aktuellen Import, dabei die n anderen in Ruhe zu lassen.
(Mehr als "komplett" austauschen einer Menge von Wiederholungen
ist nicht drin, wir bekommen ja keine Update-Anweisungen a la "der
erste ist weggefallen, der zweite wurde stark korrigiert, der dritte
ist hinzugekommen und der vierte ist der ehemalige dritte unveraendert
...").

Im Prinzip ist hier das Problem, dass wir fuer die /Funktion/
eine Feldgruppe #8e im Internformat haben, damit wir die praktisch
indexieren und Anzeigen koennen. Fuer gewisse Zwecke wie etwa
Updates waere aber eine ganz andere Gruppierung viel praktischer.
In der Verbundwelt wird das datentechnisch oft so geloest, dass
gewisse Inhalte in Lokal- und oder Exemplarsaetze ausgelagert
werden, das ginge mit allegro moeglicherweise auch, wenn man die
Indexierung konzeptionell so erweitert, dass ein Datensatz
Indexate *fuer einen anderen* Datensatz erzeugen kann. Fuer
staerker FRBRisierte Datenbanken koennte es attraktiv sein, ueber
eine Variante von Nachladung eine Art virtuellen Konglomerat-
datensatz zu schaffen, anzuzeigen, zu indexieren und wieder zu
verwerfen (mit "#^kkf" hat die Exportsprache das m.W. bereits
als Feature, evtl. aber nur fuer hierarchische Datensaetze?). Hier
muessen wir aber abwarten, wie die Mainstream-Formate mit den
RDA-Anforderungen umgehen werden.

Fuer allegro koennte ich mir vorstellen (zurueck zum Park-Feld
und anderen), dass sich

#kkx|MARC21
oder
#8e1|GBV

nicht unbedingt entscheiden muss, ob es jetzt wirklich #kkx ist,
oder eines aus einer Gruppe von Feldern, die mit #kkx beginnen:

Moeglicherweise kann man ja die Eigenschaft "zweistelliges Format
mit einer Wiederholungs- oder Indikatorposition", die fuer das
jeweilige allegro-Datenformat derzeit ganz grundlegend ist, sehr
einfach abschwaechen zu "der Kategorienspeicher ist ein assoziatives
Array, dabei sind die ersten zwei Zeichen der Keys aus einer
per .CFG hinterlegten Liste, die auch weitere Eigenschaften zu
Unterfeldern etc. regelt" Dann muss man nur noch festlegen, ob
das erste Spatium oder das erste Unterfeldzeichen die Grenze
zwischen Felddeskriptor und echtem Inhalt markieren soll.
[Ich ventiliere das schon laenger, nicht wegen der Provenienzen,
sondern um das Problem der "Wiederholungszeichen" in den Griff zu
bekommen, die derzeit ein Byte Binaerdaten in etwas sind, das eher
Text ist und daher ist die Umstellung von Folgezeichen oberhalb von
127 auf "intern Unicode" nicht gut moeglich]]




> Jedenfalls stand ich schon oft vor dem Problem, das ja auch
> Ausgangspunkt der aktuellen Diskussion war, dass ich einen Inhalt
> uebernehmen wollte aber kein vorhandenes Feld wirklich passte. Dann
> bleibt bisher nur
> - weglassen
> - ein Feld nehmen, das schlecht passt
> - ein neues Feld einfuehren
> 
> Alle drei Alternativen finde ich unbefriedigend und da waere eine vierte
> Moeglichkeit
> - im Originalformat mitfuehren
> 
> meiner Ansicht nach besser, da Informationsverlust vermieden wird.

... zumindest an dieser Stelle. Aber wenn man erst einmal Daten
verlustfrei im Datensatz hat, kann man leichter Sachen ausblenden,
da keine endgueltigen Entscheidungen vorweggenommen sind.

Eine gute Illustration ist z.B. die heutige Diskussion um die GND-
Nummer. Das ist ja kein besonders hochfliegendes Konzept, aber
klarerweise ein Desiderat, ohne dass man dem allegro-Format nun
vorwerfen kann, es 1995 oder 2004 nicht antizipiert zu haben.
Aber die Suche nach einem moeglichst sprechenden Folgebuchstaben,
auf den man ein Kuerzel wie "GND" oder einen Code wie DE-588
abbilden koennen will, ist ein absolut artifizielles Problem,
mit dessen Loesung man keinen Blumentopf gewinnen kann.

*Eine* Teilloesung koennte z.B. auch darin bestehen, alle
vorhandenen Anwendungen mittelfristig auf die 2003 eingefuehrteren
freieren Ersetzungsschluessel (von "_" umschlossen) umzustellen,
dann koennte man naemlich auch mit URIs als Verknuepfungsnummern
arbeiten bzw. mit MARC-style-Identnummern  (DE-588)1234-5

Oder man aendert die Interna, damit auch die Zeichen "(", ")" und "-"
in "normalen" v14-Identnummern vorkommen duerfen. Allerdings muss
man dann sehr genau pruefen, ob da in existiernden .cPI's nicht
Umcodierungen am Werk sind, die die Klammern killen, dann sind doch
Eingriffe in Parameterdateien erforderlich...


viele Gruesse
Thomas Berger