[Allegro] anzeige von einem hfm-feld in apr geht nicht(?)

[Thomas Berger]

Am 02.12.2015 um 08:17 schrieb Bernhard Eversberg:

> unabdingbar braucht. Es steht ja im Gegenteil immer noch die
> rigorose und durchaus vertretbare Position im Raum, HFM-Nummern
> niemals mit Semantik zu befrachten! Dann enstünde erstens das

Auch wenn ich mich zu dem Problem geaeusstert habe, ist das
immer noch und immer noch rigoros mein Standpunkt.

Ich sehe natuerlich die Eleganz, mit der ein einziges Zusatzfeld
#gn in der Lage ist, (scheinbar) einen gesamten GND-Satz treu
abzubilden. Der Teufel steckt dabei wie immer im Detail:

- MARC-Felder sind wiederholbar

- numerische Indikatoren duerfen nicht mit der Feldnummer verklebt
  werden: 60010 ist Feld 600 mit Indikatoren "1" und "0" und muss
  bei den 600ern einsortiert werden.

Man muss also beim Importieren doch die Eingangsdaten auf eine
spezielle, selbstausgedachte Art verwursten, und das bekommt
man auch hin, indem man die HFM-Zaehler stur hochzaehlt und
Original-Feldnummer und Indikatoren zum Inhalt schlaegt: So hat
es auch das "MARC-Park-Feld" MAB 999 in den Verbuenden gehalten.

Bei diesem Design verlieren wir allerdings die Moeglichkeit, gezielt
auf diejenige (oder die erste) Wiederholung zuzugreifen, die dem
Fremdfeld xyz entspricht: Man muss per Unterprogramm durch *alle*
Wiederholungen haspeln und selber auf die gewuenschte Bedingung
testen, das Ergebnis in einer Anwendervariablen zwischenspeichern
und nach Abschluss der Minischleife auswerten: Das kostet viel
Zeit und frisst am Kontingent der verfuegbaren Sprungmarken fuer
Unterprogramme.

Die Exportsprache ist optimiert auf Datenformate, in denen die
Feldnummer fuer die Semantik zustaendig ist, bereits in Kategorien-
schemata mit Indikatoren wird es uneleganter. In allegro-HANS
aber gibt es z.B. das frei wiederholbare Feld #002 ("klassisch"
wiederholt, d.h. #002, #002A, #002B, ...), das "fremde" Identnummern
aufnimmt, woher die jeweils stammt, ist in einem Unterfeld $z
hinterlegt. Ob ein Satz eine GND-Nummer traegt (und wenn ja, welche)
laesst sich nur durch Analyse aller Wiederholungen von #002 bestimmen:
Kommt irgendwo $zGND vor, ist es ein Treffer.

MARC-Formate bestehen nun ueberwiegend aus Feldern mit dieser
Charakteristik: /Weil/ tendenziell jedes Feld wiederholbar ist und mit
Unterfeldern ausgestattet, braucht die Feldnummer die Semantik nur grob
einzugrenzen, Details regeln Codes in Unterfeldern: Muss etwas neu
aufgenommen oder hinzudefiniert werden, benotigt man keine
Format-aenderung sondern nur eine Erweiterung der Codeliste: Das spart
redaktionelle Ressourcen und wird allgemein als Vorteil gesehen.

Tendenziell haben MARC-Datensaetze also wenige Felder mit extrem
vielen Wiederholungen, die Einfuehrung der HFM-Technik wurde nach
meiner Erinnerung nicht zuletzt deshalb forciert, weil in Freier
Wildbahn MARC-Saetze gesichtet wurden, die ein Feld in groesserer
Zahl enthielten, als die durch den klassischen Folgebuchstaben-
mechanismus moeglichen ca. 220 Wiederholungen.

In allegro kann man manchmal damit umgehen, indem man auf intern
wiederholte Felder umsteigt, das hat aber Vor- und Nachteile, die
gegeneinander abgewogen werden muessen. Den Versuch, HFM-Kennungen
mit Semantik "aufzuladen" sehe ich aehnlich, zumindest im aktuellen
Beispiel: Eigentlich will man nur testen, ob es irgendeine
Wiederholung mit einer bestimmten Bedingung gibt. Die haengt nun
zufaellig am Wiederholungszaehler, ist aber letztlich inhaltlich
definiert und es fehlt derzeit an einem Konstrukt der Export-
sprache, solche Tests oder Selektionen effizient vorzunehmen.

Und nicht nur in allegro: <
http://marcspec.github.io/MARCspec/marc-spec.html > ist z.B. ein
Versuch, die "ueblichen" Tests und
Selektionen, die man etwa fuer Datenkonversionen benoetigt, in
einer konzisen Sprache zu formulieren (und dabei XPATH zu
vermeiden). Die Einleitung verweist auf aeltere Anstrengungen
in diversen Kontexten:
"There are already implementations of MARC specs in tools like marcspec,
catmandu, solrmarc, easyM2R etc.. Each of them using a different flavour
of MARC spec. This document is an approach to normalize such field
specifications."

D.h. wir operieren zwar seit 60 Jahren oder so mit "records" in
immer derselben scheinbar einfachen Struktur (Felder,
Wiederholbarkeiten, Unterfelder, Wiederholbarkeiten davon,
Binnensyntax, ...) es fehlt aber immer noch an einer Sprache,
die "typischen" /Operationen/ auf solchen records auszudruecken.
Fragen wie "gibt es Feld 5000", "wie viele Felder 002 mit $zGND
gibt es" oder "endet das 245$b vorausgehende Unterfeld mit "="
muessen also ueberall auf der Welt situationsabhaengig mit den zur
Verfuegung stehenden Methoden "programmiert" werden.

viele Gruesse
Thomas Berger