Cadres d'acquisition / Jeux de données

[sig-pnrnm]

En testant les formulaires de cadres d'acquisition / jeux de données de l'instance de demo, je constate que :

• les cadres d'acquisition peuvent avoir des cadres parents / enfants
• les jeux de données ne peuvent pas avoir de jeux parents / enfants

Dans mon interprétation du glossaire SINP, je n'avais pas vu cette différence, et dans mes premières réflexions de structuration de nos Cadres et Jeu de données, j'avais d'ailleurs pensé l'inverse.

Voici les définitions actuelles :

Et voici comment j'avais envisagé la chose chez nous :

Avez-vous commencé à structurer les cadres d'acquisition et jeux de données dans vos structures, et auriez vous des exemples afin que nous partagions nos structurations ?

[gildeluermoz]

Sylvain, On a implémenté le standard 1.3.9 dont voici un extrait comportant bien un champ idmetacadreparent et ismetacadre

C'est ce doc qui est implémenté actuellement dans GN2 : (https://inpn.mnhn.fr/docs-web/docs/download/231229)

Nous n'avons pas encore pu implémenter la nouvelle version du standard de métadonnées.

[DonovanMaillard]

Sauf erreur, le standard est bien à jour dans GN (dernière version du SINP en 2017).

@gildeluermoz c'est le standard d'occurrence qui a évolué il me semble :)

@sig-pnrnm je n'ai pas vu de notions de jeux de données parents/enfants, seulement sur les Cadres d'acquisition en effet.

Pour des exemples en effet, j'ai commencé le rangement de mon coté. Ca donne quelque chose comme :

Cadre d'acquisition : ABC de la commune de Carrouge

JDD : Inventaire des papillons de la commune de Carrouge Inventaires participatifs sur la commune - Un dragon dans mon jardin Inventaire des oiseaux de la commune

On peut imaginer un cadre d'acquisition parent : "Atlas de la Biodiversité communale" si j'ai plusieurs ABC sur mon territoire.

Le plus dur est d'anticiper des métadonnées comme quelque chose qui se partage. Par exemple, l'asso pour laquelle je travaille ne fait que les papillons, et assure des prestations pour les gestionnaires. Chaque cadre d'acquisition pour nous est en fait le jeu de données d'un partenaire. On s'adapte donc en faisant des JDD de notre coté... par exemple, On a un cadre d'acquisition "ATBI du Parc des Ecrins", et on y range nos différents inventaires (au lieu d'avoir un Cadre d'acquisition par devis/prestation dans notre cas).

Tout ça est à titre d'exemple, et ce rangement, même décrit dans le référentiel, a une part de subjectivité... Au niveau SINP régional, je m'attends à ce que les jeux soient peu découpés par les producteurs qui n'ont pas des outils qui tiennent compte ds JDD. J'aurai, je pense, des jeux "mélangé" avec "Données de telle asso 2018" et tout dedans...

[gildeluermoz]

Effectivement tu as raison. il n'y a pas de nouveau standard de métadonnées. yala !

[camillemonchicourt]

A première vue ça me semblait pertinent et plus simple que tous les JDD soient au même niveau et qu'il commence pas à y avoir des JDD enfants de JDD mais de garder cet emboîtement uniquement au niveau des CA.

[sig-pnrnm]

Merci pour vos réponses.

On a implémenté le standard 1.3.9 dont voici un extrait comportant bien un champ idmetacadreparent et ismetacadre

Ok, merci pour la confirmation : ce n'est donc pas un choix, et il est évident qu'il faut se baser sur le standard.

C'est juste que, en réfléchissant à la structuration de nos JDD, donc le plus bas niveau, il me semblait plus "facile" de voir des emboitements, alors que les CA me paraissaient plus stables dans le temps (plus haut niveau), et donc sans besoin d'emboitement...

On va discuter de cette structuration avec notre ORB, pour s'accorder avec eux en amont.

Si d'autres structures ont déjà structuré leurs CA et JDD, n'hésitez pas à les partager ici !

A+

[camillemonchicourt]

De mémoire, ce vers quoi voudrait tendre le SINP est : 1 JDD = 1 producteur, 1 protocole

A noter aussi que pour l'année 2019 est l'année de la métadonnée selon l'INPN et je dirai qu'on y contribue à notre niveau avec le déploiement de GN2 par de nombreux producteurs.

[gildeluermoz]

1 JDD = 1 producteur, 1 protocole

Il y a 2 approches : l'approche intégrateur type SINP et l'approche producteur de données. Pour un seul et même producteur (cas des instances GN orientées producteurs de données), si 1 protocole = 1 JDD, alors la notion de JDD devient inutile. Le protocole suffirait. Dans GN1, on parle de lots de données. Ce vocabulare est plus adapté pour un producteur de données.

Le standard de métadonnées a été rédigés par un organisme intégrateur. Il est donc orienté ainsi. On l'a repris dans GN sans trop se poser de question.

Il faut trouver une convergence de vocabulaire et de sens ou assumer une divergence d'usage de ces concepts de métadonnées entre utilisateurs SINP et producteurs de données car avec les UUID, les données produites dans GN2 seront transmises aux SINP avec leur métadonnées "uuidifées".