Controleer de kwaliteit van uw genealogische gegevens De Gedcom standaard. Structuur van genealogische gegevens. Gegevensbeheer en controle. GEDCOM - Records - Regels - Versies Het woord GEDCOM  duidt een genealogisch gegevensuitwisselings-formaat aan. Het werd oorspronkelijk om religieuze redenen ontwikkeld door de Mormoonse kerk, en werd later opgepikt door genealogen, om genealogische gegevens uit te wisselen tussen verschillende mensen die niet dezelfde systemen hadden. GEDCOM is dus een soort genealogische taal. Het is de meest bekende en wereldwijd gebruikte. Het woord GEDCOM , wat een acroniem is voor Ge nealogische d ata com municatie, wordt gespeld als een acroniem: GEDCOM . Door metonymische afleiding duidt een GEDCOM ook een genealogiebestand in GEDCOM-indeling aan. Het bestand waaraan u werkt binnen Ancestris is een GEDCOM. Sinds het midden van de jaren negentig, met de komst van internet en de toename van digitale uitwisselingen, is de GEDCOM-specificatie geleidelijk een essentiële standaard geworden voor de meeste genealogische software en sites over de hele wereld . Hoewel de meeste van deze programma's kunnen exporteren in GEDCOM-formaat, respecteren sommigen van hen het GEDCOM-formaat niet strikt en maken enkele aanpassingen door eigen structuren toe te voegen of bestaande structuren te gebruiken voor andere betekenissen. In sommige gevallen kunnen deze eigen datastructuren van dergelijke programma's, niet correct worden geconverteerd naar het GEDCOM-formaat en daardoor kunnen bepaalde gegevens eenvoudigweg niet worden geëxporteerd. Ancestris is volledig GEDCOM-compatibel met GEDCOM-versies 5.5, 5.5.1 en 7.0.13 . Als gebruiker kunt u veilig vertrouwen op Ancestris om uitgebreide genealogiebestanden bij te houden, zonder risico op gegevensverlies, en u kunt deze bestanden met iedereen delen of aan anderen doorgeven. Karakteristieken van een GEDCOM bestand. Een GEDCOM-bestand is een tekstbestand, d.w.z. een bestand met voor mensen leesbare tekstregels, dat kan worden geopend en bewerkt met elke tekst-editor die "platte tekst" kan uitvoeren , zoals Kladblok, Notepad++, VSCode, Kate, Kwrite, Gedit, enz. De extensienaam is altijd "*.ged" . Als gevolg hiervan kan een dergelijk bestand *zonder verdere bewerking* worden gebruikt door elke genealogische software, geïnstalleerd onder elk besturingssysteem, en wel zonder enige conversie. Elke regel tekst begint met een nummer en een label. Het label wordt een "Tag" genoemd . Deze Tag bestaat uit drie of vier hoofdletters . Het definieert het type informatie dat op deze regel volgt. Zo geeft de tag PLAC (=plaats) altijd aan dat de tekst die volgt op deze tag een plaats is (zoals geboorteplaats, plaats van overlijden, plaats van een ceremonie etc.) Records van een GEDCOM bestand Een GEDCOM-bestand bevat een set records. Een record is een groep tekstregels waarvan de eerste regel begint met een nul "0". Een record definieert iets in het bijzonder, wat afhangt van het type record. Het eerste en het laatste record van een GEDCOM-bestand zijn van een afwijkend type: Het eerste record wordt de header ( HEAD-tag ) genoemd en definieert wat algemene informatie over het bestand. Het laatste record wordt de "end of file trailer marker" ( TRLR-tag ) genoemd. Het definieert het einde van het bestand. Tussen de twee bovengenoemde records ( HEAD en TRLR ) staan de overige records, deze definiëren elk een genealogische entiteit, met voor elke entiteit zijn eigen set tags . Een GEDCOM-bestand gebruikt 7 entiteitscategorieën. De 7 soorten records die in een GEDCOM-bestand te vinden zijn, zijn daarom als volgt: Records die individuen definiëren: (tag INDI ) Records die families definiëren: (tag FAM ) Records die notities definiëren: (tag NOTE ) Records die bronnen definiëren: (tag SOUR ) Records die archieven (repositories) definiëren: (tag REPO ) Records die mediabestanden definiëren: (tag OBJE ) Records die personen/instanties definiëren, die informatie toevoegen aan een GEDCOM of deze versturen: (tag SUBM ) De keuze om deze 7 gegevenscategorieën als records te beschouwen is natuurlijk arbitrair, maar dat is altijd het geval bij het maken van een standaard. Men zou zich gemakkelijk andere soorten records kunnen voorstellen, zoals plaatsen bijvoorbeeld. Het feit dat een plaats geen afzonderlijke entiteit is, weerhoudt Ancestris er niet van om ze te beheren en tegelijkertijd het GEDCOM-formaat te respecteren. Boomstructuur van een Record Elk record wordt weergegeven in een boomstructuur: elke tag kan een onbeperkt aantal subtags bevatten. Subtags zijn hiërarchisch afhankelijk van de vorige tag van een hoger niveau en kunnen op hun beurt ook weer één of meer subtags bevatten, enz. Hiërarchische niveaus Hiërarchische niveaus zijn genummerd. Aangezien elke regel verplicht op zijn plaats moet blijven vanuit het oogpunt van de hiërarchie, krijgt elk van deze regels een nummer toegewezen dat overeenkomt met het niveau dat deze regel inneemt, in de boomstructuur van het record. Daarom is de regel op het hoofdniveau van elk record, dus op niveau nul, genummerd 0 . Een regel op het niveau direct daaronder draagt ​​het nummer 1 . Een regel op het niveau direct onder niveau 1 draagt ​​het nummer 2 . En zo verder. Identificatie-nummer en entiteits records Zoals hierboven vermeld, behalve de HEAD- en TRLR-records, zijn alle andere records entiteitsrecords. Elke entiteitsrecord begint met een regel van niveau 0 , gevolgd door het volgende: Het ID-nummer van de entiteit omgeven door twee apenstaartjes (@), De tag die is gekoppeld aan de categorie waartoe de entiteit behoort. De regel 0 @I0005@ INDI is bijvoorbeeld de eerste recordregel van een INDIvidu (persoons) entiteit waarvan het ID-nummer ' I0005 ' is. Inspringen Voor meer duidelijkheid kunnen regels van een record ingesprongen worden vertoond, om de relatie tussen de regels van het record duidelijker weer te geven. De informatieregels onder een tag , kwalificeren de betreffende tag. Voorbeeld van een niet ingesprongen record. 0 @I0005@ INDI => dit definieert het nummer van het individu: 'I0005' 1 NAME Pietje Puk => De naam van de persoon is Pietje Puk 1 SEX M => Deze persoon is een man 1 BIRT => Wat hierna volgt, definieert de geboorte gebeurtenis. 2 DATE April 16, 1951 => Pietje Puk was dus geboren op 16 April 1951 1 FAMC @F1328@ => Familie F1328 is het record dat de familie van Pietje Puk definieert (FAM), waarvan hij een kind is (C). Voorbeeld van een Ingesprongen record 0 @I0005@ INDI => dit definieert het nummer van het individu: 'I0005' 1 NAME Pietje Puk => De naam van de persoon is Pietje Puk 1 SEX M => Deze persoon is een man 1 BIRT => Wat hierna volgt definieert zijn geboorte gebeurtenis 2 DATE April 16, 1951 => Pietje Puk was dus geboren op 16 April 1951 1 FAMC @F1328@ => Familie F1328 is het record dat de familie (FAM) van Pietje Puk definieert, waarvan hij een kiind is (C). De GEDCOM-editor is een editor binnen Ancestris die u de exacte informatie laat zien die zich in het GEDCOM-bestand bevindt en alles wat daarbij hoort. Het verbetert ook de weergave van deze informatie om het nog gemakkelijker te lezen. Deze editor gebruikt een ingesprongen weergave en toont geen niveaunummers. Het voegt ook pijltjes toe om subtagniveaus weer te geven of te verbergen, waardoor het gemakkelijk wordt om elke tak uit te vouwen of samen te vouwen. Dit is hoe een soortgelijke persoon zou worden weergegeven in de GEDCOM-editor: Zoals u kunt zien, verbetert de GEDCOM-editor de weergave door pictogrammen toe te voegen en relevante hints op te halen. Bijvoorbeeld het gegeven "@F1328@" (het recordnummer van de familie) wordt vervangen, alleen op het display, niet in het echte GEDCOM-bestand , met de relevante informatie over de familie zelf. Hier weten we dus meteen dat de ouders van John Doe, Martin en Kelly heten. Ook is de naam opgesplitst in het achternaam- en voornaamgedeelte met een komma ertussen. Meer informatie en een aantal voorbeelden, hoe één en ander in de GEDCOM editor wordt weergegeven, vind u op de pagina Properties . Regelopmaak binnen een record Opmaak Elke regel in een record bestaat uit 3 elementen: Het niveaunummer , van 0 tot n, De tag die het type genealogische informatie definieert dat volgt, De genealogische informatie . Voorbeeld: de regel: 2 DATUM 16 april 1951 betekent niveau 2 , Tag van het type DATUM met als waarde (de informatie) 16 april 1951 . Om te weten waar deze datum naar verwijst, zou u de vorige regels moeten lezen. Wetende dat dit een regel van niveau 2 is, moet er een niveau 1 (de gebeurtenis in dit geval) en een niveau 0 (de recordentiteit) boven zijn. Verwijzen naar een andere entiteit Soms moet men in een regel verwijzen naar een andere record entiteit. Dit gebeurt door middel van het aangeven van het identificatienummer van die entiteit, omgeven door twee apenstaartjes (@). Het verschil tussen verwijzing "@id@" die een record definieert en verwijzing "@id@" die naar een record verwijst, is het volgende: Als de referentie in het 0-niveau record voor de tag staat, direct na de "0", dan is het een definitie van een record . Voorbeeld : 0 @I0005@ INDI definieert individuele I0005 Als de referentie zich aan de rechterkant van de tag bevindt, verwijst deze naar de entiteit. We zeggen ook dat het naar de entiteit "wijst". Als we bijvoorbeeld deze regel in een individueel record hebben: 1 FAMC @F1328@ dit geeft aan dat het gezin waarvan deze persoon een kind is (betekenis van FAMC ), F1328 is. Er wordt ook van uitgegaan dat F1328 ergens anders in het GEDCOM-bestand is gedefinieerd als een record dat moet beginnen met     0 @F1328@ FAM GEDCOM standaard De GEDCOM-standaard verwijst naar de set regels die bepalen wat wel en niet kan worden gedaan bij het schrijven van een GEDCOM-bestand, zodat iedereen genealogische informatie op dezelfde manier organiseert, zodat anderen het kunnen begrijpen. Het is dus de grammatica van de GEDCOM-taal. Er bestaan ​​twee hoofdstandaarden, 5.5 en 5.5.1, de tweede is een lichte evolutie van de eerste. Dingen die in de eerste zijn toegestaan, zijn in de tweede niet meer toegestaan, en vice versa. Deze verschillen zijn echter beperkt. Ancestris kan zowel de 5.5, 5.5.1 en 7.0.13 standaarden aan, en kan uw GEDCOM-bestand van de ene standaard naar de andere converteren en vice versa. GEDCOM 5.5 Deze versie is gereleased op 2 Januari, 1996. U kunt de details van de uitgebreide GEDCOM standard release 5.5 hier   vinden, in de vorm van een html site. GEDCOM 5.5.1 Deze versie is gereleased in 1999 als concept en bleef stabiel tot 15 november 2019 toen het officieel werd gemaakt. U kunt de GEDCOM-standaard release 5.5.1 ook als pdf-bestand raadplegen: GEDCOM Standaard Versie 5.5.1 . Deze 20 jaar stabiliteit maakt deze standaard tot een zeer goed gedocumenteerde en veelgebruikte manier om genealogische informatie uit te wisselen. U vindt in het 5.5.1-document een vergelijking tussen de twee GEDCOM-standaarden. GEDCOM 7.0.13 Deze versie is gereleased in 2021. De specificatie van deze versie kunt u vinden bij de website van The FamilySearch GEDCOM Specification . GEDCOM Versies Andere GEDCOM versies kunt u hier vinden, samen met meer informatie over GEDCOM zelf: GEDCOM Versies en meer. Entities - de Records van een GEDCOM bestand Een entiteit volgens de GEDCOM specificatie , duidt een genealogisch hoofdelement aan, zoals bijvoorbeeld een individu, een informatiebron, een familie, een notitie enzovoorts. Het kan ook een multimedia object zijn, zoals een video- of een audio-record.  In een GEDCOM -bestand wordt een entiteit ook een record genoemd, dat wordt geïdentificeerd door een identificatienummer, en omschreven door een groep tags die de kenmerken specificeert. De verschillende genealogische kenmerken die bij een entiteit horen, worden properties , oftewel eigenschappen genoemd zoals bijvoorbeeld: geboorte, huwelijk, datum, plaats, gebeurtenis, tekst, adres, etc. Ancestris volgt de GEDCOM -specificatie zo nauwkeurig mogelijk en gebruikt dezelfde concepten van entiteit en eigenschap (property). De manier waarop de informatie van elke entiteit wordt georganiseerd, volgt heel precies de grammatica van de standaard. Deze grammatica biedt verschillende mogelijkheden om de informatie op te slaan. Met behulp van de GEDCOM-editor kunt u deze verschillende mogelijkheden in Ancestris te zien. De 7 entiteits categorieën Er zijn zeven categorieën entiteiten in de GEDCOM -standaard. Een entiteit behoort altijd tot één, en slechts één, van deze zeven categorieën. Deze 7 categorieën zijn:   Individuen   Families   Media   Notities   Bronnen (Sources)   Inzenders (Submitters)   Repositories (Archieven) Elke entiteitscategorie heeft zijn specifieke eigenschappen. Ongeacht de categorie waartoe ze behoren, werken alle entiteiten echter volgens dezelfde principes. Elke entiteit behoort maar tot één categorie. Alle entiteiten in Ancestris zijn toegankelijk vanuit de entiteitentabel . Individuen (Personen) Een individu of een persoon is een mens, levend of overleden. Het is het belangrijkste onderdeel van elke genealogie. In de GEDCOM -specificatie wordt een persoon gedefinieerd door de INDI -tag en heeft een identificatienummer dat bijna van alles kan zijn. In Ancestris begint dit ID-nummer met de letter I van Individu . Een individu ziet er in Ancestris zo uit:       De belangrijkste eigenschappen van een persoon zijn: een naam, bestaande uit een voornaam en een achternaam, en mogelijk nog andere naamelementen. gebeurtenissen zoals geboorte, huwelijk, beroep en vele andere. relaties met andere personen in de stamboom. Gebeurtenissen en relaties zijn waarschijnlijk de meest interessante onderdelen van uw stamboom, omdat ze de stukjes informatie zijn die u inzicht geven in het leven van uw voorouders en de verhalen die zij u kunnen vertellen.   NAME : naam van een persoon. Deze tag kan worden herhaald als het individu onder meerdere namen bekend is. GEDCOM -syntax: NAME Lt. Cmndr. Joseph /Allen/ jr. In dit voorbeeld wordt jr. beschouwd als het achtervoegsel van de naam. Alle informatie is alleen in de NAME -tag ingevoerd zonder de sub-tag te gebruiken. De GEDCOM -standaard beschikt over een gedetailleerde structuur om de naam van een persoon op te slaan, en alle mogelijke elementen van een naam te specificeren, met name NICK en NSFX die aan het einde van NAME worden geplaatst. In de nu volgende lijst staat direct na de Tag, de volledige engelse tekst waarvan deze tag is afgeleid. De verschillende onderdelen van een naam zijn:   GIVN : (given name) Voornaam; de voorna(a)m(en) van een persoon: de waarde moet identiek zijn aan die van de NAME -tag, het is een optionele tag. De verschillende voornamen moeten worden gescheiden door een komma.   NICK : (nick name) (bijnaam) Een vertrouwde naam of bijnaam, die naast of in plaats van de achternaam wordt gebruikt.   NPFX : (name prefix) Naamvoorvoegsel. Een element van de naam dat voorafgaat aan de achternaam (bijv. Meester, Generaal, Dokter, etc.)   SPFX : (surname prefix) (voorvoegsel achternaam) Deel voor de achternaam. Een aanvulling op de achternaam die aan de naam voorafgaat en waarmee geen rekening moet worden gehouden bij het sorteren van achternamen. Verschillende lidwoorden / voorvoegsels van namen worden gescheiden door een komma, bijvoorbeeld in de naam "de la Cruz" moet deze waarde "de, la" zijn.   SURN : (surname) (achternaam) Patroniem, achternaam bij geboorte, achternaam. Verschillende achternamen worden gescheiden door een komma.   NSFX : (name suffix) Naamachtervoegsel Een aanvulling op de naam, een woord, dat een deel is dat volgt op de voornaam en de achternaam, en dat niet wordt geïndexeerd. Verschillende woorden/achtervoegsels van de naam worden gescheiden door een komma. Achtervoegsel, tekst achter naam (oudste, zoon...)   NOTE : (Note) Notitie over thet individu (persoon)   SOUR : ( S ource) bron van informatie over het individu, die het bestaan ​​en de kenmerken van het individu bewijst.   ALIA : (alias) Koppelt twee INDI 's om aan te geven dat ze mogelijk dezelfde persoon zijn. Heeft niet de betekenis van pseudoniem. Het is een link met een andere individu-entiteit, wat aangeeft dat deze huidige persoon een duplicaat kan zijn van de andere en dat een van de twee uiteindelijk moet worden verwijderd. Het betekent wel dat de twee personen dezelfde persoon zijn met een andere naam. Daarvoor zou u twee NAME -tags moeten gebruiken, binnen één enkele individu-entiteit. Families Een gezin is een paar mensen, levend of overleden, samengebracht hetzij door een wettelijke verbintenis (huwelijk, PACS, enz.), hetzij door een feitelijke verbintenis (bijvoorbeeld samenwonen). Meestal worden er een of meer kinderen mee geassocieerd. Een gezin is dus een structuur die twee individuen samenbrengt, evenals een reeks specifieke eigenschappen, zoals kinderen, en de verschillende gebeurtenissen die eraan verbonden zijn (huwelijk, echtscheiding, enz.). In de GEDCOM -specificatie wordt een gezin aangeduid met het FAM -label en in Ancestris krijgt het een ID-nummer dat begint met de letter F , van Family (Familie) Notatie in Ancestris :   FAM Family (Familie) Media (Video - Audio) Een media- of multimedia-element is een foto, of een audio- of videodocument (een foto, een audio-opname, een film, een kopie van een document, enz.) dat over het algemeen bedoeld is om te worden geassocieerd met een of meer personen of families of om te worden gekoppeld aan een bron. In de GEDCOM -specificatie wordt een multimedia-element gedefinieerd door de OBJE -tag. Het in Ancestris heeft het een ID-nummer dat begint met de letter M van Media . Notatie in Ancestris: :    OBJE  multimedia element Waarschuwing! Er zijn twee soorten multimedia-elementen: de entiteit en de eigenschap (Property) . Hoewel deze twee soorten media dezelfde tag ( OBJE ) hebben, mogen ze niet worden verward. De multimedia-entiteit kan door verschillende andere entiteiten worden gebruikt. Het is daarom bedoeld om gedeeld, collectief of gemeenschappelijk te zijn. Het is echt autonoom en kan onafhankelijk bestaan ​​van de entiteiten die ernaar verwijzen. Voorbeeld: een audiobestand met uw analyse van een onderzoek waarbij meerdere personen betrokken zijn. De multimedia-eigenschap (property) is bedoeld om een ​​enkel stuk informatie van de stamboom te kwalificeren. Het kan maar één keer worden gebruikt. Het is nutteloos wanneer het uit zijn context wordt gehaald, dus uit zijn verband met de informatie waarop het betrekking heeft. Voorbeeld: een video van een pasgeboren kind. De multimedia-eigenschap(property) krijgt, in tegenstelling tot de multimedia-entiteit, geen ID-nummer en is alleen geldig voor een enkele eigenschap(property) van een bepaalde entiteit. Het kan alleen bestaan ​​binnen de entiteit die het omvat . Als de entiteit wordt verwijderd, verdwijnt deze eigenschap (property) ook. Samenvattend, als hetzelfde multimedia-object moet worden toegewezen aan meerdere individuen, meerdere families, enz., is het efficiënter om het op te slaan in de vorm van een object-entiteit. Eenmaal ingevoerd, is het mogelijk om het dan een oneindig aantal keren te gebruiken. Als object-eigenschap zou u de koppeling naar het mediabestand net zo vaak opnieuw moeten invoeren als u het bestand nodig heeft,. Waarschuw Ancestris maakt geen kopie van uw multimediabestanden. Het "verwijst" (linkt) gewoon naar de daadwerkelijke bestanden. Ancestris zal ze alleen vertonen waar u ze nodig heeft in Ancestris. Verwijdert u de bestanden dus alstublieft niet, met de gedachte dat Ancestris er een kopie van heeft gemaakt.  Waarschuwing! Ancestris maakt geen kopie van uw multimediabestanden . Het "verwijst" (linkt) gewoon naar de daadwerkelijke bestanden. Ancestris zal ze alleen vertonen waar u ze nodig heeft in Ancestris. Verwijdert u de bestanden dus alstublieft niet , met de gedachte dat Ancestris er een kopie van heeft gemaakt.  Notities Een notitie is aanvullende tekstinformatie over een andere entiteit, die kan worden geassocieerd met andere categorieën entiteiten (individuen, families, multimedia-elementen, enz.) of met een eigenschap, waar dan ook in de genealogie. In de GEDCOM -specificatie wordt een notitie gedefinieerd door de tag NOTE en in Ancestris heeft het een ID-nummer dat begint met de letter N ., van Note (Notitie) Notatie in Ancestris :     NOTE Note (Notitie) Waarschuwing! Er zijn twee soorten notities: de entiteit en de eigenschap (property) . Hoewel deze twee soorten noten dezelfde tag hebben ( NOTE ), mogen ze niet worden verward. De notitie-entiteit kan door verschillende andere entiteiten worden gebruikt. Het is daarom bedoeld om gedeeld, collectief of gemeenschappelijk te zijn. Het is echt autonoom en kan onafhankelijk bestaan ​​van de entiteiten die ernaar verwijzen. Voorbeeld: een tekst die uw analyse specificeert van een onderzoek waarbij meerdere personen betrokken zijn. De notitie eigenschap(property)  is bedoeld om een ​​enkel stuk informatie van de genealogie te kwalificeren. Het kan maar één keer worden gebruikt. Het is nutteloos wanneer het uit zijn context wordt gehaald, dus uit zijn verband met de informatie waarop het betrekking heeft. Voorbeeld: een kenmerk van een pasgeboren kind. De notitie-eigenschap krijgt, in tegenstelling tot de notitie-entiteit, geen ID-nummer en is alleen geldig voor een enkele eigenschap in een bepaalde entiteit. Het kan alleen bestaan ​​binnen de entiteit die het omvat . Als de entiteit wordt verwijderd, verdwijnt deze eigenschap (property) ook. Samenvattend, als dezelfde notitie moet worden toegewezen aan meerdere personen, meerdere families, enz., is het efficiënter om deze op te slaan in de vorm van een notitie-entiteit . Eenmaal ingevoerd, is het mogelijk om het een oneindig aantal keren te gebruiken. Als notitie-eigenschap (property) zou u de tekst van de notitie zo vaak als nodig opnieuw moeten invoeren. Bronnen (Sources) Een bron is alles dat de oorsprong van informatie definieert. Het kan een document zijn, een boek, een monument, etc. Het kan ook een natuurlijk persoon zijn: uw overgrootmoeder kan bijvoorbeeld als bron worden gekwalificeerd, als zij u mondeling een familiegeschiedenis heeft gegeven. Deze entiteit is bedoeld om zeer nauwkeurig de verschillende referenties te verzamelen (titel van het document, plaats-nummer, aktenummer, pagina, enz.) om elke latere verificatie van de kenmerken (properties) van andere entiteiten (in het bijzonder individuen en families) mogelijk te maken. In de GEDCOM -specificatie wordt een bron aangeduid met de SOUR -tag en krijgt in Ancestris een ID-nummer dat begint met de letter S , van Source (Bron) Bronnen ( Sources ) en archieven ( Repositories ) vormen twee verschillende entiteiten die niettemin nauwe banden onderhouden. Enerzijds zal een archief immers waarschijnlijk meerdere bronnen bevatten, anderzijds is het bij het aanmaken van een bron noodzakelijk om een ​​koppeling te maken naar het bijbehorende archief. Daarom is het logischer en consistenter om het archief (Repository) te maken voordat u de bron aanmaakt. Raadpleeg de pagina " Leg uw stamboom bronnen vast " voor gedetailleerde uitleg over het organiseren van bronnen ( Sources ) en archieven ( Repositories ). Notatie in Ancestris :     SOUR Source (Bron) Waarschuwing! Er zijn twee soorten bronnen ( Sources ): enerzijds de bron-entiteit , anderzijds de bron-eigenschap (Property) . Hoewel deze twee categorieën bronnen dezelfde tag ( SOUR ) hebben, mogen ze niet worden verward. De bron-entiteit kan door verschillende andere entiteiten worden gebruikt. Het is daarom bedoeld om gedeeld, collectief of gemeenschappelijk te zijn. Het is echt autonoom en kan onafhankelijk bestaan ​​van de entiteiten die ernaar verwijzen. Voorbeeld: een huwelijksakte. De bron-eigenschap (Property) is bedoeld om een ​​enkel stuk informatie van de genealogie te kwalificeren. Het kan maar één keer worden gebruikt. Het is nutteloos wanneer het uit zijn context wordt gehaald, uit zijn verband met de informatie waarop het betrekking heeft. De bron-eigenschap(property) krijgt, in tegenstelling tot de bron-entiteit , géén ID-nummer en is slechts geldig voor één eigenschap in één bepaalde entiteit . Het kan alleen bestaan ​​ binnen de entiteit die het omvat. Als de entiteit wordt verwijderd, verdwijnt de eigenschap ermee. Samenvattend, als dezelfde bron meerdere gebeurtenissen van individuen, families, etc. moet kwalificeren, is het efficiënter om deze op te slaan in de vorm van een bron-entiteit . Eenmaal ingevoerd, is het mogelijk om het een oneindig aantal keren te gebruiken. Als broneigenschap zou u de kenmerken van de bron zo vaak als nodig opnieuw moeten invoeren. Inzenders (Submitters) Een inzender of indiener, is een persoon die informatie verzamelt om bij te dragen aan de opbouw van een genealogisch bestand (stamboom). Deze persoon is waarschijnlijk één van de auteurs van de stamboom, of andere genealogen die de Ancestris-gebruiker waarschijnlijk hun genealogische informatie zullen verstrekken. In de GEDCOM -specificatie wordt een indiener gedefinieerd door de SUBM -tag en in Ancestris heeft deze een ID-nummer dat begint met de letter B . Notatie in Ancestris :     SUBM Submitter Inzender (indiener) Repositories (Archieven) Een repository is een plaats waar genealogische bronnen kunnen worden gevonden (documenten, boeken, audio-opnamen, films, enz.). Dat kan een fysiek gebouw zijn (bv. archief, begraafplaats), of een website (bv. de website van de archiefdienst). Repository-entiteiten onderhouden een nauwe relatie met bronentiteiten. Een repository bevat waarschijnlijk meerdere bronnen, een bron hoort bij één repository. In de GEDCOM -specificatie wordt een repository gedefinieerd door de REPO -tag en heeft in Ancestris een ID-nummer dat begint met de letter R , van Repository (Archief). Notatie in Ancestris :       REPO Repository (Archief of Repositorie) Raadpleeg de pagina " Leg uw stamboom bronnen vast " voor gedetailleerde uitleg over het organiseren van bronnen (Sources) en archieven (Repositories). Header entiteit (Record) De header-entiteit is het eerste record van het GEDCOM -bestand en komt maar éénmaal voor in dit bestand. De header bevat informatie over het GEDCOM bestand zelf: versie van de GEDCOM specificatie (5.5, 5.5.1 of 7.013) de auteur van het bestand structuur van de jurisdicties in plaatsen Datum laatste wijziging Eventueel een notitie, enzovoorts. Het aanmaken ervan wordt verzorgd door Ancestris bij het aanmaken van een nieuw bestand. U hoeft het hoogstwaarschijnlijk niet te wijzigen na het maken. In Ancestris kan het worden bewerkt met " Menu > Bestand > Eigenschappen ". Raadpleeg de pagina "Bewerk Stamboom Eigenschappen" voor meer informatie. Notatie in het GEDCOM bestand: 0 HEAD Trailer entiteit (Record) De trailer-entiteit komt maar éénmaal voor in een GEDCOM bestand, en is altijd het allerlaatste record. Notatie in het GEDCOM bestand: 0 TRLR De trailer entiteit heeft geen enkele property (eigenschap) Identificatie nummer van een entiteit Het ID-nummer is een identificatienummer dat aan elke entiteit binnen dezelfde categorie wordt toegekend. Om het ontstaan ​​van mogelijke duplicaten te voorkomen, is dit nummer uiteraard uniek. Bovendien heeft dit specifieke nummer altijd dezelfde vorm, namelijk een letter gevolgd door een bepaald aantal cijfers. Elke entiteitscategorie wordt geassocieerd met een bepaalde letter, de eerste letter van het ID-nummer geeft de categorie aan waartoe deze behoort. De gebruiker hoeft zich geen zorgen te maken over het toekennen van een nieuw ID-nummer bij het aanmaken van een nieuwe entiteit: deze nummering wordt automatisch uitgevoerd door Ancestris. Houd er rekening mee dat in het menu Tools / Voorkeuren / Edities / Identificatienummer een selectievakje kan worden geactiveerd om de ID-nummers opnieuw te gebruiken die beschikbaar zijn gebleven door entiteiten die zijn verwijderd. Ook kunt u ID-nummers altijd later wijzigen nadat entiteiten zijn gemaakt. Gebruik daarvoor de tool ID-nummers genereren. Properties - eigenschappen van een GEDCOM-Record Een Property of Eigenschap , is informatie die een kenmerk van een entiteit beschrijft. Een property (eigenschap) bestaat in wezen uit twee elementen: zijn naam en zijn inhoud . De naam  van een property , wordt in een GEDCOM -bestand geïdentificeerd door de Tag (het label), dat altijd een Engelse afkorting is . Voorbeeld Neem bijvoorbeeld de volgende drie properties (eigenschappen). Stad : Amsterdam Stad : Parijs Stad : Londen Deze drie properties delen dezelfde naam (Stad), maar hebben een verschillende inhoud : Amsterdam, Parijs, en Londen. De stad wordt in het GEDCOM -bestand gecodeerd met de Tag: CITY , in hoofdletters . De Tags De GEDCOM -standaard definieert een groot aantal genealogische eigenschappen (properties). Elke property wordt geïdentificeerd door een Tag , waardoor ze allemaal uniek en eenduidig zijn. Hier zijn enkele voorbeelden van properties en hun bijbehorende tags tussen haakjes. Naam (tag NAME ) Datum (tag DATE ) Plaats (tag PLAC ) Notitie (tag NOTE ) - hier bedoelen we de eigenschap NOTE, niet de entiteit NOTE. Geslacht (label SEX ) Geboorte (tag BIRT ) Huwelijk (tag MARR ) Overlijden (tag DEAT ) Beroep (tag OCCU ) Religie (tag RELI ) Woonplaats (tag RESI ) Voor meer details: Zie de pagina Tags voor de properties (eigenschappen) die gedefinieerd zijn in een GEDCOM -bestand Voor meer informatie over Datums , zie de pagina Datum. Voor meer informatie over Plaatsen , zie de Plaatsen-pagina. Voor meer informatie over Gebeurtenissen , zie de pagina Gebeurtenissen. Gebruik In het GEDCOM -bestand behouden properties (eigenschappen) altijd dezelfde structuur en volgen strikt dezelfde syntaxisregels. Daarom zien ze er altijd op dezelfde manier uit. In Ancestris komen properties (eigenschappen) exact overeen met de GEDCOM -eigenschappen, maar ze kunnen er anders uitzien, dat is namelijk afhankelijk van het scherm waarop ze worden vertoond. Dit wordt uitgelegd in de volgende 5 voorbeelden: 1: Properties in de GEDCOM file Elke regel in het GEDCOM -bestand is één property. En elke property regel heeft hetzelfde soort formaat. Dat komt omdat elke regel moet voldoen aan de syntax regels van het betreffende GEDCOM formaat. Hier een voorbeeld van een klein stukje van een Gedcom bestand, dit is een voorbeeld van een persoons- Record : (de Tags zijn paars gekleurd) U ziet dat elke regel op dezelfde manier is opgebouwd namelijk: Nummer Tag Inhoud Nummer: Dit geeft aan welk nivo deze tag heeft in het GEDCOM bestand. Daarna volgt de eigenlijke Tag , (hier in paars) die zegt om welke soort informatie het gaat, en daarna volgt de Inhoud die aan deze is Tag is gegeven door de gebruiker (uzelf). Kijkt u bijvoorbeeld bij BIRT , deze regel heeft nummer 1. Dit geeft aan dat het om een hoofd-tag gaat, in dit geval: geboorte ( BIRT ). Maar bij een geboorte horen een datum en een plaats. Deze vallen als het ware ONDER of BINNEN de tag BIRT . U ziet daarom ook dat de regels met DATE en PLAC die direct volgen op BIRT , voorafgegaan worden door een ander nummer, namelijk 2 . In dit geval zijn dus DATE en PLAC sub-tags (onderdeel) van BIRT . Ze zijn onverbrekelijk verbonden met BIRT . Omdat dit als u het voor de eerste keer ziet, best wel lastig leest en te begrijpen is, heeft Ancestris dit in de GEDCOM Editor iets duidelijker en begrijpelijker weergegeven: 2: Properties i n de GEDCOM editor We kijken eerst naar precies hetzelfde voorbeeld als in paragraaf 1 , maar nu in de GEDCOM Editor : Hier staan er geen nummers meer voor de regels, maar ze springen in. U kunt nu duidelijk zien dat DATE en PLAC horen bij BIRT , ze staan namelijk iets meer naar rechts, waardoor goed te zien is dat ze als het ware " onder " BIRT vallen. En door middel van de pijltjes, zoals bij BIRT , kunt u tags "open" en "dicht" klappen om de leesbaarheid te bevorderen. U ziet ook dat bij de Tag SEX , de inhoud direct achter de Tag zelf staat, deze Tag heeft ook geen pijltje ervoor staan. Daar zijn geen verdere sub-Tags nodig om alle informatie weer te geven. Laten we nu eens kijken naar de Tag NAME: U ziet dat BIRT even dichtgeklapt is. Zo kunnen we ons goed concentreren op NAME . We zien hier 2 tags die " onder " NAME vallen, namelijk GIVN (de officiële voornaam), hier Peter, en SURN (achternaam) hier Puk. Maar een naam kan natuurlijk nog veel meer sub-properties hebben, zoals een voorvoegsel (titel), een roepnaam enzovoorts. Hier een kleine tip van de sluier hoe de GEDCOM editor u kan helpen met het toevoegen van alle mogelijke properties die "onder" de NAME tag kunnen vallen. In de GEDCOM editor doen we daarvoor een rechtsklik precies op de NAME tag en krijgen dan: In het gele vlak ziet u alle mogelijkheden die u kunt toevoegen "onder" de tag : NAME tag. Meer uitleg over invoeren via de GEDCOM editor, vind u op de pagina " Leg uw stamboom bronnen vast ", en op de pagina van de GEDCOM editor zelf. Het is u waarschijnlijk opgevallen dat de GEDCOM Editor de properties ook weergeeft, met één propertie per regel. Toch zijn er een aantal verschillen met hoe deze regels in een GEDCOM bestand zelf staan, namelijk: De GEDCOM editor geeft niet het hele GEDCOM -bestand weer, maar slechts één entiteit tegelijk, deze ene entiteit noemen we een Record : het ID-nummer en de categorie van deze entiteit (dus van dit Record) verschijnen op de eerste regel, bovenaan. In dit voorbeeld hierboven dus ID-nummer " I00002 ", en Categorie " INDI ". (De GEDCOM specificatie verlangt dat het ID-nummer tussen 2 @-tekens staat, hieraan herkent de GEDCOM het begin van een nieuw Record .) Links van elk label (tag) bevindt zich in de GEDCOM editor een symbool in de vorm van een minipictogram dat verwijst naar de aard van de tag. De minipictogrammen die aan de boomstructuur zijn toegevoegd, maken het veel gemakkelijker te lezen in vergelijking met het onbewerkte GEDCOM -bestand. De editor geeft de regelnummers niet weer, maar geeft de regels in plaats daarvan weer in een boomstructuur, met een meer of minder uitgesproken inspringing, afhankelijk van de positie van elke regel in de hiërarchie. Deze regels zijn ook voorzien van pijltjes, waarmee u met een simpele klik de inhoud van een bepaalde tak kunt tonen of verbergen. 3: Properties i n de andere editors In alle andere Editors worden de properties (eigenschappen) weergegeven in de taal van de gebruiker. In de Aries- en Cygnus-editors verschijnen noch de Tags (labels), noch de regels, noch hun boomstructuur: de naam van elk veld, uitgebreider dan een korte eenvoudige tag, nodigt de gebruiker gewoon uit om gegevens in te vullen, op dezelfde manier zoals men een formulier invult. Cygnus Editor, naam invullen. Aries Editor, naam invullen. U ziet dat de labels bij elk invulveld veel langer en duidelijker zijn dan de korte labels ( Tags ) zelf, in de GEDCOM Editor. 4: Properties i n de Entiteiten Tabel In de Entiteiten Tabel staat elke rij voor een complete entiteit en elke kolom voor een property(eigenschap). We zeggen ook dat elke regel een Record is in het GEDCOM bestand. Het is mogelijk om de tabel te configureren om de eigenschappen (kolommen) te kiezen die moeten worden weergegeven. Entitie tabel, gedeeltelijk, met een aantal personen. Entitie tabel, instellingen voor het kiezen welke eigenschappen (properties) vertoond moeten worden. 5: Properties vertoond in overige schermen In alle andere vensters worden eigenschappen ook weergegeven en kunnen deze worden bekeken, afgedrukt of bewerkt (Zoals in de Navigator, dynamische boomstructuur, enz.). Tags - labels in een GEDCOM - Property Aaangezien er druk gewerkt wordt aan GEDCOM 7, is deze pagina niet vertaald. U kunt voorlopig de huidige informatie vinden op de Engelse pagina: Tags . Gebeurtenissen - van persoon of familie Een gebeurtenis is een van belang zijnde gebeurtenis of feit, in het leven van een persoon of een gezin, meestal voorzien van een datum en een plaats. Hoewel sommige gebeurtenissen per definitie uniek zijn (geboorte, overlijden, begrafenis, enz.), kunnen andere zich meerdere keren in een mensenleven voordoen (huwelijk, beroep, verblijf, echtscheiding, enz.). De verschillende soorten gebeurtenissen Of het nu gaat om een ​​individu of een familie, gebeurtenissen of feiten kunnen talrijk en gevarieerd zijn. In de GEDCOM -standaard en in Ancestris is een groot aantal gebeurtenissen gedefinieerd. Dit gaat door middel van zogenaamde "Tags" ( Labels ). Alle tags zijn een afkorting van een Engels woord. Zie voor een uitgebreide beschrijving de pagina over Tags . Wanneer een type gebeurtenis niet is gedefinieerd, is het mogelijk om de algemene gebeurtenis " EVEN " te kiezen waarmee deze kan worden beschreven. Gedefinieerde gebeurtenissen voor personen: Adoptie ( ADOP -tag) Aantal huwelijken (attribuut) ( NMR -tag) Aantal kinderen (attribuut) ( NCHI -tag) Begrafenis ( BURI -tag) Beroep (attribuut) ( OCCU -tag) Beschrijving (fysieke eigenschappen, bv oogkleur) ( DSCR -tag) Bevestiging als lidmaat van een kerk ( CONL -tag) Bar mitzvah ( BARM -tag) Bas mitswa ( BASM -tag) Burgerservicenummer ( SSN -tag) Crematie ( CREM -tag) Diploma ( GRAD -tag) Dood ( DEAT -tag) Doop voor volwassenen ( CHRA -tag) Doop (naamgeving van een kind) ( CHR tag) Doop (sacrament) ( BAPM -tag) Eerste communie ( FCOM -tag) Eigendom (attribuut) ( PROP -tag) Emigratie ( EMIG -tag) Erfrecht verklaring ( PROB -tag) Feit algemeen gebeurtenis attribuut. ( FACT -tag, moet ook een TYPE -tag hebben) Geboorte ( BIRT -tag) Identiteitsnummer ( IDNO -tag moet ook een TYPE -tag hebben) Immigratie ( IMMI -tag) Kaste of sociale status (attribuut) ( CAST -tag) Nationaliteit ( NATI -tag) Naturalisatie ( NATU -tag) Onderwijsniveau (attribuut) ( EDUC -tag) Pensioen ( RETI -tag) Religie (attribuut) ( RELI -tag) Testament ( WILL -tag) Titel ( TITL -tag) Volkstelling ( CENS -tag) Vormsel (officieel/volledig lid van een kerk)( CONF -tag) Wijding (tot priester e.d.) ( ORDN -tag) Woonplaats (attribuut) ( RESI -tag) Zegening ( BLESS -tag) Gedefinieerde gebeurtenissen voor families: Certificaat van toestemming ( MARL -tag) Contract huwelijkse voorwaarden ( MARS -tag) Echtscheiding ingediend ( DIVF -tag) Gebeurtenis, (evenement). ( EVEN -tag. Moet ook een TYPE -tag hebben, te gebruiken voor een gebeurtenis waarvoor geen specifieke Tag bestaat) Gescheiden ( DIV -tag) Huwelijk ( MARR -tag) Huwelijkscontract ( MARC -tag) Nietigverklaring van het huwelijk ( ANUL -tag) Ondertrouwen ( MARB -tag) Verloving ( ENGA -tag) Volkstelling ( CENS -tag) Gebeurtenis eigenschappen: Een gebeurtenis heeft over het algemeen de eigenschappen: datum en plaats. Het kan ook andere eigenschappen hebben. Hier is een voorbeeld van mogelijke eigenschappen. Bronnen (tag SOUR ): links naar brondocumenten Bureau (tag AGNC ): de instelling of persoon die het evenement bekrachtigd/bewijst. Datum (tag DATE ): datum waarop het evenement plaatsvond Multimedia-element (tag OBJE ): links naar multimedia ter illustratie van het evenement Notes (tag NOTE ): notities of opmerkingen over het evenement Oorzaak (tag CAUS ): de oorzaak van de gebeurtenis, zoals de doodsoorzaak. Plaats (tag PLAC ): locatie waar het evenement plaatsvond Type (tag TYPE ): een korte omschrijving van het type evenement Datums De datum maakt het mogelijk om elke genealogische gebeurtenis in de tijd te situeren zoals: geboorte, overlijden, huwelijk, slagen voor een examen, (verandering van) woonplaats, enz. In Ancestris kan de datum op verschillende manieren worden ingevoerd en weergegeven omdat deze volgens een bepaalde kalender is gedefinieerd, maar ook meer of minder nauwkeurig kan zijn. Datums invoeren In de verschillende editors van Ancestris wordt de datuminvoer uitgevoerd in een kleine speciale zone, die is samengesteld uit de drie bestanddelen van de datum (dag, maand en jaar), met daarbij twee knoppen, één voor de precisie, de andere voor de soort kalender. Precieze datum in Gregoriaanse kalender Datum vanaf tot Datum geïnterpreteerd Datum tussen Hebreeuwse datum Datum ongeveer Datum vóór Juliaanse datum Frans Republikeinse datum Relatieve precisie knop De knop Relatieve precisie opent een minimenu waarmee u kunt aangeven of de betreffende datum nauwkeurig is of niet, en in het tweede geval de aard van de onnauwkeurigheid. Datum, (standaard keuze): Het is een precieze, standaarddatum, opgebouwd uit de dag, de maand en het jaar (in 4 cijfers) Periode van/tot: dit is om de periode aan te geven, waarin de gebeurtenis heeft plaatsgevonden, of geldig was, zoals een verblijf op een locatie. Periode vanaf : dit is een open periode, vanaf de aangegeven, maar zonder einddatum Periode tot : Dit is een open periode kan elke datum zijn vóór, de getoonde datum. Periode tussen/en : dit is om uit te drukken dat er ergens tussen de aangegeven data een kortstondig evenement heeft plaatsgevonden. Een geboorte die in de eerste helft van januari 1874 heeft plaatsgevonden, kan bijvoorbeeld worden aangeduid als BET 1 JAN 1874 EN 16 JAN 1874. Houd er rekening mee dat het ook JAN 1874 kan zijn als het gewoon ergens in januari 1874 was. Periode vóór : hetzelfde als hierboven behalve dat alleen de maximale einddatum bekend is (de minimale startdatum is niet bekend). Periode na : hetzelfde als hierboven, behalve dat alleen de minimale startdatum bekend is (de maximale einddatum is niet bekend).   Ongeveer : Het betekent dat de datum niet exact is. Berekend . Datum wordt wiskundig berekend, bijvoorbeeld op basis van een gebeurtenis datum, en een leeftijd. (bijvoorbeeld bij een huwelijk, is een getuige 32 jaar, dan geboorte berekenen aan de hand van de huwelijksdatum, waarbij deze getuige aanwezig was, en dan 32 jaar terugtellen) Zie ook bij de Datulator tool . Geschat : datum wordt geschat op basis van een algoritme dat een andere gebeurtenisdatum gebruikt Geïnterpreteerd : wanneer dit formaat is geselecteerd, wordt rechts of onderaan een klein veld weergegeven om de elementen in te voeren die de interpretatie van deze datum mogelijk hebben gemaakt. (bijvoorbeeld: " Op goede vrijdag ") De datum wordt geïnterpreteerd op basis van kennis over de bijbehorende datumzin die in dat veld is opgegeven. Deze datumzin kan elke verklaring zijn die wordt aangeboden als een datum, wanneer het jaar niet herkenbaar is voor een onderzoeker, maar die wel informatie geeft over wanneer een gebeurtenis plaatsvond. Kalender knop De Kalender-knop opent een minimenu waarin u een van de vier beschikbare kalenders kunt selecteren om de datum uit te drukken. Hier is een uittreksel van Wikipedia. Gregoriaans : de Gregoriaanse kalender is de kalender die in het grootste deel van de wereld wordt gebruikt. Het is genoemd naar paus Gregorius XIII, die het in oktober 1582 introduceerde. De Gregoriaanse kalender is de standaardkeuze in Ancestris. Om de in Engeland en Noord-Amerika gebruikte kalender af te stemmen op die op het Europese continent, werd de Gregoriaanse kalender aangenomen en werd de kalender 11 dagen vooruitgeschoven: woensdag 2 september 1752 werd gevolgd door donderdag 14 september 1752. Het jaar 1752 was een schrikkeljaar zodat het uit 355 dagen bestond (366 dagen minus 11 weggelaten). Meer informatie in Wikipedia omtrent de Gregoriaanse kalender . Julian : De Juliaanse kalender, voorgesteld door Julius Caesar in 708 Ab urbe condita (AUC, 'vanaf de stichting van de stad') (46 v. Chr.), was een hervorming van de Romeinse kalender. Het trad in werking op 1 januari 709 AUC (45 v.Chr.), Bij edict. De Juliaanse kalender was de overheersende kalender in de Romeinse wereld, het grootste deel van Europa, en in Europese nederzettingen in Amerika en elders, totdat hij geleidelijk werd vervangen door de Gregoriaanse kalender, afgekondigd in 1582 door paus Gregorius XIII. De Juliaanse kalender wordt nog steeds gebruikt in delen van de oosters-orthodoxe kerk en in delen van de oosterse orthodoxie, evenals door de Berbers. Meer informatie in Wikipedia omtrent de Juliaanse kalender . Joods : de Joodse kalender, ook wel Joodse kalender genoemd, is een lunisolaire kalender die tegenwoordig voornamelijk wordt gebruikt voor Joodse religieuze vieringen. Meer informatie in Wikipedia omtrent de Joodse kalender . Republikeins: de Franse Republikeinse kalender, ook wel Franse Revolutionaire kalender genoemd, was een kalender gemaakt en geïmplementeerd tijdens de Franse revolutie, en gebruikt door de Franse regering gedurende ongeveer 12 jaar van eind 1793 tot 1805, en gedurende 18 dagen door de Commune van Parijs in 1871. Meer informatie in Wikipedia omtrent de Franse Republikeinse kalender . Als er een datum is ingevoerd, wordt bij elke wijziging van de kalender, die datum direct geconverteerd naar die datum in de gekozen kalender. Houd er rekening mee dat de republikeinse kalender alleen conversie accepteert voor datums tussen 22 september 1792 en 31 december 1805, aangezien dit de hoofd periode is waarin deze kalender werd gebruikt. Bovendien geeft elke regel van het minimenu, volgend op de naam van de kalender, de momenteel ingevoerde datum weer, omgezet in die kalender, met dezelfde uitzonderingen als hierboven vermeld met betrekking tot de regel van de republikeinse kalender. U ziet in dit voorbeeld dat er geen datum staat achter de Frans republikeinse datum. Dit komt omdat 8 jan 1874 (Gregoriaans) niet bestaat in de Frans Republikeinse kalender. Onderdelen van een datum De drie velden voor de datum staan ​​horizontaal op een rij, altijd in dezelfde volgorde: dag, maand en jaar . In het eerste vak, de Dag , kunt u het nummer van de dag in de maand invoeren met twee cijfers. In het vervolgkeuzemenu van Maand, kunt u de juiste maand-naam selecteren. In het vak Jaar kunt u het jaar invoeren, altijd in vier cijfers. Als de knop voor Relatieve precisie is ingesteld op een gesloten bereik, dan ziet u het klok-icoon niet, maar tekst, (bij de opties Periode van/tot of Tijdspanne tussen/en), worden de drie bestanddelen van de datum natuurlijk dubbel weergegeven. Weergave De verschillende datums die in de GEDCOM -bestanden zijn ingevoerd, kunnen ook worden weergegeven in verschillende rapporten, vensters, weergaven, enz. De keuze hoe datums moeten worden weergegeven, is beschikbaar in het paneel Voorkeuren / Gegevens / Algemene gegevens. Ongeacht het gekozen formaat, de volgorde van de drie bestanddelen van de datum is altijd dag maand jaar. Het vervolgkeuzemenu Datums heeft de volgende vier weergave-indelingen. GEDCOM formaat - 25 JAN 1970 Het GEDCOM -formaat is het formaat dat wordt gebruikt in het GEDCOM -bestand: de maand wordt in hoofdletters geschreven, waarbij de eerste drie letters van de maand altijd in het Engels worden gebruikt. Kort formaat - 25 Jan 1970 Het korte formaat geeft de maand in kleine letters weer, beginnend met een hoofdletter, geschreven met de eerste drie of vier letters van de maand in het Nederlands . Lang formaat - 25 Januari 1970 Het lange formaat geeft ook het woord van de volledige maand weer in kleine letters met een hoofdletter. Nummer formaat - 01/25/1970 De Nummer-notatie geeft maand, dag en jaar weer als getallen gescheiden door schuine strepen (/). Plaatsen en Jurisdicties Een plaats is een eigenschap van een entiteit, die een fysieke plaats aangeeft, die verband houdt met een evenement, en die over het algemeen is voorzien van een postadres en waarschijnlijk ook geografische coördinaten (lengte- en breedtegraad) kan/zal ontvangen. In de GEDCOM -standaard wordt de plaats aangegeven met de PLAC -tag (label). Plaats jurisdicties In de definitie van de GEDCOM PLAC -tag (of Label ), om een plek op aarde zo nauwkeurig mogelijk te kunnen beschrijven, wordt gebruik gemaakt van zogenaamde Jurisdicties. Een Jurisdictie is een rechtsgebied waarover een bepaalde instantie bevoegdheden heeft. Dat kan zijn over een klein gebied, zoals een dorp, maar ook over een wat groter gebied zoals een stad, of over een provincie, of een land en dergelijke. Het plaatsformaat in een GEDCOM bestand, wordt gedefinieerd door een aantal Jurisdicties van oplopende grootte. Deze Jurisdicties worden hier ook vaak: Adres elementen genoemd. De waarde van de tag PLAC , wordt gepresenteerd als adres-elementen, gescheiden door komma's, zoals een postadres. Voorbeeld (tag en waarde): PLAC ,Alkmaar,1234AA,Noord-Holland,,Nederland Deze elementen van de plaats worden jurisdicties genoemd. Een jurisdictie, ook wel plaats criterium genoemd, is dus een samenstellend element van een plaats. Deze elementen kunnen zijn: de stad, de postcode, de provincie, de regio, het land, enz. In Nederland hebben we geen regio's, althans niet in de plaatsaanduiding. Vandaar de lege plek tussen Noord-Holland en Nederland. In Frankrijk wel, daar heb je bijvoorbeeld " département ", en in Engeland bestaat " county ", in America " state ". Vooraan is ook een lege plek, want in het bovenstaande voorbeeld met Alkmaar, zijn de Nederlandse jurisdictions: Gehucht,Plaats,Postcode,Provincie,Staat,Land U ziet dat de eerste jurisdictie voor Nederland " Gehucht " is. Alleen wordt die niet in de "normale" plaatsaanduiding gebruikt. In plaats van " Gehucht " kunt u ook " Buurt " lezen. Zou u zoals hiervoor bij Alkmaar, ook de wijk willen noemen dan is het bijvoorbeeld: PLAC Alkmaar-Centrum,Alkmaar,1234AA,Noord-Holland,,Nederland In de GEDCOM -standaard zijn de verschillende jurisdicties van een plaats georganiseerd van links naar rechts, gescheiden door komma's, en in oplopende volgorde van grootte (aantal inwoners). Het volgende voorbeeld, dat de jurisdicties in willekeurige volgorde aangeeft, zou niet voldoen aan de GEDCOM-standaard : PLAC Nederland,Alkmaar,Noord-Holland,1234AA,,Alkmaar-Noord Een foutief GEDCOM voorbeeld van Boston zou bijvoorbeeld zijn: PLAC USA,Suffolk,Massachusetts,02136,New England,Hyde Park,Boston Met de GEDCOM -standaard kunt u ook uw eigen rechtsgebieden definiëren. We kunnen inderdaad bijvoorbeeld het parochie- of plaatsniveau definiëren, of, zoals in Frankrijk , twee codes voor de gemeente hebben: namelijk de postcode en de INSEE-code. In Engeland bijvoorbeeld de ZIP- of Post-code, en de Census eenheden. We kunnen dus heel goed een Insee-code hebben om de plaats hierboven te beschrijven, voorbeeld voor Frankrijk : PLAC Faouédic,Lorient,56121,56100,Morbihan,Bretagne,Frankrijk De plaats ligt voor de stad en de Insee-code staat voor de postcode, dit zijn preciezere begrippen. U kunt de jurisdicties ook aanpassen, zie de beschrijving iets verder op deze pagina. Hoe gebruiken we de komma In de GEDCOM -standaard is de komma het scheidingselement waarmee de verschillende jurisdicties van een plaats kunnen worden onderscheiden. Als een van de jurisdicties van een plaats onbekend is, wordt er een lege ruimte gelaten om deze jurisdictie te concretiseren. Bij afwezigheid van de plaatsnaam en de INSEE-code zou de hierboven genoemde plaats Lorient, als correcte GEDCOM, bijvoorbeeld de volgende vorm kunnen hebben: PLAC ,Lorient,,56100,Morbihan,Bretagne,France De beginkomma, evenals de twee komma's die op elkaar volgen , geven de locaties van de twee niet-gespecificeerde juridicties aan (de plaats en de INSEE-code). Andere voorbeeld: Bij afwezigheid van buurt en postcode zou de hierboven genoemde plaats Boston, als correcte GEDCOM , er bijvoorbeeld als volgt uitzien: PLAC ,,Boston,Suffolk,Massachusetts,New England,USA Omdat buurt en postcode ontbreken zijn er vooraan 2 lege plekken in de PLAC tag en staan er 2 komma's vlak achter elkaar. Voor een goed begrip bij het lezen van een plaats is het daarom essentieel om de plaatsing van komma's te respecteren, en natuurlijk geen komma te gebruiken binnen een juridictie. Houd er rekening mee dat het GEDCOM -bestand zelf, geen spaties aan weerszijden van de komma accepteert. De stad Den Haag houdt bijvoorbeeld zijn spatie tussen Den en Haag, maar verder staan er geen spaties, niet voor de D en niet achter de g. Om het lezen te vergemakkelijken, kunnen de verschillende schermen van Ancestris (in het bijzonder de editors) spaties voor en na de plaatsnaam onderdelen weergeven (in ieder geval na elke komma, in overeenstemming met typografisch gebruik), maar het GEDCOM -bestand zelf, accepteert geen witruimte aan beide kanten van deze komma's. Deze door Ancestris toegevoegde spaties, worden dan ook niet in het GEDCOM bestand weggeschreven Het plaats formaat Alle plaatsen van dezelfde stamboom (in één en dezelfde GEDCOM file) moeten worden beschreven volgens dezelfde jurisdicties en in dezelfde volgorde. Dit is het plaats-formaat van het GEDCOM -bestand zelf. Dit formaat wordt aangegeven in het GEDCOM -bestand zelf, en geldt dan voor alle plaatsen in die genealogie. Het wordt aangegeven in de header van het GEDCOM -bestand, in de HEAD -tag. Dit zijn de regels van de header (HEAD) van het GEDCOM -bestand die het plaatsformaat zullen aangeven De PLAC -tag is optioneel in de HEAD -tag van het GEDCOM bestand, maar in termen van consistentie en gegevenskwaliteit, raden we ten zeerste aan om het wel in de HEAD te vermelden. Voor een genealogie die meerdere landen bestrijkt, heeft u daarom een ​​generiek PLAC formaat nodig dat uitgebreid genoeg is om de plaatsen van alle in deze Genealogie voorkomende landen, in hetzelfde formaat te kunnen vermelden. Veranderen van het Plaats formaat In het venster "Plaatsformaat aanpassen" kunt u een jurisdictie in het plaats-formaat toevoegen of verwijderen, en de volgorde van de verschillende soorten jurisdicties wijzigen voor alle locaties en alle entiteiten in het gehele genealogiebestand. Dit venster is toegankelijk via het menu "Bestand / Plaats jurisdicties bewerken" . U krijgt dan het volgende scherm. De wijziging van het formaat van plaatsen is ook mogelijk vanuit de GEDCOM-editor , klik met de rechtermuisknop op een PLAC-regel, in het contextmenu kiest u het commando " Plaats Jurisdicties bewerken ". Om een ​​locatie in te voeren in de andere editors, dient u de verschillende jurisdicties in oplopende volgorde van belangrijkheid (aantal inwoners), in te voeren, waarbij elk niveau wordt gescheiden door een komma. Ook als er geen jurisdictie is opgegeven, moet de "lege" komma worden gehandhaafd. Een plaats toevoegen Principe Als u in de Voorkeuren de optie " Criteria van plaatsnamen splitsen " hebt gekozen, om te bewerken in de GEDCOM-editor , hoeft u zich geen zorgen te maken over de uitleg die volgt, u voert de jurisdicties afzonderlijk in, dat wil zeggen niveau voor niveau . Anders moet u uw locaties achter elkaar invoeren, dat wil zeggen als een reeks jurisdicties gescheiden door komma's. Als de notatie bijvoorbeeld buurt, postcode, stad, provincie, staat, regio, land is voor een evenement in Timorpark in Den Helder, postcode 1782DR, provincie Noord-Holland, in Nederland, moet u het volgende invoeren: PLAC Timorpark,1782RD,Den Helder,Noord-Holland,,Nederland Achter de naam van het land volgt niets. Als een jurisdictie onbekend is of niet bestaat, staat er een "lege" komma (hier dus op de plek van de jurisdictie "staat", want dat kennen we in Nederland niet) Stel dat we alleen de plaats zouden weten, dan moeten we invullen: PLAC ,,Den Helder,,,Nederland Het principe is eenvoudig: We vullen in van de kleinste naar de grootste jurisdictie. Alle jurisdicties zijn van elkaar gescheiden door een komma, zelfs als ze leeg zijn. Automatische aanvulling van jurisdicties Terwijl u een plaatsnaam invoert, wordt er een vervolgkeuzemenu geopend met al bekende plaatsen met dezelfde tekenreeks in de naam. Klik gewoon op de voorgestelde regel en druk op OK om te selecteren. Als u ervoor heeft gekozen om afzonderlijke jurisdicties weer te geven in de Voorkeuren, bestaat deze functie ook, maar dan regel voor regel. Wijzig alle plaatsen in één keer Als u merkt dat u vanaf het begin een typefout heeft gemaakt bij een plaats, of als dezelfde plaats op verschillende manieren is geregistreerd, wilt u misschien alle foutieve plaatsen in één keer wijzigen zonder terug te hoeven gaan naar elke plaats apart om ze te corrigeren. Dit kan gedaan worden met behulp van de GEDCOM-editor , of met behulp van de Plaatsenlijst of de Plaatsentabel . Zie aldaar. Plaatsenlijst: Plaatsentabel: Gedeelde informatie in GEDCOM en Ancestris Sommige stukjes informatie die in een stamboom zijn verzameld, kunnen ofwel specifiek zijn voor een individu, ofwel deze informatie kan worden gedeeld door meerdere individuen of meerdere families van die stamboom. Bijvoorbeeld een familiefoto hoort bij diverse familieleden, een portretfoto maar bij eentje. Een stamboom bevat heel veel informatie en het meeste daarvan zult u willen hergebruiken. Als u informatie wilt hergebruiken raden we ten zeerste aan om deze in eerste instantie op te slaan als losse entiteit , en niet als een eigenschap (property) , dus niet als onderdeel van een andere entiteit . Op die manier is de informatie herbruikbaar! Dit is het geval voor alle Notes , alle Sources (bronnen), alle Repositories (Archieven) en alle Multimedia Elements . Een uitgebreide uitleg van de verschillende entiteiten, welke er zijn en wat voor gegevens ze bevatten, vind u op de speciale entiteiten-pagina . Andere informatie in Ancestris kunt u vaak op een transparante manier hergebruiken. Dit zijn bijvoorbeeld beroeps omschrijvingen, gebeurtenis omschrijvingen, omschrijvingen van een diploma enzovoorts. Algemeen gesteld zijn het dus de korte labels die iets beschrijven. Het principe van informatie aanmaken Het principe om informatie aan te maken in Ancestris, is het volgende: Vraag uzelf steeds af of de informatie die u wilt invoeren, waarschijnlijk opnieuw zal worden hergebruikt door andere personen dan degene waaraan u nu bezig bent, of aan andere entiteiten in het algemeen. Aanmaken van gedeelde informatie Als de informatie hoogstwaarschijnlijk hergebruikt gaat, of kan worden: Maak de entiteit eerst aan als " losse ", op zichzelf staande entiteit Koppel deze losstaande entiteit vervolgens aan de andere entiteit die deze losstaande entiteit zal gaan gebruiken.  In bepaalde gevallen is het duidelijk dat een entiteit zal worden hergebruikt, zoals bijvoorbeeld bij een archief (Repository) . In andere gevallen is de keus niet altijd meteen duidelijk zoals bijvoorbeeld bij een notitie (Note) . Entiteiten die gedeelde informatie gebruiken Een ander voordeel van het gebruik van gedeelde entiteiten is, wanneer u wilt weten, welke entiteiten nu precies welke informatie gebruiken. Hiervoor gebruikt u de entiteiten lijst. U selecteert hier de gedeelde entiteit en kunt dan in een hieraan gekoppelde sub-lijst zien, welke andere entiteiten deze zelfde informatie gebruiken. U selecteert bijvoorbeeld een notitie en kunt dan precies zien waar deze notitie wordt gebruikt. Omgekeerd kunt u zo ook zien of een bepaalde gedeelde entiteit eigenlijk nog wel ergens gebruikt wordt. Voorbeelden Repository voorbeeld: Tijdens uw genealogisch onderzoek vindt u waarschijnlijk meerdere documenten die afkomstig zijn uit hetzelfde Archief (Repository) . U maakt dit archief natuurlijk slechts éénmaal aan, zodat u al uw gevonden bronnen (Sources) uit dit archief, ook hiernaartoe kunt verwijzen. En van dit archief noteert u dan alle gegevens (Properties) zoals naam, adres, telefoon, website enzovoorts. Elk van deze bronnen die uit dit archief afkomstig is, laat u dan naar dit zelfde archief verwijzen. Dit archief kan ook een regionaal archief zijn, een gemeentehuis, een website of een begraafplaats bijvoorbeeld. Hier een voorbeeld van 3 sources uit hetzelfde archief: Voorbeeld van een familie boekje Stel u ontdekt een familie boekje waarin 3 kinderen staan vermeld, en u schrijft ook een notitie waarin u uw onderzoek uitlegt, dan heeft u een schema wat er zo uitzien: De 3 kinderen (personen) vertegenwoordigen de broers en zussen. Hun geboortes (dopen) zijn afkomstig uit het familieboek zelf, dat is de bron ( Source ). En dat familieboek is weer afkomstig uit een archief ( Repository ). Het verhaal (de Note of notitie ) is van uzelf, ter ondersteuning van het onderzoek of van de observaties over deze 3 geboortes (dopen). U ziet in dit schema dat de bron ( Source ), in dit geval het familieboekje, gekoppeld is aan de doop van elk kind , dus niet aan het kind (persoon) zelf. Dit is nauwkeuriger. De doop is immers een Property (eigenschap) van elk kind. In dit voorbeeld gaan we er van uit dat de notitie (het verhaal of de Note ), alleen gaat over de geboortes (dopen) zelf. En niet over het leven van elk kind in bredere zin. Want als het over meer gaat dan alleen de doop, dan is het beter om de Note (de notitie of het verhaal) te koppelen aan elk kind zelf en niet aan de Property "geboorte of doop" van elk kind. Voorbeeld van een Note (notitie) Een notitie ( Note ) moet een gedeelde notitie zijn, als de inhoud ervan betrekking heeft op meerdere entiteiten (individuen) tegelijkertijd. Zoals dit het geval was in het vorige voorbeeld. Aan de andere kant, stel dat u een notitie ( Note ) heeft, die commentaar geeft, of omstandigheden specifieert, die alleen betrekking hebben op één enkele persoon in het bijzonder . In dat geval moet deze Note bij voorkeur worden ingevoerd als individuele notitie ( Note ) binnen de entiteit , en niet leiden tot de aanmaak van een aparte, globale, Note-Entiteit. ( Note Entity ) Dit is bijvoorbeeld het geval bij gegevens over een geboorte (de lengte en het gewicht van het kind, het feit dat de persoon in het huis van zijn of haar ouders is geboren, enz.). Deze gegevens zullen altijd alleen betrekking hebben op de geboorte van de persoon in kwestie en het is efficiënter om deze informatie direct op geboorteniveau in te voeren als een individuele notitie ( Note ). Voorbeeld van een plaats De eerste keer dat een plaats wordt gemaakt, verschijnt deze op de plek waar deze het eerst wordt gebruikt. Ancestris staat niet toe dat je het in een Place-entiteit plaatst, zelfs als je denkt dat je het later misschien opnieuw moet gebruiken. Dit komt doordat de GEDCOM -standaard plaatsen niet als entiteiten definieert . Dit is geen probleem, Ancestris beheert de lijst van plaatsen voor u en is van mening dat elke plaats hergebruikt kan worden. U moet echter voorzichtig zijn wanneer u een plaats aanmaakt: het is aan u om te controleren of deze nog niet bestaat, om te voorkomen dat u een duplicaat maakt. Een duplicaat van een plaats is op zich niet vervelend, maar wordt het wel als u bijvoorbeeld één van de twee corrigeert terwijl u denkt dat ze allemaal gecorrigeerd worden. Om te voorkomen dat er een duplicaat wordt aangemaakt bij het invoeren van een plaats, laat Ancestris automatisch alle plaatsen zien, die in uw stamboom zijn gevonden en die de ingevoerde tekst bevatten. Dankzij de weergave plaatsenlijst is het ook mogelijk plaatsen samen te voegen die per vergissing twee keer zijn ingevoerd. Uitvoering Aanmaken (invoeren) Het aanmaken van Notes (notities), Sources (bronnen), Repositories (archieven) en Multimedia Elementen  gebeurt via het Ancestris-contextmenu of via de menubalk , of automatisch vanuit de Cygnus-editor of handmatig vanuit de Aries-editor . Het aanmaken van een plaats wordt gedaan door deze via een editor aan een entity toe te voegen, of het gebeurt in de Plaatsen Editor . Koppeling (Link) De koppeling aan een bestaande notitie ( Note ), bron ( Source ), archief ( Repository ) of multimedia-element,  gebeurt via het Ancestris-contextmenu of via de editors. De koppeling naar een bestaande plaats gaat net zoals bij het aanmaken: namelijk door een plaats direct in de editors in te voeren, of via invoer in de Plaatsen Editor . Gebruik Als u van een bepaalde notitie ( Note ), bron ( Source ), archief ( Repository ) of multimedia element wilt zien door welke entities deze wordt gebruikt, doet u het volgende. U selecteert in de entiteiten tabel de betreffende notitie (of bron, archief of multimedia element) en bekijkt deze dan in de GEDCOM Editor . U ziet dan alle entities die deze informatie gebruiken, als een lijst van gekoppelde entities. Hier is een voorbeeld van bron S5 van de Bourbon stamboom, die we selecteren in de entiteiten tabel: Als we deze bekijken in de GEDCOM Editor zien we het volgende: In groen, de eigenschappen ( Properties ) van de bron ( Source ) S5 zelf. In geel zien we alle koppelingen , dus alle verschillende entities die naar deze bron verwijzen. We zien dan dat bron S5 gekoppeld is aan: notitie N2 over de moord door Ravaillac, de naam van de persoon I29 Robert Capet, de dood van Lodewijk IX en de naam van Marguerite de Provence. Als u van een plaats wilt weten door welke entities deze allemaal gebruikt wordt, gaat u naar de plaatsenlijst . Daar kunt u de plaats selecteren en door het pijltje uit te klappen ziet u de gebeurtenissen ( Events ) die bij deze plaats horen. Kwaliteits controle van uw stamboom Om de weg te kunnen vinden in uw stamboom maar ook om deze schat aan informatie te kunnen doorgeven, is het noodzakelijk consistent te blijven in de manier waarop u elke soort informatie invoert. De GEDCOM -standaard is hiervoor een goede referentie en maakt het mogelijk om een ​​groot deel van de informatie te structureren. Zelfs als u binnen de GEDCOM normering blijft, zijn er soms verschillende mogelijkheden om locaties, notities, bronnen, gebeurtenissen, media, enzovoorts in te voeren. Het kan daarom zijn dat u de kwaliteit van uw gegevens wilt controleren om er zeker van te zijn dat deze consistent zijn. We hebben verschillende soorten controles geïdentificeerd die u kunt uitvoeren: Naleving van de GEDCOM-standaard . Voorbeeld: er is maar één geboorte mogelijk voor een individu, een tag is niet gedefinieerd, een datum mag niet leeg zijn, enz. Consistentie van genealogische gegevens : lege of ongeldige datum, persoon begraven voor zijn overlijden, , leeftijdsverschil tussen echtgenoten te groot, persoon te jong om een ​​kind te krijgen, enz. Plaatsen zijn niet in overeenstemming met het plaatsenformaat (jurisdictions). Media-items niet gevonden op de computer. Ancestris heeft de gereedschappen om uit te zoeken of de ingevoerde informatie consistent is met de GEDCOM -standaard, consistent is met elkaar of voldoet aan een bepaald formaat. Om de meeste van de hierboven vermelde afwijkingen te identificeren, gaat u in het Menu naar " Gereedschap / Validatie van de GEDCOM naleving en de gegevens consistentie ". Om media-items te corrigeren, gaat u naar de functie " Bestand / Media bestanden beheren ". Plaatsen kunt u corrigeren via: " Beeld / Plaatsenlijst ". Overige correcties gaan via de diverse Editors.