Le format GEDCOM et son évolution

[thetienne]

Bonjour Jerome,
Par rapport à la question "pourquoi le format GEDCOM n'évolue pas et pourquoi les tags/implémentations propriétaires pullulent - (suite https://www.geneanet.org/forum/viewtopic.php?f=55945&t=639545&p=1590769#p1590769 )

Certains monnayent des outils pour importer des données d'un programme (TMG) vers du gedcom !!!
...
Un outil expérimental (gratuit) existe. Il n'est pas forcément complet, mais cela illustre que
la valeur (temps/coût) peut être secondaire quand on évoque les données !

TMG (The Master Genealogist) est un programme de généalogie spécifique qui a un modèle de donnée qui pose un certain nombre de problème par rapport au modèle GEDCOM. Comme le logiciel n'est plus maintenu (http://archive.constantcontact.com/fs140/1105531002059/archive/1118052201942.html ) forcément il y a un besoin de conversion de données (et certains peuvent en profiter…)

Mon propos était plus général et parlait du modèle sous-jacent du GEDCOM qui est résumé à la fin de la norme 5.5. (n'apparait plus dans le draft 5.5.1) : cf https://www.familysearch.org/developers/docs/gedcom/
A partir du moment où le modèle objet doit évoluer (je ne parle par de sa sérialisation en Gedcom, Gedcom-X, XML, Json ou autre) doit évoluer il y a un coût de développement associé pour les acteurs du marché. Pour que cela soit "rentable" il faut qu'il y a un gain fonctionnel qui permette de vendre cela (que les utilisateurs y voit un gain fonctionnel).

Pour moi c'est le problème de la norme GEDCOM-X, le cout de développement pour y passer est forcément important (évolution du modèle de donnée). Je dis juste que les principaux acteurs des logiciels de généalogie doivent investir et comme c'est lourd pour un gain fonctionnel très faible (au moins au début) je pense qu'ils ne l'utiliseront pas. Pour moi, une norme qui n'est pas appliquée rapidement est morte. (c'est probablement le cas de GEDCOM-X même si il y a quelques commit pour montrer une activité…)

L'annonce du gedcom 5.5.5 semble être une tentative de prouver que le gedcom permet encore de tout faire et qu'il n'est plus dans les mains des mormons.
… Le format gedcom c'était il y a 20 ans. On peut toujours nous vendre le format de la "maturité", c'est le format de Windows 95 et MS-DOS !

C'est une tentative louable qui fait le ménage dans la norme et impose l'Unicode (même si certains point sont discutables). Dans l'esprit de ses rédacteurs, c'est pour, par la suite (on verra bien), permettre de faire évoluer ce standard; Comme il n'y a pas de gain fonctionnel pour l'implémenter, je doute que les principaux acteurs l'implémentent (ils n'implémentent déjà pas le 5.5.1 et pour certains même pas complétement le 5 5)

Certes la norme GEDCOM a été créée à l'époque des premiers PC et de Windows 95 mais ce n'est pas en rien le format de Windows 95 et MS-DOS. C'est un format de sérialisation en texte comme le XML; YAML, JSON ou autres… Ce n'est pas parce qu'il n'a pas de "balises" qu'il ne vaut rien (si il dure c'est même le contraire !). Rien n'empêche de faire évoluer cette norme. En généalogie, où on a besoin de stabilité dans le temps, on peut même se dire qu'il est souhaitable d'avoir un format qui dure.

Les formats de sérialisation en texte sont tous +/- fugitifs dans le temps et sont très liés à la techno du moment. On peut faire une photo tous les 10 ans pour voir les nouveaux et ceux qui ont disparus. Il n'y en a pas de bon ou de mauvais.

Sauf que depuis 20 ans, le support des caractères dans le gedcom reste aléatoire,

Il n'est pas aléatoire, certains programmes ont des bugs et d'autres n'implémentent pas tous les jeux de caractères (en particulier Unicode et ses variantes). Les valeurs possibles du tag CHAR sont, certes, à mettre à jour dans la norme.

le calendrier (grégorien/julien) limite les dates pour les pays hors Europe/USA, les images, les vidéos,

Je ne vois pas pourquoi : Le format GEDCOM
- supporte aussi le calendrier hébraïque (DHEBREW) et il est possible de mettre une date en texte et il pourrait être utilisé avec un calendrier hégirien ou les autres calendriers orientaux (chinois, hindou, etc... )
Il est certes de base "occidentale" mais rien n'empeche son évolution (techniquement mineure) pour ajouter ces calendriers. Si le jeu de caractère ne pose plus de problème (unicode), le problème est plutôt qu'il faudrait des logiciels de généalogie prenant en compte ces cultures (et l'impact sur le modèle de donnée)
- supporte le lien vers des fichiers images, videos ou autre. Vu la taille de ces fichiers, il ne faut pas qu'ils soient dans le fichier décrivant une généalogie (ce serait absurde)

les mœurs contemporaines, etc

Oui c'est le problème du modèle de donnée qu'il faut faire évoluer de manière ascendante pour pouvoir en définir une sérialisation correcte. (quel que soit le format de sérialisation)

Le problème c'est la modélisation des échanges de données généalogique et pas le format de sérialisation associé. (il ne faut pas faire la confusion).
Bref il est nécessaire de faire évoluer ou remplacer la norme GEDCOM. La question est de savoir par où et comment commencer… (pour que cela ait une chance d'être adopté par la communauté (*) )

Cordialement
Thierry
(*) peut être faut-il s'inspirer du format PDF quant à la manière de s'imposer

[bricor]

Bonsoir,

ce sujet ne concerne pas le forum du bistrot et puisque vous semblez vous adresser à l'assistance je le place dans le forum des questions techniques diverses.

Merci de votre compréhension.

Brigitte

[thetienne]

ce sujet ne concerne pas le forum du bistrot et puisque vous semblez vous adresser à l'assistance je le place dans le forum des questions techniques diverses.

Bonjour Brigitte,
Pourquoi pas mais ce n'est pas une question "technique" au sens "trouver une solution technique immédiate", comme je l'indique dans la conclusion "il est nécessaire de faire évoluer ou remplacer la norme GEDCOM. La question est de savoir par où et comment commencer…". La question est plus générale "qu'est ce qu'il faudrait faire pour qu'une nouvelle norme d'import/export de donnée généalogique" soit adoptée/promulguée ?
(plusieurs ont essayé et aucun n'a réussi à imposer une nouvelle norme)

L'assistance technique Geneanet peut bien sûr participer à ce débat qui englobe plus que Geneanet. Je ne m'adresse pas spécifiquement à l'assistance Geneanet.

Cordialement
Thierry

[forhanp]

Bonjour,

Bref il est nécessaire de faire évoluer ou remplacer la norme GEDCOM. La question est de savoir par où et comment commencer… (pour que cela ait une chance d'être adopté par la communauté (*) )
(...)
(*) peut être faut-il s'inspirer du format PDF quant à la manière de s'imposer

Les normes ne s'imposent que :
- Quand elles sont imposées (ouah, ça c'est de la lapalissade en règle)
- Quand elles viennent combler un vide
- Quand elles sont supportées par les leaders du marché.

Est-il possible d'imposer un format à l'heure actuelle ? Clairement non, il n'y a pas d'autorité compétente en la matière.
Les nouvelles versions comblent-elles un manque ? Non, puisque le format GEDCOM 5.5/5.5.1 permet les échanges entre logiciels, (notamment à l'import, puisque le but de chaque logiciel est d'attirer les données et pas de les envoyer à d'autres supports).
Ces nouvelles versions sont-elles supportées par les leaders du marché ? Pas vraiment, aucun logiciel ou site avec une présence forte au niveau international ne supporte les nouvelles versions (Je crois que même Familysearch ne supporte pas les imports au format GEDCOM-X, comme ils ont changés de philosophie avec leur arbre commun, je doute que les exports fonctionnent).

Bref, une évolution du GEDCOM ne pourra pas avoir lieu sans une réelle avancée fonctionnelle et sémantique qui permettrait de transférer un vrai manque dans les données actuelles.
Et personnellement, je ne vois pas ce que cela pourrait être vu le type de données manipulées par la généalogie.

Cordialement,

[bricor]

Bonjour Jerome,
....................................
Thierry

ce sujet ne concerne pas le forum du bistrot et puisque vous semblez vous adresser à l'assistance je le place dans le forum des questions techniques diverses.

Bonjour Brigitte,
Pourquoi pas mais ce n'est pas une question "technique" au sens "trouver une solution technique immédiate", comme je l'indique dans la conclusion "il est nécessaire de faire évoluer ou remplacer la norme GEDCOM.
..............
Thierry

Bonjour Thierry,

je ne m'intéresse pas au problème du gedcom, je n'en fais pas, mais du moment que vous écrivez en commençant par "Bonjour Jérôme", je classe cela dans les problèmes techniques.

Cordialement

Brigitte

[romjerome]

Bonjour Étienne,

Désolé, demandez au tiers-sachant, il pourra vous éclairer en réécrivant l'histoire;
ce sujet ne me concerne plus.

Cordialement,
Jérôme

[forhanp]

Bonjour,

Après un échange de gedcom, mes cousin*e*s éloigné*es peuvent apprécier de savoir qu'il existe un fichier supplémentaire quelque part sur mon espace de stockage. Est-ce une fonction utile ?

Rien ne vous empèche de mettre ces données en ligne et que le lien pointe sur ces données en ligne.
C'était l'idée initiale de cette adresse dans les fichiers GEDCOM.
Il s'avère que peu de logiciels exploitent véritablement cette possibilité.

Est-ce que le gedcom est un format d'échange ou de sauvegarde ?

Il n'y a pas photo : c'est un format d'échange destiné aux données qui peuvent être traitées par le logiciel du concepteur.
Aujourd'hui on parlerait de définition d'API.

Si vous réalisez une synthèse avec ce qui n'est actuellement pas partagé entre les logiciels et portails, alors vous obtiendrez plus ou moins mon point de vue sur ce qui ne va pas ou manque au gedcom pour être une norme d'échange (et plus si affinités !).

Le GEDCOM permet déjà tout cela.
Sauf qu'il s'agit de tags définis par le logiciel qui les emploient et de ce fait ne seront pas forcément compris par un autre logiciel.
Ce n'est d'ailleurs pas si grave que cela car une bonne partie des informations ne sont pas présentes dans d'autres logiciels.
Typiquement la gestion des lieux est une spécificité de Gramps qu'aucun autre logiciel à ma connaissance ne gère de cette façon.
Qu'il n'y ait pas de support officiel dans le GEDCOM pour une gestion particulière semble plus que naturel.

Cordialement,

[romjerome]

[..]

[forhanp]

Bonjour,

Et oui, le gedcom se permet un peu tout sauf que sans instructions il ne permet rien d'efficace...
Dire aux utilisateurs de faire confiance au format gedcom puis éditer manuellement ou
ne pas tenir compte des limites cela ne va pas dans le bon sens.

J'aimerai bien voir la réaction des utilisateurs de geneanet si Gramps exportait toutes les données de la base dans le pseudo-language gedcom !
Elles seront alors importées dans des notes... Effectivement il y a plus grave, mais il y a plus beau et propre, non ?

Il y a deux aspects dans votre remarque :
La première c'est que l'export de Gramps (et d'autres logiciels) ne permet pas d'exporter l'ensemble des informations de la base de données.
Cela provoque un hiatus entre les données exportées et le contenu réel.

La deuxième, c'est que le logiciel de destination décide de sa façon dé gérer les données, qu'elles soient conformes à la norme ou non.
Par exemple, certains tags ne sont pas importés de manière cohérentes par Geneanet (il me semble avoir vu une discussion sur le tag RESI https://www.geneanet.org/forum/viewtopic.php?f=11&t=607988 ). Il s'en suit que si on demande un export GEDCOM à partir de Geneanet, il ne sera pas identique au GEDCOM fourni en entrée.

Pour l'export, c'est chaque logiciel qui suit sa procédure et décide ce qu'il exporte.
Pour l'import, c'est pareil.
Là où on peut critiquer pas mal de logiciels, c'est qu'ils ne sont pas capables de relire ce qu'ils ont eux-mêmes exportés.

En tout état de cause, je verrais d'un bon œil Gramps exporter l'ensemble de ses données et pouvoir les ré-importer à l'identique.
Et pas seulement dans le format maison.

Cordialement,

[romjerome]

[..]

[romjerome]

[..]

[thetienne]

Bonjour Pascal et Jerome,

Bref, une évolution du GEDCOM ne pourra pas avoir lieu sans une réelle avancée fonctionnelle et sémantique qui permettrait de transférer un vrai manque dans les données actuelles.
Et personnellement, je ne vois pas ce que cela pourrait être vu le type de données manipulées par la généalogie.

Je suis d'accord, c'est bien la question que je me pose. Je pense qu'une nouvelle norme ne peut s'imposer que si
- elle est compatible ascendante avec la précédente (5.5.1); donc implique forcément une sérialisation "à la GEDCOM"
- elle standardise les "relations" manquantes dans la norme
- elle standardise les "lieux" pour éviter les problèmes de décodage
- elle étend les "sources" aux sources modernes (la norme actuelle ne traitant réellement que les registres)
- elle traite plus proprement le sujet des surnoms/alias/etc... (norme actuellement ambiguë)
- …

Il faudrait arriver à une liste de besoin des utilisateurs et partir de là définir un modèle de donnée compatible ascendant.
La norme permet certes de décrire n'importe quoi (éventuellement en note…) et c'est bien pour cela quelle dure.

Il y a eu plusieurs "normes alternatives" proposées (et qui ne ce sont pas imposées) et qui sont mort-nées (comme GEDCOM-X probablement). Il faut donc forcément changer de méthode.

C'est pour cela que je pense qu'il faudrait que tous les utilisateurs expriment leur besoin d'échange de donner pour essayer de definir une extension de la norme GEDCOM à partir du besoin utilisateur. Ce qui offrirait peut être une plus grande chance de l'implémenter et un plus grand intérêt de tous.

Cordialement
Thierry

[romjerome]

[..]

[romjerome]

[..]

[forhanp]

Bonjour,

Sérieusement, c'est juste un langage et des définitions "pré-internet" !

Remplacez les numéros en début de ligne par des accolades si le numéro est supérieur au précédent et une accolade fermante si le numéro est inférieur au précédent et mettez 2 points après chaque tag, mettez une virgule à la fin de chaque ligne, vous aurez un fichier JSON très acceptable. Le JSON une structuration de données très actuelle.
Le formalisme de présentation n'influe pas sur la structuration des données.
On pourrait même faire un fichier XML du GEDCOM sans difficulté.
Le logiciel Ancestris utilise d'ailleurs une DTD pour valider la structure du GEDCOM. Comme quoi, un GEDCOM c'est un fichier XML qui s'ignore.....
"L'avantage" du GEDCOM c'est que le sucre syntaxique est très limité comparé au XML au YAML ou au JSON.

Les efforts sont louables pour donner des directions, pour maintenir une forme de vie,
par exemple avec l'encodage.

Il est tellement facile de générer un gedcom avec des erreurs qu'il ne faut pas trop attendre des versions 5.5 et inférieures ...

A partir du moment où c'est un fichier texte, n'importe qui peut ajouter ou supprimer des choses dans la structure et en faire un fichier pourri.
C'est valable pour tous les fichiers.

Cordialement,