Occurrence de taxon: statut source

[TheoLechemia]

Lors des test avec les bureaux d'étude on nous a fait remonté qu'on ne pouvait pas spécifier qu'une données provient de la littérature (étude biblio). En effet, cette info qui provient du standard: "statut_source", n'est pas dans le modèle de la base, et dans les export on met l'info à "terrain" en dur dans la vue.

Est-ce que cette info doit être ajouté dans le formulaire occurrence de taxon (et masquable du coup), ou être mise au niveau du JDD? (le standard métadonnées ne prévoit de stocker cette info à ce niveau).

On avait également parler de faire un module spécifique pour les données de biblio.

[camillemonchicourt]

En effet, on peut se poser la question de rajouter le champs. Mais dans tous les cas, c'est vrai que pour les données biblio, on avait pensé faire une module de saisie à part. Notamment car les données biblio sont souvent rattachées à un objet géographique (maille, commune, département...) alors que dans le module Occtax une donnée est localisée sur la carte (point, ligne ou polygone). A voir si il y a aussi d'autres particularités pour la biblio.

[TheoLechemia]

Fait en l'ajoutant au niveau de l'occurrence. Relevé ou occurrence, ça se discute ...

[gildeluermoz]

Je ne suis pas du tout d'accord pour intégrer les spécificités des données bibliographiques dans occtax. Occtax c'est une logique terrain et données occasionnelles de rencontre. C'est de l'actualité. Ça doit être précis (date, Loc, notamment) ou ça peut être précis (dénombrement, sexe et âge, méthode de détermination, méthode d'observation, etc...) On a potentiellement bcp d'infos précises qui peuvent faire sens. La bibliographie c'est une toute autre logique. La précision spatio-temporelle est soit mauvaise, soit floue, possiblement bonne. Les données ne sont généralement pas du tout d'actualité. On DOIT donc pouvoir isoler les données bibliographiques des données d'occtax pour des traitements spécifiques. Si on les saisies au milieu du reste c'est la foire. Si on se casse les neurones pour décliner les métadonnées avec JDD et cadre d'acquisition c'est bien pour ne pas tout mélanger.

De mon point de vue il faut faire un module biblio en forkant occtax et le modifier avec tout ce qui est spécifique :

• Date floue possible (année seulement par ex)
• Localisation par rattachement, sans carte, sur la base de référenciels géographiques) voire norme sinp.
• Bcp plus d'infos optionnelles (dénombrement, sexe, âge, etc)
• Obligation de référencer la source biblio
• Importance du nom taxonomique fourni et de la correspondance qui est parfois nécessaire de faire (il faut enregistrer les deux avec un éventuel commentaire). Avoir en tête qu'il peut y avoir un écart énorme de connaissance et de référentiel taxo de GeoNature et celui de l'époque des observations.
• Importance de la notion de précision de la localisation (en gros c'est quoi l'info initiale de localisation : xy, lieu dit, maille, commune, commentaire de localisation de l'auteur, altitude fournie ou pas).
• Numéro de collection éventuel.

Ajoutons que la validation des données bibliographiques n'a pas forcément le même sens ni la même pertinence. Si elle doivent être validées, est-ce que ça doit être fait avec le même module, les mêmes nomenclatures, que pour les données "vivantes" ?

Bref c'est très spécifique et si on permet la.saisie de données bibliographiques dans occtax on organise un joyeux mélange.

[camillemonchicourt]

Oui on est bien d'accord sur le module Bibliographie taillé pour ça et toutes les spécificités que tu mentionnes. Et certainement pareil pour les Collections.

Mais là dans Occtax, on masquera le champ dans le formulaire et on fournit une valeur par défaut dans la BDD. Mais vu que ce champs est dans la standard, c'est plus complet de le mettre dans la BDD et de permettre de l'afficher à ceux qui le souhaiteraient.

Le champs Statut Source ne correspond d'ailleurs pas uniquement à de la biblio.

[gildeluermoz]

Je ne suis pas d'accord du tout. Adieu le principe un protocole = une BDD (un MCD). Attention : occtax est conforme au standard occurrence de taxon, donc tout peut rentrer dedans. Et ce n'est pas parce que tout peut rentrer que occtax doit être un fourre tout en permettant tout. On doit aussi veiller à ne pas permettre la production de données incohérentes chaque fois que c'est possible. Et là ça me semble clair. Le statut de la source c'est 4 possibilités "terrain" ou "littérrature" ou "collection" ou "ne sait pas". Occtax c'est dédié aux observations de "terrain" et rien d'autre. Je me répète mais là organise un joyeux mélange.

[camillemonchicourt]

Je suis bien d'accord avec le côté fourre-tout de Occtax mais c'est déjà le cas. A chacun de l'utiliser comme il le souhaite. Ce n'est pas un protocole. Bien sur que dans notre cas, on masquera ce champs et d'autres aussi pour limiter son côté fourre-tout. Mais si on verrouille ce champs (avec un mécanisme rustine non générique), pourquoi pas aussi d'autres comme StatutObservation. En les laissant tous avec les mécanismes actuelles de masquage de champs et de définition d'une valeur par défaut (modifiable ou non) dans la BDD, on traite tout de la même manière, générique et souple.

[TheoLechemia]

Je pense qu'on ne peut pas présuposer de comment un organisme veut structurer sa donnée. Si pour la structure, la logique est de structurer ses données par étude d'impact par exemple. Ce sera logique pour elle de retrouver dans le même JDD des données terrain et des données biblio... Inversement, des structures vont faire des méga JDD, ou elles vont tout fourrer dedans, et ce ne sera pas mieux organisé ... On fournit les mécanismes pour organiser ses données: CA, JDD, protocoles etc... mais après chacun les organise comme il l'entend et on peut pas présupposer une organisation qui est propre à notre vision ou à notre contexte.

[camillemonchicourt]

Je suis assez d'accord avec cette vision. C'est l'éternel débat entre Contact, Occurrences de taxons, protocoles... On a déjà franchit la ligne en utilisant le standard Occurrences de taxons pour en faire un outil de saisie alors que c'est un standard d'agglomération (plutôt similaire à la synthèse qu'au Contact). Mais on propose des outils pour maquer ou non des champs, pour le faire se rapprocher de ce qu'on appelle le Contact au PNE.

[gildeluermoz]

Effectivement on ne peut présupposer de rien et laisser la responsabilité à chaque structure de faire n'importe quoi. Mais ce n'est pas comme ça que je voyais notre boulot. Ainsi soit-il ! Alors il faut vérifier pour les 25 nomenclatures du standard d'occurrence

• qu'elles sont toutes bien présentes dans le formulaire
• qu'on livre bien une valeur par défaut pour chacune

[DonovanMaillard]

Pour le coup, le naturaliste emmerdeur soutient plutôt gil. Si une donnée biblio est perdue dans un jeu de données, elle perd ses champs spécifiques et surtout elle finira en doublons dans tous les sens. Une donnée biblio qui sert à 25 études va rentrer dans les 25 jdd correspondant aux 25 études ? ? Puis pour retrouver ces données bibliographiques après il faut aller chercher dans toutes les études que tu as faites ? Pour le coup ça suit pas la logique "organisee" habituellement défendue :) et c'est moi qui le dis.... rendez vous compte !

[camillemonchicourt]

Il ne s'agit pas de soutenir untel ou untel, on est d'accord sur le fait que ce champ ne colle pas avec du Contact comme on fait au PNE et on est d'accord que pour bien faire de la biblio, il faut un module à part. Cependant, ce n'est pas un module Contact mais un module OccTax que l'on peut réduire à du Contact en masquant des champs et en poussant une valeur par défaut définie dans la BDD. De plus, actuellement on n'a pas de module Biblio. Donc la question est de savoir, si on met brutalement et en dur dans la vue d'export et dans les triggers une valeur qui nous va bien, ou si on utilise le mécanisme générique existant qui permet de masquer un champs et pousser une valeur par défaut modifiable. Tout en laissant le choix à ceux qui le souhaitent de réafficher ce champs et de saisir et ranger les données comme ils le souhaitent.

De plus, cela n'a pas rapport avec les JDD et comment sera utilisée la donnée Biblio. Les données biblio peuvent très bien être regroupées dans un JDD dédié à cela.

Dans tous les cas, en l'état, des BE vont y saisir des données biblio, sans savoir que la vue export va écrire en force "Terrain". Je suis pas sur que ce soit mieux. :-)

A défaut d'avoir un module taillé pour faire de la Biblio dans le futur.

[orovellotti]

Je doit dire, si je peux me permettre, par expérience, gérer la bilblio c’est un vrais problème qui mérite un dev spécifique.

Il peut y avoir plusieurs occurrences pour une Biblio etc ... et un besoin de s’interfacer avec un système dédie externe ...

Il faut aussi être plus permissif sur la taxonomie les toponymes et les observateurs (morts depuis longtemps).

La logique synthèse me paraît bien pour tout centraliser.

[camillemonchicourt]

Oui ça c'est clair. Faire un module Biblio dédié est identifié depuis le début.

[jbrieuclp]

Et bien moi je ne vois pas en quoi une donnée issue d'un ouvrage ou d'une collection n'est pas compatible occurrence de taxon. Concernant les dates, elles existent (la date de publication, de mort de l'auteur permet au moins de borner le maximum), les taxons taxref gère les synonymies, seulement il faut permettre le renseignement du nom cité librement en plus de faire le rattachement au référentiel. L'observateur, ça se créer, ou à défaut M'sieur-dame Non Renseigné peut faire l'affaire. La localisation... Et bien permettre le référencement du relevé sur un données de ref_geo.l_areas répond au problème, en permettant de faire un rattachement à la commune, département, autre zonage quelconque.

Pour moi le schema pr_occtax est bien suffisant, à quoi bon s’embêter à gérer une multitude de format de données/schema différents ? Paie ta maintenance si on commence à jouer à ce jeu là.... Seul le formulaire de saisie doit être différent pour être plus flexible et permettre le rattachement des données à un type de localisation et le nom cité originel.

Enfin, de mon point de vue, la référence de l'ouvrage ou de la collection doit se faire au niveau du JDD. Un ouvrage (ou chapitre ou autre niveau) = un JDD.

[camillemonchicourt]

Oui c'est bien ça, en terme de stockage le standard Occurrence de taxons fait tout à fait l'affaire.

C'est bien la logique de saisie qui diffère un peu, entre autre sur le sujet de rattachement de la localisation.