Het komt bij mij regelmatig voor dat bepaalde citaten van bronnen niet worden getoond bij de persoon waar ze bij horen. Mijn eerste conclusie is dat dit te maken heeft met het feit dat er soms twee citaten uit dezelfde bron komen. Via bovenstaande link is te zien dat Otte Ketelaar zijn hele leven in Wildervank heeft gewoond. Hierdoor is zowel bij zijn doop als bij zijn begrafenis de bron hetzelfde (Kerkregisters - Wildervank). Onder deze omstandigheden wordt niet het citaat van de begraaf-registratie getoond. De gegevens worden wel getoond indien er sprake is van twee verschillende bronnen. Hebben hier meer mensen hinder van?

Gebruikt programma: The Complete Genealogy Builder / maar oorspronkelijk MyHeritage. In beide gevallen werd dit wel goed weergegeven.

Wim

Interessante vraag, we gaan er naar kijken.

Ik voorspel problemen in de gebruikte Gedcom standaard in de software

Groet Herman

Voor mijn eigen analyse (en @Herman Schilder :-) hieronder het betreffende stuk GEDCOM over Otte Ketelaar (Harms).

De GEDCOM is volgens mij goed. De doop (CHR) en het overlijden (DEAT) zijn beide gekoppeld aan de Kerkregisters - Wildervank (S38) die bij de Groninger Archieven liggen. De doop komt uit het Doopboek en het overlijden uit de Aangegeven lijken. Ik had verwacht dat dit aparte bronnen (SOUR) zouden zijn. Maar GEDCOM technisch klopt dit volgens mij gewoon. Dan is het alleen dus de weergave op Genealogie Online die beter moet, in de weergave moeten dit twee aparte bronvermeldingen worden. Nu presenteert Genealogie Online er maar één, waarschijnlijk omdat het dus allebei bron S38 betreft. Ik ga de code in duiken.

0 @I4018@ INDI
1 NAME Otte /Ketelaar (Harms)/
...
1 CHR Y
2 DATE 16 NOV 1760
2 PLAC Wildervank, Nederland
...
2 SOUR @S38@
...
3 DATA
4 DATE 16 NOV 1760
4 TEXT Kerkelijke gemeente Wildervank - Doopboek 1729-1803
5 CONT Kind: Otte, gedoopt op 16-11-1760 te Wildervank; zoon van Harmen C… en Janna Ot…
5 CONT NB. registratie door waterschade deels onleesbaar.
...
1 DEAT Y
2 DATE 11 JUL 1809
2 PLAC Wildervank, Nederland
...
2 SOUR @S38@
...
3 DATA
4 DATE 11 JUL 1809
4 TEXT Kerkelijke gemeente Wildervank - Aangegeven lijken 1806-1811
5 CONT Overledene: Otto Harms, overleden op 11-07-1809 te Wildervank, 50 jaar.
5 CONT NB. geslacht overl.: man; nalatende [eene wedw] en 6 kinderen; tekst tussen “[]” is afkomstig van hu
5 CONC welijksbijlage van dochter Janna dd 19-09-1833.

--

0 @S38@ SOUR
1 TITL Kerkregisters - Wildervank
1 REPO @R1@

--

0 @R1@ REPO
1 NAME Groninger Archieven - Kerkregisters

Hallo Wim en Bob,

@Wim Vos

U schrijft over 2 programma's: In beide gevallen werd dit wel goed weergegeven

Ik ga er van uit dat dit is, wat u op uw scherm ziet

Dat laatste zegt dan niets over de Gedcom als u uw data ziet op het scherm in die programma's
De weergave daar is puur uit de database, zoals het ooit is ingebracht.

Hoe daar de gegevens in de Gedcom worden gegenereerd (overgeheveld) is een vertaalslag daaruit
door de software zelf.

Verschillende gegevens staan dan ook uniek in uw database gekoppeld,
maar hoe die daar echt staan is moeilijk voor mij in te schatten.
Soms is het één veld (dan is het moelijker voor aanmaken van de Gedcom, maar niet onmogelijk)
Staan deze in twee database velden dan moet het goed gaan, om deze bij de juiste tag
argumenten terecht te laten komen.

Nou ben ik nog geen door gewinterde Gedcom man hoor.
Het is best complex door de ingewikkelde geschreven handleiding. Die uiteindelijk na lezen wel logica bevat

Programmeren in antieke programmeertalen gaat mij goed af.
Wijkt nauwelijks af met vroeger en nu.
Het gaat gewoon over de "draaggolf", I/O en de rechten.
Vul het in met de juiste opdrachten en zie, daar is het.

Maar wat ik zo beredeneer zie ik ook geen rare dingen, wat ik aanvankelijk wel dacht.

Maar als je de Gedcom versie erbij neemt (in mijn geval de 5.5), de tags volgorde
en nummering kloppen gewoon.

Ik was eerst geneigd te denken dat 2 SOUR @S38@ misschien fout was,
maar deze verwijst naar het record waar de gegevens staan.
Hoe de software daar onderscheidt maakt is moeilijk te zeggen.

Ook de volgorde en de op nummering van de tags is juist.

Of de 2 SOUR @S38@ twee keer mag voorkomen, daar ben ik nog niet uit.

Gevoelsmatig zeg ik nee, maar Gedcom loopt volgorde af.

Zo ben ik recent nog tegen de een fout in OBJ tag aangelopen in mijn eigen geprogrammeerde Gedcom.

Als voorbeeld:
1 OBJE
2 FILE
3 FORM
2 TITL
de volgorde tusssen verschillende Gedcom versies lopen dus verschillend wat onder OBJ staat en werd  als fout
bij validatie gemeld.

Kon ik op 2 manieren aanpassen, met het versie nummer in de header of de betreffende tags omdraaien
Maar ook te grootte bestanden moet je weer anders invoegen en afhandelen.

@Bob,

Misschien een tip: Wat zegt de chronoplexsoftware.com Gedcom validator over het totale
Gedcom bestand ?

Zoals je best zult weten, veel software houdt zich niet aan de Gedcom versie in de header.
Het is het detectie middel om tot de juiste Gedcom inlezing te komen.

Voor de karakters (1 CHAR) settings geldt hetzelfde om b.v. extended karakters
goed weer te geven. De welbekende é ü enz.
Daar zitten we op dit moment ook in de overgang van ANSI naar UTF8 of UTF16,
meestal alleen als UNICODE genoemd (geeft ook leuke dingen) binnen Windows 10 x64.
Open maar eens een ANSI Gedcom en sla maar weer eens op in kladblok
en alle extended tekens zijn gemold als je dat in Windows x64 doet.

Onlangs zag ik dat Aldfaer en ProGen ook de Gedcom nog niet helemaal snappen.
Export van gegevens geeft bij validatie foutmeldingen.

Groet Herman

@Herman,

GEDCOM validators geven over dit "dubbele gebruik" van bron ID's geen waarschuwing. Dit sterkt mij in mijn vermoeden dat het gewoon mag en de interpretatie van Genealogie Online berust op een verkeerde aanname van mij. Met het oplossen van dit specifieke punt ben ik nog bezig.

@Bob,

De validators heb ik over het algemeen een slecht gevoel over.

Het kwam voor, dat ik net m'n Gedcom had getest in een bepaalde Validator versie en dus goed was en bij een update van de validator het daarna weer testen van de Gedcom ""gierde"" van de fouten. Dus in mijn beleving zegt dat niets.

Waar gewerkt wordt vallen spaanders; Niemand is foutloos; Dat je werkt en je best doet om er wat van te maken, toon je dus hiermee dus aan.

Verder moet men hier; de diverse topic schrijvers (dus niet allemaal) maar eens leren dat het allemaal niet zo makkelijk is om dat even in te bouwen of recht te zetten informatie is, zoals sommige (met weinig eigen onderzoek en kennis) dat wel eens vragen.

Mvg. Herman

Hallo Bob en Herman,

Er zijn veel producten in de omloop die allemaal hun eigen interpretatie hebben van de GEDCOM-implementatie. Bij  de conversie van Familiy Tree Builder (FTB) naar The Genealogy Builder (TGB) trof ik ook enkele issues aan, maar deze waren acceptabel. Ik heb ook gekeken naar bijv. Alfaer, maar met name m.b.t. bronnen en bewaarplaatsen kwam ik daarmee niet uit de voeten. De GEDCOM-validator is (tenminste de laatste versie) prima om op record-niveau wat controles uit voeren. Hiermee heb ik gericht bepaalde "problemen" bij bepaalde personen / families kunnen corrigeren (verkeerde datumopmaak / horizontale tab tekens meegekomen met kopieren en plakken / voorloopspaties / etc). Meer moet je ook niet verwachten van de GEDCOM-validator. Mijn GEDCOM had volgens de validator 14461 validatiefouten. De meest voorkomende:
- W409 (1361x) <EVENT_TYPE> events must not have a line value.
- W482 (7988x) <EVENT_TYPE> events with subordinate tags should omit the line value 'Y'.
- W461 (4474x) The <CONTINUATION> does not meet the minimum length of 1 characters.

W409 en W482 lijken te maken hebben met een datum icm de aanduiding "Y" of "N" m.b.t. de vraag of de gebeurtenis heeft plaatsgevonden. Je mag blijkbaar volgens de validator niet EN een datum opgeven EN aangeven dat de gebeurtenis heeft plaatsgevonden. Binnen TGB is dit niet of onvoldoende te regelen. Dit lijkt allemaal geen invloed te hebben bij importeren van de GEDCOM in een ander product.

W461 wordt n.a.w. veroorzaakt door een aktie van mijzelf bij het verwerken van citaten. Aan het eind geef ik een extra blanco regel mee. Dit mag blijkbaar niet. Ook dit lijkt geen invloed te hebben bij importeren van de GEDCOM in een ander product.

De validator meldt niets over problemen met bronverwijzingen. Ik betwijfel of de validator zo ver gaat.

M.b.t. het oorspronkelijk probleem: 

Ik heb binnen mijn database de bronaanduidingen generieker gehouden door de term "Burgerlijke Stand - Gemeente <naam>" te hanteren. Waardoor met name bij personen die hun hele leven binnen één gemeente blijven de bronaanduiding hetzelfde blijft. Echter het gebruikte citaat is natuurlijk verschillend, omdat zowel een geboorteakte als en overlijdensakte wordt geciteerd?

@Herman

Bij mijn oorspronkelijke melding heb ik niet aangegeven dat dit een probleem met Genealogie Online is, noch dat iemand het voor mij zou moeten rechttrekken. Wel deel ik de mening van Bob dat het aannemelijk is dat er een foutieve koppeling wordt gemaakt binnen Genealogie Online. Ik ben zelf systeembeheerder en weet als geen ander dat bug fixing een tijdrovend proces is en goed doordacht dient te gebeuren, want anders raak je van de regen in de drup. Dus ik geef Bob de nodige tijd om hier in te duiken. Intussen zal ik op het betrokken gedeelte van de GEDCOM ter beoordeling laten aanbieden aan de enige partij die dit kan: De Kerk van Jezus Christus van de Heiligen der Laatste Dagen. Zij hebben immers de GEDCOM-definitie opgesteld?

In een datumveld mag wel meer niet, ben ik vandaag tegen gekomen:

2 DATE ABT <jaar> mag alleen 2 DATE <jaar> zijn Gedcom 5.5, 5.5.1 en 5.5.5; Genealogie-online slikt de eerste gewoon als zoet koek met

2 VERS 5.5.1 in de header.

Daar beginnen voor mijn idee de problemen.

In een ouder versie (welke weet ik even niet meer) mocht dat dus wel. Ik verzin dat niet zelf dus.

De referentie op basis waarvan gegevens worden overgenomen is niet wat het moet zijn, wil je een standaard ondubbelzinnig gebruiken en onderhouden binnen een eigen systeem.

Als het niet klopt moet er gemeld worden wat er mis is, zodat een gebruiker actie kan ondernemen

In oudere sofware staat dus ook in een Gedcom zo'n versie nr en die verandert ook niet zo maar en kan dus wel fout zijn in relatie met de tag ordening.

Daar zou Genealogie-online wel mee om moeten kunnen gaan als afwijking om gebruikers tegemoed te komen.

Citaat: W461 wordt n.a.w. veroorzaakt door een aktie van mijzelf bij het verwerken van citaten. Aan het eind geef ik een extra blanco regel mee. Dit mag blijkbaar niet. Ook dit lijkt geen invloed te hebben bij importeren van de GEDCOM in een ander product.

Die kom ik dus ook regelmatig tegen bij het valideren.

Aan het begin stond vanuit m'n DOS-applicatie een lege regel die er niet mocht zijn, maar geen enkel probleem gaf, behalve dus de validators.

In jouw laatste deel vraag ik me af of je ooit antwoorden krijgt, omdat de standaard al zins eind 90-er jaren niet meer wordt onderhouden en dus out-off-date (?) is.

Het is ontzettend tijdrovend op welke basis mijn Gedcom dus moet worden aangemaakt, wat ik in onderzoek heb.

Ik kan wel alle standaarden na lezen, maar ik kom diverse hiaten tegen, maar allemaal gerelateerd aan Versies.

Dat nodigt juist uit om goed te gaan in het maken van een Gedcom.

Maar als er (in mijn ogen) ook nog eens onnodige eigen tags worden bedacht wordt het een zooitje.

Als voorbeeld:

Adoptie, Onecht kind, Gescheiden, Samenwonen, Broer-Zus Broer-Broer Zus-Zus (viceversa),

In een kwartierstaat hoort dat helemaal al niet thuis; hooguit als subinfo in een NOTE CONT info, die op zijn buurt weer heel goed te verifiëren zijn mits op de Gedcom standaard lijn.

Is uw vraag opgelost? Zo ja, kunt u die dan op 'opgelost' zetten?

Hallo,

Omdat er destijds geen terugkoppeling is geweest heb ik dit probleem eerst laten rusten. Ik ben de laatste dagen veelvuldig aan het testen geweest (zie https://www.genealogieonline.nl/familie-hommes/).

Bij Albert van Klinken (Albert van Klinken (1821-1893) » Familie Hommes Test2 » Genealogie Online) zie je dat bij geboorte het mogelijk is om twee bron-citaten te koppelen aan één gebeurtenis, maar dan moeten het wel twee verschillende bronnen zijn. Op de bronnen-tab zie je:
- de bron (SOUR),
- de datum van de bron (SOUR.DATA.DATE),
- de bewaarplaats (REPO) en
- het bron-citaat (SOUR.DATA.TEXT).
Daarnaast kun je, door te klikken op de bron-link, ook zien op welke gebeurtenissen de bron nog meer van toepassing is. Dit is een mooie mogelijkheid binnen Genealogie Online. Er zijn niet veel sites die deze mogelijkheid bieden.

Wel is jammer dat het nog niet mogelijk is om dezelfde bron te gebruiken bij verschillende gebeurtenissen (EVENTS) van één persoon. Albert is geboren, gehuwd en overleden in Onstwedde en derhalve geldt dat dezelfde bron van toepassing is - "Burgerlijke Stand - Gemeente Onstwedde" - voor alle drie de gebeurtenissen. Echter, omdat de bron als is gebruikt bij de geboorte ontstaat er een onjuiste verwijzing naar de twee overige gebeurtenissen.

Het is natuurlijk mogelijk om de tekst te verplaatsen naar de gebeurtenis zelf (DEAT.NOTE of MARR.NOTE - zie bijv. ) maar m.i. is dit bedoeld voor minder onderbouwde notities ipv een bron-citaat.

Mvrgr.

Wim Vos