Anwendung und Persistenz der METS-Attribute ID (UUID) in Kitodo.Production 3

[andre-hohmann]

Einleitung

In Kitodo.Production werden die Werte der METS-Attribute ID auf unterschiedliche Weise als in Kitodo.Production 3 erzeugt. Dies führt in einigen Fällen zu Anpassung-Bedarfen nachgelagerter Prozesse, weil diese auf den bisher bestehenden Werten entwickelt wurden.

Im Folgenden wird die vermutete Anwendung bezüglich der Erstellung der ID-Werte untersucht und einige Auswirkungen beschrieben. Ziel ist die Ermittlung der Gründe für die Umstellung der ID-Erzeugung, die jeweiligen Anwendung und deren Dokumentation. Ausdrücklich kein Ziel dieser Diskussion ist die Bewertung der Änderung zur Erzeugung der ID-Werte.

Generell werden in Kitodo.Production 3 UUID für neue METS-Attribute ID erzeugt. In einigen Fällen bleibt die vorhandene "alte" ID erhalten. Somit entstehen auch Mischungen der ID-Werte aus Kitodo-Production 2 (LOG_0000, LOG, 0001, PHYS_0001, PHYS_0001, …) und Kitodo.Production 3 (UUID) innerhalb einer METS-Datei.

Einige ID-Werte werden während der Migration in der internen METS-Datei angepasst, andere Werte werden in der exportierten METS-Datei angepasst.

Fall 1

In den folgenden ID-Attributen werden die Werte in der exportierten Datei nach jeder Aktualisierung (Export) neu erstellt, unabhängig davon, ob Änderungen an den Metadaten, Strukturdaten, … durchgeführt wurden oder nicht.

1. mets:fileSec/mets:fileGrp/mets:file/@ID
2. mets:structMap[TYPE='LOGICAL']/mets:div/@ID
   (Hierarchische Vorgänge)

Der Grund besteht wohl darin, dass die Einträge nicht in der internen METS-Datei des Vorgangs enthalten sind, somit nicht stabil vorgehalten werden können und deshalb neu erzeugt werden.

Fall 2

In den folgenden ID-Attributen werden die Werte in der internen METS-Datei während der Migration neu erstellt. Dementsprechend werden die geänderten Werte auch in die exportierte METS-Datei eingetragen.

1. mets:dmdSec/ID
2. mets:amdSec/mets:rightsMD/@ID
3. mets:amdSec/mets:digiprovMD/@ID

Der Grund für die Änderung der ID ist nicht bekannt.

Fall 3

In den restlichen ID-Attributen bleiben die ID-Werte aus Kitodo.Production erhalten.

Auswirkungen

Insbesondere die Erzeugung neuer UUID durch jede Aktualisierung er METS-Datei in den Attributen mets:fileSec/mets:fileGrp/mets:file/@ID behindert die Anwendung von Annotationen. Diese werden in Regel auf der Basis der Derivate erstellt.

Fragen

1. Sind die vermuteten Gründe für das geänderte Verhalten zur Erzeugung der ID-Werte korrekt?
2. Weshalb werden einige ID-Werte (dmdSec, ...) in der internen METS-Datei während der Migration geändert?
3. Besteht in anderen Einrichtungen der Bedarf nach „persistenten“ ID-Werten für die Derivate?

[markusweigelt]

Den Fall 1 1. hab ich mir mal angeschaut und dieser hat in der Implementierung folgenden Grund:

Beim Abspeichern im Metadateneditor wird in einer intern geladenen Map mit relativen URI's z.B. jpgs/thumbs/example.jpg als Schlüssel und dem Dateiidentifier als Wert geschaut, ob die URI vorhanden ist. Wenn die URI gefunden wird, dann wird der Dateiidentifier zurückgegeben.

Diese Funktion wird auch beim Export aufgerufen, allerdings wird hier mit der absoluten URI des METS Pfades (aus der Unterordnerkonfiguration) z.B. http://www.example.com/content/123456/jpgs/thumbs/example.jpg gesucht. Da diese Liste nur mit relativen URI's aufgebaut ist, wird der Dateiidentifier nicht gefunden und null zurückgegeben und ein neuer Dateiidentifier erstellt und zurückgegeben.

Deshalb ändert sich beim Abspeichern im Metadateneditor die UUID in der meta.xml nicht aber nach jedem Export in der exportierten METS.

[matthias-ronge]

das fehlt dann schlicht, oder?

[markusweigelt]

Kann leider keine Aussage mehr dazu treffen. Dafür ist es schlichtweg zu lange her und bin aktuell nicht mehr in einem Kitodo.Production Projekt um mir dazu einen Überblick zu verschaffen.

[BartChris]

Um die Stelle zu markieren, wo das beschriebene Verhalten auftritt:

kitodo-production/Kitodo-DataFormat/src/main/java/org/kitodo/dataformat/access/MetsXmlElementAccess.java

Lines 372 to 383 in 2b12938

	for (Entry<MediaVariant, URI> variantEntry : physicalDivision.getMediaFiles().entrySet()) {
	UseXmlAttributeAccess use = new UseXmlAttributeAccess(variantEntry.getKey());
	useToPhysicalDivisions.computeIfAbsent(use, any -> new HashSet<>());
	URI uri = variantEntry.getValue();
	useToPhysicalDivisions.get(use).add(uri);
	if (physicalDivision instanceof PhysicalDivisionMetsReferrerStorage) {
	fileIds.put(Pair.of(use, uri), ((PhysicalDivisionMetsReferrerStorage) physicalDivision).getFileId(uri));
	}
	}
	for (PhysicalDivision child : physicalDivision.getChildren()) {
	generateFileSecRecursive(child, useToPhysicalDivisions, fileIds);
	}

kitodo-production/Kitodo-DataFormat/src/main/java/org/kitodo/dataformat/access/PhysicalDivisionMetsReferrerStorage.java

Line 50 in 2b12938

String getFileId(URI key) {

Das Problem ist, wie bereits herausgtestellt, dass wir zwar die persistente UUID für jede Datei in einer HashMap speichern, allerdings unter dem Namen der lokalen Datei (images/tif/00000001.tif), die nicht mehr verfügbar ist, da wir den lokalen Pfad beim Export in der Klasse SchemaService in eine URL für den externen Zugriff transformieren..

kitodo-production/Kitodo/src/main/java/org/kitodo/production/services/schema/SchemaService.java

Line 147 in 2b12938

String mediaFile = variableReplacer.containsFiles(folder.getUrlStructure())

Ich bin mir nicht sicher, wie man hier weiter vorgehen soll. Soll die UUID auch unter dem exportierten Pfad gespeichert werden, indem der für den Export verwendete Pfad abgeleitet und dieser auf die gleiche UUID abgebildet wird? Oder sollte zumindest eine Zuordnung erhalten bleiben, welche ursprünglichen Dateipfade zu den erzeugten Exportpfaden gehören? Letzteres würde es uns ermöglichen, die persistenten UUIDs weiterhin über die internen Kitodo-Pfade nachzuschlagen.

Siehe auch das verwandte Issue: #4916

[matthias-ronge]

Ganz grundsätzlich werden die Struktur- und Metadaten im laufenden Betrieb von Kitodo.Production nicht in METS “gedacht”, sondern in einer Struktur (als Java-Objekte) verwaltet, die technisch die Funktionalität der Darstellung in Presentation abbildet:

🗎 Workpiece (1)
├ 🗎 creation date (2)
├ 🗎 edit history (3)
│ ├ 🗎 processing note
│ │ ├ 🗎 name
│ │ ├ 🗎 note
│ │ ├ 🗎 role
│ │ └ 🗎 type
│ ├ 🗎 processing note
│ ├ 🗎 processing note
│ ┆   ...
│ 🗎   
├ 🗎 id (4)
├ 🗎 physical structure (5)
│ ├ 🗎 physical division
│ │ ├ 🗎 children
│ │ │ ├ 🗎 physical division
│ │ │ ├ 🗎 physical division
│ │ │ ┆   ...
│ │ ├ 🗎 contentIDs (7)
│ │ ├ 🗎 label (7)
│ │ ├ 🗎 mediaFiles (10)
│ │ │ ├ 🗎 LOCAL → images/ProcessTitle_tif/00000001.tif
│ │ │ ├ 🗎 MAX → jpgs/max/00000001.jpg
│ │ │ ┆   ...
│ │ ├ 🗎 mediaPartial (11)
│ │ ├ 🗎 metadata (12)
│ │ ├ 🗎 order (13)
│ │ ├ 🗎 orderlabel (14)
│ │ └ 🗎 type (15)
│ ├ 🗎 physical division
│ ├ 🗎 physical division
│ ┆   ...
└ 🗎 logical structure  (6)
  ├ 🗎 logical division
  │ ├ 🗎 children
  │ │ ├ 🗎 logical division
  │ │ ├ 🗎 logical division
  │ │ ┆   ...
  │ ├ 🗎 contentIDs (7)
  │ ├ 🗎 label (8)
  │ ├ 🗎 link (9)
  │ ├ 🗎 metadata (12)
  │ │ ├ 🗎 domain
  │ │ ├ 🗎 key
  │ │ └ 🗎 value
  │ ├ 🗎 order (13)
  │ ├ 🗎 orderlabel (14)
  │ ├ 🗎 type (15)
  │ └ 🗎 views (16)
  ├ 🗎 logical division
  ├ 🗎 logical division
  ┆   ...

1. Das Digitalisat
2. Dateidatum (mets:metsHdr\@CREATEDATE)
3. Kommentare. Die Funktion, Kommentare im Digitalisat zu speichern wird allerdings nicht genutzt. Sie werden in Production auch nicht angezeigt. Beispiel für einen Kommentar:

<mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
    <mets:name>Kitodo</mets:name>
    <mets:note>Converted by Kitodo - Data Editor - 3.2.1-SNAPSHOT (2021-03-29T07:53:32Z)</mets:note>
</mets:agent>

4. Vorgangsnummer. Die wird hier zur nur abgespeichert, dass man sie benutzen kann. Ich habe schon ein paar Mal überlegt, ob es nicht sinnvoller wäre, den Vorgängstitel als ID zu hinterlegen
5. Dateien im Vorgang. Dabei ist jeder Eintrag ein Sammelbecken für alle verschiedenen Derivate desselben Mediums. Anfangs war das lediglich eine Liste, durch Einführung des physischen Strukturbaumes wurde es eine hierarchische Struktur (→ children: untergeordnete physische Strukturelemente als Baum). Änderungen in dieser Struktur werden in Presentation nicht angezeigt, waren aber wichtig.
6. Struktur. Die logische Struktur, die, die man sieht und im Strukturbaum bearbeiten kann.
7. In Content-IDs (mets:div\@CONTENTIDS) kann man jedem Strukturelement zusätzlich URIs als permanente ID hinterlegen. Ich kenne allerdings niemanden, der das nutzt.
8. Der angezeigte Text am Strukturelement (mets:div\@LABEL)
9. Verknüpfung mit einem anderen Dokument (hierarchische Vorgänge)
10. Die am Strukturelement hängende(n) Datei(en) in allen Verwendungen (mets:fileGrp\@USE) in denen die Datei tatsächlich existiert. Eine Datei muss nicht immer in allen Varianten existieren.
11. Angaben zum Ausschnitt bei Mediendateien
12. Metadaten. An jedem einzelnen Metadatum ist die domain (description → dmdSec, source → amdSec\sourceMD, technical → amdSec\techMD, …) gespeichert, in welche Kategorie der Eintrag einzuordnen ist.
13. legt die Reihenfolge des physischen Strukturelemente fest
14. Paginierung
15. Strukturtyp (für physische Strukturelemente die reservierten Schlüsselwörter page/track/other)
16. die an dem Strukturelement hängenden Medien. Eigentlich sollten die Informationen über den Ausschnitt (11) in die View, und die View zeigt dann auf den Ausschnitt eines Mediums in der physischen Struktur. Allerdings wurde das anders umgesetzt.

Wie man sieht, gibt es in dieser Struktur gar keine IDs. Sie werden beim Speichern der Struktur nach METS erzeugt, weil es in METS halt nicht ohne IDs geht, und beim Lesen benutzt, um die Puzzlesteine der METS-Datei wieder an den richtigen Stellen in ein zusammenhängendes Datenmodell zu laden. Eigentlich hatte ich hier wie in Version 2 benannte IDs benutzt (LOG_0001, LOG_0002, LOG_0003, …), da man dafür aber eine extra Klasse im Code brauchte, war Wunsch des Release Managements, stattdessen (zufällige) UUIDs zu benutzen. Da METS-IDs aber nicht mit einer Ziffer beginnen dürfen, braucht es jetzt doch eine Klasse dafür. Da es sich um zufällige UUIDs handelt, werden diese natürlich bei jedem Speichern zufällig neu gebildet.

Die Fälle, in denen IDs erhalten bleiben, wurden nachträglich absichtsvoll in diese Logik hineingearbeitet, da diese IDs auf bestimmten Kundensystemen erhalten bleiben müssen, weil die IDs zusätzlich in einer externen Datenbank mitgeführt werden und sich deshalb nicht mehr ändern dürfen. Dafür wurden noch ein paar Felder bzw. Sub-Klassen eingefügt, die in der Darstellung oben nicht aufgelistet sind. Eine Frage wäre, ob man dafür nicht CONTENTIDS nutzen könnte.

Ich glaube, die größte Verwirrung besteht darin, dass das interne Datenmodell überhaupt nach METS konvertiert abgespeichert wird. Das führt immer wieder zu Verwirrungen, auch wenn Fremddaten (z.B. ein Link auf ein Volltext-PDF) von anderen Skripten in die interne METS-Datei eingetragen werden und dann “verloren gehen”. Natürlich kann Production mit diesen Angaben beim Auswerten der METS-Datei nichts anfangen (da es dafür im obigen Modell kein Feld gibt) und “überliest” sie dann einfach. Ich hätte es auch lieber gesehen, dass die internen Daten in einem eigenen Format gespeichert werden, das die innere Programmlogik besser repräsentiert. Das hätte uns auch noch andere Möglichkeiten geboten, es wurde dann aber anders entschieden.

So kommt es zum beschriebenen Verhalten.

[andre-hohmann]

Die Änderung der ID in <mets:dmdSec> hat Auswirkungen auf die Deutsche Digitale Bibliothek (DDB) und das Zeitungsportal.

Wenn die ID eines Objekts geändert wird, wird das Objekt von der DDB nicht mehr mit dem vorhandenen Objekt zusammengeführt, sondern als neues Objekt bewertet. Dadurch entstehen Dubletten, wie zum Beispiel:

• https://www.deutsche-digitale-bibliothek.de/newspaper/2737221-2?day=3&month=10&year=1899

In der SLUB Dresden werden alle Vorgänge exportiert, um die ID in <mets:dmdSec> in allen METS-Dateien auf die uuid zu vereinheitlichen. Danach wird ein Gesamtabzug von der DDB erstellt, um die Daten in den Portalen zu ersetzen.

Durch die sukzessive Aktualisierung der METS-Dateien wegen Metadaten-Korrekturen, Hinzufügen von Kollektionen, oder anderer Gründe würden sich ansonsten mit der Zeit dublette Datensätze anhäufen.

Ergänzung:

• Generell kann die DDB die uuid verarbeiten
• Die ID in <dmdSec> wird jedoch auch dafür genutzt, um bereits vorhandene Datensätze der jeweiligen Einrichtung in der DDB zu ermitteln
• Problematisch bezüglich der ID in <dmdSec> ist die Umstellung von „DMDLOG_0001“, … auf uuid während der Migration von Kitodo.Production 2 auf Kitodo.Production 3, weil dadurch die bereits vorhandenen Datensätze in der DDB nicht mehr ermittelt werden können
• Der erstmalige Export eines Vorgangs nach der Migration in Kitodo.Production 3 ändert die ID der <dmdSec> in der METS-Datei eines Datensatzes und in der DDB wird nach erneutem Harvesting ein neuer Datensatz und somit eine Dublette angelegt
• Die ID in <dmdSec> wird nach der Migration zu Kitodo.Production 3 nicht mehr geändert, so dass weitere Aktualisierungen der Datensätze nicht mehr problematisch sind
• Dubletten in der DDB können unter anderem wie folgt vermieden werden:
  • Nach der Migration werden alle Vorgänge exportiert und die METS-Dateien an der OAI-Schnittstelle aktualisiert, dann kann von der DDB ein Gesamtabzug erstellt werden, um den Vergleich vorhandener Datensätze und die Erstellung von Dubletten zu vermeiden - da die ID in <dmdSec> nach der Migration nicht mehr verändert wird, sind weitere Exporte/Aktualisierungen nicht mehr problematisch
  • Die migrierten Daten mit geänderter ID in <dmdSec> werden nicht mehr an die DDB geliefert

Allgemeine Informationen:
In der SLUB Dresden werden die METS-Dateien regelmäßig von der DDB via OAI-Schnittstelle geharvestet. Dies beinhaltet neue und aktualisierte Datensätze.
Einrichtungen mit anderen Ablauf der Datenlieferungen sind von dem zuvor beschriebenen Verhalten gegebenenfalls nicht betroffen.

[BartChris]

Wenn ich mich nicht täusche und darauf wurde bereits oben verwiesen, betrifft das Problem der geänderten IDs bei Metadatenabzügen nur hierarchische Vorgänge. Und genauer: Die ID des erzeugten div-Containers für Eltern-Elemente (z.B. einen Jahrgang einer Zeitung, eine Zeitschrift). Das Problem tritt also in der XML-Datei der Unterordnung auf, die nun einen Elternvorgang mit anderer ID referenziert.

Erster Export:

 <mets:structMap TYPE="LOGICAL">
      <mets:div ID="uuid-87ac6c0e-2b93-420e-bb8b-6c6bf1c31447"
                TYPE="multivolume_work"
                LABEL="Versuch eines Systems des teutschen Styls, zu einem vollständigen Kursus der teutschen Sprache auf Akademien und Gymnasien">
         <mets:mptr LOCTYPE="URL"
                    xlink:href="https://content.digital.ub.uni-koeln.de/mets/retro_991020828859706476_000000"/>
         <mets:div ID="uuid-c60b7dbd-3974-44da-85cd-31a7c543f2b2"
                   DMDID="uuid-1e34d349-28eb-3c3c-904c-cb389f84ddef"
                   ADMID="uuid-af4f6d90-c121-3d1c-af83-bb4c36538ee5"
                   TYPE="volume"
                   LABEL="2. Versuch eines Systems des teutschen Styls, zu einem vollständigen Kursus der teutschen Sprache auf Akademien und Gymnasien"/>
      </mets:div>
   </mets:structMap>

Zweiter Export:

 <mets:structMap TYPE="LOGICAL">
      <mets:div ID="uuid-722a4694-039d-4bc5-ac74-c066918be9d7"
                TYPE="multivolume_work"
                LABEL="Versuch eines Systems des teutschen Styls, zu einem vollständigen Kursus der teutschen Sprache auf Akademien und Gymnasien">
         <mets:mptr LOCTYPE="URL"
                    xlink:href="https://content.digital.ub.uni-koeln.de/mets/retro_991020828859706476_000000"/>
         <mets:div ID="uuid-c60b7dbd-3974-44da-85cd-31a7c543f2b2"
                   DMDID="uuid-1e34d349-28eb-3c3c-904c-cb389f84ddef"
                   ADMID="uuid-af4f6d90-c121-3d1c-af83-bb4c36538ee5"
                   TYPE="volume"
                   LABEL="2. Versuch eines Systems des teutschen Styls, zu einem vollständigen Kursus der teutschen Sprache auf Akademien und Gymnasien"/>
      </mets:div>
   </mets:structMap>

Das Problem liegt vermutlich darin, dass der Verweis auf die Überordnung beim Export immer nur dynamisch erzeugt wird und in der internen Kitodo-XML gar nicht vorgehalten wird. Er kann dementsprechend auch nicht persistent gespeichert werden.

[henning-gerhardt]

Das liegt eher daran, dass u.a. die DDB aber auch einige SLUB-Dienste sich darauf verlassen haben, dass die Identifier im METS persistent sind. Das waren sie früher eher durch Zufall aber nicht beabsichtigt. Es gibt auch keine schriftlich festgehaltene Zusage, dass die METS Identifier, die Kitodo.Production erzeugt auch über die Lebenszeit des Dokuments / Vorgangs persistent sind.

Edit: wäre es nicht besser auf die schon vorhandenen Mittel im METS zurück zu greifen? Matthias hat ja schon die CONTENTIDS ins Spiel gebracht. Genauso gibt es noch die OBJID, die dafür genutzt werden kann, statt die METS Identifier zu persistieren.

[andre-hohmann]

Das grundlegende Problem bezüglich der Dubletten in der DDB ist die Anpassung der ID in allen <dmdSec> während der Migration von Kitodo.Production 2 auf Kitodo.Production 3. Dies betrifft zumindest in der SLUB Dresden leider die METS-Dateien aller migrierten Vorgänge.
Seltsamer Weise wurden die ID in <mets:structMap> beibehalten. Allerdings auch hier nicht die ID der Überordnung.

Die folgenden Exporte nach der Migration sind meines derzeitigen Kenntnisstandes nicht kritisch, weil sich die ID in <dmdSec> durch die Exporte nicht ändert. Die ID der Überordnungen sind vermutlich nicht relevant.

Vermutlich (!) ist die Konsistenz der ID für die DDB notwendig, weil nicht nur die <dmdSec> der Dokumente (Monografie, Band, ...) ehemals DMDLOG_0000 für nicht-hierarchische Vorgänge , sondern auch der Strukturelemente (Artikel, Kapitel, ..., wie zum Beispiel Kapitel) als eigenständige Datensätze verwaltet werden.
Einige Informationen finden sich unter: https://wiki.deutsche-digitale-bibliothek.de/pages/viewpage.action?pageId=69124760.

Aus meiner Sicht löst nur der erste Export/die erste Aktualisierung die Dubletten-Probleme aus.
Deshalb streben wir die Aktualisierung aller Vorgänge und einen Gesamtabzug durch die DDB an, um eine Vermengung der "alten" und "neuen" ID zu vermeiden.

[andre-hohmann]

Ergänzung nach einem Treffen von @andre-hohmann , @apiller und einem Kollegen der DDB:

Die folgende Vermutung war korrekt:

Vermutlich (!) ist die Konsistenz der ID für die DDB notwendig, weil nicht nur die der Dokumente (Monografie, Band, ...) ehemals DMDLOG_0000 für nicht-hierarchische Vorgänge , sondern auch der Strukturelemente (Artikel, Kapitel, ..., wie zum Beispiel Kapitel) als eigenständige Datensätze verwaltet werden.
Einige Informationen finden sich unter: https://wiki.deutsche-digitale-bibliothek.de/pages/viewpage.action?pageId=69124760.

Siehe: #5860 (reply in thread)

Die Identifier in der DDB werden für alle Strukturelemente (Monografie, Volume, Kapitel, ...) aus folgenden Bestandteilen gebildet.

• ISIL + mods:recordIdentifier + mets:dmdSec

Dies ist in der API der DDB für jeden Datensatz in dem Element <mods:recordIdentifier source="zvdd"> nachvollziehbar, wie zum Beispiel:

• https://api.deutsche-digitale-bibliothek.de/items/JXWQ34PXYZW4TNS23K3BYX7FUCJJRSCC/source/record

Für:

• https://www.deutsche-digitale-bibliothek.de/item/JXWQ34PXYZW4TNS23K3BYX7FUCJJRSCC