====== Réflexions/Discussions sur le format d'échange ====== Retourner sur la page [[database:import-formats|le format d'import/export]] en cliquant sur l'icône de la barre d'outil à droite. ===== Ressources ===== * [[http://standards-sinp.mnhn.fr/occurrences-de-taxon-v2-0/|Standard OccTax v2]] * [[https://github.com/PnX-SI/GeoNature/blob/occtax-v2/data/core/synthese.sql|Évolution de la synthèse dans GeoNature v2.5+]] * [[https://github.com/PnX-SI/GeoNature/blob/occtax-v2/docs/implementation_gn_standard_occtax2.0.ods|Fichier de travail sur l'implémentation d'OccTax v2 dans GeoNature v2.5+]] * [[https://docs.google.com/spreadsheets/d/1JBNSQjmOaHLJvLTLAG43SGk5METxwhLv2_VfMn3Z1hg/edit?usp=sharing|Format d'échange proposé par le Pôle Régional Invertébrés (AURA)]] ===== Points à discuter ===== * Voir si on utilise plutôt un chaine vide sans guillemet pour indiquer une valeur NULL dans le format d'import --- //[[jp.milcent@cbn-alpin.fr|Jean-Pascal MILCENT]] 2020/08/31 08:00// * A priori, dans le format d'import, l'utilisation d'une tabulation (qui ne se rencontre pratiquement jamais dans les valeurs des champs) doit permettre d'éviter l'utilisation des guillemets pour encapsuler une valeur de champ même si celui-ci en contient. --- //[[jp.milcent@cbn-alpin.fr|Jean-Pascal MILCENT]] 2020/08/31 08:00// * Lors de l'import avec //COPY// il n'y a pas de vérification des doublons. Si nous répétons la procédure d'import les méta-données peuvent être importé plusieurs fois. Solutions ( --- //[[jp.milcent@cbn-alpin.fr|Jean-Pascal MILCENT]] 2020/08/31 08:00//) : * le script d'import doit se charger de réinitialiser ces tables avant chaque import s'ils trouvent les codes/UUID qui vont être importés via les fichiers CSV * pour les métadonnées nous pouvons peut être utiliser un script SQL plus classique qui se chargerait d'éviter l'import si les données sont déjà présentes. Inconvénients : moins lisible, 2 formats et traitements différents. Avantages : gestion complètes des méta-données (protocoles, acteurs de type personne...). * le script d'import via //COPY// charge les données dans une table temporaire (copie vide de la table de destination) puis les injectes dans la table de destination en s'assurant qu'il n'y a pas de doublon (//NOT EXISTS//). * Prévoir un fichier pouvant indiquer la version du format d'échange. Cela implique de versionner ce format. --- //[[jp.milcent@cbn-alpin.fr|Jean-Pascal MILCENT]] 2020/08/31 08:00// * Ne devrait on pas transférer les champ //code_nomenclature_blurring// et //code_nomenclature_diffusion_level// dans DATASET ? Avantage : cela aurait plus de sens vis à vis de notre décision de gérer par jeu de données complet ces infos. Inconvénient : oblige à transférer un fichier //dataset.csv//, rend plus difficile l'intégration des infos dans GeoNature... --- //[[jp.milcent@cbn-alpin.fr|Jean-Pascal MILCENT]] 2020/08/31 08:00// * Afin de rendre la page plus lisible (--- //[[jp.milcent@cbn-alpin.fr|Jean-Pascal MILCENT]] 2020/08/31 08:03//) : * passe-t-on la description des ressources sous forme de tableau comme sur la page présentant [[database:correspondance-champs-sinp-geonature-synthese|la correspondance entre les champs de la Synthèse de GeoNature et le standard OccTax]] ? * ajoute-t-on les valeurs des nomenclatures à utiliser dans le wiki (oblige un travail de maintenance) ou indiquons nous seulement la correspondance avec le nom du type de nomenclature présent dans le standard OccTax v2 ? ===== À faire ===== * Indiquer la correspondance avec les nomenclatures de OccTax v2. * Préciser les flux de transmission les plus courants (Partenaires=>PIFH ; CBNA=>PIFH ; PIFH=>Partenaires....)