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/
