Standardisation des données

Table des matières

Couches de normalisation
Mise en œuvre
Ressources de formation

La vision de la découverte et de la réutilisation FAIR des ensembles de données comporte un certain nombre de motivations et de défis. Des opportunités de normalisation existent à la fois au niveau du format des données du projet (syntaxe), aux niveaux de la provenance/du processus/du flux de travail/du fichier/du dossier et également en termes de signification sémantique ou de « sujet » de l’ensemble de données, qui nécessite souvent des références à la conception expérimentale, au protocole et à d’autres données contextuelles. Cela nous permet de déterminer si les ensembles de données ou les points de données sont comparables ou non, et il s’agit donc d’informations importantes sur les ensembles de données que les catalogues de données en aval doivent absorber et exploiter dans leurs interfaces de recherche.

En fin de compte, une condition essentielle au succès est un langage technique bien coordonné pour décrire les objectifs et les méthodes de recherche du projet, ainsi que les tables et les champs des ensembles de données. À l’avenir, l’intelligence artificielle associera probablement les descriptions en langage clair des utilisateurs des types de données recherchés et du contexte aux fonds de catalogues de données, mais dans tous les cas, la vision de la découverte et de la réutilisation exige que les gestionnaires de données de projet fournissent suffisamment d’informations à différents niveaux, comme indiqué ci-dessous. Nous travaillons d’abord sur une description et des recommandations sur le mélange de langage actuellement présent dans la description du contenu standard des données à différents niveaux et dans diverses applications logicielles et technologies de stockage, puis nous discutons de la manière dont les ontologies peuvent être superposées pour aider à déterminer la comparabilité sémantique.

Valeurs : Un champ de formulaire, un champ d’enregistrement, un champ de ligne de tableau, une cellule de feuille de calcul, un attribut ou une propriété ou un emplacement d’objet/classe de calcul, ou une variable peut contenir une valeur (alias élément de données ou donnée).
Types de données fondamentaux : essentiels à la lisibilité par machine, une valeur peut être d’un certain type de données « littéral » ou syntaxique fondamental, comme une chaîne, une date, une heure, un nombre entier ou décimal, un booléen, une valeur catégorielle ou un type de référence d’URL. Il existe quelques « langages d’échange de données » standard courants qui les expriment : XML, JSON et SQL.
Unités : les valeurs numériques peuvent être accompagnées d’unités (par exemple, « 1m » pour un mètre ou « 2d » pour 2 jours). Il appartient aux développeurs de schémas de déterminer si une unité est associée à un nombre en tant que valeur de type de données de chaîne unique ou si elle est stockée séparément d’une valeur. En elles-mêmes, les unités ont besoin d’une représentation de chaîne ou de codage, telle que celle fournie par les codes UCUM ou une ontologie d’unités (par exemple, QUDT, OM, UO).
Syntaxe de chaîne : un schéma de données peut également fournir des extensions de type de données de chaîne plus complexes en imposant des contraintes supplémentaires à leur syntaxe afin d’exprimer par exemple la norme ISO 19115-1:2014 Informations géographiques — Métadonnées pour les coordonnées de latitude et de longitude. La manière standard de procéder consiste à utiliser des expressions régulières. Remarque : un schéma OCA documente toutes sortes de nombres comme un type de données « numérique », et nécessite donc une expression régulière pour fournir une granularité plus fine, correspondant aux types décimaux ou entiers.
Une spécification de données destinée à un seul projet ou aux flux de travail d’une infrastructure peut permettre une description plus souple de certains types de données, par exemple en permettant à des dates ayant des formats différents d’être un type de données « date », ou à des nombres de précisions différentes d’être un type « numérique ». Cependant, la transition de la spécification des données à la norme des données minimise idéalement ces ambiguïtés, de sorte que « 04/05/22 » ne soit pas confondu avec le mois, le jour et l’année, ou qu’une valeur « 10,5 » ne génère pas d’erreur parce qu’une base de données a choisi de la stocker sous forme d’entier, tandis qu’une autre a choisi un format décimal. Il est préférable d’être aussi précis et précis que possible sur les types de données souhaités dès le départ, en reconnaissant toutefois que les caractéristiques peuvent être mesurées de différentes manières (comme indiqué dans la section Attributs ci-dessous).

La rencontre d’une valeur qui a une structure syntaxique au-delà des caractères aléatoires suggère qu’elle a une signification à propos de quelque chose, ce qui nous amène au sujet des attributs.

Attributs : un type d’enregistrement de table, une feuille de calcul, un objet ou une classe informatique, une entité ontologique ou un formulaire d’interface utilisateur peut avoir un certain nombre d’attributs obligatoires et/ou facultatifs. Selon le contexte d’utilisation, un attribut est également appelé champ, propriété, variable, caractéristique ou emplacement. Une spécification d’attribut doit inclure une définition en langage relativement simple qui le distingue des autres attributs ayant des noms ou une sémantique similaires. Dans la section sur l’ontologie, nous discutons des définitions aristotéliciennes qui tirent parti des attributs organisés en hiérarchies sémantiques. Pour plus de simplicité, nous dirons généralement qu’un attribut est une caractéristique d’une entité.
Nommage d’attribut : lorsque quelqu’un fait référence à un attribut, il peut y avoir une certaine ambiguïté dans ce qu’il signifie : s’agit-il d’un nom d’affichage de colonne, d’un nom de champ standardisé par un tiers ou d’un nom programmatique à utiliser dans des scripts ou des bases de données ? Une séparation des préoccupations doit être établie dans une spécification d’attribut concernant son nom simple par défaut à des fins d’affichage (qui apparaît généralement dans les applications et les interfaces utilisateur), sa référence de codage informatique (base de données ou programmation) et son nom ou référence normalisé.
Nom simple : une étiquette ou un titre** d’interface utilisateur en langage simple par défaut (y compris les étiquettes de colonnes de feuille de calcul) pour une lisibilité humaine, comme « Date de naissance », « Date de naissance », « date de naissance », « né », etc. Permettre au titre ou à l’étiquette d’avoir des variantes linguistiques ouvre également la voie à des interfaces multilingues. Dans les logiciels, il ne doit pas être utilisé comme clé pour rechercher des informations sur les attributs.
Nom de codage : un nom de « codage » d’attribut de niveau logiciel/script/analytique/base de données/sérialisation, tel que « date_de_naissance ». Ce nom est la clé de la lisibilité par la machine, et son format standard doit s’aligner sur les conventions de dénomination des variables de programmation courantes pour éviter les erreurs lors de l’analyse des fichiers de données et de la validation, et pour permettre la génération de code (par exemple, alphanumérique + trait de soulignement uniquement ; aucun espace, tiret, barre oblique, crochets, parenthèses ou points, etc. autorisés dans un nom). Les cadres de schémas de données comme LinkML ont été guidés par les noms d’attributs Python / compatibles R et SQL et les noms de table/objet standardisés, en particulier :
PascalCase : pour les noms de table, d’objet et de liste de sélection, utilisez une chaîne alphanumérique commençant par une majuscule. Une expression régulière MS Excell
lower_camel_case : pour les noms de codage d’attribut, utilisez des mots alphanumériques en minuscules séparés par des traits de soulignement.
Pour ceux qui travaillent dans MS Excell, une expression régulière pour convertir un nom d’attribut simple de colonne A, ligne 1 en PascalCase est : =regexreplace(proper(A1),”[_ (/)-]”,””) et pour lower_camel_case : =Lower(regexreplace(regexreplace(A1,”[ /]”,”_”),”[-()]”,””))
Référence de normalisation : comme détaillé dans la section des identifiants permanents ci-dessous, une spécification d’attribut peut avoir un ou plusieurs identifiants purl qui pointent vers une ontologie ou d’autres termes de vocabulaire structuré qui indiquent que l’attribut est comparable par machine à tout attribut marqué de manière similaire. Chaque purl doit pointer vers une ressource qui indique la définition sémantique, la synonymie et les contraintes logiques d’un terme. Par exemple, le purl d’ontologie de cellule type de cellule peut être la référence normalisée pour un attribut « cell_type », et en fait, les termes subordonnés de ce terme peuvent être utilisés comme liste de valeurs possibles qu’un attribut cell_type peut contenir.
Valeur(s) d’attribut : la spécification de schéma d’un attribut autorise au moins un type de données de valeur, mais dans certains schémas, il peut en avoir plusieurs, comme un entier de date de naissance plus une « liste de valeurs nulles » (une liste de sélection des statuts de collecte de données manquantes, non collectées, etc.). Des normes telles que le rapport de valeur manquante du NCBI couvrent ce sujet.
Sémantique d’attribut : un attribut possède un type de données fondamental plus étroit qui transmet la syntaxe de valeur liée à la façon dont il a été mesuré, ainsi qu’un type sémantique contextuel qui indique ce qui a été mesuré. Par exemple, alors qu’un attribut peut simplement être appelé « âge » (avec un type de données entier et une unité d’année implicite), il n’est pas destiné à être comparé à l’attribut « âge » d’un ensemble de données existant dans le monde, comme le montre cette liste de types d’âge. Une définition en texte brut d’attribut peut indiquer à quel type d’âge il s’agit ou à quelle entité il s’applique, mais les ordinateurs ne le voient pas. C’est pourquoi les schémas de données bénéficient de l’ajout de références de normalisation d’entités et d’attributs. Idéalement, un schéma de données s’appuie sur une bibliothèque partagée d’attributs organisés par leurs différences sémantiques.
Mesures : les attributs ne sont pas toujours mesurés de la même manière, même au sein d’un même schéma. Dans ce cas, il convient de définir des attributs différents (avec un codage différent et des noms simples) qui incluent la mesure ou l’échelle précise de l’unité en question (comme « âge_en_années » ou « âge_en_semaines » ou « âge_gestationnel » ou « âge_trimestre »). Cela résout l’ambiguïté informatique.

Attributs catégoriels : comme cela apparaît souvent dans les enquêtes, certains attributs sont mesurés par un ensemble catégoriel/ordinal de valeurs autorisées (comme « jeune

adulte

âgé » pour l’âge). Ces choix proviennent de listes de sélection intégrées au schéma ou d’un ou plusieurs vocabulaires contrôlés. Les schémas de données ont besoin d’un mécanisme pour indiquer quels sont les choix de la « liste de sélection » de vocabulaire ou, dans le cas de vocabulaires volumineux et évolutifs, où ils se trouvent en ligne et de quelles branches inclure ou exclure les choix.

Attributs composés : il s’agit de spécifications d’objet ou de structure de données, qui peuvent être résumées en un seul attribut, constituées de plusieurs attributs. Par exemple, un « emplacement » peut être une combinaison de latitude et de longitude dans une chaîne. Un autre exemple est la variété de types d’adresses (boîte postale, rue, adresse légale, siège social, domicile) qui peuvent être sérialisés dans une seule valeur de chaîne. Nous préférons plutôt les diviser en un objet « adresse » général contenant la rue ou la boîte postale, la ville, le code postal, la région, etc. Des types d’adresses particuliers héritent des attributs du type d’adresse général et ajoutent les leurs, comme pour le type de boîte postale.
Identifiants permanents : étant donné la nécessité de référencer le vocabulaire et d’autres ressources de données sur le Web, le travail de normalisation implique souvent un type de valeur appelé référence d’identifiant permanent qui pointe vers une ressource comme un ensemble de données, un document ou une page de détails de termes de vocabulaire. Pour une référence Web, cela s’appelle une URL permanente ou « purl », comme http://purl.obolibrary.org/obo/OBI_0001167. Une fois qu’une URL permanente est mise en circulation sur le Web, elle est censée y rester afin de pouvoir toujours récupérer la ressource ou, si ce vers quoi elle pointe devient archaïque ou abandonné, une réponse de code « obsolète ». De plus, si un vocabulaire ou une ressource plus récente la remplace, un identifiant de remplacement est indiqué. De cette façon, le contenu des données peut être mis à jour pour harmoniser et simplifier la fédération et les requêtes. Il existe des registres de ressources dotées de PUL qui incluent des bases de données et des ontologies, comme le registre PUL du groupe communautaire des identifiants permanents du W3C [https://w3id.org/] et bioregistry.io, qui se concentre davantage sur la recherche en sciences de la vie et constitue un excellent endroit pour les projets qui souhaitent ajouter leurs propres liens de ressources (lorsqu’un vocabulaire référencé dans une base de données n’est pas encore représenté sur le Web).
Vocabulaire structuré : nous utilisons le terme « vocabulaire structuré » pour décrire un fichier de termes de vocabulaire (tels qu’une taxonomie ou une ontologie) qui comprend des détails d’attribut dans une certaine mesure - tels que des noms en anglais simple ou dans d’autres langues, des noms de codage, des PUL, des définitions et une sémantique telle que des hiérarchies de termes. Il existe de nombreux catalogues de vocabulaire structuré sous forme de listes ou de portails consultables, notamment :
L’agence internationale de recherche agricole CGIAR a publié une ressource d’ontologies communes pour l’agriculture (https://bigdata.cgiar.org/ontologies-for-agriculture/).
AgroPortal soutenu par un certain nombre d’agences de recherche françaises de premier plan est une autre source de vocabulaire de recherche agricole.
OBO Foundry est un effort collaboratif multi-agences d’ontologies des sciences de la vie liées à la recherche en agriculture, biologie, climat et écologie, toutes fonctionnant dans le cadre d’une méthodologie de conservation alignée.
OLS L’interface de recherche d’ontologies de l’Institut européen de bioinformatique du Laboratoire européen de biologie moléculaire (EMBL) reflète l’engagement des agences à développer des ontologies dans le domaine des sciences de la vie.
Fairsharing.org dispose d’un registre de normes dédié aux ressources de flux de travail et d’ontologie.
Wikidata dispose d’un vaste ensemble d’identifiants de pays, de région, de ville et d’autres identifiants de géolocalisation pouvant être obtenus en recherchant un nom souhaité.
GOLD système de classification des écosystèmes au format tabulaire plat https://gold.jgi.doe.gov/download?mode=ecosystempaths, et son équivalent ontologique OBO Foundry [https://github.com/cmungall/gold-ontology/blob/main/gold_definitions.yaml).

Plus de détails sur l’application d’ontologies adaptées à la normalisation des ensembles de données sont fournis dans la section ontologie.

Couches de normalisation

Résumé du schéma de données et du contenu des ensembles de données

Les schémas de données harmonisés contribuent à la fois au partage de données entre pairs et à la visibilité du catalogue de données. Cela implique de normaliser les ensembles de données/schémas de projet jusqu’au niveau du nom de champ et de la valeur de la liste de sélection - ou au moins de les mapper à leurs équivalents sémantiques. Les noms idiosyncratiques sont remplacés par des termes référencés dans les normes.

Informations récapitulatives (métadonnées) organisées par l’homme :
Les mots-clés du domaine d’étude de l’ensemble de données peuvent être standardisés via des menus de mots-clés basés sur l’ontologie (par opposition à des menus de mots-clés en texte libre) ; Ces éléments sont de plus en plus adoptés par les catalogues de données, par exemple, l’utilisation abondante de l’ontologie EDAM [topics](https://edamontology.org/page par Fairsharing.org et d’autres ontologies OBO Foundry pour la description du contenu.
La portée spatiotemporelle (par exemple, la date et le(s) lieu(x) de collecte d’un ensemble d’échantillons) peut être décrite à l’aide de vocabulaires structurés comme la base de connaissances géographiques de Wikidata, par exemple Canada.
Les informations dérivées du schéma de données, y compris les listes de normes et de vocabulaires structurés utilisés, peuvent être référencées dans les catalogues de données FAIR des agences ou du public.
Les informations dérivées des ensembles de données, y compris le nombre d’enregistrements et la taille des octets de sérialisation Les informations, les fréquences d’utilisation de mots-clés démographiques/contextuels, le tableau harmonisé des ensembles de données et les informations au niveau du terrain (par exemple, le nombre de types de milieu de croissance des plantes présents) peuvent être publiés.

Métadonnées sur la conception expérimentale et le protocole

Au-delà des domaines d’étude, ces métadonnées permettent aux chercheurs de juger de la pertinence d’un ensemble de données issu d’échantillons ou d’observations lorsque les données elles-mêmes ne définissent pas clairement les groupes expérimentaux ou le contexte de collecte, ou la méthodologie sensible impliquée.

Par exemple, l’assistant de conception expérimentale génère des diagrammes visuels d’études multi-groupes et de variables expérimentales dans la recherche animale pour une comparaison détaillée plus rapide.
Plus généralement, l’ontologie OBI et le NCIT Thesaurus fournissent une liste importante de termes de conception d’études qui peuvent être référencés dans tous les domaines de recherche en sciences de la vie.
Protocols.io est un système populaire pour détailler et publier des informations sur les protocoles.

Provenance

L’histoire de l’endroit où les ensembles de données sont hébergés et des projets, personnes et agences responsables de leur création et de leur gestion. Le langage commun couvre :

L’emplacement d’hébergement des ensembles de données, la paternité, les dates de publication, les articles et institutions associés. L’ontologie de provenance (PROVO) est souvent utilisée ici, ainsi qu’un certain nombre de métadonnées Dublin Core DCMI Metadata Terms.
Paternité : les identifiants ORCID sont désormais le moyen standard de référencer les auteurs

Gouvernance

Les points ci-dessus se concentrent sur la normalisation des données de projet pour la découverte. De plus, la normalisation de l’aspect gouvernance des données, y compris les critères d’accès aux données et les processus de récupération comme l’authentification des utilisateurs et l’accès autorisé via les règles de confidentialité du contenu, évolue avec l’aide d’ontologies telles que l’ontologie d’utilisation des données DUO et de systèmes d’authentification standardisés tels que OAuth 2.0.

Fichiers, dossiers et workflow

Un projet est composé de nombreux fichiers et dossiers générés par le workflow qui doivent être systématiquement organisés, comme expliqué ici

Mise en œuvre

Il est important de souligner que les chercheurs ne devraient pas avoir à assumer la majeure partie du travail de normalisation, car cela implique un certain nombre de compétences techniques et une connaissance générale des vocabulaires contrôlés et des formats de données normalisés qui prennent du temps à acquérir. Idéalement, le personnel de gestion des données du projet, les scientifiques et les analystes sont disponibles pour aider à la normalisation des schémas de données ou des projets de données exportées. C’est là que l’équipe DCC peut vous aider !

Si cela est prévu au début du cycle de conception du projet, les composants du schéma de données peuvent être normalisés en tant que copies de composants de normes tiers existants, comme nous le recommandons dans la section Bibliothèque de schémas. Cependant, souvent, que ce soit en raison de la dynamique du projet ou d’un engagement envers l’infrastructure informatique existante, un schéma de données n’est pas normalisé, et les produits de données nécessitent donc un processus de mappage pour transformer les données de projet existantes en format normalisé pour une utilisation externe. Ce processus de mappage est effectué soit par des scripts de conversion spécialisés qui doivent souvent être modifiés au fil du temps, soit idéalement en utilisant un modèle de programmation plus générique pour convertir entre les composants du schéma de projet et les produits de données standardisés cibles (par exemple, des formats de données spécifiques pris en charge par les référentiels de stockage). On peut également s’attendre à une itération du travail de spécification à mesure que les schémas de données évoluent pour la surveillance ou la recherche longitudinale.

Composants de données standardisés :
Niveau d’attribut du schéma de données : S’ils sont prévus au début du cycle de conception du projet, les attributs de données peuvent être standardisés (ou personnalisés) en tant que copies d’éléments de normes tiers existants, partageant les éléments de spécification d’attributs décrits ci-dessus. La spécification groupée NCBI BioSample est une bonne source d’attributs utilisés pour décrire le contexte environnemental/agricole ou humain/animal/végétal des bioéchantillons pour la recherche génomique.
Niveau d’enregistrement du schéma de données : la production de produits de données standardisés est généralement réalisée en copiant ou en mappant des parties sélectionnées des spécifications cibles dans le schéma de données d’un projet. La spécification NCBI BioSample est en fait organisée en « packages » plus thématiques pour une compréhension et une copie plus faciles des parties ou des ensembles. Des travaux ont été réalisés pour convertir la majorité de ces spécifications en un format de référentiel GitHub MIxS LinkML lisible par machine, avec une version de documentation consultable.
Convention de dénomination des données : Peu importe qu’un schéma de données réutilise ou non des éléments d’autres schémas, il est important d’imposer des conventions de dénomination des données (décrites ci-dessus) à ses composants développés en interne. Cela est fait principalement pour éviter les problèmes lors de l’application ou du développement de scripts logiciels pour la validation, la transformation et/ou l’interaction avec la base de données.
Ontologies : Un travail de normalisation important peut être effectué avant d’introduire des identifiants d’ontologie dans un schéma. D’une certaine manière, les ontologies fournissent les fruits comparables de l’interopérabilité, mais un schéma de données est l’arbre pratique qui doit être construit sur lequel reposent les termes d’ontologie. Dans la section ontologie, vous trouverez une liste d’ontologies recommandées et des moyens de les implémenter en tant que couche sur un schéma de données et des métadonnées de projet.

Ressources de formation

À déterminer

Auteurs : Damion Dooley