Ik weet dat er al meer berichtjes zijn geschreven over de gedcom-standaard. Toch wil ik (nogmaals?) aandacht vragen voor het probleem.
De aanleiding voor mijn vraag is de blog van Bob Coret en de daarin genoemde link om de Gedcom-kwaliteit van het door jou gebruikte stamboomprogramma, natuurlijk Aldfaer, te laten testen. Wat blijkt? Een grote rij foutmeldingen.

Wanneer een mogelijke doorontwikkeling van Aldfaer gaat plaatsvinden, hoop ik dat hierop wordt gelet.

Uiteraard ben ik bereid het foutenrapport ter beschikking te stellen aan geïnteresseerden.

Leuke bla bla zonder enige referentie welke Gedcom standaard gehanteerd wordt EN welke interpretaties aan diverse vrije tags toegekend zijn.
De laatste officiële versie is release 5.5 en gebruik van latere versies als b.v 5.5.1 (beta) is dus uit de boze. Als ik mij niet vergis is het laatste het geval bij Coret en kan men daarom bij een foutenrapport vele vraagtekens zetten..

Verder bestond er sinds december 2002 een Beta release 6.0 bedoeld voor XML verwerking. Deze ontwikkeling is stopgezet en vervangen door het project GEDCOM X.
Zie http://www.gedcomx.org/
De huidige beta versie wordt aangegeven als: "GEDCOM X Date 1.0"

N.B de oude site www.gedcom.org waar gedcom 6.0 naar refereerde is opgeheven en het domein staat te koop

Nu is de heer Coret een "founding member" van de FHISO organisatie die ook een gedcom model schijnt te ontwikkelen. Beide organisaties refereren naar het Dublin Core Date and Time Requirements Wiki, maar geven niet aan of en in welke mate dit gevolgd wordt.

2 Organisaties die een nieuwe "standaard" Gedcom ontwikkelen?
Naar mijn mening, maakt dat de puinhoop alleen maar nog groter. Overigens een standaard wat, naar mijn weten, op dit moment geen enkel programma kan verwerken. Ik kan er echter naast zitten...

Kortom werk aan een programma dat gedcom 5.5 en/of beta 5.5.1 kan verwerken is dus nu tijdverspilling en de vermelde blog lijkt derhalve een beetje op mosterd na de maaltijd

Voorzover ik kan nagaan is de website waarnaar Bob Coret verwijst om je Gedcom-bestand te laten valideren NIET van hem.

Als ik het goed gelezen heb, wordt op die website de aangeleverde gedcom gelezen en op basis van de aangegeven Gedcom-versie wordt dan een "foutenrapport" gemaakt.

Zo bleek dat bestandsnamen van gekoppeld materiaal uit maximaal 30 tekens mogen bestaan...

Dat betreft in feite "invoerfouten" door de gebruiker en de gevolgen in een Gedcom. Een bestandsnaam wordt buiten Aldfaer gegenereerd en is derhalve niet de verantwoording van Aldfaer. Een wens zou kunnen zijn dat op het moment van het maken van een koppeling Aldfaer, indien dat mogelijk is, de lengte van de bestandsnaam kontroleert

Voor de duidelijkheid Gedcom 5.5: 30 tekens plus een punt gevolgd door 3-4 voor bestandstype (jpeg, bmp, pict etc)

Uit de Gedcom 5.5 release:
MULTIMEDIA_FILE_REFERENCE: = {Size=1:30}
A complete local or remote file reference to the auxiliary data to be linked to the GEDCOM context. Remote reference would include a network address where the multimedia data may be obtained.

MULTIMEDIA_FORMAT: = {Size=3:4}
[ bmp | gif | jpeg | ole | pcx | tiff | wav ]
Indicates the format of the multimedia data associated with the specific GEDCOM context. This allows processors to determine whether they can process the data object. Any linked files should contain the data required, in the indicated format, to process the file data. Industry standards will emerge in this area and GEDCOM will then narrow its scope.

Voor meer zie: http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gctoc.htm

Gedcom, die goede oude standaard van weleer is toch al lang ter ziele!!

Ik snap de Bob Coret ook niet met zijn hele gefussel. Degenen die gedcom bestanden testen op een DRAFT gedcom standard zijn ook niet zo goed bezig want daarmee 'verheffen' ze een niet goedgekeurd ontwerp als standaard.

Over de vermeende fouten in de 5.5 heb ik ook nog niet zoveel gehoord dat informatie verloren is gegaan. Ook niet als er te lange bestandsnamen zijn gebruikt. Wordt de gedcom gebruikt door een andere Aldfaer gebruiker dan is er al helemaal geen probleem.

Dan de vermeende fout van de ASO structuur. Die zie ik niet zitten, ook niet als ik de 5.5 daar nog eens op nalees.

En er zijn inderdaad mensen die hele verhalen maken van een image bestand. Aldfaer heeft daar geen moeite mee maar als iemand een bestandsnaam "Dit is een foto van Pietje toe hij nog 5 jaar oud was. Hij ging toen naar school bij de broeders.jpg" maakt dan zet ik daar toch een vraagteken bij, zeker voor wat betreft de efficiency.

Han,
Dat gedcom allang ter ziele is, is volgens mij gedeeltelijk waar. Zolang er geen goed alternatief is en iedereen het nog zal "moeten" gebruiken om gegevens te transporteren tussen stambomen en stamboomprogramma's, is het een slapend mechanisme (of zo je wilt: op sterven na dood).
Welk systeem gebruik je dan?
Dus wat mij betreft wordt gedcom nog in leven gehouden totdat de opvolger is geboren.

Terzijde: de bestandsnamen van mijn materiaal bestaan "slechts" uit de namen van de personen plus geboortejaar en type.
janssen_hendrik_cornelis_1883_en_klaassen_margaretha_1890_zerk.jpg

Dit doet denken aan discussies uit het verleden, of Aldfaer het programma is waarin/aan je grote hoeveelheden documenten moet koppelen. Als aanvulling op het programma zelf, voor bv presentatie volstaan m.i. enkele foto's of documenten
Met een goed opslagsysteem kan je de documenten en foto's los van Aldfaer houden waarbij er geen noodzaak is grote hoeveelheden materiaal te transporteren via Gedcom

Jan,

In een gedcom wordt er geen materiaal meegenomen, alleen de link naar het materiaal wordt in de gedcom meegenomen, het materiaal zelf staat in een aparte map buiten het Aldfaer prog.

guidovanh,
Als het programma van Bob Coret last heeft met de import van een aldfaer gedcom hoeft hij enkel zijn programma aan te passen aan de Aldfaer gedcom en niet omgekeerd.

Volgens mij is het geen programma van Bob Coret, maar een dienst waarnaar Bob verwijst. Voorzover ik heb begrepen, controleert deze dienst alleen maar of de gedcom aan de standaard voldoet. Ik heb te weinig verstand van die standaard, maar als die standaard aangeeft dat een bestandsnaam (van het materiaal) max. 30 tekens mag zijn, dan is het geen fout van de gedcomfunctie van Aldfaer noch een fout van de service waarnaar Bob verwijst, maar een fout in het stamboombestand, in dit geval dus mijn eigen data (en daarbij laat ik in het midden dat ik nog nooit problemen heb gehad met te lange bestandsnamen ofzo).

guidovanh,

Welk probleem ???
Ik heb nog nooit een probleem gehad met het inlezen op het net met een Aldfaer gedcom.
Als er een probleem is met het inlezen van een Aldfaer gedcom op het net graag wat specifieker wat er mis is.
Alleen de melding dat er een probleem is daar heeft niemand iets aan.

Ok, toegegeven, "probleem" is een te groot woord.
Zoals Bob Coret in zijn blog schrijft: "Als we één liter melk kopen verwachten we één liter melk.", zo ook: "als Aldfaer in zijn geëxporteerde gedcom schrijft dat het een versie 5.5-bestand is, dan moet het ook aan de voorwaarden voldoen van versie 5.5.

Guido,
"Het" probleem is dat Gedcom 5.5 aan diverse tags een vrijheid aan interpretaties toelaat en derhalve geen waterdichte specificatie = standaard verschaft.

Gezien het feit dat nu twee organisaties een nieuwe "standaard" ontwikkelen heb ik, zoals reeds eerder aangegeven, niet veel hoop dat een echte uniforme standaard gaat ontstaan.
Natuurlijk kan men hopen, mijzelf ingesloten, dat ik mij vergis...