Kitodo-Developer

Download

kitodo-developer@kitodo.org

March 2019

1 participants
1 discussions

Unterstützung der IIIF Presentation API in Kitodo.Presentation
by Lutz Helm 08 Mar '19

08 Mar '19

Liebe Kolleginnen und Kollegen, im Rahmen des EFRE-Projektes "Cross Media Repository" wurde in den letzten Monaten an der Unterstützung von IIIF-Presentation-API-Manifesten (https://iiif.io/api/presentation/2.1/) in Kitodo.Presentation gearbeitet. Die Arbeit ist inzwischen an einem Punkt angekommen, an dem sich eine Übernahme der Ergebnisse in den master-Branch lohnt. Nach Übernahme der Änderungen aus dem Entwicklungszweig in den master-Branch wird Kitodo.Presentation in der Lage sein, beliebige IIIF-Manifeste anzuzeigen. Eine recht umfangreiche Unterstützung gibt es dabei vor allem für die IIIF Presentation API 2.0 / 2.1, aber auch Manifeste der mittlerweile obsoleten IIIF Metadata API 1.0 sowie der demnächst erscheinenden IIIF Presentation API 3.0 können schon jetzt grundlegend angezeigt werden. Für die Verwendung von IIIF-Manifesten wird dabei fast komplett auf die bestehenden Oberflächen-Plugins der Typo3-Extension zurückgegriffen wie zuvor schon für METS/MODS-Dokumente. Lediglich im Toolbox-Plugin ist ein Werkzeug zur Anzeige von IIIF-Annotationen hinzugekommen, für weitere Plugins sowie für die Extension an sich gibt es teilweise geänderte und erweiterte Konfigurationen. Die IIIF-Presentation-API-Features werden auch nach Übernahme in den Master noch weiterentwickelt werden und sollten noch nicht produktiv eingesetzt oder erweitert werden, da weitere weitreichende Änderungen noch nicht ausgeschlossen sind. Die Änderungen sind derzeit im Feature-Branch unter https://github.com/ubleipzig/kitodo-presentation/tree/cmr-3.2-iiif-manifests verfügbar. Einige bereits in den Master gemergte Bugfixes an den IIIF-Imageviewer-Features sind noch nicht im Branch enthalten, weswegen sich zum ausprobieren aller IIIF-Features eher (https://github.com/ubleipzig/kitodo-presentation/tree/cmr-3.2-with-master-f…, Installation über Composer) empfiehlt. Im folgenden gibt es einen groben Überblick über die hinzugekommenen Funktionen, Hinweise auf wichtige Quellcodeänderungen und ein paar Problemschilderungen. Über Feedback und Anregungen dazu (insbesondere zu den Problemen) würde ich mich freuen. ## Technische Einzelheiten und unterstützte Features * Angezeigt wird im Viewer jeweils das erste Bild pro Canvas für die Canvases der Default-Sequenz. Die Unterstützung mehrerer Bild-Annotationen pro Canvas steht noch aus. Nicht nur für den Zweck der Anzeige mehrerer Bilder ist außerdem eine noch angedachte Unterstützung der genauen Positionierung von Bildern z.B. per Fragment Identifier oder Selector nötig (https://iiif.io/api/presentation/2.1/#segments) * Für IIIF-Manifeste erhält das Metadaten-Plugin die Option, diese komplett wie im Manifest angegeben anzuzeigen statt anhand einer Metadaten-Konfiguration im Backend. Falls es um eine Darstellung von Manifesten mit unbekannten Metadaten geht, entspricht eine derartige Darstellung eher den Vorgaben der IIIF Presentation API. Der Name für die TypoScript-Konfiguration ist "originalIiifMetadata"; über "displayIiifDescription", "displayIiifRights" und "displayIiifLinks" lässt sich dann einstellen, ob auch eine Beschreibung, rechtliche Angaben und Verlinkungen gemeinsam mit den Metadaten angezeigt werden sollen. * Metadaten aus IIIF-Manifesten mit bekannter (Metadaten-) Struktur können aber auch anhand einer Metadatenkonfiguration angezeigt sowie im Backend und im Suchindex gespeichert werden; mehr dazu weiter unten. * PDFs von vollständigen Werken sowie von Einzelseiten können über die Eigenschaft "rendering" des Manifests oder der Default-Sequence (für das Werk) oder des Canvas oder der Image-Annotation (für Einzelseiten) angegeben werden. Damit der Eintrag als PDF-Variante der jeweiligen Darstellung erkannt wird, muss für den "rendering"-Eintrag die "@id" die Download-URL enthalten und als "format" "application/pdf" angegeben werden: "rendering": [ { "@id": "http://example.org/files/book1.pdf", "format": "application/pdf" }, ... ] * Volltext, der als ALTO-XML vorliegt, kann auch in IIIF-Manifesten verwendet werden. Dazu wird das jeweilige ALTO-Dokument im "seeAlso"-Feld des Canvas verlinkt. Um als ALTO erkannt zu werden, muss entweder als "format" der (nicht offiziell registrierte) Media Type "application/alto+xml" oder als "profil" die jeweilige ALTO-Schema-Location angegeben sein (z.B. "http://www.loc.gov/standards/alto/alto-v2.0.xsd"; entscheidend ist, dass die URL mit "http://www.loc.gov/standards/alto/" beginnt). "seeAlso": [ { "@id": "http://example.org/fulltext/book1/alto-page1.xml", "format": "application/alto+xml", "profile": "http://www.loc.gov/standards/alto/alto-v2.0.xsd" } ] * Daneben kann Volltext auch in den Text-Annotations des Canvas vorliegen. Da Text-Annotationen jedoch keine Informationen darüber enthalten, ob sie nun den Volltext repräsentieren oder z.B. eine Beschreibung des jeweiligen Canvas und seiner einzelnen Bereiche enthalten, können sie nicht einfach als Volltext angeboten werden, sondern werden über ein neues Annotations-Werkzeug ggf. zusätzlich zum Volltext angeboten, verhalten sich aber diesem recht ähnlich. Bisher werden nur Annotationen mit "motivation": "sc:painting" in der Oberfläche angeboten, im weiteren Verlauf der Entwicklung ist auch eine Auswahl aus allen Motivationen (neben "painting" vor allem "commenting") denkbar. Im Backend kann konfiguriert werden, ob der Inhalt der painting-Text-Annotationen als Volltext gespeichert werden soll. * Für METS-MODS erwartet Kitodo.Presentation Vorschaubilder in einer passenden "fileGrp". Ein Vorschaubild-Feature gibt es auch für IIIF-Images aus IIIF-Manifesten; dort kann direkt in der "thumbnail"-Property des Canvas, der Image-Annotation oder der Content-Resource ein Vorschaubild angegeben werden. Falls dieses fehlt, lassen sich für IIIF-Bilder problemlos Thumbnails in beliebiger Größe generieren, sofern der angegebene Image-Service das unterstützt. In Kitodo.Presentation kann die gewünschte Größe dieser Vorschaubilder über die Einstellungen der Extension im Reiter "IIIF" gesteuert werden. * Die Thumbnail- und Annotationsindizierungseinstellungen erfolgen derzeit in den Einstellungen der Extension, denkbar wäre alternativ aber auch eine Konfiguration im jeweiligen Systemordner. ## Wichtige Quellcode- und Datenbankschema-Änderungen * Die bedeutendste Änderung im Quellcode ist die Abstrahierung der Klasse tx_dlf_document und die Trennung der METS- und IIIF-spezifischen Funktionen in tx_dlf_mets_document und tx_dlf_iiif_manifest, die jeweils abstrakte Methoden der Klasse tx_dlf_document implementieren. * In der Datenbank erfolgt die prinzipielle Unterscheidung zwischen IIIF- und METS-Dokumenten anhand des neuen Feldes tx_dlf_document.document_format mit den Werten 'METS' und 'IIIF'. * IIIF-versionsspezifischer Code ist im Code von Kitodo.Presentation so knapp wie nur möglich gehalten worden. Erreicht wird dies durch die Auslagerung konkreter IIIF-Implementierungsdetails in eine eigens entwickelte Bibliothek (https://github.com/ubleipzig/php-iiif-prezi-reader) über deren Interfaces alle IIIF-Versionen versionsunabhängig angesprochen werden können. Das ermöglicht eine Unterstützung auch über die derzeit gültige Presentation-API-Version 2.1 hinaus. * Falls die Metadaten anhand einer vorgegeben Konfiguration verwendet werden sollen, wie das vor allem für eine lokale Speicherung der Dokumente nötig ist, kann diese für IIIF-Manifeste vorerst mit JsonPath-Ausdrücken (https://goessner.net/articles/JsonPath/) erfolgen. Andere Varianten (z.B. anhand des "label"s des "metadata"-Arrays (zu unflexibel) oder anhand von SPARQL-Queries (neue, komplexe Abhängigkeiten für ein vergleichsweise kleines Feature) wurden zunächst als unpraktikabel erachtet; zugleich bleibt abzuwarten, ob sich JsonPath für diesen Zweck tatsächlich praktisch bewährt. Alternativvorschläge und Anregungen dazu sind herzlich willkommen! * Die Metadatenkonfiguration wird wie schon für MODS und TEIDHR in tx_dlf_metadataformat gespeichert. Neben MODS und TEIHDR sind dafür die Formate IIIF1, IIIF2 und IIIF3 hinzugekommen. Für die Angabe der JsonPath-Ausdrücke des jeweiligen IIIF-Formats werden die Datenbank-Felder tx_dlf_metadataformat.xpath und tx_dlf_metadataformat.xpath_sorting wiederverwendet. Um dem geänderten Inhalt der Felder Rechnung zu tragen, werden diese in metadataquery und metadataquery_sorting umbenannt. * Im Gegensatz zu den via METS transportierten Formaten muss hier weder eine Klasse zur extrahieren der Metadaten noch (offensichtlicherweise) ein XML-Root-Element angegeben werden. Anstelle des Namespaces wird der Context-IRI gespeichert. Die ursprüngliche Eingrenzung der Formate auf XML wird dadurch umgangen, zugleich ist so aber eine gemeinsame Konfiguration der Metadaten ohne eine Parallelstruktur für IIIF möglich. Gleichzeitig wird die Formate-Tabelle aber auch bereits genutzt, um ALTO als Format für Volltexte anzugeben, das zwar wiederum ein XML-Format, aber kein Metadatenformat ist. Es wäre zu diskutieren, ob die Struktur in der Form so weitergenutzt werden kann. * Als JsonPath-Bibliothek wird zur Zeit https://github.com/FlowCommunications/JSONPath verwendet. ## Probleme * Eine IIIF-Unterstützung durch das OAI-PMH-Plugins erscheint nicht sinnvoll. Die Metadaten in IIIF-Manifesten haben aus Sicht der API keine semantische Bedeutung z.B. für maschinelle Verabreitung und sind auch nicht für Discovery-Zwecke vorgesehen, sondern dienen lediglich der Anzeige. * Im Zusammenhang mit OAI steht das Problem, dass jedes lokal indexierte Dokument eine recordId benötigt, die den Datensatz eindeutig identifiziert. Für IIIF-Manifeste bietet sich dafür die (auflösbare) ID des Manifests selbst an. Im Metadaten-Plugin sowie in den betreffenden Formularen in Backend zeigt Kitodo.Presentation diese Record-ID als "OAI-Identifier" an, was irreführend ist, wenn die ID nicht tatsächlich als OAI-Identifier dient. Es lassen sich natürlich auch andere Werte für die Record-ID definieren, allerdings erscheint als Fallback nur der @id-IRI des Manifests sinnvoll. * Ein bekanntes Problem ist, dass die IIIF-Bibliothek (noch) keine wiederholten IDs unterstützt. Derzeit können Resourcen von verschiedenem Typ keine gleiche ID haben. Es gibt aber z.B. durchaus Manifeste, in denen eine Image-Annotation und ein Canvas die gleiche ID haben bzw. aus RDF-Perspektive die betreffende Ressource zwei verschiedene Typen hat und als Canvas sich selbst zugleich als eine ihrer Annotationen hat: { "@context": "http://iiif.io/api/presentation/2/context.json", "@id": "http://www.example.org/common-id", "@type": "sc:Canvas", "images": [ { "@id": "http://www.example.org/common-id", "@type": "oa:Annotation" } ] } * Kitodo.Presentation bietet in der Klasse tx_dlf_document über die magische __get()-Methode Zugriff auf einige protected properties, einige davon METS-spezifisch. Das macht es schwierig, eine abstrakte Klasse zu formulieren, die alle bisherigen Features tx_dlf_document unterstützt und mit der erweiternder Code ohne Probleme läuft. Die Unterstützung beschränkt sich auf die bisher existenten öffentlichen Methoden. Für Extensions, die auf Kitodo.Presentation aufsetzen, bedeutet das, dass Code angepasst werden muss, wo direkter Property-Zugriff erfolgt. Im DFG-Viewer beispielsweise wird in Slub\Dfgviewer\Helpers\GetDoc direkt auf tx_dlf_document->mets zugegriffen. Ich freue mich auf Ihr Feedback! Viele Grüße Lutz Helm -- Lutz Helm Bereich Digitale Dienste AG Anwendungsentwicklung Universitätsbibliothek Leipzig Beethovenstraße 6, 04107 Leipzig T: +49 341 97 30566 helm(a)ub.uni-leipzig.de https://www.ub.uni-leipzig.de/

1 0