Données validables ?

[camillemonchicourt]

Le module Validation se base sur la Synthèse pour lister les occurrences.

Cependant il est probable que certaines données ne soient pas à valider. Les données de partenaires par exemple.

Il est aussi possible que des données n'ayant pas été saisies avec GeoNature n'aient pas d'UUID donc ne soient pas validables car de mémoire la jointure entre la Synthèse et gn_commons.t_validations se fait sur l'UUID.

A creuser.

[gildeluermoz]

Bien vu pour l'UUID.
En première approche, je dirais :

• le module de validation n'a pas vocation à valider des données produites hors GN
• on ajoute un champ validable à la table t_sources
• l'uuid est celui de l'enregistrement dans la table source et pas forcement celui de la synthese, il en faut donc un dans cette table source effectivement. Et même s'il y a souvent concordance entre ces 2 uuid, rien n'impose que ce soit le même que le unique_id_sinp de la synthèse. En gros si tu as des sources de données sans uuid_sinp, il faudra créer un uuid si l'on veut que ces données soient validables.

[DonovanMaillard]

"le module de validation n'a pas vocation à valider des données produites hors GN"

Pour ce coup, ça dépend des usages en effet, dans notre cas par exemple c'est exactement l'inverse.

"on ajoute un champ validable à la table t_sources"
Solution sympa pour tout permettre en effet selon l'utilisation qu'on fait de notre instance.

"l'uuid"
Seule remarque pour l'uuid, c'est presque dommage que celui de la synthèse ne soit pas systématiquement celui de la source quand il existe (à nous d'y veiller quand on pousse les données vers la synthèse)
Mais du coup c'est l'uuid synthèse qui sert pour la validation ? Ou l'uuid source s'il est différent ? Tu semble dire que c'est la source, il y a une raison particulière ? (je pensais que la validation s'appuyait uniquement sur la synthèse ;) )

[camillemonchicourt]

Oui un booléen à mettre sur sources ou datasets est une bonne idée.

Les uuid de la Synthèse ne doivent surtout pas être différents de ceux de la source sinon ça perd tout son sens.

[camillemonchicourt]

Oui c'est l'uuid de la Synthèse qui est utilisé.

Quand on valide on ne repasse pas par la donnée source

[camillemonchicourt]

On a aussi la possibilité de limiter l'action VALIDER à la portée 2 pour les validateurs, donc ils ne pourront valider que les données de leur organisme.

[gildeluermoz]

Je refais un point là dessus mais on log la table source dans t_validations.
Je ne vois pas pourquoi limiter à son organisme. La notion d'expertise ou d'experts validateur est justement trans-organisme.
Non ?

[camillemonchicourt]

Oui et dans certains cas comme indique Donovan, c'est même souhaitable.

Mais utiliser la portée 2 est un moyen de ne pas proposer les données partenaires à la validation.

[gildeluermoz]

C'est une manière de répondre à ce pb mais ça va en poser d'autres. Ce n'est très précis comme filtrage...

[gildeluermoz]

Le id_source ça fait le job, non ?

[camillemonchicourt]

Oui le CRUVED portée devra être vérifié car il peut être utile mais pas suffisant.

Oui un booléen validable sur t_sources semble la meilleure solution.

[gildeluermoz]

Voici un point sur le processus de validation en base et son fonctionnement actuel.

Statut de validation par défaut

Dans n'importe quelle table on peut mettre le trigger générique gn_commons.fct_trg_add_default_validation_status() sur un after insert (et si on veut sur un update selon le comportement souhaité). Ce trigger fonctionne comme ça :

• il reconnait la table qui le déclanche
• il va chercher dans la table gn_commons.bib_tables_location le nom du champ uuid de cette table
• avec ces 2 infos, il récupère l'uuid de l'enregistrement en cours de validation (avec le NEW)
• il insert dans t_validations :
  • le statut de validation,
  • l'id de la table source,
  • l'uuid,
  • la nomenclature par défaut pour le type 'STATUT_VALID' (lu dans ref_nomenclatures.defaults_nomenclatures_value)
  • null pour id_validator
  • 'auto = default value' comme validation_comment
  • now() pour validation_date

Remarques : il faut que la table contenant les enregistrements à valider soit déclarée dans gn_commons.bib_tables_location et que le trigger pointant sur cette function trigger genérique soit créé. (même mécanisme que l'historisation). La nomenclature par défaut du statu de validation doit aussi exister.

Dernier statut de validation en synthese

Le dernier statut de validation connu est maintenu en synthèse par la fonction trigger gn_commons.fct_trg_update_synthese_validation_status() qui est déclanchée par un trigger after insert sur la table t_validations.
La correspondance entre l'observation qui vient de recevoir un nouveau statut de validation (validation entrant dans t_validations (manuelle ou auto) et sa correspondance en synthèse se fait via unique_id_sinp coté synthese et NEW.uuid_attached_row coté t_validations.
Subtilité : la première validation auto et potentiellement d'autres 'dévalidations' auto sur update mais cela n'est pas implémenté pour le moment viennent de la table source , les suivantes, manuelles, proviennent de la synthèse.

Donc

• Oui, il faut maintenir une correspondance entre les uuid en synthese et dans les tables sources.
• Une donnée sans uuid ne peut pas être validée en l'état
• Des données dont la table source n'est pas déclarée dans gn_commons.bib_tables_location ne peuvent pas recevoir de validation auto mais peuvent recevoir une validation via le module de validation (cas tordu qu'il me semble souhaitable d'éviter)
• la lecture des données validables en synthèse nécessite un champ validable dans t_sources ET un uuid en synthèse et dans la table source pour rester cohérent et ne pas faire de cas particuliers.

Sur le plan conceptuel, il me semble important qu'une donnée enrichie par un travail de validation dispose bien d'une identification unique. Si elle doit être validée c'est pour être valorisée dans le circuit SINP. Certains diront pas forcement. Mais ce n'est pas l'esprit de GeoNature que de fournir un outil pour produire des données hors circuit SINP.
L'uuid pré-existe à son intégration dans GeoNature ou sera à créer lors de l'import. Pour les raisons techniques exposées ci-dessus et pour des raisons conceptuelles, l'existence de cet uuid devrait donc rester un pré-requis au fait qu'une donnée soit validable.
Le boolean validable ne servira donc qu'à exclure les données que l'on ne souhaite pas rendre disponible dans le module de validation. Sa valeur par défaut est true.

[camillemonchicourt]

OK, merci pour ce point global sur le fonctionnement de la validation, aussi lié à PnX-SI/GeoNature#520

[gildeluermoz]

DONE : PnX-SI/GeoNature@2557ba9

[DonovanMaillard]

Discussion à revoir avec @gildeluermoz et @camillemonchicourt : la validation sur l'UUID oblige les organismes qui le veulent à créer un UUID pour des données qu'ils n'ont pas forcement produite.

1 donnée peut donc avoir autant d'UUID que de bases dans lesquelles elle se trouve suite à des échanges de données. Il semblerait à priori plus pertinent de se baser sur l'ID_synthèse pour ne pas générer d'UUID sur des données issues d'échanges lorsqu'on n'est pas dans le cadre du SINP. Ce point arrive un peu tardivement pour le module validation, à rediscuter

[gildeluermoz]

On peut étudier ça.
En effet, si des données sont importées et qu'elles n'ont pas d'UUID, on ne peut pas les valider.

Il y a 2 approches :
1/ pourquoi valider des données sans UUID (sous entendu quelle est leur valeur et n'ont-elles ou ne vont-elles pas être validées par ailleurs)
2/ Pourquoi s'en priver si techniquement c'est possible ? Cela regarde le gestionnaire de la base GN.
Je ne trancherai pas.

Techniquement dans l'absolu, on ne peut valider que des données présentes dans la synthèse puisque c'est là qu'on lit. De plus en synthèse il y a un lien vers la source si besoin.
Partant de là, on pourrait modifier la table t_validations, supprimer le champs id_table_location et uuid_attached_row pour les remplacer par le seul id_synthese. Il faudrait légèrement reprendre la fonction gn_commons.fct_trg_add_default_validation_status().
Je trouverais ça plus cohérent, plus lisible et surtout ça donnerait à la table gn_commons.bib_tables_location le rôle unique de lister les tables "historisées". Actuellement pour valider des données, il faut inscrire les entités qui hébergent les données dans cette table et donc historisation et validation ne sont pas dissociables.

Je ne maîtrise pas du tout l'impact sur le dev du module de validation ou éventuellement sur d'autres éléments de GeoNature ?

[camillemonchicourt]

OK c'est une reflexion plus globale qui ne peut pas impacter la V1 du module Validation en cours, déjà bien avancée.

Oui ça pose pas mal de questions, on se les était déjà posé et on avait privilégié de se baser sur l'UUID.
Techniquement on peut valider des données qui ne sont pas dans la Synthèse à partir du moment où elles ont un UUID. Ce n'est que l'interface actuelle qui se base sur la Synthèse, donc ce n'est qu'une histoire d'affichage mais pas de BDD.

Par ailleurs, se baser sur l'id_synthese pose problème car il créé de la dépendance de donnée vis à vis de la synthèse ce qui n'est pas très sain ni souhaitable.
Le principe théorique de la Synthèse est que tout ce qu'elle contient peut être calculé (donc en théorie on peut la vider et la regénérer). Ca reste de la théorie mais il est important de ne rien baser dessus au niveau BDD, ni d'y stocker des infos utiles qu'on a pas ailleurs.
C'est d'ailleurs pour ça qu'on stocke la validation dans une table transversale et non pas dans le Synthèse comme on pensait initialement.

Mais la question des UUID reste à creuser et ouverte car elle a vocation à éviter de créer des doublons mais la systématiser pourrait en effet avoir l'effet inverse.

[gildeluermoz]

Vu tous les éléments techniques que vous avancez, il semble évident qu'il ne faut pas s'appuyer sur l'id_synthese.
Par contre les remarques de Donovan concernant l'usage et la création des uuid SINP sont intéressantes.
Je propose de ne rien modifier pour le moment et de considérer comme je le disais plus haut

pourquoi valider des données sans UUID (sous entendu quelle est leur valeur et n'ont-elles ou ne vont-elles pas être validées par ailleurs)

Par ailleurs Théo a très justement fait remarquer en off qu'on confond l'usage technique interne à GN de l'UUID (pour le mécanisme de validation ou d'historisation) avec l'UUID SINP ayant une unicité de caractère universel.
L'attribution de l'uuid SINP par GN ou par ailleurs est une question d'organisation du flux de données dans le circuit SINP et ne relève pas de ce ticket.

Je propose pour avancer :

• Conserver l'uuid comme identifiant de validation et considérer les uuid comme étant des outils propres au fonctionnement de GeoNature.
• Réfléchir à une identification claire de l'identifiant SINP pour une version ultérieure. A creuser un champ booléen du genre is_gn_uuid_the_sinp_identifier pour ne pas créer de confusion en créant 2 uuid ayant des fonctions différentes.

Question concernant le fonctionnement du module de validation.
La validation s'enregistre dans gn_commons.t_validations avec un champ id_table_location. Ce champ a une FK sur gn_commons.bib_tables_location, ce qui veut dire que théoriquement les données dont la table source n'est pas enregistrée dans gn_commons.bib_tables_location ne sont pas validables ; Est-ce bien le cas (filtrage des données validables sur cette base lors de la lecture en synthèse) ?
L'enregistrement de ces tables sources dans gn_commons.bib_tables_location est-elle à faire en base ou existe t-il un backoffice pour le faire ?

[camillemonchicourt]

Oui à mûrir en effet.

Je pencherai plutôt pour :

• un UUID_SINP généré quand on produit la donnée dans GN, rapatrié quand on importe des données contenant l'info, mais jamais utilisé pour le fonctionnement de GN
• un UUID_GN dé-corrélé, généré quand on créé une donnée dans GN mais aussi quand on importe une donnée externe, utilisé de manière centrale dans les tables verticales et reporté dans la Synthèse

[DonovanMaillard]

Bon, désolé je crois que j'ai un peu mis le boxon.

Dans ce cas, si on reprend l'idée de camille, on aurait :

• 1 identifiant source
• 1 uuid geonature
• éventuellement un uuid SINP.

Si un uuid_geonature doit être créé, il faudra l'intégrer au niveau de tous les modules (notamment l'import en ce qui me concerne). un UUID est alors généré uniquement si on est producteur de la donnée (plus efficace) ou pole sinp s'il n'y a pas eu d'uuid sinp au niveau du producteur.

Faudra juste bien faire attention à ce que ces uuid_geonature ne soient, par exemple, pas dans l'interface de la synthèse ni dans aucun export...

Après, reste aussi la question posée par Gil. Est-ce très gênant de ne valider que les données qui ont un UUID SINP (donc soit les siennes, soit celles qui sont passées par un sinp) (ou quelle est la valeur de ces données) . Je soulevais la question à la base parce que j'imagine que cette limite pourra en gener certains (un organisme qui doit faire une liste rouge ou quelque chose comme ca), mais il faut voir si c'est vraiment bloquant en soi....

[camillemonchicourt]

Non c'est pas le boxon, c'est intéressant.
C'était un peu limite d'utiliser l'UUID_SINP de manière centrale dans GN.
Donc ça permettrait d'assainir et renforcer le mécanisme global.

Par contre l'UUID_GN deviendrait obligatoire sur toutes les données.

Et comme c'est conséquent et risqué, on laisse mûrir la réflexion pour une version 2.x

[DonovanMaillard]

Bon courage, c'est sans doute le mieux à faire!

[camillemonchicourt]

Après reflexion, il n'est pas souhaitable de gérer la notion de validable (oui/non) dans la table t_sources. Cette table est technique et sert à faire le lien entre une donnée dans la Synthèse et sa données source dans la BDD. D'ailleurs toutes les données dans la Synthèse n'ont pas forcément de table source stockée dans GeoNature (même si non conseillé).

Du coup on opte pour ajouter le champs validable dans la table gn_meta.t_datasets.
Nous avons juste une réserve sur le fait d'ajouter ça dans cette table qui est basée sur un standard SINP et ne doit pas être étendue dans tous les sens pour des besoins purement GeoNature.
Mais pour le moment, cela semble la solution la plus simple et la plus opérationnelle.

[camillemonchicourt]

Champs validable basculé dans meta.t_datasets : PnX-SI/GeoNature@ebd4f7a

[camillemonchicourt]

Évolution des données validables traité dans la version 2.1.1 de GeoNature.
Reste la question plus globale d'ajouter un UUID_GN pour ne plus s'appuyer sur l'UUID_SINP pour le fonctionnement du cœur de GeoNature et notamment le mécanisme de tables transversales.