Ich entschuldige mich schon vorab, dass die Slides ein bisschen gemischt sind sprachlich. Manche haben englische Anteile, manche sind deutsch. Das liegt daran, dass die Inhalte aus verschiedenen Quellen von mir nochmal zusammengestellt wurden jetzt für die heutige Veranstaltung.

Triple IF, das wunderbare lange kurze Akronym International Image Interoperability Framework heißt es, bezeichnet eine Technologie, die dazu gedacht ist, die dazu dient, Bilder, Digitalisate von Objekten im Internet interoperabel bereitzustellen und das sehr komfortabel zu tun.

Ich gehe jetzt die halbe Stunde ein bisschen an Beispielen entlang und beschreibe auch die Theorie, die Technik hinter Triple IF und bin danach gerne im Jitsi-Raum noch ansprechbar.

Da kann man vielleicht per Screensharing oder so auch noch ein bisschen den Hands-on-Charakter wiederbeleben und ein bisschen zeigen, wie sich Triple IF in der Praxis anfühlen kann. Sie kennen alle diese Situationen, ganz typisch.

Kultureinrichtungen überall auf der Welt verwenden ihre Repositorien, um Images, um Bilder und die entsprechenden Metadaten zu speichern und ihn dann eben in ihren institutionellen Web-Oberflächen zu präsentieren, zu zeigen.

Und ja, es gibt dann einige Einrichtungen, viele Einrichtungen inzwischen, die sich denken, die sehr eracht haben, Digitalisierung. Das muss nicht nur bedeuten, dass ich die Objekte online zeige, dass andere die betrachten können online, sondern dass digitalisierte Objekte im Netz auch in neuen Kontexten eingebunden werden können,

dass mit ihnen gearbeitet werden kann, dass es nicht nur das reine Präsentieren, das Anschauen der Objekte gemeint sein muss. Und aus diesen Gedanken heraus sind eben die Triple IF, APs, die Schnittstellen entstanden,

die es ermöglichen, Digitalisate und zumindest im Groben die Strukturdaten, Metadaten, wäre es vielleicht ein bisschen verfänglich, wenn ich das sagen würde, einrichtungsübergreifend verfügbar zu machen über solche Schnittstellen.

Die Community um diese Technologie-Standards ist inzwischen sehr groß. Ich erspare mir jetzt hier einzelne Einrichtungen zu nennen. Wenn Sie das interessiert, dann schauen Sie auf www.if.io.community eine wirklich beeindruckende Liste internationaler Einrichtungen.

Auch inzwischen eine ganze Reihe Einrichtungen aus Deutschland oder aus dem deutschsprachigen Raum sind dort mit aufgelistet. Ich habe diesmal meinen Vortrag ein bisschen umgedreht und will zuerst mit den Beispielen beginnen und danach die Technik erklären. Ich bin mal gespannt, wie gut das diesmal funktioniert.

Ich handele hier mich jetzt an ein paar konkreten Anwendungsbeispielen von Triple IF entlang und werde Ihnen da versuchen, ein bisschen zu erklären oder erst mal zu demonstrieren, wie das eigentlich funktioniert, um dann im Nachhinein die Technik noch ein bisschen zu erklären.

Nur diese eine Folge jetzt zum Einstieg in die Demos. Es könnte sein, dass mir die Begriffe Kollektion und Manifeste immer mal rausrutschen. Das sind die Begriffe, die für die wichtigste, glaube ich, Schnittstellendefinition,

die Presentation API besonders relevant sind. Die bezeichnen eben die Daten, die die Kollektionen repräsentieren und die Manifeste beschreiben die eigentlichen digitalisierten Objekte mit ihren Strukturinformationen,

während dann als dritter wichtiger Punkt die Image API die tatsächlichen Bildquellen, also die Pixelquellen beschreibt. Los geht's mit dem ersten Beispiel, der Papyrus evas,

ein Objekt, das sich hier in der Universitätsbibliothek in Leipzig befindet. Es handelt sich dabei um eine Schriftrolle aus dem alten Ägypten über dreieinhalbtausend Jahre alt, die über 800 medizinische Behandlungsverfahren beschreibt. Und diese Rolle, die wurde aus konservatorischen Gründen zerschnitten irgendwann

und die einzelnen Teile in Glasplatten eingeklebt. Und wir haben diese Schriftrolle digital restauriert und dann als eines unserer ersten Objekte per triple IF bereitgestellt.

Und was ich Ihnen jetzt zeige, das ist die Image API-Funktion, ist also sehr schön möglich jetzt in diesem doch recht großen Digitalisat zu scrollen, zu zoomen und sich die Details genau anzuschauen.

Das alles funktioniert eben, wie gesagt, über die triple IF Image API. Und bei dem Beispiel möchte ich Ihnen gleich noch eine zweite Funktion zeigen, nämlich die Möglichkeit, Annotationen für Digitalisate zu hinterlegen. In dem Fall sind das die Übersetzungen der medizinischen Behandlungsverfahren,

die sich die Nutzer und Nutzerinnen hier auf der Web-Oberfläche anschauen können. Das ist, glaube ich, ein recht schönes Beispiel dafür, wie man diese Image API benutzen kann.

Das Digitalisat selbst 145.000 Pixel breit und knapp 3000 Pixel hoch ist tatsächlich eine riesige Datei, die wir so auf dem Server liegen haben und die dann eben in Teilen über die entsprechende Anwendung, über den entsprechenden triple IF Server bereitgestellt wird.

Das zweite Beispiel, und jetzt kommen wir, glaube ich, zu den wirklich spannenden Eigenschaften von triple IF, betrifft ein weiteres Objekt, nämlich den Codex Sinaiticus. Das ist eine Bibel-Handschrift aus dem vierten Jahrhundert. Und dieses Werk ist deshalb so bedeutend,

weil es als die früheste Bibel-Handschrift gilt, die das neue Testament enthält. Es ist jetzt aus historischen Gründen so, dass diese Bibel-Handschrift über vier Einrichtungen verteilt ist.

Die British Library, die Universitätsbibliothek in Leipzig und die Nationalbibliothek in St. Petersburg sowie das St. Keschwins Monastery in Ägypten. Das wäre also ein tolles Beispiel für triple IF. Ist im Moment noch nicht per triple IF eingerichtet,

außer den Leipziger Plättern. Die sind inzwischen per triple IF verfügbar. Es gibt aber eine ähnlich bedeutsame Handschrift, die etwa gleich alt ist und auch diese Texte schon enthält, die im Vatikan zu finden ist.

Und nun ist es so, dass sowohl die Leipziger Plätter als auch die Digitalisate aus dem Vatikan per triple IF verfügbar sind. Und das macht es möglich. Und hier kommt dieser Interoperability Aspekt von triple IF zum Tragen, dass man in einer geeigneten triple IF basierten Arbeitsumgebung,

wenn man die entsprechenden Verknüpfungen sich herausgesucht hat in den Katalogen, die Digitalisate zusammenziehen kann und dann in der Oberfläche diese beiden Objekte als Forschendorfer vergleichen kann.

Das geht nicht nur mit zwei Objekten, da kann man auch viel mehr Objekte reinladen und dann auch später Annotationen hinterlegen und so weiter. Und der technische Aspekt, auf den es mir eben ankommt, ist, dass diese Bilder nicht vorab zusammengebracht werden müssen, die müssen nicht kopiert oder transferiert werden,

sondern in dem Moment des Auffindens des Links zu der triple IF-Quelle ist es möglich für den Forschenden, diese Daten spontan und virtuos in einer gewissen Weise in seine Oberfläche zu laden und zu vergleichen.

Es gibt noch andere tolle Beispiele, die ich kurz zeigen möchte. Hier haben wir eine Handschrift, die das Schicksal erlitten hat, dass die Illumination herausgeschnitten wurde. Das ist ein Beispiel aus Frankreich. Und hier haben wir eine Möglichkeit zur Demonstration,

wie das ausgeschnittene Bild und das Bild der eigentlichen Handschrift per triple IF zusammengefügt werden können. Man kann hier schön, das kommt dann später noch in einem Technikteil, sehen, dass diese beiden Bildteile tatsächlich von verschiedenen Bild-Servern

bereitgestellt werden und über diese Manifest-Datei hier zusammengeführt werden zu einer einheitlichen Ansicht. Noch ein weiteres Beispiel hier für die Möglichkeit, Bilder auch zu überlagern,

wenn also in einem Manifest beispielsweise, also in einer, in der Beschreibung eines solchen digitalen Objektes, die digitalisat entsprechend verzeichnet sind, dann ist auch möglich, die Bilder direkt zu überlagern, wenn man zum Beispiel verschiedene Aufnahmen eines Werkes, also eines Objektes hat, fotografisch vielleicht

oder Röntgen oder Infrarotaufnahmen oder was da an den Stellen möglich ist. Das kann ich mal ganz kurz hier auch live zeigen. Man kann dann die verschiedenen Layer hier einschalten und die Transparenz beispielsweise ändern.

Das sind Dinge, die man mit triple IF eben nicht nur in einer speziellen, für einen Anwendungsfall programmierten Art und Weise umsetzen kann, sondern in einer generischen, systematischen Weise, die dann auch für andere nachnutzbar ist. Im Handschriftenkurs in der UBI Leipzig beispielsweise,

haben wir einmal mit einer triple IF Arbeitsumgebung experimentiert. Infrastrukturell ist das natürlich, ja, erfordert das gewisse Voraussetzungen, sowas systematisch anzubieten. Aber wir hatten es einmal in einem begrenzten Rahmen konkret im Einsatz und haben da auch die Annotationsmöglichkeiten eingesetzt.

Die Teilnehmenden des Handschriftenkurses hatten da die Möglichkeit, Digitalisator aus unterschiedlichen Quellen, aus unterschiedlichen Einrichtungen unter dieser einen Oberfläche zu sehen, zu annotieren, die Annotationen miteinander zu sharen.

Was bei den triple IF Events auch immer gerne gezeigt wird, fällt unter den Begriff Fun with triple IF. Also man muss nicht nur die hochbedeutsamen wissenschaftlichen und erforschungsrelevanten Anwendungen sehen. Man kann auch mit dieser Technologie hübsche und verspielte Sachen machen.

Vielleicht kann man es auch Kunst nennen, was man mit dieser Technologie anstellen kann. Ich bin hier ganz unverschämt und zeige zwei kleine Beispiele, die ich selbst in meiner Freizeit mal programmiert habe in den letzten Jahren. Hier beispielsweise die Anwendung Anklitz Ninja,

die Gemälde aus verschiedenen Museen weltweit verarbeitet hat und per Face Detection die Gesichter in den Gemälden erkannt hat. Und ist dann diese spielerische Anwendung entstanden, die es ermöglicht, die Gesichtspartien zu neuen Portraits zu kombinieren.

Unter Anklitz Ninja kann man sich das auch selbst anschauen. Oder hier die Anwendung Cover Boutique, die es ermöglicht, sich kleine Bastelvorlagen für Smartphone Hüllen mit triple IF Bildquellen zu erstellen.

Das ist auch eine Anwendung, die ich selbst geschrieben habe. Mit meiner Tochter übrigens, das war deren Idee. Wenn Sie uns ein Gefallen tun wollen, dann folgen Sie uns ruhig auch auf Cover Boutique App, so viel Zeit muss sie jetzt sein.

Gut, jetzt komme ich ein bisschen zur Technik, zum technischen Hintergrund dieser ganzen Technologie. Der triple IF Standard beschreibt derzeit insgesamt vier APIs, vier Schnittstellensprachen. Ich glaube, die wichtigste ist die Presentation API,

die, wie ich schon eingangs sagte, eben die Kollektionen modelliert und dann die eigentlichen Objekte in den Manifesten beschreibt. So kann sowas zum Beispiel aussehen. Das ist eine Kollektion, die hier zu sehen ist.

Vom Type Collection kann man hier sehen. Und diese Kollektionen, die sind hierarchisch schachtelbar. Das heißt, ich kann hier in der Kollektion wieder auf weitere Unterkollektionen verweisen. An irgendeinem Punkt ist es dann so, dass die Kollektion auch Manifeste,

also die Beschreibungen der einzelnen Objekte, verweist. Und in diesen Objekten stehen dann die eigentlichen Daten zum Objekt. Wobei in diesen Manifesten das sogenannte Shared Canvas Data Model eingesetzt wird.

Das bedeutet, dass die Seiten zunächst mal im Datenmodell angelegt werden und die eigentlichen Digitalisate, die Bilder, die sind dann schon als Annotationen auf diese Seiten modelliert. Daher ist es zum Beispiel auch möglich, verschiedene Inhalte auf diesen einen Canvas zu bringen.

Also wie wir vorhin im Beispiel gesehen haben, verschiedene Bilder, verschiedene Digitalisate, fotografische oder auch mehrere verschiedene fotografische Aufnahmen, die vielleicht zu unterschiedlichen Zeitpunkten gemacht wurden. Ebenso wie Annotationen im Sinne von Texten, die hinterlegt sein können.

Das können beschreibende, kommentierende Texte sein oder eben zum Beispiel auch OCR-Texte und solche Dinge. Da ist der Standort komplett offen und schränkt die Anwendungsbeispiele eigentlich kaum ein.

In den Manifesten selbst gibt es dann typischerweise, was ich zeige, sind immer so ein bisschen die typischen Fälle, wie ich sie aus meinen Anwendungsbereichen kenne. Da gibt es dann einen Punkt, zum Beispiel diesen Service-Block, der dann über seine ID auf die Bildquelle, nämlich auf die Image-API-Schnittstelle verweist.

Was ich an dieser Stelle nochmal sagen muss, ich glaube, das habe ich noch nicht so explizit zum Ausdruck gebracht, ist, dass diese IIIF-APIs alle auf den Grundlagen von linked data beruhen.

Das heißt, die IDs der verschiedenen Angaben sind immer auch URIs und können im besten Fall per HTTP auflösbar sein. Und so ist das eben hier auch der Fall bei dieser Schnittstelle zur Image-API,

die dann die eigentlichen Bildinhalte zugänglich macht. Entschuldigung, es ist mir etwas runtergefallen. So. Wenn man so eine Image-API-Schnittstelle anfragt, dann bekommt man typischerweise auch so eine JSON-Information zum Bildsdigitalisiert.

Da gibt es dann Informationen zum Inhalt, zur Auflösung und eben auch zu den Features, die der jeweilige Image-API-Server anbietet. Und über diese Features und über die Nutzung der Image-API ist es dann möglich, eben nicht nur das volle, einfache, hochauflösende Digitalisat zu bekommen,

sondern sich auch gleich Ausschnitte aus dem Digitalisat liefern zu lassen in verschiedenen Auflösungen. Und je nachdem, wie ausgefeilt dann die jeweilige Implementierung des Image-Servers ist,

kann ja dann auch die Bilder schon vorab für die Anwendung drehen und skalieren. Das ist also eigentlich für einen Anwendungsentwickler, der mit diesen Digitalisaten arbeiten möchte. Wunderbar, wenn er nicht die großformatigen Bilder selbst in seiner Anwendung laden, verarbeiten, skalieren muss,

sondern wenn er den Bildserver direkt nach den jeweiligen Daten einfach direkt per API fragen kann. Das finde ich immer sehr angenehm. Um diese Möglichkeit, um diese Funktion möglichst komfortabel und performant bereitzustellen,

ist es üblich, die Bilder vorzuberechnen, in sogenannte Pyramiden-Dateien zu konvertieren. Das heißt, die Bilddaten liegen in verschiedenen Auflösungen und in verschiedenen Kachelunterteilungen schon in der Datei vor.

Dafür kann man TIFF oder JPEG 2000 nehmen. Es gibt inzwischen eine ganze Reihe von Open Source-Anwendungen, aber auch kommerzielle Programme, die derartige Dateien herstellen können. Ja, noch einmal ein Hinweis zum Hintergrund Link Data und auch der Verknüpfbarkeit eben dieser Daten mit anderen Datenquellen.

Hier ein kleines Beispiel aus der vorhin gezeigten Software Antlitz Ninja, die zum Beispiel die erkannten Gesichter, die per Face Detection erkannten Gesichter hier als Annotationen verzeichnet hat

und dann markiert, in welchem Bereich des Digitalisats ein Gesicht erkannt wurde. Das nur mal auch um ein Beispiel zu bringen, das nicht den typischen Standardfall der Annotation im Sinne eines Kommentars oder einer Bemerkung zeigt, sondern der auch eine andere Anwendung mal vorführt.

Um Digitalisate nach IIIF auch wirklich nutzen zu können, gibt es inzwischen verschiedene Anzeige, also Viewer-Software. Ich glaube, zu Recht an erster Stelle kann man hier den Mirador-Viewer erwähnen, der sich durch einige besondere Funktionen auszeichnet.

Er kann eben, wie auch vorhin in den Beispielen gezeigt, mehrere Digitalisate parallel anzeigen und je nachdem, ob man die Version II oder III verwendet, ist es möglich, Annotationen anzulegen, zu speichern, die Bilder zu drehen

oder mit verschiedenen Bildverarbeitungsmethoden direkt im Viewer nochmal zu verändern. Da sind also die Funktionen sehr breit. Es gibt auch den Universal Viewer, der sehr populär ist und an vielen Stellen eingesetzt wird. TIFFI ist eine Entwicklung der SUB Göttingen, ein sehr leichtgewichtiger

und sehr peppermenter Viewer für IIIF-Digitalisate oder KITOTO-Presentation beispielsweise, das ja auch zum Beispiel für den DFG-Viewer eingesetzt wird, unterstützt inzwischen die Anzeige von IIIF-Digitalisaten. Wer Software selbst entwickeln möchte, der kann beispielsweise auf Open Seat Dragon oder Open Layers zurückgreifen.

Diese Frameworks oder Libraries, die unterstützen das Anzeigen von IIIF-Digitalisaten direkt. Im Idealfall übergibt man denen dann einfach nur den Endpunkt zur Image API und dann können die das digitale Satz selbst anzeigen.

Ja, an der OB Leipzig verwenden wir zurzeit noch die Software Kakadu. Ich überspringe, das ist ein Business zu kommen, plex glaube ich für die letzten Minuten, die mir noch zur Verfügung stehen. Aber ein Hinweis auf die Open Digitization Policy, die wir im Rahmen auch der Umsetzung von IIIF gewählt haben,

möchte ich gerne noch hier machen. Wir haben uns eben entschlossen, die Digitalisate, die sich auf gemeinfreie Werke beziehen, unter CC0 oder mit der CCPD-Mark zu veröffentlichen, sodass eine weitreichende Nutzung der Digitalisate auch möglich ist.

Das ist natürlich eine wunderbare Kombination mit dann der technischen IIIF-Schnittstelle, um die Nachnutzung der Digitalisate zu ermöglichen. Da gibt es auch ein kleines Werkstatt-Schaufenster, das man im Moment anschauen kann, um zu sehen, welche Digitalisate in jüngster Zeit in der Werkstatt verarbeitet wurden,

oder die Top-Level Collection für diejenigen, die hier mit softwaretechnischen Methoden sich unsere Bestände erschließen möchten. Die können hier den Einstieg in die Daten an oberster Ebene durchführen.

Noch ein paar Punkte für die Zukunft möchte ich erwähnen. Das Handschriftenportal, der eine oder andere von Ihnen hat vielleicht schon von diesem Projekt gehört. Vier Einrichtungen in Deutschland sind damit befasst, ein neues Portal für die mittelalterlichen Buchhandschriften zu schaffen.

Das basiert auf der IIIF-Technologie, zumindestens für die Anzeige, für die Interaktion zwischen Text und Bild und auch für die späteren, für spätere Phasen vorgesehenen Workspace-Funktionen soll IIIF die technische Grundlage darstellen.

Und einen anderen Hinweis möchte ich auch noch geben, nämlich, dass aktuell noch die IIIF-APIs in der Version 2 aktuell sind, aber schon seit längerer Zeit an der API-Version 3 gearbeitet wird, zumindestens für die Image. Die Presentation-API stimmt das und da werden sicherlich noch einige Veränderungen dann auf die IIIF-Welt zukommen,

wenn diese neuen Versionen tatsächlich in der Praxis eingesetzt werden. Ganz aktuell ist auch die Entwicklung, ich hatte es vorhin schon kurz erwähnt, von Mirador 3,

das ist also eine dieser besonders populären Viewer für IIIF, der nicht nur Multidokumenten fähig ist, sondern jetzt in der neuesten Version hier auch nochmal verstärkt Workspace-artige Umgebungen realisiert mit Fenstern, die vergrößert und frei verschoben werden können, also passieren spannende Dinge, die man sich auch selbst anschauen kann.

Wenn Sie daran denken, IIIF selbst zu implementieren, lege ich Ihnen diese Checkliste ans Herz. Wichtig sind da verschiedene technische Parameter bei der Veröffentlichung und klare Lizenzangaben sind wichtig,

ist noch nicht überall anzutreffen, dass man genaue Auskunft über die Verwendbarkeit von Digitalisaten erhält und auch die technische Verlinkung der Quellen auf den Katalog-Oberflächen finde ich persönlich immer sehr wichtig und komfortabel,

auch das ist nicht immer in allen Fällen gegeben. Schließen möchte ich mit zwei Veranstaltungshinweisen. Gleich in der nächsten Woche findet statt der sonst üblichen IIIF-Jahreskonferenz die IIIF-Week statt, das ist also ganz ähnlich hier wie die wunderbare VBIP 20 organisiert,

nur weil es noch ein stärker international orientierter Event ist, finden die Veranstaltungen die Web, die Videokonferenzen meistens nur in den Abendstunden statt, damit in Amerika und in Europa gleichzeitig teilgenommen werden kann,

kann ich sehr empfehlen dort mal vielleicht sich die eine oder andere Veranstaltung rauszusuchen und sich da mit reinzuhängen und zuzuhören. Und ich hoffe, dass im November diesen Jahres der IIIF-Outreach-Event, den wir mit organisieren,

auf der Mootech, der Fachmesse für Museums- und Ausstellungstechnik in Leipzig stattfinden kann, auch das ist ein Event, den ich empfehlen kann und würde mich freuen, wenn Sie bei Interesse sich für unsere Newsletter anmelden. Vielen Dank für Ihre Aufmerksamkeit. Hier nochmal die Links alle zusammen auf einer Seite, an denen Sie sich weiter informieren können

und wenn Sie Lust haben, dann gerne gleich jetzt im Anschluss im Jitsi Raum 3. Ja, vielen Dank. Ganz kurze Frage gibt es, zwei Minuten haben wir noch, eine Technikfrage.

Die Frage ist, spielt das Grafik-Container-Format.hike in Ihrem Bereich eine Rolle? Wie heißt das Punkt? Hike? H-I-K-H-E. Sagt mir spontan gar nichts. Also eher nein. Würde ich mir aber mal anschauen.

Muss mir dann nochmal angucken, wie es genau beschrieben wird. Hab ich jetzt nicht rausgehört. Sagt mir aber nichts. Und eine weitere Frage, gibt es eine Anleitung zur Installation von Jopla App auf Linux-Server? Ziel ist es, eine eigene Service-Instanz zu installieren und diese in unserem Digitalisierungswerkportal im Netz zur Verfügung zu stellen?

Tatsächlich gibt es, habe ich im Dezember vorigen Jahres, diesen Hands-on-Workshop, der hätte eigentlich auch stattfinden sollen.

So einen Hands-on-Workshop habe ich da schon mal gehalten, nämlich auf der Swip. Die Folien davon sollten im Internet zu finden sein und die führen Schritt für Schritt durch eine Möglichkeit, wie man AAAF installieren kann. Es gibt, wie gesagt, ganz viele unterschiedliche Software-Produkte, die AAAF-Dienste implementieren.

Und da muss man auch ein bisschen schauen, welche Software den eigenen Vorgaben infrastruktureller Art und auch dem Anwendungsfall entspricht. Aber da ist vielleicht eine Sache, die wir im Nachhinein nochmal besprechen könnten.

Da würde ich darum bitten, dann vielleicht nochmal auf mich zuzukommen und das vielleicht im Detail zu besprechen.