Replies: 1 comment
-
|
Als erstes vielen Dank, dass du das Thema weiter verfolgst und hier wieder einbringst. Ich versuche die aufgeworfenen Fragen aus meiner Perspektive zu beantworten bzw. ergänze mit Kommentaren und Fragen:
„unzureichend“ ist gut formuliert. Der Massenimport erscheint derzeit als komfortabelste Lösung. Es ist aber nötig, dass eine Schnittstelle bereitsteht, über die die im Massenimport angegebenen Identifier abgefragt werden können. Die Frage, ob das Eingabeformat hier XML sein sollte, oder auch z.B. JSON denkbar wäre, könnte noch aufgeworfen werden.
Damit könnte an bestehende Möglichkeiten angeknüpft werden. Mir stellt sich aber auch die Frage, ob dafür nicht die gleiche Einrichtung einer Importkonfiguration wie für die bestehende Möglichkeit des XML-Uploads (wir haben diese noch nicht getestet oder weiter verfolgt) nötig wäre und dem entsprechend auch eine Unterbringung auf der für diese Funktion gedachten Upload-Seite naheliegend wäre. Derzeit stellt für uns allerdings der manuelle Upload der Liste über die Massenimport-Seite einen eher umständlichen Schritt dar, da dies nicht automatisiert werden kann. Umgangen werden könnte dieses Problem durch die erneute Möglichkeit zum Anlegen von Prozessen durch externe Anwendung, wie derzeit bei #4837 diskutiert wird. Vielleicht sollte einen Implementierung also auch diese Entwicklung im Blick haben. Sofern dies implementiert wird könnten die Daten also auch statt als XML oder JSON als MapMessage übergeben werden, nachdem sie zuvor aus einem der anderen Formate konvertiert wurde. Für Nutzende, die einzelne Bestände importieren wollen, keine Möglichkeiten zur Konvertierung und Adressierung des ActiveMQ-Dienstes und nur die Möglichkeit zum manuellen Export der XML-Dateien aus dem AFIS haben, würde dies aber natürlich eine komfortable Verbesserung gegenüber den bisherigen Möglichkeiten darstellen.
Die erste Frage ist daher schwer zu beantworten. Die Importmöglichkeiten werden dadurch erweitert und prinzipielle Anforderungen können – für einen begrenzten Anwendungsfall – entsprechend definiert und erfüllt werden. Die Möglichkeiten sind damit etwas weniger „unzureichend“ als sie jetzt sind (und auch jetzt können wir mit dem Massenimport arbeiten), ob sie dadurch aber „zureichend“ werden, ist fraglich. Eine – wie mir auch erneut durch Rückmeldungen auf dem Praxistreffen und aus dem Community Board bestätigt wurde – Schwierigkeit, mit der sich Archive gegenüber Bibliotheken besonders konfrontiert sehen, ist die zum Teil gegebene Unvollständigkeit oder Ungenauigkeit der Erschließungsdaten. Es kann daher sein, dass gesuchte Daten schlichtweg nicht im verwendeten Abfragesystem vorhanden sind und anders ergänzt werden müssen. |
Beta Was this translation helpful? Give feedback.
-
Kitodo.Production 3.x unterstützt verschiedene Formen des Metadaten-Imports. Diese werden über sogenannte "Importkonfigurationen" konfiguriert (siehe https://github.com/kitodo/kitodo-production/wiki/Projektauswahl-und-Katalogsuche#import-konfigurationen), die die alte Datei
kitodo_opac.xmlersetzen:Katalogabfrage - Metadaten einzelner Datensätze können via ID (oder andere Suchparameter) von konfigurierten Suchschnittstellen abgefragt und daraus Digitalisierungsvorgänge erstellt werden. Wenn die Suchschnittstelle dies unterstützt, sind verschiedene Arten des hierarchischem Imports möglich, d.h. die Katalogschnittstelle wird für den Import von potentiellen Über- oder Unterordnungen erneut abgefragt, wenn deren IDs in den Metadaten des ursprünglich importierten Datensatzes enthalten sind, und die zurückgegebenen Datensätze als hierarchisch verknüpfte Vorgänge importiert. (siehe auch https://github.com/kitodo/kitodo-production/wiki/Kalliope-SRU-deutsch). Wenn der Datensatz die ID einer Überordnung enthält, ein Vorgang mit dieser ID aber bereits in Kitodo existiert, wird die Überordnung nicht erneut importiert, sondern der importierte Datensatz mit der bereits in Kitodo bestehenden Überordnung hierarchisch verknüpft.
Datei-Upload - XML-Dateien mit Metadaten können direkt vom lokalen Rechner hochgeladen werden. Es ist möglich, aus der gleichen XML-Datei zusätzlich die Überordnung des Datensatzes zu importieren, wenn eine separate Abbildungsdatei für die Extraktion der Metadaten der Überordnung in der verwendeten Importkonfiguration hinterlegt ist. Es ist also auch hier ein (auf die Überordnung) eingeschränkter, hierarchischer Import möglich.
Vorgangsvorlagen - Metadaten können von entsprechend ausgezeichnten Vorgängen übernommen werden, z.B. für das Anlegen multipler Zeitschriftenbände mit größtenteils gleichen Metadaten.
Massenimport - Über eine zusätzliche Maske können Listen von IDs an eine konfigurierte Katalogschnittstelle (siehe 1.) übergeben werden, die dann den Import sequentiell für jede einzelne ID automatisch durchführt und multiple Vorgänge erstellt. Wie beim regulären Katalogimport werden importierte Datensätze (z.B. Bände eines mehrbändigen Werkes) als Unterordnungen an existierende Überordnungen (das mehrbändige Werk) gehängt, wenn ein entsprechender Vorgang der Überordnung in Kitodo bereits existiert oder die ID der Überordnung in der Liste der zu importierenden IDs vor den IDs der Unterordnungen steht und damit zuerst importiert wird.
Konzept Weiterentwicklung:
Hierarchischer Massenimport (e.g. "Archivdatenimport"):
Aus mehreren Gesprächen mit Archiven ist hervorgegangen, dass die bestehenden und oben beschriebenen Möglichkeiten des Metadatenimports für den Einsatz von Kitodo.Production in Archiven unzureichend sind. Es besteht der Wunsch, mehrere Vorgänge inkl. einer Überordnung (Bestand) und potentiell vieler Unterordnungen (Verzeichniseinheiten) aus EINER manuell hochgeladenen oder von einer Schnittstelle zurückgegebenen XML-Datei (z.B. EAD) automatisch als einzelne, hierarchisch miteinander verknüpfte Vorgänge zu importieren.
Dies könnte über eine Erweiterung der Massenimport-Seite funktionieren. Wenn hierbei von einer festen Struktur einer solchen, hochgeladenen Archivmetadaten-Datei ausgegangen werden kann, würde der Massenimport aus einer Datei automatisch einen Vorgang für den Bestand ("collection") und n Vorgänge für die Verzeichniseinheiten ("item") erstellen und diese hierarchisch miteinander verknüpfen.
@vernst @aetherfaerber @rchr @PeterJunger @Aigeus erfüllt dieses Konzept aus Sicht der Archive die prinzipielle Anforderung an eine Erweiterung des Imports? Was müsste noch ergänzt werden bzw. was habe ich nicht bedacht oder vielleicht falsch verstanden?
@kitodo/kitodo-community-board könnte dieses Thema in Eure Liste aufgenommen werden?
Beta Was this translation helpful? Give feedback.
All reactions