Wie in dem letzten Beitrag angekündigt, schauen wir hier, wie man IIIF Manifest Editor verwenden kann.
Mit dem Editor, der von der Bodleian Library, Univ. of Oxford, entwickelt wurde, kann man sowohl ein vorhandenes Manifest weiter editieren, als auch ein neues Manifest erstellen.

Es ist jetzt relativ klar, dass wir hier «New Manifest» anklicken sollen…

Dann kommt man auf diese User Interface. Auf der rechten Seite findet ihr 3 Balken «Manifest metadata», «Sequence metadata» und «Canvas metadata». Diese Struktur haben wir in dem letzten Beitrag schon gesehen.

Zunächst habe ich eine einfache Metadaten für das Item geschrieben…

Da fehlen jedoch noch Bilder, die wir im Viewer zeigen lassen wollen. Dafür fügen wir zuerst ein Canvas pro Bild im Manifest hinzu – Also das Symbol «Add Canvas» klicken.

Dann taucht eine leere Fläche mit «Empty canvas» auf. Diese Fläche klicken und aktivieren. Danach die Balken «Canvas metadata» klicken.

Dadurch wird das Arbeitsfläche für Canvas-Bereich geöffnet. Und da steht «Add Image to Canvas»! – Natürlich klicken!

Hier können wir die URI zu IIIF-Bilder, die wir durch Cantaloupe Image Server ins Netz gestellt haben, hinzufügen. Solange IIIF Image öffentlich zur Verfügung gestellt ist, kann man auch beliebige IIIF Image hier einsetzen. Um am Beispiel des Bildes von der NDL zu bleiben, nehmen wir IIIF-Bild von dem letzten Beitrag. Im IIIF Manifest, das die NDL anbietet, steht IIIF image URI hier:

Die URI sieht so aus:
https://www.dl.ndl.go.jp/api/iiif/2584849/R0000001/full/full/0/default.jpg
Dies ins Feld eingeben und einfach «submitten»…

Dann wird das Bild auf dem Canvas aufgenommen. Die Grösse (Höhe x Breite) des Canvas wird nach dem Bild automatisch eingegeben. Man kann noch einzelne Canvas beschrieben, in dem man in «Canvas label» die Beschreibung hinzufügt.

Wenn man keine weitere Eigenschaften (wie z.B. Laufrichtung der Bilder usw.) bestimmen will, kann man das Manifest downloaden, indem man zuerst «Save manifest» klickt und danach (wie oben) das Manifest herunterlädt. Man erhält dadurch ein JSON-Datei auf dem lokalen Arbeitsplatz.
Dieses JSON-Datei (ich benenne es «testmanifest.json») lädt man auf den Internetserver hoch. Für das Manifest muss auch CORS (Cross-Origin Resource Sharing) ermöglicht sein. Hier könnt ihr mein hochgeladenes Manifest ansehen. … Fertig! Zum guten Schluss schauen wir die durch das Manifest zusammengestellten Bilder an, indem wir z.B. das URL des eigenen Manifest in den UV (Universal Viewer) hineintun und die Bilder anzeigen lassen:
Glückwunsch! Ihr habt damit ein Manifest im IIIF-Standard veröffentlicht!
Wie man hier am Beispiel sieht, können IIIF-Bilder – egal von welchem Server sie stammen mögen – durch Manifest zusammengeführt und als ein «Item» präsentiert werden. Dies ist eine Stärke vom IIIF.
Wenn man noch keinen Server für IIIF-Manifest habt, könnt ihr z.B. bei Github (unter «gist») das IIIF-Manifest hochladen.

Wenn man das Manifest in GithubGist hochlädt und die Datei aufmacht, sieht es so aus. Dann «Row»-Button (unten) klicken.

So wird die Manifest/JSON-Datei im Browser angezeigt. Diese URL sieht es so aus:
https://gist.githubusercontent.com/[username]/[...]/raw/[...]/testmanifest.json
Die URL gilt als URL zum IIIF-Manifest. Daher kann man diese Link in einem beliebigen IIIF-Viewer hinentun und anzeigen lassen. Zum Beispiel dies:
Wenn’s klappt, ist das Manifest vollständig:)
In diesem Prozess habt ihr sicher bemerkt, dass man die IIIF-Bilder nicht selbst hochladen muss, solange man die IIIF-Bilder von einem dritten Anbieter für ein neues Manifest benutzt. Ihr könnt zum Beispiel so ein neues Manifest mit verschiedenen Bildern kreieren – Wie ein virtuelles Museum. Aber bitte dabei auf die Urheberrechte oder sonstige rechtliche Angaben zur Nutzung der Bilder achten.
Wer sich noch weiter über IIIF-Manifest vertiefen will, könnte man demnächst die Beschreibung von Presentation API von IIIF (unter §5 Resource structure – § 5.1 Manifest [link]) ansehen. Dort steht es, dass der Identifikator von einem Manifest eine empfohlene Form gibt.
Recommended URI pattern:
{scheme}://{host}/{prefix}/{identifier}/manifest
[…] The identifier in
@id
must always be able to be dereferenced to retrieve the JSON description of the manifest, and thus must use the http(s) URI scheme.
Dementsprechend könnte man überlegen, wie man der Identifikator einem Manifest vergibt und wie die URL leitet. Dies gilt auch für eine AnnotationList [link]…