(Re-)Import von METS-Dateien nach Kitodo.Production

[BartChris]

Da in der Mailing-Liste kürzlich die Frage nach dem Import von METS-Daten nach Kitodo.Production aufkam, habe ich (auch in Vorbereitung einer möglichen Dokumentation im Wiki) die bisherige Funktion in Kitodo einmal ausprobiert, um potentielle Importpfade aufzuzeigen.

Bereits seit einiger Zeit besitzt Kitodo die Funktion des "vorstrukturierten" Imports (siehe hierzu etwa #4847).

Der vorstrukturierte Import ermöglicht beim Import der Daten nach Kitodo auf Basis einer passenden XSL-Transformation nicht nur Metadaten aus einem Katalogsystem, sondern bestehende Strukturdaten (Physische Struktur, Logische Struktur, StructLinks) zu übernehmen. Grundsätzlich kann jedes konfigurierte Import-Interface für den vorstrukturierten Import genutzt werden.

Die konfigurierte Schnittstelle gibt im Idealfall eine vollständige DFG-Anwendungsprofil-konforme METS/MODS-Datei zurück.
Benötigt wird darüber hinaus eine XSL-Datei, die die übergebene METS-Datei in ein Kitodo-kompatibles METS (inklusive aller Strukturinformationen) konvertiert.

Ich habe einmal ein solches XSL mit minimaler Metadateninformation angelegt:
https://gist.github.com/BartChris/83e0954086f7aa673e84a72a89c23eb4

Diese XSL-Datei kann als "Abbildungsdatei" in Kitodo hinterlegt werden. Für sie ist der vorstrukturierte Import zu konfigurieren:

Anschließend kann eine beliebige Katalog-Import-Konfiguration hinterlegt werden, die auch als "vorstrukturierter" Import auszuweisen ist:

Beispiel:

CUSTOM:

OAI

Im Reiter Abbildungsdateien kann die eben erzeugte Konfiguration hinterlegt werden:

Beim kataloggestützten Import kann der vorstrukturierte Import ausgewählt und der Import wie gewohnt gestartet werden.

Der Vorgang ist dann inklusive aller Strukturdaten (aber ohne Bilder) im System.

[BartChris]

Weitergehende Anmerkungen:

a) Stabilität der Identifier im Quell-Dokument

Wenn die METS-Daten per vorstrukturiertem Import nach Kitodo geladen werden, wird die Mehrzahl der im Dokument vergebenen Identifier konserviert. (Insbesondere Logical- und Physical StructMap)
Nicht erhalten bleiben u.U. die Identifier der Metadaten-Sektionen:

<mets:dmdSec ID="uuid-4a9db38f-f1bd-3dce-b1e9-1b5388fcbe33">
 <mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="KITODO">
  <mets:xmlData>
    <kitodo:kitodo>
      <kitodo:metadata name="TitleDocMain">Ein kurzer Buchtitel</kitodo:metadata>
....

Dieses Thema wurde bereits ausführlich diskutiert: #5860

Kitodo generiert die UUID-Identifier der Metadatensektionen automatisch aus den Identifiern der zugehörigen logischen Struktur. Falls in importierten METS-Daten keine UUID-Identifier für die logische Struktur verwendet wurden, sieht die generierte dmdSec-ID i. d. R. anders aus als jene des Originaldokuments.
Ich habe noch keine ausführlichen Tests mit mehreren Metadatensektionen gemacht.

b) Umgang mit Überordnungen

Bislang keine systematischen Versuche.

c) Umgang mit Bilddaten

Das verlinkte Code-Segment nimmt bereits erste Vorbereitungen vor, um existierende Retrodigitalisate in Kitodo zu bearbeiten und geht dabei von bestimmten Annahmen aus.

So werden externe URLs auf interne Kitodo-URLs umgeschrieben

https://gist.github.com/BartChris/83e0954086f7aa673e84a72a89c23eb4#file-xsl-L90-L96

Daneben werden alle Filegroups, die für die Nachverarbeitung in Kitodo nicht benötigt werden, aus der XML-Datei entfernt.

Die grundsätzliche Überlegung geht von einem Nachbearbeitungs/-Korrektur-Szenario auf bereits publizierten Digitalisaten aus, für die keine Master-Files, sondern allenfalls nur Derivate benötigt werden.

Die Bilder müssen aktuell manuell/per Skript in die generierten Vorgangsverzeichnisse kopiert werden. Eine weitergehende Überlegung wäre, ob Kitodo in Zukunft eine Funktion unterstützen kann, die ermöglicht, die in einem externen Repository gespeicherten Bilder automatisch in die generierten Kitodo-Vorgangs-Verzeichnisse zu kopieren.