Das Backup der Oracle-Datenbanken, mit denen imdas pro arbeitet, wird mit den üblichen Aufbewahrungsfristen entsprechend dem Datensicherungskonzept vorgehalten. Für längere Fristen werden die Museumsdaten derzeit nicht aufbewahrt, da sie sich in imdas pro nicht mehr nutzen lassen würden, sobald sich dessen Datenbankschema geändert hat. Stattdessen wird überlegt, in der ExpoDB die XML-Daten zu archivieren, die auch ohne Datenbankmanagementsystem langfristig interpretierbar bleiben.

Wie der Datenabruf funktioniert die Auslieferung von Medien über eine URL. Obligatorischer Parameter ist dabei lediglich die imdas-pro-ID, um den Objektsatz zu bestimmen, zu dem ein Medium angefordert wird. Gibt es mehrere Bilder zu einem Datensatz, so wird das erste ausgeliefert, sofern nicht durch den Parameter "pos" ein anderes angefordert wird. Mit einem weiteren Parametern "h", "w" oder "d" kann Höhe, Breite bzw. das Maximum von Breite und Höhe spezifiziert werden. Die Bilddateien werden dann auf dem Server on-the-fly entsprechend skaliert.

Die Auslieferung von PDFs oder anderen Medienformaten wird auf ähnliche Weise angeboten, wie auch bei den Bildern wird im Response der entsprechende Mime-Typ gesetzt.

Bislang nutzen die Museen pragmatische Methoden, um in imdas pro zu markieren, welche Bilder zur Veröffentlichung über die ExpoDB vorgesehen sind. Dazu fügen sie der Bildbezeichnung des sog. Medienobjekts Tags wie zum Beispiel "[Digitaler Katalog=2]" bei, wobei die Nummerierung die Position in der Folge der angebotenen Bilder bezeichnet. Man könnte ähnliche Festlegungen auch über das Publikumshäkchen sowie das vorhandene Reihnungsfeld in imdas pro machen. Wo Bedarf nach unterschiedlicher Nutzung eines Bildes in unterschiedlichen Kontexten besteht, dürfte allerdings die pragmatische Methode flexibler sein.

Für Agenturen, die die Schnittstelle implementieren wollen, ist diese in der ausführlichen Spezifikation zu expo.digest beschrieben.

Bildauslieferung mit Cantaloupe

Für die Lieferung von Bildern in einen Digitalen Katalog wird ein Cantaloupe IIIF-Server zur Verfügung gestellt. Dieser kann sehr performant Vorschaubilder oder Ausschnitte aus den jeweiligen Objektbildern ausliefern. Über die Funktion zur Lieferung von Ausschnitten in verschiedenen Auflösungen kann eine zoombare Ansicht mit einem IIIF-Viewer wie OpenSeaDragon realisiert werden, wie er in expo.media eingebunden ist. Darüber hinaus lassen sich auch Vorschaubilder direkt von Cantaloupe einbinden. Beispielsweise bezieht die "Sammlung Online" unseres Pilotkunden für Cantaloupe, den Städtischen Museen Freiburg, sämtliche Bilder in der Objektliste sowie dem "Streifen" unten auf der Startseite direkt von Cantaloupe.

Die vollständige Spezifikation für IIIF 2.0 ist unter https://iiif.io/api/image/2.0/ zu finden. Ein Viewer wie OpenSeaDragon liest dabei die Metadaten aus info.json (z.B. https://expodelivery.bsz-bw.de/iiif/2/smf_85d49269-4caf-43b0-976f-bc9ce89e410d/info.json) und entscheidet dann, welche Kacheln in welcher Auflösung benötigt werden, um den vom Benutzer gewünschten Ausschnitt anzuzeigen. (Beispielobjekt: Messel-Specht)

Für ein Vorschaubild von z.B. maximal 100x100 Pixeln kann aber auch direkt eine entsprechend skalierte Version von Cantaloupe angefordert werden: https://expodelivery.bsz-bw.de/iiif/2/smf_85d49269-4caf-43b0-976f-bc9ce89e410d/full/!100,100/0/default.jpg. Die Zeit für ein solches Bild ist fast ausschließlich von der Größe des Ergebnisses abhängig, d.h. solche Vorschaubilder werden sehr schnell ausgeliefert, unabhängig davon wie groß das Original ist. Das komplette Bild als JPEG in voller Auflösung (z.B. https://expodelivery.bsz-bw.de/iiif/2/smf_85d49269-4caf-43b0-976f-bc9ce89e410d/full/full/0/default.jpg) hat eine Ladezeit von 15-30 Sekunden je nach Größe, wenn noch nicht im Cache von Cantaloupe vorhanden. Um den Ressourcenverbrauch durch große Bilder zu reduzieren, ist die maximale Anzahl Pixel eins Ergebnisbildes begrenzt (derzeit 10M Pixel, also z.B. ~2000x5000 oder ~3000x3000).

Der IIIF-Endpoint des BSZ ist https://expodelivery.bsz-bw.de/iiif/2/; der Identifier besteht aus dem Museumskürzel, Unterstrich, und der ID des Bilds (z.B. smf_85d49269-4caf-43b0-976f-bc9ce89e410d). Die Bild-IDs werden im JSON-File aus der expoDB ausgeliefert. Für Bilder aus der Medienbereitstellung ist die ID die Submaster-UUID, oder ersatzweise die Master-UUUID wenn in der Aggregation kein Submaster vorhanden ist. Für Bilder auf dem MusIS-Laufwerk Z ist es die IMDAS ID des Medienobjekts (nicht mit der des Museumsobjekts zu verwechseln!). Die resultierenden IDs sind also Case Sensitive, bestehen aus den Zeichen 0123456789abcdefABCDEF- und sind bis zu 36 Zeichen lang. Insbesondere sind es nicht immer gültige UUIDs. Beispiele: 85d49269-4caf-43b0-976f-bc9ce89e410d, FA0F5CFC459242638D5F38AB8F214DCC, 370780. Die letzte Form, mit kurzer nummerischer ID, kommt nur vorübergehend vor, bevor ein Objektbild eine dauerhafte ID erhält.

  • Keine Stichwörter