Standardisation des schémas de données

Table des matières

  1. Standardisation d’un schéma de données
    1. Valeurs
    2. Types de données fondamentaux
    3. Attributs
    4. Valeur(s) d’attribut
    5. Sémantique d’attribut
    6. Attributs composés
    7. Identifiants permanents
  2. Vocabulaire structuré
  3. Sources d’attributs standardisés
  4. Ressources de formation

Standardisation d’un schéma de données

Les schémas de données, qu’ils capturent les détails syntaxiques et sémantiques d’une seule table de données ou qu’ils couvrent de nombreuses tables imbriquées ou des transformations entre elles, sont un terrain fertile pour les opportunités de standardisation. Nous commençons par une description et des recommandations sur le mélange de langage actuellement présent dans la description du contenu des schémas de données, puis nous discutons de la manière dont les vocabulaires structurés, y compris les ontologies, peuvent être superposés 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

Essentiel à 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 sous forme 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 sur leur syntaxe afin d’exprimer par exemple la norme ISO 19115-1:2014 Information géographique — Métadonnées pour les coordonnées de latitude et de longitude. La méthode standard pour ce faire est d’utiliser des expressions régulières.
  • 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 aux dates ayant des formats différents d’être un type de données « date », ou aux nombres de précisions différentes d’être un type « numérique ». Cependant, les spécifications et les normes de données minimisent idéalement ces ambiguïtés, de sorte que « 04/05/11 » 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 cependant que les caractéristiques peuvent être mesurées de différentes manières (comme indiqué dans la section sur les attributs ci-dessous).

Rencontrer 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 conduit 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 la 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. Dans le langage de l’ontologie, nous dirions de manière abstraite qu’un attribut est une caractéristique d’une entité.

  • Nommage d’attribut : lorsqu’une personne fait référence à un attribut, il peut y avoir une certaine ambiguïté dans sa signification : s’agit-il d’un nom d’affichage de colonne, d’un nom de champ standardisé 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 sa référence standardisé.
  • Nom simple : une étiquette ou un titre** d’interface utilisateur en langage simple par défaut (y compris les étiquettes de colonne de feuille de calcul) pour une lisibilité humaine, comme « Date de naissance », « Date de naissance », « date de naissance », « né », etc. Le fait de permettre au titre ou à l’étiquette d’avoir des variantes linguistiques ouvre également la voie à des interfaces multilingues. Dans un logiciel, 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, crochet, parenthèse ou point, etc. n’est autorisé 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 et qui ont besoin d’obtenir automatiquement des noms de codage à partir de certains noms en langage clair, une expression régulière pour convertir un nom d’attribut simple de colonne A, ligne 1 d’une feuille de calcul

  • en PascalCase : =regexreplace(proper(A1),”[_ (/)-]”,””)

  • en minuscules : =Lower(regexreplace(regexreplace(A1,”[ /]”,”_”),”[-()]”,””))

  • Référence de terme de vocabulaire normalisée : 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és indiquant 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 « type_de_cellule », et en fait, les termes subordonnés de ce terme peuvent être utilisés comme liste de valeurs possibles qu’un attribut type_de_cellule 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 attribut « date de naissance » qui peut avoir à la fois une valeur de type de données de date, mais aussi une « liste de valeurs nulles » (une liste de sélection catégorique 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. De plus, certains champs autorisent les listes de sélection à sélection multiple, qui doivent être enregistrées dans des chaînes délimitées, ou une structure de données de 1 champ à plusieurs valeurs.

Sémantique d’attribut

Un attribut a 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, même si 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 type de données et de vocabulaire standardisé. 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/personne âgée » 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 constituées de plusieurs attributs. Par exemple, un attribut « geo_location » peut être une combinaison de latitude et de longitude dans une chaîne. Si un schéma donné le permet, un emplacement peut faire référence à une classe d’objet LatLong qui possède elle-même deux attributs, la latitude et la longitude.

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ées dans une seule valeur de chaîne. En général, les concepteurs de schémas préfèrent diviser une adresse en attributs d’un objet d’adresse générale contenant des éléments de rue ou de boîte postale, de ville, de code postal, de région, etc.

Identifiants permanents

Étant donné la nécessité de référencer du vocabulaire et d’autres ressources de données sur le Web, le travail de normalisation implique souvent un type de valeur appelée 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, on parle d’URL permanente ou « purl » **, comme par exemple 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 PURL qui incluent des bases de données et des ontologies, comme le registre PURL du groupe communautaire des identifiants permanents du W3C (https://w3id.org/) et le site 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é » (également appelé vocabulaire contrôlé) 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 définitions et une sémantique telle que des hiérarchies de termes. Les agences peuvent établir une liste de vocabulaires structurés recommandés à utiliser dans leurs schémas de données de projet et d’infrastructure. Nous nous intéressons particulièrement aux vocabulaires structurés soutenus par une curation collaborative multi-agences, et qui ont un purl pour chaque terme qui peut être trouvé dans des portails consultables. Parmi les principaux exemples de tels vocabulaires et portails de recherche, on peut citer :

  • L’agence internationale de recherche agricole CGIAR a publié une ressource d’ontologies communes pour l’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 curation alignée.
  • OLS L’interface de recherche d’ontologie de l’Institut européen de bioinformatique du Laboratoire européen de biologie moléculaire (EMBL) reflète l’engagement des agences à soutenir les ontologies 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/commune et d’autres identifiants de géolocalisation pouvant être obtenus en recherchant le 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 compatible avec OBO Foundry [https://github.com/cmungall/gold-ontology/blob/main/gold_definitions.yaml).

Sources d’attributs standardisés

Les termes d’ontologie peuvent être précis pour décrire une chose mesurée, mais pas la manière dont elle est mesurée. Les attributs de schéma de données vont souvent plus loin que les ontologies dans la mesure où les spécifications d’attribut incluent le type de données de la ou des valeurs. Les attributs standardisés avec des noms de codage se trouvent par exemple dans les normes de référentiel plat NCBI BioSample et dans les normes plus structurées Phenopacket. Plus de détails sur l’utilisation du vocabulaire structuré, y compris les ontologies, sont fournis dans la section ontologie.

Ressources de formation

À déterminer

Auteurs : Damion Dooley