Reimport von Titelmetadaten einzelner Vorgänge

[andre-hohmann]

Einleitung

Im Community Board (Kitodo.Production) wird die Implementierung eines Reimports diskutiert (2023‐08‐08, 2023‐09‐19). Auslöser ist die Diskussion während des Kitodo-Praxistreffens 2022 und Issue #5410 sowie PR #5613.

Ziel ist zunächst die Erarbeitung von Vorschlägen zur Umsetzung der Funktionalität für einzelne Vorgänge im Metadateneditor. Unter anderem werden folgende Aspekte untersucht:

• Position des Buttons, um den Reimport auszulösen
• Informationen über Änderung der Daten

Darauf aufbauend werden perspektivisch Vorschläge zur Massen- oder Stapelbearbeitungen größerer Mengen erarbeitet. Zum Beispiel ob die KitodoSkripte erweitert werden können oder ob ein neues Konzept entwickelt wird. Zudem muss noch unter anderem geklärt werden, wie der korrekte Katalog oder die korrekte Metadatenquelle ausgewählt wird.

In dieser GitHub-Diskussion werden die bisherigen Erkenntnisse des Community Board zusammengeführt, um eine Diskussion in der gesamten Community anzuregen. Gleichzeitig sollen die Herausforderungen einer nachhaltigen Lösung hinsichtlich aller Aspekte (technisch, fachlich, Nutzerfreundlichkeit ...) vermittelt werden.

Position des Buttons, um den Reimport auszulösen

Im Community Board (Kitodo.Production) wurden zwei Lösungsansätze diskutiert:

1. Button im „Kopf“ des Frame Metadaten
2. Button im "Kopf" des Metadateneditors

Lösungsansatz 1 wird derzeitig im Community Board favorisiert.

Button im „Kopf“ des Frame Metadaten

Lage: Entsprechend der Funktionalitäten im "Kopf" des Strukturbaums (Ein- und Ausklappen des Strukturbaums, ...)

Vorteile

• Ähnliche Struktur wie im Frame „Strukturdaten“
• Funktionalität entspricht der Metadatenbearbeitung
• Der „Kopf“ des Metadateneditors bleibt übersichtlicher

Nachteile

• Der Frame Metadaten wird etwas kleiner
• Die Position ist nicht so prägnant wie im „Kopf“ des Metadateneditors

Voraussetzungen

• Mouseover mit Erläuterung der Funktion (Vergleiche Buttons Einklappen/Ausklappen des Strukturbaums)
• Prüfen, ob der +-Button zum Hinzufügen von Metadaten ebenfalls in den Kopf des Frames eingefügt wird
• Vermittlung, dass sich die Funktion auf die Katalogmetadaten bezieht, nicht auf die manuell erfassten Metadaten der Strukturdaten

Beispiel

Button im „Kopf“ des Metadateneditors

Lage: Neben „Schließen“, „Validieren“, …

Vorteile

• Prägnante Position, die rasch erkannt wird

Nachteile

• Die Zeile wird rasch voll, wenn andere Aktionen angezeigt (Bildbearbeitung, …) oder in Zukunft hinzugefügt werden
• Inhaltlich entspricht es weniger den eher allgemeinen Aktionen Speichern, Zurück, …

Beispiel

Informationen über Änderung der Daten

Funktionalität
Bevor die Metadaten aktualisiert werden, sollen folgende Funktionen angeboten werden:

• Anzeige der Änderungen, die durchgeführt werden
• Möglichkeit, die Art der Anpassung (replace, add, …) anzupassen
• Anwendung des Reimports auf alle oder nur ausgewählte Metadatenfelder

Beispiel

[markusweigelt]

Mein erster Eindruck davon ist, dass die zwei Lösungsansätze optisch verschiedene Funktionalitäten vermitteln und ich mir auch gut vorstellen kann, dass beide Funktionen Einsatz finden.

Der Button im oberen Bereich des Metadateneditors suggeriert mir, dass es sich um einen Reimport aller Metadaten aus allen Strukturelementen handelt bzw. der Nutzer aus allen Metadaten auswählen kann. Der Button innerhalb des Frames Metadaten bezieht sich nach meinem Eindruck nur auf die Metadaten, die sich innerhalb des Frames befinden.

Je nach Anwendungsfall kann es sinnvoll sein eine komplette Liste der Metadaten für Reimport durchzugehen oder nur die dem Strukturelement zugeordnet sind. Beide Buttons müssen sich meiner Meinung nach aber nicht ausschließen. Im Backend wäre es sicher dieselbe Funktionalität. Der Unterschied wäre lediglich, dass beim Frame Metadaten auf die Metadaten des ausgewählten Strukturelementes gefiltert wird..

Mit dem bereits gemergten PR #5701 zur Mediendateiumbenennung, gibt es bereits einen weiteren Button ab Release 3.6 der sich im oberen Bereich befinden kann (je nach Berechtigungen). Vielleicht könnte im "Kopf" des Metadateneditors ähnlich der Vorgangsübersicht ein Button "Aktionen" hinzugefügt werden und der Reimport aus den Aktionen ausgewählt werden. Der Button für die Mediendateiumbenennung könnte auch in die Aktionen verschoben werden.

Zusammenfassend kann ich mir beide Buttons vorstellen bzw. den Button je nach präferierten Anwendungsfall.

[oliver-stoehr]

Ich hatte vor längerer Zeit einen Wireframe für das Dialogfenster der Metadaten-Aktualisierung erstellt. Ich habe dies nun in ein Mockup überführt und will es zu dieser Diskussion beisteuern:

In diesem Konzept sollten Record-Identifier und Katalog in der Überschrift stehen und rechts ein kleines Hinweis-Icon, über das ein Erklärungstext zu dem Dialogfenster eingeblendet werden kann (ähnlich den schönen Hinweisen bei den Importkonfigurationen).

Die eigentliche Tabelle soll links die Metadaten-Keys, in der zweiten Spalte die bisherigen Werte aus Kitodo und in der letzten Spalte die neuen, aus dem Katalog geladenen Werte auflisten.
Die dritte Spalte soll möglichst intuitive Buttons zur Steuerung beinhalten. Diese Buttons haben jeweils drei Zustände, wo der Pfeil jeweils auf den Wert zeigt, der übernommen werden soll:

• --> (ersetzen)
• <-- (behalten)
• <--> (ergänzen)

In diesem Mockup würde also der bisherige Titel beibehalten werden, die bisherige Sprache um die neue, aktualisierte Sprache ergänzt werden, das bisherige Erscheinungsjahr beibehalten werden und der Erscheinungsort ersetzt werden.

Durch einfaches Klicken auf einen Button soll durch die Zustände durchgeschaltet werden können. Wäre der Zustand --> "ersetzen" ausgewählt würde der erste Klick zu <-- "behalten" wechseln, der zweite Klick zu <--> "ergänzen".
Dadurch wäre für viele Änderungen nur ein Klick notwendig und der aktuelle Zustand wäre schnell und ohne texthelle Erläuterungen zu erkennen.
Ein Klick auf das Symbol in der Titelzeile würde den Zustand für alle Zeilen auf --> "ersetzen" ändern, ein zweiter Klick würde alle Zeilen auf <-- "behalten" ändern und ein dritter Klick auf <--> "ergänzen". So könnten mit wenigen Klicks alle Zeilen angepasst werden. Einzelne Zeilen könnten danach abgeändert werden, wenn ein Update zum Beispiel viele Metadaten lädt, aber nur einzelne Zeilen davon übernommen werden sollten.

Zwecks besserer Eindeutigkeit sollten die Metadaten, die durch die entsprechenden Auswahlen übernommen werden würden, hervorgehoben werden. In diesem Konzept sind die entsprechenden Einträge fett geschrieben, eine andere Art der Hervorhebung wäre aber auch denkbar (Rahmen um die Wert, Textfarbe, Hintergrundfarbe oder Ähnliches).

[solth]

Wenn bei der entsprechenden Überordnung dasselbe gemacht wird, d.h. wenn immer eine PPN vorangestellt wird, funktioniert die automatische Verknüpfung zur Überordnung vermutlich trotzdem. Insofern war vermutlich nicht intendiert, dass im recordIdentifier etwas anderes steht als der exakte Katalogschlüssel, allerdings wird dies softwareseitig aktuell nicht erzwungen. Und die automatische Verknüpfung zur Überordnung kann dann trotzdem funktionieren, wenn es immer (also auch für die Überordnungen und die Verweise auf die Überordnungen) gemacht wird.

Richtig, wenn das funktionale Metadatum, das als higherlevelidentifier konfiguriert wurde (und das die ID der Überordnung enthalten soll) auf die gleiche Art modifiziert wurde wie der recordIdentifier selbst, funktioniert auch die automatische Verknüpfung mit der Überordnung (da der higherlevelidentifier der Unterordnung hierbei mit dem recordIdentifier der Überordnung verglichen wird). Auf die Idee, beide Werte gleichmäßig zu ändern und damit weiterhin kompatibel zu halten, bin ich noch nicht gekommen.

Allerdings wird dies vermutlich beim Thema "Re-Import" tatsächlich Probleme verursachen, da die Suchschnittstelle nichts über den zusätzlichen Präfix weiß und Kitodo bisher auch keine Funktionalität enthält, einen solchen (optionalen) Präfix explizit (e.g. außerhalb der Import-XSLT-Datei) zu definieren und damit vor erneuter Abfrage der Suchschnittstelle automatisch zu entfernen.

[BartChris]

Evtl. können @subhhwendt oder @apiller kurz erläutern mit welcher Intention die Anreicherung der Katalogschlüssel mit einem Präfix erfolgt. Ich glaube teilweise sind zu diesem Zweck auch schon Doppelfelder im Einsatz um etwa die ursprüngliche PPN und die PPN mit Präfix beide abzubilden.

[apiller]

Wenn ich das richtig in Erinnerung habe ist das bei @subhhwendt im Einsatz, um eine Verwechselung mit Identifiern aus anderen Katalogen zu verhindern. Wir haben zumindest in Kitodo 3 keine Präfixe im Einsatz. In der 2er Version haben wir damit sichergestellt, dass unser Mandant eine bei uns bereits angelegte PPN ohne Probleme nochmal anlegen kann. Problem hierbei war, dass die PPN als ID auch für Präsentation und Verknüpfung zu übergeordneten Stufen verwendet wird. Der recordIdentifier ist aber bei uns immer die aktuelle PPN ohne Prä- oder Suffixe.

[subhhwendt]

Wir sind 2010ff an der Seite von Intranda im Schatten der Göttinger Installation mit dem Präfix "PPN" gestartet - ohne das bis in alle Tiefen zu durchdenken. Ich meine auch die SBB ist so unterwegs.
Das Konfigurationsgewusel fing - wie schon von Arved beschrieben- mit Kitodo3 an, wo der Vorgang der Überordnung zuverlässig gefunden werden musste. So ist ab Version 3.6 in unserem Regelsatz zu finden - vorher war ein Teilaspekt in der Importkonfiguration untergebracht ("Metadatum für Katalog-ID"):

=>KatalogIdentifier ohne Vorlauf PPN
=>KatalogIdentifier der ÜO in meta.xml eines Bandes, der dann auf die CatalogIDDigitalInternal bei der ÜO matcht.

[andre-hohmann]

Ich wurde darauf hingewiesen, dass in der SLUB Dresden ebenfalls Vorgänge in Kitodo.Production verwaltet werden, in denen recordIdentifier nicht dem Identifier entspricht, mit dem die Schnittstelle durchsucht wird. Statt dessen wird der recordIdentifier aus zwei Werten zusammengesetzt.

Deshalb unterstütze ich mittlerweile zur Kennzeichnung des Identifikators für den Re-Import die Erstellung eines neuen Attributes für den Regelsatz, wie zum Beispiel importMetadata.

Das scheint mir am nachhaltigsten zu sein. Im schlimmsten Fall werden einem Metadatum zwei Attribute zugewiesen.
<key id="CatalogIDDigital" use="recordIdentifier" use="importMetadata">
Da sich das Metadatum vermutlich selten ändern wird, ist der Aufwand aus meiner Sicht überschaubar. Die Flexibilität für mögliche zukünftige Anwender oder Anwendungsfälle ist jedoch sehr hoch.

[subhhwendt]

da ist was vom Editor gefressen worden - sorry!
CatalogIdDigitalInternal mit use="recordIdentifier" =>KatalogIdentifier ohne Vorlauf PPN
CatalogIdDigitalAnchorInternal mit use="higherlevelIdentifier"=>KatalogIdentifier der ÜO in meta.xml eines Bandes, der dann auf die CatalogIDDigitalInternal bei der ÜO matcht.

[andre-hohmann]

Hier noch Antworten auf gestellte Fragen

Wurden sich auch Gedanken gemacht, wie sich die zusätzliche Speicherung dieser Information sich bei Bestandsdaten verhalten soll? Einige hundert tausend Datensätze von Hand nach zu tragen, kann ja keine Lösung sein oder?

Ja, das wurde bedacht und intern diskutiert. Wenn neue Elemente oder Funktionen implementiert werden, soll die notwendige maschinelle Anpassung der bestehenden Vorgänge ermöglicht werden. Dies betrifft vor allem die mögliche Verknüpfung mit der jeweiligen Importkonfiguration.
Eine manuelle Anpassung der vorhandenen Vorgänge, um einen Re-Import zu ermöglichen muss unbedingt vermieden werden.

Ist vorgesehen bzw. wurde bedacht, dass sich Import-Konfigurationen auch ändern und abgelegte Informationen sich dann zwangsweise auch ändern müssen bzw. angepasst werden müssen. Wie soll dies in der Anwendung durchgeführt werden (auch wieder im Blick auf große Datenmengen).

Nein, das wurde noch nicht bedacht. Das ist vermutlich auch davon abhängig, wie die Funktion implementiert wird. Im besten Fall wird jeweils die Import-Konfiguration entsprechend angepasst, um eine Anpassung der Vorgangs-Eigenschaften (ID der Import-Konfiguration, ...) zu vermeiden.
Diesbezüglich müssten Anwendungsfälle beschrieben werden.
Unter Umständen kann die Lösung zur vorigen Fragen angewendet/angepasst werden.

Wie soll sich der Re-Import verhalten, wenn die Daten aus mehreren Katalogen kommen?

Das wurde noch nicht ausführlich diskutiert, da bisher in der Regel nur die Metadaten aus einem Katalog importiert werden.

[andre-hohmann]

Es wurde eine zweite Version erstellt, in der weitere Erkenntnisse und Ergebnisse aus dem weitere Community Board zusammengeführt wurden:

• Reimport von Titelmetadaten einzelner Vorgänge - Version 2 #5904

Hinsichtlich der Übersichtlichkeit wird diese Diskussion geschlossen.