Aller au contenu principal

Éliminer les obstacles à la conversion des données

· 6 minutes de lecture
Devon Hayley Farrell
LINCS Metadata Co-op

Unsplash

S'il y a une chose que j'ai apprise au cours de mes études supérieures en bibliothéconomie, archivistique et information, c'est que les institutions de l'information sont hostiles au changement. La profession d'archiviste progresse à un rythme glacial. Cela se juxtapose avec les sauts et les limites réalisés dans les technologies de l'information au cours des vingt-cinq dernières années. À première vue, il n'est pas logique que de nombreuses bibliothèques utilisent encore le format désuet MARC pour leurs notices bibliographiques, ou pourquoi les institutions d'archives au Canada toujours mandaté pour utiliser la version 2008 des règles de description archivistique, qui n'a pas de véritable solution pour décrire les documents électroniques...

Pourquoi ne pouvons-nous pas moderniser nos normes et nos pratiques ? Pourquoi ne pouvons-nous pas développer de nouveaux logiciels brillants pour fournir une infrastructure d'informations plus élégante, complexe et robuste ? La technologie pour faire et construire ces choses est là - tout ce que nous avons à faire est de tendre la main et de la saisir.

Le problème se résume au cost. Le coût de la construction de nouvelles infrastructures, le coût de la main-d'œuvre nécessaire pour apporter des changements systémiques, le coût de la formation du personnel aux nouveaux systèmes. La plupart des institutions canadiennes d'information dépendent du financement, souvent public, pour fonctionner. Ces institutions ne sont pas conçues pour faire du profit ; leur valeur est précisément d'être gratuit pour leurs utilisateurs. Malheureusement, le financement est rarement suffisant pour soutenir des projets d'immobilisations tels que des mises à niveau d'infrastructures, et il est difficile d'expliquer au service du budget pourquoi il est si coûteux de passer d'une ancienne norme de données à une nouvelle ou pourquoi cela pourrait être un projet important. L'infrastructure de l'information, et la valeur qu'elle apporte, est si souvent invisible pour le public.

Avec cette perspective à l'esprit, l'aspect de conversion de données de LINCS est une entreprise massive. Nous avons parcouru le défi ontologique de choisir une norme, triplestore utilisant CIDOC CRM, pour nos Données liées (LD) triples. Nous avons conceptualisé comment les schémas de métadonnées existants et les façons de décrire l'information peuvent s'intégrer dans ce nouveau cadre à travers le processus de mappage : identifier les éléments dans un schéma cible qui sont fonctionnellement équivalents aux éléments dans un schéma source. Nous avons sélectionné des plates-formes pour stocker les données transformées résultantes. Même avec toutes ces pièces de puzzle en place, nous devons toujours prendre les données d'origine pour chaque ensemble de données contribué à LINCS et les transformer en CIDOC CRM triples TTL pour ingestion dans la nouvelle système triplestore. Passer d'une norme de métadonnées traditionnelle à une autre est un défi en soi, sans parler de passer d'une métadonnée de style élément-valeur à CIDOC CRM. Nous pouvons écrire des triplets TTL en utilisant la structure de CIDOC CRM à la main - et nous l'avons certainement fait, lors du test de la façon de cartographier notre premier ensemble de données à convertir, la Personographie jaune des années 90 - mais nous ne pouvons pas convertir un ensemble de données entier manuellement (et encore moins tous les ensembles de données qui font partie du projet), car cela prendrait du temps, et le temps c'est de l'argent. La conversion manuelle est désordonnée, lente et ne contribue pas à la réplicabilité des processus, tandis que les pipelines de conversion automatisés réduisent les erreurs, font gagner du temps et sont réutilisables pour de futurs lots de données.

Avoir les bons outils pour le travail fait toute la différence. Disposer d'une plate-forme en ligne gratuite et open source comme X3ML Toolkit et son outil de conversion de données [Mapping Memory Manager (3M)](https ://github.com/isl/Mapping-Memory-Manager) fait une différence encore plus grande. 3M est un outil de conversion de données conçu pour convertir les données en différentes structures ; dans notre cas, un schéma de métadonnées personnalisé en XML-RDF vers CIDOC CRM en TTL-RDF. 3M peut ingérer un échantillon de métadonnées à partir d'un ensemble de données d'origine et recevoir une ontologie cible vers laquelle convertir les données. Ensuite, il s'agit d'indiquer à 3M quel élément des données d'origine vous souhaitez mapper et à quel modèle de votre ontologie cible vous souhaitez mapper. Une fois qu'un mappage est configuré et testé, il peut convertir un ensemble de données complet en quelques secondes. 3M a automatisé le processus de conversion des données avec une personnalisation minimale requise, ce qui nous évite d'avoir à créer un outil sur mesure et fait gagner un temps précieux à l'équipe de conversion des données. Cela nous a permis de convertir des ensembles de données individuels en quelques semaines plutôt que de prolonger le temps de conversion pour inclure également le développement d'outils.

La magie ontologique d'enseigner à 3M comment convertir les métadonnées en CIDOC CRM se produit dans le tableau de correspondance, un onglet de l'outil 3M - c'était l'arène principale de mon travail dans le processus de conversion. Le tableau de correspondance peut gérer des conversions complexes, permettant les multiples triplets connectés dont le CIDOC CRM a besoin pour exprimer sémantiquement des informations nuancées, par exemple en conceptualisant l'école qu'une personne a fréquentée comme une activité éducative avec des rôles, comme on le voit dans la rangée inférieure du tableau de correspondance. Tableau ci-dessous.

Tableau de correspondance 3M

Le tableau d'appariement 3M.

À l'aide de 3M, nous avons défini la sortie souhaitée conforme au CIDOC CRM pour chaque élément de métadonnées Yellow Nineties Personography, vérifié que chaque élément se transformait correctement à l'aide d'un petit échantillon de données réelles et converti l'ensemble de données Yellow Nineties Personography en CIDOC CRM au format TTL. Nous sommes impatients d'automatiser davantage ce processus en utilisant un outil graphique ou en écrivant du code qui peut nous aider à vérifier les données, mais pour l'instant nous sommes très satisfaits du résultat de cette première conversion. C'est certainement une étape importante pour l'équipe. qui a travaillé sur la conversion de Yellow Nineties Personography et pour LINCS en général. Nous n'aurions pas pu terminer le processus de conversion sans avoir le bon outil, un outil qui se trouvait être l'option open source gratuite. 3M réduit considérablement le travail requis pour transformer les données, rendant le processus de conversion plus réalisable. J'espère que notre succès dans la conversion des données pourra être utilisé comme exemple de la façon dont d'autres institutions peuvent faire de même, le tout sans se ruiner. Nous sommes convaincus que 3M est la bonne solution pour LINCS et sommes prêts à convertir plus d'ensembles de données à l'avenir !

Consultez le billet de blog de mon collègue et coéquipier dans la conversion de données Justin pour plus d'informations sur 3M et comment il s'intègre dans le cadre d'un Pipeline Extract-Transform-Load.