[Allegro] Hochfrequente Mehrfachfelder : Neue Lösung gesucht

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,


>>> und statt 2 und 3 kann es auch lauten 0 und 1 oder 1 und 9 oder
>>> a und b oder X und Y usw. - Die Zeichen müssen nur eindeutig sein,
>>> d.h. zweimal #40a in einem Satz geht nicht.
>>
>> Ich denke, das ist die Stelle, an der angesetzt werden muss:
>> Die Mehrfachcodes muessen weg!
>>
> Zuzugeben ist: Die allegro-Mehrfachmethodik ist eigenwillig und folgt
> keinem Standard. Allerdings gibt es auch keinen, der explizit
> durchdacht wäre. MARC und Pica (und teilweise MAB) wiederholen schlicht
> die Nummer. Auch XML-Schemata haben eine schlichte Wiederholtechnik
> ohne individualisierende Kennzeichnung der einzelnen Feldinhalte.

Wenn es mehrere gleichartige Sachverhalte gibt, stehen sie
(bei einer "Serialisierung") hintereinander, jeweils als der
Sachverhalt gekennzeichnet. Manchmal ist die Bedeutung dabei
die einer "geordneten Liste" (etwa Absaetze in in einem Text
zum Lesen, Sacherschliessung von den Haupt- zu den Nebenaspekten),
manchmal die einer ungeordneten Liste, bzw. einer einfachen
Menge (etwa alles was als RDF codiert wird, oder sonstige
beteiligte Personen), das wird syntaktisch nicht unterschieden.

In bibliothekarischen Daten ist es fast immer der Fall "geordnete
Liste", d.h. die Benutzer legen beim Erfassen eine bestimmte
Reihenfolge fest und bei der Verarbeitung muss die stets
erhalten bleiben.

Elemente in einer geordneten Liste haben eine Position, darueber
hinaus kann man in XML jedem (XML-)Element eine Id verpassen,
in MARC21 gibt es mit $w eine aehnliche Technik.

Differenzierung der Nummer benoetigt man in den folgenden zwei
Arte von /Gruppierung/:

Aus MAB bekannt: Zusammengehoeriges ist auf mehrere Nummern
verteilt, etwa 100 - 103 fuer verschiedene Datenelemente zur
ersten beteiligten Person, will man das Wiederholbar machen,
kann man nicht erneut 100 - 103 nehmen (wo endet die erste und
beginnt die zweite, meist sind ja nicht alle belegt) sondern
muss mit 104-107 vier voellig neue Nummern spendieren.
(Weder in MAB noch in MARC wurde spezifiziert, ob Benutzer oder
Anwendung die Reihenfolge der Felder mit /verschiedenen/ Nummern
festlegen. In der Praxis ordnen alle Systeme nach dem Sortierwert
des Tags, d.h. die Anwender koennen die Reihenfolge nicht beeinflussen)

RSWK-Schlagwortfolgen in MARC21:
Da pro Feld nur eine Verknuepfung moeglich ist, muessen die
Folgenglieder der ersten Schlagwortfolge auf je eine Wiederholung
(von MARC 689) aufgeteilt werden. In frueheren Entwuerfen fuer
die "deutsche Anwendungsschicht" wurde dann fuer die 2. bis 9. Folge
ein jeweils neues Feld spendiert.
(Durchgesetzt hat sich aber die Methode, die nur mit einem Feld,
naemlich 689 auskommt, in den Wiederholungen wechseln sich
Felder fuer die eigentlichen Folgenglieder und solche, die die
Nummer bzw. das Ende einer konkreten Folge angeben, ab.

Allegro hat die Beschraenkung auf "nur eine Verknuepfung pro Feld"
nicht, insofern sind /interne/ Wiederholungen ein maechtigeres
Werkzeug als in den Austauschformaten. Oft sind sie als Alternative
zu Feldwiederholungen gedacht, das fuehrt aber staendig zur
Situation, dass in einer Datenbank oder gar einem Datensatz sowohl
interne als auch echte Feldwiederholungen genutzt werden und die
Frage aufscheint, ob es da einen intendierten Bedeutungsunterschied
gibt. Im Zusammenhang mit Unterfeldern fuehren interne Wiederholungen
ebenfalls zu einer unklaren Situation: Gilt das Wiederholungszeichen
in Bezug auf das aktuelle Unterfeld (und warum wurde es hier nicht
einfach wiederholt), oder gilt es in Bezug aufs Feld, d.h. trennt
ganze Gruppen von Unterfeldern?

All diese Wiederholbarkeiten sind traditionell nur durch ihre
relative Position im aktuellen Datensatz "adressierbar", insbesondere
also nicht persistent: Kommt z.B. ein Update mit zwei beteiligten
Personen fuer einen Datensatz mit bislang drei, dann kann ich
nicht entscheiden, ob eine entfallen ist oder ob zwei entfallen
und eine neu hinzugekommen ist oder ob eine der nicht entfallenen
ihre Position oder ihre Funktion geaendert hat: Ich kann nur die
komplette bisherige Menge oder Liste der Personen entfernen und
die komplette neue Liste uebernehmen.
[Das ist eines der Probleme, die man in der Post-MARC-Aera zu
loesen hofft: Habe ich drei Personen aus Fremddaten, eine lokal
ergaenzte Person fuer einen Spezialsachverhalt und zu den
Fremddaten-Personen noch lokale Anreicherungen, dann will ich bei
einem Re-Import aus der Fremddatenquelle nur die Angaben "putzen",
die tendenziell auch wieder geliefert werden, nicht meine
Anreicherungen oder Angaben aus weiteren externen Quellen]

Aus meiner Erfahrung gibt es bei der Bearbeitung von Datensaetzen
folgende Anforderungen:

* Zugriff aufs "erste" (oft das Bedeutsamste)

* Loeschen eines bestimmten Listenelements

* Anfuegen eines Elements ans Ende der Liste

* nacheinander Durchlaufen in der gegebenen Reihenfolge

* Test darauf, ob die Liste "voll" ist (manchmal gibt es
  eine Mengenbeschraenkung, bzw. (artifizielles Problem)
  beim Konstruieren von Flips muss ich testen, ob das
  letzte moegliche Folgezeichen fuer #uY~/#uZ~ bereits
  verbraten ist: Weise ich noch mehr zu, bricht sonst
  Chaos aus.

 Traditionell in allegro nicht realisierte Desiderate:

* Neu-Sortieren der Liste

* Einfuegen an beliebiger Position in der Liste

* Loeschen des ersten Elements einer Liste

* Behandlung von Anwendervariablen als Liste


> So etwas geht bei der internen Technik der Satzverwaltung in
> allegro nicht, sondern jedes Feld braucht seine Identität, und sie
> liegt nicht einfach in der Position innerhalb einer Folge von Feldern
> mit gleicher Nummer, sondern sie liegt in dem Zeichen direkt hinter
> der Feldnummer. Dies grundsätzlich zu ändern würde einen nicht
> unbeträchtlichen Änderungsaufwand innerhalb der Programme bedeuten.

Naja, aber die von Ihnen vorgeschlagene Loesung von 63 Wiederholungen
pro Feld und von der Anwendung spendierten Hilfsfeldern mit je
63 weiteren Wiederholungen wuerde unabsehbaren Aufwand fuer alle
Anwendungen bringen (und ist keine Loesung fuer Anwendervariable
wie die fuer Flips): Es muessen ja nicht nur alle Zeilen, die eines
der Felder nutzen, dupliziert werden, sondern im Fall von bedingten
Postfixen muss individuell meist eine voellig neue Loesung
implementiert werden (Die CFG-Reihenfolge mag zwar festlegen, dass
#4Aff, #4Bff, etc. zwischen #40ff und #41ff gespeichert werden,
aber die Zeile

#40 ++ >K m>k #00 1 #40z 2 #69 3 #72 >m #76 1

kann nicht schematisch gedoppelt und von "#40z" auf "#4Dz" umgestellt
werden, den bei diesen Vergleichen ist dann #41 m.W. dann ebenfalls
umfasst. Man braucht dann also (ohne Gewaehr) mindestens eine
Umformulierung als

#40 ++ >K m>k #00 1 #40z 2 #49z 3 #4Dz 2 #69 3 #72 >m #76 1
#4A. ++ >K m>k #00 1 #40z 2 #49z 3 #4Dz 2 #69 3 #72 >m #76 1
#4B. ++ >K m>k #00 1 #40z 2 #49z 3 #4Dz 2 #69 3 #72 >m #76 1
#4C. ++ >K m>k #00 1 #40z 2 #49z 3 #4Dz 2 #69 3 #72 >m #76 1
#4D. ++ >K m>k #00 1 #40z 2 #49z 3 #4Dz 2 #69 3 #72 >m #76 1




> Zu ändern wäre zum einen auch die Felddefinition der CFG, oder doch
> deren Interpretation durch die Programme, zum andern kann es
> vielfältige Aus- und Nebenwirkungen, die zu Änderungen zwängen, auch
> in den Parametern und FLEXen geben, in denen mit Mehrfachfeldern
> gearbeitet wird.

Mein Vorschlag ist,

#40<17>

oder - mehr Mainstream -

#40[17]


sagen zu duerfen fuer die 17. Wiederholung von #40

In Parameterdateien duerfte das direkt nie genutzt werden (ausser in
ganz primitiven, die sich das "++" sparen und alle Wiederholungen
direkt auflisten - hoffentlich gibt es keine Luecken), Beim holen
oder Rueckspeichern mit "w" wird man aber um die Angabe der gewuenschten
Wiederholung nicht herumkommen.

Um Ersetzungsbefehle nicht zu gefaehrden, darf das natuerlich nicht
"echt" im Datenfeld stehen, es ist nur eine Auszeichnungssyntax.

Es braucht dann zusaetzlich noch einen Manipulationsbefehl, der
zu einem Feld seine Wiederholungsnummer liefert: Bislang kam man
ueber Indikatoraktionen oder s-Befehle da mit einigen Muehen
heran (man braucht es aber nicht besonders oft), das soll aber nicht
verloren gehen, fuer "w" in der Exportsprache braucht man es wie
erwaehnt auch wirklich.

Ob wirklich so viel Code von allegro geaendert werden muss,
bezweifele ich: Felder sind sortiert in CFG-Reihenfolge im
Arbeitsspeicher abgelegt und werden anhand der Nummer gesucht,
das aendert sich nicht, nur muss nun (aehnlich wie bei #kk.)
eine bestimmte Wiederholung ermittelt werden. Oder man haelt
das #40[17] sogar im Kategoriespeicher, muss bei der
Vorbereitung von Arbeitstexten allerdings dafuer sorgen dass
"[17]" nicht gezeigt wird..



> Was Berger *eigentlich* will, das ist ein neues System, das nicht nur
> an dieser Stelle bessere Eigenschaften hätte, sondern an sehr vielen
> anderen Stellen auch. Das wird auch kommen, aber woher, das weiß im
> Moment noch keiner. Dann braucht's nur noch  einen "Migrationspfad",
> und das ganze Gerümpel der Parameter etc. kann in den Schrott. So ist
> doch der Lauf der Welt, oder nicht?


> Im Kontext eines existierenden und vielfältig eingesetzten Systems aber,
> das läuft und das weiterlaufen soll, da kann man nur vorsichtig
> operieren. Es gibt neuerdings das Konzept des "Incremental Commitment
> Spiral Model", demzufolge man den Fortschritt nicht als einen Gewaltsprung,
> sondern als Folge kleiner Schritte in die richtige
> Richtung verstehen sollte, die jeweils überschaubar sind und
> konkret durchführbar aber auch jeweils einen Vorteil bringen.

So war es bei allegro schon immer. Nur das mit der "richtigen
Richtung" kann in der Rueckschau machmal anders aussehen: Dann
handelt es sich um "Geruempel". Wird man das nicht irgendwann
wieder los, werden spaetere Schritte (egal in welche Richtung)
immer muehsamer.

Das konkrete Problem haben Sie ja zutreffend beschrieben, und es
ist seit 2003(!) der Knackpunkt dafuer, dass Datenbanken nicht
nach Schema Eff auf Unicode umgestellt werden koennen: Ueberall
mittendrin im Text, naemlich genau zwischen Feldnummer und
Feldinhalt steht das Folgezeichen mit seiner Doppelnatur als
"Zeichen" (das der Anwender sieht und eingibt) und binaerem
8bit-Integer-Zaehler (womit das Programm operiert).

Das hat schon immer Aerger gemacht:
- Anwender fanden, dass die theoretisch 220 nutzbaren Wiederholungen
  zu wenige sind

- Neue Syntaxkonstruktionen ($, ù, ~, ., ...) fuehrten immer wieder
  dazu, dass Daten mit nunmehr ungueltigen und unzugaenglichen
  Wiederholungszeichen "entstanden"

- Erst letztes Jahr fiel auf, dass die notwendige Ostwest<->Windows-
  Umsetzung allerhand Wiederholungen zusammenfallen liess, daraufhin
  wurde das Mapping so erweitert, dass nun in Ostwest ungenutzte
  Zeichenpositionen, die aber als Wiederhlungs-"Zahl" dennoch
  wichtig waren, nun irgendwie auf allegro-Windows gemappt werden.

Ich finde durchaus, dass dieser Binaermuell in Textdaten unbedingt
abgeschafft werden muss, besser jetzt als spaeter. Nur finde ich,
dass es keinen Zwang gibt, dass Internanzeige eines Satzes,
interne Repraesentation im Arbeitsspeicher und gespeicherte Version
in der .cLD-Datei /zeichenidentisch/ sind. Es genuegt, hier effiziente
1:1-Umsetzungen vorhalten zu koennen, in ganz beschraenktem Umfang
wird das ja auch bereits gemacht, indem fuer die Internanzeige
ein "#" vor die Feldnummer montiert wird und das Zeichen 0 am
Feldende durch \n dargestellt. Warum kann also nicht der Binaerzaehler
a) gar nicht gespeichert
und
b) als Zaehler dargestellt werden?

viele Gruesse
Thomas Berger