Réflexions sur le module Import/Export GEDCOM d'Ancestrologie
Pour ceux qui ne connaissent rien à la structure d'un fichier GEDCOM, faites un petit tour chez Joël
J'ai plongé dans la norme GEDCOM 5.5 (ici) que j'ai lu et relu plusieurs fois. Au cours de cette exercice je me suis aperçu qu'Ancestrologie semblait ne pas suivre la norme dans certains cas et que dans d'autres il semblait y avoir une erreur de traduction ou de compréhension. Vous trouverez ci-dessous le fruit de mes réflexions et quelques suggestions qui devrait permettre de rentrer au maximum dans la norme. J'ai pu, moi aussi, mal comprendre ou mal interpréter la norme GEDCOM 5.5. Dans ce cas inutile d'entamer une polémique, exposez votre point de vue et nous devrions pouvoir extraire la "substantifique moelle".
Dans tout ce qui suit, je ne cherche pas à critiquer Ancestrologie, ni à polémiquer, ni à imposer quoique ce soit à qui que ce soit, juste à apporter ma modeste contribution dans l'amélioration des fonctionnalisés de mon logiciel préféré :Ancestrologie
Le 5 mars 2008 toutes les "anormalités" du GEDCOM ont été corrigées ce qui permet à Ancestrologie de devenir le meilleur programme pour gérer des données généalogiques car il est toujours le seul, à ma connaissance, qui utilise un vrai SGBDR (RDBMS) et un SQL standard.
Structure des lieux
Actuellement les lieux (PLAC) sont divisés en six champs selon la structure Ville , Code Lieu , Département , Région , Pays, Subdivision
Or dans le descriptif de la norme GEDCOM 5.5 il est précisé que les éléments d'un lieu doivent être classés du plus précis vers le plus général (ici). Subdivision devrait donc se trouver normalement en première position cependant pour des raisons de compatibilité avec d'autres logiciels c'est la dernière position qui est le meilleur choix. Rappelons qu'il est très facile de modifier l'ordre de la structure PLAC à l'aide de l'utilitaire GedLieu
Ancestrologie définit un champ Lieu qui n'existe pas dans la norme GEDCOM 5.5. Ce champ est exporté en GEDCOM en utilisant un artifice qui le rend incompatible avec tous les autres programmes de généalogie. Je ne peux donc que conseiller d'éviter d'utiliser ce champ.Tags qui n'existent pas.
Ancestrologie utilisait des tags qui n'existaient pas dans la norme GEDCOM 5.5 mais ceci a été corrigé à partir de la version 2008.0.0.780
Il est possible de créer des tags spécifiques à un programme qui doivent, pour être conforme à la norme (ici), commencer par un underscore ( _ ). Ancestrologie respecte cette synthaxe.
ALIV Vivant (Le bon Tag est l'inverse mort 1 DEAT Y)
Merci de le supprimer de la liste des TAGs GEDCOM
BENE Bénédiction (Le bon Tag est BLES) BRIT Brit Mila (utiliser EVEN / TYPE) COMU Communion (utiliser EVEN / TYPE) CTY Ville - Faute de frappe qui semble limitée à la liste déroulante (le bon Tag est CITY) DECO Décoration (utiliser EVEN / TYPE) DIPL Diplôme devrait utiliser GRAD (dble emploi avec Niveau de Diplôme qui semble une mauvaise traduction : devrait être Niveau d'Instruction) FILA* Filiation (voir ci-dessous) INHU Inhumation qui se traduit par BURIal (dble emploi avec Sépulture qui veut dire la même chose) LIEU Lieu, Lieu-dit, paroisse... (voir ci-dessus) INSEE Code INSEE LEGA Légataire (utiliser EVEN / TYPE) MILI Service militaire (utiliser EVEN / TYPE) PURC Acquisition (utiliser EVEN / TYPE) SACR Sacre (utiliser EVEN / TYPE) SALE Ventes (utiliser EVEN / TYPE) STAT Etat / Département (le bon tag est STAE) TEL dans les adresses - devrait être PHON (corrigé à partir v2.1.0.2) TITR Titres de noblesse (le bon tag est TITL) TRIP Voyage long (utiliser EVEN / TYPE) VOYA Voyage (utiliser EVEN / TYPE) TYPU Type Union X_MU1 devrait utilser EVEN / TYPE X_MU2 devrait utilser EVEN / TYPE X_MU3 devrait utilser EVEN / TYPE
XHENN devrait utilser EVEN / TYPE XHOUP devrait utilser EVEN / TYPE XLOI devrait utilser EVEN / TYPE XSPO devrait utilser EVEN / TYPE XORD devrait être du style _ORDR
* Il me semble que les valeurs de FILA devraient être positionnées dans la description de l'événement naissance.
Filiation Commentaires Enfant adopté devrait être un événement Adoption (donc à supprimer) Enfant adultérin correspond bien à une naissance adultérine Enfant légitime valeur "normale" d'une naissance Enfant légitimé comme "enfant reconnu" devrait être un événement (donc à supprimer) Enfant mort-né bien lié à la naissance Enfant naturel bien lié à la naissance Enfant reconnu comme "enfant légitimé" devrait être un événement (donc à supprimer) Enfant trouvé c'est en effet la date de la "trouvaille" qui sert bien souvent de date de naissance Filiation inconnue La filiation est bien lié à la naissance
Dans la norme GEDCOM 5.5 il y a deux structures liées à l'individu (ici):
la Structure_des_attributs_de_l'individu et la Structure_des_événements_individuels.
Ancestrologie les a réuni en une seule structure ce qui crée quelques soucis et confusions (sans compter une troisième structure liée aux événements Mormons qui n'a pas été prise en considération ici).Structure_des_attributs_de_l'individu
Cette structure (ici) enregistre des caractéristiques simples qui ne sont, en principe, pas liées à un lieu ou une date. Elle utilise la syntaxe suivante :
n [ XXXX ] <données selon Taille>
+1 <détails de l'événement>où XXXX peut prendre les valeurs du tableau ci-dessous.
Il n'y a pas de problème sur cette structure dans Ancestrologie qui prend pour <données selon Taille> le contenu du champ "desc."
Ne figure pas dans le tableau ci-dessus le tag RESI (domicile) qui n'a pas de <données selon Taille> (donc RIEN derrière RESI ). Il me semble que c'est ce tag qui devrait être utilisé en niveau 1 pour les données contenues dans l'onglet Domiciles. Une structure adresse est en effet disponible sous <détails de l'événement> (4ème ligne ici et structure là)
Ancestrologie respecte cette synthaxe à partir de la version 2008.0.0.780
Il me semble cependant que l'usage de la structure adresse, serait malgré tout préférable pour RESI.
Le tag IDNO (ici) (N° d'identification) doit obligatoirement être suivi par un TYPE (au niveau +1) pour préciser quel genre de N° est enregistré. Il me semble que c'est ce tag que devrait utiliser notre N° de SS dans Ancestrologie car le tag SSN n'a pas la taille voulu (de 9 à 11 car) et semble réservé aux USA. Problème il manque un champ ou les étiquettes de ceux existants ne sont pas explicites.
Exemple :1 IDNO 1450699365078
2 TYPE Numéro de Sécurité Sociale (France)
Structure_des_événements_individuels
Cette structure (ici) enregistre les événements qui ont émaillé la vie d'un individu. Elle utilise la syntaxe suivante :
n [ XXXX ] [Y ou RIEN ]
+1 <détails de l'événement>où XXXX peut prendre les valeurs du tableau ci-dessous.
* Un événement recensement CENS existe aussi dans la Structure_des_événements_familiaux
La présence d'un tag DATE et/ou d'un tag PLACe dans <détails de l'événement> remplie l'affirmation de Quand et/ou Où l'événement a eu lieu, et par conséquence que cet événement est bien arrivé. (troisième paragraphe ici)
L'absence de ces deux tags impose la valeur Y(es) sur la ligne du tag parent pour certifier que l'événement a bien eu lieu.
La syntaxe précise bien (ici) qu'il ne peut y avoir après le tag que Y ou RIEN (même pas un Null).
Ancestrologie est conforme à cet usage à partir de la version 2008.0.0.780
En plus des tags figurant dans le tableau il existe un tag EVEN (traduit par Divers) et que je traduirais plutôt par "événement libre". Ce tag EVEN doit être utilisé seul sans RIEN derrière (même pas de Y) et doit obligatoirement être suivi par un TYPE <description de l'événement> (au niveau +1).(voir bas de page ici et là) La description de l'événement doit être utilisée chaque fois que le tag EVEN est utilisé, pour définir l'événement cité.
Par exemple, si l'événement est l'achat d'une résidence, le tag EVEN sera suivi d'un tag TYPE subordonné avec la valeur "Achat d'une résidence".En conséquence tous les tags qui n'existent pas, devraient pouvoir être remplacés par un "événement libre" EVEN à condition de contrôler que le champ <description de l'événement> à bien été rempli.
Ce qui donnerait, par exemple, pour une Brit Mila :
1 EVEN
2 TYPE Brit Mila
Cette structure est utilisée par Généatique 2000, Hérédis et Cumberland Family Tree au moins.
Ancestrologie utilise correctement cette structure à partir de la version 2008.0.0.780Adoption et filiation
Dans le paragraphe précédent aurait du figurer un tag de plus, celui de l'adoption ADOP. Ce tag demandant une gestion un peu spéciale, il a été séparé des autres. Tout d'abord l'adoption fait bien parti de la Structure_des_événements_individuels et non pas de la Structure_des_événements_familiaux objet du paragraphe suivant..
Sa syntaxe est la suivante :n [ ADOP ] [Y ou RIEN ]
+1 <détails de l'événement>
+1 FAMC @<Pointeur_famille>@
+2 ADOP <parent>où la valeur de parent peut être: HUSB (conjoint), WIFE (conjointe) ou BOTH (les deux) (ici)
Cette structure n'existe pas dans Ancestrologie et nécessiterait une modification de la fenêtre liée à cet événement.Il existe enfin un tag PEDI subordonné au Lien_famille_enfant (ici) (FAMC) qui permet de caractériser l'appartenance à la famille_enfant (FAMC) (ici)
Ce tag PEDI peut prendre les valeurs suivantes : famille de naissance (birth), d'adoption (adopted), d'accueil (foster) et enfin ????? (sealed).[ Le terme sealed est lié à la religion des Mormons et je n'en connais pas la signification].
Cette syntaxe est utilisée systématiquement par Cumberland Family Tree.
1 FAMC @<Pointeur_famille>@
2 PEDI birth
Cette structure n'existe pas dans Ancestrologie
Structure_des_événements_familiaux
Dans la norme GEDCOM 5.5 le tag MARR est défini (voir MARR ici) comme l'événement légal, de concubinage (common-law) ou coutumier (customary) créant une unité familiale (famille) composée d'un homme et d'une femme comme mari et femme. Il ne faut donc pas comprendre mariage (qui est trop restrictif) mais UNION (même si celle-ci est très fugace comme dans le cas de Relations extra-conjugales).
A partir de là, la norme GEDCOM 5.5 offre un certain nombre d'événements pour définir les événements liés à la famille.
La Structure_des_événements_familiaux (ici) est la suivante :
n [ XXXX ] [Y ou RIEN ]
+1 <détails de l'événement>
où XXXX peut prendre les valeurs du tableau ci-dessous.
* Un événement recensement CENS existe aussi dans la Structure_des_événements_individuels
La présence d'un tag DATE et/ou d'un tag PLACe dans <détails de l'événement> remplie l'affirmation de Quand et/ou Où l'événement a eu lieu, et par conséquence que cet événement est bien arrivé. (troisième paragraphe ici)
L'absence de ces deux tags impose la valeur Y(es) sur la ligne du tag parent pour certifier que l'événement à bien eu lieu.
Il est donc obligatoire d'écrire 1 DIV Y ou 1 MARR Y si ni la date ni le lieu ne sont connus.
Il existe aussi un TYPE <description de l'événement> applicable à chacun de ces événements et la norme GEDCOM 5.5 précise même "le tag MARR peut être complété d'un tag TYPE <description de l'événement>. Les valeurs possibles pour <description de l'événement> peuvent comprendre "Concubinage", "Coutume tribale" ou "Naissance hors mariage" (Childbirth unmaried) par exemple" (ici). A noter que "Naissance hors mariage" semble bien corespondre aux relations extra-conjugales ou à une "union" du même type
C'est donc là, me semble-t-il, qu'il faudrait mettre le type de l'union.
Les valeurs de la liste déroulante dans Ancestrologie sont donc toutes correctes sauf "séparés" qui ne devrait pas figurer dans cette liste. Il me semble aussi que "Mariage" serait plus logique que "Mariés".
Ce qui donnerait donc pour un Concubinage :
1 MARR
2 TYPE Concubinage
Ancestrologie est conforme à cette synthaxe à partir de la version 2008.0.0.780
Enfin il existe aussi un "événements libre" EVEN qui se gère exactement comme celui utilisé dans la Structure_des_événements_individuels.
Structure_association
Cette structure (ici) (ASSO) permet de relier des amis, des voisins, des parents ou des personnes associés à un individu (voir ASSO ici). Cette structure est normalement exclusivement liée à l'individu et ne devrait donc pas être utilisée avec les événements (ici).
Cependant, comme la norme GEDCOM n'a rien prévu pour traiter les témoins des événements, il semble "légitime" de gérer les témoins des événements individuels ou familiaux en utilisant cette structure.
Ancestrologie utilise cette structure à partir de la version 2008.0.0.780
ATTENTION : cette structure ne comporte pas de TYPE.
Quelques relations sont plus "importantes" que les autres : le parrain, la marraine et le (ou les) parent(s) adoptif(s).
Soit quatre personnages (au maximum) qui, s'ils existent, devraient être mis en évidence dans la fiche Individu sans être obligé d'ouvrir un événement pour les trouver. Cette disposition permettrait, en outre, la navigation de la fiche d'un enfant adoptif vers celles des membres de sa famille adoptive.
Le "livre bleu" en bas dans la rangée de bouton pourrait être modifié pour montrer tous les "relations" (RELA) de la personne avec d'autres personnes de la base.