# Standard d'échange pour les métadonnées V2.0

Chloé Vinet, Solène Robert, Noëlie Maurel, Kévin Plaëtevoët, Paul Fromage, Pascal Dupont, Valérie Raevel, Adèle Hurabielle, Silvère Camponovo, Mathieu Manceau, et al.

## ► To cite this version:

Chloé Vinet, Solène Robert, Noëlie Maurel, Kévin Plaëtevoët, Paul Fromage, et al. Standard d'échange pour les métadonnées V2.0. PatriNat (OFB-MNHN-CNRS-IRD). 2023. mnhn-04625680

HAL Id: mnhn-04625680

https://mnhn.hal.science/mnhn-04625680v1

Submitted on 26 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
<figure><img src="image_2.png" /></figure>

SINP
Système d'Information
de l'Inventaire du Patrimoine naturel

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

# STANDARD D'ÉCHANGE POUR LES MÉTADONNÉES

## Version 2.0

Mai 2023

<figure><img src="image_5.png" /></figure>
## Historique des versions du document

<table><thead><tr><td>Version</td><td>Date</td><td>Commentaire</td></tr></thead><tbody><tr><td>1.3.10</td><td>26/13/2019</td><td>Version corrigée</td></tr><tr><td>2.0</td><td>22/05/2023</td><td>Version finale</td></tr></tbody></table>

## Rédactrice du document

Chloé VINET – PatriNat (OFB-MNHN-CNRS-IRD)

Sur la base du travail coordonné par Rémy JOMIER ayant abouti à la version 1.3.10.

## Groupe de travail

### Cercle 1

ARB-Bourgogne-Franche-Comté

Déborah BECHTEL

DEAL Réunion

Rémy BOUILLY

CBN du Bassin Parisien

Silvère CAMPONOVO

SOAD (OFB)

Julie CHATAIGNER

LPO

Laurent COUZI

PatriNat (OFB-MNHN-CNRS-IRD)

Jeanne DE MAZIÈRES

PatriNat (OFB-MNHN-CNRS-IRD)

Pascal DUPONT

FAUNA

Paul FROMAGE

Picardie Nature

Adèle HURABIELLE

PatriNat (OFB-MNHN-CNRS-IRD)

Noëlie MAUREL

PatriNat (OFB-MNHN-CNRS-IRD)

Mathieu MANCEAU

PatriNat (OFB-MNHN-CNRS-IRD)

Olivier NORVEZ

PatriNat (OFB-MNHN-CNRS-IRD)

Sophie PAMERLON

PatriNat (OFB-MNHN-CNRS-IRD)

Kévin PLAËTEVOËT

DREAL Hauts-de-France

Valérie RAEVEL

PatriNat (OFB-MNHN-CNRS-IRD)

Solène ROBERT

PatriNat (OFB-MNHN-CNRS-IRD)

Eva RODINSON

PatriNat (OFB-MNHN-CNRS-IRD)

Chloé VINET

## Relecteurs et/ou testeurs du dictionnaire

PatriNat (OFB-MNHN-CNRS-IRD)

Pamela AMIARD

PatriNat (OFB-MNHN-CNRS-IRD)

Lucille BILLON

Fédération départementale de pêche de l'Aisne

Emmanuelle CHEVALIER

CBNA

Jean-Michel GENIS

CBNA

Ornella KRISTO

PatriNat (OFB-MNHN-CNRS-IRD)

Mathieu MANCEAU

PatriNat (OFB-MNHN-CNRS-IRD)

Noëlie MAUREL

PatriNat (OFB-MNHN-CNRS-IRD)

Kévin PLAËTEVOËT

DREAL Hauts-de-France

Valérie RAEVEL

PatriNat (OFB-MNHN-CNRS-IRD)

Solène ROBERT

## Pour citer ce document :

VINET C., ROBERT S., MAUREL N., PLAËTEVOËT K., FROMAGE P., DUPONT P., RAEVEL V., HURABIELLE A., CAMPONOVO S., MANCEAU M., DE MAZIÈRES J., RODINSON E., PAMERLON S., BECHTEL D., CHATAIGNER J., COUZI L., NORVEZ O., BOUILLY R., 2023. Standard d'échange de métadonnées v2.0, PatriNat (OFB-MNHN-CNRS-IRD), Paris, 32 pp.
Table des matières

<table><tr><td>1</td><td>Préambule</td><td>4</td></tr><tr><td>2</td><td>Les standards d'échange du SINP</td><td>4</td></tr><tr><td>2.1</td><td>Contexte et objectifs</td><td>4</td></tr><tr><td>2.1.1</td><td>Le SINP</td><td>4</td></tr><tr><td>2.1.2</td><td>Les standards d'échange</td><td>5</td></tr><tr><td>2.2</td><td>Principes et notations</td><td>6</td></tr><tr><td>2.2.1</td><td>Notation UML et diagramme de classes</td><td>6</td></tr><tr><td>2.2.2</td><td>Les concepts</td><td>7</td></tr><tr><td>2.2.3</td><td>Les attributs</td><td>7</td></tr><tr><td>2.3</td><td>Guide de lecture du document</td><td>8</td></tr><tr><td>3</td><td>Le standard d'échange de métadonnées</td><td>10</td></tr><tr><td>3.1</td><td>Schéma de principe général</td><td>10</td></tr><tr><td>3.2</td><td>Cadre d'acquisition, jeu de données</td><td>10</td></tr><tr><td>3.3</td><td>Utilisateurs cibles</td><td>11</td></tr><tr><td>4</td><td>Modèle conceptuel de données</td><td>11</td></tr><tr><td>4.1</td><td>Guide de lecture du modèle conceptuel de données</td><td>13</td></tr><tr><td>4.2</td><td>Concepts obligatoires</td><td>13</td></tr><tr><td>4.2.1</td><td>CadreAcquisition</td><td>13</td></tr><tr><td>4.2.2</td><td>JeuDeDonnees</td><td>16</td></tr><tr><td>4.3</td><td>Concepts facultatifs</td><td>20</td></tr><tr><td>4.3.1</td><td>Publication</td><td>20</td></tr><tr><td>4.3.2</td><td>BaseProduction</td><td>20</td></tr><tr><td>4.3.3</td><td>ConformiteCoherence</td><td>21</td></tr><tr><td>4.3.4</td><td>NonConformeNonCoherent</td><td>22</td></tr><tr><td>4.3.5</td><td>AttributAdditionnel</td><td>23</td></tr><tr><td>4.3.6</td><td>ModificationAttribut</td><td>23</td></tr><tr><td>4.3.7</td><td>JeuDeDonneesLie</td><td>25</td></tr><tr><td>4.4</td><td>Types</td><td>26</td></tr><tr><td>4.4.1</td><td>ActeurType</td><td>26</td></tr><tr><td>4.4.2</td><td>MethodeType</td><td>27</td></tr><tr><td>4.4.3</td><td>ProtocoleType</td><td>27</td></tr><tr><td>5</td><td>Annexe</td><td>28</td></tr><tr><td>5.1</td><td>Modifications entre les versions 1.3.10 et 2.0</td><td>28</td></tr><tr><td>5.1.1</td><td>Modifications générales</td><td>28</td></tr></table>
<table><tr><td>5.1.2</td><td>Ajout, modification et suppression de concepts</td><td>28</td></tr><tr><td>5.1.3</td><td>Ajout, modification et suppression d'attributs</td><td>29</td></tr><tr><td>5.1.4</td><td>Ajout, modification et suppression de référentiels et nomenclatures</td><td>32</td></tr></table>

# 1 Préambule

## Articulation entre le document de présentation du standard et le dictionnaire de données du SINP :

En complément de ce document, le **dictionnaire de données du SINP** liste les attributs existants dans le cadre des standards d'échange de données. Dans sa première version le dictionnaire liste les attributs du standard d'échange de données d'observations et de suivis de taxons (SOT) v3.0 ainsi que du standard d'échange de métadonnées v2.0. Pour chaque attribut est indiqué le format (integer, decimal, varchar, date, etc.), le concept qu'il caractérise, une définition, les éventuelles règles d'écriture à respecter et un exemple. Le dictionnaire de données est donc un document complémentaire et indispensable à la compréhension et l'utilisation du standard d'échange.

Ce présent document et le dictionnaire de données du SINP sont indissociables et à utiliser conjointement pour comprendre et appliquer le standard d'échange.

# 2 Les standards d'échange du SINP

## 2.1 Contexte et objectifs

### 2.1.1 Le SINP

Le système d'information de l'inventaire du patrimoine naturel (SINP) est établi pour organiser et soutenir la conception, la mise en œuvre et l'évaluation des inventaires mentionnés aux I, II et IV de l'article L. 411-1 A du code de l'environnement.

Le SINP vise à structurer les synergies et les coopérations entre les acteurs œuvrant pour la production, la gestion, le traitement, la valorisation et la diffusion des données relatives à l'inventaire du patrimoine naturel institué en application de l'article L. 411-1 A du code de l'environnement. On entend par inventaire du patrimoine naturel, l'inventaire des richesses écologiques, faunistiques, floristiques, géologiques, pédologiques, minéralogiques et paléontologiques.

C'est un dispositif partenarial entre le ministère chargé de l'environnement, les associations, les collectivités territoriales, les établissements publics ou privés, les services de l'État, etc. qui a pour objet de structurer les connaissances sur l'état et sur les tendances de la biodiversité au rang des espèces et des populations (faune, flore, fonge), des communautés d'espèces, des écosystèmes (les habitats naturels ou semi-naturels, ainsi que les biotopes, milieux et physionomies de végétations), et sur le patrimoine géologique, pédologique, minéralogique et paléontologique afin de mettre à disposition ces connaissances au plus grand nombre, de manière utile et fiable, et selon les réglementations en vigueur.

Le SINP porte sur l'ensemble du territoire national terrestre, fluvial et marin. Il s'applique en métropole et dans les collectivités relevant du code de l'environnement (départements d'outre-mer, Terres australes et antarctiques françaises, Saint-Pierre-et-Miquelon). Les autres collectivités d'outre-mer peuvent, sans que cela ne constitue une obligation, s'inscrire dans la démarche du SINP.
Le SINP porte sur l'état actuel ou passé du patrimoine naturel. Il couvre les grandes classes d'information que sont :

- les données d'observation et de suivi ;

- les données synthétiques ;

- les données descriptives, telles que les bases de connaissance ;

- les données de référence, éléments d'interopérabilité du système d'information, telles que le référentiel taxonomique (TaxRef<fnref n="1" />) ou le référentiel des typologies d'habitats (HabRef<fnref n="2" />) ;

- les métadonnées, informations descriptives des données, quel que soit leur type, permettant de préciser des éléments relatifs à un lot de données.

Le SINP doit permettre d'améliorer la production, la gestion et la circulation d'informations de qualité en offrant un cadre méthodologique et scientifique de référence. Les connaissances partagées doivent notamment permettre l'élaboration et le suivi des politiques publiques, la mise à disposition des citoyens d'informations suffisantes pour permettre le débat public, de faciliter la prise de décision dans un cadre démocratique, de décloisonner les informations entre autorités publiques, citoyens et acteurs économiques et de permettre les rapportages correspondant aux engagements européens et internationaux.

### 2.1.2 Les standards d'échange

Une multitude de données sur la biodiversité (observations et suivis de taxons ou d'habitats) est produite chaque année par de nombreux acteurs sur le territoire national français ( métropole et outre-mer). Ces données sont collectées selon des protocoles, méthodes et techniques différentes et à des fins variées.

Les standards d'échange du SINP permettent de disposer d'un « langage commun » afin de partager les données d'observation et de suivi et les métadonnées entre acteurs du SINP, d'assurer la qualité des informations bancarisées et diffusées, et in fine d'en faciliter la réutilisation. C'est la complétude et la qualité des données et des métadonnées qui permet de valoriser au mieux l'information qu'elles véhiculent : le processus de standardisation ne doit ni trier ni altérer cette information. Ainsi, les données standardisées doivent être brutes autant que possible, de façon à ne pas limiter leur réutilisation à un usage spécifique.

Le partage des données de biodiversité dans le SINP s'appuie sur trois standards :

- un standard pour les métadonnées, qui sont décrites à deux niveaux : le cadre d'acquisition et le jeu de données ;

- un standard pour les données d'observation et de suivi de taxons<fnref n="3" />;

- un standard pour les données d'observation et de suivi d'habitats<fnref n="4" />.

<footnote n="1">¹ https://inpn.mnhn.fr/telechargement/referentielEspece/referentielTaxo</footnote>

<footnote n="2">² https://inpn.mnhn.fr/telechargement/referentiels/habitats</footnote>

<footnote n="3">³ https://inpn.mnhn.fr/programme/donnees-observations-especes/references/standard-echange</footnote>

<footnote n="4">⁴ https://inpn.mnhn.fr/programme/donnees-observations-habitats/references/standard-echange</footnote>
<figure><img src="image_6.png" /><figcaption>Figure 1: Principes et articulation des standards du SINP</figcaption></figure>

## 2.2 Principes et notations

### 2.2.1 Notation UML et diagramme de classes

Les standards d'échange du SINP utilisent la notation « langage de modélisation unifié » (UML pour *Unified Modeling Language*). Il s'agit d'un langage graphique normé qui permet de décrire différents aspects des systèmes d'information, en particulier sous forme de diagrammes de classes.

Un diagramme de classes comprend des classes d'objets, qui possèdent des éléments (attributs) qui leur sont propres et qui sont reliées entre elles via des associations. Une classe d'objet est un regroupement d'objets disposant de caractéristiques communes et pour lesquels on veut gérer la même information.

Une classe est représentée graphiquement par un rectangle séparé en deux parties, le nom de la classe et les attributs qui la caractérisent. Les associations entre classes sont représentées par des flèches. Chaque extrémité d'une association porte une indication de multiplicité. Elle exprime le nombre minimum et maximum d'objets d'une classe cible pouvant être associés à un seul objet de la classe source.

La multiplicité s'applique également à la relation entre la classe et ses attributs. Dans un modèle conceptuel de données, la multiplicité suivant un attribut indique le nombre minimum et maximum d'utilisation de cet attribut pour une utilisation de la classe.

**Multiplicité (cardinalité) :**

Pour une association donnée, la multiplicité indique le nombre de fois, au minimum et au maximum, que l'on peut utiliser une classe :

- **1 ou rien** (valeur par défaut) : exactement une fois ;
- **1..*** : une ou plusieurs fois possibles (autrement dit, au moins une fois);

- **0..1** : zéro ou une fois;

- **0..*** : zéro ou une ou plusieurs fois possibles;

- **1..10** : une à dix fois

<figure><img src="image_7.png" /><figcaption>Figure 2: Modélisation d'une association entre deux classes et leur multiplicité</figcaption></figure>

### 2.2.2 Les concepts

Un concept décrit une **catégorie d'information**, qui peut être caractérisée par de multiples éléments. Les concepts correspondent à ce qu'on appelle « classes » en UML.

Dans le standard, chaque concept est décrit par un texte donnant sa définition et son caractère obligatoire ou non, la liste des éléments d'information (attributs) qui le caractérisent, ainsi que la liste des associations avec d'autres concepts, et la multiplicité de ces associations.

**Caractère obligatoire ou non :**

Les concepts **OBLIGATOIRES** sont ceux qui décrivent les informations minimales nécessaires pour rendre les données utilisables. D'autres catégories d'information sont pertinentes ou non selon le contexte de production de la donnée ou selon le contexte d'utilisation du standard : les concepts qui les décrivent sont **FACULTATIFS**.

### 2.2.3 Les attributs

Un attribut permet de renseigner un **élément d'information**, il est rattaché à un concept et le caractérise.

La définition de l'attribut, son format informatique (format de données), ses règles de renseignement générales, et le cas échéant un vocabulaire contrôlé sont décrits dans le dictionnaire de données du SINP.

Dans le standard, chaque attribut est décrit par son caractère obligatoire ou facultatif ainsi que sa multiplicité avec le concept auquel il est rattaché, et le cas échant des règles de renseignement spécifiques au standard.

**Caractère obligatoire ou non :**

- **OBLIGATOIRE** : L'attribut DOIT être renseigné ; s'il n'est pas renseigné, la donnée sera considérée comme invalide lors des contrôles de conformité<fnref n="5" /> préalables à l'intégration des données dans la base nationale de l'INPN ;

- **OBLIGATOIRE CONDITIONNEL** : L'attribut peut être OBLIGATOIRE ou FACULTATIF selon le contexte, c'est-à-dire qu'il y a un lien d'interdépendance avec le renseignement d'un autre attribut ; la ou les condition(s) sont explicitement décrite(s) dans les règles de renseignement de l'attribut ;

<footnote n="5">⁵ La conformité désigne le respect des règles fixées dans le cadre de la mise en œuvre des formats standards de données et de métadonnées autant sur les aspects physiques que conceptuels (renseignement des champs obligatoires, format, utilisation des référentiels et des listes de valeurs/nomenclatures).</footnote>
- **FACULTATIF** : L'attribut PEUT être renseigné mais n'est pas requis ; s'il n'est pas renseigné, la donnée ne sera pas considérée comme invalide lors des contrôles de conformité.

**Au sujet du caractère obligatoire ou facultatif des attributs :**

* Le caractère obligatoire ou facultatif d'un attribut décrit le traitement informatique qui sera appliqué à cet attribut lors des contrôles de conformité préalables à l'intégration du jeu de données dans la base de données nationale de l'INPN. Dès lors que la disponibilité d'une information dépend du contexte de production de la donnée ou du contexte d'utilisation du standard, l'attribut porteur de cette information ne peut pas être rendu obligatoire. Toutefois, cela ne signifie pas que cette information, quand elle existe, n'est pas importante. **Lorsque l'information véhiculée par un attribut existe, alors il faut renseigner cet attribut, même s'il est facultatif.**

* Dans le cas d'informations qui ne seraient pas systématiquement collectées, les standards du SINP privilégient des attributs facultatifs prenant la valeur NULL lorsqu'ils ne sont pas renseignés, plutôt que des attributs obligatoires admettant pour valeur une chaîne de caractère telle que « Inconnu » ou « NSP ».

* L'utilisation d'un concept peut dépendre du contexte, mais certains éléments d'information peuvent être requis dès lors que ce concept est utilisé. Par conséquent, **il peut y avoir des attributs obligatoires au sein d'un concept facultatif.**

**Règles de renseignement :**

Les règles de renseignement d'un attribut guident l'utilisateur lorsque ce renseignement est sujet à interprétation. Elles permettent également de préciser dans quelle s condition s un attribut OBLIGATOIRE CONDITIONNEL est OBLIGATOIRE. Le but de ces règles est d'homogénéiser la forme des données afin d'en faciliter la réutilisation ultérieure.

## 2.3 Guide de lecture du document

Le standard se présente de la façon suivante :

- Le schéma de principal général du standard pour avoir une vue d'ensemble de l'articulation des concepts ;

- Le modèle conceptuel de données (schéma du diagramme de classes UML et vocabulaire contrôlé associée) ;

- Liste des concepts obligatoires et leurs attributs ;

- Liste des concepts facultatifs et leurs attributs ;

- Liste des concepts types et leurs attributs.

Chaque concept est défini et ses conditions d'utilisation explicitées. Les attributs de chaque concept et leur multiplicité sont listés. Le formalisme et la définition des attributs sont décrits dans le dictionnaire de données du SINP.

Un concept type (noté XXXType) permet de renseigner de la même manière plusieurs attributs différents véhiculant le même type d'information, évitant ainsi des répétitions dans le standard ; les concepts types sont notamment utiles dans le cas d'attributs dits complexes (= renseignés à travers de multiples attributs). Par exemple, la description d'un acteur (rôle, nom, prénom, organisme) permet de caractériser l'acteur principal du cadre d'acquisition, le contact principal du jeu de données, mais aussi le contact de la base de production lorsque ces informations existent.
XXXXX ou XXXXType <- nom du concept

abcdef <- texte d'explication. Définition du concept et caractère obligatoire ou non (sauf pour concepts types).

ATTRIBUTS

abcdefgh <- nom de l'attribut

Multiplicité : [1] <- multiplicité de l'attribut lors de l'utilisation du concept

Éventuelle règle de renseignement concept-spécifique à l'utilisation de l'attribut

Cet attribut est **OBLIGATOIRE**. <- caractère obligatoire, obligatoire conditionnel ou facultatif de l'attribut lors de l'utilisation du concept

Règle de renseignement des identifiants uniques du SINP (attributs « idSinp... ») :

Les identifiants uniques du SINP sont au format UUID v4. Il est préconisé que ces identifiants soient gérés au plus près de la collecte des données, donc dans les bases de données sources lorsque cela est possible.

La production de l'identifiant au plus près du producteur de données facilite en effet la traçabilité des données et limite l'intégration de doublons.

Dans le cas où les identifiants uniques n'auraient pas été créés avant la transmission des données à une plateforme du SINP, les identifiants seront alors créés par la plateforme lors de leur intégration dans le dispositif.

Vigilance : les métadonnées peuvent déjà être enregistrées dans le SINP, auquel cas il faudra renseigner l'identifiant du jeu de données et du cadre d'acquisition existant.
# 3 Le standard d'échange de métadonnées

Le but du présent standard est de permettre d'échanger les informations relatives au cadre d'acquisition et au jeu de données, s'appliquant au domaine terrestre ou marin, sur l'ensemble du territoire français (métropole et outre-mer).

## 3.1 Schéma de principe général

<figure><img src="image_8.png" /><figcaption>Figure 3: Schéma simplifié du standard</figcaption></figure>

## 3.2 Cadre d'acquisition, jeu de données

Les métadonnées décrivent des ensembles de données ayant des caractéristiques communes.

Au sein du SINP, on distingue deux niveaux de métadonnées pour décrire les données d'observation :

* **Le cadre d'acquisition**

Il décrit le contexte stratégique et opérationnel d'un programme ou d'un projet qui conduit à la production d'un ou de plusieurs jeux de données. Les métadonnées du cadre d'acquisition renseignent notamment sur l'objectif du programme d'acquisition, sur les moyens mis en œuvre, sur le contexte d'acquisition et sur les acteurs impliqués (maitres d'œuvre, maitre d'ouvrage).

* **Le jeu de données**

C'est un regroupement de données qui se veut homogène, c'est-à-dire qu'un jeu de données contiendra des données ayant des caractéristiques communes, notamment sur le protocole d'acquisition utilisé (par exemple un même plan d'échantillonnage, les mêmes paramètres recueillis, etc.). Les métadonnées du jeu de données renseigneront notamment sur le processus de collecte, sur les acteurs impliqués (producteurs, fournisseurs) et sur les modalités de diffusion de cet ensemble de données.
Pour plus d'informations, consulter le guide pour la constitution des jeux de données du SINP et le renseignement des métadonnées associées<fnref n="6" />.

## 3.3 Utilisateurs cibles

Le standard pour le partage des métadonnées s'adresse :

- Aux **plateformes du SINP** pour la circulation des métadonnées entre plateformes régionales et plateforme nationale;

- Aux **producteurs de données** pour la transmission des métadonnées à la plateforme nationale.

Le caractère obligatoire ou non des concepts et des attributs peut en conséquence varier en fonction du contexte d'utilisation du standard. Ainsi, pour les concepts et attributs concernés, ce document précise si leur caractère obligatoire ou facultatif diffère en fonction du contexte d'utilisation du standard.

D'un point de vue technique, le format d'échange recommandé est le CSV<fnref n="7" />. Les gabarits de saisie fournis avec ce document sont au format CSV.

## 4 Modèle conceptuel de données

Le modèle conceptuel de données permettant de décrire les métadonnées est transcrit par un diagramme de classes en UML et s'accompagne d'une description de chaque concept.

Il convient de noter qu'un modèle conceptuel de données ne fixe pas les règles physiques de gestion de données. Ainsi, toutes les clés étrangères ne sont pas explicitement mentionnées dans ce modèle, elles sont implicitement représentées par les associations (flèches et multiplicités) entre concepts.

<footnote n="6">⁶ https://inpn.mnhn.fr/docs-web/docs/download/244790</footnote>

<footnote n="7">⁷ D'autres formats sont possibles auquel cas il faut en discuter en amont de l'échange entre les deux parties (partie qui envoi les données et celle qui les reçoit)</footnote>
<figure><img src="image_9.png" /><figcaption>Figure 4: modèle conceptuel de données</figcaption></figure>
# 4.1 Guide de lecture du modèle conceptuel de données

## Couleurs de concepts :

- Les concepts gris clair sont obligatoires ;

- Les concepts gris foncé sont facultatifs ;

- Les concepts bleus sont des concepts types.

## Caractère obligatoire ou facultatif d'un attribut :

- Un attribut précédé par '#' est obligatoire ;

- Un attribut précédé par '+' est facultatif ;

- Un attribut obligatoire conditionnel est précédé par un '# et est suivi par une indication de multiplicité commençant par [0..].

## Multiplicité d'un attribut :

- [0..1] : attribut facultatif ne pouvant être utilisé qu'une seule fois, une seule valeur possible pour l'attribut ;

- [0..*] : attribut facultatif pouvant être utilisé plusieurs fois, plusieurs valeurs possibles pour l'attribut ;

- [1..*] : attribut obligatoire pouvant être utilisé plusieurs fois, au moins une valeur pour l'attribut et plusieurs sont possibles ;

- [1] ou pas de multiplicité indiquée pour les attributs obligatoires (#) : attribut obligatoire ne pouvant être utilisé qu'une seule fois, valeur unique mais obligatoire pour l'attribut.

# 4.2 Concepts obligatoires

Cette section contient les concepts qui véhiculent l'information minimale indispensable pour décrire les métadonnées du cadre d'acquisition et du jeu de données et permettre sa réutilisation ultérieure.

## 4.2.1 CadreAcquisition

Il décrit le contexte stratégique et opérationnel d'un programme ou d'un projet qui conduit à la production d'un ou de plusieurs jeux de données. Les métadonnées du cadre d'acquisition renseignent notamment sur l'objectif du programme d'acquisition, sur les moyens mis en œuvre, sur le contexte d'acquisition et sur les acteurs impliqués (maître-s d'œuvre, maître-s d'ouvrage).

Un ou plusieurs jeux de données ont pu être acquis au sein d'un même cadre d'acquisition.

Ce concept est **OBLIGATOIRE** pour l'échange de métadonnées.

ATTRIBUTS

<figure><img src="image_10.png" /></figure>

idSinpCA

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**. Si le producteur ne l'a pas renseigné, la plateforme du SINP doit le générer.

**Attention :** Vérifier si le cadre d'acquisition est déjà enregistré dans le SINP. Dans ce cas, renseigner l'identifiant existant.
ATTRIBUTS

libelleCA

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

descriptionCA

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

dateCreationFicheMtd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

dateLancementCA

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

dateClotureCA

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

objectifCA

Multiplicité : [1..*]

Cet attribut est **OBLIGATOIRE**. Il est possible de renseigner plusieurs valeurs pour cet attribut.

territoire

Multiplicité : [1..*]

Cet attribut est **OBLIGATOIRE**. Il est possible de renseigner plusieurs valeurs pour cet attribut.

domaineMarin

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.
ATTRIBUTS

* domaineTerrestre

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* echelleTerritoriale

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* acteurPrincipal

Multiplicité : [1]

Utilise le concept type ActeurType. Pour les règles de renseignement, voir le concept type ActeurType.

Au moins un des trois attributs suivants est obligatoire : identite, organisme ou idOrganisme

Le code renseigné pour roleActeur doit être 1 (contact principal).

Cet attribut est OBLIGATOIRE.

* acteurAutre

Multiplicité : [0...*]

Utilise le concept type ActeurType. Pour les règles de renseignement, voir le concept type ActeurType.

Si cet attribut est renseigné, au moins un des trois attributs suivants de ActeurType est obligatoire : identite, organisme ou idOrganisme

Cet attribut est FACULTATIF. Il est possible de renseigner plusieurs valeurs pour cet attribut.

* motCleCA

Multiplicité : [0...*]

Cet attribut est FACULTATIF. Il est possible de renseigner plusieurs valeurs pour cet attribut.

* idMetaCadreParent

Multiplicité : [0..1]

Cet attribut est FACULTATIF.
ATTRIBUTS

Attention : Vérifier si le métacadre d'acquisition est déjà enregistré dans le SINP. Dans ce cas, renseigner l'identifiant existant.

<figure><img src="image_11.png" /></figure>

estMetaCadre

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

4.2.2 JeuDeDonnees

Regroupement de données qui se veut homogène, c'est-à-dire qu'un jeu de données contiendra des données
ayant des caractéristiques communes, notamment sur le protocole de collecte utilisé. Les métadonnées du
jeu de données renseigneront notamment sur le protocole et la méthode de collecte, sur les acteurs impliqués
(producteurs, fournisseurs) et sur le statut public ou privé d'acquisition des données.

Ce concept est OBLIGATOIRE pour l'échange de métadonnées.

ATTRIBUTS

<figure><img src="image_12.png" /></figure>

idSinpJdd

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

Attention : Vérifier si le jeu de données est déjà enregistré dans le SINP. Dans ce cas, renseigner l'identifiant existant.

<figure><img src="image_13.png" /></figure>

idSinpCA

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

Attention : Vérifier si le cadre d'acquisition est déjà enregistré dans le SINP (ou vient d'être créé pour l'échange). Dans ce cas, renseigner l'identifiant existant.

Cet attribut sert à faire le lien entre un jeu de données et le cadre d'acquisition auquel il est rattaché. Son
utilisation peut varier selon l'outil de saisie des données. Il est obligatoire pour les données échangées via
des fichiers CSV. Pour les tables gérées en base de données, cet attribut est la clé étrangère entre les tables
CadreAcquisition et JeuDeDonnees.

<figure><img src="image_14.png" /></figure>

libelleJdd

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.
ATTRIBUTS

<figure><img src="image_15.png" /></figure>

libelleCourt

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_16.png" /></figure>

descriptionJdd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_17.png" /></figure>

dateCreationJdd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_18.png" /></figure>

typeDonnees

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_19.png" /></figure>

categorieDonnees

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_20.png" /></figure>

precisionCatDonnees

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Si le code de la valeur « autre » est renseigné pour l'attribut categorieDonnees, l'attribut precisionCatDonnees doit être renseigné pour préciser cette autre catégorie.

<figure><img src="image_21.png" /></figure>

characteristiqueJdd

Multiplicité : [0..*]

Cet attribut est **FACULTATIF**. Il est possible de renseigner plusieurs valeurs pour cet attribut.

<figure><img src="image_22.png" /></figure>

classeEBV

Multiplicité : [0..*]
ATTRIBUTS

Cet attribut est FACULTATIF. Il est possible de renseigner plusieurs valeurs pour cet attribut.

contactJdd

Multiplicité : [1..*]

Utilise le concept type ActeurType. Pour les règles de renseignement, voir le concept type ActeurType.

Au moins un contact pour le jeu de données est obligatoire.

Pour ce contact, le code de roleActeur doit être 1 (contact principal) et au moins un des trois attributs suivants de ActeurType doit être renseigné : identite, organisme ou idOrganisme.

Cet attribut est OBLIGATOIRE. Il est possible de renseigner plusieurs valeurs pour cet attribut.

contactPF

Multiplicité : [0..1]

Utilise le concept type ActeurType. Pour les règles de renseignement, voir le concept type ActeurType.

Le code de roleActeur doit être 1 (contact principal) et au moins un des trois attributs suivants doit être renseigné : identite, organisme ou idOrganisme.

Cet attribut est FACULTATIF et n'est utilisable que par les plateformes du SINP.

motCleJdd

Multiplicité : [0..*]

Cet attribut est FACULTATIF. Il est possible de renseigner plusieurs valeurs pour cet attribut.

statutOrigineDonnees

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

methodeCollecte

Multiplicité : [0..*]

Cet attribut est FACULTATIF. Il est possible de renseigner plusieurs valeurs pour cet attribut.

autreMethode

Multiplicité : [0..*]
ATTRIBUTS

Utilise le concept MethodeType. Pour les règles de renseignement, voir le concept type MéthodeType.

Cet attribut est FACULTATIF. Il est possible de renseigner plusieurs valeurs pour cet attribut.

precisionSurMethode

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

protocoleCollecte

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

autreProtocole

Multiplicité : [0..1]

Utilise le concept ProtocoleType. Pour les règles de renseignement, voir le concept type ProtocoleType.

Cet attribut est FACULTATIF.

precisionSurProtocole

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

suppressionJdd

Multiplicité : [0..1]

Cet attribut est FACULTATIF.
# 4.3 Concepts facultatifs

## 4.3.1 Publication

Publication associée au cadre d'acquisition ou au jeu de données.

Ce concept est **FACULTATIF** et peut être répété autant de fois que nécessaire.

### ATTRIBUTS

<figure><img src="image_23.png" /></figure>

* referencePublication

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_24.png" /></figure>

* urlPublication

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

<figure><img src="image_25.png" /></figure>

* descriptionPublication

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

<figure><img src="image_26.png" /></figure>

* typePublication

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

## 4.3.2 BaseProduction

Base de données ayant servi à la production du jeu de données.

Ce concept est **FACULTATIF**.

### ATTRIBUTS

<figure><img src="image_27.png" /></figure>

* contactBaseProd

Multiplicité : [0..*]

Le rôle de l'acteur (**roleActeur**) doit être **7** (point de contact base de données de production).

Pour les règles de renseignement, voir le concept type **ActeurType**.

Cet attribut est **FACULTATIF**. Il est possible de renseigner plusieurs valeurs pour cet attribut.
ATTRIBUTS

<figure><img src="image_28.png" /></figure>

baseProduction

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

4.3.3 ConformiteCoherence

Contrôle selon une procédure de conformité et de cohérence. Peut s'appliquer aux métadonnées du jeu de données ou aux données du jeu de données (indiquer via l'attribut typeControle).

La conformité désigne le respect des règles fixées dans le cadre de la mise en œuvre des formats standards de données et de métadonnées autant sur les aspects physiques que conceptuels (renseignement des champs obligatoires, format, utilisation des référentiels et des listes de valeurs/nomenclatures).

Exemple de conformité : la date transmise est de type date norme ISO8601 comme spécifié par le dictionnaire de données. L'attribut X est renseigné avec des valeurs conformes à la nomenclature définie dans le dictionnaire de données. L'attribut Y est renseigné avec le type d'information spécifié dans le dictionnaire de données (un nombre par exemple).

La cohérence désigne le respect de la logique combinatoire des informations transmises au sein des données,
au sein des métadonnées et entre les données et les métadonnées.

Exemple de non cohérence : la date de début de l'observation n'est pas antérieure à la date de fin de l'observation.

Consulter la procédure nationale pour la conformité et la cohérence :
https://inpn.mnhn.fr/programme/donnees-observations-especes/references/validation

Ce concept est FACULTATIF et peut être utilisé 2 fois au maximum. Une fois pour les métadonnées du jeu de données et une fois pour les données du jeu de données.

Ce concept est à utiliser par les plateformes du SINP.
ATTRIBUTS

<figure><img src="image_29.png" /></figure>

dateControle

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_30.png" /></figure>

organismeControle

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_31.png" /></figure>

typeControle

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_32.png" /></figure>

referenceOuUrl

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

### 4.3.4 NonConformeNonCoherent

Attributs optionnels étant erronés selon le contrôle de cohérence et de conformité, effectué par la plateforme nationale ou régionale du SINP, pour les métadonnées ou les données du jeu de données.

Ce concept est **FACULTATIF** et peut être répété autant de fois que nécessaire.

Ce concept est à utiliser par les plateformes du SINP.

ATTRIBUTS

<figure><img src="image_33.png" /></figure>

attrNonConfCoh

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_34.png" /></figure>

valeurInitiale

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.
### 4.3.5 AttributAdditionnel

Attribut pour lequel le standard ne prévoit pas de champ dédié ou de règle spécifique. Ces informations peuvent être véhiculées dans le standard en utilisant ce concept.

Ce concept est **FACULTATIF** et peut être répété autant de fois que nécessaire.

#### ATTRIBUTS

* nomAttributAdd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

* definitionAttributAdd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

* valeurAttributAdd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

* uniteAttributAdd

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

### 4.3.6 ModificationAttribut

Permet de garder un historique des modifications de valeur des attributs (cf. 'valeurInitialeModif').

Ce concept est **FACULTATIF** et peut être répété autant de fois que nécessaire.

#### ATTRIBUTS

* attrModif

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

* idConceptModif

Multiplicité : [1]
ATTRIBUTS

Cet attribut est **OBLIGATOIRE**. S'il existe, renseigner l'idSinp du concept auquel l'attribut appartient, sinon son identifiant d'origine.

Cet attribut sert à faire le lien entre l'attribut modifié et son concept. Son utilisation peut varier selon l'outil de saisie des données. Il est obligatoire pour les données échangées via des fichiers CSV. Pour les tables gérées en base de données, cet attribut est la clé étrangère permettant de faire le lien entre la modification d'un attribut et le concept auquel il est rattaché.

<figure><img src="image_35.png" /></figure>

dateModif

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_36.png" /></figure>

auteurModif

Multiplicité : [1]

Utilise le concept type ActeurType. Pour les règles de renseignement, voir le concept type ActeurType.

Règle de renseignement si utilisation de l'attribut :

- Le code renseigné pour roleActeur doit être 8 (valeur « auteur de la modification »)

- au moins un des trois attributs suivants doit être renseigné : identite, organisme ou idOrganisme.

Cet attribut est **FACULTATIF**.

<figure><img src="image_37.png" /></figure>

valeurInitialeModif

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_38.png" /></figure>

motifModif

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.
### 4.3.7 JeuDeDonneesLie

Permet de faire le lien entre plusieurs jeux de données de type de données identiques ou différents, qu'ils soient enregistrés dans le SINP ou sur une autre plateforme/base.

**Restriction : un jeu de données d'observations ne peut pas être lié à un autre jeu de données d'observations.**

Exemples :

- un jeu de données d'observation peut être lié avec un jeu de données sources mais également avec un jeu de données intermédiaires (élaborées/interprétées/de synthèse) et/ou avec deux jeux de données indicateurs.

- Un jeu de données indicateur peut être relié à quatre jeux de données sources, utilisées pour produire les indicateurs.

**ATTRIBUTS**

<figure><img src="image_39.png" /></figure>

idSinpJddLie

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il DOIT être renseigné si urlJddLie ne l'est pas.

Cet attribut sert à faire le lien entre deux jeux de données liés. Son utilisation peut varier selon l'outil de saisie des données. Il est obligatoire pour les données échangées via des fichiers CSV. Pour les tables gérées en base de données, cet attribut est la clé étrangère permettant la jointure entre deux jeux de données.

<figure><img src="image_40.png" /></figure>

urlJddLie

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il DOIT être renseigné si idSinpJddLie ne l'est pas.

<figure><img src="image_41.png" /></figure>

descriptionJddLie

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

<figure><img src="image_42.png" /></figure>

typeDonneesJddLie

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.
## 4.4 Types

### 4.4.1 ActeurType

Concept type qui doit être utilisé pour renseigner les attributs `acteurPrincipal` et `acteurAutre` de `CadreAcquisition`, les attributs `contactJdd` et `contactPF` de `JeuDeDonnées`, l'attribut `contactBaseProd` de `BaseProduction` et l'attribut `auteurModif` de `ModificationAttribut`.

Organisme, rôle de l'organisme, personne à contacter pour l'acteur considéré. L'acteur peut être de différents types (liste non exhaustive : point de contact principal, maître d'ouvrage, maître d'œuvre...).

Ce type est **OBLIGATOIRE** au moins une fois pour l'attribut `acteurPrincipal` de `CadreAcquisition` et l'attribut `contactJdd` de `JeuDeDonnees`.

**ATTRIBUTS**

<figure><img src="image_43.png" /></figure>

roleActeur

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_44.png" /></figure>

identite

Multiplicité : [0..1]

Règle de renseignement si utilisation de l'attribut : renseigner « INCONNU » si l'information n'est pas connue.

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il DOIT être renseigner si organisme ou idOrganisme ne le sont pas.

<figure><img src="image_45.png" /></figure>

organisme

Multiplicité : [0..1]

Règle de renseignement si utilisation de l'attribut :

- Renseigner « INCONNU » si l'information n'est pas connue ;

- Renseigner « INDEPENDANT » si l'acteur n'appartient pas à un organisme.

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il DOIT être renseigner si identite ou idOrganisme ne le sont pas.

<figure><img src="image_46.png" /></figure>

idOrganisme

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il DOIT être renseigner si identite ou organisme ne le sont pas.
ATTRIBUTS

<figure><img src="image_47.png" /></figure>

anonymisation

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il **DOIT** être renseigné si identite est renseigné.

4.4.2 MethodeType

Concept type qui doit être utilisé pour renseigner l'attribut autreMethode du concept JeuDeDonnees.

Permet d'indiquer la ou les méthodes de collecte utilisées pour le jeu de données qui ne sont pas référencées
dans CAMPanule (donc non renseignées dans methodeCollecte).

Un libellé, une description et une référence bibliographique ou lien url sont obligatoires. Ces attributs sont compatibles avec les champs de la table MÉTHODES de CAMPanule.

Ce concept est FACULTATIF et peut être répété autant de fois que nécessaire. Un protocole de collecte peut mettre en œuvre plusieurs méthodes au niveau d'un même jeu de données.

ATTRIBUTS

<figure><img src="image_48.png" /></figure>

libelleMethode

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_49.png" /></figure>

descriptionMethode

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_50.png" /></figure>

referenceMethode

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

4.4.3 ProtocoleType

Concept type qui doit être utilisé pour renseigner l'attribut autreProtocole du concept JeuDeDonnees.

Il ne peut il y avoir qu'un seul protocole de collecte associé à un même jeu de données, soit on renseigne
protocoleCollecte soit on renseigne autreProtocole.

Un libellé, une description et une référence bibliographique (ou un lien url) sont obligatoires. Ces attributs sont compatibles avec les champs de la table PROTOCOLES de CAMPanule.

Ce concept est FACULTATIF. Il ne peut il y avoir qu'un seul protocole de collecte associé à un même jeu de données.
ATTRIBUTS

<figure><img src="image_51.png" /></figure>

libelleProtocole

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_52.png" /></figure>

descriptionProtocole

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

<figure><img src="image_53.png" /></figure>

referenceProtocole

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

# 5 Annexe

## 5.1 Modifications entre les versions 1.3.10 et 2.0

### 5.1.1 Modifications générales

* Évolution de la terminologie :

- Le terme « concepts généraux » est remplacé par « concepts obligatoires »

- Le terme « extensions » est remplacé par « concepts facultatifs »

* Suppression du caractère « recommandé » des attributs. Désormais, 3 possibilités sont retenues : obligatoire, obligatoire conditionnel, facultatif

* Création d'un nouveau concept « type » : MethodeType

* Nouvelles règles de renseignement pour les attributs avec la multiplicité [0..*] ou [1..*] : lorsque le format de fourniture des données ne permet pas la répétition de l'attribut, la concaténation des multiples valeurs est utilisée avec le séparateur vertical « | ».

### 5.1.2 Ajout, modification et suppression de concepts

Les attributs du concept RéférenceTemporelle sont intégrés au concept CadreAcquisition car la multiplicité [1]-[1] entre les deux concepts ne justifie pas la création d'un concept à part entière.

Concepts ajoutés :

ModificationAttribut -> lié à CadreAcquisition et JeuDeDonnees, facultatif [0..*]

MethodeType -> utilisé dans JeuDeDonnees, facultatif [0..*]

JeuDeDonneesLie -> utilisé pour lier plusieurs jeux de données entre eux, facultatif [0..*]
Concepts modifiés :

AttributsAdditionnels -> renommé AttributAdditionnel

ProtocoleType -> attributs modifiés

Concepts supprimés :

RéférenceTemporelle -> attributs déplaces dans CadreAcquisition

BoundingBox (information calculée a posteriori)

5.1.3 Ajout, modification et suppression d'attributs

• Concept obligatoire CadreAcquisition :

Attributs ajoutés :

dateLancementCA -> obligatoire [1]

dateClotureCA -> facultatif [0..1]

domaineMarin -> facultatif [0..1]

domaineTerrestre -> facultatif [0..1]

Attributs modifiés :

libelle -> renommé libelleCA

objectif -> renommé objectifCA

description -> renommé descriptionCA

identifiantCadre -> renommé idSinpCA

niveauTerritorial -> renommé echelleTerritoriale

motCle -> renommé motCleCA

dateCreationMtd -> renommé dateCreationFicheMtd

Attributs supprimés :

voletSINP

precisionGeographique

typeFinancement

dateMiseAJourMtd

descriptionCible

cibleEcologiqueOuGeologique

referenceBiblio -> inutile car le concept Publication existe

idTPS

• Concept obligatoire JeuDeDonnees :

Attributs ajoutés :

statutOrigineDonnees -> facultatif [0..1]

methodeCollecte -> facultatif [0..*]

autreMethode -> facultatif [0..*]

precisionSurMethode -> facultatif [0..1]

protocoleCollecte -> facultatif [0..1]

precisionSurProtocole -> facultatif [0..1]

suppressionJdd -> facultatif [0..1]

categorieDonnees -> obligatoire [1]

classeEBV -> facultatif [0..*]

precisionCatDonnees -> facultatif [0..1]

caracteristiqueJdd -> facultatif [0..*] (remplace objectifJdd)
### Attributs modifiés :

protocoles -> renommé autreProtocole, facultatif [0..1], à renseigner via le concept type ProtocoleType (concept modifié)

dateCreation -> renommé dateCreationJdd

identifiantJdd -> renommé idSinpJdd

pointContactJdd -> renommé contactJdd

pointContactPF -> renommé contactPF

motCle -> renommé motCleJdd

identifiantCadre -> renommé idSinpCA

typeDonnees -> la nomenclature utilisée pour cet attribut a été complètement modifiée

### Attributs supprimés :

dateRevision

territoire

domaineMarin

domaineTerrestre

empriseGeographique

methodeRecueil

objectifJdd

* **Concept facultatif AttributAdditionnel :**

### Attribut ajouté :

uniteAttributAdd -> facultatif [0..1]

### Attribut modifié :

nomAttribut -> renommé nomAttributAdd

definitionAttribut -> renommé definitionAttributAdd

valeurAttribut -> renommé valeurAttributAdd

* **Concept facultatif BaseProduction :**

### Attribut modifié :

contactBaseProduction -> renommé contactBaseProd

* **Concept facultatif ConformiteCoherence :**

### Attribut ajouté :

referenceOuUrl -> obligatoire [1]

### Attribut supprimé :

protocole

* **Concept facultatif NonConformeNonCoherent :**

### Attribut modifié :

nomAttribut -> renommé attrNonConfCoh
* **Concept facultatif ModificationAttribut :**

**Attributs ajoutés :**

attrModif -> obligatoire [1]

idConceptModif -> obligatoire [1]

dateModif -> obligatoire [1]

auteurModif -> obligatoire [1], à renseigner via le concept type ActeurType

valeurInitialeModif -> obligatoire [1]

motifModif -> facultatif [0..1]

* **Concept facultatif Publication :**

**Attributs ajoutés :**

descriptionPublication -> facultatif [0..1]

typePublication -> facultatif [0..1]

* **Concept type ActeurType :**

**Attribut ajouté :**

idOrganisme -> obligatoire conditionnel, à renseigner selon le référentiel CodeOrganismeValue

anonymisation -> obligatoire conditionnel [0..1]

**Attribut modifié :**

nomPrenom -> renommé identite

**Attribut supprimé :**

mail

* **Concept type MethodeType :**

**Attributs ajoutés :**

referenceMethode -> obligatoire [1]

libelleMethode -> obligatoire [1]

descriptionMethode -> obligatoire [1]

* **Concept type ProtocoleType :**

**Attributs modifiés :**

uRL -> renommé en referenceProtocole, obligatoire [1]

libelle -> renommé en libelleProtocole, obligatoire [1]

description -> renommé descriptionProtocole, obligatoire [1]

**Attribut supprimé :**

typeProtocole
### 5.1.4 Ajout, modification et suppression de référentiels et nomenclatures

Les référentiels et nomenclatures sont décrits en détail dans le dictionnaire de données du SINP.

* Référentiels

**Référentiels ajoutés :**

CodeCAMPanuleValue

CodeOrganismeValue

CodeLocalisationValue

CodeTypoHabRefValue

* Nomenclatures

Pour toutes les nomenclatures d'attributs facultatif, suppression des valeurs 'inconnu', 'ne sait pas', 'non renseigné', 'non déterminé' qui n'apportent pas plus d'information qu'une valeur nulle (sauf cas exceptionnels).

**Nomenclature ajoutée :**

statutOrigineDonneesValue

categorieDonneesValue

caractistiqueJddValue (ancienne nomenclature objectifJddValue avec modification)

classeEBVValue

**Nomenclatures modifiées :**

typeDonneesValue -> valeurs totalement modifiées

objectifValue (cadre d'acquisition) -> renommé objectifCAValue et suppression des valeurs gelées

roleActeur -> ajout de la valeur « auteur de la modification »

**Nomenclatures supprimées :**

TypeFinancementValue

VoletSINPValue

MethodeRecueilValue

TypeProtocoleValue

objectifJddValue -> modifiée et renommée caractistiqueJddValue