1. Hoe standaard is “volgens de standaard”?

De GEDCOM standaard dient om het uitwisselen van gegevens mogelijk te maken. En wel in de richting van de centrale computer van de mormonen. Dat daarnaast velen hem zijn gaan gebruiken voor eigen doeleinden is prettig voor ons als stamboomonderzoekers, maar heeft het probleem dat de gegevens van de verschillende programma's niet op elkaar aansluiten opeens wel erg zichtbaar gemaakt. Want wat zie je nu: het ene programma kan zelden een GEDCOM van het andere programma foutloos verwerken. Toch beweren alle programma's, meestal geheel terecht, dat zij zich aan de standaard houden. Hoe kan dit?

Om deze vraag te beantwoorden gaan we even een stapje terug. We praten over het uitwisselen van gegevens. En we nemen voor het gemak aan dat elk programma alle gegevens verstaat en begrijpt. Mijns inziens is dat waar het probleem met GEDCOM gegevensuitwisseling ontstaat. Niet elk programma legt immers dezelfde gegevens vast, waardoor niet alle programma's dezelfde gegevens ter beschikking kunnen stellen, en waardoor niet alle programma's behoefte hebben om alle gegevens te begrijpen. Elk programma gebruikt dat deel van de standaard dat noodzakelijk is om de gegevens die in het programma worden vastgelegd te kunnen exporteren en importeren. En soms ook bij de import nog wat extra codes, waardoor bijvoorbeeld de gegevens van andere veelgebruikte programma's ook gesnapt worden. Maar deze gegevens worden dan altijd in het programma omgezet in een vorm die voor het programma zelf wel acceptabel is. Bijvoorbeeld door feiten die het inlezende programma niet kent als notities (meestal zelfs met de GEDCOM codes er nog bij) weer te geven.

Een heel concreet voorbeeld van niet aansluiten van programma's: HAZA-Data 7.2, een programma dat jarenlang door velen is gebruikt wordt nu door de gebruikers vaak afgestoten. En dan probeert een deel van de gebruikers of bijvoorbeeld Aldfaer een goed programma zou zijn om als vervanger op te treden. De eerste test die dan plaatsvindt is het importeren van GEDCOM bestanden in Aldfaer. En dat geeft negen van de 10 keer een grote teleurstelling. Haza (gebaseerd op standaard versie 5.3) gebruikt gewoon te veel eigen codes om door Aldfaer te worden begrepen. Omgekeerd geldt overigens hetzelfde.

Laten we de volgende denkbeeldige persoon eens nemen: 

Het moet na de vorige hoofdstukken voor iedereen te volgen zijn wat hier staat. Alleen de code _ALDFAER_TBS zal voor een aantal mensen onbegrijpelijk zijn. Dat is zo'n code die slechts door één programma wordt gebruikt, in dit geval Aldfaer, en die inhoudt dat er geen begrafenis is geweest maar dat het lichaam ter beschikking is gesteld van de wetenschap. Vergelijk dat eens met de persoon hier onder:

Voor degenen die niet bekend zijn in de omgeving van Dordrecht en Gorinchem: de namen voor beide plaatsen kennen een korte vorm en een lange vorm. Het gaat dus om dezelfde plaatsen. Met die wetenschap is het te zien dat het om dezelfde persoon gaat, maar toch is meer dan de helft van de regels verschillend. Let ook op de details als de volgorde van de naam: voornaam en achternamen staan verschillend.

Dit voorbeeld maakt wel duidelijk dat de standaard weliswaar bepaalt hoe je dingen mag opschrijven, maar dat binnen die regels de menselijke geest van de vrijheid heeft om verschillende notaties voor dezelfde gegevens te gebruiken. Het is dus geen standaard manier om dingen op te schrijven, maar de GEDCOM standaard geeft aanwijzingen over de mogelijke wijze waarop de gegevens voor andere computers leesbaar kunnen worden weergegeven.

In dit voorbeeld staan de gegevens niet ver van elkaar en was u gewaarschuwd dat er iets aan zat te komen, dus zal de overeenkomst u zijn opgevallen. Maar voor een computer staat hier echt tweemaal iets verschillends. Waarmee maar gezegd is de standaard helpt wel bij het uitwisselen van gegevens maar er is meer nodig dan alleen een standaard voor de te gebruiken constructies om een taal te maken die door anderen begrepen wordt.

2. Hoe beheersbaar zijn uw gegevens?

Kijkt u nog eens naar de de eerste drie code-segmenten bij dit artikel. We hebben het dan over 80 regels code. En het enige dat u dan weet is dat ik 11 mei 1956 ben geboren, 30 december 1980 ben getrouwd en twee kinderen heb. En daarbij is er nog een aantal ongedefinieerde labels, waardoor de code nog gaat groeien bij het volledig maken GEDCOM bestanden worden al snel erg groot. En dus hoeft niemand zich te verbazen als hij/zij een GEDCOM bestand van 50 Megabytes of zo'n 3 miljoen regels krijgt opgestuurd. Daar zitten dan meestal 100.000+ personen in.

En u was zelf ook ijverig bezig geweest en had al zo'n 30,000 namen in uw bestanden. Hoe vind je nu uit welke namen er dubbel in het systeem komen als de bestanden worden samengevoegd? Of (hypothetisch bij uw bestand, maar niet bij dat van een ander) wie er al dubbel in één van de bestanden zit. En hoe gaan we na wat de kwaliteit van de gegevens is? Of het wel allemaal personen zijn die voor u van belang zijn, of er lussen in de gegevens zitten, of het bestand technisch correcte GEDCOM bevat, of de gegevens logische samenhang vertonen?

Dat kan met dergelijk grote hoeveelheden gegevens dus alleen met computerprogramma's. Maar dan gaat het zo goed als de programmeur die het programma heeft gemaakt is. En dat is over het algemeen ook maar een mens, die fouten maakt. Anders gezegd: GEDCOM biedt de mogelijkheid om snel veel gegevens uit te wisselen, maar introduceert daarmee ook de mogelijkheid dat uw zorgvuldig opgebouwde gegevensverzameling, door het importeren van vervuiling aangeleverd door anderen, waardeloos en onbruikbaar wordt.

Mijn inschatting is dat van de gegevens die enkel als GEDCOM worden verzonden, een groot deel klakkeloos wordt overgenomen, waarbij het ene programma de betrouwbaarheidsaanduidingen van het andere programma niet snapt en die dus maar overboord gooit. En dan worden gegevens vaak doorgespeeld van de een naar de ander, met als gevolg dat een zorgvuldig opgebouwd bestand met een deel van mijn stamboom met veel commentaar en waarschuwingen in het origineel, zonder enige notities, kwaliteitsaanduidingen etc in Oost-Azië op een website stond, binnen enkele dagen nadat ik het een een ver familielid had toegestuurd (overigens was de tikfout die ik bij een naam had gemaakt bewaard gebleven).

Is dat erg, dat mijn gegevens daar staan? Ja en Nee.

• Nee, het gaat over mensen die al eeuwen dood zijn, dus niemand heeft direct last van.

• Ja, want er staan zaken als hele waarheden gepresenteerd terwijl er in mijn bestand bijstond “is het op zijn mist speculatief te noemen om aan te nemen dat om .... ging”. En door die weglating wordt een mogelijkheid die ik voor mezelf als zodanig (een mogelijkheid en niet meer dan dat) had genoteerd als de heilige waarheid door anderen overgenomen. En maakt het gebruik van GEDCOM het mogelijk om snel veel fouten verspreiden.

3. Andere (technische) problemen

3.1. Codepages

En dan zou de techniek de techniek niet zijn geweest als die van iets simpels als lettertekens niet iets onmogelijk complex had weten te maken. Want wat is het geval? Computers onthouden niet de grafische weergave van de letters, maar een getal dat voor een letter staat. Simpel toch: Overal waar je het getal 65 tegenkomt druk je een hoofdletter A af. En zo ook voor alle ander letters en cijfers. Een kwestie van met elkaar afspreken welke code voor welke letter staat. En dat afspreken is dan ook gebeurd: per taal, per operating system, soms zelfs per lettertype. Dat is geen enkel probleem als je je gegevens altijd van mensen krijgt die met de zelfde instellingen van hun computer werken als je zelf doet, maar leidt anders bijna altijd tot problemen bij tekens 'met een dode toetsaanslag', é, ä, ñ, ç.

Wat is hier exact aan de hand: Om te beginnen doen we steeds minder zuinig bij het toekennen van ruimte voor de getallen die de letters weergeven. In de gloriedagen van de telex waren dat 7 bits per teken. Daarmee waren er 128 tekens mogelijk en dat was voldoende om de wereld te runnen. 26 Hoofdletters, 26 kleine letters, 10 cijfers, 30 stuurcodes (nieuwe regel, BELL etc) lieten zelf nog wat ruimte voor speciale tekens (die ook weer niet helemaal vastlagen. Met de komst van computers was het opeens niet meer zo logisch om 7 bits te gebruiken voor het opslaan van tekens, want computers doen van oudsher alles in veelvouden van 8 Bits. Dus werd dat 8ste bit ook voor de codering gebruikt.. Dat gaf de mogelijkheid om 128 extra tekens toe te voegen. Vaak is dat per taal gebeurd en moet u dus de vertaaltabel (Eng: codepage) van de juiste taal gebruiken om iets zinnigs te kunnen lezen

Vervolgens kwam de Amerikaanse overheid met ANSEL (American National Standard for Extended Latin Alphabet Coded Character Set for Bibliographic Use, ofwel een uitbreiding aan destijds bekende codes om de tekens uit het Spaans een plekje te geven) , een coderingstechniek die soms twee bytes (16 bits) gebruikt voor een teken, soms één byte (8 bits). Deze volgens velen inmiddels achterhaalde standaard was het neusje van de zalm toen de eerste versies van de GEDCOM standaard werden opgesteld. En dus werd die codering tot de standaard codering van GEDCOM files verklaard. Alle van het Arabische alfabet afgeleide letters hebben een plek gevonden in deze code, maar Grieks schrift, Russisch schrift en dergelijke worden niet ondersteund.

Om deze tekortkomingen weg te nemen zijn nieuwe systemen bedacht waarbij altijd van 16-bits (2 bytes) gebruik wordt gemaakt. Al met al een overdaad aan systemen om letters te coderen, en al die systemen worden gebruikt ook. Als het goed is staat in het begin van elk GEDCOM bestand welke codering wordt gebruikt, maar in de praktijk gaat dit vaak fout en hun met als gevolg dat uw bestand na inlezen allerlei vreemde namen met onleesbare tekens weergeeft. Op zich is dat voor u wel te herstellen, maar een computerprogramma zal er problemen mee hebben. Want hoewel er tweemaal Daniël bedoeld wordt staat het er eenmaal niet en andermaal wel. En dus herkent de computer het niet als dezelfde naam.

3.2. Bestandsformaten

Een computerbestand is vaak meer dan het oog ziet. Er zitten soms bv. een aantal tekens in de start van het bestand die worden verzwegen door Windows, maar waar het wel uit kan lezen dat er bv Big-endian 8 codering is toegepast. Handig voor Windows, maar lastig voor ons want wij willen al;s we het bestand openen als allereerste lezen '0 HEAD'. En jawel: sommige programma's zijn zo assertief dat ze niet van de Windows routines gebruik maken (biv. omdat ze op Linux lopen) en dus de voorloopbytes gewoon gepresenteerd krijgen. Met als gevolg een foutmelding, want het bestand begint niet met de juiste eerste regel..

Een ander principieel verschil dat vaak tot ellende leidt is de gewoonte van Windows om een Carriage Return en een Line Feed aan het einde van een regel te zetten (stelt u zich even voor dat alles met een automatische schrijfmachine wordt uitgetikt, en u begrijpt wat deze codes doen). Linux, Unix en andere systemen gaan er van uit dat er altijd aan het begin van de volgende regel moet worden begonnen en geven de Carriage Return niet. En ook dat kan als een bestand van het ene naar het andere operating system wordt overgezet tot problemen leiden. En vergist u zich niet, want u werkt waarschijnlijk vaker met UNIX/LINUX dan u weet: bijna alle websites draaien op een van deze operating systemen.