[Allegro] HFM und Formulare

[Bernhard Eversberg]

Am 19.01.2015 16:40, schrieb Thomas Berger:

>> Das wäre, bis auf das Präfix #gn, genau die Pica-Form des
>> GND-Schlagwortsatzes für das Datenbanksystem allegro.
>
> ... Wo 550 und viele andere wiederholbar sind...
>
Da haben Sie recht, ganz so einfach wie behauptet geht
es nicht, denn HFM-Felder als solche sind nicht wiederholbar.
Man hätte Importparameter zu schreiben, mit denen Mehrfach-
felder zu einem zusammengefaßt würden, unter Anwendung einer
eindeutigen Zeichenfolge zur Trennung.

> unaufwendig Fremd-Nummern 1:1 verarbeiten zu koennen. Meine
> Phantasie ging da eher in die Richtung, Feldnummern freier
> Laenge zuzulassen, etwa #GN550 - das sollte eigentlich
> unproblematisch sein, wenn der Feld/inhalt/ mit Unterfeldzeichen
> beginnt, wie bei echtem MARC], brauechten Sie Doppel-HFM:
> ...
>
> Alternativ kann man natuerlich mit langen Nummern arbeiten, die
> letzten drei Stellen sind fuer die Zaehlung. Dann muss man
...

Schon richtig, man kann sich einiges ausdenken. Wir haben ja
hin und her überlegt, letztlich aber wollten wir keinen Bruch
herbeiführen, bei dem die neuen Programme nicht mehr ohne
Datenänderungen auf alten Datenbanken hätten operieren
können.
Mit Formulierungen wie "Feldnummern freier Länge zuzulassen"
oder "kann man natürlich mit langen Nummern arbeiten" entsteht
der Eindruck, eine Realisierung wäre ja wohl kein großes
Problem, wir müßten das nur "zulassen", vielleicht einen Schalter
umlegen oder sowas. Die Realität sieht leider anders aus, das wird
aber gerade Ihnen wohl auch klar sein.
Die Doku in vb260 veranschaulicht denn doch, was alles zu bedenken
ist und folglich mit einem veränderten Modell eben auch zu
Programmänderungen zwingen würde, wobei die Wahrung der Kontinuität,
d.h. unveränderte Weiterarbeit mit alten Parametern, CFGs, FLEXen,
Formularen, wahrlich kein Pappenstiel ist. Es war Schwerarbeit,
glauben Sie's einfach mal, HFM umzusetzen, und jede andere denkbare
Modalität wäre, bin ich jedenfalls überzeugt, noch schwerer gewesen.

Und weil nun der Trend eindeutig weg von Kategorienummern geht und
hin zu verbalen XML-Tags, muß man auch überlegen, wieviel Aufwand
sich noch lohnt - denn das wird definitiv ganz andere Software mit
ganz anderen Kernkonzepten brauchen. Schon VuFind hat zwar noch MARC
innerhalb von Solr, aber ansonsten eine ganz abstrakte Datendefinitions-
Ebene, die nicht mit Nummern und geläufigen Satzkonzepten arbeitet.
Die könnte auch weiter funktionieren, wenn sich innerhalb von Solr die
Daten in ganz anderer Form befänden.
Aber andererseits: VuFind ist eine Suchmaschine mit einer modernen
Oberfläche, sonst nichts!

B.E.