Über das Projekt

Das International Image Interoperability Framework (IIIF) ist ein internationaler Standard zum Austausch von digitalen Bildern und Bilddaten. Digitale Editionen teilen die übergeordnete Zielsetzung in Hinblick auf meist in Textform überlieferte Information; unter dem Stichwort „Distributed Editions“ werden die Vorteile in der Anwendung von IIIF schon länger diskutiert (van Zundert 2018, Witt 2018, Drucker 2021). Obwohl IIIF in vielen Applikationen digitaler Editionen genutzt wird, um Bilddaten etwa von Faksimiles darzustellen, sind die Möglichkeiten nicht ausgeschöpft.

Das betrifft ein knowledge gap zwischen technischer Umsetzung und Anforderungen aus den Editionsprojekten - in beide Richtungen: Einerseits gibt es Features, die sowohl in den IIIF-Spezifikationen als auch in Viewern implementiert sind, die aber nicht genutzt werden, da sie nicht bekannt sind oder für den Anwendungsfall als nicht sinnvoll erachtet werden; andererseits wünschen Editionsprojekte - als BenutzerInnen ihrer eigenen Editionen wie als bemühte BereitstellerInnen von dem jeweiligen Material angemessenen Funktionalitäten - Features im Umgang mit Bilddaten, deren vorhandene technische Implementierbarkeit den EntwicklerInnen der Präsentationsschichten nicht bekannt ist.

Die Editionswissenschaft hat ihrerseits die Bedeutung von faksimilierenden Reproduktionen für die Rechtfertigung editorischer Entscheidungen zur Kenntnis genommen und sie in unterschiedlichen Gradierungen auf einer Skala zwischen reiner Reproduktion (und Sicherung etwa fragilen Materials) und interpretatorischem Eingriff verortet (Bosse 2023, 16f). Geht es um digitale Editionen, so zeigt sich in einer vorläufigen Literaturrecherche in den Bänden und Beiheften von Editio sowie in den Rezensionen aus RIDE: Es liegt der Fokus entweder auf UI-Elementen (wobei Viewer als Standardkomponenten kaum besondere Aufmerksamkeit erfahren), oder auf der technischen Implementierung der Bildauslieferung (wobei IIIF als Schlagwort für die Qualität der Umsetzung einer Applikation ausreichend scheint). Die Möglichkeiten von IIIF und ihre spezifische Anwendbarkeit für digitale Editionen sind jedenfalls von dieser Seite nicht systematisch erfasst.

Einführung

Was ist IIIF?

Das International Interoperability Framework (IIIF; gesprochen Triple-Ei-F) bietet einen Standard, wie digitale Bilder im Internet geteilt werden können. IIIF entstand 2011 mit Unterstützung der Mellon Foundation aus einer Initiative renommierter Gedächtnisorganisationen, zu denen unter anderem die Harvard University, die Stanford University Libraries, die Cornell University, die British Library, die Bodleian Library (Oxford) sowie die Nationalbibliotheken von Frankreich und Norwegen gehören. [...] IIIF schafft eine noch nie dagewesene Interoperabilität und ermöglicht einen institutionsübergreifenden Austausch digitaler Objekte sowie ihre standortunabhängige Darstellung in unterschiedlichsten Viewern und sonstigen Präsentationslösungen im World Wide Web.

IIIF ist also ein Standard für das Ausliefern von Bilddaten im World Wide Web. In den allermeisten Fällen ist dabei der Lieferant ein sogenannter (IIIF-) Image-Server, also der Ort im Netz, an dem die Bilddaten liegen bzw. für die Abholung aufbereitet werden. Der Empfänger ist zumeist der Browser, in dem die gelieferten Bilddaten dargestellt werden sollen. Da IIIF unter Rücksichtnahme auf allgemeine Web-Standards entwickelt wurde (und weiter wird), funktioniert dies mit allen modernen Webbrowsern. Unterstützt der Empfänger jedoch zudem selbst den IIIF Standard (wie es beispielsweise bei IIIF- fähigen Viewern Fall ist), lässt sich das Potential der Technologie voll ausschöpfen.

Ziel dieses Tutorials ist es, hier unser Wissen über IIIF und dessen Verwendung - insbesondere in Hinblick auf Digitale Editionen - zu bündeln. Es richtet sich demnach primär an Webentwickler, die wissen wollen:

Wie adressiere ich meine IIIF Ressourcen über den Browser bzw. in einem IIIF Viewer?
Wie organisiere ich meine IIIF Ressourcen mit Hilfe von Manifesten und Collections?
Welche IIIF Viewer gibt es und wie binde ich sie in meine Digitale Edition ein?

Was hier hingegen nicht geboten wird ist eine Anleitung für das Aufsetzen und Betreiben eines IIIF Image Servers. Zu diesem und vielen weiteren Aspekten rund um IIIF, sowie zur Vertiefung der im Rahmen dieses Tutorials größtenteils nur überblicksartig behandelbaren Themen sei auf die exzellente offizielle IIIF Website verwiesen, auf welche hier noch des Öfteren referenziert werden wird.

Begriffliches

IIIF Ressourcen

Wir gehen also von (Bild-)Daten aus, die bereits auf IIIF Image Servern zur Verfügung stehen, womit sie als IIIF Ressourcen oder IIIF Services (die Nomenklatur ist zum Teil recht verwirrend) über die IIIF APIs zugänglich sind. Jede dieser Ressourcen (in der Regel entspricht eine (Bild-)Quelle einer Ressource) wird durch einen URI eindeutig referenziert, der auch base-URI der jeweiligen IIIF Ressource genannt wird und sich folgendermaßen zusammensetzt:

{scheme}://{server}/{prefix}/{identifier}

Beispiele für base-URIs sind:

https://iiif.onb.ac.at/images/ABO/Z165851607/00000002
https://gams.uni-graz.at/iiif/o:glossvibe.bvi/IMAGE.1
https://digi.vatlib.it/iiif/MSS_Vat.lat.3225/res/img0005

Im (vom Framework empfohlenen) Normalfall werden diese base-URIs von einem Web-Browser auf das image information document (info.json) der betreffenden Ressource dereferenziert (dazu weiter unten mehr).

Vollbild

Wie bereits erwähnt repräsentiert jede IIIF Ressource im Regelfall eine einzelne Bildquelle, beispielsweise den Scan einer einzelnen (oder doppelten) Buchseite. Die Qualität der Ressource ist damit größtenteils von der Qualität der zugrundeliegenden Bilddatei - insbesondere deren Auflösung - abhängig bzw. durch diese limitiert. Das legt die Verwendung möglichst hoch auflösender Bilder (und damit großer Bilddateien) nahe, wobei IIIF Server auch Maximaldimensionen für die Bereitstellung von Ressourcen festlegen können. Mit dem Begriff Vollbild (full image) ist hier die - egal ob nun durch die zugrundeliegende Bilddatei oder die Implementation selbst definierte - höchstauflösendste vom Server bereitgestellte Version des gesamten Bildbereichs gemeint.

IIIF APIs

Vielerorts wird IIIF auch als Spezifikation eines Sets von Services oder APIs, die diesen Standard unterstützen, definiert. Als zentrale (oder Kern-) APIs des Frameworks gelten dabei die IIIF Image API und die IIIF Presentation API, mit denen sich auch dieses Tutorial eingehender beschäftigen wird. Grob gesagt kümmert sich erstere um die Auslieferung einzelner Bildquellen, während letztere die Anzeige von Kompositionen aus mehreren Einzelquellen (beispielsweise eines Buches als chronologische Sequenz seiner Seiten) mitsamt zugehörigen Metadaten ermöglicht und steuert. Weiters umfasst der IIIF Standard die Authorization Flow API (regelt mögliche Zugriffsbeschränkungen), die Change Discovery API (Versionierung), die Content Search API (Durchsuchbarkeit) sowie die Content State API (Navigation der Presentation API).

IIIF Versionen

Sowohl die Image- als auch die Presentation API liegen seit 2020 in der Version 3.0 vor. Da einige der Änderungen zu Version 2 nicht abwärtskompatibel sind macht es einen Unterschied, welche Version am jeweiligen Image Server implementiert ist. In der Praxis findet man - Stand 2024 - fast ausschließlich Implementationen der Version 2 vor (inklusive aller obigen Beispiele). Trotzdem wollen wir uns hier auf die APIs der Version 3.0 konzentrieren und gegebenenfalls auf Änderungen zur vorherigen Version hinweisen.

IIIF Image API

The IIIF Image API specifies a web service that returns an image in response to a standard HTTP or HTTPS request. The URI can specify the region, size, rotation, quality characteristics and format of the requested image. A URI can also be constructed to request basic technical information about the image to support client applications. This API was conceived of to facilitate systematic reuse of image resources in digital image repositories maintained by cultural heritage organizations. It could be adopted by any image repository or service, and can be used to retrieve static images in response to a properly constructed URI.

An die Image API können also grundsätzlich zwei unterschiedliche Arten von Abfragen (Requests) gestellt werden:

Ein Image Information Request gibt Metainformationen über die adressierte Ressource zurück.
Ein Image Request liefert eine Repräsentation der Ressource, also ein tatsächliches Bild (bzw. einen Bildausschnitt) zurück.

Nachdem (Image) Information Requests meist automatisiert im Hintergrund - beispielsweise von einem Viewer - gestellt werden, wird diese Funktionalität der Image API mancherorts etwas stiefmütterlich behandelt (wenn beispielsweise von Image Delivery API die Rede ist).

Compliance Levels

Wichtig vorauszuschicken ist, dass IIIF Ressourcen unterschiedlich stark implementiert werden können, also nicht jede Ressource zwangsläufig alle Funktionalitäten (features) der Image API unterstützen muss. Für einen Client - der beispielsweise auch ein IIIF Viewer sein kann (und in den meisten Fällen wahrscheinlich auch ist) - ist es demnach nützlich vorab zu wissen, welche Funktionalitäten er für eine bestimmten Ressource vom Server erwarten kann - sprich: welche Requests an die Image API möglich und sinnvoll sind. Zu diesem Zweck unterscheidet das Framework drei Konformitätsstufen (Compliance Levels), die den Mindestfunktionsumfang jeder Ressource auf den ersten Blick ersichtlich machen sollen:

level0: Mindestanforderungen für alle IIIF Ressourcen. Der Server muss im Prinzip nur das Vollbild als .jpg in einer beliebigen, voreingestellten (default) Qualität ausliefern können
level1: Empfohlener Implementationsstandard. Es können zusätzlich auch Bildausschnitte adressiert und in verschiedenen Auflösungen angefordert werden
level2: Zusätzlich sind Adressierungen sowohl über Prozentangaben (pct:) als auch über Maximaldimensionen (!) implementiert. Die Rückgabe muß zudem als Portable Network Graphics (.png) und - sofern möglich, also wenn das Original nicht selbst monochrom bzw. schwarzweiß ist - in den Qualitäten color und gray verfügbar sein sowie orthogonale Rotation (90, 180, 270) unterstützen.

Image Information Requests

Für jede IIIF Ressource wird ein sogenanntes image information document erzeugt, das strukturierte Metadaten über die Ressource beinhaltet. Dieses ist in den allermeisten Fällen (wiederum eine Empfehlung, manche IIIF Server erlauben jedoch eine benutzerdefinierte Namensgebung) info.json benannt, ist also eine Datei im JSON - genauer gesagt JSON-LD - Format, die zumindest folgende Informationen bereitstellen muss:

@context Interpretationskontext des Dokuments. Für die Image API 3.0 stellt das Framework http://iiif.io/api/image/3/context.json bereit
id (base-) URI der Ressource
type Art (Version) der Image API, ImageService3 für Version 3
protocol Art des Services, http://iiif.io/api/image für die IIIF Image API
profile Compliance level der Ressource
width height Initiale (volle) Bilddimensionen

Des Weiterem kann angegeben sein:

sizes Bereitgestellte (vorberechnete) Bilddimensionen
maxWidth maxHeight maxArea Maximale Dimensionen, in dem Bilder (beispielsweise über einen Image Request oder an einen Viewer) ausgeliefert werden
tiles Informationen zur Kachelung der Ressource
preferredFormats extraFormats Gibt (Datei-)Formate an, die per Image Request abrufbar sind (jpg, png, tif etc.)
rights Lizenzinformation zum Bildinhalt. Muss entweder einer Creative Commons license URI (beispielsweise http://creativecommons.org/licenses/by/4.0/) oder einer Rights Statements URI (beispielsweise http://rightsstatements.org/vocab/InC-NC/1.0/) entsprechen
extraQualities Steht eine Ressource in mehreren Qualitäten (color, gray, bitonal) zur Verfügung, werden diese hier aufgelistet
extraFeatures Funktionalitäten, die der Service für die Ressource zur Verfügung stellt (und über jene durch ihr jeweiliges Compliance Level definierten hinausgehen)
partOf seeAlso service Verweis auf externe Ressourcen (beispielsweise Manifeste) oder Services

Hier der Versuch einer Gegenüberstellung eines image information documents (info.json) auf Basis der Beispiele der offiziellen API-Dokumentation (in den Versionen 3.0 bzw. 2.1). Die Beispiele wurden geringfügig angepasst um eine bessere Vergleichbarkeit zu gewährleisten. Eine ausführlichere Aufstellung aller Änderungen findet sich im offiziellen Image API 3.0 Change Log.

Image API 3

{
    "@context": "http://iiif.io/api/image/3/context.json",
    "id": "https://example.org/image-service-3/abc/123",
    "type": "ImageService3",
    "protocol": "http://iiif.io/api/image",
    "profile": "level1",
    "width": 6000,
    "height": 4000,
    "maxWidth": 3000,
    "maxHeight": 2000,
    "maxArea": 4000000,
    "sizes": [
        {"width": 600, "height": 400},
        {"width": 3000, "height": 2000}
    ],
    "tiles": [
        {"width": 512, "scaleFactors": [ 1, 2, 4 ]},
        {"width": 1024, "scaleFactors": [ 8, 16 ]},
    ],
    "rights": "http://rightsstatements.org/vocab/InC-EDU/1.0/",
    "preferredFormats": [ "png", "gif"],
    "extraFormats": [ "pdf" ],
    "extraQualities": [ "color", "gray" ],
    "extraFeatures": [ "mirroring", "rotationArbitrary" ],
    "service": [
        {
        "id": "https://example.org/service/example",
        "type": "Service",
        "profile": "https://example.org/docs/example-service.html"
        }
    ]
}

Image API 2

{
    "@context" : "http://iiif.io/api/image/2/context.json",
    "@id" : "http://www.example.org/image-service-2/abc/123",
    "protocol" : "http://iiif.io/api/image",
    "width" : 6000,
    "height" : 4000,
    "sizes" : [
        {"width" : 600, "height" : 400},
        {"width" : 3000, "height": 2000}
    ],
    "tiles": [
        {"width": 512, "scaleFactors": [ 1, 2, 4, 8, 16 ]},
    ],
    "license" : [
        "http://example.org/rights/license1.html",
        "http://rightsstatements.org/vocab/InC-EDU/1.0/"
    ],
    "profile" : [
        "http://iiif.io/api/image/2/level2.json",
        {
        "formats" : [ "png", "gif", "pdf" ],
        "qualities" : [ "color", "gray" ],
        "supports" : [ "mirroring", "rotationArbitrary" ]
        }
    ],
    "service" : {
    "@context": "http://iiif.io/api/annex/service/physdim/1/context.json",
    "profile": "http://iiif.io/api/annex/service/physdim",
    "physicalScale": 0.0025,
    "physicalUnits": "in"
    }
}

Image Requests

IIIF Image Requests (Bildanforderungen oder -aufrufe) sind unbestritten das zentrale Feature (und verkörpern gewissermaßen die Grundidee) des Frameworks. Einfach ausgedrückt könnte man sagen, dass mit IIIF Bilder (Ressourcen) über normale HTTP(S) Requests (Links) dynamisch in verschiedensten Varianten (Ausschnitten, Größen, Rotationen, Qualitäten und Formaten) so ausgeliefert werden können, als ob diese unter der jeweiligen Adresse (URL) tatsächlich (also als Bilddateien am Server) hinterlegt wären. Über die Parametrisierung dieses URL (Request-URI) lässt sich dabei konfigurieren, welche Variante des Bildes konkret zurückgegeben werden soll.

{base-uri}/{region}/{size}/{rotation}/{quality}.{format}

region Auszuwählender, rechteckiger Bildbereich des Vollbildes. Möglich sind:

full0	Der gesamte Bildbereich
square1	Der größtmögliche quadratische Bildbereich, der sich aus dem Vollbild generieren lässt (die Seitenlänge entspricht damit dessen kürzester Seite)
x,y,w,h1	Absoluter Bildbereich, definiert durch dessen linken oberen Punkt (x,y), Breite (w) und Höhe (h) in Pixel
pct:x,y,w,h2	Relativer Bildbereich. Die Angabe pct:50,50,50,50 selektiert demnach das untere rechte Viertel des Vollbildes

.../full/max/0/default.jpg

.../square/max/0/default.jpg

.../1500,1250,300,300/max/0/default.jpg

.../pct:50,50,10,10/max/0/default.jpg

size Dimensionen (Größe), in denen der ausgewählte Bildbereich (region) ausgeliefert werden soll. Möglich sind:

max0	Der ausgewählte Bildbereich in der größtmöglichen (bzw. -zugelassenen) Auflösung
w,h1	Exakte Breite w und Höhe h in Pixel. Kann zu Verzerrungen führen
w,1	Die Auswahl wird auf eine Breite von w Pixel proportional verkleinert
,h1	Die Auswahl wird auf eine Höhe von h Pixel proportional verkleinert
!w,h2	Die Auswahl wird genau so weit proportional (!) verkleinert, dass sie gerade noch in ein imaginäres Fenster der Breite w Pixel und Höhe h Pixel passt
pct:n2	Länge und Breite der Rückgabe entsprechen n Prozent (pct) der Auswahl

.../full/300,300/0/default.jpg

.../full/300,/0/default.jpg

.../full/!300,300/0/default.jpg

.../full/pct:10/0/default.jpg

Upscaling: Wird einem der obigen Dimensionsangaben ein Zirkumflex (^) vorangestellt (also ^max, ^!w,h, ^,h etc.), versucht der IIIF Server den gewählten Bildausschnitt auf die gewünschten Dimensionen (nötigenfalls) hochzuskalieren. Das funktioniert jedoch nur dann, wenn der Server das Hochskalieren auch aktiv unterstützt.

.../1500,1250,300,300/^!400,400/0/default.jpg

.../1500,1250,300,300/^pct:200/0/default.jpg

rotationAusrichtung der Rückgabe Möglich sind:

n0/2/-	Das zurückgegeben Bild ist um n° im Uhrzeigersinn gedreht
!n	Das Bild wird zuerst horizontal gespiegelt und dann um n° gedreht (!0 bewirkt daher eine horizontale Spiegelung ohne Rotation)

.../full/!300,300/0/default.jpg

.../full/!300,300/!0/default.jpg

.../full/!300,300/!332.5/default.jpg

quality Qualität der Rückgabe. Möglich sind:

default0	Die vom Server voreingestellte Bildqualität (entspricht zumeist color)
color2	Alle (vorhandenen) Farbinformationen
gray2	Schwarzweiß MIT Graustufen (s/w monochrom)
bitonal	Schwarzweiß OHNE Graustufen (s/w bitonal)

format (Datei-)Format der Rückgabe. Unterstützt werden:

jpg0	image/jpeg
png2	image/png
tif	image/tiff
gif	image/gif
jp2	image/jp2
pdf	application/pdf
webp	image/webp

.../full/pct:10/0/gray.jpg

.../full/pct:10/0/bitonal.jpg

.../full/pct:10/0/color.png

IIIF Presentation API

The objective of the IIIF (pronounced Triple-Eye-Eff) Presentation API is to provide the information necessary to allow a rich, online viewing environment for compound digital objects to be presented to a human user, often in conjunction with the IIIF Image API.

Die IIIF Presentation API dient also - hauptsächlich - der Repräsentation von zusammengesetzten (compound) (Bild-)Objekten. Darunter versteht man - grob verallgemeinert - Bildsammlungen bzw. - im Bezug auf IIIF - Arrangements mehrerer bestehender Einzelressourcen, wobei die Kuratierung dieser Ressourcen keinen inhaltlichen Regeln unterliegt (so kann es beispielsweise sinnvoll sein, die Vorder- und Rückseite einer Postkarte oder Fotografien zu einem bestimmten Thema als zusammengehörig anzusehen, aber auch völlig willkürlichen Zusammenstellungen von Ressourcen setzt das Framework keine Grenzen). Ein eigentlich sehr spezieller, besonders in Hinblick auf Digitale Editionen jedoch wesentlicher Anwendungsfall hierfür ist die Darstellung gebundener Texte als Arrangements bzw. Abfolgen (sequences) von Digitalisaten einzelner Seiten.

Die Steuerung dieser Arrangements übernehmen bei IIIF abermals Dateien im JSON-LD Format, sogenannte Strukturressourcen (structural resources):

Manifeste beschreiben Struktur und Metadaten eines digitalen (compound-) Objekts
Mit Collections lassen sich wiederum Strukturen aus mehreren Manifesten (und/oder weiteren, untergeordneten Collections) beschreiben

Manifeste

The Manifest resource typically represents a single object and any intellectual work or works embodied within that object. In particular it includes descriptive, rights and linking information for the object. The Manifest embeds the Canvases that should be rendered as views of the object and contains sufficient information for the client to initialize itself and begin to display something quickly to the user.

Ein Manifest ist also - wie das bereits beschriebenen image information document - eine JSON-Datei. Als Einstieg, hier ein - stark gekürztes - Beispiel aus einem laufenden Projekt:

{
  "@context": "http://iiif.io/api/presentation/3/context.json",
  "id": "https://www.ditah.at/iiif/example_manifest.json",
  "type": "Manifest",
  "label": {
    "none": ["Compendium Historiae in Cambridge, Corpus Christi College, MS 29, p1-3"]
  },
  "metadata": [
    {
      "label": {
        "de": ["Autor"],
        "none": ["Author"]
      },
      "value": {
        "de": ["Peter von Poitiers"],
        "none": ["Peter of Poitiers"]
      }
    },
    {
      "label": {
        "de": ["Datierung"],
        "none": ["Date"]
      },
      "value": {
        "none": ["1200 - 1225"]
      }
    }
  ],
  "summary": {
    "de": ["Ein Manifest-Beispiel aus dem Compendium Historiae-Projekt"],
    "none": ["A manifest example from the Compendium Historiae project"]
  },
  "requiredStatement": {
    "label": {
      "de": ["Bildrechte"],
      "none": ["Image rights"]
    },
    "value": {
      "none": ["Corpus Christi College, Cambridge"]
    }
  },
  "rights": "http://creativecommons.org/licenses/by/4.0/",
  "provider": [
    {
      "id": "https://www.ditah.at/",
      "type": "Agent",
      "label": {
        "de": ["Digitale Transformation der Österreichischen Geisteswissenschaften"],
        "none": ["Digital Transformation of Austrian Humanities"]
      },
      "logo": [
        {
          "id": "https://www.ditah.at/images/DiTAH_Logo_blau-01.svg",
          "type": "Image",
          "format": "image/svg+xml"
        }
      ]
    }
  ],
  "items": [
    {
      "id": "https://www.ditah.at/iiif/example_manifest/canvas1",
      "type": "Canvas",
      "label": "f. vir",
      "height": 8586,
      "width": 5962,
      "items": [
        {
          "id": "https://www.ditah.at/iiif/example_manifest/canvas1/annoPage1",
          "type": "AnnotationPage",
          "items": [
            {
              "id": "https://www.ditah.at/iiif/example_manifest/canvas1/annoPage1/anno1",
              "type": "Annotation",
              "motivation": "painting",
              "target": "https://www.ditah.at/iiif/example_manifest/canvas1",
              "body": {
                "id": "https://www.ditah.at/iiif/example_manifest/canvas1/annoPage1/anno1/image1",
                "type": "Image",
                "service": {
                  "id": "https://stacks.stanford.edu/image/iiif/xj710dc7305%252F029_vi_R_TC_46",
                  "profile": "level2",
                  "type": "ImageService2"
                }
              }
            }
          ]
        }
      ]
    },
    {
      "id": "https://www.ditah.at/iiif/example_manifest/canvas2",
      "type": "Canvas",
      "label": "f. viv",
      "height": 8634,
      "width": 6010,
      "items": [
        {
          "id": "https://www.ditah.at/iiif/example_manifest/canvas2/annoPage1",
          "type": "AnnotationPage",
          "items": [
            {
              "id": "https://www.ditah.at/iiif/example_manifest/canvas2/annoPage1/anno1",
              "type": "Annotation",
              "motivation": "painting",
              "target": "https://www.ditah.at/iiif/example_manifest/canvas2",
              "body": {
                "id": "https://www.ditah.at/iiif/example_manifest/canvas2/annoPage1/anno1/image1",
                "type": "Image",
                "format": "image/jpeg",
                "height": 8634,
                "width": 6010,
                "service": {
                  "id": "https://stacks.stanford.edu/image/iiif/xj710dc7305%252F029_vi_V_TC_46",
                  "profile": "level2",
                  "type": "ImageService2"
                }
              }
            }
          ]
        }
      ]
    },
    {
      "id": "https://www.ditah.at/iiif/example_manifest/canvas3",
      "type": "Canvas",
      "label": "f. viir",
      "height": 8575,
      "width": 5938,
      "items": [
        {
          "id": "https://www.ditah.at/iiif/example_manifest/canvas3/annoPage1",
          "type": "AnnotationPage",
          "items": [
            {
              "id": "https://www.ditah.at/iiif/example_manifest/canvas3/annoPage1/anno1",
              "type": "Annotation",
              "motivation": "painting",
              "target": "https://www.ditah.at/iiif/example_manifest/canvas3",
              "body": {
                "id": "https://www.ditah.at/iiif/example_manifest/canvas3/annoPage1/anno1/image1",
                "type": "Image",
                "service": {
                  "id": "https://stacks.stanford.edu/image/iiif/xj710dc7305%252F029_vii_R_TC_46",
                  "profile": "level2",
                  "type": "ImageService2"
                }
              }
            }
          ]
        }
      ]
    }
  ]
}

Manifestmetadaten

@context Interpretationskontext des Dokuments. Für die Presentation API 3.0 stellt das Framework http://iiif.io/api/presentation/3/context.json bereit
id Identifikator des Manifest, idealerweise dessen URL
type Ressourcentyp, Manifest für Manifeste

Objektmetadaten

label Titel des durch das Manifest repräsentierten (compound-) Objekts, optional in mehreren Sprachen
metadata (Frei wählbare) Metadaten zum Objekt. Jedes Metadatenelement besteht aus einem label und einem value, wiederum optional mehrsprachig
summary Kurzbeschreibung des Objekts, wiederum optional mehrsprachig
requiredStatement Text, der bei der Darstellung des Objekts angezeigt werden muss (beispielsweise für Bildrechte)
rights Lizenzinformation zum Manifest. Muss entweder einer Creative Commons license URI (beispielsweise http://creativecommons.org/licenses/by/4.0/) oder einer Rights Statements URI (beispielsweise http://rightsstatements.org/vocab/InC-NC/1.0/) entsprechen"id": "anno
provider Informationen zu Personen und/oder (mehrere Einträge möglich) Organisationen, die an der Entstehung des Manifests und/oder der referenzierten (Bild-) Inhalte beteiligt waren (contributors). Zur den möglichen Angaben gehören label, homepage und logo, zur genauen Struktur sei hier auf die offizielle Dokumentation verwiesen

Objektstruktur

Prinzipiell drücken IIIF Manifeste zusammengehörige oder zusammengesetzte Objekte als geordnete Listen dieser ihrer einzelnen Elemente (items) aus, wobei die Reihenfolge dieser Elemente deren Anzeigereihenfolge (beispielsweise beim Durchblättern in einem Viewer) festlegt. Im Detail gestalten sich die Beziehungen der unterschiedlichen IIIF Ressourcetypen - bedingt unter anderem durch die Angleichung an das Web Annotation Data Model des W3C - allerdings als äußerst komplex:

items (Canvas) Für jedes Element (Einzelansicht) wird eine Projektionsfläche oder Leinwand (canvas) mit bestimmten Abmessungen (height, width) definiert (analog zu einer leeren Buchseite)
items/ items (AnnotationPage) Liste von Annotationen, die auf das jeweilige Canvas angewendet werden. Beispielsweise kann es sinnvoll sein, getrennte Listen für Text- und Bildannotationen zu führen
items/items/ items (Annotation) IIIF (respektive das Web Annotation Model) denkt auch das eigentliche Bild als Projektion bzw. Annotation einer externen Inhaltsressource (Content Resource) auf die leere Leinwand (Canvas)
items/items/items/ target Referenziert das Canvas, auf das die Annotation angewendet wird
items/items/items/ body (Image) Beschreibt die zu annotierende Inhaltsressource, welche wiederum eine IIIF Ressource sein und über service auf die Image API verweisen kann. Ist kein service angegeben, wird die id als URL einer Bilddatei interpretiert

Collections

Collections sind ebenfalls JSON-Dateien, die wiederum Manifeste und/oder Collections enthalten können

Viewer

OpenSeadragon

const osd = OpenSeadragon({
    id: 'osd',
    prefixUrl: 'https://cdn.jsdelivr.net/npm/openseadragon@5.0/build/openseadragon/images/',
    sequenceMode: true,
    tileSources: [
        "https://stacks.stanford.edu/image/iiif/xj710dc7305%252F029_vi_R_TC_46/info.json",
        "https://stacks.stanford.edu/image/iiif/xj710dc7305%252F029_vi_V_TC_46/info.json",
        "https://stacks.stanford.edu/image/iiif/xj710dc7305%252F029_vii_R_TC_46/info.json"
    ]
});

Universal Viewer

const uv = UV.init('uv', {
    manifest: 'https://www.ditah.at/iiif/example_manifest.json'
});

Mirador

const mdv = Mirador.viewer({
    id: 'mdv',
    windows: [{
        manifestId: 'https://www.ditah.at/iiif/example_manifest.json'
    }]
});

Tify

const tify = new Tify({
    container: '#tify',
    manifestUrl: 'https://www.ditah.at/iiif/example_manifest.json'
});

Weiterführende Literatur

Kränzle, A., Ritter, G., Sieber, Ch. 2023: Sources Online: Eine nachhaltige Infrastruktur für digitale wissenschaftliche Texteditionen auf der Grundlage von TEI Publisher und IIIF: Sources Online: A Sustainable Infrastructure for Digital Scholarly Text Editions Based on TEI Publisher and IIIF, ABI Technik 43/3,158-167. DOI: 10.1515/abitech-2023-0030.
The digital Analysis of Syriac Handwriting (DASH) Projekt: Augmenting Manuscript Studies via Interactive Scriptcharts and IIIF: https://dh2020.adho.org/wp-content/uploads/2020/07/442_TheDigitalAnalysisofSyriacHandwritingDASHProjectAugmentingManuscriptStudiesviaInteractiveScriptchartsandIIIF.html
Mertens, I. 2021. Zwei Seiten einer Medaille - IIIF und die Arbeit mit digitalen Bildbeständen. In: Zeitschrift für digitale Geisteswissenschaften. Wolfenbüttel. DOI: 10.17175/2021_002
van Zundert, J. 2018: On Not Writing a Review about Mirador: Mirador, IIIF, and the Epistemological Gains of Distributed Digital Scholarly Resources. Digital Medievalist 11(1): 5, pp. 1-48, DOI: 10.16995/dm.78.
Witt, J. C. 2018. Digital Scholarly Editions and API Consuming Applications. In: Digital Scholarly Editions as Interfaces, hg. v. R. Bleier, M. Bürgermeister, H. Klug, et al. (Schriften des Instituts für Dokumentologie und Editorik 12), 219-247. http://nbn-resolving.de/urn:nbn:de:hbz:38-91182.