Sujet: Question sur TAGS gedcom

[Ancestrologie]

Bonjour

comme vous avez pu le constater, le GEDCOM est en refonte, pour etre aux normes 5.5, vu que c est la dernière norme et que la 6 n est plus à l'ordre du jour

Quelle est la norme de nommage pour les TAGS propriétaires  ?

[Facon]

Bonjour Philippe,
Le standard 5.5 donne les indication suivantes:

NEW_TAG: = {Size=1:15}
A user-defined tag that is contained in the GEDCOM current transmission. This tag must begin with an underscore (_) and should only be interpreted in the context of the sending system.

User-Defined Tags
We do not encourage the use of user-defined GEDCOM tags. Applications requiring the use of non-standard tags should define them with a leading underscore so that they will not conflict with future GEDCOM standard tags. Systems that read user-defined tags must consider that they have meaning only with respect to a system contained in the HEAD.SOUR context.

It is legal to extend the context of the form, but only by using user-defined tags which must begin with an underscore. This will not violate the lineage-linked GEDCOM standard unless the context for the grammar of the Lineage-Linked GEDCOM Form is violated. The use of the underscore in the user tag name is to signal a non-standard construct is being used. This notifies the reading system of a discrepancy and will avoid future conflicts with tags that may be standardized in subsequent GEDCOM releases.

Sur son site, Aquablue a de longue date rédigé quelques notes sur l'export/import Gedcom et Lya avait procédé à quelques essais sur cette fonction pour mettre également en évidence les manques, les erreurs de syntaxe et les anomalies.

Le standard indique pour les tags utilisateur ou propriétaire une longueur de 15 caractères maxi, il semble préférable de maintenir ces tags avec une longueur aussi courte que possible car de nombreuses applications ne reconnaissent que des tags plus brefs. Il faut trouver le bon compromis entre la longueur du tag et sa signification.
La recommandation reste malgré tout de minimiser le recours à ces tags non standards et d'utiliser les possibilités offertes par le standard Gedcom en respectant naturellement la syntaxe.

C'est une réponse d'un non connaisseur, Aquablue, André et sans doute d'autres doivent avoir un avis plus éclairé sur ta question.
Il est clair qu'à l'heure actuelle Ancestrologie est pollué par quelques tags mis en place dans la précipitation et pour d'autres parfois en double avec des tags standards.

  Dans sa recherche de conformité au standard, il faudrait qu'Ancestrologie soit le plus proche possible de celui-ci et qu'il soit tolérant vis à vis des gedcoms élaborés à partir d'autres applications de telle manière que la récupération des données puisse se faire dans les meilleures conditions et avec le minimum de perte par les utilisateurs.

[Ancestrologie]

l est clair qu'à l'heure actuelle Ancestrologie est pollué par quelques tags mis en place dans la précipitation et pour d'autres parfois en double avec des tags standards.

Justement le but,  c'est d'uniformiser ces tags en respectant le gedcom

quelle serait la taille maxi de ce tag en comptant le _   ?

[Facon]

Philippe,
Je pense que d'autres utilisateurs doivent avoir un avis bien plus sérieux que le mien et je pense en particulier à Aquablue.

Néanmoins, les tags standards sont pour la plupart construits avec 4 lettres. Il me semblerait bien de s'en tenir pour les tags propriétaires à cinq (5) caractères y compris le underscore "_".
A titre d'exemple, certains tags propres à Ancestrologie auraient pu être de la forme: _HENN : Henné -Fiançailes, _HOUP : Houpa - Bénédiction religieuse, etc....

L'idée maîtresse est selon moi de rester le mieux possible dans le cadre du standard et d'utiliser les subtilités du standard pour décrire des événements ou des indications qui n'existent pas dans le standard. Il existe effectivement dans Ancestrologie des tags dits "intrus" par exemple LIEU qui aurait dû être _LIEU mais qui n'aurait jamais dû être créé car la définition d'un lieu ne reprend pas cette notion dans le standard. Dans ce cas, la question serait de gérer convenablement la suppression du champ Lieu car des utilisateurs ont pu y inscrire des indications qui ne sont de toutes façons pas reprises lors de l'import dans un autre logiciel.

La mise en ordre engagée dans la gestion de l'import/export du gedcom porte sur l'utilisation des tags mais aussi et surtout dans la syntaxe et la structure à utiliser pour respecter le langage Gedcom. Par la même occasion quelques lacunes et/ou anomalies sont à traiter pour préserver les informations enregistrées par les utilisateurs.
D'autres points sont aussi à examiner, c'est notamment le traitement des sources. Aujourd'hui le principe est de pouvoir associer une seule source à un événement. Dans la réalité il peut y en avoir une multitude.
Dans l'onglet Unions, il existe la notion de Type d'union. Cette information n'est pas reconnue par les autres logiciels. L'information peut être assez curieuse puisque nous pouvons y inscrire Mariés et un peu plus bas l'événement Mariage suivi de Rupture de l'union. L'absence de renseignement dans le Type d'union n'est en rien préjudiciable.

Le traitement de l'export a déjà été largement repris par André. Il a permis de résoudre de nombreux points et il en reste probablement certains à régler.
Si j'ai bien compris, le traitement de l'import est beaucoup plus tordu à réaliser et notamment en raison de certaines options retenues dans la structure de création des événements ou autres et tout cela vient se compliquer avec l'obligation de préserver le passé pour ne pas perdre les données encodées par les utilisateurs.

En définitive j'ai tendance à penser que les tags ne sont qu'une infime partie du problème.

Au risque de me répéter, le fil conducteur devrait être:
  Rechercher la conformité au standard Gedcom tout en préservant les données déjà enregistrées et en maintenant la convivialité d'Ancestrologie;
  Savoir "digérer" les imports de gedcom issus d'autres logiciels, ce qui est une autre forme de préservation des données;
  Savoir exporter des gedcoms conformes au standard afin qu'ils puissent être convenablement repris par d'autres logiciels dans la mesure de leur propre conformité au standard.

[AquaBlue]

Un TAG propriétaire commence obligatoirement par _ (underscore) et la combinaison des 15 premiers caractères doit être unique.
Il semble effectivement tout a fait inutile d'utiliser trop de caractères (c'est à cause d'un TAG de plus de 15 caractères que GedLieu ne marche plus avec Ancestrologie)

Il faut éviter au MAXIMUM l'usage de TAGS propriétaires qui seront perdus pour tous les autres logiciels.

Il faut donc preferer systematiquement "la norme".
C'est le cas spécialement pour FILA et TYPU.
TYPU caractérise le Type de l'union et devrait donc se trouver dans le TYPE de l'événement union (MARR qui une fois encore ne veut pas dire mariage mais union) et devrait donc être là dans le GEDCOM et dans Ancestro
FILA correspond (pas totalement) au TYPE de BIRT et devrait donc être là dans le GEDCOM et dans Ancestro

Pour LIEU on ne devrait même pas en parler puisque ce champ faisant double emploi avec Subd, ne sert strictement à rien et devrait donc être supprimé d'Ancestrologie (surtout après les dernières modifications sur Subd.)

Le problème de CodePostal et de Code INSEE est aussi un faux problème. L'export GEDCOM devrait demander lequel on veut utiliser et n'exporter qu'un code dans PLAC (soit l'un soit l'autre en fonction du choix). même chose pour l'import.

Les événements spéciaux XHENN (Henné), XHOUP (Houpa), XLOI (Loisirs), XSPO (Sports), XMU1 (Circonsision),XMU2 (Chahada) et XMU3 (El Hadj). Normalement ces événements devraient utiliser une structure EVEN/TYPE avec le nom de l'événement dans TYPE. Donc même s'ils sont "pré-définis" dans Ancestrologie ils devraient être importés/exportés en EVEN/TYPE

Pour _ANCES_ORDRE c'est export semble inutile. "YAKA" exporter les événements dans l'ordre et les importer en respectant l'ordre du GEDCOM. (Cette remarque est valable pour l'ordre des enfants)

Pour les XTYPE, XIDEN, XMODE ... liés à OBJE j'aurai tendance à penser que ça pourrait être codé dans la NOTE liée à l'OBJE.
Si ce n'est pas possible, les coder tous dans un seul TAG propriétaire.

Pour _ANCES_CLE_FIXE je pense que le bon TAG devrait être REFN de la structure INDIVIDU avec ça définition dans le TYPE suivant . Donc
1 REFN "la clé unique pour Qui sont-ils"
2 TYPE clé unique utilisable par tous Add-ins

Pour les coordonnées géographique le choix d'André du MAP de 5.5.1 me semble excellent car d'autres logiciels ont aussi fait ce choix.

Suivre 5.5.1 aussi pour _EMAIL et _URL

Continuer à utiliser ASSO avec les événements et avec FAM même si ce n'est pas "standard"

Ajout ultérieur : Surtout laisser le Subd à la fin de PLAC même si ce n'est pas "conforme" car on peut très facilement le remettre à la bonne place si nécessaire (GedLieu) mais surtout ça reste compatible avec le très mauvais logiciel utilisé par plus de 50% des français.

[DDdeBerdeux]

Bonjour,
Quasi entièrement d'accord avec ce qui vient d'être dit par Aquablue. J'ajouterai que pour l'export standard, j'ai mis dans le champ Note subordonné à PLAC, en première ligne le code INSEE et en deuxième ligne le LIEU. Cà a pour avantages de ne pas perdre l'information dans les logiciels qui ne connaissent pas ces champs (mais qui suivent la norme), et avec peu de programmation de pouvoir être récupéré dans les bons champs par Ancestrologie, sans pour celà nécessiter la création d'étiquettes spécifiques. Peut-être devrais-je compléter en mettant INSEE: et LIEU: en tête de ces lignes pour être plus clair et éviter une possible confusion lors de l'import d'un gedcom d'une autre origine.
Je pense qu'ajoutée à ce qu'a dit Aquablue, la méthode pourrait être étendue à d'autres cas pour éviter la création de bien des étiquettes spécifiques.
A+
André

[hubert.delcroix]

Bravo, enfin Ancestrolgie exporte en GEDCOM les sources suivant la norme.
Je viens de le tester avec TNG et GENEWEB que j'utilise sur mes sites web et ça marche.
Philippe,  ANCESTROLGIE qui est un merveilleux logiciel devient enfin utilisable
pour des généalogistes sérieux qui tiennent aux sources.
un grand merci
Hubert

[Roger 1]

Snif, snif, pour André aussi qui s'échine jusqu'à pas d'heure

[hubert.delcroix]

Pardon d'avoir oublié  les membres de la valeureuse équipe et particulièrement André.
merci à tous
Hubert