Iiif

MPDL,Digitization Lifecycle

Hintergrund
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 Zeit-Indices der Ressourcen, die in diesem Fall hinzukommen) sind in Vorbereitung.

Für uns zentral ist schließlich noch die sog. "Presentation API": Hier ist beschrieben, wie Metadaten angeboten werden, die zum kontextuellen Aspekt einer Präsentation der Bildressourcen gehören. Dies betrifft z.B. 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. Die Beschreibung ist in diesem Falle eigentlich nicht die Beschreibung der API eines Servers, sondern hauptsächlich eines Dateiformats, des sogenannten Manifests.

Ich habe testweise einen Server aufgesetzt, um zu simulieren, wie ein institutioneller iiif-Service aussehen könnte. Fürs erste habe ich aber nur eine Sammlung Bilder hochgeladen, nämlich eine Reihe von Werken aus dem Salamanca-Projekt. Ich habe die Software "digilib" verwendet, die am MPI für Wissenschaftsgeschichte in Berlin entwickelt wird; diese liest Bilddateien aus einem konfigurierbaren Verzeichnis und stellt sie gemäß der iiif-Spezifikation zur Verfügung. Konkret habe ich auf der Maschine, auf der dieser Server liegt, die Dateien in  (erste Seite im ersten Band des Werkes W0013) usw. gelegt, mit weiteren Werken unter  (Werk W0004) usw. Digilib wertet die Verzeichnis-Hierarchie aus und stellt die Bilder und Informationen gemäß iiif image API unter URLs wie den im Folgenden genannten zur Verfügung.

Image API
http://141.5.104.131:8080/digilib/Scaler/IIIF/svsal§W0013§A§W0013-A-0017 (im folgenden mit  bezeichnet, die '§' übersetzen die Ebenen-Übergänge der Verzeichnishierarchie)

Diese Adresse leitet weiter auf eine Datei, 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, indem man eine Anfrage mit genauer definierten Parametern sendet. So folgt hier eine Anfrage nach dem vollen Bild (das erste "full") in der vollen Auflösung (das zweite "full"), nicht rotiert ("0") im jpg-Format:



Oder 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, im png-Format:



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

Das funktioniert so weit schon mit allen Bildressourcen, die dafür lediglich in das in der Konfiguration festgelegte Verzeichnis  gelegt werden mussten.

Manifest API
Für uns ist aber auch interessant, dass auf der Grundlage der iiif-Standards beschrieben werden kann, wie verschiedene Bilder (zu einem Werk) zusammen gehören. Insbesondere ist interessant, dass der digilib-Server so ein Manifest, das eben ein ganzes Werk mit vielen Seiten repräsentiert, automatisch anhand der Verzeichnishierarchie im Dateisystem und den Dateinamen erstellt:

http://141.5.104.131:8080/digilib/Manifester/IIIF/svsal§W0015

und

http://141.5.104.131:8080/digilib/Manifester/IIIF/svsal§W0106 (für ein Werk, von dem wir bislang neben den Bilddateien noch keine weiteren Informationen in unserer Db erfasst haben)

Wie für solche automatisch erstellten Manifeste nicht anders zu erwarten, sind dort Metainformationen, die nicht in Datei- und Verzeichnisnamen und -Hierarchie enthalten sind (z.B. Titel und Autor), eben nicht enthalten. Allerdings können wir diese Manifest-Datei leicht einlesen und mit Informationen aus der "Salamanca-Db" aufbessern.

Die folgende URL richtet eine Anfrage an den Salamanca-Test-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, wobei die Bilder 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.

http://141.5.106.211:8080/exist/apps/salamanca/en/iiif-out.xql?wid=W0015 (im Vergleich zu oben ein um Titel usw. angereichertes Manifest)

http://141.5.106.211:8080/exist/apps/salamanca/en/iiif-out.xql?wid=W0013 (ein Manifest, das sich auf ein mehrbändiges Werk bezieht und daher neben Metainformationen zum übergeordneten Werk zwei weitere Manifeste für die Teilbände enthält.)

Ein denkbares Ziel ist nun, den digilib automatisch Manifeste als Vorlage erstellen zu lassen, diese manuell (oder durch eine Db-Anwendung wie die Salamanca-App) aufzubessern und dann als verbessertes Manifest wieder im Digilib abzulegen, und diesem dann mitzuteilen, dass er bei Vorliegen einer solchen Datei diese einer automatisch zu erstellenden Manifestdatei vorziehen soll. Da ist noch etwas Arbeit nötig, aber im Grunde ist das meiste vorgezeichnet ...

Viewer
Damit sind die Bilder 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 vor allem von den Univ. Libraries in Harvard und Stanford) und der Universalviewer (entwickelt vor allem von der British Library und Digirati). Digilib hat auch einen Viewer, aber den lassen wir mal beiseite...

Man kann also jetzt auf die Mirador Demo-Seite gehen und mit dem Kachel-Icon (das zweite Icon oben links in jedem der beiden Fenster) ein neues Objekt hinzufügen, wobei man im anschließenden Bildschirm rechts oben eine Manifest-URL 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://141.5.106.211:8443/exist/apps/salamanca/en/iiif-out.xql?wid=W0015

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

Nun kann man aber zwar die Auswahl und Inbetriebnahme eines geeigneten Viewers theoretisch dem Benutzer überlassen, aber normalerweise bietet man ja 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 gemacht.

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


 * http://141.5.106.211:8080/exist/apps/salamanca/en/mirador.html?wid=W0015
 * http://141.5.106.211:8080/exist/apps/salamanca/en/mirador.html?wid=W0004
 * http://141.5.106.211:8080/exist/apps/salamanca/en/mirador.html?wid=W0002

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

Und ich habe diese Mirador-Konfiguration auch in unsere Leseansicht eingebunden. Wenn man also auf dem Testserver das Werk W0015 aufruft und dort auf eine Seitenzahl klickt, öffnet sich ein Fenster in dem der Mirador Viewer seine Dienste tut und die angeklickte Seite anzeigt. Dort kann man endlich auch im Viewer durch die Seiten blättern:

http://141.5.106.211:8080/exist/apps/salamanca/en/work.html?wid=W0015

(Damit das funktioniert musste ich im Moment das anzuzeigende Element provisorisch berechnen. Diese Berechnung verwendet einen hart einkodierten Offset-Wert und so stimmt es bei W0015 zwar, liegt aber bei W0004 um fünf Seiten daneben und für mehrbändige Werke funktioniert sie noch gar nicht. Auch hier ist aber relativ klar vorgezeichnet, wie das unaufwändig "in the right way" zu lösen ist.)

Was hier noch fehlt
1. Im Moment fehlt bei der Lösung in der Salamanca-Leseansicht noch eine Möglichkeit, nach dem Blättern im Viewer die Textansicht zu synchronisieren. In die eine Richtung geht es: Ich habe den Viewer offen, scrolle in der Leseansicht aber weiter und will den Viewer auf die nun aktuelle Seite der Leseansicht aktualisieren -> Mit einem Klick auf die Seitenzahl in der Leseansicht. Umgekehrt geht es aber noch nicht: ich habe Leseansicht und Viewer offen und blättere im Viewer, dann will ich die Leseansicht an die entsprechende Seite scrollen, z.B. mit einem Klick auf das Bild-Digitalisat oder auf ein Extra-Icon im Viewer. Da bin ich noch dran. (Ich glaube nicht, dass ein zwangs-synchronisiertes Scrollen/Blättern von den Benutzern wirklick gewünscht und auch nicht, dass es leicht zu implementieren ist.)

2. Zweitens will ich mich um eine Möglichkeit kümmern, den Digilib-Server wie oben beschrieben Manifeste ausliefern zu lassen, die aufgebessert worden sind.

3. Wir sollten zu gegebener Zeit versuchen, die Möglichkeit auszunutzen, dass die iiif Presentation API vorsieht, Bereiche zur Navigation anzugeben. In unserem Falle sind das wohl meistens Kapitel, Unterkapitel, einzelne Artikel usw. Hier ist noch etwas Bewegung im Standard und in der Implementierung auf Seiten der Viewer. Ein schönes Beispiel kann man hier sehen: http://www.llgc.org.uk/llyfrycofio Das Problem scheint hauptsächlich darin zu bestehen, dass der Standard im Moment mehrere Deutungen zulässt und die verschiedenen Viewer jeweils nur eine, aber eben voneinander abweichende Deutung interpretieren können. Eine striktere Lösung auf Seiten des Standards ist in Vorbereitung und wird wohl im Laufe des nächsten Jahres mit der iiif Presentation API 3.0 festgelegt.

4. Hier ist noch gar nicht über Annotationen und Linked Data diskutiert worden. Das ist ein wichtiger Aspekt, auf dem iiif besondere Stärken zeigt.

Schluss
Eine Neuauflage von DLC sollte m.E. nicht an dieser Technologie "vorbei" entwickelt werden. Ich habe aber noch keinen konkreten Vorschlag bzw. sehe noch nicht, wie genau und in welcher Reichweite das eingebaut werden könnte/sollte. Vieles an DLC geht in einer bestimmten Hinsicht schon vollständig in so einem iiif-Arrangement auf, wie es hier beschrieben wurde; aber dabei gehen u.U. wichtige andere Aspekte verloren. (Welche?) Soll man die anders hinterher wieder "dranbauen" oder auf die Implementierung dieser Hinsichten verzichten?

Anderes (wie z.B. die Suche und die Authentifizierung) habe ich mir noch gar nicht angeschaut...

Links
Schöne Beispielseiten, die auf iiif, Mirador und/oder dem Universalviewer basieren:


 * mit Strukturdaten: Mirador, The Welsh National Book of Remembrance (hat eben nur langsam und dann unvollständig geladen)
 * mit Annotationen: Mirador eingebettet, E.T. Newell's Numismatic Notebook
 * mit Metadaten: Universalviewer eingebettet, Karte von Wales mit Handle-, Lizenz-informationen, Logo u.a. (rechts einblendbar)
 * Vatikanische Bibliothek, angepasster Mirador

Weitere Informationen:


 * Sehr gute Einführung in iiif bei digirati.
 * Blogeintrag über ein Projekt der BL, das iiif und Web-Annotation in einem Crowdsourcing-Ansatz verbindet.
 * iiif-Aktivitäten der Bayerischen Staatsbibliothek, die mit der SUB Göttingen eines der beiden einzigen deutschen Mitglieder des iiif-Konsortium ist.
 * Bericht vom Treffen der DINI AG Kompetenzzentrum Interoperable Metadaten (KIM) zum Thema iiif aus dem Mai 2017.