Jottem Platform Design

A Collection of Interesting Ideas,

This version:
https://github.com/inside-out-time-machines/design
Editor:
Bob Coret (Gouda Tijdmachine)

© 2026 Inside Out Time Machines. Dit document is beschikbaar onder de licentie CC BY-SA 4.0: hergebruik met naamsvermelding, bewerkingen onder dezelfde licentie.

1. Introductie

Dit document beschrijft de plannen en ideeën van het project Inside Out Time Machines (IOTM). Het is bedoeld om discussie te stimuleren en kan op elk moment veranderen. Het wordt samengesteld op basis van content in de Design repository.

2. Salespitch voor het Jottem platform

Voor organisaties (historische verenigingen, erfgoedhuizen en archieforganisaties) is er een niet-technische salespitch als losse pagina: Jottem voor organisaties - wat het platform oplevert en wat het vraagt (jaarlijkse bijdrage, communicatie en moderatie).

2.1. Hoofdboodschap

Jottem: Maak erfgoed van iedereen, door iedereen

Jottem is het participatieve digitale erfgoedplatform dat gemeenschappen in staat stelt hun eigen lokale geschiedenis te verzamelen, te delen en te verrijken. Van de homepage van je huis tot de verhalen van je buurt – Jottem brengt erfgoed terug waar het thuishoort: midden in de samenleving.

2.2. Het probleem

Mensen voelen zich sterk verbonden met hun leefomgeving en willen graag hun verhalen delen. Maar traditionele erfgoedzorg is:

2.3. De oplossing: het Jottem platform

Jottem draait het perspectief om: niet de collectie staat centraal, maar de gemeenschap.

2.3.1. Kernfunctionaliteiten

Voor burgers (uploaders & annoteerders):

Voor organisaties (historische verenigingen, Time Machines, archieven):

Voor hergebruik (API’s):

2.4. Onderscheidende kenmerken

2.4.1. Participatie in de volle breedte

Van expert tot buurtbewoner – iedereen kan bijdragen op zijn eigen niveau. De visueel aantrekkelijke, laagdrempelige interface maakt meedoen makkelijk en leuk.

2.4.2. Duurzaam en betrouwbaar

2.4.3. Open en herbruikbaar

2.4.4. Bewezen concept

Ontwikkeld vanuit concrete behoefte van vier Time Machines:

2.4.5. Van aanbod naar vraag

Niet: "Wat kunnen wij ontsluiten?" Maar: "Wat willen mensen delen, bewaren en doorgeven?"

2.5. Wat levert het op?

2.5.1. Voor gemeenschappen:

2.5.2. Voor organisaties:

2.5.3. Voor de erfgoedsector:

2.6. Oproep tot actie

Voor organisaties: Wil jouw historische vereniging, archief of Time Machine ook participatiever worden? Sluit je aan bij Jottem en geef je gemeenschap de tools om zelf erfgoed te maken.

Voor gemeenschappen: Heb je verhalen, foto’s of herinneringen over je buurt? Word deel van een groeiende beweging die lokale geschiedenis levend houdt.

2.7. Slogan opties

3. Activiteitenplan

Dit deel komt uit het activiteitenplan (versie 31 augustus 2025, opgesteld door Ingeborg Verheul, Bob Coret, Toine Pieters, Elsbeth Kwant) dat onderdeel was van de aanvraag voor de Subsidieregeling Uitvoeringsagenda Faro. De oorspronkelijke tekst is intact gelaten; waar van toepassing staat onder een deelactiviteit een statusnoot (augustus 2026) met de inmiddels opgeleverde producten en genomen besluiten.

3.1. Hoofdactiviteit en doel

Mensen voelen zich vaak sterk verbonden met de omgeving waarin ze wonen en de geschiedenis daarvan. Ze vinden het interessant om erover te leren, maar ook om hun eigen verhalen te vertellen. De vier Time Machines die actief zijn in hun stad, ervaren deze behoefte regelmatig. Zo vertelde de Amsterdam Time Machine bij een event op de RingA10 (tijdens het jubileumjaar Amsterdam 750) over de ‘homepage van je huis’ en vroegen mensen of ze ook hun eigen foto’s daaraan konden toevoegen. In Hilversum is er een groep vrijwilligers die een grafisch atelier runt, dat allerlei erfgoedmateriaal van ontwerpers en drukkerijen bezit en dat graag zou digitaliseren op een makkelijke manier. In Utrecht zijn de vrijwilligers van OUD Utrecht, Museum Van Zuilen en het Utrechts Geveltekenfonds geïnteresseerd om zo bij te dragen en in Gouda deelt de historische vereniging momenteel vooral informatie via Facebook. Zij zouden graag bereid zijn dat in samenwerking met de Time Machine aan te leveren als het daarmee duurzamer toegankelijk is.

De Time machines willen geschiedenis relevant maken voor de inwoners van hun steden / omgevingen. We willen bestaande tijdmachines participatiever maken door de mogelijkheid te creëren foto’s, verhalen en informatie te delen of bestaande informatie te verrijken. Dit project creëert een publieksvriendelijke en visueel aantrekkelijke interactie-omgeving (we denken aan een annotatieomgeving, zoals die nu in demo door het Netwerk Digitaal Erfgoed wordt gehost). We verkennen in dit project wat de meest laagdrempelige en beheersbare oplossing is, zowel aan de voor- als aan de achterkant. Ook wisselen we (open source) software uit om succesvolle applicaties van de ene Time Machine te kunnen hergebruiken in een andere. We maken het zo mogelijk dat inwoners zich meer verbinden met de geschiedenis van hun stad, wijk, straat en huis.

3.2. Beoogde eindresultaat

​​We maken het mogelijk dat mensen zelf informatie gaan bijdragen aan lokale time machines. Door op deze manier technologie, lokale geschiedenis en burgerparticipatie te combineren, maken we het voor inwoners makkelijker en leuker om actief betrokken te zijn bij het erfgoed van hun eigen leefomgeving. Daarmee dragen we bij aan het gevoel van verbondenheid met die leefomgeving.

3.3. Deelactiviteiten

3.3.1. Uitvraag behoefte

Aard & wijze van uitvoering:

Uitvoeren van gesprekken, workshops en digitale enquêtes met belanghebbenden in de vier steden (bewoners, erfgoedinstellingen, vrijwilligers bij historische vereniging, enz.).

Onderzoek naar gebruiksbehoefte m.b.t. toevoegen van beeldmateriaal en verhalen, en het verrijken van bestaande erfgoeddata.

Parallel verkenning van auteursrechtelijke vraagstukken in samenwerking met o.a. Wikimedia Nederland.

Doelstelling:

Inzicht verkrijgen in gebruikersbehoeften en voorwaarden voor participatie.

Risico’s op auteursrechtinbreuk ondervangen via kennisdeling en samenwerking.

Resultaten/Producten:

Uitgewerkte lijst met functionele en niet-functionele requirements.

Aanpak auteursrecht & participatie.

Status (augustus 2026): de functionele en niet-functionele requirements en usecases per rol zijn uitgewerkt. Voor auteursrecht en participatie liggen er juridische conceptdocumenten (o.a. risico’s en wet- en regelgeving, algemene voorwaarden en een handreiking moderatie), nog te toetsen door een jurist.

3.3.2. Verkenning technische oplossingsrichting

Aard & wijze van uitvoering:

Technische analyse op basis van de requirements.

Verkenning bestaande oplossingen (bijv. via open source, Linked Data, crowdsourcing-tools). Gebruik maken van de kennis van het Netwerk Digitaal Erfgoed en de ervaringen van de Amsterdam Time Machine met Meaningful Memories in samenwerking met SURF.

Interviews met technische partners, leveranciers en gebruikers. Hier wordt een breed netwerk van partners ingezet in elk van de vier locaties.

Doelstelling:

Vaststellen welke (generieke of lokale) technische oplossing het meest geschikt is.

Resultaten/Producten:

Status (augustus 2026): de architectuurschets is uitgegroeid tot een volwaardige systeemarchitectuur en data-architectuur. De scenario-afweging is uitgevoerd in de infrastructuuranalyse (vier richtingen); er is gekozen voor één generiek platform (Jottem) voor alle tijdmachines, in plaats van maatwerk per tijdmachine.

3.3.3. Keuze oplossingsrichting

Aard & wijze van uitvoering:

Afweging van technische en functionele varianten op basis van geschiktheid, schaalbaarheid en duurzaamheid.

Besluitvorming in overleg met lokale partners en gebruikers.

Doelstelling:

Vaststellen van een gedragen en uitvoerbare oplossingsrichting.

Resultaten/Producten:

Status (augustus 2026): opgeleverd als het keuzedocument: alles op de Jottem-server met een expliciete exit-/exportstrategie, een gekozen technologiestack en besliste openstaande vragen (o.a. ARK uitgesteld naar een latere fase).

3.3.4. Implementatie per tijdmachine

Aard & wijze van uitvoering:

Gefaseerde implementatie in vier steden (Amsterdam, Utrecht, Gouda, Hilversum), afhankelijk van lokale infrastructuur en partners.

Aansluiten op bestaande platforms of ontwikkelen van aanvullende modules.

Training van lokale beheerders en vrijwilligers.

Doelstelling:

Functionele toepassing waarmee gebruikers foto’s/verhalen kunnen toevoegen en/of erfgoeddata kunnen verrijken.

Resultaten/Producten:

Status (augustus 2026): het ontwerp voor de realisatie is gereed (usecases, API-specificaties, klikbaar prototype). De eerste implementatie start met de pilot Smaak van Gouda, als eerste project op de organisatiejottem van Streekarchief Midden-Holland. Voor het aansluiten van (meer) organisaties is er een salespitch voor organisaties (jaarlijkse bijdrage €100, inzet op communicatie en moderatie). De MVP-afbakening en fasering staan in het § 16 Realisatieplan.

3.3.5. Testen en nazorg

Aard & wijze van uitvoering:

Uitvoeren van gebruikerssessies met diverse doelgroepen (jong, oud, expert, leek)

Inrichting aanspreekpunt per Time Machine bij knelpunten.

Verzamelen van feedback via surveys en interviews.

Doelstelling:

Verbeterpunten identificeren en gebruikservaring meten.

Resultaten/Producten:

Status (augustus 2026): de aanpak voor geautomatiseerd testen en monitoring is uitgewerkt in de systeemarchitectuur; gebruikerssessies volgen tijdens de pilot.

3.3.6. Evaluatie en leerpunten

Aard & wijze van uitvoering:

Interne evaluatie met projectteam en partners.

Reflectie op aanpak, werkwijze en samenwerking.

Doelstelling:

Vastleggen van leerpunten en bepalen van vervolgscenario’s (zoals vervolg in andere steden of opschaling).

Resultaten/Producten:

3.3.7. Communicatie & kennisdeling

Aard & wijze van uitvoering:

Regelmatige updates via nieuwsbrieven, sociale media van de verschillende tijdmachines en partnersites.

Organiseren van minimaal twee kennissessies/webinars over participatief digitaal erfgoed.

Doelstelling:

Transparantie in het proces, kennisdeling en communityvorming bevorderen.

Resultaten/Producten:

3.3.8. Beheer & borging

Aard & wijze van uitvoering:

Afspraken maken over beheer en actualisatie van functionaliteit.

Inbedding in organisatie/partnerstructuren (bijv. via erfgoedhuizen, bibliotheken of burgerinitiatieven).

Doelstelling:

Duurzame borging van de oplossing.

Resultaten/Producten:

Status (augustus 2026): er ligt een concept-samenwerkingsovereenkomst; duurzame borging is verankerd in de exit-/exportstrategie van het keuzedocument en de e-depot-export per project (BagIt + RO-Crate). Tot het duurzame beheer hoort ook de afleverbaarheid van de platformmail: vóór livegang worden SPF, DKIM en DMARC op het verzenddomein ingeregeld en krijgen de attenderingsmails one-click unsubscribe, zodat gebruikers ze makkelijk uitzetten in plaats van ze als spam te markeren; het volledige pakket maatregelen (reverse DNS, eigen MTA, bouncebeheer, reputatiemonitoring) staat in de afleverbaarheidssectie van het ontwerp.

3.4. Relatie met de Faro-kernwaarden

Participatie in de volle breedte: Door het delen en taggen van foto’s, verhalen en kennis ontstaat er een directe en laagdrempelige vorm van erfgoedparticipatie. Dit past bij het idee van “mee kunnen doen” en “mee mogen bepalen”. Door te werken aan een publieksvriendelijke, visuele annotatieomgeving verlagen we de drempel om deel te nemen – zowel technisch als mentaal. We creëren een webomgeving waarbij vrijwilligers zelf informatie kunnen toevoegen, verbeteren of kunnen linken naar andere bronnen. Niet alleen experts, maar ook buurtbewoners, jongeren of incidentele bezoekers kunnen meedoen, hun stem laten horen en hun perspectieven toevoegen. Daarmee groeit het besef dat iedereen eigenaar is van erfgoed en dat erfgoed gevormd wordt door de gemeenschap zelf.

Erfgoed midden in de samenleving: Dit initiatief plaatst erfgoed letterlijk en figuurlijk midden in de samenleving. De lokale Time Machines brengen de geschiedenis van de stad, wijk, straat of zelfs het huis dichtbij bewoners, en maken het tastbaar, zichtbaar én persoonlijk relevant. Door mensen uit te nodigen hun eigen foto’s en verhalen te delen, verandert erfgoed van iets ‘van een instelling’ in iets van en voor iedereen. Het project erkent dat erfgoed onlosmakelijk deel uitmaakt van de leefomgeving, en maakt dat zichtbaar op plekken waar mensen dagelijks zijn.

De Time Machines functioneren als platforms voor ontmoeting, herinnering en kennisdeling, en sluiten daarmee aan op de gedachte dat erfgoed bijdraagt aan identiteit, zelfbewustzijn en gemeenschapszin. Inwoners herkennen hun eigen geschiedenis in het grotere verhaal van hun stad en voelen zich daardoor meer verbonden met hun omgeving. Dit versterkt het gevoel van eigenaarschap en draagt bij aan het welzijn van mensen - erfgoed als bron van zingeving en verbondenheid.

3.5. Omschrijving hoofdthema en aanluiting bij de Uitvoeringsagenda Faro

Het Time Machine-initiatief sluit goed aan bij het kantelende perspectief op dienstverlening zoals geformuleerd in de NDE-agenda: niet de collectie of technologie staat centraal, maar de gemeenschap als belanghebbende. In dit project draait het om wat inwoners zelf belangrijk vinden in hun leefomgeving, welke verhalen ze willen vertellen en hoe ze dat digitaal willen doen. De vraag is niet: “Wat kunnen wij ontsluiten?” maar: “Wat willen mensen delen, bewaren en doorgeven?” Daarmee sluit het project direct aan op het idee om erfgoedgemeenschappen mede vorm te laten geven aan digitaal erfgoed.

Het initiatief bevordert ‘Ondersteuning erfgoedparticipatie’ doordat het de voorwaarden schept voor inwoners, vrijwilligers en erfgoedgemeenschappen om actief bij te dragen aan het zichtbaar maken van erfgoed. Mensen kunnen laagdrempelig meedoen. Het project ondersteunt erfgoedparticipatie door mensen niet alleen te betrekken als publiek, maar hen daadwerkelijk in staat te stellen zelf mede-eigenaar, bijdrager en medevormgever van het erfgoed te worden.

Tegelijkertijd is er ruimte voor intergenerationele samenwerking. Jongeren kunnen bijvoorbeeld ouderen helpen met het digitaliseren van oude foto’s, terwijl ouderen hun lokale historische kennis delen. Zo ontstaat een dynamische uitwisseling van digitale nieuwsgierigheid en historische ervaring, waarin beide groepen waardevol zijn voor het erfgoedproces.

De Time Machines maken het mogelijk dat lokale bewoners - jong en oud, digitaal vaardig of juist minder - actief bijdragen aan erfgoed door eigen foto’s te delen, deze te taggen, of verhalen toe te voegen. Er is aandacht voor een laagdrempelige en beheersbare interactieomgeving, zodat mensen eenvoudig kunnen meedoen, zonder dat technische barrières hen uitsluiten. Dit draagt bij aan digitale inclusie en erkent dat niet iedereen dezelfde toegang of vaardigheden heeft. De tools die ontwikkeld en gedeeld worden binnen dit project zijn dan ook gericht op gebruiksvriendelijkheid, herbruikbaarheid en brede toepasbaarheid, zodat ook kleinere erfgoedinitiatieven of vrijwilligersgroepen ermee aan de slag kunnen. Dit maakt dat digitaal erfgoed het hoofdthema is waarbinnen we aanvragen.

3.6. Structurele verandering ten opzichte van het huidige functioneren van de erfgoedzorg

In plaats van erfgoed slechts te bewaren en ontsluiten, draait het in de lokale Time Machines om actieve betrokkenheid, samenwerking en gedeeld eigenaarschap. Inwoners kunnen hun eigen foto’s en verhalen toevoegen en taggen, waardoor erfgoed dynamisch, persoonlijk en meervoudig wordt. Dit vraagt om een systeemaanpassing: van aanbod- naar vraaggericht werken en van erfgoed beheren naar erfgoed samen maken.

Het project ontwikkelt en test een laagdrempelige, visueel aantrekkelijke annotatieomgeving waarin burgers op toegankelijke wijze kunnen participeren. Dit instrument biedt een concrete methodiek voor participatieve digitale erfgoedzorg, die breed toepasbaar en herbruikbaar is. Door technische samenwerking en uitwisseling tussen Time Machines ontstaat bovendien een schaalsprong: succesvolle toepassingen kunnen eenvoudig elders worden ingezet. Dit maakt het mogelijk om met beperkte middelen meer gemeenschappen te bedienen.

Daarnaast stimuleert het project nieuwe coalities tussen erfgoedinstellingen, vrijwilligersorganisaties, burgerinitiatieven, ontwerpers, techpartners en educatieve instellingen. Een voorbeeld is de samenwerking in Hilversum met Hilversummers.nl, een een online platform dat zich inzet voor het versterken van de lokale gemeenschap in Hilversum; of de samenwerking in Gouda met een game-ontwikkelaar. Deze netwerken zorgen voor verankering, maar ook voor verrijking van het erfgoed met diverse perspectieven en kennisvormen. Zo wordt het erfgoedveld inclusiever, creatiever en beter verbonden met de samenleving.

Kortom, het initiatief is geen tijdelijk experiment, maar een bouwsteen voor een digitale, meer democratische en participatieve erfgoedsector. Het laat zien hoe erfgoed midden in de samenleving kan staan als iets dat mensen samen vormgeven, betekenis geven en levend houden.

3.7. Plan voor kennisontwikkeling en kennisdeling en de daarbij beoogde doelgroep(en)

Het project zet actief in op kennisdeling met erfgoedprofessionals, burgers en beleidsmakers. Dit gebeurt via twee sporen: doorlopende communicatie via online kanalen van de participerende time machines (en partnerorganisaties) en het organiseren van kennissessies.

3.7.1. Doorlopende communicatie

3.7.2. Kennissessies en webinars

Er worden minimaal twee kennissessies georganiseerd:

4. Pilot: Smaak van Gouda

Smaak van Gouda – Verhalen achter verdwenen restaurants in de stad is een participatief erfgoedproject over de horecageschiedenis van Gouda. Het is de eerste concrete pilot waarmee het IOTM/Jottem platform van begin tot eind wordt beproefd.

4.1. Aanleiding & doel

Restaurants, cafés, snackbars, lunchrooms, koffiehuizen, ijssalons en afhaalzaken zijn al generaties lang onderdeel van het dagelijks leven in Gouda. Veel van deze zaken zijn verdwenen, terwijl nieuwe ondernemers en keukens hun intrede deden. Het project wil de geschiedenis van de Goudse horeca documenteren, bewaren en toegankelijk maken - van koffiehuizen en melkbars tot Chinese restaurants, shoarmazaken, pizzeria’s, Surinaamse eethuizen en moderne wereldkeukens - met bijzondere aandacht voor de rol van ondernemers met verschillende culturele achtergronden en de ontwikkeling van internationale keukens. Zo ontstaat niet alleen een overzicht van eetgelegenheden, maar ook een sociaal-culturele geschiedenis van smaak, ondernemerschap, migratie en ontmoeting.

4.2. Pilot voor IOTM

De pilot draait als eerste project op de organisatiejottem van Streekarchief Midden-Holland, met een eigen projectpagina, oproep en datasetbeschrijving. Inwoners dragen bij via het Jottem platform: foto’s, menukaarten, advertenties en persoonlijke herinneringen worden verzameld, gemodereerd en duurzaam ontsloten. De pilot valideert de bestaande platformfunctionaliteit (zie § 7 Usecases per rol) en brengt een aantal eisen scherp in beeld.

4.3. Wat dit van het platform vraagt

4.4. Te verzamelen materiaal

4.5. Participatie

Het project wordt samen met inwoners opgebouwd via verzameldagen en scansessies, oproepen via lokale media en interviews met oud-horecaondernemers, in samenwerking met wijkverenigingen en erfgoedorganisaties zoals Stichting Gedeeld Verleden, Gezamenlijke Toekomst.

5. Praatplaten

5.1. Belanghebbenden

5.2. Mediaproces

5.3. Processtappen

5.4. Platformonderdelen

5.5. Annotaties

5.6. Technische onderdelen

6. Requirements

6.1. Functionele requirements

6.2. Niet-functionele requirements

Onderstaande waarden zijn richtwaarden (concept), vast te stellen door de projectgroep.

6.3. Standaarden & API’s

6.5. (Sub)domeinen

7. Usecases per rol

Ter ondersteuning van onderstaande usescases is er een prototype.

7.1. Als platformbeheerder kan ik

7.2. Als organisatiebeheerder kan ik

7.3. Als moderator kan ik

7.4. Als gebruiker (binnen een organisatie) kan ik

7.5. Als gebruiker/uploader (binnen een organisatie) kan ik

7.6. Als gebruikers/annoteerder (binnen een organisatie) kan ik

Zie § 8 Verrijkingen voor de volledige catalogus van verrijkingsmogelijkheden, met per mogelijkheid de call-to-action, de technische impact en de vorm als Web Annotation.

7.7. Als API gebruiker kan ik

7.8. Als bezoeker kan ik

8. Verrijkingen

Het verrijken van geüploade afbeeldingen is cruciaal om losse foto’s en documenten om te zetten in doorzoekbare, gestructureerde en betekenisvolle historische bronnen. Dit hoofdstuk is de catalogus van verrijkingsmogelijkheden: per mogelijkheid de beschrijving, de call-to-action (B1-taalniveau) die bij een jottem wordt getoond om gebruikers te nudgen, de technische impact of standaard, en een indicatie hoe de verrijking er als W3C Web Annotation uitziet. Het sluit aan op de § 7 Usecases per rol van de annoteerder en op de opslag en ontsluiting van annotaties in de data-architectuur.

Leeswijzer bij de Web Annotation-voorbeelden. Alle voorbeelden volgen het W3C Web Annotation Data Model. Voor de leesbaarheid zijn @context (http://www.w3.org/ns/anno.jsonld), id, creator en created weggelaten; het platform vult die altijd. Het target is de duurzame jottem-URI of het IIIF-canvas; vlakken worden geselecteerd met een FragmentSelector (xywh=pixel:x,y,w,h) of SvgSelector. De impact-indicatie: laag = past in de bestaande annotatieflow, middel = extra UI of veld, hoog = nieuwe pipeline of koppelvlak. Mogelijkheden gemarkeerd met (niet in MVP) volgen in fase 2 of later.

8.1. Inhoudelijke en beeldannotaties (IIIF en W3C Web Annotations)

8.1.1. Vlak-annotaties (bounding boxes)

Het selecteren van specifieke regio’s of uitsneden op een afbeelding, bijvoorbeeld een individuele persoon op een groepsfoto, een detail van een gevel of een specifiek gerecht op een menukaart.

Call-to-action: "Zie je iets bijzonders op deze foto? Teken er een vak omheen en vertel wat het is." en "Ken je iemand op deze foto? Klik op die persoon."

Techniek/standaard: W3C Web Annotation met FragmentSelector (Media Fragments, xywh=pixel:) of SvgSelector op het IIIF-canvas; Annotorious in de frontend. Impact: laag (kern van de bestaande annotatieflow).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "identifying",
  "target": {
    "source": "https://iiif.iotm.nl/jottem/{id}/canvas/1",
    "selector": {
      "type": "FragmentSelector",
      "conformsTo": "http://www.w3.org/TR/media-frags/",
      "value": "xywh=pixel:410,220,180,260"
    }
  },
  "body": { "type": "TextualBody", "purpose": "identifying", "value": "Wong Lee, kok" }
}

8.1.2. Taggen met gecontroleerde vocabulaires

Het koppelen van gestructureerde begrippen uit het NDE Termennetwerk, de Cultuurhistorische Thesaurus (CHT) of Wikidata aan (onderdelen van) de afbeelding.

Call-to-action: "Wat zie je op deze foto? Kies een woord uit de lijst, dan kan iedereen het terugvinden."

Techniek/standaard: motivation tagging met een SpecificResource-body die naar de term-URI wijst; termen zoeken via het NDE Termennetwerk (GraphQL), beperkt tot de terminologiebronnen van het project. Impact: laag (bestaande Termennetwerk-integratie).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "tagging",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "SpecificResource",
    "purpose": "tagging",
    "source": "https://data.cultureelerfgoed.nl/term/id/cht/{term}"
  }
}

8.1.3. Materiaal- en genretypering

Het toekennen van het specifieke bron- of materiaaltype aan de upload, zoals foto, menukaart, advertentie, folder, krantenartikel of vergunning.

Call-to-action: "Wat voor iets is dit? Kies: foto, menukaart, advertentie of iets anders."

Techniek/standaard: in de MVP is dit metadata (Media.genre, gekoppeld aan een CHT-term, zie de data-architectuur), geen annotatie; een correctievoorstel door een gebruiker kan wél als annotatie. Impact: laag (bestaand veld).

Als Web Annotation (correctievoorstel):

{
  "type": "Annotation",
  "motivation": "classifying",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "SpecificResource",
    "purpose": "classifying",
    "source": "https://data.cultureelerfgoed.nl/term/id/cht/{menukaart}"
  }
}

8.1.4. Crowd-solving: identificatievragen

Vragen stellen aan de gemeenschap om onbekende elementen op te lossen, zoals "Wie kent deze persoon?" of "Welke winkel was dit?".

Call-to-action: "Weet jij dit niet? Stel je vraag, misschien weet een ander het wel." en bij bestaande vragen: "Iemand vraagt: wie is dit? Weet jij het antwoord?"

Techniek/standaard: motivation questioning; antwoorden hangen er als reactie aan (motivation replying, zie de bestaande reactieflow). Impact: laag.

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "questioning",
  "target": {
    "source": "https://iiif.iotm.nl/jottem/{id}/canvas/1",
    "selector": { "type": "FragmentSelector", "value": "xywh=pixel:120,80,200,300" }
  },
  "body": { "type": "TextualBody", "purpose": "questioning", "value": "Wie kent deze persoon?" }
}

8.2. Geografische en temporele verrijking (plaats en tijd)

8.2.1. Georeferentiëring en adreskoppeling

Het toevoegen van coördinaten, straatnamen en huisnummers waaraan de afbeelding is gerelateerd. In de MVP prikt de uploader de locatie als speld op de kaart (dat levert de coördinaten als metadata); automatische adreskoppeling (geocoding, pand-ID’s zoals BAG) is (niet in MVP).

Call-to-action: "Weet je waar dit was? Zet een speld op de kaart." en "Klopt de plek niet helemaal? Versleep de speld."

Techniek/standaard: speld = lat/lon als metadata bij de jottem (MVP); correcties en aanvullingen door anderen als annotatie met een GeoJSON-body; latere fase: PDOK Locatieserver en BAG-pand-ID’s. Impact: laag (speld), hoog (adreskoppeling).

Als Web Annotation (locatievoorstel):

{
  "type": "Annotation",
  "motivation": "identifying",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "TextualBody",
    "purpose": "identifying",
    "format": "application/geo+json",
    "value": "{ \"type\": \"Point\", \"coordinates\": [4.7083, 52.0115] }"
  }
}

8.2.2. Tijdlijn en periode-aanduiding

Het vastleggen van een exacte datum, jaartal of tijdsperiode, zoals de openings- en sluitingsjaren van een horecazaak of bedrijf in een pand.

Call-to-action: "Weet je wanneer dit was? Vul het jaartal in, ook een gok helpt." en "Wanneer ging deze zaak open en dicht?"

Techniek/standaard: periodes in EDTF (Extended Date/Time Format, bijv. 1973/1996 of 196X voor "jaren zestig"); exacte datums als metadata, aanvullingen en correcties als annotatie. Voedt de pand-tijdlijn op de kaart. Impact: laag.

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "describing",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "TextualBody",
    "purpose": "describing",
    "value": "Geopend 1973, gesloten 1996 (EDTF: 1973/1996)"
  }
}

8.2.3. Geopositionering en zichtveld

Het bepalen van het camerastandpunt en de kijkrichting om de foto in te passen in een interactieve kaart of ruimtelijk-temporele omgeving, zoals de Gouda Tijdmachine.

Call-to-action: "Waar stond de fotograaf? Zet een speld en draai het pijltje in de kijkrichting."

Techniek/standaard: GeoJSON-punt met kijkrichting (bearing in graden) en zichtshoek; sluit aan op het GTM-koppelvlak (fase 2) en op de geo-requirements (WKT/GeoJSON). Impact: middel (extra UI op de kaart). De invoer gebruikt Leaflet.GeotagPhoto (L.geotagPhoto.camera), dezelfde interactie als in de Gouda Tijdmachine: versleep de camera en het doelpunt en knijp de beeldhoek. Opgeslagen wordt een Feature met het camerapunt als geometry en properties: { bearing, fov, target: [lon, lat] }; het doelpunt maakt herbewerken mogelijk.

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "describing",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "TextualBody",
    "purpose": "describing",
    "format": "application/geo+json",
    "value": "{ \"type\": \"Point\", \"coordinates\": [4.7083, 52.0115], \"properties\": { \"bearing\": 220, \"fov\": 60 } }"
  }
}

8.3. Tekstuele verrijking en transcriptie (OCR/HTR)

8.3.1. Handmatige en geassisteerde transcriptie (niet in MVP)

Het letterlijk uittypen van teksten die op het beeld staan, zoals opschriften op uithangborden, menukaarten, krantenartikelen of handgeschreven annotaties en brieven.

Call-to-action: "Kun je lezen wat hier staat? Typ het over, dan kan iedereen het vinden."

Techniek/standaard: motivation supplementing (de standaardvorm voor transcripties in IIIF-omgevingen), per tekstregel of tekstblok met een vlak-selector; geassisteerd met OCR (Tesseract) of HTR (Loghi/Transkribus) als suggestie. Impact: hoog (aparte transcriptie-UI en, bij assistentie, een OCR/HTR-pipeline).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "supplementing",
  "target": {
    "source": "https://iiif.iotm.nl/jottem/{id}/canvas/1",
    "selector": { "type": "FragmentSelector", "value": "xywh=pixel:60,340,480,60" }
  },
  "body": { "type": "TextualBody", "purpose": "supplementing", "value": "Babi pangang f 8,50" }
}

8.3.2. Vertaling en begrippenverklaring

Het toelichten van verouderde termen, verdwenen beroepen, dialectwoorden of historische munteenheden die op het beeld of in menukaarten en documenten voorkomen.

Call-to-action: "Weet jij wat dit woord betekent? Leg het uit voor wie het niet meer kent."

Techniek/standaard: motivation describing op een vlak of op de hele jottem; waar mogelijk met een term-URI (Termennetwerk) als tweede body. Impact: laag.

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "describing",
  "target": {
    "source": "https://iiif.iotm.nl/jottem/{id}/canvas/1",
    "selector": { "type": "FragmentSelector", "value": "xywh=pixel:60,340,180,40" }
  },
  "body": {
    "type": "TextualBody",
    "purpose": "describing",
    "value": "Een melkinrichting was een winkel waar je melk, boter en kaas kocht."
  }
}

8.3.3. Indexering van namen en lijsten (niet in MVP)

Het specifiek doorzoekbaar maken van namen en functies op gedenkplaten, verenigingsfoto’s of officiële documenten.

Call-to-action: "Staan er namen op? Typ ze over, dan zijn ze te vinden voor familie en onderzoekers."

Techniek/standaard: reeks supplementing-annotaties met per naam een vlak-selector en een gestructureerde body (naam, functie); de zoekindex neemt ze mee als doorzoekbare velden. Impact: middel (lijst-invoer-UI en indexering).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "supplementing",
  "target": {
    "source": "https://iiif.iotm.nl/jottem/{id}/canvas/1",
    "selector": { "type": "FragmentSelector", "value": "xywh=pixel:220,120,160,40" }
  },
  "body": { "type": "TextualBody", "purpose": "identifying", "value": "J. van Dam, voorzitter" }
}

8.4. Storytelling en anekdotische verrijking

8.4.1. Persoonlijke herinneringen en anekdotes

Het toevoegen van verhalen en getuigenissen bij een foto. Hierbij wordt een duidelijk onderscheid gemaakt tussen historisch verifieerbare feiten en persoonlijke herinneringen.

Call-to-action: "Was jij hier weleens? Vertel je herinnering, groot of klein." en "Wat weet jij nog van deze plek?"

Techniek/standaard: motivation commenting; het onderscheid herinnering versus feit is een expliciet kenmerk op de annotatie (platform-extensie jottem:aard), zichtbaar in de weergave en meegenomen in de moderatiehandreiking. Impact: laag.

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "commenting",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "TextualBody",
    "purpose": "commenting",
    "value": "Mijn ouders aten hier elke verjaardag."
  },
  "jottem:aard": "herinnering"
}

8.4.2. Audio-annotaties en interviews (niet in MVP)

Het koppelen van gesproken herinneringen, mondelinge historie (oral history) of interviewfragmenten aan de afbeelding of een specifiek canvas.

Call-to-action: "Vertel je verhaal liever? Neem het op, praten mag ook."

Techniek/standaard: annotatie met een audio-body (opname via de browser, opslag in de audio-bucket); hangt samen met de audio-ondersteuning uit fase 2 (transcodering, IIIF-audio-canvas). Impact: hoog (opname-UI en audio-pipeline).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "commenting",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "Sound",
    "id": "https://media.iotm.nl/audio/{opname}.mp3",
    "format": "audio/mpeg"
  }
}

8.4.3. Externe bronverwijzingen

Het toevoegen van URI-koppelingen naar externe archiefsystemen, kadasterkaarten of krantenbanken zoals Delpher.

Call-to-action: "Ken je een krantenbericht of archiefstuk over deze plek? Plak de link erbij."

Techniek/standaard: motivation linking met de externe URI als body; label en bronvermelding erbij. Sluit aan op het bestaande requirement voor archiefbron-koppelingen (label + URI). Impact: laag.

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "linking",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "SpecificResource",
    "purpose": "linking",
    "source": "https://resolver.kb.nl/resolve?urn=ddd:110577489:mpeg21"
  }
}

8.5. Relatieve en vergelijkende activiteiten

8.5.1. "Toen en nu" (herfotografie) (niet in MVP)

Het toevoegen van een hedendaagse foto vanaf exact dezelfde locatie en invalshoek om verandering in de leefomgeving in beeld te brengen.

Call-to-action: "Woon je in de buurt? Maak dezelfde foto zoals het er nu uitziet en zet hem ernaast."

Techniek/standaard: de nu-foto is zelf een jottem (met eigen moderatie); de koppeling loopt via dezelfde structurele relatie als bij § 8.5.2 Zelfde object, andere foto, met de linking-annotatie als afgeleide; weergave als voor/na-schuif in de viewer (IIIF Choice of twee canvassen). Impact: middel (upload-koppelflow en vergelijkingsweergave).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "linking",
  "target": "https://www.iotm.nl/jottem/{toen}",
  "body": {
    "type": "SpecificResource",
    "purpose": "linking",
    "source": "https://www.iotm.nl/jottem/{nu}"
  }
}

8.5.2. Zelfde object, andere foto

Iemand herkent het onderwerp van een jottem en heeft er zelf een foto van: dezelfde gevel tien jaar later, hetzelfde interieur vanuit een andere hoek, dezelfde zaak op een ansichtkaart. Anders dan de andere verrijkingen levert dit geen uitspraak óver de bestaande jottem op, maar een nieuwe jottem plus een koppeling tussen de twee.

Call-to-action: "Heb je zelf een foto van hetzelfde, maar uit een andere tijd of vanuit een andere hoek? Voeg hem toe."

Techniek/standaard: de call-to-action opent een uitleg en leidt daarna naar het uploadformulier, met de jottem van herkomst in beeld; de nieuwe foto is zelf een jottem met eigen moderatie. De koppeling is een structurele relatie in de database (MediaRelatie, binnen hetzelfde project) en is daarmee de bron van waarheid; daaruit worden een linking-annotatie in de container van beide jottems en dcterms:relation in de RDF van beide jottems afgeleid, zodra allebei gepubliceerd zijn. Weergave: bij beide jottems een kaartje met thumbnail en link. Impact: middel (uploadkoppelflow en weergave aan twee kanten).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "linking",
  "target": "https://www.iotm.nl/jottem/{deze}",
  "body": {
    "type": "SpecificResource",
    "purpose": "linking",
    "source": "https://www.iotm.nl/jottem/{andere}"
  },
  "jottem:verrijking": "zelfde-object"
}

8.5.3. Chronologische reeksen

Het onderling koppelen van afbeeldingen om een tijdlijn van één specifieke locatie, familie of evenement door de jaren heen op te bouwen.

Call-to-action: "Hoort deze foto bij dezelfde plek als een andere? Koppel ze aan elkaar."

Techniek/standaard: in de MVP ontstaat de pand-tijdlijn automatisch uit adres en openings-/sluitingsjaren (metadata); handmatige koppelingen zijn structurele relaties zoals bij § 8.5.2 Zelfde object, andere foto, met de linking-annotatie als afgeleide; gepubliceerde reeksen als IIIF Collection of Range. Impact: laag (automatisch), middel (handmatig koppelen met UI).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "linking",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "SpecificResource",
    "purpose": "linking",
    "source": "https://www.iotm.nl/jottem/{ander}"
  }
}

8.5.4. Multimediale bundeling (niet in MVP)

Een krantenartikel, menukaart, interieurfoto en personeelsfoto van hetzelfde pand of bedrijf aan elkaar koppelen.

Call-to-action: "Heb je meer over deze zaak? Voeg het samen tot één verhaal."

Techniek/standaard: IIIF Collection per pand of bedrijf, gevuld met linking-annotaties tussen de jottems; de bundel krijgt een eigen pagina. Impact: middel.

Als Web Annotation: zoals bij § 8.5.3 Chronologische reeksen; de bundel zelf is een IIIF Collection, geen annotatie.

8.6. Geautomatiseerde en AI-ondersteunde verrijking

8.6.1. Automatische beeldherkenning (niet in MVP)

AI-gebaseerde detectie van objecten, architectuurstijlen, voertuigen of kledingstijlen als suggestie voor de gebruiker.

Call-to-action: "De computer denkt dat hier een bakfiets staat. Klopt dat? Ja / Nee."

Techniek/standaard: eigen dienst naast de Herkenbaar API; suggesties zijn annotaties met een generator (software) en een betrouwbaarheidsscore; een gebruiker of moderator bevestigt voordat de suggestie definitief wordt. Impact: hoog (ML-pipeline en bevestigingsflow).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "tagging",
  "generator": { "type": "Software", "name": "jottem-beeldherkenning" },
  "jottem:betrouwbaarheid": 0.87,
  "target": {
    "source": "https://iiif.iotm.nl/jottem/{id}/canvas/1",
    "selector": { "type": "FragmentSelector", "value": "xywh=pixel:40,300,220,180" }
  },
  "body": { "type": "TextualBody", "purpose": "tagging", "value": "bakfiets" }
}

8.6.2. Suggesties bij het uploaden

Het uploadformulier loopt in twee stappen: eerst de foto, dan de gegevens erbij. Tussen die twee stappen is het beeld al bekend, en dat is het moment waarop het platform kan meedenken. Anders dan de overige verrijkingen gebeurt dit niet ná publicatie maar ervóór, en het resultaat is geen annotatie maar een voorgevuld formulierveld dat de inzender bevestigt of overschrijft.

Bij een beeldbank-permalink komt de eerste vulling gratis: het IIIF-manifest bevat titel, beschrijving, datering en vervaardiger. Bij een eigen foto komt hij van een interne dienst.

Call-to-action: geen knop; de velden staan voorgevuld met een regel eronder waar het voorstel vandaan komt. Is de dienst nog bezig wanneer de inzender aan de gegevens toe is, dan overbrugt een wachtscherm dat moment: een vis, getekend naar het beeldmerk, die rustig deint tot de voorstellen er zijn. Dat scherm knippert niet bij een snelle dienst, houdt niemand langer dan vijftien seconden op, en is altijd over te slaan.

Techniek/standaard: één interne dienst naast de Herkenbaar API, met één endpoint dat titel, categorie en steekwoorden teruggeeft, elk met een betrouwbaarheidsscore. Dezelfde semantiek als het Herkenbaar-signaal: een hulpsignaal, geen poortwachter. Ligt de dienst plat of duurt hij te lang, dan opent stap 2 met lege velden en merkt de inzender daar niets van. Impact: hoog (nieuwe dienst met twee modellen).

*Gerealiseerd in augustus 2026 als de Suggesties API (EUPL-1.2). Gemeten op de ontwikkelmachine (24 kernen, geen videokaart): 3,5 tot 5,4 seconde per foto en 2,7 GB geheugen. Een aanvaard steekwoord uit de thesaurus draagt zijn term-URI mee en komt in de RDF terug als schema:about met label en URI, niet als los woord in schema:keywords.*

Steekproef van 22 archiefbeelden (zeven foto’s uit de SAMH-beeldbank, de rest historisch drukwerk uit Wikimedia Commons, verdeeld over de zeven categorieën):

Veld Uitkomst
titel 16 van de 22 direct bruikbaar, 4 zwak of vaag ("Een oud gebouw in een stad"), 2 fout ("Een man met een masker" bij een kledingstuk op een paspop). De beste zijn opvallend precies: "Een menukaart voor een hotel du cheval blanc", "Twee mannen in militaire uniformen poseren", "Een groot gebouw met rode luiken op de voorkant".
categorie 20 van de 22 kregen een voorstel, waarvan 17 juist. Twee keer geen voorstel bij een beeld waar het model geen signaal vond, en dat is de bedoeling. Eén echte misser: een bronzen gedenkplaat werd "folder" genoemd.
steekwoorden 19 voorstellen over 10 beelden, waarvan 14 raak. Rake voorbeelden: "stadhuizen" en "marktplaatsen" bij het Goudse stadhuis, "bruggen" en "grachten" bij een brug over een gracht, en drie treffers bij een reclamewagen. Misslagen zijn van het type "postkantoren" bij een marktplein: verwant maar onjuist. De helft van de beelden kreeg geen enkel steekwoord.

De steekproef legde één instelfout bloot die met redeneren niet te vinden was: de ondergrens voor de categorie stond op een absolute waarde, en juist gewone historische foto’s scoren absoluut laag. Vijf van de zeven echte foto’s werden daardoor overgeslagen terwijl "foto" wel met ruime voorsprong won. Bij een keuze uit een gesloten lijst zegt de verhouding tot de nummer twee alles en de absolute waarde niets; na die correctie gingen de vijf gemiste foto’s alsnog goed.

Let wel: 22 beelden is een indruk, geen maat. Voor de livegang hoort dit herhaald te worden op materiaal dat de pilot zelf oplevert.

8.6.2.1. Afweging: één dienst of drie
Optie Voordelen Nadelen
Eén nieuwe dienst met één endpoint (gekozen) De foto gaat één keer over de lijn en wordt één keer gedecodeerd; beide modellen delen dezelfde voorbewerking; één container, één health-check, één plek voor het AI-label; permissief gelicentieerde modellen, dus de dienst kan EUPL-1.2 zijn zoals het platform Twee modellen in één proces, dus het geheugengebruik van beide tegelijk; een storing raakt alle drie de suggesties tegelijk
Erbij in de Herkenbaar API Geen extra container; het beeld is daar al in het geheugen Die repo is AGPL-3.0 omdat ultralytics/YOLO dat afdwingt, en die grens valt bewust samen met de repogrens; bovendien zou één dienst twee ongelijksoortige dingen doen (portretrecht tegenover metadata)
Drie losse diensten Maximaal modulair; per taak apart te schalen of te vervangen Drie containers, drie modelladingen en drie keer hetzelfde beeld over de lijn, zonder dat het iets oplevert op de schaal van dit platform

Besluit. Eén nieuwe dienst in een eigen repo, naast de Herkenbaar API. Doorslaggevend is dat de licentiegrens hier ánders ligt: Florence-2 is MIT en SigLIP 2 is Apache-2.0, dus deze dienst hoeft niet AGPL te worden en kan dezelfde licentie dragen als het platform. De prijs is een tweede container die modelgewichten in het geheugen houdt.

Herzien wanneer. De inferentie zo zwaar wordt dat hij een eigen machine of videokaart verdient; dan is het ook het moment om per taak te splitsen.

8.6.2.2. Afweging: het model voor de titel
Optie Voordelen Nadelen
**Florence-2-base plus een vertaalmodel** (gekozen) MIT; 0,23 miljard parameters, dus bescheiden geheugen; onderschrijven is precies waarvoor het model gemaakt is; het vertaalmodel (opus-mt-en-nl) is ongeveer 300 MB en klaar binnen een seconde; twee kleine, voorspelbare stappen die los te beproeven zijn Twee modellen in plaats van één; gemeten 3,7 seconde per foto op onze machine (de schatting was vijf tot tien); de vertaalstap voegt een foutbron toe en Engelse woordvolgorde schemert soms door
Florence-2-large Merkbaar betere onderschriften, vooral op rommelige historische foto’s 0,77 miljard parameters en ongeveer drie keer zo traag; op onze machine tegen de dertig seconden per foto
Een meertalig VLM zoals Qwen2.5-VL Praat direct Nederlands, dus geen vertaalstap; kan in één prompt titel, categorie én steekwoorden geven Fors trager en zwaarder zonder videokaart; een generatief model verzint eerder details die niet op de foto staan, en bij erfgoed is een verzonnen detail schadelijker dan een ontbrekend
BLIP of BLIP-2 Beproefd en veel gebruikt, ruime documentatie Ouder; kortere en vlakkere onderschriften; nog steeds Engels, dus de vertaalstap blijft
Geen titelsuggestie Nul risico op verzonnen tekst; de inzender weet zelf wat erop staat Het lege titelveld is juist de plek waar mensen afhaken of "scan001" invullen

Besluit. Florence-2-base met een vertaalstap. Een onderschrift is nog geen titel, dus er gaat een korte regel overheen die "een zwart-witfoto van een winkelpui met een uithangbord" terugbrengt tot "Winkelpui met uithangbord". De prijs is de vertaalstap en de wachttijd, en die valt weg achter het invullen van stap 2.

Herzien wanneer. Er een klein meertalig model verschijnt dat op enkel CPU binnen een paar seconden Nederlands onderschrijft; dan vervalt de vertaalstap.

Gemeten les bij het inrichten. Meer rekenkernen maakte de dienst dramatisch tráger: dezelfde foto kostte 3,7 seconde met zes threads, 4,5 met acht, twintig met twaalf en drieënvijftig met vierentwintig. PyTorch pakt standaard de helft van de kernen en zit daarmee ver in het verkeerde gebied, zeker op een machine die de rest van de stack ook draait. Het aantal threads is daarom instelbaar en staat op zes; op een andere machine ligt het optimum elders en moet het opnieuw gemeten worden.

8.6.2.3. Afweging: het model voor de categorie

De categorie is een keuze uit zeven vaste waarden (foto, menukaart, advertentie, folder, krantenartikel, vergunning, overig). Dat is het schoolvoorbeeld van zero-shot-classificatie: je geeft het model de kandidaatlabels als tekst en het kiest de best passende.

Optie Voordelen Nadelen
**SigLIP 2 base zero-shot** (gekozen) Apache-2.0; 0,4 miljard parameters; meertalig, dus Nederlandse labels werken direct zonder vertaling; onder de seconde per foto; dezelfde modelfamilie doet ook de steekwoorden, dus één set gewichten voor twee taken De labels moeten zorgvuldig geformuleerd worden ("een menukaart van een restaurant" werkt beter dan "menukaart"); folder en advertentie lijken op elkaar en worden matig onderscheiden
CLIP (ViT-L/14) De bekendste; veel voorbeeldcode en artikelen Engelstalige tekstencoder, dus de labels moeten vertaald; ouder en zwakker op zero-shot dan SigLIP 2
RAKE op de tekst Licht, geen model nodig, geen rekentijd Werkt hier niet: RAKE haalt sleutelwoorden uit tekst, en een geüploade foto bevat geen tekst. Het levert bovendien losse woorden op, geen keuze uit zeven categorieën
Een eigen getraind classificatiemodel Het scherpst op precies deze zeven categorieën Vraagt een gelabelde verzameling die er niet is, en onderhoud bij elke wijziging van de lijst

Besluit. SigLIP 2 zero-shot met Nederlandse labels. Onder een drempel stellen we niets voor, en "overig" is nooit een suggestie: dat brengt niemand verder.

RAKE valt hier af omdat er geen tekst is, maar krijgt later wél een zinnige plek: op de beschrijving die de inzender zelf typt, en op getranscribeerde tekst van een menukaart of krantenartikel zodra transcriptie bestaat. Dan is er tekst om uit te putten.

Herzien wanneer. De verwarring tussen folder en advertentie in de praktijk hindert; dan is een fijnmaziger labelformulering of een klein bijgetraind model de volgende stap.

8.6.2.4. Afweging: de bron van de steekwoorden
Optie Voordelen Nadelen
SigLIP 2 tegen een woordenlijst met term-URI’s (gekozen) De voorstellen dragen meteen een term-URI, precies wat schema:about en schema:keywords willen; hetzelfde model als bij de categorie, dus geen extra gewichten; de lijst is per project in te perken, net als de terminologiebronnen nu al Wat niet in de lijst staat wordt nooit voorgesteld; de lijst moet samengesteld en onderhouden worden
Vrije labels uit het beeldmodel Breder bereik, geen lijst nodig Engels en zonder URI; de labels zijn bovendien algemeen ("building", "person") waar erfgoed juist om specifieke termen vraagt
Kandidaten opvragen bij het Termennetwerk Altijd actueel, geen eigen lijst te onderhouden Het Termennetwerk zoekt op tekst, niet op beeld; er is dus eerst een zoekterm nodig, en die is er op dat moment nog niet
Geen steekwoordsuggesties Geen risico op verkeerde termen in de open data Steekwoorden maken een foto vindbaar, en met de hand doet bijna niemand het

Besluit. Zero-shot scoren tegen een lijst erfgoedtermen en de drie tot vijf best scorende voorstellen, boven een drempel. Zero-shot heeft hoe dan ook een kandidatenlijst nodig, en dat komt hier goed uit: de RDF wil term-URI’s en geen losse woorden. De inzender kan altijd zelf typen; de bestaande term-zoeker levert dan alsnog een URI.

Herzien wanneer. De woordenlijst te krap blijkt voor een project met een ander onderwerp; de lijst is dan per project uit te breiden zonder de dienst te wijzigen.

8.6.3. Digitale restauratie en inkleuring (niet in MVP)

Het toevoegen van een digitaal ingekleurde of herstelde variant van een beschadigde of zwart-witfoto als secundaire weergave.

Call-to-action: "Bekijk deze foto in kleur." (weergave-optie, geen invoer van de gebruiker)

Techniek/standaard: de variant is een afgeleide (nooit het origineel vervangend), aangeboden als IIIF Choice op hetzelfde canvas; herkomst en methode worden vastgelegd. De ingekleurde of gerestaureerde weergave krijgt in de viewer een zichtbaar AI-label ("Deze weergave is met AI bewerkt"), conform de transparantieverplichting voor AI-gegenereerde en AI-bewerkte beelden uit de AI Act (Verordening (EU) 2024/1689, art. 50); het label wordt ook als metadata bij de afgeleide vastgelegd, zodat het bij hergebruik en in de API’s behouden blijft. Impact: hoog (beeldpipeline).

Als Web Annotation (variant als painting-alternatief op het canvas):

{
  "type": "Annotation",
  "motivation": "painting",
  "target": "https://iiif.iotm.nl/jottem/{id}/canvas/1",
  "body": {
    "type": "Choice",
    "items": [
      { "type": "Image", "id": "https://iiif.iotm.nl/{origineel}/full/max/0/default.jpg" },
      { "type": "Image", "id": "https://iiif.iotm.nl/{ingekleurd}/full/max/0/default.jpg" }
    ]
  }
}

8.7. Collectievorming en community-validatie

8.7.1. Feitencontrole en moderatie door de gemeenschap (niet in MVP)

Het controleren, aanvullen en goedkeuren van ingevoerde metadata door medegebruikers of moderatoren.

Call-to-action: "Klopt deze informatie? Bevestig het of stel een verbetering voor."

Techniek/standaard: motivation assessing op een bestaande annotatie of op de metadata; bevestigingen tellen op tot een betrouwbaarheidsindicatie. De reguliere moderatie door moderatoren en de meldingenflow bestaan al in de MVP; dit betreft de bredere community-validatie. Impact: middel.

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "assessing",
  "target": "https://anno.iotm.nl/annotation/{bestaande-annotatie}",
  "body": {
    "type": "TextualBody",
    "purpose": "assessing",
    "value": "Klopt, zie de bouwvergunning uit 1972."
  }
}

8.7.2. Thematische collecties en favorieten (niet in MVP)

Het groeperen van verrijkte afbeeldingen in openbare thema-albums (bijvoorbeeld "Verdwenen ijssalons" of "Gevelstenen") of persoonlijke favorietenlijsten. Persoonlijke favorieten met openbare deellink bestaan al in de MVP; de openbare thema-albums zijn de uitbreiding.

Call-to-action: "Mooi gevonden? Bewaar deze foto in je eigen lijst." en "Maak je eigen album over een onderwerp dat jou raakt."

Techniek/standaard: favorieten via het bestaande Favoriet-model; thema-albums als IIIF Collection met eigen pagina; opname in een album als bookmarking-annotatie. Impact: middel (albumbeheer-UI).

Als Web Annotation:

{
  "type": "Annotation",
  "motivation": "bookmarking",
  "target": "https://www.iotm.nl/jottem/{id}",
  "body": {
    "type": "TextualBody",
    "purpose": "tagging",
    "value": "Album: Verdwenen ijssalons"
  }
}

8.8. Instelbaar per project

De organisatiebeheerder bepaalt per project welke verrijkingsmogelijkheden beschikbaar zijn, net zoals de terminologiebronnen per project worden ingesteld. Alleen ingeschakelde verrijkingen tonen hun call-to-action op de jottem-pagina; de rest blijft verborgen. Zo kan een fotoproject inzetten op herinneringen en identificatie, en een documentenproject op transcriptie en begrippenverklaring, zonder gebruikers te overladen met knoppen.

8.9. Aanvullende requirements

*Status (augustus 2026): de MVP-verrijkingen uit dit hoofdstuk zijn gerealiseerd, inclusief V-1 t/m V-4, V-7, V-8 en V-9 (per project instelbaar, CTA’s op de jottem-pagina, W3C-opslag in AnnoRepo, jottem:aard, meldingen/moderatie, de eigen JSON-LD-context /ns/jottem.jsonld en de koppeling tussen twee jottems). Het uploadformulier loopt sinds augustus 2026 in twee stappen en vult bij een beeldbank-permalink titel, beschrijving, datering en vervaardiger voor uit het IIIF-manifest; de suggestiedienst uit § 8.6.2 Suggesties bij het uploaden volgt daarna. V-5, V-6 en V-10 blijven van kracht voor de fase 2-verrijkingen.*

9. Deelbaarheid

Jottem leeft niet alleen op het platform zelf. De gemeenschap zit op sociale media, op de website van de historische vereniging, in nieuwsbrieven en op buurtplatforms. Dit hoofdstuk beschrijft hoe jottems en projecten buiten het platform zichtbaar en deelbaar zijn, met als doel de participatie via andere websites en platforms te bevorderen. De keten is steeds dezelfde: iemand ziet een jottem of project op een ander kanaal, klikt door naar het platform en draagt bij via de verrijkingsmogelijkheden uit § 8 Verrijkingen. De deel-nudge in de publicatiemail (zie § 11 Notificaties) en de open data-uitgangen (RSS, IIIF; zie data-architectuur) zijn onderdelen van dezelfde beweging: het platform brengt de inhoud naar de mensen toe, niet andersom.

9.1. Social login

Wie via een ander kanaal binnenkomt, moet zonder drempel kunnen meedoen. Daarom is inloggen laagdrempelig, inclusief social login via federatie: in de MVP Google, Microsoft en Facebook; Apple en Instagram volgen in fase 2 vanwege de aanvraag- en reviewdoorlooptijd. Authentik doet uitsluitend authenticatie; rollen komen uit de database. Zie de systeemarchitectuur voor de inrichting. Status (augustus 2026): gerealiseerd.

9.2. Deelknoppen en Open Graph

Elke gepubliceerde jottem-pagina heeft een Delen-knop die het deelmenu van het apparaat opent via de Web Share API, en elke publiekspagina draagt Open Graph-metadata zodat een gedeelde link een nette preview toont. De volledige uitwerking (knopplaatsing, OG-elementen en hun bronnen, canonical-beleid) staat in de data-architectuur. Status (augustus 2026): gerealiseerd.

Nieuw in deze iteratie: de og:title en de Web Share-deeltekst van een jottem gebruiken niet langer de vaste oproep "weet jij hier meer van?", maar een willekeurige, binnen het project actieve verrijkings-call-to-action uit § 8 Verrijkingen. Een gedeelde link vraagt zo meteen om een concrete bijdrage ("Weet je wanneer dit was? Vul het jaartal in, ook een gok helpt.") en varieert per deelmoment, wat de kans vergroot dat één van de oproepen de ontvanger raakt. Heeft een project geen actieve verrijkingen, dan valt de titel terug op de vaste oproep.

9.3. Widgets

Organisaties willen hun Jottem-project tonen op de eigen website: de historische vereniging op haar WordPress-site, het archief op de collectiepagina. Daarvoor levert het platform widgets: dynamisch gegenereerde, zelfstandige HTML-fragmenten die met een iframe of een klein script worden ingebed.

Widget URI-patroon Inhoud
Projectinfo https://www.iotm.nl/widget/{organisatieSlug}/{projectSlug} logo, titel en beschrijving/oproep van het project, de algemene oproep "Help mee op Jottem" met het Jottem-beeldmerk, en een link naar de projectpagina
Recente jottems https://www.iotm.nl/widget/{organisatieSlug}/{projectSlug}/recent/{n} de {n} meest recent gepubliceerde jottems als thumbnails naast elkaar, elk een link naar de jottem-pagina; eronder een willekeurige actieve verrijkings-call-to-action met link naar de projectpagina
Willekeurige jottems https://www.iotm.nl/widget/{organisatieSlug}/{projectSlug}/willekeurig/{n} als hierboven, maar {n} willekeurig gekozen gepubliceerde jottems; elke weergave toont andere beelden, wat de widget levend houdt

Het aantal {n} is begrensd op 1 tot en met 12; daarbuiten weigert de route. Alleen goedgekeurde (gepubliceerde) jottems verschijnen in de widgets.

9.3.1. Vormgeving en gedrag

9.3.2. Inbedden

Twee inbedvormen, allebei met voorbeeldcode in het projectbeheer:

Iframe: werkt overal waar HTML mag, ook in het "Aangepaste HTML"-blok van WordPress en in de meeste andere CMS’en. De widget-routes sturen daarvoor géén X-Frame-Options en een Content Security Policy met frame-ancestors *; de rest van het platform blijft frame-ancestors 'none' sturen.

<iframe src="https://www.iotm.nl/widget/samh/smaak-van-gouda/recent/3"
        style="width:100%; height:220px; border:0" title="Jottem: Smaak van Gouda"></iframe>

Script: een klein laadscript (widget.js) haalt dezelfde HTML op en plaatst die direct in de pagina, zodat de widget het lettertype en de kleuren van de site zelf erft. De widget-routes sturen daarvoor Access-Control-Allow-Origin: *.

<div id="jottem-widget"></div>
<script async src="https://www.iotm.nl/widget.js"
        data-doel="#jottem-widget"
        data-src="https://www.iotm.nl/widget/samh/smaak-van-gouda/recent/3"></script>

Voor WordPress is het iframe de eenvoudigste route (plakken in een "Aangepaste HTML"-blok); het script is het mooiste resultaat op sites die externe scripts toestaan. Een eigen WordPress-plugin of Gutenberg-block is bewust géén onderdeel van het ontwerp: het "Aangepaste HTML"-blok volstaat, en met het oEmbed-endpoint uit § 9.5 Fase 2 wordt zelfs dat plakken van code overbodig.

9.3.3. Widgetlinks in het projectbeheer

De organisatiebeheerder ziet op de projectbeheerpagina een blok Widgets met de drie widget-URL’s, de voorbeeldcode voor beide inbedvormen (kopieerbaar) en een levend voorbeeld van de widgets, zodat de beheerder zonder technische hulp de code op de eigen site kan plakken.

9.4. oEmbed

Platforms met oEmbed-ondersteuning (WordPress, Mastodon, diverse CMS’en) tonen een geplakte Jottem-URL automatisch als embed; plakken van voorbeeldcode is dan niet nodig. Het endpoint is GET /oembed op de publiekssite, en elke project- en jottem-pagina draagt een discovery-link (<link rel="alternate" type="application/json+oembed" href="…">) zodat consumers het endpoint zelf vinden. Status (augustus 2026): gerealiseerd.

Parameter Betekenis
url de geplakte pagina-URL; alleen project- en jottem-pagina’s van het platform zelf, anders 404
format alleen json; xml geeft 501 (toegestaan volgens de spec voor een niet-ondersteund formaat)
maxwidth, maxheight bovengrens die de consumer meegeeft; het antwoord blijft eronder

Het antwoord hangt af van het soort URL:

9.5. Fase 2

9.6. Aanvullende requirements

Status (augustus 2026): social login en deelknoppen/Open Graph waren al gerealiseerd; D-1 t/m D-7 zijn in de huidige iteratie gerealiseerd, D-8 is fase 2.

10. Acceptatiecriteria

Per usecase (zie § 7 Usecases per rol) de testbare criteria voor oplevering; ze vormen de basis voor de end-to-end-testsuite uit de systeemarchitectuur en de livegang-criteria in het § 16 Realisatieplan. De niet-functionele eisen (§ 6.2 Niet-functionele requirements) gelden daarbovenop voor alle schermen en API’s. Criteria bij fase 2-functionaliteit zijn gemarkeerd met (fase 2).

10.1. Platformbeheerder

10.2. Organisatiebeheerder

10.3. Moderator

10.4. Gebruiker

10.5. Uploader

10.6. Annoteerder

10.7. API-gebruiker

10.8. Bezoeker

11. Notificaties

Alle notificatiemails op een rij: trigger, ontvanger en doel. Mails worden asynchroon verstuurd door de Celery-workers via de eigen mailserver (MTA, zie de systeemarchitectuur en § 11.5 Afleverbaarheid), zijn Nederlandstalig en dragen de huisstijl (logo, kleuren) van de betreffende organisatiejottem.

11.1. Overzicht

# Trigger Ontvanger Inhoud / doel
1 Platformbeheerder voegt een organisatiebeheerder toe uitgenodigde spelregels + bevestigingslink naar de Authentik-enrollment (wachtwoord + verplichte 2FA: TOTP of passkey); de klaargezette rol wordt bij eerste login gekoppeld
2 Organisatiebeheerder voegt een moderator toe uitgenodigde idem als 1
3 Moderator keurt een jottem goed uploader "je jottem staat online": duurzame link + oproep om te delen via sociale media (reacties en annotaties uitlokken)
4 Moderator keurt een jottem af uploader afkeurreden + directe link om de jottem aan te passen en opnieuw in te dienen
5 Er staan jottems in de moderatiewachtrij en/of er zijn onafgehandelde meldingen op annotaties/reacties moderatoren van de organisatie dagelijkse samenvatting (alleen verstuurd als er iets wacht) - voorkomt mail per upload of melding
6 Verwijderverzoek ingediend indiener ontvangstbevestiging + verwachte afhandeltermijn (30 dagen, zie de niet-functionele requirements)
7 Verwijderverzoek ingediend moderatoren van de organisatie directe melding (juridische termijn loopt) met link naar de afhandelpagina
8 Verwijderverzoek afgehandeld indiener uitkomst: gehonoreerd (jottem gedepubliceerd) of afgewezen met toelichting
9 E-depot-export gereed organisatiebeheerder (aanvrager) directe downloadlink naar het BagIt-pakket + de beperkte bewaartermijn
10 Nieuwe annotatie of reactie op jouw jottem uploader instelbaar in het profiel (standaard aan); gebundeld tot maximaal één mail per dag
11 Reactie op jouw annotatie annoteerder instelbaar in het profiel (standaard aan); gebundeld tot maximaal één mail per dag

11.2. Afbakening

11.3. Templates

Alle mails zijn template-gebaseerd; de sjablonen leven in het monorepo onder api/templates/mail/ zodat ze onder versiebeheer en review vallen. Per notificatie zijn er drie sjablonen:

Bestand Rol
nl/<slug>.mjml de HTML-mail, geschreven in MJML - een buildstap (MJML-CLI) compileert dit naar robuuste, responsive e-mail-HTML in dist/ (gegenereerd, niet in git)
nl/<slug>.subject.j2 de onderwerpregel
nl/<slug>.txt.j2 de platte-tekstversie

De mailworker vult de sjablonen met Jinja2 en verstuurt ze als multipart/alternative (HTML + tekst - beste afleverbaarheid en toegankelijkheid). Gedeelde partials leveren de kop (logo en kleur van de organisatiejottem) en de voet; de voet toont automatisch een uitschakellink wanneer uitschakelUrl is meegegeven (attenderingen 10 en 11). Variabelenconventie: organisatie.* (naam, logoUrl, kleurPrimair), ontvangerNaam, en …Url voor alle links; de variabelen per template staan gedocumenteerd in de README bij de sjablonen. De mapstructuur is per taal (nl/), zodat meertaligheid later zonder verbouwing kan.

11.4. Regels

11.5. Afleverbaarheid

Mail heeft alleen waarde als hij aankomt, en aankomen blíjft. De grote providers (Gmail, Yahoo, Microsoft) handhaven sinds 2024-2026 harde afzendereisen; onderstaande maatregelen zorgen dat Jottem-mail daaraan voldoet en een goede verzendreputatie opbouwt en behoudt.

*Status (augustus 2026): de ontwikkelomgeving verstuurt echt, via een bestaande exim-relay met gevestigde reputatie (SPF, DKIM met een 2048-bit sleutel op selector jottem, DMARC p=none met rapportage, kloppende PTR/HELO); de attenderingsmails dragen de RFC 8058-headers. De eigen MTA in de stack blijft het productiedoel hieronder; bouncebeheer en DMARC-aanscherping volgen richting livegang.*

Authenticatie (verplicht). Op het verzenddomein staan drie DNS-records ingeregeld:

Daarnaast: een kloppende reverse DNS (PTR-record) op het verzendende IP, een HELO-naam die daarmee consistent is, en TLS op de verzendverbinding.

Makkelijk uitschrijven. Wie een attenderingsmail (10, 11) niet meer wil, moet er zonder moeite vanaf kunnen; anders wordt de spamknop het uitschrijfmechanisme en die klachten beschadigen de reputatie van het hele platform. Daarom dragen attenderingsmails naast de uitschakellink in de voettekst de headers List-Unsubscribe (mailto én https) en List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058), zodat mailclients een eigen "Uitschrijven"-knop tonen. Uitschrijven werkt direct en zonder inloggen (de uitschakellink bevat een token) en wordt binnen 48 uur verwerkt (in de praktijk: meteen). Transactionele mails (1 t/m 9) vallen hier bewust buiten; die horen bij een handeling van de gebruiker zelf.

Verzendroute: eigen MTA. De platformmail loopt via een eigen MTA (Postfix met DKIM-ondertekening, bijv. via rspamd of OpenDKIM) als container in de stack; een externe (betaalde) verzenddienst is op deze schaal niet nodig. Randvoorwaarden: een vast IPv4-adres met instelbare PTR, uitgaande poort 25 open bij de hostingprovider, en consistente HELO-/PTR-/A-records.

Reputatie. Het platform schrijft alleen geverifieerde adressen aan (e-mailverificatie bij registratie is al verplicht). Bounces worden verwerkt: hard bounces gaan op een suppressielijst en worden niet opnieuw aangeschreven. Bij livegang wordt het volume rustig opgebouwd in plaats van in één keer bulk te versturen. De attenderingen zijn gebundeld tot maximaal één mail per dag (zie het overzicht), wat het volume en de irritatie laag houdt.

Monitoring. De DMARC-rapporten (rua) worden periodiek bekeken; het platform is aangemeld bij Google Postmaster Tools en Microsoft SNDS/JMRP zodat reputatie en spamklachtratio zichtbaar zijn. De spamklachtratio blijft onder de 0,3% (de harde grens van de grote providers), met minder dan 0,1% als streefwaarde. De adressen postmaster@ en abuse@ op het verzenddomein bestaan en worden gelezen (RFC 2142).

12. Infrastructuurkeuze

13. Keuze oplossingsrichting

Dit document legt de gekozen oplossingsrichting en technologiestack vast en is het resultaat van de deelactiviteit "Keuze oplossingsrichting" uit het § 3 Activiteitenplan. Het bouwt voort op de analyse van vier infrastructuurrichtingen en de systeemarchitectuur. Status: concept, augustus 2026 - vast te stellen door de projectgroep.

13.1. Infrastructuurrichting: alles op de Jottem-server

Van de vier onderzochte richtingen (Wikimedia, Internet Archive, e-Depot, eigen server) is gekozen voor richting 4: alles op de Jottem-server - afbeeldingen, metadata en annotaties in één geïntegreerd systeem in eigen beheer.

Onderbouwing:

Beheersmaatregelen - de analyse benoemt duurzaamheid als zwakte van deze richting; die wordt als volgt ondervangen:

13.2. Besliste openstaande ontwerpvragen

ARK: uitgesteld naar een latere fase. De MVP mint geen ARK’s. Elke gepubliceerde jottem krijgt een duurzame platform-URL (met content negotiation naar HTML en RDF, zoals in § 6.1 Functionele requirements). Het subdomein ark.iotm.nl blijft gereserveerd; een NAAN-aanvraag, minter en resolver volgen zodra ARK wordt geactiveerd. URL’s worden zo gekozen dat latere ARK-koppeling zonder linkbreuk kan.

Annotaties: bewerken en verwijderen door de annoteerder zelf. Annoteerders kunnen hun eigen annotaties bewerken én verwijderen. De versiegeschiedenis wordt met volledige payload vastgelegd in het Gebeurtenislog van het platform, zodat herinneringen, aanvullingen en correcties herleidbaar blijven.

13.3. Technologiestack

Per component is uit de in de systeemarchitectuur genoemde kandidaten de volgende keuze gemaakt:

Component Keuze
Webfrontend (www.iotm.nl) Next.js (React) met OpenSeadragon/Mirador (IIIF-viewer), Annotorious (annoteren) en MapLibre GL (kaart)
Backend-API (api.iotm.nl) FastAPI (Python) met iiif-prezi3
Async workers Celery met Valkey als broker
Identity provider (auth.iotm.nl) Authentik (OIDC, social login, 2FA via TOTP of passkey/WebAuthn) - afwijkend van de architectuursuggestie (Keycloak): lichter in beheer bij gelijkwaardige functionaliteit (identity brokering, 2FA-afdwinging per rol, uitnodigingsflows)
IIIF Image API (iiif.iotm.nl) Cantaloupe achter Varnish
Annotatieserver (anno.iotm.nl) AnnoRepo (KNAW HuC) met MongoDB - *afwijkend van de architectuursuggestie (miiify): dat is read-only geworden, zie de afweging in de systeemarchitectuur*
RDF-publicatie (data.iotm.nl) Apache Jena Fuseki
Zoekmachine Elasticsearch
Relationele database PostgreSQL
Cache en taakwachtrij Valkey - afwijkend van de architectuursuggestie (Redis): drop-in compatibel, maar volledig open source (Linux Foundation)
Mediaopslag (S3) Externe Object Storage (S3) - herziene keuze (aug 2026): extern in plaats van zelf-gehost MinIO; geen eigen opslagbeheer en de opslag groeit mee zonder serverwijziging. Alle componenten spreken S3, dus MinIO blijft het zelf-gehoste alternatief; de leverancierskeuze is een exploitatiebesluit en blijft buiten het ontwerp
Suggesties bij het uploaden Suggesties API (eigen dienst: FastAPI + Florence-2 + SigLIP 2), interne container, aangeroepen tussen de twee stappen van het uploadformulier; EUPL-1.2 want de modellen zijn permissief gelicentieerd
Detectie herkenbare personen Herkenbaar API (eigen dienst: FastAPI + YOLO-pose), interne container, synchroon aangeroepen door de backend bij upload
Reverse proxy, TLS Traefik
Monitoring, logging, alerting Prometheus, Grafana, Loki, Alertmanager (conform systeemarchitectuur)
ARK-resolver (ark.iotm.nl) vervalt in de MVP - latere fase, zie § 13.2 Besliste openstaande ontwerpvragen

13.4. Open source: licenties en repostructuur

De salespitch belooft open source; de volgende besluiten maken dat concreet (augustus 2026):

Samengevat, het licentiebeeld van het Jottem-ecosysteem:

Onderdeel Licentie
Platformcode (jottem) EUPL-1.2
Herkenbaar API AGPL-3.0
Ontwerpdocumenten (design) CC BY-SA 4.0
Prototype, website en merkgids CC BY 4.0
Lettertypes Fraunces en Albert Sans (huisstijl) SIL OFL 1.1

13.5. Consequenties voor de ontwerpdocumenten

14. Systeemarchitectuur

De systeemarchitectuur van Jottem beschrijft een op Docker gebaseerde systeemarchitectuur voor het Jottem-platform: een participatief digitaal erfgoedplatform waarin gebruikers media (jottems) uploaden, moderatoren deze beoordelen en publiceren, en annoteerders verrijkingen toevoegen. Het geheel wordt via subdomeinen onder iotm.nl ontsloten en implementeert de in het designdocument genoemde standaarden: IIIF Image API 3.0, IIIF Presentation API 3.0, IIIF Change Discovery, W3C Web Annotations, schema.org AP NDE, ARK en RSS.

Contextdiagram

(klik op bovenstaand contextdiagram voor het gehele architectuurdocument)

15. Data-architectuur

De data-architectuur van Jottem beschrijft het datamodel (ERD), de URI-strategie en alle data-outputs van het platform: IIIF (Image API v3, Presentation API v3, Change Discovery v1), W3C Web Annotations (incl. Annotation Protocol en Miifi API), RDF/datadump conform schema.org AP NDE met datasetbeschrijving conform de NDE-requirements, de publieke en beheer-API’s, RSS, vocabulaires en de zoekindex.

Per output bevat het document een veld→bron-tabel als outputcontrole: is alle data die aan de outputkant nodig is beschikbaar in de eerdere lagen (PostgreSQL, Object Storage, annotatieserver)? De daarbij gevonden hiaten zijn verwerkt in het ERD.

16. Realisatieplan

Dit plan bakent de MVP af en geeft de fasering richting de livegang van de pilot Smaak van Gouda: MVP live vóór eind 2026, fase 2 in het voorjaar van 2027. Het bouwt voort op het § 3.3.3 Keuze oplossingsrichting en de systeemarchitectuur en data-architectuur.

16.1. MVP-scope (livegang pilot, eind 2026)

De MVP omvat alles wat nodig is om de pilot van begin tot eind te laten draaien:

16.2. Fase 2 (voorjaar 2027)

Latere fase (reeds besloten in § 13.2 Besliste openstaande ontwerpvragen): ARK-minting/resolving, externe preserveringskopie (Internet Archive/e-depot), Wikimedia-doorzetting van de vrije subset, harde opslagquota per organisatie (MVP: monitoring met alerts).

16.3. Mijlpalen 2026

Periode Mijlpaal
september Fundament staat: docker-compose-stack op de ontwikkelomgeving (Authentik, PostgreSQL, Valkey, externe Object Storage (S3), backend-skelet), datamodel geïmplementeerd, upload→moderatie→publicatie-keten end-to-end werkend (kaal); huisstijl Jottem ontworpen en vastgesteld (zie § 16.5 Huisstijl Jottem-platform)
oktober Publieksomgeving: jottem-detailpagina met IIIF-viewer, annoteren met Termennetwerk, zoeken met facetten, kaart + pand-tijdlijn, huisstijl SAMH, Herkenbaar-integratie
november Open data & toetsing: IIIF/RSS/RDF-outputs, datasetbeschrijving + Datasetregister-validatie (NDE-compatibel), gebruikerssessie met SAMH-vrijwilligers, juridische toetsing gestart, alle notificatiemails werkend (zie § 11 Notificaties)
december Hardening & livegang: securitytoets, monitoring/back-ups aantoonbaar werkend, mail-afleverbaarheid ingeregeld (SPF/DKIM/DMARC, one-click unsubscribe, zie § 11.5 Afleverbaarheid), DPIA en juridische toetsing afgerond, moderatoren getraind, verzameldag/oproep → pilot live

16.4. Livegang-criteria

De pilot gaat live wanneer aantoonbaar:

  1. de kritieke keten (registratie → upload → moderatie → publicatie → annotatie → zoeken) end-to-end werkt en de § 10 Acceptatiecriteria van de MVP-usecases zijn aangetoond, incl. de e2e-test uit de systeemarchitectuur;

  2. de outputcontrole uit de data-architectuur klopt en de datasetbeschrijving valideert tegen het NDE Datasetregister;

  3. de juridische documenten door een jurist zijn getoetst en de DPIA is afgerond;

  4. moderatie is ingericht (getrainde moderatoren, handreiking);

  5. back-ups, monitoring en alerting draaien en de hersteltest is uitgevoerd;

  6. SPF, DKIM en DMARC staan op het productie-verzenddomein en een testmail bereikt de inbox van de grote providers (Gmail, Outlook) zonder spammarkering (zie § 11.5 Afleverbaarheid).

16.5. Huisstijl Jottem-platform

Naast de huisstijl per organisatiejottem (logo, kleurenpalet, favicon op Organisatie) heeft het platform zelf een huisstijl. Die is uitgewerkt in de merkgids op brand.iotm.nl, met de projectgroep vast te stellen in de septembermijlpaal. De merkgids omvat:

Jottem-woordmerk

16.6. Openstaand ontwerp tijdens de bouw

Uit de gap-analyse resteert ontwerpwerk dat ter voorbereiding op fase 2 wordt opgepakt: de interfacebeschrijving van de tijdmachine-koppeling en de uitwerking van de IIIF-import. De huisstijl van het platform is uitgewerkt in de merkgids en wacht op vaststelling door de projectgroep (§ 16.5 Huisstijl Jottem-platform, septembermijlpaal). Het notificatie-overzicht (§ 11 Notificaties) en de acceptatiecriteria per usecase (§ 10 Acceptatiecriteria) zijn uitgewerkt. De open-sourcelicenties en repostructuur zijn inmiddels besloten, zie § 13.4 Open source: licenties en repostructuur: EUPL-1.2 voor de platformcode in het monorepo jottem, AGPL-3.0 voor de Herkenbaar API, CC BY-SA 4.0 voor de ontwerpdocumenten (design-repo) en CC BY 4.0 voor de overige documentatie (prototype, website, brand).

17. Juridisch

Een platform als Jottem levert risico’s op en dient te voldoen aan (inter)nationale wet- en regelgeving. Een eerste overzicht hiervan is opgenomen in het document Risico’s en wet- en regelgeving.

De voornoemde documenten en de volgende documenten dienen om de risico’s te beheersen.

Ter verantwoording (AVG) horen daar de volgende documenten bij:

Let op: alle concept documenten zijn gemaakt door een niet-jurist en dienen we vóór gebruik te laten controleren door een jurist.