MCD GN-citizen

[camillemonchicourt]

Première réflexion sur le MCD.
En orange les référentiels avec lesquels l'application interagirait.
En vert les schémas de GeoNature avec lesquels elle pourrait communiquer.

A voir néanmoins comment permettre d'utiliser cette application indépendamment de GeoNature.

[camillemonchicourt]

A voir par contre si on a plusieurs programmes de collecte citoyenne, alors il faudra ajouter une table gn_citizen.t_programs avec une FK dans gn_citizen.t_observations y faisant référence.

gn_citizen.t_programs contiendrait un id_program, program_name, active (boolean), description, id_list_taxons

[camillemonchicourt]

Après discussion :

• On s'appuierait bien sur TaxHub, ses listes et son API
• On ne s'appuierait pas sur UsersHub dans un premier temps car c'est complexe et pas mur. On aurait donc une table t_users intégrée à gn_citizen
• A voir si on utilise le schéma ref_geo dont on n'aurait pas besoin de tout mais qui apporte des fonctionnalités et une homogénéité intéressantes : https://github.com/PnX-SI/GeoNature/blob/develop/data/core/ref_geo.sql
• On pourrait se brancher aux différents schémas de GeoNature sans l'imposer (validation, synthèse, métadonnées...)
• Du coup, on intégrerait une gestion des médias des observations dans gn_citizen pour ne pas imposer une dépendance à GeoNature

[gildeluermoz]

Oups, je n'ai pas participé aux discussions mais cette approche me semble ambigüe. Je ne vois pas la logique de faire un module citizen qui soit un module geonature tout en pouvant être indépendant de geonature.

Vu de loin je dirais qu'il y a 2 options
1/ citizen est un vrai module de geonature, il est donc fortement intégré et on peut utiliser tout ce qui vient du cœur et des référentiels. Il ne peut pas fonctionner sans geonature dans ce cas.
2/ citizen doit pouvoir vivre sans geonature et dans ce cas il a son propre MCD, complet, avec sa liste de taxon et éventuellement d'utilisateurs, de programmes, etc... Et peut-être son back-office, voire sa propre base de données.

Dans le cas 2, c'est une application totalement autonome. Pour faire le lien avec geonature il faut envisager un paramètre + une configuration spécifique optionnelle permettant à citizen d'écrire dans la synthèse d'un geonature via l'api de la synthèse.
Une bonne approche serait de faire une web API synthèse. Cette web API étant capable décrire dans la synthèse en prenant comme source un json normé. Ainsi citizen ou n'importe quelle autre application externe peut écrire dans la synthèse si elle sait fabriquer et transmettre ce json normé à la webapi synthèse (en s'authentifiant bien sûr).
Reste à décider de la place que prendront ces données dans la synthèse car elles n'auront ni cruved, ni métadonnées (ou plutôt un cruved et des métadonnées toutes identiques et correspondant à une source externe non définie). A voir si on peut envisager que ces métadonnées et éventuellement un cruved soit transmis via l'authentification.

Dans tous les cas si citizen doit produire des données dans la synthèse il faut établir des correspondances avec toutes les nomenclatures du standard occurrence de taxon présentes dans la synthèse (nomenclature_default_values) car dans le mcd actuel de citizen il n'y a aucun cd_nomenclature.

[camillemonchicourt]

Ce n'est pas un module GeoNature.
C'est un application indépendante de GeoNature mais connectable à GeoNature. Comme GN-atlas mais au lieu d'être en aval, elle est en amont.

Donc c'est plutôt le cas 2, mais comme GN-atlas il dépendra de TaxHub (de manière optionnelle mais fortement conseillée pour pouvoir gérer les médias, les descriptions, les listes...) mais pas de GeoNature.

En effet la synthèse aura une API donc on a imaginé l'utiliser de l'extérieur (pour des get mais aussi des post, update, delete avec un token). Cependant, dans notre cas, si quelqu'un veut utiliser GN-citizen avec GeoNature, on a plutôt imaginer intégrer son schéma gn_citizen dans la BDD de GeoNature et faire un trigger vers la synthèse comme depuis les autres sources. En plus de simplifier les choses, cela permettrait aussi de pouvoir bénéficier des tables verticales d'historique, de validation...

Concernant les données dans la Synthèse, comme beaucoup de données partenaires, elles n'auront pas de CRUVED, et peu de nomenclatures renseignées que l'on mettra alors à Non renseigné, à moins d'avoir une valeur globale certaine (comme pour StatutObservation=Présent et quelques autres). Comme les données partenaires elles seront associées à des jeux de données, des cadres d'acquisition, des sources...

Pour le moment, pour faire simple, on a prévu de pouvoir ne pas imposer l'authentification, voire même de la désactiver totalement. Et pour limiter les dépendances, de ne pas fonctionner avec UsersHub mais avec une gestion interne des utilisateurs. Néanmoins pour une meilleure intégration avec GeoNature, pour bénéficier d'un id_role, voire d'un id_organisme, cette piste pourra être réétudiée dans un second temps, avec les conséquences que cela entraîne. Pour le moment, ce n'est pas mur.

[camillemonchicourt]

Actuellement le MCD implémenté est https://github.com/PnX-SI/GeoNature-citizen/blob/dev/mcd.png

[lpofredc]

Merci @camillemonchicourt , C'est un MCD provisoire en cours de construction. Vu pour la proposition du shema ref_geo. En effet, autant partir sur la même base.

[camillemonchicourt]

Oui OK, super. Bravo pour l'avancement des développements.

[lpofredc]

Nouvelle

[camillemonchicourt]

OK merci.
Il ne devrait pas y avoir de lien entre sights et li_municipalities.
li_municipalities est une extension de l_areas. Donc ça devrait être l'inverse. Un lien entre sights et l_areas. Et li_municipalities étant lié à l_areas, elle permet d'avoir des infos complémentaires sur la commune quand le zonage est de type "Commune".

[lpofredc]

Dernière version de mcd

[lpofredc]

Dernière mise à jour du MCD.
Ajout d'une table des correspondances des médias avec les observations pour plus de souplesse (en prévision de pouvoir poster plus de média par observation). Table automatiquement alimentée par la fonction save_upload_files.

[camillemonchicourt]

Pour les médias, ne faut-il pas ajouter une légende (title), un auteur et éventuellement une source et une licence ?

[lpofredc]

Si, en effet:

• Pour la légende, on peut par exemple le générer à partir du nom d'espèce,
• l'auteur, plus complexe du fait des deux cas de figure (enregistré ou non)... ça soulève de nombreuses questions... Notamment la gestion en cas de suppression du compte.
• source: nom du programme?
• licence: défini globalement pour le portail dans les CGU de la plateforme ?

[camillemonchicourt]

Pour moi ce sont tous des champs texte optionnels :

• La légende peut être plus fine que le nom d'espèce (avec le lieu, le contexte...).
• L'auteur du média est pas forcément le même que celui qui saisit l'observation
• Source, c'est différent du programme, c'est l'éventuelle structure à l'origine du média (en complément de l'auteur)
• Pour le licence, je ne sais pas si le portail peut l'imposer globalement, d'autant plus si le média a déjà une licence existante.

Mais tout ça est peut-être hors cadre pour des médias illustrant une observation.