Gestion de plusieurs versions du référentiel TaxRef en base

[bouttier]

Actuellement, il n’est possible de stocker qu’une seule version du référentiel TaxRef en base.
Or lors d’une mise-à-jour du référentiel, certain taxon sont dédoublées, tandis que d’autres sont fusionnées.

Ceci a un impact important sur les données utilisant le référentiel TaxRef : les fusions sont facile à gérer (mise-à-jour des références d’un taxon fusionnée vers sa fusion) mais la gestion des taxons dédoublées est plus compliqué. En effet, il est nécessaire de faire appel à l’expertise naturaliste afin de pouvoir déterminer pour chaque observation quel est le taxon réellement observé dans le nouveau référentiel. Or, cela n’est pas toujours possible : données trop anciennes, ou producteur de la données indisponible, …

Une autre limitation est l’impossibilité de partager des données entre diverses instances utilisant des versions différentes du référentiel.

L’idée serait donc de rajouter une colonne indiquant à quelle version du référentiel est rattaché un taxon. Toutefois, ne serait proposé à la saisie dans des outils tel que OccTax uniquement les taxons de la dernière version du référentiel. On peut également imaginer ne garder que les taxons ayant connues des évolutions pour les anciennes versions du référentiel.

[jbdesbas]

Et une approche moins intrusive qui consisterai à stocker dans une table splittage le couple cd_nom/v_taxref des taxons ayant splitté ?
La version du taxref utilisée lors de la saisie est déjà stockée dans la synthèse, on peut donc déduire que les données de la synthèse ayant une correspondance de cd_nom/v_taxref avec la table splittage sont problématiques (en attente d'un nouveau cd_nom, si possible, ou du rattachement au taxon supérieur selon le choix du gestionnaire).

D'après la doc du taxref (https://inpn.mnhn.fr/docs-web/docs/download/302170), le cd_nom problématique (avant splittage) est conservé.

[amandine-sahl]

Il y a un autre cas qui entraine la suppression d'un cd_nom : "taxon non présent diffusé à tord". Dans ce cas il faut également revenir aux données et les corriger car il y a eu erreur de saisie. La correction n'est pas toujours possible et il n'est pas évident de supprimer ou dégrader (passage au rang suppérieur) une donnée dont on n'est pas forcément propriétaire.

Dans la mesure où il y a une contrainte d'intégrité entre la synthèse (+ ...) et la table taxref je ne vois pas comment faire sans concerver les cd_noms disparus dans la table taxref. Ce qui obligerai de spécifier le référentiel au niveau de chaque enregistrement.

Autre point, dont on garder un lien avec les anciens status de ces taxons.

[bouttier]

Ok intéressant.

Il serait bien de ne plus proposer à la saisie dans OccTax des cd_nom qui n’existe plus. Il me semble assez lourd pour la db de filtrer suivant la condition « pas d’entrée dans cd_nom / v_taxref », mais peut-être pas ?

[gildeluermoz]

Le terrain me semble glissant. Il faut bien évaluer les effets de bords et la complexité induite par cette approche.
Quel sera le statut des données rattachées à ces taxons "dépréciés" ? comment les utiliser, afficher, exporter, valider ? En synthèse ou dans occtax, ou dans l'export ? Comment les gérer s'ils apparaissent dans un fichier à importer via le module d'import ?
Dans les cas de splittage, ou de "taxon non présent diffusé à tord", j'aurais plutôt tendance à rechercher une solution visant à exclure les observations concernées plutôt que de tordre le référentiel. Donc les déplacer dans une table clonée mais sans contrainte d'intégrité ou avec intégrité vers une table old_taxref comme évoqué ci-dessus mais ne comportant que qq taxons problématiques. Ces tables aideraient d'ailleurs à la migration taxref.
Le passage de ces données dans cette table d'attente peut-être temporaire si les experts trouvent la réaffectation. Sinon ça reste là... en attente.
Mais un référentiel est un référentiel. Il me semble donc plus simple et plus carré que les données disponibles dans un GN présentent la garantie d'être conformes à un seul référentiel taxonomique et pas à plusieurs...

[DonovanMaillard]

Assez d'accord avec gil, avoir des tables temporaires pour les donnees qui posent question permettraient de gérer les donnees au cas par cas quand on le peut.

Mais même si les évolutions de taxref sont assez lourdes a gérer, elles ont l'avantage de nous forcer à maintenir des donnees à jour, échangeables, intégrables dans le sinp, différentes instances etc

Mixer plusieurs référentiels peut aussi avoir des conséquences sur la lisibilité : je vois une donnee dun taxon deprecié, mais je ne peux pas le saisir ? Et si l'observation est ancienne ? Et si cest une saisie de bete en collection donc nommée par un ancien nom ? Pourquoi ne pas le rendre disponible à la saisie ? Et si je veux modifier une donnee d'un taxon dépréciee mais sans changer le taxon, comment occtax peut valider le formulaire ?
Il y aura potentiellement pas mal de soucis autour qui vont se greffer a la question.

[bouttier]

À noter que rendre possible d’avoir plusieurs référentiels n’oblige pas à en avoir plusieurs ! Si vous êtes à même de mettre à jour vos données pour la dernière version du référentiel, tant mieux ! Cependant, comme je le disais, cela n’est pas toujours possible, et c’est à ce point auquel j’aimerai trouver une solution.

Déplacer ces données dans une table temporaire est une solution à mon sens extrêmement limité : elles sont alors accessible uniquement par un administrateur de base de données, mais elles ne sont plus visible par les utilisateurs les ayants saisies et elles ne sont plus exportable. Et je pense que ça peut être vite le bazard dans les différentes tables si on a une table par version du référentiel.

Je reconnais bien évidemment qu’un référentiel multi-version soulève certains problèmes qu’il faut adresser. Une idée peut être de stocker avec chaque observation la version du référentiel à laquelle celle-ci se réfère (+ contraintes, un peu comme les nomenclatures, pour vérifier la validité de la clé étrangère). Ainsi, OccTax pourrait proposer la dernière version du référentiel pour les nouvelles saisies (paramétrable), tandis qu’il pourrait proposer l’ancien référentiel pour les vieilles données – ainsi que toutes les versions ultérieur du référentiel de manière à pouvoir mettre à jour sa donnée.
De plus, on pourrait facilement rajouter des filtres dans la synthèse et dans le module d’export pour pouvoir exclure des données rattaché à une version obsolète du référentiel.
Pour l’import, on serait alors capable d’importer des données créer pour un ancien référentiel. Ça me semble très utile lorsque l’on importe de vieilles données issue d’un vieux tableur. On pourrait tout de même afficher des warnings pour indiquer que certaines données fournies le sont pour une ancienne version du référentiel (un paramètre de config pourrait interdire l’import de telles données).

[camillemonchicourt]

Je ne suis pas non très chaud d'un système de table temporaire, où on déplace des données d'occurrences, puis on les remet ensuite dans leurs tables (Occtax, Monitoring, autres sources, synthèse...).

Et si aucun cd_nom n'était jamais supprimé de Taxref mais que les cd_nom n'étant plus utilisés étaient gelés, alors ça solutionnerait pas mal de nos soucis ? On n'aurait pas besoin d'avoir plusieurs versions de Taxref dans notre BDD.

Et il n'y aurait que les données liés à des cd_nom qui seraient gelés qui seraient à revoir, corriger, sans bloquer la MAJ de la version de Taxref.

Je pense que cette solution a été souvent évoquée/discutée au niveau de l'équipe qui gère Taxref. Si on en a besoin, on peut pousser ce sujet.

[bouttier]

Ça semble un compromis intéressant, plus simple qu’une version de référentiel :

• pas besoin de s’interroger sur « est-ce que la v14 est la dernière version ? », on a directement l’information si le taxon est obsolète ou non
• stocker la version du référentiel avec la données, et vérifier la cohérence devient inutile
• à l’export, ou dans les filtres de la synthèse, juste une coche « inclure les données avec un cd_nom gelé »

Je pense qu’on pourra aussi facilement développer des outils pour faciliter la mise-à-jour des données concernant des taxons gelés, sans avoir besoin d’un administrateur de bdd pour mettre à jour les données.

[camillemonchicourt]

Une première piste serait lors de la mise à jour de Taxref, de pouvoir garder uniquement les cd_nom qui ne sont plus présents dans la nouvelle de Taxref et n'ont pas de cd_nom de remplacement et qui ont des données associées dans le GeoNature en question.
De bien les identifier comme gelés et de les retirer des listes pour ne pas les proposer à la saisie, mais de permettre ainsi de ne pas bloquer le mise à jour ni de supprimer les données concernées.

[camillemonchicourt]

Intégré dans la migration vers Taxref v15 où un paramètre keep-cdnom a été ajouté : 2ae98b1

[bouttier]

Peux-t-on en savoir plus sur ce que fait exactement le paramètre --keep-cdnom ?
La discussion s’était arrêté aux marquages des anciens cd_nom comme gelés, mais je n’ai pas l’impression que c’est ce qui est fait dans le commit référencé.

[amandine-sahl]

Effectivement cette commande ne permet pas la gestion de plusieurs référentiels. Il n'y a aucune structuration qui permet de faire mentioner le referentiel en lien avec le nom. Elle permet juste d'éviter la suppression des cd_nom qui ne sont pas présents dans la version de taxref importée. Ces noms peuvent être soit des noms de taxref supprimés soit des noms créés manuellement par les utilisateurs (issue ou non d'autres référentiels).

Pour le moment, mais ça peut être changé, la table des cd_noms disparus est supprimée lors du nettoyage de la base après la mise à jour du taxref. Donc nous perdons la trace qu'ils ne sont plus dans le dernier taxref. Nous pouvons concerver cette table, mais il y a un décalage des cd_nom qui sont notés comme supprimés et les noms qui sont effectivement dans le dernier taxref.
De mémoire il y a deux cd_noms notés comme supprimés dans taxref v14 et qui sont encore dans taxref v15, et dans taxref v14 il y a de nombreux cd_nom qui sont notés comme supprimés en v9.

On pourrait imaginer de garder cette table (malgré les petites incohérences) et de filtrer les noms disponibles dans l'ajout des listes sur l'interface de taxhub pour limiter les incohérences. Normalement le script retire ces noms des listes automatiquement.

[camillemonchicourt]

Pour commencer l'option --keep-cdnom a été ajoutée dans la version 1.10.0, aux scripts de mise à jour de Taxref, pour empêcher la suppression des cd_noms manquants.