Publicatie:IIIF-metadatahandboek

Samenvatting

Het IIIF-metadatahandboek wil geïnteresseerden op een toegankelijke manier wegwijs maken in de geheimen van IIIF. Het handboek besteedt in het bijzonder aandacht aan de noodzakelijke metadata en hoe deze metadata in een IIIF-manifest moeten worden opgenomen om een correcte en logische IIIF-presentatie via een IIIF-viewer mogelijk te maken. Daarnaast gaan we dieper in op een aantal tools die je kunnen helpen om een IIIF-manifest op te maken. Aan de hand van voorbeelden illustreren we hoe je complexe en minder complexe werken via IIIF kan meedelen.

Met het metadatahandboek hopen we niet alleen de ‘diehards’ maar ook de minder technisch onderlegde erfgoedmedewerkers te verleiden om met IIIF aan de slag te gaan.

Referentie

Titel	IIIF-metadatahandboek (Voorkeurstitel)
Locatie
Uitgever	meemoo - Vlaams instituut voor het archief
Jaar van uitgave	2023
Rechten	CC-BY-SA
Persistent ID

Trefwoorden

IIIF for dummies

IIIF (lees: “triple-aai/eye-eff”) staat voor International Image Interoperability Framework. Deze naam verwijst naar een internationaal protocol om beelden en audiovisueel materiaal online te presenteren, uit te wisselen en te hergebruiken. Dit protocol wordt onderhouden en ontwikkeld door een consortium van internationale universiteiten, bibliotheken, musea en archieven. De implementatie ervan in software en de uitwerking van concrete use cases gebeuren door een actieve community.

Waarom IIIF?

IIIF vormt een antwoord op de dure en afgesloten beeldinfrastructuren van verschillende instellingen en de moeilijkheden voor eindgebruikers die daarmee gepaard gaan.

Door gebruik te maken van een gedeeld protocol worden de kosten voor ontwikkeling en infrastructuur gedeeld. Best practices en implementaties worden internationaal ter beschikking gesteld.
Eindgebruikers kunnen beelden van verschillende instellingen op een uniforme manier gebruiken.
Beelden blijven verbonden met de beherende instelling.
De community zorgt voor de ontwikkeling van rijke en open-source tools (bv. viewers).

Standaarden en API's

Een beroep doen op IIIF bij de ontsluiting van gedigitaliseerde collecties betekent dat je digitale representaties (bv. foto van een schilderij) en de verbonden metadata aanbiedt op een gestandaardiseerde manier. Je volgt met andere woorden de afspraken/standaarden die door het consortium zijn vormgegeven. Deze steunen op het gebruik van web API's (Application Programming Interface), een methode om informatie tussen systemen uit te wisselen via commando's in URL's. Er zijn vandaag zes API's, waarvan de Image en de Presentation API de belangrijkste zijn:

Image API: zorgt voor een efficiënte uitwisselen en manipulatie van digitale beelden aan de hand van URL's. Via de aanpassing van specifieke onderdelen van de URL-syntax kan je een beeld draaien, verkleinen, in zwart-wit tonen, een detail uitsnijden, ...
Presentation API: biedt de informatie die nodig is om een rijke, online kijkomgeving mogelijk te maken waarin samengestelde digitale objecten (en metadata) aan een menselijke gebruiker kunnen worden gepresenteerd, vaak in combinatie met de IIIF Image API.
Authorization Flow API: beschrijft een reeks workflows om de gebruiker door een bestaand toegangscontrolesysteem te leiden. Deze API laat toe om de toegang tot beelden en metadata op een gecontroleerde manier te bepalen.
Change Discovery API: biedt de informatie die nodig is om IIIF-bronnen machinaal te ontdekken en te gebruiken.
Content Search API: laat toe om te zoeken naar tekstannotaties die zijn gekoppeld aan een object binnen de IIIF-context.
Content State API: biedt een manier om te verwijzen naar een IIIF Presentation API-bron, of een deel van een bron, in een compact formaat dat kan worden gebruikt voor de weergave van die bron in elke omgeving.

Het implementeren van (een deel van) deze API's vraagt om computertechnische expertise. Op de IIIF-website zijn enkel de nodige documentatie en interessante bouwblokken te vinden.

IIIF-bronnen gebruiken

Wanneer de infrastructuur is opgezet, kan je beelden uit de eigen collectie aanbieden en gebruiken via het IIIF-protocol. Dit gebeurt via URL's.

De Image URL (bv. https://iiif.meemoo.be/833mw2908t_19140804_0001/full/full/0/native.jpg) laat toe om een beeld in een browser te openen. Aanpassingen aan de onderdelen van deze URL zorgen voor bewerkingen van het beeld.
De Manifest URL (bv. https://digitalcollections.universiteitleiden.nl/iiif_manifest/item:130472/manifest) kan worden ingeladen in een viewer of andere tool. Op die manier worden het beeld/de beelden en de toegevoegde metadata gepresenteerd.

Welke viewer je hiervoor gebruikt, is afhankelijk van de doelen die je wil bekomen. Sommige viewers laten immers enkel toe om het beeld te bekijken en in te zoomen. Andere viewers presenteren ook de toegevoegde metadata.

IIIF-manifest

Het zogenaamde IIIF-manifest is een centrale bouwsteen van de uitwisselings- en presentatiestandaard. Dit bestand bevat alle informatie die nodig is om een collectiestuk op het web te tonen. Omdat het gaat om een JSON-LD (JavaScript Object Notation for Linked Data) bestand kunnen deze data zowel door een mens als door een machine gelezen en geïnterpreteerd worden.

Om uitwisseling te kunnen verzekeren, zijn de voorgeschreven regels uit de Presentation API sturend. Dit betekent echter niet dat er geen inhoudelijke en structurele keuzes moeten worden gemaakt. Daarom is een inzicht in de structuur en onderdelen van een IIIF-manifest belangrijk.

Structuur

Om de onderlinge relaties tussen beelden op een duidelijke manier te kunnen weergeven, wordt er een onderscheid gemaakt tussen een manifest, een canvas, een range en een collection. Dit onderscheid kan het best geïllustreerd worden met het voorbeeld van een boek.

Het boek zelf wordt gerepresenteerd door een manifest. Een manifest komt dus doorgaans overeen met een object.
Een boek bestaat uit verschillende bladzijden. Elke bladzijde (of een combinatie van twee bladzijden) komt overeen met een canvas. Een canvas is met andere woorden het individuele vlak waarop één of meerdere beelden 'geplakt' worden. Een manifest is daarom vaak opgebouwd uit verschillende canvassen.
Een boek heeft ook hoofdstukken. Deze hoofdstukken kunnen worden gevat door het gebruik van een range. Een range brengt dus extra structuur aan in de canvassen.
Een boek kan tot slot ook onderdeel zijn van een bredere verzameling. Om dit te vatten, is het mogelijk binnen de IIIF-standaarden om een collection/collectie van manifesten te vormen.

Inhoud (bv. beeld, tekst) toevoegen aan een canvas gebeurt via annotaties. Zo kan je via de image API een beeld op een canvas aanbrengen. Ook annotaties kunnen extra gestructureerd worden. Annotaties kunnen samengenomen worden in een annotationpage. Meerdere pages vormen een annotationcollection.

Eigenschappen

Bij elk van deze types horen eigenschappen. Deze voegen informatie toe (bv. label, beschrijving, auteursrechteninfo). De Presentation API geeft voor elke eigenschap aan hoe deze gebruikt moet/mag worden.

Opgelet: Presentation API versie 3.0 is de huidige versie. In vergelijking met de vorige versie, 2.1, zijn enkele benamingen gewijzigd. Momenteel wordt gewerkt aan versie 4.0, gericht op de presentatie van 3D-modellen.

De eigenschappen worden ingedeeld in verschillende categorieën.

Beschrijvende eigenschappen

Beschrijvende eigenschappen beschrijven of vertegenwoordigen de bron/het artefact/het object waarmee ze geassocieerd zijn en worden ter duiding weergegeven aan de gebruiker. Beschrijvende eigenschappen zijn onder meer:

Label: de naam of de titel van het object.
Metadata: een geordende lijst met beschrijvingen die aan de gebruiker getoond moeten worden, via paren als ‘label’ en ‘value’. Bijvoorbeeld: ‘label’: Kunstenaar’ en ‘value’: "James Ensor (1860-1949)".
Summary > description in v2: een korte samenvatting of beschrijving van het object.
requiredStatement > attribution in v2: een korte tekst die moet worden weergegeven o.a. voor auteursrecht, de collectiehouder, fotograaf,…
rights > license in v2: een link (URL) naar een externe bron die de (hergebruik)licentie- of rechtenverklaring aangeeft. Hiervoor moet Creative Commons of RightsStatements.org gebruikt worden, tenzij de specifieke licentie met de kunstenaar online raadpleegbaar is.

Technische eigenschappen

Technische eigenschappen beschrijven de technische kenmerken van de bronnen en worden door de viewer verwerkt om te begrijpen hoe de bron moet worden weergegeven.

id > @id in v2: de effectieve link of URI die de bron identificeert.
type > @type in v2: type of klasse van de bron. Dit kan o.a. beeld, tekst, geluid of video zijn.
format: het specifieke mediatype (vaak een MIME-type genoemd) voor de bron, bijvoorbeeld image/jpeg.
language: de taal of talen die gebruikt worden in de inhoud van deze externe bron.

Linkende eigenschappen

Linkende eigenschappen zijn verwijzingen of links tussen bronnen, opgesplitst in externe en interne links:

Externe links waarbij het gelinkt object zich buiten de IIIF-ruimte bevindt.

homepage > related in v2: link naar een webpagina van het object.
service: link om extra informatie of functionaliteit te krijgen voor het gebruik van de bron.
seeAlso: link naar een machineleesbaar bestand dat het object beschrijft, bijvoorbeeld een XML-export van het record uit het collectiebeheersysteem.

Interne links waarbij het gelinkt object een IIIF resource is.

partOf > within in v2: link naar een IIIF-bron die deze bron bevat, kan gebruikt worden voor een object dat behoort tot een collectie. Bijvoorbeeld een prent uit een prentenreeks, een paneel uit een retabel,…
start > startCanvas in v2: link naar een Canvas of deel ervan om de gebruiker het beginpunt (de start) van de bron te tonen.
supplementary: link van een ‘Range’ naar een Annotation Collection die aanvullende annotaties van bronnen voor die ‘Range’ bevat. Bijvoorbeeld: de ‘Range’ vertegenwoordigt een aantal opeenvolgende bladen uit een schetsboek van George Minne die kunnen worden gelinkt aan een specifiek beeldhouwwerk van George Minne, terwijl andere bladen uit dat schetsboek niet aan dat specifieke beeldhouwwerk kunnen worden gelinkt.

Structurele eigenschappen

Structurele eigenschappen definiëren de structuur van het object om het mogelijk te maken om ‘child resources' in 'parents’ op te nemen bv. canvas in een Manifest of Manifest in een Collection. Meestal wordt 'items' gebruikt, maar er zijn 2 speciale gevallen voor verschillende soorten structuren.

Items: vastleggen van de volgorde waarin ‘child resources’ voorkomen binnen ‘parent’ bronnen, zoals Collection of Manifests binnen een parent Collection of Canvases binnen een Manifest. Een voorbeeld zou kunnen zijn: Een gedrukte encyclopedie (parent bron) kan gezien worden als een collectie van boeken (child resources). De encyclopedie (Collection) heeft verschillende boeken (manifesten) van de verschillende jaargangen (items). Elk boek (manifest) heeft verschillende pagina's van een specifieke jaargang (items). Elke pagina wordt op een apart canvas weergegeven.
Structures: structuur van een object dat als een Manifest wordt weergegeven, kan worden beschreven met behulp van een hiërarchie van Ranges. Bijvoorbeeld: Ranges kunnen worden gebruikt om de ‘inhoudsopgave’ van het object te beschrijven of andere logica’s of structuren waarmee de gebruiker kan navigeren buiten de volgorde die door de eigenschap ‘items’ van het Manifest wordt opgegeven.
Annotations: geordende lijst van Annotation Pages die commentaar of andere Annotaties over deze bron bevatten, los van de Annotaties die worden gebruikt om de inhoud op een Canvas te duiden. Bijvoorbeeld: overkoepelende notities over de restauratie van een manuscript terwijl het canvas telkens maar een pagina van het manuscript weergeeft en bij dat canvas enkel de transcriptie van de middeleeuwse tekst als annotatie is terug te vinden.

Annotaties

Annotaties bestaan steeds uit 3 karakteristieken: target, body en motivation (soms ook purpose genoemd).

Target: het item (of deel daarvan) waarop de annotatie betrekking heeft.
Body: de waarde van de annotatie zelf. Dit kan zowel een tekst (bvb een opmerking), een afbeelding (bvb een detailfoto van een schadegeval) of zelfs audio of video zijn.
Motivation (in sommige gevallen purpose): dit geeft de verhouding tussen de annotatie en het target weer. De mogelijke waarden hiervoor zijn ‘painting’ (gebruikt om de hoofdafbeelding aan te duiden), ‘supplementing’ (info over een hoofdafbeelding) en 'georeferencing' (toevoeging van geocoördinaten).

IIIF en metadata

IIIF is een set van standaarden voor de uitwisseling en presentatie van beelden. Deze focus en de brede waaier aan objecten die via IIIF beschikbaar worden gemaakt zorgen ervoor dat er geen sprake is van een uniforme invulling van de eigenschap 'metadata'. Elke instelling kan zelf beslissen welke informatie hieraan toegevoegd wordt. Het is daarom belangrijk om af te wegen welke informatie nuttig en/of noodzakelijk is binnen een IIIF-omgeving en welke daarbuiten op een efficiëntere manier gebruikt en beheerd kan worden.

In vele gevallen wordt er gekozen om een selectie van basisinformatie in het manifest op te nemen. Via het manifest zou het mogelijk moeten zijn om volgende vragen te beantwoorden. Bevat het manifest voldoende informatie

om het object in de presentatie eenduidig te identificeren?
om het object in de presentatie logisch te presenteren?
voor het rechtsgeldig hergebruik van de presentatie?

Tools

Een computertechnische kennis is belangrijk voor een volledige implementatie van de IIIF-API's. Dit betekent evenwel niet dat je niets kan uitvoeren zonder deze kennis. Vanuit de community worden verschillende tools ter beschikking gesteld. Deze kunnen onder meer helpen om inzicht te krijgen in de structuur van een IIIF-manifest.

Een overzicht van opensource tools en infrastructuur is te vinden via Awesome IIIF.

IIIF Manifest Editors

Een IIIF-Manifest Editor is een eenvoudige en gebruiksvriendelijke tool voor het schrijven van een manifest. De tool laat je toe via een template vooraf bepaalde velden te bewerken of in te vullen, én afbeeldingen/canvassen te ordenen of toe te voegen. En dat zonder enige voorkennis van JSON. Je kunt de gemaakte of gewijzigde manifesten valideren en downloaden om deze dan verder te gebruiken.

Om een bestaand manifest te wijzigen, uit te breiden of te bewerken, kan je deze in de editor openen. De reeds gebruikte velden zullen dan in de editor ingevuld verschijnen. Extra metadata toevoegen kan door zelf velden aan te vullen of extra velden toe te voegen. Als je een volledig nieuw manifest wil maken, moet je vooraf weten welke metadata je wil gebruiken en in welke velden je dit dan moet invullen. Daarom kan het handig zijn om eerst een bestaand manifest te openen en als inspiratiebron te bekijken. Voor eenvoudige werken en in kleine hoeveelheden kan dat werken, bij complexere werken en meerdere gelijkaardige soorten manifesten lijkt “machinaal” werken via een script meer aangewezen.

Bodleian Manifest Editor

De Bodleian IIIF-Manifest Editor is een vrij eenvoudige en duidelijke editor, opgevat als een grote template waarbij je niet moet wakker liggen van ingewikkelde codes. De Bodleian IIIF-Manifest Editor is handig als kennismakingsinstrument om IIIF en IIIF-manifesten beter te begrijpen.

Let op! Voor het openen van de manifesten zijn er twee versies, naargelang de url van je manifest http of https bevat: http-versie (via text and bytes) en https-versie (via the Bodleian). Uitgebreide info vind je in de User Manual.

Standaard levert de editor Presentation v2 manifesten aan. Dat merk je ook aan de voorgestelde velden, “Predefined Fields”, zoals ‘Description’, ‘Attribution’ en ‘License’ die in versie 3 andere benamingen hebben. Versie 3 (v3) is wel via dezelfde url beschikbaar maar hiervoor moet je ‘content negotiation’ gebruiken, wat dan weer niet zo eenvoudig is, laat staan foutloos werkt.

Open Manifest

Wil je vertrekken vanuit een bestaand manifest, dan zijn er verschillende opties:

via drag & drop,
via een lokaal bestand op je computer,
via een url,
via ‘discover manifest’ (hier krijg je een lijst van instellingen waar je manifesten kan ophalen, bekijken of zelfs aanpassen)

New Manifest

Wil je een nieuw manifest aanmaken, dan volg je onderstaande stappen.

Links onderaan klik je op ‘+ Add Canvas’ en daarna op ‘empty canvas’.
Open het tabblad ‘Canvas Metadata’. Via ‘+ Add Image to Canvas’ kan je een beeld toevoegen naar eigen keuze of naargelang de plaats waar het beeld staat opgeslagen. *Daarna vul je de velden van het Canvas verder in en voeg je extra canvassen toe (voor complexe werken).
Vergeet tot slot niet de andere tabbladen en velden, in het bijzonder de ‘Manifest metadata’, in te vullen.

Bij ‘Manifest Metadata – Custom Fields’ vind je ‘+ Add metadata’ en ‘+ Add language metadata’. Als je meerdere talen wil gebruiken moet je de ‘+ Add language metadata’ kiezen, waarbij je ook de taalkeuze kan instellen. Merk op dat de ‘Manifest URI’ reeds standaard is ingevuld en je dit niet kan wijzigen. Bij ‘license’ staat een link van CreativeCommons ingevuld. Het is belangrijk te checken of dit klopt met de reële rechtenstatus en het beeldbeleid dat binnen jouw organisatie wordt opgezet.

Via ‘Bulk Actions’ kan je o.a. automatisch meerdere canvassen in een keer een andere naam geven. Je ziet ook twee sub-tabbladen ‘Predefined Fields’ en ‘Custom Fields’. ‘Predefined fields’ zijn een aantal standaard velden. ‘Custom fields’ zijn velden die je zelf kan toevoegen afhankelijk van de metadata die je wil gebruiken.

Bovenaan heb je ook nog een dropdown menu ‘Manifest Actions’, waar je eventueel je manifest kan valideren of canvassen kan importeren. Helemaal bovenaan bij ‘Save Manifest’ kan je, niet te vergeten, je manifest bewaren (via download of online bewaren (op een gekozen server)).

Per item heb je ook telkens een (?) waar je meer info kan vinden.

Digirati Manifest Editor

De IIIF-Manifest Editor van Digirati werkt op een gelijkaardige wijze als de Bodleian editor. Een belangrijk voordeel van de Digirati-Editor is wel dat deze IIIF-Presentation v3-manifesten oplevert. Dat merk je niet alleen aan de voorgestelde v3-velden (‘Summary’, ‘RequiredStatement’, ‘Rights’), maar ook aan de mogelijkheid om naast beelden ook video en audio toe te voegen.

Via plugins kan de editor bovendien worden uitgebreid om manifesten te maken met specifieke structuren en bijgevolg een aangepaste presentatie op te zetten. De slideshows van het V&A Museum en de complexere digitale tentoonstellingslay-outs van het Delft Museum zijn daar voorbeelden van. Dergelijke presentaties zijn extra troeven in functie van contentcreatie voor digitale storytelling.

Links voor online Digirati Editor:

Deze online versie heeft als nadeel dat het niet zo handig is om alle velden gemakkelijk ingevuld te krijgen. Dit is voornamelijk te wijten aan de scroll-functie die in de browser niet (goed) lijkt te werken.
Deze online versie werkt beter, hoewel het ingeven van de image url ook niet altijd zo vlot verloopt.

Omzetapplicatie Prezi-2-to-3

Veel manifesten die momenteel ter beschikking worden gesteld zijn gebaseerd op Presentation v2 API en nog niet op v3. Daarom werd er een converter ontwikkeld om manifesten automatisch te upgraden van v2 naar v3. Deze converter werkt zeker nog niet foutloos. Her en der zie je dat er toch verschillende problemen worden vermeld.

Via Prezi-2-to-3 kan je een manifest automatisch upgraden van IIIF Presentation API v2 naar v3. Deze bibliotheek is een directe javascript port van de IIIF prezi-2-to-3 en converteert JSON-LD-documenten van IIIF Presentation v2 naar v3. Er zijn drie mogelijkheden om de omzetapp te gebruiken: via Docker, lokaal geïnstalleerd of programmatisch. Wij kozen voor Docker en volgden de instructies voor “Using Docker”.

Bij ‘URL of Manifest to convert’ typ je de url van het te converteren manifest. Bij ‘Default Lang’ staat standaard ‘@none’, dat vervang je best door een taalkeuze: ‘nl’ of ‘en’. Wanneer je ‘@none’ niet aanpast, riskeer je bij het valideren van je nieuwe v3-manifest hiervoor een foutmelding te krijgen.

De conversie werkt behoorlijk, maar bij het valideren van je manifest zijn ‘errors’ zeker niet uitgesloten.

Tijdens de conversie worden velden met metadata uit v2 soms ook overgenomen in v3 die daar echter niet meer geldig zijn of op een andere manier opgebouwd worden en zo een foutmelding geven. Als je dit wil oplossen, zal dat handmatig moeten gebeuren en is toch wel enige kennis en inzicht in manifesten en code nodig.
Het gebruik van meerdere talen blijft een moeilijk verhaal.

De tool kan een optie zijn om een aantal manifesten om te schakelen naar v3, maar het blijft wel eerder een tussenoplossing. Voor nieuwe projecten is het aan te raden om vanaf de basis met API’s versie 3 te werken.

Voorbeelden

Heb je eigen manifesten gevormd, dan kan je nagaan hoe de beelden en metadata in een viewer gepresenteerd worden. Deze presentatie verschilt voor diverse types objecten. Hieronder zijn enkele voorbeelden te vinden.

Het is de bedoeling dat dit overzicht wordt aangevuld met representatieve voorbeelden. Heb je dus zelf een voorbeeld, stuur dan zeker een mail naar rein.debrulle@meemoo.be.

Schilderij

Het eerste voorbeeld komt uit de collectie van het Museum voor Schone Kunsten in Gent. De manifesten (zowel versie 2 als versie 3) worden automatisch gevormd via de VKC-imagehub.

De JSON-bestanden van dit manifest vind je hier:

Sculptuur

Het tweede voorbeeld is een sculptuur van de heilige Cornelius, uit de collectie van de Musea Brugge. Dit manifest bestaat niet uit één, maar uit meerdere beelden. De beelden tonen hetzelfde werk uit verschillende standpunten.

De JSON-bestanden van dit manifest vind je hier:

Prentenreeks

Het derde voorbeeld is een prentenreeks van James Ensor met de naam 'De 7 hoofdzonden'. Ditmaal bestaat het manifest uit meerdere, verschillende beelden. Er is geen duidelijke volgorde.

De JSON-bestanden van dit manifest vind je hier:

Tekeningenreeks

Het vierde voorbeeld is een tekeningenreeks over Reinaert de Vos, gemaakt door Gustave Van de Woestyne. Ook hier zijn meerdere beelden opgenomen in het manifest, maar deze zijn wel gepresenteerd in een specifieke volgorde.

Het JSON-bestand van dit manifest vind je hier:

Versie 2

Schetsboek

Als vijfde voorbeeld is gekozen voor een schetsboek van George Minne. Dit schetsboek is een ideaal voorbeeld om aan te tonen hoe aan de hand van het 'viewingHint' (v2) keyword kan bepaald worden op welke manier een samengesteld werk gepresenteerd moet worden. In eerdere voorbeelden zoals de prentenreeks, werden de delen van het samengesteld werk steeds individueel weergegeven, wat de standaard-waarde van het 'viewingHint' keyword is. Door in het manifest bij 'viewingHint' 'paged' te gebruiken, visualiseert de viewer het schetsboek in boekvorm, waarbij steeds 2 pagina's naast elkaar getoond worden. De enige uitzondering hierop is de eerste pagina die wel individueel weergegeven wordt, aangezien dit de kaft van het boek betreft.

Het JSON-bestand van dit manifest vind je hier:

Versie 2

Altaarretabel

Dat de IIIF standaard ook gebruikt kan worden om complexe werken zoals het Lam Gods te visualiseren, wordt aangetoond met dit voorbeeld. Alle panelen zijn voorzien van een annotatie. Deze kunnen via Mirador gepresenteerd worden. Zo kan je dus ook in een complex beeld structuur aanbrengen zonder daarbij ieder beeld als een apart canvas op te nemen.

Het JSON-bestand van dit manifest vind je hier:

Versie 3

IIIF op je eigen website?

Wil je zelf ook een voorbeeld creëren en toevoegen aan je eigen website? Dat kan, maar de ene viewer vraagt al wat meer computertechnische kennis dan de andere.

Universal viewer

Universal Viewer voorziet een share-knop. Hier kan je niet alleen het IIIF-manifest en de URL naar de viewer vinden. Onder de optie 'Embed' wordt een iframe-tag voorzien. Kopieer je deze tag en plak je deze in een websitebouwer, dan verschijnt de Universal Viewer op jouw website.

Mirador Viewer

De Mirador Viewer is een complexer geval. Een integratie gebeurt niet via iframe, maar via de toevoeging van meer uitgebreide code. Dit vraagt daarom om computertechnische ondersteuning. Tegelijk betekent dit ook wel dat de configuratiemogelijkheden een stuk uitgebreider zijn. Documentatie over deze integratie is te vinden op GitHub.

Andere viewers

Er bestaan ook nog andere viewers. Een overzicht is te vinden via de IIIF Awesome List. Bij elke viewer is een verwijzing te vinden naar de projectpagina. Daarop staat doorgaans de documentatie die nodig is om de viewer te gebruiken en te integreren.

Use case: multilayering

De bovenstaande voorbeelden geven een beeld van enkele mogelijkheden van IIIF voor verschillende use cases. Het aantal use cases is evenwel uitgebreider dan dat. Een overzicht van officiële 'recepten' vind op de IIIF website.

Een interessante mogelijkheid uit dit overzicht is de presentatie van meerdere beelden in dezelfde weergave (canvas), ook multilayering genoemd. Dit gebeurt via het itemtype 'Choice' dat aan het IIIF-manifest wordt toegevoegd. Zo wordt het bijvoorbeeld mogelijk om verschillende weergaves (infrarood, ultraviolet, X-ray) van eenzelfde schilderij boven elkaar te presenteren.

Een voorbeeld van dit type manifest vind je hier.

Enkel Mirador en Annona ondersteunen vandaag deze meerlagige presentatie. De OpenSeaDragon viewer heeft standaard geen ondersteuning voor het weergeven van meerlagigheid, maar er bestaan extensies van de basis viewer die dit wel toelaten. Een voorbeeld hiervan is de Curtain-Sync extensie, die in essentie 2 view modes toevoegt aan de viewer, namelijk curtain view en synchronized view.

Use case: meertaligheid

IIIF zet in op uitwisselbaarheid en interoperabiliteit. Dit betekent onder meer dat binnen deze standaarden aandacht gaat naar het faciliteren van meertalige metadata. Alle data die bedoeld zijn om gepresenteerd te worden aan gebruikers kunnen met andere woorden in verschillende talen in een manifest opgenomen worden.

Presentation API 2.1

Binnen Presentation API 2.1 kan deze meertaligheid van gepresenteerde metadata worden bekomen door de toevoeging van “@language” en een ‘language tag’, gevormd volgens de afspraken in RFC 5646. Deze afspraken maken het mogelijk om een taal, schrift, regio, variant, … via een internationaal afgesproken ‘code’ te identificeren.

Voorbeelden van deze ‘language tag’ zijn:

‘de’ (Duits), ‘fr’ (Frans), ‘en’ (Engels)
‘en-US’ (Engels zoals gebruikt in de Verenigde Staten)
‘zh-Hans-CN’ (Chinees, geschreven in het vereenvoudigd schrift zoals gebruikt op het Chinese vasteland)

Deze toevoeging kan enkel gebeuren bij de eigenschappen “label”, “description”, “attribution” en alle labels en waarden onder de eigenschap “metadata”. De combinatie “@language” en een ‘language tag’ dient daar telkens voor de “@value” toegevoegd te worden, gescheiden door een komma.

Hieronder vind je een voorbeeld in JSON-formaat:

"metadata": [
{"label": [
{ "@language": "en",
"@value": "Creator"},
{"@language": "nl",
"@value": "Vervaardiger"},
{"@language": "fr",
"@value": "Créateur"},
{"@language": "de",
"@value": "Hersteller"}],
"value": "Ensor, James"},

Door meerdere talen op te nemen in het manifest wordt het mogelijk om bij een viewer alle componenten van de user interface in meerdere talen aan te bieden. Niet alle viewers ondersteunen echter alle talen. Daardoor is het mogelijk dat eenzelfde manifest, met meertalige velden, in verschillende viewers anders wordt gepresenteerd.

Het aangepaste manifest van onderstaand voorbeeld is hier terug te vinden. (De taal kan je wijzigen via het tandwiel in de linker kolom.)

Presentation API 3.0

Binnen Presentation API 3.0 is het verplicht om bij elke vrije tekst die bedoeld is voor presentatie de taal te specificeren. Dit betekent dat de eigenschappen “label”, “summary”, “requiredStatement” en alle labels en waarden onder “metadata” van een taal moeten worden voorzien. Dit gebeurt via een JSON sleutel/waarde-paar (key/value pair, zie voorbeeld hieronder), met als sleutel een code gevormd volgens de afspraken in BCP 47. Deze afspraken zijn een combinatie van de documenten RFC 4647 en RFC 5646.

Hieronder vind je een voorbeeld in JSON-formaat (“en” = key; ["Attribution"] = value):

"requiredStatement": {"label": {"en": ["Attribution"],"nl": ["Naamsvermelding]},

Opgelet!

Is de taal niet bekend of niet van toepassing (bv. bij een eigennaam), dan wordt als sleutel “none” gebruikt.
Deze werkwijze voor meertaligheid geldt niet voor opgenomen tekst in annotaties. Annotaties volgen de afspraken van het Web Annotation Data Model. Dit betekent dat de taal in een aparte eigenschap (“language”) wordt aangegeven.
Niet alle viewers ondersteunen alle mogelijke talen. Universal Viewer biedt bijvoorbeeld Engels en Frans aan, maar geen Nederlands of Duits. Ook TIFY biedt niet de mogelijkheid om de taal te wijzigen. Zelfs als vertalingen van labels wel in het manifest zijn opgenomen, worden deze daardoor soms niet getoond (zie bijvoorbeeld de Universal Viewer hieronder).

Het aangepast manifest van onderstaand voorbeeld is hier terug te vinden.

Verwerking door viewers

De informatie die in een manifest opgenomen is, wordt door viewers zoals Mirador, Universal Viewer, Tify, … verwerkt om deze logisch te presenteren. Die verwerking gebeurt in principe op basis van voorgeschreven ‘algoritmes’. Een inzicht in die algoritmes is belangrijk om in te schatten hoe de eigen manifesten gepresenteerd zullen worden.

Voor de verwerking van de meertaligheid wordt vanuit de IIIF-Community het volgende algoritme opgelegd:

Als alle waarden gekoppeld zijn aan de “none”-sleutel moeten al deze waarden door de viewer getoond worden
Is dit niet het geval, dan moet de viewer trachten de taalvoorkeur van de gebruiker te achterhalen (bv. via cookies) of een bepaalde taal als standaardinstelling gebruiken.
- De viewer moet dan alle waarden tonen die verbonden zijn met de taal die het beste bij de taalvoorkeur of de standaardinstelling aansluit.
- Als alle waarden in het manifest met een taal verbonden zijn, maar geen enkele taal aansluit bij de taalvoorkeur of de standaardinstelling, moet de viewer één taal selecteren en alle waarden die daarmee verbonden zijn presenteren.
- Als maar een deel van de waarden in het manifest met een taal verbonden is en geen enkele taal aansluit bij de taalvoorkeur, moet de viewer alle waarden tonen die niet met een taal verbonden zijn.

Bronnen

“IIIF Presentation API 3.0 - Language of Property Values.” International Image Interoperablity Framework. Geraadpleegd op 10.05.2023. https://iiif.io/api/presentation/3.0/#language-of-property-values.

“Internationalization and Multi-language Values.” International Image Interoperablity Framework. Geraadpleegd op 10.05.2023. https://iiif.io/api/cookbook/recipe/0006-text-language/.

Meer over IIIF

In de volgende artikels leer je meer over specifieke mogelijkheden van IIIF:

Publicatie:IIIF-metadatahandboek

IIIF for dummies

Waarom IIIF?

Standaarden en API's

IIIF-bronnen gebruiken

IIIF-manifest

Structuur

Eigenschappen

Beschrijvende eigenschappen

Technische eigenschappen

Linkende eigenschappen

Structurele eigenschappen

Annotaties

IIIF en metadata

Tools

IIIF Manifest Editors

Bodleian Manifest Editor

Digirati Manifest Editor

Omzetapplicatie Prezi-2-to-3

Voorbeelden

Schilderij

Sculptuur

Prentenreeks

Tekeningenreeks

Schetsboek

Altaarretabel

IIIF op je eigen website?

Universal viewer

Mirador Viewer

Andere viewers

Use case: multilayering

Use case: meertaligheid

Presentation API 2.1

Presentation API 3.0

Verwerking door viewers

Bronnen

Meer over IIIF

Navigatiemenu

Zoeken