# Standard d'échange pour les données d'observations et de suivis de taxons V3.0

Chloé Vinet, Solène Robert, Noëlie Maurel, Kévin Plaëtevoët, Paul Fromage, Pascal Dupont, Valerie 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 données d'observations et de suivis de taxons V3.0. PatriNat (OFB-MNHN-CNRS-IRD). 2023. mnhn-04625685

HAL Id: mnhn-04625685

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

Submitted on 21 Oct 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 DONNÉES D'OBSERVATIONS ET DE SUIVIS DE TAXONS

## Version 3.0

Mai 2023

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

<table><thead><tr><td>Version du document</td><td>Date</td><td>Commentaire</td></tr></thead><tbody><tr><td>2.0</td><td>15/03/2018</td><td>Version finale</td></tr><tr><td>3.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 OccTax 2.0.

## 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 pour les données d'observations et de suivis de taxons v3.0*, PatriNat (OFB-MNHN-CNRS-IRD), Paris, 54 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>5</td></tr><tr><td>2.1</td><td>Contexte et objectifs</td><td>5</td></tr><tr><td>2.1.1</td><td>Le SINP</td><td>5</td></tr><tr><td>2.1.2</td><td>Les standards d'échange</td><td>6</td></tr><tr><td>2.2</td><td>Principes et notations</td><td>7</td></tr><tr><td>2.2.1</td><td>Notation UML et diagramme de classes</td><td>7</td></tr><tr><td>2.2.2</td><td>Les concepts</td><td>8</td></tr><tr><td>2.2.3</td><td>Les attributs</td><td>8</td></tr><tr><td>2.2.4</td><td>Échange de l'information géographique</td><td>9</td></tr><tr><td>2.3</td><td>Guide de lecture du document</td><td>9</td></tr><tr><td>3</td><td>Le standard d'échange de données d'observations et suivis de taxons</td><td>11</td></tr><tr><td>3.1</td><td>Schéma de principe général</td><td>11</td></tr><tr><td>3.2</td><td>Observation, évènement d'observation et sujet d'observation</td><td>11</td></tr><tr><td>3.3</td><td>Utilisateurs cibles</td><td>13</td></tr><tr><td>4</td><td>Modèle conceptuel de données</td><td>13</td></tr><tr><td>4.1</td><td>Guide de lecture du modèle conceptuel de données</td><td>16</td></tr><tr><td>4.2</td><td>Concepts obligatoires</td><td>17</td></tr><tr><td>4.2.1</td><td>Evenement</td><td>17</td></tr><tr><td>4.2.2</td><td>SujetObservation</td><td>20</td></tr><tr><td>4.3</td><td>Concepts facultatifs</td><td>21</td></tr><tr><td>4.3.1</td><td>AttributAdditionnel</td><td>21</td></tr><tr><td>4.3.2</td><td>AutreResource</td><td>22</td></tr><tr><td>4.3.3</td><td>Determination</td><td>22</td></tr><tr><td>4.3.4</td><td>DescriptifSujet</td><td>24</td></tr><tr><td>4.3.5</td><td>DescriptifSujetStrate</td><td>27</td></tr><tr><td>4.3.6</td><td>Interaction</td><td>27</td></tr><tr><td>4.3.7</td><td>LienHabitats</td><td>28</td></tr><tr><td>4.3.8</td><td>ModificationAttribut</td><td>28</td></tr><tr><td>4.3.9</td><td>RegroupementEvenements</td><td>30</td></tr><tr><td>4.3.10</td><td>ValidationProducteur</td><td>31</td></tr><tr><td>4.3.11</td><td>ValidationRegionaleOuNationale</td><td>32</td></tr><tr><td>4.3.12</td><td>Strate</td><td>34</td></tr><tr><td>4.4</td><td>Types</td><td>35</td></tr></table>
<table><tr><td>4.4.1</td><td>DateHeureType</td><td>35</td></tr><tr><td>4.4.2</td><td>DenombrementType</td><td>37</td></tr><tr><td>4.4.3</td><td>HabitatType</td><td>38</td></tr><tr><td>4.4.4</td><td>LocalisationType</td><td>39</td></tr><tr><td>4.4.5</td><td>MethodeType</td><td>42</td></tr><tr><td>4.4.6</td><td>ObjetGeographiqueType</td><td>43</td></tr><tr><td>4.4.7</td><td>PersonneType</td><td>43</td></tr><tr><td>4.4.8</td><td>TechniqueType</td><td>44</td></tr><tr><td>5</td><td>Annexe</td><td>45</td></tr><tr><td>5.1</td><td>Modifications entre les versions 2.0 et 3.0 du standard</td><td>45</td></tr><tr><td>5.1.1</td><td>Modifications générales</td><td>45</td></tr><tr><td>5.1.2</td><td>Modification, ajout et suppression de concepts</td><td>46</td></tr><tr><td>5.1.3</td><td>Modification, ajout et suppression d'attributs</td><td>46</td></tr><tr><td>5.1.4</td><td>Modification, ajout et suppression de référentiels et nomenclatures</td><td>53</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 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·s concept·s 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.

Cette version fait suite au standard Occurrences de Taxon (OccTax) v2.0. **Le standard a été renommé « Observations et suivis de taxons (abrégé « SOT v3.0 ») » à l'occasion de cette version.**

Le nom a été modifié pour la version 3.0 afin d'être en cohérence avec son équivalence pour les habitats, le standard d'échange de données d'observations et suivis d'habitats (SOH) v2.0
# 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

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

<footnote n="2">² https://inpn.mnhn.fr/telechargement/referentiels/habitats</footnote>
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<fnref n="3" />, 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 ;

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

Le standard pour les taxons et celui pour les habitats suivent une logique commune : décrire un **évènement d'observation** (lieu, date, observateur), et les **observations réalisées** lors de cet évènement (le(s) taxon(s) ou le (les) habitat(s) observé(s), et selon quelle technique). Un lien peut être fait entre observations de taxons et observations d'habitats ainsi qu'entre les évènements d'observation de taxons et d'habitats.

<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 ;

- **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é.

<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>
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.2.4 Échange de l'information géographique

Dans ce document, la représentation spatiale de l'objet est modélisée par un attribut de type géométrique. Cet attribut a pour type « GM_Object ». Il s'agit d'une classe mère des objets géographiques en langage UML, elle permet de modéliser tous les types de géométries (points, lignes, polygones, etc.) sans présumer de leur format technique.

Ainsi, les jeux de données échangés dans le cadre du SINP devront se conformer au modèle de données conceptuel décrit dans la suite du document mais pourront prendre plusieurs formats techniques différents.

Dans le cadre du SINP, les jeux de données et leur information géographique peuvent ainsi être véhiculée via
plusieurs formats, notamment :

- Formats **Shapefile**, **GeoJSON** ou **Geopackage**<fnref n="6" /> : les points, lignes et polygones sont stockés dans des fichiers Shape de points, de lignes ou de polygones, ou dans un Geopackage ou GeoJSON.

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) ;

<footnote n="6">⁶ D'autres formats sont possibles auquel cas il faut en discuter en amont de l'échange entre les deux parties (partie qui envoie les données et celle qui les reçoit)</footnote>
- 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.

Modèle de présentation d'un concept et de ses attributs dans le document :

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

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

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 données d'observations et suivis de taxons

Le but du présent standard est de permettre de véhiculer des informations relatives aux **taxons de l'ensemble du domaine du vivant**, observés dans le domaine **terrestre** ou dans le domaine **marin**, sur l'ensemble territoire français (**métropole** et **outre-mer**).

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

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

## 3.2 Observation, évènement d'observation et sujet d'observation

- **Observation** : L'observation est l'identification selon des techniques directes (de visu) ou indirectes (empreintes, fèces...) de la présence ou de l'absence d'un taxon. Pour être valide, une observation doit comporter des informations sur son sujet d'observation (le Quoi), sa localisation (le Où), sa date de réalisation (le Quand), ainsi que les informations de son ou ses observateurs (le Qui) ;

- **L'évènement d'observation** : l'évènement d'observation porte toutes les informations relatives à un relevé. On retrouve dans l'évènement les informations sur le « où ? », le « qui ? » (l'observateur) et le
« quand ? ». Plusieurs évènements peuvent être regroupés, par exemple pour les besoins de mise en œuvre du protocole de collecte définit dans les métadonnées ;

- Quoi (Sujet d'observation) : Une observation décrit la présence d'un taxon. Ce taxon, organisme vivant partageant des caractères communs avec d'autres individus d'une unité de la classification du vivant (famille, genre, espèce, sous-espèce...) est le sujet de l'observation. La description du sujet d'observation comporte les informations relatives à la spécificité de l'organisme observé (sexe, stade biologique, comportement...) ainsi qu'à la technique de collecte mise en œuvre ayant aboutie à l'observation de l'organisme (le Comment). Ce sont des informations complémentaires utiles à la validation scientifique<fnref n="7" /> des données.

Le présent standard renvoie au **référentiel national TaxRef**, qui est un référentiel nomenclatural et taxonomique de tous les organismes vivant en France métropolitaine et outre-mer. Ce référentiel est unique pour la France ; il a pour but de lister et d'organiser les noms scientifiques de l'ensemble des êtres vivants recensés sur le territoire.

Pour faciliter la réutilisation des données à des fins de connaissance ou de valorisation, le présent standard préconise, pour un taxon donné, la mention du **CD_NOM**, c'est-à-dire l'identifiant unique du nom scientifique du taxon dans le référentiel TaxRef ;

- Taxon : Le taxon est une unité quelconque (genre, famille, espèce, sous-espèce, etc.) des classifications hiérarchiques des êtres vivants. Généralement le terme est employé aux rangs spécifique (l'espèce) et subspécifique (la sous-espèce).

- Où (Localisation) : La localisation correspond au lieu où le taxon a été observé. Elle correspond alors à un objet géographique ponctuel, linéaire ou surfacique ; simple ou multiple. Il représente la localisation de l'observation réelle avec son maximum de précision. Dans le cas où aucune localisation précise n'est disponible (données bibliographiques anciennes faisant référence à une observation communale...) il est indispensable de proposer un rattachement géographique de l'observation. Ce rattachement est une localisation approximative de l'observation selon un référentiel géographique spécifique. Plusieurs modalités de géolocalisation sont alors proposées dans le standard :

- Commune

- Maille 1*1, 5*5, 10*10 Km de la grille nationale

- Zonage marin national

- Département (utilisable seul uniquement dans le cas d'une donnée sensible de niveau 3, ou d'une donnée historique non précisément localisée)

Ces différents référentiels géographiques sont disponibles sur le site de l'Inventaire National du Patrimoine Naturel, à des adresses qui sont précisées plus bas dans le document.

**Une localisation, la plus précise disponible, doit être transmise pour l'évènement d'observation et peut être transmise pour le regroupement d'évènements.**

- Quand : Date (ou période) de l'observation lorsque cette précision existe.

- Qui : Personne·s morale·s ou physique·s ayant réalisé l'observation, la détermination, la validation de la donnée.

<footnote n="7">⁷ https://inpn.mnhn.fr/docs-web/docs/download/247445</footnote>
- **Validation scientifique** : La validation scientifique consiste en des processus d'expertises visant à renseigner sur la fiabilité (désigne le degré de confiance que l'on peut accorder à la donnée). Ces processus font intervenir des bases de connaissance et/ou de l'expertise directe.

Exemple :

o la donnée d'Atrichum angustatum (Brid.) Bruch & Schimp., observée le 5 janvier 2015 et située sur la maille 10kmL93E077N634 présente un bon niveau de fiabilité au regard des éléments fournis et de la répartition connue. La donnée est probable.

o la donnée de Tursiops truncatus (Montagu, 1821), observée le 3 août 2014 sur le département de l'Yonne est considérée comme trop improbable au regard de l'aire de répartition connue et de la niche écologique du taxon. La donnée est considérée comme invalide.

On distingue :

o La validation scientifique dite automatique qui consiste en une validation faisant appel à des résultats d'expertises préalables, (des référentiels, des bases de connaissances, etc.). Ce processus est réalisé de manière automatique (informatique) dans le cadre du SINP.

o La validation scientifique dite manuelle (nonobstant le fait qu'une interface informatique peut être utilisée) qui consiste en une validation des informations faisant appel à une expertise directe (avis d'expert suite à l'analyse des informations transmises). Ce processus est réalisé par un ou des experts dans le cadre du SINP.

Procédure nationale pour la validation scientifique : https://inpn.mnhn.fr/docs-web/docs/download/247445
(consulté le 08/12/22)

- **Comment (méthode et technique d'observation)** : Lien avec la méthode et la technique de collecte du référentiel des protocoles et méthodes (CAMPanule<fnref n="8" />) au niveau de l'évènement d'observation et de la description du sujet observé.

## 3.3 Utilisateurs cibles

Le standard pour le partage des données d'observations et de suivis de taxons s'adresse :

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

- Aux **producteurs de données** pour la transmission des donné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="9" /> (+ Shape, GeoPackage et GeoJSON pour les informations géographiques). 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 données d'observations et de suivis de taxons est transcrit par un diagramme de classes en UML et s'accompagne d'une description de chaque concept.

<footnote n="8">⁸ https://inpn.mnhn.fr/programme/campanule</footnote>

<footnote n="9">⁹ 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>
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.
<figure><img src="image_10.png" /><figcaption>Figure 4 : modèle conceptuel de données</figcaption></figure>
Les données sensibles et le standard d'échange SINP :

Selon les principes du SINP, les données sensibles sont partagées entre plateformes SINP au niveau de précision maximale mais leur diffusion et leur communication seront différenciées :

- Pour l'accès aux données par tout citoyen, la localisation précise des espèces sensibles est floutée selon les niveaux et les conditions définis au sein du référentiel de sensibilité.

- Pour accéder aux données précises sur les espèces sensibles, une demande motivée et nominative doit être formulée et acceptée. La communication de ces données fait l'objet d'un acte d'engagement de la part du demandeur en référence à une licence d'utilisation stricte qui n'autorise pas la rediffusion de ces données hormis l'obligation de dépôt légal des données biodiversité (études d'impacts).

Les données de localisation sensibles du SINP sont accessibles aux administrations publiques conformément aux textes qui les régissent.

Le floutage n'est donc pas effectué par le producteur mais par la plateforme du SINP pour les besoins de diffusion. S'agissant d'espèces rares et/ou menacées, il est en effet primordial que l'information précise puisse servir pour éviter les impacts sans pour autant entrainer un risque accru sur les espèces.

La localisation des données échangée via les standards SINP doit donc être la plus précise disponible. Le floutage sera appliqué pour la diffusion selon les procédures en vigueur.

Pour plus d'informations : https://inpn.mnhn.fr/telechargement/referentiels/sensibilite

## 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 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 pouvant être utilisé qu'une seule fois, une seule valeur obligatoire pour l'attribut.
## 4.2 Concepts obligatoires

Cette section contient les concepts qui véhiculent l'information minimale indispensable pour décrire une donnée d'observation de taxon et permettre sa réutilisation ultérieure.

### 4.2.1 Evenement

Événement de collecte d'information. Ce concept permet notamment de définir l'événement d'observation de taxon en caractérisant l'emprise géographique de l'observation (localisation), la date ou période du relevé, et l'observateur.

Ce concept est **OBLIGATOIRE**.

**Renseignement de la méthode de collecte au niveau de l'évènement d'observation en plus du jeu de données :**

En principe, la mise en œuvre d'une méthode génère plusieurs données (pas une observation seule). Ce qui semble le plus logique et complémentaire est donc de l'intégrer au niveau du jeu de donnée avec le protocole (si on connaît le protocole, a priori on sait s'il y a une méthode et laquelle, mais si on ne connaît pas/ou absence de protocole, alors renseigner une méthode peut être informatif).

La question d'intégrer la méthode également au niveau des données, peut être posée pour des protocoles particuliers.

Exemple : l'IQE (indice de qualité écologique)

Pour l'IQE on note toutes les espèces observées sur l'itinéraire de parcours du site (= technique "observation directe", pas méthode). On fait également une session de point d'écoute des oiseaux, de 10 minutes (= technique "écoute directe", méthode "point d'écoute"). On peut donc distinguer au moins deux évènements, avec des méthodes différentes (il est donc utile d'avoir la méthode au niveau de l'évènement). Si la méthode est au niveau du jeu de données, on ne peut pas distinguer quelles espèces ont été observées par quelle méthode. Cela est d'autant plus important qu'il est précisé dans l'IQE que les données du point d'écoute peuvent être utilisées au niveau national dans le cadre du STOC (suivi temporel des oiseaux communs) ce qui ne pourra pas être possible si les données de plusieurs méthodes sont mélangées.

Pour les cas comme l'IQE, il est donc nécessaire de pouvoir également renseigner les attributs relatifs à la méthode au niveau de l'évènement.

**ATTRIBUTS**

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

idSinpEvenement

Multiplicité : [1]

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

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

idOrigineEvenement

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.
ATTRIBUTS

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

idSinpJdd

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 jeu de données est déjà enregistré dans le SINP. Dans ce cas, renseigner l'identifiant existant.

Cet attribut sert à faire le lien entre un jeu de données et ses données. 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 sert de clé étrangère.

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

observateur

Multiplicité : [0..*]

Utiliser le concept type PersonneType. Pour les règles de renseignement, voir le concept type PersonneType.

Si cet attribut est utilisé alors au moins un des trois attributs de PersonneType suivants doit être renseigné :

- identite

- organisme

- idOrganisme

Cet attribut est **FACULTATIF**. Plusieurs valeurs possibles pour cet attribut.

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

verbatimObservateur

Multiplicité : [0..1]

Doit s'écrire : NOM Prénom (Organisme)

Si plusieurs observateurs : NOM Prénom (Organisme)1 | NOM Prénom (Organisme)2

Cet attribut est **FACULTATIF**.

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

dateEvenement

Multiplicité : [1]

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

Cet attribut est **OBLIGATOIRE**.

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

localisationEvenement
ATTRIBUTS

Multiplicité : [1]

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

Cet attribut est **OBLIGATOIRE**.

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

evenementSansObservation

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

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

methodeCollecte

Multiplicité : [0..1]

Un évènement ne peut avoir qu'une seule méthode. Si plusieurs méthodes sont mises en œuvre pour un même jeu de données, il faut créer autant d'évènements qu'il y a de méthodes.

Cet attribut est **FACULTATIF**. Ne **DOIT PAS** être renseigné si **autreMethode est renseigné**.

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

autreMethode

Multiplicité : [0..1]

Attribut utilisé pour renseigner une méthode de collecte qui n'est pas référencée dans CAMPanule.

Un évènement ne peut avoir qu'une seule méthode. Si plusieurs méthodes sont mises en œuvre pour un même évènement, il faut créer autant d'évènements qu'il y a de méthodes.

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

Cet attribut est **FACULTATIF**. Ne **DOIT PAS** être renseigné si **methodeCollecte est renseigné**.

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

precisionSurMethode

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

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

statutSource

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.
ATTRIBUTS

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

referenceSource

Multiplicité : [0..*]

Cet attribut est FACULTATIF. Plusieurs valeurs possibles pour cet attribut.

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

doublonDeEvenement

Multiplicité : [0..*]

Cet attribut est FACULTATIF. Plusieurs valeurs possibles pour cet attribut.

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

commentaireEvenement

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

4.2.2 SujetObservation

Sujet observé (taxon). À un même évènement d'observation peuvent être rattachés un ou plusieurs sujets d'observation.

Ce concept est OBLIGATOIRE.

ATTRIBUTS

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

idSinpSujetObs

Multiplicité : [1]

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

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

statutObservation

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

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

nomCite

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

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

idOrigineSujetObs
ATTRIBUTS

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

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

cdNom

Multiplicité : [0..1]

Cet identifiant est nommé CD_NOM dans le référentiel TaxRef. Il doit être fourni autant que possible, sauf s'il est constaté après recherche que le taxon considéré ne figure pas dans TaxRef.

Cet attribut est OBLIGATOIRE.

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

doublonDeSujetObs

Multiplicité : [0..*]

Cet attribut est FACULTATIF.

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

commentaireSujetObs

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

## 4.3 Concepts facultatifs

Cette section contient les concepts qui véhiculent une information complémentaire à l'information minimale, dont l'existence dépend du contexte de collecte de la donnée (par exemple, information sur la détermination du taxon) et/ou d'utilisation du standard (par exemple, information sur la validation régionale ou nationale).

### 4.3.1 AttributAdditionnel

Permet de définir tout attribut qui n'aurait pas été prévu dans la présente version du standard. Chaque attribut additionnel devra avoir un nom, une définition, et une valeur.

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

ATTRIBUTS

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

nomAttributAdd

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.
ATTRIBUTS

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

definitionAttributAdd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

valeurAttributAdd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

uniteAttributAdd

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

### 4.3.2 AutreRessource

Permet de véhiculer l'information selon laquelle d'autres ressources biologiques du sujet observé existent.

Par exemple une séquence ADN de l'organisme, ou s'il est conservé en collection.

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

ATTRIBUTS

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

typeRessource

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

lienRessource

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

### 4.3.3 Determination

Permet d'indiquer comment et par qui la détermination du taxon du sujet observé a été réalisée.

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

Toutefois, il est possible d'utiliser ModificationAttribut pour ne modifier qu'un seul attribut en particulier d'une des déterminations. Par exemple, modifier une information sur l'un des outils renseignés dans outilDetermination.
ATTRIBUTS

idSinpDetermination

Multiplicité : [1]

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

determinateur

Multiplicité : [0..1]

Utiliser le concept type PersonneType. Pour les règles de renseignement, voir le concept type PersonneType.

Si cet attribut est utilisé alors au moins un des trois attributs de PersonneType suivants doit être renseigné :

- identite

- organisme

- idOrganisme

Cet attribut est **FACULTATIF**.

dateDetermination

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

methodeDetermination

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

outilDetermination

Multiplicité : [0..*]

Cet attribut est **FACULTATIF**.

referenceOutilDetermination

Multiplicité : [0..*]

Cet attribut est **FACULTATIF**.

commentaireDetermination
ATTRIBUTS

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

4.3.4 DescriptifSujet

Permet d'indiquer toute information descriptive sur le sujet observé. Cela peut être un état biologique, un comportement, son sexe, par quelle technique il a été observé, etc...

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

Règle de renseignement du dénombrement du sujet observé :

Si le sujet observé concerne plusieurs organismes dénombrables selon les valeurs 'individu' de objetDenombrement et que ceux-ci sont de sexe différent ou diffèrent par toute autre caractéristique définie par les attributs du concept, alors devront être créés autant de DescriptifSujet que d'individus différents.

Exemple : Je compte 3 individus de l'espèce Felis silvestris, dont 2 femelles et 1 mâle. Je devrai créer un descriptif pour les deux femelles si aucune autre caractéristique définie par les attributs du concept ne les différencie, et un descriptif pour le mâle. Si les deux femelles se différencient par exemple par leur comportement ou leur état biologique, alors un descriptif par femelle devra être créé.

ATTRIBUTS

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

idSinpDescriptif

Multiplicité : [1]

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

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

techniqueCollecte

Multiplicité : [0..1]

Cet attribut est FACULTATIF. Ne DOIT PAS être renseigné si autreTechnique est renseigné.

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

autreTechnique

Multiplicité : [0..1]

Attribut utilisé pour renseigner une technique de collecte qui n'est pas référencée dans CAMPanule.

Un DescriptifSujet ne peut avoir qu'une seule technique. Si plusieurs techniques sont mises en œuvre pour un même descriptif, il faut créer autant de descriptifs qu'il y a de techniques.

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

Cet attribut est FACULTATIF. Ne DOIT PAS être renseigné si techniqueCollecte est renseigné.

precisionSurTechnique

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

etatBiologique

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

causeEtatBiologique

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

spontaneite

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

sexe

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

stadeBiologique

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

phaseBiologique

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

urlPreuveNumerique

Multiplicité : [0..*]
ATTRIBUTS

Cet attribut est FACULTATIF.

preuveNonNumerique

Multiplicité : [0..1]

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

Cet attribut est FACULTATIF.

comportement

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

denombrement

Multiplicité : [0..1]

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

Cet attribut est FACULTATIF.

indicePresence

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

codeAtlasNidification

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

statutSocial

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

supportOrganisme

Multiplicité : [0..1]
ATTRIBUTS

À utiliser pour les organismes sessiles.

Cet attribut est FACULTATIF.

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

commentaireDescriptif

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

### 4.3.5 DescriptifSujetStrate

Utilisé pour les relevés phytosociologiques. Permet de préciser pour chaque taxon son lien avec une ou plusieurs strates par la qualification de son abondance/dominance. Une seule utilisation de DescriptifSujetStrate par SujetObservation et codeStrate.

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

ATTRIBUTS

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

codeStrate

Multiplicité : [1]

Cet attribut est OBLIGATOIRE. Ce code doit être le même que celui renseigné dans le concept Strate décrivant la strate associée.

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

coefAbondanceDominance

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

### 4.3.6 Interaction

Permet de préciser l'interaction, si elle existe, entre deux taxons (sujets observés) relatifs à un même événement d'observation.

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

ATTRIBUTS

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

idSinpSujetObsLie

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.
ATTRIBUTS

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

typeInteraction

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

commentaireInteraction

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

### 4.3.7 LienHabitats

Permet de faire le lien avec un évènement d'observation d'habitat ou une observation d'habitat tel qu'identifié lors de l'échange de données via le standard Observations et Suivis d'Habitats. Permet également de faire le lien avec un habitat qui n'aurait pas déjà été enregistré dans le SINP.

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

ATTRIBUTS

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

evenementHabitat

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

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

observationHabitat

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

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

habitat

Multiplicité : [0..1]

Utiliser le concept type HabitatType. Pour les règles de renseignement, voir le concept type HabitatType.

Cet attribut est **FACULTATIF**.

### 4.3.8 ModificationAttribut

Permet de modifier la valeur d'un attribut du standard tout en conservant la valeur initiale pour permettre un historique des modifications effectuées.

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

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

attrModif

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

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

idConceptModif

Multiplicité : [1]

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_53.png" /></figure>

dateModif

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

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

auteurModif

Multiplicité : [0..1]

Utiliser le concept type PersonneType. Pour les règles de renseignement, voir le concept type PersonneType.

Si cet attribut est utilisé alors au moins un des trois attributs de PersonneType suivants doit être renseigné :

- identite

- organisme

- idOrganisme

Cet attribut est FACULTATIF.

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

valeurInitialeModif

Multiplicité : [0..1]

Cet attribut est OBLIGATOIRE.

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

motifModif
ATTRIBUTS

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

4.3.9 RegroupementEvenements

Permet de regrouper des évènements d'un même jeu de données, par exemple pour préciser la mise en œuvre d'un protocole de collecte.

Ce concept est FACULTATIF. Un même évènement ne peut être associé qu'à un seul regroupement et le concept de regroupement est récursif, un regroupement peut en comprendre un autre.

ATTRIBUTS

idSinpRegroupement

Multiplicité : [1]

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

typeRegroupement

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

nomRegroupement

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

localisationRegroupement

Multiplicité : [0..1]

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

Cet attribut est FACULTATIF.

idOrigineRegroupement

Multiplicité : [0..1]

Cet attribut est FACULTATIF.
ATTRIBUTS

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

estRegroupementParent

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

idRegroupementParent

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

## 4.3.10 ValidationProducteur

Indique les contrôles de validation scientifique et le niveau de validité attribué à la donnée d'observation de taxon par le producteur.

Ce concept est **FACULTATIF** : à utiliser seulement si la donnée a fait l'objet d'une validation scientifique par le producteur.

ATTRIBUTS

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

niveauValidationValProd

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

validateurValProd

Multiplicité : [0..1]

Utiliser le concept type PersonneType. Pour les règles de renseignement, voir le concept type PersonneType.

Si cet attribut est utilisé alors au moins un des trois attributs de PersonneType suivants doit être renseigné :

- identite

- organisme

- idOrganisme

Cet attribut est **FACULTATIF**.

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

dateValProd

Multiplicité : [0..1]
ATTRIBUTS

Cet attribut est FACULTATIF.

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

procedureValProd

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

## 4.3.11 ValidationRegionaleOuNationale

Décrit les opérations de validation scientifique et le niveau de validité attribué à la donnée d'observation de taxon. Les contrôles de validation scientifique ont été effectués au niveau régional et/ou national. Il n'est donc possible de transmettre que deux résultats de contrôle de validation au maximum via ce concept : l'un national, l'autre régional.

À utiliser seulement par les plateformes SINP si la donnée a été soumise à une procédure de validation scientifique nationale ou régionale (automatique, manuelle ou combinée).

Renseigner la dernière validation en date.

Ce concept est FACULTATIF.

Ce concept est à utiliser par les plateformes du SINP.

ATTRIBUTS

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

idSinpVal

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

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

niveauValidationValRegOuNat

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

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

validateurValRegOuNat

Multiplicité : [1]

Utiliser le concept type PersonneType. Pour les règles de renseignement, voir le concept type PersonneType.

Au moins un des trois attributs de PersonneType suivants doit être renseigné :

- identite

- organisme

- idOrganisme
ATTRIBUTS

Cet attribut est **OBLIGATOIRE**.

dateValRegOuNat

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

typeValidation

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

echelleValidation

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

perimetreValidation

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

producteur

Multiplicité : [0..1]

Utiliser le concept type PersonneType. Pour les règles de renseignement, voir le concept type PersonneType.

Au moins un des trois attributs de PersonneType suivants doit être renseigné :

- identite

- organisme

- idOrganisme

Cet attribut est **OBLIGATOIRE CONDITIONNEL** : il **DOIT** être renseigné si **dateContact** est utilisé.

dateContact

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL** : il **DOIT** être renseigné si **producteur** est utilisé.

procedureValRegOuNat
ATTRIBUTS

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL** : Il **DOIT** être renseigné si **procedureReference** n'est pas renseigné.

procedureVersion

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

procedureReference

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL** : Il **DOIT** être renseigné si **procedureValRegOuNat** n'est pas renseigné.

commentaireValidation

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

4.3.12 Strate

Un relevé phytosociologique s'effectue en déterminant les espèces présentes dans chaque niveau d'étagement végétal (arboré, arbustif, herbacé, muscinal et leurs potentielles déclinaisons) = strate. Une espèce peut être présente dans plusieurs strates.

Un relevé phytosociologique présente d'une part une description de chaque strate présente et étudiée (hauteur min, max et modale, recouvrement de cette strate par rapport à la surface totale) = concept Strate, d'autre part une répartition des espèces par strate (spécifiant l'abondance de cette espèce dans cette strate) = concept DescriptifSujetStrate lié au SujetObservation.

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

ATTRIBUTS

codeStrate

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

libelleStrate

Multiplicité : [1]
ATTRIBUTS

Cet attribut est **OBLIGATOIRE**.

definitionStrate

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

hauteurModaleInf

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

hauteurModaleSup

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

hauteurModaleVeg

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

recouvrementStrate

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

## 4.4 Types

Cette section présente les concepts « types » : ces concepts permettent 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.

### 4.4.1 DateHeureType

Ce concept type est appelé par l'attribut dateEvenement du concept Evenement.

Permet de définir une date exacte ou une période temporelle entre deux dates, qu'il s'agisse d'une période d'inventaire ou d'une date imprécise.
ATTRIBUTS

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

dateExacte

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il **DOIT** être renseigné si **dateDebut et dateFin** ne sont pas renseignés.

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

dateDebut

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il **DOIT** être renseigné si **dateExacte** n'est pas renseigné.

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

dateFin

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il **DOIT** être renseigné si **dateExacte** n'est pas renseigné.

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

dateImprecise

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

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

dateCitee

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

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

heureExacte

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**. Si l'heure d'observation est connue, cet attribut doit être renseigné si **heureDebut et heureFin** ne le sont pas.

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

heureDebut

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**. Si l'heure d'observation est connue, cet attribut doit être renseigné si **heureExacte** ne l'est pas.

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

heureFin
ATTRIBUTS

Multiplicité : [0..1]

Cet attribut est FACULTATIF. Si l'heure d'observation est connue, cet attribut doit être renseigné si heureExacte ne l'est pas.

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

heureImprecise

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

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

heureCitee

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

4.4.2 DenombrementType

Ce concept type est appelé par l'attribut denombrement du concept DescriptifSujet.

Permet de décrire un dénombrement de sujet d'observation : ce qui est dénombré, comment et combien.

Pour renseigner un dénombrement exact, renseigner les mêmes valeurs dans denombrementMin et denombrementMax.

Dans le cas d'un dénombrement avec bornes minimales et maximales, la valeur de denombrementMin doit être inférieure à celle de denombrementMax.

ATTRIBUTS

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

objetDenombrement

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

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

methodeDenombrement

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

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

denombrementMin

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

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

denombrementMax
ATTRIBUTS

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

4.4.3 HabitatType

Ce concept type est appelé par l'attribut habitat du concept LienHabitats.

Type d'habitat dans lequel l'observation a été réalisée.

Règle de renseignement d'une mosaïque d'habitats :

* Lorsque deux habitats au moins sont tels qu'on ne peut pas les individualiser au sein d'une entité spatiale donnée, on parle alors d'une mosaïque d'habitats.

* Par ailleurs, un même habitat peut être décrit selon plusieurs typologies d'habitats (par exemple, une typologie des végétations et EUNIS).

* Dans de rares cas, un habitat peut être décrit à travers au moins deux unités d'habitat différentes coexistant à un même niveau hiérarchique au sein d'une même typologie.

* Ces trois situations sont prises en compte dans ce standard à travers la cardinalité multiple entre les concepts Evenement et LienHabitats. **Si l'évènement d'observation est associé à une mosaïque d'habitat, il faut utiliser autant de fois que d'habitats** (de typologies différentes ou d'unités différentes de la même typologie) **le concept LienHabitats, en utilisant le concept type HabitatType et en renseignant TRUE pour estMosaique.** Tous les habitats renseignés comme étant des mosaïques, associés au même évènement, seront considérés comme les habitats composant la même mosaïque.

Toutefois, pour véhiculer des données d'observations d'habitats nous recommandons vivement d'utiliser le standard d'échange prévu à cet effet, le standard d'échange de données d'observations et de suivis d'habitats.

Un lien entre le standard habitats et le standard taxons est possible via le concept LienHabitats (attributs evenementHabitat et observationHabitat).

ATTRIBUTS

nomHabCite

Multiplicité : [0..1]

Cet attribut est OBLIGATOIRE CONDITIONNEL. Il DOIT être renseigné si les attributs codeHabCite et cdHab ne sont pas renseignés.

codeHabCite

Multiplicité : [0..1]
ATTRIBUTS

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il **DOIT** être renseigné si les attributs **nomHabCite** et **cdHab** ne sont pas renseignés.

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

nomTypologie

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

codeTypologieHabRef

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

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

versionTypologie

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

cdHab

Multiplicité : [0..1]

Cet identifiant est nommé CD_HAB dans le référentiel HabRef. Il doit être fourni autant que possible, sauf s'il est constaté après recherche que l'unité d'habitat considérée ne figure pas dans HabRef (soit parce que la typologie utilisée n'est pas intégrée dans HabRef, soit parce qu'elle est incomplète).

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il **DOIT** être renseigné si les attributs **nomHabCite** et **codeHabCite** ne sont pas renseignés.

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

versionHabRef

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

estMosaique

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

4.4.4 LocalisationType

Localisation de l'évènement d'observation et du regroupement d'évènements.
Ce concept type est appelé par les attributs localisationEvenement et localisationRegroupement des concepts Evenement et RegroupementEvenements.

Ce concept est **OBLIGATOIRE** pour l'évènement d'observation et facultatif pour le regroupement d'évènements.

## La localisation des données échangées au SINP :

**La localisation de la donnée transmise doit être la plus précise disponible.** Si la localisation transmise n'est pas la plus précise disponible, l'indiquer via l'attribut transmissionPrecise.

Le type de localisation de la donnée doit correspondre à une valeur comprise dans la nomenclature de l'attribut localisationType.

En fonction du type de localisation, soit renseigner le codeLocalisation correspondant au type soit renseigner une géométrie précise via ObjetGeographiqueType.

### ATTRIBUTS

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

typeLocalisation

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

codeLocalisation

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il DOIT être renseigné si la valeur renseignée pour typeLocalisation est différente de 5 (code de la valeur géométrie).

Se référer à la partie sur les référentiels dans le dictionnaire de donnés pour savoir quel code indiquer pour chaque type de localisation.

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

anneeRef

Multiplicité : [0..1]

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Il DOIT être renseigné si le typeLocalisation renseigné est un référentiel INSEE (région, commune, département, collectivité d'outre-mer).

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

objetGeo

Multiplicité : [0..1]

Utilise le concept type ObjetGeographiqueType. Pour les règles de renseignement, voir le concept type ObjetGéographiqueType.

Cet attribut est **OBLIGATOIRE CONDITIONNEL**. Le concept type ObjetGeographiqueType DOIT être renseigné si la valeur renseignée pour typeLocalisation est 5 (code de la valeur géométrie).
ATTRIBUTS

* natureObjetGeo

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* nomLocalisation

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* altitudeMin

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* altitudeMoy

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* altitudeMax

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* profondeurMin

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* profondeurMoy

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

* profondeurMax

Multiplicité : [0..1]

Cet attribut est FACULTATIF.
ATTRIBUTS

transmissionPrecise

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

pente

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

exposition

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

textureSol

Multiplicité : [0..1]

Cet attribut est FACULTATIF.

4.4.5 MethodeType

Ce concept type est appelé par l'attribut autreMethode du concept Evenement.

Permet d'indiquer une méthode de collecte qui n'est pas déjà référencée dans CAMPanule. 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.

ATTRIBUTS

libelleMethode

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

descriptionMethode

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.
ATTRIBUTS

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

referenceMethode

Multiplicité : [1]

Cet attribut est OBLIGATOIRE.

4.4.6 ObjetGeographiqueType

Permet de définir l'objet géographique de l'événement ou du regroupement d'évènements.

Ce concept type est appelé par l'attribut objetGeo du concept type LocalisationType.

Ce concept est **OBLIGATOIRE si 5 (code de la valeur geometrie) est renseigné pour typeLocalisation.**

ATTRIBUTS

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

geometrie : GM_Object

Multiplicité : [1]

Pour renseigner cet attribut trois cas de figure sont possibles :

- Créer deux champs « X » et « Y » dans lesquels sont renseignées les coordonnées X et Y d'un point

- Créer un champ « WKT » dans lequel est renseigné le WKT d'un point, d'une ligne ou d'un polygone

- Renseigner dans le champ « geometrie » la CléObjet (l'identifiant) de l'objet géographique indiquée dans les fichiers SIG échangés avec les données

Cet attribut est **OBLIGATOIRE**.

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

codeEPSG

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

precisionGeometrie

Multiplicité : [0..1]

Cet attribut est **FACULTATIF**.

4.4.7 PersonneType

Permet de définir la ou les personne(s) ayant procédé à l'observation / la détermination / la validation du taxon/de l'observation.
ATTRIBUTS

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

identite

Multiplicité : [0..1]

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

Doit s'écrire : NOM Prénom

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

<figure><img src="image_95.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 la personne n'appartient pas à un organisme.

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

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

idOrganisme

Multiplicité : [0..1]

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

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

anonymisation

Multiplicité : [0..1]

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

4.4.8 TechniqueType

Ce concept type est appelé par l'attribut autreTechnique du concept DescriptifSujet.

Permet d'indiquer une technique de collecte qui n'est pas déjà référencée dans CAMPanule. Un libellé, une description et une référence bibliographique ou lien url sont obligatoires. Ces attributs sont compatibles avec les champs de la TECHNIQUES de CAMPanule.
ATTRIBUTS

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

libelleTechnique

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

descriptionTechnique

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

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

referenceTechnique

Multiplicité : [1]

Cet attribut est **OBLIGATOIRE**.

# 5 Annexe

## 5.1 Modifications entre les versions 2.0 et 3.0 du standard

### 5.1.1 Modifications générales

* Évolution de la terminologie :

- Le terme « concepts centraux » 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.

* 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 « | ».

* Intégration du standard de données phytosociologie v2.0 (celui-ci devient donc caduc) :

Un relevé phytosociologique est composé d'une liste d'espèces décrites par strate végétale, d'attributs stationnels et d'une association avec un syntaxon et/ou plusieurs unités d'habitat (EUNIS, Corine, cahiers d'habitats).

Au regard de la (très) grande proximité des données (et de leur structuration) collectées dans le cadre d'un relevé d'observation de taxons ou d'un relevé phytosociologique, les informations spécifiques à un relevé phytosociologique peuvent être intégrées dans le standard d'observations et de suivis de taxons, et ainsi abandonner le standard dédié aux données de relevés phytosociologiques.
L'intégration des données complémentaires attendues dans le cadre d'un relevé phytosociologique engendre la création de deux nouveaux concepts facultatifs et l'ajout d'attributs facultatifs dans LocalisationType.

### 5.1.2 Modification, ajout et suppression de concepts

#### Refonte complète de concepts

Le concept Evenement est créé. Il reprend toutes les informations potentiellement communes à un relevé, dont celles préalablement rattachées au SujetObservation. L'évènement comprend les informations sur le « où ? », le « quand ? » et le « qui ? », et le SujetObservation garde les informations sur le « quoi ? ». De plus, RegroupementObservations est renommé RegroupementEvenements (regroupement d'évènements par exemple pour préciser la mise en œuvre du protocole de collecte associé au jeu de données).

Un évènement ne peut être associé qu'à une seule information géographique (localisation, le « où ? »). De ce fait les concepts traduisant une information géographique sont tous regroupés sous un unique concept type, LocalisationType.

* Concepts ajoutés : AutreRessource, Détermination, DescriptifSujetStrate, Interaction, LienHabitats, Strate, DateHeureType, LocalisationType, MethodeType, TechniqueType.

* Concepts modifiés :

- SujetObservation est décomposé en deux concepts -> nouveau concept Évènement qui comprend les informations sur le « qui ? », « quand ? » et « où ? », et SujetObservation qui comprend les informations sur le « quoi ? »

- DenombrementType -> attributs modifiés

- PersonneType -> attributs modifiés

- HabitatType -> attributs modifiés

- ObjetGeographiqueType -> attributs modifiés

- DescriptifSujet -> attributs modifiés

- AttributAdditionnel -> attributs modifiés

- Modification -> renommé ModificationAttribut pour mieux comprendre qu'il s'applique aux attributs

- RegroupementObservations -> renommé RegroupementEvenements

* Concepts supprimés :

- Doublon -> attributs intégrés à Evenement

- Source -> certains attributs sont intégrés à SujetObservation

- Département, Commune, MasseEau, Maille10x10, EspaceNaturel (MasseEau et EspaceNaturel étant complètement supprimés car croisements a posteriori) -> département, commune et maille10x10 intégrés au nouveau concept type LocalisationType en tant que valeurs de la nomenclature typeLocalisationValue

- OrganismeType -> attributs intégrés à PersonneType

- ElémentsDéplacés

### 5.1.3 Modification, ajout et suppression d'attributs

* Concept obligatoire Evenement

Attributs ajoutés :

idSinpEvenement

idOrigineEvenement
idSinpJdd -> déplacé depuis Source, concept supprimé

observateur -> déplacé depuis SujetObservation

verbatimObservateur

dateEvenement

localisationEvenement

evenementSansObservation

methodeCollecte

autreMethodeCollecte

precisionSurMethode

statutSource -> déplacé depuis Source, concept supprimé

referenceBiblio -> déplacé depuis Source, concept supprimé et renommé referenceSource

doublonDeEvenement -> déplacé depuis Doublon, concept supprimé

commentaireEvenement

## Concept obligatoire SujetObservation

**Attribut ajouté :**

idOrigineSujetObs -> déplacé depuis le concept Source (concept supprimé) et renommé idOrigineSujetObs, facultatif

doublonDeSujetObs -> facultatif

**Attributs modifiés :**

idSinpOccTax -> renommé idSinpSujetObs

commentaire -> renommé commentaireSujetObs

**Attributs supprimés :**

dateDebut -> déplacé dans le concept type DateHeureType

dateFin -> déplacé dans le concept type DateHeureType

heureDebut -> déplacé dans le concept type DateHeureType

heureFin -> déplacé dans le concept type DateHeureType

observateur -> déplacé dans le concept Evenement

objetGeo -> déplacé dans le concept type LocalisationType

determinateur -> déplacé dans le concept Determination

dateDetermination -> déplacé dans le concept Determination

altitudeMin -> déplacé dans le concept type LocalisationType

altitudeMoyenne -> déplacé dans le concept type LocalisationType

altitudeMax -> déplacé dans le concept type LocalisationType

prodondeurMin -> déplacé dans le concept type LocalisationType

profondeurMoyenne -> déplacé dans le concept type LocalisationType

profondeurMax -> déplacé dans le concept type LocalisationType

denombrement -> déplacé dans le concept DescriptifSujet

habitat -> déplacé dans le concept LienHabitats

## Concept type LocalisationType

**Attributs ajoutés :**

typeLocalisation -> obligatoire ; à renseigner selon typeLocalisationValue

codeLocalisation -> obligatoire conditionnel ; à renseigner selon les référentiels en vigueur
anneeRef -> obligatoire conditionnel (déplacé depuis Commune et Département (concepts supprimés))
objetGeometrie -> obligatoire conditionnel, à renseigner selon ObjetGeographiqueType
natureObjetGeo -> facultatif (déplacé depuis ObjetGeographiqueType)
nomLocalisation -> facultatif (repris de nomLieu, déplacé depuis ObjetGeographiqueType)
altitudeMin -> facultatif (déplacé depuis SujetObservation)
altitudeMoy -> facultatif (déplacé depuis SujetObservation)
altitudeMax -> facultatif (déplacé depuis SujetObservation)
profondeurMin -> facultatif (déplacé depuis SujetObservation)
profondeurMoy -> facultatif (déplacé depuis SujetObservation)
profondeurMax -> facultatif (déplacé depuis SujetObservation)
transmissionPrecise -> facultatif
pente -> facultatif
exposition -> facultatif
textureSol -> facultatif

* **Concept type ObjetGéographiqueType**

**Attribut ajouté :**

codeEPSG -> obligatoire

**Attribut supprimé :**

nomLieu -> déplacé dans le concept LocalisationType et renommé nomLocalisation

* **Concept type PersonneType**

**Attributs ajoutés :**

idOrganisme -> obligatoire conditionnel, à renseigner selon le référentiel CodeOrganismeValue
anonymisation -> obligatoire conditionnel si l'identité est renseignée

**Attributs modifiés :**

identite -> obligatoire conditionnel
organisme -> devient obligatoire conditionnel et n'appelle plus le concept OrganismeType. Le nom de l'organisme est renseigné via cet attribut.

**Attribut supprimé :**

mail

* **Concept type DateHeureType**

**Attributs ajoutés :**

dateExacte -> obligatoire conditionnel
dateCitee -> facultatif
dateDebut -> déplacé depuis le concept SujetObservation, devient obligatoire conditionnel
dateFin -> déplacé depuis le concept SujetObservation, devient obligatoire conditionnel
dateImprecise -> facultatif
heureExacte -> facultatif
heureDebut -> déplacé depuis le concept SujetObservation, facultatif
heureFin -> déplacé depuis le concept SujetObservation, facultatif
heureCitee -> facultatif
heureImprecise -> facultatif

* **Concept type TechniqueType**

**Attributs ajoutés :**

libelleTechnique -> obligatoire si ce concept est utilisé

descriptionTechnique -> obligatoire si ce concept est utilisé

referenceTechnique -> obligatoire si ce concept est utilisé

* **Concept type MethodeType**

**Attributs ajoutés :**

libelleMethode -> obligatoire si ce concept est utilisé

descriptionMethode -> obligatoire si ce concept est utilisé

referenceMethode -> obligatoire si ce concept est utilisé

* **Concept type DenombrementType**

**Attributs modifiés :**

typeDenombrement -> renommé methodeDenombrement, à renseigner selon la nomenclature

methodeDenombrementValue

* **Concept type HabitatType**

**Attributs ajoutés :**

nomHabCite -> obligatoire si ce concept est utilisé

estMosaique -> obligatoire si ce concept est utilisé

versionTypologie -> obligatoire si ce concept est utilisé

codeTypologieHabRef -> facultatif

**Attributs modifiés :**

codeHabitat -> renommé codeHabCite, obligatoire si ce concept est utilisé

codeHabRef -> renommé cdHab, obligatoire si ce concept est utilisé

refHabitat -> renommé nomTypologie, obligatoire si ce concept est utilisé

versionRef -> renommé versionHabRef, obligatoire si ce concept est utilisé

* **Concept facultatif LienHabitats**

**Attributs ajoutés :**

evenementHabitat -> obligatoire conditionnel

observationHabitat -> obligatoire conditionnel

habitat -> déplacé depuis SujetObservation, à renseigner via le concept HabitatType, obligatoire conditionnel

* **Concept facultatif Strate**

**Attributs ajoutés :**

codeStrate -> obligatoire

libelleStrate -> obligatoire

definitionStrate -> facultatif
hauteurModaleInf -> facultatif

hauteurModaleSup -> facultatif

hauteurModaleVeg -> facultatif

recouvrementStrate -> facultatif

* **Concept facultatif Determination**

**Attributs ajoutés :**

idSinpDetermination -> obligatoire si ce concept est utilisé

déterminateur -> déplacé depuis SujetObservation, à renseigner via le concept PersonneType, obligatoire si ce concept est utilisé

dateDetermination -> déplacé depuis SujetObservation, à renseigner via le concept DateHeureType, obligatoire si ce concept est utilisé

methodeDetermination -> facultatif

outilDetermination -> facultatif

referenceOutilDetermination -> facultatif

commentaireDetermination -> facultatif

* **Concept facultatif AttributAdditionnel**

**Attributs modifiés :**

nomAttribut -> renommé en nomAttributAdd

definitionAttribut -> renommé definitionAttributAdd

valeurAttribut -> renommé valeurAttributAdd

uniteAttribut -> renommé uniteAttributAdd

**Attributs supprimés :**

thematiqueAttribut

typeAttribut

* **Concept facultatif ValidationProducteur**

**Attributs modifiés :**

nivVal -> renommé niveauValidationValProd, devient obligatoire si ce concept est utilisé

dateCtrl -> renommé dateValProd

validateur -> renommé validateurValProd

procedure -> renommé procedureValProd

* **Concept facultatif ValidationRégionaleOuNationale**

**Attribut ajouté :**

IdSinpVal -> obligatoire si ce concept est utilisé

**Attributs modifiés :**

dateCtrl -> renommé dateValRegOuNat, devient obligatoire si ce concept est utilisé

nivVal -> renommé niveauValidationValRegOuNat, obligatoire si ce concept est utilisé, à renseigner selon la nomenclature niveauValidationValue

validateur -> renommé validateurValRegOuNat, obligatoire si ce concept est utilisé, à renseigner via le concept type PersonneType
typVal -> renommé typeValidation, devient obligatoire conditionnel si ce concept est utilisé, à renseigner selon
la nomenclature typeValidationValue

echVal -> renommé echelleValidation, devient obligatoire conditionnel si ce concept est utilisé, à renseigner
selon la nomenclature echelleValidationValue

periVal -> renommé perimetreValidation, devient obligatoire conditionnel si ce concept est utilisé, à
renseigner selon la nomenclature perimetreValidationValue

producteur -> devient obligatoire conditionnel, à renseigner via le concept type PersonneType

dateContact -> renommé dateValRegOuNat, devient obligatoire conditionnel

procedure -> renommé procedureValRegOuNat, devient obligatoire si ce concept est utilisé

procVers -> renommé procedureVersion, devient obligatoire conditionnel si ce concept est utilisé

procRef -> renommé procedureReference, devient obligatoire conditionnel si ce concept est utilisé

* **Concept facultatif ModificationAttribut**

**Attributs ajoutés :**

idConceptMod -> obligatoire si ce concept est utilisé

valeurInitialeMod -> obligatoire si ce concept est utilisé

**Attributs modifiés :**

dateMod -> devient obligatoire si ce concept est utilisé

auteurMod -> devient obligatoire si ce concept est utilisé

attrMod -> devient obligatoire si ce concept est utilisé

**Attribut supprimé :**

criticité

* **Concept facultatif DescriptifSujet : le préfixe « occ » est supprimé des attributs**

**Attributs ajoutés :**

denombrement -> déplacé depuis SujetObservation, facultatif, à renseigner via le concept type

DenombrementType

statutSocial -> facultatif

supportOrganisme -> facultatif

codeAtlasNidification -> facultatif

causeEtatBiologique -> facultatif

idSinpDescriptif -> obligatoire si ce concept est utilisé

techniqueCollecte -> facultatif, à renseigner via le référentiel techniqueCollecteValue

autreTechnique -> facultatif, à renseigner via le concept type TechniqueType

precisionSurTechnique -> facultatif

commentaireDescriptif -> facultatif

**Attributs modifiés :**

occEtatBiologique -> renommé etatBiologique

occNaturalité -> renommé spontaneite

occSexe -> renommé sexe

occStadeDeVie -> renommé stadeBiologique

occStatutBiologique -> renommé phaseBiologique

occComportement -> renommé comportement

**Attributs supprimés :**
obsTechnique

occStatutBiogéographique

preuveExistante

obsDescription

obsContexte

occMethodeDétermination

* **Concept facultatif DescriptifSujetStrate**

**Attributs ajoutés :**

codeStrate -> obligatoire

coefAbondanceDominance -> obligatoire

* **Concept facultatif RegroupementÉvènements**

**Attributs ajoutés :**

localisationRegroupement -> facultatif, à renseigner via le concept type LocalisationType

estRegroupementParent -> obligatoire

idRegroupementParent -> facultatif

commentaireRegroupement -> facultatif

nomRegroupement -> facultatif

**Attributs modifiés :**

typeRegroupement -> devient un champ texte libre

idOrigine -> renommé en idOrigineRegroupement

**Attributs supprimés :**

methodeRegroupement

techniqueEchantillonnage

tailleEchantillon

uniteTailleEchantillonnage

effortEchantillonnage

* **Concept facultatif Interaction**

**Attributs ajoutés :**

idSinpSujetObsLie -> obligatoire si ce concept est utilisé

typeInteraction -> obligatoire si ce concept est utilisé, à renseigner selon la nomenclature

typeInteractionValue

commentaireInteraction -> facultatif

* **Concept facultatif AutreRessource**

**Attributs ajoutés :**

typeRessource -> obligatoire si ce concept est utilisé

identifiantRessource -> obligatoire si ce concept est utilisé
### 5.1.4 Modification, ajout et suppression de référentiels et nomenclatures

Les référentiels et métadonnées sont décrits en détail dans le dictionnaire de données.

#### • Référentiels

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

- CodeOrganismeValue

- CodeLocalisationValue (agrégation de plusieurs référentiels)

- CodeCAMPanuleValue

- CodeTypoHabRefValue

**Référentiels modifiés :**

CodeCommuneValue -> lien INSEE mis à jour vers la version la plus récente du référentiel

CodeDépartementValue -> lien INSEE mis à jour vers la version la plus récente du référentiel

CodeHabRefValue -> lien INPN mis à jour vers la version la plus récente du référentiel

CodeTaxRefValue -> lien INPN mis à jour vers la version la plus récente du référentiel

**Référentiels supprimés :**

codeENValue

codeMasseEauValue

IDCNPValue

CodeHabitatValue

NomCommuneValue

#### • Nomenclatures

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

**Nomenclatures ajoutées :**

methodeDeterminationValue

typeInteractionValue

statutSocialValue

typeLocalisationValue

codeStrateValue

coefAbondanceDominanceValue

expositionValue

textureSolValue

typeInteractionValue

**Nomenclatures modifiées :**

- natureObjetGeoValue -> suppression de la valeur 'NSP : Ne sait pas : L'information est inconnue'

- objetDénombrementValue -> suppression des valeurs 'nid', 'inconnu', 'surface' ; ajout des valeurs 'inflorescence', 'herbier massif', 'carpophore', 'indice de présence', 'clone' et 'contact acoustique'

- occEtatBiologiqueValue -> renommé etatBiologiqueValue ; suppression de toutes les valeurs, remplacées par 'mort', 'vivant', 'blessé' et 'dégradé'

- OccurrenceNaturaliteValue -> renommé spontaneiteValue ; suppression des valeurs 'inconnu' et 'féral' ; nouvelles valeurs 'sauvage/spontané', 'échappé/subspontanné' et 'non déterminable'
- occSexeValue -> renommé en sexeValue ; suppression des valeurs 'inconnu', 'indéterminé', 'non renseigné'

- occStadeDeVieValue -> renommé en stadeBiologiqueValue ; nomenclature remplacée par celle de la base de traits TaxRef (voir lien)

- occStatutBiologiqueValue -> renommé en phaseBiologiqueValue ; suppression des valeurs 'inconnu', 'non renseigné', 'non déterminable' et 'pas de reproduction/végétatif' ; ajout des valeurs 'gestation', 'floraison', 'fructification', 'dissémination', 'graine', 'migration' et 'décrépitude'

- statutObservationValue -> comprend maintenant uniquement les valeurs 'absent' et 'présent'

- typeDenombrementValue -> renommé en methodeDenombrementValue

- niveauValidationValue -> la valeur 'certain – très probable' est renommée 'certain'

- occComportementValue -> renommé comportementValue ; hiérarchisation des valeurs et ajouts

Nomenclatures supprimées :

CriticiteValue

dEEFloutageValue

DSPubliqueValue

NiveauPrecisionValue

ObservationTechniqueValue

OccurrenceStadeDeVieValue : remplacée par stadeBiologiqueValue

OccurrenceStatutBiogeographiqueValue

PreuveExistanteValue

SensibiliteValue

TypeAttributValue

TypeENValue

TypeInfoGeoValue

TypeRegroupementValue : typeRegroupement devient un champ texte libre

VersionMasseDEauValue