[Allegro] Umgang mit Mehrfachkennung (Mehrfachkategorien)

[Bernhard Eversberg]

Am 04.07.2013 19:07, schrieb Thomas Berger:

>>> Am 02.07.2013 16:55, schrieb Sibylle Koczian:
>>>> Ich bin verwirrt. Ist denn nicht das von H. Berger als nützlich in die
>>>> Debatte geworfene Konstrukt "nächstes Mehrfachfeld"
>>>
>>> Wozu eigentlich wäre das nützlich?
>>>
>>
>> Um genau das einfacher zu tun, was sich jetzt mittels Trick 46 machen lässt:
>> iterieren durch Mehrfachfelder.

Statt Feldwiederholung besteht die Möglichkeit der Wiederholung
*innerhalb* des Feldes mit definiertem Trennzeichen. Sowas läßt sich
dann bequem beim Export und in FLEX abarbeiten. Nicht günstig ist es,
wenn der Feldinhalt in sich strukturiert ist, vor allem durch
Unterfelder.

>
> Nett, und unten drunter auch eine Variante von Heinrich Allers,
> die das Gesammelte in die iV schreibt, das war ja auch mein
> alternativer Ansatz mit dem "Filter-Kommando" anstelle der
> Iteration. Was nuetzlicher sein koennte, ist schwierig zu
> beurteilen: /Eine/ Schleife wird man in jedem Fall benoetigen,
> und ob man nur Einzeloperationen (wie etwa Loeschungen)
> durchfuehrt oder das gesammelte als Gesamtheit untersuchen
> kann, ist vorher nicht klar.
>
Grundsätzlich muß man sagen: Die interne Methodik der Adressierung
von Feldern ist rigoros auf Performanz optimiert. Das ist bei allen
umfänglichen Exporten, und bes. beim Indexieren, wichtig. Da müssen
mitunter weit mehr als 1000mal einzelne Felder angesprochen, also
im internen Speicher aufgefunden werden. Das geschieht nicht durch
ein textuelles parsing durch den Satztext, sondern beim Einlesen wird
eine Hilfsliste angelegt (Array int gi[] in record.cpp). Beim Einlesen
der Parameter werden dann die Feldnummern im Parameterspeicher auch
nicht als solche abgelegt, sondern deren interne Nummern, die sich aus
der CFG-Reihenfolge ergeben. Hinzu tritt der Mehrfachcode. So wird
jedes Feld sehr schnell gefunden.
Ganz ähnlich ist es mit den #u-Variablen.
In dieser Methodik wäre es nun ein Problem, Mehrfachfelder zu verwalten,
die kein unterscheidendes Merkmal haben, wie z.B. in MARC21, Unimarc und
teilweise in Pica3. Die kann man nicht eindeutig adressieren. Auch die
Idee mit den nicht festgelegten Feldnummernlängen oder mit den mehr
als einstelligen Wiederholungskennungen wäre nicht einfach zu lösen.

Und wenn man nun daranginge, die interne Struktur und Adressierung der
Datensätze und -felder grundlegend zu ändern, hätte das weitreichende
Auswirkungen auf Parameter und FLEX. Sicher wird hieraus verständlich,
daß eine "Aufbohrung" in Richtung liberalerer Feldwiederholung keine
leichte Aufgabe wäre und u.U. sogar (erstmals) die Rückwärts-
Kompatibilität durchbrechen müßte. (PRESTO wäre dann mausetot, aber das
soll kein Argument sein.)

>
> Solche Szenarien sind einer der Gruende, warum das "Record"-Konzept
> der Bibliotheksdaten an Grenzen gestossen ist: Ich habe nicht
> mehr den perfekten Datensatz, den ich jahrzehntelang nicht mehr
> anfassen brauche.

> ...angemessener waere eine
> Vielzahl mit der "Hauptdarstellung" verknuepfter Mini-"Records",
> die im Extremfall nur eine einzelne Zusatzinformation tragen.
>  ... Nach meinem Verstaendnis
> ist das genau die Stossrichtung der Bibframe-Entwicklung.
>
So sieht das aus. Die Jungtürken in der BIBFRAME-Szene [pardon, falls
so ein Wort nicht mehr politisch korrekt sein sollte], aber anscheinend
auch ein paar nicht so junge, scheinen da sehr zuversichtlich. Obwohl
ein "proof of concept" m.E. noch fehlt, jedenfalls in den für uns
entscheidenden Dimensionen und Komplexitäten.
Wie auch immer: Versuchen könnte man ja auch innerhalb allegro,
verknüpfte Mini-Datensätze mit jeweils nur einem Feldinhalt, also ein
Analogon zu einem RDF-Tripel, zu definieren. Irgendeine Erweiterung des
bestehenden internen Datenkonzepts scheint dafür nicht nötig. Nur
natürlich ein paar hundert mehr Parameterzeilen.
Wir stellen das mal anheim.

B.E.