TYP, LABEL und ORDERLABEL in Überordnung speichern

[BartChris]

Die Verwendung von LABEL und ORDERLABEL bei Bänden einer Überordnung, sowie generell die Arbeit mit Überordnungen sind von vielfältigen Usability-Problemen betroffen:

• Übergeordnete Vorgänge mit sehr vielen zugeordneten Bänden sind im Metadateneditor kaum zu öffnen un erst recht nicht vernünftig bearbeitbar (siehe insbesondere Reduce the time to open superordinate processes with many subordinate processes #5934)
• Beim Export von Überordnungen besteht das Problem, dass die LABEL der Teilbände, die für die Anzeige im DFG-Viewer wichtig sind bereits vorhanden sein müssen, um in der Überordnung enthalten zu sein. Dies erzwingt diese Information bereits vor dem Export eines Bandes für alle Bände bereitzustellen. Dies erfordert LABEL in Kitodo parallel zu (evtl. identischen) Titelangaben zu verwalten. (siehe insbesondere Automatically set outline headings  #5016)
• Die Anzeige der Teilband-Informationen in Kitodo ist oft nicht zu verwenden, da nur Identifier-und Titel-Informationen angezeigt werden, die nicht immer Rückschlüsse zulassen, welcher Band genau vorliegt, zumal auch die Metadaten der Teilbände nicht im Metadaten-Editor der Überordnung angezeigt werden können. (siehe Show options "Type", "Title" and "Type - Title" in metadata editor structure panel #4925 (reply in thread))

Kitodo arbeitet stets mit der Grundannahme, dass TYPE, LABEL und ORDERLABEL eines Teilbandes stets nur beim jeweiligen Band verwaltet und dann (unter Inkaufnahme hoher Ladezeit) ad hoc in die Überordnung geladen werden.
#3436 (comment)

To display the structure tree, every linked child METS file must be read. A newspaper annual process with children can be opened, it simply takes some time. The more children, the more time is needed. (A detailed performance analysis of this can be found in KIT-1112.)

Ich würde daher gerne zumindest versuchsweise die Frage ansprechen wollen, ob es nicht möglich ist, diese Information auch in der internen Kitodo-METS-Datei der Überordnung zu speichern. Das hätte den Vorteil, dass sie sowohl beim Export der Daten als auch bei der Anzeige sofort vorhanden wären, was viele Prozesse beschleunigen würde.

<mets:structMap TYPE="LOGICAL">
        <mets:div ID="uuid-390ab1bf-d6d2-4cc3-9606-e7a68173b882" DMDID="uuid-d1190b8e-913b-3edd-8c38-74564270ee56" TYPE="periodical" ORDER="1" LABEL="Meine Überordnung">
            <mets:div ID="uuid-7e59a709-1a25-44ff-9e5b-bf780ad089b0">
                <mets:mptr LOCTYPE="OTHER" OTHERLOCTYPE="Kitodo.Production" xlink:href="database://?process.id=3813"/>
            </mets:div>
        </mets:div>
    </mets:structMap>

Konkret hieße das also, in der METS-Datei der Überordnung, die die Unterordnungen nur per Pointer referenziert, auch das LABEL, den TYPE und das ORDERLABEL zu ergänzen:

<mets:structMap TYPE="LOGICAL">
        <mets:div ID="uuid-390ab1bf-d6d2-4cc3-9606-e7a68173b882" DMDID="uuid-d1190b8e-913b-3edd-8c38-74564270ee56" TYPE="periodical" ORDER="1" LABEL="Meine Überordnung">
            <mets:div ID="uuid-7e59a709-1a25-44ff-9e5b-bf780ad089b0"  TYPE="volume" ORDER="1" ORDERLABEL="MEIN ORDERLABEL" LABEL="MEIN LABEL">
                <mets:mptr LOCTYPE="OTHER" OTHERLOCTYPE="Kitodo.Production" xlink:href="database://?process.id=3813"/>
            </mets:div>
        </mets:div>
    </mets:structMap>

Das würde dann an folgenden Stellen relevant:

• bei der Anlage des Vorgangs kann, sofern diese Information (im Mindesten der TYPE) vorhanden ist, die Information auch in die Überordnung eingetragen werden
• Bei Änderung der Metadaten und Änderung des Strukturtypen (des Wurzelelements) kann die Information auch in der Überordnung aktualisiert werden
• Beim Export eines Bandes kann - insbesondere wenn die LABEL-Information erst durch das Export-XSL-erzeugt wird - das LABEL auch in die (interne Kitodo-) METS-Datei der Überordnung geschrieben werden und ist dann beim Export weiterer Bände bereits vorhanden. Dies würde das Problem lösen, dass die LABEL der Unterordnungen bereits vor dem Export besetzt sein müssen.

Gegen diese Herangehensweise spricht vermutlich eine Verdopplung der Datenhaltung in den XML-Dateien, die technisch evtl. nicht ganz sauber und auch nicht zwingend notwendig ist, aber zumindest die Arbeit mit Überordnungen erheblich erleichtern und beschleuingen würde. Auch dauert es dann vermutlich länger, Änderungen an der einzelen XML-Datei zu speichern, da die Änderungen auch an die METS-Datei der Überordnung weitergereicht werden müssen. Da ich nicht mit Zeitungen arbeite, habe ich die Rückwirkungen auf die Zeitungsprozesse auch noch nicht bis zum Letzten durchdurcht.

Evtl. bietet auch Hibernate-Search Möglichkeiten bestimmte Informationen der Teilbände direkt in der Hibernate-Search-Repräsentation der Überordnung zu speichern (siehe #6095 (reply in thread)), das könnte man also auch diskutieren. Das wäre aber vermutlich umständlicher, als die Werte in die XML-Datei zu speichern.
In beiden Varianten (Speichern in METS-Datei oder in Hibernate Search) gibt es natürlich immer das Problem, was ist, wenn XML-Daten per Skript verändert werden. Hier müsste man dann überlegen, ob man eine Option schafft, die METS-Datei der Überordnung zu synchronisieren bzw. zumindest beim Export eine Synchronisierung der LABEL zu ermöglichen.

Dies nur einmal als Diskussionsaufschlag, um diese Variante zumindest einmal diskutiert zu haben, auch wenn sich herausstellen sollte, dass das keine gute Idee ist. Vorschläge, Usability und Performance der Arbeit mit Überordnungen zu erleichtern, werden m.E. dringend benötigt

[henning-gerhardt]

Auf den ersten Blick, sieht es natürlich verlockend aus, diese Informationen direk in der Überordnung zu speichern. Ob dies aber auch wirklich der Fall ist, sollte man zumindest mit weiteren theoretischen Speicherorten oder Datenbereitstellungen vergleichen. Dabei muss aber auch die jeweilige (theoretische) Implementierung und die Wartung dieses Codes mit bedacht werden.

Bei der Überlegung, wie die Speicherung der Informationen in der Überordnung bzw. dessen Metadaten Datei gespeichert werden kann und wo es an diesen Stellen zu Problemen führen kann, bin ich auf die folgenden Punkte gekommen. Diese sind ggf. nicht nur für eine Speicherung im Dateisystem relevant sondern ggf. auch für andere Orte und / oder Zugriffsarten.

1. Synchronisierung
   Wenn man an mehreren Stellen die gleichen Daten ablegen will, dann hat das Synchron halten dieser Daten oberste Priorität. Nichts ist schlimmer, wenn diese Daten nicht mehr synchron sind. Es stellt dann zu Recht die Datenhaltung bzw. Synchronisierung in Frage, da man sich nicht mehr darauf verlassen kann, dass Synchronisierungsfehler nicht nur an der einen erkannten Stelle passiert sind sondern vermutlich noch an vielen anderen, die man nur noch nicht entdeckt hat. Man könnte sich vielleicht damit behelfen, dass in regelmäßigen Abständen eine Synchronisierung stattfindet, aber das umgeht das Problem nur und löst es nicht nachhaltig. Davon abgesehen, dass die Synchronisierung bei sehr vielen Hierarchien und Vorgängen vermutlich sehr lange laufen wird, viele Systemressourcen bindet und dies nicht überall und immer möglich ist.

2. Paralle schreibende Zugriffe
   Auch wenn es vielleicht nicht so häufig in der Praxis so sein sollte, aber man muss bei jeder Lösung mit bedenken, dass die schreibenden Zugriffe auf die zu änderte Überordnung parallel stattfinden wird. Es dürfen keine Änderungen verloren gehen (siehe synchron Halten der Daten) und es auch zu keiner Korrumption der Überordnung an für sich kommen. Da die Dateien nicht zwingend auf lokalen, schnellen Speichersystemen vorliegen sondern auf deutlich langsameren Netzlaufwerken, spielen dann auch (Netzwerk-)Latenzen, Netzwerksynchronisierungen und Sperrungen von Dateien eine nicht zu unterschätzende und nicht zu ignorierende Problemstelle dar.

3. Auswirkungen durch die Anwendung von KitodoScript Aufrufen zur Manipulation von Metadaten
   Mit Hilfe diverser KitodoScripte können die Metadaten von Vorgängen auf vielfältige Art und Weise geändert werden. Diese Änderungen können auch die Metadaten betreffen, die sich auf LABEL und ORDERLABEL (TYP ist eher unwahrscheinlich) auswirken, die dann in die Überordnung eingetragen werden müssen. Damit man die Daten synchron (Punkt 1) hält, aber durch die Häufigkeit der Änderung auch der die Metadatendatei der Überordnung selbst es zu Problemen kommen kann (Punkt 2 in Teilen). Gerade wenn hier an der Stelle die Umsetzung nicht gut durchgeführt wird und es zu Synchronisierungen kommt, die aber gar nicht notwendig sind, da die Daten sich nicht ändern, wird de Metadatendatei unnotwendiger weise sehr oft neu geschrieben.

4. Migration bestehender Altdaten
   Egal, welche Lösung man schlussendlich nimmt, es müssen ja auch die bestehenden Daten auf die neue Lösung angepasst werden. Auch hier muss man im Blick haben, dass man nicht wenige sondern sehr viele Hierarchien gibt, die nachträglich auf die neue Lösung hin angepasst werden müssen. Eine einmalige Migration, die ggf. auch länger dauert und dafür korrekt arbeitet, sollte Vorgang vor einer Migration adhoc haben, wo nur aktuell zugegriffene Daten aktualisiert werden. Durch letzteres ist nie sicher gestellt, dass der gesamte Datenbestand auf die neue Lösung umgestellt wurde sondern auch in Zukunft mit Alt-Vorgängen zu rechnen ist. Dadurch muss diese Art der Migrationslösung für sehr lange Zeit oder gar für immer am Leben gehalten werden. Da zukünftige Migrationen an den Daten nicht auszuschließen sind, würde es dann zu einen Zoo an unterschiedlichsten Daten-Migrationen kommen, wo man nicht mehr weiß, welche schon ausgeführt wurden und welche noch durchzuführen sind.

5. Nachnutzung bestehender Lösung und Konzepte
   Wenn man unterschiedliche Löungsansätze miteinander vergleicht, sollte man auch mit Bedenken, dass dieses Problem nicht neu ist und es schon andere Personen gab, die dieses Problem gelöst haben. Daher sollte man auch mit schauen, ob es gute Lösungen (best practice) gibt und nutzt, statt das Rad neu zu erfinden. Letzteres mag zwar an vielen Stellen auch verlockend sein, aber man macht die gleichen aber auch neue Fehler, die andere schon gefunden und gelöst haben.

Dies sind mit Absicht auch sehr allgemein gehaltene Gedanken, die zwar im Fokus einer Datei-orientierten Lösung sind, aber auch bei anderen Lösungsarten mit bedacht werden sollten.

[andre-hohmann]

Nur eine kurze Anmerkung zu "3 Auswirkungen durch die Anwendung von KitodoScript Aufrufen zur Manipulation von Metadaten":

Mit dem KitodoScript lassen sich meines Wissens nur die MODS-Daten (dmdSec) manipulieren. Zumindest habe ich es nicht geschafft, bei Zeitschriftenbände die Bandnummer in LABEL und ORDERLABEL zu kopieren.

Da sich die Funktionsweise ändern kann, sollte der Aspekt auf jeden Fall bedacht werden.
Ich will jedoch vermeiden dass man derzeit von falschen Grundannahmen ausgeht. Ich bin ja etwas enttäuscht, dass LABEL und ORDERLABEL nicht mit KitodoScript manipuliert werden kann - aber vielleicht ist es objektiv besser so...

[BartChris]

Vielen Dank für die elaborierten Ausführungen. Ja, das sind natürlich gewichtige weitere Argumente. Was mich aktuell - unabhängig von allen angeführten Konsistenzproblemen - insbesondere stört, ist, dass nur um eine Überordnung anzuzeigen(!) (man kann im Editor nichts an den Daten der abhängigen Bände ändern), massive Ressourcen aufgewandt werden müssen und der Editor fast unbenutzbar ist.

Da wäre eine Option, die in der Überordnung abgelegten Daten nur für die Anzeige zu nutzen, auch wenn das natürklich auch Probleme mit sich bringt, wenn sie nicht konsistent sind. Die aufgeworfenen Konsistenz- und Altdatenfragen sind grunsätzlich allesamt berechtigt, was mich - wie bereits oben angesprochen - überlegen lässt, ob man diese Funktion nicht doch irgendwie an Hibernate Search und in fremden Entitäten abgelegte Properties (Objekteigenschaften) lösen kann. Das würde vermutlich auch das Problem der Altdaten evtl. besser adressieren, da nur einmal neu indexiert würden müsste. Dafür wird natürlich erstmal die Entwicklung für Hibernate Search benötigt.

[henning-gerhardt]

Mir ist dieses Problem bekannt und wir an der SLUB sind auch davon massiv betroffen, da es bei uns viele umfangreiche Hierarchien gibt, die dadurch nur schwer oder gar nicht bearbeitbar sind (Andre Hohmann kann davon ein Lied singen). Mir ist sehr wohl an einer Lösung gelegen, jedoch sollte hier nicht die schnell entwickelte sondern eine nachhaltige Lösung her.

In 2.x hatte man zwar keine Hierarchien, aber um nach Werten in den Metadaten zu suchen, wurden dort die Vorgangseigenschaften (neben den Vorlagen- und Werkstückeigenschaften) eingeführt. In den Vorganseigenschaften wurden die "wichtigen" Metadaten bei der Erzeugung des Vorgangs eingetragen aber auch die beiden anderen Eigenschaftentypen. Diese Eigenschaften hatten aber den Nachteil, dass diese nicht automatisch synchron gehalten wurden sondern die Synchronisierung manuell zu erfolgen hatte. Deswegen wurde ja in der 3.x Entwicklung auf ElasticSearch und der Speicherung der Metadaten im ElasticSearch gesetzt. Die Speicherung der Metadaten funktioniert, jedoch der Zugriff auf diese Werte ist - meines Wissens nach nicht möglich oder zumindest an den gewünschten Stellen nicht. Die Daten und die Synchronisierung der Daten ist grundsätzlich da, aber es muss "nur" der Zugriff auf diese Daten erfolgen. Hibernate Search wird dieses Problem nicht alleine durch die Existenz und die Nutzung von Hibernate Search lösen bzw. bereit stellen. Die Lösung (Zugriff auf die Metadaten im Suchindex / Hibernate Search) muss so oder so geschaffen werden, wenn der Suchindex (entweder wie aktuell oder durch Hibernate Search) die Lösung für das Problem sein soll.

[BartChris]

Volle Zustimmung. Es hinge generell an der besseren Zugreifbarkeit der Metadaten im Suchindex. Hibernate Search käme nur insofern ins Spiel, als es hier evtl. Mechanismen gibt, in der Entität der Überordnung gehaltene Metadaten bei Änderung der Metadaten der verknüpften Objekte automatisch zu aktualisieren; Synchronisierungslogik also an das Framework delegiert werden kann. Aber natürlich würde es wohl auch schon helfen, wenn die Metadaten der Unterordnungen schnell und performant zugreifbar sind (und die Synchronisierung verlässlich funktioniert).

[andre-hohmann]

Die fehlenden LABEL und ORDERLABEL-Elemente werden vermutlich auch bald in Kitodo.Presentation auffallen.
Bisher wird das intern gelöst, aber vermutlich soll diese Funktion entfallen:

• [BUGFIX] Get issue title from the day if the issue itself doesn't contain correct date kitodo-presentation#1315

Zusätzlich scheint auch in ORDERLABEL der Ausgabe der Monatswerts eingetragen zu werden.

[andre-hohmann]

Hier einige Anmerkungen zu den ursprünglich drei genannten Aspekten

Aspekt 1
Der erste Aspekt scheint durch den folgenden Pull Request nicht mehr gewichtig zu sein:

• Speed up display of parent processes #6185

Vielen Dank für diese Lösung!

Aspekt 3
In der SLUB Dresden können wir zum Glück die Sortierung der untergeordneten Bände anhand des Vorgangstitels erkennen - zumeist durch Jahreszahlen oder Bandzählungen. Zugegeben nicht immer elegant wegen Anpassung der Vorgangstitelbildung, oder fehlerhafter Erfassung, aber immerhin möglich. Siehe Screenshots am Ende dieses Kommentars. Somit ist dieser Aspekt für die SLUB Dresden nicht so relevant.

Aspekt 2
Für die SLUB Dresden ist jedoch der zweite Aspekt von hoher Relevanz. Dieser Aspekt ist jedoch sehr komplex und ich habe dafür eine eigene Diskussion erstellt, um die Zusammenhänge zu beschreiben.

• Anwendung der METS-Attribute LABEL und ORDERLABEL in Kitodo #6277

Es scheint, dass teilweise das Verhalten von Kitodo.Production 2 wieder gewünscht wird und ich befürchte, dass die Nachteile dieser Lösung nicht mehr in Erinnerung sind, oder nur uns betreffen. Aus meiner Sicht sollten die jeweiligen Vorteile aus der vorigen und der derzeitigen Lösung zusammengeführt werden. Auf jeden Fall sollte vermieden werden, dass weitere Nachteile entstehen. Ich habe zwei Bereiche identifiziert, die intensiv untersucht werden sollten:

1. Erfassung von LABEL und ORDERLABEL in den Vorgängen von Zeitschriften-Bänden und Zeitungs-Ausgaben
2. Austausch von LABEL und ORDERLABEL zwischen hierarchischen Vorgängen während des Exports

Ich frage mich, ob es durch die Lösung für Aspekt 1 nicht möglich ist, die Werte der Attribute LABEL und ORDERLABEL beim Öffnen des Metadateneditors aus den untergeordneten Vorgängen zu ermitteln und anzuzeigen.
Dann müsste nur eine Lösung ermittelt werden, um LABEL und ORDERLABEL in den (untergeordneten) Vorgängen flexibel und korrekt zu erfassen - nicht nur durch das Export-XSLT. Wenn die Werte in den internen Daten der Vorgänge vorhanden sind, werden sie ja korrekt exportiert.

Sollen/können wir die Kernaspekte noch klarer benennen, um das weitere Vorgehen zu bestimmen?

Screenshots
Beispiele Zeitschriften

Beispiele Mehrbändigkeit