Goobi-Bildstapel-Wandler

Aus Allegro
Wechseln zu: Navigation, Suche

1 Neuigkeiten[Bearbeiten | Quelltext bearbeiten]

Innerhalb des METS-Editors wurde ein neuer Bereich geschaffen, der es dem Bearbeiter erlaubt, unmittelbar einen Eingriff in die Digitalisate auf dem Goobi-Server zu nehmen. Dies gestattet dem Metadatenbearbeiter so einfach, doppelte Bilder zu löschen, ohne dass aufwendige Korrekturschleifen mit anderen Arbeitsschritten durchlaufen werden müssen. Manipulationen innerhalb der Digitalisate haben dabei stets eine Auswirkung auf sämtliche Verzeichnisse des jeweiligen Vorgangs. Eine Umbenennung oder Löschung der Masterbilder hat demnach auch sofort eine Änderung der analog zu den Masterbildern bestehenden Derivaten zur Folge.

Als wir den Bildstapel-Wandler benutzten, musste man noch in beide Bildverzeichnisse die Images hochladen. Hat sich anscheinend geändert im Sinne von verbessert.

2 Nachfragen[Bearbeiten | Quelltext bearbeiten]

Intranda: Bild unnummeriert einfügen: die Paginierung wird für die nachfolgenden Seiten nicht angefaßt. Mit der Option Paginierungssequenz werden die nachfolgenden Seiten entsprechend hochgezählt. Die nachfolgenden Bilder werden um 1 verschoben.

3 Ergebnisprüfung am Vorgang 2466 (allgdele_ZDB020612311_0030)[Bearbeiten | Quelltext bearbeiten]

Alte Version des Bandes im Viewer: http://goobiweb.bbf.dipf.de/viewer/image/ZDB020612311_0030/119/ - ab Image 119 (Paginierung 98) bzw. vor Image 120 (Paginierung 101) sind zwei Dummybilder in Goobi.Production eingefügt mit Paginierung 99 und 100. Die Bilder sind neuer Bestandteil von Heft 11 und Schlusseiten von dessen letztem Heftartikel. Es werden also die Bilder 120 und 121 eingefügt. Heft 12 beginnt danach ab Bild 122

Betroffen sind also:

  • Heft 11(109:91-121:100)
  • Tagesgeschichtliches und Feuilleton(115:94-121:100)

Entsprechung in der meta.xml von Goobi.Production:

Bildateien in fileSec

 <mets:file ID="FILE_0120" MIMETYPE="image/tiff">
 <mets:FLocat LOCTYPE="URL" xlink:href="00000120.tif" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 </mets:file>
 <mets:file ID="FILE_0121" MIMETYPE="image/tiff">
 <mets:FLocat LOCTYPE="URL" xlink:href="00000121.tif" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 </mets:file>


Bilder in structMap physical

Es fällt auf, daß die "DMDID"-Attribute der mets-Elemente bei allen eingefügten Bildern fehlen und somit auch deren Attributwerte DMDPHYS_nnnn. Es gibt diese DMDPHYS_0120 und DMDPHYS_0121 auch gar nicht in der meta.xml!

 <mets:div DMDID="DMDPHYS_0119" ID="PHYS_0119" ORDER="119" ORDERLABEL="98" TYPE="page">
 <mets:fptr FILEID="FILE_0119" /> 
 </mets:div>
 <mets:div ID="PHYS_0120" ORDER="120" ORDERLABEL="99" TYPE="page">
 <mets:fptr FILEID="FILE_0120" /> 
 </mets:div>
 <mets:div ID="PHYS_0121" ORDER="121" ORDERLABEL="100" TYPE="page">
 <mets:fptr FILEID="FILE_0121" /> 
 </mets:div>
 <mets:div DMDID="DMDPHYS_0122" ID="PHYS_0122" ORDER="122" ORDERLABEL="101" TYPE="page">
 <mets:fptr FILEID="FILE_0122" /> 
 </mets:div>

FILE_0120 und FILE_0121 ist also verbunden mit PHYS_0120 und PHYS_0121 verlinkt mit LOG_0042 (Heft) und LOG_0046 (Artikel)

Was sind LOG_0042 und LOG_0046? Richtig: Heft und Artikel:

 <mets:div DMDID="DMDLOG_0040" ID="LOG_0042" TYPE="PeriodicalIssue">
 <mets:div DMDID="DMDLOG_0041" ID="LOG_0043" TYPE="Article" /> 
 <mets:div DMDID="DMDLOG_0042" ID="LOG_0044" TYPE="Article" /> 
 <mets:div DMDID="DMDLOG_0043" ID="LOG_0045" TYPE="Article" /> 
 <mets:div DMDID="DMDLOG_0044" ID="LOG_0046" TYPE="Article" />

Ist DMDLOG_0040 das Heft 11? Ja, mit URN: urn:nbn:de:0111-bbf-spo-8916893 Ist DMDLOG_0044 der Artikel? Ja, mit URN: urn:nbn:de:0111-bbf-spo-8916931

Zuweisungen in structLink

In <mets:div DMDID="DMDLOG_0001" ID="LOG_0003" TYPE="PeriodicalVolume"> sind die Seiten verzeichnet:

 <mets:smLink xlink:to="PHYS_0118" xlink:from="LOG_0003" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0119" xlink:from="LOG_0003" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0120" xlink:from="LOG_0003" xmlns:xlink="http://www.w3.org/1999/xlink" />
 <mets:smLink xlink:to="PHYS_0121" xlink:from="LOG_0003" xmlns:xlink="http://www.w3.org/1999/xlink" />
 <mets:smLink xlink:to="PHYS_0122" xlink:from="LOG_0003" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0123" xlink:from="LOG_0003" xmlns:xlink="http://www.w3.org/1999/xlink" />

Weiter in stuctLink auf Heftebene (Heft 11): Paßt, 13 Seiten</ br> Heft 11(109:91-121:100) = <mets:dmdSec ID="DMDLOG_0040" >

 <mets:smLink xlink:to="PHYS_0109" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0110" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0111" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0112" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0113" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0114" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0115" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0116" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0117" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0118" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0119" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0120" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0121" xlink:from="LOG_0042" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 

Weiter in stuctLink auf Artikelebene (in Heft 11): Paßt, 7 Seiten Tagesgeschichtliches und Feuilleton(115:94-121:100) = <mets:dmdSec ID="DMDLOG_0044">

 <mets:smLink xlink:to="PHYS_0115" xlink:from="LOG_0046" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0116" xlink:from="LOG_0046" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0117" xlink:from="LOG_0046" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0118" xlink:from="LOG_0046" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0119" xlink:from="LOG_0046" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0120" xlink:from="LOG_0046" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 <mets:smLink xlink:to="PHYS_0121" xlink:from="LOG_0046" xmlns:xlink="http://www.w3.org/1999/xlink" /> 
 

Probe URN-Erhalt mit PHYS_0115

 <mets:div DMDID="DMDPHYS_0115" ID="PHYS_0115" ORDER="115" ORDERLABEL="94" TYPE="page">
 <mets:fptr FILEID="FILE_0115" /> 
 </mets:div>

ist:

 <mets:file ID="FILE_0115" MIMETYPE="image/tiff">
 <mets:FLocat LOCTYPE="URL" xlink:href="00000115.tif" xmlns:xlink="http://www.w3.org/1999/xlink" />

ist:

 <mets:dmdSec ID="DMDPHYS_0115">
 <mets:mdWrap MDTYPE="MODS">
 <mets:xmlData>
 <mods:mods xmlns:mods="http://www.loc.gov/mods/v3">
 <mods:extension>
 <goobi:goobi xmlns:goobi="http://meta.goobi.org/v1.5.1/">
 <goobi:metadata name="_urn">urn:nbn:de:0111-bbf-spo-8919541</goobi:metadata>

ist Seite 94 mit Artikelbeginn rechts unten.

Gleiche URN zum Bild im Viewer mit alter Version von meta.xml vorhanden.

4 Erfahrungsaustausch[Bearbeiten | Quelltext bearbeiten]

Liebe Frau Wendt,

mittlerweile haben wir auch die Goobi.production-Erweiterung von intranda bekommen, die das Formular "Austausch von Dateien" eröffnet. Die Dokumentation dazu läßt auch in mehrerer Hinsicht noch Fragen offen und deshalb ist auch dieser Text geschrieben, um "Nachfolger" in den anderen Einrichtungen zu unterstützen. Aber ich frage Sie auch (ganz unten) hierzu noch etwas.

Wir bringen nun Dummy-Bilder als Platzhalter in die Bildstapel, wo bisher verschiedene physische Vorlagen(seiten) fehlten und somit, naja, logische Dateilücken im Digitalisat bestanden. Im Goobi-Band sind auch entsprechende Paginierungslücken schon vorhanden. Wir wollen mit Dummies logisch und physisch die Vorgänge samt Paginierung komplettieren. Wir hatten zum Beispiel bei einem Band mit 522 Bildern noch 20 Dummy-Bilder an neun Stellen eingefügt.

Intranda, also Herr Sehr, nennt den TIFF-Ordner, den der Metadateneditor zur Bildanzeige nutzt, den "Inhalteordner". Dann gibt es ja noch den "orig_Ordner". Die Arbeit am geöffneten Vorgang im Metadateneditor ist:

0. Wechsel zum Formular "Austausch von Dateien" , Bereich "Datei hochladen"
1. Wir wählen das Dummy-Bild per "Durchsuchen..." aus,
2. wählen den "Inhalteordner" aus,
3. wählen die Seite, die um ein Bild Richtung Bildstapelende verschoben werden soll und
4. nennen die einzufügende TIFF-Datei z.B. "00000537.tif" und somit immer einen Zähler höher als der gesamte Bilddateistapel im Moment hat; also letzte Bilddatei + 1 Zähler hinzu,
5. wählen die Option "unnummeriert",
6. führen "Datei hochladen" aus,
A. [1.-6.] widerholen die Sache, sofern 2 und mehr Dummy-Bilder in einer zusammenhängenden (!) Folge eingefügt werden müssen,
A1: achten darauf, daß die Auswahl von Punkt 3. um einen Zähler steigt und im Feld "Position" des Formulars wieder mit neuem Wert gewählt werden muß,
7. wechseln zum Formular "Strukturdaten",
8. wählen z.B. das betroffene Zeitschriftenheft,
9. fügen die neu erstellten Seiten in "zugehörige Seiten" des Heftes ein,
10. wählen z.B. den im Heft betroffenen Artikel(n),
11. fügen die neu erstellten Seiten in "zugehörige Seiten" des Heftes ein,
12. wechseln zum Formular "Paginierung",
13. geben den eingefügten "uncounted"-Seiten deren Paginierung,
14. starten mit "Dateinamen neu erzeugen" das Umbenennen des Bilddateistapels,
15. speichern den Vorgang ab.

Damit ist der "Inhalteordner" mit neuen und korrekt eingeordneten TIFF-Dateien erstellt.

Probleme dabei:

1. Wenn die Einfügungen keine Dummy-Bilder sind, sondern echte (Nach-)Scans in der entsprechenden Auflösung und Größe eines Masterbildes, so befinden sich diese Bilder in Bezug auf unserem Workflow regelverstoßend im "Inhalteordner". Also müßte der "Inhalteordner" nochmal mit der Komprimierfunktion bearbeitet werden. Dies wird bei uns per Goobi-Skriptbefehl: action:runscript "stepname:Automatischer Kopier- und Komprimierschritt" "script:Komprimieren" gemacht.

2. Wenn die TIFF-Header der Bilder im "Inhalteordner" wichtig sind, so fehlen den neuen Mitgliedern im "Inhalteordner" diese Metadaten. Ich bin mir nicht sicher, ob die TIFF-Header beim Kopieren oder beim Komprimieren geschrieben werden. Ein Start des Kopieren-Skripts um TIFF-Header zu schreiben ist aber aus folgendem Grund ausgeschlossen:

3. Im "orig_Ordner" sind durch die Schritte (oben) 1.-15. keine Bilder hinzugekommen. Die beiden TIFF-Bild-Verzeichnisse sind also ab nun bedeutend verschieden. Dem "orig_Ordner" fehlen die neuen Bilder. Es gibt im Moment bei der Erweiterung keine Möglichkeit, beide Ordner per Punkt 6. und 14. oben mit den Bildern synchron zu führen, was eigentlich der gewünschte Regelfall wäre und somit doch als Standard programmiert werden könnte. Es wirkt das Skript im Formular "Paginierung" namens "Dateinamen neu erzeugen" nur im "Inhalteordner".

4. Viel manueller Aufwand: Um den "orig-Ordner" auf den gleichen Stand zu bringen, ist es also erforderlich vor (!) dem Komprimieren die Bilder aus dem Inhalteordner an bestimmte Stellen im Dateistapel des "orig-Ordner" zu kopieren, wobei ein anderer Dateiname zu nehmen ist. Sind alle Dateien im "orig-Ordner" an der richtigen Stelle, kann man mit einem beliebigen Tool den ganzen Dateistapel von 0000 0001.tif bis nnnn nnnn.tif umbenennen.

Wenn nun beide Ordner in puncto Reihenfolge und Inhaltsgleichheit der Bilder identisch sind, kann man nun den Kopierschritt und Komprimierschritt durchführen, wenn TIFF-Header und Komprimierung erforderlich sei.

Wie bringen Sie in Hamburg die beiden Bildordner wieder zueinander passend?

Wunsch für die Zukunft:

Diese Platzhalter für fehlende Scans sollten auffindbar gemacht werden, ohne sie mühselig & manuell metasprachlich beschreiben zu müssen. Es wäre schön, wenn man per OAI-PMH oder sonstiger Technik eine Digitale Bibliothek abfragen könnte, welche Werke noch solcherart gekennzeichnete Lücken haben. Nur so könnte man ein (inter-)nationales Meldewesen für Vervollständigungsbemühungen aufbauen. Oder wäre das ein Thema für einen gemeinsamen Förderantrag?? ;-)

Herzlichen Gruss, Martin Wünsch

5 Erklärung intranda 20131101[Bearbeiten | Quelltext bearbeiten]

Die Erweiterung funktioniert so, wie sie von der SUB Hamburg beauftragt wurde. Es ist zum Beispiel beabsichtigt, das man Dateien immer nur in einen Ordner hoch laden kann.

Damit Sie die Funktionen auf Ihrem Server wie gewünscht nutzen können, gibt es je nachdem, was für Bilder Sie importieren, verschiedene Möglichkeiten.

  • Wenn Sie ein Dummy Bild in den Derivate Ordner importieren wollen, können Sie im Anschluss das Bild unter dem gleichen Namen in den orig_Ordner importieren. Jegliche nachträglichen Änderungen der Reihenfolge oder Umbenennung der Dateien werden synchron in allen Ordnern durchgeführt, in denen Dateien mit diesen Namen vorhanden sind. Dies betrifft neben allen Bilderordnern auch die Ordner für OCR-Ergebnisse.

Wenn Sie nachträglich ein neues master-Bild hinzufügen wollen, schlage ich folgendes Vorgehen vor:

1.) geben Sie den Vorgang per Korrekturmeldung zurück in den Schritt Scannnen.

2.) Fügen Sie die neuen Bilder ans Ende in den orig_Ordner ein.

3.) Lassen Sie die automatischen Schritte zum Kopieren, Konvertieren, Tiffheader-Schreiben durchlaufen.

4.) Im Metseditor stehen nun am Ende der Paginierungssequenz die neuen Bilder zur Verfügung. Diese können nun an die richtige Stelle verschoben werden. Wenn dies zu aufwändig ist, gibt es auch die Möglichkeit, die zu verschiebenden Bilder serverseitig zu exportieren, dabei zu löschen und an der neuen Stelle zu importieren.

5.) Führen Sie danach die URN-Generierung erneut durch. Dadurch werden für die neu eingefügten Bilder neue URNs erzeugt. Bestehende URNs bleiben erhalten.