Van data naar dienst. Visie op de ontwikkeling van verbonden erfgoeddiensten

Netwerk Digitaal Erfgoed November 2025 Van data naar dienst Visie op de ontwikkeling van verbonden erfgoeddiensten Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Inhoud Samenvatting 2 1. Inleiding 5 2. Het dienstplatform van vandaag 7 3. Het dienstplatform van morgen 15 4. Samen verder bouwen 34 Bijlage 1: Inventarisatie van 12 dienstplatformen 38 1.1 Delfts aardewerk 40 1.2 Koloniale Collecties Datahub 46 1.3 Modemuze 52 1.4 Oorlogsbronnen 57 1.5 Van Gogh Worldwide 62 1.6 De Gouda Tijdmachine 67 1.7 LisseTijdReis 72 1.8 Amsterdam Time Machine - Diaries 78 1.9 Podiumkunst.net 85 1.10 Linked Open Limburg 89 1.11 Collectieplatform Nieuwe Instituut 94 1.12 Rijksmuseum 99 Bijlage 2: Weergave types 109 Bijlage 3: Vereisten voor de (meta)data 112 Bijlage 4: Begrippenlijst 115 1 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Samenvatting Rol van dienstplatformen Dienstplatformen spelen een centrale rol in het digitaal erfgoedveld. Ze brengen data uit verschillende bronnen samen, zorgen voor vindbaarheid en maken presentaties mogelijk voor uiteenlopende doelgroepen. Voorbeelden zijn Oorlogsbronnen, Van Gogh Worldwide en de Gouda Tijdmachine. Voor gebruikers vormen dit soort platformen de toegangspoort tot verhalen, objecten en collecties die anders verspreid en moeilijk vindbaar zouden blijven. In 2024 en 2025 is de architectuur van twaalf verschillende dienstplatformen in kaart gebracht. Mede op basis van deze informatie is een schets gemaakt van de huidige werkwijze voor het ontwikkelen van een platform voor verbonden erfgoeddiensten. De analyse laat zien dat de bouw van een dienstplatform nog complex en kostbaar is. Het werk van de afgelopen tien jaar aan standaardisatie bij de bron en aan de ondersteunende voorzieningen in het netwerk maakt het realiseren van verbonden erfgoeddiensten nu al eenvoudiger. Samen met meer standaardisatie aan de kant van de diensten kan er een nieuw ecosysteem ontstaan waarin gebruikers eenvoudiger toegang krijgen tot rijkere, meer verbonden diensten. Zo tekent zich een nieuw speelveld af: dankzij standaardisatie bij de bron en verdere standaardisatie aan de kant van de diensten wordt het ontwikkelen van platformen eenvoudiger en flexibeler, en komt eenvoudiger hergebruik en grotere zichtbaarheid nog beter binnen bereik. Waar gaat deze analyse over? Veel van de onderzochte dienstplatformen zijn als maatwerkprojecten opgezet. Data wordt gekopieerd, opgeschoond en getransformeerd binnen het platform zelf. Verrijkingen worden veelal niet gepubliceerd en zijn daardoor niet beschikbaar voor anderen. Daardoor voeren deze platformen telkens dezelfde bewerkingen uit. Het resultaat: hoge ontwikkelkosten en beperkte uitwisselbaarheid van resultaten. Gebruikers verwachten intussen rijke, samenhangende ervaringen over de grenzen van verschillende erfgoeddiensten heen. Hun behoefte blijft niet beperkt tot het perspectief van een dienstplatform, maar ze willen steeds weer nieuwe verhalen ontdekken die bronnen uit meerdere collecties combineren. Om daaraan te voldoen, moeten diensten voor verbonden erfgoed flexibeler worden ingericht. Op basis van deze analyse van de bestaande praktijk volgt een visie op de aanpak en wat daar (nu al) in gedaan kan worden. 2 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Uitgangspunten De analyse formuleert enkele uitgangspunten die richting geven aan de toekomst: 1. Eigenaarschap bij de bron. Bronhouders blijven verantwoordelijk voor hun data en publiceren volgens gedeelde standaarden. 2. Scheid data en presentatie. De datalaag zorgt voor een uniforme, verbonden dataset; de presentatielaag bouwt daarop voort met publieksgerichte toepassingen. 3. Werk met open standaarden. Het Datasetregister, Termennetwerk, IIIF en NDE-Schema.org vormen elementen waarop diensten kunnen bouwen. 4. Maak onderscheid tussen nu en later. Sommige stappen zijn direct uitvoerbaar, andere vragen gezamenlijke ontwikkeling op middellange termijn, waarin samenwerking in het Netwerk Digitaal Erfgoed van belang is. Wat kan nu al? Ontwikkelaars en dataspecialisten kunnen vandaag al stappen zetten die direct effect hebben. Het begint met het zichtbaar maken van datasets in het Datasetregister. Daarmee wordt duidelijk welke bronnen beschikbaar zijn en kunnen updates efficiënt worden verwerkt. Als bronhouders hun data publiceren volgens het NDE-Schema.org-profiel, ontstaat bovendien een solide basis voor hergebruik en vindbaarheid. Voor beeldmateriaal kan de internationale IIIF-standaard direct meerwaarde opleveren: afbeeldingen hoeven niet langer te worden gekopieerd, maar kunnen flexibel worden gedeeld en gepresenteerd. Ook het openstellen van bestaande API’s draagt bij aan een betere scheiding tussen datalaag en presentatielaag, zodat anderen eenvoudig kunnen voortbouwen op dezelfde gegevens. Ten slotte kunnen verrijkingen, zoals nieuwe metadata of annotaties, als aparte datasets worden gepubliceerd met duidelijke herkomstinformatie. Daarmee worden ze niet alleen binnen één platform benut, maar beschikbaar voor het hele netwerk van gedistribueerde erfgoedinformatie. Wat vraagt ontwikkeling? Naast de stappen die nu al mogelijk zijn, is extra ontwikkeling nodig om de basis te leggen voor een duurzaam ecosysteem van erfgoeddiensten. Dat vraagt ook om voorzieningen op instellingsoverstijgend niveau, zodat data eenvoudiger te hergebruiken is voor dienstplatformen. Hierbij kan bijvoorbeeld gedacht worden aan diensten voor automatische transformatie of verrijking van brondata of slimme notificatie diensten. Daarmee kunnen diensten sneller en makkelijker tot stand komen, wat de weg opent naar een dynamischer aanbod. Ook op het gebied van de presentatielaag liggen er kansen. Nu bouwen veel platformen eigen oplossingen voor beeldweergave, tijdlijnen en kaarten. Door herbruikbare open source-componenten te ontwikkelen die direct aansluiten op gestandaardiseerde API’s, kunnen kosten worden verlaagd en functionaliteiten sneller worden uitgerold. Tot slot kunnen AI-technieken worden ingezet om datakwaliteit te verbeteren, bijvoorbeeld door entiteiten te herkennen of handschriften te transcriberen, en deze voorzieningen als netwerkdiensten beschikbaar te stellen. 3 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Conclusie Aanbieders van verbonden erfgoeddiensten hoeven niet telkens opnieuw te beginnen. Door data aan de bron te publiceren volgens standaarden, open API’s aan te bieden en netwerkvoorzieningen te gebruiken, ontstaat een robuust en efficiënt ecosysteem. Het gebruik van linked data is hierbij de sleutel. Het maakt erfgoedinformatie schaalbaar, duurzaam en breed herbruikbaar. Daarmee wordt niet alleen dubbel werk voorkomen, maar ontstaat ook de ruimte voor innovatieve toepassingen die erfgoed dichter bij de gebruiker brengen. 4 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1. Inleiding Het digitaal toegankelijk maken van erfgoedcollecties is de afgelopen tien jaar sterk in beweging gekomen. Waar collecties vroeger vooral binnen de muren van één instelling werden ontsloten, verwachten gebruikers nu dat informatie over grenzen heen samenkomt. Ze willen niet zoeken op losse websites, maar verhalen ontdekken en verbanden zien tussen objecten, thema’s en collecties. Dienstplatformen spelen hierin nu een sleutelrol. Ze brengen data uit verschillende bronnen samen, maken die vindbaar en presenteren ze in uiteenlopende vormen. Voorbeelden zijn thematische platformen zoals Modemuze en Van Gogh Worldwide, tijdmachines zoals de Gouda Tijdmachine, en samenwerkingsplatformen zoals Podiumkunst.net. Ook instellingen als het Rijksmuseum en het Nieuwe Instituut gebruiken platformen om hun eigen collecties onderling te verbinden en te verrijken met externe informatie. Dienstplatformen vormen de voorhoede in het ontwikkelen van verbonden erfgoeddiensten, zoals de Nationale Strategie Digitaal Erfgoed nastreeft. Uitgaande van de behoefte van de gebruiker bieden zij diensten waarin informatie uit verschillende bronnen samenkomt. Deze verbonden erfgoeddiensten zijn nu vooral zichtbaar via de dienstplatformen. Om die reden is het werk van de platformen gebruikt als vertrekpunt voor het ontwikkelen van een visie op verbonden erfgoeddiensten. Dit rapport beschrijft een visie die de ontwikkeling van verbonden erfgoeddiensten kan versnellen. Vanuit deze visie kan elke erfgoedinstelling diensten aanbieden die gebruikmaken van het netwerk van verbonden erfgoedinformatie. Dat netwerk ontstaat door standaardisatie en samenwerking binnen het Netwerk Digitaal Erfgoed. Het werk van het Netwerk Digitaal Erfgoed staat op een kantelpunt. Steeds meer collecties worden gepubliceerd als linked data, waardoor dienstplatformen informatie eenvoudiger kunnen hergebruiken. Dat maakt dit het juiste moment om te onderzoeken hoe platformen nu zijn ingericht, welke kansen en knelpunten er zijn en welke stappen op korte en langere termijn nodig zijn. Deze analyse bouwt voort op bijna tien jaar gezamenlijke inspanning. In 2015 werd de Nationale Strategie Digitaal Erfgoed gelanceerd, met als doel collecties digitaal over organisatiegrenzen heen toegankelijk te maken. Een jaar later wees het position paper Naar een gedistribueerd netwerk van erfgoedinformatie de richting: door data bij de bron als linked data te publiceren, zouden uitgebreide bewerkingen per toepassing uiteindelijk overbodig worden. Sindsdien zijn belangrijke bouwstenen ontwikkeld, zoals de Digitaal Erfgoed Referentie Architectuur (DERA), het Datasetregister en het Termennetwerk. Ook collectie-informatiesystemen zijn doorontwikkeld om linked data te ondersteunen. In 2023 verscheen de eerste architectuurblauwdruk voor dienstplatformen. Als vervolg daarop zijn in 2024 en 2025 twaalf platformen onderzocht, die samen een beeld geven van de diversiteit in technologie, context en doelstellingen. Daarbij is gekeken naar de datalaag (het binnenhalen, 5 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten transformeren en harmoniseren van broninformatie) en de presentatielaag (de functies die informatie bij de gebruiker brengen). Deze analyse brengt de inzichten samen en schetst een visie op de verdere doorontwikkeling van de verbonden erfgoeddiensten . Door verder te standaardiseren en voorzieningen slim te benutten, kan een duurzaam ecosysteem ontstaan waarin erfgoeddiensten eenvoudiger en efficiënter ontwikkeld worden – met meer samenhang, betere kwaliteit en bredere impact. Om deze ambities te realiseren wordt een beroep gedaan op alle partijen in het netwerk om samen te werken aan verdere standaardisatie, hogere datakwaliteit, open en herbruikbare oplossingen en inspirerende praktijkvoorbeelden. De manier waarop aansturing, ondersteuning en rolverdeling verder vorm moeten krijgen, valt buiten de scope van dit rapport en zal in overleg met de stakeholders in het netwerk worden uitgewerkt. Verantwoording Dit rapport is tot stand gekomen dankzij de medewerking van een groot aantal organisaties die hun inzichten, werkwijze en ervaring open met het NDE-team hebben gedeeld. Zonder de openheid en medewerking van de initiatiefnemers en beheerders van de twaalf onderzochte dienstplatformen was deze analyse niet mogelijk geweest. Op basis van de mondelinge en schriftelijke informatie is de applicatiearchitectuur van de platformen nauwkeurig in kaart gebracht. Vervolgens zijn gedetailleerde architectuurschetsen opgesteld die de functionaliteit binnen het platform relateren aan de applicatiefuncties en referentiecomponenten die in de DERA worden beschreven. De detailanalyses van de dienstplatformen en de generalisaties zijn met veel zorg en oog voor detail opgesteld door informatieanalist Sablina Vis - Machado Maciel en informatiearchitect Pano Maria. De beschrijvingen van de platformen zoals opgenomen in de bijlagen zijn meerdere keren voorgelegd en getoetst bij de organisaties die de platformen beheren. Op grond van de detailanalyses is een algemene schets gemaakt van de functionaliteiten zoals die in de huidige dienstplatformen regelmatig worden teruggevonden. Deze schets is gebruikt als leidraad voor de analyse van de huidige situatie (hoofdstuk 3) en het schetsen van een toekomstig visie (hoofdstuk 4) voor het realiseren van diensten voor verbonden erfgoed. Waar de diensten de interactie met de gebruiker raken, zijn de gedragsprofielen digitaal erfgoed als leidraad gebruikt. De analyse en toekomstvisie is geschreven door Enno Meijers (CTO) in nauwe afstemming met het NDE-infrastructuurteam en het NDE-netwerkteam, in het bijzonder Elisabeth Wiessner (netwerkcoördinator Digitaal Erfgoed Zichtbaar) en Wilbert Helmus (netwerkmanager). De eindredactie was in handen van Ronald de Nijs (netwerkredacteur). Tot slot een dankwoord aan de externe reviewers Sjors de Valk (Oxodax), Martijn Arts (Total Design), Sies Vonk (Vonker Kunst & Cultuur) en Nadine van Tijn en collega’s van RCE voor hun constructieve feedback op de conceptversie van het rapport. 6 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 2. Het dienstplatform van vandaag Om de werking van dienstplatformen in kaart te brengen zijn twaalf verschillende platformen geanalyseerd die diensten aanbieden binnen het NDE-netwerk. Dit hoofdstuk beschrijft op basis van deze analyse de belangrijkste functies voor het verwerken van broninformatie tot relevante diensten voor eindgebruikers: van het binnenhalen, transformeren, harmoniseren en indexeren van data tot de uiteindelijke presentatie aan gebruikers. Inleiding Er bestaan veel platformen die gebruikers toegang geven tot erfgoedinformatie, vaak afkomstig uit verschillende bronnen. Deze dienstplatformen kennen allerlei vormen, zowel qua aangeboden diensten en functies als de onderliggende technische inrichting. Om de werking van de huidige platformen te begrijpen, zijn twaalf dienstplatformen grondig geanalyseerd. Ze maken elk een specifieke selectie van informatie toegankelijk voor gebruikers door gegevens uit verschillende bronnen samen te brengen. Voor elk dienstplatform is het applicatielandschap in kaart gebracht om inzicht te krijgen in de gebruikte toepassingen. Vervolgens is een architectuurschets opgesteld, waarin de belangrijkste functies op een gestandaardiseerde manier zijn beschreven. De bijlage bevat de gedetailleerde beschrijvingen van alle twaalf platformen. Op basis van de analyse beschrijft dit hoofdstuk de belangrijkste functies van dienstplatformen. De nadruk ligt op de functies die broninformatie geschikt maken voor het aanbieden van diensten aan eindgebruikers, zoals het binnenhalen, transformeren, harmoniseren en indexeren. Samen vormen deze functies de datalaag, met als resultaat een set van verbonden erfgoedinformatie. Daarnaast beschikken de meeste dienstplatformen over een presentatielaag. Deze omvat functies waarmee verbonden erfgoedinformatie aan gebruikers wordt aangeboden, bijvoorbeeld door informatie op een kaart te tonen of een resultatenlijst op te bouwen. De analyse richt zich vooral op de datalaag, waar de grootste complexiteit voor bouwers van dienstplatformen ligt en de belangrijkste vraagstukken rond het werken met erfgoedinformatie spelen. Over de presentatielaag is relatief weinig nieuwe informatie opgehaald, omdat de eerder uitgevoerde analyse naar de gedragsprofielen voor digitaal erfgoed al een goed beeld geeft van wat hiervoor relevant is. 7 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Wanneer het dienstplatform deze informatie beschikbaar stelt, wordt de beheerder van het platform feitelijk bronhouder van nieuwe informatie en publiceert deze desgewenst als nieuwe bron, inclusief een datasetbeschrijving. Zo digitaliseert Gouda Tijdmachine erfgoedbronnen over gebouwen, straten, bedrijven en bewoners in Gouda. Om deze geharmoniseerde informatie breder beschikbaar te maken, publiceert het dienstplatform datasetbeschrijvingen voor opname in het Datasetregister. Bespreking van de functies van de presentatielaag De laatste twee stappen zijn onderdeel van de presentatielaag: de laag waar de presentatie en de interactie met de gebruiker plaatsvindt. Op basis van de analyse van de twaalf platformen valt deze laag uiteen in een functie voor het ophalen van de metadata uit de datalaag en de daadwerkelijke presentatie aan de gebruiker. Stap 9: ophalen van metadata Deze functie zorgt voor het bevragen van de beschikbare API’s en het ophalen en klaarmaken van de gegevens voor de presentatie. Omdat er in de praktijk vaak geen duidelijke scheiding is tussen de datalaag en de presentatielaag, is er weinig specifieke informatie gevonden om algemene uitspraken te kunnen doen over deze functie. Wel vindt er altijd een zoekactie plaats die resulteert in het terugleveren van relevante metadata. Voor de presentatielaag, waar deze en de volgende stap onder vallen, worden technieken gebruikt die algemeen van toepassing zijn voor het bouwen van websites. IIIF vormt hierop een uitzondering: deze technologie wordt nog niet breed toegepast buiten het erfgoeddomein, waardoor specifieke oplossingen nodig zijn. Het gebruik van IIIF om beeldmateriaal (en bijbehorende metadata) bij de bron op te halen wordt in de onderzochte platformen eveneens nog beperkt toegepast. Stap 10: presenteren van metadata Deze laatste stap is de uiteindelijke presentatie van de gegevens op een manier die aansluit bij de doelstelling van het platform en de wensen en het gedrag van de gebruikers. De manier waarop verbonden erfgoedinformatie wordt gepresenteerd aan de gebruikers van dienstplatformen is zeer divers. Het onderzoek naar gedragsprofielen beschrijft de volgende presentatievormen: afbeeldingweergave, multimediaweergave, tijdlijnof kaartweergave of verhaalweergave. De bijlage ‘Weergave types’ geeft een overzicht van de belangrijkste kenmerken. Deze presentatievormen sluiten goed aan bij de praktijk van de onderzochte dienstplatformen. Platformen met een volledig ingerichte presentatielaag richten zich vooral op diensten die passen bij de gedragsprofielen ‘Gericht informatie zoeken’, ‘Browsen en ontdekken’ en ‘Intens beleven’. Voor de inrichting van de presentatie zelf lijken nauwelijks standaardoplossingen te worden gebruikt; vaak gaat het om maatwerktoepassingen die specifiek voor het dienstplatform zijn ontwikkeld. Voor zover dit na te gaan was, worden weinig herbruikbare oplossingen toegepast die uitwisselbaar zijn tussen platformen. 14 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 3. Het dienstplatform van morgen De meeste dienstplatformen zijn gebouwd voordat de huidige netwerkvoorzieningen (Termennetwerk en Datasetregister) en NDE-compatibele collectie-informatiesystemen beschikbaar waren. Hoe zou een dienstplatform eruitzien als het vandaag wordt gebouwd? Dit hoofdstuk beschrijft opnieuw de belangrijkste functies van een dienstplatform, maar dan met deze vraag als vertrekpunt. Inleiding Het vorige hoofdstuk beschreef de huidige praktijk van dienstplatformen, gebaseerd op de belangrijkste functies die bij vrijwel alle onderzochte platformen voorkomen. In dit hoofdstuk wordt verkend hoe dienstplatformen eruit kunnen zien wanneer ze optimaal profiteren van de samenwerking in het netwerk, zoals de Nationale Strategie Digitaal Erfgoed dit beoogt. Concreet gaat het om de volgende uitgangspunten: ● Werken volgens de rollen en verantwoordelijkheden voor bronhouders en dienstverleners, zoals beschreven in de DERA; ● Voortbouwen op NDE-compatibele collectie-informatiesystemen; ● Maximaal gebruikmaken van netwerkvoorzieningen zoals het Datasetregister en het Termennetwerk; ● Vergroten van het aanbod van diensten van verbonden erfgoedinformatie door drempels voor hergebruik te verlagen; ● Vereenvoudigen van het opnemen van broninformatie via verdere standaardisatie en ondersteunende voorzieningen in het netwerk; ● Samenwerking en hergebruik beter mogelijk maken via afspraken over koppelvlakken en datamodellen voor de presentatie van erfgoedinformatie. Hoe kan een dienstplatform eruitzien wanneer het vandaag volgens deze uitgangspunten zou worden gebouwd? Deze vraag wordt beantwoord vanuit twee perspectieven: het implementatieperspectief (wat kan er nu al gedaan worden?) en het ontwikkelperspectief (wat wordt er mogelijk op de langere termijn?). De termen ‘implementatie’ en ‘ontwikkeling’ worden in de rest van dit rapport gebruikt om beide perspectieven te onderscheiden. Bij het implementatieperspectief gaat het om het doorvoeren van de bestaande technische oplossingen en afspraken. Denk hierbij aan het gebruik van de NDE-compatibele bronsystemen en de netwerkvoorzieningen, maar ook aan nieuwe technische oplossingen die nog niet breed worden toegepast. Programma’s gericht op implementatie spelen een belangrijke rol bij het vergroten van de NDE-compatibiliteit. Het Versnellen-programma helpt erfgoedorganisaties bijvoorbeeld om te migreren of over te stappen naar een NDE-compatibel bronsysteem. Ook het werk van de datawerkplaatsen en de digitaal-erfgoed-coaches draagt bij aan verdere standaardisatie en kwaliteitsverbetering. Dankzij deze stappen wordt het eenvoudiger om een dienstplatform in te richten. 15 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Voor het ontwikkelperspectief worden voorstellen gedaan om de bouw van dienstplatformen te vereenvoudigen. Dit kan gaan om het ontwikkelen van nieuwe functionaliteit in de bestaande netwerkvoorzieningen of de ontwikkeling van nieuwe voorzieningen. Nadrukkelijk wordt ook gekeken naar de inzet en doorontwikkeling van bestaande open source oplossingen. Beide perspectieven vragen inzet van alle partijen in het netwerk om tot een nieuwe manier van werken te komen. Bij implementatie ligt de nadruk op samenwerking met betrokken partijen om een NDE-compatibele manier van werken te realiseren. Voor het ontwikkelen van nieuwe functionaliteit is samenwerking nodig tussen instellingen, softwareleveranciers en experts, gericht op het vinden van oplossingen die haalbaar en breed inzetbaar zijn. Scheiding in datalaag en presentatielaag Bij de analyse van de twaalf onderzochte dienstplatformen is nadrukkelijk gekozen voor een scheiding tussen functies voor de datalaag en de presentatielaag. De datalaag creëert een uniforme, verbonden uitsnede van het aanbod van erfgoedinformatie. De presentatielaag presenteert deze passend aan de beoogde gebruiker. Deze scheiding opent mogelijkheden voor nieuwe samenwerkingsvormen tussen dienstplatformen en aanbieders van publiekstoepassingen. In de huidige situatie is dit het standaardbeeld van een dienstplatform. Een dienstplatform haalt informatie op uit diverse bronnen en vormt deze in de datalaag om tot een geïntegreerd geheel. Op basis daarvan richt de presentatielaag de dienst in voor de gebruiker. Nu worden dienstplatformen vaak nog als gesloten systemen gezien, waarbij hergebruik van onderdelen zoals toegang tot de zoekindex of knowledge graph niet mogelijk is. Dit kan in de toekomst veranderen. Wanneer de datalaag en de presentatielaag op elkaar worden aangesloten via open en gestandaardiseerde APIs die de data leveren volgens algemeen gedefinieerde datamodellen, ontstaat een nieuwe dynamiek. De inspanningen van platformen worden dan breder herbruikbaar en andere partijen kunnen eenvoudiger voortbouwen op wat er al beschikbaar is. Hieronder volgen enkele schetsen die dit illustreren. 16 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Het is goed voorstelbaar dat een dienstplatform in de toekomst een presentatielaag inricht op basis van informatie afkomstig uit zowel de eigen datalaag als de datalaag van andere dienstplatformen of bronsystemen. Omdat beide datalagen informatie aanbieden via een gestandaardiseerde API, kan de presentatielaag eenvoudig uit beide API’s putten voor het inrichten van de dienst. Een dergelijke configuratie is denkbaar wanneer een instelling de eigen collectiepresentatie wil verrijken met aanvullende informatie uit het netwerk. Om die reden is het linker dienstplatform in de figuur benoemd als ‘collectieplatform’; de bronnen zijn in dit geval afkomstig van de instelling zelf. De aanzet tot dit patroon is zichtbaar bij het Collectieplatform Nieuwe Instituut. Dit soort scenario’s worden pas mogelijk wanneer dienstplatformen hun datalaag open en herbruikbaar aanbieden. Zoals nu het NDE-compatibel werken bij de bron een belangrijk gemeenschappelijk doel is, zo zal in de toekomst ook het NDE-compatibel werken bij het dienstplatform een belangrijk gemeenschappelijk doel worden. Een volgende ontwikkelstap is om de presentatielaag volledig los te zien van het dienstplatform. De presentatielaag maakt dan gebruik van een koppelvlak dat ergens in het netwerk aanwezig is en wordt aangeboden door een ander dienstplatform. Een voorbeeld hiervan is een creatieve partij die een alternatieve presentatie ontwikkelt voor een bestaande dienst. Het doel kan zijn om informatie beter te laten aansluiten bij een andere doelgroep die door het oorspronkelijke platform niet wordt bediend, bijvoorbeeld het onderwijs. Omdat er een open en gestandaardiseerd koppelvlak is, kan de informatie eenvoudig worden hergebruikt. 17 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten In deze situatie bestaat het dienstplatform feitelijk alleen uit een softwaretoepassing die de presentatielaag verzorgt op basis van een of meer bronnen. Een laatste voorbeeld van een andere manier van denken over dienstplatformen is een dienstplatform dat zelf geen presentatielaag inricht, maar functioneert als koppelvlak voor de presentatielagen van anderen. Het biedt datadiensten aan waarmee anderen diensten voor gebruikers kunnen inrichten. Bovenstaande inzichten zijn meegenomen in de visie op het dienstplatform van morgen, die in de rest van dit hoofdstuk in meer detail wordt uitgewerkt. 18 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Overzicht van de ontwikkelstappen voor dienstplatformen De onderstaande tabel geeft een overzicht van de inhoud van het resterende deel van dit hoofdstuk. Net als in het vorige hoofdstuk vormt het schematisch overzicht van de functies binnen het dienstplatform het vertrekpunt voor de bespreking. In het vorige hoofdstuk is de huidige situatie geschetst. Hier wordt verkend hoe de platformen eruit kunnen zien wanneer ze optimaal profiteren van de samenwerking in het netwerk en aansluiten bij de ontwikkelingen die het NDE-programma in de afgelopen jaar in gang gezet heeft. Bij elke stap komt de ideale toekomstige situatie aan bod, met daarbij acties waar nu al aan gewerkt kan worden (‘Implementatie’) en acties voor de langere termijn (‘Ontwikkeling’). Stap Functie Doel Implementatie Ontwikkeling 1 Opname van de bronnen Dienstplatformen kunnen op een gestandaardiseerde manier broninformatie ophalen en periodiek bijwerken Datasetregister gebruiken voor het opvragen van de bronnen Wijzigingen bij de bron leidend maken voor het bijwerken de opgenomen informatie 2 Selectie van metadata Dienstplatformen krijgen broninformatie op maat aangeleverd en ontvangen informatie over relevante ontwikkelingen bij de bronnen Datasets worden op maat aangeboden voor eenvoudig hergebruik Datasetregister gebruiken om relevante bronnen te ontdekken 3 Normalisatie van gegevens Dienstplatformen krijgen broninformatie van goede kwaliteit die eenvoudig te verwerken is Inzetten op schone, genormaliseerde data bij de bron Inzetten van (AI-)tools om hogere datakwaliteit te bereiken 4a Transformatie naar een geharmoniseerd model (technisch) Dienstplatformen nemen broninformatie op die in linked data-vorm beschikbaar is Meer instellingen gaan NDE-compatibele systemen gebruiken Ontwikkeling van functionaliteit voor automatische transformaties naar linked data 4b Transformatie naar een geharmoniseerd model (inhoudelijk) Dienstplatformen nemen broninformatie op die volgens een standaard datamodel is opgebouwd Meer instellingen gaan hun data volgens het NDE-Schema.orgtoepassingsprofiel publiceren Ontwikkeling van functionaliteit voor automatische transformaties van datamodellen 19 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 5 Inwinnen van verrijkingen Dienstplatformen kunnen de opgenomen informatie eenvoudig verrijken met andere kennisbronnen in het netwerk en publiceren hun verrijkingen volgens een standaardmodel Verrijkingen worden op een gestandaardiseerde manier gepubliceerd Ontwikkeling van functionaliteit voor het zoeken naar termen in een netwerk van verbonden termen (Knowledge Graph voor Termen) 6 Opbouwen van een knowledge graph Dienstplatformen vormen de opgenomen informatie om tot verbonden erfgoedinformatie in de vorm van knowledge graphs De betekenis en samenhang van de verzamelde informatie wordt optimaal benut door het opbouwen van knowledge graphs Ontwikkeling van functionaliteit die toegang tot andere knowledge graphs eenvoudig mogelijk maakt 7 Opbouwen van een zoekindex Dienstplatformen ontwikkelen zoekdiensten die een laagdrempelige ingang op het netwerk van verbonden erfgoedinformatie bieden Voor het opbouwen van zoekindexen wordt gebruikgemaakt van de opgebouwde kennis in de knowledge graphs Ontwikkeling van functionaliteit die het zoeken in geharmoniseerde collecties eenvoudig mogelijk maakt 8 Beschikbaar stellen Dienstplatformen bieden gestandaardiseerde toegang tot hun datalaag zodat standaardtoepassingen hierop aan kunnen sluiten Duidelijke scheiding aanbrengen tussen datalaag en presentatielaag Ontwikkeling van standaard API’s en datamodellen voor verdere standaardisatie van de presentatielaag 9 Ophalen van metadata Dienstplatformen combineren informatie in het platform met informatie uit het netwerk voor het presenteren van relevante erfgoedinformatie aan gebruikers Gedragsprofielen leidend maken voor het opvragen van de informatie Ontwikkeling van functionaliteit om aanvullende informatie uit andere bronnen op te halen 10 Presentatie van metadata Dienstplatformen kunnen gebruikmaken van standaardtoepassingen voor het presenteren van hun informatie Gedragsprofielen leidend maken voor het presenteren van erfgoedinformatie Ontwikkeling van standaard en herbruikbare presentatievormen 20 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bespreking van de functies van de datalaag Het volgende deel beschrijft de acht stappen die samen de datalaag vormen. Vertrekkend vanuit de informatie uit de bronnen wordt de informatie geschikt gemaakt voor gebruik in de presentatielaag. Stap 1: opname van de bronnen Doelstelling De eerste stap bij het bouwen van een dienstplatform is het selecteren en opnemen van gegevens uit de bronnen. In de huidige situatie gebeurt dit vaak nog statisch en handmatig, waarbij voor elke bron specifieke acties of kennis nodig zijn. Het doel voor deze stap is dat dienstplatformen de broninformatie op een gestandaardiseerde manier kunnen ophalen en periodiek bijwerken zodra er wijzigingen bij de bron plaatsvinden. Implementatie: het Datasetregister gebruiken voor het opvragen van de bronnen Dienstplatformen kunnen eenvoudiger werken wanneer ze het Datasetregister als vertrekpunt nemen. Dit register biedt een betrouwbare en machineleesbare manier om inzicht te krijgen in de beschikbare informatie, hoe deze te benaderen is en welke API’s en datadumps beschikbaar zijn. Het Datasetregister heeft als doel om informatie over alle beschikbare bronnen zichtbaar te maken, zodat duidelijk is dat ze bestaan en hoe de data toegankelijk is. In principe kan elke bron worden opgenomen, ongeacht de manier waarop de data wordt gepubliceerd. Als bronhouders nog geen datasetbeschrijving hebben gepubliceerd, bijvoorbeeld omdat hun systeem dit (nog) niet ondersteunt, kan deze eenvoudig worden toegevoegd. Waar nodig kunnen het Datasetregisterteam en de datawerkplaatsen ondersteuning bieden. Dit geldt ook voor gevallen waarin de huidige informatie in het Datasetregister nog niet van voldoende kwaliteit is om goed hergebruik mogelijk te maken. Ontwikkeling: wijzigingen bij de bron leidend maken voor het bijwerken van de opgenomen informatie De datasetbeschrijving biedt ook de mogelijkheid om een wijzigingsdatum door te geven. Bij een goede inrichting van de bron kan een afnemer via deze datum zien dat de dataset gewijzigd is en er een nieuwe versie geladen moet worden. Dit mechanisme wordt al toegepast bij Koloniale Collecties. In de toekomst komen er linked data-publicatievormen beschikbaar waarmee kleine wijzigingen kunnen worden doorgegeven, zonder dat steeds de volledige dataset hoeft te worden vervangen. De meest volwassen technologie hiervoor, gebaseerd op linked data-standaarden, is Linked Data Event Streams (LDES). Een vergelijkbare technologie is de op IIIF gebaseerde Change Discovery API-specificatie. Het Rijksmuseum gebruikt de LDES-technologie al voor de aanlevering aan Koloniale Collecties. Het NDE-team onderzoekt samen met Europeana hoe deze technologie kan worden toegepast voor de doorlevering van data aan Europeana. Stap 2: selectie van metadata Doelstelling In de huidige situatie wordt gewerkt met een vooraf bepaalde selectie van bronnen die worden opgenomen. Bij het opnemen van de brondata is altijd filtering en selectie nodig om te komen tot een op 21 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten maat gemaakte set van informatie die past bij de dienst die het platform wil bieden. Het doel van deze stap is dat dienstplatformen broninformatie direct op maat aangeleverd krijgen en meldingen ontvangen over relevante ontwikkelingen bij de bronnen. Implementatie: datasets worden op maat aangeboden voor eenvoudig hergebruik Om dienstplatformen zo efficiënt mogelijk in te richten, is het handig wanneer bronhouders niet alleen hun volledige dataset aanbieden, maar ook op maat gemaakte versies die eenvoudiger te verwerken zijn. Bijvoorbeeld alle objecten waar een term uit de WO2-Thesaurus aan gekoppeld is, of alle objecten waarvan de vervaardiger de RKDartists-term voor ‘Vincent van Gogh’ bevat. Platformen zoals Oorlogsbronnen en Van Gogh Worldwide kunnen die informatie dan eenvoudiger verwerken. Er geldt geen beperking voor de hoeveelheid datasets die per organisatie kan worden aangeboden. Deelcollecties en de volledige collectie kunnen probleemloos naast elkaar worden gepubliceerd. Het platform Oorlogsbronnen past deze werkwijze regelmatig toe door samen met bronhouders een relevante selectie van het totaal te bepalen en dit als dataset te definiëren. Belangrijk is dat de datasets goed van elkaar te onderscheiden zijn door duidelijke beschrijvingen. In de technische beschrijving kan de relatie tussen datasets worden weergegeven met behulp van een datasetcatalogus of het gebruik van een deel/geheel-eigenschap. Ontwikkeling: het Datasetregister gebruiken om relevante bronnen te ontdekken Op basis van beschrijvingen in het Datasetregister en de beschikbare linked data bij de bron kunnen inhoudelijke analyses worden gemaakt van de informatie. Zo kunnen interessante datasets worden geïdentificeerd en kunnen platformen automatisch meldingen ontvangen van relevante ontwikkelingen bij de bronnen. Denk aan nieuwe datasets met informatie over specifieke schrijvers (voor het Auteursportaal) of datasets met links naar de WO2-Thesaurus (voor Oorlogsbronnen). Een eerste aanzet voor deze aanvullende dienstverlening is nu in ontwikkeling. De dienst ‘Knowledge Graph voor Datasets’ analyseert periodiek alle datasets die beschikbaar zijn als linked data en stelt een profiel op met de belangrijkste kenmerken. De analyse wordt momenteel uitgevoerd op circa 1 miljard triples die via het Datasetregister zijn gevonden (zie code en data story). De dienst wordt verder ontwikkeld met inzichten die zijn opgedaan in concrete toepassingen. Stap 3: normalisatie van gegevens Doelstelling In de huidige situatie is de normalisatie van gegevens, zoals het eenduidig schrijven van datums of namen, een arbeidsintensief onderdeel van het werk van dienstplatformen. De opgeschoonde data blijft doorgaans binnen het platform, waardoor andere platformen hetzelfde werk moeten doen. Vaak zijn voor het opschonen extra hulpmiddelen nodig en moet de data extra worden geëxporteerd en geïmporteerd. Het doel van deze stap is dat dienstplatformen broninformatie aangeboden krijgen die van goede kwaliteit is en eenvoudig te verwerken. Implementatie: inzetten op schone, genormaliseerde data bij de bron Idealiter vindt de normalisatie van gegevens direct bij de bron plaats, op basis van gezamenlijke afspraken binnen het netwerk. Zo wordt de kwaliteit van de bron duurzaam verbeterd en hoeven niet alle hergebruikers dezelfde problemen op te lossen. Bronhouders werken, met ondersteuning van de 22 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten datawerkplaatsen, aan kwaliteitsverbetering van hun gegevens en nemen feedback van dienstplatformen en andere (her)gebruikers mee. Ook het starten van crowdsourcing initiatieven kan hiervoor behulpzaam zijn. Deze werkwijze vraagt om een open houding van bronhouders en actieve communicatie vanuit dienstplatformen en andere hergebruikers, ondersteund door duidelijke, netwerkbrede afspraken over het gebruik van standaarden en het volgen van best practices. Zo geeft de publicatie ’Grip op je data’ tips voor het analyseren en verbeteren van beschrijvingen. Ook voor het verbinden met termen via het Termennetwerk zijn diverse tools en handleidingen beschikbaar. Organisaties die grote hoeveelheden data beschikbaar stellen, zouden ook na moeten denken over processen waarmee terugkoppeling van dienstplatformen en gebruikers eenvoudig verwerkt kan worden. Ontwikkeling: inzetten van (AI-)tools om hogere datakwaliteit te bereiken AI-tools kunnen substantieel bijdragen aan het creëren en opschonen van informatie. Er is grote vooruitgang in het omzetten van handgeschreven teksten of audiovisuele content dankzij technieken als Handwritten Text Recognition (HTR), Automatic Text Recognition (ATR) en Automatic Speech Recognition (ASR). Hierdoor ontstaan er rijke data en metadata, zeker wanneer dit gecombineerd wordt met technieken als Named Entity Recognition (NER). Amsterdam Timemachine heeft deze technieken onder andere toegepast in het Diaries project en het Meaningful Memories project. Ook voor het opschonen en verbeteren van metadatavelden kunnen AI-toepassingen een belangrijke rol spelen. Een grote uitdaging is wel het gericht inzetten van deze technieken. In de bronsystemen zal daarvoor voorlopig nog niet altijd een mogelijkheid zijn. Daarom is het relevant om te verkennen hoe deze technieken als generieke voorziening kunnen worden aangeboden. Bronsystemen moeten dan wel functionaliteit bieden om dit soort verbeteringen of verrijkingen te importeren. Stap 4a: transformatie naar een geharmoniseerd model (technisch) Doelstelling Zoals beschreven in hoofdstuk drie moeten dienstplatformen de verschillende bronnen harmoniseren naar een gemeenschappelijk model dat de basis vormt voor de diensten. Hoewel dit nog niet voor alle dienstplatformen geldt, gebruiken vrijwel alle onderzochte platformen linked data als integratiemethode. Linked data wordt duidelijk gezien als een goede manier om informatie uit verschillende bronnen technisch te integreren. Momenteel kost het echter nog veel inspanning om broninformatie te transformeren naar linked data. Het doel voor deze stap is daarom dat dienstplatformen in de toekomst broninformatie kunnen opnemen die al in linked data-vorm beschikbaar is en daarmee eenvoudiger te integreren. Implementatie: meer instellingen gaan NDE-compatibele systemen gebruiken Dienstplatformen hebben nu vaak nog te maken met een grote verscheidenheid aan manieren waarop de data van bronnen wordt aangeboden, zoals CSV, OAI-PMH, specifieke API’s en linked data. Steeds meer bronhouders publiceren hun data echter op een NDE-compatibele manier, waardoor bronnen steeds vaker als linked data (als dump of via een SPARQL-endpoint) beschikbaar komen. Hierdoor neemt de verscheidenheid sterk af. 23 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Ontwikkeling: ontwikkeling van standaard API’s en datamodellen voor verdere standaardisatie van de presentatielaag Het open maken van de huidige, gesloten API’s is een eerste stap naar meer transparantie. Om echt een nieuw ecosysteem van dienstplatformen te realiseren, is verdere ontwikkeling nodig: open en gestandaardiseerde API’s en datamodellen waarmee standaardtoepassingen op meerdere platformen kunnen worden ingezet. Meer standaardisatie in de aansluiting tussen de datalaag en de presentatielaag creëert nieuwe mogelijkheden voor samenwerking en hergebruik. In plaats van een eigen redactionele pagina te maken zou het Van Gogh Village Museum bijvoorbeeld in de toekomst voor hun pagina over Vincent in Nuenen gebruik kunnen maken van wat er beschikbaar is in het netwerk. Afbeeldingen via IIIF bij het Van Gogh Museum en de bijbehorende rijke metadata via een API van het Van Gogh Worldwide-platform. Met open en gestandaardiseerde API’s – zowel bij de bron als bij het dienstplatform – kan dit scenario eenvoudig werkelijkheid worden. Het uiteindelijke doel is om erfgoedinformatie op elke plaats in het netwerk beschikbaar te stellen via open en gestandaardiseerde API’s: bij de bron, in de netwerkvoorzieningen en na verwerking in dienstplatformen. Deze aanpak zorgt voor een flexibele, dynamische en duurzame samenwerking. De API-strategie van de Nederlandse overheid biedt inspiratie voor deze ontwikkelrichting. Door API’s open te maken ontstaat de mogelijkheid om netwerkbrede afspraken te maken over API-standaarden en bijbehorende datamodellen voor de presentatielaag. Voor collectiemanagementsystemen is het werken met API's en datamodellen inmiddels de dagelijkse praktijk. Voor dienstplatformen zou dit in de toekomst net zo vanzelfsprekend moeten worden. Bespreking van de functies van de presentatielaag De resterende twee stappen zijn onderdeel van de presentatielaag: de laag waar de interactie met de gebruiker plaatsvindt – en daarmee het sluitstuk van de hele keten van bron naar dienst. Op basis van de analyse van de twaalf platformen valt deze laag uiteen in een functie voor het ophalen van de metadata uit de datalaag en de daadwerkelijke presentatie aan de gebruiker. Beide functies bouwen vooral door op inzichten uit de ‘Gids voor het werken met gedragsprofielen’. In de huidige dienstplatformen zien we vooral diensten die gaan over het presenteren van informatie. In de gedragsprofielen is er daarnaast ook nadrukkelijk aandacht voor andere vormen van interactie met de erfgoedinformatie. Als resultaat van de uitwerking van de gedragsprofielen kan dit tot nieuwe soort interacties of interfaces leiden. Stap 9: ophalen van metadata Doelstelling Zoals in de inleiding van dit hoofdstuk beschreven zullen de datalaag en de presentatielaag in de toekomst meer los van elkaar kunnen functioneren. Voor het presenteren van relevante erfgoedinformatie aan gebruikers haalt de presentatielaag informatie op via het koppelvlak dat beschikbaar is gemaakt in de datalaag van het eigen platform. Daarnaast wordt het mogelijk om in de toekomst ook informatie op te halen van andere platformen of bronnen in het netwerk. 30 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Implementatie: gedragsprofielen leidend maken voor opvragen van de informatie Relevante diensten voor gebruikers vragen om kwalitatief goede gegevens die eenvoudig kunnen worden opgevraagd. De bijlage ‘Vereisten voor de (meta)data volgens de gids voor gedragsprofielen’ geeft een overzicht van de eisen die gesteld worden aan de data en metadata voor de verschillende gedragsprofielen. Afhankelijk van het gekozen gedragsprofiel moet de presentatielaag de juiste informatie kunnen opvragen. Gedragsprofielen moeten daarom leidend worden bij het inrichten van de datamodellen waarmee de datalaag de informatie aanbiedt. Veel diensten presenteren beeldmateriaal aan gebruikers. De IIIF-interface biedt een slimme oplossing voor het gestandaardiseerd ophalen en presenteren van beeldinformatie. Alle NDE-compatibele bronsystemen ondersteunen IIIF voor het aanbieden van metadata over beeldmateriaal. Hoewel IIIF bij de start mogelijk extra inspanning vereist omdat het nog nieuwe vrij onbekende technologie gebruikt, voorkomt het ingewikkelde oplossingen om afbeeldingen uit verschillende omgevingen bij elkaar te brengen. Bovendien wordt het vooraf verzamelen en bewerken van afbeeldingen overbodig, wat de transparantie verbetert en de duurzaamheid vergroot. Ontwikkeling: ontwikkeling van functionaliteit om aanvullende informatie uit andere bronnen op te halen Steeds meer gegevens komen bij de bronnen als linked data beschikbaar. Dit betekent dat de informatie links bevat naar gerelateerde of aanvullende informatie elders op het web. Eerder werd al besproken dat het bij verrijkingen nuttig kan zijn deze extra informatie op te halen. Het is ook mogelijk om dit pas later te doen, bijvoorbeeld wanneer een gebruiker de informatie daadwerkelijk opvraagt. Het volgen van de links in de data en het flexibel kunnen integreren van deze aanvullende informatie in de dienst demonstreert de meerwaarde van verbonden erfgoedinformatie. Gouda Tijdmachine is een van de schaarse voorbeelden van de onderzochte platformen die dit principe al toepast. In de presentatie van dit demo-object wordt informatie rechtstreeks opgehaald bij de onderliggende bronnen. Stap 10: presenteren van metadata Als laatste stap wordt verbonden erfgoedinformatie via een gebruikersinterface gepresenteerd aan de gebruiker van de dienst. Dit kan variëren van een eenvoudige widget tot een app of uitgebreide functionaliteit binnen een contentmanagementsysteem. In de visie van het NDE zou uiteindelijk elke omgeving waar erfgoedinformatie wordt gepresenteerd een ingang op het netwerk van verbonden erfgoedinformatie kunnen zijn. Het in contact komen met erfgoedinformatie gebeurt vaak vanuit de eigen vragen of de context van de gebruiker. Door het aanbieden van diensten te vereenvoudigen ontstaan er meer plaatsen waarin gebruikers in contact komen met verbonden erfgoedinformatie, waardoor het bereik wordt vergroot. De voorafgaande stappen gingen over standaardisatie van de data en koppelvlakken. In deze stap staat het beschikbaar maken van standaardtoepassingen centraal. Hiermee kunnen dienstplatformen en instellingen hun erfgoedinformatie eenvoudiger aanbieden binnen de context van de beschikbare informatie in het netwerk. 31 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Implementatie: gedragsprofielen leidend maken voor het presenteren van erfgoedinformatie Het NDE-programma werkt al langere tijd met gedragsprofielen om de beoogde gebruiker zo goed mogelijk te bedienen. De gedachte is dat gebruikers een bepaald gedrag vertonen dat aansluit bij hun doel voor het raadplegen van erfgoedinformatie. Er worden acht verschillende gedragsprofielen onderscheiden. Elk profiel bevat een korte omschrijving en een overzicht van relevante functionaliteiten voor een publiekstoepassing. Voor meer informatie zie de ‘Gids voor het werken met gedragsprofielen’. Veel organisaties werken met een benadering vanuit doelgroepen, bijvoorbeeld aan de hand van ‘persona’s’. Voor dit rapport is als uitgangspunt genomen dat de doelgroepenbenadering uiteindelijk resulteert in het uitwerken volgens een of meer gedragsprofielen. Gedragsprofielen zijn een waardevol hulpmiddel voor ontwikkelaars van dienstplatformen. Ze helpen te bepalen welke functionaliteit en metadata nodig zijn om gebruikers optimaal te bedienen. Daarmee ligt er een goed vertrekpunt om gezamenlijk te werken aan standaardtoepassingen die voldoen aan de eisen van een bepaald gedragsprofiel. Voor het tonen van afbeeldingen zijn inmiddels standaardtoepassingen beschikbaar dankzij het gebruik van de IIIF-standaard. Als een bron toegang via IIIF ondersteunt, kan beeldmateriaal eenvoudig worden gepresenteerd met een van de beschikbare IIIF-viewers. Deze bieden uitgebreide functionaliteit, zoals inzoomen, uitsnedes maken, draaien en spiegelen. Daarnaast biedt de IIIF-media ook mogelijkheden voor verrijkingen zoals tagging of georefereren. Ontwikkeling: ontwikkeling van standaard en herbruikbare presentatievormen In het voorgaande is uitgebreid gesproken over standaardisatie van koppelvlakken (API’s) en de gegevens die daarin beschikbaar gesteld worden. Een volgende stap voor efficiëntere samenwerking in het netwerk is standaardisatie van de functionaliteit waarmee erfgoedinformatie wordt gepresenteerd. De gedragsprofielen bieden een goed uitgangspunt voor verdere standaardisatie op dit gebied. Voor de presentatie van erfgoedinformatie voor het bladeren door afbeeldingen, het scrollen via een tijdlijn of het navigeren over een kaart is in veel gevallen geen maatwerk nodig, maar volstaat een standaardtoepassing. Een dergelijke toepassing levert functionaliteit die voor de meeste diensten voldoet. De vormgeving is daarbij uiteraard volledig zelf in te richten. Door samen te werken aan het beschikbaar maken van dit soort toepassingen voor de meest gangbare presentatievormen, kan gebruikers eenvoudig toegang worden geboden tot verbonden erfgoedinformatie via elke erfgoedwebsite en -app. Een inspirerend voorbeeld in deze context is het initiatief van het Kadaster voor een standaardpresentatie van informatie op een kaart via NLMaps. Vanuit het NDE-programma wordt de komende tijd ingezet op het stimuleren van de ontwikkeling van standaardtoepassingen. Uitgaande van de verschillende gedragsprofielen en bijbehorende weergavetypes worden ontwikkelpartijen uitgenodigd herbruikbare componenten te ontwikkelen. Deze componenten dienen als bouwstenen voor de erfgoedpresentatie binnen erfgoedwebsites en dienstplatformen in het netwerk. 32 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten De herbruikbare componenten maken gebruik van de eerder beschreven standaardkoppelvlakken en -datamodellen. Ze zijn toepasbaar binnen de gangbare contentmanagementsystemen en programmeertalen en worden als open source ontwikkeld. Idealiter draagt elk nieuw initiatief bij aan het opbouwen en verbeteren van deze presentatiecomponenten – bij voorkeur als eis voor projecten met financiering vanuit het netwerk. Als eerste stap worden naar aanleiding van dit rapport gesprekken gestart met alle betrokken partijen om de haalbaarheid te verkennen. Dit moet leiden tot een programma dat, uitgaande van de gedragsprofielen, stapsgewijs standaardcomponenten ontwikkelt voor het presenteren van verbonden erfgoedinformatie. Een mogelijk startpunt is om de focus eerst te richten op een algemene use case, zoals het bladeren door beeldcollecties. Eerste verkenningen in deze richting wordt al uitgevoerd in het MakeMyFlix-project en de Erfgoedflix. Hiermee komt de visie op het dienstplatform van morgen tot een einde. Het volgende en laatste hoofdstuk beschrijft een agenda voor de samenwerking om de opgave van dienstplatformen te vereenvoudigen en hun werk binnen het netwerk breder beschikbaar te maken. 33 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 4. Samen verder bouwen Door samen te werken aan verdere standaardisatie ontstaat een ecosysteem waarin erfgoeddiensten gemakkelijker ontwikkeld kunnen worden. De onderstaande agenda laat zien hoe bronhouders, dienstplatformen en alle andere betrokkenen dit samen kunnen bereiken. Het jaarlijkse NDE-programma onder leiding van het NDE-netwerkteam draagt hieraan bij. Inleiding Het inrichten en onderhouden van een dienstplatform is complex en kostbaar. Tegelijkertijd groeit, aangespoord door de Nationale Strategie Digitaal Erfgoed, de behoefte om erfgoedinformatie uit verschillende bronnen op een zinvolle manier aan gebruikers aan te bieden. Uiteindelijk zal elke website van een erfgoedinstelling fungeren als ingang tot het netwerk van verbonden erfgoedinformatie. Gebruikers krijgen zo toegang tot erfgoedinformatie die is verbonden met informatie van andere instellingen en platformen. Deze dataruimte voor cultureel erfgoed ontstaat door gezamenlijke afspraken, standaarden en netwerkvoorzieningen als het Datasetregister en het Termennetwerk. Tot nu toe worden dienstplatformen vaak als autonome en geïsoleerde programma’s ontwikkeld. Volgens de Nationale Strategie maken ze echter deel uit van de dataruimte voor cultureel erfgoed en zijn ze een belangrijk instrument om erfgoedinformatie bij grote groepen gebruikers te brengen. Met de inzichten uit dit rapport kan een dynamisch ecosysteem ontstaan waarin nieuwe diensten eenvoudiger en tegen lagere kosten worden ingericht, dankzij verdere standaardisatie en nauwere samenwerking. Dit vraagt om duidelijke uitgangspunten voor bronhouders, dienstplatformen en alle verdere betrokken partners, van leveranciers en ontwikkelpartijen tot adviseurs. Zo ontstaat een programma voor een NDE-compatibele manier van werken voor alle deelnemers in het netwerk. Het NDE-netwerkteam geeft hier richting aan via het jaarlijkse NDE-programma, dat mede gericht is op de ontwikkeling en het gebruik van dit dynamische ecosysteem. In lijn met de eisen voor NDE-compatibel werken bij de bronnen tekenen zich, mede door de analyse in dit rapport, ook de contouren af van de realisatie van NDE-compatibele diensten. Deze diensten kenmerken zich doordat ze: ● het Datasetregister als vertrekpunt nemen ● doorbouwen op NDE-compatibele bronnen ● samen met de bronhouders werken aan normalisatie en betere kwaliteit van de broninformatie ● aanvullende informatie op een standaard manier beschikbaar maken voor hergebruik in het netwerk ● een duidelijke scheiding aanbrengen tussen de datalaag en de presentatielaag, en de APIs en metadatamodellen die het koppelvlak vormen standaardiseren en beschikbaar stellen voor hergebruik ● de presentatie voor en interactie met de gebruiker inrichten op basis van de inzichten over de gedragsprofielen. 34 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Het onderstaande overzicht beschrijft hoe de verschillende partners optimaal kunnen bijdragen aan het toegankelijk maken van erfgoedinformatie voor gebruikers op een NDE-compatibele manier. Geordend naar wat nu al kan en waar gezamenlijk naartoe wordt gewerkt, ontstaat het onderstaande beeld. Dit vat de in het vorige hoofdstuk uitgebreid besproken informatie in hoofdlijnen samen, geordend naar de verschillende rollen in het netwerk. Implementatieagenda De dienstplatformen dragen bij door: ● Het gebruik van datasetbeschrijvingen als startpunt voor het verzamelen van broninformatie; ● Het actief benaderen van bronhouders voor het aanbieden van specifieke datasets en datasetbeschrijvingen om de verwerking te vereenvoudigen; ● Het melden van problemen op het gebied van datakwaliteit aan bronhouders; ● Het aansporen van bronhouders om NDE-compatibel te werken (waar mogelijk met financiële ondersteuning); ● Het gebruiken van datasets in linked data-vorm en IIIF wanneer beschikbaar; ● Het toetsen van de bruikbaarheid van het NDE-Schema.org-toepassingsprofiel en het bijdragen aan verbeteringen; ● Het publiceren van verrijkingen volgens een standaardmodel en geschikt voor opname in het Datasetregister; ● Het samenbrengen van de opgenomen informatie in een knowledge graph voor een optimaal gebruik van de verzamelde kennis; ● Het slim gebruikmaken van semantiek voor het bouwen van de zoekindexen; ● Het onderscheid aanbrengen tussen functies van de datalaag en de presentatielaag en in beeld brengen van de koppelvlakken daartussen; ● Het toepassen van gedragsprofielen voor het bepalen van de benodigde informatie; ● Het toepassen van de gedragsprofielen voor het presenteren van de informatie; ● Het gebruik van IIIF voor het ophalen en presenteren van beeldinformatie. De bronhouders dragen bij door: ● Het aanleveren van actuele en rijk beschreven datasetbeschrijvingen; ● Het op maat aanbieden van datasets op basis van de behoeften van de dienstplatformen en andere hergebruikers; ● Het gebruik van het invulboek en andere richtlijnen voor invoer en opschoning van gegevens; ● Het delen van informatie vanuit NDE-compatibele collectie-informatiesystemen dan wel het maken van plannen om daartoe over te schakelen; ● Het beschikbaar stellen van beeldmateriaal dat bruikbaar is voor hergebruik door dienstplatformen en andere partijen (voldoende hoge resolutie, voorzien van de juiste licentievoorwaarden). ● Het publiceren van data volgens het NDE-Schema.org-toepassingsprofiel en eventueel aangevuld met de publicatie volgens een domeinspecifiek toepassingsprofiel; ● Het openstaan voor feedback van dienstplatformen en andere instellingen als reactie op het publiceren van de data; ● Het meewerken aan het opstellen van mappingen van specifieke data naar algemeen gebruikte datamodellen. 35 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Het NDE-programma draagt bij door: ● Het bieden van ondersteuning vanuit het Datasetregister: ○ voor opname van datasetbeschrijvingen en hergebruik van gepubliceerde data; ○ om aangeboden datasets beter te laten aansluiten bij behoeften van dienstplatformen; ● Het bieden van ondersteuning vanuit het Termennetwerk om broninformatie zo veel mogelijk te verbinden met gestandaardiseerde terminologiebronnen; ● Het bieden van ondersteuning bij het opstellen en delen van best practices voor invoer van erfgoeddata; ● Het ontwikkelen van initiatieven om NDE-compatibel werken voor alle bronhouders mogelijk te maken; ● Het onderhouden van het NDE-Schema.org-toepassingsprofiel en verwerking van feedback hierop; ● Ondersteuning bieden bij de doorontwikkeling van domeinspecifieke toepassingsprofielen; ● Het ontwikkelen van een toepassingsprofiel voor het delen van verrijkingen; ● Het verkennen van de mogelijkheden voor (meer) centrale opslag van verrijkingen; ● Het adviseren over opbouw en bevraging van knowledge graphs; ● Het adviseren over opbouw van zoekindexen die de semantiek in de data optimaal benutten en inventarisatie van inspirerende voorbeelden; ● De doorontwikkeling van de DERA voor de dienstplatformen samen met de DERA-Architectuurraad; ● De doorontwikkeling van gedragsprofielen door het formuleren van minimale data-eisen; ● De doorontwikkeling van gedragsprofielen door het formuleren van minimale presentatie-eisen. Ontwikkelagenda De dienstplatformen dragen bij door: ● Een datagestuurd proces voor de opname van bronnen door: ○ verkennen van mogelijkheden om datasets op te halen op basis van wijzigingsdatum; ○ verkennen van mogelijkheden om updates vanuit bronnen te verwerken; ● Het experimenteren met nieuwe technieken voor automatische verbetering van datakwaliteit; ● Het kiezen van standaarddatamodellen als vertrekpunt voor het opnemen van bronnen; ● Het optimaal gebruiken van gelinkte termen voor het zoekproces; ● Het slim gebruikmaken van informatie uit andere knowledge graphs in het netwerk voor verrijking van de eigen dienst; ● Het gebruikmaken van standaard API’s en datamodellen voor het koppelvlak tussen datalaag en presentatielaag; ● Het mogelijk maken om gerelateerde informatie van buiten het platform te integreren; ● Het gebruikmaken van standaardoplossingen voor presentatie van erfgoedinformatie. De bronhouders dragen bij door: ● Betrouwbare wijzigingsdatums van de datasets en de daarin beschreven objecten; ● Het verkennen van mogelijkheden voor het aanbieden van wijzigingen en updates; ● Steeds beter verbinden van informatie met termen en links naar andere relevante informatie; ● Het verkennen van mogelijkheden om feedback of verrijkingen in bulk te verwerken in het systeem; ● Experimenteren met nieuwe technieken voor de automatische verbetering van datakwaliteit. 36 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Het NDE-programma draagt bij door: ● Het experimenteren met doorlevering van gegevens op basis van wijzigingen in de data; ● De doorontwikkeling van de Knowledge Graph voor Datasets op basis van behoeften van dienstplatformen en andere hergebruikers; ● De ondersteuning van experimenten voor automatische verbetering van datakwaliteit; ● De ontwikkeling van faciliteiten voor automatische transformatie naar linked data; ● De ontwikkeling van faciliteiten voor automatische transformatie naar standaarddatamodellen; ● De ontwikkeling van functionaliteit voor optimaal gebruik van verbonden termen, bijvoorbeeld door verkenning van een Knowledge Graph voor Termen; ● Het verkennen van de ontwikkeling van aanvullende knowledge graphs voor betere vindbaarheid van erfgoedinformatie; ● De verkenning van een (meer) centrale zoekindex die een eenvoudige zoekfunctionaliteit biedt voor standaardvragen; ● De ontwikkeling van gemeenschappelijke afspraken over standaarden en toepassingsprofielen voor het gebruik van API’s en datamodellen in het koppelvlak tussen datalaag en presentatielaag; ● Het adviseren over optimaal gebruik van gerelateerde externe informatie en het delen van best practices; ● Het stimuleren van de ontwikkeling van standaardcomponenten voor de presentatie van erfgoedinformatie conform de gedragsprofielen. 37 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bijlage 1: Inventarisatie van 12 dienstplatformen Deze bijlage beschrijft de gedetailleerde analyses van twaalf dienstplatformen die in de periode van januari tot en met december 2024 in kaart gebracht zijn. De dienstplatformen maken allemaal een specifieke selectie van informatie toegankelijk voor gebruikers door gegevens uit meerdere bronnen samen te brengen. Een diversiteit aan dienstplatformen Voor deze analyse is een selectie gemaakt die een goed beeld geeft van de diversiteit van dienstplatformen, zowel qua gebruikte technologie als context en doelstelling. Het meest voorkomende type is het thematische platform dat erfgoedinformatie van verschillende organisaties samenbrengt rondom een specifiek thema. In onderstaand overzicht komen achtereenvolgens de thematische platformen van Delfts aardewerk, Koloniale Collecties, Modemuze, Netwerk Oorlogsbronnen en Van Gogh Worldwide aan bod. Een variant hiervan is het tijdmachineplatform. Ook deze brengt bronnen vanuit één perspectief samen, maar dan met als doel een zo volledig mogelijk beeld te geven van een bepaalde plaats of regio. Hierbij vormen locatie en tijd belangrijke invalshoeken om de geschiedenis van een gebied in de loop der tijd te tonen. Voor dit rapport is gekeken naar Gouda Tijdmachine, Lisse Tijdreis en Amsterdam Time Machine - Diaries, waarbij de laatste een specifieke toepassing is binnen het bredere Amsterdam Time Machineprogramma. Andere platformen zijn ontstaan vanuit organisatorisch perspectief. Zo beschrijft het rapport Linked Open Limburg, waarin infrastructuur en diensten worden ontwikkeld vanuit de samenwerking tussen Limburgse erfgoedinstellingen rondom de Limburg Collectie. Een ander voorbeeld is Podiumkunst.net. Hier werken organisaties samen vanuit hun rol voor de podiumkunsten, met als doel een integraal en toegankelijk digitaal overzicht van het Nederlandse podiumkunsterfgoed te realiseren. Bij dit type platformen staat het realiseren van een overkoepelende infrastructuur centraal waar zo veel mogelijk instellingen bij kunnen aansluiten en op basis waarvan gestandaardiseerde diensten kunnen worden aangeboden. Ten slotte zijn platformen opgenomen die vooral gericht zijn op de presentatie van de eigen collectie van een organisatie, waarbij vergelijkbare inspanningen gedaan worden om informatie uit verschillende bronnen te integreren en toegankelijk te maken voor gebruikers. Hiervan zijn het Collectieplatform van het Nieuwe Instituut en de nieuwe collectie-infrastructuur van het Rijksmuseum de voorbeelden. Hoe de dienstplatformen zijn onderzocht Voor elk dienstplatform is, samen met de beheerders ervan, een gedetailleerde beschrijving van de functionaliteit opgesteld. Deze bestaat uit een korte introductie van de context en het doel, een 38 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten overzichtstekening van alle toegepaste functies en applicaties (het applicatielandschap) en een gedetailleerde beschrijving van hoe de brondata naar de dienst wordt vertaald. Op basis van de verzamelde informatie zijn architectuurschetsen opgesteld die laten zien hoe de functionaliteit van het dienstplatform zich verhoudt tot algemene kenmerken van dienstplatformen zoals die in de DERA beschreven zijn. De architectuurschetsen geven zo een gemeenschappelijk beeld van de inrichting van de dienstplatformen vanuit het perspectief van de DERA. Zo ontstaat er een uniforme manier van kijken naar de platformen. Bij de analyse van de platformen is specifiek gekeken naar twee delen van de infrastructuur. Ten eerste is onderzocht hoe erfgoedinformatie uit bronnen wordt voorbereid voor gebruik binnen het platform – dit deel is aangeduid als de datalaag. Ten tweede is geanalyseerd hoe de samengebrachte informatie wordt verwerkt voor presentatie aan de gebruiker – dit onderdeel van de infrastructuur vormt de presentatielaag. Per platform zijn verder de belangrijkste kenmerken als patronen beschreven. Zo is er gekeken naar de manier waarop broninformatie wordt getransformeerd, hoe binnen de platformen een geharmoniseerd model van de verzamelde gegevens wordt opgebouwd, hoe de interface tussen de dataen presentatielaag is ingericht en op welke manier er gebruikgemaakt wordt van netwerkvoorzieningen zoals het Datasetregister en het Termennetwerk. Op basis van deze analyse kon een reeks algemene uitspraken worden gedaan over de werking van de dienstplatformen. Deze bevindingen vormen de basis voor de bespreking van de dienstplatformen in het eerste deel van dit rapport. Deze bijlage met de inventarisatie van de twaalf dienstplatformen bevat zeer gedetailleerde technische informatie die zich specifiek richt op collega's die bij dit soort platformen betrokken zijn. Er is bewust voor gekozen deze details volledig op te nemen, omdat deze informatie bijzonder waardevol is voor deze doelgroep. Voor zover bekend is dit de eerste keer dat dergelijke informatie op zo’n integrale wijze is gedocumenteerd en beschikbaar wordt gesteld. Voor de niet-technische lezer is het advies om vooral kennis te nemen van de bespreking in het rapport zelf. Niettemin is geprobeerd om de informatie in deze bijlage zo gestructureerd en helder mogelijk te presenteren zodat ook zonder diepgaande technische kennis de lezer toch een beeld kan vormen van de aanpak en inrichting. De tekst bevat bovendien talrijke verwijzingen naar achtergrondinformatie en is voorzien van een begrippenlijst die de belangrijkste termen toelicht. Naast het in kaart brengen van het applicatielandschap van de twaalf platformen is er ook een architectuuranalyse uitgevoerd in het kader van de DERA. Deze analyse is opgesteld in de ArchiMate-architectuurtaal. De samenvatting hiervan is opgenomen in het rapport, de detailanalyses zijn beschikbaar via: https://github.com/netwerk-digitaal-erfgoed/archi-dienstplatformen. 39 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.2 Koloniale Collecties Datahub Beschrijving van het platform Koloniale Collecties Datahub is een project van het Colonial Collections Consortium. Het consortium is een partnerschap van vijf organisaties met expertise op het gebied van koloniale collecties. Het dienstplatform is gebouwd om erfgoedobjecten uit een koloniale context, in Nederlandse musea, digitaal openbaar en toegankelijk te maken. Het is opgezet op basis van linked data, draaiend op een aangepaste architectuur die rekening houdt met de variëteit van brondata en bronhouders. De Datahub bestaat uit twee elementen: een Dataset Browser en een Research Applicatie. Via de Research Applicatie krijgen gebruikers toegang tot de datasets van deze collecties en kunnen ze zowel zoeken als browsen door de objecten. De metadata van de objecten omvat de oorsprong en zo veel mogelijk andere gegevens, zodat onderzoekers en herkomstgemeenschappen wereldwijd kunnen zien wat voor objecten waar in Nederland te vinden zijn. Het platform heeft hierbij als functie om de uitvoering van het Nederlandse restitutiebeleid te ondersteunen. Daarnaast faciliteert de Research Applicatie de samenwerking tussen belanghebbenden, gemeenschappen en onderzoekers. Dit gebeurt via functies waarmee gebruikers informatie, perspectieven en context kunnen toevoegen aan objecten en collecties en waarmee gemeenschappen kunnen worden aangemaakt. Om overzicht te houden op de datasets binnen de Datahub en om hun toegankelijkheid te bepalen, heeft het consortium ook een Dataset Browser ontwikkeld. Met deze applicatie kunnen gebruikers naar datasets zoeken en de belangrijkste kenmerken van een dataset bekijken, zoals licentie, taal en formaat. 46 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Overzicht van het applicatielandschap De belangrijkste functionele componenten van Koloniale Collecties zijn TriplyETL, TriplyDB en maatwerk TypeScript-toepassingen. De onderstaande figuur geeft een overzicht van het applicatielandschap. Bronnen Het goed op orde krijgen van de bronsystemen hoorde ‘officieel’ niet tot de taken van het dienstplatform, maar werd uiteindelijk een groot deel van het project qua tijd en budget. Voor het project hebben Museum Bronbeek, Nationaal Museum van Wereldculturen en NIOD samen voor het project een linked data-publicatievoorziening ingericht op basis van TriplyDB. Het Rijksmuseum en RCE hebben een eigen linked data-publicatievoorziening gebruikt. 1. Museum Bronbeek en Wereldmuseum beheren hun collectie in TMS (The Museum System). Voor beide datasets worden exports opgehaald als datadumps en opgeslagen in GitHub. Met TriplyETL 47 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten worden de metadata-exports getransformeerd naar RDF en ingeladen in TriplyDB, waar ze beschikbaar worden gesteld als linked data met een SPARQL-endpoint. 2. Voor de metadata van NIOD is gebruikgemaakt van een GitHub-repository, waar documenten als YAML-bestanden opgeslagen worden. Met behulp van GitHub-actions worden deze bestanden naar JSON getransformeerd met Python-scripts (ETL NIOD, yaml2json.yml). Met TriplyETL worden de metadata-exports getransformeerd naar RDF en ingeladen in TriplyDB waar ze beschikbaar worden gesteld als linked data met een SPARQL-endpoint. 3. Rijksmuseum heeft eigen data services voor het beschikbaar stellen van zijn collectie. Deze werken via verschillende API's, waarvan de LDES-API wordt gebruikt. 4. Een LDES-client zorgt voor een incrementele update van de metadata zodat alleen de laatste wijzigingen worden opgehaald. 5. Museum Bronbeek, Nationaal Museum van Wereldculturen en NIOD delen een publicatievoorziening op basis van TriplyDB, waarmee de datasets beschikbaar worden gesteld. 6. Vanuit de linked data omgeving van RCE wordt metadata opgehaald en genormaliseerd. 7. Vanuit Memorix Maior (RCE) worden de afbeeldingen opgehaald om te gebruiken in de presentatielaag. Datalaag 8. Koloniale Collecties heeft in de datalaag transformatiescripts die de datasets ophalen en transformeren naar een standaard datamodel, in dit geval Linked Art, zodat de datasets makkelijker verwerkt kunnen worden. Dit resulteert in een knowledge graph die alle datasets bevat en waar Koloniale Collecties garant voor kan staan. Hierbij worden datasets ververst door gebruik te maken van het Datasetregister. Per bron wordt gekeken naar de wijzigingsdatum van de relevante datasetbeschrijving in het Datasetregister (zie stap 21). Alleen wanneer deze datum is gewijzigd ten opzichte van de vorige update, wordt de dataset ververst. 9. De knowledge graph wordt vervolgens ingeladen en gehost als dataset in de TriplyDB-instantie, waar ook de meeste brondatasets te vinden zijn. 10. Vanuit de knowledge graph is een aparte search-graph aangemaakt via een ETL-proces, dat bestaat uit SPARQL-construct queries die per brondataset (Nationaal Museum van Wereldculturen-collectie en -thesaurus, Rijksmuseum en RCE) worden uitgevoerd. De code voor deze processen is te vinden in de Koloniale Collecties GitHub-repository ‘integration-layer’. De search-graph is specifiek ontwikkeld voor het Koloniale Collecties-platform en is gemodelleerd met een eigen – op Schema.org gebaseerd – model. Dit model representeert de data minder gelaagd (platgeslagen). Het proces om de search-graph te bouwen bestaat uit een ‘iteratie’-query die de relevante data uit de knowledge graph ophaalt, en een ‘generate’ construct-query die deze data transformeert naar de CC-ontologie. Ook wordt bijgehouden of er wijzigingen in de knowledge graph zijn (check-query). Is dat het geval, dan worden de iteratieen generatie-queries opnieuw uitgevoerd. Bovenop de search-graph wordt een indexeringstrategie toegepast zodat de metadata eenvoudiger doorzoekbaar is in de Datahub. Door de automatische verversing op basis van wijzigingen in de knowledge graph, is de inhoud van de search-graph veranderlijk. 11. Omdat de bron niet altijd gebruikmaakt van standaardtermen uit terminologiebronnen, is er ook een ETL ontwikkeld om de knowledge graph te verrijken met de juiste terminologie. 48 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 12. In de TriplyDB-instantie van Koloniale Collecties zijn de brondatasets, de knowledge graph met verrijkingen uit terminologiebronnen en de search-graph te vinden. Dit is de datalaagkern die het dienstplatform gebruikt om data op te halen. Dienstenlaag De dienstenlaag is opgebouwd uit twee applicaties: de Data Browser en de Research Applicatie. 13. Koloniale Collecties bestaat uit twee applicaties: de dataset-browser en de research-app, beide gebouwd met Next.js en gehost op het hostingplatform Vercel. 14. Het GUI-prototype is gemaakt om te laten zien hoe een gebruikersinterface eruit zou kunnen zien, mits de data beschikbaar is. Deze prototypes zijn gebouwd in HTML en bevatten componenten om beschikbare data te testen. 15. De Data Browser is gebouwd door het consortium en geeft een overzicht van alle bronnen die data leveren aan Koloniale Collecties. Voor transparantiedoeleinden toont de browser welke datasets zijn opgenomen in de Datahub. Met deze applicatie kunnen gebruikers naar datasets zoeken en de metadata van datasets bekijken. 16. De Research Applicatie (GitHub) staat in verbinding met veel diensten om het proces te faciliteren, zoals een email-provider (SendGrid) voor een contactformulier. Daarnaast haalt de Research Applicatie gestandaardiseerde bronnen en diensten binnen voor een verbeterde gebruikerservaring (GeoNames, OpenStreetMap en Wikidata) en is er een verbinding met externe datastores (zie stap 16-18). Externe databronnen en applicaties Data van externe bronnen, zoals GeoNames en OpenStreetMap, wordt geïntegreerd om geolocatie-informatie en aanvullende context te bieden. 17. Databron voor verrijkingen door gebruikers: toevoegingen van onderzoekers kunnen als zogenaamde nanopublicaties (een model om op een gestandaardiseerde wijze kleine informatiesets, zoals verrijkingen, te delen) opgeslagen worden in een externe voorziening die door Knowledge Pixels wordt geleverd. Via een proxyserver (Fly) worden de verrijkingen opgeslagen. 18. De in stap 16 opgeslagen verrijkingen worden door Knowledge Pixels opgehaald en gepubliceerd. Hierdoor worden ze via de Datahub beschikbaar gesteld. 19. PlanetScale is een database die de mogelijkheid biedt om aangemaakte lijsten/collecties van gebruikers op te slaan. 20. Clerk wordt gebruikt om gebruikers te authenticeren en beheren. De Research Application staat in wisselwerking met Clerk, waarbij gebruikersdata zowel wordt opgeslagen als opgevraagd. De opgeslagen gebruikersgegevens worden weer verder verwerkt door de ETL voor verrijkingen voor de knowledge graph (zie stap 10). 21. De Global Resolver en de Local Resolver zorgen voor het resolven van de ARK URI’s naar een RDF-resource. Netwerklaag 22. De datasetbeschrijvingen van Museum Bronbeek, Nationaal Museum van Wereldculturen en RCE worden geleverd aan het Datasetregister. Verder worden er bronnen opgehaald via het Datasetregister voor het verrijkingsproces van de knowledge graph (zie stap 10). 49 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Architectuurschets De architectuurschets geeft de hierboven beschreven functionaliteit weer in een genormaliseerde vorm. 50 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bespreking belangrijkste patronen Transformatie naar RDF Koloniale Collecties heeft zich ervoor ingezet om de transformatie van metadata naar RDF bij de bronnen zelf te realiseren. Het Rijksmuseum leverde al RDF-data. Hun metadata wordt via LDES opgehaald, waarmee alleen de wijzigingen in de data kunnen worden afgenomen. Koloniale Collecties gebruikt momenteel een aparte triplestore om deze incrementele updates te verwerken, voordat de data wordt toegevoegd aan de centrale knowledge graph. Deze aanpak wordt mogelijk in de toekomst geoptimaliseerd om de integratie verder te stroomlijnen. Gecachete knowledge graph Koloniale Collecties ontsluit een gecachete knowledge graph die is samengesteld uit geaggregeerde metadata uit de bronnen. Om de actualiteit te waarborgen, wordt de cache dagelijks ververst. Een geautomatiseerd proces raadpleegt het Datasetregister om te bepalen of er wijzigingen zijn opgetreden in de datasets van de bronnen. Indien wijzigingen worden gedetecteerd, worden de betreffende datasets in de cache bijgewerkt. Voor de data afkomstig van het Rijksmuseum wordt de registratie van wijzigingen intern door Koloniale Collecties bijgehouden en vervolgens meegenomen in het verversingsproces. Zoekindex Voor de Research Applicatie en de Dataset Browser heeft Koloniale Collecties een zoekindex ontwikkeld, gebaseerd op de gecachete knowledge graph. Voordat de metadata uit de knowledge graph wordt geïndexeerd, wordt deze geoptimaliseerd. Net als de knowledge graph wordt ook de zoekindex dagelijks ververst om actuele resultaten te garanderen. Interface tussen de datalaag en presentatielaag De interface tussen de datalaag en de presentatielaag binnen Koloniale Collecties wordt verzorgd door een SPARQL-endpoint op de gecachete knowledge graph en een search-API op de zoekindex. Het SPARQL-endpoint dient voor specifieke data-opvragingen, terwijl de search-API is geoptimaliseerd voor full-text zoekopdrachten. Gebruik van de netwerkinfrastructuur Binnen Koloniale Collecties wordt gebruikgemaakt van het Datasetregister om de gecachete knowledge graph efficiënt actueel te houden. Een geautomatiseerd proces controleert dagelijks via het Datasetregister of datasets bij de bron zijn gewijzigd. Wanneer wijzigingen worden gedetecteerd, worden alleen de gewijzigde datasets opnieuw verwerkt bij het verversen van de cache. Dit voorkomt onnodige herladingen en zorgt voor een efficiënte en schaalbare manier om de knowledge graph actueel te houden. De informatie in dit deel is tot stand gekomen in afstemming met de volgende personen: Gertjan Filarski, Camiel de Kom en Sjors de Valk. De beschrijving is opgesteld in de periode 2024/2025. 51 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.3 Modemuze Beschrijving van het platform Sinds 2015 dient Modemuze als een online tentoonstellingsruimte en samenwerkingsverband tussen Nederlandse en Belgische musea met een modecollectie. In het Modemuze-platform worden de collecties van alle deelnemende instellingen bij elkaar gebracht en verbonden. Daarnaast biedt het platform mogelijkheden voor crowdsourcing via blogs en nieuwsbrieven. Modemuze heeft, met financiële steun van het Mondriaan Fonds, geïnvesteerd in een infrastructurele herinrichting om beter aan te sluiten op de richtlijnen van de Nationale Strategie Digitaal Erfgoed. De architectuur is gericht op het verbinden van achttien collecties van erfgoedinstellingen, die vervolgens door de Modemuze-pipeline worden verwerkt, waarbij harmonisatie, verrijking, opslag en publicatie plaatsvinden. De website is gebouwd door Finalist en vormgegeven door Ape to Zebra. Overzicht van het applicatielandschap De belangrijkste functionele componenten van Modemuze zijn Python-scripts, MINT, OpenRefine en Drupal. De onderstaande figuur geeft een overzicht van het applicatielandschap. 52 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bronnen 1. Het dataplatform van erfgoedinstellingen levert via OAI-PMH (onder andere TMS en Adlib), als datadump, handmatig of via een eigen API, metadata aan de collector (script) die datasets opvraagt. 2. De collector is een concept, waarbij verzamelde datasets in allerlei vormen opgehaald kunnen worden. Maar in de praktijk bestaat de 'Collector' uit een reeks van aanleverwijzen en -formaten, met verschillende (deels handmatige) processen om ze te kunnen verwerken. Dit kan betekenen dat datasets zowel geharvest kunnen worden via de API door Mint als handmatig verwerkt door Modemuze. 3. Verrijkingen: In de dataverwerking worden termen gekoppeld aan de objectbeschrijvingen (zie stap 8). Daarnaast voegen de redactie en blogschrijvers handmatig termen toe aan artikelen om een koppeling te maken met de collectie voorwerpen (zie stap 12). Datalaag 4. De image collector verzamelt het beeldmateriaal vanuit de Collector en Modemuzes Drupal-dataplatform waar het opgeslagen wordt. 5. De image transformer haalt het verzamelde beeldmateriaal op uit de image collector en transformeert het naar de gewenste grootte en het gewenste formaat. 6. Via de image publisher wordt beeldmateriaal toegankelijk gemaakt binnen Modemuze.nl. 7. Met MINT wordt de opgehaalde metadata 'geharmoniseerd' en ‘genormaliseerd’, door het converteren van verschillende datamodellen of formaten naar RDF/XML gemodelleerd met het EDM-fp-model. De datasets die op deze manier ontstaan worden vervolgens als CSV’s geëxporteerd en ingeladen in OpenRefine of geëxporteerd via MINT’s OAI-PMH (de publisher) en doorgeleverd aan Europeana Fashion. 8. De termen (literals) worden in OpenRefine verrijkt met de reconciliatieservice van terminologiebronnen als AAT en EFT (Europeana Fashion Thesaurus). 9. De CSV-exports uit OpenRefine worden met het RDF transformer-script getransformeerd naar RDF volgens het EDM-fp-model. Dit resulteert in N-Triples datadumps. 10. De RDF-datadumps worden opgeslagen in het Modemuze-datasetregister via een GitHub-repository (de publisher). Via GitHub maakt de publisher de datasets toegankelijk voor de importer. Dienstenlaag 11. De importer: de datasets worden gedownload en handmatig geüpload naar de Modemuze-website. De nieuwe collectie-items worden geïmporteerd met de status 'niet gepubliceerd'. Hier is een script toegevoegd dat alle 'niet-gepubliceerde' collectie-items langsloopt, en neemt daarvan het veld edm:isShownBy. Dit is een link naar de image van het collectie-item, en die wordt opgehaald en lokaal op de server opgeslagen. Dat ophalen gebeurt met een pauze van 5 seconden per image. Het is een traag proces, maar het zal de servers van de instellingen niet belasten. 12. In de Drupal CMS is er een interne veld-mapping waarbij datavelden worden gemapt naar de Drupal-velden voor de correcte representatie op de website. Ook maakt het CMS van alle geïmporteerde image items met het veld edm:isShownBy een aantal 'image styles'. Dit zijn images in kleinere formaten zodat het bekijken van de images op de website sneller en efficiënter verloopt. Voor de zoekfunctionaliteit op de website wordt Search API Solr van Drupal gebruikt. 53 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Netwerklaag 13. Met de publisher worden de – in het EDM-fp-model gemodelleerde – datasets als RDF/XML via MINT’s OAI-PMH gepubliceerd ten behoeve van Europeana Fashion. 14. Het toegankelijk maken van de datasets voor Europeana Fashion (EF) is een aparte dienst en staat los van het Modemuze.nl-platform. 15. Modemuze maakt op dit moment nog geen gebruik van het Datasetregister voor het ophalen van informatie bij de bron. 54 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Architectuurschets De architectuurschets geeft de hierboven beschreven functionaliteit weer in een genormaliseerde vorm. 55 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.5 Van Gogh Worldwide Beschrijving van het platform Van Gogh Worldwide brengt collecties samen die informatie bevatten over de werken van Vincent van Gogh, zoals schilderijen, tekeningen en prenten. Het platform streeft ernaar wereldwijde informatie over Van Goghs werken te verzamelen. Het dienstplatform is gebouwd vanuit een samenwerking tussen het RKD, het Van Gogh Museum en het Kröller-Müller Museum. De architectuur van Van Gogh Worldwide gebruikt linked data als basis om collecties samen te brengen. Het kan uitgebreid worden met meer collecties en is generiek inzetbaar door te werken met linked data vanuit de bron, modellering met Linked Art en het koppelen van thesaurustermen zoals de AAT en RKDartists. Hoewel de architectuur van Van Gogh Worldwide is gericht op linked data vanuit de bron, vinden er nog wel bewerkingen en transformaties plaats als tussenstap tussen bron en dienstplatform. Overzicht van het applicatielandschap De belangrijkste functionele componenten van Van Gogh Worldwide zijn Spinque Desk, Drupal en het React-framework. De onderstaande figuur geeft een overzicht van het applicatielandschap. 62 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bronnen Data over Van Gogh wordt verzameld vanuit de hele wereld, vaak ook van kleine instellingen. De kernpartners zijn het Van Gogh Museum, het Kröller-Müller Museum en het RKD. Voor deze hoofdpartners van het consortium gelden strengere eisen voor het leveren van data, zoals het aanleveren van data via een API. Voor de andere instellingen, die een klein gedeelte van hun collectie leveren en die de stap naar linked data nog niet hebben gemaakt, gelden soepelere regels. 1. Instellingen die (een deel van) de collectie nog niet als linked data kunnen delen, krijgen van het consortium een template met instructies hoe ze hun data kunnen leveren. Deze instructies staan ook in de GitHub-repository. Het formaat van de gestructureerde metadata kan wisselen per instelling en kan geleverd worden als RDF gemodelleerd in Linked Art, als CSV volgens het sjabloon van het Van Gogh Consortium, of XML volgens LIDO. Data via de API’s van de bronsystemen moet gemodelleerd zijn in Linked Art en termen dienen te worden gereconcilieerd met de terminologiebronnen AAT (Art & Architecture Thesaurus), TGN (Getty Thesaurus of Geographic Names) en RKDartists of ULAN (Union List of Artist Names). Als dit onvoldoende is gedaan bij de aangeleverde bronnen, verleent het Consortium een service door ze te modelleren en (beperkt) te reconciliëren in Spinque Desk. Bronnen mogen ook via het RKD hun collecties aansluiten. Alle modellering en reconciliatie als service heeft tot doel de data bruikbaar te maken voor het dienstplatform zonder inhoudelijke aanpassingen of verrijkingen. Dit gebeurt deels automatisch, deels handmatig. 2. Founding partners (het Van Gogh Museum, het Kröller-Müller Museum en het RKD) leveren RDF-datadumps gemodelleerd in Linked Art. Zij hebben een eigen ETL-proces voor de transformatie van data naar RDF. De resulterende RDF-datadumps worden geïntegreerd in de VGW Knowledge Graph in Spinque Desk. Meestal betreft het RDF datadump exports; een enkele partner levert via een API. 2.1. Het Van Gogh Museum en het RKD beheren hun collecties in Axiell Collections. Kröller-Müller Museum gebruikt TMS (The Museum System) als collectiebeheersysteem. 2.2. Daarnaast zijn er instellingen die niet behoren tot de hoofdpartners, zoals de RCE (Rijksdienst voor het Cultureel Erfgoed), maar die wel collectiedata kunnen leveren als RDF-datadump in de GitHub-instantie van VGW. Deze dumps zijn al gemodelleerd in Linked Art en verrijkt met de juiste terminologiebronnen. Datalaag 3. Spinque Desk is een platform dat wel vaker wordt gebruikt binnen het erfgoedveld om verschillende collecties bij elkaar te brengen in een gemeenschappelijk model. Hierop wordt een knowledge graph gebouwd, waarbij zoekstrategieën op maat kunnen worden gemaakt. In Spinque Desk van Van Gogh Worldwide worden de beschreven bronnen van stap 2 geïmporteerd en direct geïntegreerd in de VGW Knowledge Graph. De bronnen van stap 1 die als XML of CSV worden geleverd, worden in Spinque Desk getransformeerd naar RDF en gemodelleerd in Linked Art. De Mapping Tool is een standaardonderdeel van Spinque Desk. Belangrijk is dat het Van Gogh Consortium autonomie heeft in Spinque Desk om zelf data te importeren, transformeren, modelleren en de zoekstrategieën aan te passen. Zo kan de knowledge graph opnieuw worden gebouwd en kan de API worden geüpdatet. 4. In Spinque Desk kunnen zoekstrategieën worden samengesteld met onder andere filtering, ordenen, matching en samenvoeging van data om een bepaalde vraag te beantwoorden. Hiermee worden API’s gegenereerd die alleen de benodigde data leveren voor de specifieke componenten van het dienstplatform. Spinque verzorgde de initiële configuratie; bij 63 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten veranderingen kan VGW het zelf instellen, vooralsnog in overleg met Spinque. Daarnaast worden deze zoekstrategieën ook gebruikt voor koppelingen (bijvoorbeeld over tentoonstellingen) die niet mogelijk zijn met alleen de knowledge graph. Dienstenlaag 5. Vangoghworldwide.org is gebouwd door Limoengroen en ontwikkeld met Drupal in combinatie met een React-framework. Limoengroen doet het webbeheer en de aanpassingen. Daardoor kan het Van Gogh Consortium niet zelf pagina’s aanmaken of iets toevoegen. Dit is zo opgezet omdat er geen behoefte was aan een dynamische opzet en omdat het kostenbesparend is. 6. De zoekfunctie is een van de componenten van vangoghworldwide.org en biedt gebruikers de mogelijkheid om te zoeken naar een kunstwerk op onder andere titel, collectienummer en F-nummer (een catalogusnummer). 7. De kaartfunctionaliteit toont de locaties van erfgoedpartners en musea op een wereldkaart. Hier kunnen gebruikers inzoomen en op een museum klikken, waarna ze de mogelijkheid hebben om de koppeling te volgen naar de kunstwerken uit dat specifieke museum. De kaart gebruikt Leaflet met OpenStreetMap als kaartlaag. 8. De galerij toont de kunstwerken met een filteroptie voor de periode, collectielocatie, uit welke instelling het afkomstig is en andere relevante kenmerken zoals materiaal en techniek. Op de itempagina staan alle kenmerken uitgebreid weergegeven, inclusief koppelingen naar externe bronnen. 9. Afbeeldingen worden beschikbaar gesteld volgens de IIIF-standaard en op de website getoond met behulp van de Mirador-viewer. Netwerklaag 10. Het Van Gogh Worldwide Consortium kan bepalen welke datasets als RDF-datadumps beschikbaar worden gesteld via de Spinque-dataservice. Het Datasetregister neemt de beschikbare datasets op in het register aan de hand van de datasetbeschrijvingen die de Spinque-dataservice meelevert. 11. Alle reconciliatie met het Termennetwerk vindt plaats bij de bron. 64 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Architectuurschets De architectuurschets geeft de hierboven beschreven functionaliteit weer in een genormaliseerde vorm. Bespreking belangrijkste patronen Transformatie naar RDF De founding partners en enkele andere instellingen leveren hun metadata direct als RDF, gemodelleerd volgens Linked Art. Hierdoor is de metadata (vrijwel) direct geschikt voor integratie binnen het platform. De meeste instellingen kunnen in de praktijk nog geen linked data leveren. Voor die instellingen biedt het Van Gogh Worldwide Consortium ondersteuning via templates en een handboek. Gegevens kunnen worden aangeleverd als CSV volgens het sjabloon van het Consortium of als XML in LIDO-formaat. Hiervoor is een standaard transformatiepipeline ingericht in Spinque Desk, waarbij de data wordt gemodelleerd naar Linked Art en termen worden in beperkte mate gereconcilieerd met 65 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten terminologiebronnen. Deze transformatie maakt de data bruikbaar binnen het platform zonder inhoudelijke wijzigingen of verrijkingen. De verwerking gebeurt deels automatisch, deels handmatig. (Gecachete) knowledge graph Van Gogh Worldwide gebruikt een (gecachte) knowledge graph voor efficiënte toegang tot collectiegegevens. Deze knowledge graph wordt opgebouwd uit data van verschillende bronnen en gemodelleerd volgens Linked Art. De cache is partieel: een deel van de data is slechts eenmalig aangeleverd door bronnen en wordt niet periodiek ververst. Het periodiek ophalen en verwerken van data beperkt zich tot bronnen die frequente updates aanleveren. De knowledge graph wordt opgeslagen in een graafgebaseerde opslag binnen de datalaag van het dienstplatform. Zoekindex Op de knowledge graph index kan tevens zoekfunctionaliteit gebouwd worden. Deze fungeert dan ook als zoekindex. Interface tussen de datalaag en gebruik Een REST API faciliteert de uitwisseling van gegevens tussen de datalaag en de presentatielaag. Deze API gebruikt de knowledge graph index en levert data aan in JSON-formaat, zodat de presentatielaag efficiënt objectinformatie en gerelateerde metadata kan ophalen. Voor zoekfunctionaliteit biedt Van Gogh Worldwide een aparte zoek-API, die ook in JSON-formaat resultaten teruggeeft. Ook de zoek-API gebruikt de knowledge graph index. Voor het leveren van afbeeldingen aan de presentatielaag zijn er verschillende opties. Als bronnen zelf een IIIF Image API aanbieden, wordt deze direct gebruikt vanaf de presentatielaag. Als bronnen afbeeldingen via HTTP aanleveren zonder IIIF-ondersteuning, fungeert de IIIF image server van Van Gogh Worldwide als een proxy voor het ophalen van de afbeeldingen. Zo kunnen de mogelijkheden van IIIF toch worden benut. Bij de partijen die afbeeldingen alleen als download aanbieden, worden de afbeeldingen opgenomen in de datalaag van Van Gogh Worldwide. De IIIF-server kan ze dan via de IIIF Image API leveren aan de presentatielaag. Gebruik van de netwerkinfrastructuur Relevante wijzigingen in de datasetbeschrijving in de dataservice van Spinque worden bijgewerkt in het Datasetregister, zodat externe partijen altijd toegang hebben tot de meest actuele metadata. Ook stelt Van Gogh Worldwide een RDF-dump van de dataset beschikbaar voor hergebruik door andere platformen. Het platform maakt zelf geen gebruik van het Datasetregister voor het vinden of bijwerken van relevante bronnen. De informatie in dit deel is tot stand gekomen in afstemming met de volgende personen: Lian Wintermans en Reinier van 't Zelfde. De beschrijving is opgesteld in de periode 2024/2025. 66 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.6 De Gouda Tijdmachine Beschrijving van het platform De Gouda Tijdmachine is een project dat de historische ontwikkeling van de stad Gouda digitaal reconstrueert. Het project verzamelt onder andere data over gebouwen, straten, waterwegen, bedrijven en bewoners, waarbij archiefbronnen worden gedigitaliseerd en gekoppeld. Via verschillende publiekstoepassingen wordt deze gekoppelde data gevisualiseerd. Daarnaast is de data beschikbaar voor anderen om eigen publiekstoepassingen op te bouwen of te koppelen aan andere dienstplatformen. Het project gebruikt het Omeka-S, een linked-data-by-design collectiebeheersysteem, om de verzamelde data als open data beschikbaar te stellen. Vrijwilligers spelen een belangrijke rol bij het transcriberen en invoeren van data. Zij kunnen tevens online bijdragen via het crowdsourcingplatform 'Vele Panden'. Streekarchief Midden-Holland participeert actief in het project, Historische Vereniging Die Goude ondersteunt het initiatief. Overzicht van het applicatielandschap De belangrijkste functionele componenten van de Gouda Tijdmachine zijn Omeka-S en GraphDB. De onderstaande figuur geeft een overzicht van het applicatielandschap. 67 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bronnen/datalaag 1. CSV-bestanden worden direct ingelezen en verwerkt in Omeka S, of ondergaan eerst een metadatapreparatiestap via OpenRefine en/of worden verwerkt door scripts voordat ze in Omeka S worden geïmporteerd. 2. In sommige gevallen wordt de data opgeschoond in OpenRefine. 3. De metadatapreparatiescripts zetten de data om naar tekstbestanden met kolomkoppen die overeenkomen met de veldnamen. Dit vereenvoudigt het importeren en mappen in Omeka S. 4. Afbeeldingen die niet beschikbaar zijn in IIIF-formaat, worden geïmporteerd in Omeka S. Een Omeka S-module maakt deze afbeeldingen toegankelijk via de IIIF Image API (image server) en de IIIF Presentation API. 5. Afbeeldingen die al in IIIF-formaat beschikbaar zijn, worden als IIIF-link toegevoegd aan bestaande items. 6. Omeka S fungeert als het collectiebeheersysteem en gebruikt de semantische ondersteuning voor het modelleren van de metadata en het toekennen van een ARK-persistent identifier. Daarnaast fungeert Omeka S ook als publicatieomgeving van de collectiedata. Netwerklaag 7. Met de module NDE-Termennetwerk worden termen verbonden met de metadata uit de imports. 8. Een PHP-crawler (een applicatie die data in documenten op het web kan verzamelen) harvest N-Triples van de Omeka S API. Een Bash script verzamelt de N-Triples, per resource opgeslagen in MongoDB (een document-georiënteerde database met een JSON-achtige opslagstructuur) en gepubliceerd als een datadump. De harvester is geoptimaliseerd om alleen nieuwe en bijgewerkte resources te verwerken. Dit wordt bepaald op basis van metadata in Omeka S die het moment waarop een resource voor het laatst gewijzigd is aangeeft. Vervolgens wordt deze datadump geïmporteerd in GraphDB. 9. GraphDB stelt het SPARQL-endpoint beschikbaar. 10. Voor het Termennetwerk stelt de Gouda Tijdmachine haar thesauri beschikbaar. Voor betere performance gebruikt het SPARQL-endpoint een Lucene-index. 11. Een PHP-crawler, gebruikmakend van EasyRDF, roept de Omeka-S data catalogue API aan om de datasetbeschrijvingen van de bij stap 8 gemaakte datadump samen met andere (bron)datasets aan te melden bij het Datasetregister. 68 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Gouda Tijdmachine data pipelines Dienstenlaag Gouda Tijdmachine heeft zich eerst vooral gefocust op het dataplatform. Voor het dienstplatform worden nu verschillende onderdelen ontwikkeld: een location-based game en een publieksviewer met een kaart, tijdlijn en objectinformatie, gebaseerd op data uit het dataplatform. 12. Omeka S en WordPress worden gebruikt om de collectiebrowser in de presentatielaag van het dataplatform vorm te geven. Het beheer van de datacomponenten op de website gebeurt via de Omeka S API en de Image-, IIIFen Tile Server (een component om kaartmateriaal efficiënt te serveren). De website voorziet ook in functionaliteit om gelinkte informatie te tonen. Bij de gepresenteerde URI’s wordt, bij het aanklikken, de achterliggende informatie opgehaald en als sub-tabel getoond (zie demopagina). 13. Omeka S ondersteunt ook linked data URI resolving met content negotiation. 14. WordPress publiceert een website die tijdelijk als dienstplatform fungeert. 15. Voor de publieksviewer (zie https://gtm-poc-gui.vercel.app/ voor een PoC) en presentaties als https://www.goudatijdmachine.nl/omeka/s/data/page/gebouwen wordt veelvuldig gebruikgemaakt van GeoJSON, die wordt gegenereerd in het dataplatform. Voor de achtergrondkaarten wordt de Web Map Service (WMS)-standaard van het Open Geospatial Consortium (OGC) gebruikt. 16. De Gouda Tijddetective is een location-based game in ontwikkeling door Living Story en Tourio. Voor het werken met de linked data uit het platform heeft Tourio een lod-explorer ontwikkeld die laagdrempelig inzicht geeft in de beschikbare data van het SPARQL-endpoint van de Gouda Tijdmachine. 69 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Architectuurschets De architectuurschets geeft de hierboven beschreven functionaliteit weer in een genormaliseerde vorm. Bespreking belangrijkste patronen Transformatie naar RDF De meeste bronnen voor de Gouda Tijdmachine zijn nog niet als linked data beschikbaar en worden binnen het platform naar RDF getransformeerd. Daarnaast is er vaak erfgoedmateriaal zonder bijbehorende metadata. Het platform biedt een beheerfunctie voor het invoeren van metadata voor dit materiaal. 70 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Gecachete knowledge graph De Gouda Tijdmachine biedt een gecachete knowledge graph die via SPARQL te bevragen is. De cache wordt periodiek ververst. Bij elke verversing wordt de RDF API doorzocht om te bepalen welke objectbeschrijvingen nieuw of gewijzigd zijn sinds de vorige update. Alleen deze beschrijvingen worden dan verwerkt. Zoekindex De zoekfunctionaliteit van de Gouda Tijdmachine gebruikt de standaard zoekmogelijkheden van Omeka S, die ook via een API beschikbaar zijn. Voor uitgebreidere zoekopties is de Omeka S Advanced Search-module toegevoegd. Vanwege de schaal van het platform – met bijna 1,8 miljoen items – wordt ook een Solr-module gebruikt. Deze module biedt toegang tot een Apache Solr-installatie die speciaal is ingericht om efficiënte zoekopdrachten op grote datasets te verwerken. Interface tussen de datalaag en presentatielaag De uitwisseling van metadata tussen de datalaag en presentatielaag gebeurt via een RDF API (JSON-LD) en een SPARQL-endpoint op de gecachete knowledge graph en de search API op ze zoekindex. Voor de achtergrondkaarten wordt een achtergrondkaart-API gebruikt. Geo-features worden uitgewisseld via een GeoJSON API. Afbeeldingen worden gedeeld via de IIIF Image API en de IIIF Presentation API. Deze worden waar mogelijk rechtstreeks bij de bron opgevraagd. Bij ontbrekende bron-API’s worden afbeeldingen opgenomen in de datalaag van de dienst, die een eigen IIIF Imageen Presentation API aanbiedt. Gebruik van de netwerkinfrastructuur De Gouda Tijdmachine gebruikt het Termennetwerk door termen te reconciliëren met behulp van het Termennetwerk tijdens het transformatieproces naar RDF. Relevante termen worden gematcht en geïntegreerd in de getransformeerde metadata. Dit zorgt voor verbinding met andere datasets in het Netwerk Digitaal Erfgoed. Daarnaast worden de datasetbeschrijvingen van de resulterende datasets gepubliceerd in het Datasetregister, waardoor de datasets vindbaar en herbruikbaar worden binnen het bredere erfgoednetwerk. Om deze integratie te vergemakkelijken, is een Omeka S-module (LinkedDataSets) ontwikkeld, waarmee datasets eenvoudig als linked data kunnen worden geregistreerd. De informatie in dit deel is tot stand gekomen in afstemming met Bob Coret. De beschrijving is opgesteld in de periode 2024/2025. 71 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.8 Amsterdam Time Machine - Diaries Beschrijving van het platform Amsterdam Time Machine - Diaries kwam in mei 2024 online. Deze site toont fragmenten uit dagboeken van zes vrouwen die in Amsterdam woonden tijdens de Tweede Wereldoorlog. De persoonlijke verhalen staan in dagboekvorm weergegeven. De site gebruikt linked open data om de dagboekteksten te presenteren, te verrijken en met elkaar te verbinden. Dat gebeurt op basis van namen, locaties, organisaties, het thema eten en drinken en data. De opgenomen dagboeken komen uit het Verzetsmuseum, Atria, Stadsarchief Amsterdam en het Joods Historisch Museum. Ze zijn ook in te zien via Delpher/HetGeheugen. Dit prototype laat zien wat Amsterdam Time Machine allemaal kan met linked open data. De publiekstoepassing toont hoe nieuwe verhalen kunnen worden verteld en hoe bronnen uit archieven, musea en bibliotheken en andere databronnen zoals Wikidata met elkaar kunnen worden verbonden en verrijkt. De Amsterdam Time Machine - Diaries-webapplicatie wordt verder ontwikkeld om een rijkere gebruikerservaring te bieden. Op dit moment heeft de site themapagina’s waarop een eerste thema is uitgewerkt, galerijen over onder andere dagboekschrijfsters, inclusief een korte biografie van de schrijfsters en personen en organisaties die in de dagboekfragmenten genoemd worden, met verwijzingen naar externe databronnen zoals Wikidata. Ook is er een kaartweergave met alle locatiegerelateerde passages uit de dagboeken, getoond op een historische kaart van Amsterdam uit 1943, en een kalender waar bezoekers dagboekfragmenten en/of pagina’s met een specifieke datum kunnen zoeken. Daarnaast is het mogelijk per fragment te ‘flippen’ tussen de originele (geschreven) en de getranscribeerde versie van een dagboek. 78 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Overzicht van het applicatielandschap De belangrijkste functionele componenten voor de presentatielaag zijn MariaDB en Nuxt/TypeScript, voor de datalaag zijn dit GitHub, Transkribus, OpenRefine en diverse Python-scripts. 79 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bronnen 1. Inventarisatie van dagboeken: Onder begeleiding van een universitair docent hebben studenten dagboeken gezocht die relevant zijn voor Amsterdam, vooral uit de 19e en 20e eeuw, met speciale aandacht voor dagboeken van vrouwen in Amsterdam tijdens het Interbellum en de Tweede Wereldoorlog. Veel van deze dagboeken zijn online in te zien, vooral in Delpher/Het Geheugen of in de online collectie van erfgoedorganisaties. Uiteindelijk zijn dagboeken geselecteerd uit de collecties van het Verzetsmuseum, Atria, Stadsarchief Amsterdam en het Joods Historisch Museum. Datalaag 2. De dagboeken worden getranscribeerd met Transkribus, een tool voor handschriftherkenning. De volgende stappen worden hierbij doorlopen: 2.1. De JPEGs worden geüpload. Er wordt een basic layout-analyse over de pagina’s gedaan met het Transkribus LA-model. Daarna vindt verfijning plaats door classificaties voor regio’s mee te geven aan header, paragraaf, bijschrift, afbeelding en paginanummer. De automatische transcripties zijn een startpunt en worden vervolgens gecontroleerd en gecorrigeerd door studenten en begeleiders . Afhankelijk van het handschrift kan er veel tijd gaan zitten in de curatie hiervan. Deze informatie kan uiteindelijk geëxporteerd worden in het PageXML-formaat. 2.2. In Transkribus worden tekstpassages geannoteerd met informatie over personen, plaatsen, datums en organisaties. De geannoteerde data wordt geëxporteerd vanuit Transkribus als XML-bestanden. Omdat deze gevonden entiteiten met meer dan alleen Wikidata (bijvoorbeeld Adamlink) gelinkt worden, wordt geen gebruik gemaakt van de ingebouwde functie in Transkribus om termen aan Wikidata te koppelen. 2.3. De XML bestanden worden via een datavoorbereidscript omgezet naar CSV. 3. In OpenRefine worden de XML-bestanden geïmporteerd en omgezet naar CSV. Ook vindt hier verrijking plaats met externe bronnen zoals Wikidata en Adamlink via de Termennetwerk-reconciliatieservice (zie stappen 14 en 15). 4. De CSV-bestanden uit OpenRefine worden opgeslagen in de Amsterdam Time Machine GitHub-repository. Het script main.py realiseert meerdere processen: 4.1. De regio’s en textlines uit de PageXML worden omgezet naar webannotaties. 4.2. Metadata van de dagboeken en schrijfsters wordt gemodelleerd met het op Schema.org gebaseerde Amsterdam Diaries-model. 4.3. De gebruikte concepten (eten en drinken) worden in SKOS beschreven. 4.4. De annotaties van entiteiten in de dagboeken worden als webannotaties gemodelleerd. 4.5. Links naar externe resources worden toegevoegd aan de entiteitsannotaties. 4.6. Output-formaat is in JSON-LD. 5. Met het Python-script ‘update_external_resources.py’ wordt de annotatiedata verrijkt met metadata uit Wikidata en Adamlink . 5.1. Met een SPARQL-query wordt vanuit Wikidata de locatie-label, -beschrijving en -geometrie (longitude en latitude) opgehaald. 5.2. Locatiegegevens worden ook vanuit Adamlink opgehaald met een SPARQL-query. Het gaat hier ook om locatie-label, -beschrijving en -geometrie (asWKT). Voor de geolocaties worden de coördinaten omgezet naar latitude en longitude zodat deze gebruikt kunnen worden in Leaflet (stap 13). 80 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 5.3. De verrijking gebeurt in ‘annotations_linking.csv’, die aangemaakt is door main.py en die metadata van dagboekfragmenten heeft. Aan de ‘annotations_linking.csv’ worden de eigenschappen voor locatie toegevoegd van Wikidata, en waar het ontbreekt aangevuld door Adamlink. Bij het opnieuw uitdraaien van main.py wordt de extra informatie toegevoegd. Dit onderdeel is ingebouwd vanwege een gebrek aan een database en werkt naar tevredenheid om de identifiers van de annotaties stabiel te houden. 5.4. Bij gebrek aan een IIIF-endpoint van de erfgoedaanbieders host Amsterdam Diaries zelf de scans. Alleen op die manier kunnen fragmenten uit de scans getoond worden in de applicatie (via xywh-fragmentselector). In het ideale geval kan ook verwezen worden naar de IIIF Image API-endpoints van erfgoedinstellingen, waarbij geannoteerd wordt op de canvas-URI’s die erfgoedinstellingen beschikbaar maken. Dienstenlaag 6. De Amsterdam Diaries Time Machine-applicatie biedt toegang tot dagboekfragmenten waar bezoekers doorheen kunnen navigeren . De applicatie is gebouwd door Total Design, gebruik makend van een Nuxt-framework waarin zich alle applicatielogica bevindt. De Amsterdam Diaries Time Machine Vue-applicatie verzorgt met name de front-end componenten, zoals dagboekpagina's, galerijen, een kaartweergave en een kalenderpagina. Daarnaast wordt er gebruikgemaakt van MariaDB zodat het in de applicatiedata wordt weggeschreven en weer wordt opgehaald om het te gebruiken in andere componenten. 7. In de Nuxt-applicatie zijn er importer-scripts die Amsterdam Diaries Time Machine-data ophalen uit de ‘amsterdam-diaries-data/rdf’-folder (via REST API) in JSON-LD-formaat. De (meta)data wordt naar een relationele structuur verwerkt (rijen en kolommen) en als tabellen opgeslagen in MariaDB. 8. In de applicatie wordt data vanuit MariaDB opgehaald via SQL-queries en gemapt zodat deze bruikbaar is in de componenten. 9. In de applicatie is de OpenSeadragon-module geïmplementeerd om de originele dagboekscans te kunnen bekijken. Bij gebrek aan een IIIF-endpoint van de erfgoedaanbieders worden de scans gehost door Amsterdam Diaries Time Machine. Op die manier kunnen fragmenten uit de scans getoond worden in de applicatie (via xywh-fragmentselector). Verder is het mogelijk, mits de erfgoedaanbieders een IIIF Image API-endpoint kunnen leveren, om ernaar te verwijzen en hebben alle webannotaties de desbetreffende URL als target, en/of wordt er direct geannoteerd aan de canvas-URI’s die erfgoedinstellingen beschikbaar maken. Momenteel wordt er door betrokken erfgoedinstellingen nog geen gebruikgemaakt van een IIIF Presentation API en worden er alleen nog maar scans geannoteerd. 10. De website gebruikt geen zoekfunctionaliteit of filters maar er is gekozen voor themapagina's voor ‘personen’, ‘dagboekschrijfsters’, ‘thema’s’ en ‘organisaties’ waar de data en entiteiten weergegeven worden als in een galerij. 11. Voor de kaartviewer wordt Leaflet in de applicatie geïmplementeerd die een historische kaart weergeeft uit 1943 van Amsterdam. Hiervoor worden de tiles uit https://tiles.amsterdamtimemachine.nl/ gebruikt. De logica achter de kaartpagina toont een lijst van dagboekfragmenten die bijgewerkt worden op basis van de geselecteerde locatie op de kaart. 12. De kalenderfunctionaliteit maakt het mogelijk om op een kalender op datums te klikken, waarna dagboekpassages tevoorschijn komen die op die datum geannoteerd zijn. De gebruiker kan 81 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten vervolgens navigeren naar de bijbehorende pagina. De applicatiecomponenten voor de kalenderpagina zijn geïmplementeerd in het framework. 13. Dagboeken worden weergegeven als meerdere pagina’s waar de gebruiker doorheen kan navigeren. De getranscribeerde pagina’s met verrijkingen en annotaties worden aan een kant weergegeven en aan de andere kant wordt de scan van het bijbehorende dagboekgedeelte afgebeeld. Netwerklaag 14. Termen worden gereconcilieerd met de Adamlink-terminologiebron in OpenRefine via de Termennetwerk-reconciliatieservice, en als annotaties met Python-scripts (zie stap 5). 15. De dataverwerking in de stappen 3 en 5 wordt gereconcilieerd met Wikidata. Wanneer een persoon niet in Wikidata te vinden was, is er in enkele gevallen gelinkt naar de persoonsobservatie-URL in het Stadsarchief Amsterdam (bijvoorbeeld van een persoonskaart). Zo werd het toch mogelijk om onbekende personen (die ook niet direct voldoen aan het notabiliteitscriterium van Wikidata) een URI te geven, waarmee in ieder geval binnen de applicatie de verschillende vermeldingen van dezelfde persoon in de dagboekfragmenten aan één persoon in het personenoverzicht gekoppeld konden worden. 16. De data voor de applicatie is beschikbaar gemaakt in een datadump op Zenodo (https://doi.org/10.5281/zenodo.14385058). De code voor Amsterdam Diaries is beschikbaar gesteld onder MIT-licentie: https://github.com/amsterdamtimemachine/amsterdam-diaries. 82 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Architectuurschets De architectuurschets geeft de hierboven beschreven functionaliteit weer in een genormaliseerde vorm. 83 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bespreking belangrijkste patronen Transformatie naar RDF In het Amsterdam Diaries-dienstplatform worden metadata en transcriptiedata omgezet naar RDF in de vorm van JSON-LD. Dit proces start met Transkribus, waaruit – na het transcriptieproces – de transcripties geëxporteerd worden als XML en met een datavoorbereidscript worden omgezet naar CSV. Vervolgens wordt deze CSV met OpenRefine omgezet naar een geharmoniseerd CSV-formaat. Zowel tijdens het transcriptieproces als bij de transformatie in OpenRefine worden er verrijkingen op basis van Wikidata en Adamlink verwerkt. De daadwerkelijke RDF-transformatie vindt plaats met een Python-script dat de CSV-bestanden verwerkt en omzet naar RDF in JSON-LD. De JSON-LD-output wordt uiteindelijk opgeslagen in de GitHub-repository van Amsterdam Diaries. Vanwege de relatief beperkte omvang van de data is geen gebruik gemaakt van een triplestore of andere database voor het opslaan van de RDF-data. Interface tussen de datalaag en presentatielaag Om de presentatielaag te voeden wordt gebruikgemaakt van een importscript, gebouwd in TypeScript, dat de metadata mapt naar een relationele structuur om deze vervolgens op te slaan in een relationele database. Deze database wordt verder gebruikt om data, via SQL-queries, te ontsluiten voor de website van Amsterdam Diaries. Om te kunnen werken met afbeeldingen is in de presentatielaag een IIIF-server ingericht die een IIIF Image API ontsluit. De gebruikte afbeeldingen zijn de scans van de originele dagboeken. Gebruik van de netwerkinfrastructuur Amsterdam Diaries gebruikt het Termennetwerk voor het reconciliëren van termen tijdens het transformatieproces. De reconciliatie API van het Termennetwerk wordt vanuit OpenRefine aangeroepen, waarbij termen worden gematcht met de Adamlink-terminologiebron, om vervolgens te worden opgenomen in de getransformeerde metadata. De informatie in dit deel is tot stand gekomen in afstemming met Leon van Wissen. De beschrijving is opgesteld in de periode 2024/2025. 84 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.9 Podiumkunst.net Beschrijving van het platform Podiumkunst.net heeft als doel het verbinden en ontsluiten van collectiegegevens van verschillende typen podiumkunstinstellingen, van theatergroepen tot muziekarchieven. Een uitwerking van het bronlandschap is te vinden in de Podiumkunst.net-wiki. Met financiering vanuit de culturele basisinfrastructuur (BIS) helpt Podiumkunst.net partijen om bewust te archiveren. Ook ondersteunt Podiumkunst.net podiumkunstinstellingen om metadata om te zetten naar linked data. Dit is een ondersteunende activiteit waarbij de verantwoordelijkheid voor het beheer en de beschikbaarstelling van de collecties en de bijbehorende metadata bij de deelnemende podiumkunstinstellingen zelf blijft. Deze activiteit staat los van het beheren van de functionaliteit van het dienstplatform Podiumkunst.net. Overzicht van het applicatielandschap De belangrijkste technische componenten voor Podiumkunst.net zijn een triple store, cachinglaag en REST API, waarvoor op dit moment gebruikgemaakt wordt van TriplyDB, en een transformatie-engine, waarvoor TriplyETL wordt ingezet. De bovenstaande figuur geeft een overzicht van het applicatielandschap. 85 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bronnen 1. Instellingen die geen metadata in gestructureerde vorm kunnen aanleveren, krijgen een op het RDA-applicatieprofiel gebaseerde spreadsheet. In deze spreadsheet kan door de instelling de metadata worden ingevuld. De spreadsheet kan vervolgens worden omgezet naar RDF met een modellering naar RDA. 2. Metadata die als RDF gepubliceerd is maar niet in RDA gemodelleerd, wordt getransformeerd naar het RDA-model volgens het RDA-applicatieprofiel van Podiumkunst.net. Voor de transformaties uit de stappen 1 en 2 worden scripts en pijplijnen gebruikt, bijvoorbeeld de TriplyETL-functionaliteit. 3. Metadata die als RDF gepubliceerd is en in RDA gemodelleerd, kan op twee manieren worden gepubliceerd. Voor instellingen die zelf (nog) geen mogelijkheid hebben om hun linked data te publiceren, biedt Podiumkunst.net (tijdelijk) de mogelijkheid deze publicatie technisch te verzorgen. Daarvoor wordt in de TriplyDB-omgeving van Podiumkunst.net een aparte instantie specifiek voor die instelling aangemaakt. De podiumkunstinstelling kan vervolgens haar metadata daarin op (laten) nemen. Ten tweede kunnen organisaties die al een triplestore hebben, de data laten ophalen in stap 8 voor het verversen van de cache. In de ideale situatie hebben instellingen metadata in een eigen triplestore. Omdat veel instellingen nog niet zo ver zijn, is deze gedeelde voorziening ingericht. Datalaag 4. Podiumkunst.net biedt een (tijdelijke) voorziening in de TriplyDB-omgeving om instellingen te helpen die zelf (nog) geen triplestore hebben. 5. Instellingen met een eigen triplestore kunnen ook hun dataset aansluiten op de triplestore/cachinglaag van Podiumkunst.net. 6. Podiumkunst.net maakt en publiceert zelf ook terminologiebronnen. Deze terminologiebronnen zijn opgenomen in het Termennetwerk. 7. Podiumkunst.net kan helpen bij het leveren van datasets aan het Datasetregister. Idealiter registreren instellingen hun datasets zelf. De Muziekschatten-dataset wordt bijvoorbeeld door de Stichting Omroep Muziek (een consortiumpartner) geleverd. Dienstenlaag Het Podiumkunst.net-platform biedt een eenduidige ingang op de collectie(meta)data van aangesloten podiumkunstinstellingen, waarop andere dienstaanbieders eenvoudig eigen diensten kunnen ontwikkelen. Daartoe biedt het Podiumkunst.net dienstplatform een REST API die de linked data van aangesloten instellingen ontsluit als JSON-LD. De dienstenlaag bestaat uit de volgende onderdelen: 8. Een Triply-voorziening haalt via de SPARQL-endpoints (dit kunnen ook endpoints zijn van instellingen die een eigen triplestore hebben) periodiek de metadata op en mapt deze naar een dataset waarbij een cachinglaag is ontworpen. Deze cache is eigendom van en wordt beheerd door Podiumkunst.net. Bovenop deze cachinglaag worden query-API’s geconfigureerd. 86 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Gebruik 9. Widget: De widget consumeert data uit de API (8) (de presentatielaag). Instellingen kunnen deze zoekfunctie als widget gebruiken op hun eigen websites. De widget is als open source software ontwikkeld en staat op GitHub. Architectuurschets De architectuurschets geeft de hierboven beschreven functionaliteit weer in een genormaliseerde vorm. Bespreking belangrijkste patronen Transformatie naar RDF Een belangrijk aspect van de architectuur van Podiumkunst.net is de plek waar metadata wordt omgezet naar RDF. Binnen het netwerk van deelnemende podiumkunstinstellingen is een duidelijke afspraak gemaakt over de verantwoordelijkheden. De transformatie van metadata naar RDF is belegd bij de individuele bronhouders. Om dit proces te ondersteunen, is indien nodig expertise beschikbaar gesteld aan deze partners. 87 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.11 Collectieplatform Nieuwe Instituut Beschrijving van het platform Het Collectieplatform van Nieuwe Instituut biedt een nieuwe manier om de Rijkscollectie voor Nederlandse Architectuur en Stedenbouw te ontdekken. Het is mogelijk om in de collectie gericht te zoeken, maar gebruikers kunnen ook dwalen door archieven, objecten en verhalen om onverwachte verbanden te ontdekken. De collectie omvat diverse materialen zoals tekeningen, foto’s, maquettes en gedigitaliseerd materiaal, aangevuld met verhalen die een extra contextuele laag bieden. Naast de Rijkscollecties worden de getoonde gegevens verrijkt met drie externe bronnen: Wikidata, Getty (AAT) en het Nederlands Instituut voor Kunstgeschiedenis (RKD). Deze bronnen bevatten voornamelijk gegevens die relevant zijn voor de categorie Personen. Door het gebruik van linked open data kunnen verbindingen worden gelegd tussen objecten binnen de Rijkscollectie en met andere collecties wereldwijd. Het ontwerp is gebaseerd op onderzoek naar gebruikersgedrag en richt zich op storytelling en verrassende ontdekkingen. De cloud-interface biedt zoomniveaus waarmee gebruikers steeds dieper de collectie kunnen verkennen. Het gehele platform bestaat uit drie hoofdonderdelen: Strapi Backend, Nestjs Gateway en Next.JS Frontend. Nieuwe Instituut heeft als principe om alleen collecties op het platform weer te geven die afkomstig zijn van bronnen die voldoen aan linked open data-standaarden. 94 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Applicatielandschap De belangrijkste functionele componenten van het Collectieplatform zijn TriplyDB, Strapi (een op Node.js gebaseerd CMS) en het React-framework. De onderstaande figuur geeft een overzicht van het applicatielandschap. Bronnen Nieuwe Instituut neemt in principe alleen bronnen op die voldoen aan linked open data-standaarden. Ook worden externe bronnen opgehaald via federated SPARQL-queries. Alle federated SPARQL-queries worden uitgevoerd via de Triply REST-JSON API, en de output wordt geserveerd aan de GraphQL API (stap 6). 1. De interne collectie van Nieuwe Instituut wordt beheerd met Axiell Collections, die data via OAI-PMH levert aan TriplyDB. 2. WoodWing (DAMS) levert afbeeldingen van collecties in linked open data-formaat. Er is voor de opslag van masterbestanden een AWS S3-bucket ingericht: de Preservation Archive. 95 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 3. Data wordt verrijkt zoals hierboven beschreven met federated SPARQL-queries die worden uitgevoerd via de Triply REST API met data vanuit Getty AAT, Wikidata, en met data vanuit het RKD - Nederlands Instituut voor Kunstgeschiedenis. Datalaag 4. De TriplyDB-instantie wordt gebruikt als linked data-platform waar alle collecties samenkomen. Met een REST API wordt JSON geleverd aan de TOI API/Gateway in Nestjs. Dienstenlaag Nieuwe Instituut heeft een GitHub-repository waar alle verwerkingen en de framework-logica staan. Het gehele platform bestaat uit drie hoofdonderdelen: Strapi CMS, Nestjs Gateway en Next.JS Frontend. 5. De websitecontent wordt via het Strapi CMS beheerd en beschikbaar gesteld via een GraphQL API (zie stap 8). 6. Met de Active Directory Federation Services (ADFS)-server wordt gebruikersautorisatie beheerd via de SAML 2.0-standaard. 7. TOI API/Gateway Nestjs dient als een centrale toegangspoort voor meerdere API’s. Deze ondersteunt de verbinding tussen TriplyDB en het Strapi CMS. 8. De Strapi CMS-content wordt via een GraphQL API ontsloten. 9. De database PostgreSQL (DigitalOcean) dient als cloud storage-oplossing voor de gestructureerde data. 10. Strapi gebruikt Amazon S3 (cloud storage) voor schaalbare opslag van alle content die geüpload wordt. 11. Een tweede GraphQL API haalt data op vanuit het CMS via de eerst beschikbaar gestelde GraphQL API. Deze API haalt ook data op via de Search API en de REST/JSON API van Triply, waarbij federated SPARQL-queries worden uitgevoerd om data te verrijken. 12. Het REACT-Next.JS Framework bevat alle applicatielogica voor de front-end, haalt data op vanuit de GraphQL API (stap 11) en mapt data naar de front-end componenten. 13. The Other Interface-website wordt geserveerd met een Nginx-proxyserver. 14. Browsen door collecties: Het platform bevat een ‘cloud interface’ waar gebruikers door verschillende zoom-levels dieper kunnen navigeren door de nodes en edges in de collectie. Gebruikers starten met het selecteren van een start node: Archieven, Objecten, Personen, Verhalen of Publicaties, en gaan dan naar een diepere laag: de bijbehorende properties en relaties. 15. De zoekmachine maakt het mogelijk om naar een specifiek concept te zoeken en geeft overeenkomende zoekresultaten. Ook hiervoor is een filteroptie om de zoekresultaten te specificeren. De zoekmachine gebruikt Triply’s Elasticsearch-oplossing. 16. Provenance: Databronnen, bijvoorbeeld de RKD URI behorend tot een persoon, worden waar mogelijk weergegeven in de entiteitspagina. Netwerklaag 17. Data wordt geleverd aan het Datasetregister via het TriplyDB SPARQL-endpoint. 18. Het Termennetwerk wordt ingezet bij de bron, waarbij er handmatig invoer plaatsvindt bij de collectiebeheersystemen. 96 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Architectuurschets De architectuurschets geeft de hierboven beschreven functionaliteit weer in een genormaliseerde vorm. 97 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bespreking belangrijkste patronen Transformatie naar RDF Nieuwe Instituut gebruikt het OAI-PMH-endpoint van hun collectiebeheersysteem om metadata op te halen voor het proces van normaliseren en transformeren van de metadata naar RDF. De transformatie vindt plaats bij de bron en wordt opgenomen in een triplestore om de knowledge graph te realiseren. Gecachete knowledge graph De knowledge graph met collectiedata kan gezien worden als een cache die periodiek wordt ververst, waarin de collectiedata al in RDF beschikbaar is. Zoekindex Het dataplatform biedt een zoekindex die wordt opgebouwd op basis van de knowledge graph. Hiermee is dezelfde informatie die via SPARQL te bevragen is, ook te ontsluiten via een zoek-API. Ontsluiting vanuit het dataplatform De JSON API maakt zelf gebruik van het SPARQL-endpoint van de knowledge graph en voert ook federatieve SPARQL-query’s uit naar externe bronnen. Opvallend hierbij is dat de integratie van externe bronnen voornamelijk op het niveau van de interface plaatsvindt en niet direct in de datalaag. Dit betekent dat gegevens uit externe bronnen pas bij bevraging via de GraphQL API worden opgehaald en niet vooraf worden opgeslagen of verwerkt in de eigen datalaag. Daarnaast wordt de zoekindex via een zoek-API ontsloten. Interface tussen de datalaag en de presentatielaag De datalaag van de dienst biedt een GraphQL API aan ten behoeve van de presentatielaag. Deze GraphQL API orkestreert API-calls naar de JSON API van het dataplatform. Daarnaast maakt de GraphQL API gebruik van de zoek-API van het dataplatform van Nieuwe Instituut en van data die door beheerders in het CMS van het dienstplatform is opgenomen. Het GraphQL-endpoint voorziet de website vervolgens van data. Gebruik van de netwerkinfrastructuur Nieuwe Instituut publiceert de datasetbeschrijving van zijn collectiedataset in het Datasetregister, waardoor de metadata beter vindbaar is en hergebruikt kan worden door andere partijen. De datasetbeschrijving wordt daarbij bijgehouden om wijzigingen door te voeren en de metadata up-to-date te houden. Op dit moment wordt het Termennetwerk alleen handmatig gebruikt bij het beheer van de collectie. Er wordt echter gewerkt aan de implementatie van een koppeling met het Termennetwerk binnen het collectiebeheersysteem, zodat in de toekomst reconciliatie automatisch kan plaatsvinden tijdens het collectiebeheer. De informatie in dit deel is tot stand gekomen in afstemming met de volgende personen: Gijs Broos en Loïs Hutubessy. De beschrijving is opgesteld in de periode 2024/2025. 98 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 1.12 Rijksmuseum Beschrijving van het platform Het Rijksmuseum verbindt mensen met kunst en geschiedenis door zijn collectie beschikbaar te stellen aan het publiek via enerzijds Collectie Online, de collectie-interface van de website http://www.rijksmuseum.nl, en anderzijds de dataservices via data.rijksmuseum.nl. De dataservices vormen belangrijke bouwstenen voor de website, maar worden ook apart aangeboden als onderdeel van het in 2024 vernieuwde informatieen databeleid van het museum. In 2013 lanceerde het Rijksmuseum het eerste volwaardige online collectieplatform, bekend onder de naam Rijksstudio. De designprincipes van deze vroege museale discovery interface werden enkele jaren nadien door Mitchell Whitelaw betiteld als een vroege vorm van een 'generous interface'. De beelden van de collectie werden bijna allemaal in CC0 aangeboden en konden individueel worden gedownload, of worden geharvest via een open API. De ontwikkeling en het beheer van de presentatieén de datalaag gebeurden toen door twee externe bureaus, Q42 en Fabrique. In 2016 werd het beheer van alle informatie en data over de collectie en de organisatie in het Rijksmuseum gecentraliseerd binnen een nieuwe afdeling, Research Services. Daarbinnen werd een nieuwe entiteit gecreëerd die verantwoordelijk was voor Collectie IT. Deze subafdeling is sindsdien verantwoordelijk voor alle collectiesystemen, van de collectie, het archief, de bibliotheek, het DAM-systeem en de onderzoeksdata. De ambitie was vanaf toen om het beheer van de datalaag en de daarbij horende API's en end points terug te halen naar het Rijksmuseum. De afgelopen jaren heeft het Rijksmuseum als doel gehad om een robuuste infrastructuur te bouwen, data op te schonen, verantwoordelijkheden beter te beleggen en processen te verbeteren. Het museum stond voor de uitdaging om intern een integratielaag en collectiedata-infrastructuur te ontwikkelen waarmee data en systemen effectief konden worden verbonden en ontsloten. Vanaf 2022 is er, met een aanzienlijke investering, een nieuwe collectiedata-infrastructuur (integratielaag) én een nieuwe collectiewebsite gelanceerd. De integratielaag draait op linked open data en valt onder de verantwoordelijkheid van de afdeling Research Services, en daarbinnen Collectie IT. Er moest flink geïnvesteerd worden om de architectuur goed in te richten, vooral gezien het toenmalige gefragmenteerde IT-landschap binnen het Rijksmuseum. Dit hele traject kwam mede voort uit een vernieuwde Digitale Strategie (2022-2025) waarbij de verantwoordelijkheden voor IT binnen het Rijksmuseum zijn verdeeld over de afdeling Communicatie & Marketing die verantwoordelijk is voor Publieke IT, de afdeling Research Services die verantwoordelijk is voor Collectie IT en de afdeling ICT die verantwoordelijk is voor Core IT-processen. Het Rijksmuseum heeft met het herbouwen van de architectuur een integratielaag ontwikkeld die robuust en schaalbaar is. Daarnaast is het databewustzijn binnen het Rijksmuseum vergroot, wat datamanagement, digitale specialisten, informatiespecialisten, websitebouwers, ontwerpers en conservatoren raakt. 99 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Het ontwikkelen van de integratielaag speelt een cruciale rol bij het verbinden van data uit verschillende domeinen. Door deze laag wordt informatie, die voorheen in afzonderlijke datasilo's zat, toegankelijk gemaakt en worden de silo’s doorbroken. Hierdoor kan data uit diverse domeinen worden ontsloten en worden er verbindingen gelegd tussen de verschillende informatiegebieden. Momenteel is de collectiedata uit het collectiemanagementsysteem, de bibliografische metadata uit het bibliotheeksysteem en de beelden uit het DAM-systeem met elkaar verbonden. In de toekomst staan de koppeling met het archiefen documentatiesysteem en de research data repository nog gepland. Voor het bouwen van de integratielaag is zoveel mogelijk ingezet op standaardisatie. Zo worden diverse standaarddatamodellen en protocollen zoals Linked Art en IIIF gebruikt. De infrastructuur is gebaseerd op een microservices-architectuur waarbij relatief kleine services zijn ontworpen om een specifieke functie uit te voeren en worden georkestreerd om businessfuncties uit te voeren. De software wordt gesplitst in kleine onderdelen, gebundeld als Docker-containers (een lichtgewicht, geïsoleerd pakket waarin een applicatie draait met alles wat die nodig heeft, zoals code, libraries en instellingen, zodat het overal hetzelfde werkt) zodat het eenvoudig valt uit te rollen op servers. In het geval van het Rijksmuseum draaien de containers op een Kubernetes-cluster, als onderdeel van de Azure Kubernetes Service. Met een ‘infrastructuur als code’-benadering wordt softwarematig bepaald hoe de services zich moeten gedragen. Met continuous deployment worden updates naar nieuwe versies naar de productieomgeving automatisch uitgevoerd. Applicatielandschap De onderstaande figuren geven een overzicht van het applicatielandschap. De eerste figuur toont de invoerlaag van de integratielaag waarin data uit verschillende bronnensystemen wordt opgehaald om verwerkt te worden. De tweede figuur beeldt de domeinlaag en de uitvoerlaag van de integratielaag af, waarop de presentatielaag is aangesloten en de overige dataservices die worden aangeboden. De derde figuur toont de presentatielaag waarop de collectiewebsite is gebaseerd. Voor elke figuur worden de belangrijkste stappen toegelicht. 100 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Figuur 1: invoerlaag integratielaag Invoerlaag De bronnen komen uit het bibliotheeksysteem, collectiemanagementsysteem en documentmanagementsysteem (afbeelding 3). 1. Het Rijksmuseum gebruikt op dit moment Axiell Collections voor het beheren van haar kunstcollectie. 2. De Python-service Axiell-Collections-downloader haalt, bij trigger door een data-event, data op vanuit Axiell Collections via een API die XML levert. 3. De Python-service Axiell-Collections-monitor detecteert wijzigingen in Axiell Collections en triggert het downloader-service (stap 2). De trigger voor de downloader is een bericht op zijn queue, die door de Axiell-Collections-monitor wordt gevuld. Zo kunnen er ook meerdere Axiell-Collections-downloaders worden gestart die werk oppakken. Er is nooit directe communicatie tussen componenten om vervlechting te voorkomen, de communicatie is loosely coupled via een Message Oriented Middleware (RabbitMQ) en gebruikt het Publish-Subscribe patroon voor Loosely Coupled interactie tussen componenten. 4. De Python-service Axiell-Collections-deletion-detector monitort of er nieuwe records zijn bijgekomen of verwijderd, en consumeert nieuwe identificaties die gepubliceerd worden door de Python-service ID Publisher. 5. Voor de bibliotheekdata wordt Koha gebruikt als open source integrated bibliotheeksysteem. Hierbij wordt de MARC21-standaard gebruikt als metadataformaat. 101 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten 6. De Python-service Koha-connector haalt bibliografische records vanuit Koha en plaatst deze op de queue van de ‘Source data gateway’ (stap 9) om verder verwerkt te worden. 7. Picturepark is een platform voor digitaal collectiemanagement dat gebruikt kan worden om diverse soorten informatie te structureren en te centraliseren. De component Picturepark Image metadata levert data in JSON-formaat, die getransformeerd wordt met XSLT naar XML. Er wordt een verbinding gemaakt met Micr.io, een IIIF viewer (Image binaries IIIF, image API). 8. De Python-service Picturepark-connector haalt afbeeldingsdata op uit het Picturepark-beheersysteem. 9. De Source data gateway is de middleware die het doorstromen van data uit verschillende bronnen naar de Domain Graph Inserter faciliteert. Figuur 2: de domeinen uitvoerlaag van de integratielaag Domeinen uitvoerlaag De integratielaag van het Rijksmuseum bestaat uit meerdere lagen, elk met componenten die worden gehost op Microsoft Azure cloud platform. Op de Rijksmuseum Data Services-website staat de 102 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten documentatie van alle metadata die beschikbaar is gesteld door het Rijksmuseum, door middel van API's (stap 22 en 23), endpoint (stap 25) of datadumps. Op de datadump-pagina kunnen de datasets gedownload worden. 10. De Python-service Domain-graph-inserter persisteert aangeleverde domeindata in de triplestore Domain-store en publiceert een domain-data-event voor verdere consumptie. Dit is een lichtgewicht event om bepaalde uitvoer-pipelines, zoals bijvoorbeeld het genereren van Schema.org of Linked Art, te triggeren. Een pipeline is een verzameling van componenten die logisch bij elkaar horen, bijvoorbeeld alle Axiell-Collections-componenten of alle uitvoer Linked-Art-componenten. 11. De Python-service Matcher is bedoeld om entiteiten uit verschillende domeinen (dus bijvoorbeeld een kunstenaar in het erfgoeddomein en een schrijver uit het bibliografische domein) te reconciliëren. Dit gebeurt op basis van overeenkomende (externe) identifiers. De matcher kan bijvoorbeeld bepalen dat twee entiteiten/resources dezelfde persoon zijn, en dit leidt tot het toekennen van een museum-level identifier en het samenvoegen van metadata in één extra resource. 12. De Python-service Minter verwerkt de nieuwe data en creëert nieuwe identifiers voor de gereconcilieerde resources die weer worden opgenomen in de Triplestore Domain-store (14). 13. De SQL-database Mint slaat alle identifiers, en de (mapping van de) identifiers van de domain-resources waarvoor een museum-level resource is gecreëerd, op. 14. De Triplestore Domain-store (GraphDB). 15. De Python-service ID-inserter slaat de relevante identificaties van de aangeleverde domeindata op in de SQL Database IDs. 16. SQL Database IDs bevat alle identificaties van domeinobjecten van het Rijksmuseum. 17. De Python-service ID-publisher publiceert de identifiers die tot nu toe door de integratielaag verwerkt zijn zodat de deletion-detectors in de bronsystemen kunnen nagaan of records nog bestaan. 18. De Python-service Partitioner vertaalt de relevante subset van metadata naar representatie in het toepasselijke model door middel van SPARQL en past JSON-LD-framing toe. Resolver service De resolver draagt zorg voor dereferencing van URI's naar data/resources/informatieobjecten en content negotiation. 19. Python-service resolver-inserter verwerkt de Schema.orgen Linked-Art-wijzigingen in de SQL-resolver-database. Hierin worden alle door de integratielaag gegenereerde serialisaties opgeslagen. 20. SQL-resolver-database voedt de resolver-dataservice met data. 21. De Resolver API (resolver-dataserver) draait op de data van de resolver-database. 22. IIIF change-discovery (resolver-dataserver) levert domeindata-wijzigingsberichten conform de IIIF-standaard. De dataservices stellen onder andere de IIIF change discovery API, IIIF Image API en IIIF presentation API beschikbaar. 23. LDES (resolver-dataserver) levert domeindata-wijzigingsberichten conform het LDES-protocol. Vanuit de dataservices wordt een LDES API beschikbaar gesteld. 103 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Tijdlijnof kaartweergave Een gebruiker wil een tijdlijn of kaart kunnen bekijken, zodat hij beter begrijpt hoe het object of de informatie zich verhoudt tot gebeurtenissen of locaties. Algemene vereisten: ● Een kaart of tijdlijn toont relevante informatie ● Delen van de kaart of tijdlijn zijn aanklikbaar ● De kaart of tijdlijn toont details of context ● Het is mogelijk om de kaart of tijdlijn te delen via bijvoorbeeld social media ● Het is mogelijk om de kaart of tijdlijn in volledige schermweergave te bekijken Vereisten voor de (meta)data: ● Voor een kaart zijn plaatsnamen, locaties of coördinaten nodig ● Voor een tijdlijn zijn data nodig ● De informatie voor een kaart of tijdlijn volgt zoveel mogelijk de standaarden, bijvoorbeeld een standaard datum/tijd formaat of geo-coördinaten ● Er is data voor contextinformatie, zoals een afbeelding Vereisten voor het ontwerp: ● De kaart of tijdlijn is interactief, bijvoorbeeld met een inen uitzoommogelijkheid ● Er is een legenda of uitleg over het gebruik van de kaart of tijdlijn Verhaalweergave Een gebruiker wil een verhaal kunnen lezen of beluisteren, zodat hij meer leert over de geschiedenis en betekenis van een object. Dit kan in verschillende vormen: een tekst met afbeeldingen, een gesproken verhaal of een video-opname. Algemene vereisten: ● Het verhaal kan gepresenteerd worden in verschillende vormen, zoals tekst, audio en video ● Er is navigatie om het verhaal gemakkelijk te lezen ● Het is mogelijk om te reageren Vereisten voor de (meta)data: ● Metadata bij het verhaal, bijvoorbeeld de auteur, titel, publicatiedatum, genre, taal of herkomst ● Trefwoorden of tags ● Afbeeldingen of andere media ● Extra metadata, zoals de leeftijdsaanduiding, dialect, duur en gerelateerde locatie Vereisten voor het ontwerp: ● Een verhaal is visueel aantrekkelijk ● Het verhaal kan gepresenteerd worden in verschillende vormen, zoals tekst, audio en video 110 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Zoeken Een gebruiker wil kunnen zoeken naar een specifiek onderwerp, zodat hij snel relevante resultaten kan vinden. Algemene vereisten: ● Het zoeken start na invoer van het zoekwoord of ‘enter’ ● Het zoeken geeft direct resultaat of een indicatie van laadtijd ● Het zoekwoord is aan te passen om opnieuw te zoeken ● Verschillende zoekstrategieën, bijvoorbeeld door gebruik van speciale woorden en tekens om de zoekopdracht slimmer te maken ● Suggesties op basis van het zoekwoord ● Het zoeken werkt ook met synoniemen of spelfouten (‘fouttolerantie’) Vereisten voor de (meta)data: ● Metadata voor ‘wie’, ‘wat’, ‘waar’ en ‘wanneer’ ● Extra metadata, zoals kleur, materiaal en andere kenmerken Vereisten voor het ontwerp: ● Het zoekformulier is op elke pagina gemakkelijk te vinden ● Het zoekformulier heeft een label of een voorbeeldtekst (‘placeholder’) Zoekresultaten Een gebruiker wil resultaten kunnen zien na het invoeren van een trefwoord in een zoekformulier, zodat hij antwoord krijgt op de zoekvraag. Algemene vereisten: ● Resultaten bevatten het oorspronkelijke zoekwoord ● Een melding wanneer er geen resultaten zijn ● Elk resultaat bevat een titel, korte omschrijving en link naar volledige resultaat ● Informatie over totaal aantal resultaten ● Meer resultaten zien door paginering, oneindig scrollen of ‘meer laden’-knop Vereisten voor de (meta)data: ● Titel, korte beschrijving en link naar volledige resultaat ● Extra data in resultaat, zoals afbeelding, auteur en datum Vereisten voor het ontwerp: ● De zoekresultaten staan op dezelfde pagina als het zoekformulier ● Het oorspronkelijk zoekwoord is gemarkeerd of uitgelicht in de resultaten ● Het zoekformulier heeft een label of een voorbeeldtekst (‘placeholder’) ● Verschillende manieren om de resultaten te bekijken, bijvoorbeeld als lijst (nadruk op informatie) of als galerij (nadruk op afbeeldingen) 111 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bijlage 3: Vereisten voor de (meta)data Op basis van de gids voor gedragsprofielen worden de volgende eisen gesteld aan de data en bijbehorende metadata ingedeeld per functionaliteit: Apparaten en schermformaten ● Geoptimaliseerde mediabestanden Zoekmachines ● Een actuele sitemap.xml ● Een robots.txt-bestand ● Relevante metatags ● Duidelijk leesbare url’s, geen onuitspreekbare combinaties van cijfers en tekens ● Een zoekfunctionaliteit ● Mogelijkheden om verder te browsen Afbeeldingweergave (op basis van IIIF) ● Een afbeelding met een hoge resolutie ● Metadata bij de afbeelding, zoals titel en formaat ● Metadata over de maker ● (Meta)data over IIIF-beelden (‘IIIF manifest’) Bewaren ● Een licentie of rechten ● Metadata bij een object, zoals de titel, afbeelding en korte beschrijving Bronverwijzing ● Een link naar de bron is aanwezig in de metadata ● Een permanente link of identifier Citeren ● Metadata voor het citeren, zoals de vervaardiger, titel, datum en identifier Datasetbeschrijving inzien ● Metadata, zoals de bronhouder, titel, publicatie en actualisatiedatum ● Een versienummer ● Voorbeelden die de inhoud van de dataset illustreren ● Andere eisen staan in de dataset requirements van het Netwerk Digitaal Erfgoed Dataset downloaden ● Metadata, zoals de bronhouder, titel en publicatiedatum ● Bestandsformaat en datasetgrootte ● Een versienummer 112 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Datatset gebruiken ● Metadata bij dataset, zoals de beschrijving, maker en publicatiedatum ● De inhoud en beschrijving zijn actueel ● De dataset is gepubliceerd als linked data Delen ● Een licentie of rechten ● Metadata voor sociale media, zoals de titel, afbeelding en korte beschrijving Filteren ● Metadata voor filters, bijvoorbeeld de periode, maker, locatie en materiaalsoort ● Metadata voor filters, afgestemd op gebruikersgedrag en -voorkeuren Gerelateerde objecten bekijken ● Metadata om de aanbevelingen te doen is aanwezig, bijvoorbeeld de maker, onderwerp, periode en plaats ● Metadata is uniform en volledig Herkomst controleren ● De herkomst en bronhouder ● Metadata die de herkomst ondersteunt, bijvoorbeeld de maker, vindplaats en vervaardigingsdatum Leeftijdsindicatie ● Het taalgebruik past bij de leeftijdscategorie Licentie inzien ● Licentie of rechten Multimediaweergave ● Metadata bij multimedia, zoals de titel, duur en formaat ● Metadata over de vervaardiger ● Er is een uitleg over de werking van de digitale ervaring Objectdetails ● Metadata is uniform en volledig ● Er zijn relaties met andere informatie of bronnen Overzicht van creaties ● Metadata, zoals de maker, publicatiedatum, beschrijving, genre en trefwoord ● Er is een verwijzing naar gebruikte bronnen Personaliseren ● Er wordt zorgvuldig omgegaan met de (persoons)gegevens van de vragensteller ● Er is een privacyverklaring 113 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Reageren ● Er is een privacyverklaring Sorteren ● Metadata voor beschikbare sorteermogelijkheden, bijvoorbeeld een datum wanneer sorteren op datum mogelijk is ● Metadata is uniform en correct, bijvoorbeeld altijd dezelfde notatie voor de datum Taggen ● Vrij in te voeren begrippen of termen uit een gecontroleerde terminologiebron Tijdlijnof kaartweergave ● Voor een kaart zijn plaatsnamen, locaties of coördinaten nodig ● Voor een tijdlijn zijn datums nodig ● De informatie voor een kaart of tijdlijn volgt zoveel mogelijk de standaarden, bijvoorbeeld een standaard datum/tijd formaat of geo-coördinaten ● Er is data voor contextinformatie, zoals een afbeelding Transcriberen ● Metadata van de bron, bijvoorbeeld de maker, datum en herkomst ● Tags of trefwoorden ● Het is duidelijk wat de status en kwaliteit van de transcripties is ● Het is duidelijk in welke taal de transcriptie is Uploaden ● Opslaan metadata, zoals de auteur, titel en datum ● Er zijn richtlijnen om ongepaste creaties te voorkomen ● Het is duidelijk wat er met creaties wordt gedaan Verhaalweergave ● Metadata bij het verhaal, bijvoorbeeld de auteur, titel, publicatiedatum, genre, taal of herkomst ● Trefwoorden of tags ● Afbeeldingen of andere media ● Extra metadata, zoals de leeftijdsaanduiding, dialect, duur en gerelateerde locatie Zoeken ● Metadata voor ‘wie’, ‘wat’, ‘waar’ en ‘wanneer’ ● Extra metadata, zoals kleur, materiaal en andere kenmerken Zoekresultaten ● Titel, korte beschrijving en link naar volledige resultaat ● Extra data in resultaat, zoals afbeelding, auteur en datum 114 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten Bijlage 4: Begrippenlijst A ● Apache Solr/Lucene (Solr): Een open source systeem voor het indexeren van tekstuele en andere informatie voor zoekdoeleinden. ● Application programming interface (API): Een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel. ● Archival Resource Key (ARK): Een ARK is een type persistent identifier. Een ARK kent een specifieke opbouw en wordt meestal gebruikt als onderdeel van een URL om een bepaalde resource te kunnen identificeren en op te halen op het web. B ● Bash: Werkomgeving voor Linux-systemen waarin scripts voor het automatisch uitvoeren van taken kunnen worden geschreven. ● BIBFRAME: BIBFRAME (Bibliographic Framework) is een datamodel, gebaseerd op linked data, voor bibliografische beschrijving van objecten. C ● CIDOC-CRM: CIDOC Conceptual Reference Model (CRM) is een ontologie voor het erfgoedveld. ● Content negotiation: Een mechanisme in HTTP waarmee een server verschillende weergaven van een bron kan weergeven op basis van de voorkeuren van een vragende partij, zoals taal of bestandsformaat. Dit proces zorgt ervoor dat de vragende partij de meest geschikte versie van de bron ontvangt. ● Contentmanagementsysteem (CMS): Een systeem waarmee je content en pagina's kunt beheren voor publicatie op het web. D ● Django: Een open source framework voor het ontwikkelen van moderne, veilige en schaalbare webapplicaties. ● Drupal: Een open source content management systeem (CMS). ● Dublin Core: De Dublin Core (DC) is een standaard voor het beschrijven van content op het internet. Dit omvat zowel geschreven teksten op webpagina's als content in XML-formaat. Ook video's en geluidsfragmenten kunnen met de Dublin Core beschreven worden. 115 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten E ● Elasticsearch: Elasticsearch levert een breed gebruikte oplossing voor search – het doorzoekbaar maken van documenten. ● ELT: Extract Load Transform (ELT) is een proces om data uit een bron op te halen (Extract), deze weg te schrijven op een andere plaats (Load) en op dezelfde plaats te transformeren naar een gewenste structuur (Transform), vaak in combinatie met andere data die vanuit verschillende plekken geladen is. ● ETL: Extract Transform Load (ETL) is een proces om data uit een bron op te halen (Extract), deze te transformeren naar een gewenste structuur (Transform) en weer weg te schrijven op een andere plaats (Load). ● Europeana Data Model (EDM): EDM is een ontologie voor het beschrijven van erfgoedinformatie in het kader van Europeana. G ● GeoJSON: formaat voor het vastleggen van geografische kenmerken samen met andere (niet ruimtelijke) data door middel van JavaScript Object Notatie (JSON). ● GraphDB: GraphDB van Ontotext is een van de bekende triplestore-oplossingen gebruikt voor het opslaan, bevragen of bewerken van RDF. ● GraphQL: (Graph Query Language): taal voor het bevragen van databronnen, de datastructuur van het resultaat is vooraf vastgelegd en het wordt weergegeven in JSON-formaat wat de taal populair maakt onder frontend/web ontwikkelaars. I ● IIIF Change Discovery API: Een API om IIIF data-objecten te vinden en om te zien welke data-objecten nieuw zijn toegevoegd of aangepast, zodat ze efficiënt kunnen worden bijgewerkt of opgehaald. ● IIIF Image API: De IIIF Image API definieert een webservice die afbeeldingen levert in reactie op een gestandaardiseerd HTTP(S)-verzoek. Hiermee kunnen afbeeldingen opgevraagd, geschaald, bijgesneden en getransformeerd worden voor flexibele weergave in IIIF-compatibele viewers. ● IIIF Presentation API: De IIIF Presentation API biedt een rijke standaardbeschrijving van hoe (een mogelijk complexe combinatie van) afbeeldingdata gepresenteerd moet worden op het web. ● IIIF viewer: Een IIIF viewer is een tool waarmee je hoge resolutie afbeeldingen kunt bekijken, inzoomen en annoteren volgens de International Image Interoperability Framework (IIIF)-standaard. Dit wordt veel gebruikt in musea, bibliotheken en archieven om digitale collecties toegankelijk te maken. ● International Image Interoperability Framework (IIIF): IIIF is een set open standaarden die het makkelijker maakt om gedigitaliseerde schilderijen, kaarten, aktes, middeleeuwse handschriften, foto’s en andere afbeeldingen online toegankelijk te maken, samen met de bijbehorende informatie. 116 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten K ● Knowledge graph: Een knowledge graph is een gestructureerde representatie van kennis, waarbij entiteiten zoals objecten, gebeurtenissen of concepten als knopen (nodes) worden weergegeven, en de relaties tussen deze entiteiten als verbindingen (edges). Dit model stelt zowel mensen als machines in staat om informatie effectief te begrijpen en te gebruiken, doordat het de context en onderlinge verbanden tussen verschillende gegevens weergeeft [ontotext, wikipedia]. L ● Library Reference Model (LRM): LRM is een referentiemodel voor het beschrijven van bibliotheeken cultureel erfgoedcollecties en ondersteunt de mogelijkheid om de informatie in linked data vorm te publiceren. ● Lightweight Information Describing Objects (LIDO): LIDO is een XML-publicatieformaat voor erfgoedinformatie. ● Linked Art Model: Het Linked Art Data Model is een model dat kan worden gebruikt om bronnen van cultureel erfgoed te beschrijven, met een focus op kunstwerken en museumgeoriënteerde activiteiten. Het is gebaseerd op CIDOC-CRM. ● Linked Data Event Streams (LDES): LDES is een linked data protocol om wijzigingen in een linked data dataset als stream te publiceren. N ● NestJS: Een server-side applicatieframework gebaseerd op Node.JS en TypeScript. ● Next.js: Een React-framework dat gebruikmaakt van alle React voordelen zoals flexibiliteit, snelheid en optimalisatie-opties. ● Nginx: Een krachtige, efficiënte en veelgebruikte open source webserver. Het kan worden ingezet als webserver, reverse proxy, load balancer, en meer. Het is populair vanwege zijn hoge prestaties en lage resource verbruik. ● Nuxt: Een gratis en open source frontend framework gebouwd boven op Vue.js. Het biedt ingebouwde functies en tools, waardoor het gemakkelijker wordt om ingewikkelde applicaties te maken. Het is een framework met een uitbreidbare manier om webapplicaties en websites te maken met Vue.js. O ● Omeka S: Een open source, semantisch collectiebeheersysteem, waaraan je verschillende modules kunt toevoegen om het systeem NDE-compatibel te maken. ● Ontologie: Een conceptueel datamodel van een bepaald domein. Linked data-ontologieën worden meestal in OWL uitgedrukt. 117 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten ● Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH): OAI-PMH is een protocol primair bedoeld om metadata te harvesten. Het is gebaseerd op XML en kan ook RDF/XML retourneren. ● OpenRefine: Een krachtige gratis open source tool voor het werken met rommelige data: het opschonen ervan, het omzetten van het ene formaat naar het andere en het uitbreiden ervan met webservices en externe data. ● OpenSeadragon: Een open source, webgebaseerde viewer voor hoge-resolutie inzoom bare afbeeldingen, geïmplementeerd in pure JavaScript, geschikt voor desktop en mobiel. ● OpenStreetMap: Een project dat als doel heeft om vrij beschikbare en bewerkbare geografische gegevens te verzamelen, zodat daaruit landkaarten en andere diensten gemaakt kunnen worden. P ● Persons in Context (PiCo): PiCo is een kennismodel voor het beschrijven van persoonsvermeldingen en (daaruit afgeleid) uniek geïdentificeerde personen. Het kennismodel gebruikt een aantal bestaande ontologieën: Schema.org, BIO, PNV en PROV-O. ● PoolParty Semantic Suite: Een betaalde dienst van Semantic Web Company voor het opbouwen van en onderhouden van taxonomieën, thesauri en ontologieën volgens SKOS en OWL. Nederlandse erfgoedinstellingen kunnen hier kosteloos gebruik van maken via de Rijksdienst voor Cultureel Erfgoed. ● PRO-GEN: Software ontworpen om stamboomonderzoek te ondersteunen. Het stelt gebruikers in staat om genealogische gegevens in te voeren, beheren en publiceren. Er zijn uitgebreide mogelijkheden voor het vastleggen van informatie zoals roepnamen, titels, bronvermeldingen, aktenummers, bronteksten en getuigen. ● Protégé: Een gratis, open source ontologie-editor en framework voor het bouwen van intelligente systemen. ● Proxyserver: Een server die zich bevindt tussen de computer van een gebruiker en de computer waarop de door de gebruiker gewenste informatie staat. Wil iemand op een computer waarop een proxyserver is ingesteld een andere computer bereiken, dan gebeurt dit niet rechtstreeks, maar via deze proxyserver. Het doel van deze tussenstap is afhankelijk van het type proxyserver. ● Python: Een programmeertaal dat ontwikkeld is met het oog op leesbare code. Het is erg eenvoudig om in Python herbruikbare code te schrijven. Python wordt daarom veel gebruikt voor het snel ontwikkelen van een nieuwe applicatie zonder dat de daarbij geproduceerde code onleesbaar wordt. Q ● QGis: Een gratis en open source Geografisch Informatiesysteem (GIS) waarmee gebruikers geografische gegevens kunnen visualiseren, bewerken, analyseren en beheren. 118 Van data naar dienst - Visie op de ontwikkeling van verbonden erfgoeddiensten R ● RDA: (Resource Description and Access) is een standaard voor het beschrijven en ontsluiten van informatiebronnen, zoals boeken, archieven en digitale objecten. Het is ontworpen voor gebruik in bibliotheken en erfgoedinstellingen en gebaseerd op het conceptuele Library Reference Model ● React: React (ook wel React.js of ReactJS genoemd) is een Javascriptbibliotheek om gebruikersinterfaces mee te bouwen. ● Representational state transfer (REST): REST is een software-architectuur voor gedistribueerde mediasystemen zoals het wereldwijde web. REST wordt veelal gebruikt voor het ontwerpen van application programming interfaces (API) voor het internet, op de HTTP-standaard, maar is niet gelimiteerd tot HTTP en ook toepasbaar buiten API’s. Een klikbare, interactieve website zoals Wikipedia voldoet bijvoorbeeld aan de REST-architectuur. ● Reverse proxy: Een server die zich bevindt tussen de computer van een gebruiker en de computer waarop de door de gebruiker gewenste informatie staat. Bij reverse proxy werkt de proxyserver van buiten naar binnen, dus andersom. Dit wordt ook wel ‘web server acceleration’ genoemd. Hierbij wordt de proxyserver ingezet om de belasting vanuit het internet naar de webserver(s) gelijkmatiger te verdelen, zowel om beveiligingsals om ‘loadbalancing’-redenen. ● Records-in-Contexts Ontology (RIC-O): RiC-O is een conceptueel model ontwikkeld door de International Council on Archives (ICA). Het model biedt een relationele manier om archiefgegevens te beschrijven. In plaats van alleen documenten hiërarchisch te ordenen, legt RiC-CM nadruk op relaties tussen documenten, personen, organisaties, functies en gebeurtenissen. S ● Schema.org: Een gezamenlijk initiatief van drie grote zoekmachines: Bing, Google en Yahoo met als doel om een gedeeld schema op te stellen om data te structureren. ● SPARQL-endpoint: Een web-gebaseerde interface of dienst, waarmee gebruikers data kunnen opvragen en ophalen uit RDF-datasets met behulp van de SPARQL-querytaal. ● Spinque Desk: Een betaalde dienst van Spinque waarmee gebruikers data uit verschillende bronnen samen kunnen brengen in een Knowledge Graph en waarmee zoekstrategieën ontwikkeld kunnen worden voor het aanbieden van relevante informatie. T ● Transkribus is een platform, ondersteund door AI, dat het mogelijk maakt om scans van bijvoorbeeld historische documenten die handgeschreven zijn te digitaliseren. ● Triplestore: Een triplestore of RDF-store is een speciaal gebouwde database voor de opslag en het ophalen van triples via semantische query's . Een triple is een data-entiteit die is samengesteld uit subject – predikaat – object , zoals ‘Bob is 35’ (d.w.z. Bobs leeftijd gemeten in jaren is 35) of ‘Bob kent Fred’. 119