Links

Juni 2021

Entwicklungen und Neuerungen an Goobi workflow im Juni 2021

Coming soon

  • Auslagerung einiger Statistiken zu Plugins mit Auffrischung der Nutzeroberfläche
  • Implementierung einer neuen Such-Syntax
  • Überarbeitung der internen Ordnerstruktur zur Einhaltung der Maven-Konvention
  • Ausbau der Plugin-Dokumentationen

Konvertierung von Lido zu METS/MODS und METS/MODS zu Lido nun möglich

Goobi unterstützt nun die Konvertierung des Metadatenformats LIDO zu METS. So ist es von nun an zum Beispiel möglich, eine LIDO Datei zu importieren und intern wieder als METS-Datei zu speichern. Genauso lässt sich eine vorliegende METS-Datei auch wieder als LIDO-Datensatz exportieren.
Konvertierung von METS zu LIDO und zurück

Weitere Orte für Bilderreferenzierungen in LIDO-Dateien

Bisher wurden Bilder in LIDO als <linkResource> innerhalb des Elements <resourceRepresentation> erwartet:
<lido:administrativeMetadata>
<lido:resourceWrap>
<lido:resourceSet>
<lido:resourceRepresentation lido:type="local">
<lido:linkResource>00000001.jpg</lido:linkResource>
</lido:resourceRepresentation>
</lido:resourceSet>
</lido:resourceWrap>
</lido:administrativeMetadata>
Mit den Entwicklungen in diesem Monat ist es nun möglich geworden, dass Bilder stattdessen auch als <resourceID> angegeben werden können. Dies ist insbesondere für die Datenübernahme aus der Applikation MuseumPlus hilfreich:
<lido:administrativeMetadata>
<lido:resourceWrap>
<lido:resourceSet>
<lido:resourceID>00000001.tif</lido:resourceID>
</lido:resourceSet>
</lido:resourceWrap>
</lido:administrativeMetadata>
Zu beachten ist: Wenn ein Bild zu einem Unterelement gehört, so muss die Angabe innerhalb des <lido> Elements erfolgen, das dieses Unterelement beschreibt.

Anpassungen an der Nutzbarkeit von IIIF-URLs in Skriptaufrufen

Vor kurzem hatten wir den sogenannten Variablen-Replacer dahingehend erweitert, dass dieser nun auch IIIF-URL für die zugehörigen Bilder eines Vorgangs in Skriptaufrufen erlaubt. Hier mussten wir noch einmal etwas nachkorrigieren, damit das Encoding der URLs für die jeweiligen Anwendungsfälle passt.

Aufbau eines Authority Servers für Vokabulare

Die Vokabularverwaltung in Goobi workflow ermöglicht es, in der Nutzeroberfläche kontrollierte Vokabulare zu verwalten und diese im Metadateneditor als Auswahlmöglichkeiten für Metadatenfelder zu nutzen. Besonders praktisch ist hierbei, dass die Beschreibung für eine bestimmte Entität geändert werden kann und dadurch, dass in der METS-Datei nur auf einen Vokabular-Eintrag verlinkt wird, der Eintrag automatisch auch in allen Vorgängen aktualisiert wird. Aufgrund dieser Vorzüge wird die Vokabularverwaltung in immer mehr Projekten verwendet.
Die Vokabularverwaltung von Goobi findet immer mehr Einsatz
Ein Problem bei der Verwendung der Vokabulare kann entstehen, wenn nach dem Export der Daten auch der Goobi viewer auf die gleichen Vokabulare zugreifen soll, da die Goobi workflow Installation häufig von außerhalb des Einrichtungsnetzes nicht erreichbar, da sie sich hinter eine Firewall befindet. Aus diesem Grund haben wir einen neuen Vokabularserver entwickelt, auf den Goobi workflow alle Änderungen an den in diesem Sinne konfigurierten Vokabularen spiegelt. In die Metadaten der METS-Datei wird in einem solchen Fall die URL der Datensätze im öffentlich zugänglichen Vokabularserver eingetragen, der bei intranda gehostet und entsprechend weltweit erreichbar ist. So kann der Goobi viewer dann auch ohne Probleme auf die Vokabulare zugreifen und erhält so immer aktuelle Datensätze aus dem Vokabular.
Der Code zu diesem Server ist bisher noch nicht veröffentlicht und befindet sich im intranda-internen Git-Repository: https://gitea.intranda.com/intranda/goobi-authority-server. Dort befindet sich auch die noch interne Dokumentation im Repository: https://gitea.intranda.com/intranda/goobi-authority-server/src/branch/master/goobi-authority-server/docs/AuthorityServer.md. Über den Zeitpunkt der Veröffentlichung dieses Projektes haben wir bisher noch nicht entschieden. Zuvor möchten wir den Quellcode noch einem Review unterziehen und auch die Dokumentation aufbereiten und übersetzen.

Beautifier für MARC Datensätze

Schon seit den ersten Tagen von Goobi existiert die Möglichkeit, dass Vorgänge auf der Basis einer Katalogabfrage erzeugt werden und somit die Daten aus dem Katalog nachnutzen. Leider ist jedoch die Antwort der jeweiligen Kataloge manchmal nicht so, dass Goobi beispielsweise die Publikationstypen verlässlich aus den zu erwartenden Feldern interpretieren kann. Daher gibt es schon lange die Möglichkeit, die Katalogantwort vor deren Auswertung mit dem sogenannten Beautifier zu manipulieren. Dies ging in der Vergangenheit bereits mit PICA-Datensätzen. Neu hinzugekommen ist nun, dass diese Möglichkeiten jetzt auch für MARC-Datensätze bestehen. Eine solche Konfiguration kann beispielsweise so aussehen:

Manipulationen am Leader

In diesem Beispiel wird der Leader an Position 19 mit einem Leerzeichen (\u0020) ersetzt, sofern im Leader an Position 6 der Wert e steht.
<beautify>
<setvalue tag="leader19" subtag="" value="\u0020">
<condition tag="leader6" subtag="" value="e" />
</setvalue>
</beautify>

Schreiben von Controlfields

Dieses Beispiel zeigt, wie bei einem Datensatz einer OPAC-Anfrage das Feld <controlfield tag="999"> mit dem Wert KXP erzeugt wird.
<beautify>
<setvalue tag="999" subtag="" value="KXP" />
</beautify>

Ersetzen von Feldinhalten:

Diese Beispiel zeigt, wie ein Feldinhalt geändert werden kann. Hier wird das Feld 041$a mit dem Wert ger ersetzt, sofern es den Wert lat enthält.
<beautify>
<setvalue tag="041" subtag="a" value="ger">
<condition tag="041" subtag="a" value="lat" />
</setvalue>
</beautify>
Unter der folgenden URL ist die Konfiguration für Kataloge und auch die Festlegung des Beautifiers dokumentiert:
7.2 goobi_opac.xml
Goobi workflow (Deutsch)
https://docs.goobi.io/goobi-workflow-de/admin/7/7.2

Weitere Accessibility-Anpassungen

Und weiter ging die wilde Fahrt auch in diesem Monat was die Accessibility-Optimierungen angeht. Man erhält schon den Eindruck, dass es sich hier um eine Lebensaufgabe handelt. Aber es fühlt sich doch immerhin schon danach an, als ob wir auf der Zielgeraden sind. Schauen wir mal, wie es im nächsten Monat aussieht. :)
Accessibility ist wichtiger als viele denken!

Kompilieren mit Java 11 möglich

Das Kompilieren von Goobi workflow ist nun nicht mehr festgelegt auf die schon recht betagte Version 8 von Java. Stattdessen ist von nun an nicht mehr nur der Betrieb mit Java 11 möglich sondern auch das Kompilieren.
Auszug aus der Konsole nach dem Kompilieren von Goobi workflow mit Java 11
Für diejenigen, die Goobi gern einmal selbst kompilieren möchten, gibt es hier einmal eine Mini-Zusammenfassung, wie man dies selbst durchführen kann:
# install needed packages
sudo apt install git
sudo apt install maven
# checkout Goobi workflow from GitHub
git clone https://github.com/intranda/goobi-workflow.git
# go into the Goobi workflow project
cd goobi-workflow/Goobi/
# compile Goobi workflow
mvn package

Automatische Generierung von JWT Secrets

JSON Web Tokens (JWTs) werden in Goobi workflow an immer mehr Stellen eingesetzt, um anderen Programmen oder auch Personen zu erlauben, bestimmte Aktionen für eine gewisse Zeit auszuführen. Bisher musste hierzu im Vorfeld ein JWT-Secret zwingend von Hand vorkonfiguriert werden, um diese Funktionalität nutzen zu können. Seit diesem Monat erzeugt Goobi workflow das JWT secret selbst, wenn es bisher noch nicht vorkonfiguriert wurde.
In der Standard-Installation ist das JWT-Secret noch auskommentiert und kann inidividuell konfiguriert werden

JWT key Rotation

Bei der Implementierung der oben beschriebenen automatischen Generierung der JWT secrets, ist eine potentielle Sicherheitslücke aufgefallen: Die JWT keys wurden nicht rotiert, was einem Angreifer bei vielen abgefangenen Nachrichten eventuell ermöglicht hätte, das secret zu erraten. Dies wurde nun geändert und die keys werden alle 24 Stunden rotiert.

Anpassungen des Standard-Exports für Benennungsänderungen

Ganz selten kommt es vor, dass Dateinamen von Bildern einzelner Vorgänge an Goobi vorbei umbenannt werden, so dass Goobi von diesen Umbenennungen bisher keine Kenntnis hatte und dies bei erneuten Exporten der METS-Dateien zu Problemen führen konnte.
Einstellung des Standard-Exports für METS-Dateien ohne Berücksichtigung des MIME-Types
Mit einer Anpassung des Standard-Exports umgehen wir diese Problematik nun. Denn im Falle der Projektkonfiguration, dass die METS-Datei dynamisch die Dateinamen abhängig vom erkannten MIME-Type (z.B. image/jpeg) erzeugt werden soll, erfolgt nun auch eine Aktualisierung der intern gespeicherten zwischenzeitlich geänderten Dateinamen innerhalb der METS-Datei. Somit werden solche potentiellen Fehlerfälle bei unabhängig von Goobi vorgenommenen Umbenennungen (z.B. angepasste Groß- und Kleinschreibung, geänderte Dateiendung) abgefangen.
Einstellung des Standard-Exports für METS-Dateien für die Berücksichtigung des MIME-Types

Code-Optimierungen

Wenig spektakulär für Nicht-Programmierer klingt eine aufwendige Umstellung die wir intern gerade vornehmen für weitere Code-Optimierungen. Wir verwenden hier gerade noch mehr die Programmbibliothek Lombok zur Code-Generierung von langweiligem aufgeblähtem aber leider notwenigem Quellcode, den man per Konvention innerhalb von Java-Applikationen haben muss.
Für diejenigen Leser, die selbst Java programmieren: Lombok ist definitiv einen Blick wert und übernimmt die automatische Generierung von Gettern, Settern, Konstruktoren und noch einiges mehr.
Generierung von Gettern und Settern durch Lombok

Duplizieren von Metadatengruppen erweitert

Die Metadatengruppen haben wir kürzlich bereich massiv erweitert. Für ein Projekt in Kroatien benötigten wir hier noch etwas Nacharbeit: Es war notwendig, dass Metdatengruppen auch dupliziert werden können, so dass diese nun korrekt alle zugehören Metadaten, Personen sowie Untergruppen mit duplizieren. Das spart einige unnötige manuelle Bearbeitungen.
Metadatengruppen lassen sich nun vollständig duplizieren