[obsolète][version de travail]Test du Darwin Core et du standard d'échange pour l'observation et le suivi de taxons du SINP aux données de surveillance de la biodiversité

Chloé Vinet, Guillaume Body

► To cite this version:

Chloé Vinet, Guillaume Body. [obsolète][version de travail]Test du Darwin Core et du standard d'échange pour l'observation et le suivi de taxons du SINP aux données de surveillance de la biodiversité. 2024. mnhn-04830824

HAL Id: mnhn-04830824

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

Preprint submitted on 11 Dec 2024

**HAL** is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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>
# Test du Darwin Core et du standard d'échange pour l'observation et le suivi de taxons du SINP aux données de surveillance de la biodiversité

Chloé Vinet, Guillaume Body

<figure><img src="image_2.png" /></figure>
# PATRINAT

## Centre d'expertise et de données
sur le patrimoine naturel

Un service commun
de l'Office français de la biodiversité,
du Muséum national d'Histoire naturelle,
du Centre national de la recherche scientifique
et de l'Institut pour la recherche et le développement

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

RÉPUBLIQUE
FRANÇAISE

Liberté
Égalité
Fraternité

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

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

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

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

Nom du projet : Standardisation des données de surveillance

Convention et financeurs : Biodiversa +

Responsable de l'étude : Chloé Vinet (PatriNat), Guillaume body (PatriNat)

Chef de l'équipe en charge du programme : Thomas Bouix

Contributeurs et expert(s) mobilisé(s) : Benoît Fontaine (CESCO), Yves Bas (CESCO), Tiphaine Devaux (CESCO), Aurélie Lacoeuilhe (PatriNat), Eddy Cosson (OFB), Juliette Damiano (PatriNat)

Relecteurs : Guillaume Body (PatriNat)

Référence du rapport conseillée : Vinet C., Body G., 2024. Test du Darwin Core et du standard d'échange pour l'observation et le suivi de taxons du SINP aux données de surveillance de la biodiversité. PatriNat (OFB-MNHN-CNRS-IRD).
## PatriNat

### Centre d'expertise et de données sur le patrimoine naturel

Dans une unité scientifique associant des ingénieurs, des experts et des spécialistes de la donnée, PatriNat rapproche les compétences et les moyens de ses quatre tutelles que sont l'OFB, le MNHN, le CNRS et l'IRD.

PatriNat coordonne des programmes nationaux d'acquisition de connaissance pour cartographier les écosystèmes, les espèces et les aires protégées, surveiller les tendances de la biodiversité terrestre et marine, répertorier les zones clefs pour la conservation de la nature (Znieff), et produire des référentiels scientifiques et techniques (TaxRef, HabRef, etc.). Ces programmes associent de nombreux partenaires et fédèrent les citoyens à travers des observatoires de sciences participatives (tels que Vigie-Nature, INPN espèces ou Vigie-terre).

PatriNat développe des systèmes d'information permettant de standardiser, partager, découvrir, synthétiser et archiver les données aussi bien pour les politiques publiques (SIB, SINP) que pour la recherche (PNDB) en assurant le lien avec les systèmes internationaux (GBIF, CDDA, etc.).

PatriNat apporte son expertise dans l'interprétation des données pour accompagner les acteurs et aider les décideurs à orienter leurs politiques : production d'indicateurs, notamment pour l'Observatoire national de la biodiversité (ONB) et des livrets de chiffres clés, élaboration des Listes rouges des espèces et écosystèmes menacés, revues systématiques, préparation des rapportages pour les directives européennes, élaboration d'outils de diagnostic de la biodiversité pour les acteurs des territoires, ou encore évaluation de l'efficacité des mesures de restauration. PatriNat organise également l'autorité scientifique CITES pour la France.

L'ensemble des informations (de la donnée brute à la donnée de synthèse) est rendu publique dans les portails NatureFrance, INPN et Compteur BIOM.

En savoir plus : www.patrinat.fr

Direction : Laurent PONCET et Julien TOUROULT

## Biodiversa+

### Le partenariat européen pour la biodiversité

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

biodiversa+
European Biodiversity Partnership

Biodiversa+ est le partenariat européen cofinancé pour la biodiversité, soutenant la recherche d'excellence sur la biodiversité avec un impact sur les politiques et la société. Développé conjointement par BiodivERsA et la Commission européenne (DG Recherche & Innovation et DG Environnement), il a été lancé le 1er octobre 2021. Biodiversa+ fait partie de la Stratégie européenne pour la biodiversité à l'horizon 2030, qui vise à remettre la biodiversité européenne sur la voie de la récupération d'ici 2030. Le partenariat vise à connecter la science, la politique et la pratique pour un changement transformateur. Il réunit actuellement 80 programmes de recherche et bailleurs de fonds ainsi que des acteurs de la politique environnementale de 40 pays européens et associés, travaillant sur 5 objectifs principaux :

1. Planifier et soutenir la recherche et l'innovation sur la biodiversité grâce à une stratégie commune, des appels annuels conjoints pour des projets de recherche et des activités de renforcement des capacités.

2. Mettre en place un réseau de schémas harmonisés pour améliorer la surveillance de la biodiversité et des services écosystémiques à travers l'Europe.

3. Contribuer à des connaissances de haut niveau pour le déploiement de solutions fondées sur la nature et l'évaluation de la biodiversité dans le secteur privé.

4. Assurer un soutien basé sur la science pour l'élaboration des politiques et leur mise en œuvre en Europe.

5. Renforcer la pertinence et l'impact de la recherche panéuropéenne sur la biodiversité dans un contexte mondial.

En savoir plus : https://www.biodiversa.eu/
Table des matières

<table><tr><td>1.</td><td>Introduction</td><td>10</td></tr><tr><td>1.1.</td><td>La surveillance de la biodiversité</td><td>10</td></tr><tr><td>1.2.</td><td>La standardisation et les standards d'échange de données</td><td>10</td></tr><tr><td>1.2.1.</td><td>Le standard Darwin Core</td><td>11</td></tr><tr><td>1.2.2.</td><td>Le standard Observations et suivis de taxons V3.0</td><td>12</td></tr><tr><td>1.3.</td><td>Objectif du rapport</td><td>13</td></tr><tr><td>1.4.</td><td>Guide de lecture</td><td>13</td></tr><tr><td>1.4.1.</td><td>Informations générales sur la standardisation</td><td>16</td></tr><tr><td>1.4.2.</td><td>Bonnes pratiques de standardisation</td><td>16</td></tr><tr><td>2.</td><td>Résultats des tests de standardisation</td><td>17</td></tr><tr><td>2.1.</td><td>Jeu de données n°1 : ADNe (metabarcoding)</td><td>18</td></tr><tr><td>2.1.1.</td><td>Standardisation Darwin Core</td><td>18</td></tr><tr><td>2.1.2.</td><td>Standardisation avec SOT V3.0</td><td>20</td></tr><tr><td>2.2.</td><td>Jeu de données n°2 : LEDKOA (surveillance aérienne)</td><td>21</td></tr><tr><td>2.2.1.</td><td>Standardisation du jeu LEDKOA avec le Darwin Core</td><td>23</td></tr><tr><td>2.2.2.</td><td>Standardisation avec SOT V3.0 du jeu de données LEDKOA</td><td>24</td></tr><tr><td>2.3.</td><td>Jeu de données n°3 : ASPE (pêche électrique)</td><td>25</td></tr><tr><td>2.3.1.</td><td>Standardisation avec le Darwin Core du jeu de données ASPE</td><td>26</td></tr><tr><td>2.3.2.</td><td>Standardisation avec SOT V3.0 du jeu de données ASPE</td><td>27</td></tr><tr><td>2.4.</td><td>Jeu de données n°4 : STOC-EPS (points d'écoute)</td><td>28</td></tr><tr><td>2.4.1.</td><td>Standardisation avec le Darwin Core du jeu de données STOC-EPS</td><td>29</td></tr><tr><td>2.4.2.</td><td>Standardisation avec SOT V3.0 du jeu de données STOC-EPS</td><td>30</td></tr></table>
<table><tr><td>2.5.</td><td>Jeu de données n°5 : Vigie-Chiro (contacts acoustiques)</td><td>31</td></tr><tr><td>2.5.1.</td><td>Standardisation avec le Darwin Core du jeu de données Vigie-Chiro</td><td>32</td></tr><tr><td>2.5.2.</td><td>Standardisation avec SOT V3.0 du jeu de données Vigie-Chiro</td><td>33</td></tr><tr><td>3.</td><td>Conclusion</td><td>34</td></tr><tr><td>4.</td><td>Discussion</td><td>37</td></tr><tr><td>4.1.</td><td>Réflexions sur la standardisation des jeux de données issus de techniques ADNe</td><td>37</td></tr><tr><td>4.2.</td><td>Darwin Core ou SOT V3.0 ?</td><td>38</td></tr><tr><td>5.</td><td>Annexes</td><td>40</td></tr><tr><td>5.1.</td><td>Tables de standardisation du DwC pour le jeu de données ADNe</td><td>40</td></tr><tr><td>5.2.</td><td>Tables de standardisation du SOT V3.0 pour le jeu de données ADNe</td><td>41</td></tr><tr><td>5.3.</td><td>Tables de standardisation du DwC pour le jeu de données LEDKOA</td><td>43</td></tr><tr><td>5.4.</td><td>Tables de standardisation du SOT V3.0 pour le jeu de données LEDKOA</td><td>46</td></tr><tr><td>5.5.</td><td>Tables de standardisation du DwC pour le jeu de données ASPE</td><td>48</td></tr><tr><td>5.6.</td><td>Tables de standardisation du SOT V3.0 pour le jeu de données ASPE</td><td>51</td></tr><tr><td>5.7.</td><td>Tables de standardisation du DwC pour le jeu de données STOC-EPS</td><td>55</td></tr><tr><td>5.8.</td><td>Tables de standardisation du SOT V3.0 pour le jeu de données STOC-EPS</td><td>56</td></tr><tr><td>5.9.</td><td>Tables de standardisation du DwC pour le jeu de données Vigie-Chiro</td><td>57</td></tr><tr><td>5.10.</td><td>Tables de standardisation du SOT V3.0 pour le jeu de données Vigie-Chiro</td><td>59</td></tr></table>
## Table des figures

<table><tr><td>Figure 1 : Schéma de l'organisation "en étoile" des classes du standard Darwin Core</td><td>11</td></tr><tr><td>Figure 2 : Schéma général du standard SOT V3.0. Présentation des concepts et des liens entre eux.</td><td>12</td></tr><tr><td>Figure 3 : Modèle conceptuel générique de l'organisation d'un jeu de données de biodiversité avec le DwC</td><td>14</td></tr><tr><td>Figure 4 : Modèle conceptuel générique de l'organisation d'un jeu de données de biodiversité par le SOT V3.0</td><td>15</td></tr><tr><td>Figure 5 : Schéma de l'organisation générale des données. Pour chaque échantillon, l'abondance relative des 44 espèces de bivalves est recherchée (nombre 44 accolé à la flèche).</td><td>18</td></tr><tr><td>Figure 6 : modèle conceptuel de la standardisation de l'organisation des données par le standard Darwin Core</td><td>19</td></tr><tr><td>Figure 7 : modèle conceptuel de la standardisation de l'organisation des données par le standard SOT V3.0</td><td>20</td></tr><tr><td>Figure 8 : Schématisation de l'organisation des éléments du jeu de données LEDKOA.</td><td>22</td></tr><tr><td>Figure 9 : Modèle conceptuel du jeu de données LEDKOA avec le DwC</td><td>23</td></tr><tr><td>Figure 10 : Modèle conceptuel du jeu de données LEDKOA avec le SOT V3.0</td><td>24</td></tr><tr><td>Figure 11 : Schématisation de l'organisation des éléments du jeu de données ASPE.</td><td>25</td></tr><tr><td>Figure 12 : Modèle conceptuel du jeu de données ASPE avec le DwC</td><td>26</td></tr><tr><td>Figure 13 : Modèle conceptuel du jeu de données ASPE avec le SOT V3.0</td><td>27</td></tr><tr><td>Figure 14 : Schématisation de l'organisation des éléments du jeu de données STOC-EPS.</td><td>29</td></tr><tr><td>Figure 15 : Modèle conceptuel du jeu de données STOC-EPS avec le DwC</td><td>29</td></tr><tr><td>Figure 16 : Modèle conceptuel du jeu de données STOC-EPS avec le SOT V3.0</td><td>30</td></tr><tr><td>Figure 17 : Schématisation de l'organisation des éléments du jeu de données protocole point fixe Vigie-Chiro</td><td>32</td></tr><tr><td>Figure 18 : Modèle conceptuel du jeu de données protocole point fixe Vigie-Chiro avec le DwC</td><td>32</td></tr><tr><td>Figure 19 : Modèle conceptuel du jeu de données protocole point fixe Vigie-Chiro avec le SOT V3.0</td><td>33</td></tr><tr><td>Figure 20 : Modèle conceptuel des standards Darwin Core et SOT V3.0</td><td>34</td></tr><tr><td>Figure 21 : Étapes intermédiaires de schématisation de l'organisation des données du jeu de données ADNe</td><td>40</td></tr><tr><td>Figure 22 : Étape intermédiaire de schématisation des éléments du jeu de données ADNe.</td><td>41</td></tr><tr><td>Figure 23 : Étape intermédiaire de schématisation de l'organisation des éléments du jeu de données ASPE.</td><td>49</td></tr><tr><td>Figure 24 : Modèle conceptuel de la standardisation du jeu de données ASPE avec le standard OccTax V2.</td><td>51</td></tr><tr><td>Figure 25 : Étape intermédiaire dans la construction du modèle conceptuel du jeu de données ASPE avec le SOT V3.0</td><td>52</td></tr></table>

## Table des tableaux

<table><tr><td>Tableau 1 : Tables de standardisation génériques des classes, extensions et termes du standard DwC</td><td>14</td></tr><tr><td>Tableau 2 : Tables de standardisation génériques des concepts et attributs du SOT V3.0</td><td>15</td></tr><tr><td>Tableau 3 : Extrait du jeu de données étudié, issu de l'extraction de la base de données du producteur. Il comprend un échantillon de deux lignes, toutes les espèces (seules quelques-unes sont visibles sur cette figure) et toutes les informations hors espèce.</td><td>18</td></tr><tr><td>Tableau 4 : Extrait du jeu de données LEDKOA</td><td>21</td></tr><tr><td>Tableau 5 : Extrait du jeu de données ASPE</td><td>25</td></tr><tr><td>Tableau 6 : Extrait du jeu de données STOC-EPS</td><td>28</td></tr><tr><td>Tableau 7 : Extrait du jeu de données protocole point fixe Vigie-Chiro</td><td>31</td></tr><tr><td>Tableau 8 : Table de standardisation de la classe Event du DwC pour le jeu de données ADNe</td><td>40</td></tr><tr><td>Tableau 9 : Table de standardisation de l'extension MoF du DwC pour le jeu de données ADNe</td><td>40</td></tr><tr><td>Tableau 10 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données ADNe</td><td>41</td></tr><tr><td>Tableau 11 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données ADNe</td><td>42</td></tr><tr><td>Tableau 12 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données ADNe</td><td>42</td></tr><tr><td>Tableau 13 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données ADNe</td><td>42</td></tr><tr><td>Tableau 14 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données ADNe</td><td>43</td></tr><tr><td>Tableau 15 : Table de standardisation des concepts facultatifs DescriptifSujet et Determination du SOT V3.0 pour le jeu de données ADNe</td><td>43</td></tr><tr><td>Tableau 16 : Table de standardisation de la classe Event du DwC pour le jeu de données LEDKOA</td><td>44</td></tr><tr><td>Tableau 17 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données LEDKOA</td><td>44</td></tr></table>
<table>
  <tr>
    <td>Tableau 18 : Table de standardisation de l'extensions MoF du DwC pour le jeu de données LEDKOA</td>
    <td>45</td>
  </tr>
  <tr>
    <td>Tableau 19 : Tableau des codes des objets observés utilisé dans le programme LEDKOA</td>
    <td>46</td>
  </tr>
  <tr>
    <td>Tableau 20 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données LEDKOA</td>
    <td>46</td>
  </tr>
  <tr>
    <td>Tableau 21 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données LEDKOA</td>
    <td>47</td>
  </tr>
  <tr>
    <td>Tableau 22 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données LEDKOA</td>
    <td>47</td>
  </tr>
  <tr>
    <td>Tableau 23 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données LEDKOA</td>
    <td>48</td>
  </tr>
  <tr>
    <td>Tableau 24 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données LEDKOA</td>
    <td>48</td>
  </tr>
  <tr>
    <td>Tableau 25 : Table de standardisation de la classe Event du DwC pour le jeu de données ASPE</td>
    <td>49</td>
  </tr>
  <tr>
    <td>Tableau 26 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données ASPE</td>
    <td>50</td>
  </tr>
  <tr>
    <td>Tableau 27 : Table de standardisation de l'extension MoF du DwC pour le jeu de données ASPE</td>
    <td>50</td>
  </tr>
  <tr>
    <td>Tableau 28 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données ASPE</td>
    <td>52</td>
  </tr>
  <tr>
    <td>Tableau 29 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données ASPE</td>
    <td>52</td>
  </tr>
  <tr>
    <td>Tableau 30 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données ASPE</td>
    <td>53</td>
  </tr>
  <tr>
    <td>Tableau 31 : Table de standardisation du concept Interaction du SOT V3.0 pour le jeu de données ASPE</td>
    <td>53</td>
  </tr>
  <tr>
    <td>Tableau 32 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données ASPE</td>
    <td>54</td>
  </tr>
  <tr>
    <td>Tableau 33 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données ASPE</td>
    <td>54</td>
  </tr>
  <tr>
    <td>Tableau 34 : Table de standardisation de la classe Event du DwC pour le jeu de données STOC-EPS</td>
    <td>55</td>
  </tr>
  <tr>
    <td>Tableau 35 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données STOC-EPS</td>
    <td>55</td>
  </tr>
  <tr>
    <td>Tableau 36 : Table de standardisation de l'extension MoF du DwC pour le jeu de données STOC-EPS</td>
    <td>56</td>
  </tr>
  <tr>
    <td>Tableau 37 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données STOC-EPS</td>
    <td>56</td>
  </tr>
  <tr>
    <td>Tableau 38 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données STOC-EPS</td>
    <td>56</td>
  </tr>
  <tr>
    <td>Tableau 39 : Table de standardisation du concept LienHabitats du SOT V3.0 pour le jeu de données STOC-EPS</td>
    <td>57</td>
  </tr>
  <tr>
    <td>Tableau 40 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données STOC-EPS</td>
    <td>57</td>
  </tr>
  <tr>
    <td>Tableau 41 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données STOC-EPS</td>
    <td>57</td>
  </tr>
  <tr>
    <td>Tableau 42 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données STOC-EPS</td>
    <td>57</td>
  </tr>
  <tr>
    <td>Tableau 43 : Table de standardisation de la classe Event du DwC pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>58</td>
  </tr>
  <tr>
    <td>Tableau 44 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>58</td>
  </tr>
  <tr>
    <td>Tableau 45 : Table de standardisation de l'extension MoF du DwC pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>59</td>
  </tr>
  <tr>
    <td>Tableau 46 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>60</td>
  </tr>
  <tr>
    <td>Tableau 47 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>60</td>
  </tr>
  <tr>
    <td>Tableau 48 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>60</td>
  </tr>
  <tr>
    <td>Tableau 49 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>60</td>
  </tr>
  <tr>
    <td>Tableau 50 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td>
    <td>61</td>
  </tr>
</table>
# 1. Introduction

## 1.1. La surveillance de la biodiversité

Le schéma directeur de la surveillance de la biodiversité terrestre<fnref n="1" /> définit la surveillance de la biodiversité comme « l'observation répétée de ces composantes sur le long terme, afin de percevoir des changements en qualité ou en quantité aux différents niveaux d'organisation (écosystèmes, habitats, espèces, gènes). N'ayant pas vocation à s'arrêter, elle repose sur l'acquisition périodique de données standardisées ou de mesures de variables à l'échelle d'un territoire. » Au niveau européen, Biodiversa+<fnref n="3" />[1] utilise une définition similaire basée sur trois caractéristiques de la surveillance : le suivi à long terme, l'évaluation de statut et de tendance, et l'aspect agnostique au niveau d'organisation biologique, au domaine (terrestre, marin, eau douce) et à l'échelle géographique.

Au niveau européen, Biodiversa+<fnref n="4" /> défini un protocole de surveillance comme un jeu structuré de procédures, méthodes et de lignes directrices développés pour collecter des informations sur la biodiversité.

## 1.2. La standardisation et les standards d'échange de données

Une multitude de données sur la biodiversité (observations et suivis d'espèces, d'habitats et d'écosystèmes) est produite chaque année par différents acteurs, du niveau le plus local au plus international et dans le cadre de programmes répondants à des politiques publiques ou de recherche. Ces données sont collectées selon des protocoles différents et à des fins variées ce qui limite leur harmonisation et interoperabilité. Parmi ces limitations on trouve :

- Le type des données, qui est très divers : cartes de distribution, observations d'espèces, tendances d'abondance d'espèces, comportement d'un individu, cartes d'habitats, analyses génétiques ou encore enregistrements sonores.

- La source des données : il y a les données dites « brutes » ou « primaires » issues directement de la collecte de données sur le terrain ou au laboratoire et les données dites « de synthèse », « élaborée » ou « secondaire » qui sont le résultat de données brutes ayant déjà été utilisées pour des analyses et des modélisations ou des données moissonnées de la littérature.

- Le format des données est aussi très varié, que ce soit le format des valeurs de champ de données (généralement colonne d'un tableau) ou le type de fichier sous lequel sont encodées les données.

De ce fait il est nécessaire de disposer d'un « langage commun » afin de rendre interoperables les systèmes de gestion de données de biodiversité, d'assurer la qualité des informations bancarisées et diffusées, d'en faciliter l'interprétation et in fine leur exploitation. C'est ce langage commun qui est appelé « standard d'échange » de données ou de métadonnées. La complétude et la qualité des données et des métadonnées régies par le standard d'échange permet de valoriser au mieux l'information qu'elles véhiculent : le processus de standardisation ne doit

<footnote n="1">¹ Ministère de la Transition écologique. Décision du 9 janvier 2024 portant approbation du schéma directeur de la surveillance de la biodiversité terrestre 2024-2025. Bulletin Officiel, 23 janvier 2024.</footnote>

<footnote n="3">3 Basille Mathieu, Body Guillaume, Brotons Lluís, Gaigr Jonas, Onen Tarantini Senem, Pulieri Martina, Rodić Petra, Silva del Pozo Michelle, Winfler Ron, et al.. (2024). Concept note on a methodological approach to define priorities for monitoring biodiversity. Biodiversa+ report. 32 pp. https://doi.org/10.5281/zenodo.13934670</footnote>

<footnote n="4">⁴ Silva del Pozo Michelle, Body Guillaume, Rerig Gaby, Basille Mathieu. (2023). Guide on harmonising biodiversity monitoring protocolsacrossscales. Biodiversa+ report. 60 pp.</footnote>
ni trier ni altérer cette information. La standardisation des jeux de données ne garantit pas leur interoperabilité et harmonisation scientifique, elle ne s'intéresse qu'à leur interoperabilité et harmonisation technique, facilitant ainsi l'échange des données issues d'origines diverses. Cependant, comme dans de nombreux autres domaines de recherche, « une norme unique ne convient pas à tous ». Chaque communauté en écologie collecte et stocke des données sous des formes et combinaisons qui répondent le mieux à leurs besoins, c'est pourquoi de nombreux standards communautaires pour les données sur la biodiversité existent (Darwin Core, ABCD, ect.).

Dans ce rapport, nous avons effectué un exercice de standardisation des données issus de différents dispositifs de surveillance. Nous avons testé pour cela deux standards important : le standard de données international Darwin Core<fnref n="5" /> et le standard d'échange de données national français Observations et Suivis de Taxons V3.0⁶ ont été testés.

### 1.2.1. Le standard Darwin Core

Le Darwin Core (abrégé DwC dans la suite du rapport) est un standard international pour le partage de données sur la biodiversité initialement développé en 1999 et formalisée par le Darwin Core Task Group en 2009 (aujourd'hui Darwin Core maintenance group).

Il propose une liste de termes (équivalent des attributs) aux définitions fixes et regroupés en classes (équivalent des concepts) nommées selon des éléments d'étude de la biodiversité (Event, Occurrence, Location, etc.). Ce standard est orienté sur les informations sur les taxons, leur observation, les spécimens, les échantillons et de nombreuses informations connexes (Organism, Taxon, Identification, MeasurementOrFact, etc.). L'utilisation du standard se veut la plus simple possible, les termes restreints par un vocabulaire contrôlé ou une obligation de renseignement sont rares, le reste étant laissé en texte libre. Dans sa forme la plus simple, le DwC consiste en un format de données plat (fichier CSV), composé d'une table de données (Simple Darwin Core). L'organisation de ces éléments peut être représentée sous forme d'étoile (figure 1).

Des types d'enregistrement tels que les données d'herbier ont été décrits par le DwC depuis son lancement et il connait une utilisation croissante depuis, en particulier pour les données protocolées (EU BON), les observations en milieu marin (OBIS) et les observations mondiales de la biodiversité (GBIF). Cependant, la simplicité du standard peut présenter des limites pour standardiser certains types de données. Ainsi, la communauté de développement de standards sur les données de biodiversité, dont le Darwin Core, (Biodiversity Information Standards -TDWG-) propose régulièrement des mises à jour du standard ainsi que des extensions complètes - propre à un type de données de biodiversité comme les données dérivées d'ADN, les données issues de collections, les médias associés aux données (enregistrements sons, images), les données géologiques pour la paléontologie ou encore les données des pièges photographiques -, ouvrant ainsi la bancarisation à de nouveaux types de données de surveillance. Il est aujourd'hui le standard le plus couramment utilisé pour le partage des données de biodiversité au niveau international.

<figure><img src="image_9.png" /><figcaption>Figure 1 : Schéma de l'organisation "en étoile" des classes du standard Darwin Core</figcaption></figure>

<footnote n="5">⁵ https://dwc.tdwg.org/terms/ consulté en février 2024</footnote>

<footnote n="6">⁶ https://inpn.mnhn.fr/docs-web/docs/download/421824</footnote>
Parmi les extensions du Darwin Core, la Humboldt Extension for Ecological Inventories (eco) a été développée pour mieux standardiser les informations issues de processus d'inventaire. Bien qu'elle entre dans le cadre des jeux de données étudiés dans ce rapport, cette extension n'a pas été testée. À la fois par manque de temps pour bien maîtriser tout son contenu et à la fois à cause des lacunes d'informations, demandées par l'extension, des jeux de données considérés - ces informations n'étant pas renseignées ou déjà standardisées par d'autres termes. Il n'en reste pas moins très intéressant de donner suite à cet exercice en testant plus spécifiquement cette extension.

### 1.2.2. Le standard Observations et suivis de taxons V3.0

Le standard Observations et de Suivis de Taxons version 3.0 (abrégé SOT V3.0 dans la suite du rapport) est le standard d'échange de données utilisé par le système d'information sur l'inventaire du patrimoine naturel (SINP), base de données nationale sur le patrimoine naturel français.

Le standard un outil indispensable pour normer la circulation des données de biodiversité et ainsi faciliter leur échange au sein du réseau. Il permet de standardiser les données d'observations et de suivis de taxons en proposant des concepts correspondants aux informations collectées lors d'études écologiques - comme le sujet de l'observation (le plus communément, un taxon) et l'évènement d'observation (le relevé). L'organisation de tous ces éléments est schématisée telle que présentée en figure 2.

Riche d'un vocabulaire contrôlé étoffé utilisant des nomenclatures et référentiels nationaux officiels, il permet de standardiser avec grande complétude et qualité une diversité importante de type de données : données d'observations opportunistes, données protocolées, données d'observations de taxons en lien avec les habitats, phytosociologie, interaction entre sujets d'observations et autres mesures descriptives ainsi que des concepts pour la validation scientifique de la donnée et l'enregistrement de ses modifications. À l'utilisation, le standard se présente sous la forme de gabarits de saisie (fichiers type CSV) nommés selon les concepts et préremplis avec les attributs du standard. Il est également intégré directement à plusieurs bases de gestion de données des acteurs du réseau ainsi qu'à des applications de saisie WEB ou mobile comme GeoNature. Aussi, un flux de données entre le SINP et le GBIF existe à la fois pour la remontée des données au niveau international (utilisation du format Darwin Core) et pour la redecente au niveau national de toutes les

<figure><img src="image_10.png" /><figcaption>Figure 2 : Schéma général du standard SOT V3.0. Présentation des concepts et des liens entre eux.</figcaption></figure>
données du GBIF collectées sur le territoire français (utilisation du format SOT V3.0).

## 1.3. Objectif du rapport

L'objectif de ce rapport est de rendre compte des résultats de l'exercice d'applicabilité des standards DwC et SOT V3.0 aux données issues de la surveillance de la biodiversité française. Ce rapport partage des recommandations et des bonnes pratiques de standardisation ainsi qu'une réflexion sur la co-existence du DwC et du SOT V3.0 en conclusion.

> Les métadonnées ne sont pas concernées par le périmètre de l'exercice par manque de temps dédié. Néanmoins elles constituent une information indispensable pour décrire le contexte de collecte des données et ainsi faciliter leur interprétation et exploitation. Elles doivent toujours faire l'objet d'une standardisation et d'une bancarisation en amont des données du jeu de données. On distingue de plus en plus les métadonnées de jeu de données, spécifique à celui-ci, des métadonnées de programme/cadre d'acquisition qui sont génériques à plusieurs jeux de données<fnref n="7" />.

Dans le corps du rapport sont présentés les modèles conceptuels de standardisation de chaque jeu de données pour chaque standard accompagné d'un résumé (forces et faiblesses) de chaque standardisation. Les étapes de standardisation réelle (tables de standardisation) pour chaque jeu de données et pour chaque standard sont disponibles en annexe du document.

## 1.4. Guide de lecture

Dans la suite du rapport les résultats de standardisation sont présentés sous forme de modèle conceptuel inspiré librement de celui proposé par De Pooter et al. (2017)<fnref n="8" /> et appliqué dans les rapports d'Enetwild<fnref n="9" />,<fnref n="10" />. Le code couleur appliqué aux classes du DwC utilisé dans les rapports d'Enetwild<fnref n="9" />,<fnref n="10" /> E et al. (2022) est également repris, en le déclinant aux autres classes du standard utilisées ainsi qu'aux concepts du standard SOT V3.0 (figure 3). Cette méthode permet un aperçu facile à assimiler des informations constituant le jeu de données et des relations entre elles. La modélisation conceptuelle des données est une étape très importante à réaliser avant la standardisation réelle en tables (reprenant les concepts et attributs d'un standard).

<footnote n="7">⁷ Basset Alberto, Onen Tarantini Senem, Eggermont Hilde, Mandon Cécile, Vihervaara Petteri (2023) Report on the harmonisation and interoperability of datasets across regions and countries. Biodiversa+ report. 58pp.</footnote>

<footnote n="8">⁸ De Pooter Daphnis et al. (2017) Toward a new data standard for combined marine biological and environmental datasets – expanding OBIS beyond species occurences. Biodiversity Data Journal 5: e10989. https://doi.org/10.3897/BDJ.5.e10989</footnote>

<footnote n="9">⁹ Enetwild consortium, Body Guillaume, Mousset Mathilde, Chevallier Emmanuelle, Scandura Massimo, Pamerlon Sophie, Blanco-Aguiar Jose Antonio, Vicente Joaquin (2020) Applying the Darwin core standard to the monitoring of wildlife species, their management and estimated records. EFSA supporting publication 2020: 2N-1841. 81 pp. doi:10.2903/sp.efsa.2020.EN 1841</footnote>

<footnote n="10">¹⁰ Enetwild consortium, Jaroszynska Francesca, Body Guillaume, Pamerlon Sophie, Archambeau Anne-Sophie (2022) Applying the Darwin core data standard to wildlife disease – advancements toward a new data model. EFSA supporting publication 2022: EN-7667. 68 pp. doi:10.2903/sp.efsa.2022.EN-7667</footnote>
<figure><img src="image_11.png" /><figcaption>Figure 3 : Modèle conceptuel générique de l'organisation d'un jeu de données de biodiversité avec le DwC</figcaption></figure>

Le code couleur utilisé pour identifier les éléments du modèle est le suivant :

- orange clair pour la classe Event ;

- vert pour la classe Occurrence (qui sera utilisée dans cet exercice comme un extension à la classe Event) ;

- bleu pour l'extension MeasurementOrFact (MoF) ;

- gris pour les autres extensions du DwC (par exemple DNA derived data).

La classe Event est utilisée dans cet exercice comme l'élément central auquel sont attachées des extensions (Occurrence, MoF, autres). Ces extensions peuvent également être liées entre elles. Ces liens sont représentés dans le modèle par les termes « ...ID ». La classe Event est récursive et les extensions Occurrence et MoF sont proposées¹⁰,¹¹ pour être récursives c'est-à-dire que plusieurs instances de la classe peuvent être liées entre elles dans une relation parent-enfant. Cela est notamment possible par les termes « parent....ID ». Nous verrons que cette fonctionnalité est très utile pour standardiser les jeux de données de surveillance de la biodiversité. L'organisation des éléments du modèle conceptuel pour le DwC suivra toujours la chaîne Event à gauche et Occurrence à droite avec l'extension MoF en bas.

La version de l'extension MeasurementOrFact utilisée dans cet exercice est celle actuellement publiée par le TDWG. Elle comprend les ajouts des termes proposés par De Pooter et al (2017) – version extendedMeasurementOrFact - et par ENETWILD Consortium et al. (2020) – version nestedExtendedMeasurementOrFact. Nous verrons dans cet exercice des exemples de l'utilité de ces ajouts.

Dans cet exercice est utilisée la version de l'extension Occurrence proposée par ENETWILD Consortium et al. (2022) qui consiste en l'ajout du terme parentOccurrenceID. Bien que cet ajout n'ait pas encore été officiellement accepté par le TDWG nous verrons dans cet exercice un exemple de son utilité.

<table><caption>Tableau 1 : Tables de standardisation génériques des classes, extensions et termes du standard DwC</caption><thead><tr><th>eventID</th><th>parentEventID</th><th>term3</th><th>occurrenceID</th><th>eventID</th><th>parentOccurrenceID</th></tr></thead><tbody><tr><td>value</td><td>value</td><td>value</td><td>value</td><td>value</td><td></td></tr><tr><th>measurementID</th><th>eventID</th><th>occurrenceID</th><th>parentMeasurementID</th><th>term5</th><th></th></tr><tr><td>value</td><td></td><td>value</td><td>value</td><td>value</td><td></td></tr></tbody></table><table><thead><tr><th>eventID</th><th>occurrenceID</th><th>term3</th></tr></thead><tbody><tr><td>value</td><td>value</td><td>value</td></tr></tbody></table>

Le tableau 1 présente les tables de standardisation génériques qui sont été utilisées pour cet exercice et qui sont intégrées au rapport en annexes. Les tables sont colorées suivant le même code que celui appliqué pour le modèle conceptuel. Ainsi, la table orange correspond à la classe Event, en vert à l'extension Occurrence, en bleu à l'extension MoF et en gris toutes les tables correspondant à d'autres extensions du standard. Pour chaque table
les identifiant uniques à reporter sont précisés. Le premier terme (« term » en anglais et dans la figure - équivalent à l'attribut pour le SOT V3.0 -) de chaque table correspond à son identifiant unique propre (eventID, occurrenceID, etc.). Les termes suivants correspondent aux identifiant des classes et extensions avec lesquelles les enregistrements de la table considérée peuvent être en lien (clés étrangères) ou les liens de récursivité (parent...ID). Une fois ces termes renseignés la table est complétée par tous les autres termes de la classe ou de l'extension en question. Une cellule grisée (voir table bleue) indique qu'aucune information (de l'enregistrement considéré) pour ce terme n'est disponible dans le jeu de données.

<figure><img src="image_12.png" /><figcaption>Figure 4 : Modèle conceptuel générique de l'organisation d'un jeu de données de biodiversité par le SOT V3.0</figcaption></figure>

Le même type de modèle conceptuel est utilisé pour représenter l'organisation d'un jeu de données avec le SOT V3.0 (figure 4). Le code couleur utilisé pour le DwC est appliqué aux éléments équivalents du SOT V3.0 :

- en orange le concept Evenement (équivalent Event)

- en vert le concept SujetObservation (équivalent Occurrence)

- en bleu le concept AttributAdditionnel (plus ou moins équivalent MoF)

- en gris les autres concepts facultatifs du standard (équivalent des autres extensions du DwC)

- en orange foncé (encadré couleur brique) le concept RegroupementEvenements (équivalent de la récursivité de la classe Event)

Le concept RegroupementEvenements possède la fonctionnalité de récursivité via l'attribut idRegroupementParent. Les concepts du SOT V3.0 sont liés entre eux par les attributs « idSinp... ». Les règles du standard obligeant à respecter la chaîne RegroupementEvenements>Evenement>SujetObservation seul le lien RegroupementEvenements-SujetObservation n'est pas possible (à l'exception de quelques autres concepts optionnels du standard). L'organisation des éléments du modèle conceptuel suivra toujours cette chaîne : RegroupementEvenements à gauche du modèle, SujetObservation à droite et AttributAdditionnel en bas - exceptés certains concepts facultatifs qui sont le plus souvent tout à droite du modèle.

<table><caption>Tableau 2 : Tables de standardisation génériques des concepts et attributs du SOT V3.0</caption><thead><tr><th>idSinpRegroupement</th><th>idSinpRegroupementParent</th><th>idRegroupementParent</th><th>Autre attribut du concept</th></tr></thead><tbody><tr><td>valeur</td><td>valeur</td><td>valeur</td><td>valeur</td></tr></tbody><thead><tr><th>idSinpEvenement</th><th>idSinpJdd</th><th>idSinpRegroupement</th><th>Autre attribut du concept</th></tr></thead><tbody><tr><td>valeur</td><td></td><td>valeur</td><td>valeur</td></tr></tbody><thead><tr><th>idSinpEvenement</th><th>idSinpSujetObs</th><th>idSinpRegroupement</th><th>Autre attribut du concept</th></tr></thead><tbody><tr><td>valeur</td><td>valeur</td><td>valeur</td><td>valeur</td></tr></tbody></table><table><thead><tr><th>idSinpSujetObs</th><th>idSinpEvenement</th><th>Autre attribut du concept</th></tr></thead><tbody><tr><td>valeur</td><td>valeur</td><td>valeur</td></tr></tbody></table><table><thead><tr><th>idSinpEvenement</th><th>idSinpSujetObs</th><th>idSinpRegroupement</th><th>Autre attribut du concept</th></tr></thead><tbody><tr><td>valeur</td><td>valeur</td><td>valeur</td><td>valeur</td></tr></tbody></table>

Les tables de standardisation du SOT V3.0 sont construites de la même manière que celles pour le DwC (tableau 2). Les identifiants uniques qui servent de clés primaires et étrangères entre les concepts sont toujours renseignés
dans les premières colonnes de chaque table (attributs idSinp...). De plus, pour la table RegroupementEvenements (couleur brique) l'attribut idRegroupementParent permettant la récursivité du concept est également renseigné le cas échéant.

Un attribut bloquant - c'est-à-dire que son renseignement est obligatoire selon les règles du standard mais pour lequel aucune valeur n'est disponible dans le jeu de données - est mis en évidence en rouge.

L'attribut idSinpJdd (concept Evenement) sera toujours mis en évidence en rouge lors de la standardisation avec le standard SOT V3.0. En effet, cette information requiert d'avoir préalablement standardiser les métadonnées du jeu de données. La standardisation des métadonnées n'ayant pas été faite pour cet exercice cette information n'est connue pour aucun jeu de données.

### 1.4.1. Informations générales sur la standardisation

Les cardinalités (dans le cas d'un lien entre deux concepts -flèche- = nombre de fois qu'une instance d'un concept ou d'une classe peut être utilisée) ne sont pas représentées dans les modèles conceptuels de l'exercice. En effet, cet exercice n'a pas pour but de réaliser la standardisation réelle de tous les enregistrements du jeu de données mais de présenter les possibilités de standardisation. Pour cela, un seul enregistrement de chaque jeu de données est standardisé - il n'est donc pas nécessaire de représenter les cardinalités (car toutes uniques, sauf exceptions). À savoir que la standardisation réalisée pour un enregistrement est applicable à tous les enregistrements du jeu de données.

Lors d'un exercice de standardisation plusieurs configurations (organisation des éléments) du modèle conceptuel sont envisagées en fonction du suivi étudié et de la compréhension qu'en a l'utilisateur :

- la configuration opérationnelle (operational scope) permet de représenter les données selon les étapes opérationnelles de la collecte. Exemple : un protocole de suivi d'un site sur lequel on effectue différentes opérations, des mesures de paramètres, des dénombrements d'organismes ;

- La configuration temporelle (temporal scope) permet de représenter les données selon les étapes temporelles de la collecte. Exemple : un programme pluriannuel ayant plusieurs sessions d'observation par an et chaque session se déroulant sur plusieurs jours pendant lesquelles sont enregistrés des observations ;

- La configuration spatiale (spatial scope) permet de représenter les données selon les étapes spatiales de la collecte. Exemple : un suivi d'une zone dans laquelle on parcours des transects dans lesquels plusieurs points peuvent être prospectés.

Une seule de ces configurations pour chaque jeu de données est présentée dans ce rapport, celle qui semble la plus appropriée pour représenter l'organisation des données du jeu étudié. Cependant toutes les configurations peuvent être valables et il est toujours utile de discuter avec le producteur de la donnée pour s'assurer que le choix réponde au mieux à ses besoins et à l'interprétation finale du jeu de données en vue de son exploitation.

Cette modélisation conceptuelle intervient en amont de la standardisation réelle en tables de gestion (voir figures 4 et 6). Ces tables, liées entre elles par les identifiants uniques (clé primaire et clé étrangère), sont le format de standardisation usuel pour la bancarisation des données en base de gestion. Dans ce rapport, les tables de gestion complètes sont présentées en annexes.

### 1.4.2. Bonnes pratiques de standardisation

La réalisation de l'exercice de standardisation s'est appuyé sur un ensemble de bonnes pratiques:

- construire un **modèle conceptuel du jeu de données** aide à la compréhension du processus de collecte et facilite la standardisation des données ;

- **traduire** en anglais le libellé des champs du jeu de données et leur valeur (les libellé pour les valeurs qualitatives et les unité pour les valeurs quantitatives) pour la standardisation avec le Darwin Core ;
- respecter la règle d'écriture **-minuscule au début puis majuscule au début de chaque mot-** pour les libellés et valeurs des termes du DwC et attributs de SOT V3.0 (exemple : *libelleAttributOuFait*) lors de leur standardisation avec l'extension MoF et le concept *AttributAdditionnel*;

- utiliser le terme **eventType** (classe Event du DwC) pour spécifier le niveau de chaque évènement ;

- utiliser le terme **eventRemarks** (classe Event DwC) ou l'attribut « **commentaires** » (concept Evenement de SOT V3.0) si nécessaire pour apporter un complément d'information. Attention cependant à ne pas transformer ces champs en fourre-tout. Toute information dont la standardisation est possible par un terme ou attribut définis dans les standards mais renseignée en remarque ou commentaire la rend inexploitable ;

- utiliser l'**extension MeasurementOrFact** (MoF) pour standardiser toute information ne pouvant pas l'être par des termes existants du Darwin Core. En effet on préfèrera toujours utiliser la solution qui standardise au maximum l'information pour favoriser l'homogénéité de format des données. L'attribut **dynamicProperties**, son équivalent dans la classe Record, est à renseigner sous un format JSON (exemple : `{"heightInMeters":1.5}`) et permet uniquement de standardiser le type d'information, sa valeur et son attribut. En revanche, l'extension MoF est plus complète, elle permet de standardiser le type quantitatif ou qualitatif d'une mesure, sa valeur, son unité mais également par qui elle a été réalisé, la date de réalisation, la méthode appliquée, une remarque libre et la précision de la mesure. Chacun des termes de l'extension est régit par des règles d'écriture ou des recommandations, de ce fait il est préférable de standardiser toute information supplémentaire via cette extension.

Pour les termes du Darwin Core se terminant par « ID » comme eventID et occurrenceID et les attributs de SOT commençant par « idSinp » il est fortement recommandé d'utiliser des identifiants universels uniques (UUID). Cependant, pour la lisibilité de l'exercice les identifiants sont simplifiés pour refléter la hiérarchie des données.

## 2. Résultats des tests de standardisation

Pour cet exercice de standardisation cinq jeux de données issus de divers dispositifs de surveillance français répondant à des politiques publiques nationales ou européennes ou issus de projets de recherche ont été étudiés. Ces programmes ont été choisis car ils s'opèrent à différentes échelles, sur différents milieux et leurs données sont utilisées à des fins variées. Ils correspondent à :

- Un jeu de données extrait de la base de données Pelagis portant sur la surveillance annuelle des populations de mammifères marins sur le site d'implantation d'un projet d'éolienne en mer (LEDKOA).

- Un jeu de données extrait d'un projet de recherche d'inventaire annuel de toutes les espèces de bivalves d'eau douce du paléarctique occidental dans des cours d'eau de France hexagonale par analyse ADNe (metabarcoding).

- Un jeu de données extrait de la base de données du programme STOC portant sur la surveillance des oiseaux communs terrestres, regroupées au point.

- Un jeu de données extrait de la base de données du programme Vigie-Chiro portant sur la surveillance des chauves-souris.

- Un jeu de données extrait de la base de données ASPE correspondant à l'application du protocole de pêche électrique complète en rivière.

Chaque jeu de données a fait l'objet d'un test d'applicabilité du standard Darwin Core et du standard SOT V3.0. Dans les parties suivantes nous décrivons tout d'abord le jeu de données et son contexte, puis nous exposons les résultats de standardisation – illustrés de modèles conceptuels – avec le Darwin Core et enfin les résultats de standardisation avec SOT V3.0. La standardisation réelle des jeux de données (tables de standardisation) est incluse en annexe du document.
## 2.1. Jeu de données n°1 : ADNe (metabarcoding)

Le jeu de données étudié est issu d'un projet de recherche sur la surveillance annuelle de toutes les espèces de bivalves d'eau douce du paléarctique occidental (espèces rares, menacées et introduites) dans plusieurs cours d'eau en France hexagonale. Cette surveillance est réalisée avec une méthode d'analyse de l'ADN environnemental (ADNe), le metabarcoding. Les données à disposition sont considérées comme « brutes » bien qu'issues à la fois de données terrain (informations sur le site d'échantillonnage, etc.) et des analyses en laboratoire (abondance relative). Ces données sont exploitées pour l'estimation de la probabilité de détection des espèces, pour étudier la co-occurrence et la composition des communautés dans les cours d'eau ainsi qu'à la réalisation de cartes de distribution d'espèces.

<table><caption>Tableau 3 : Extrait du jeu de données étudié, issu de l'extraction de la base de données du producteur. Il comprend un échantillon de deux lignes, toutes les espèces (seules quelques-unes sont visibles sur cette figure) et toutes les informations hors espèce.</caption><thead><tr><th>Locality</th><th>Kit#</th><th>Replicate</th><th>ID</th><th>Principaux cc Etude</th><th>BV</th><th>Rivière</th><th>Commune</th><th>Date</th><th>Latitude</th><th>Longitude</th><th>Anodonta ani</th><th>Anodonta cyg</th><th>Anodonta exi</th><th>Corbicula sp.</th><th>Corbicula flum</th><th>Dreissena po</th><th>Dreissena ro</th><th>Euglesa case</th></tr></thead><tbody><tr><td>1</td><td>SPY1600673</td><td>R1</td><td>1</td><td>CNR</td><td>Vigilife Rhôni</td><td>Rhône</td><td>Rhône</td><td>Pont de Poug</td><td>06/04/2016</td><td>46.144235</td><td>5.963902</td><td></td><td></td><td></td><td></td><td></td><td>423107</td><td>46834</td><td>4241</td></tr><tr><td>1</td><td>SPY1600674</td><td>R2</td><td>1</td><td>CNR</td><td>Vigilife Rhôni</td><td>Rhône</td><td>Rhône</td><td>Pont de Poug</td><td>06/04/2016</td><td>46.144217</td><td>5.964059</td><td></td><td></td><td></td><td></td><td></td><td>239202</td><td>48716</td><td>4132</td></tr></tbody></table>

On comprend de l'analyse du jeu de données (tableau 3) qu'un ou deux échantillons d'eau ou sont prélevés (Replicate) pour chaque site (localité). La liste des 44 espèces de bivalves et leurs abondances relatives (nombre de lectures de machine, résultat d'analyses génétiques non reportées dans les données) est associée à chaque échantillon. Les informations supplémentaires sur l'étude sont disponible, comm les principaux contributeurs, le numéro de kit d'échantillonnage utilisé, les coordonnées du point de relevé de l'échantillon, la date du relevé et d'autres informations géographiques sur le site d'échantillonnage, le bassin versant, la rivière et la commune. Un enregistrement (ligne de données) est donc composé d'un site d'échantillonnage auquel est rattaché au minimum un échantillon auquel est rattachée l'abondance relative des 44 espèces. L'organisation des données peut être schématisée simplement tel que présenté en figure 5.

<figure><img src="image_13.png" /><figcaption>Figure 5: Schéma de l'organisation générale des données. Pour chaque échantillon, l'abondance relative des 44 espèces de bivalves est recherchée (nombre 44 accolé à la flèche).</figcaption></figure>

Dans les deux parties suivantes (une pour chaque standard) nous exposons la dernière étape de modélisation conceptuelle de l'organisation des données avant la standardisation en tables. Plus de détails sur les étapes menant à ce modèle, notamment les étapes intermédiaires de modélisation et leur standardisation en tables, sont rapportés dans l'annexe 5.1 pour le standard Darwin Core et l'annexe 5.2 pour le standard SOT V3.0. Seul le modèle conceptuel final est présenté dans le corps du rapport. Il permet une représentation schématique de l'organisation des éléments du jeu de données et de leur standardisation.

### 2.1.1. Standardisation Darwin Core

L'organisation et la standardisation des données (traduites en anglais) avec le standard Darwin Core peuvent être modélisées tel que présenté en figure 6.
<figure><img src="image_14.png" /><figcaption>Figure 6: modèle conceptuel de la standardisation de l'organisation des données par le standard Darwin Core</figcaption></figure>

La classe Event (évènement) permet de standardiser les informations de date, de localisation, de protocole et d'échantillon. Aussi, la récursivité de la classe Event (via le terme « parentEventID ») permet de lier deux évènements. Dans ce cas l'évènement « parent » est celui du site d'échantillonnage et l'évènement « fils » celui de l'échantillon (réplicat). On lie à l'Event core l'extension Occurrence (existence d'un organisme en un lieu et un temps donné) pour standardiser le nom scientifique, le règne, la quantité de lectures de machines et le statut de présence/absence de l'espèce. Pour ce jeu de données, 44 occurrences (une pour chaque espèce de bivalves recherchée) sont associées à un même évènement de réplicat (water sample replicate). En plus de ces informations, le GBIF, dans son guide « Publishing DNA-derived data through biodiversity data platforms »<fnref n="14" />, recommande d'enrichir les occurrences dérivées d'ADN en renseignant des termes issus de l'extension « DNA derived data » tels que target_gene (gène ciblé) et seq_meth (méthode de séquençage) ainsi que des termes issus de classes existantes dans le DwC (sampleSizeValue, sampleSizeUnit, materialSampleID). Ces informations ne sont pas renseignées dans le jeu de données mais sont décrites dans les publications scientifiques associées<fnref n="15" />. Il serait intéressant à l'avenir, puisqu'elles sont connues, de les renseigner directement dans le jeu de données (ainsi que plusieurs autres termes recommandés dans le guide GBIF) ou d'au moins renseigner la publication associée. Enfin, seul l'attribut « Etude » (study) du jeu de données n'a pas de correspondance dans le standard Darwin Core et doit donc être standardisé en utilisant l'extension MeasurementOrFact (paramètres ou valeur qualitative).

Bien que le jeu de données soit standardisé par les éléments du Darwin Core certaines difficultés inhérentes au jeu de données ont été rencontrées. En effet, il a été difficile de choisir la correspondance de certaines informations avec des termes du Darwin Core. Cela a été le cas avec les multiples informations relatives à la localisation du site d'échantillonnage. La différence d'utilisation, ou d'importance d'utilisation, des informations portées par les champs « ID » et « Locality 1 » n'est pas claire d'autant plus que leur valeur est identique. Aussi, les valeurs du champ « Commune » ne correspondent pas à une commune référencée par l'Insee. En supposant que les valeurs de ce champ doivent en théorie être des communes existantes, il a été choisi de le standardiser via le terme « municipality ». Si la cohérence des valeurs de ce champ n'est pas satisfaisante, le terme « Locality » - à ne pas confondre avec Locality 1 du jeu de données - de la classe Location peut être utilisé pour standardiser cette information.

Résumé de la standardisation du jeu de données ADNe par le Darwin Core :

<footnote n="14">¹⁴ https://doi.org/10.35035/doc-vf1a-nr22</footnote>

<footnote n="15">¹⁵ https://doi.org/10.1007/s10750-020-04260-8 ; https://doi.org/10.1016/j.biocon.2023.110089</footnote>
* Les données sont facilement standardisées en utilisant la classe Event et les extensions Occurrence, Taxon et MeasurementOrFact. La récursivité de la classe Event (utilisation du terme parentEventID) permet de rendre compte efficacement de l'organisation du suivi entre le site d'échantillonnage et les échantillons ;

* Seul l'attribut Study (Etude) doit être standardisé par l'extension MeasurementOrFact ;

* L'extension DNA derived data, recommandée par le GBIF dans le guide « Publishing DNA-derived data through biodiversity data platforms » permet de standardiser les informations liées aux analyses génétiques réalisées. Des informations décrites dans les publications associées au jeu de données mais qui gagneraient à être renseignées directement dans le jeu de données à l'avenir pour favoriser son exploitation.

## 2.1.2. Standardisation avec SOT V3.0

La standardisation des données avec le standard SOT V3.0 peut être modélisée comme présenté en figure 7.

<figure><img src="image_15.png" /><figcaption>Figure 7: modèle conceptuel de la standardisation de l'organisation des données par le standard SOT V3.0</figcaption></figure>

L'échantillon est standardisé en évènement d'observation (concept Evenement) avec sa date, son observateur et les coordonnées du point d'échantillonnage. Le ou les échantillons réalisés pendant le relevé sont regroupés dans un regroupement d'évènements (concept RegroupementEvenements) correspondant au site d'échantillonnage. Le lien entre l'évènement et le regroupement est alors réalisé en reportant l'identifiant SINP unique du regroupement (idSinpRegroupement) dans l'évènement. À l'échantillon sont liées 44 observations de taxons (concept SujetObservation) pour lesquelles sont reportées les informations sur le taxon (nomCite) et le statut de l'observation (présent ou absent).

Bien que le jeu de données soit facilement standardisé par le standard SOT certaines difficultés ont été rencontrées. En effet, plusieurs champs du jeu de données sont standardisés en attributs additionnels, soit car il n'y a pas d'attribut correspondant dans le standard soit à cause de blocages liés à la condition obligatoire des attributs du standard et pour lesquels aucune donnée n'est disponible dans le jeu de données (valeur nulle bloquante). Cet exercice de standardisation permet notamment de pointer l'absence de valeur correspondant à des lectures de machine dans la nomenclature de l'attribut obligatoire objetDenombrement pourtant indispensable pour indiquer une abondance relative des taxons en analyse ADNe. La date de détermination (concept Determination) est obligatoire, cependant cette information n'est pas disponible dans les données, bloquant alors l'utilisation de l'attribut methodeDetermination qui permettrait d'indiquer la valeur « génétique » et ainsi apporter un élément important pour la compréhension du jeu de données. De même pour l'idSinpJdd (identifiant SINP unique du jeu de données) mais cela est normal compte tenu de l'étape de vie du jeu de données dans le SINP à laquelle cet exercice est réalisé. Aussi, des incohérences dans les données ont été identifiées, notamment les valeurs du champ Commune qui ne correspondent pas à des communes référencées par l'Insee ce qui bloque le renseignement des attributs obligatoires de localisationRegroupement (codeLocalisation,
<table><tr><td rowspan="2">region</td><td rowspan="2">survey</td><td rowspan="2">subRegion</td><td rowspan="2">cycle</td><td rowspan="2">session</td><td rowspan="2">routeType</td><td rowspan="2">strate</td><td rowspan="2">computer</td><td rowspan="2">transect</td><td rowspan="2">effort</td><td rowspan="2">status</td><td rowspan="2">date</td><td rowspan="2">hh:mm:ss</td><td rowspan="2">seaState</td><td rowspan="2">subjective</td><td rowspan="2">lat</td><td rowspan="2">lon</td><td rowspan="2">DATE_TIME1</td><td rowspan="2">DATE_TIME2</td><td rowspan="2">legLength</td><td rowspan="2">nom_suivi</td><td rowspan="2">type</td></tr><tr></tr><tr><td>NEA</td><td>DunkRisk</td><td>MAN</td><td>1</td><td>LEG</td><td>N3</td><td>B</td><td>N3/101</td><td>L25-4-B</td><td>BEGIN.2017/04/07</td><td>142340</td><td>2.GM</td><td>51.61095166667</td><td>2.96203666667</td><td>2017-04-07T14:23:40</td><td>2017-04-07T14:24:53</td><td>3.73981683999563</td><td>DunkRisk_1(1)</td><td>plane</td></tr></table>

Lors du téléchargement des données de cette campagne deux fichiers sont disponibles (tableau 4). On comprend qu'un des fichiers contient les informations sur les observations (identifiant de l'observation, horodatage, espèce observée et transect pendant lequel a été faite l'observation) et que l'autre contient les informations sur l'effort d'observation (état de la mer, visibilité, horodatage, type d'effort, localisation et transect pendant lequel se déroule l'effort). En analysant plus précisément ces deux fichiers et en les recoupant aux informations sur le suivi que l'on possède on comprend qu'une observation est toujours reliée à un effort, or ce lien n'est pas directement renseigné dans les fichiers téléchargés. En effet, l'identifiant de l'observation ou l'identifiant de l'effort ne sont pas reportés dans l'un ou l'autre des fichiers, l'utilisateur doit donc faire le lien lui-même s'il veut pouvoir analyser ces informations conjointement. C'est un travail très chronophage qui demande de vérifier la correspondance entre l'horodatage de l'observation et de l'effort - combiné à l'identifiant de transect auquel ils sont rattachés, sachant qu'une observation correspond à un instant t au sein d'un effort caractérisé par une durée. Hors du cadre de cet exercice, l'utilisateur devrait demander un retour auprès du producteur de données pour qu'il lui renvoie un fichier comprenant le lien direct entre les observations et les efforts. Pour cet exercice nous continueront tel quel, en ne testant la standardisation que sur quelques enregistrements.

Dans ce jeu de données les observations peuvent porter sur des taxons mais également sur des objets tels que des bateaux de pêche, des bouées, des déchets plastiques, etc. Les observations de taxons seront facilement standardisées par les classes et concepts des standards en revanche la standardisation d'observations non taxonomiques n'est pas supportée – nous le verrons dans la suite de l'exercice.

On remarque également que certaines informations sont communes à tous les enregistrements des deux fichiers (region, survey, subRegion). Ces informations peuvent alors être considérées comme des métadonnées du jeu de données et ne sont donc pas standardisées dans cet exercice.

Une fois l'analyse des fichiers effectuée, l'organisation des données peut être schématisée comme suit :

<figure><img src="image_16.png" /><figcaption>Figure 8 : Schématisation de l'organisation des éléments du jeu de données LEDKOA.</figcaption></figure>

À gauche de la figure 8 sont représentées les multiples sessions de survol se déroulant sur une campagne. À une session sont liés plusieurs transects définis selon un plan d'échantillonnage. Au cours d'une session de survol d'un transect tous les efforts d'observation sont enregistrés et à chaque effort d'observation une observation de taxon peut être liée (lien en pointillé dans la figure car le lien n'est pas directement renseigné dans les fichiers de données - lors de la standardisation le lien sera fait via l'identifiant du transect). Un autre cas de figure peut se présenter lorsque des observations sont faites en dehors des transects prédéfinis. Il s'agit de manœuvres spéciales de survol entre transects. Dans cette figure, le nombre de sessions de survol, de transects, d'efforts et
d'observations représentées est un exemple. De plus, dans cette version du schéma les éléments sont déjà colorés selon le code couleur utilisé pour l'exercice.

### 2.2.1. Standardisation du jeu LEDKOA avec le Darwin Core

À partir de schémas tel que celui présenté en figure 8 et en y ajoutant tous les champs présents dans les fichiers de données, le modèle conceptuel final de la standardisation des données avec le Darwin Core peut être construit tel que présenté en figure 9.

<figure><img src="image_17.png" /><figcaption>Figure 9 : Modèle conceptuel du jeu de données LEDKOA avec le DwC</figcaption></figure>

La classe Event et son terme parentEventID permettant d'imbriquer plusieurs évènements est très utile pour ce jeu de données. En effet, tel que présenté en figure 13, les informations sur la session, le transect, l'effort et l'observation sont standardisées avec la classe Event. Dans ce cas, pour respecter l'organisation des données, l'évènement (Event) « Session » est le parent de l'évènement « Transect » qui est lui-même parent des évènements « Effort » et « Observation ». Aussi, tel que précisé précédemment, une observation peut être réalisée hors d'un transect, l'évènement « Session » est alors également parent de l'évènement « Observation » (un évènement « Observation » aura soit un évènement parent « Session » soit un évènement parent « transect »).

Lors d'une observation son identifiés des taxons (espèce) ou des objets (bateau, bouée, pollution). Les informations sur le taxon sont standardisées par l'extension Occurrence liée à l'évènement « Observation » en revanche les observations d'objets sont standardisées en tant que MoF liés à l'évènement d'observation. En effet, si l'on veut respecter les règles de validité du standard DwC, seule une observation de taxon peut être standardisée via les termes de l'extension Occurrence (taxonID, scientificName, individualCount, organismQuantity, ect.).

Dans chacune des boîtes (évènement et occurrence) de la figure 9 sont inscrits les termes du Darwin Core à utiliser pour la standardisation. Ils sont soit la correspondance directe du DwC des champs du jeu de données soit des termes obligatoires du standard soit des termes supplémentaires que l'utilisateur choisi d'utiliser pour aider à la compréhension du jeu de données. Cependant, cela n'est pas suffisant pour standardiser tous les champs du jeu de données par des termes existants du DwC, l'extension MoF est donc utilisée. C'est le cas des champs « cycle », « computer », « strate » et « surveyName » (qui sont tous communs à une même session de survol) ou encore les informations sur l'état de la mer et les conditions d'observations relevées lors d'une observation. Le champ « routeType » - renseigné à la fois pour les efforts et les observations dans le jeu de données - n'est pas standardisé pour les efforts car la valeur est toujours « LEG » - un effort étant toujours un « LEG » d'un transect.

Résumé de la standardisation des données de la campagne LEDKOA par le Darwin Core :
* L'organisation hiérarchisée des étapes du suivi mis en œuvre - tels que des passages le long d'un transect - est efficacement standardisée par la classe Event et le terme parentEventID.

* De nombreux champs spécifiques au suivi appliqué pour ce jeu de données sont standardisés en tant que MeasurementOrFact (extensions MoF), ce qui est normal pour des informations si spécifiques à un suivi.

* Les règles du standard Darwin Core ne permet pas la standardisation d'observations d'unité non taxonomique (objet, pollution). Ces informations sont alors standardisées par l'extension MoF.

### 2.2.2. Standardisation avec SOT V3.0 du jeu de données LEDKOA

À partir de schémas tel que celui présenté en figure 8 et en y ajoutant tous les champs présents dans les fichiers de données, le modèle conceptuel de la standardisation des données avec standard SOT V3.0 peut être construit tel que présenté en figure 10.

<figure><img src="image_18.png" /><figcaption>Figure 10 : Modèle conceptuel du jeu de données LEDKOA avec le SOT V3.0</figcaption></figure>

La figure 10 présente la modélisation conceptuelle de l'organisation du jeu de données par le standard SOT V3.0. Les attributs du standard utilisés pour la standardisation sont inscrits dans les boîtes représentant les concepts.

Ici, le concept RegroupementEvenements est utilisé pour standardiser les informations sur la session de survol qui regroupe les évènements d'observations (Evenement) réalisées hors transect et est regroupement parent du regroupement d'évènements « transect ». Le regroupement « transect » regroupe les évènements d'observations réalisées pendant le survol du transect et les efforts d'observation liés à ces observations. À noter que le lien entre qu'aucun lien direct n'est renseigné entre l'effort et son observation dans les fichiers de données.

À chaque évènement d'observation sont liés un ou plusieurs sujets d'observation (SujetObservation) auquel sont rattachés si besoin des éléments de description (DescriptifSujet) tels que le dénombrement.

Toutes les informations qui ne pouvent pas être standardisées avec des attributs de concepts définis – c'est-à-dire qu'ils désignent clairement un élément des données de biodiversité – dans le standard (Evenement, SujetObservation, DescriptifSujet, etc.) est standardisée en utilisant le concept AttributAdditionnel. C'est le cas
des informations spécifiques au suivi mis en œuvre comme l'ordinateur utilisé (computer) pour enregistrer les observations, la longueur de la section d'effort en kilomètres (legLenKm) ou le type de survol (routeType).

## Résumé de la standardisation du jeu de données LEDKOA par le SOT V3.0 :

* L'organisation hiérarchisée des étapes du suivi tels que les passages le long d'un transect est efficacement standardisée par le concept RegroupementEvenements et la fonctionnalité de récursivité que permet les attributs estRegroupementParent et idRegroupementParent.

* Les règles de renseignement du concept SujetObservation ne permettent pas de standardiser des observations d'unités non taxonomiques tels que des objets - les objets en mer (bateaux, pollutions, bouées) étant des observations relevées dans le cadre du suivi appliqué dans ce jeu de données. Ces observations doivent alors être standardisées en utilisant le concept AttributAdditionnel.

* De nombreuses autres informations sont standardisées comme attribut additionnel car elles sont trop spécifiques au suivi mis en œuvre.

## 2.3. Jeu de données n°3 : ASPE (pêche électrique)

Ce jeu de données est extrait de la base de données de l'application ASPE (Application de saisie des données piscicoles et environnementales), administrée par l'Office français de la biodiversité. L'API Poisson, disponible sur la plateforme Hub'Eau (outil du système d'information sur l'eau (SIE)), permet l'accès aux données d'hydrobiologie qui nous intéressent pour cet exercice. Elles correspondent aux informations collectées lors de la mise en œuvre de protocoles de pêche électriques (ici, protocole de type pêche complète) dans les cours d'eau français. Elles sont notamment utilisées pour calculer l'Indice poisson rivière (IPR) dans le cadre du rapportage de la directive cadre sur l'eau (DCE). Ci-dessous un extrait du jeu de données tel que structuré dans la base de données ASPE.

<table><caption>Tableau 5 : Extrait du jeu de données ASPE</caption><thead><tr><th>Code Sandre de la station</th><th>Nom de la station</th><th>Code ASPE du point de prélèvement</th><th>Code Sandre du point de prélèvement</th><th>Numéro d'opération</th><th>Date de l'opération</th><th>Niveau de validation</th><th>Qualification de la donnée</th><th>Bassin hydrographique</th><th>Cours d'eau</th></tr></thead><tbody><tr><td>4613007</td><td>R DEME A LOUESTAULT</td><td></td><td>6</td><td>90170</td><td>12/10/23</td><td>Validé niveau 1</td><td>Correcte</td><td>LOIRE-BRETAGNE</td><td>la Dème</td></tr><tr><td>4613007</td><td>R DEME A LOUESTAULT</td><td></td><td>6</td><td>90170</td><td>12/10/23</td><td>Validé niveau 1</td><td>Correcte</td><td>LOIRE-BRETAGNE</td><td>la Dème</td></tr><tr><td>4613007</td><td>R DEME A LOUESTAULT</td><td></td><td>6</td><td>90170</td><td>12/10/23</td><td>Validé niveau 1</td><td>Correcte</td><td>LOIRE-BRETAGNE</td><td>la Dème</td></tr><tr><th>Code de l'entité hydrographique</th><th>Région</th><th>Département</th><th>Commune</th><th>Lieu-dit</th><th>Coordonnées X du point de prélèvement</th><th>Coordonnées Y du point de prélèvement</th><th>Système de projection des coordonnées du point</th><th>Objectif de pêche</th><th>Espace ciblé</th></tr><tr><td>M1345800</td><td>CENTRE-VAL-DE-LOIRE</td><td>Indre-et-Loire</td><td>BEAUMONT-LA-RONCE</td><td>PONT DE LA D29 - LIEU-DIT- MOQUE-SOURIS</td><td>524028.00000000</td><td>6728114.00000000</td><td>RGF93 / Lambert 93</td><td>RRP - Réseau de Référence Pérenne</td><td></td></tr><tr><td>M1345800</td><td>CENTRE-VAL-DE-LOIRE</td><td>Indre-et-Loire</td><td>BEAUMONT-LA-RONCE</td><td>PONT DE LA D29 - LIEU-DIT- MOQUE-SOURIS</td><td>524028.00000000</td><td>6728114.00000000</td><td>RGF93 / Lambert 93</td><td>RRP - Réseau de Référence Pérenne</td><td></td></tr><tr><td>M1345800</td><td>CENTRE-VAL-DE-LOIRE</td><td>Indre-et-Loire</td><td>BEAUMONT-LA-RONCE</td><td>PONT DE LA D29 - LIEU-DIT- MOQUE-SOURIS</td><td>524028.00000000</td><td>6728114.00000000</td><td>RGF93 / Lambert 93</td><td>RRP - Réseau de Référence Pérenne</td><td></td></tr><tr><th>Protocole de pêche</th><th>Numéro du Passage</th><th>Type de point</th><th>Nom de l'ambiance</th><th>Surface échantillonnée (m²)</th><th>Identifiant du lot</th><th>Numéro du lot</th><th>Type du lot</th><th>Effectif de la ligne</th><th>Effectif du lot</th></tr><tr><td>Pêche complète à un ou plusieurs passages</td><td>1</td><td></td><td></td><td>351.00</td><td>5648513</td><td>1</td><td>N</td><td>1</td><td>1</td></tr><tr><td>Pêche complète à un ou plusieurs passages</td><td>1</td><td></td><td></td><td>351.00</td><td>5648575</td><td>63</td><td>1</td><td>1</td><td>3</td></tr><tr><td>Pêche complète à un ou plusieurs passages</td><td>1</td><td></td><td></td><td>351.00</td><td>5648569</td><td>57</td><td>S/L</td><td>1</td><td>158</td></tr><tr><th>Poids du lot (g)</th><th>Taille maximale des individus du lot (mm)</th><th>Taille minimale des individus du lot (mm)</th><th>Type de longueur du lot</th><th>Identifiant du poisson</th><th>Taxon - Code alternatif</th><th>Taxon - Code taxref</th><th>Taille de l'individu (mm)</th><th>Mesure réelle de la taille (non dégroupée)</th><th>Poids du poisson (g)</th><th>Présence de pathologie</th><th>Sexe de l'individu</th><th>Opération confidentielle</th></tr><tr><td>36</td><td></td><td></td><td>Totale</td><td>22483116</td><td>TRF</td><td>67778</td><td>Truite de rivière</td><td>162</td><td>Oui</td><td>Non</td><td>Non</td><td></td></tr><tr><td>34</td><td></td><td></td><td>Totale</td><td>22483352</td><td>LOF</td><td>67550</td><td>Loche franche</td><td>56</td><td>Oui</td><td>Non</td><td>Non</td><td></td></tr><tr><td>864</td><td></td><td></td><td>Totale</td><td>22483172</td><td>VAI</td><td>67404</td><td>Vairon</td><td>79</td><td>Oui</td><td>Non</td><td>Non</td><td></td></tr></tbody></table>

En analysant les champs du jeu de données (tableau 5) on comprend que les informations collectées lors de la mise en œuvre du protocole de pêche électrique complète peuvent être schématisées comme suit :

<figure><img src="image_19.png" /><figcaption>Figure 11 : Schématisation de l'organisation des éléments du jeu de données ASPE.</figcaption></figure>
La figure 11 présente la première schématisation des données une fois l'analyse du jeu de données complétée. Dans une station, un ou plusieurs points de prélèvement sont réalisés. Sur un point de prélèvement, une ou plusieurs opérations de pêche (selon le protocole de pêche) sont réalisées. Pour chaque opération, un prélèvement élémentaire (correspondant à un passage, selon le protocole) est effectué. Ce prélèvement permet de constituer des lots de poissons sur lesquels sont réalisées des mesures globales (mesure de l'ensemble du lot) et/ou individuelles de taille et de poids. Ainsi, plusieurs types de lot sont constitués. Un lot de type I (< 30 individus) signifie que la taille est mesurée pour tous les individus du lot mais que la pesée est globale (mesure de la biomasse). Un lot de type N contient un unique individu sur lequel sont effectuées les mesures de taille et de poids. Un lot de type S/L (> 50 individus) comprend les informations d'un lot L dénombré et pesé globalement auquel est rattaché un sous-échantillon S pour lequel des mesures individuelles sont effectuées. Ces informations sont importantes à comprendre pour standardiser le plus fidèlement possible le suivi mis en œuvre. Une fois cette étape validée le but est de transformer ce schéma en modèle conceptuel de données.

### 2.3.1. Standardisation avec le Darwin Core du jeu de données ASPE

<figure><img src="image_20.png" /><figcaption>Figure 12 : Modèle conceptuel du jeu de données ASPE avec le DwC</figcaption></figure>

La figure 12 présente le modèle conceptuel des données étudiées. Il reprend le libellé des classes et des termes qui les constituent du standard Darwin Core. Les termes utilisés pour la standardisation et indiqués dans ce modèle correspondent à des informations du jeu de données.

La station, le point de prélèvement (sampling point), l'opération de pêche (fishing operation) et le prélèvement élémentaire (operation session) traduisent la chaîne d'évènements (Event core) présentés en figure X. L'évènement de la station étant le plus englobant. Ces évènements sont reliés en reportant le terme parentEventID dans chaque évènement « fils ».

À l'évènement de prélèvement élémentaire sont liés les lots - standardisés par la classe Occurrence pour les informations sur l'espèce et identifiés par un identifiant unique. Si les individus du lot font l'objet de mesures individuelles alors ces informations sont standardisées par la classe Occurrence (alors identifiés par un identifiant unique). Le lien entre un poisson (individu) et le lot auquel il appartient est standardisé grâce au terme parentOccurrenceID. Tous les champs trop spécifiques au jeu de données, tels que le type du lot (batchType) et la taille du poisson (fishSize), sont standardisés par l'extension MeasurementOrFact.

Remarque sur les identifiants des évènements : le terme utilisé pour standardiser l'identifiant unique des évènements station et sampling point est standardisé avec le terme locationID alors que celui utilisé pour standardiser l'identifiant unique des évènements d'opération de pêche et de prélèvement élémentaire est fieldNumber. Il a été choisi d'utiliser locationID pour identifier les informations géographiques telles que celles décrivant une station et un point de prélèvement et fieldNumber pour celles décrivant une action telle que la mise en œuvre d'un protocole ou une session de passage.
Les noms de la station (« r deme a louestault ») et du point de prélèvement (« Pont de la D29 – lieu-dit Moque-Souris ») sont standardisé par le terme verbatimLocality (nom d'origine dans le jeu de données). Le champ « effectif de la ligne » - dont les valeurs sont identiques à l'effectif du lot dans tout le jeu de données - est standardisé par l'extension MeasurementOrFact (fishingLineQuantity) et lié à l'occurrence du lot (Batch) - qui standardise déjà l'effectif du lot via le terme individualCount.

Résumé de la standardisation par la Darwin Core :

* Le Darwin Core est très efficace pour standardiser l'organisation du jeu de données ASPE. Le terme parentEventID permettant de standardiser la hiérarchie des évènements.

* Le terme parentOccurrenceID est très utile pour ce jeu de données. Il permet de lier deux occurrences entre elles - permettant ainsi de standardiser le lot de poissons et les mesures individuelles sans perdre le lien entre les deux.

2.3.2. Standardisation avec SOT V3.0 du jeu de données ASPE

La standardisation du jeu de données ASPE par le standard SOT V3.0 peut se modélisée comme suit. Pour ce jeu
de données nous nous sommes appuyés sur la standardisation des données de pêche électrique complète
précédemment effectuée pour le standard SOT V2 (voir annexes 5.5 et 5.6).

<figure><img src="image_21.png" /><figcaption>Figure 13 : Modèle conceptuel du jeu de données APSE avec le SOT V3.0</figcaption></figure>

Pour ce jeu de données il a été choisi de modéliser les informations selon une organisation opérationnelle (figure 13). Ainsi, trois briques opérationnelles composent la chaîne de collecte des informations. Dans le standard SOT le concept d'évènement constitue le cœur des informations d'un relevé. Le prélèvement élémentaire est standardisé comme un évènement (évènement d'observation) comprenant l'information de localisation la plus précise – de ce fait les coordonnées du point de prélèvement sont rattachées au prélèvement élémentaire – et la date (la date de l'opération). Seul le champ prelevSurfaceEchant (surface échantillonnée) a été standardisé en tant qu'attribut additionnel du prélèvement élémentaire. Pour le protocole de pêche complète appliquée dans ce jeu de données un ou deux passages sont possibles, les évènements de prélèvement élémentaire sont donc regroupés par opération – standardisée par le concept RegroupementEvenements. Chaque opération est identifiée par son numéro (attribut idOrigineRegroupement) et le type de regroupement (ici « opération ») pour accompagner l'identifiant unique du regroupement. À cette opération sont rattachées en tant qu'attribut additionnel toutes les informations liées à la station et au point de prélèvement qui n'ont pas été standardisées
via l'évènement ou le regroupement (code de la station, nom de la station, codes du point de prélèvement, cours d'eau du points de prélèvement, etc.) ainsi que les informations de l'opération ne pouvant être standardisées par des attributs existants au concept RegroupementEvenements (espèce ciblée de l'opération, confidentialité de l'opération, etc.).

Le champ « Protocole de pêche » (rattaché à l'opération) fait référence à un protocole - il doit donc être standardisé en tant qu'attribut des métadonnées du jeu de données selon les règles des standards SINP et n'est donc pas standardisé dans cet exercice.

Des lots de poissons sont associés à chaque évènement de prélèvement élémentaire. L'identifiant du lot et l'espèce sont standardisés par les attributs du concept SujetObservation. Les informations sur le type de lot, les mesures globales de taille et de poids ainsi que le type de longueur mesurée et le numéro du lot (différent de son identifiant unique) ne sont pas portées par des attributs du standard - elles sont donc standardisées en tant qu'attribut additionnels des SujetObservation Lot. L'effectif du lot est quant à lui standardisé par les attributs du concept DescriptifSujet. Des individus peuvent être mesurés pour chaque lot - ils obtiennent alors un identifiant unique. Or le lien entre un lot et un individu du lot n'est pas directement possible entre deux instances de SujetObservation (pas d'attribut tel que parentOccurrenceID du DwC). De ce fait, le concept Interaction est utilisé pour lier deux instances de SujetObservation entre elles. En effet, le concept Interaction permet de lier deux instances de SujetObservation en reportant l'identifiant unique d'une des deux instances dans l'attribut idSinpSujetObsLie de l'instance d'Interaction rattachée à la deuxième instance de SujetObservation. C'est-à-dire qu'est rattachée à chaque instance de SujetObs décrivant un individu une instance d'Interaction dans laquelle est reportée l'idSinp du SujetObservation du lot auquel l'individu appartient. L'attribut typeInteraction du concept Interaction est lié à une nomenclature permettant de qualifier le lien entre les deux instances de SujetObservation par la valeur « est associé à ». Nous avons donc une instance de SujetObservation pour un individu qui « est associé à » l'idSinp du lot. De même que pour le lot, à chaque poisson est lié un DescriptifSujet dans lequel ont précise un dénombrement (toujours 1 dans ce cas) et le sexe de l'individu. Les informations sur la taille, le poids et une éventuelle pathologie sont standardisées en tant qu'attribut additionnel.

### Résumé de la standardisation avec le standard SOT V3.0 :

* La chaîne opérationnelle de collecte des données est efficacement standardisée par l'utilisation des concepts RegroupementEvenements (pour l'opération), Evenement (pour le prélèvement élémentaire) et SujetObservation pour le lot.

* Les mesures individuelles, nécessitant l'ajout d'un identifiant unique au poisson mesuré sont standardisées en tant que SujetObservation. De ce fait la standardisation du lien entre un lot et un individu de ce lot a nécessité l'utilisation du concept Interaction (interaction entre deux sujets d'observation) puisque le lien direct entre deux instances de SujetObservation n'est pas possible (pas d'attribut comme idSinpSujetObsParent).

* L'attribut « protocole de pêche » fait référence au protocole d'acquisition des informations mis en œuvre. Selon les règles du SINP le protocole est une information des métadonnées il n'est donc pas standardisé dans cet exercice.

## 2.4. Jeu de données n°4 : STOC-EPS (points d'écoute)

<table><caption>Tableau 6 : Extrait du jeu de données STOC-EPS</caption><thead><tr><td>Point</td><td>Carre</td><td>Annee</td><td>Id_point_année</td><td>Etude</td><td>Imse</td><td>Departement</td><td>Code_mdp</td><td>Cote_espaces_touristiques</td><td>Abondance_letit</td><td>Altitude</td><td>Longueur_mg84</td><td>Latitude_mg84</td><td>Code_hab_princ_1</td><td>Tab_princ_1</td><td>Code_hab_princ_2</td><td>Tab_princ_2</td><td>Code_hab sec_1</td><td>Tab_princ_1</td><td>Code_hab sec_2</td><td>Tab_princ_2</td></tr></thead><tbody><tr><td>0101000P01</td><td>10100</td><td>2007</td><td>20070310100P01</td><td>STOC EPS</td><td>0</td><td>1</td><td>HIRRUS</td><td>3696</td><td>4</td><td>235</td><td>5.33185781156003</td><td>46.166193329289</td><td>D02</td><td>Prairie non cultivée</td><td>D02</td><td>Prairie non cultivée</td><td>A01</td><td>Fortuit de feuillus</td><td>E03</td><td>Bourg rural</td></tr></tbody></table>

Le jeu de données étudié correspond aux données collectées lors de la mise en œuvre du programme de Suivi Temporel des Oiseaux Communs (STOC). Cet extrait (tableau 6) est issu de la base de données Faune France et
correspond aux données STOC rapportées au point d'écoute (on parle alors de STOC-EPS, Échantillonnages Ponctuels Simples). Ces données sont utilisées pour obtenir une évaluation des tendances d'évolution des effectifs de différentes espèces d'oiseaux communs de France. Le nombre de contacts avec une espèce en un point donné est une mesure de l'abondance de l'espèce dans le milieu. Si l'on totalise les contacts avec cette espèce dans tous les milieux du même type ou dans une région, et si l'on compare les valeurs obtenues au cours du temps, on peut apprécier la tendance d'évolution de l'espèce dans ce type de milieu ou à un niveau régional.

Au cours d'une année de suivi les observateurs notent le nombre d'individus (abondance brute) de chaque espèce d'oiseaux entendues ou vues lors de deux sessions d'écoute (réparties entre mars et juin) de 5 minutes sur chacun des points (au maximum 10) de leur carré STOC. Un observateur suit le même carré STOC et les mêmes points d'écoute d'année en année. Au cours d'une session d'écoute sont également notés l'habitat principal et l'habitat secondaire de chaque point. Ces habitats sont mis à jour chaque année si une modification d'habitat s'est opérée. Une ligne de données correspond à l'abondance brute d'une espèce sur une année pour un point d'un carré STOC. L'abondance brute des deux sessions d'écoute point étant regroupées au point dans ce jeu de données, les deux habitats de chaque session sont également regroupés au point.

Cette organisation des données peut être schématisée telle que présentée en figure 14.

<figure><img src="image_22.png" /><figcaption>Figure 14 : Schématisation de l'organisation des éléments du jeu de données STOC-EPS.</figcaption></figure>

La notion de participation correspond à l'identifiant unique de la saisie des données par l'observateur dans la base de données de Faune France. L'existence de cet identifiant unique justifie donc sa distinction des autres éléments du jeu de données (voir figure 14).

## 2.4.1. Standardisation avec le Darwin Core du jeu de données STOC-EPS

L'organisation des données peut être standardisée avec le Darwin Core telle que modélisée en figure 15.

<figure><img src="image_23.png" /><figcaption>Figure 15 : Modèle conceptuel du jeu de données STOC-EPS avec le DwC</figcaption></figure>

La classe Event permet de standardiser les informations d'un carré (identifiant unique, protocole et informations de localisation), d'un point (coordonnées du point, identifiant unique) et d'une participation (date et identifiant unique). Pour les habitats, le Darwin Core ne permet pas de standardiser des informations sur les habitats mis à part le terme « habitat » de la classe Event (permet de renseigner une catégorie ou une description d'un habitat dans lequel l'évènement s'est produit). Or, quatre habitats sont renseignés pour chaque évènement de participation avec un code et un libellé, ce n'est donc pas possible de standardiser ces informations avec le seul terme « habitat ». De ce fait, l'extension MeasurementOrFact est utilisée pour les standardiser.
L'évènement du point porte les informations sur les coordonnées du point, l'altitude ainsi que l'identifiant unique d'origine dans le jeu de données (champ id_point_annee).

L'évènement du carré (Square) porte les informations sur le protocole mis en œuvre et des informations de localisation supérieures aux coordonnées (pays). Les informations portées par les champs INSEE et Département sont standardisés par l'extension MeasurementOrFact.

À chaque participation sont liées des observations d'oiseaux. Les informations sur l'espèce et l'abondance brute sont standardisées par la classe Occurrence. Seul le champ Code_sp (traduit dans le modèle en speciesCode), correspondant à une nomenclature propre à Faune France, est standardisé en utilisant l'extension MeasurementOrFact.

Résumé de la standardisation avec le Darwin Core :

* La récursivité de la classe Event (par le terme parentEventID) permet de standardiser efficacement les étapes d'un STOC.

* Le Darwin Core ne permet pas de standardiser des informations complexes sur les habitats. Un unique terme « habitat » lié à la classe Event existe. Il ne permet pas de renseigner des codes d'habitats comme cela est de plus en plus commun avec l'utilisation de référentiel d'habitats. De ce fait, les quatre habitats d'un point sont standardisés avec l'extension MeasurementOrFact.

* Les termes samplingEffort et samplingProtocol suffisent à standardiser les informations sur le protocole et l'effort d'échantillonnage.

2.4.2. Standardisation avec SOT V3.0 du jeu de données STOC-EPS

<figure><img src="image_24.png" /><figcaption>Figure 16 : Modèle conceptuel du jeu de données STOC-EPS avec le SOT V3.0</figcaption></figure>

Le concept RegroupementEvenements permet de standardiser les informations du carré et du point (figure 16). Le regroupement « carré » est le regroupement parent du regroupement « point » (jusqu'à 10 points d'écoute peuvent être suivis dans un carré) et le regroupement « point » regroupe tous les évènements de participation liés au point - selon les années et le nombre d'espèces observées en une session d'écoute. Ces liens sont standardisés en reportant l'idSinpRegroupement du regroupement « carré » dans le regroupement « point » (attribut idRegroupementParent) et en reportant l'idSinpRegroupement du regroupement « point » dans chaque évènement « participation » lié au point. À chaque évènement « participation » est liée un sujet d'observation, l'espèce d'oiseau. L'abondance brute du sujet d'observation est décrite par les attributs du concept
le programme STOC et pour le programme Vigie-Chiro – sur 1 à 10 points qu'il choisit de suivre dans ce carré.
L'organisation des données peut être schématisée comme sur la figure 17.

<figure><img src="image_25.png" /><figcaption>Figure 17 : Schématisation de l'organisation des éléments du jeu de données protocole point fixe Vigie-Chiro.</figcaption></figure>

Selon le protocole une participation est définie comme l'enregistrement des données pour un point spécifique dans un carré au cours d'une session d'enregistrement. Cette session peut se dérouler sur une seule nuit ou s'étendre sur plusieurs nuits consécutives. Cependant dans le jeu de données étudié une participation (champ « participation » qui a pour valeur un identifiant unique universel) peut correspondre à plusieurs nuits et pour chacune de ces nuits une ou plusieurs espèces peuvent être détectées (une ligne de données par espèce détectées au cours d'une nuit). Dans cet exercice la participation est alors équivalente à la session d'enregistrement (telle que présentée dans le guide du protocole) et les nuits sont schématisées et standardisées comme appartenant à une participation.

### 2.5.1. Standardisation avec le Darwin Core du jeu de données Vigie-Chiro

<figure><img src="image_26.png" /><figcaption>Figure 18 : Modèle conceptuel du jeu de données protocole point fixe Vigie-Chiro avec le DwC</figcaption></figure>

L'organisation des données de Vigie-Chiro peut être standardisée telle que modélisées conceptuellement en figure 18. Le carré (Square), le point (Point), la participation (Participation) et la nuit d'enregistrement (Night) sont standardisés par la classe Event. Cette classe permet de hiérarchiser des évènements grâce aux termes eventID et parentEventID - telle qu'une nuit d'enregistrement est incluse dans une participation (qui peut regrouper plusieurs nuits d'enregistrement) portant l'information de l'année de suivi d'un point d'un un carré Vigie-Chiro. Dans ce modèle les termes du DwC correspondant aux champs du jeu de données sont directement inscrits, exceptés les champs standardisés par l'extension MeasurementOrFact qui sont uniquement traduits. Au cours de chaque nuit une ou plusieurs espèces de chiroptères (et d'autres organismes vivants tels que des insectes) sont détectées par l'enregistreur. Ces observations sont standardisées par les termes de l'extension Occurrence. Tous les champs spécifiques au suivi mis en œuvre (matériel d'enregistrement utilisé, conditions météorologiques, nombre d'heures enregistrées ainsi que les scores liés à l'identification automatique ou les probabilités de détection) sont standardisés par l'extension MeasurementOrFact. Cette extension est très utile pour ce jeu de données car elle permet - de par le terme parentMeasurementID - d'imbriquer des mesures entre elles et ainsi représenter une hiérarchie plus fine des données. En effet, pour l'exploitation de ces données, l'équipe Vigie-Chiro se base sur le nombre de nbContacts dont le score_max (traduits en contactNumber et maxScore dans le modèle) est compris entre 0.5 et 1, il faut donc que la standardisation des données permette de renseigner ce lien - cela est possible grâce au terme parentMeasurementID. Tous les champs sur le matériel utilisé sont standardisés en MeasurementOrFact de l'évènement Participation tandis que ceux sur les conditions
météorologiques et les heures d'enregistrement sont standardisés via un lien à l'évènement Night et ceux concernant l'identification et la détection des espèces le sont pour l'occurrence Species.

Résumé de la standardisation par le Darwin Core :

* Le terme parentEventID de la classe Event permet de standardiser efficacement l'organisation des données (carré>point>participation>nuit>espèce).

* Le lien entre les champs contacts_nb et score_max - qui est très important pour l'utilisation des données - est standardisé en utilisant le terme parentMeasurementID de l'extension MeasurementOrFact.

2.5.2. Standardisation avec SOT V3.0 du jeu de données Vigie-Chiro

<figure><img src="image_27.png" /><figcaption>Figure 19 : Modèle conceptuel du jeu de données protocole point fixe Vigie-Chiro avec le SOT V3.0.</figcaption></figure>

L'organisation des données du protocole point fixe du programme Vigie-Chiro peut être modélisée comme présenté dans la figure 19. Le concept RegroupementEvenements permet de standardiser les différents éléments du suivi : le carré (RegroupementEvenements) regroupe des points (RegroupementEvenements) qui sont suivi annuellement. Chaque suivi annuel est enregistré comme une participation (RegroupementEvenements) regroupant une ou plusieurs nuits d'enregistrement (Evenement). Pour chaque nuit une ou plusieurs espèces (SujetObservation et DescriptifSujet) sont dénombrées. Tous les champs du jeu de données spécifiques au suivi (matériel d'enregistrement, conditions météorologiques, nombre d'heures enregistrées, probabilité de détection et d'identification) sont standardisés en tant qu'attributs additionnels. Tous les champs sur le matériel d'enregistrement sont liés au regroupement Participation, tous ceux sur l'enregistrement (nombre d'heures, conditions météorologiques) sont liés à l'évènement Nuit et tous ceux sur l'observation des organismes (décalage avec lever et coucher du soleil, confiance du validateur sur l'observation, groupe taxonomique, score d'identification, etc.) sont liés au sujet d'observation (espèce). La documentation du jeu de données indique que le champ score_max (scoreMax) est lié au champ nbContacts (nbContacts) et que cette information est très importante pour l'utilisation du jeu de données. Cela implique que le lien entre ces deux champs est à standardiser or, ce n'est pas possible dans la version actuelle du standard.

Résumé de la standardisation avec SOT V3.0 :

* Les différents éléments du suivi sont efficacement standardisés par les concepts du standard SOT V3.0. Notamment le concept RegroupementEvenements qui permet de regrouper les nuits d'enregistrement dans les participations correspondantes qui elles-mêmes sont regroupées au point et les points au carré.

* La standard SOT V3.0 ne permet cependant pas de standardiser le lien entre deux attributs additionnels or cela est nécessaire pour les champs score_max et nbContacts.

* Lors de la standardisation en table on remarque qu'il manque une valeur adéquate dans la nomenclature associée à l'attribut methodeDenombrement pour les observations déterminées par ordinateur/programme informatique automatisé.
* La valeur « CA » pour « contact acoustique » de la nomenclature associée à l'attribut objetDenombrement peut être utilisée pour standardiser ce jeu de données.

## 3. Conclusion

Dans cet exercice cinq jeux de données - représentant des processus de suivi mis en œuvre pour des programmes liés à des politiques publiques ou des projets de recherche - ont été étudiés pour tester l'applicabilité des standards DwC et SOT V3.0 aux données de surveillance de la biodiversité.

<figure><img src="image_28.png" /><figcaption>Figure 20 : Modèle conceptuel des standards Darwin Core et SOT V3.0</figcaption></figure>

La totalité des informations que portent ces jeux de données peut être standardisée à l'aide des éléments des deux standards notamment grâce à l'extension MeasurementOrFact du DwC et le concept AttributAdditionnel du SOT V3.0 - qui permettent de standardiser n'importe quelle information, aussi spécifique à un jeu de données soit-elle, tant que l'on peut lui attribuer un libellé, une description, une valeur et potentiellement une unité. L'organisation hiérarchisée des informations (structure commune aux jeux de données de surveillance) est efficacement standardisée par les classes Event et Occurrence du DwC et les concepts RegroupementEvenements, Evenement et SujetObservation du SOT V3.0 (figure 20), notamment grâce aux fonctionnalités de récursivité que permettent les termes « parent....ID » et l'attribut « idRegroupementParent ». Une des forces du Darwin Core est l'utilisation des termes eventType et eventRemarks - bien que non contraint par un vocabulaire contrôlé - permettant de préciser le niveau de chaque évènement en complément du terme eventID. L'attribut « commentaireEvenement » du SOT V3.0 permet également d'apporter des informations complémentaires. Il faut cependant faire attention à l'utilisation à outrance de ces termes et attributs - dont le renseignement est libre – qui pourrait les transformer en « fourre-tout » et les rendre non exploitables (le format des valeurs étant trop hétérogène).

Toutefois, des difficultés de standardisation – qu'elles soient spécifiques à un jeu de données ou liées aux règles des standards - ont été mises en lumière par cet exercice.

Faiblesses du Darwin Core :

- La documentation du Darwin Core est peu accessible. En effet, l'entrée principale pour prendre connaissance des éléments du standard est une page web, sans schéma ou modèle conceptuel explicatif des liens possibles entre les classes. La présenation est faite dans un format complexe, même pour quelqu'un de familier avec ce type d'outils. Le reste de la documentation est uniquement accessible via le
Github du projet. Il serait intéressant d'améliorer cette documentation en ajoutant, entre autres, des schémas et modèles conceptuels explicatifs.

- La flexibilité du standard est une grande force pour sa liberté d'utilisation mais aussi une faiblesse. En effet, pour un grand nombre de termes, l'utilisation d'un vocabulaire contrôlé est recommandée mais aucun lien vers une liste existante n'est donné. Cela laisse aux utilisateurs le choix du vocabulaire contrôlé à utiliser - ce qui peut desservir l'intérêt de l'outil en augmentant l'hétérogénéité des valeurs renseignées pour les termes concernés -, rendant l'interprétation des données plus difficile.

- La récursivité de la classe Occurrence par l'ajout du terme parentOccurrenceID qui a été proposé par la communauté d'utilisateurs du DwC<fnref n="16" /> n'est - à l'heure de la rédaction de ce rapport - pas encore acceptée par le TDWG. Or, nous avons démontré dans cet exercice qu'elle est utile pour standardiser le lien entre un lot et un individu de ce lot (jeu de données ASPE) sur lesquels sont effectuées des mesures. Il est aussi plus utile pour faire automatiquement le lien entre deux occurrences dans les tables de gestion que le terme AssociatedOccurrences car il demande le renseignement des identifiants uniques et non pas un format {libellé:valeur}. De plus, le libellé de ce nouveau terme est cohérent avec les termes parentEventID et parentMeasurementID.

- Les classes du standard sont exclusivement « taxon orientées ». Il n'existe pas de possibilité – en respectant les règles de renseignement du standard – de renseigner par exemple l'observation d'un objet ou de pollution (jeu de données LEDKOA). Ces informations seront pourtant de plus en plus relevées pour établir leur lien avec l'état des espèces et des habitats.

- Il n'existe qu'un unique terme dans le standard pour renseigner des informations sur les habitats (terme « habitat » de la classe Event). Cependant l'utilisation de typologies d'habitats (versionnées) avec des codes d'identification est de plus en plus répandue dans la communauté - ces informations doivent donc être standardisées.

Faiblesses du SOT V3.0 :

- Le manque de récursivité des concepts SujetObservation et DescriptifSujet a posé problème pour le jeu de données ASPE (mesure individuelle sur un individu d'un lot de poissons).

- Il serait utile que le concept AttributAdditionnel puisse être lié à davantage de concepts notamment à DescriptifSujet.

- La condition d'obligation de renseignement de certains attributs c'est révélé bloquante pour la standardisation d'informations des jeux de données étudiés. Que ce soit simplement qu'aucune valeur pour un attribut obligatoire n'est renseignée dans le jeu de données ou lorsque l'utilisation d'un attribut est bloquée car ce dernier appartient à un concept dont d'autres attributs sont obligatoires mais pour lesquels aucune valeur n'est renseignée dans le jeu de données.

- Certaines nomenclatures du standard présentent des lacunes qui ont été bloquantes pour standardiser certains jeux de données. Il s'agit notamment de la nomenclature objetDenombrement pour les abondances relatives issues d'analyses génétiques dont le dénombrement se fait par un nombre de lectures machine, ou les identifications d'espèce par programme informatique automatisé.

Résumé de l'applicabilité du standard Darwin Core aux jeux de données de surveillance :

1. Les classes Event et Occurrence - en utilisant les termes parentEventID et parentOccurrenceID - permettent de bien standardiser la hiérarchisation des données d'un protocole de suivi.

2. La récursivité de la classe Occurrence par l'ajout du terme parentOccurrenceID qui a été proposé par la communauté d'utilisateurs du DwC n'est - à l'heure de la rédaction de ce rapport - pas encore acceptée par le

<footnote n="16">¹⁶ Enetwild consortium, Jaroszynska Francesca, Body Guillaume, Pamerlon Sophie, Archambeau Anne-Sophie (2022) Applying the Darwin core data standard to wildlife disease – advancements toward a new data model. EFSA supporting publication 2022: EN-7667. 68 pp. doi:10.2903/sp.efsa.2022.EN-7667</footnote>
TDWG. Or, nous avons démontré dans cet exercice qu'elle est utile pour standardiser le lien entre un lot et un individu de ce lot (jeu de données ASPE) sur lesquels sont effectuées des mesures. Il est aussi plus utile pour faire automatiquement le lien entre deux occurrences dans les tables de gestion que le terme AssociatedOccurrences car il demande le renseignement des identifiants uniques et non pas un format {nom:valeur}. De plus, le libellé de ce nouveau terme est cohérent avec les termes parentEventID et parentMeasurementID.

3. L'extension MoF (en utilisant le terme parentMeasurementID) permet de standardiser toutes les informations des jeux de données qui ne sont pas prises en charge par une autre classe ou extension du standard.

4. L'utilisation des termes eventType (site, transect, occurrence, etc.) et eventRemarks permettent d'identifier et de préciser le rôle que représente chaque évènement créé afin de comprendre la manière dont le jeu de données a été standardisé.

5. La documentation du Darwin Core est peu accessible. En effet, l'entrée principale pour prendre connaissance des éléments du standard est une page web - sans schéma ou modèle conceptuel explicatif des liens possibles entre les classes - présentée dans un format déjà assez complexe même pour qui est familier avec ce type d'outils. Le reste de la documentation étant accessible uniquement via le Github du projet. Il serait intéressant d'améliorer cette documentation en ajoutant, entre autres, des schémas et modèles conceptuels explicatifs.

6. La flexibilité du standard est une grande force pour sa liberté d'utilisation mais aussi une faiblesse. En effet, pour un grand nombre de termes, l'utilisation d'un vocabulaire contrôlé est recommandée mais aucun lien vers une liste existante n'est donné. Cela laisse aux utilisateurs le choix du vocabulaire contrôlé à utiliser - ce qui peut desservir l'intérêt de l'outil en augmentant l'hétérogénéité des valeurs renseignées pour les termes concernés -, rendant l'interprétation des données plus difficile.

7. Il n'existe qu'un unique terme dans le standard pour renseigner des informations sur les habitats (terme « habitat » de la classe Event). Cependant l'utilisation de typologies d'habitats (versionnées) avec des codes d'identification est de plus en plus répandue dans la communauté - ces informations doivent donc être standardisées.

8. Les classes et extensions du standard sont exclusivement « taxon orientées » (les termes des classes Occurrence, Taxon et Organism se rapportent tous au concept de taxon). La possibilité d'indiquer la présence d'objet (autre que taxon) ou de pollution (cas du jeu de données LEDKOA) n'existe pas.

## Perspectives d'évolution du standard et recommandations d'utilisation :

a. Lorsque l'utilisation d'un vocabulaire contrôlé est recommandée par le standard, il serait intéressant de compléter les exemples de valeur par l'utilisation d'un vocabulaire existant en indiquant un lien vers lequel le consulter. Cela améliorerait l'homogénéité des valeurs renseignées pour les termes concernés.

b. Promouvoir l'utilisation du terme eventType pour identifier le rôle de chaque Event (en complément de l'eventID qui doit être sous forme d'UUID).

c. Faire évoluer la documentation du standard pour qu'elle soit plus accessible à tout niveau d'utilisateur. Ajouter des schémas explicatifs de l'organisation des classes entre elles et de leurs liens.

d. Ajouter davantage de termes pour standardiser les informations sur les habitats et permettre d'associer plusieurs habitats à un Event.

e. À l'avenir, de plus en plus de données sur les pressions seront collectées lors de la réalisation de suivi de taxons et d'habitats. Le Darwin Core et ses extensions gagneraient à être en capacité de les standardiser.

## Résumé de l'applicabilité du standard SOT V3.0 aux jeux de données de surveillance :

1. Les concepts Evenement, RegroupementEvenements et SujetObservation permettent de bien retranscrire la hiérarchisation des données issues d'un protocole de suivi, à quelques exceptions.
2. Le concept AttributAdditionnel permet de standardiser toute information d'un jeu de données qui n'est pas standardisée par les attributs des autres concepts du standard. Cependant, AttributAdditionnel est lié uniquement aux trois concepts cités dans le point 1. Dans certain cas, bien que l'information puisse être standardisée par ce concept, des liens entre informations peuvent être perdus. Par exemple des mesures complémentaires réalisées sur un individu (impossibilité de lier un attribut additionnel au concept DescriptifSujet).

3. L'absence de récursivité des concepts SujetObservation et DescriptifSujet a posé problème pour standardiser la hiérarchisation des données du jeu ASPE (mesure individuelle sur un individu d'un lot de poissons).

4. Le caractère obligatoire de certains attributs c'est révélé bloquant pour la standardisation de plusieurs informations. L'utilisation d'un attribut peut être bloquée car il se trouve dans le même concept que d'autres attributs obligatoires pour lesquels aucune information n'est disponible dans le jeu de données (ex. attribut idSinpJdd du concept Evenement, attribut dateDetermination du concept Determination pour le jeu de données ADNe et les attributs versionTypo et versionHabRef du concept LienHabitats).

5. Il existe des lacunes de valeurs dans les nomenclatures du standard, notamment pour les données issues d'analyses génétiques comme le metabarcoding (ADNe) ce qui cause des pertes d'informations.

## Perspectives d'évolution du standard et recommandations d'utilisation :

a. Ajouter des valeurs dans les nomenclatures pour une meilleure prise en compte des données issues d'analyses génétique (objetDenombrement).

b. Revoir le caractère obligatoire de dateDetermination (ou le placement de methodeDetermination); versionType et versionHabRef.

c. Toujours enregistrer les métadonnées (cadre d'acquisition et jeu de données) avant l'intégration des données car l'attribut IdSinpJdd est obligatoire.

d. Ajouter une récursivité au concept SujetObservation (ou revoir l'utilisation du concept Interaction).

e. Ajouter des possibilités de lien entre le concept AttributAdditionnel et davantage de concepts du standard.

# 4. Discussion

## 4.1. Réflexions sur la standardisation des jeux de données issus de techniques ADNe

La standardisation des jeux de données issus de méthode ADNe par des standards d'échange portés sur l'observation de taxon demande encore beaucoup de réflexion à plusieurs niveaux.

En effet, la collecte de données par des techniques d'analyse génétique comme pour l'ADNe est en croissance constante et se démocratise au-delà de la communauté de la recherche. Cette nouvelle diversité d'acteurs multiplie les besoins d'utilisation de ce type de données ce qui accroit potentiellement la quantité d'informations à renseigner dans ces jeux de données. Or, cela impose aux producteurs de données une charge de travail supplémentaire.

Il semble donc nécessaire que la communauté scientifique parvienne à harmoniser les techniques ADNe utilisées au niveau national, si possible international, qui mènera à une harmonisation des informations collectées et renseignées dans les jeux de données. Il est également nécessaire que la communauté réfléchisse aux informations les plus importantes à renseigner lors de la collecte des données en vue de le leur interprétation et exploitation. Une attention particulière devra notamment être portée sur les variables qui seront standardisées en attributs obligatoires dans les standards et celles pouvant être considérées comme facultatives - afin d'alléger le renseignement des informations pour les producteurs de données.
Pour les informations collectées par metabarcoding, par exemple, le nombre de lectures de machine (reads) en sortie de séquençage traduit une abondance relative du sujet observé. En effet, des milliers de séquences peuvent appartenir à un même individu ou plusieurs. Cela rend obligatoire de séparer la standardisation des informations « individu » et « nombre de lecture » qui correspondent à deux dénombrements différents liés à un même sujet d'observation. De même, les séquences peuvent être liées à un OTU, une unité ne correspondant pas à un rang taxonomique référencé. —Si le nom d'espèce est obligatoire dans le standard de données, l'utilisation d'OTU n'est plus compatible et les données ne peuvent pas être standardisées.. Doit-on tenir compte de ces spécificités dans les futures évolutions des standards de données ? Ce sont à ces questions qu'il faut réfléchir dès maintenant.

Les standards du SINP proposent tout de même de premiers éléments pour standardiser les données issues d'analyse ADNe. Dans le standard SOT V3.0, l'attribut methodeDetermination (concept Determination) permet de renseigner la valeur « génétique », les attributs techniqueCollecte - faisant appel à Campanule - et autreTechnique permettent d'associer au sujet observé la technique de collecte mise en œuvre. Dans le standard Métadonnées V2 l'attribut classeEBV permet de renseigner la valeur « données liées à la génétique ».

La communauté du GBIF a quant à elle produit un guide pour standardiser les données dérivées d'ADN en utilisant le Darwin Core. Cependant, la majorité des informations recommandées par ce guide ne sont pas renseignées dans le jeu de données étudié alors qu'elles sont trouvables dans les publications scientifiques associées. De ce fait il devrait être fortement recommandé, de renseigner les références de ces publications dans le jeu de données - les standards d'échanges testés pour cet exercice permettent tous deux de standardiser des références bibliographiques.

Dans l'idéal, il faudrait renseigner directement dans le jeu de données toutes les informations recommandées par le guide GBIF. La communauté scientifique pourrait se saisir de ces recommandations comme base de réflexion à l'harmonisation des données collectées par analyses ADNe et ainsi organiser la structure des jeux de données afin que les évolutions des standards puissent les prendre en compte.

Dans tous les cas, sans ces deux niveaux d'harmonisation – technique ADNe mise en œuvre et informations minimales à renseigner dans le jeu de données - il semble encore difficile que les standards satisfassent pleinement aux besoins de la communauté.

## 4.2. Darwin Core ou SOT V3.0 ?

La philosophie d'élaboration des standards Darwin Core et SOT V3.0 est très similaire. En effet, les deux standards ont pour vocation le partage des données d'observation (ou d'occurrence) de taxon (présence ou absence d'un taxon à un lieu et une date donnée). Ils permettent de standardiser les différentes étapes de collecte d'un suivi de la biodiversité grâce au concept d'évènement (informations relatives à un relevé, la date, l'observateur, le lieu) pouvant être emboîtés et auquel sont rattachées les observations.

Des différences majeures distinguent cependant les deux standards.

Tout d'abord, le Darwin Core est plus souple sur les conditions de renseignement de ses termes là où le standard SOT V3.0 est plus contraignant (vocabulaire contrôlé). Cette caractéristique a ses avantages et ses inconvénients : contraindre les utilisateurs est un risque de désengagement car cela demande plus de temps et d'implication pour le renseignement des données mais être trop souple impact la qualité et l'utilisation ultérieure des données (hétérogénéité). Nous recommandons donc de produire des exemples, des guides et des outils permettant d'orienter les utilisateurs vers des pratiques communes.

La cible de ces standards n'est également pas la même. En effet, le standard SOT V3.0 s'inscrit dans le SINP, dispositif national et partenarial, devant rendre compte d'une certaine qualité des données afin qu'elles puissent être utiles directement à la fois pour l'élaboration et l'évaluation des politiques publiques et les rapportages
européens ; pour améliorer la connaissance de la biodiversité des territoires ou être utilisées dans la réalisation de divers documents de référence (listes régionales de sensibilité, des atlas, des études d'impacts etc.) ; à une échelle nationale pour la valorisation et la validation scientifique des données du SINP assurant sa qualité ; enfin pour les acteurs nationaux et territoriaux, améliorer la qualité des données et leur validation scientifique et technique. Le standard Darwin Core est lui utilisé au niveau international notamment par la communauté du GBIF et a plus une vocation de connaissance globale sur la biodiversité du globe. Seules quelques informations sont alors obligatoires pour rendre accessibles les observations.

Aujourd'hui une correspondance existe entre les deux standards pour permettre l'échange de données entre le SINP et le GBIF. À l'avenir il est toutefois envisageable que des concepts/classes constituent une base commune aux deux standards (même attributs, même libellés, avec traduction) auxquels seraient appliquées des règles d'utilisation spécifiques aux besoins nationaux du SINP pour SOT V3.0 (attributs obligatoires, nomenclatures, concepts de validation, de modification etc.). Le Darwin Core pourrait quant à lui reprendre certains concepts du SOT V3.0 comme LienHabitats et Strate - types d'informations lui faisant actuellement défaut. La dynamique actuelle d'évolution du Darwin Core va en ce sens. En effet, son nouveau modèle de données, en phase de publication, tend à contraindre davantage la standardisation de ses termes avec du vocabulaire contrôlé, se rapprochant de la philosophie du SINP quant à la qualité et la complétion des données requises.

Pour conclure, ces deux standards ont vocation dans leur philosophie et leur contenu à se rapprocher l'un de l'autre mais la différence dans le public ciblé et les vocations d'utilisation des données rendent leur coexistence indispensable.
# 5. Annexes

## 5.1. Tables de standardisation du DwC pour le jeu de données ADNe

<figure><img src="image_29.png" /><figcaption>Figure 21: Étapes intermédiaires de schématisation de l'organisation des données du jeu de données ADNe</figcaption></figure>

En haut, la traduction en anglais de l'organisation des données. En bas, identification par code couleurs des classes à utiliser lors de la standardisation et des éléments importants à standardiser dans chaque boîte.

Les schémas présentés en figure 21 sont les premières étapes essentielles à une bonne standardisation des données et intervient avant le modèle conceptuel. Elles consistent à schématiser l'organisation des données en boîtes, identifier les éléments clés de chaque boîte et à quelle boîte des standards elle peuvent correspondre (code couleur).

<table><caption>Tableau 8 : Table de standardisation de la classe Event du DwC pour le jeu de données ADNe</caption><thead><tr><th>eventID</th><th>parentEventID</th><th>materialInSampleID</th><th>fieldNumber</th><th>eventDate</th><th>location</th><th>decimalLatitude</th><th>decimalLongitude</th><th>geodeticDatum</th><th>sampleId</th><th>sampleType</th><th>samplingProtocol</th><th>waterBody</th><th>municipality</th><th>locationID</th><th>verbatimLocality</th><th>higherGeography</th><th>eventRemarks</th><th>eventType</th><th>dynamicProperties</th></tr></thead><tbody><tr><td>sampling1</td><td></td><td></td><td></td><td>06/04/2016</td><td>CNR</td><td></td><td></td><td></td><td></td><td></td><td>*</td><td>Valserine</td><td>La Valserine</td><td>1</td><td>1</td><td>Rhône</td><td>No occurrences</td><td>site</td><td>(= study = VigiLife Rhône)</td></tr><tr><td>replicate1</td><td>sampling1</td><td>SPV1600873</td><td>R1</td><td></td><td></td><td>48.144235</td><td>5.963902</td><td>4326</td><td>800000</td><td>DNA sequence reads</td><td></td><td></td><td></td><td></td><td></td><td></td><td>3000000DNA sequence reads for each of the two primers</td><td>Sample</td><td></td></tr><tr><td>replicate2</td><td>sampling1</td><td>SPV1600874</td><td>R2</td><td></td><td></td><td>48.144217</td><td>5.964269</td><td>4326</td><td>800000</td><td>DNA sequence reads</td><td></td><td></td><td></td><td></td><td></td><td></td><td>3000000DNA sequence reads for each of the two primers</td><td>Sample</td><td></td></tr></tbody></table>

<table><caption>Tableau 9 : Table de standardisation de l'extension MoF du DwC pour le jeu de données ADNe</caption><thead><tr><th>measurementID</th><th>parentEventID</th><th>parentOccurrenceID</th><th>measurementType</th><th>measurementValue</th><th>measurementUnit</th></tr></thead><tbody><tr><td>meas1</td><td>sampling1</td><td></td><td>study</td><td>Vigielife Rhône</td><td></td></tr></tbody></table>

Le site d'échantillonnage est standardisé via la classe Event (eventID « sampling1 ») (tableau 8) et comprend les informations sur la date (eventDate), les multiples informations géographiques liées au site (higherGeography, municipality, waterBody, verbatimLocality, locationID) ainsi que la précision de l'eventType (site) et une remarque libre (ici précision que cet évènement n'a pas d'occurrence qui lui est lié). (Des informations supplémentaires peuvent être ajoutées à la classe Event permettant ainsi de faciliter la compréhension des données. Le terme eventType permet d'associer à chaque enregistrement, ici l'évènement du site, son type (élément descriptif de compréhension). L'information portée par le champ Etude (traduit ici en « study ») est standardisée via l'extension MeasurementOrFact (figure 5) n'ayant pas de correspondance dans les termes du Darwin Core. Pour rappel, cette information peut être standardisée en tant que métadonnée si elle se révèle être commune à tous les enregistrements du jeu de données.

À cet évènement est lié un ou deux évènements « fils », les échantillons (replicate1/replicate2), faisant devenir l'évènement du site leur évènement « parent » (parent event) par le renseignement du terme « parentEventID ». La classe Event permet de standardiser le numéro de l'échantillon (champ Replicate, terme fieldNumber), les coordonnées du point d'échantillonnage (decimalLatitude, decimalLongitude, geodeticDatum), le numéro du kit
d'échantillonnage (champ kit# terme materialSampleID (en considérant que le numéro du kit est utilisé comme identifiant unique de l'échantillon pour ce jeu de données)). Suivant les recommandations du guide GBIF sur la standardisation des données dérivée d'ADN, il est recommandé de renseigner les termes sampleSizeValue et sampleSizeUnit. Ces valeurs ne sont pas présentes dans le jeu de données étudié mais sont indiquées dans les publications associées, il faudrait donc à l'avenir que ces informations soient directement renseignées dans le jeu de données pour faciliter la récupération de ces informations. De même que pour l'évènement du site d'échantillonnage on précise un eventType (sample) et une eventRemarks, ici elle permet par exemple d'expliquer plus en détails la valeur de SampleSizeValue.

<table><caption>Tableau 10 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données ADNe</caption><thead><tr><th>occurrenceID</th><th>eventID</th><th>taxonID</th><th>scientificName</th><th>organismQuantity</th><th>organismQuantityType</th><th>kingdom</th><th>occurrenceStatus</th><th>basisOfRecord</th><th>target_gene</th><th>seq_meth</th></tr></thead><tbody><tr><td>occ100</td><td>replicate1</td><td></td><td>Anodonta anatina</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ101</td><td>replicate1</td><td></td><td>Anodonta cygnea</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ102</td><td>replicate1</td><td></td><td>Anodonta exulcerata</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ103</td><td>replicate1</td><td></td><td>Corbicula sp.</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ104</td><td>replicate1</td><td></td><td>Corbicula fluminalis</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ105</td><td>replicate1</td><td></td><td>Dreissena polymorpha</td><td>423107</td><td>DNA sequence reads</td><td>animalia</td><td>present</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ106</td><td>replicate1</td><td></td><td>Dreissena rostriformis bugensis</td><td>46834</td><td>DNA sequence reads</td><td>animalia</td><td>present</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ107</td><td>replicate1</td><td></td><td>Euglesa casertana</td><td>4241</td><td>DNA sequence reads</td><td>animalia</td><td>present</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ108</td><td>replicate1</td><td></td><td>Euglesa compressa</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ10...</td><td>replicate1</td><td></td><td>...</td><td>...</td><td>...</td><td>animalia</td><td>...</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ201</td><td>replicate2</td><td></td><td>Anodonta anatina</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ202</td><td>replicate2</td><td></td><td>Anodonta cygnea</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ203</td><td>replicate2</td><td></td><td>Anodonta exulcerata</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ204</td><td>replicate2</td><td></td><td>Corbicula sp.</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ205</td><td>replicate2</td><td></td><td>Corbicula fluminalis</td><td></td><td></td><td>animalia</td><td>absent</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ206</td><td>replicate2</td><td></td><td>Dreissena polymorpha</td><td>239202</td><td>DNA sequence reads</td><td>animalia</td><td>present</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ207</td><td>replicate2</td><td></td><td>Dreissena rostriformis bugensis</td><td>48716</td><td>DNA sequence reads</td><td>animalia</td><td>present</td><td>MaterialSample</td><td></td><td></td></tr><tr><td>occ20...</td><td>replicate2</td><td></td><td>...</td><td>...</td><td>...</td><td>animalia</td><td>...</td><td>MaterialSample</td><td></td><td></td></tr></tbody></table>

La liste des 44 occurrences d'espèces recherchées et associée à chaque évènement d'échantillonnage (replicate1 et replicate2) est standardisée à l'aide de la classe Occurrence (tableau 10). Le nom scientifique de chaque espèce est standardisé par le terme scientificName, le nombre de lectures machine de chaque espèce est standardisé par les termes organismQuantity et organismQuantityType en indiquant la valeur « DNA sequence reads » tel que préconisé par le guide GBIF. Toujours selon les recommandations du GBIF, il est fortement recommandé de renseigner les termes target_gene et seq_meth, issus de l'extension « DNA derived data » que l'on peut ici directement inclure à l'occurrence. Le règne est standardisé par le terme correspondant kingdom. De plus, pour chaque occurrence doivent être renseignés les termes obligatoires basisOfRecord (permettant de signifier que cette occurrence est issue d'un échantillon matériel (MaterialSample)) et occurrenceStatus, très important pour ce jeu de données afin d'indiquer si l'espèce est présente ou absente.

## 5.2. Tables de standardisation du SOT V3.0 pour le jeu de données ADNe

<figure><img src="image_30.png" /><figcaption>Figure 22 : Étape intermédiaire de schématisation des éléments du jeu de données ADNe.</figcaption></figure>

La figure 22 présente l'identification par code couleurs des concepts à utiliser et les principales informations à standardiser (et leur correspondances SOT V3.0).
<table><caption>Tableau 11 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données ADNe</caption><thead><tr><th>idSinpEvenement</th><th>idSinpRegroupement</th><th>idOrigineEvenement</th><th>idSinpJdd</th><th>organisme</th><th>dateEvenement</th><th>typeLocalisation</th><th>Y</th><th>X</th><th>codeEPSG</th><th>statutSource</th></tr></thead><tbody><tr><td>replicat1</td><td>site1</td><td>SPY1600673</td><td></td><td>CNR</td><td>05/04/2016</td><td>5</td><td>46.144235</td><td>5.963902</td><td>4326</td><td>Te</td></tr><tr><td>replicat2</td><td>site1</td><td>SPY1600674</td><td></td><td>CNR</td><td>05/04/2016</td><td>5</td><td>46.144217</td><td>5.964059</td><td>4326</td><td>Te</td></tr></tbody></table>

L'échantillon (réplicat) est standardisé comme un évènement (tableau 11) avec sa date, le contributeur (attribut observateur (organisme)), l'identifiant d'origine de l'évènement (idOrigineEvenement) qui est ici compris comme le numéro du kit (Kit#), les coordonnées de l'échantillon sont standardisées grâce aux attributs de localisationEvenement. L'attribut statutSource, qui est obligatoire, est renseigné avec le code « Te » correspondant à la valeur « terrain » de la nomenclature liée à l'attribut. L'attribut idSinpJdd est mis en évidence en rouge car c'est un attribut obligatoire du standard SOT pour lequel il n'y a pas de valeur dans le jeu de données.

<table><caption>Tableau 12 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données ADNe.</caption><thead><tr><th>idSinpRegroupement</th><th>idOrigineRegroupement</th><th>typeRegroupement</th><th>typeLocalisation</th><th>codeLocalisation</th><th>anneeRef</th><th>nomLocalisation</th><th>estRegroupementParent</th></tr></thead><tbody><tr><td>site1</td><td>1</td><td>site d'échantillonnage</td><td></td><td></td><td></td><td>Pont de Pougny</td><td>false</td></tr></tbody></table>

<table><caption>Tableau 13 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données ADNe.</caption><thead><tr><th>idSinpRegroupement</th><th>idSinpEvenement</th><th>idSinpSujetObs</th><th>nomAttributAdd</th><th>definitionAttributAdd</th><th>valeurAttributAdd</th><th>uniteAttributAdd</th></tr></thead><tbody><tr><td>site1</td><td></td><td></td><td>BV</td><td>Bassin-versant de la rivière dans laquelle ont été réalisés les évènements</td><td></td><td></td></tr><tr><td>site1</td><td></td><td></td><td>Rivière</td><td>Rivière dans laquelle ont été réalisés les évènements</td><td></td><td></td></tr><tr><td>site1</td><td></td><td></td><td>Commune</td><td>Commune</td><td>Pont de Pougny</td><td></td></tr><tr><td>site1</td><td></td><td></td><td>Etude</td><td>De quelle étude il s'agit (ex. inventaire du PNR du Limousin, Vigilife Rhône, Etude des mulettes par FNE...)</td><td>Vigilife Rhône</td><td></td></tr><tr><td>site1</td><td></td><td></td><td>Locality1</td><td>Nom de la localité telle que donnée par l'opérateur</td><td>1</td><td></td></tr><tr><td></td><td>replica1</td><td></td><td>replicate</td><td>Réplica terrain (R1, R2, ou seulement R1 quand il n'y a pas eu de réplica terrain)</td><td>R1</td><td></td></tr><tr><td></td><td>replica2</td><td></td><td>replicate</td><td>Réplica terrain (R1, R2, ou seulement R1 quand il n'y a pas eu de réplica terrain)</td><td>R2</td><td></td></tr><tr><td></td><td></td><td>sujetobs1</td><td>nombreLectures</td><td>Résultat du séquençage. Nombre de lectures de machine correspondant à l'espèce.</td><td>46834</td><td>Lectures de machine</td></tr><tr><td></td><td></td><td>sujetobs3</td><td>nombreLectures</td><td>Résultat du séquençage. Nombre de lectures de machine correspondant à l'espèce.</td><td>23374</td><td>Lectures de machine</td></tr></tbody></table>

Un échantillon est réalisé au sein d'un site d'échantillonnage, afin de retranscrire cette organisation, l'évènement de l'échantillon doit être lié à un regroupement d'évènements (le site d'échantillonnage). Au sein de ce concept (tableau 12), l'attribut typeRegroupement est obligatoire et est utilisé pour préciser que le regroupement est un site d'échantillonnage (facilite la compréhension en complément de l'idSinp, comme eventType dans le Darwin Core). L'attribut obligatoire estRegroupementParent permet d'indiquer si ce regroupement d'évènement est parent d'un autre regroupement, ce n'est pas le cas pour ce jeu de données. La standardisation est plus complexe pour la localisation du site. En effet, comme de nombreux champs du jeu de données concernent la localisation du site (Commune, BV, Rivière, Locality 1, ID) il faut choisir quelle information standardiser via les attributs de localisationRegroupement. Il a été choisi que l'attribut Commune serait le type de localisation indiqué (via attribut nomLocalisation) car la plus précise. Cependant les valeurs de ce champ ne correspondant pas à une commune référencée dans l'Insee il est alors impossible de renseigner les attributs obligatoires codeLocalisation et anneeRef qui lui sont lié, ce qui est bloquant pour l'intégration des données (mis en évidence en rouge). Le champ Commune doit donc être standardisé en attribut additionnel du regroupement comme les attributs BV, Rivière, Etude et Locality 1 (tableau 13). L'attribut ID est considéré ici comme l'idOrigineRegroupement. L'idSinpRegroupement est celui reporté dans l'évènement de l'échantillon pour faire le lien.
<table><caption>Tableau 14 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données ADNe</caption><thead><tr><td>idSinpSujetObs</td><td>idSinpEvenement</td><td>statutObservation</td><td>nomCite</td></tr></thead><tbody><tr><td>sujetobs100</td><td>replicat1</td><td>2</td><td>Anodonta anatina</td></tr><tr><td>sujetOb10..</td><td>replicat1</td><td>...</td><td>...</td></tr><tr><td>sujetobs200</td><td>replicat2</td><td>1</td><td>Anodonta anatina</td></tr><tr><td>sujetObs20..</td><td>replicat2</td><td>...</td><td>...</td></tr></tbody></table>

À un échantillon sont liées les abondances relatives de 44 espèces de bivalves d'eau douce (tableau 14). Le nom scientifique indiqué pour chaque espèce (champ reprenant le nom de l'espèce) est standardisé par l'attribut nomCite. L'attribut statutObservation est obligatoire et permet d'indiquer si le sujet observé est présent ou absent (code 2 correspondant à « présent » et code 1 correspondant à « absent »).

<table><caption>Tableau 15 : Table de standardisation des concepts facultatifs DescriptifSujet et Determination du SOT V3.0 pour le jeu de données ADNe</caption><thead><tr><td>idSinpDescriptif</td><td>idSinpSujetObs</td><td>objetDenombrement</td><td>denombrementMin</td><td>denombrementMax</td></tr></thead><tbody><tr><td>descriptif1</td><td>sujetObs1</td><td></td><td>46834</td><td>46834</td></tr><tr><td>descriptif2</td><td>sujetObs2</td><td></td><td>23374</td><td>23374</td></tr></tbody></table>

<table><thead><tr><td>idSinpDetermination</td><td>idSinpSujetObs</td><td>dateDetermination</td><td>methodeDetermination</td></tr></thead><tbody><tr><td>determination1</td><td>sujetObs1</td><td></td><td>605</td></tr><tr><td>determination2</td><td>sujetObs2</td><td></td><td>605</td></tr></tbody></table>

Pour l'abondance le concept DescriptifSujet et les attributs de Denombrement pourraient être utilisés (tableau 15 haut) cependant la nomenclature de l'attribut obligatoire objetDenombrement ne comprend pas de valeur qui correspondrait à des lectures de machine. Le nombre de lectures de machine doit donc être standardisé comme un attribut additionnel du SujetObservation. Dans l'objectif de mieux identifier ces données comme étant issues d'analyses génétiques, il est possible dans le standard SOT d'utiliser la valeur « génétique » (code 605) de la nomenclature liée à l'attribut methodeDetermination du concept Determination (tableau 15 bas). Cependant, l'attribut dateDetermination de ce même concept est obligatoire mais aucune information n'est disponible dans les données, il y a donc un blocage pour utiliser methodeDetermination.

## 5.3. Tables de standardisation du DwC pour le jeu de données LEDKOA
<figure><img src="image_31.png" /><figcaption>Tableau 16 : Table de standardisation de la classe Event du DwC pour le jeu de données LEDKOA</figcaption></figure>

Ce tableau représente la table de la classe Event du Darwin Core. Tous les évènements présentés dans le tableau 16 sont reportés dans cette table. Le terme eventType permet de savoir à quel évènement du modèle conceptuel correspond chaque enregistrement. Le terme eventRemarks permet de préciser que des évènements ne sont pas liés directement à des occurrences, seuls les évènements d'observation n'ont pas cette précision et sont donc liés à des occurrences. Pour identifier une session de survol ont standardise son numéro (fieldNumber) ainsi que la période sur laquelle elle se déroule (eventDate). Un transect à l'identifiant de la session (eventID) pour parentEventID, un numéro (fieldNumber), puis des informations géographiques (ici le transect est utilisé comme porteur des informations géographiques (où se trouve le transect ?)). Un effort a pour parentEventID l'identifiant du transect, un identifiant unique au jeu de données (fieldNumber), un horodatage et une localisation précise. Ces mêmes informations sont reportées pour chaque évènement d'observation.

<table><caption>Tableau 17 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données LEDKOA</caption><thead><tr><td>occurrenceID</td><td>parentEventID</td><td>taxonID</td><td>parentUsageNameID</td><td>individualCount</td><td>organismQuantity</td><td>organismQuantityType</td><td>organismScope</td><td>vernacularName</td><td>scientificName</td><td>family</td><td>basisOfRecord</td><td>occurrenceStatus</td></tr></thead><tbody><tr><td>occ1</td><td>obs1</td><td>60939</td><td>196139</td><td>1</td><td>1</td><td>individual</td><td></td><td>Harbour porpoise</td><td>Phocoena phocoena</td><td>Phocoenidae</td><td>HumanObservation</td><td>present</td></tr><tr><td>occ2</td><td>obs3</td><td>60776</td><td>193036</td><td>2</td><td>2</td><td>individual</td><td>pod</td><td>Grey seal (Atlantic seal)</td><td>Halichoerus grypus</td><td>Phocidae</td><td>HumanObservation</td><td>present</td></tr></tbody></table>

Le tableau 17 présente la table de la classe Occurrence. Dans cette table sont standardisées les informations sur l'observation, ce qui a été observé (organismScope, vernacularName, scientificName, family, parentUsageNameID (cdNom TaxRef)) et sa quantité (individualCount, organismQuantity, organismQuantityType). Les termes basisOfRecord et occurrenceStatus sont obligatoires ou fortement recommandés et utilisés pour tous les jeux de données de cet exercice. basisOfRecord permet d'indiquer que l'observation est d'origine humaine (contrairement à une machine par exemple) et que le taxon renseigné est bien présent (et non absent, lorsque recherché). Dans le cas d'observations opportunistes telles que dans ce suivi, la valeur d'occurrenceStatus sera toujours « present ».
<table><caption>Tableau 18 : Table de standardisation de l'extensions MoF du DwC pour le jeu de données LEDKOA</caption><thead><tr><td>measurementID</td><td>parentMeasurementID</td><td>eventID</td><td>occurrenceID</td><td>measurementType</td><td>measurementValue</td><td>measurementUnit</td></tr></thead><tbody><tr><td>meas1:Session1</td><td></td><td>Session1</td><td></td><td>cycle</td><td>I</td><td></td></tr><tr><td>meas2:session1</td><td></td><td>Session1</td><td></td><td>computer</td><td>B</td><td></td></tr><tr><td>meas3:session1</td><td></td><td>Session1</td><td></td><td>strate</td><td>N3</td><td></td></tr><tr><td>meas4:session1</td><td></td><td>Session1</td><td></td><td>surveyName</td><td>DunkRisk_1(1)</td><td></td></tr><tr><td>meas1:effort1</td><td></td><td>Effort1</td><td></td><td>status</td><td>BEGIN</td><td></td></tr><tr><td>meas2:effort1</td><td></td><td>Effort1</td><td></td><td>legLenKm</td><td>3.73981683999583</td><td>kilometers</td></tr><tr><td>meas3:effort1</td><td></td><td>Effort1</td><td></td><td>subjective</td><td>MM</td><td></td></tr><tr><td>meas4:effort1</td><td></td><td>Effort1</td><td></td><td>seaState</td><td>3</td><td></td></tr><tr><td>meas1:obs1</td><td></td><td>Obs1</td><td></td><td>routeType</td><td>LEG</td><td></td></tr><tr><td>meas1:obs3</td><td></td><td>Obs3</td><td></td><td>routeType</td><td>TRANSIT</td><td></td></tr><tr><td>meas1:obs4</td><td></td><td>Obs4</td><td></td><td>otherObjectName</td><td>Fishing buoy, setnet</td><td></td></tr><tr><td>meas2:obs4</td><td></td><td>Obs4</td><td></td><td>otherObjectCode</td><td>BUOY</td><td></td></tr><tr><td>meas3:obs4</td><td></td><td>Obs4</td><td></td><td>otherObjetActivity</td><td>Fishing activity</td><td></td></tr><tr><td>meas4:obs4</td><td></td><td>Obs4</td><td></td><td>otherObjectFrenchName</td><td>Bouée de pêche</td><td></td></tr><tr><td>meas5:obs4</td><td></td><td>Obs4</td><td></td><td>otherObjectKind</td><td>Buoy</td><td></td></tr><tr><td>meas6:obs4</td><td></td><td>Obs4</td><td></td><td>otherObjectQuantity</td><td>1</td><td></td></tr><tr><td>meas7:obs4</td><td></td><td>Obs4</td><td></td><td>routeType</td><td>CIRCLE BACK</td><td></td></tr><tr><td>meas1:occ1</td><td></td><td></td><td>occ1</td><td>taxon</td><td>Marine mammal</td><td></td></tr><tr><td>meas2:occ1</td><td></td><td></td><td>occ1</td><td>species</td><td>PHOPHO</td><td></td></tr><tr><td>meas3:occ1</td><td></td><td></td><td>occ1</td><td>taxonFr</td><td>Mammifère marin</td><td></td></tr><tr><td>meas4:occ1</td><td></td><td></td><td>occ1</td><td>familyFr</td><td>Phocoenidae</td><td></td></tr><tr><td>meas5:occ1</td><td></td><td></td><td>occ1</td><td>nameFr</td><td>Marsouin commun</td><td></td></tr></tbody></table>

Le tableau 18 présente toutes les informations contenues dans le jeu de données qui ont été standardisées en tant que MeasurementOrFact. L'identifiant de l'évènement ou de l'occurrence auquel elles sont rattachées est reportée dans cette table grâce aux termes eventID et occurrenceID. Toujours lorsque l'on utilise le Darwin Core, tout le texte est traduit en anglais (l'unité, la valeur).

Cependant, cette solution n'est réalisable qu'en théorie. En effet, bien que leur renseignement soit en texte libre, les libellés des termes organismQuantity et organismQuantityType - de même que leur définition dans le standard - rendent leur utilisation incohérente pour une observation autre qu'un taxon. En effet, le libellé des termes du DwC utilisés pour cette standardisation est taxon-orienté (« organism », « individual », « vernacularName », « scientificName »). Une proposition serait de les renommer avec des libellés plus génériques comme « subject » ou « quantity ».
<caption>Tableau 19 : Tableau des codes des objets observés utilisé dans le programme LEDKOA</caption>

CODES AUTRES OBJETS

<table><thead><tr><th>CODE</th><th>Name</th><th>activity</th><th>French name</th><th>Kind</th></tr></thead><tbody><tr><td>BOAT</td><td>Non identified ship</td><td></td><td>Bateau non identifié</td><td>Ship</td></tr><tr><td>ADMIBO</td><td>Administrative boat (navy, custom, coast guard)</td><td>Administrative vessel</td><td>Bateau de l'Etat (douanes, marine)</td><td>Ship</td></tr><tr><td>RESCUB</td><td>Rescue vessel</td><td>Administrative vessel</td><td>Bateau de secours</td><td>Ship</td></tr><tr><td>RESEBO</td><td>Research vessel</td><td>Service</td><td>Navire scientifique</td><td>Ship</td></tr><tr><td>SERVBO</td><td>service boat (wind farm, port...)</td><td>Service</td><td>Bateau de maintenance, service</td><td>Ship</td></tr><tr><td>CARGOB</td><td>Merchant ship ind.</td><td>Transport</td><td>Bateau transport marchandise</td><td>Ship</td></tr><tr><td>CONTBO</td><td>containership</td><td>Transport</td><td>Porte container</td><td>Ship</td></tr><tr><td>BULKBO</td><td>Bulk ship</td><td>Transport</td><td>Vraquier (granulat, céréales..)</td><td>Ship</td></tr><tr><td>TANKER</td><td>Gaz, oil ship</td><td>Transport</td><td>Pétrolier, chimiquier, gazier</td><td>Ship</td></tr><tr><td>FERRYB</td><td>Ferry</td><td>Transport</td><td>Ferry</td><td>Ship</td></tr><tr><td>CRUIBO</td><td>Cruise ship</td><td>Transport</td><td>Bateau de croisière</td><td>Ship</td></tr><tr><td>MOTOBO</td><td>Small motor boat</td><td>Recreational boating</td><td>Bateau à petit moteur</td><td>Ship</td></tr><tr><td>PLEABO</td><td>Non identified Pleasure boat</td><td>Recreational boating</td><td>Bateau de plaisance ind.</td><td>Ship</td></tr><tr><td>SAILBO</td><td>Sailing boat</td><td>Recreational boating</td><td>Bateau de plaisance à voile</td><td>Ship</td></tr><tr><td>FISHBO</td><td>Fishing boat (professional)</td><td>Fishing activity</td><td>Bateau de pêche pro</td><td>Ship</td></tr><tr><td>TRAWLB</td><td>Trawler</td><td>Fishing activity</td><td>Bateau chalutier</td><td>Ship</td></tr><tr><td>PATRAB</td><td>Pair trawler</td><td>Fishing activity</td><td>Bateau chalutier en boeuf</td><td>Ship</td></tr><tr><td>SEINBO</td><td>Seiner</td><td>Fishing activity</td><td>Bateau senneur, bolincheur</td><td>Ship</td></tr><tr><td>PASSBO</td><td>Boat using for Passive fishing gear unidentified</td><td>Fishing activity</td><td>Bateau art dormant ind. (fileyeur, caseyeur)</td><td>Ship</td></tr><tr><td>NETBO</td><td>Gill-netter</td><td>Fishing activity</td><td>Bateau fileyeur</td><td>Ship</td></tr><tr><td>CANOBO</td><td>Small traditional fishing boat</td><td>Fishing activity</td><td>Petit bateau de pêche artisanale</td><td>Ship</td></tr><tr><td>POTBO</td><td>Pot vessel</td><td>Fishing activity</td><td>Bateau caseyeur</td><td>Ship</td></tr><tr><td>LONGBO</td><td>Longliner</td><td>Fishing activity</td><td>Bateau palangrier</td><td>Ship</td></tr><tr><td>BUOY</td><td>Fishing buoy, setnet</td><td>Fishing activity</td><td>Bouée de pêche</td><td>Buoy</td></tr><tr><td>FISHFA</td><td>Fishing farm</td><td>Fishing activity</td><td>Ferme aquacole</td><td>Other</td></tr></tbody></table>

<table><tbody><tr><td>TRASH</td><td>Non identified Trash</td><td></td><td>Déchet non déterminé</td><td>Trash</td></tr><tr><td>PLASTR</td><td>Plastic trash</td><td></td><td>Déchet plastique</td><td>Trash</td></tr><tr><td>FISHTR</td><td>Fishing trash (net part, rope, adrift buoy...)</td><td></td><td>Déchet de pêche (filet, bout, bouée à la dérive)</td><td>Trash</td></tr><tr><td>POLYTR</td><td>Polystyrene trash</td><td></td><td>Dechet polystyrene</td><td>Trash</td></tr><tr><td>IRONTR</td><td>Iron or Metal trash</td><td></td><td>Déchet en fer ou métal</td><td>Trash</td></tr><tr><td>OIL</td><td>Oil slick</td><td></td><td>Déchet hydrocarbure (nappe)</td><td>Trash</td></tr><tr><td>WOODTR</td><td>Unnatural wood</td><td></td><td>Déchet bois (non naturel)</td><td>Trash</td></tr></tbody></table>

La tableau 19 présente les différents champs correspondant à une observation d'objet.

## 5.4. Tables de standardisation du SOT V3.0 pour le jeu de données LEDKOA

<table><caption>Tableau 20 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données LEDKOA</caption><thead><tr><th>idSinpRegroupement</th><th>typeRegroupement</th><th>idOrigineRegroupement</th><th>estRegroupementParent</th><th>idRegroupementParent</th></tr></thead><tbody><tr><td>regroupSession1</td><td>Regrouper tous les transects survolés lors d'une session ainsi que les observations réalisées hors transect</td><td>DunkRisk_1(5) ou 5</td><td>true</td><td></td></tr><tr><td>regroupTransect001</td><td>Regrouper tous les efforts et observations pour un même transect (lors d'une session)</td><td>N3/208</td><td>false</td><td>regroupSession1</td></tr></tbody></table>

Cette première table (tableau 20) présente la standardisation des informations dans le concept RegroupementEvenements. Deux types de regroupements sont nécessaires pour standardiser ce jeu de données, un regroupement par session de survol (regroupe les transects et les évènements d'observation hors transect) et un regroupement par transect (regroupe les évènements d'effort et d'observation réalisés lors du survol d'un transect). Pour cet exercice, l'identifiant unique SINP du regroupement (idSinpRegroupement), qui selon les règles du standard devrait être un UUID, a été simplifié dans cet exercice pour faciliter la compréhension de la standardisation. La numérotation 1 ou 001 en fin d'identifiant indique de que multiples regroupements par
session et regroupements par transect sont possibles (autant qu'il y en a de renseigner dans le jeu de données). Par soucis de lisibilité seuls deux exemples sont présentés dans cet exercice. L'identifiant d'origine renseigné dans le jeu de données est standardisé tel quel par l'attribut idOrigineRegroupement. Cet attribut permet un retour facilité vers les données. Les attributs estRegroupementParent et idRegroupementParent permettent l'imbrication de regroupements d'évènements. Cette fonctionnalité est utilisée pour regrouper tous les regroupements d'observations par transect (regroupTransect001) dans la même session de survol (regroupSession1, estRegroupementParent = true) en reportant l'identifiant unique (idSinpRegroupement) en valeur de l'attribut idRegroupementParent.

<table><caption>Tableau 21 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données LEDKOA</caption><thead><tr><th>idSinpEvenement</th><th>idOrigineEvenement</th><th>idSinpRegroupement</th><th>idSinpIdd</th><th>statutSource</th><th>evenementSansObservation</th><th>dateExacte</th><th>heureDebut</th><th>heureFin</th><th>heureExacte</th><th>typeLocalisation</th><th>Y</th><th>X</th><th>codeEPSG</th><th>commentaireEvenement</th></tr></thead><tbody><tr><td>event1</td><td>S102-15-B</td><td>regroupTransect001</td><td></td><td>Te</td><td>false</td><td>2018-03-07</td><td></td><td></td><td>06:42:34</td><td>5</td><td>51.29337</td><td>1.522095</td><td>4326</td><td>Observation liée à un transect d'une espèce</td></tr><tr><td>event2</td><td>S3-15-B</td><td>regroupSession1</td><td></td><td>Te</td><td>false</td><td>2018-03-07</td><td></td><td></td><td>06:27:53</td><td>5</td><td>51.05767</td><td>1.79294833333</td><td>3</td><td>Observation hors transect d'une espèce</td></tr><tr><td>event4</td><td>obsHorsTransect1</td><td>regroupSession1</td><td></td><td>Te</td><td>false</td><td>2018-03-07</td><td></td><td></td><td>06:27:53</td><td>5</td><td>51.05767</td><td>1.79294833333</td><td>3</td><td>Observation hors transect d'un objet</td></tr><tr><td>event3</td><td>L1-15-B</td><td>regroupTransect001</td><td></td><td>Te</td><td>true</td><td>2018-03-07</td><td>07:24:36</td><td>07:25:34</td><td></td><td>5</td><td>50.98223666667</td><td>1.871785</td><td>4326</td><td>Effort d'observation pour un transect (LEG)</td></tr></tbody></table>

Présentés dans le tableau 21, trois types d'évènements sont nécessaires pour standardiser le jeu de données : les observations réalisées dans un transect (rattachées au regroupement d'évènements transect), les observations réalisées hors transect (rattachées au regroupement d'évènements session) et les efforts d'observation (rattachés au regroupement transect). Les identifiants d'origine des observations et effort sont standardisés dans l'attribut idOrigineEvenement et l'identifiant du regroupement est reporté dans l'attribut idSinpRegroupement. L'identifiant du jeu de données qui est obligatoire est bloquant pour l'intégration des données en base s'il n'est pas renseigné c'est pour cela qu'il est mis en évidence en rouge. Pour l'intégration de données dans la base de gestion du SINP il faut toujours créer les métadonnées du jeu de données (et donc créer un identifiant SINP) avant de standardiser le jeu de données. Une localisation précise et une date sont standardisées pour chaque type d'évènement. Pour les observations l'horodatage est exact (dateExacte) alors que pour l'effort l'horodatage est une période (heureDebut et heureFin). Le standard SOT permet d'indiquer si un évènement est sans observations (sans sujet d'observation) grâce à l'attribut evenementSansObservation. Il est très utile pour indiquer qu'aucun enregistrement de SujetObservation n'est lié à un effort (le lien entre un effort et les observations réalisées pendant cet effort n'est pas indiqué dans le jeu de données, le lien se fait alors avec l'horodatage et l'identifiant de transect). L'attribut statutSource est un attribut obligatoire du concept Evenement et permet d'indiquer que l'évènement est issu du terrain (et non pas de la littérature par exemple).

<table><caption>Tableau 22 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données LEDKOA</caption><thead><tr><th>idSinpSujetObs</th><th>idSinpEvenement</th><th>statutObservation</th><th>cdNom</th><th>nomCite</th></tr></thead><tbody><tr><td>sujetobs1</td><td>event1</td><td>2</td><td>60939</td><td>Phocoena phocoena</td></tr><tr><td>sujetobs2</td><td>event2</td><td>2</td><td>60776</td><td>Phoque gris</td></tr></tbody></table>

Ainsi à chaque évènement d'observation est liée un sujet d'observation pour ce jeu de données une espèce ou un objet (tableau 22). Les observations d'espèce sont standardisées par le concept SujetObservation. À chaque fois, les attributs obligatoires statutObservation (présent (code 2) ou absent (code 1)) et nomCite (nom du sujet observé, généralement nom vernaculaire pour les espèces) sont utilisés. De même que les attributs d'identification idSinpSujetObs et idSinpEvenement (fait le lien entre le sujet d'observation et l'évènement d'observation). Pour l'espèce est ajouté l'attribut cdNom (identifiant unique du taxon dans le référentiel TaxRef).
<table><caption>Tableau 23 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données LEDKOA</caption><thead><tr><td>idSinpDescriptif</td><td>idSinpSujetObs</td><td>objetDenombrement</td><td>methodeDenombrement</td><td>denombrementMin</td><td>denombrementMax</td></tr></thead><tbody><tr><td>descriptif1</td><td>sujetObs1</td><td>IND</td><td>Co</td><td>7</td><td>7</td></tr><tr><td>descriptif2</td><td>sujetobs2</td><td>IND</td><td>Co</td><td>1</td><td>1</td></tr></tbody></table>

Le dénombrement des espèces observées sont standardisées par le concept DescriptifSujet dont la table de standardisation est présentée dans le tableau 23.

Le reste des informations du jeu de données, non standardisées par des attributs et concepts prédéfinis du standard sont standardisées en tant qu'attribut additionnel (tableau 24).

<table><caption>Tableau 24 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données LEDKOA</caption><thead><tr><td>idSinpEvenement</td><td>idSinpSujetObs</td><td>idSinpRegroupement</td><td>nomAttributAdd</td><td>definitionAttributAdd</td><td>valeurAttributAdd</td><td>uniteAttributAdd</td></tr></thead><tbody><tr><td></td><td>sujetobs1</td><td></td><td>taxon</td><td>Groupe taxonomique de l'espèce observée</td><td>Mammifere marin</td><td></td></tr><tr><td></td><td>sujetobs1</td><td></td><td>famille</td><td>Famille ou sous-famille de l'espèce observée</td><td>Phocoenidae</td><td></td></tr><tr><td></td><td>sujetobs1</td><td></td><td>Cd_taxsup</td><td>Code TAXREF d'un rang taxonomique supérieur à l'espèce</td><td>196139</td><td></td></tr><tr><td></td><td>sujetobs1</td><td></td><td>nomFr</td><td>Nom français de l'espèce observée</td><td>Marsouin commun</td><td></td></tr><tr><td></td><td>sujetobs1</td><td></td><td>Species</td><td>Code espèce de l'observation</td><td>PHOPHO</td><td></td></tr><tr><td>event1</td><td></td><td></td><td>routeType</td><td>Type de trajet. LEG = en effort, Circle_back et TRANSIT = hors effort d'observation</td><td>CIRCLE_BACK</td><td></td></tr><tr><td>event2</td><td></td><td></td><td>routeType</td><td>Type de trajet. LEG = en effort, Circle_back et TRANSIT = hors effort d'observation</td><td>TRANSIT</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>nomAutreObjet</td><td>Nom de l'objet observé en français</td><td>Bouée de pêche</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>codeAutreObjet</td><td>Autre type d'objets observés qui ne sont pas des taxons (bateaux, déchets, bouée, etc.)</td><td>BUOY</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>quantiteAutreObjet</td><td>Quantité de codeAutreObjet</td><td>1</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>nomAutreObjetEng</td><td>Nom anglais de l'objet</td><td>Fishing buoy, setnet</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>activiteFr</td><td>Activité lié à l'objet en français</td><td>activité de pêche</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>activiteEng</td><td>Activité lié à l'objet en anglais</td><td>Fishing activity</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>typeAutreObjet</td><td>Type d'objet</td><td>Bouée</td><td></td></tr><tr><td>event4</td><td></td><td></td><td>routeType</td><td>Type de trajet. LEG = en effort, Circle_back et TRANSIT = hors effort d'observation</td><td>TRANSIT</td><td></td></tr><tr><td>event3</td><td></td><td></td><td>routeType</td><td>Type de trajet. LEG = en effort, Circle_back et TRANSIT = hors effort d'observation</td><td>LEG</td><td></td></tr><tr><td>event3</td><td></td><td></td><td>computer</td><td>Identifiant du système sur lequel le vol est effectué</td><td>B</td><td></td></tr><tr><td>event3</td><td></td><td></td><td>status</td><td>Statut du point de parcours. BEGIN= Debut du parcours; ADD= changement de conditions; END= fin du parcours</td><td>ADD</td><td></td></tr><tr><td>event3</td><td></td><td></td><td>legLengKm</td><td>Longueur du LEG (effort) en kilomètres</td><td>3.73981683999583</td><td>kilomètres</td></tr><tr><td>event3</td><td></td><td></td><td>seaState</td><td>Code pour l'état de la mer selon l'échelle de Beaufort</td><td>3</td><td></td></tr><tr><td>event3</td><td></td><td></td><td>subjective</td><td>Détectabilité(Estimation des observateurs en fonction des autres paramètres si les conditions sont bonnes ou non). 1er pour le côté gauche, 2e pour le droit: E=excellentes, G=bonnes, M=moyennes et P=pauvres</td><td>GM</td><td></td></tr><tr><td></td><td>regroupTransect001</td><td></td><td>Strate</td><td>Strate d'échantillonnage</td><td>N3</td><td></td></tr></tbody></table>

Comme pour le DwC, la standardisation des observations d'objet n'est possible qu'en théorie avec le SOT V3.0. En effet, l'attribut nomCite est renseigné par du texte libre ce qui permettrait en théorie de renseigner un nom d'objet mais la définition de l'attribut vise uniquement les taxons. Donc, pour rester cohérent avec les règles du standard cette standardisation n'est pas possible. Toutes les informations portant sur l'observation d'un objet sont alors standardisées en attribut additionnel d'un évènement d'observation d'objet comme le montre le tableau 24.

## 5.5. Tables de standardisation du DwC pour le jeu de données ASPE
<figure><img src="image_32.png" /><figcaption>Figure 23 : Étape intermédiaire de schématisation de l'organisation des éléments du jeu de données ASPE.</figcaption></figure>

La figure 23 présente une des étapes préliminaires au modèle conceptuel de données. Elle correspond à la figure 11 mais les éléments sont présentés de façon différente. Aussi, à cette étape, les boîtes qui correspondront aux éléments à standardiser sont colorées selon le code couleur des classes et concepts utilisé pour cet exercice.

<table><caption>Tableau 25 : Table de standardisation de la classe Event du DwC pour le jeu de données ASPE</caption><thead><tr><th>eventID</th><th>parentEventID</th><th>fieldNumber</th><th>locationID</th><th>waterBody</th><th>stateProvince</th><th>country</th><th>municipality</th><th>decimalLatitude</th><th>decimalLongitude</th><th>geodeticData</th><th>eventDate</th><th>samplingProtocol</th><th>verbatimLocality</th><th>samplingSize</th><th>samplingValue</th><th>Type</th><th>eventRemarks</th></tr></thead><tbody><tr><td>station1</td><td></td><td></td><td>4613007</td><td></td><td>Centre-Val-de-Loire</td><td>Inde-Loire</td><td>Beaumont-La-Ronce</td><td></td><td></td><td></td><td></td><td></td><td>R DEME A LOUESTAULT</td><td></td><td></td><td>site</td><td>No occurrences</td></tr><tr><td>samplingPoint1</td><td>station1</td><td>6</td><td>La Délme</td><td></td><td></td><td></td><td></td><td>6728114.00000000</td><td>524028.00000000</td><td>2154</td><td></td><td></td><td></td><td>Point de la D29 - Lieu-dit Moque-Souris</td><td></td><td></td><td>point</td><td>No occurrences</td></tr><tr><td>operation1</td><td>samplingPoint1</td><td>90170</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>12/10/23</td><td>Pêche complète à un ou plusieurs passages</td><td></td><td></td><td></td><td>operation</td><td>No occurrences</td></tr><tr><td>operationSession1</td><td>operation1</td><td>1</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>351.00</td><td>m²</td><td>Observation session</td><td></td></tr></tbody></table>

Le tableau 25 présente la table de standardisation de la classe Event. On y retrouve les quatre types d'évènements (précisé par eventType): station1 (traduit en site car c'est une appellation plus commune en anglais pour ce type d'évènement), samplingPoint1, operation1, operationSession1 (prélèvement élémentaire). Les identifiants uniques sont suffixés par une numérotation pour indiquer que plusieurs instances de chaque évènement est possible (en fonction des informations renseignées dans le jeu de données). On ajoute une précision sur l'existence ou non d'occurrences associées à l'évènement avec le terme eventRemarks. L'identifiant unique d'origine (locationID), le nom et des informations géographiques supérieures sont rattachées à la station. L'identifiant unique d'origine (locationID), le nom et les informations géographiques précises (coordonnées) sont associées au point de prélèvement (samplingPoint). L'identifiant unique d'origine (fieldNumber), la date et le protocole mis en œuvre sont associés à l'opération. Enfin, l'identifiant unique d'origine (fieldNumber) et la surface échantillonnée (sampling size and value) sont rattachée au prélèvement élémentaire (operationSession).
<table><caption>Tableau 26 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données ASPE</caption><thead><tr><th>occurrenceID</th><th>parentOccurrenceID</th><th>eventID</th><th>catalogNumber</th><th>recordNumber</th><th>basisOfRecord</th><th>occurrenceStatus</th><th>taxonID</th><th>nameAccordingTo</th><th>vernacularName</th><th>individualCount</th></tr></thead><tbody><tr><td>batch1</td><td></td><td>operationSession1</td><td>5648513</td><td>1</td><td>HumanObservation</td><td>present</td><td>67778</td><td>TaxRef</td><td>River trout (riverine ecotype)</td><td>1</td></tr><tr><td>batch2</td><td></td><td>operationSession1</td><td>5648575</td><td>63</td><td>HumanObservation</td><td>present</td><td>67550</td><td>TaxRef</td><td>Stone loach</td><td>3</td></tr><tr><td>batch3</td><td></td><td>operationSession1</td><td>5648569</td><td>57</td><td>HumanObservation</td><td>present</td><td>67404</td><td>TaxRef</td><td>Common minnow</td><td>158</td></tr><tr><td>batch1/ind1</td><td>batch1</td><td></td><td>22483116</td><td></td><td>HumanObservation</td><td>present</td><td>67778</td><td>TaxRef</td><td>River trout (riverine ecotype)</td><td>1</td></tr><tr><td>batch2/ind1</td><td>batch2</td><td></td><td>22483352</td><td></td><td>HumanObservation</td><td>present</td><td>67550</td><td>TaxRef</td><td>Stone loach</td><td>1</td></tr><tr><td>batch2/ind2</td><td>batch2</td><td></td><td>22483353</td><td></td><td>HumanObservation</td><td>present</td><td>67550</td><td>TaxRef</td><td>Stone loach</td><td>1</td></tr><tr><td>batch2/ind3</td><td>batch2</td><td></td><td>22483354</td><td></td><td>HumanObservation</td><td>present</td><td>67550</td><td>TaxRef</td><td>Stone loach</td><td>1</td></tr><tr><td>batch3/ind1</td><td>batch3</td><td></td><td>22483172</td><td></td><td>HumanObservation</td><td>present</td><td>67404</td><td>TaxRef</td><td>Common minnow</td><td>1</td></tr><tr><td>...</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>batch3/ind68</td><td>batch3</td><td></td><td>22483355</td><td></td><td>HumanObservation</td><td>present</td><td>67404</td><td>TaxRef</td><td>Common minnow</td><td>1</td></tr></tbody></table>

Le tableau 26 présente les occurrences liées à chaque évènements (voir tableau 25). Pour chaque prélèvement élémentaire (identifiant de operationSession reporté dans eventID) sont standardisés l'identifiant unique d'origine du lot (catalogNumber), le numéro de lot (recordNumber), les informations sur le taxon (noms scientifique et vernaculaire, identifiant dans le référentiel TaxRef) ainsi que le nombre d'individu composant le lot (individualCount). Les termes obligatoires basisOfRecord et occurrenceStatus sont renseignés pour toutes les occurrences avec les informations présence et observation humaine. Les mesures des individus sont également standardisées en tant qu'occurrences (batch1/ind1). Le lien entre le lot et l'individu est possible grâce au report de l'identifiant de l'occurrence du lot dans le terme parentOccurrenceID pour chaque occurrence d'individu du lot. Dans cette figure sont représentées les 68 occurrences « individu » du lot 1 (batch1). Pour chaque occurrence « individu » sont renseignés l'identifiant unique d'origine (catalogNumber), les informations sur le taxon comme pour le lot ainsi que le dénombrement (toujours 1 pour une occurrence « individu »).

<table><caption>Tableau 27 : Table de standardisation de l'extension MoF du DwC pour le jeu de données ASPE</caption><thead><tr><th>measurementID</th><th>eventID</th><th>occurrenceID</th><th>measurementType</th><th>measurementValue</th><th>measurementUnit</th></tr></thead><tbody><tr><td>samplingPoint1/mea1</td><td>samplingPoint1</td><td></td><td>watershedName</td><td>Loire-Bretagne</td><td></td></tr><tr><td>samplingPoint1/mea2</td><td>samplingPoint1</td><td></td><td>watershedCode</td><td>M1345800</td><td></td></tr><tr><td>samplingPoint1/mea3</td><td>samplingPoint1</td><td></td><td>wamaCode</td><td>x</td><td></td></tr><tr><td>operation1/mea1</td><td>operation1</td><td></td><td>operationConfidentialityStatus</td><td>No</td><td></td></tr><tr><td>operation1/mea2</td><td>operation1</td><td></td><td>validationLevel</td><td>Validity level 1</td><td></td></tr><tr><td>operation1/mea3</td><td>operation1</td><td></td><td>dataQualification</td><td>correct</td><td></td></tr><tr><td>operation1/mea4</td><td>operation1</td><td></td><td>operationPurpose</td><td>RRP - Réseau de Référence Pérenne</td><td></td></tr><tr><td>operation1/mea5</td><td>operation1</td><td></td><td>taxonomicScope</td><td>x</td><td></td></tr><tr><td>batch1/mea1</td><td>batch1</td><td>batch1</td><td>batchType</td><td>N, I or S/L</td><td></td></tr><tr><td>batch1/mea1</td><td>batch1</td><td>batch1</td><td>fishingLineQuantity</td><td>1</td><td></td></tr><tr><td>batch1/mea1</td><td>batch1</td><td>batch1</td><td>batchWeight</td><td>36</td><td>grams</td></tr><tr><td>batch1/mea1</td><td>batch1</td><td>batch1</td><td>maximalFishSize</td><td>x</td><td>millimeters</td></tr><tr><td>batch1/mea1</td><td>batch1</td><td>batch1</td><td>minimalFishSize</td><td>x</td><td>millimeters</td></tr><tr><td>batch1/mea1</td><td>batch1</td><td>batch1</td><td>sizeType</td><td>total</td><td></td></tr><tr><td>batch1/mea1</td><td>batch1</td><td>batch1</td><td>alternateTaxonCode</td><td>TRF</td><td></td></tr><tr><td>Batch1/ind1/mea1</td><td>batch1/ind1</td><td>batch1</td><td>fishSize</td><td>162</td><td>millimeters</td></tr><tr><td>Batch1/ind1/mea2</td><td>batch1/ind1</td><td>batch1</td><td>realSizeMeasurement</td><td>yes</td><td></td></tr><tr><td>Batch1/ind1/mea3</td><td>batch1/ind1</td><td>batch1</td><td>fishWeight</td><td>x</td><td>grams</td></tr><tr><td>Batch1/ind1/mea4</td><td>batch1/ind1</td><td>batch1</td><td>fishPathology</td><td>no</td><td></td></tr><tr><td>Batch3/ind68/mea1</td><td>batch3/ind68</td><td>batch3</td><td>fishSize</td><td>79</td><td>millimeters</td></tr><tr><td>Batch3/ind68/mea2</td><td>batch3/ind68</td><td>batch3</td><td>realSizeMeasurement</td><td>no</td><td></td></tr><tr><td>Batch3/ind68/mea3</td><td>batch3/ind68</td><td>batch3</td><td>fishWeight</td><td>x</td><td>grams</td></tr><tr><td>Batch3/ind68/mea4</td><td>batch3/ind68</td><td>batch3</td><td>fishPathology</td><td>no</td><td></td></tr></tbody></table>

La tableau 27 quant à lui présente toutes les informations standardisées en utilisant l'extension MeasurementOrFact pour le jeu de données ASPE. Le nom des champs, leur valeur et unité sont traduits en anglais si pertinent (le standard Darwin Core étant utilisé notamment par le GBIF qui est une base de données internationale).
## 5.6. Tables de standardisation du SOT V3.0 pour le jeu de données ASPE

<figure><img src="image_33.png" /><figcaption>Figure 5 : Résumé de la correspondance des données de pêche électrique vers OccTax</figcaption></figure>

Les **rectangles bleus** sont des concepts (et des concepts rattachés) de la pêche électrique (approchés dans ASPE ou Naïade).

Les **rectangles verts** sont des concepts SINP (OccTax, sauf mention contraire).

Les **flèches noires** → représentent des liens entre concepts au sein d'un SI.

Les **flèches bleues** → montrent comment faire la correspondance.

<caption>Figure 24 : Modèle conceptuel de la standardisation du jeu de données ASPE avec le standard OccTax V2.</caption>

La figure 24 présente le scénario d'échange qui avait été conceptualisé pour les jeux de données de pêche électrique par PatriNat en utilisant le standard OccTax V2¹⁷. La standardisation avec le SOT V3.0 se base sur cet exemple en adaptant les correspondances aux nouveautés de la dernière version du standard (ajout du concept Evenement par exemple).

<footnote n="17">¹⁷ https://inpn.mnhn.fr/docs-web/docs/download/271850</footnote>
<figure><img src="image_34.png" /><figcaption>Figure 25 : Étape intermédiaire dans la construction du modèle conceptuel du jeu de données ASPE avec le SOT V3.0.</figcaption></figure>

La figure 25 présente la schématisation des données du jeu de données ASPE selon la structure utilisée pour la standardisation avec OccTax V2 (voir figure 24). Cette schématisation a permis de comprendre quelles informations seraient standardisées avec le concept Evenement et de trouver la solution de standardisation (après plusieurs essais et versions) du lien entre le lot et les individus du lot. Cette étape c'est avérée clé dans le processus de standardisation du jeu de données.

<table><caption>Tableau 28 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données ASPE</caption><thead><tr><td>idSinpRegroupement</td><td>typeRegroupement</td><td>idOrigineRegroupement</td><td>estRegroupementParent</td></tr></thead><tbody><tr><td>regroupOperation</td><td>Opération de pêche complète</td><td>90170</td><td>false</td></tr></tbody></table>

Le tableau 28 présente la table de standardisation avec le concept RegroupementEvenements. Un seul regroupement est nécessaire pour standardiser efficacement l'organisation des données, le regroupement d'opération. L'identifiant unique d'origine de l'opération est standardisé dans idOrigineRegroupement et les attributs obligatoires typeRegroupement et estRegroupementParent sont renseignés, l'un pour expliciter la création de ce regroupement et l'autre pour indiquer que ce regroupement n'est pas parent d'autres regroupements.

<table><caption>Tableau 29 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données ASPE</caption><thead><tr><td>idSinpEvenement</td><td>idOrigineEvenement</td><td>idSinpRegroupement</td><td>idSinpJdd</td><td>statutSource</td><td>dateExacte</td><td>typeLocalisation</td><td>Y</td><td>X</td><td>codeEPSG</td><td>commentaireEvenement</td></tr></thead><tbody><tr><td>eventPrelevementEle</td><td>1</td><td>regroupOperation</td><td></td><td>Te</td><td>2023-10-12</td><td>5</td><td>6728114.00000000</td><td>524028.00000000</td><td>2154</td><td>Prélèvement élémentaire (passage)</td></tr></tbody></table>

Le tableau 29 présente la table de standardisation du concept Evenement. Un évènement représente un prélèvement élémentaire (passage) effectué lors de l'opération on reporte donc l'identifiant SINP du regroupement dans l'évènement (idSinpRegroupement). Sont standardisés l'identifiant unique d'origine (idOrigineEvenement), la date de réalisation du prélèvement ainsi que les coordonnées précises du relevé. Les attributs obligatoires statutSource et idSinpJdd sont renseignés (Te = Terrain) sachant que le l'identifiant SINP du
jeu de données n'est pas disponible il est mis en évidence en rouge. Dans les faits d'une réelle standardisation cela serait bloquant pour l'intégration des données en base. Un commentaire sur l'évènement est précisé – ici pour préciser le type d'évènement.

<table><caption>Tableau 30 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données ASPE</caption><thead><tr><td>idSinpSujetObs</td><td>idSinpEvenement</td><td>statutObservation</td><td>idOrigineSujetObs</td><td>cdNom</td><td>nomCite</td></tr></thead><tbody><tr><td>sujetObsLot1</td><td>eventPrelevementEle</td><td>2</td><td>5648513</td><td>67778</td><td>Truite de rivière</td></tr><tr><td>sujetObsLot2</td><td>eventPrelevementEle</td><td>2</td><td>5648569</td><td>67404</td><td>Vairon</td></tr><tr><td>sujetObsLot3</td><td>eventPrelevementEle</td><td>2</td><td>5648575</td><td>67550</td><td>Loche franche</td></tr><tr><td>sujetObsInd1Lot1</td><td>eventPrelevementEle</td><td>2</td><td>22483116</td><td>67778</td><td>Truite de rivière</td></tr><tr><td>sujetObsInd3Lot2</td><td>eventPrelevementEle</td><td>2</td><td>22483354</td><td>67404</td><td>Vairon</td></tr><tr><td>sujetObsInd15Lot3</td><td>eventPrelevementEle</td><td>2</td><td>22483183</td><td>67550</td><td>Loche franche</td></tr><tr><td>sujetObsInd123Lot3</td><td>eventPrelevementEle</td><td>2</td><td>22483445</td><td>67550</td><td>Loche franche</td></tr></tbody></table>

Le tableau 30 présente la table de standardisation du concept SujetObservation. À chaque évènement de prélèvement élémentaire sont liées des observations soit de lot (idSinpSujetObs = sujetObsLotX) soit d'individus (idSinpSujetObs = sujetObsIndYLotX). Le lien entre chaque individu et son lot est standardisé par le report de l'identifiant SINP par l'attribut idSinpEvenement. L'attribut statutObservation est obligatoire et ici toujours renseigné avec le code 2 qui correspond à « présent ». L'identifiant unique d'origine de l'individu est standardisé par l'attribut idOrigineSujetObs et les informations sur le taxon (nom vernaculaire et identifiant dans le référentiel TaxRef) sont standardisés par les attributs nomCite et cdNom.

<table><caption>Tableau 31 : Table de standardisation du concept Interaction du SOT V3.0 pour le jeu de données ASPE</caption><thead><tr><td>idSinpSujetObs</td><td>idSinpSujetObsLie</td><td>typeInteraction</td></tr></thead><tbody><tr><td>sujetObsInd1Lot1</td><td>sujetObsLot1</td><td>21</td></tr><tr><td>sujetObsInd3Lot2</td><td>sujetObsLot2</td><td>21</td></tr><tr><td>sujetObsInd15Lot3</td><td>sujetObsLot3</td><td>21</td></tr><tr><td>sujetObsInd123Lot3</td><td>sujetObsLot3</td><td>21</td></tr></tbody></table>

Le tableau 31 présente la table de standardisation du concept Interaction. Dans cette table est reporté l'idSinp du sujet d'observation auquel on veut lier un autre sujet d'observation. L'identifiant SINP de cet autre sujet observation est reporté dans la table par l'utilisation de l'attribut idSinpSujetObsLie et le type d'interaction entre les deux sujets d'observation est standardisé par la nomenclature rattachée à l'attribut typeInteraction. Ici la valeur 21 correspond à « est associé à ». Ainsi, le lien entre un poisson et son lot peut être standardisé.
<table><caption>Tableau 32 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données ASPE</caption><thead><tr><td>idSinpDescriptif</td><td>idSinpSujetObs</td><td>objetDenombrement</td><td>methodeDenombrement</td><td>denombrementMin</td><td>denombrementMax</td></tr></thead><tbody><tr><td>descriptifLot1</td><td>sujetObsLot1</td><td>IND</td><td>Co</td><td>1</td><td>1</td></tr><tr><td>descriptifLot2</td><td>sujetObsLot2</td><td>IND</td><td>Co</td><td>158</td><td>158</td></tr><tr><td>descriptifLot3</td><td>sujetObsLot3</td><td>IND</td><td>Co</td><td>3</td><td>3</td></tr><tr><td>descriptifInd1Lot1</td><td>sujetObsInd1Lot1</td><td>IND</td><td>Co</td><td>1</td><td>1</td></tr><tr><td>descriptifInd3Lot2</td><td>sujetObsInd3Lot2</td><td>IND</td><td>Co</td><td>1</td><td>1</td></tr><tr><td>descriptifInd15Lot3</td><td>sujetObsInd15Lot3</td><td>IND</td><td>Co</td><td>1</td><td>1</td></tr><tr><td>descriptifInd123Lot3</td><td>sujetObsInd123Lot3</td><td>IND</td><td>Co</td><td>1</td><td>1</td></tr></tbody></table>

Le tableau 32 présente la table de standardisation du concept DescriptifSujet. Ce concept est utilisé pour standardiser les informations de dénombrement et de sexe des SujetObservation « lot » et « individu ». La valeur renseignée pour objetDenombrement est « IND » qui correspond à « individu » selon la nomenclature associée. La méthode de dénombrement, ici Co = compté, est renseignée ainsi que le minimum et le maximum d'individus ou de lots comptés. Pour un dénombrement exact (le lot contient 68 poissons) le même nombre est indiqué pour le min et le max.

<table><caption>Tableau 33 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données ASPE</caption><thead><tr><td>idSinpEvenement</td><td>idSinpSujetObs</td><td>idSinpDescriptif</td><td>idSinpRegroupement</td><td>nomAttributAdd</td><td>definitionAttributAdd</td><td>valeurAttributAdd</td><td>uniteAttributAdd</td></tr></thead><tbody><tr><td></td><td></td><td></td><td>regroupOperation</td><td>stationCodeSandre</td><td></td><td>4613007</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>stationNom</td><td></td><td>R DEME A LOUESTAULT</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>stationCommune</td><td></td><td>BEAUMONT-LA-RONCE</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>ptPrelevCodeSandre</td><td></td><td>6</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>ptPrelevCodeWama</td><td></td><td>x</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>ptPrelevBassinHydro</td><td></td><td>LOIRE-BRETAGNE</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>ptPrelevCodeEntiteHydro</td><td></td><td>M1345800</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>ptPrelevCoursDeau</td><td></td><td>la Dème</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>operationConidentielle</td><td></td><td>Non</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>operationObjectifPeche</td><td></td><td>RRP - Réseau de Référence Pérenne</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>operationEspeceCiblee</td><td></td><td>x</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>operationQualifDonnee</td><td></td><td>Correcte</td><td></td></tr><tr><td></td><td></td><td></td><td>regroupOperation</td><td>operationNiveauValidation</td><td></td><td>Validé niveau 1</td><td></td></tr><tr><td>eventPrelevementEle</td><td></td><td></td><td></td><td>prelevSurfaceEchant</td><td></td><td>351.00</td><td>mètres carré</td></tr><tr><td></td><td>sujetObsLot1</td><td></td><td></td><td>lotNumero</td><td></td><td>4</td><td></td></tr><tr><td></td><td>sujetObsLot1</td><td></td><td></td><td>lotType</td><td></td><td>N</td><td></td></tr><tr><td></td><td>sujetObsLot1</td><td></td><td></td><td>lotEffectifLigne</td><td></td><td>1</td><td></td></tr><tr><td></td><td>sujetObsLot1</td><td></td><td></td><td>lotPoids</td><td></td><td>36</td><td></td></tr><tr><td></td><td>sujetObsLot1</td><td></td><td></td><td>lotTailleMax</td><td></td><td>x</td><td>millimètres</td></tr><tr><td></td><td>sujetObsLot1</td><td></td><td></td><td>lotTailleMin</td><td></td><td>x</td><td>millimètres</td></tr><tr><td></td><td>sujetObsLot1</td><td></td><td></td><td>lotTypeLongueur</td><td></td><td>Totale</td><td></td></tr><tr><td></td><td>sujetObsLot1ind1</td><td></td><td></td><td>poissonTaille</td><td></td><td>162</td><td>millimètres</td></tr><tr><td></td><td>sujetObsLot1ind1</td><td></td><td></td><td>poissonMesureRelleTaille</td><td></td><td>Oui</td><td></td></tr><tr><td></td><td>sujetObsLot1ind1</td><td></td><td></td><td>poissonPoids</td><td></td><td>x</td><td>grammes</td></tr><tr><td></td><td>sujetObsLot1ind1</td><td></td><td></td><td>poissonPathologie</td><td></td><td>Non</td><td></td></tr></tbody></table>

Le tableau 33 présente la table de standardisation du concept AttributAdditionnel. Tous les champs qui ne sont pas standardisés par des attributs des concepts définis par le standard SOT V3.0 sont standardisés en tant
qu'attribut additionnel. Pour chacun le nom de l'attribut, sa définition, sa valeur et son unité doivent être renseignés. Dans cet exemple, la définition n'a pas été renseignée par soucis de lisibilité (les définitions - issues de la documentation officielle ASPE - pouvant être assez longues). Les informations géographiques - moins précises que les coordonnées renseignées pour l'évènement de prélèvement élémentaire - de la station et du point de prélèvement sont standardisées en attribut additionnel ainsi que certains codes spécifiques au jeu de données ou aux bases de gestion. Les informations sur l'opération telles que sa confidentialité, le niveau de qualification des données ou l'espèce ciblée sont standardisées en attribut additionnel. Les informations de mesure de taille et de poids des lots et des individus le sont également.

## 5.7. Tables de standardisation du DwC pour le jeu de données STOC-EPS

<table><caption>Tableau 34 : Table de standardisation de la classe Event du DwC pour le jeu de données STOC-EPS</caption><thead><tr><th>eventID</th><th>parentEventID</th><th>fieldNumber</th><th>eventDate</th><th>samplingProtocol</th><th>samplingEffort</th><th>verbatimElevation</th><th>decimalLongitude</th><th>decimalLatitude</th><th>geodeticDatum</th><th>Type</th><th>eventRemarks</th></tr></thead><tbody><tr><td>Square1</td><td></td><td>10295</td><td></td><td>STOC-EPS</td><td>5 minutes observation for maximum of 10 points in a 2km² square two times a year</td><td></td><td></td><td></td><td></td><td>square</td><td>No occurrences</td></tr><tr><td>Point1</td><td>square1</td><td>010295P01</td><td></td><td></td><td></td><td>228 meters</td><td>5,3005832432536</td><td>46,2795251160109</td><td>4326</td><td>point</td><td>No occurrences</td></tr><tr><td>participation1</td><td>point1</td><td>2002010295P01</td><td>2002</td><td></td><td></td><td></td><td></td><td></td><td></td><td>session</td><td></td></tr></tbody></table>

Le tableau 34 présente la table de standardisation de la classe Event. Un évènement pour le carré (Square1), le point (Point1) et pour la participation (participation1) sont créés. L'évènement de point est lié au carré en reportant l'eventID de l'évènement carré dans le terme parentEventID, de même entre la participation et le point. Les identifiants uniques d'origine de ces trois éléments sont standardisés par le terme fieldNumber. La date (année) est liée à la participation. Le nom du protocole et la description de l'effort d'échantillonnage sont standardisés par les termes samplingProtocol et samplingEffort. Les coordonnées du point et son altitude sont standardisées par les termes verbatimElevation, decimalLongitude, decimalLatitude et geodeticDatum. Les termes eventType et eventRemarks sont utilisés pour apporter des compléments d'information aidant à la compréhension des évènements créés. Par exemple, on précise qu'aucune occurrence n'est liée au évènements Square1 et Point1 à l'inverse de l'évènement participation1 comme le montre le tableau 35.

<table><caption>Tableau 35 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données STOC-EPS</caption><thead><tr><th>occurrenceID</th><th>eventID</th><th>individualCount</th><th>basisOfRecord</th><th>occurrenceStatus</th><th>scientificName</th><th>scientificNameAutorship</th><th>taxonID</th><th>nameAccordingTo</th></tr></thead><tbody><tr><td>occ1</td><td>participation1</td><td>3</td><td>HumanObservation</td><td>present</td><td>Buteo buteo</td><td>Linnaeus, 1758</td><td>2623</td><td>TaxRef</td></tr><tr><td>occ2</td><td>participation1</td><td>1</td><td>HumanObservation</td><td>present</td><td>Hirundo rustica</td><td>Linnaeus, 1758</td><td>3696</td><td>TaxRef</td></tr></tbody></table>

Le tableau 35 présente la table de standardisation de la table Occurrence. Pour la même participation (session d'écoute à une date donnée pour un point en particulier) de multiples occurrences - observations d'espèces - peuvent exister telle qu'une occurrence par espèce observée pendant la participation. Les termes scientificName, scientificNameAutorship, taxonID et nameAccordingTo sont utilisés pour standardiser les informations sur le taxon observé. Les termes basisOfRecord et occurrenceStatus sont obligatoires et permettent de renseigner que l'observation a été faite par un humain (sur le terrain) et que le taxon est présent (toujours le cas pour des observations opportunistes, non spécifiquement recherchées). Enfin, le terme individualCount permet de standardiser l'abondance de brute de chaque espèce.
<table><caption>Tableau 36 : Table de standardisation de l'extension MoF du DwC pour le jeu de données STOC-EPS</caption><thead><tr><td>measurementID</td><td>eventID</td><td>occurrenceID</td><td>measurementType</td><td>measurementValue</td></tr></thead><tbody><tr><td>meas1</td><td>square1</td><td></td><td>municipalityID</td><td>1</td></tr><tr><td>meas2</td><td>square1</td><td></td><td>countyID</td><td>1283</td></tr><tr><td>meas3</td><td>participation1</td><td></td><td>session1PrimaryHabitatCode</td><td>D02</td></tr><tr><td>meas4</td><td>participation1</td><td></td><td>session1PrimaryHabitat</td><td>Prairie non cultivée</td></tr><tr><td>meas5</td><td>participation1</td><td></td><td>session2PrimaryHabitatCode</td><td>E03</td></tr><tr><td>meas6</td><td>participation1</td><td></td><td>session2PrimaryHabitat</td><td>Bourg rural</td></tr><tr><td>meas7</td><td>participation1</td><td></td><td>session1SecondaryHabitatCode</td><td>B06</td></tr><tr><td>meas8</td><td>participation1</td><td></td><td>session1SecondaryHabitat</td><td>Coupe « à blanc »</td></tr><tr><td>meas9</td><td>participation1</td><td></td><td>session2SecondaryHabitatCode</td><td>A03</td></tr><tr><td>meas10</td><td>participation1</td><td></td><td>session2SecondaryHabitat</td><td>Forêt mixte</td></tr><tr><td>meas11</td><td></td><td>occ2</td><td>speciesCode</td><td>BUTBUT</td></tr></tbody></table>

Enfin, le tableau 36 présente la table de standardisation de l'extension MeasurementOrFact. Tous les champs non standardisés par des classes et termes définis par le standard Darwin Core le sont dans cette table. À l'occasion de la standardisation avec le Darwin Core, les libellés et les valeurs sont traduits en anglais (cela devrait être le cas pour la colonne measurementValue mais les valeurs correspondent à une nomenclature pour laquelle je ne suis pas certaine de la traduction).

## 5.8. Tables de standardisation du SOT V3.0 pour le jeu de données STOC-EPS

<table><caption>Tableau 37 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données STOC-EPS</caption><thead><tr><td>idSinpRegroupement</td><td>typeRegroupement</td><td>nomRegroupement</td><td>idOrigineRegroupement</td><td>estRegroupementParent</td><td>idRegroupementParent</td></tr></thead><tbody><tr><td>idSinpCarre</td><td>regroupe tous les points d'un carré</td><td>Carré</td><td>10100</td><td>true</td><td></td></tr><tr><td>idSinpPoint</td><td>Regroupe toutes les participations d'un point</td><td>Point</td><td>010100P01</td><td>false</td><td>idSinpCarre</td></tr></tbody></table>

Le tableau 37 présente la table de standardisation du concept RegroupementEvenements. Les attributs typeRegroupement et nomRegroupement sont des informations supplémentaires au données du jeu de données qui aident à la compréhension des regroupements créés. L'identifiant d'origine du regroupement, ici l'identifiant du carré et du point sont standardisés par l'attribut idOrigineRegroupement. Le lien entre le regroupement « carré » et le regroupement « point » est standardisé par les attributs estRegroupementParent (on indique oui ou non) et idRegroupementParent pour faire le lien avec les identifiant unique SINP.

<table><caption>Tableau 38 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données STOC-EPS</caption><thead><tr><td>idSinpEvenement</td><td>idOrigineEvenement</td><td>idSinpRegroupement</td><td>idSinpJdd</td><td>statutSource</td><td>dateExacte</td><td>typeLocalisation</td><td>Y</td><td>X</td><td>codeEPSG</td><td>altitudeMin</td><td>altitudeMax</td></tr></thead><tbody><tr><td>idSinpParticipation</td><td>2007010100P01</td><td>idSinpPoint</td><td></td><td>Te</td><td>2008</td><td>5</td><td>46,1661933292989</td><td>5,33185781156003</td><td>4326</td><td>235</td><td>235</td></tr></tbody></table>

Le tableau 38 présente la table de standardisation du concept Evenement. Pour un enregistrement de données un seul enregistrement est à créer, celui de la participation. L'évènement « participation » est lié au regroupement « point » en reportant l'idSinpRegroupement dans l'évènement. L'identifiant unique d'origine de la participation est standardisé par l'attribut idOrigineEvenement. L'attribut obligatoire statutSource est renseigné avec le code Te correspondant à la valeur « terrain ». La date exacte correspond à l'année pour laquelle les participations du point ont été regroupées. Les autres attributs permettent de standardiser les informations sur les coordonnées du point et son altitude. Les coordonnées du point sont standardisées dans le concept Evenement car selon les règles du standard c'est l'évènement qui porte l'information de localisation précise.
<table><caption>Tableau 39 : Table de standardisation du concept LienHabitats du SOT V3.0 pour le jeu de données STOC-EPS</caption><thead><tr><td>idSinpEvenement</td><td>nomHabCite</td><td>codeHabCite</td><td>nomTypologie</td><td>versionTypologie</td><td>versionHabRef</td><td>estMosaique</td></tr></thead><tbody><tr><td>idSinpParticipation</td><td>D02</td><td>Prairie non cultivée</td><td>Les codes habitat -STOC-EPS</td><td></td><td></td><td>false</td></tr><tr><td>idSinpParticipation</td><td>D02</td><td>Prairie non cultivée</td><td>Les codes habitat -STOC-EPS</td><td></td><td></td><td>false</td></tr><tr><td>idSinpParticipation</td><td>B06</td><td>Coupe « à blanc »</td><td>Les codes habitat -STOC-EPS</td><td></td><td></td><td>false</td></tr><tr><td>idSinpParticipation</td><td>A03</td><td>Forêt mixte</td><td>Les codes habitat -STOC-EPS</td><td></td><td></td><td>false</td></tr></tbody></table>

Le tableau 39 présente la table de standardisation du concept LienHabitats pour lequel les attributs obligatoires versionTypologie et versionHabRef n'ont pas de champ correspondant dans le standard et sont donc mis en évidence en rouge. Le libellé et le code de l'habitat cités dans le jeu de données sont standardisés par les attributs nomHabCite et codeHabCite. L'attribut estMosaique est obligatoire et permet d'indiquer si oui ou non les habitats forme une mosaïque d'habitat (pour plus d'information sur la mosaïque d'habitats lire le standard SOT V3.0).

<table><caption>Tableau 40 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données STOC-EPS</caption><thead><tr><td>idSinpSujetObs</td><td>idSinpEvenement</td><td>statutObservation</td><td>cdNom</td><td>nomCite</td></tr></thead><tbody><tr><td>idSinpObs</td><td>idSinpParticipation</td><td>2</td><td>3696</td><td>x</td></tr></tbody></table>

Le tableau 40 quant à lui présente la table de standardisation du concept SujetObservation. À chaque évènement « participation » est liée au moins une observation d'espèce. Dans le jeu de données seule l'information du cdNom est renseignée. Aucune information n'existe pour renseigner l'attribut obligatoire nomCite, ce qui sera bloquant en vue d'une bancarisation dans le SINP. L'attribut obligatoire statutObservation est renseigné avec le code « 2 » qui correspond à la valeur « présent ».

<table><caption>Tableau 41 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données STOC-EPS</caption><thead><tr><td>idSinpSujetObs</td><td>objetDenombrement</td><td>methodeDenombrement</td><td>denombrementMin</td><td>denombrementMax</td></tr></thead><tbody><tr><td>idSinpObs</td><td>IND</td><td>Co</td><td>4</td><td>4</td></tr></tbody></table>

Le tableau 41 présente la table de standardisation du concept DescriptifSujet. À chaque sujet observation (espèce) est associé un dénombrement. L'attribut objetDenombrement permet d'indiquer que des individus sont dénombrés (code IND). L'attribut methodeDenombrement permet d'indiquer que ce dénombrement a été compté (code Co) et les attribut denombrementMin et denombrementMax servent à standardiser l'abondance brute.

<table><caption>Tableau 42 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données STOC-EPS</caption><thead><tr><td>idSinpEvenement</td><td>idSinpSujetObs</td><td>idSinpRegroupement</td><td>nomAttributAdd</td><td>definitionAttributAdd</td><td>valeurAttributAdd</td><td>uniteAttributAdd</td></tr></thead><tbody><tr><td></td><td>idSinpObs</td><td></td><td>codeSp</td><td>Code de l'espèce selon le protocole STOC-EPS</td><td>HIRRUS</td><td></td></tr><tr><td></td><td></td><td>idSinpCarre</td><td>departement</td><td>Numéro du département</td><td>1</td><td></td></tr></tbody></table>

Enfin, le tableau 42 présente la table de standardisation du concept AttributAdditionnel. Les deux champs du jeu de données - Code_sp et Departement - non standardisés par des attributs et concepts définis dans le standard le sont grâce à ce concept.

## 5.9. Tables de standardisation du DwC pour le jeu de données Vigie-Chiro
<table><caption>Tableau 43 : Table de standardisation de la classe Event du DwC pour le jeu de données protocole point fixe Vigie-Chiro</caption><thead><tr><th>eventID</th><th>parentEventID</th><th>year</th><th>eventDate</th><th>samplingProtocol</th><th>decimalLongitude</th><th>decimalLatitude</th><th>coordinateUncertaintyInMeters</th><th>geodeticDatum</th><th>fieldNumber</th><th></th><th>eventType</th><th>eventRemarks</th></tr></thead><tbody><tr><td>square1</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>3405791</td><td>square</td><td>No occurrences</td><td></td></tr><tr><td>square1point1</td><td>square1</td><td></td><td></td><td></td><td>3.5707980394363</td><td>43.644709061177</td><td>25</td><td>4326</td><td>Z1</td><td>point</td><td>No occurrences</td><td></td></tr><tr><td>55dddbc0fdfe23000c79dd3a</td><td>square1point1</td><td>2018</td><td></td><td>Vigie-Chiro All night fixed point</td><td></td><td></td><td></td><td></td><td></td><td>session</td><td>No occurrences</td><td></td></tr><tr><td>night1</td><td>55dddbc0fdfe23000c79dd3a</td><td></td><td>2018-07-02</td><td></td><td></td><td></td><td></td><td></td><td></td><td>observation</td><td></td><td></td></tr></tbody></table>

Le tableau 43 présente la table de standardisation de la classe Event. On retrouve les quatre évènements qui constituent le jeu de données. Pour chaque évènement un eventID est donné à titre d'exemple en revanche pour la participation l'identifiant renseigné dans le jeu de données est repris car c'est un identifiant unique universel (UUID). Le terme parentEventID permet de standardiser le lien entre les évènements. Pour le carré (square1) seul sont identifiant unique du jeu de données est standardisé (terme fieldNumber). Les coordonnées du point, la précision de ces coordonnées et son identifiant unique dans le jeu de données sont standardisés. L'évènement de participation porte les informations sur le protocole mis en œuvre (samplingProtocol) et l'année du suivi. Pour chaque nuit (Night1) seule la date est standardisée par la classe Event. Les termes eventType et eventRemarks sont ajoutés pour aider à la compréhension des évènements créés.

<table><caption>Tableau 44 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données protocole point fixe Vigie-Chiro</caption><thead><tr><th>eventID</th><th>occurrenceID</th><th>vernacularName</th><th>scientificName</th><th>organismQuantity</th><th>organismQuantityType</th><th>basisOfRecord</th><th>occurrenceStatus</th><th>recordedBy</th><th>recordedByID</th></tr></thead><tbody><tr><td>night1</td><td>occ1</td><td>Barbastelle d'Europe</td><td>Barbastella barbastellus</td><td>1</td><td>Identification over 50 % confidence</td><td>machineObservation</td><td>present</td><td>Miss A</td><td>000acd059.....000e0793ee</td></tr><tr><td>night1</td><td>occ2</td><td>Serotine commune</td><td>Eptesicus serotinus</td><td>6</td><td>Identification over 50 % confidence</td><td>machineObservation</td><td>present</td><td>Miss A</td><td>000acd059.....000e0793ee</td></tr></tbody></table>

Le tableau 44 présente la table de standardisation de la classe Occurrence. Toutes les observations d'espèces sont standardisées dans cette table, elles peuvent liées à une même nuit ou à des nuits différentes, dans cette figure les occurrences d'une seule nuit sont représentées. Ne sont dénombrées que les identifications pour lesquelles le pourcentage de bonne identification (par le programme d'identification automatique) est supérieur à 50 (organismQuantity, organismQuantityType). Les noms vernaculaires et scientifique de l'espèce sont standardisés par les termes vernacularName et scientificName. Dans le jeu de données des informations sur la personne ayant enregistré la participation (identité et identifiant unique) sont renseignées. Elles sont standardisées par les termes recordedBy et recordedByID (les valeurs ont été anonymisées). Les termes obligatoires basisOfRecord et occurrenceStatus permettent de standardiser l'information que l'observation a été réalisée par une machine (l'enregistreur) et que l'espèce est présente (utile dans le cas d'espèce recherchée mais non trouvée).