 Einen wunderschönen guten Morgen am Tag 4 des 34. Cars Communication Congress. Es freut mich, dass so viele von euch schon hier sind. Und wir legen auch gleich los, damit wir nicht gleich wieder in Verzug kommen. Mit mir auf der Bühne steht Leander Seige und er erzählt euch etwas zum Thema International Image Interoperability Framework. Kulturinstitutionen schaffen interoperable Schnittstellen für digitalisiertes Kulturgut. Bitte einen großen Applaus für Leander. Ja, vielen, vielen Dank. Auch von mir einen wunderschönen guten Morgen und ich freue mich sehr, dass obwohl heute der vierte Konferenztag ist, ihr dennoch schon zum ersten Talk heute hier erschienen seid. Vielen Dank dafür. Ich freue mich und ich freue mich vor allen Dingen auch, dass ich heute die Gelegenheit habe, hier meine aktuelle Lieblingstechnologie zu präsentieren. Nämlich das International Image Interoperability Framework, dass es erlaubt interoperable Schnittstellen für digitalisiertes Kulturgut zu realisieren. Ganz wenige Worte zu mir selbst. Ich arbeite in der Universitätsbibliothek Leipzig. Bin verantwortlich für den Bereich digitale Dienste und habe aus diesem Kontext heraus mit diesen Dingen natürlich sehr zu tun. Aber ich begeister mich auch persönlich dafür und das führt dazu, dass ich auch das eine oder andere kleine selbst motivierte private Projekt in diesem Bereich durchführe. Da zeige ich nachher auch noch ein kleines Beispiel. Ich denke, es ist bekannt und viele würden mir dann zustimmen, dass die digitalisierte Bilder heutzutage eine fundamentale Informationsträger kulturellen Erbes sind, Handschriften, Drucker, Zeichnungen, Gemälde und viele andere Dinge werden auf diese Weise viel besser zugänglich. Früher war dieser Zugang nur exklusiv, forschenden möglich. Heute ist das für jedermann möglich und die Originale erfahren dadurch auch einen viel höheren Schutz. Digitalisierung ist nichts Neues. Bisher war Digitalisierung oft damit verbunden, dass die Daten, die Metadaten und die digitalisierten Bilder selbst in siloartigen Systemen präsentiert wurden, nur kaum mit anderen Daten verknüffbar waren, entsprechend schwerfällig intern auch die Prozesse waren, Bilder bereitzustellen und auch immer individuell an die Realisierung des jeweiligen Portals geknüpft waren. Ich habe hier ein Beispiel aus unserer eigenen Bibliothek genommen, eine alte Bibelhandschrift, die ich später noch genauer vorstellen werde, bei der das der Fall war, als dieses Portal gebaut wurde, war es damals ein sehr modernes und fortschrittliches Portal, aber heutzutage kann es diesen Ansprüchen nicht mehr genügen, die heute daran angelegt werden. Wie das genau aussieht, kommt nicht dann gleich dazu. Hier nochmal ein Sinnbild dafür, wie die Situation oft ist, wie Präsentationen von Digitalisaten im Netz oft realisiert werden. Die Systeme sind isoliert, tragen ihren institutionellen Charakter nach außen und sind Zugänge zu den Repositoren, was schön ist, aber sie sind eben nicht interoperabel miteinander. Und diesen Punkt, den adressiert das International Image Interoperability Framework, das speziell für diesen Zweck konstruiert wurde, nämlich einen Apiläer, einen standardisierten Apiläer zwischen den eigentlichen Repositorien, also den Speichersystemen für digitalisierte Bilder und die Metadaten zu schaffen. Und diese APIs mit den Präsentationen zu verbinden, sodass die Daten aus verschiedenen Repositorien in verschiedenen institutionell auch nicht gebunden, also beispielsweise privaten Arbeitsoberflächen virtuos vom Nutzer selbst zusammengesetzt werden können. Die Community um dieses Framework ist recht groß geworden, gebildet wurde sie aus einer Gemeinschaft von Stanford University Libraries, der British Library und den Bibliotheken in Oxford. Inzwischen ist das sehr stark gewachsen, die Community. In Deutschland ist es vor allen Dingen, beispielsweise die bayerische Staatsbibliothek, die sich da sehr engagiert. Die Universitätsbibliothek Leipzig tut das auch, die französischen Nationalbibliothek und viele andere. In der Community finden sich inzwischen sehr viele internationale, bedeutende Bibliotheken, Universitätsbibliotheken, Nationalbibliotheken, auch die vatikanische Bibliothek stellt ihre digitalisierte in diesem interoperablen Format inzwischen bereit. Es gibt derzeit vier APIs, die spezifiziert sind. Unter CC By-Lizenz zwei von diesen APIs sind tatsächlich erforderlich eine Präsentation aufzusetzen. Das ist einmal die Image-API, die tatsächlich die Pixel ausliefert. Es gibt die Presentation-API, die dafür da ist, die Struktur und Metadaten zu diesen Pixel zu definieren und interoperabel abrufbar zu machen. Weitere APIs kümmern sich dann um das Thema Suche und Authentifizierung, aber auf die gehe ich hier nicht weiter ein, weil das den Rahmen sprengen würde. Das Besonders Schöne an diesem Standard ist, dass er auf Link Data beruht. Die Daten sind typischerweise in JSON-LD abgelegt. Die Identifier für die verschiedenen Dinge in diesen Daten sind in der Regel HTTP-Uris, die also auflösbar sind und auch den Bezug von Metadaten aus verschiedenen Quellen zueinander ermöglichen, völlig unabhängig von ihrer Speicherung. Ganz kurz wenige Worte über die Presentation-API, die die Hierarchie modelliert, in der die Metadaten abgelegt sind. Zunächst gibt es da die Kollektionen, die also mehrere Werke zu einer sinnhaften Einheit zusammenfassen. Solche Kollektionen können auch selbst gebildet werden. Forscher können sich ihre eigenen Forschungskollektionen zusammenlegen, die aus Manifeste-Dateien bestehen, die dann Sequenzen von Bildern definieren. Eine Manifestdatei beschreibt also ein Werk, das aus Bildsequenzen besteht. Diese Bildsequenzen sind Canvas-Objekte, also reine Seitenobjekte, die dann durch Inhalte, durch Bilder, aber das können eben auch Texte sein, anotiert werden. Ich gehe noch einmal zu der Slide zurück. Das sieht man hier auf dieser Slide sehr schön, wie dieses abstrakte Canvas-Objekt schließlich mit dem eigentlichen Bildinhalt anotiert wird, was es ermöglicht, dieses Canvas-Objekt eben auch durch mehrere verschiedene Bilddateien und auch Texte, beschreibende Texte, Transkriptionen und vielleicht sogar Übersetzungen zu beschreiben. Die Manifestdateien sind so aufgebaut. Ich habe hier vielleicht ganz kurz mal so einen schematischen Überblick zusammengestellt. Den muss man jetzt nicht genau anschauen, sondern nur beschreiben, wie die innere Struktur in Link-Data-Manier aufgebaut ist. Und nach dem gleichen Modus sind eben auch die Anotationen, die die Nutzer selbst auch anlegen können in diesen Systemen. Strukturiert, so dass es möglich ist, eigene Anotationen in eigenen Speichersystemen auf Objekte beziehen zu lassen, die gar nicht in meinem eigenen Speichersystem vorhanden sein müssen. Diese Funktionalität ist hier auf dieser Slide noch einmal abgebildet. Es ist also möglich mit AAAF-Präsentationssysteme aufzusetzen, die aus verschiedenen Repositorienbilder in eine virtuelle Forschungsumgebung um diesen belasteten Begriff mal zu benutzen zusammenzufassen und dann in verschiedenen Anotationsspeichern die wissenschaftlichen Bemerkungen zu speichern. Für die APIs von AAAF gibt es inzwischen zahlreiche Softwareanwendungen. Ich greif hier immer nur ein Beispiel raus, dass ich auch gleich noch live zeigen werde. Für die Presentation-API gibt es einige Fure, die Digitalisate darstellen können. Speziell erwähnen möchte ich hier den Mirador Fure, der multidokumentenfähig ist, also aus verschiedenen Quellen verschiedene Digitalisate zusammenstellen kann und auch über umfangreiche Funktionen der Bildmanipulation und der Anotation verfügt. Die Image-API, die tatsächlich die Bilder ausliefert, ist sehr dynamisch strukturiert. Das heißt, man kann dem Bildserver, der dieser API entspricht, tatsächlich sagen, welchen Ausschnitt aus einem Bild skaliert oder nicht skaliert gedreht und so weiter. Also man kann Bildmanipulation direkt beim Server auch erbitten, der die Digitalisate dann entsprechend aufbereitet und so ist es eben möglich, Digitalisate, die von Institutionen bereitgestellt werden, dynamisch in seine eigenen Anwendungen zu übernehmen. Wie auch bei der Presentation-API gibt es eine ganze Reihe von Softwareprodukten, die Bildserver auf dieser Technologie realisieren. Als Beispiel nenne ich hier den IP-Image-Server, das ist ein fast CGI-Modul für Apache, das unter der GPL V3 bereitgestellt wird. Und dieser Server ist eben in der Lage, diese Presentation-API umzusetzen und das tut er auf der Grundlage von preprozessierten Bilddateien. Dafür legt man Bilddateien an, die über die mehrere Auflösungen des Digitalisats enthalten und idealerweise auch schon in Kacheln unterteilt sind, die von dem Bildserver dann dynamisch ausgeliefert werden. Es gibt leider nur eine geringe Auswahl an Software, mit der man solche Dateien zurzeit erstellen kann. Tiefdateien lassen sich recht gut mit Image-Magic herstellen. Aber für JPEG 2000 ist es schon schwieriger, da gibt es leider nur die kommerzielle Lösung Kakadu und die Open JPEG-Implementierung wird, glaube ich, gerade verbessert, um in diesem Kontext auch eingesetzt werden zu können. Beispiel Nummer eins, der Papyrus Ebers, möchte ich kurz präsentieren. Jetzt wird es ein bisschen praktisch, ich zeig ein paar Demos. Der Papyrus Ebers ist eine Schriftrolle, die ist 3.500 Jahre alt, ist sehr gut erhalten und enthält 880 medizinische Behandlungsverfahren, die Beschreibungen davon aus dem alten Ägypten. Die Rolle hat eine Gesamtlänge von 18 Metern, wurde aus konservatorischen Gründen 1 zerschnitten und ist jetzt digitalisiert wieder zusammengefügt worden auf dieser, auf unserer Seite und ist auch per AAAF abrufbar natürlich und ich zeige nur ganz kurz, wie das funktioniert und auch die Qualität der Darstellungen zu präsentieren. Das ist also die gesamte Schriftrolle, die physisch gar nicht mehr existiert und das Digitalisator übrigens ist 145.000 Pixel breit und 3.000 Pixel hoch und lässt sich trotzdem hier wunderbar zoomen. Darüber hinaus haben wir über die AAAF Funktionalität auch die Übersetzungen dieser medizinischen Rezepte hinterlegt, so dass man hier auch drüber schauen kann, welche medizinischen Verfahren für welche Gebrechen angewendet wurden. Zur Sicherheit habe ich das hier noch als Slides, das überspring ich jetzt. Beispiel 2, der Codex Sinaiticus ist eine Bibelhandschrift aus dem 4. Jahrhundert. Die gilt als die erste Bibelhandschrift, die das vollständige Neue Testament enthält und heute sich leider auf 4 Einrichtungen verteilt. Der größte Teil liegt in der British Library in London, ein kleinerer Teil liegt hier in der Universitätsbibliothek in Leipzig, die Nationalbibliothek in Russland und das Sound-Cathrin's Monastery in Ägypten besitzen auch noch kleinere Teile des Codex und das ist ein perfekter Use-Case eigentlich für AAAF um aus diesen einzelnen besitzenden Institutionen das Gesamtwerk wieder in einer Präsentation zusammenzuführen und dann Platterbau zu machen. Toppen kann man die ganze Sache allerdings noch dadurch, dass es eine zweite Bibelhandschrift gibt, die in etwa das gleiche Alter hat, den Codex Vatikanus, der wie der Namen schon sagt im Vatikan liegt und das Schöne ist jetzt eben, dass die Platter, zumindest die Leipzigerplatter des Codex Sinaitikus bei uns als AAAF bereitstellen und die Platter des Vatikans auch von den vatikanischen Bibliotheken als AAAF bereitgestellt wurden. Und jetzt kann ich zeigen, wie es möglich ist, in einer AAAF-kompatibelen Oberfläche, die man sich auch selbst aufsetzen kann, sich Digitalisate aus unterschiedlichen Einrichtungen zusammenzuziehen. Ich nehme hier zunächst den Codex Sinaitikus aus Leipzig und lade auch die Manifestdatei des Codex Vatikanus in diese Oberfläche und öffnet diese Ansicht hier in dem Mirador-Viewer und kann jetzt über diese relativ komfortable Möglichkeit die Digitalisate nebeneinander anzuzeigen, tatsächlich als Forscher an diesen prominenten Beispiel demonstriert, die Digitalisate aus ganz unterschiedlichen Häusern mir individuell in meiner Forschungsumgebung zusammenstellen. Ich ruf mal hier zwei mal die gleiche Stelle auf, also inhaltlich die gleiche Stelle, der ist der Beginn des Buches Esther und auch mir als völlige Leie auf dem Gebiet, ist das dann auch schon gleich ersichtlich, dass es sich hier offensichtlich um den gleichen Inhalt handelt. So, weiter geht es. Hier nochmal das Sinnbild, um zu verdeutlichen, dass die beiden Digitalisate in diesem Moment von unterschiedlichen Repositorien ausgeliefert werden. Beispiel Nummer 3 ist eine Demo, die in dem offiziellen Demo-System des Projects Mirador zu finden ist. Ich schließe mal hier dieses andere Objekt, zeigt eine Handschrift aus Frankreich, aus der, das ist wohl immer wieder vorgekommen, aus der hier eine Illustration ausgeschnitten wurde und diese Illustration sich heute offensichtlich in einer anderen Institution befindet und das Datenmodell von AAAF, das Institutionsübergreifende, lässt es eben jetzt auch zu, Digitalisate aus verschiedenen Institutionen auf den gleichen Canvas, ich hatte es vorhin kurz gezeigt, auf dem gleichen Canvas zusammenzuführen, um den Eindruck des Originals virtuell auch wieder herzustellen. Und weil dieses Demo-System hier so schön ist, kann ich gleich noch ganz kurz zeigen, wie das mit den Anotationen funktioniert. Dafür ruft man hier diesen, kann man hier so ein Bereich aufrufen und dann hier seine wichtige Bemerkung hinterlassen. Und je nachdem, wie das Viosystem dann konfiguriert ist, kann diese Anotation in eine institutionelle Speicherung gespeitert werden, aber es ist durchaus auch möglich, Forschern, Arbeitsumgebungen in Zukunft bereitzustellen, diese ermöglichen, diese dort ihre privaten Anotationen, ihre Notizen zu den Werken, an denen sie arbeiten, zu hinterlegen. So, ja, hier habe ich nochmal so ein Ausriss gemacht, in dem man sieht, wie in der Manifestartei diese beiden unterschiedlichen Digitalisaten und wenn man sich die URL anschaut, auch aus unterschiedlichen Bildsaubern, hier auf der Canvas-Oberfläche zusammengefasst werden. So ist das so ein Fehler. Ein Beispiel kann ich noch benennen, wir haben diese Technologie auch praktisch ausprobiert in diesem Jahr. Es findet jährlich ein Handschriftenkurs an der Universitätsbildpolitik Leipzig statt und dieses Jahr war es zum ersten Mal so, dass wir eine virtuelle Arbeitsumgebung, den Kursteilnehmern bereitgestellt haben, in der sie virtuell mit unseren eigenen Handschriften aber eben auch mit Handschriften aus anderen Häusern arbeiten konnten und dann in Gruppen zusammengestellt, Anotationen über Handschriften gemeinsam erstellt haben und so ihre Forschungsergebnisse gemeinsam dokumentieren konnten. Das basierte übrigens auf einer Software, die von den Stanford University Libraries bereitgestellt wird und die auch frei verfügbar ist und den Mirador Viewer, den ich vorhin gezeigt habe, nochmal um Funktionen erweitert. Ich möchte auch eingangs angekündigt noch ein kleines Privatesprojekt vorstellen. Ich habe mittels Wikidata und der Nutzung des Sparkle Endpoints mir hoch auflösende Bilder von gemählten Zeichnungen und Karten auf mein eigenes Server gezogen und die dort in AAAF umgewandelt und bereitgestellt und auch durchsuchbar gemacht und auf diesem System kann man sich jetzt eben diese Digitalisator raussuchen und hier kann ich auch noch das Track and Drop Feature zeigen, dass jetzt sehr oft benutzt oder empfohlen wird für die Einbindung oder die Verbindung von Discovery-Systemen mit Bildpräsentationssystemen, in denen man diese Daten hier abrufbar macht. Über dieses Logo sind auch die AAAF-Manifest-Lateien, die man benötigt, um die Daten in andere Workspaces zu ziehen, erreichbar. Vielleicht noch wirklich eine ganz winzige Auswahl. Es haben sehr viele bedeutende Einrichtungen inzwischen AAAF-Digitalisate online gestellt und unter anderem das Metropolitan Museum of Art in New York und die Französische Nationalbibliothek. Aber beispielsweise gibt es auch in der Schweiz ein Handschriftenportal, dass die bedeutenden Handschriften, die in den Schweizer Institutionen liegen, zusammenfasst. Auch das ist alles AAAF-Kompatibel. Hier sind die Links dazu, wenn ihr das interessiert, der kann das sicher später im PDF raussuchen oder die Welcome Library hat auch große Bildbestände Archive org unterstützt AAAF inzwischen auch. Das nur ganz kurz als Beispiele von großen Daten-Pools, die man anzapfen kann, um seine eigenen Präsentation oder sonstige Projekte, die man mit diesen Daten anstellen möchte, zu realisieren. Die AAAF-APIs entwickeln sich natürlich weiter. In Kürze soll die Version 3.0 der Präsentation-API veröffentlicht werden, die zum einen ein Wechsel der Datenmodelle bezüglich der Annotationen vorsieht und auf der anderen Seite aber auch die Unterstützung für Videodaten mitbringen soll. Institutionell gesehen noch zwei Worte zur Universitätsbibliothek Leipzig. Wir haben für uns eine Open Digitalization Policy gefasst mit der Absicht, die dafür geeigneten Digitalisade in unserem Haus unter CCCRO oder CCPD-Mark frei verfügbar zu machen und das auch in dieser institutionsübergreifenden kompatiblen Art und Weise unter der hier eingeplandeten URL kann man in unsere Digitalisierungswerkstatt schauen, in der immer die letzten 20 Digitalisade, mit unseren Digitalisierungs-Wirkflogen, live angeschaut werden können. Der eine Hinweis sei mir noch gestattet. Wir führen demnächst einen Hackathon durch in Leipzig, sodass wir auch ein AAAF-Workshop veranstalten werden. Ich danke vielmals für Ihre Aufmerksamkeit. Wenn ihr mehr wissen wollt über AAAF, dann könnt ihr das unter AAAF.io erfahren. Meine Kontaktdaten stehen auch hier. Vielen Dank und wer noch Fragen an mich hat, stehen jetzt vielleicht noch ein paar Minuten Zeit. Vielen herzlichen Dank, Leander. Wir haben fünf Minuten für Q&A. Wenn ihr Fragen habt, stellt euch an. Frage an den Signalangel ist, dass Internet schön munter und hat Fragen. Keine Fragen aus dem Internet. Vielen Dank für den Vortrag. Meine Frage. Gibt es Schnittstellen zu Inventur- oder Inventardatenbanken? Wie Star-Text-Hieder? Oder Ähnliches? Auf speziell dieses Produkt kann ich keine Aussage drüber machen. AAAF ist ja eine standardisierte, nur die Beschreibung eines Schnittstellen. Systeme, die damit kompatibel gemacht werden sollen, müssen eben Schnittstellen anbieten, die diesen Standard realisieren. Dann machen wir weiter mit Mikrofonenz. Meine Frage ist, das ist jetzt ein Standard. Gibt es denn alternative Standards, die irgendwo aufverwendet werden? Weil ich meine, der große Vorteil ist ja, dass wenn das alle verwenden, das verschiedene Institutionen, das machen. Wenn jetzt aber irgendwie in Berlin die Bibliothek anfängt, einen anderen Standard umzusetzen, ist es vielleicht ein bisschen schlecht. Meine Frage, wird es irgendwie allgemein verwendet in der Bibliotheks-Szene? Oder gibt es da konkurrierende Standards? Es gibt tatsächlich einen älteren konkurrierenden Standard. Das sind ja basiert auf XML-Dateien. Dort ist auch vorgesehen, dass die Daten in der Regel als komplette Bilder ausgeliefert werden. Aber auf diesem technologischen Standard, diese dynamische Auslieferung auf Kachelbasis, die Basis auf Link-Data-Technologien, ist nach meinem Kennenstand so konkurrenzlos im Moment. Wunderbar, herzlichen Dank. Gibt es sonst noch Fragen? Hat sich das Internet mittlerweile gemeldet? Noch immer nicht die Schlafen alle noch? Haben die auch Party gemacht, so wie wir alle? Gut, an den Mikrofonen steht sonst niemand mehr. Dann würde ich sagen vielen herzlichen Dank, Leander. Danke.