Module 17 – Traverser aux passages piétons
Dans ce module, nous aborderons la mise en correspondance des données.
Dans notre module précédent
Dans notre module précédent, nous avons :
abordé les schémas de métadonnées. Comme vous le savez, chaque schéma possède ses propres règles et éléments obligatoires qui sont consignés. Dans certains cas, vous devrez peut-être convertir vos métadonnées d'un schéma à un autre, par exemple si vous souhaitez les déposer dans un autre dépôt, mais que celui-ci exige un schéma différent.
La traduction nécessaire s'appelle le « crosswalking ».
Apprendre à utiliser un passage piéton est une expérience courante dans l'enfance. Les marquages au sol et les feux de signalisation permettent aux piétons de passer en toute sécurité d'un côté à l'autre de la rue, lorsque celle-ci est traversée par des voitures, dans un monde où la voiture occupe une place prépondérante. Une partie de cet apprentissage consistait à se faire accompagner par quelqu'un pour traverser.
Contrairement aux humains, les machines se heurtent toutefois à un mur lorsqu'il s'agit d'apprendre et de comprendre certains concepts de manière dynamique. Leurs capacités sont limitées, ce qui signifie qu'il reste encore des tâches que les humains doivent accomplir pour qu'elles puissent fonctionner.
L'une de ces fonctions, appelée « traverser le passage piéton », concerne les schémas de métadonnées. Il s'agit essentiellement de passer d'un schéma à un autre. Par exemple, imaginez que le schéma MODS (Metadata Object Description Schema) se trouve d’un côté de la rue, et que vous deviez prendre tous ces termes pour les adapter correctement et de manière dynamique aux termes situés de l’autre côté de la rue, dans la convention de métadonnées CF. Traverser le passage piéton, c’est justement ce tri.
On peut aussi voir cela comme une traduction linguistique : vous traduisez un schéma de métadonnées vers un autre.
Voici un exemple de tableau de correspondance, en utilisant des normes courantes que vous avez sans doute déjà rencontrées :
Liste A : Provinces par leur nom complet
- Alberta
- Nouvelle-Écosse
- Colombie-Britannique
- Manitoba
- Québec
La liste A contient quelques provinces, mais celles-ci doivent être transférées vers la liste B, où elles doivent être répertoriées sous leur code provincial à deux lettres à des fins d'envoi postal.
Il faudrait donc connaître l'abréviation convenue pour chaque province et les transposer dans la liste B. (Certaines correspondent aux deux premières lettres du premier mot, d'autres aux deux premières lettres, et d'autres encore à la première et à la dernière lettre.)
Il s'agit là d'un bon exemple de normalisation des schémas de métadonnées, puisque le schéma correspondant à « B » a été créé et validé par une institution spécifique, en l'occurrence Postes Canada. Ces codes postaux provinciaux permettent un tri plus efficace du courrier, tant par les machines que par les humains, et présentent l'avantage de gagner de la place sur les petites enveloppes ou les cartes postales, puisque le nom complet de la province n'a pas besoin d'être indiqué.
Liste B : Provinces classées par code postal officiel
- AB
- NS
- av. J.-C.
- MB
- CQ
L’une des principales raisons pour lesquelles le « crosswalking » reste une tâche réservée aux humains est que ces derniers sont plus à même de porter des jugements contextuels que les machines ne sont pas forcément capables d’émettre, ou de repérer des informations manquantes que les machines ne sont pas en mesure de lire. Dans l’exemple ci-dessus, il n’existe aucun algorithme que l’on pourrait fournir à une machine pour déterminer les codes de chaque province ; ceux-ci devraient simplement être programmés individuellement. (Le code de l’Alberta est « AB », qui correspond à la première et à la troisième lettre de son nom, tandis que celui du Manitoba est également « MB », mais dans ce cas, il s’agit de la première et de l’avant-dernière lettre. Il n’existe aucune régularité mathématique qu’une machine puisse exploiter.) C’est pourquoi le recoupement est utile, car sans cela, la machine ne serait pas en mesure de lire ces informations.
Se familiariser avec les principes fondamentaux constitue également une première étape importante pour comprendre les bases de la conception web et du codage, car une grande partie du temps que vous passerez à coder des feuilles de style XSLT et XML consistera à transposer des propriétés d’un schéma de conception à un autre, par exemple en transposant l’utilisation des couleurs, la taille des bordures, ou encore la police et le style du texte, à partir des propriétés descriptives d’une page vers une autre.
XML, acronyme de « Extensible Markup Language », est un format de fichier permettant de stocker, de reconstituer et de partager des données. Il permet de coder des documents de manière à ce qu'ils soient lisibles à la fois par les machines et par les humains, et est largement utilisé sur le Web.
Voici unepage de métadonnées provenant de l'explorateur de données du CIOOS. Le langage XML est structuré en arborescences d'informations qui deviennent de plus en plus spécifiques. C'est pourquoi nous avons mis l'accent sur les connaissances de base en programmation et en conception web, car la compréhension du fonctionnement des arborescences XML vous aidera à mieux appréhender les métadonnées.
Contexte océanique
Le mappage doit le plus souvent être effectué par des humains, car certains schémas de métadonnées présentent un niveau de complexité plus élevé que d’autres. Par exemple, Darwin Core permet de préciser un emplacement jusqu'aux coordonnées GPS, ainsi que presque tous les niveaux de classification des spécimens biologiques, du règne jusqu'à l'espèce. (Ceci est utile car, dans les grandes bases de données, la recherche peut être aussi détaillée que le niveau de l'espèce, afin de permettre leur comparaison.)
Cependant, toutes les bases de données ni tous les schémas ne sont pas aussi complexes, et il peut, dans certains cas, s'avérer utile d'ajouter vos données à un référentiel présentant un niveau de complexité moindre afin de les partager.
C'est là que le « crosswalking » entrerait en jeu.
Voici le format Darwin Core, plus complexe, comparé au format MODS, moins complexe sur le plan biologique :
Darwin Core propose plus de 50 méthodes différentes pour délimiter le contexte spatial de vos données, et encore davantage en ce qui concerne les aspects temporels de celles-ci. En revanche, MODS ne fournit que des informations très générales.
| Darwin Core | MODS |
| Année, mois, jour | <subject><temporal> |
| Identifiant de lieu | <subject><geographic> |
| Pays, État, Province, Archipel, Île | <subject><hierarchicalGeographic> |
| Latitude décimale et longitude décimale | <subject><cartographics><coordinates> |
Comme vous pouvez le constater, Darwin Core comporte de nombreux attributs spécifiques qui devraient être regroupés en un seul attribut dans MODS. Ce n’est là qu’un petit aperçu de la spécificité de Darwin Core, dont le schéma comporte encore davantage de termes. Il prévoit même l’intégration d’un pourcentage d’erreur de coordonnées dans le schéma, ainsi que des exemples temporels et spatiaux extrêmement détaillés.
Cet exemple montre clairement pourquoi le mappage effectué par des humains est nécessaire : en effet, les termes ne correspondent pas toujours, et les décisions concernant les données à mapper et leur destination dépendent du contexte ; c'est donc aux humains qu'il revient le mieux de les prendre.
Le « crosswalking » pourrait permettre un partage des données à une échelle encore plus large, même entre des référentiels qui ne seraient pas en mesure d'utiliser un schéma de métadonnées plutôt qu'un autre.
Avant de partir ! Pensez à préparer le module suivant :
Dans notre module consacré aux schémas de métadonnées, nous vous avons demandé de réfléchir au type de schéma que vous utiliseriez pour votre propre collection d'objets. Si vous connaissez une autre personne qui suit ce tutoriel et qui a élaboré son propre schéma de métadonnées, essayez à tour de rôle de transposer vos données dans le schéma de l'autre personne.
