Van informatieautonomie tot AI-bevraagbare archieven: een persoonlijke reis langs Markdown, Obsidian en chatbot-gedreven automatisering

Dit is een verslag van experimenten met mijn eigen informatieverzamelingen — e-mail, stripboeken, reisverslagen, chatgeschiedenis — om te zien wat mogelijk is wanneer je data bevrijdt uit platformen en converteert naar open, doorzoekbare formaten. Het is ook een verkenning van een nieuwe werkwijze waarbij je het functioneel ontwerp en plan met één chatbot maakt, en een andere AI het laat uitvoeren.

Het kernidee is simpel: leveranciersonafhankelijkheid begint bij platte tekst. Markdown is de kleinste gemene deler — weinig opslagruimte, mens-leesbaar, machine-leesbaar, en overal te openen. Obsidian is de toegangspoort. De chatbots doen het hand-en-span werk.

De pijlers van het systeem

Wat is Markdown?

Markdown (.md) is platte tekst met een paar simpele leestekens voor opmaak — een hashtag voor een kop, sterretjes voor vet of cursief. Omdat het gewoon leesbare tekst is, heb je geen speciaal programma nodig om een Markdown-bestand te openen: elke computer kan het lezen en dit maakt het een uitermate duurzaam formaat. Vergelijk dat met .wps, het bestandsformaat van het oude Microsoft Works (de kleine broer van Word uit de jaren 1990/2000). Works is al lang gestopt en moderne versies van Word/Office kunnen dit soort bestanden niet meer zomaar openen — je hebt er een los conversieprogramma of een oude installatie voor nodig. Markdown loopt dat risico niet: het bestand ís de inhoud, zonder tussenlaag die kan verouderen.

Dat verschil zie je ook meteen terug in de bestandsgrootte. Voor een vergelijkbaar document van een paar pagina's tekst geldt ruwweg:

Dus: Markdown is ongeveer 4× kleiner dan DOCX en 16–20× kleiner dan PDF.

Waarom Obsidian?

Obsidian is een lokaal draaiende kennismanagementtool die Markdown-bestanden leest en doorzoekbaar maakt. Geen cloud, geen vendor-lock-in, geen database — gewoon bestanden op je eigen schijf. Het is populair geworden omdat het meerdere hoekstenen combineert:

• Volledige lokale controle — je bestanden staan op jouw apparaat, niet op een server van een techbedrijf.

• Bestandsformaat — Obsidian slaat elke notitie op als een Markdown-bestand. Alle voordelen die ik net beschreef — leesbaar zonder speciale software, toekomstbestendig — gelden dus direct voor je eigen notities. Voor het toevoegen van metadata -'eigenschappen' in Obsidian- wordt YAML-frontmatter gebruikt, een methode om gestructureerde metadata bovenaan een Markdown-bestand op te slaan.

• Export en overstappen — omdat je notities gewoon Markdown-bestanden in een map zijn, is er nooit een aparte exportstap nodig: kopieer de map en je bent klaar. Vergelijk dat met Evernote, waar je wel kunt exporteren, maar dan in Evernotes eigen bestandsformaat, dat eerst weer omgezet moet worden voordat een andere app er iets mee kan. Bij OneNote is het nog lastiger: er is geen manier om je notities in een open, bruikbaar formaat te exporteren — je krijgt losse pagina's, of een back-upbestand dat alleen weer door OneNote zelf te openen is. Je zit dus vast aan het platform waarin je begonnen bent.

• Koppelen notities en tags — je kunt tags toevoegen aan notities en notities ook eenvoudig aan elkaar koppelen. In de graph view zie je al die koppelingen als lijntjes tussen bolletjes (jouw notities) — een netwerk waarin je verbanden ontdekt die je zelf nooit had gezien.

• Sjablonen — je kunt vaste sjablonen maken voor terugkerende notities, zoals een vergaderverslag of een boekrecensie, zodat je niet telkens opnieuw dezelfde structuur hoeft te typen. De ingebouwde Templates-functie doet dit al, en de plugin Templater breidt dit uit met bijvoorbeeld een automatisch ingevulde datum of een vraag die je invult op het moment dat je de notitie aanmaakt.

• Plug-in-ecosysteem — met plug-ins (gebouwd door de community van Obsidian en gratis beschikbaar) zoals Dataview (bouwt automatisch een actuele tabel, bijvoorbeeld van alle gelezen boeken met beoordeling) en Tag Wrangler (hernoemt een label in één keer door je hele archief heen) is de functionaliteit eenvoudig en geheel naar wens uit te breiden.

De andere gereedschappen

Naast Obsidian vormen een paar andere tools het ecosysteem. Ter vergelijking: een vergelijkbaar ecosysteem gebouwd op de gangbare Big Tech-diensten heeft zijn eigen licentiekosten, die niet per se hoger liggen dan hier. Het verschil zit eerder in wat minder zichtbaar is: de opslag die oploopt door zwaardere, gesloten bestandsformaten, en de tijd, moeite en risico's van een conversie of migratie zodra een leverancier iets wijzigt of een dienst stopzet. Die kosten staan zelden op een factuur, maar tellen wel mee.

Comfort vs controle

Het nadeel is reëel: je bent zelf verantwoordelijk voor je bestanden, back-ups en synchronisatie. Maar dat is precies ook de kracht.

Bij diensten zoals Microsoft 365 of SharePoint, en bij Google — beide platformen die ik zowel privé als zakelijk altijd heb gebruikt — denkt het platform voor je na: back-ups zijn automatisch, sync gebeurt in de cloud, herstel is ingebouwd. Dat is comfortabel, maar ook afhankelijk van Amerikaanse bedrijven die de tarieven eenzijdig kunnen verhogen, functies schrappen of aanpassen zonder jou te vragen, en waarbij je data onder Amerikaanse wetgeving valt (zoals de CLOUD Act). Bij Google komt daar nog iets bovenop: die dienst scant je gegevens voor advertentieprofielen.

Bij Obsidian draait het andersom. Je kiest zelf hoe je de back-up organiseert. In mijn geval: Proton Drive — een Zwitsers, end-to-end-versleutelde dienst als bewust Europees alternatief op Amerikaanse Big Tech. Geen datamining, geen advertentieprofielen, geen onverwachte tariefverhogingen. En als je wilt: Syncthing. Dit is een gratis, open-source programma waarmee je bestanden direct synchroniseert tussen jouw eigen apparaten (bijvoorbeeld laptop en telefoon) — zonder tussenkomst van een cloud provider.

Die keuzevrijheid vereist actie. Je moet zelf nadenken over je strategie en de setup. Maar daardoor word je eigenaar van je eigen gegevens: ze zijn op vele manieren te doorzoeken en te hergebruiken, en ze blijven toegankelijk ongeacht wat een bedrijf besluit — of dat nu een prijsverhoging is, een gestopte dienst, of een gewijzigd advertentiebeleid. Je bent geen gebruiker meer van een dienst die je data exploiteert, maar eigenaar van gegevens die je altijd zelf kunt meenemen. Dat is 'informatieautonomie'.

De reis: vier informatieverzamelingen

Project 1: Polarsteps → Obsidian + back-up

Probleem: Reisverslagen opgesloten in Polarsteps, afhankelijk van het platform en niet te combineren met verslagen van dezelfde reis die ik privé wilde houden.

Aanpak: Polarsteps exporteerde JSON-bestanden. Lumo schreef het Python-script. Dit script converteerde 169 reisverslagen naar een Markdown bestand per verslag (step), met foto's gekoppeld per step, genereerde YAML-metadata als eigenschappen in de MD bestanden: titel verslag, titel reis, datum verslag, locatie, land, latitude + longitude locatie, tags (handmatig in te vullen); waarmee je met plug-ins weer allerlei leuke dingen kunt doen.

Resultaat: Reisarchief in Obsidian, met inmiddels bijna alle digitale reisverslagen die ik ooit heb geschreven. Wie weet -ooit- de papieren reisdagboeken nog (ik zie mogelijkheden na Project 4).

Project 2: Gmail → lokaal doorzoekbaar archief

Probleem: wens om Gmail op te heffen, zonder voor vervuiling te zorgen in mijn nieuwe Proton mailbox, maar wel alle e-mail willen bewaren in een lokaal, doorzoekbaar archief

Aanpak: Google Takeout leverde een 2 GB MBOX-bestand. Lumo schreef het Python-script. Dit script pakte de 5239 e-mails uit, extraheerde metadata en ruim 2000 bijlagen, en zette elk bericht om naar Markdown met genereerde YAML-metadata (afzender, datum, labels, tags met o.a. de mappenstructuur, bijvoorbeeld 'reizen/vliegtickets') en met links naar de bijlagen. Een tweede script ordende alles per jaar in een Obsidian-kluis.

Resultaat: 5236 e-mails over een periode van 18 jaar verwerkt tot Markdown-bestanden, allemaal doorzoekbaar zonder internetverbinding. E-mail thread samengevoegd in één Markdown bestand (dit was een bewuste keuze), met bovenaan een index voor de afzonderlijke gesprekken. Bijlagen behouden in origineel formaat. Er was een uitval van drie e-mails. Deze bevatten technische fouten in hun opbouw — een onleesbare tekencodering en een ongebruikelijke metadatastructuur — waardoor het script ze niet kon vertalen.

Niet uitgevoerde optie: het laten opschonen van de e-mail op basis van regels. Dit had wel gekund, maar ik vond het lastig om de regels te formuleren en was bang voor onbedoeld informatieverlies. De mailbox was ook vanaf het begin met enige regelmaat opgeschoond van nieuwsbrieven en dergelijke, vandaar 'slechts' 5236 e-mails over een periode van 18 jaar. Voor een demo kluis in Obsidian heb ik wel, met Claude Chat & Cowork, op basis van regels een demoselectie gemaakt van de e-mails. Een handmatige controle om té persoonlijke e-mails eruit te filteren was nog wel noodzakelijk.

Project 3: ChatGPT-geschiedenis → Obsidian

Probleem: Wens om ChatGPT op te heffen (betaald account al in 2025 gestopt en overgestapt op Lumo van Proton). AI-conversaties opgesloten in ChatGPT's exportformaat (JSON), niet doorzoekbaar buiten het platform.

Aanpak: Export leverde 8 JSON-bestanden met 96 gesprekken. Lumo schreef het Python-script. Dit script sorteerde berichten chronologisch, genereerde YAML-metadata (startdatum, einddatum) en sloeg elk gesprek op als los Markdown-bestand.

Resultaat: Eén map in mijn persoonlijke Obsidian-kluis, handmatig te taggen en te koppelen aan andere notities zoals bijvoorbeeld boeken die ik over het onderwerp van de chat heb gelezen, doorzoekbaar met full-text search.

Niet uitgevoerde optie: Het script laten zoeken naar specifieke woorden in de chat-tekst en tags toe laten kennen op basis daarvan. Bijvoorbeeld: "reizen": "reis", "reizen", "vakantie", "vlucht", "hotel", "itinerary". De chats zijn al full-text doorzoekbaar. Voor een kleine 100 heb ik ervoor gekozen een handmatige opschoon- en tag actie te doen.

Project 4: 3000 stripboeken → digitaal archief

Probleem: Een fysieke collectie van 3000 albums. Moeten deels worden aangeboden voor de verkoop waarvoor ook een waarde-inschatting wenselijk is. Handmatig een digitale index maken kost ik-wil-niet-weten-hoeveel-tijd en is niet een hele leuke klus.

Aanpak: Per album twee foto's (cover + colofon) gemaakt met een Samsung telefoon (dit is uiteindelijk nog het meeste werk). Python-script stuurt deze naar de GPT-4o Vision API, die automatisch 11 metadata-velden uitleest (waarbij niet beschikbaar = leeg): serie, titel, nummer, auteur, jaartal, druk, uitgever, ISBN, taal, speciale uitgave, opmerkingen.

Resultaat: Per album een Markdown bestand in Obsidian met YAML-properties en ingesloten foto's, plus een CSV voor spreadsheet-gebruik. Test uitgevoerd met 140 album, makkelijk schaalbaar naar 3000. Op basis van het CSV bestand heb ik Lumo laten zoeken naar bedragen waarvoor de afzonderlijke stripboeken op veilingen e.d. zijn aangeboden.

Waarom Claude Code beter werkt dan alleen chatten

De doorbraak kwam toen ik na diverse tests voor project 4 overschakelde van chatbot-conversaties naar Claude Code. Het verschil is fundamenteel:

Bij een gewone chatbot schrijf je in je bericht wat je wilt, de bot genereert code, jij kopieert het naar een bestand, slaat het op, voert het uit, krijgt een foutmelding, plakt de foutmelding terug in de chat, en de cyclus herhaalt zich. Dit was langzaam en foutgevoelig, zeker op Windows waar paden, aanhalingstekens en command-interpreters (cmd vs. PowerShell) voor verwarring kunnen zorgen. Zowel Lumo als ik maakte af en toe fouten, die soms heel leerzaam waren, maar het hele proces wel frustrerend kunnen vertragen.

Claude Code draait in je terminal, leest je bestanden direct, schrijft wijzigingen ter plekke, voert scripts uit, ziet de output en corrigeert zichzelf — alles in één lus. Het is het verschil tussen een architect die tekeningen mailt en een architect die op de bouwplaats staat. Je geeft het functioneel ontwerp; Claude Code regelt de uitvoering én de feedback-loop.

Wat het werken erbij zorgvuldig maakt, is de manual modus: bij elke beslissing legt Claude Code concrete opties voor en wacht tot jij kiest hoe het verder moet gaan. Niets wordt zonder jouw goedkeuring uitgevoerd. Jij behoudt de regie.

Back-up en synchronisatie

Voor alle vier de archieven gold hetzelfde: Proton Drive was ingesteld voor automatische versleutelde back-up van de Obsidian-kluis, met Syncthing als peer-to-peer alternatief voor apparatuur synchronisatie zodat de kluizen, wanneer ik daarvoor kies, bijvoorbeeld ook beschikbaar zijn op mijn telefoon.

Wat het oplevert: AI-bevraging van je eigen archief

Het echte verschil met traditionele archieven is niet alleen dat je data lokaal staat — het is dat AI je archief kan bevragen. Een concreet voorbeeld: Claude Chat & Cowork doorzocht mijn Markdown Gmail-archief, vond alle vliegtickets, en construeerde automatisch een chronologisch overzicht van mijn vliegreizen. Dat kostte me enkele minuten.

Dat ging zo snel dankzij de kracht van platte tekst met gestructureerde metadata: elk AI-model dat tekst kan lezen, kan je archief bevragen. Platte tekst heeft namelijk geen vertaalslag nodig — een AI-model leest Markdown zoals het er staat, koppen, lijsten en tabellen zijn simpele tekens (#, -, |) die zowel ik als de machine meteen begrijpen. Bij een DOCX-bestand zit de tekst verpakt in een laag XML met opmaak, stijlen en documenteigenschappen; bij een PDF is het vaak niet meer dan losse tekstfragmenten met coördinaten op een pagina, zonder gegarandeerde leesvolgorde. Een AI moet die structuur eerst reconstrueren voordat het de inhoud kan interpreteren — en daarbij gaat weleens iets mis: tabellen die uit elkaar vallen, kolommen die door elkaar lopen, tekst die in de verkeerde volgorde wordt uitgelezen. Wat dan ontstaat lijkt op hallucinatie: de AI produceert zelfverzekerde antwoorden die feitelijk fout zijn, omdat het de bron verkeerd heeft gelezen. Markdown met YAML-frontmatter slaat die vertaalslag over: de metadata staat er al gestructureerd bij, klaar om direct bevraagd te worden. Dat elimineert hallucinatie niet volledig, maar neemt een belangrijke oorzaak weg.

Die betrouwbaarheid raakt aan iets fundamentelers dan techniek alleen: wie er in de praktijk mee kan werken, en wanneer. In een traditioneel archief hangt de vindbaarheid van een overzicht zoals mijn vliegtickets af van keuzes die ooit bij de ontsluiting zijn gemaakt: staat 'vliegticket' in het metadataschema, is het een trefwoord, bestaat de juiste toegang? Wie die specifieke vraag niet had voorzien op het moment van beschrijven, moet het antwoord alsnog handmatig samenstellen — dossier voor dossier, jaar voor jaar. Bij een AI-bevraagbaar platte-tekstarchief verschuift dat moment. De vraag hoeft niet voorzien te zijn bij het aanleggen van het archief; ze kan worden gesteld op het moment dat iemand haar nodig heeft, en het antwoord wordt dan ter plekke uit de brontekst gedestilleerd — niet uit een vooraf ingericht register.

Schaalbaarheid: wat werkt en wat breekt

De vier projecten variëren van 96 bestanden (ChatGPT) tot 5236 (Gmail) — bescheiden aantallen vergeleken met wat een universiteit, archiefdienst, gemeente of ministerie beheert, maar groot genoeg om te zien waar het patroon standhoudt en waar het wringt.

Wat schaalt:

• Markdown-bestanden zijn klein en snel te indexeren; Obsidian-gebruikers melden probleemloze vaults tot tienduizenden bestanden, met merkbare vertraging pas vanaf enkele honderdduizenden — en dan is vaak niet het bestandsaantal de bottleneck, maar de gekozen sync-methode.
• Python-scripts zijn herbruikbaar: hetzelfde parseer- en conversiepatroon (bron → JSON → Markdown) werkt voor elk nieuw datatype.
• Obsidian's full-text search is direct beschikbaar na indexering, ook bij duizenden bestanden.
• YAML-frontmatter is machine-leesbaar voor AI zonder verdere conversie.

Wat knelt:

• Graph-view in Obsidian (de weergave die eruit ziet als een neuraal netwerk) wordt onbruikbaar bij duizenden losse bestanden zonder onderlinge koppelingen. Voor de vier projecten koos ik daarom voor aparte kluizen; samenvoegen (migratie) is dan niet meer dan mappen verplaatsen of kopiëren naar één kluis.
• Bijlagen openen in Obsidian werkt niet altijd soepel: spaties in bestandsnamen kunnen links breken, omdat de onderliggende Markdown-standaard die niet toestaat. Dit soort kinderziektes meld je bij de chatbot, die het herstelt, waarna je opnieuw test.
• Media-koppeling (foto's aan reisstappen, bijlagen aan e-mails) vereist zorgvuldige matching en blijft kwetsbaar

Voor de praktijk van informatie- en archiefbeheer: deze projecten tellen duizenden bestanden; gemeenten, ministeries en universiteiten beheren er miljoenen, verspreid over tientallen bronsystemen en met eigen bewaartermijnen, autorisatieniveaus en verantwoordingseisen. Toch schaalt het onderliggende patroon: de pipeline (export → parse → metadata → Markdown) is paralleliseerbaar en geschikt voor batchverwerking, ongeacht of de bron een mailbox is of een DMS. De bottleneck is dan ook zelden de techniek. Die zit in de governance: wat extraheer je, welke metadata standaardiseer je organisatiebreed, wie mag welk dossier laten bevragen door AI, en hoe waarborg je daarbij privacy en verantwoording?

Mogelijkheden voor informatie- en archiefbeheerders

Tussen de regels van deze persoonlijke experimenten liggen praktische mogelijkheden voor onze professionele werkvelden. Hieronder schets ik vier gebieden, fantaseer met me mee.

Opschonen

Met je Markdown-archief als bron kun je AI inzetten om duplicaten te detecteren, lege of incompleet gemetadateerde records te identificeren, en inconsistenties in naamgeving of datering te markeren. Bij het Gmail-project vond het script automatisch 3 van 5239 e-mails die niet volledig konden worden verwerkt. De uitval werd heel duidelijk beschreven en aan mij geleverd. Dat soort geautomatiseerde kwaliteitscontrole is direct vertaalbaar naar dossierbeheer.

Metadateren

De stripboek-case toont dat AI Vision metadata kan extraheren uit afbeeldingen: titels, datums, ISBN-nummers, auteurs. Hetzelfde principe geldt voor gescande documenten, oude briefwisselingen, of archiefbescheiden met onvolledige beschrijving. De metadata landt direct in YAML-frontmatter — gestructureerd, valideerbaar, en compatible met je eigen metadataschema.

Classificeren

Met getagde Markdown-bestanden kun je AI vragen om een classificatieschema voor te stellen op basis van de inhoud. Geef Claude je archief, laat het patronen herkennen, en het stelt categorieën voor die wij als informatieprofessionals valideren. Dit is geen automatische classificatie — het is AI-gedragen suggestie met menselijke goedkeuring.

Bevragen met AI

Dit is de kroon op het werk. Het Markdown-archief is platte tekst met gestructureerde metadata. Elk AI-model kan het lezen en bevragen: "Toon alle documenten die nodig zijn voor de komende accreditatie", "Welke dossiers hebben geen bewaartermijn ingesteld?", of "Maak een overzicht van alle correspondentie met externe partners uit land X." Geen querytaal leren, geen databaseschema kennen — gewoon vragen stellen in natuurlijke taal.

Slotsom

De reis ging van onrust over Big Tech-afhankelijkheid, chaotisch kennismanagement en behoefte aan informatieautonomie, via Markdown en Obsidian, naar een systeem waarin informatieverzamelingen niet alleen doorzoekbaar zijn, maar met AI in natuurlijke taal bevraagd kunnen worden. De tools zijn open source of betaalbaar. De formaten zijn toekomstbestendig. De workflow — functioneel ontwerp en plan opstellen met één AI, uitvoering door Claude Code — is herhaalbaar. Ik roep al jaren dat ik 'niet heel technisch' ben. Ik begon zelfs met een vrij chaotisch en conceptueel idee. Je kunt een chatbot met je mee laten denken en vragen laten stellen om scherp te krijgen wat je precies wilt bereiken. Het functioneel ontwerpen doe je dan samen.

Digitale soevereiniteit is geen politiek statement — het is een praktische keuze voor platte tekst.

Hoe nu verder?

Mijn persoonlijke reis heeft de eindbestemming nog lang niet bereikt. Dit is wat ik van plan ben.

Ik ben met mega enthousiasme aan de slag gegaan met Obsidian, met behulp van het boek Starten met Obsidian van Martijn Aslander. Ik ben nog niet op de helft en ken pas het topje van de ijsberg van alle mogelijkheden. Mijn volgende stap is dan ook simpel: Obsidian beter leren kennen, handige plug-ins ontdekken, en al mijn losse notities en schrijfsels verplaatsen naar de kluis "Barbara's tweede brein".

De opzet van Claude Code vond ik zelf niet makkelijk, maar ik heb Claude Chat iedere stap laten uitleggen — en dat was super leerzaam. We gaan samen het stripboekenarchief afmaken, en daarna volgt een collectie LP's. Een chatbot zoekt op basis van de index in CSV straks ook de geschatte waarde van beide collecties op. Tip: vergeet niet om de instelling uit te schakelen die toestaat dat Anthropic jouw data gebruikt om zijn AI-modellen te trainen. In mijn enthousiasme was ik dat zelf vergeten — geen fijn idee als je net je e-mailarchief hebt overhandigd.

Daarnaast wil ik de scripts en werkwijze uit dit artikel documenteren op GitHub — een platform waar mensen code en uitleg openbaar delen, met een volledige geschiedenis van alle wijzigingen die erin zijn gemaakt. Zo kunnen andere informatie- en archiefbeheerders de aanpak bekijken, hergebruiken of verbeteren, zonder zelf helemaal bij nul te beginnen.

Ik ga ook verder met het aanbevelen van het boek Informatieautonomie – De ontbrekende voorwaarde voor datasoevereiniteit in een tijdperk van vendor lock-in en AI (informatieautonomie.nl) van Martijn Aslander. Daarmee begon voor mij deze hele reis. Lees dit. Vandaag nog.

De mogelijkheden zijn ongekend, de uitdagingen waar we voor staan minstens zo groot. Ik zoek daarom graag het gesprek op met collega's die ook met Markdown, Obsidian en AI experimenteren — niet om los van elkaar te pionieren, maar om samen een visie te bouwen op wat dit voor ons vakgebied kan betekenen.