L’amélioration de la qualité des données de NAKALA : retour sur les opérations de “mise en qualité”

Depuis la mise à jour majeure de NAKALA en décembre 2020, puis la refonte complète de sa documentation en 2022, l’équipe en charge de ce service mène régulièrement des campagnes d’amélioration de la qualité des données dans l’entrepôt. Cet article présente ces chantiers.

• Éléments de contexte
• Mise en cohérence du schéma de description
• Contrôle des champs du schéma de description
• Amélioration de l’affichage de la notice descriptive des données
• Identification des formats de fichiers
• Mise à disposition de guides d’aide à la description pour les déposants

Éléments de contexte

NAKALA est un entrepôt généraliste pour le dépôt de données de recherche. Ces données sont collectées et produites dans le cadre de projets en sciences humaines et sociales, domaine qui couvre des données hétérogènes issues de différentes disciplines. C’est pourquoi le choix du Dublin Core qualifié, un schéma de métadonnées générique pour décrire tout type de ressources numériques, a été fait dans NAKALA. Ce format présente l’avantage de couvrir des besoins de description diversifiés et larges. De plus, le Dublin Core qualifié permet aux déposants de décrire précisément les données en sélectionnant les propriétés et encodages les plus adaptés à leurs dépôts.

Ouvert en 2014, l’entrepôt NAKALA contient aujourd’hui près de 800 000 données dont la qualité des descriptions est inégale. De plus, à l’usage, certains champs de description se sont révélés mal appropriés ou peu utilisés. Leur formalisme n’est pas toujours correctement respecté. Ainsi de nombreux chantiers ont été menés au cours de ces deux dernières années afin d’améliorer la qualité des données dans l’entrepôt.

Mise en cohérence du schéma de description

Une réflexion a été menée sur la mise en cohérence du schéma de métadonnées pour supprimer des propriétés et des encodages inadaptés. Ces décisions ont été guidées par une analyse de leur pertinence dans le contexte de l’entrepôt NAKALA et du constat de leur usage erroné.

L’équipe NAKALA a accompagné les déposants qui avaient utilisé les propriétés et encodages destinés à être supprimés en leur proposant des corrections et des alternatives. La mise en œuvre de ces modifications s’est faite par lots successifs et selon les étapes suivantes :

• sélection des propriétés et encodages à supprimer et investigation d’alternatives pour leur remplacement
• vérification de leur utilisation dans NAKALA
• identification des déposants qui les ont utilisés
• information par mail des changements à venir auprès des déposants pour expliquer la démarche, préciser les métadonnées concernées et les opérations qui seront effectuées (remplacement par la propriété ou l’encodage adéquat, puis suppression)
• réalisation des remplacements et suppressions à une date annoncée
• signalement des opérations dans la rubrique Mises à jour de la documentation.

Ces nettoyages ont été faits par lots successifs afin de faciliter la mise à jour du schéma techniquement et fonctionnellement.

Ainsi plusieurs propriétés (ex. owl:sameAs, foaf:page, foaf:theme, foaf:publications) ont été retirées. Et plusieurs encodages ont été remplacés par des encodages plus pertinents avant d’être supprimés (ex. les encodages dcterms:RFC3066, dcterms:ISO639-2 et dcterms:ISO639-3 ont été remplacés par dcterms:RFC5646 qui couvre l’ensemble des normes dcterms:ISO639-2 et dcterms:ISO639-3 et a rendu obsolète dcterms:RFC3066).

L’historique de ces évolutions est consigné dans les mises à jour de NAKALA.

Contrôle des champs du schéma de description

L’analyse des pratiques de description des données dans NAKALA a révélé des usages inappropriés de certaines métadonnées. Afin de faciliter et d’améliorer l’utilisation du schéma, des contrôles automatiques ont été mis en place sur des propriétés et des encodages pour contraindre le formalisme des informations renseignées et signaler les erreurs au déposant lorsqu’il enregistre le dépôt.

Les contrôles automatiques s’effectuent de deux manières :

• en associant au champ un vocabulaire contrôlé (liste fermée) dans lequel le déposant sélectionne une valeur : seules les valeurs contenues dans la liste sont acceptées.
• en contraignant la forme syntaxique de l’information pour l’adapter aux normes et standards en vigueur : seules les formes d’écriture compatibles avec la norme ou le standard sont acceptées. Dans ce cas les messages d’erreur apportent des précisions pour guider sur la manière de renseigner les informations selon les spécifications de chaque métadonnée concernée.

Contrôles des propriétés NAKALA

Les métadonnées suivantes sont contrôlées automatiquement :

• Type de dépôt : champ associé à une liste fermée composée de plusieurs vocabulaires contrôlés. Voir les précisions
• Auteurs : forme d’écriture contrainte pour la création d’un nouvel auteur avec 2 champs obligatoires à renseigner : Nom, Prénom ; et un contrôle de l’ORCID. Voir les précisions
• Date de création : format de date contraint selon les spécifications du W3C-DTF et la norme ISO 8601. Voir les précisions
• Licence : champ associé à une liste fermée (Etalab, Creative Commons, GNU, FLOSS, Rights Statement). Voir les précisions
• Langues : champ associé à une liste fermée issue des normes ISO-639-1 et ISO-639-3. Voir les précisions

Par ailleurs, via l’API, il était par exemple possible de préciser la langue des métadonnées renseignées dans les champs ‘Type de dépôt’, ‘Auteurs’ et ‘Licence’. Or il était incohérent de renseigner une langue pour des informations associées à des listes (‘Type de dépôt’ et ‘Licence’) et à des noms de personnes (‘Auteurs’). Ce point a été amélioré et dorénavant un contrôle empêche de saisir la langue dans ces trois propriétés depuis l’API.

Contrôle des encodages

Ces contrôles des propriétés vont de pair avec la mise en place de contrôles automatiques sur les encodages du champ ‘Type’ associé à une propriété du Dublin Core (zone “Ajouter d’autres métadonnées”). En effet, chaque encodage est associé à un formalisme spécifique et documenté par le DCMI – Dublin Core™ Metadata Initiative – qui précise la forme et la syntaxe des informations à saisir.

Un contrôle des informations renseignées est en place sur les encodages suivants :

• dcterms:DCMIType : champ associé à un vocabulaire contrôlé pour définir la nature ou le genre de la ressource ; pour l’utiliser dans NAKALA, voir les précisions
• dcterms:Box : sert à encoder les limites géographiques d’un espace physique ; pour l’utiliser dans NAKALA, voir ces précisions
• dcterms:Point : sert à encoder des coordonnées géographiques ; pour l’utiliser dans NAKALA, voir ces précisions
• dcterms:ISO3166 : champ associé à un vocabulaire contrôlé de l’ISO qui définit les codes pays “countryCode” ; pour l’utiliser dans NAKALA, voir ces précisions
• dcterms:Period : sert à encoder un intervalle temporel délimité ; pour l’utiliser dans NAKALA, voir ces précisions
• dcterms:W3CDTF : sert à encoder les formats de dates selon les spécifications du W3C ; pour l’utiliser dans NAKALA, voir ces précisions

Cette normalisation permet notamment aux machines d’interpréter les valeurs et de les restituer correctement dans d’autres contextes. Par exemple, des coordonnées géographiques pourront être automatiquement géolocalisées sur une carte par un système externe à NAKALA qui moissonnerait ces métadonnées. Exemple la géolocalisation sur Navigae (plateforme du consortium ImaGEO permettant de consulter des données issues de travaux en géographie) du corpus : “Sur les pas d’Emmanuel de Martonne : 3e excursion Roumanie, 1921”: https://www.navigae.fr/fieldnotes/?i=demartonne-c4. La collection dans NAKALA : https://www.nakala.fr/collection/10.34847/nkl.6cf30136

Amélioration de l’affichage de la notice descriptive des données

La notice de description des données est maintenant affichée directement sur la page de présentation de la donnée (landing page) sans avoir besoin d’ouvrir une fenêtre contextuelle.
Cela facilite la lisibilité de la donnée en permettant la consultation de toutes les informations renseignées par le déposant.
Par ailleurs, les noms des champs qui étaient affichés dans des syntaxes diverses et hétérogènes auparavant ont été homogénéisés. La notice descriptive affiche sur 4 colonnes :

1. l’intitulé du champ : une URI simplifiée pour chaque propriété basée sur un modèle commun à tous les champs de description. Par exemple : http://purl.org/dc/terms/tableOfContents est devenu dcterms:tableOfContents
2. le type d’encodage le cas échéant
3. la langue utilisée
4. la valeur (l’information renseignée par le déposant)

 

Identification des formats de fichiers

Une fonction d’identification automatique des fichiers a été ajoutée à NAKALA lors de la mise à jour du 30 septembre 2024. Les fichiers déposés font maintenant l’objet d’une identification automatique de leur format par l’outil DROID (Digital Record Object Identification).
Le résultat de cette identification est consultable par l’API dans les informations techniques de chaque fichier à travers les propriétés “mime_type” (utilisant le registre des types MIME de IANA) et “puid” (utilisant le registre PRONOM des Archives nationales du Royaume-Uni).
Le repérage de l’identifiant “puid”, plus fin que le “mime_type”, servira de base à de futurs développements comme : orienter le choix d’une visionneuse adaptée par le navigateur, ou permettre la mise en place d’opérations de conversions de formats de fichiers pour favoriser leur pérennité.

Mise à disposition de guides d’aide à la description pour les déposants

Le rôle des déposants dans la description de leurs données est prépondérant pour assurer la qualité des données. C’est pourquoi Huma-Num met à disposition un guide de description détaillé complet en ligne et un guide synthétique de 2 pages au format pdf téléchargeable.
De plus, le formulaire de dépôt en ligne propose pour chaque métadonnée une aide contextuelle accessible en cliquant sur le “?” associé à chaque champ. Les messages associés vont être mis à jour d’ici la fin de l’année 2024 afin de faciliter la compréhension du schéma de description.

---

Ces chantiers d’amélioration se poursuivent et sont décrits dans la documentation des mises à jour de NAKALA : https://documentation.huma-num.fr/nakala-release-notes/

L’équipe NAKALA peut être contactée à l’adresse nakala[@]huma-num.fr

---

---