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.