stamboomforum

Forum logoGenealogie software / GEDCOMs » verval



Profiel afbeelding

.

Herman - 20 jan 2013 - 11:37

Hallo Herman,


Even een reactie op wat dingen die U aanstipt:

> Wat vooral naar voren komt is dat Gedcom onvoldoende ondersteuning biedt aan het

> verplaatsen van onze DATA items (namen, feiten o.i.d.) van het ene in het andere pakket.

In tegendeel, het is andersom! De bedoeling van de GedCom standaard is juist om uitwisseling van genealogische gegevens tussen allerlei pakketten mogelijk te maken. Het is echter aan de programmeurs om die specificaties goed na te leven, en helaas schort het daar wel eens aan. Soms uit slordigheid of gemakszucht, soms is het moedwillig en wil men dingen gewoon net even iets anders doen.

Een anecdotisch voorbeeld, hier is een zeer recente discussie op het ondersteuningsform van één zo'n pakket over één van de simpelste (maar weinig gebruikte) tags, nl QUAY (quality of data.) Dat zou een code met waardes 0 t/m 3 moeten zijn, maar zelfs dat leidt tot pagina's lange discussies. Een korte quote daaruit om de problemen te illustreren:

daj> I'm struggling to find anything authoritative on the QUAY tag

kiwi> You have found the ONLY authoritative text that exists for anything in Genealogy. It is

kiwi> not an area that contains any "rules". The GEDCOM spec is the only / nearest authority

kiwi> that exists, and those "rules" are ignored, bent, and broken everywhere, all the time.

> wat kun je nog verder doen om voldoende informatie over te hevelen of overgeheveld

> te krijgen, zodat in ieder geval geen informatie verloren gaat, op de langere termijn?

Publicatie in een ander (vrij) formaat is goed mogelijk, bv boekdruk of html pagina's.

> dat we de data zodanig invoeren, dat we het maximale eruit kunnen halen

> als we willen overstappen.

1. óf we wel willen overstappen, dat is zeer onzeker.

2. Feit is dat elk pakket z'n eigen GedCom dialect spreekt, en dat elk pakket zo z'n beperkingen heeft. Bij de overweging van zo'n overstap zou u eerst een uitgebreide test kunnen doen van GedCom compabiliteit tussen specifiek pakket A en pakket B. Maar wie neemt daar de tijd voor? En hoever moet je gaan in zo'n test? 

Het alternatief is namelijk om alleen de zgn "lowest common denominator" te gebruiken, dwz Gedcom constructies waarvan wel zeker is dat alle pakketten ze hetzelfde begrijpen. Dat houdt dan ook een versobering in van wat er wordt vastgelegd, dus nogmaals een compromis sluiten op het toch al redelijk stricte GedCom keurslijf.

> We willen in iedergeval toch dat onze nabestaande nog iets hebben

> aan onze uitgepluisde gegevens

Daar hoeft u zich geenszins zorgen over te maken. Zolang alle archieven met bronmateriaal maar beschikbaar blijven, is in de verre toekomst al uw werk en dat van anderen te reconstrueren. Ik ken nu al drie andere genealogen in mijn familie, en we komen allemaal onafhankelijk van elkaar op dezelfde gegevens omdat we allemaal uit dezelfde bronnen onze basis informatie halen. Het enige dat wij toe kunnen voegen, dat zijn gegevens die niet in een archief zijn vastgelegd, maar waarvan wij weet hebben omdat we de persoon in kwestie van dichtbij hebben gekend. Zo heb ik van mijn vader een foto album gekregen waarin hij net twee maanden voor zijn dood had aangetekend wie op welke foto stond. Zonder die aantekeningen zou het slechts een album met oude foto's van onbekende mensen zijn, maar nu is het een (voor mij) waardevol familiedocument.

> Let wel voor de gegevens die bijna niet onder te brengen zijn bij één of ander feit.

Daarvoor kunnen altijd nog Notes en Sources aan een persoon of familie worden toegevoegd. Ook bent u niet gebonden aan het handjevol facts/events die de heren Mormonen in Utah hebben bedacht. Er is een goedgekeurde constructie om een niet-standaard event vast te leggen:

1 EVEN 40 jarig dienstverband

2 TYPE Jubileum

2 DATE 01 NOV 1928

1 EVEN Protestantsche Zangvereeniging

2 TYPE Lid van

2 DATE 1889

2 PLAC Amsterdam, Noord-Holland, NL    

2 SOUR @S1350@

Maar of uw pakket dit ook soepel ondersteund kan ik niet bepalen.

BertKoor - 22 jan 2013 - 23:25

.

Herman - 23 jan 2013 - 22:29

.

Herman - 6 feb 2013 - 21:07

> de twee meest genoemde pakketten op dit forum. 

Welke waren dat eigenlijk? Ik gok dat één daarvan Aldfaer was.

>  wat je erin stopt komt er al niet hetzelfde uit (als structuur) en dat is op zich al verwonderlijk. 

Dat is geheel verklaarbaar. Elk pakket heeft z'n eigen interne datastructuur. Bij een GedCom import wordt die gevuld, en bij export gebeurt het omgekeerde zo goed als mogelijk. Maar al bij de import worden uw gegevens als het ware door de gehaktmolen gehaald. Het geëxporteerde GedCom bestand is dus een reconstructie. Het zal wel dezelfde gegevens bevatten, maar kan er net wat anders uit zien.

Bijvoorbeeld een valide naam in de kortste vorm:

1 NAME Johannes /van Veen/

Als ik in mijn eigen pakket deze aanmaak, dan ziet die er als volgt uit:

1 NAME Johannes /van Veen/

2 GIVN Johannes

2 SPFX van

2 SURN Veen

Dezelfde gegevens, maar een net wat andere representatie. Beiden zijn even valide. Het is maar net hoe betreffend pakket er mee om gaat. Besef ook dat de volgorde van gelijkgenummerde tags in het geheel niet uitmaakt.

Ik ken trouwens een pakket dat door z'n opzet garandeert dat wat er is geïmporteerd er bij GedCom export ook weer net zo uit komt: webtrees. Dat is een doorontwikkeling op PhpGedView. Elk record (Individual, Family, Note, Media, Source, Repository) bevat namelijk de GedCom representatie in z'n ruwe vorm. Deze is altijd de basis, en alle gegevens worden daaruit afgeleid. Dat heeft echter wel zo z'n nadelen. De ontwikkelaars van webtrees gaan in de volgende versie over op een geheel ander "genormaliseerd" database model, voornamelijk om het hunzelf makkelijker te maken. Ik verwacht dat ook dan de export er net wat anders uit ziet als wat was geïmporteerd.

> omdat ik in mijn Genealogische gegevens Geografische markeringen aan het meegeven ben

> in de data. van oude nog bestaande en niet meer bestaande adressen.

Leuk dat U dit aanstipt. Twee heel verschillende voorbeelden:

2 PLAC Wijk C, Schiedam, Zuid-Holland, NL

3 ADDR Boterstraat 84

2 PLAC Kaap de Goede Hoop, Op Zee

3 MAP

4 LATI S31.8833

4 LONG E31.5667

Ik had er voor kunnen kiezen om ook van het adres in Schiedam de coordinaten te bepalen, maar dat heb ik niet gedaan. Mijn pakket heeft de mogelijkheid te integreren met GoogleMaps. Zo kan ik ofwel GoogleMaps laten uitzoeken waar Schiedam op de kaart van Zuid-Holland ligt, of ik kan zelf centraal dus éénmalig opgeven wat de coordinaten van het oude centrum van Schiedam zijn. Dat voorkomt veel extra opzoekwerk, want die plek komt vele malen voor in mijn bestand. De GedCom standaard biedt daarvoor geen goede ondersteuning (zou mooi zijn als er een zevende record type Place bestond naast Individual, Family, etc) maar ondanks dat kan het pakket wel extra faciliteiten bieden.

BertKoor - 7 feb 2013 - 14:19

.

Herman - 10 feb 2013 - 21:46

Zoals ik al eerder aangaf, GedCom faciliteert niet-standaard gegevens via de algemene tags EVEN en FACT.

Betreft alternatieve spellingswijzen of historische plaatsnamen, die kan ik in GedCom formaat gewoon kwijt. Ik hanteer de moderne spelling en geografische indeling, eventueel verduidelijkt met een notitie. Voorbeelden:

2 PLAC Ouder-Amstel, Amstelveen, Noord-Holland, NL

2 PLAC Batavia, Djakarta, Java, Indonesië

2 PLAC Timisoara, Timis, Roemenië

3 NOTE Destijds Temiswar (Hongarije) en onderdeel Oostenrijks-Hongaars keizerrijk.

Niet ideaal, zeker niet voor herhalingen, maar het kan wel degelijk!

Het Kekulé, Ahnen of Sosa nummer is afhankelijk van wie het startpunt is van de kwartierstaat. Dat zal u meestal zelf zijn, maar kan mogelijk ook uw partner zijn of iemand anders. Alleen directe voorouders genoemd in de kwartierstaat hebben zo'n nummer; oom of tante, neven en nichten zullen het zonder moeten doen. Stel dat er ergens bij uw voorouders kwartierstaatherhaling voorkomt (bv huwelijk van (achter)neef en nicht) dan heeft u een conflict en zult u meerdere nummers aan één persoon moeten toewijzen.

Dit alles maakt zo'n nummer niet geschikt om op te slaan. Het is beter om deze pas te bepalen als de kwartierstaat zelf wordt gegenereerd.

BertKoor - 11 feb 2013 - 16:39

Idee: u kunt willekeurige gegevens opslaan in GedCom bestanden onder de tag DATA.

Zijlijntje: de titel van dit topic verwijst naar de GedCom 5.5 richtlijnen. Die zijn echter achterhaald, de meeste pakketten die nu op de markt zijn ondersteunen versie 5.5.1. Die is weliswaar nog officieus, er is alleen een "draft" versie (klad) gepubliceerd. Maar aangezien dat al meer dan 10 jaar geleden was, is deze toch door de meeste partijen geaccepteerd. Ondertussen schijnt er ook nog v5.6 te zijn. Op deze pagina van TamuraJones.net staat een overzichtje met de verschillen, het is niet echt wereldschokkend...

Op diezelfde site vond ik een interessante quote:

"The demand is exporting the data again into a valid GEDCOM file, adding nothing to and omitting nothing from the the data."

Ik schat in dat niet veel pakketten aan die eis voldoen, als je de geexporteerde gegevens vergelijkt met wat er geimporteerd is.

Een aantal andere artikelen van TamuraJones die de moeite waard zijn om te lezen:

A Gentle Introduction to GEDCOM

GEDCOM Validation

The Fan Value

What does GEDCOM X mean?

BertKoor - 12 feb 2013 - 16:07

.

Herman - 12 feb 2013 - 22:34

.

Herman - 14 mar 2013 - 22:16

Ik heb mijn gegevens van Gensdatapro over gezet naar Aldfaer,  Paf, Family-Treemaker, Broterskeeper, Genealogie-Online, Geneanet en My-Heritage en vele anderen omdat ze allemaal een andere uitvoer hebben en dat leuk is om te bekijken.

Het overzetten gaat feilloos en zonder problemen.

Ook opmerkingen, rubriek opmerkingen en bronnen gaan feilloos mee.

Uiteraard blijven het allemaal verschillende programma's en je kan niet van een gedcom programma verwachten dat het alles kan.

marcel van de krol - 27 mar 2013 - 16:39

Herman, sorry ik zie je bericht nu pas, en ook wat je hebt gemaakt.

Integratie met GoogleMaps, dat is iets wat mijn favoriete programma webtrees ook kan.

Zie bv pagina http://svn.webtrees.net/demo-stable/individual.php?pid=i7&ged=demo

en dan tabblad GoogleMaps.

Het schalen (inzoomen) is nog iets dat je zou kunnen verbeteren.

BertKoor - 27 mar 2013 - 16:55

.

Herman - 27 mar 2013 - 23:58


Sorry Herman, ik had de markeringen in Indonesië en Zui-Oost Azië over het hoofd gezien.

BertKoor - 28 mar 2013 - 12:07







Plaats een reactie

Om reacties (en nieuwe onderwerpen) te plaatsen op het Stamboom Forum dient u eerst in te loggen! Nog geen lid? Registratie is gratis en snel!


Inloggen Registreer nu