4. Gegevens van relaties

Relaties is waar het in het leven om gaat. En ook bij stamboomonderzoek ben je altijd bezig met relaties. De GEDCOM standaard kent twee soorten relaties: die waarin een ouders/kind(eren) verhouding zou kunnen bestaan, en alle overige. En die ' alle overige' worden inde taal beschreven met de hierboven genoemde ASSO code. Blijft voor dit hoofdstuk dus over de groep waarin er van meerdere generaties sprake is.Wederom een stukje GEDCOM als voorbeeld.

Zoals gebruikelijk begint ook dit blok code met een label en dan de aanduiding van het type gegevens. (FAM). Zoals reeds eerder is aangegeven er is geen vaste volgorde waarin de codes moeten staan maar binnen een FAM moet er altijd wel tenminste één HUSB (manlijke partner) of WIFE (vrouwelijke partner) aanwezig zijn, en tevens maximaal één van elke. Het aantal CHIL (kind records) is onbeperkt. En er dienen tenminste twee personen opgegeven te worden. Dit betekent dus dat het niet mogelijk is om twee broers aan elkaar te koppelen via een FAM record, tenzij er tenminste 1 ouder bekend is of er een dummy (Naam Onbekend) wordt ingevoerd.

Het zal de inmiddels duidelijk zijn dat de code HUSB middels het label @I1@ verwijst naar mijn gegevens zoals die in het vorige codefragment staan. En WIFE @I8@ naar het blok in het GEDCOM bestand waar de gegevens van mijn vrouw worden vermeld, de CHIL codes verwijzen naar de gegevens van mijn kinderen.

Vervolgens komen er wat feiten uit de relatie. Waarbij zich al direct een probleem voordoet want ik wilde de ondertrouw opnemen, maar in de Verenigde Staten (waar de standaard zich hoofdzakelijk op richt) zijn de procedures rond een huwelijk net even anders dan bij ons en er is dus geen code voor onze ondertrouw. MARL (marriage license) wordt er wel voor gebruikt maar dat is toch niet helemaal hetzelfde. De GEDCOM standaard biedt ook hier de mogelijkheid om (evenals bij personen) eigen types feiten te definiëren en dus heb ik dat gedaan met de EVEN constructie.

Er zijn 11 voorgedefinieerde feiten bij relaties. Waarvan MARR (Huwelijk) waarschijnlijk de meest gebruikte is. Deze code kan bij een relatie meerdere keren voorkomen met verschillen type aanduidingen. (Bijv Church en Civil, voor kerkelijk en burgerlijk huwelijk). In de standaard staat zelfs geen beperking om dezelfde TYPE aanduiding meerdere malen te gebruiken, zodat het in theorie mogelijk is met wat eigen feiten en herhaling van codes een relatie te beschrijven waarin er eerst wordt samengewoond, vervolgens voor de wet getrouwd en pas later voor de de kerk. En er na een periode waarin er een echtscheiding (code DIV) was wordt hertrouwd voor de wet.

Met vermelden van de code DIV is gelijk de op een na meest gebruikte code genoemd. De overige feiten zal ik hier niet verder benoemen, omdat ze in de praktijk te weinig voorkomen.

In het codevoorbeeld staan voorbeelden van notities op verschillende levels, en die dus steeds alleen slaan op het eerst hogere level. De via een label gekoppelde aantekening over het weer heeft dus in theorie alleen betrekking op de ondertrouw.

De code NCHI staat voor het aantal kinderen. Hier lijkt hij overbodig, maar het expliciet toevoegen van het aantal kinderen als dat bekend is, betekent dat het voor iedereen duidelijk is of alle kinderen zijn vermeld.

De verwijzingen van de personen naar de relatie, en van de relatie naar de personen dienen altijd beide aanwezig te zijn. Verwijzingen naar andere soorten labels, zijn altijd alleen aanwezig bij het item waar de gegevens achter het label moeten worden ingevoegd. Dus een persoon verwijst wel naar bv. een aantekening, maar die aantekening verwijst niet terug naar de persoon.

5. Bronnen

Afhankelijk van het doel van het stamboomonderzoek komt er vroeger of later een ogenblik dat je inziet dat het van belang is om alle bronnen van alle feiten goed vast te leggen. Als je dan twee stamboomonderzoekers bij elkaar plaatst dan heb je al snel kans dat er een verhitte discussie ontstaat over wat een bron is, en wat je van een bron moet opnemen in je genealogie. Ik ga hier niet op die discussie in, maar wil wel aangeven dat het bronnen systeem in GEDCOM een van de meest rijke onderdelen van de taal is.

Maar alvorens op de complexe brondefinitie in te gaan, eerst even de opmerking dat een simpele bron kan worden opgenomen als een simpele bronvermelding van een of meer regels. Dit geldt overigens voor veel componenten die als afzonderlijk blok opgenomen kunnen worden (naast de bronnen bij voorbeeld notities en adressen) Een korte vermelding luid:

1 BIRT

2 DATE 11 MAY 1956

2 PLAC Ooltgensplaat

3 SOUR trouwboekje ouders

Hier staat dus dat de bron waaruit ik mijn geboorteplaats ken het trouwboekje van mijn ouders is. De datum heeft mogelijk een andere bron. Om de veelheid aan mogelijkheden te laten zien volgt hieronder geen code maar een stukje uit de standaard, en wel dat waarin de structuur van een bronvermelding wordt beschreven. Alle structuren worden op deze wijze in de standaard beschreven, en de uitleg hier kan dus helpen als u zelf verder in de standaard gaat zoeken.

Van boven naar beneden staat hier respectievelijk:

• Een bron begint altijd met een label (weergegeven door @<XREF:SOUR>@), dat op elk level kan zitten (aangegeven door de letter n aan het begin van de eerste regel) en waarvan er tenminste één en maximaal één moet zijn per bron ({1:1}). De typeaanduiding achter het label is altijd SOUR. Hoewel volgens de standaard een bronvermelding op elk niveau kan beginnen, vindt u in de praktijk alleen het cijfer 0

• Een bronvermelding kan een opsomming bevatten van de feiten die in de bron genoemd worden. Deze kan eenmaal voorkomen, en bevat dan 0 tot elk gewenst aantal gebeurtenissen. Die gebeurtenissen worden elk weer met een EVEN structuur beschreven. Verder kan hierbij worden opgenomen welke instelling (AGNC) verantwoordelijk is voor de bron en kan een onbepaald aantal notities worden opgenomen. En elke notitie kan een structuur op zichzelf zijn, met een bronvermelding daarin. Dit alles onder de code DATA, die een level hoger (+1) zit dan het label.

• Bij een bronvermelding kan worden opgenomen wie de auteur van de bron is (AUTH op 1 level hoger dan het label) en daarbij kunnen weer meerdere regels worden gebruikt om de gegevens goed weer te geven. Er kunnen nul of meerdere auteurs worden genoemd.

• De bron kan een titel hebben, maximaal één. Dit is de titel waaronder de bron gepubliceerd is.

• Als de bron in eigen bezit is hier worden opgegeven hoe hij is opgeborgen met behulp van de ABBR code, die ook maar één keer mag voorkomen.

Het principe zal nu duidelijk zijn en een verdere opsomming zal ik dan ook niet geven, maar voor details verwijs ik naar de standaard. Indien u dit artikel voor u heeft als computerdocument, kunt u op de verwijzingen klikken om direct bij de juiste hoofdstukken in de standaard te komen. Heeft u het artikel niet als computerdocument dan kunt u het, met het programma voor het formatteren van GEDCOM ophalen van http://www.famrozendaal.net, onder GEDCOM introductie.

En bovenstaande geeft u dus zeer veel mogelijkheden om zelf te bepalen wat u van een bron wilt opslaan, en hoe u dat wilt doen. Om dit geheel extra krachtig te maken kunt u nog van het volgende gebruikmaken: bij het verwijzen naar een bron kunt u op de volgende regels extra details toevoegen die alleen van belang zijn op dat punt van verwijzen. Een praktische toepassing daarvan vindt u in het programma GEDCOMpare (zie verderop), waar bij het verwerken van gegevens uit GENLIAS bij elke persoon die in een bron wordt genoemd de verwijzing naar de bron wordt gevolgd door een beschrijving van de rol die die persoon bij de gebeurtenis die in de bron beschreven wordt heeft vervuld. Op die manier hoeven de meeste gegevens van de bron slechts eenmalig vermeld te worden en kan toch specifiek per persoon worden aangegeven wat er aan de hand is. 

6. Betrouwbaarheid

Als u gegevens verwerkt is het natuurlijk van belang dat u enig idee heeft over de betrouwbaarheid van die gegevens. In GEDCOM kan dat op twee manieren worden aangegeven. Ten eerste impliciet door de volgorde van de gegevens (dat lijkt inderdaad in tegenspraak met de opmerking eerder dat de volgorde er niet toe doet) en expliciet door de betrouwbaarheid van een bron aan te geven.

Om met dat laatste te beginnen: als u een bron heeft beschreven op de wijze zoals die hierboven is weergegeven, moet u op de punten waar u de bron wilt refereren een regel van het type n SOUR @Snummer@ opnemen. U heeft reeds gezien dat daaronder nadere specificatie van de reden van vermelding kan worden geplaatst (bv. met ROLE). In deze situatie (en volgens de standaard nergens anders) kunt u de QUAY code gebruiken om aan te geven hoe betrouwbaar u als opsteller van het GEDCOM bestand de bron van de gegevens acht voor deze vermelding. De waardes lopen daarbij uiteen van 0 tot 3 met (vrij vertaald) de volgende betekenissen: 

0 = Onbetrouwbaar bewijsmateriaal of geschatte gegevens

1 = Roddel, achterklap, autobiografieën en andere bronnen die geneigd zijn te “verlevendigen”.

      Twijfelachtige betrouwbaarheid van het bewijs.

2 = Indirect bewijs of officiële vastlegging geruime tijd na de gebeurtenissen

3 = Direct, primair bewijs, of een overdaad aan indirect bewijs.

Het gaat hierbij dus om uw inschatting van de betrouwbaarheid van het bewijsmateriaal. Dit ontheft de ontvanger van de gegevens niet van de plicht om zelf na te gaan of hij het met uw inschatting eens is.

NB: er zijn programma's die deze codes in de omgekeerde volgorde gebruiken (Aldfaer bv. geeft bij code 3 de betekenis “onbetrouwbaar”, maar daar moet bij worden gezegd dat de tag die wordt gebruikt _QUAY is.)

Het andere systeem werkt als volgt: stel u komt twee namen tegen waarvan u aanneemt dat ze op dezelfde persoon betrekking hebben. U kunt dan beide namen opgeven voor deze persoon, waarbij de volgorde zo moet zijn dat degene die u het meest betrouwbaar acht of bij voorkeur gebruikt als eerste wordt genoemd. De volgende naam die u vermeldt heeft minder voorkeur en een eventuele derde weer minder dan de tweede. In dit geval gaat het dus om een oordeel over de juistheid van de gegevens en niet over de juistheid van de bronnen.

En om de verwarring nog groter te maken: u kunt dus de meest betrouwbare naam vooraan plaatsen en daarbij aangeven dat de betrouwbaarheid van de bron minder is dan die van de volgende naam. Terwijl het feit dat het de volgende naam is aangeeft dat u de naam op zich minder betrouwbaar acht. Een ander niet geheel denkbeeldig feit: u weet van twee mensen dat ze getrouwd zijn geweest want u heeft van beiden de overlijdensakte gevonden. En beide aktes verwijzen naar de andere partner (de een als echtgenoot of echtgenote en ander als weduwe of weduwnaar van). Maar u heeft geen huwelijksakte. In dat geval kunt u dus twee bronnen opgeven voor het bestaan van het huwelijk, maar als u dat doet is er volgens de standaard impliciet een minder betrouwbaar dan de ander. En dat hoeft in de praktijk absoluut niet zo te zijn.

Concluderend: er zijn mogelijkheden om aan te geven hoe betrouwbaar bronnen zijn, maar deze hebben interne tegenstrijdigheden, reden waarom velen ervoor kiezen de het oordeel over de betrouwbaarheid als notitie bij de bron te nemen, en dat over een feit bij de gegevens zelf in plaats van bij de bron. En hiervoor de QUAY code misbruiken.

7. Het grote geheel

Wat u tot nu toe heeft gelezen betreft slechts een beperkte inleiding in de GEDCOM. De taal kent meer dan 200 vaste codes en een groot aantal per programma verzonnen codes. Want dat laatste is volgens de standaard toegestaan: elk programma mag een eigen code, of meerdere eigen codes, invoeren zolang mijn naam maar begint met een teken _. Andere programma's worden geacht deze codes niet te verwerken, of de verwerking van het bron programma over te nemen.  

Onderdelen die niet genoemd zijn, maar wel uitgebreid worden beschreven in de standaard zijn:

• Multimedia. Het is mogelijk om in een GEDCOM bestand te verwijzen naar multimedia bestanden, die ofwel op internet staan, ofwel los worden meegestuurd, ofwel als onderdeel van het GEDCOM bestand worden meegestuurd.

• Repositories. Dit is een verzamelbegrip voor plaatsen waar bronnen zijn opgeslagen: archieven etc.

• Identificatiecodes voor personen, relaties, etc., en wijzigingsindicaties Gegevens veranderen tussen verschillende versies van een bestand. Vaak is het wenselijk om niet alle gegevens opnieuw in te lezen, maar alleen de gewijzigde. En dan moet er dus duidelijk zijn wanneer een item:

• voor het laatst gewijzigd is (Daarvoor wordt de CHAN code, met subcodes gebruikt),

• nieuw is toegevoegd (_NEW, de enige code in de standaard zelf met een underscore begint),

• en over welk item we het hebben.

En dat laatste wordt in de standaard anders beschreven dan door veel programma's in de praktijk wordt gedaan. Het GEDCOM label mag wat de standaard aangaat veranderen tussen verschillende versies van dezelfde gegevens en is dus niet betrouwbaar als identificatie. Toch vertrouwen veel programma's hier wel op. Al eerder heeft u kunnen lezen dat gegevens tot 99 niveaus diep genest kunnen zijn in een GEDCOM bestand. In de praktijk komt dat niet voor, maar is 5 of 6 het maximum dat gebruikt wordt. Toch geeft dit niveau van diepgang al een complexiteit die erg moeilijk is te verwerken. De meeste programmamakers beperken zich dan ook tot een subset van de standaard, en proberen het aantal niveaus van de codes tot het minimum te beperken.