[Occtax] déterminateur et méthode de détermination

[jbrieuclp]

Salut, J'expose ici 2 remarques sur le déterminateur et la méthode de détermination dans le but de les poursuivre en discussion et potentiellement de les concrétiser en évolutions :

Déterminateur Nous avons pour le moment un champ déterminateur de type texte non obligatoire dans le formulaire de saisie. Ce champ est recommandé dans le format plateforme thématique sinp 3.1, mais obligatoire lorsqu'un cd_nom est transmis dans occurrence de taxons 2.0. Même si ce champ, pour des question de validation, devrait être obligatoire pour tous, je peux comprendre que dans certain cas il ne le soit pas. Du coup un paramètre pourrait être créer pour gérer cette notion d'obligation. De plus le connecter à la liste des utilisateurs et en le remplissant par défaut par l'utilisateur connecté serait un gros plus (encore un paramètre ?).

Méthode de détermination Les formats standards (2.0 et plateforme thématique) font de ce champ un champ de type commentaire. Dans GeoNature et je trouve ça très bien, ce champ est issu d'une liste de nomenclatures. Seulement, le MNHN considère ce champ comme commentaire, car potentiellement il existe nombre de méthodes de déter selon les groupes, les protocoles ou les naturalistes. A ce niveau, je pense qu'il y a un "problème" au niveau de la table synthèse car la clé de la méthode de déter est stockée, là où normalement la valeur devrait s'y trouver selon le format standard. Au passage cette méthode de déter n'est pas affichée au niveau de la popup d'information du module synthèse.

[jbrieuclp]

En rebond au premier poste je vous propose une modification de la BD pour que le déterminateur soit géré de la même manière que les observateurs avec une table associative cor_deter_releves_occtax et un champ texte determinateur_txt dont l'utilisation de l'un ou l'autre se fait au niveau d'un paramètre (comme pour l'observateur), la fonction pr_occtax.insert_in_synthese fonctionnant avec un COALESCE pour réagir selon le paramétrage choisi. La table cor_deter_releves_occtax aurait cette structuration :

(
id_releve_occtax bigint NOT NULL,
id_role integer NOT NULL,
date_deter timestamp without time zone --Autorisation du NULL et sans DEFAULT Now()
)

Niveau frontend on aurait un fonctionnement de type dénombrement pour la gestion de ces déterminateurs : un template de formulaire simple (1 role, 1 date) avec un bouton + pour le répéter autant de fois que de déterminateur.

Cette proposition d'évolution est-elle partagée ?

[jbdesbas]

Effectivement je ne vois pas de raison que ce champs soit géré différemment de celui des observateurs. Je suis donc d'accorder avec le lien vers la table des rôles (+champs texte libre).

Par contre je doute sur l'intérêt (et la complexité) d'intégrer plusieurs déterminateurs successifs (ce qui veut dire qu'il faudrait aussi stocker les différentes déterminations ?).

[jbrieuclp]

Après un échange en interne, je pense pouvoir clarifier les éléments : Pour nous, une occurrence c'est ça :

(
nom_cite_originel text NOT NULL, --nom cité à l'identique par la toute première personne, le nom avec fautes issu des étiquettes de collection, d'herbier...
nom_cite text NOT NULL, --nom cité par le déterminateur
cd_nom integer, -- peut être NULL Taxref n'étant pas encore parfais
id_déterminateur integer, -- FK sur t_roles selon paramètre
determinateur_txt text, --selon paramètre
date_deter timestamp truc, --date de la déter si elle est connue (si que année, mettre 31/12/AAAA comme le préconise le MNHN)
)

En plus de cette première détermination il peut y avoir des confirmateurs, et c'était ça que j'évoquais dans mon second post, 2 solutions :

• soit on passe par une table qui serait cor_conf_deter_occurrences_occtax (au passage j'avais mis relevé, ce qui est très con...):

  (
  id_occurrence_occtax bigint NOT NULL,
  id_role integer NOT NULL, --FK
  date_confirmation timestamp without time zone --Autorisation du NULL et sans DEFAULT Now() ?
  )

  • soit on ajoute un champ confirmateurs jsonb à t_occurrences_occtax avec un json structuré de manière similaire à la table. Peut être que je me trompe, mais l'info de confirmateurs doit quand même être marginal, je json devrait suffir. (Vous allez me faire aimer ce type de donnée à force... :D)

Pour la question du changement de détermination, la table d'archivage est là pour l'historique, le seul champ invariable doit être nom_cite_originel. Si jamais un changement de détermination à lieu (changement de nom_cite ou cd_nom), on vide les confirmateurs. Un trigger peut être utilisé.

Il est évident que pour de la saisie d'observation récente, de terrain nom_cite_originel = nom_cite = nom_complet (taxref), il n'y a donc toujours qu'une unique zone de saisie dans le formulaire.

Et je justifie le champ nom_cite pour palier aux manques de Taxref : pouvoir saisir une donnée si son rattachement au référentiel n'est pas possible.

[jbdesbas]

confirmateurs? On arrive dans le champs de la validation là non ? (qui prévoit déjà plusieurs validations successives) Je ne vois pas non plus l'intérêt du champs "nom_cite_originel", la table d'archivage ne devrait pas suffire, vu l'utilisation marginale qui risque d'en être fait ?

[DonovanMaillard]

La confirmation renvoie un peu à la validation oui, ou alors on peut mentionner en text plusieurs déterminateurs.

Au dela de ca et pour le nom-cite-originel, je pense que si on ne veut pas se perdre en superposant les notions, mieux vaut rester le plus fidèle possible aux standards, qui même s'ils sont imparfaits, permettent de parler un même langage. Le nom_cité, dans e référentiel, renvoie déjà au nom originel. Le nom "en cours" correspondant au cd_nom, le nom cité n' déjà pas vocation a être modifié a priori au cours du traitement de la donnée.

[jbrieuclp]

Le confirmateur va appuyer la détermination, la confirmer, pour autant il ne la valide pas dans le sens où il lui attribut une note de validation. Une bestiole déterminée peut être mal déterminée, la méthode de déter à un intérêt ici et cette méthode est une information à ajouter au niveau du confirmateur. Par exemple, une première détermination à vue, peut être confirmée par une seconde personne par une dissection ou autre examen d'élément spécifique.

La validateur va, lui, suivre un protocole de validation afin d'appliquer une note à la donnée. Ce protocole peut prendre en compte le déterminateur et les confirmateurs. Aussi, à condition, qu'il ait accès à l'échantillon, le validateur peut confirmer l'espèce.

Pour le nom cité originel, je comprend que c'est délicat. C'était en réponse au cas de la saisie d'une bestiole empaillée, d'un herbier ou d'une bête en boîte, comment conserver ce qui est sur l'étiquette avec l’imprécision qui peut exister, tout en attribuant un nouveau nom pouvant lui même ne pas être rattachable à taxref, donc sans cd_nom.

Peut-être que dans ce cas, la proposition du nouveau nom hors référentiel doit se faire en commentaire ?

[camillemonchicourt]

Concernant le déterminateur, dans notre cas, on ne le renseigne que dans des cas particuliers où il est différent de l'observateur. Souvent, il s'agit alors d'experts, qu'on n'a pas besoin, ni envie d'ajouter à notre table utilisateurs/observateurs. Du coup le fait d'en faire un champ texte, comme prévu dans le standard, nous allait très bien.

Mettre en place un mode mixte, comme pour les utilisateurs avec possibilité d'être en liste ou en texte se tient. Mais c'est assez lourd à gérer, au niveau des triggers, des mises à jour, des vérifications etc... Nous n'en avons clairement pas le besoin et le mode texte nous va très bien. Si quelqu'un veut le faire, pas de soucis.

Je ne suis pas sur qu'il faille en faire une table de correspondance type cor_deter_releves_occtax, ni d'ajouter une date, un seul déterminateur suffit, non ? Ensuite en effet c'est de la validation selon moi. Et il faut essayer de rester basé sur le standard.

De mémoire aussi le champ nom_cite ne doit pas bougé dans le temps et correspond au nom cité originel.

Hormis le fait de pouvoir baser le déterminateur sur une liste déroulante (désactivable en texte, paramétrable et basée sur une liste d'utilisateurs), le reste me semble assez particulier, non standard et spécifique. A voir comment faire si vous en avez besoin.

[DonovanMaillard]

Je pense qu'on se perd en oubliant l'unique finalité de la donnée : vivre et apporter une information sur l'espèce.

Si quelqu'un se trompe et qu'n déterminateur repasse, il suffit de corriger l'espèce et mettre le nom valide avec son déterminateur. Au pire des cas si on veut garder en mémoire que l'observateur a donné la muvaise espèce dans un premier temps on le met en commentaire, mais concrètement c'est une information fausse qui n'a pas grand intérêt à être historisé et complexifier le mcd à mon avis.

Pour le nom hors référentiel c'est un autre sujet je pense. Un nom historique, soit il est quand meme dans le taxref avec un cd_ref différent du cd_nom, soit il a intérêt à y etre ajouté s'il est valide. Soit il est supprimé, auquel cas on ne sait pas à quoi le rattacher. Mais le plus pertinent dans ce cas selon moi, c'est de faire évoluer le taxref pour le rendre toujours plus exhaustif, plutôt que créer des ajouts de notre coté dans nos instances, car là aussi ca produit in fine des données "mortes" qu'on ne pourra pas partager car hors référentiels...

Ce n'est que mon avis. Mais je me rends compte que de fil en aiguille, GeoNature se compléxifie déjà énormément coté base, et je pense qu'il faut rester dans l'idée de complexifier les mcd uniquement si ca a un intérêt pour des cas communs et fréquents. Ici j'ai l'impression qu'on risque de rajouter des tables et des liens un peu partout pour historiser des déterminations, pour quelques données un peu particulières. Mon but n'est pas de m'opposer à de telles évolutions, mais surtout de relancer le débat pour voir où on met la barre entre le fait de répondre à tout, le fait d'avoir un outil relativement simple, et le fait d'avoir un outil qui répond au mieux aux standards pour faciliter les échanges (car pour ma part, l'intérêt d'une donnée repose uniquement sur sa transmission au reste du réseau).

[jbrieuclp]

Bon clairement ce que je peux évoquer ici doit être plus relatif à une logique métier appliquée à l'entomologie, mais peut-être aussi un peu à la bota.

Le fait d'ajouter des confirmateurs en plus d'un déterminateur n'est pas liée à la notion d'archivage. C'est appuyer/justifier/confirmer une détermination par une seconde personne ultérieurement et qui peut utiliser une autre méthodo. (en entomo les bestioles sont échangées et peuvent être déterminées par plusieurs spécialistes) Si jamais la première détermination est remise en cause, alors oui, une nouvelle détermination (= changement de cd_nom/cd_ref) est faite remplaçant alors la mauvaise et comme lors de toute modif, la donnée avant sa modification est archivée dans la table t_history_actions.

Concernant le standard justement, il prévoit bien plusieurs déterminateurs (=pour moi : déterminateur + confirmateurs), mais il ne demande que la dernière date de détermination. La méthode est quant à elle un champ commentaire (ce devrait donc être la même chose dans la synthèse).

Il est vrai que le champ déterminateur actuel au format text fait le taf, par contre pour retrouver des données déterminées par un utilisateur c'est pas franchement réalisable...

Enfin le fait de ne pas renseigner le champ déterminateur car déterminateur = observateur, c'est un usage qui peut fonctionner en interne (=protocole de saisi interne), mais dans l'objectif de partage des données qu'est le SINP, cette information ne sera pas partagée et donc elle sera perdue : les données n'auront pas de déterminateur.

Dans une optique de validation c'est une information qui est importante. Aussi bien celle du déterminateur que la méthode employée.