Deliverable

Project: IIIF-beeldinfrastructuur gekoppeld aan de VKC-Datahub. Fase 1: proefopstelling Werkpakket: WP2 Selectie van IIIF-compatibele componenten Subsidie: Projectsubsidie voor een internationaal cultureel-erfgoedproject Periode: 2 juli 2018 - 31 augustus 2019

D2: Bestek van de IIIF Proefopstelling Auteur: Matthias Vandermaesen (VKC)

1

Datum Versie Informatie

2.04.2019 0.1 Initiële versie.

2

Deliverable .................................................................................................................................... 0

D2: Bestek van de IIIF Proefopstelling ......................................................................................... 0

Situering .................................................................................................................................... 2

Doelstellingen ........................................................................................................................ 3

Timing .................................................................................................................................... 3

Het VKC ecosysteem ................................................................................................................ 3

Overzicht ............................................................................................................................... 3

Infrastructuur ......................................................................................................................... 5

Beheer ................................................................................................................................... 5

Ontwikkeling .......................................................................................................................... 5

International Image Interoperability Framework ........................................................................ 6

Overzicht ................................................................................................................................... 6

Infrastructuur ............................................................................................................................. 6

ImageHub .................................................................................................................................. 6

IIIF Image API ........................................................................................................................ 7

IIIF Presentation API ............................................................................................................. 8

IIIF Authentication API ......................................................................................................... 16

Het beheer van gebruikers .................................................................................................. 16

Het beheer van beelden ...................................................................................................... 18

Statische pagina’s ............................................................................................................... 20

Arthub Flanders ....................................................................................................................... 20

Integratie van een IIIF viewer .............................................................................................. 21

Meertaligheid ....................................................................................................................... 21

Operationalisering ............................................................................................................... 22

Situering De Vlaamse Kunstcollectie lanceerde in 2018 Arthub Flanders. Op dit gezamenlijke platform ontsluit ze de collecties van de musea voor beeldende kunsten voor een publiek van museale medewerkers, studenten, onderzoekers en internationale musea. De ontsluiting gaat verder dan het louter aanbieden van de registratiegegevens via een zoekmachine. Arthub Flanders biedt de registratiegegevens ook aan in XML en JSON formaten als open data via deze catalogus en een duurzame digitale onderbouw.

3

Zie: https://arthub.vlaamsekunstcollectie.be

Naast het ontsluiten van data, wensen de Vlaamse Kunstcollectie en haar museale partners ook digitaal beeldmateriaal van hoogwaardige kwaliteit online te delen. Daartoe willen ze in de infrastructuur die Vlaamse Kunstcollectie bouwt en onderhoud, een nieuwe toepassing introduceren die zal toelaten om beeldmateriaal te publiceren via het International Image Interoperability Framework of IIIF. Dit framework is een internationale standaard die de publicatie van gedigitaliseerd beeldmateriaal van culturele en erfgoedobjecten in digitale toepassingen stroomlijnt. De ontsluiting van het beeldmateriaal naar het doelpubliek van Vlaamse Kunstcollectie zal gebeuren via Arthub Flanders en diverse andere digitale kanalen.

Deze toepassing wordt gebouwd binnen het kader van een binnen het Vlaamse erfgoeddecreet gesubsidieerd project getiteld “IIIF-beeldinfrastructuur gekoppeld aan de VKC-Datahub: Fase 1”

Doelstellingen

Dit bestek omschrijft deze toepassing als een proefopstelling waarbij op basis van reeds bestaande technische componenten, een toepassing wordt gebouwd die de ontsluiting van 200 digitale beelden mogelijk moet maken.

Het project wordt gedragen door Vlaamse Kunstcollectie en een aantal partners. Het gaat om volgende spelers, en hun doelstellingen:

Vlaamse Kunstcollectie wenst via Arthub Flanders digitale beelden van werken open een uniforme, open, gecontroleerde, kwalitatieve en gebruiksvriendelijke wijze te publiceren voor hergebruikers van museale content. Daartoe zet ze in op de operationalisering van het IIIF framework.

PACKED-VIAA-LUKAS wenst in de toekomst de archivering en ontsluiting van gedigitaliseerd beeldmateriaal in haar dienstverlening op te nemen. De organisatie wil onderzoeken welke technische oplossingen hiervoor in aanmerking zouden kunnen komen. Aan de hand van een aantal business cases wenst ze de diverse noden, vereisten, uitdagingen en valkuilen in kaart te brengen. Arthub Flanders is een van deze business cases.

Timing De implementatie en het operationeel stellen van de proefopstelling dient te gebeuren in de periode 1 april - 30 juni 2019

Het VKC ecosysteem

Overzicht Sinds 2015 werkt Vlaamse Kunstcollectie, in nauwe samenwerking met PACKED, aan de modernisering van haar digitale ecosysteem. Op basis van dit ecosysteem biedt ze een diverse dienstverlening in functie van de noden en wensen van haar partnermusea.

4

Dit digitale ecosysteem bestaat uit een aantal toepassingen of “digitale vensters” voor eindgebruikers:

● Arthub Flanders (https://arthub.vlaamsekunstcollectie.be) ● De Koepelwebsite (http://www.vlaamsekunstcollectie.be) (geplande vernieuwing) ● Thematische websites

○ Barok in Vlaanderen (http://barokinvlaanderen.vlaamsekunstcollectie.be/nl) ○ Vlaamse Primitieven (http://vlaamseprimitieven.vlaamsekunstcollectie.be/nl) ○ Abstract Modernisme (https://abstractmodernisme.vlaamsekunstcollectie.be/nl) ○ James Ensor (http://jamesensor.vlaamsekunstcollectie.be/nl) ○ Pieter Brueghel (in ontwikkeling)

Daarnaast ontsluit de Vlaamse Kunstcollectie de gezamenlijke catalogus via een aantal internationale platformen:

● Europeana (https://europeana.eu) ● Wikidata (https://wikidata.org)

Centraal in deze modernisering staat de bouw van een duurzame onderbouw die gegevens via gestandaardiseerde protocollen en formaten uit de collectieregistratiesystemen van de musea uitwisselt met de hierboven genoemde toepassingen.

Technisch bestaat deze onderbouw uit een Datahub toepassing die de uitwisseling van registratiegegevens tussen de collectieregistratiesystemen en de toepassingen voor eindgebruikers operationaliseert via een aantal API’s. De uitgewisselde gegevens worden gemodelleerd volgens het LIDO XML formaat.

● http://datahub.vlaamsekunstcollectie.be ● http://lido-schema.org

De geautomatiseerde uitwisseling van de registratiegegevens gebeurt door middel van diverse ETL-pipelines (Extract, Transform Load). Vlaamse Kunstcollectie zet Catmandu in om deze pipelines te realiseren.

● http://www.librecat.org

In 2018 lanceerde Vlaamse Kunstcollectie samen met PACKED een Dashboard toepassing. Deze toepassing is een monitor voor de kwaliteit van de registratiegegevens die via de Datahub worden ontsloten. Via een aantal parameters wordt de digitale bruikbaarheid van de gegevens gemeten en in kaart gebracht.

● http://dashboard.vlaamsekunstcollectie.be

Daarnaast beheert Vlaamse Kunstcollectie een eigen installatie van het collectieregistratiesysteem CollectiveAccess. Deze installatie bevat registratiegegevens die via

5

de collectiepresentatie op de diverse thematische websites worden ontsloten. Het gaat om gegevens die niet alleen worden aangeleverd door de museale partners, maar ook door andere, internationale musea, bibliotheken, archieven,...

Tenslotte beheert Vlaamse Kunstcollectie ook een aantal resolvers. Deze toepassing verwijst de bezoeker van een persistent URI door naar op het Web ontsloten registratiegegevens over een specifiek object. Vlaamse Kunstcollectie gebruikt persistente URI’s binnen het ecosysteem om objecten en informatie uniek te identificeren en terug te vinden.

Infrastructuur

Vlaamse Kunstcollectie least infrastructuur bij VIAA-PACKED-LUKAS voor het hierboven geschetste digitale ecosysteem. Deze infrastructuur bestaat uit een aantal VPS (virtual private server) installaties waarop de toepassingen zijn uitgerold:

● 2 x VPS (QA en Productie) ○ Thematische websites ○ CollectiveAccess

● 2 x VPS (QA en Productie) ○ Datahub ○ Dashboard ○ Arthub Flanders ○ ETL pipelines op basis van Catmandu

● 1 x VPS ○ Resolvers

Beheer

Het operationele beheer van de VPS installaties waar Arthub Flanders, de Datahub, de diverse ETL pipelines en de Thematische websites op werden uitgerold, is uitbesteed aan Inuits BVBA. Het operationele beheer van de VPS met de resolver installaties is de verantwoordelijkheid van de Vlaamse Kunstcollectie.

Ontwikkeling

De ontwikkeling en het onderhoud van de thematische websites en CollectiveAccess is uitbesteed aan Inuits BVBA.

De initiële ontwikkeling de Datahub en Arthub Flanders gebeurde door Inuits BVBA. Het verdere onderhoud gebeurt door Vlaamse Kunstcollectie.

De ontwikkeling en het onderhoud van de ETL pipelines wordt volledig gedragen door Vlaamse Kunstcollectie

De ontwikkeling van de resolver toepassing gebeurde door PACKED. Vlaamse Kunstcollectie voorziet de verdere operationalisering van de installaties in opdracht van haar partners.

6

International Image Interoperability Framework IIIF of International Image Interoperability Framework is een gestandaardiseerde specificatie die beschrijft hoe beeldmateriaal via het Web uitgewisseld kan worden door gebruik te maken van open, gestandaardiseerde formaten en protocollen die fundamenteel zijn voor de werking van het Web. Het biedt een set van standaard APIs aan die als doel hebben de metadata van beelden te beschrijven en mee aan te leveren met die beelden (IIIF Representation API), en een API die zorgt voor de interoperabele aanlevering van beelden zelf (Image API). Daarbij zijn er nog twee optionele APIs, de Authentication en de Search API. De Presentation en Image APIs kunnen gelezen en geïnterpreteerd worden door een aantal verschillende viewers, waarvan wij graag de Universal Viewer zouden willen implementeren.

Overzicht De proefopstelling bestaat uit verschillende componenten. Er is een server waarop digitaal beeldmateriaal wordt gehost. Dit beeldmateriaal wordt op het Web gepubliceerd via web services waarvan de specificaties zijn gedefinieerd in het International Image Interoperability Framework (IIIF).

Deze IIIF compliant web services kunnen worden aangesproken door IIIF compliant clients. In het bijzonder door in Javascript geïmplementeerde “viewers” en “zoom tools” die embedded kunnen worden op websites. Binnen de context van de proefopstelling wordt een dergelijke viewer geïntegreerd in het Arthub Flanders platform. Deze viewer communiceert met de IIIF compliant web services, haalt relevant beeldmateriaal op en geeft deze weer op het Arthub Flanders platform.

In deze sectie geven we een beknopt overzicht van de te bouwen componenten.

Infrastructuur De volledige proefopstelling wordt geïnstalleerd op een VPS of virtual private server welke wordt aangeleverd door VIAA. Alle software componenten worden geïnstalleerd en geconfigureerd op deze virtuele machine. Tevens wordt een kopie van de relevante beeldbestanden op deze machine gehost.

ImageHub De ImageHub is een component die de volledige proefopstelling aanstuurt. Functioneel is de ImageHub verantwoordelijk voor:

● Het ontsluiten van metadata gerelateerd aan het beeld per de IIIF Presentation API specificatie versie 2.1

● Het gecontroleerd afschermen van de toegang tot beeldmateriaal per de IIIF Authentication API versie 2.1

7

● Het geautomatiseerd verwerken en ontsluiten van beeldmateriaal op basis van registratiegegevens die als LIDO records worden gepubliceerd via een publieke endpoint.

● Een administratieve module die de manuele ingest van beeldmateriaal via een gebruiksvriendelijke interface.

● Een administratieve module die het toegangsbeheer van het beeldmateriaal in functie van de IIIF Authentication API mogelijk maakt.

● Een administratieve module voor het beheer van geauthenticeerde gebruikers.

De ImageHub is een web-gebaseerde, database-driven toepassing gebouwd op basis van Symfony (PHP) met een databank backend. De voorkeur wordt hier gegeven aan MongoDB aangezien dit DBMS reeds in de technology stack van Vlaamse Kunstcollectie operationeel wordt ingezet.

Het is geenszins de bedoeling om een volwaardig DAM (Digital Asset Management) systeem te bouwen. De focus van dit prototype ligt volledig op de ontsluiting van beeldmateriaal via het IIIF framework.

IIIF Image API IIIF Image API is een document dat een API beschrijft voor het leveren van digitale beelden volgens het International Image Interoperability Framework. De IIIF Image API specificeert een webservice die een afbeelding retourneert als antwoord op een standaard HTTP- of HTTPS-verzoek. De URI kan de regio, de grootte, de rotatie, de kwaliteitskenmerken en het formaat van de gevraagde afbeelding specificeren.

Een URI kan ook worden geconstrueerd om technische basisinformatie over het beeld op te vragen ter ondersteuning van clienttoepassingen. Deze API is ontworpen om systematisch hergebruik van beeldmiddelen in digitale beeldopslagplaatsen die worden onderhouden door culturele erfgoedorganisaties te vergemakkelijken. De API kan door elke beeldopslagplaats of dienst worden overgenomen en kan worden gebruikt om statische beelden op te halen als reactie op een goed geconstrueerde URI.

Zie: https://iiif.io/api/image/2.1/

Er bestaat een ruime waaier aan IIIF Image API server software. Voor deze proefopstelling werd gekozen om Cantaloupe te operationaliseren op de VPS.

Zie: ttps://github.com/IIIF/awesome-iiif#image-servers

Zie: https://github.com/medusa-project/cantaloupe/

Verwachte acties:

● Installatie en configuratie van Cantaloupe. ● Opslag van 200 digitale beeldbestanden op het bestandssysteem van de VPS

Verwacht resultaat:

8

● Beeldbestanden worden publiek ontsloten op het Web volgens de IIIF Image API specificatie.

IIIF Presentation API Dit document beschrijft hoe de structuur en lay-out van een complex beeldobject op een standaard manier beschikbaar kan worden gesteld. Er kunnen veel verschillende stijlen van viewer worden geïmplementeerd die de informatie verbruiken om een rijke en dynamische ervaring mogelijk te maken, waarbij content uit verschillende collecties en hosting instellingen wordt geconsumeerd. Tegelijkertijd kan de Presentation API ook een beperkte set beschrijvende metadata meegeven over het beeld/de beelden, zoals titel, vervaardiger, persistent URI van het werk, auteursrechtelijke info etc.

Een object kan bestaan uit een reeks pagina's, oppervlakken of andere weergaven; bijvoorbeeld de enkele weergave van een schilderij, de twee zijden van een foto, vier kardinale weergaven van een beeld, of de vele pagina's van een editie van een krant of boek. De belangrijkste vereisten voor de IIIF Presentatie API zijn het geven van een opdracht voor deze weergaven, de middelen die nodig zijn om een weergave van de weergave weer te geven, en de beschrijvende informatie die nodig is om de gebruiker in staat te stellen te begrijpen wat er gezien wordt.

Zie: https://iiif.io/api/presentation/2.1/

Het genereren van een IIIF manifest bestand per beeld De ImageHub voorziet een proces dat bestaat uit een (of meerdere) script(s) of command(s) dat toelaat om op basis van een aantal databronnen, een zogenaamd IIIF manifest bestand te genereren. De technische commando’s of scripts op de VPS worden ingesteld als een cron job die regelmatig (elke dag, elke week) als een geautomatiseerd proces wordt uitgevoerd.

Een IIIF manifest bestand is een JSON document waarvan het schema beantwoordt aan de IIIF Presentation API specificatie. Per beeldbestand die via de IIIF Image API wordt ontsloten, dient er een dergelijk IIIF manifest bestand te worden aangemaakt.

Het gehele proces om een IIIF manifest bestand te genereren bestaat uit verschillende stappen:

1. Discovery van beeldbestanden a. Lees de directory op het bestandssysteem uit en lijst alle bestanden op. b. Valideer elk bestand. c. Haal ingebedde metadata uit de bestanden (EXIF of TIFF tags).

2. Haal op basis van de uit de beeldbestanden geëxtraheerde metadata inhoudelijke en technische metadata op uit drie databronnen:

a. Via de Datahub worden inhoudelijke registratiegegevens uit de collecties ontsloten. De gegevens zijn geformatteerd in het LIDO XML formaat.

i. Zie: http://datahub.vlaamsekunstcollectie.be b. Via de IIIF Image API wordt er een aantal technische gegevens ontsloten.

9

i. I.e. http://www.example.org/image-service/abcd1234/info.json (domeinnaam & service naam nog te bepalen)

3. Injecteer extra metadata uit aparte databronnen in de LIDO records. Concreet gaat het om:

a. Vertalingen van titel, korte beschrijving en periode b. De auteursrechtelijke status op gestructureerde wijze geformuleerd. c. De relaties tussen objecten.

4. Compileren van een IIIF manifest document per beeld a. De metadata uit de drie bronnen wordt door het proces gecompileerd in tot een

IIIF manifest document per beeld. Dit document is gestructureerd als een JSON object waarvan het schema moet conformeren aan de IIIF Presentation API specificatie.

5. Storage van het IIIF manifest document per beeld a. Het proces schrijft het gegenereerde IIIF Manifest document weg als een aparte

record naar de databank van de toepassing. b. De record in de databank kan worden geïdentificeerd op basis van de persistente

identifier (of PID) die zowel in de beeldbestanden wordt ingebed als in de LIDO metadata aanwezig is.

c. Indien er op het niveau van de databank reeds een record bestaat met dezelfde identificatie, overschrijf deze dan integraal met het gegenereerde IIIF manifest document.

Bij het genereren van de verschillende artefacten - manifests, canvasses en sequences - moet de IIIF Presentation API specificatie worden gevolgd.

Zie: https://iiif.io/api/presentation/2.1

Het genereren van een IIIF Manifest bestand met verschillende beelden. In een aantal gevallen zijn beelden inhoudelijk aan elkaar gerelateerd. Het gaat om beeldmateriaal dat ontstond door de digitalisering van individuele onderdelen van een groter geheel (i.e. pagina’s in een schetsboek, de verschillende luiken van een veelluik, een reeks van schilderijen,...). Het IIIF framework voorziet de modellering van dergelijke relaties in 1 IIIF Manifest bestand via ‘sequences’ en ‘canvases’.

Zie: https://iiif.io/api/presentation/2.1/#primary-resource-types

Zie: http://ronallo.com/iiif-workshop/presentation/canvas.html

De relaties tussen de individuele onderdelen en het grotere geheel wordt geregistreerd in de museale data. De LIDO XML records die via de Datahub worden ontsloten bevatten relevante velden waarin deze relaties worden geregistreerd.

De ImageHub toepassing voorziet een tweede proces bestaande uit een of meerdere scripts of commando’s. Dit proces zal op basis van de informatie in de LIDO records, de relaties tussen verschillende beelden modelleren via de data structuren beschreven in de IIIF presentation API.

10

Het gehele proces bestaat uit verschillende stappen:

1. Discovery van beeldbestanden a. Lees de directory op het bestandssysteem uit en lijst alle bestanden op. b. Valideer elk bestand. c. Haal ingebedde metadata uit de bestanden (EXIF of TIFF tags).

2. Haal op basis van de uit de beeldbestanden geëxtraheerde metadata worden inhoudelijke en technische metadata opgehaald uit drie databronnen:

a. Via de Datahub worden inhoudelijke registratiegegevens uit de collecties ontsloten. De gegevens zijn geformatteerd in het LIDO XML formaat.

i. Zie: http://datahub.vlaamsekunstcollectie.be b. Via de IIIF Image API wordt er een aantal technische gegevens ontsloten.

i. I.e. http://www.example.org/image-service/abcd1234/info.json (domeinnaam & service naam nog te bepalen)

c. Per beeld wordt ook de auteursrechtelijke status als metadata ontsloten. Deze informatie bevindt zich niet in de LIDO records, maar wel in een apart spreadsheet bestand.

3. Weerhoudt die LIDO records waarin een verwijzing is opgenomen naar een groter geheel of een verwijzing naar meerdere onderdelen.

a. De informatie is aanwezig in de XML structuur “lido:relatedWorksWrap” 4. Genereer per discrete serie van samen horende records een “graph” (i.e. een array, een

linked list, etc.) die de hiërarchische structuur vervat in de LIDO records modelleert. 5. Stap doorheen elke graph en genereer per item in de graph de relevante IIIF sequence

en IIIF canvas objecten. a. Elke graph wordt gepresenteerd door 1 IIIF manifest document. b. IIIF sequence en canvas objecten worden gerelateerd aan en embedded in het

IIIF manifest document. 6. Bewaar de verschillende IIIF objecten (manifests, canvassen en sequences) als aparte

entities in de databank a. De identificatiegegevens ingebed in de metadata van de beelden dienen als

persistente identifiers voor de identificatie van de verschillende IIIF onderdelen.

Bij het genereren van de verschillende artefacten - manifests, canvasses en sequences - moet de IIIF Presentation API specificatie worden gevolgd.

Zie: https://iiif.io/api/presentation/2.1

We merken op dat in deze proefopstelling er voor elke afbeelding één, en slechts één, canvas zal worden gebruikt. Met andere woorden, elke canvas bevat exact één IIIF image resource object. Er is geen detecteerbare use case die verantwoordt dat er meerdere IIIF image resources op een enkele canvas aanwezig kunnen zijn.

Het tweede proces volgt op het eerste proces. Logischerwijs zullen sommige manifest bestanden worden overschreven en opnieuw worden gegenereerd. Dit wordt niet als problematisch beschouwd. Gezien het grote verschil in eindresultaat (aparte, geïsoleerde manifest bestanden versus modellering van gerelateerde IIIF manifests) is het architecturaal te

11

verantwoorden om de algoritmes in twee gescheiden processen te implementeren. Zo blijft de complexiteit van de te ontwikkelen code voor de developer beheersbaar.

Identificatie van de onderdelen in de proefopstelling

De beelden, de LIDO records, en de verschillende IIIF onderdelen (manifests, sequences, canvases) moeten eenduidig worden geïdentificeerd om de verwerking van de gegevens en de uitwisseling van beelden mogelijk te maken.

Het IIIF framework is gebaseerd op de principes van Linked Open Data. Zowel de technische metadata in de IIIF Image API als de presentatie metadata in de IIIF Presentation API worden door de specificatie gemodelleerd als JSON-LD (JSON Linked Data). Identificatie binnen dit model gebeurt bij voorkeur via persistente URI’s. Dit zijn URL’s die niet alleen gebruikt worden gegevens te consumeren op het Web (“dereferencing”) maar ook om gegevens, concepten en objecten te identificeren in een data model.

Zie: https://iiif.io/api/presentation/2.1/#technical-properties

De implementatie van de IIIF Presentation API in de ImageHub moet dus alle discrete onderdelen identificeren aan de hand van eenduidige URI’s welke in de @id property van de diverse IIIF elementen (beelden, manifests, sequences, canvasses) is opgenomen. Dergelijke modellering ziet er als dusdanig uit:

LIDO Record Persistente URI in het veld “lido:lidoRecID” (preferred). Deze URI identificeert de record. (de Data PID) Persistente URI in het veld “lido:objectPublishedID” (preferred). Deze URI identificeert het fysieke werk dat door de record wordt beschreven. (de Work PID) In beide gevallen bestaat de persistente URI uit een HTTP URI waarvan het laatste gedeelte de zgn. PID identifier is. Dit is een string die gebaseerd is op het oorspronkelijke in het registratiesysteem toegekende inventarisnummer. De persistente URI in “lido:objectPublishedID” vormt de basis voor de identificatie van beelden.

Digitale beelden Deze bevinden zich op het bestandssysteem in JPG, JPG2000 of TIFF formaat. In elk beeldbestand horen identificatiegegevens te worden ingebed in TIFFtags of EXIF metadata. Minimaal zijn dit:

● De persistente URI (Work PID) zoals opgenomen in de lido:objectPublishedID

● Een persistente URI die het discrete digitale beeld identificeert (Representation PID)

12

IIIF Manifest Per digitaal beeld wordt een IIIF manifest document gegenereerd. De @id property bevat een identificator die moet voldoen aan de specificatie: https://iiif.io/api/presentation/2.1/#manifest De “identifier” in het “recommended URI pattern” schema is de PID die geëxtraheerd wordt uit de Work PID afkomstig uit het LIDO record of het beeldbestand.

IIIF Sequence Elke manifest document bevat minimaal 1 sequence (de “default” sequence). Deze sequence is een object (array, linked list) die alle IIIF canvasses bevat. https://iiif.io/api/presentation/2.1/#sequence De “identifier” in het “recommended URI pattern” schema is de PID die geëxtraheerd wordt uit de Work PID afkomstig uit het LIDO record of het beeldbestand. De “name” in het “recommended URI pattern” schema is een unieke string die de IIIF sequence identificeert binnen de manifest. Voor de “default” sequence wordt de string “normal” gehanteerd.

IIIF Canvas Een sequence bevat 1 of meerdere canvases. Een canvas definieert de box waarbinnen afbeeldingen zullen worden ontsloten. Ze bevat ook metadata betreffende de volgorde van de canvassen. https://iiif.io/api/presentation/2.1/#canvas De “identifier” in het “recommended URI pattern” schema is de PID die geëxtraheerd wordt uit de Work PID afkomstig uit het LIDO record of het beeldbestand. De “name” property bevat de unieke identifier van de canvas. Dit kan een door een databank of de applicatie gegenereerd nummer zijn (bv. canvas-4380405). De volgorde van de beelden, indien relevant (i.e. linkerluik, centraal luik, rechterluik) wordt bepaald door de volgorde van de elementen in de sequences array in het JSON object. Er is geen property die expliciet de volgorde aangeeft in de metadata.

IIIF Image Resource Een Canvas bevat één of meerdere image resources welke worden opgelijst in de “images” property. https://iiif.io/api/presentation/2.1/#image-resources

13

De “identifier” in het “recommended URI pattern” schema is de PID die geëxtraheerd wordt uit de Work PID afkomstig uit het LIDO record of het beeldbestand. De “name” property bevat de unieke identifier van de Image Resource. Dit kan een door een databank of de applicatie gegenereerd nummer zijn (bv. anno-4380405). Het nummer in de “name” property kan worden herhaald op het niveau van de canvas als de image resource, en voorzien van een prefix “anno” of “canvas”. Dit is géén vereiste. Er is geen directe betekenisvolle relatie tussen de identifier van een image resource en een canvas. Beiden mogen volledig verschillen. Binnen de Image Resource is er een “resource” property met een @id veld welke effectief verwijst naar de IIIF URI zoals ze wordt gepubliceerd door de IIIF Image API.

Publicatie van de verschillende onderdelen Een aantal van de hierboven vermelde onderdelen worden gepubliceerd onder een eigen URL als een discreet JSON document via de ImageHub web service. Concreet gaat het om:

● Elke manifest in het systeem wordt gepubliceerd onder een eigen URL. ● Elke canvas in het systeem wordt gepubliceerd onder een eigen URL. ● Elke image resource in het systeem wordt gepubliceerd onder een eigen URL.

Sequences publiceren we niet onder een aparte URL. Dus dat zijn ook geen aparte JSON objecten. Ze vormen direct een integraal onderdeel van de manifest JSON documenten.

Aangezien we maar 1 sequence per manifest document op nemen - de zogenaamde "default" sequence - is een @id property met een URL niet verplicht. Dus voorzien we dit niet.

De achterliggende reden om canvases en image resources apart te publiceren, is potentieel hergebruik van die data in andere manifest documents.

Inhoudelijke informatie in IIIF manifest documenten Het aanmaken van de IIIF manifest documenten veronderstelt dat er informatie wordt overgenomen uit LIDO XML records die via de Datahub worden gepubliceerd. Deze LIDO XML records bevatten registratiegegevens die het fysieke object beschrijven dat door de musea wordt beheerd. Concreet gaat het om een aantal inhoudelijke metadata die moeten worden overgenomen:

14

● De vervaardiger(s) Dit is een combinatie van de naam van de vervaardiger, de rol en de qualificatie. XPath queries voor LIDO XML: eventWrap/event[eventType='production']/eventActor/actorInRole/actor/nameActorSet/appellationValue eventWrap/event[eventType='production']/eventActor/actorInRole/roleActor/term eventWrap/event[eventType='production']/eventActor/actorInRole/attributionQualifierActor

● De korte beschrijving Dit is de korte, tekstuele beschrijving van het fysieke object. XPath queries voor LIDO XML: objectIdentificationWrap/objectDescriptionWrap/objectDescriptionSet/descriptiveNoteValue

● De productie datum van het werk Dit is de exacte datering van een werk. XPath queries voor LIDO XML: eventWrap/event[eventType='production']/eventDate/date/earliestDate eventWrap/event[eventType='production']/eventDate/date/latestDate

● De periode waarin het werk wordt gedateerd. Dit is een tijdsvak uitgedrukt in eeuwen (17de eeuw, 18de eeuw) XPath queries voor LIDO XML: eventWrap/event[eventType='production']/periodName/term

● De naam van de instelling die het fysieke object beheert Kan zijn: Groeningemuseum, Museum voor Schone Kunsten Gent,... XPath queries voor LIDO XML: objectIdentificationWrap/repositoryWrap/repositorySet/repositoryName/legalBodyName

● De objectnaam Het type object: olieverfschilderij, pentekening,... XPath queries voor LIDO XML: objectClassificationWrap/objectWorkTypeWrap/objectWorkType/term

● De rechtenstatus Dit is een indicatie van de auteursrechtelijke status van het fysieke werk ten aanzien van de digitale kopie. XPath queries voor LIDO XML: rightsWorkWrap/rightsWorkSet/RightsType/Term rightsWorkWrap/rightsWorkSet/RightsType/ConceptID

Tijdens de ontwikkeling van de ImageHub wordt er een mapping opgesteld tussen deze velden in het LIDO datamodel en de IIIF Presentation model.

15

Meertaligheid De IIIF Manifest documenten horen rekening te houden met meertalige inhoudelijke informatie. De LIDO records kunnen informatie bevatten in het Frans, Engels en Nederlands. Bij de extractie en conversie van informatie wordt rekening gehouden met meertalige content.

Het LIDO XML schema voorziet dat meertalige informatie wordt gemarkeerd met een “lang” attribuut in de XML nodes. Deze meertalige informatie is initieel niet aanwezig in de LIDO records die uit de Datahub komen. Vooraleer de LIDO records worden geconverteerd naar IIIF manifests documenten, wordt de meertalige data uit een derde databron (CSV files, SQLite databank, etc.) opgehaald en rechtstreeks in de DOM structuur van de individuele LIDO records geïnjecteerd.

De IIIF Presentation API voorziet dat meertalige content kan worden gemodelleerd volgens een complexe structuur waarbij gebruik wordt gemaakt van een @value en @language property:

{"description": {"@value": "Here is a longer description of the object", "@language": "en"}}

Zie: https://iiif.io/api/presentation/2.1/#language-of-property-values

Het voorzien van de correcte taal attributen in de IIIF Manifest documenten is voldoende om meertalige functionaliteit in IIIF compliant consumers - bv. IIIF viewers - aan te sturen.

Opbouw van een IIIF Manifest document Een IIIF manifest document is opgebouwd volgens een gelaagd structuur van JSON objecten (manifest > sequence > canvas > image resource). Tussen de verschillende JSON objecten kan er een 1 op meer relatie bestaan. Voor de modellering binnen de proefopstelling houden we een welbepaalde structuur aan:

● 1 IIIF Manifest bevat altijd 1 en slechts 1 IIIF Sequence ● 1 IIIF Sequence kan 1 of meerdere IIIF Canvases bevatten ● 1 IIIF Canvas bevat altijd 1 en slechts 1 IIIF Image Resource.

Waarom deze structuur?

● Een IIIF sequence definieert een serie van een aantal canvases met afbeeldingen in een specifieke volgorde. Dezelfde canvases en afbeeldingen kunnen ook in een alternatieve volgorde worden getoond (i.e. Left-to-right, right-to-left). In de proefopstelling gaan we uit van 1 en slechts 1 sequence waarbinnen de volgorde slechts wordt bepaald in de mate dat er relevante, leesbare contextuele metadata aanwezig is.

● Een IIIF canvas kan meerdere image resources - de referentie naar de feitelijke beelden - bevatten. Zo kan worden beantwoord aan use cases zoals kranten en boeken waar meerzijdige pagina’s binnen 1 canvas worden getoond. De business case binnen de proefopstelling voorziet echter slechts 1 afbeelding per fysiek object.

16

Een IIIF manifest kan een sequence bevatten met meerdere canvases / beelden. In dergelijke gevallen wordt elk individueel beeld in een bredere context van gerelateerd beeldmateriaal geplaatst. Hoe wordt zo’n

Auteursrechtelijke status

Speciale aandacht gaat uit naar de auteursrechtelijke status van een werk. Een werk kan immers tot het publieke domein behoren, of nog onder de bescherming van het auteursrecht vallen. In het laatste geval kan een digitale kopie van het werk niet zonder meer worden gepubliceerd. Er dient rekening te worden gehouden met de voorwaarden die rechthebbenden stellen aan de publicatie van het werk.

De auteursrechtelijke status van het fysieke werk wordt afgeleid op basis van het veld “rechtenstatus” in de LIDO XML record. Door gebruik te maken van gestandaardiseerde terminologie - Creative Commons - wordt op een eenduidige wijze de rechtenstatus gecommuniceerd.

Een doelstelling van deze proefopstelling is om hier te onderzoeken hoe deze informatie praktisch / concreet kan worden gebruikt om de rechtenstatus te communiceren via een IIIF manifest document en hoe er rekening kan worden gehouden met de diverse ‘concerns’ betreffende auteursrecht en de communicatie hiervan.

Publiceren van IIIF manifest documenten via een web service De ImageHub is verantwoordelijk voor de publicatie van de manifest documenten (en onderliggende IIIF presentation entities zoals sequences, canvases en image resources) via een publieke, open web service.

De IIIF presentation entities worden gezien als HTTP resources die identificeerbaar zijn via een HTTP URI. De vorm / patroon waaraan deze URI’s moeten beantwoorden is vastgelegd in de IIIF presentation API specificatie 2.1. De implementatie van de ImageHub beantwoordt aan deze specificatie.

IIIF Authentication API

Er is in deze proefopstelling ruimte voorzien voor de opzet van een IIIF authentication API, die het mogelijk zou maken voor bijvoorbeeld interne medewerkers van musea om toegang te krijgen tot IIIF data die niet voor een non-authenticated user zichtbaar is, wellicht omdat het werk nog binnen het auteursrecht valt of over het algemeen niet voor verspreiding onder het publiek geschikt is.

Het beheer van gebruikers De ImageHub voorziet administratieve modules die het mogelijk maakt om (a) beelden manueel op te laden en (b) opgeladen beelden te beheren via een gebruiksvriendelijke interface. Aangezien deze module het wijzigen of aanvullen van content in het gehele systeem

17

veronderstelt, is het noodzakelijk dat deze modules enkel toegankelijk zijn voor geauthenticeerde gebruikers. Gebruikersbeheer voorziet drie authenticatie niveaus:

● Anonieme gebruikers. Dit zijn bezoekers en consumenten van de IIIF API’s die niet zijn ingelogd (geen sessie cookie aanwezig)

● Managers. Dit zijn gebruikers die in staat zijn om eigen beelden te beheren en op te laden, maar geen beelden van anderen kunnen beheren. Managers kunnen ook geen gebruikers beheren (accounts verwijderen, deactiveren,...)

● Superadministrator. Dit is de algemene beheerder (slechts 1 account). Deze kan alle beelden beheren en heeft ook de mogelijkheid om gebruikers aan te maken of te verwijderen.

Technisch praktisch kan de ontwikkelaar de code van de gebruikersmodule uit de Datahub overnemen en hergebruiken in de ImageHub toepassing: Zie: https://github.com/thedatahub/Datahub/tree/master/src/DataHub/UserBundle

Inloggen en uitloggen Om toegang te krijgen tot de administratieve modules dienen de gebruikers zich in te loggen via een gebruiksvriendelijk inlogformulier. Na het inloggen landt de ingelogde gebruiker terug op de homepagina van de toepassing.

Er wordt ook een “I forgot my password” functionaliteit voorzien waarbij gebruikers een e-mail krijgen met een one-time-login link. Zo kunnen gebruikers inloggen en een nieuw wachtwoord instellen wanneer ze hun oude zijn vergeten.

Na succesvol inloggen landt de gebruiker terug op de startpagina van de toepassing. Een ingelogde gebruiker ziet in het hoofdmenu de extra administratieve secties (afhankelijk van het toegangsniveau); een link naar de eigen profielpagina en een knop uitloggen.

Door op de knop uitloggen te klikken, wordt de actieve sessie vernietigd. De gebruiker wordt terug aanzien door het systeem als een anonieme bezoeker. Tenslotte landt de gebruiker na het uitloggen terug op de startpagina en heeft deze niet langer toegang tot de administratieve onderdelen van de toepassing.

Aanmaken, beheren en verwijderen van gebruikers Deze drie submodules van het gebruikersbeheer zijn enkel toegankelijk na het inloggen met een superadministrator account.

Het aanmaken van nieuwe gebruikers bestaat uit een invulformulier dat toelaat om nieuwe gebruikers met een (tijdelijk) wachtwoord aan te maken. Een gebruiker heeft minimaal een gebruikersnaam, een wachtwoord en een e-mailadres. Er kunnen geen twee gebruikers zijn met

18

dezelfde gebruikersnaam en/of hetzelfde e-mailadres. Hetzelfde formulier kan ook worden gebruikt om gebruikers te verwijderen.

Het beheren van gebruikers bestaat uit een lijstweergave van alle aangemaakte gebruikers met een aantal actie knoppen per gebruiker: bewerken of verwijderen, en een algemene knop “voeg nieuwe gebruiker toe” knop.

Het verwijderen van gebruikers bestaat uit een formulier met de knoppen “verwijder deze gebruiker” en “Annuleren” wat om een expliciete bevestiging vraagt. Bij het klikken op de eerste knop, wordt de gebruiker uit de databank permanent verwijderd. De superadministrator landt terug op de lijstweergave na het uitvoeren van de actie.

Elke ingelogde gebruiker kan ook het eigen profiel bekijken en bewerken. Er is een aparte profielpagina met gebruikersgegevens die de gebruiker via een link in het hoofdmenu kan benaderen. Via een knop “bewerk mijn profiel” kan de gebruiker het eigen profiel bewerken (bijvoorbeeld een nieuw wachtwoord instellen)

Het beheer van beelden

De manuele ingest van beelden

Deze submodule is enkel toegankelijk voor ingelogde gebruikers met de rol “manager” of “superadministrator”.

De ingest van beeldbestanden kan op twee manieren gebeuren. Enerzijds door het beeldmateriaal rechtstreeks in een voor de toepassing toegankelijke directory op het bestandssysteem te plaatsen. Dit kan via (S)FTP, SCP, RSync of andere methoden. Anderzijds door een gebruiksvriendelijk formulier te voorzien dat de manuele ingest van beelden mogelijk maakt voor een eindgebruiker, zonder dat deze direct volledige toegang krijgt tot het systeem.

De module voorziet dat één of meerdere beelden kunnen worden opgeladen via een gebruiksvriendelijk formulier met een oplaad element:

Zie: https://gitlab.com/meno/dropzone

Wanneer een beeld wordt opgeladen, wordt met deze elementen rekening gehouden:

● Validatie van het bestandsformaat: ○ JPEG2000

● Validatie van de embedded EXIF informatie in het bestand: ○ Is er een Work PID aanwezig en is dit een valide URL?

Het systeem houdt geen rekening met bestanden die reeds op het bestandssysteem aanwezig zouden zijn. Reeds aanwezige beeldbestanden met dezelfde bestandsnaam worden zonder meer overschreven. Er wordt evenmin een bevestiging gevraagd wanneer een bestand reeds zou bestaan.

19

Eenmaal een bestand is opgeladen, landt de gebruiker terug op de pagina met het oplaadformulier met een melding dat de actie (al dan niet) succesvol werd uitgevoerd door het systeem.

Verdere verwerking van het beeld - het ophalen van metadata uit de Datahub, de conversie naar een IIIF manifest document,.... - wordt in eerste instantie niet voorzien tenzij dit opportuun of noodzakelijk blijkt voor de goede werking van de toepassing De verdere verwerking van het beeld wordt overgelaten aan de geautomatiseerde processen zoals hierboven beschreven.

Wel wordt er een record aangemaakt in de databank waarbij het beeld wordt geïdentificeerd op basis van de Representation PID (of een ander identificeerbaar gegeven zoals de bestandsnaam). Dit record voorziet deze velden:

● De interne ID van het record (automatisch toegekend door het DBMS) ● De ID van het beeld op basis van de bestandsnaam of de Representation PID ● Een text veld object number op basis van het inventarisnummer van het fysieke werk dat

uit het beeld werd opgehaald. ● Een boolean vlag “published” die bepaald of het beeld al dan niet gepubliceerd wordt via

de IIIF Presentation API. ● Een textveld “manifest” dat het te genereren IIIF manifest bestand bevat. ● Een veld “owner” die verwijst naar de account van de gebruiker in de “users” tabel of

collectie.

Beheren, bewerken en verwijderen van beelden Deze module is enkel toegankelijk voor ingelogde gebruikers met de rol “manager” of “superadministrator”. Ze bestaat uit een aantal submodules

Het beheren van beelden bestaat uit een lijstweergave die alle beelden aanwezig op het bestandssysteem weergeeft. Per item in de lijst worden een aantal eigenschappen weergegeven:

● De bestandsnaam ● De Work PID die uit het beeld werd opgehaald ● De Representation PID die uit het beeld werd opgehaald. ● Het oorspronkelijke inventarisnummer die uit het beeld werd opgehaald ● Een indicatie of het beeld al dan niet via de IIIF Presentation API beschikbaar wordt

gesteld. ● Een indicatie of er al dan niet reeds een IIIF Manifest document reeds aanwezig is in de

databank.

De weergave voorziet een knop “verwijder” en “bewerk” per beeld en een algemene knop “voeg een nieuw beeld toe”.

De weergave geeft weliswaar alle aanwezige beelden weer, maar toont enkel knoppen “bewerk” of “verwijder” voor die beelden waar de ingelogde gebruiker eigenaar van is (dus zelf heeft

20

opgeladen). De superadministrator wordt niet geconfronteerd met deze beperking en kan alle beelden bewerken of verwijderen.

Het bewerken van een beeld leidt naar een apart formulier. Dit formulier is enkel toegankelijk voor eigenaars van het beeld. De gebruiker ziet deze bewerkbare velden:

● Een boolean vlag “published” die bepaald of het beeld al dan niet gepubliceerd wordt via de IIIF Presentation API.

Het verwijderen van een beeld leidt naar een apart formulier. Dit formulier bestaat uit de knoppen “verwijder deze gebruiker” en “Annuleren” wat om een expliciete bevestiging vraagt. Bij het klikken op de eerste knop, wordt de gebruiker uit de databank permanent verwijderd. De superadministrator landt terug op de lijstweergave na het uitvoeren van de actie.

Statische pagina’s

Net zoals de Datahub voorziet de ImageHub een aantal pagina’s die men kan bezoeken te weten:

De homepagina

Dit is de startpagina van de toepassing. Net zoals bij de Datahub is hier een welkomstbericht voorzien met een aantal gegevens:

● De naam van de organisatie die de ImageHub beheert en operationeel stelt. ● De contactgegevens van de organisatie die de ImageHub beheert en operationeel stelt. ● Het aantal IIIF manifest documenten dat aanwezig is in de ImageHub ● Het aantal IIIF manifest documenten met meerdere sequenties en canvases.

De IIIF Presentation API pagina

Deze pagina bevat een paragraaf met een beknopte uitleg over de IIIF Presentation API en technische documentatie die gebruikers in staat moet stellen om de IIIF Presentation API implementatie van de ImageHub te consumeren.

De IIIF Image API pagina

Deze pagina bevat een paragraaf met een beknopte uitleg over de IIIF Image API en technische documentatie die gebruikers in staat moet stellen om de IIIF Image API implementatie van de proefopstelling te consumeren.

Arthub Flanders De proefopstelling bevat een kopie van het Arthub Flanders platform. Deze toepassing is een zoekmachine waarin de 200 beelden zullen worden ontsloten via de IIIF onderbouw naar de gebruikers van de Arthub Flanders.

21

Arthub Flanders is gebaseerd op Project Blacklight (http://projectblacklight.org/). Dit is een Ruby on Rails applicatie met een Apache Solr backend.

Aan deze kopie of proefversie dienen een aantal aanpassingen te worden uitgevoerd in het kader van dit bestek.

Integratie van een IIIF viewer Op de detailpagina van een werk in de Arthub Flanders wordt er een IIIF compatible viewer / zoomtool voorzien die de manifest files komende uit de ImageHub zal consumeren.

Concreet is de ontwikkelaar verantwoordelijk voor:

● De implementatie van Universal Viewer (https://universalviewer.io/) ● De integratie van IIIF Manifest URL’s in het datamodel van Arthub Flanders zodanig dat

deze door de IIIF viewer kunnen worden geconsumeerd. ● De implementatie van de IIIF Authentication API op het niveau van Arthub Flanders via

de IIIF Viewer.

Meertaligheid De zoekfunctionaliteit en de weergave van registratiegegevens dient te worden voorzien van ondersteuning voor meertaligheid.

De interface van Arthub Flanders is reeds meertalig. Via een taalselectie kunnen gebruikers de taalweergave van de statische teksten, labels, elementen,... aansturen. Dit is echter niet het geval voor de registratiegegevens. Deze worden eenzijdig in het Nederlands weergegeven ongeacht de geselecteerde interface taal.

Om dit te realiseren zijn een aantal fundamentele aanpassingen aan de logica en het datamodel van het platform noodzakelijk:

● Een aantal aanpassingen in de ETL pipeline die meertalige LIDO records uit de Datahub ophaalt, verwerkt en als een JSON document opslaat in de Apache Solr database backend.

○ In de huidige ETL pipeline wordt er per LIDO record een Solr document gegenereerd. In de aanpassing wordt er op basis van het aantal gedetecteerde talen in de LIDO record, een overeenkomstig aantal Solr documenten aangemaakt. Bv. een LIDO record met zowel Nederlandse als Engelse content levert 2 Solr documenten op.

● Een aantal aanpassingen in het datamodel dat door Apache Solr en Project Blacklight wordt gehanteerd te weten:

○ De toevoeging van een “language” parameter aan discrete Solr documents en op het niveau van de Ruby on Rails toepassing. De waarde van deze parameter wordt rechtstreeks afgeleid uit de LIDO record.

● De toevoeging van een “Language” / “Taal” facet. Deze zal toelaten dat de zoekresultaten gefilterd worden op taal.

22

○ De standaardtaal van de applicatie is “Nederlands”. De zoekfacet zal als dusdanig worden geïnitieerd.

○ Er is altijd een taal geselecteerd. Het is dus niet mogelijk om een “taalonafhankelijke” zoekopdracht te geven.

○ De URL’s van de geactiveerde facets (Nederlands & Engels) worden gebruikt in de taalselectie in het hoofdmenu. Zo zal het klikken op “EN” of “NL” niet alleen de taal van de interface aansturen, maar ook de taal van de zoekresultaten in de catalogus.

Operationalisering De ontwikkelaar zal daarbij een kopie maken van de codebase die terug te vinden is op https://github.com/VlaamseKunstcollectie/Arthub-Frontend. De ontwikkelaar zal toegang krijgen tot de codebase en op een aparte git branch de verwachte wijzigingen aanbrengen.

De ontwikkelaar zal een operationele proefversie van Arthub Flanders met alle wijzigingen in de aparte git branch uitrollen op de voor deze proefopstelling voorziene VPS.