Das Importieren automatisieren

Viele Museen importieren ihre Daten zu museum-digital. Wie auch die allgemeine Benutzung von museum-digital gibt es dabei eine Reihe von Gründen und Motivationen.

Museen, die bisher ein anderes Tool zum Sammlungsmanagement genutzt haben migrieren ihre Daten einmal mit Hilfe des Importtools – oft mit dem generischen CSVXML-Import – um dann in musdb weiterzuarbeiten. Museen, die ein anderes Sammlungsmanagement-System haben und damit zufrieden sind nutzen museum-digital rein zur Publikation und fallen dabei in zwei bis drei Kategorien. Die wahrscheinlich größte Gruppe sind dabei Museen, die zum Abschluss eines Digitalisierungsprojektes die im Rahmen des Projektes digitalisierten Bestände importieren und dann gesammelt publizieren. Andere, oft eher größere Institutionen wie das Landesmuseum Württemberg oder die Staatlichen Schlösser und Gärten Hessens importieren und veröffentlichen regelmäßiger um die neuesten gut erfassten Objekte auch unabhängig von Projektkontexten schnell publiziert zu sehen. Dazu kommen Institutionen wie die in den Interaktiven Katalogen des Münzkabinetts arbeitenden Münzsammlungen, die eine eigene primäre Publikationsplattform betreiben und für einen regelmäßigen Datenabgleich daraus importieren.

Zu guter Letzt gibt es Häuser, die zwar direkt in musdb erfassen, aber schlicht zu viele Bild-Digitalisate erstellen, als das ein manueller Upload Sinn machen würde – etwa das Freie Deutsche Hochstift in Frankfurt mit seiner Handschriftensammlung. Hier werden die Bilder entsprechend ihrer Dateinamen zu den bestenfalls schon bestehenden Objektdatensätzen importiert.

Für alle, die regelmäßig und immer wieder mit denselben Methoden bzw. im selben Format importieren, macht es Sinn zu lernen, wie man Importe selbst durchführt.

Importe selbst durchführen

Für das eigenständige Importieren von Objektdaten zu museum-digital steht eine WebDAV-Schnittstelle zur Verfügung. Grob funktioniert der Upload dann wie mit einem Netzwerklaufwerk (bzw. ist genau das) – man verbindet sich und bekommt Zugriff auf einen Ordner.

In diesem befinden sich zwei leere Unterordner, einer für Metadaten und einer für Mediendateien. Nun können die Objektdaten hochgeladen werden. Zuletzt muss man dem Server mitteilen, dass der Upload bereit steht und welche Einstellungen für den Import genutzt werden sollen. Das passiert über eine Konfigurationsdatei. Mehr dazu im Handbuch.

Einerseits ermöglicht das Prozedere Usern einen – einmal probiert – halbwegs einfachen und stabilen Import. Andererseits ist es bei häufigen und regelmäßigen Importen doch weiter mit manueller Arbeit verbunden. Man muss sich eben erstmal verbinden, Uploads auswählen und hochladen, und die Konfiguration erstellen (oder kopieren). Bei großen Datenmengen kann die notwendigerweise chronologische Abfolge der Arbeitsschritte zudem aller Vereinfachung zum Trotz einen nicht zu verachtenden Zeitaufwand bedeuten.

In anderen Worten: Da ist Raum für weitere Automatisierung.

Automatisieren

Gesagt, getan. Mit einem neuen Upload-Tool (erst einmal unkreativ museum-digital:uploader genannt) lässt sich der Upload einfacher gestalten und/oder weiter automatisieren.

Das Tool basiert auf der Annahme, dass man als Museum nur eine Art von Import regelmäßig durchführen möchte – die Einstellungen für den Import also stabil bleiben. Entsprechend beginnt die Nutzung des Tools mit der Konfiguration.

Hier wird neben der ID der Institution, der Mailadresse der importierenden User und dem Importformat auch nach einem Ordner für die Uploads gefragt. Dieser wird in der Folge regelmäßig überprüft. Befinden sich darin Metadaten-Dateien (XML, JSON, CSV) und/oder Mediendateien, so wird ein Import initiiert. Dazu werden die Dateien hochgeladen und die Importkonfiguration auf Basis der Anfangs einmal eingegebenen Einstellungen generiert. Zuletzt werden die Dateien aus dem Ordner gelöscht. Dabei werden sowohl auf lokaler Seite als auch auf dem Server Checks durchgeführt, damit der Upload nicht durchgeführt werden kann, wenn die Ordner gerade noch befüllt werden (etwa lokal erst vor 20 Sekunden ein neu hereinkopiertes Bild vorliegt oder auf dem Server noch ein vorheriger Upload geplant ist).

Damit sich das Tool möglichst flexibel genutzt werden kann, kann es sowohl über Kommandozeilen-Parameter als auch über ein browserbasiertes Interface genutzt werden. Ersteres könnte etwa bei Nutzung eines externen, regelmäßigen Aufrufs genutzt werden. Das Browser-Interface andererseits kommt sowohl mit einer Möglichkeit zum manuellen Anwerfen des Uploads als auch mit einem eingebauten Scheduler, der die Prüfung des Ordners und das etwaige Uploaden alle drei Stunden automatisch durchführt.

Somit ist mit dem Tool der einzige verbleibende Schritt zum vollständig automatisierten Datenabgleich. Für die Häuser, die über einem festgelegten Schema Bild-Digitalisate importieren um sich den manuellen Upload zu sparen heißt das ein einfaches Kopieren der Dateien in den Ordner. Ggfs. schwieriger wird es für die, die häufiger aus einem hausinternen Sammlungsmanagement-System (CMS) importieren. Wie leicht – und ob – sich daraus automatisiert Exporte erstellen lassen, hängt vom jeweiligen CMS und seinen Schnittstellen ab. Es wäre interessant, hier mehr über die Möglichkeiten der einzelnen CMS zu erfahren.

Code-Signing, Windows, Leiden

Schon beim ersten Ideensammeln zum Uploader standen ein paar Grundanforderungen fest.

• Der Uploader muss auf einem lokalen Rechner genutzt werden können.
• Er muss unabhängig von der Wahl des Betriebssystems eingesetzt werden können. Während der überwiegende Teil der Museen Windows nutzt, sind MacOS-Systeme doch immer wieder anzutreffen. Und die Entwicklung geschieht primär unter Linux.
• Alle nötigen Ressourcen für das Programm müssen entweder im Programm enthalten oder über das Netz nachgeladen werden. Die Bedingungen in vielen Museen sind nicht so, dass man sich auf Ordnerstrukturen verlassen könnte, oder als das das zusätzliche Installieren eines Interpreters nicht eine große zusätzliche Hürde darstellen würde.
• Das Programm muss stabil sein. Im Idealfall sollte es einmal eingerichtet quasi unsichtbar im Hintergrund arbeiten.

Für die Wahl der Programmiersprache heißt das, dass es eine kompilierte Sprache brauchte, deren Compiler Cross-Compilation (also das Kompilieren von Programmen für ein Betriebssystem unter einem Anderen) unterstützt. Die Wahl fiel auf Go. Die Implementation gestaltete sich damit sehr angenehm, sodass die erste volle Release-Version jetzt zum Download zur Verfügung steht. Die Anwendung ist nach GPL 3 lizensiert, kann also frei weiterentwickelt werden (solange man die eigenen Anpassungen auch wieder teilt).

Unter anderem durch die Wahl der Programmiersprache tauchen aber an anderen Stellen Schwierigkeiten auf. Unter Linux läuft das Programm flüssig – unter Windows blockiert der Windows Defender SmartScreen die Benutzung. Und so eröffnet sich eine ganz neue Problemklasse.

Zur Abwehr von Malware blockiert der SmartScreen Anwendungen, die a) verdächtig aussehen, b) nicht von einer vertrauenswürdigen Stelle signiert sind und/oder c) noch keine breite Verwendung haben. Wie genau die verschiedenen Aspekte zusammenspielen ist nicht öffentlich bekannt.

Da das Programm neu ist, ist klar, dass es noch keine breite Benutzerbasis hat. Und mit seiner Zielgruppe und seinem Zweck wird es die wohl auch nie bekommen.

Dass Go-Programme von Microsoft als „verdächtig“ eingeschätzt werden ist ein so bekanntes Problem, dass es dazu einen eigenen Eintrag im FAQ der Programmiersprache gibt. Auch daran scheint sich wenig ändern zu lassen.

Bleibt ein Zertifikat: Die zum Signieren von Programmen für Windows nötigen Zertifikate werden in einer Struktur ausgegeben, die sehr an die Vergabe von TLS-Zertifikaten vor 20 Jahren erinnert (und tatsächlich sind dabei dieselben Firmen vertreten). Man beantragt ein Zertifikat und wird kurz überprüft – je nach Art des Zertifikats muss man eine Kopie eines Ausweisdokuments einsenden oder Nachweisen, dass man eine seit mehreren Jahren registrierte Firma/Organisation ist. Dazu muss man – wieder unterschiedlich je nach Anbieter und Zertifikatstyp – einige hundert Dollar zahlen (z.B. hier). Dazu bieten alle außer dem „größten“ Zertifikatstyp (EV) keine Garantie, dass die Warnungen damit vermieden werden können. Schon vor dem Hintergrund jedes einzelnen dieser Aspekte ist das Signieren der Anwendung keine Option. Falls jedoch jemand ein Zertifikat hat und zur Verfügung stellen möchte, wären wir darüber froh.

Einen Ausweg – oder zumindest einen Schritt dahin – könnte es doch geben. Microsoft bietet einen Service an, bei dem man sein Binary hochladen und sich über fälschliche Kategorisierungen beschweren kann. Um diesen zu nutzen braucht man einerseits ein Benutzerkonto (warum ist nicht ersichtlich, aber immerhin ist die Hürde gering), andererseits die Fehlermeldungen / Warnungen, über die man sich beschweren möchte. Und das heißt dann doch wieder, dass man einen Windows-Rechner braucht, um die richtigen Fehlercodes zu ermitteln. Cross-Compilation funktioniert heute also technisch eigentlich problemlos – eine cross-compilation tatsächlich nutzbarer und verteilbarer Programme bleibt schwierig.

So oder so führt wohl mittelfristig kein Weg an einer Meldung bei Microsoft vorbei. Ob das ausreicht, damit das Programm ohne Warnungen genutzt werden kann, bleibt unklar. Auch dazu hält sich Microsoft bedeckt, und es gibt verschiedene Erfahrungsberichte. Aber immerhin scheint es die wahrscheinlich zu erhöhen, dass es (zumindest innerhalb eines Releases) problemlos genutzt werden kann.