Proposition d'évolution du MCD

[gildeluermoz]

Pour une éventuelle V2 ou V1.5

Constat

L'idée de structurer la taxonomie en 2 parties apparait indispensable :

• le référentiel national taxref,
• le référentiel de la structure.

Actuellement bib_noms n'est pas un référentiel. C'est ni plus ni moins qu'une liste extraite de taxonomie.taxref. Du coup on ne peut pas ajouter des taxons absents de taxref. Donc on n'a pas de référentiel de la structure mais on a la contrainte de gérer le contenu de bib_noms comme préalable à tout le reste.

Sur ces 2 référentiels, il y a un besoin d'enrichissement de ces référentiels avec les notions de listes et d'attributs permettant de répondre aux besoins locaux.
Si on a deux référentiels dans 2 tables, on aura tjs un dilème :

• lequel utiliser ?
• quand ?
• sur quelle table faire pointer les FK ?
• et si on a besoin des deux on fait comment ?

Actuellement bib_noms est au centre des listes et des attributs alors qu'on se base toujours sur cd_nom ou cd_ref, présents dans taxonomie.taxref. En gros bib_noms n'apporte que le choix du nom_français et depuis peu la possibilité de commentaires. Il constitue par ailleurs une liste limitative des taxons de la structure.

Autre soucis, les listes se basent uniquement sur les noms (cd_nom) et les attributs uniquement sur les taxons (cd_ref). Impossible de faire par exemple un attribut qui concernerait tous les synonymes d'un taxon ou de faire une liste avec uniquement des taxons de référence.

Propositions

• supprimer bib_noms et donc du coup le id_nom tout pourri et totalement inutile car chaque cd_nom unique a un id_nom unique...
• ajouter un champ inpn (true/false) à taxonomie.taxref,
• ajouter les qq taxons du référentiel de la structure à la table taxonomie.taxref avec inpn = false,
• ajouter un champ is_ref a bib_attributs et bib_listes,
• faire pointer cor_nom_liste et cor_taxon_attribut sur le cd_nom de taxref au lieu de pointer sur bib_noms et utiliser le champ is_ref de bib_listes ou bib_attributs dans une contrainte pour savoir si l'attribut ou la liste doit accueillir uniquement des taxons de référence ou si elle peut accueillir des synonymes. CONSTRAINT CHECK (f_is_cd_nom_matching_with_attribut(cd_nom, id_attribut).
  Avec la petite fonction qui va bien :

CREATE OR REPLACE FUNCTION f_is_cd_nom_matching_with_attribut(cd_nom integer, id_attribut integer)
RETURNS BOOLEAN AS 
$$ 
DECLARE
  attr_is_ref boolean;
BEGIN
  SELECT INTO attr_is_ref is_ref FROM taxonomie.bib_attributs WHERE id_attribut = $2;
  IF ((attr_is_ref AND $1 == taxonomie.find_cdref($1)) OR !attr_is_ref) THEN 
   RETURN true;
  ELSE 
    RETURN false;
  END IF;
END;
$$ 
LANGUAGE plpgsql IMMUTABLE 
COST 100;

• ajouter une liste "taxons_structure",
• gérer le nom_français à retenir dans un attribut nom_fr,
• gérer les commentaires dans un attribut commentaire.

Ainsi :

• on garde toute la richesse de la hiérarchie taxonomique pour nos deux référentiels,
• on peut facilement isoler les taxons du référentiel structure avec le champ inpn (migration taxref, export, transmission à l'INPN pour expertise, etc...),
• squand elles existent, on peut établir des correspondances entre le référentiel de la structure et le référentiel INPN avec les champ cd_ref et cd_taxsup,
• TOUTES les références vers cd_nom ou cd_ref (FK ou jointures) se font sur une seule table,
• on donne la possibilité aux listes de référencer des taxons et plus seulement des noms, sans avoir à créer cor_taxon_liste à coté de cor_nom_liste,
• idem, on donne la possibilité aux attributs de référencer noms ou taxons sans avoir à créer cor_nom_attribut à coté de cor_taxon_attribut,
• on peut limiter les requêtes aux taxons de la structure avec la liste "taxons_structure",
• on répond peut-être, au moins partiellement à ce besoin : Groupes d'espèces #159.

[camillemonchicourt]

Merci pour cette proposition qui est la suite de plusieurs discussions sur le sujet.

Elle est ressortie au moment de discuter de la manière de lister les taxons dans la Synthèse de GeoNature V2 : PnX-SI/GeoNature#385

En effet, on constate que le fait d'avoir à tout passer par bib_noms alourdit la gestion et duplique des informations.

Cet aspect étant discuté depuis quelques temps, on a fait en sorte que ni GeoNature-atlas, ni GeoNature n'utilisent bib_noms. Ils s'appuient directement sur taxref, sur les listes, les attributs et les médias.

Les conséquences d'un tel changement impacteront donc principalement TaxHub.

En effet bib_noms est une liste de taxons, donc pourrait être une liste comme les autres.
Je me suis interrogé si il ne faudrait pas donner quand même un statut particulier à cette liste pour que qu'on on créé une nouvelle liste, on puisse s'appuyer sur cette "liste des noms de mon territoire" pour faciliter le remplissage des autres listes. Sinon j'ai pensé à avoir de la hiérarchie entres listes pour que cette liste soit de niveau 1 et que les autres soient des sous-listes de niveau 2 mais ça me semble un peu complexe pour peu d'apport.

En effet un des principales intérêts de bib_noms était de pouvoir renseigner les noms français pour les simplifier ou en disposer quand il n'y en avait pas beaucoup dans Taxref.
On pourrait désormais en faire un attribut.
Mais je me pose la question sur la pertinence de cela.
Cela duplique une information qui est maintenant de plus en plus renseignée dans Taxref.
Si on a renseigné cette info sur un taxon ou qu'on la laissée nulle et que le nom est ajouté ou corrigé dans une version suivante de Taxref, on n'en bénéficie pas car on a recréé un nouveau français à part.
Je me demande donc si c'est toujours pertinent.

Il me semble important que les listes s'appuient sur les cd_noms pour que l'on puisse choisir quels synonymes sont proposés à la saisie par exemple, sans forcément les embarquer tous.
Pour les attributs et les médias, il me semble important que tous les noms d'un taxon aient les mêmes.

La manière d'étendre Taxref avec ses propres taxons (ou groupes) plus proprement comme tu proposes est intéressante aussi.

[gildeluermoz]

En effet bib_noms est une liste de taxons, donc pourrait être une liste comme les autres.
Je me suis interrogé si il ne faudrait pas donner quand même un statut particulier à cette liste pour que qu'on on créé une nouvelle liste, on puisse s'appuyer sur cette "liste des noms de mon territoire" pour faciliter le remplissage des autres listes. Sinon j'ai pensé à avoir de la hiérarchie entres listes pour que cette liste soit de niveau 1 et que les autres soient des sous-listes de niveau 2 mais ça me semble un peu complexe pour peu d'apport.

J'y ai pensé et on pourrait garder bib_noms avec uniquement cette fonction (en faisant sauter id_nom ainsi que le nom_français et le commentaire). Mais si on fait ça c'est uniquement dans le but de moins avoir à retoucher TaxHub car cette table devient vide de sens.
Il y certainement mieux à faire : conserver l'idée de la supprimer et quand on ajoute un taxon à "mes_taxons", l'ajouter à la liste "taxons_de_ma_structure" (= liste 0) automatiquement. Ainsi tu ne peux pas oublier de le mettre dans cette liste, c'est TaxHub qui le fait. Evidemment si tu bosses en admin, il faut le faire à la mimine. Partant de là, tu as tjs une liste des taxons de ta structure que tu peux mettre dans une vue ou dans une jointure à partir d'un
SELECT cd_nom FROM cor_nom_liste WHERE id_liste = 0;

Concernant les noms français, l'attribut n'étant pas obligatoire, on le fait uniquement sur les rares cas où c'est nécessaire. Sachant que le nom_vern de taxonomie.taxref ne sera utilisé que si l'attribut nom_fr pour ce taxon n'existe pas. Et on l'utilise ou pas selon le besoin.

Il me semble important que les listes s'appuient sur les cd_noms pour que l'on puisse choisir quels synonymes sont proposés à la saisie par exemple, sans forcément les embarquer tous.
Pour les attributs et les médias, il me semble important que tous les noms d'un taxon aient les mêmes.

Oui bien sur. Ma proposition ne remet pas ça en cause. Elle permet juste de choisir si ta liste "L" ou ton attribut "A" concerne tous les noms ou seulement les taxons de références. On garde les fonctionnalités actuelles mais on se donne des possibilités supplémentaires. Un attribut "A" concerne les taxons de référence et un autre attribut "B" concerne tous les noms synonymes.

[camillemonchicourt]

Ça serait dommage de garder bib_noms juste pour ça car c'est ce qui est un peu lourd à chaque fois qu'on veut ajouter un nouveau nom.
On pourra en causer avec les autres au workshop.
En fait je me dis que le plus simple serait de laisser l'utilisateur choisir.
Quand il peuple une liste, par défaut on lui affiche tout Taxref, mais il peut limiter la liste des taxons proposés à une autre liste. Il peut ainsi peupler une liste à partir de la liste "Taxons de mon territoire" ou autre si il le souhaite.

OK pour les noms français, on en recausera.

Pour les liens entre cd_nom/cd_ref et listes et attributs, je vois pas bien, ais on en rediscutera aussi.

[DonovanMaillard]

Bien intéressant comme discussion et perspectives.

Concernant le champ is_ref, est-ce qu'on ne peut pas simplement s'appuyer sur le fait de cd_nom=cd_ref

Concernant le "nom français structure", ça peut aussi permettre de faire le tri quand il existe 15 nom_vern pour un taxon selon les choix d'une structure... Mais sur ce point est-ce que ça risque pas de créer des complications et des risques d'erreurs à chaque changement de version du taxref, pour une fonctionnalité peut être pas si essentielle ?

L'idée de la liste qui se crée automatiquement pour avoir la liste de la structure est sympa aussi, ainsi biensur que les groupes d'espèces qui deviendraient possibles.

[gildeluermoz]

Faut que j'explicite mieux ce champ is_ref.
Oui c'est cd_nom = cd_ref si is_ref = true mais si is_ref = false c'est tous les cd_nom qui peuvent avoir une valeur différente pour cet attribut.

Actuellement les attributs se basent sur le cd_ref de bib_noms et ne concernent donc que les taxons de référence donc is_ref = true obligatoire pour TOUS les attributs. Si on ajoute ce champ is_ref à bib_attributs, on peut dire que cet attribut concernera tous les synonymes : is_ref = false
Par exemple, on pourrait dire que saisie_possible n'est plus une liste mais un attribut avec is_ref = false. On pourrait surtout dire que cet attribut 'saisie_possible' n'est plus seulement booleen oui/non mais de type array avec une liste de valeurs possibles du genre 'array des modules dans lesquels on peut saisir ce nom'.
Pour faire ça avec les listes, il faudrait faire une liste 'saisie possible' par module. Car une liste contient un nom ou ne le contient pas.

Idem avec les listes. La liste 'plantes comestibles' avec is_ref = true et tu ne peux mettre dans cette liste que des taxons de référence, ce qui t'évite qu'un nom soit comestible et que son synonyme ne le soit pas.

Mais comme une liste est une sorte d'attribut boolean (true/false), on pourrait même carrément se passer des listes avec par exemple un attribut 'comestible' de type booléen au lieu d'une liste. Tu donnes l'attribut comestible = true à n taxons et ça te fait ta liste. C'est le principe des tags. Et avec is_ref tu dis si ton attribut concerne tous les noms ou que les taxons de référence.

Bon j'admets que la notion de liste est parlante mais en base on pourrait s'en passer.

[camillemonchicourt]

C'est clair que les listes c'est quand même plus parlant, plus lisible car tu vois ce qui est dedans ou pas, tu peux les lier à des groupes et c'est plus facile à remplir que des attributs nom par nom.

D'ailleurs j'ai renommé l'attribut "Saisie possible" en "Saisie Occtax" dans cette idée qu'il y a une liste par module.

Mais à creuser en effet les pistes que tu évoques pour ajouter de nouvelles possibilités.

[gildeluermoz]

Oui en interface faut absolument garder les listes. En base ça se discute.

[camillemonchicourt]

La table bib_noms a été supprimée dans la version 2.0.0 de TaxHub. 🎉