[Allegro] Umgang mit Mehrfachkennung (Mehrfachkategorien)

[Thomas Berger]

Lieber Herr Eversberg,

> Das ist das eine, das andere die Tatsache, daß bei den ganz normalen
> Bibliotheksanwendunden, wie sie typisch sind für die A-Anwender,
> generell kein Bedarf für extremere Mehrfachbelegungen besteht und
> außerdem auch oft die simplere Wiederholung innerhalb von Feldern mit
> Trennzeichen ; oder Strg+t genutzt wird.
> Es sind die etwas individuelleren Projekte abseits der gewöhnlichen
> Katalogisierung, die gelegentlich einen exorbitanten Bedarf entwickeln
> für Feldwiederholungen. Dafür sollte man sich vielleicht in Zukunft
> den Namen BIBFRAME merken in Kombination mit Linked Data und RDF
> Triples. Da wäre z.B. jedes einem Objekt zugeordnete Schlagwort ein
> getrennt gespeichertes Triple, welches aussagen würde: Objekt 123 hat
> das Schlagwort XYZ, und mehr nicht. Ein Triplestore kann zu jedem Objekt
> beliebig viele solche Statements enthalten, aber Mehrfachkennungen

+1 fuer die Umwandlung der .ald-Dateien in einen Triplestore.


> gibt es da gar nicht. Wie ja auch im echten MARC21 die wiederholbaren
> Felder keine Mehrfachkennung besitzen! Dies ist mit allegro ja auch
> so nicht abbildbar.

Darueber habe ich in den letzten Tagen nachgedacht: Im Prinzip
gibt es m.E. keine zwingenden Gruende, die Mehrfachkennungen
explizit zu machen (das Problem einmal beiseite gelassen, dass
manche davon, insbesondere in $A.CFG, bedeutungstragend im Sinne
eines Indikators sind)

Das, was in einer .ald-Datei steht, kann sequentiell als Datensatz
geladen werden (wobei es allerdings ab und zu eine Umsortierung
anhand der aktuellen .CFG-Reihenfolge gibt, die traditionell die
Reihenfolge der echten Kategorien beruecksichtig, aber unangenehmeweise
nie die zu den Kategorien notierte Reihenfolge der Mehrfachkennungen)

Beim Editieren und unmittelbaren Einfuegen eines Felds haben
wir allerdings das Problem, dass dieses Feld etwas bereits
vorhandenes ersetzen soll: Diese Identifikation betrifft aber
eigentlich (wichtig: Gibt es hier einen Denkfehler?) nur einen
zeitlich kleinen Bereich der "Bearbeitung" eines konkreten
Datensatzes innerhalb eines konkreten Programms, also den
Zeitraum, wo a99 ein gewisses Formular zeigt oder wo ein
bestimmter Flex ablaeuft: D.h. die Identifikation des durch
etwas bearbeitetes zu ersetzenden muss ja gar nicht an Bytes
gebunden sein, sondern koennte auch ein anderes "Token"
benutzen, das mir der Auslesevorgang mit dem Inhalt mitgegeben
hat.

Konkret:
Wenn ich beim Klick auf #36[nichtdarstellbareskloetzchen] im
Auswahlfenster ein
#36<12345>
ins Schreibfeld bekomme und darauf achte, das "<12345>" nicht
zu zerstoeren, dann sollte die Ersetzung des vorhandenen Felds
nach Abschicken des Schreibfelds mit Enter doch kein Problem
darstellen?

Und damit koennte ich dann in den .ald-Dateien ganz ohne Folgezeichen
auskommen (wg. UTF-8 ein starkes Desiderat), und ausserdem eine
echt freie Wiederholbarkeit hinbekommen und der "Preis" dafuer
waere nur, dass a) die interne Repraesentation /eventuell/ nicht
Byteidentisch mit der .ald-Datei ist und b) die /Kommunikation/
zwischen "Speicher" und "Bearbeitung" etwas staerker zwischen
"Daten" und "Adressierung" unterscheidet: Bislang kennen wir
das von "#" zur Adressierung von Kategorien (das Zeichen ist
in den Daten nicht bzw. anders praesent) und "$" fuer
Unterfeldzeichen (uneinheitlich: In Flex und Parameterdatei
zur Adressierung erlaubt, in "echten" Eingaben nicht, denn
sonst koennte man keine Preise in USD anggeben) und bekaeme
nun noch etwas fuer "Wiederholungszaehler" hinzu.

Wenn wir uns "record"-orientierte Datenformate wie MARC oder
MAB oder PICA anschauen, und deren Serialisierungen als XML
oder JSON, dann sind das ja alles Baum-artige Strukuren, die
alle nicht besonders tief gehen: Es gibt zwei Stufen im "record",
naemlich "field" und "subfield". Und es gibt Faelle, wo das eine
oder das andere wiederholbar ist, in solchen Faellen wird nicht
explizit angegeben, dass es sich nun um die x-te Wiederholung
handelt (diese Aussage koennte dann im Konflikt mit der tatsaechlichen
Reihenfolge in der konkreten Serialisierung stehen).

[Solche "freien" Wiederholbarkeiten /machen/ in der Praxis Probleme,
denn wenn ich ein Update einer Dreiverfasserschrift bekomme,
das nur noch zwei Verfasser liefert, kann ich nur die jeweiligen
Momentaufnahmen betrachten, also 3 gegen 2 und ich weiss nicht,
ob der zweite entfallen ist oder der dritte oder ob beide gegen
eine ganz andere Person ausgetauscht wurde: Ich bekomme niemals
eine konkrete Update-/Anweisung/ und kann daher stets nur die
alte /Liste aller Verfasser/ gegen die neue austauschen. allegro
benennt sie derzeit zwar #40, #402 und #403, das hilft mir in
der Situation aber nicht, weil der "2. Verfasser" und der "3. Verfasser"
nur instantiell sind: Loesche ich #402 ist der vormals dritte
Verfasser jetzt der zweite und ich muesste strenggenommen #403
nun umbenennen. Und aufgrund der Natur aller real existierenden
Fremddaten bekomme ich als Rohergebnisses eines Imports auch nie
die Konstellation #40 + #403 herein, die es mir ermoeglichen
wuerde, gezielt #402 zu loeschen...]

In so einer XML oder JSON-Situation (oder auch ein DOM-Objekt,
das ich mit Javascript bearbeite) habe ich nun stets eine
darauf zugeschneiderte Adressierungssyntax, d.h. ich kann
nicht nur das Field mit Tag "36" selektieren oder das
Subfield mit Code "x", sondern auch das Dritte Unterfeld mit
Code "x" im zweiten Feld mit Tag "36" (und noch so einiges
mehr). D.h. direkte Adressierung ueber Attribute plus
Nennung der gewuenschten Wiederholungsnummer liefert mir dann
exakt ein einzelnes Datenelement, auch ohne dass ich die
Wiederholungsnummer als Code ueberall explizit machen musste.
Der erforderliche Schritt ist allerdings, dass sich "eigentliche
Daten" und Adressierungssyntax voneinander unterscheiden. Das
ist aber auch in allegro bei Formular-Syntax und Cstrings in
Ansaetzen bereits angelegt.

viele Gruesse
Thomas Berger