In dit hoofdstuk treft u een beschrijving van de taal aan, toegelicht met eenvoudige voorbeelden. Het is de bedoeling dat u na het lezen van dit hoofdstuk eenvoudige bestanden kunt begrijpen. Maar de echte complexe zaken blijven buiten beschouwing.

1. De componenten
GEDCOM is bedoeld om gegevens uit te wisselen. Gegevens van stamboomonderzoekers, liefst goed gedocumenteerd, en zonder onbegrijpelijke 'eigen' manieren van weergeven.
Welke componenten heb je minstens nodig om de bovenstaande beschrijving te voldoen?

• Gegevens van de samensteller van het bestand

• Gegevens over de personen in het bestand

• Gegevens over de relaties tussen die personen

• Gegevens over de bronnen van het bovenstaande

• De mogelijkheid om aan te geven hoe betrouwbaar de gegevens zijn (volgens de samensteller van het bestand)

• Elk van deze punten wordt hieronder in het kort toegelicht. Vooraf nog de vermelding dat een GEDCOM bestand op regel 1, kolom 1 altijd 0 HEAD heeft staan (gevolgd door wat technische regels, die bij de samensteller worden toegelicht) en op de laatste regel, kolom 1 altijd 0 TRLR

2. De samensteller en andere inleidende gegevens
Hieronder ziet u de eerste regels van een GEDCOM bestand zoals het wordt aangemaakt door PAF, het gratis programma om stamboom gegevens vast te leggen van de Mormonen (www.kerkvanjezuschristus.nl/downloads/index.php).

• 0 HEAD

• 1 SOUR PAF

• 2 NAME Personal Ancestral File

• 2 VERS 5.2.18.0

• 2 CORP The Church of Jesus Christ of Latter-day Saints

• 3 ADDR 50 East North Temple Street

• 4 CONT Salt Lake City, UT 84150

• 4 CONT USA

• 1 DEST Other

• 1 DATE 6 Jul 2006

• 2 TIME 11:44:33

• 1 FILE vb.ged

• 1 GEDC

• 2 VERS 5.5

• 2 FORM LINEAGE-LINKED

• 1 CHAR UNICODE

• 1 LANG English

• 1 SUBM @SUB1@

• 0 @SUB1@ SUBM

• 1 NAME Wim Rozendaal

• 1 ADDR straat 12

• 2 CONT woonplaats

• 2 CONT provincie

• 2 CTRY Nederland

• 1 PHON 0123456789

• 1 EMAIL

Dit stukje code geeft al direct weer hoe een bestand is opgebouwd. Elke regel bevat een nummer (maximaal 99), gevolgd door ofwel een label (startend en eindigend met @) ofwel een code voor het type gegevens (ook wel Tag genoemd). En als laatste de gegevens. Een regel met het nummer 0 zit op het hoogste niveau in de hiërarchie en is een zelfstandige eenheid. Een regel op nummer 1 zegt iets naders over de eenheid op nummer (ook wel level genoemd) 0, 2 geeft een extra detail over 1 etc. Er zitten dus twee zelfstandige eenheden in het bovenste blok: : 0 HEAD en 0 @SUB1@ SUBM 0 HEAD beschrijft het bestand, maar de meeste gegevens die hier kunnen staan worden in de praktijk weggelaten. In dit geval staan er dus gegevens over het programma waarmee het bestand is aangemaakt (SOUR met alle details), de bestemming van het bestand (DEST), de datum en tijd van het aanmaken van het bestand en de naam waaronder het is aangemaakt. De regel 1 GEDC geeft aan dat het om GEDCOM gaat en de volgende welke versie van de standaard is gebruikt. 1 CHAR geeft aan dat de lettertekens in het bestand zijn gecodeerd volgens het unicode systeem De laatste regel van dit blok zegt de samensteller (SUBM) gedetailleerd staat beschreven onder het label @SUB1@.

Het tweede zelfstandige blok bevat een eerste regel met een label (@SUB1@) en de aanduiding dat het om informatie over de inzender van het bestand gaat (SUBM). Dit lijkt niet alleen dubbel op; het is dubbel op. Want de regel er boven staat al dat het label @SUB1@ over SUBMitter data gaat. Toch is dit de consequent toegepaste werkwijze bij GEDCOM, die er voor zorgt dat een bestand slechts eenmalig hoeft te worden gescand bij het verwerken, hoewel het niet is te voorkomen dat soms pas nadat het label is gedefinieerd wordt aangegeven waar het gebruikt wordt. Met de huidige computers is een tweede scan geen groot probleem, maar met de apparatuur uit bijv 1990 toen de standaard in ontwikkeling was, maakte dat nog een heel groot verschil.

De codes in het gegevensblok over de inzender spreken verder voor zich, alleen de code CONT verdient een afzonderlijke vermelding. Deze code kan nml. niet zelfstandig bestaan. Hij en zijn broertje CONC worden gebruikt om stukken tekst in de GEDCOM op te nemen. Soms alleen vanwege de opmaak, soms ook vanwege de lengte van de gegevens (een regel in GEDCOM mag max 255 tekens lang zijn) moet die tekst over meerdere regels worden verdeeld. De vervolgregels met de code CONT moeten bij het weergeven dan op een nieuwe regel worden geplaatst, die met CONC moeten direct (zonder extra spatie) achter de tekst van de vorige regel worden geplaatst (dus altijd afbreken midden in een woord)

Bovenstaande vlakke layout is de gebruikelijke manier om GEDCOM weer te geven Om de leesbaarheid te vergroten, gebruik ik echter liever het format hieronder, dat met een klein programmaatje vanuit het eerste kan worden gemaakt, en weer kan worden teruggezet. Dat laatste is overigens vaak niet nodig want bijna alle programma's slikken de lege regels en de spaties aan het begin van een regel gewoon in. En dat is ook conform de standaard.

Het desbetreffende programma kan worden opgehaald van http://www.famrozendaal.net menukeuze “GEDCOM introductie”. En hieronder dus de iets leesbaarder weergave:

3. Gegevens van personen

Laten we eenvoudig beginnen: ik stel mij voor:  

Dit simpele voorbeeld laat veel van de rijkdom van de GEDCOM taal zien. Van boven naar beneden:

• Allereerst het label waarmee er naar mijn gegevens kan worden verwezen van elders in het bestand, met de indicatie dat het een INDIvidual (persoon) gaat. Deze indicatie dient ertoe dat het programma dat de GEDCOM leest weet welke betekenis aan de volgende codes moet worden toegekend.

• Dan volgt mijn naam (NAME), de achternaam tussen de / tekens en de voornamen dus niet. Met als subitem mijn roepnaam (NICK), en een aantekening (NOTE) over waar mijn naam vandaan komt.

• Het geslacht (SEX) is ook te bevatten, en dan komen zaken die GEDCOM lastig maken: de feiten en gebeurtenissen.

Er zijn 21 voorgedefinieerde feiten voor personen, zoals geboorte (BIRT), doop (BAPM of CHR), beroep (OCCU), en veel gebeurtenissen in de kerk van de Mormonen. Elk van deze feiten heeft zijn eigen structuur en regels voor het vastleggen. Zeker als je tot in details wilt gaan. En daarnaast bestaat er nog de mogelijkheid om 'eigen feiten' (EVEN) te maken, waarbij je het type (TYPE) kunt definiëren en details op de gebruikelijke wijze kunt invoegen.

Maar er is wel het een en ander standaard voor alle feiten:

a) Bij elk feit kan je een datum (DATE) opgeven. En dat kan een enkele dag zijn, of een periode waarbinnen (BETWEEN ... AND ... ), of een periode gedurende dewelke (FROM ... TO ...). Daarbij is het format DD MMM YYYY. (dag met voorloopnul, de Amerikaanse 3 letter afkorting voor de naam van de maand in hoofdletters en 4 cijfers voor het jaar. Delen van een datum die niet bekend zijn kunnen worden weggelaten. En dan zijn er nog wat wat aanduidingen waarmee wordt aangeven hoe zeker de datum is. (AFT (na), BEF (voor), ABT (ongeveer), EST (geschat), CAL (berekend) .... )

Al met al leidt dat er toe dat volgende data valide zijn:

1. 11 MAY 1956

2. BETWEEN CAL 1511 AND EST 3 APR 1712

3. FROM ABT OCT 1984 to BEF 2 FEBR 2002

b) Bij elk feit kan een plaats (PLAC) worden meegeven. En dat kan dan weer met verschillende methodes worden gedaan (Alleen de plaatsnaam, plaatsnaam en provincie/land, geografische coördinaten, etc.)

c) Onder elke code (dus die voor het feit, maar ook die voor de datum, en die voor de plaats) kan een notitie of een bronvermelding worden geplaatst die betrekking heeft op het bovenliggende detail. (Dus een notitie bij een bron vermelding, met een bronvermelding voor die notitie is niet verboden). De tekst van de notitie of de bronvermelding kan direct worden opgenomen, of met een label, als verwijzing naar een speciale constructie. (Die dan wel ergens moet staan in het bestand.)

d) Er is geen GEDCOM code om het tijdstip van een gebeurtenis vast te leggen. Tussen de feiten staat nog een code die veelal wordt weggelaten, maar die je zou kunnen gebruiken om aan te geven dat iemand niet alle gegevens heeft gekregen (RESN., restriction notice). Ik heb die code daar neergezet omdat het spontaan in me opkwam tijdens het intikken. En bij GEDCOM maakt de volgorde van de codes op hetzelfde level, onder dezelfde hogerliggende code niet uit. Dus mijn geboortegegevens had ik ook achteraan kunnen zetten als:

De 7 laatste regels zeggen iets over mijn relaties met anderen. FAMS (altijd gevolgd door een label!) verwijst naar een gezinsverband/ouderpaar waar van ik een van de partners ben. FAMC (ook altijd gevolgd door een label) naar een gezinsverband/ouderpaar waar ik als kind bij betrokken was. Hoe die betrokkenheid was geeft de code PEDI weer. De gegevens over de gezinsverbanden worden bij het label weergeven en staan verderop beschreven

De ASSO code is een buitenbeentje. Hij moet worden gebruikt om alle andere relaties mee weer te geven, en zou dus een heel krachtig hulpmiddel kunnen zijn bij het vastleggen van de gegevens. Maar in de standaard staat hij nauwelijks genoemd en in de praktijk worden de gegevens veelal als notities vastgelegd. Een gemiste kans. De werking van de ASSO is heel simpel. In het voorbeeld verwijst de eerste ASSO van mij naar het label @I2@, waarachter mijn zus schuilgaat. En de onderliggende code RELA beschrijft vanuit mijn standpunt de relatie: ik (trad op als) getuige bij haar huwelijk met .... Vanzelfsprekend was ik ook getuige bij het huwelijk van mijn zwager.

Nog een opmerking over het stukje GEDCOM waarin ik mij voorstel: Hoewel het geheel aan de standaard voldoet, zijn de zeven programma's die het ter test heb aangeboden (Aldfaer, Easy Computing StamBoom, Stamboom de Luxe versie 4, FAMYX, Pro-GEN, GEDVIEW en Genealogica Grafica) er geen van allen in geslaagd de gegevens na inlezen weer te geven zoals ik ze bedoelde. Hoe dat komt wordt later besproken, voor dit ogenblik volstaat het om te zeggen dat dat niet betekent dat mijn code fout is, of de programma's niet goed zijn. Je kunt er alleen uit afleiden dat GEDCOM zo zijn beperkingen heeft.

Voor het vervolg: ga naar de volgende sub-pagina.