Wat er verdwijnt als je een stamboom overzet

Gepubliceerd op 29 augustus 2026 · 7 min lezen

Je zet je stamboom over naar een ander programma. De import meldt achtduizend personen, de namen kloppen, de data staan er. Opgelucht sluit je het oude programma af.

Pas maanden later merk je dat de scans nergens meer openen, of dat een pleegzoon als eigen kind in de kwartierstaat is beland. Er is geen foutmelding geweest, geen waarschuwing, niets. En je bent bepaald niet de eerste bij wie dat gebeurt.

Hieronder vijf soorten verlies waar je op kunt letten. Geen van alle is jouw schuld, en alle vijf zijn ze op te sporen voordat het te laat is.

Waarom je het niet ziet

Stil verlies ontstaat doordat drie partijen elk iets doen dat op zichzelf klopt. Je oude programma toont wat je hebt ingevoerd. De export schrijft er een geldige regel voor. Het nieuwe programma slaat een regel over die het niet kent, of leest hem anders dan bedoeld. Nergens in die keten zit iemand die kan zeggen: hier gaat iets weg.

Daar komt bij dat GEDCOM ouder is dan de meeste dingen die genealogen tegenwoordig vastleggen. De grammatica komt uit versie 5.5 (1996); versie 5.5.1 is een concept uit 1999 dat pas in november 2019 definitief werd vastgesteld. In de decennia daarna zijn archiefscans, gedeelde bronnen en samengestelde gezinnen normaal geworden. De standaard is daar maar deels in meegegroeid. Datzelfde speelt bij onzekere datums, waar de vorm van je twijfel vaak sneuvelt bij het overzetten.

De remedie is niet beter opletten, maar controleren: één keer na de export nagaan of staat wat je belangrijk vindt, in een vorm die de ontvanger leest.

Scans komen niet mee

Een GEDCOM-bestand bevat geen afbeeldingen. Het bevat verwijzingen naar afbeeldingen: een pad als C:\Documenten\Scans\doop1721.jpg. Op een andere computer, of bij een collega, wijst zo'n pad naar niets. De akte staat er nog in je hoofd, maar niet meer in je bestand.

Tot versie 5.5 kon een GEDCOM een afbeelding nog echt insluiten, met een BLOB-tag. In 5.5.1 is dat er bewust uitgehaald: "The BLOB context of the multimedia record was removed in version 5.5.1." In 5.5.1 is er dus geen enkele manier om een scan ín het bestand mee te sturen. GEDCOM 7.0 heeft daar wel iets voor — een zip-variant die de scans meeneemt — maar dat werkt alleen als beide programma's 7.0 spreken, en de meeste doen dat nog niet. Dat is geen tekortkoming van je programma maar van de standaard, en het raakt precies het onderdeel waar je de meeste uren in hebt zitten.

In de praktijk: exporteer je media apart, houd de mappenstructuur ná de overstap identiek aan die ervóór, en controleer de eerste tien paden voordat je verder gaat. Zet de scans op een vaste plek waar je ze de komende twintig jaar laat staan, niet in een map die met je bureaublad meeverhuist.

Pleegkind wordt bloedkind

Deze is de vervelendste van de vijf, want hij raakt je conclusies en niet alleen je presentatie. GEDCOM legt de aard van een kindrelatie niet vast bij het gezin, maar op de verwijzing van het kind naar dat gezin, met de tag PEDI. De toegestane waarden zijn birth, adopted, foster en sealing.

Laat een programma dat veld weg bij de export, of negeert het de waarde bij de import, dan blijft de gezinsverbinding gewoon staan. Alleen de aard ervan is verdwenen, en de ontvanger vult de meest voor de hand liggende aanname in: eigen kind. Een pleegzoon of een geadopteerde dochter komt dus aan als bloedverwant, en gaat vanaf dat moment mee in elke kwartierstaat en elke afstammingsberekening die je maakt.

Er is geen foutmelding, en het valt ook niet op bij een steekproef: de persoon staat er, op de goede plek, met de goede datums. Alleen de bloedlijn klopt niet meer. Controleer na een overstap gericht de gezinnen waarvan je weet dat ze samengesteld waren.

De vindplaats in de bron

Een bronverwijzing in GEDCOM bestaat uit twee delen: de bron zelf (het doopboek) en de vindplaats daarbinnen (deel 3, folio 45, akte 112). Dat tweede deel staat in de tag PAGE, bij de verwijzing en niet bij de bron. Bronnen worden vaak gedeeld door tientallen personen; de vindplaats is per persoon anders.

Precies dat maakt het kwetsbaar. Programma's die bij de import gedeelde bronnen samenvoegen of "plat" kopiëren, houden de bron over en laten de vindplaats vallen. Je houdt dan achthonderd verwijzingen naar "DTB Zutphen" over zonder dat één ervan zegt wáár in dat boek. Voor wie navolgbaar werkt is dat het verschil tussen een onderbouwde bewering en een aanwijzing.

Dit is de eerste die je zou moeten controleren, om twee redenen: het raakt de kern van het vak, en het is achteraf bijna niet te reconstrueren zonder elke akte opnieuw op te zoeken.

De lege bewering

Weet je dát iets gebeurde maar niet wanneer of waar, dan is dat in GEDCOM een lastig geval. De standaard zegt het zo:

Een gebeurtenis zonder datum, zonder plaats en zonder die Y is dus geen bewering, en een lezer mag hem overslaan. Zonder waarschuwing, want er is formeel niets beweerd om te bewaren.

Hier zit een addertje dat zelfs veel programmamakers ontgaat. De tekst hierboven klinkt algemeen, maar de grammatica van 5.5.1 staat die Y maar op vier plekken toe: bij geboorte, doop als kind, overlijden en huwelijk. Bij PROB, WILL, BURI en de rest is Y formeel niet toegestaan. Pas GEDCOM 7.0 heeft het naar alle gebeurtenissen doorgetrokken. In de praktijk schrijven de meeste programma's het toch, en accepteren de meeste lezers het, maar een strenge validator niet.

Praktisch: heb je losse gebeurtenissen zonder datum of plaats, zet er dan iets bij dat ze wél draagt. Een notitie of een bronverwijzing is genoeg om de regel betekenis te geven.

Eén letter verschil

GEDCOM kent tagparen die één letter schelen en iets heel anders betekenen. Het scherpste voorbeeld is PROB tegenover PROP. De eerste is de gerechtelijke afwikkeling van een testament, een gebeurtenis met een datum en een plaats. De tweede is bezit: een kenmerk met een omschrijving. Let ook op het onderscheid tussen WILL (het testament zelf, gedateerd op de dag van ondertekening) en PROB (de afwikkeling erna, meestal na het overlijden).

Daar komt bij dat niet elk programma elke tag kent. Er is een veelgebruikt publicatieprogramma dat PROB eenvoudigweg niet verwerkt. De verleiding is dan groot om de gebeurtenis maar als "overig" te exporteren, want dan wordt hij daar wél zichtbaar. Doe dat niet. Je maakt hem zichtbaar in één programma en betekenisloos in alle andere.

Zelf controleren

Alle vijf zijn na te tellen in je eigen bestand, en daar heb je geen technische kennis voor nodig. Een GEDCOM-bestand is gewone tekst: je opent het, zoekt op een woord, en ziet of het erin staat.

Zoek bijvoorbeeld op PEDI, de aanduiding voor een pleeg- of adoptiekind. Geen enkele treffer terwijl je die wél hebt vastgelegd, betekent dat ze bij de ontvanger als eigen kind aankomen.

Hoe je het bestand opent zonder het te beschadigen, wat al die woorden betekenen en hoe je de aantallen laat tellen in plaats van te zoeken, staat stap voor stap in zelf in je GEDCOM-bestand kijken.

Eén tip alvast, want die is het belangrijkst: voer elke controle uit op de export uit je oude programma én op een export uit het nieuwe, en leg de uitkomsten naast elkaar. Eén getal zegt weinig, twee getallen zeggen alles. En doe het voordat je afscheid neemt van het oude programma — zolang je beide kanten nog hebt, is een verschil te herstellen.

Wat je eraan doet

Mist er iets, dan is de eerste vraag waar het misging. Staat het gegeven wél in het bestand maar niet in het nieuwe programma, dan zit het probleem bij de import: meld het daar en bewaar het bestand. Staat het er niet in, dan zit het in de export, en kun je in het oude programma kijken of het anders weg te schrijven is.

Bewaar in beide gevallen je laatste export uit het oude programma, ook nadat de overstap is gelukt. Het is het enige bewijs van wat je had.

Benieuwd hoe Pecktree met GEDCOM omgaat? Dat staat bij de functies.