iiif in der Schule von Salamanca

Autor
Veröffentlicht am

Das iiif Consortium und die weitere iiif Community haben Standard-Protokolle definiert, wie man sie in der Darstellung von Bildressourcen benötigt. Die Protokolle sind als Beschreibungen von „Schnittstellen“ formuliert, d.h. es wird beschrieben, unter welcher Adresse, mit Hilfe welcher Parameter der Dienst eine bestimmte Funktion anbieten soll. In dieser Weise gibt es Beschreibungen von Zoom-/Rotations-/Ausschnitts-/Format-Konversions- und ähnlichen Diensten in der iiif image API, die aktuell in Version 2.1.1 vorliegt. Ferner Beschreibungen von Zugangsmanagement- und Authentifikationsservices sowie von Such-Funktionen in der Authentication API bzw. der Search API, beide jüngeren Datums und erst in der Version 1.0 vorliegend. Beschreibungen von Video- und Audio-Daten (z.B. für die in diesem Fall hinzukommenden Zeit-Indices der Ressourcen) sind in Vorbereitung.

Im Projekt „Die Schule von Salamanca. Eine digitale Quellensammlung und ein Wörterbuch ihrer juridisch-politischen Sprache“ erstellen wir eine Online-Edition von ca. 115 spanischen und lateinischen gedruckten Werken der spanischen Spätscholastik des 16. und 17. Jahrhunderts (und ein Wörterbuch, das zu den wichtigsten dieser Begriffe Auskunft gibt). Diese Online-Edition basiert auf TEI/XML-Dateien, die untereinander und mit dem Wörterbuch verknüpft sind und die in einer den modernen Lesegewohnheiten entgegenkommenden Weise dargestellt werden. Um die damit einhergehenden editorischen Eingriffe nachvollziehbar zu halten, sollen die Facsimiles der originalen Scans jederzeit einfach eingeblendet werden können. Zu Beginn des Projekts 2013/14 haben wir die Anzeige dieser Bilder demnach so entwickelt, dass diese als jpg-Bilddateien (in einer einzigen Auflösung) in einem (Apache-)Webspace der GWDG lagen und von dort durch einen Openseadragon-Viewer und eigentlich den Browser per HTTP GET geladen wurden. Die Erstellung von Ausschnitten, das Zoomen und Verschieben war durch den OSD-Viewer für den Benutzer bereits sehr komfortabel (z.B. mit dem Mausrad) möglich, geschah jedoch alles clientseitig und auf der Basis einer einzigen jpg-Datei (pro Buchseite). Was noch nicht möglich war, von uns aber als Desiderat gesehen wurde, war das Blättern durch die Facsimiles, was in der Konsequenz auch die Lektüre des ganzen Quellwerkes in einer Vollbildansicht der Facsimiles ermöglichen würde.

Im vergangenen Jahr haben wir beschlossen, die Bildanzeige auf iiif umzustellen. Die wesentlichen Komponenten dafür sind ein digilib-Server und ein Mirador-Viewer, den wir wie gehabt in unsere eXist-db-Webanwendung eingebunden haben. Dieser Blogbeitrag beschreibt die von uns in Anspruch genommenen Funktionalitäten der genannten Komponenten und wie sie, durch den iiif-Standard ermöglicht, ineinander geifen. (Die technischen Details der Implementierung im Rahmen unserer eXist-Webanwendung sind am besten in deren Quellcode nachzuvollziehen, v.a. in den Dateien templates/template_work.html, templates/template_mirador.html, sowie modules/iiif.xql.)

Server-Seite

Wir betreiben auf einem Cloud-Server des Max-Planck-Instituts für europäische Rechtsgeschichte einen digilib-Server (einstweilen noch im Testbetrieb) und auf einem anderen den eXist-db-Server des Salamanca-Projekts.

Image API

Auf dem Digilib-Server habe ich die Bilddateien des Projekts in /var/lib/iiif-files/salamanca/W0013/A/W00013-A-0001.jpg (erste Seite im ersten Band des Werkes W0013) usw. gelegt, mit weiteren Werken unter /var/lib/iiif-files/salamanca/W0004 (Werk W0004) usw. Digilib wertet nun schon automatisch die Verzeichnis-Hierarchie aus und stellt die Bilder und Informationen gemäß iiif image API unter URLs wie den im Folgenden genannten zur Verfügung:

https://c104-131.cloud.gwdg.de:8443/digilib/Scaler/IIIF/svsal!W0013!A!W0013-A-0017
(im folgenden mit {Ressource} bezeichnet. Nach der Zeichenkette /IIIF/ wird in dieser Adresse die Verzeichnishierarchie (innerhalb von /var/lib/iiif-files) wiedergegeben, die ‚!‘ übersetzen die Ebenen-Übergänge dieser Hierarchie.)

Eine Anfrage an diese Adresse wird auf eine Datei {Ressource}/info.json weitergeleitet, in der allgemeine Informationen über die angefragte Bild-Ressource wie etwa die Auflösung, die verfügbaren Bildformate, die angebotenen Funktionen (Ausschnitt, Rotation usw.) zu finden sind.

Ein richtiges Bild erhält man dann erst, indem man eine Anfrage mit genauer definierten, als weitere virtuelle Pfad-Angaben notierten, Parametern sendet. So sieht zum Beispiel eine Anfrage nach dem vollen Bild (das erste „full“) in der vollen Auflösung (das zweite „full“), nicht rotiert („0“) im jpg-Format („.jpg“) aus:

{Ressource}/full/full/0/default.jpg

Oder so sieht eine Anfrage nach einem Ausschnitt (angegeben durch die erste Reihe numerischer Koordinaten), in beiden Richtungen um 500% skaliert, also fünffach vergrößert, und um 30° gedreht, diesmal im png-Format aus:

{Resource}/400,100,100,100/500,500/30/default.png

Die gesamte Berechnung von Ausschnitt, Skalierung, Rotation und Formatkonversion geschieht hier nun durch den Server. Das heißt z.B., dass ein Bildbetrachter, der aufgrund einer Zoom-Operation einen Teil des Bildes vergrößert darstellen will, sich auf das Nachladen des relevanten Bildausschnitts in 200facher Vergrößerung beschränken kann, und dann auch nur diesen Ausschnitt übertragen bekommt und nicht etwa das vollständige Bild in maximaler Auflösung. Und jeder iiif-kompatible Bildbetrachter weiß durch den Standard definiert, mit welchen Parametern er seinen Bildserver anfragen muss, um den gewünschten Ausschnitt zu erhalten.

Das funktioniert beim Digilib-Server im iiif-Modus so weit schon mit allen Bildressourcen, die dafür lediglich in das in der Digilib-Konfiguration festgelegte Verzeichnis /var/lib/iiif-files (und eben in entsprechende Unterverzeichnisse) gelegt werden mussten.

Presentation API

Mit-entscheidend ist für uns allerdings auch noch die sog. „iiif Presentation API“ : Hier ist beschrieben, wie Metadaten angeboten werden, die zur Präsentation der Bildressourcen gehören. Dies betrifft z.B. den Titel des abgebildeten Werkes sowie die Reihenfolge, in der mehrere Bilder aufeinander folgen können und so gemeinsam ein Werk ausmachen (Seiten in einem Buch, verschiedene Ansichten eines 3D-Objekts, verschiedene Bilder einer kuratierten Ausstellung), die Bereiche und Unterbereiche, durch die man in der Sammlung von Bildern navigieren kann (z.B. Kapitel im Falle eines Buches), Attribution und Rechte, aber auch Annotationen der Bilder und Verweise zu weitergehenden Informationsquellen als Linked Data. Der iiif Standard ist in diesem Falle eigentlich nicht die Beschreibung der API eines Servers, sondern hauptsächlich eines Dateiformats, des sogenannten „Manifests“.

In so einem iiif Manifest kann eben beschrieben werden, wie verschiedene Bilder (zu einem Werk) zusammen gehören. Für uns ist nun insbesondere interessant, dass der digilib-Server so ein Manifest, das eben ein ganzes Werk mit vielen Seiten repräsentiert, automatisch anhand der Dateinamen und der Verzeichnishierarchie im Dateisystem erstellen kann:

https://c104-131.cloud.gwdg.de:8443/digilib/Manifester/IIIF/svsal!W0034

(Das letztgenannte W0034 beschreibt ein Werk, von dem wir bislang neben den Bilddateien noch keine weiteren Informationen in unserer Db erfasst haben. Dieses können wir nun durch das im Weiteren beschriebene Setup wenigstens zum Durchblättern anbieten, selbst wenn wir noch keinen Editionstext etabliert haben. So konnten wir unsere Werkliste tatsächlich so umstellen, dass über einen „Images“-Link bereits jetzt viel mehr Werke zugänglich sind als bloß diejenigen, die unseren Transkriptions- und Redaktionsprozess schon durchlaufen haben.)

Wie es für solche automatisch erstellten Manifeste auch gar nicht anders möglich ist, beinhalten sie keine Metainformationen, die nicht in Datei- und Verzeichnisnamen und -hierarchie enthalten sind (z.B. Titel, Autor, Lizenz). Allerdings können wir diese Manifest-Datei in unserem eXist-db Server nun leicht einlesen und mit Informationen aus der „Salamanca-Db“ aufbessern. Daher haben wir den eXist-db Server so eingerichtet, dass er gleichsam als Proxy vor dem iiif-Server sitzt, von diesem Manifeste abruft und sie – je nach Verfügbarkeit weiterer Daten aufgebessert oder unverändert – dann weitergibt.

Die folgende URL richtet also eine Anfrage an den Salamanca-Server und dieser gibt eine „verbesserte“ Manifest-Datei aus. Wie man sieht, gibt diese Datei hauptsächlich an, in welcher Reihenfolge die Erstellerin der Datei eine Reihe von Bildern angezeigt wissen will. Bemerkenswert ist dabei, dass die Bilder tatsächlich an einem ganz anderen Ort als das Manifest liegen können (also z.B. auf einem „MPIeR/MPDL/DLC“-iiif-image-Server und eben nicht auf dem „Salamanca“-Server, an den die Anfrage gerichtet wurde und der das Manifest vorhält), oder sogar an mehreren Orten. Im Netz finden sich Manifeste, die in einem Kontext die Bestände verschiedener Kulturerbeinstitutionen zusammenführen: kuratierte Sammlungen verschiedener Museen oder Bücher, deren Fragmente von verschiedenen digitalen Bibliotheken iiif-konform angeboten werden.

https://www.salamanca.school/iiif-out.xql?wid=W0034
(Im Vergleich zu oben dasselbe Werk, aber in einem um Titel usw. angereicherten Manifest)

Und während der Digilib-Server keine Manifeste für mehrbändige Werke erstellen kann – er liefert ein leeres Manifest aus, wenn die angefragte Adresse keine Bilddateien sondern nur weitere Unterverzeichnisse (für die Teilbände) enthält -, können wir so dazwischengehen und im eXist-db Server ein Sammlungs-Manifest erstellen, welches im Hintergrund die Teilband-Manifeste vom Digilib-Server lädt und zusammensetzt:

https://www.salamanca.school/iiif-out.xql?wid=W0013

(vgl. die reine Digilib-Ausgabe: https://c104-131.cloud.gwdg.de:8443/digilib/Manifester/IIIF/svsal!W0013)

Als einen weiteren Schritt sind wir aktuell damit befasst, die verbesserten Manifeste wieder auf dem Digilib-Server abzulegen und diesen dazu zu bewegen, sie, sofern vorhanden, anstelle neu zu erzeugender Manifeste auszuliefern. Damit würden wir zwar nicht für die Erstellung der „guten“ Manifeste, wohl aber für deren Auslieferung wieder unabhängiger vom eXist-db Server. Leider funktioniert das noch nicht ganz, vielleicht bedarf es aber nur eines Upgrades des Digilib auf die aktuellste Version. Im Moment können wir so ein verbessertes Manifest schon an einem Pfad wie /var/lib/iiif-files/W0034/W0034.txt ablegen, dann wird es durch Digilibs „Texter“-Servlet bei Anfragen an die folgende Adresse ausgeliefert:

https://c104-131.cloud.gwdg.de:8443/digilib/Texter/svsal/W0034

Problematisch sind an dieser Lösung noch der veränderte Pfad (es sollte ja idealerweise an derselben Aufrufadresse wie oben funktionieren) und die Tatsache, dass das „Texter“ Servlet die Datei als text/plain Mime-Typ und ohne encoding Header ausliefert. (Beide Punkte haben unterdessen geschlossene Tickets – Eins und Zwei – wir müssen nur dazu kommen, unsere Installation zu updaten.)

Client-/Viewer-Seite

Die Bilder sind nun also in geordneter Weise verfügbar, und jeder Viewer, der das iiif-Protokoll versteht, kann sie öffnen, wenn er das entsprechende Manifest lädt. Zwei der wichtigsten Viewer sind Mirador (entwickelt u.a. von den Univ. Libraries in Harvard und Stanford) und der UniversalViewer (entwickelt vor allem von der British Library und Digirati. Digilib liefert selbst auch einen Viewer mit, aber den lassen wir mal beiseite…

Man kann also jetzt z.B. auf die Mirador Demo-Seite gehen und mit dem Kachel-Icon (das zweite Icon oben links in jedem der beiden Fenster) und dann dem Befehl „Neues Objekt“ ein neues Objekt hinzufügen, wobei man im anschließenden Bildschirm rechts oben eine Manifest-URL wie z.B. unsere https://www.salamanca.school/iiif-out.xql?wid=W0034 einkopieren und das Manifest laden kann….

Im UniversalViewer kann man das Manifest auch schon über einen Parameter beim Aufruf gleich mitgeben:
http://universalviewer.io/uv.html?manifest=https://www.salamanca.school/iiif-out.xql?wid=W0034

Beide Viewer können eine Übersicht über alle Seiten und, wie vom Standard gefordert, die Metainformationen einblenden (bei Mirador über das i-Icon, bei Universalviewer über rechte Seitenleiste „<< More Information“).

Nun kann man zwar die Auswahl und Installation eines geeigneten Viewers theoretisch dem Benutzer überlassen, aber normalerweise bietet man ja mit einem Projekt selbst auch einen (Default-)Viewer auf der eigenen Seite an. Dafür ist es bei beiden genannten Produkten möglich, sie auf einer eigenen Seite einzubinden. Die BSB macht das z.B. auf ihren Seiten mit dem Mirador Viewer: https://app.digitale-sammlungen.de/bookshelf/ Und so habe ich es auch für unser Projekt gemacht.

Ich habe also eine Seite erstellt, auf der der Mirador Viewer in einer sehr basalen Konfiguration Werke nach Salamanca-Id anzeigt:

usw. (das benötigt beim ersten Aufruf u.U. einen Moment, bevor die Ressourcen geladen sind.)

Und dann habe ich diese Mirador-Konfiguration auch in unsere Leseansicht eingebunden. Wenn man also in der Salamanca eXist-Db-Webapp das Werk W0015 (Vitoria, Confesionario, jetzt ein anderes Werk, zu dem eben der Volltext und damit auch erst eine Leseansicht vorhanden sind) aufruft und dort auf eine Seitenzahl links neben dem Haupttext klickt, öffnet sich ein Popup-Fenster in dem über ein iframe die oben genannte Basis-Mirador-Seite eingebunden ist, und diese wird von der aufrufenden Seite mit anzuzeigendem Manifest und Bild konfiguriert. Dort kann man endlich auch im Viewer durch die Seiten unserer Werke blättern:

https://www.salamanca.school/en/work.html?wid=W0015

In unserer Instanz habe ich dann schließlich auch noch eine wechselseitigen Synchronisierung zwischen Facsimile- und Lese-Ansicht implementiert: Wenn in der Leseansicht auf eine andere Seitenzahl geklickt wird, wechselt die Bildanzeige im Mirador-Popup auf das entsprechende Fascimile. (Die anchor-Elemente in der Leseansicht enthalten ein data-canvas-Attribut, in dem für jede Seite die entsprechenden Kenn-Werte vorhanden sind, so dass eine Javascript-Funktion sie an die Mirador-Instanz weitergeben kann.) Umgekehrt kann man im Mirador-Viewer zwischen den Facsimiles blättern und wenn man dann auf den in unserem Mirador hinzugefügten „Sync“-Button klickt, fährt die Leseansicht an die entsprechende Textstelle. (Und zu allerletzt habe ich noch einen Link zum Download der gezippten Facsimiles des aktuellen Werkes in das Mirador-Menü eingebaut.)

Links

Weitere schöne Beispielseiten

Weitere Informationen

Angesichts der Informationen aus dem letzten Link und der Bemühungen auch den DFG-Viewer iiif-„fähig“ zu machen (finde den Link nicht mehr), und angesichts der Tatsache, dass iiif und das aktuell in den DFG Praxisregeln Digitalisierung geforderte Datenaustausch-Format METS/MODS, in gewisser Weise konkurrierende Formate sind, bin ich sehr gespannt, ob sich die zunehmende Verbreitung von iiif auch in „offiziellen“ Vorgaben und einer eventuellen Neuaflage der Praxisregeln niederschlagen wird…

Author

  • Andreas Wagner ist Philosoph und Berater für Digital Humanities. Er arbeitet seit 2013 für das Projekt "Die Schule von Salamanca" und beginnend im Januar 2017 für das Max-Planck-Institut für europäische Rechtsgeschichte in Frankfurt.

    Alle Beiträge ansehen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert