# Test d'applicabilité des standards d'échange Darwin Core et SOT V3.0 aux données de surveillance de la biodiversité

Chloé Vinet, Guillaume Body

► To cite this version:

Chloé Vinet, Guillaume Body. Test d'applicabilité des standards d'échange Darwin Core et SOT V3.0 aux données de surveillance de la biodiversité. PatriNat (OFB-CNRS-MNHN-IRD). 2024. mnhn-05145092

HAL Id: mnhn-05145092

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

Submitted on 4 Jul 2025

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

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

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

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

PATRINAT

CENTRE D'EXPERTISE ET DE DONNÉES
OFB-MNHN-CNRS-IRD

# Test d'applicabilité des standards d'échange Darwin Core et SOT V3.0 aux données de surveillance de la biodiversité

Chloé Vinet, Guillaume Body

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

<figure><img src="image_8.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_9.png" /></figure>

RÉPUBLIQUE
FRANÇAISE

Liberté
Égalité
Fraternité

OFB
OFFICE FRANÇAIS
DE LA BIODIVERSITÉ

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

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

IRD
Institut de Recherche
pour le Développement
FRANCE

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 d'applicabilité des standards d'échange Darwin Core et SOT V3.0 aux données de surveillance de la biodiversité. PatriNat (OFB-MNHN-CNRS-IRD). 66 p.
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_12.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><tr><td>2.4. Jeu de données n°4 : STOC-EPS (points d'écoute)</td><td>27</td></tr><tr><td>2.4.1. Standardisation du jeu de données STOC-EPS avec le Darwin Core</td><td>27</td></tr><tr><td>2.4.2. Standardisation du jeu de données STOC-EPS avec SOT V3.0</td><td>28</td></tr><tr><td>2.5. Jeu de données n°5 : Vigie-Chiro (contacts acoustiques)</td><td>30</td></tr><tr><td>2.5.1. Standardisation du jeu de données Vigie-Chiro avec le Darwin Core</td><td>30</td></tr><tr><td>2.5.2. Standardisation du jeu de données Vigie-Chiro avec SOT V3.0</td><td>31</td></tr><tr><td>3. Résumé des forces et faiblesses des standards</td><td>32</td></tr><tr><td>3.1. Forces des deux standards</td><td>32</td></tr><tr><td>3.2. Faiblesses du Darwin Core</td><td>33</td></tr><tr><td>3.3. Faiblesses du SOT V3.0</td><td>33</td></tr><tr><td>4. Discussion</td><td>34</td></tr><tr><td>4.1. Réflexions sur la standardisation des jeux de données issus de techniques ADNe</td><td>34</td></tr><tr><td>4.2. Darwin Core ou SOT V3.0 ?</td><td>35</td></tr><tr><td>4.3. Perspectives d'évolution du Darwin Core et recommandations d'utilisation</td><td>36</td></tr><tr><td>4.4. Perspectives d'évolution du SOT V3.0 et recommandations d'utilisation</td><td>36</td></tr><tr><td>5. Conclusion</td><td>36</td></tr><tr><td>6. Annexes</td><td>37</td></tr><tr><td>6.1. Tables de standardisation du jeu de données ADNe avec le Darwin Core</td><td>37</td></tr><tr><td>6.2. Tables de standardisation du jeu de données ADNe avec le SOT V3.0</td><td>38</td></tr><tr><td>6.3. Tables de standardisation du jeu de données LEDKOA avec le Darwin Core</td><td>40</td></tr><tr><td>6.4. Tables de standardisation du jeu de données LEDKOA avec le SOT V3.0</td><td>42</td></tr><tr><td>6.5. Tables de standardisation du jeu de données ASPE avec le Darwin Core</td><td>44</td></tr><tr><td>6.6. Tables de standardisation du jeu de données ASPE avec le SOT V3.0</td><td>46</td></tr></table>
6.7. Tables de standardisation du jeu de données STOC-EPS avec le Darwin Core .................................................. 51

6.8. Tables de standardisation du jeu de données STOC-EPS avec le SOT V3.0 .................................................. 52

6.9. Tables de standardisation du jeu de données Vigie-Chiro avec le Darwin Core .................................................. 53

6.10. Tables de standardisation du jeu de données Vigie-Chiro avec le SOT V3.0 .................................................. 55

Table des figures

Figure 1 : Schéma de l'organisation "en étoile" des classes du standard Darwin Core .................................................. 9

Figure 2 : Schéma général du standard SOT V3.0. Présentation des concepts et des liens entre eux. .................................................. 10

Figure 3 : Modèle conceptuel générique de l'organisation d'un jeu de données de biodiversité avec le DwC. .................................................. 11

Figure 4 : Modèle conceptuel générique de l'organisation d'un jeu de données de biodiversité par le SOT V3.0. .................................................. 12

Figure 5 : Schéma de l'organisation générale des données. Pour chaque échantillon, l'abondance relative des espèces de bivalves est recherchée. .................................................................................................................. 15

Figure 6 : modèle conceptuel de la standardisation de l'organisation des données par le standard Darwin Core. .................................................. 16

Figure 7 : modèle conceptuel de la standardisation de l'organisation des données par le standard SOT V3.0. .................................................. 17

Figure 8 : Schématisation de l'organisation des éléments du suivi réalisé dans le cadre du projet LEDKOA. .................................................. 19

Figure 9 : Modèle conceptuel du jeu de données LEDKOA avec le DwC. .................................................................................................................. 20

Figure 10 : Modèle conceptuel du jeu de données LEDKOA avec le DwC et proposition d'évolution. .................................................. 21

Figure 11 : Modèle conceptuel du jeu de données LEDKOA avec le SOT V3.0. .................................................................................................................. 22

Figure 12 : Schématisation de l'organisation des éléments du jeu de données ASPE. .................................................................................................................. 24

Figure 13 : Modèle conceptuel du jeu de données ASPE avec le DwC. .................................................................................................................. 24

Figure 14 : Modèle conceptuel du jeu de données ASPE avec le SOT V3.0. .................................................................................................................. 26

Figure 15 : Schématisation de l'organisation des éléments du jeu de données STOC-EPS. .................................................................................................................. 27

Figure 16 : Modèle conceptuel du jeu de données STOC-EPS avec le DwC. .................................................................................................................. 28

Figure 17 : Modèle conceptuel du jeu de données STOC-EPS avec le SOT V3.0. .................................................................................................................. 29

Figure 18 : Schématisation de l'organisation des éléments du jeu de données protocole point fixe Vigie-Chiro. .................................................. 30

Figure 19 : Modèle conceptuel du jeu de données protocole point fixe Vigie-Chiro avec le DwC. .................................................. 30

Figure 20 : Modèle conceptuel du jeu de données protocole point fixe Vigie-Chiro avec le SOT V3.0. .................................................. 31

Figure 21 : Modèle conceptuel des standards Darwin Core et SOT V3.0. .................................................................................................................. 32

Figure 22 : Étapes intermédiaires de schématisation de l'organisation des données du jeu de données ADNe. .................................................. 37

Figure 23 : Étape intermédiaire de schématisation des éléments du jeu de données ADNe. .................................................................................................................. 38

Figure 24 : Étape intermédiaire de schématisation de l'organisation des éléments du jeu de données ASPE. .................................................. 44

Figure 25 : Modèle conceptuel de la standardisation du jeu de données ASPE avec le standard OccTax V2. .................................................. 47

Figure 26 : Étape intermédiaire dans la construction du modèle conceptuel du jeu de données ASPE avec le SOT V3.0. .................................................. 48

Table des tableaux

Tableau 1 : Tables de standardisation génériques des classes, extensions et termes du standard DwC. .................................................. 12

Tableau 2 : Tables de standardisation génériques des concepts et attributs du SOT V3.0. .................................................. 13

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. .................................................................................................................. 15

Tableau 4 : Extrait du jeu de données LEDKOA. .................................................................................................................. 18

Tableau 5 : enregistrement d'observation d'activités humaines lors de la campagne DunkRisk (LEDKOA) .................................................. 19

Tableau 6 : Extrait du jeu de données ASPE. .................................................................................................................. 24

Tableau 7 : Extrait du jeu de données STOC-EPS. .................................................................................................................. 27

Tableau 8 : Extrait du jeu de données protocole point fixe Vigie-Chiro. .................................................................................................................. 30

Tableau 9 : Table de standardisation de la classe Event du DwC pour le jeu de données ADNe. .................................................. 37

Tableau 10 : Table de standardisation de l'extension MoF du DwC pour le jeu de données ADNe. .................................................. 37

Tableau 11 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données ADNe. .................................................. 38

Tableau 12 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données ADNe. .................................................. 39

Tableau 13 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données ADNe. .................................................. 39

Tableau 14 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données ADNe. .................................................. 39
<table><tr><td>Tableau 15 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données ADNe</td><td>40</td></tr><tr><td>Tableau 16 : Table de standardisation des concepts facultatifs DescriptifSujet et Determination du SOT V3.0 pour le jeu de données ADNe</td><td>40</td></tr><tr><td>Tableau 17 : Table de standardisation de la classe Event du DwC pour le jeu de données LEDKOA</td><td>40</td></tr><tr><td>Tableau 18 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données LEDKOA</td><td>41</td></tr><tr><td>Tableau 19 : Table de standardisation de l'extensions MoF du DwC pour le jeu de données LEDKOA</td><td>41</td></tr><tr><td>Tableau 20 : Proposition de standardisation de la table occurrence prenant en compte les observations autres que taxons et modification de la table MoF en conséquence</td><td>42</td></tr><tr><td>Tableau 21 : Tables de standardisation des concepts RegroupementEvenements, Evenement, SujetObservation et DescriptifSujet du SOT V3.0 pour le jeu de données LEDKOA</td><td>43</td></tr><tr><td>Tableau 22 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données LEDKOA</td><td>44</td></tr><tr><td>Tableau 23 : Table de standardisation de la classe Event du DwC pour le jeu de données ASPE</td><td>45</td></tr><tr><td>Tableau 24 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données ASPE</td><td>45</td></tr><tr><td>Tableau 25 : Table de standardisation de l'extension MoF du DwC pour le jeu de données ASPE</td><td>46</td></tr><tr><td>Tableau 26 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données ASPE</td><td>48</td></tr><tr><td>Tableau 27 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données ASPE</td><td>48</td></tr><tr><td>Tableau 28 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données ASPE</td><td>49</td></tr><tr><td>Tableau 29 : Table de standardisation du concept Interaction du SOT V3.0 pour le jeu de données ASPE</td><td>49</td></tr><tr><td>Tableau 30 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données ASPE</td><td>50</td></tr><tr><td>Tableau 31 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données ASPE</td><td>50</td></tr><tr><td>Tableau 32 : Table de standardisation de la classe Event du DwC pour le jeu de données STOC-EPS</td><td>51</td></tr><tr><td>Tableau 33 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données STOC-EPS</td><td>51</td></tr><tr><td>Tableau 34 : Table de standardisation de l'extension MoF du DwC pour le jeu de données STOC-EPS</td><td>52</td></tr><tr><td>Tableau 35 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données STOC-EPS</td><td>52</td></tr><tr><td>Tableau 36 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données STOC-EPS</td><td>52</td></tr><tr><td>Tableau 37 : Table de standardisation du concept LienHabitats du SOT V3.0 pour le jeu de données STOC-EPS</td><td>53</td></tr><tr><td>Tableau 38 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données STOC-EPS</td><td>53</td></tr><tr><td>Tableau 39 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données STOC-EPS</td><td>53</td></tr><tr><td>Tableau 40 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données STOC-EPS</td><td>53</td></tr><tr><td>Tableau 41 : Table de standardisation de la classe Event du DwC pour le jeu de données protocole point fixe Vigie-Chiro</td><td>54</td></tr><tr><td>Tableau 42 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données protocole point fixe Vigie-Chiro</td><td>54</td></tr><tr><td>Tableau 43 : Table de standardisation de l'extension MoF du DwC pour le jeu de données protocole point fixe Vigie-Chiro</td><td>55</td></tr><tr><td>Tableau 44 : Table de standardisation du concept RegroupementEvenements du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td><td>56</td></tr><tr><td>Tableau 45 : Table de standardisation du concept Evenement du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td><td>56</td></tr><tr><td>Tableau 46 : Table de standardisation du concept SujetObservation du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td><td>56</td></tr><tr><td>Tableau 47 : Table de standardisation du concept DescriptifSujet du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td><td>56</td></tr><tr><td>Tableau 48 : Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données protocole point fixe Vigie-Chiro</td><td>57</td></tr></table>
# Préambule

Cette étude s'inscrit au sein des réflexions nationales et européennes sur l'amélioration de la prise en compte des données issues de dispositifs de surveillance de la biodiversité par les systèmes d'informations sur la biodiversité existants. Ce travail a été réalisé au cours du premier semestre 2024. Les versions des standards utilisées sont celles qui étaient en vigueur en février 2024. De ce fait, tout élément de réflexion et discussion, notamment ceux exposés en partie 4 sont à replacer dans ce contexte. Ce travail pourra toutefois être révisé dans une version ultérieure en prenant en compte les dernières évolutions de standards testés.

Le jeu de données LEDKOA (partie 2.2) ayant été retravaillé le plus récemment car étant un cas d'usage très intéressant, des différences dans l'approche et l'application de la standardisation de ce jeu, par rapport aux autres jeux testés, peuvent exister.

# 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="2" /> 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.

De plus, Biodiversa+<fnref n="3" /> 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 interopérabilité. 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 interopérables 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 ni trier ni altérer cette information.* La

<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="2">2 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="3">³ Silva del Pozo Michelle, Body Guillaume, Rerig Gaby, Basille Mathieu. (2023). Guide on harmonising biodiversity monitoring protocols across scales. Biodiversa+ report. 60 pp.</footnote>
standardisation des jeux de données ne garantit pas leur interopérabilité et harmonisation scientifique, elle ne s'intéresse qu'à leur interopérabilité 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.).

## 1.3. Objectif du rapport

Dans ce rapport, nous avons effectué un exercice de standardisation des données issues de différents dispositifs de surveillance. Nous avons testé pour cela deux standards importants : le standard de données international Darwin Core<fnref n="4" /> et le standard d'échange de données national français Observations et Suivis de Taxons V3.0⁵. Nous partageons des recommandations et des bonnes pratiques de standardisation ainsi qu'une réflexion sur la coexistence de ces deux standards 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="6" />.

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.3.1. Le standard Darwin Core

Le Darwin Core (abrégé DwC dans la suite du rapport et utilisé de manière générale comme incluant l'occurrence core, l'event core et toutes autres extensions) 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

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

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

<footnote n="5">⁵ https://inpn.mnhn.fr/docs-web/docs/download/421824</footnote>

<footnote n="6">⁶ 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>
développement de standards sur les données de biodiversité (Biodiversity Information Standards -TDWG-), dont le Darwin Core, 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.

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 pour cause de 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.3.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 définis 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 SINP 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 données du GBIF collectées sur le territoire français (utilisation du format SOT V3.0).

<figure><img src="image_14.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>
## 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="7" /> et appliqué dans les rapports d'Enetwild<fnref n="8" />,<fnref n="9" />.

Le code couleur appliqué aux classes du DwC utilisé dans les rapports d'Enetwild<fnref n="9" />,¹⁰ est également repris, en le déclinant aux autres classes du standard utilisées (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).

<figure><img src="image_15.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 une 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é. Dans ce rapport, l'organisation des éléments du modèle conceptuel pour le DwC sera toujours présentée selon 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 (février 2024). Elle comprend les ajouts des termes proposés par De Pooter et al (2017) – version extendedMeasurementOrFact - et

<footnote n="7">⁷ 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="8">⁸ 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="9">⁹ 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>
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></tbody></table><table><thead><tr><th>measurementID</th><th>eventID</th><th>occurrenceID</th><th>parentMeasurementID</th><th>term5</th><th>eventID</th><th>occurrenceID</th><th>term3</th></tr></thead><tbody><tr><td>value</td><td></td><td>value</td><td>value</td><td>value</td><td>value</td><td>value</td><td>value</td></tr></tbody></table>

Le tableau 1 présente les tables de standardisation génériques 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.

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

<figure><img src="image_16.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 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></table><table><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></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><table><thead><tr><th>idSinpEvenement</th><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><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 la standardisation des données - 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 pour l'enregistrement considéré - est mis en évidence en rouge.

L'attribut idSinpJdd (concept Evenement) sera toujours mis en évidence en rouge dans cet exercice pour la standardisation avec le standard SOT V3.0. En effet, cette information requiert d'avoir préalablement standardisé 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.

Les cardinalités (nombre de fois qu'une instance d'un concept ou d'une classe peut être utilisée) du lien (flèche, voir figure 4) entre deux concepts ne sont pas représentées sauf exception 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.

### 1.4.1. Informations générales sur la méthode de standardisation appliquée

Lors d'un exercice de standardisation plusieurs configurations (organisation des éléments du standard) 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 parcourt des transects dans lesquels plusieurs points peuvent être prospectés.

Seule la configuration qui nous a semblé la plus appropriée pour représenter l'organisation des données du jeu étudié est présentée dans ce rapport. 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. Ces tables, liées entre elles par des 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 standardisation 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ée 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 ;

- un évènement (classe Event du Darwin Core et concept Evenement du SOT V3.0) doit être utilisé telle manière qu'il comprend des informations pouvant être définies avant la collecte sur le terrain (site étudié, date, observateur, méthode de collecte mise en œuvre, etc.)

- utiliser l'**extension MeasurementOrFact** (MoF) pour standardiser toute information – relative à une mesure ou un fait relié à l'évènement ou l'occurrence – 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 et leur réutilisation. 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.

- traduire en anglais le libellé des champs du jeu de données et leur valeur (les libellés pour les valeurs qualitatives et les unités 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 ;

- choisir des libellés explicites pour les attributs additionnels du SOT V3.0 et les mesures ou faits du Darwin Core (MeasurementOrFact) pour faciliter la lisibilité et la compréhension de la standardisation. Par exemple pour la mesure de taille d'un poisson : `tailleDuPoisson`. Ce libellé utilisant le terme générique « taille » pouvant ensuite être réutilisé pour d'autres mesures de taille (ex : `tailleDuSujetObserve`). Cette pratique participant à l'harmonisation de la standardisation.

- utiliser le terme **** (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 à l'évènement d'observation. Attention cependant à ne pas transformer ces champs en fourre-tout d'informations. Toute information dont la standardisation est rendue possible par un terme ou attribut définis dans les standards mais renseignée en remarque ou commentaire la rend inexploitable ;

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

## 1.5. Dispositifs choisis pour l'exercice

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 dispositifs 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 par technique de reconnaissance acoustique automatique.

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

# 2. Résultats des exercices de standardisation

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 des modèles conceptuels – avec le Darwin Core et enfin les résultats de standardisation avec SOT V3.0. Les standardisations réelles des jeux de données (tables de standardisation) sont incluses 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 technique d'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 (sortie de séquençage et identification). 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 1</th><th>Kit#</th><th>Replicate</th><th>ID</th><th>Principaux co Etude</th><th>BV</th><th>Rivière</th><th>Commune</th><th>Date</th><th>Latitude</th><th>Longitude</th><th>Anodonta ani; Anodonta cyg; Anodonta exi Corbicula sp.</th><th>Corbicula flum</th><th>Dreissena po Dreissena ro Euylesa 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>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>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 sont prélevés (Replicate) pour chaque site (Locality 1). La liste des 44 espèces de bivalves et leurs abondances relatives (nombre de lectures de machine) est associée à chaque échantillon. Des informations supplémentaires sur l'étude sont renseignées, comme les principaux contributeurs (Principaux contributeurs), le numéro de kit d'échantillonnage utilisé (Kit#), les coordonnées du point de relevé de l'échantillon (Latitude et Longitude), la date du relevé (Date) 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 recherchées. L'organisation des données peut être schématisée simplement telle que présentée en figure 5.

<figure><img src="image_17.png" /><figcaption>Figure 5 : Schéma de l'organisation générale des données. Pour chaque échantillon, l'abondance relative des espèces de bivalves est recherchée.</figcaption></figure>

Dans les deux parties 2.1.1 et 2.1.2 (une pour chaque standard) nous exposons la dernière étape de modélisation conceptuelle (modèle conceptuel final) de l'organisation des données avant la standardisation réelle 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.

### 2.1.1. Standardisation du jeu de données ADNe avec le Darwin Core

L'organisation et la standardisation des données (traduites en anglais) avec le standard Darwin Core peuvent être modélisées telles que présentées en figure 6.
<figure><img src="image_18.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="10" />, 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="11" />. 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 », dont la signification exacte n'est pas connue) 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 :

* 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 mais il serait probablement mieux positionné dans les métadonnées du jeu de données ;

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

<footnote n="11">¹¹ https://doi.org/10.1007/s10750-020-04260-8 ; https://doi.org/10.1016/j.biocon.2023.110089</footnote>
* 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 du jeu de données ADNe avec le SOT V3.0

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

<figure><img src="image_19.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 information 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. 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, anneeRef). Seule la localisation la plus précise est attendue par le standard SOT, les champs BV (bassin versant) et Rivière sont donc standardisés en tant qu'attributs additionnels (la commune étant la localisation la plus précise pour le regroupement). L'information portée par le champ Etude est standardisée en attribut additionnel car aucun attribut du SOT ne lui correspond. Cette information correspondrait plutôt à un attribut des métadonnées du jeu de données (si cette information est bien commune à tout le jeu de données). Enfin, il n'est pas clairement précisé quel attribut correspond à l'identifiant unique (au moins au sein du jeu de données) de l'échantillon entre Kit# et Replicate ou tout du moins si Kit# est utilisé comme tel. Cette information joue sur le choix du champ qui sera standardisé comme l'identifiant d'origine de l'évènement (idOrigineEvenement) et par conséquent celui qui sera standardisé comme attribut additionnel (ici, il a été choisi que Kit# serait standardisé en tant qu'idOrigineEvenement). Ces interrogations demanderaient un retour auprès du producteur pour avoir plus d'explication sur le jeu de données.

Résumé de la standardisation du jeu de données ADNe par le standard SOT V3.0 :
* L'organisation des données entre le site d'échantillonnage et les échantillons est facilement standardisée par le lien entre les concepts RegroupementEvenements (site d'échantillonnage) et Evenement (réplicat) grâce à l'attribut idSinpRegroupement reporté dans Evenement.

* Le dénombrement (quantité) de lectures de machines ne peut pas être standardisé par le DescriptifSujet (lacune de valeur correspondante dans la nomenclature objetDenombrement). Il doit être standardisé en AttributAdditionnel du SujetObservation.

* La nomenclature methodeDetermination du concept Determination permet d'indiquer que le SujetObservation a été déterminé en utilisant une méthode génétique, cependant aucune information ne permet de renseigner l'attribut obligatoire dateDetermination (du même concept), il est donc impossible d'utiliser le concept et par conséquent methodeDetermination.

* La localisation la plus précise du regroupement est la commune or les règles du standard obligent d'indiquer le code d'une commune référencée par l'Insee (codeLocalisation, anneeRef) ce qui n'est pas le cas des valeurs du champ Commune, ce qui est bloquant. Cette information est donc standardisée en attribut additionnel du regroupement, tout comme BV et Rivière.

## 2.2. Jeu de données n°2 : LEDKOA (observation aérienne)

Ce jeu de données est issu des recensements aériens de 2017 et 2018 dédiés à l'observation de prédateurs supérieurs marins de l'action LEDKOA pour « Levée des risques pour l'appel d'offres Eolien au large de DunKerque par Observation Aérienne ». Cette action a été conduite par l'OFB et l'Observatoire Pelagis dans le cadre des études préalables à l'autorisation d'un projet éolien en mer. Ces recensements ont été organisés d'avril 2017 à mai 2028 en plusieurs sessions de quelques jours (quatre au printemps et en été, deux en hiver). Le protocole d'observation multi-cibles est identique à celui appliqué lors des campagnes SAMM et REMMOA de l'observatoire Pelagis<fnref n="12" />.

Dans le jeu de données étudié, les données d'observations collectées concernent les mammifères marins, les oiseaux de mer, d'autres espèces de la mégafaune marine (requins, phoques), le phytoplancton, ainsi que les macro-déchets, les bateaux de toutes catégories (pêche/plaisance/commerce/...) et tous les engins de pêche matérialisés par des bouées (seront cités dans la suite de l'exercice en tant qu'objet ou activité humaine). Les conditions environnementales (état de la mer) sont aussi enregistrées ainsi qu'un indice de détectabilité basé sur les petits delphinidés et déterminé de manière globale par l'observateur (conditions excellentes, bonnes, moyennes, ou mauvaises).

Une « observation » correspond à la détection d'un animal ou d'un groupe d'animaux (ou d'objets) d'une même espèce (ou type d'espèces), à la même position et au même instant. Une observation peut donc correspondre à un ou plusieurs individus.

<table><caption>Tableau 4 : Extrait du jeu de données LEDKOA</caption><thead><tr><th>region</th><th>survey</th><th>subRegion</th><th>cycle</th><th>session</th><th>routeType</th><th>strate</th><th>computer</th><th>transect</th><th>effort</th><th>status</th><th>date</th><th>hhmmss</th><th>seaState</th><th>subjective</th><th>lat</th><th>lon</th><th>DATE_TIME1</th><th>DATE_TIME2</th><th>legLength</th><th>nom_suivi</th><th>type</th></tr></thead><tbody><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</td><td>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.73981683999583</td><td>DunkRisk_1(1) plane</td><td></td></tr></tbody></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 si celle-ci a été réalisée en effort (transect) ou hors effort) et que l'autre contient les informations sur l'effort d'observation (état de la mer, visibilité, horodatage, type d'effort, localisation et transect sur 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 peut être liée à un effort de prospection 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.

<footnote n="12">¹² https://www.observatoire-pelagis.cnrs.fr/wp-content/uploads/2021/08/GuideMethodoAerien2020.pdf</footnote>
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.

<table><caption>Tableau 5 : enregistrement d'observation d'activités humaines lors de la campagne DunkRisk (LEDKOA)</caption><thead><tr><th>species</th><th>taxon_fr</th><th>taxon_eng</th><th>famille_fr</th><th>family_eng</th><th>nom_fr</th><th>name_eng</th><th>nom_latin</th><th>cd_nom</th><th>cd_taxsup</th><th>podSize</th></tr></thead><tbody><tr><td>BUOY</td><td>Activite humaine</td><td>Human activity</td><td>Bouee</td><td>Buoy</td><td>Bouee de peche</td><td>Fishing buoy, setnet</td><td>Fishing buoy, setnet</td><td>NA</td><td>NA</td><td>1</td></tr><tr><td>MOTOBO</td><td>Activite humaine</td><td>Human activity</td><td>Navire</td><td>Ship</td><td>Bateau a petit moteur</td><td>Small motor boat</td><td>Small motor boat</td><td>NA</td><td>NA</td><td>1</td></tr></tbody></table>

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. (tableau 5). 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 prise en compte par les règles des standards – 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_20.png" /><figcaption>Figure 8: Schématisation de l'organisation des éléments du suivi réalisé dans le cadre du projet LEDKOA.</figcaption></figure>

La prospection est effectuée au cours d'une session de vol. À une session sont liés plusieurs transects définis selon un plan d'échantillonnage. L'effort de prospection correspond au survol d'un transect. 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 ou d'activité humaine (pollution, objet, navire) peut être liée. Un autre cas de figure peut se présenter lorsque des observations sont faites en dehors des transects prédéfinis correspondant à des manœuvres spéciales de vol entre transects ou pour revoir une observation (circle back, transit). Ces observations sont enregistrées comme étant hors effort.

### 2.2.1. Standardisation du jeu de données LEDKOA avec le Darwin Core

À partir de schémas tel que celui présenté en figure 8 et en y ajoutant tous les champs pertinents 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_21.png" /><figcaption>Figure 9 : Modèle conceptuel du jeu de données LEDKOA avec le DwC</figcaption></figure>

Nous avons compris que l'évènement principal d'observation est réalisé pendant un effort de prospection ou hors d'un effort, la classe Event est donc utilisée deux fois pour standardiser ces deux situations (« On effort » et « Off effort »). Le numéro de la session de vol est standardisé en tant que « locationRemarks » pour tous les évènements « on effort » (la strate n'est pas reportée dans le jeu de données pour les évènements « off effort). L'identifiant du transect pour le plan d'échantillonnage considéré est reporté uniquement pour les évènements « on effort » et est standardisé en tant que fait (classe MeasurementOrFact).

Lors d'une observation son identifiés des taxons (espèce) ou des évidences d'activités humaines (navire, bouée, pollution). Les informations sur le taxon sont standardisées par l'extension Occurrence (« 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 cohérence du standard DwC, seule une observation de taxon peut être standardisée par 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 à nouveau mobilisée. C'est le cas des champs « cycle », « computer », « strate » et « status », « seaState », « subjective » et « routeType » (qui sont tous communs à un même évènement d'effort).

Comme cité précédemment les observations d'activités humaines collectées dans le cadre de ce suivi ne sont théoriquement pas des observations destinées à être échangées par le DwC. Toutefois, ces observations étant importantes dans le cadre de ce suivi et seront probablement de plus en plus relevées à l'avenir par la communauté de la surveillance, nous proposons en figure 10 une version de standardisation du jeu de données prenant en compte ce type d'observations en tant qu'occurrence.
<figure><img src="image_22.png" /><figcaption>Figure 10 : Modèle conceptuel du jeu de données LEDKOA avec le DwC et proposition d'évolution</figcaption></figure>

Tous les champs concernant les observations d'activité humaines - étant précédemment standardisés en tant que MoF - sont standardisés dans la classe Occurrence. Pour que la classe Occurrence prenne en compte à la fois les observations de taxons et d'activités humaine nous proposons de modifier des termes existants du DwC (scientificName, vernacularName, organismQuantity, etc) en utilisant le mot « entity » (entityFamily, entityScientificName, entityVernacularName, entityQuantity, entityScope, entityCode, ect.) qui englobe alors les deux types d'observations. Nous proposons également d'inclure dans la standardisation d'occurrence le terme « entityScope » (actuellement « organismScope » dans le DwC) qui permet de préciser le type d'observation dont il s'agit (« taxa » ou « human activity » pour ce jeu de données). Vous pouvez voir un exemple de table de standardisation selon ces propositions en annexe 5.3 du présent document.

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 efforts de prospection le long d'un transect - est efficacement standardisée par la classe Event.

* De nombreux champs spécifiques au suivi appliqué pour ce jeu de données sont standardisés en tant que MeasurementOrFact (extensions MoF).

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

* Nous proposons d'étendre la notion d'observation de taxon à des observations d'entités pour pouvoir intégrer l'observation d'objets liés à l'activité humaine (évolution d'utilisation de la classe Occurrence) aux données échangeables par le Darwin Core.

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

À partir d'un schéma 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 proposé ci-dessous.
<figure><img src="image_23.png" /><figcaption>Figure 11 : Modèle conceptuel du jeu de données LEDKOA avec le SOT V3.0</figcaption></figure>

Ici, le concept RegroupementEvenements est utilisé pour standardiser les informations sur l'effort de prospection (« effort de prospection ») qui est toujours effectué pendant le survol d'un transect au cours d'une session de vol. Cependant les attributs du concept RegroupementEvenements ne permettent de standardiser qu'un seul identifiant d'origine, les identifiants du transect et de la strate sont donc standardisés en tant qu'attributs additionnels du regroupement pour permettre la standardisation de l'identifiant de l'effort de prospection en tant qu'idOrigineRegroupement. L'identifiant de la session (information liée à une observation en effort ou hors effort) est quant à lui standardisé en tant qu'attribut additionnel des évènements d'observation.

Le regroupement « effort de prospection » regroupe les évènements d'observations effectués au cours de cet effort (« Observation en effort »). Les observations réalisées hors effort sont directement standardisées en évènement « observation hors effort », elles ne sont pas rattachées à un regroupement spécifique (liées ni à un transect ni à une strate dans les fichiers de données).

À chaque évènement d'observation est lié un sujet observé (concept SujetObservation) – un taxon ou une évidence d'activité humaine - auquel sont rattachés si besoin des éléments de description (DescriptifSujet) tel que le dénombrement (comptage).

Dans le standard SOT V3.0, le concept SujetObservation ne comprend pas d'attributs permettant de standardiser une date ou un horodatage précis de l'observation. Ces informations étant présentes dans le jeu de données (horodatage de l'observation), elles sont alors standardisées en tant qu'horodatage de l'évènement d'observation (en effort ou hors effort). Cependant dans le jeu de données l'horodatage est également spécifié pour l'effort de prospection (élément déjà standardisé via le concept de RegroupementEvenements). Or, le concept RegroupementEvenements ne comprend pas d'attribut pour standardiser des informations de type date ; seul le concept Evenement prend en charge ce type d'information. Dans cet exercice, l'horodatage de l'effort n'est alors pas standardisé, nous considérons que l'horodatage le plus important pour la réutilisation des données est celui de l'observation.

**Ce problème ne pourrait-il pas être solutionné en fusionnant le concept RegroupementEvenements au concept Evenement ? Comme cela est actuellement fait dans le Darwin Core via la fonctionnalité de récursivité de la classe Event.**

Toutes autres informations qui ne peuvent pas être standardisées avec des attributs de concepts définis dans le standard (Evenement, SujetObservation, DescriptifSujet, etc.) sont standardisées 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 route de vol (routeType).
Comme pour le Darwin Core, les règles du standard SOT V3.0 ne permettent pas en théorie d'échanger des observations d'entités non taxonomiques (hors vocation du standard). Cependant, l'attribut `cd_nom` (rattaché au référentiel national TAXREF) étant facultatif, il est tout de même possible en pratique de standardiser et d'intégrer (par exemple à la base de données de l'INPN qui utilise le SOT) des observations d'entités non taxonomiques. **Néanmoins la diffusion d'un jeu de données non lié à un cd_nom pourrait être bloquée.**

Dans le cas où il serait tout de même souhaité que le jeu de données soit intégré en base, il est possible de renseigner l'information du nom commun/le plus précis (ex : bouée de pêche) donné à l'entité dans l'attribut « nomCite » du concept SujetObservation. Cependant, les autres informations liées aux observations d'activités humaines doivent quant à elles être standardisées en tant qu'attribut additionnel (familleAutreObjet, quantiteAutreObjet, etc.) : la nomenclature objetDenombrement ne comprenant pas de valeur correspondante (ex : « entite »), et les informations typologiques de niveau supérieur (hors référentiel taxonomique) n'étant pas échangées par le standard (ex : activité humaine, bouée).

Les observations de taxons et d'activités humaines étant enregistrées sous les mêmes champs dans les fichiers de données étudiés - si les règles du standard le permettaient - ces informations seraient efficacement standardisées en tant qu'attribut des concepts SujetObservation et DescriptifSujet (ligne en pointillés représentée sur la figure 11), en ajustant notamment la liste de valeurs de l'attribut objetDenombrement (ajout de la valeur « entité » par exemple).

## 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 - telles que les observations réalisées pendant une session d'effort le long d'un transect - est bien standardisée par les concepts RegroupementEvenements et Evenement. **Cependant, des informations, notamment de type date, peuvent être perdues lors d'une standardisation utilisant le concept RegroupementEvenements. Proposer un unique concept Evenement, récursif, tel que cela est fait dans le Darwin Core pourrait solutionner ce problème et serait à étudier lors des évolutions futures du standard SOT.**

* Les règles de renseignement du concept SujetObservation ne permettent pas, en théorie, de standardiser des observations d'unités non taxonomiques telles que des activités humaines (objets en mer, navires, pollution). **Néanmoins, la condition de renseignement facultative de l'attribut cd_nom rend possible en pratique la standardisation de ces informations - en vue d'intégrer le jeu de données à une base utilisant le standard. Cependant, la diffusion de ces données une fois intégrées, dont le sujet observé ne serait pas lié à un cd_nom, pourrait être bloquée.** L'utilisation du concept AttributAdditionnel reste nécessaire pour les autres informations liées à ce type d'observation (dénombrement, niveaux de dénomination). Des évolutions du standard pourront être discutées en ce sens.

* De nombreuses autres informations sont standardisées en tant qu'attribut additionnel car trop spécifiques au suivi mis en œuvre (ordinateur utilisé, manœuvre de vol, strate du plan d'échantillonnage, etc.).

## 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 6 : 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 colspan="2">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ée</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>S24028.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>S24028.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>S24028.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 colspan="2">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></td><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></td><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>I</td><td>1</td><td>3</td></tr><tr><td></td><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 colspan="2">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 - Nom commun</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></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></td><td>Non</td></tr><tr><td>34</td><td></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></td><td>Non</td></tr><tr><td>864</td><td></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></td><td>Non</td></tr></tbody></table>

En analysant les champs du jeu de données (tableau 6) 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_24.png" /><figcaption>Figure 12: Schématisation de l'organisation des éléments du jeu de données ASPE</figcaption></figure>

La figure 12 présente la première schématisation des données une fois l'analyse du jeu de données effectué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, qui ont nécessité la consultation de documentation relative au protocole, 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 du jeu de données ASPE avec le Darwin Core

<figure><img src="image_25.png" /><figcaption>Figure 13: Modèle conceptuel du jeu de données ASPE avec le DwC</figcaption></figure>
La figure 13 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 du jeu de données ASPE avec SOT V3.0

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_26.png" /><figcaption>Figure 14 : 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 14). 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 standardisables par des attributs définis 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 le concept n'étant pas récursif (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 pallier ce problème en liant deux instances de SujetObservation en reportant l'identifiant unique d'une des deux instances dans l'attribut idSinpSujetObsLie. 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 (vocabulaire contrôlé) 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 informations 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 de récursivité).

* 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 7 : Extrait du jeu de données STOC-EPS</caption><thead><tr><th>Point</th><th>Carre</th><th>Année</th><th>tf_point_année</th><th>Etude</th><th>Insee</th><th>Departement</th><th>Code_sp</th><th>CodEsp Espafran</th><th>Abondance_let</th><th>Altitude</th><th>Longitude_mg84</th><th>Latitude_mg84</th><th>Cod hab princ 1</th><th>Hab princ 1</th><th>Cod hab princ 2</th><th>Hab princ 2</th><th>Cod hab sec 1</th><th>Hab sec 1</th><th>Cod hab sec 2</th><th>Hab sec 2</th></tr></thead><tbody><tr><td>010100P01</td><td>10100</td><td>2007</td><td>2007010100P01</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.166193292869</td><td>D02</td><td>Prairie non cultivée</td><td>D02</td><td>Prairie non cultivée</td><td>A01</td><td>Fordit 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 7) 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'oiseau entendue ou vue 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. Un enregistrement (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 d'un 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 15.

<figure><img src="image_27.png" /><figcaption>Figure 15 : 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 15).

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

L'organisation des données peut être standardisée avec le Darwin Core telle que modélisée en figure 16.
<figure><img src="image_28.png" /><figcaption>Figure 16 : 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 du jeu de données STOC-EPS avec SOT V3.0
<figure><img src="image_29.png" /><figcaption>Figure 17 : 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 17). 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 DescriptifSujet. Aussi, les quatre habitats (un habitat primaire et un habitat secondaire par session – les sessions étant regroupées par année et par point -) associés à un point pour une année peuvent être standardisés en utilisant le concept LienHabitats. Ce concept permet d'indiquer le libellé et le code de l'habitat tels que renseignés dans le jeu de données ainsi que les informations sur la typologie d'habitat utilisée et sur sa correspondance avec le référentiel national HabRef. Cependant les attributs versionTypologie et versionHabRef du concept LienHabitats sont obligatoires selon les règles du standard or aucune information n'est disponible dans le jeu de données pour les renseigner – cette lacune d'information devient donc bloquante pour une future intégration de ces jeux de données dans les bases de données utilisant ce standard. De même pour l'attribut obligatoire nomCite du concept SujetObservation - pour lequel aucun nom d'espèce (nom vernaculaire généralement) n'est renseigné dans le jeu de données hormis le code espèce – et l'attribut obligatoire idSinpJdd. Le code espèce – propre à Faune France – est alors standardisé en tant qu'attribut additionnel, de même que l'information sur le département dans lequel se trouve le carré STOC.

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

L'organisation des données est standardisée efficacement par le standard SOT V3.0. Peu d'attributs doivent être standardisés en tant qu'attributs additionnels. Le lien entre le carré, ses points et leurs participations est possible d'une part grâce à la fonctionnalité de récursivité du concept RegroupementEvenements (attributs estRegroupementParent et idRegroupementParent) et d'autre part en reportant l'identifiant SINP du regroupement dans les évènements.

Le concept LienHabitats, permet de lier de multiples habitats à un évènement d'observation ce qui est très utile pour ce jeu de données.

Cependant plusieurs attributs s'avères bloquants en vue d'une intégration des données dans une base de données utilisant ce standard :

- L'attribut obligatoire IdSinpJdd du concept Evenement n'est pas renseigné car les métadonnées du jeu de données n'existent pas (n'ont pas été bancarisées dans le SINP) ;

- L'attribut obligatoire nomCite du concept SujetObservation n'a aucun champ correspondant dans le jeu de données. Cette lacune pourrait facilement être corrigée en ajoutant un champ « espèce » en complément du code de l'espèce ;
- Les attributs obligatoires versionTypologie et versionHabRef du concept LienHabitats - utilisé pour standardiser les informations sur les quatre habitats renseignés par participation - n'ont pas de champ correspondant dans le jeu de données.

## 2.5. Jeu de données n°5 : Vigie-Chiro (contacts acoustiques)

Ce jeu de données est extrait de la base de données du programme de suivi des chiroptères Vigie-Chiro (tableau 8).

<table><caption>Tableau 8 : Extrait du jeu de données protocole point fixe Vigie-Chiro</caption><thead><tr><th>participation</th><th>espace lout</th><th>num_mic micro groupe</th><th>nbContacts score</th><th>max_min_decals_couch</th><th>min_decals_ever</th><th>nbContacts ng_conance</th><th>valideur confiance</th><th>observateur</th><th>index_ale</th><th>Index_repos/acture</th><th>longitude</th><th>latude</th><th>precision</th><th>prototype</th><th>type</th><th>enregistreur</th></tr></thead><tbody><tr><td>5660cbdc0f2300c79d3Bster</td><td>2015-01-03</td><td>0 Chauve-souris</td><td>2.014</td><td>647</td><td>29848</td><td>0</td><td>0.03909</td><td>0.000396666666666656P</td><td>1.870198034363</td><td>43.64479061177</td><td>25 point fine entre</td><td>enregistrement</td><td>SMCBAT</td><td></td><td></td></tr><tr><th>type_mic</th><th>hauteur</th><th>micro_gite</th><th>nom_gite</th><th>nb heures</th><th>enregistrement</th><th>nuit</th><th>complete</th><th>observateur</th><th>rice</th><th>id_obs</th><th>numero_carr</th><th>point</th><th>temperature</th><th>debut</th><th>temperature</th><th>fin</th><th>couverture</th><th>nuage</th><th>vent</th></tr><tr><td>Micro interne</td><td>0.2</td><td>0</td><td>8.6</td><td></td><td></td><td>TRUE</td><td></td><td>Yves Bas</td><td></td><td>558acd059cbdc000e0793e*</td><td>340670 Z1</td><td></td><td>26</td><td></td><td>50-75</td><td></td><td></td><td>FAIBLE</td></tr><tr><th>type_suivi_gite</th><th>problème</th><th>micro_année</th><th>idnum</th><th>NomFr</th><th>NomSci</th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th></tr><tr><td>non</td><td></td><td>2015</td><td>522979</td><td>Barbastelle d'Europe</td><td>Barbastella barbastellus</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

Pour collecter des informations de présence sur les chiroptères des détecteurs-enregistreurs autonomes couplés à l'identification assistée par ordinateur sont utilisés. Ce suivi repose sur l'enregistrement de nuits complètes ce qui permet un meilleur aperçu de la communauté de chiroptères utilisant le site. Ce protocole contribue à l'évaluation des variations spatiales et temporelles des abondances de chiroptères tout en tenant compte des habitats ou de l'influence des conditions météorologiques (les informations sur les habitats ne sont pas comprises dans l'extrait étudié). Comme pour le programme STOC, un carré est tiré aléatoirement selon une grille du MNHN et est attribué à l'observateur qui mettra en œuvre le protocole 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 18.

<figure><img src="image_30.png" /><figcaption>Figure 18 : 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. 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 du jeu de données Vigie-Chiro avec le Darwin Core

<figure><img src="image_31.png" /><figcaption>Figure 19 : 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 19. 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 - par le terme parentMeasurementID - d'imbriquer des mesures entre elles et ainsi représenter une organisation 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 du jeu de données Vigie-Chiro avec SOT V3.0

<figure><img src="image_32.png" /><figcaption>Figure 20 : 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 20. 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 avec 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. Résumé des forces et faiblesses des standards

## 3.1. Forces des deux standards

Dans cet exercice cinq jeux de données issus de la mise en œuvre de dispositifs de surveillance 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_33.png" /><figcaption>Figure 21 : Modèle conceptuel des standards Darwin Core et SOT V3.0</figcaption></figure>

La quasi-totalité des informations que portent ces jeux de données a pu être standardisée à l'aide des éléments des deux standards. Notamment grâce à l'extension MeasurementOrFact du DwC et au 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 facultativement une unité. L'organisation hiérarchisée des informations (structure commune aux jeux de données de surveillance, faisant référence aux étapes du suivi mis en oeuvre) est efficacement standardisée par les classes Event et Occurrence du DwC et les concepts RegroupementEvenements, Evenement et SujetObservation du SOT V3.0 (figure 21), 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 contraints 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 des termes et attributs dont le renseignement est libre : il existe le risque d'en faire des « fourre-tout » d'informations et de les rendre non exploitables (le format des valeurs renseignées é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.

## 3.2. 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ésentation est faite dans un format complexe, même pour un utilisateur familier de 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 souvent, aucune liste existante n'est préconisée. 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.

- 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), qui est le type de données visé par le standard. Il n'existe pas la possibilité théorique – 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 par la communauté scientifique pour établir leur lien avec l'état des espèces et des habitats dans le cadre de la surveillance.

- 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 référentiels d'habitats (versionnés) avec des codes d'identification est de plus en plus répandue dans la communauté - ces informations doivent donc pouvoir être standardisées.

Nous rappelons que l'extension Humboldt for Ecological Inventories (eco) n'a pas été testée dans cet exercice. Elle propose un vocabulaire et des nouveaux termes spécifiques pour transmettre des informations sur les suivis de la biodiversité comprenant une structure hiérarchique. Son utilisation est voulue comme une description étendue des évènements (Event). De ce fait cette extension pourrait répondre au besoin de standardisation de nombreuses mesures ou faits (MeasurementOrFact) liés à l'évènement et créés dans ces exercices.

## 3.3. Faiblesses du SOT V3.0

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

- Pour le jeu de données LEDKOA, l'absence d'attribut de type date dans le concept RegroupementEvenements a entraîné une perte d'information.

- Il serait utile que le concept AttributAdditionnel puisse être applicable à davantage de concepts tel que DescriptifSujet.

- La condition d'obligation de renseignement de certains attributs a pu être bloquante pour la standardisation d'informations des jeux de données étudiés. Que ce soit car 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 les autres attributs sont obligatoires mais non utilisés pour le jeu de données considéré.

- La condition de renseignement facultative de l'attribut cdNom permet en pratique de standardiser et d'intégrer – à une base de données utilisant le standard – des observations d'entités non taxonomiques. Cependant, selon les règles de validation du SINP, la diffusion d'observations non liées à une unité taxonomique peut bloquer leur diffusion et donc leur réutilisation. Le standard n'est donc pas opérationnel pour gérer ce type d'observations.

- Certaines nomenclatures du standard présentent des lacunes de valeur qui ont pu être 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 -, des identifications d'espèce par programme informatique automatisé (identification sur enregistrement acoustique) ou encore des évidences d'activité humaine.
# 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 techniques 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 telles que l'ADNe est en croissance constante et se démocratise largement dans les communautés scientifiques en écologie notamment dans le cadre de la surveillance de la biodiversité. Cette nouvelle diversité d'acteurs multiplie les cas d'usage pour ce type de données ce qui multiplie potentiellement la quantité d'informations à renseigner dans les jeux de données. Or, cela impose aux producteurs de données une charge de travail supplémentaire pour s'y conformer.

Il semble donc nécessaire que la communauté scientifique 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 de faciliter le renseignement des informations pour le producteur de données.

Parmi les informations collectées par ces techniques et importantes pour leur compréhension et leur utilisation, le nombre de lectures de machine (reads) en sortie de séquençage traduit une abondance relative du sujet observé. Cependant, de multiples séquences peuvent appartenir à un même individu ou plusieurs, cette information n'étant pas connue. Pour le standard SOT V3.0 et dans le cas où cette information serait connue il faudrait alors standardiser séparément les informations de dénombrement « individu » (valeur de objetDenombrement du concept DescriptifSujet – lié au concept SujetObservation) et « nombre de lecture de machine » (qui dans ce cas serait aussi un dénombrement du sujet observé). De même, les séquences génétiques analysées peuvent être liées à un OTU, une unité ne correspondant pas à un rang taxonomique référencé. Or si le nom de taxon est un attribut obligatoire dans le standard de données (Darwin Core ou SOT), l'intégration de ces données aux bases de données utilisant les standards est bloquée. La réflexion pourrait être poussée sur les informations liées aux protocoles (terrain, laboratoire) mis en œuvre pour obtenir le résultat d'identification et leur importance dans la réutilisation des données.

Ces spécificités justifient-elles de faire évoluer les standards Darwin Core et SOT ? Nous rappelons que ces standards - de par les dispositifs dans lesquels ils s'inscrivent ou sont utilisés - ont vocation à être des standards « généraux » sur les données d'observation de la biodiversité. Ils ne sont donc pas voués à être très spécifiques à un type de données. L'analyse des attributs additionnels ou mesures en rapport avec des inform déjà enregistrées dans les bases de données utilisant ces standards Ce sont des questions auxquelles il faut réfléchir dès maintenant dans la perspective d'une meilleure prise en compte et réutilisation des données issues de techniques ADNe.

Les standards du SINP proposent tout de même de premiers éléments permettant de standardiser les jeux de données issues de techniques ADNe. Dans le standard SOT V3.0, l'attribut methodeDetermination (concept Determination) permet de renseigner la valeur « génétique ». Les attributs techniqueCollecte et autreTechnique – faisant appel au référentiel Campanule - permettent de préciser la technique de collecte mise en œuvre. Dans le standard de 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 se basant sur le Darwin Core. Cependant, la majorité des informations recommandées par ce guide ne sont pas renseignées dans le jeu de données ADNe étudié pour cet exercice alors qu'elles sont disponibles dans les publications scientifiques liées à l'étude. Cet exemple est-il représentatif des pratiques de la communauté ? Dans ce cas il apparaît nécessaire de fortement recommander le renseignement des références de ces publications dans les jeux de données - les standards d'échanges testés pour cet exercice permettant tous deux de standardiser des références bibliographiques.
Dans l'idéal, afin de maximiser la qualité et la réutilisation de ce type de données il faudrait que soient renseignées 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 techniques ADNe et ainsi organiser la structuration de ce type de jeu de données afin que les évolutions des standards puissent le prendre en compte.

Dans tous les cas, sans ces deux niveaux d'harmonisation – précision sur la 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é utilisant les techniques ADNe.

## 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 de données de surveillance de la biodiversité grâce au concept d'évènement (informations relatives à un relevé, la date, l'observateur, le lieu) pouvant être emboîté ou regroupé et auquel sont rattachées les observations.

Des différences notables distinguent cependant les deux standards.

Les deux standards s'opposent notamment sur (1) leur échelle d'application, (2) l'avancement dans le contrôle du vocabulaire, notamment en lien avec les référentiels nationaux, (3) la gestion d'informations supplémentaires et (4) l'utilisation de la récursivité.

Sur le premier point, le SINP est un dispositif national organisé selon une logique partenariale avec les régions françaises tandis que le Darwin Core, notamment utilisé par le GBIF, est un réseau international faisant « référence » à cette échelle (utilisation des outils GBIF par de nombreuses communautés scientifiques). De ce fait les attendus en termes de services rendus et de qualité des données peuvent être plus spécifiques pour le SINP.

Sur le deuxième point, le Darwin Core est plus permissif sur les conditions de renseignement de ses termes là où le standard SOT V3.0 est plus contraignant (davantage de 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é (harmonisation) et l'utilisation ultérieure des données (davantage d'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. De plus, de nombreux référentiels nationaux existent en France et sont utilisés par le SINP, cela participe grandement à l'harmonisation des données mais réduit la flexibilité du standard (praticité pour les utilisateurs).

Sur le troisième point les dernières évolutions du Darwin Core quant à la gestion des informations additionnelles via la classe extendedMeasurementOrFact permettent de standardiser une structuration des données plus complexe et donc une plus grande richesse d'information que le concept AttributAdditionnel du SOT, notamment grâce à sa récursivité.

Le quatrième point conforte le précédent, en effet l'utilisation de la récursivité dans le Darwin Core est plus développée que dans le SOT, permettant de standardiser efficacement des structurations complexes d'informations. Nous avons vu avec ces exercices que la récursivité de la classe Event était très utile pour standardiser des données de surveillance. Côté SOT V3.0 l'existence en parallèle des concepts Evenement et RegroupementEvenements - bien que facilitant la lecture du standard par leur libellé explicite - s'avère complexifier la standardisation dans certains cas. Une fusion de ces deux éléments en introduisant une récursivité du concept Evenement fluidifierait la standardisation des informations en même temps qu'améliorer l'interopérabilité des deux standards.

Une correspondance de champs (« mapping » en anglais) existe entre les deux standards pour permettre le flux de données entre le SINP et le GBIF. À l'avenir il est toutefois envisageable que certains concepts/classes constituent une base commune aux deux standards (même attributs, même libellés, avec traduction) - auxquels pourraient être appliquées des règles d'utilisation spécifiques aux besoins nationaux du SINP pour le SOT (attributs obligatoires, nomenclatures, référentiels, concepts de validation, de modification, etc.) lorsque nécessaires. Le Darwin Core pourrait être complété de concepts du SOT V3.0 comme LienHabitats et Strate - types d'informations lui faisant actuellement défaut quant aux données sur les habitats et la phytosociologie.

La dynamique actuelle d'évolution du Darwin Core va en ce sens. En effet, le nouveau modèle de données du Darwin Core – en cours de développement par le TDWG – tend à contraindre davantage la standardisation de ses termes avec du vocabulaire contrôlé, se rapprochant de la philosophie du SINP sur la qualité et la complétion des données requises.
## 4.3. Perspectives d'évolution du Darwin Core 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. 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.

c. 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).

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

e. Généraliser la notion d'observation de taxon à celui d'observation d'entité dans tous les termes (entityFamily, entityScientificName, entityVernacularName, entityQuantity, entityScope, entityCode, ect.) afin de pouvoir rapporter des observations sur les pressions qui seront de plus en plus collectées lors de la réalisation de suivi de taxons et d'habitats.

## 4.4. Perspectives d'évolution du SOT V3.0 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), versionTypo et versionHabRef.

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

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

e. Afin de simplifier l'utilisation de cet attribut et éviter de rajouter des valeurs spécifiques à chaque cas d'étude on pourrait imaginer ajouter la valeur « nombreEntité » qui serait générique à tous les types de sujet observé (nombre d'entités liées au sujet observé). Ce dénombrement serait alors à analyser au regard de la technique de collecte renseignée dans le jeu de données.

f. Nous proposons également de fusionner les concepts RegroupementEvenements et Evenement du SOT V3.0 afin de fluidifier la standardisation des données avec ce standard, ce qui le rapprocherait de fait de la structuration du Darwin Core.

## 5. Conclusion

Pour conclure, ces deux standards ont vocation dans leur philosophie et leur contenu à se rapprocher l'un de l'autre mais la différence d'échelle d'application (SINP dispositif partenarial national-régional) et de cible rendent leur coexistence indispensable.

Aussi, les propositions d'évolutions exposées ci-dessus amènent toutes à une question majeure : quel type de données un standard a-t-il vocation à échanger ? Un même standard doit-il prendre en compte de multiples types de données d'observation ou doit-on en développer de nouveaux, spécifiques aux enjeux des communautés scientifiques ?

Ainsi, les standards Darwin Core et SOT ont-ils vocation à standardiser des données autres que des observations de taxons ? L'exercice sur le jeu de données LEDKOA nous montre qu'il peut être intéressant que des observations de taxon soient liées à des observations d'activité humaine dans le cadre d'études réglementaires notamment. Ce sont ces questions qu'il faut avant tout poser lors des réflexions autour de l'évolution de ces standards.
# 6. Annexes

## 6.1. Tables de standardisation du jeu de données ADNe avec le Darwin Core

<figure><img src="image_34.png" /><figcaption>Figure 22 : É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 22 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 9 : 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>medianSampleID</th><th>fieldNumber</th><th>eventDate</th><th>occurrence</th><th>decimalLatitude</th><th>decimalLongitude</th><th>geodeticDatum</th><th>sampleSize</th><th>sampleSizeUnit</th><th>samplingProtocol</th><th>waterBody</th><th>municipality</th><th>locationID</th><th>veracity</th><th>higherGeography</th><th>enrichment</th><th>eventType</th><th>id</th><th>standardProperty</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>VesselName</td><td>La VesselName</td><td>1</td><td>1</td><td>Rhône</td><td>No occurrences</td><td>site</td><td>(in study)</td><td>Vigilife Rhône</td></tr><tr><td>replicates</td><td>sampling1</td><td>SPY1600073</td><td>91</td><td></td><td></td><td>46.144235</td><td>5.943902</td><td>4326</td><td>600000</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>replicates2</td><td>sampling1</td><td>SPY1600074</td><td>82</td><td></td><td></td><td>46.144217</td><td>5.944029</td><td>4326</td><td>600000</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 10 : 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>Vigilife Rhône</td><td></td></tr></tbody></table>

Le site d'échantillonnage est standardisé via la classe Event (eventID « sampling1 ») (tableau 9) 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 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 11 : 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 11). 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.

## 6.2. Tables de standardisation du jeu de données ADNe avec le SOT V3.0

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

La figure 23 présente l'identification par code couleurs des concepts à utiliser et les principales informations à standardiser (et leur correspondances SOT V3.0).
<table><caption>Tableau 12 : 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 12) 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 13 : 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 14 : Table de standardisation du concept AttribAdditionnel du SOT V3.0 pour le jeu de données ADNe.</caption><thead><tr><th>idSinpRegroupement</th><th>idSinpEvenement</th><th>idSinpSujetObs</th><th>nomAttribAdd</th><th>definitionAttribAdd</th><th>valeurAttribAdd</th><th>uniteAttribAdd</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 muleettes 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 13), 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 14). 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 15 : 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 15). 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 16 : 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 16 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 16 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.

## 6.3. Tables de standardisation du jeu de données LEDKOA avec le Darwin Core

Par soucis de lisibilité seuls quelques enregistrements sont présentés dans cet exercice, représentatifs des différents types d'enregistrement du jeu de données.

<table><caption>Tableau 17 : Table de standardisation de la classe Event du DwC pour le jeu de données LEDKOA</caption><thead><tr><td>eventID</td><td>fieldNumber</td><td>eventDate</td><td>samplingProtocol</td><td>sampleSizeValue</td><td>sampleSizeUnit</td><td>higherGeography</td><td>waterBody</td><td>decimalLongitude</td><td>decimalLatitude</td><td>geodeticDatum</td><td>locationRemarks</td><td></td><td>eventType</td><td>datasetName</td></tr></thead><tbody><tr><td>effort1</td><td>L22-4-B</td><td>12-03-2017:140322</td><td>Aerial tracking</td><td>3.73981683999583</td><td>kilometers</td><td>Northeast Atlantic ocean</td><td>English Channel</td><td>2.96203666667</td><td>51.61095166667</td><td>4326</td><td>Strate N3 of sampling plan</td><td>On effort</td><td>DunkRisk</td><td></td></tr><tr><td>offEffort1</td><td></td><td></td><td>Aerial tracking</td><td></td><td></td><td>Northeast Atlantic ocean</td><td>English Channel</td><td></td><td></td><td></td><td></td><td>Off effort</td><td>DunkRisk</td><td></td></tr></tbody></table>

Le tableau 17 représente la table de la classe Event du Darwin Core. Le terme eventType permet de savoir à quel évènement du modèle conceptuel correspond chaque enregistrement. L'identifiant de l'effort de prospection est standardisé par le terme fieldNumber. La date et la localisation précise de cet effort sont respectivement standardisées par les termes eventDate, decimalLongitude et decimalLatitude. La quantité d'effort déployée pour le suivi peut être standardisée par les termes sampleSizeValue et sampleSizeUnit (ici la longueur d'un LEG de transect, correspondant à un effort). Des informations communes à l'ensemble des enregistrements (higherGeography, waterBody, datasetName) sont standardisées comme informations des évènements bien qu'elles pourraient être standardisées en tant que métadonnées du jeu de données.
<table><caption>Tableau 18 : Table de standardisation de l'extension Occurrence du DwC pour le jeu de données LEDKOA</caption><thead><tr><th>occurrenceID</th><th>parentEventID</th><th>recordNumber</th><th>eventDate</th><th>decimalLatitude</th><th>decimalLongitude</th><th>geodeticDatum</th><th>taxonID</th><th>parentUsageNameID</th><th>organismQuantity</th><th>organismQuantityType</th><th>vernacularName</th><th>scientificName</th><th>family</th><th>basisOfRecord</th><th>occurrenceStatus</th></tr></thead><tbody><tr><td>occ1</td><td>effort1</td><td>51538-14-8</td><td>2018/03/06 14:38:36-00</td><td>51.07243333333333</td><td>2.03597833333333</td><td>4326</td><td>60939</td><td>196139</td><td>1</td><td>pod</td><td>Harbour porpoise</td><td>Phocoena phocoena</td><td>Phocoenidae</td><td>HumanObservation</td><td>present</td></tr><tr><td>occ2</td><td>offeffort1</td><td>5102-15-8</td><td>2018/03/07 06:42:34-00</td><td>51.293337</td><td>1.522095</td><td>4326</td><td>60776</td><td>193036</td><td>2</td><td>pod</td><td>Grey seal (Atlantic seal)</td><td>Halichoerus grypus</td><td>Phocoidae</td><td>HumanObservation</td><td>present</td></tr><tr><td>occ3</td><td>offeffort1</td><td>5158-5-8</td><td>2017/06/13 07:29:11-00</td><td>51.04980166667</td><td>2.04301333333333</td><td>4326</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>HumanObservation</td><td>present</td></tr></tbody></table>

Le tableau 18 présente la table de la classe Occurrence. Dans cette table sont standardisées les informations sur l'observation d'un taxon ou d'une évidence d'activité humaine : sont reportées les informations sur le taxon observé (vernacularName, scientificName, family, taxonID, parentUsageNameID) ainsi que la quantité (organismQuantity, organismQuantityType) et la localisation précise de cette observation (decimalLatitude, decimalLongitude). L'identifiant d'origine de l'observation est standardisé par le terme recordNumber.

Les termes basisOfRecord et occurrenceStatus sont obligatoires ou fortement recommandés et utilisés pour tous les jeux de données de cet exercice. Le terme basisOfRecord permet d'indiquer que l'observation est d'origine humaine (contrairement à une machine par exemple) et occurrenceStatus 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 ».

Nous pouvons voir que pour une observation d'activité humaine aucune valeur n'est reportée dans les termes taxonID, parentUsageNameID, organismQuantity, organismQuantityType, vernacularName, scientificName et family. En effet, comme exposé précédemment, si l'on respecte les règles du standard, il n'a pas vocation à échanger des données d'observations autres que de taxons. De ce fait, ces informations sont standardisées en tant que MeasurementOrFact (tableau 19).

<table><caption>Tableau 19 : Table de standardisation de l'extensions MoF du DwC pour le jeu de données LEDKOA</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>meas1:effort1</td><td>effort1</td><td></td><td>status</td><td>BEGIN</td><td></td></tr><tr><td>meas2:effort1</td><td>effort1</td><td></td><td>cycle</td><td>1</td><td></td></tr><tr><td>meas3:effort1</td><td>effort1</td><td></td><td>subjective</td><td>GM</td><td></td></tr><tr><td>meas4:effort1</td><td>effort1</td><td></td><td>seaState</td><td>3</td><td>Douglas scale</td></tr><tr><td>meas5:effort1</td><td>effort1</td><td></td><td>computer</td><td>B</td><td></td></tr><tr><td>Meas6:effort1</td><td>effort1</td><td></td><td>transect</td><td>N3/101</td><td></td></tr><tr><td>meas7:effort1</td><td>effort1</td><td></td><td>routeType</td><td>LEG</td><td></td></tr><tr><td>meas1:offEffort1</td><td>offEffort1</td><td></td><td>cycle</td><td>1</td><td></td></tr><tr><td>meas2:offEffort1</td><td>offEffort1</td><td></td><td>computer</td><td>B</td><td></td></tr><tr><td>meas3:offEffort1</td><td>offEffort1</td><td></td><td>routeType</td><td>CIRCLE_BACK</td><td></td></tr><tr><td>meas1:occ1</td><td></td><td>occ1</td><td>taxon</td><td>Marine mammal</td><td></td></tr><tr><td>meas2:occ1</td><td></td><td>occ1</td><td>speciesCode</td><td>PHOPHO</td><td></td></tr><tr><td>meas1:occ2</td><td></td><td>occ2</td><td>taxon</td><td>Marine mammal</td><td></td></tr><tr><td>meas2:occ2</td><td></td><td>occ2</td><td>speciesCode</td><td>PHOCID</td><td></td></tr><tr><td>meas1:occ3</td><td></td><td>occ3</td><td>otherObjectName</td><td>Fishing buoy, setnet</td><td></td></tr><tr><td>meas2:occ3</td><td></td><td>occ3</td><td>otherObjectCode</td><td>BUOY</td><td></td></tr><tr><td>meas3:occ3</td><td></td><td>occ3</td><td>otherObjectFamily</td><td>Buoy</td><td></td></tr><tr><td>meas4:occ3</td><td></td><td>occ3</td><td>otherObjectHigherClassification</td><td>Human activity</td><td></td></tr><tr><td>meas5:occ3</td><td></td><td>occ3</td><td>otherObjectQuantity</td><td>1</td><td>entity</td></tr></tbody></table>

Le tableau 19 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é 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, comme mentionné précédemment, 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 »). Nous proposons alors ci-dessous une évolution de la classe Occurrence qui pourrait prendre en compte davantage de type d'observation (tableau 20).

<table><caption>Tableau 20 : Proposition de standardisation de la table occurrence prenant en compte les observations autres que taxons et modification de la table MoF en conséquence.</caption><thead><tr><th>occurrenceID</th><th>parentEventID</th><th>recordNumber</th><th>eventDate</th><th>decimalLatitude</th><th>decimalLongitude</th><th>geodeticDatum</th><th>gridRef</th><th>entityID</th><th>entityType</th><th>entityScope</th><th>entityName</th><th>entityFamily</th><th>entityScope</th><th>basicOffRecord</th><th>occurrenceStatus</th></tr></thead><tbody><tr><td>occ1</td><td>effort1</td><td>55538-14-8</td><td>2018/03/06 14:38:36-00</td><td>51.07243333333333</td><td>2.03597833333333</td><td>4326</td><td>60939</td><td>TAXREF</td><td>196139</td><td>1</td><td>pod</td><td>Harbour porpoise</td><td>Phocoena phocoena</td><td>Phocoenoid</td><td>taxa</td><td>HumanObservation</td><td>present</td></tr><tr><td>occ2</td><td>offEffort1</td><td>5302-15-8</td><td>2018/03/07 06:42:34-00</td><td>51.29337</td><td>1.522095</td><td>4326</td><td>60776</td><td>TAXREF</td><td>193036</td><td>2</td><td>pod</td><td>Grey seal (Atlantic seal)</td><td>Halichoerus grypus</td><td>Phocoide</td><td>taxa</td><td>HumanObservation</td><td>present</td></tr><tr><td>occ3</td><td>offEffort1</td><td>5558-5-8</td><td>2017/06/13 07:29:11-00</td><td>51.04080166667</td><td>2.04301333333333</td><td>4326</td><td>BUOY</td><td>Pelagis</td><td>1</td><td>entity</td><td></td><td>Fishing buoy, setnet</td><td></td><td>Buoy</td><td>Human activity</td><td>HumanObservation</td><td>present</td></tr></tbody></table>

<table><thead><tr><th>measurementID</th><th>eventID</th><th>measurementType</th><th>measurementValue</th><th>measurementUnit</th></tr></thead><tbody><tr><td>meas1:effort1</td><td>effort1</td><td>status</td><td>BEGIN</td><td></td></tr><tr><td>meas2:effort1</td><td>effort1</td><td>cycle</td><td>1</td><td></td></tr><tr><td>meas3:effort1</td><td>effort1</td><td>subjective</td><td>GM</td><td></td></tr><tr><td>meas4:effort1</td><td>effort1</td><td>seaState</td><td>3</td><td>Douglas scale</td></tr><tr><td>meas5:effort1</td><td>effort1</td><td>computer</td><td>B</td><td></td></tr><tr><td>Meas6:effort1</td><td>effort1</td><td>transect</td><td>N3/101</td><td></td></tr><tr><td>meas7:effort1</td><td>effort1</td><td>routeType</td><td>LEG</td><td></td></tr><tr><td>meas1:offEffort1</td><td>offEffort1</td><td>cycle</td><td>1</td><td></td></tr><tr><td>meas2:offEffort1</td><td>offEffort1</td><td>computer</td><td>B</td><td></td></tr><tr><td>meas3:offEffort1</td><td>offEffort1</td><td>routeType</td><td>CIRCLE_BACK</td><td></td></tr></tbody></table>

Le tableau 20 expose une proposition d'évolution de la table Occurrence du Darwin Core (voir les termes en violet dans le tableau). Nous proposons de renommer certains termes par la notion d'»entity » qui pourrait alors s'appliquer à tout occurrence, que ce soit un taxon ou un objet anthropique. Nous proposons également d'utiliser le terme `entityScope` (actuellement `organismScope`) pour préciser de quel type d'occurrence il s'agit (`taxa/human activity`). Le terme `entityID` (actuellement `taxonID`) permettrait de standardiser les identifiants liés à des référentiels ou typologies spécifiques (par exemple les codes objet des suivis menés par l'observatoire Pelagis). En conséquence, la table MoF s'en trouve grandement allégée, facilitant la lisibilité du jeu de données.

## 6.4. Tables de standardisation du jeu de données LEDKOA avec le SOT V3.0

Par soucis de lisibilité seuls quelques enregistrements sont présentés dans cet exercice, représentatifs des différents types d'enregistrements du jeu de données.
<table><caption>Tableau 21 : Tables de standardisation des concepts RegroupementEvenements, Evenement, SujetObservation et DescriptifSujet 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>typeLocalisation</th><th>X</th><th>Y</th><th>codeEPSG</th><th></th><th></th></tr></thead><tbody><tr><td>sessionEffort1</td><td>Session d'effort de prospection regroupant des observations</td><td>L25-4-B</td><td>false</td><td>5</td><td>51.6109516667</td><td>2.9620366667</td><td>4326</td><td></td><td></td></tr><tr><th colspan="10">idSinpEvenement</th></tr><tr><th>event1</th><th>S29-14-B</th><th>sessionEffort1</th><th></th><th>statutSource</th><th>dateExacte</th><th>heureExacte</th><th>typeLocalisation</th><th>Y</th><th>X</th><th>codeEPSG</th><th>methodeCollecte</th><th>commentaireEvenement</th></tr><tr><td></td><td></td><td></td><td></td><td>Te</td><td>2018/03/06</td><td>06:42:34</td><td>5</td><td>51.29337</td><td>1.522095</td><td>4326</td><td>2004</td><td>Observation d'une espèce lors d'une session d'effort</td></tr><tr><th>event2</th><th>S3-15-B</th><th></th><th></th><th>Te</th><td>2018/03/07</td><td>06:27:53</td><td>5</td><td>51.05767</td><td>1.79294833333</td><td>4326</td><td>2004</td><td>Observation d'une espèce hors d'une session d'effort</td></tr><tr><th>event3</th><th>S102-15-B</th><th></th><th></th><th>Te</th><td>2017/06/14</td><td>06:27:53</td><td>5</td><td>51.12205166667</td><td>1.92201833333</td><td>4326</td><td>2004</td><td>Observation d'une activité humaine hors d'une session d'effort</td></tr><tr><th colspan="10">idSinpSujetObs</th></tr><tr><th>sujetobs1</th><th>event1</th><th></th><th>2</th><th>statutObservation</th><th>cdNom</th><th>nomCite</th><th></th><th></th><th></th><th></th><th></th><th></th></tr><tr><th>sujetobs2</th><th>event2</th><th></th><th>2</th><th></th><th>60939</th><th>Phocoena phocoena</th><th></th><th></th><th></th><th></th><th></th><th></th></tr><tr><th>sujetobs3</th><th>event3</th><th></th><th>2</th><th></th><th>60776</th><th>Phoque gris</th><th></th><th></th><th></th><th></th><th></th><th></th></tr><tr><th colspan="10">idSinpDescriptif</th></tr><tr><th>descriptif1</th><th>sujetObs1</th><th></th><th>1140</th><th>techniqueCollecte</th><th>objetDenombrement</th><th>methodeDenombrement</th><th>denombrementMin</th><th>denombrementMax</th><th></th><th></th><th></th><th></th></tr><tr><th>descriptif2</th><th>sujetObs2</th><th></th><th>1140</th><th></th><th>IND</th><th>Co</th><th>7</th><th>7</th><th></th><th></th><th></th><th></th></tr><tr><th>descriptif3</th><th>sujetObs3</th><th></th><th>1140</th><th></th><th>IND</th><th>Co</th><th>1</th><th>1</th><th></th><th></th><th></th><th></th></tr></tbody></table>

La première table (marron) du tableau 21 présente la standardisation des informations dans le concept RegroupementEvenements. Un regroupement est nécessaire pour standardiser ce jeu de données : un regroupement d'observations par effort de prospection (regroupe les observations réalisées pendant un effort de prospection (LEG)). Pour cet exercice, l'identifiant unique SINP du regroupement (idSinpRegroupement), qui selon les règles du standard devrait être un UUID, a été simplifié pour faciliter la compréhension de la standardisation (« sessionEffort1 »). L'identifiant d'origine de l'effort renseigné dans le jeu de données est standardisé par l'attribut idOrigineRegroupement (« L25-4-B »). Cet attribut permet un retour facilité vers les données.

La deuxième table (orange) présente les trois types d'évènements rencontrés dans le jeu de données (voir commentaireEvenement) : les observations d'espèces réalisées lors d'un d'effort (rattachées au regroupement d'évènements effort), les observations d'espèces réalisées hors effort (non rattachées au regroupement) et les observations d'activité humaines qui peuvent être réalisée dans ou hors effort (dans le tableau 21, seul le deuxième type est présenté).

Les identifiants d'origine des observations sont standardisés dans l'attribut idOrigineEvenement et l'identifiant du regroupement est reporté dans l'attribut idSinpRegroupement (pour évènement d'observation en effort).

L'identifiant du jeu de données - qui est obligatoire - est bloquant pour l'intégration des données en base (utilisant le standard SOT) 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 les données du 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). L'attribut statutSource est un attribut obligatoire du concept Evenement et permet d'indiquer que l'évènement est issu du terrain via la valeur Te (et non pas de la littérature par exemple).

Ainsi, à chaque évènement d'observation est liée un sujet d'observation : pour ce jeu de données une espèce ou une activité humaine. Les observations d'espèces 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'observation d'espèce est utilisé l'attribut cdNom (identifiant unique du taxon dans le référentiel TaxRef).

Enfin, le dénombrement des espèces observées sont standardisées par le concept DescriptifSujet (table grise du tableau 21). La technique de collecte telle que référencée dans le référentiel national Campanule est également indiquée pour améliorer la réutilisation des données.

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 22).
<table><caption>Tableau 22: Table de standardisation du concept AttributAdditionnel du SOT V3.0 pour le jeu de données LEDKOA</caption><thead><tr><th>idSinpEvenement</th><th>idSinpSujetObs</th><th>idSinpRegroupement</th><th>nomAttributAdd</th><th>definitionAttributAdd</th><th>valeurAttributAdd</th><th>uniteAttributAdd</th></tr></thead><tbody><tr><td></td><td></td><td>sessionEffort1</td><td>strate</td><td>Strate d'échantillonnage</td><td>N3</td><td></td></tr><tr><td></td><td></td><td>sessionEffort1</td><td>status</td><td>Statut du point de parcours (en effort), BEGIN= Debut du parcours; ADD= changement de conditions; END= fin du parcours</td><td>BEGIN</td><td></td></tr><tr><td></td><td></td><td>sessionEffort1</td><td>transect</td><td>Identifiant du transect</td><td>N3/108</td><td></td></tr><tr><td></td><td></td><td>sessionEffort1</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></td><td></td><td>sessionEffort1</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></td><td>sessionEffort1</td><td>legLenKm</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>routeType</td><td>Type de trajet. LEG = en effort, Circle_back et TRANSIT = hors effort d'observation</td><td>LEG / TRANSIT / CIRCLE_BACK</td><td></td></tr><tr><td>event3</td><td></td><td></td><td>session</td><td>Session de vol de la campagne</td><td>1</td><td></td></tr><tr><td></td><td>sujetobs2/3</td><td></td><td>taxon</td><td>Classification supérieure de l'objet ou du taxon observé</td><td>Activité humaine / mammifère marin</td><td></td></tr><tr><td></td><td>sujetobs2/3</td><td></td><td>species</td><td>Code espèce de l'observation ou code objet</td><td>PHOPHO / BUOY</td><td></td></tr><tr><td></td><td>sujetobs3</td><td></td><td>familleAutreObjet</td><td>Famille ou sous-famille d'objet observé</td><td>Bouee</td><td></td></tr><tr><td></td><td>sujetobs3</td><td></td><td>quantiteAutreObjet</td><td>Dénombrement d'objet observé</td><td>1</td><td>Entité</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 réalisée. Toutes les informations portant sur l'observation d'un objet sont alors standardisées en attribut additionnel d'un sujet d'observation (objet).

## 6.5. Tables de standardisation du jeu de données ASPE avec le Darwin Core

<figure><img src="image_36.png" /><figcaption>Figure 24 : Étape intermédiaire de schématisation de l'organisation des éléments du jeu de données ASPE</figcaption></figure>

La figure 24 présente une des étapes préliminaires au modèle conceptuel de données. Elle correspond à la figure 12 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 23 : 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>geodeticDatum</th><th>eventID</th><th>samplingProtocol</th><th>verbatimLocation</th><th>samplingSize</th><th>samplingValue</th><th></th><th>eventType</th><th>eventRemarks</th></tr></thead><tbody><tr><td>station1</td><td></td><td>4613007</td><td></td><td></td><td>Centre-Val-de-Loire</td><td>Indre-et-Loire</td><td>Beaumont-La-Rence</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><td></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>Pont de la D29 - Lieu-dit Mosques-Souris</td><td></td><td></td><td>point</td><td>No occurrences</td><td></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></td><td>Pêche complète à un ou plusieurs passages</td><td></td><td></td><td>operation</td><td>No occurrences</td><td></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></td><td>Observation session</td><td></td></tr></tbody></table>

Le tableau 23 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 24 : 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 24 présente les occurrences liées à chaque évènements (voir tableau 23). 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 25 : 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/ind1</td><td>fishSize</td><td>162</td><td>millimeters</td></tr><tr><td>Batch1/ind1/mea2</td><td>batch1/ind1</td><td>batch1/ind1</td><td>realSizeMeasurement</td><td>yes</td><td></td></tr><tr><td>Batch1/ind1/mea3</td><td>batch1/ind1</td><td>batch1/ind1</td><td>fishWeight</td><td>x</td><td>grams</td></tr><tr><td>Batch1/ind1/mea4</td><td>batch1/ind1</td><td>batch1/ind1</td><td>fishPathology</td><td>no</td><td></td></tr><tr><td>Batch3/ind68/mea1</td><td>batch3/ind68</td><td>batch3/ind68</td><td>fishSize</td><td>79</td><td>millimeters</td></tr><tr><td>Batch3/ind68/mea2</td><td>batch3/ind68</td><td>batch3/ind68</td><td>realSizeMeasurement</td><td>no</td><td></td></tr><tr><td>Batch3/ind68/mea3</td><td>batch3/ind68</td><td>batch3/ind68</td><td>fishWeight</td><td>x</td><td>grams</td></tr><tr><td>Batch3/ind68/mea4</td><td>batch3/ind68</td><td>batch3/ind68</td><td>fishPathology</td><td>no</td><td></td></tr></tbody></table>

La tableau 25 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).

## 6.6. Tables de standardisation du jeu de données ASPE avec le SOT V3.0
<figure><img src="image_37.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 25 : Modèle conceptuel de la standardisation du jeu de données ASPE avec le standard OccTax V2</caption>

La figure 25 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="13">¹³ https://inpn.mnhn.fr/docs-web/docs/download/271850</footnote>
<figure><img src="image_38.png" /><figcaption>Figure 26 : É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 26 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 25). 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 26: 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 26 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 27 : 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 27 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 28: 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 28 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 29: 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 29 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 30: 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 30 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 31: 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>operationObjectiPeche</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 31 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