# Vers une approche basée sur les graphes de connaissances pour l'évaluation de la qualité des données dans l'IoT

Oumaima Amal, Nathalie Hernandez, Thierry Monteil

## ► To cite this version:

Oumaima Amal, Nathalie Hernandez, Thierry Monteil. Vers une approche basée sur les graphes de connaissances pour l'évaluation de la qualité des données dans l'IoT. Ingénierie des Connaissances (Evènement affilié à PFIA 2025), AFIA - Association Française pour l'Intelligence Artificielle, Jul 2025, Dijon (Bourgogne), France. hal-05493805

HAL Id: hal-05493805

https://hal.science/hal-05493805v1

Submitted on 4 Feb 2026

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

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

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

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Vers une approche basée sur les graphes de connaissances pour l'évaluation de la qualité des données dans l'IoT

Oumaima Amal<fnref n="1" />, Nathalie Hernandez<fnref n="2" />, Thierry Monteil<fnref n="1" />

¹ IRIT, Université de Toulouse, INSA Toulouse, France

² IRIT, Université Toulouse 2 Jean Jaurès, Toulouse, France

prénom.nom@irit.fr

## Résumé

L'évaluation de la qualité des données (QD) dans les systèmes IoT constitue un défi en raison de l'hétérogénéité des données, de leur production en flux continus et des environnements dynamiques dans lesquels elles sont produites. Les approches existantes se limitent souvent à un nombre restreint d'indicateurs de qualité. Cet article propose une approche granulaire et traçable reposant sur des graphes de connaissances (GC) pour enrichir et annoter les données avec des informations détaillées sur leur qualité. Celle-ci prend en compte divers indicateurs en fonction du contexte de production des données et de la tâche cible. Trois niveaux de granularité sont définis afin de structurer l'évaluation des indicateurs de QD, et des ontologies dédiées à cette évaluation sont présentées dans le cadre de ce travail.

## Mots-clés

QD, granularités d'évaluation, GC, ontologies, énergie

## Abstract

Evaluating data quality (DQ) in IoT systems is challenging due to their heterogeneity, real-time generation, and the dynamic environments in which they operate. Existing approaches often focus on a limited set of quality indicators. This paper proposes a granular and traceable approach based on knowledge graphs (KG) to enrich and annotate data with detailed quality information. It considers various indicators depending on the data production context and the target task. Three levels of granularity are defined to structure the evaluation of DQ indicators, and ontologies dedicated to this assessment are presented as part of this work.

## Keywords

DQ, assessement granularities, KG, ontologies, energy

## 1 Introduction

L'évaluation de la qualité des données (QD) constitue une étape incontournable dans la gestion des données. Face à la quantité massive de données générées, reçues ou stockées par les dispositifs interconnectés, leur transmission requiert une réflexion approfondie sur leur qualité afin de garantir une optimisation des données transmises. L'étude [13] propose un cadre parmi les plus couramment utilisés, structu-

rant un ensemble d'indicateurs de QD en quatre catégories : intrinsèque, contextuelle, représentationnelle et accessibilité. Certaines analyses, comme celle de [12], distinguent les indicateurs s'appliquant à une valeur unique de ceux s'appliquant à un ensemble de données.

Dans ce travail, nous proposons des niveaux de granularité spécifiques aux environnements IoT. En effet, l'évaluation de la QD ne se limite pas à étudier une ou plusieurs valeurs, mais à considérer la ou les valeurs dans le contexte dans lequel elles sont produites. Nous nommons une valeur et son contexte une observation. L'évaluation d'un ensemble de données diffère selon que ces observations proviennent d'un même dispositif ou de plusieurs dispositifs distincts. L'objectif de cet article est alors d'introduire une approche permettant de calculer des indicateurs de QD en prenant en compte ces niveaux de granularité. Une valeur ajoutée de cette approche réside dans l'utilisation d'ontologies, assurant une traçabilité du processus d'évaluation de la QD. Cet article est structuré comme suit : la Section 2 introduit les indicateurs de QD et décrit les ontologies utilisées pour représenter les observations, notamment Sensor, Observation, Sample, and Actuator (SSN/SOSA)<fnref n="1" /> et Extensible Observation Ontology (OBOE)<fnref n="2" />, ainsi que celle dédiée à la modélisation de la QD dont Data Quality Vocabulary (DQV)<fnref n="3" />. La Section 3 introduit les différents niveaux de granularité d'évaluation, une revue des indicateurs selon ces niveaux et décrit l'ontologie proposée Data Quality Assessment (DQA). La Section 4 présente les principales étapes de notre approche pour l'évaluation de la QD.

## 2 État de l'art : Indicateurs de QD et Ontologies

Dans cet article, nous considérons un exemple de base simple pour l'étude des indicateurs de QD et des ontologies permettant de les décrire. Nous prenons comme cas d'usage illustratif cinq dispositifs installés dans une salle de classe d'un bâtiment d'un campus. Nous considérons cinq capteurs, dont deux sont des capteurs de présence, et trois

<footnote n="1">1. https://www.w3.org/TR/vocab-ssn/</footnote>

<footnote n="2">2. https://bioportal.bioontology.org/ontologies/OBOE</footnote>

<footnote n="3">3. https://www.w3.org/TR/vocab-dqv/</footnote>
sont intégrés à trois plateformes : un climatiseur, un vidéo-
projecteur et un système de ventilation. Ces trois capteurs
sont utilisés pour suivre leur consommation énergétique (en
watts) sous forme d'observations. Ce cas d'usage est décrit
via des ontologies qui seront introduites dans les sections
suivantes du papier (Voir figure 2).

**2.1 Indicateurs de QD existants**

Les indicateurs de QD ont été largement étudiés dans la lit-
térature. L'un des cadres les plus couramment utilisés pour
les classifier est celui proposé par [13], qui définit quatre
grandes catégories de QD : intrinsèque, contextuelle, re-
présentationnelle et accessibilité (Voir figure 1). Nous ne
considérons pas l'étude des indicateurs liés à l'accessibilité
qui pourra être réalisée dans des travaux futurs, notamment
dans une perspective d'intégration de mécanismes de sécu-
rité et de contrôle d'accès. Nous introduisons les définitions
des indicateurs sans prendre en considération les méthodes
utilisables pour les quantifier, notre objectif est de fournir
un cadre général se concentrant sur leur finalité.

<figure><img src="image_2.png" /><figcaption>FIGURE 1 – Catégories et indicateurs de la QD</figcaption></figure>

**Indicateurs intrinsèques** : cette catégorie inclut des di-
mensions qui peuvent être évaluées indépendamment de la
tâche pour laquelle les données produites seront utilisées.
L'évaluation de la QD intrinsèque se concentre sur les pro-
priétés inhérentes à la valeur des données elle-même. Nous
présentons les définitions des indicateurs intrinsèques :

**Précision** : Dans [9], les auteurs définissent la précision comme le degré avec lequel les valeurs mesurées sont proches les unes des autres. Nous retenons cette définition.

**Exactitude** : Dans [4] et [1], les auteurs décrivent l'exactitude comme le degré de proximité d'une valeur par rapport à une valeur de référence dans le domaine, tandis que pour [5], l'exactitude est appelée correction et correspond au degré avec lequel les données sont conformes à une valeur attendue ou à un ensemble de valeurs acceptables prédéfinies. Pour nous, l'exactitude est le degré avec lequel la valeur est proche d'une valeur réalistee attendue. e.g. : le capteur sensor#08 rapporte à 2025-01-31T09:00:00 une observation (obs_020) avec une valeur de 330.00W. La consommation attendue pour la plateforme videoprojector#65 est entre 100W et 500W. Comme la valeur observée est dans l'intervalle, l'exactitude est fixée à 100%.

Provenance : Dans [10], la provenance est la possi-

bilité de connaître la source des données ainsi que la des-
cription de cette source. Elle fait référence au suivi et à
la documentation de l'origine des données et du proces-
sus par lequel les données ont été générées, collectées ou
transformées. Nous utiliserons la même définition dans ce
travail. e.g. : l'observation obs_003 est générée par le
capteur sensor#53, qui est hébergé sur la plateforme
airconditionner#32.

**Cohérence** : Selon [6], [9], et [11], la cohérence des données est définie comme le degré, exprimé en pourcentage, avec lequel deux ou plusieurs valeurs dans un ensemble de données ne sont pas contradictoires. Nous suivons cette définition en considérant que ces valeurs, qu'elles proviennent d'un seul appareil ou de plusieurs sources produisant des données similaires, doivent respecter des règles ou des contraintes prédéfinies, telles que des relations logiques ou des lois physiques. e.g. l'observation obs_015, capturée par le capteur sensor#08 à 2025-01-31T09:00:00, indique une puissance consommée de 290W pour videoprojector#65. Cependant, si l'observation suivante obs_016, réalisée par le même capteur, mesure 600W, cette variation soudaine et inexpliquée diminue le degré de cohérence des observations.

**Duplication** : Selon [4], la duplication fait référence à la présence de valeurs distinctes pour le même attribut de la même entité dans un ensemble de données. Nous considérons alors qu'il y a une duplication lorsque deux valeurs identiques ou plus sont présentes dans un ensemble de données, bien qu'elles soient censées être distinctes en fonction de la fréquence attendue de génération des observations. e.g. Deux observations distinctes, obs_004 et obs_003, générées par le capteur sensor#53 à la même date et heure (2025-01-31T08:30:00), contiennent exactement la même valeur de consommation énergétique (2200.0W). Cela indique une duplication des données.

**Indicateurs contextuels** : cette catégorie englobe des attributs qui dépendent du contexte d'utilisation, en particulier en lien avec la tâche à accomplir. Contrairement à la QD intrinsèque, la QD contextuelle ne peut être évaluée sans prendre en compte le contexte ou/et l'objectif pour lesquels les données sont utilisées. Nous introduisons les définitions des indicateurs contextuels :

**Ponctualité** : Selon [9], la ponctualité fait référence à l'âge des données, qui doit être approprié pour la tâche à accomplir. Elle évalue si les données sont disponibles au moment requis et respectent les délais prévus pour leur utilisation. Nous suivons cette définition en considérant que des données ponctuelles doivent être reçues et traitées dans un délai compatible avec les exigences de la tâche cible. e.g. supposons qu'une tâche nécessite des observations dans les 30 dernières minutes en temps réel. Si le capteur sensor#53 fournit des données toutes les 15 min et que l'observation obs_010 arrive avec un retard de 20 min, elle dépasse la fenêtre de 30 min et devient obsolète, ce qui peut impacter les résultats obtenus.

Complûtude : Selon [11], la complûtude correspond
au degré avec lequel les données fournissent les valeurs at-
tendues pour les caractéristiques requises dans un contexte d'utilisation donné. Dans [12], elle est définie par la présence de valeurs pour toutes ces caractéristiques. Pour nous, elle correspond à la présence de valeurs ou instances attenues pour les propriétés et entités requises afin de répondre aux besoins d'une tâche spécifique. e.g. les observations obs_001 à obs_010 sont considérées complètes si et seulement si le capteur capture des valeurs pour la propriété observée power consumption pour toutes ces observations.

**Pertinence** : Pour [7], la pertinence fait référence aux données répondant aux besoins pour lesquels elles ont été collectées, placées dans une base de données et utilisées. Pour nous, la pertinence fait référence au degré d'importance des valeurs des données pour un objectif prédefini. Elle est relative et dépend forcément de l'évaluation des autres indicateurs de qualité. e.g. les observations obs_001 à obs_010 sont pertinentes si et seulement si elles sont complètes.

**Indicateurs représentationnels** : cette catégorie se concentre sur le format et l'interprétabilité des données. Elle inclut les indicateurs suivants :

**Interprétabilité** : La description de la donnée attendue est claire en termes de langue, symbole et unité. De plus, la donnée considérée peut être associée à la description correspondante.

**Concision** : La concision est définie par [13] et [2] comme le degré avec lequel les données sont représentées de manière compacte.

**Cohérence Représentationnelle** : Dans [9], il est mentionné que la cohérence représentationnelle fait référence au fait que les données doivent être présentées dans des formats compatibles.

**Facilité de Compréhension** : Selon [5], la compréhension est liée à la clarté des données, qui doivent être sans ambiguïté. Pour nous, l'évaluation de ce critère repose sur l'analyse des trois indicateurs précédents.

## 2.2 SOSA et OBOE : Ontologies pour la description des observations

Selon [8], l'ontologie SOSA<fnref n="4" /> est un cadre léger conçu pour modéliser et décrire les interactions et les fonctionnalités des capteurs, des actionneurs, ainsi que les processus d'observation et d'échantillonnage. Elle a été développée dans le cadre d'un effort collaboratif entre l'Open Geospatial Consortium (OGC) et le World Wide Web Consortium (W3C) afin de répondre aux besoins des développeurs web, des scientifiques de domaine et des ingénieurs en données liées. Dans le cadre de l'exemple considéré au début de cet article (Voir la figure 2), la salle de classe est modélisée comme une sosa:FeatureOfInterest, identifiant le contexte spatial des observations représentées par la classe sosa:Observation.

<figure><img src="image_3.png" /><figcaption>FIGURE 2 – Exemple illustratif de GC avec SOSA et OBOE</figcaption></figure>

Les observations, générées par des capteurs définis à travers la propriété sosa:madeBySensor, mesurent la consommation d'énergie via la propriété powerConsumption de type sosa:observedProperty, indiquant ce qui est mesuré. La donnée produite par un capteur est exprimée via la propriété hasSimpleResult lorsqu'il s'agit d'une valeur numérique simple. Enfin, l'instant de production de chaque observation est enregistré grâce à la propriété sosa:resultTime, permettant de la situer dans son contexte temporel. Chaque observation, comme obs_003 ou obs_020, suit ce même schéma de description. Au-delà de la description fournie par SOSA, l'ontologie OBOE facilite la représentation d'une collection d'observations oboe:Observation qui peut être liée à plusieurs observations sosa:Observation (l'équivalent de oboe:Measurement<fnref n="5" />) via la propriété oboe:hasMeasurement.

## 2.3 DQV : Ontologie pour l'évaluation de la QD

L'ontologie Data Quality Vocabulary - DQV<fnref n="6" /> (Voir la figure 4), constitue un cadre général pour décrire la QD. Bien qu'il ne vise pas à fournir une définition formelle et exhaustive de la qualité, il établit une approche cohérente pour partager des informations de qualité, permettant aux utilisateurs d'évaluer la pertinence d'un jeu de données pour leurs besoins spécifiques. Conçue comme une extension du vocabulaire Data Catalog Vocabulary - DCAT<fnref n="7" />, DQV s'appuie sur les travaux antérieurs de représentation de la QD, notamment l'ontologie Dataset Quality Vocabulary - daQ [3], qui se concentre sur la capture d'informations en particulier des métriques, relatives à la qualité des jeux de données. DQV va au-delà en proposant une structure plus flexible, intégrant des aspects tels que les annotations, les politiques

<footnote n="4">4. https://github.com/w3c/sdw</footnote>

<footnote n="5">5. https://www.w3.org/ns/sosa/oboe</footnote>

<footnote n="6">6. https://www.w3.org/TR/vocab-dqv/</footnote>

<footnote n="7">7. https://www.w3.org/TR/vocab-dcat-3/</footnote>
et les certifications de qualité, offrant ainsi une description plus riche.

DQV comprend des classes principales telles que `dqv:Dimension`, qui représente les dimensions ou indicateurs de la qualité. Il y a aussi `dqv:Category`, qui permet de classer ces dimensions en différentes catégories. La classe `dqv:Metric` définit les métriques associées à chaque dimension. Enfin, `dqv:QualityMeasurement` associe les valeurs des mesures obtenues en appliquant ces métriques. Les propriétés principales incluent `dqv:inDimension` reliant une métrique à la dimension correspondante, `dqv:inCategory` reliant une dimension à une catégorie, `dqv:expectedDataType` qui spécifie le type de données attendu pour chaque métrique, et `dqv:value` qui attribue une valeur mesurée à une métrique. En complément, des propriétés issues de SKOS (Simple Knowledge Organization System), comme `skos:prefLabel` et `skos:definition`, enrichissent la représentation des dimensions et des métriques, en précisant leurs labels et définitions.

# 3 Granularités d'évaluation de QD et Ontologie DQA

## 3.1 Niveaux de granularité

L'étude [12] est l'une des rares à explorer la notion de granularité dans l'évaluation de la QD, en faisant la distinction entre points de données individuels (cellules) et ensembles de données. Bien qu'intéressante, elle ne prend pas en compte les cas intermédiaires ni les défis posés par les données IoT, où les observations peuvent être liées par le temps, l'espace ou le contexte. Nous proposons une catégorisation qui évalue la QD à travers trois niveaux (Voir figure 3), permettant ainsi de mieux structurer l'évaluation des indicateurs de QD dans l'approche qui est prévue pour être déployable dans un réseau d'objets IoT :

<figure><img src="image_4.png" /><figcaption>FIGURE 3 – Granularités d'évaluation</figcaption></figure>

- **Observations uniques, UO**: Celles-ci représentent des observations individuelles sur une mesure unique à un instant précis.

- **Ensemble d'observations provenant d'un seul dispositif, SO-SD**: À ce niveau, les observations proviennent d'un seul dispositif et mesurent une même propriété sur un intervalle de temps.

- **Ensemble d'observations provenant de plusieurs dispositifs, SO-MD**: Les observations, à ce niveau, sont issues de plusieurs dispositifs portant sur une

ou plusieurs propriétés qui sont considérées en fonction de l'objectif d'utilisation de ces observations.

## 3.2 Indicateurs revus par rapport aux niveaux

Dans cette partie, nous présentons une analyse des indicateurs introduits dans 2.1 en fonction des niveaux de granularités proposés dans 3.1, comme le montre le tableau 1. Les indicateurs marqués par * sont évalués selon des conditions supplémentaires au niveau SO-MD.

<table><caption>TABLE 1 – Indicateurs par niveaux de granularité</caption><thead><tr><th>Indicateur</th><th>UO</th><th>SO-SD</th><th>SO-MD</th></tr></thead><tbody><tr><td>Exactitude</td><td>X</td><td></td><td></td></tr><tr><td>Précision</td><td></td><td>X</td><td>X*</td></tr><tr><td>Provenance</td><td>X</td><td>X</td><td>X</td></tr><tr><td>Cohérence</td><td></td><td>X</td><td>X</td></tr><tr><td>Duplication</td><td></td><td>X</td><td>X*</td></tr><tr><td>Compléture</td><td></td><td>X</td><td>X*</td></tr><tr><td>Ponctualité</td><td></td><td>X</td><td>X</td></tr><tr><td>Pertinence</td><td>X</td><td>X</td><td>X</td></tr><tr><td>I. Représentationels</td><td>X</td><td>X</td><td>X</td></tr></tbody></table>

Le croisement des indicateurs de QD avec les niveaux de granularité permet de mettre en évidence que l'évaluation de ces indicateurs peut varier en fonction du niveau de granularité. L'application de tous les indicateurs nécessite l'acquisition des valeurs des observations (e.g. les valeurs associées aux observations `obs_001`, `obs_002`, ...), les capteurs qui les génèrent (e.g. `sensor#53`, `sensor#19`, ...), les plateformes qui les hébergent (e.g. `airconditionner#32`, `ventilationsys#07`, ...) et qui sont en fonctionnement ainsi que la propriété observée (e.g. `powerConsumption`). Certains indicateurs sont évalués uniquement au niveau UO, ce qui permet de garantir un marquage de qualité unitaire pour chaque valeur observée; c'est le cas de l'exactitude par exemple. Par ailleurs, au niveau de SO-SD qui peuvent être constituées de plusieurs observations UO, l'évaluation des indicateurs de QD est requise en raison de son importance pour faciliter la sélection des observations ayant un niveau de qualité suffisant pour être soit comparées, soit fusionnées avec d'autres observations pour des évaluations ultérieures de QD au niveau SO-MD. Pour les ensembles d'observations SO-SD et SO-MD qui ne sont pas marqués par (*), les indicateurs de QD sont évalués selon les définitions présentées dans la section 2.1. Cependant, certains indicateurs, tels que la compléture, la précision et la duplication, peuvent nécessiter des conditions particulières d'application, notamment au niveau SO-MD. Ces conditions sont expliquées via l'exemple suivant. Pour clarifier, prenons l'exemple de deux ensembles d'observations, `obsCollection1` et `obsCollection2`, générées respectivement par les capteurs `sensor#53` et `sensor#73`, qui mesurent la même propriété `powerConsumption` et sont hébergés par des plateformes du même type. Pour la compléture, si les deux capteurs générant `obsCollection1`
et obsCollection2 ont respectivement des pas de temps différents (e.g. 5min et 10min), il devient pertinent d'évaluer si les deux ensembles peuvent être combinés pour former une collection unique. Cela permettrait, par exemple, de compléter les données manquantes dans une collection. Concernant l'évaluation de la précision, il est également possible de combiner les deux ensembles obsCollection1 et obsCollection2 pour évaluer la précision globale d'une seule mesure (e.g. powerConsumption). Enfin, pour l'évaluation de la duplication, il est possible de comparer les ensembles obsCollection3 et obsCollection4 issus des capteurs de présence sensor#19 et sensor#20, à condition qu'ils observent le même phénomène d'intérêt, measurent la même propriété aux mêmes timestamps.

## 3.3 DQA : Extension proposée pour DQV

Data Quality Assessment - DQA<fnref n="8" /> est une extension proposée de l'ontologie DQV (Voir la figure 4). Elle enrichit le modèle DQV en introduisant de nouveaux concepts et relations pour une évaluation plus détaillée et traçable de la QD. DQA conserve les classes fondamentales de DQV, notamment dqv:Dimension, dqv:QualityMeasurement, et dqv:Metric.

<figure><img src="image_5.png" /><figcaption>FIGURE 4 – Vocabulaires DQA/DQV</figcaption></figure>

DQA introduit dqa:QualityAssessmentProcess, comme une classe qui permet de décrire le processus d'évaluation de la QD pour garantir la traçabilité des méthodes utilisées. Ces méthodes sont définies par la classe dqa:AssessmentMethod. Les méthodes basées sur des formules sont représentées par dqa:FormulaBasedMethod, tandis que celles permettant de récupérer les sources et leurs descriptions contenues dans le GC sont décrites par dqa:SourceBasedMethod. La propriété dqa:findsSource est associée aux méthodes dqa:SourceBasedMethod et permet de décrire la

source retrouvée dans le GC, si elle existe. (Voir exemples<fnref n="9" /> pour la provenance, l'exactitude et la duplication.)

Afin de structurer davantage l'évaluation, DQA introduit la classe dqa:AssessmentGranularity, qui précise le niveau de granularité des évaluations. Cette classe se décline en dqa:GranularitySO pour un Set of Observations et dqa:GranularityUO pour une Unique Observation. De plus, la classe dqa:AssessmentLabel permet d'étiquer les résultats des évaluations et est associée à un seuil, défini par la propriété dqa:labelThreshold. Par ailleurs, la propriété dqa:assessIndicator relie un processus d'évaluation à un indicateur de qualité, tandis que dqa:producesResult capture la sortie d'un processus d'évaluation sous forme de mesure de qualité. L'association entre un processus et une méthode spécifique est représentée par dqa:usesMethod, et la granularité de l'évaluation est précisée par dqa:hasGranularity. Enfin, la mesure obtenue est qualifiée par un label à l'aide de la propriété dqa:hasLabel.

# 4 Vers une approche d'évaluation granulaire et traçable de la QD

L'approche suit trois étapes principales, comme le montre la figure 5, et s'appuie sur les ontologies SOSA, OBOE, DQV et DQA pour assurer la modélisation des processus d'évaluation des indicateurs de QD tout en prenant en compte les niveaux de granularité. Des exemples pour chaque étape sont introduits sur GitLab<fnref n="10" />.

<figure><img src="image_6.png" /><figcaption>FIGURE 5 – Aperçu sur les trois étapes de l’approche</figcaption></figure>

## Étape 1 : Enrichissement de l'observation

La première étape consiste à recevoir une observation et à l'enrichir en utilisant l'ontologie SOSA, qui permet de structurer les relations entre les capteurs, les observations et les propriétés observées. Contrairement aux étapes suivantes, cette phase ne nécessite pas une description des traitements effectués sur l'observation en termes d'indicateurs représentationnels, parce qu'ils concernent principalement la bonne représentation des données plutôt que leur évaluation qualitative. Une fois l'enrichissement terminé, l'observation est stockée dans le dépôt de GC

<footnote n="8">8. https://gitlab.irit.fr/projet-ai-nrgy/dqa-ontology.git</footnote>

<footnote n="9">9. https://gitlab.irit.fr/projet-ai-nrgy/dqa-ontology/provenance</footnote>

<footnote n="10">10. https://gitlab.irit.fr/projet-ai-nrgy/dqa-ontology/examples</footnote>
pour être utilisée dans les phases d'évaluation.

## Étape 2 : Évaluation des indicateurs QD au niveau UO

À cette étape, les indicateurs de QD pouvant être évalués sur une observation unique (UO) sont appliqués. Ceci inclut : l'exactitude, la provenance, la pertinence et la fraîcheur. Chaque indicateur est évalué individuellement, et le résultat obtenu est stocké dans le dépôt avec une description complète du processus d'évaluation en utilisant les ontologies SOSA, DQV et DQA.

## Étape 3 : Évaluation des indicateurs QD aux niveaux SO-SD et SO-MD

Dans cette dernière étape, l'évaluation porte sur des ensembles d'observations (SO-SD et SO-MD). Deux types d'évaluation peuvent être réalisés :

- Évaluation agnostique de la tâche : certains indicateurs de QD peuvent être évalués indépendamment d'un objectif utilisateur, uniquement en tenant compte du contexte de génération des observations. Ces indicateurs incluent : la précision, la duplication et la cohérence.

- Évaluation liée à une tâche définie par l'utilisateur : lorsqu'un utilisateur définit une tâche spécifique, d'autres indicateurs de QD peuvent être nécessaires en plus des trois indicateurs précédents, dont la compléture, la ponctualité et la pertinence.

L'ontologie OBOE est utilisée pour définir les ensembles d'observations sur lesquels l'évaluation est effectuée. Les résultats de l'évaluation sont documentés via DQV, le processus d'évaluation étant décrit en utilisant DQA.

# 5 Conclusion

Cet article propose une approche basée sur les GC pour l'évaluation de la QD dans les systèmes IoT, avec une contribution principale : la structuration des indicateurs QD selon différents niveaux de granularité (UO, SO-SD, SO-MD). Dans ce travail, nous nous sommes concentrés sur le cas des dispositifs fixes, vu que l'intégration des dispositifs mobiles augmentera la complexité d'application des indicateurs de QD, mais pourra être creusée dans nos futurs travaux. Cette organisation granulaire permet une évaluation plus fine et adaptée au contexte de production des données. Nous avons également proposé une extension de DQV, nommée DQA, et réutilisé les ontologies SOSA, OBOE et DQV pour décrire et sauvegarder les métadonnées associées au processus de l'évaluation des indicateurs de QD. Nous avons défini une méthodologie pour mettre en œuvre cette approche. Le travail à venir consistera à finaliser l'implémentation en se basant notamment sur SPARQL et des règles SHACL distribuées. Cette approche sera validée dans un contexte énergétique dans le cadre du projet AI-NRGY.

# Remerciements

Ce travail a bénéficié d'une aide de l'État gérée par l'Agence Nationale de la Recherche au titre de France 2030 portant la référence 22-PETA-0004 - projet AI-NRGY.

# Références

[1] Carlo Batini and Monica Scannapieca. *Data Quality: Concepts, Methodologies and Techniques*. Springer, Berlin, 2006.

[2] John Byabazaire, Gregory O'Hare, and Declan Delaney. Data quality and trust : Review of challenges and opportunities for data sharing in iot. *Electronics, by MDPI*, 20(24):1-20, Dec 2020.

[3] Jeremy Debattista, Christoph Lange, and Sören Auer. daq, an ontology for dataset quality information. In *Proceedings of the Linked Data on the Web Workshop (LDOW 2014)*, by CEUR-WS.org, Seoul, Korea, 2014.

[4] Christopher Fox, Anany Levitin, and Thomas Redman. The notion of data and its quality dimensions. *Inf Process Manag*, by Elsevier, 30(1):9-19, 1994.

[5] Christian Fürber and Martin Hepp. Using semantic web resources for data quality management. In *Know-ledge Engineering and Management by the Masses*, by Springer, pages 211-225, Berlin, Heidelberg, 2010.

[6] Sandra Geisler, Christoph Quix, Sven Weber, and Matthias Jarke. Ontology-based data quality management for data streams. *Journal of Data and Information Quality*, by ACM, 7(4):1-34, 2016.

[7] Thomas Nelson Herzog, Fritz Joseph Scheuren, and William Edward Winkler. *Data Quality and Record Linkage Techniques*. Springer, New York, 2007.

[8] Krzysztof Janowicz, Armin Haller, Simon J.D. Cox, Danh Le Phuoc, and Maxime Lefrançois. Sosa : A lightweight ontology for sensors, observations, samples, and actuators. *Journal of Web Semantics*, by Elsevier, 56:1-10, 2019.

[9] Nisrine Makhoul. Review of data quality indicators and metrics, and suggestions for indicators and metrics for structural health monitoring. *Advances in Bridge Engineering*, by Springer Nature, 3(1):1-32, 2022.

[10] Maria Priestley, Fionntán O'Donnell, and Elena Simperl. A survey of data quality requirements that matter in ml development pipelines. *Journal of Data and Information Quality*, by ACM, 15(2):3592616, 2023.

[11] R. Pérez-Castillo, A. G. Carretero, I. Caballero, M. Rodríguez, M. Piattini, A. Mate, S. Kim, and D. Lee. Daqua-mass : An iso 8000-61 based data quality management methodology for sensor data. *Sensors*, by MDPI, 18(9):3105, 2018.

[12] Antonio Vetrò, Lorenzo Canova, Marco Torchiano, Camilo Orozco Minotas, Raimondo Iemma, and Federico Morando. Open data quality measurement framework : Definition and application to open government data. *Government Information Quarterly*, by Elsevier Ltd, 33(2):325-337, 2016.

[13] Richard Y. Wang and Diane M. Strong. Beyond accuracy : What data quality means to data consumers. *Journal of Management Information Systems*, by Taylor Francis, 12(4):5-33, 1996.