[Allegro] Mal wieder was zu GND

Thomas Berger ThB at Gymel.com
Mo Okt 15 15:08:19 CEST 2012


Lieber Herr Eversberg,

>> Ich wollte dann mit m-Befehlen moeglichst treffendes einsammeln,
>> das hat dann aber nicht funktioniert, weil die D-Befehle
>> fuer das ISO-Format das entsprechende Feld stets entwertet
>> haben, egal ob ich es wollte oder nicht.
>>
> Das Entwerten macht der m-Befehl, nicht der D-Befehl.

ich erinnere mich nicht mehr genau, jedenfalls gab es eine
Diskrepanz in der Verarbeitungslogik zwischen den Typen
C und D, in Bezug auf Wiederholbarkeiten, "x" und "m"-Befehle,
die mich gezwungen hat, sehr explizite Schleifen zu programmieren.

Etwa in der folgenden symbolischen Art, um #6ns aus zwei alternativen
Beziehungsarten und drei moeglichen MARC-Feldern einzusammeln:


-kornazwno
  % #6ns Name spaeter <- 510,511,551 mit $94:nasp
  %      Nachfolger   <- 510,511,551 mit $94:nach
#u1
(R
%<*iso2709>
D "001"
%</iso2709>
%<*!iso2709>
s 0
%</!iso2709>
l 0
w ""
)R
C "94:nasp"
(
w "${wdhzei}"
Yxx
qkornasp0
)
C "94:nach"
(
w "${wdhzei}"
Yxx
qkornasp0
)
qkornaspno
-kornasp0
#6ns
kuxx
i 20
%<*iso2709>
d "510"
%</iso2709>
%<*!iso2709>
g 0 "510"
} 1
%</!iso2709>
c "94:nasp"
(W
x
} 2
w "${wdhzei}"
W ""
Yxx
)W
c "94:nach"
>W
qkornasp0
#6ns
kuxx
i 20
%<*iso2709>
d "511"
%</iso2709>
%<*!iso2709>
g 0 "511"
} 1
%</!iso2709>
c "94:nasp"
>W
c "94:nach"
>W
qkornasp1
-kornasp5
#6ns
kuxx
i 20
%<*iso2709>
d "551"
%</iso2709>
%<*!iso2709>
g 0 "551"
} 1
%</!iso2709>
c "94:nasp"
>W
c "94:nach"
>W
qkornasp5
#6ns
(C
kuxx
 b "${wdhzei}"
i 20
W " "
)C

-kornaspno

(alles noch etwas umstaendlicher dadurch, dass aus UTF-8-Gruenden
#6ns nicht als Zwischenspeicher fuer die eigenen Inhalte genutzt
werden darf, sondern alles in #uxx geparkt werden muss)


> Aber das Original-MARC-Format würde sich für eine an RegEx angelehnte
> Methodik sowieso nicht eignen, weil ja Tag und Inhalt keine
> zusammengehörige Zeichenfolge bilden.

Original-MARC waere z.B. auch MARCXML, Sie meinen also ISO 2709...

> Vorherige Umwandlung von Original-MARC mittels MarcEdit in das
> Externformat (mit  =245... als Feldbezeichnung, also Typ C) würde dann
> vielleicht noch bessere Möglichkeiten eröffnen.

Obiges Beispiel ist eigentlich recht typisch fuer MARC21-artiges:
Die Datensaetze aggregieren in wenigen Feldern oft eine Vielzahl
von Varianten (etwa die GND im Pseudo-Unterfeld "$94:") oder sogar
Alternativen ($2 bezeichnet die jeweilige "Ontologie" oder
wiederholbare $0 geben mehrere variante Verknuepfungsnummern zur
Auswahl).

Sofern man das nicht 1:1 abbildet, sondern in die aus der MAB-Welt
gewachsenen Formate, wozu ich auch die allegro-Formate zaehle,
umwandeln will, die differenziertere /Felder/ haben aber eben
nicht den zusaetzlichen Freiheitsgrad von Alternativen, und zudem
quasi orthogonal zum Quellformat sind, indem naemlich aus mehreren
wiederholbaren Eingangsfeldern sozusagen ueberkreuz die Inhalte
fuer diverse wiederholbare Zielfelder zu selektieren sind, bietet
es sich in der Tat an, die Importsprache um Mechanismen zu erweitern,
die eigentlich nur folgendes leisten sollten:

* Durchlauf durch alle Wiederholungen des Ausgangsfelds mittels
  m- bzw. m"..." Befehlen, dabei darf das Feld aber nur
  entwertet werden, wenn man explizit "x" gibt

* Eine vernuenftige Loesung fuer das "Wiederaufsetzen" im Fall
  des Einsammelns einer im Zielformat nur intern wiederholbaren
  Kategorie aus mehreren Eingangsfeldern auch im UTF-8-Fall.

Ich habe allerdings meine Zweifel, ob sich das halbwegs kompatibel
in die Importsprache einbauen laesst bzw. ob sich die vorhandenen
Befehle solcherart umimplementieren lassen, ohne existierende &
funktionierende Altimporte massiv zu stoeren.

Umgekehrt sehe ich allerdings auch bei Ihrem Regexp-Vorschlag
das Problem, dass - wie von Ihnen schon bemerkt - eine Uebertragung
auf Typ D schwer moeglich scheint, /und/ dass ich mir auch bei Typ C
nicht so recht vorstellen kann, an welcher Stelle nun die
implizite Entwertung des Feldes stattfindet, das da irgendwie vom
Regexp getroffen wird.

Ihre Loesung

#nnn
s 0 "500 .*$4obal"
...
m"; "

ist "etwas mehr" als nur die Vereinfachung des (nicht getestet!)

#nnn
s 0 "500 "
c "$4obal"
(
...
W"; "
)
l 0
m""

da es gewisse Eingangsfelder gar nicht besucht und daher durch m"" auch
nicht entwerten kann, so dass sie fuer spaetere Zugriffe noch verfuegbar
sind. Theoretisch koennte man aber auch genau die bereits selektierten
noch einmal besuchen wollen, etwa um ein anderes Unterfeld auszuwerten,
da hilft dann auch der verbesserte Positionierungsbefehl nicht ueber
die durch "m" stets stattfindende Entwertung hinweg.

Ich schlage vor, einmal in die folgende Richtung zu denken:
Wie waere es, wenn wir einen varianten m-Befehl, etwa "M" haetten,
der keine Entwertung der besuchten Ausgangsdaten vornimmt, koennte man
damit nicht bereits einiges wesentlich eleganter und durch den
Parameter-Programmierer feiner steuerbar hinbekommen?

viele Gruesse
Thomas Berger







Mehr Informationen über die Mailingliste Allegro