Vers un nouveau workflow d’imports de données dans le Sudoc : les notices des ouvrages publiés par Oxford University Press

Pourquoi un nouveau workflow d’imports de données dans le Sudoc ?

D’un point de vue technique, charger des corpus de livres dans le Sudoc n’est pas très difficile. Depuis plusieurs années, les équipes de l’Abes importent régulièrement des ensembles de notices MARC en provenance de différents éditeurs (Springer, CAIRN …) et, globalement, ces notices sont bien utilisées par les bibliothèques du réseau. Pour autant, on a pu constater que ce système comporte des limites : en amont, il n’est pas toujours évident de récupérer auprès des éditeurs des notices MARC – qui plus est de bonne qualité – et cela exige souvent de nombreux aller-retours. En aval, ces opérations de chargement dans le Sudoc requièrent des interventions humaines et des compétences spécifiques, relativement rares à l’Abes

Ceci rendant les processus actuels difficilement scalables et difficile aussi l’atteinte de l’objectif de signalement total, il s’est avéré indispensable de réfléchir  à la conception de nouveaux  workflows, processus en mesure de réaliser automatiquement les opérations d’ingestion, de transformation, d’enrichissements et de chargement dans le Sudoc

La sélection du corpus test

Afin de conduire l’expérimentation, nous avions besoin d’un corpus répondant à quelques critères simples :

  • les métadonnées devaient être accessibles (FTP, API,…) afin de pouvoir automatiser le workflow ;
  • les métadonnées devaient être dans un format standard mais pas nécessairement du MARC ;
  • le chargement du corpus devait répondre à un besoin  du réseau, constaté mais non encore satisfait ;
  • ce corpus devait correspondre à l’ensemble du catalogue d’un éditeur ou à un sous-ensemble identifiable, quelque soit le support (imprimé et électronique).

Une analyse menée en 2016 avait permis d’identifier la liste des éditeurs représentant la plus forte activité de catalogage dans le Sudoc. C’est donc au sein des premières places de ce classement qu’un corpus répondant à ces critères a été recherché. Le choix s’est rapidement porté sur Oxford University Press (OUP), second de notre liste avec 1757 titres de monographies imprimées catalogués en 2016 et répartis sur 131 ILN.

Avec une production annuelle d’environ 4400 titres,  OUP met également à disposition la version électronique de ses ouvrages, via sa propre plate-forme et via des agrégateurs (Proquest, Dawson, OAPEN…). Autre intérêt spécifique à OUP : la mise à disposition sur son site http://databank.oup.com/gb des métadonnées des ouvrages de son catalogue imprimé au format ONIX 2.1  et des fichiers KBART décrivant les bouquets de monographies électroniques (voir ici).

Les éléments étaient donc en place pour lancer l’expérimentation, l’objectif étant de mettre à disposition, selon un rythme hebdomadaire, dans la base de production Sudoc les notices des ouvrages imprimés et électroniques du catalogue OUP.

Le nouveau workflow

Première étape : Ingestion

Après un simple enregistrement, le site http://databank.oup.com propose l’export de données du catalogue OUP, dans son intégralité ou par sous-ensembles éditoriaux, au format ONIX 2.1 et/ou tabulé. Nous avons fait le choix de récupérer le flux ONIX exposant hebdomadairement toutes les nouvelles publications d’OUP. Par défaut, l’éditeur propose d’envoyer les données par FTP. Pour des raisons de sécurité, nous avons préféré les récupérer directement sur son FTP, ce que l’éditeur a accepté. Pour ce faire, un simple script shell se lançant à intervalles réguliers se connecte au serveur FTP d’OUP, prend le dernier fichier en date et le copie localement.

Deuxième étape : Transformation et enrichissements

Cette étape constitue l’enchaînement de plusieurs procédures s’exécutant dans des environnements différents : transformations XSL ; requêtes SQL et procédures dans le système de gestion de base de données ORACLE ; requêtes SPARQL dans une base RDF Virtuoso ; programmes externes d’alignements… Le tout piloté par une interface graphique de gestion de workflow qui, grâce à l’agencement des différentes briques entre elles, offre une bonne visibilité sur l’étape où d’éventuels problèmes peuvent se présenter (un peu comme Yahoo pipes, pour ceux qui s’en souviennent).

Aperçu de l’interface graphique de gestion de workflows

Dans un premier temps, il s’agit  de convertir en RDF les données fournies par l’éditeur. On peut avantageusement se replonger dans ce document pour se remémorer les raisons d’un tel choix de format pivot.

Une grosse partie du travail consiste à analyser les données afin de comprendre comment l’éditeur utilise ONIX 2.1, en pariant que l’éditeur reste cohérent dans le temps avec ses propres choix afin que le mapping – entre ONIX et les propriétés sélectionnées dans différents vocabulaires – n’évolue qu’à la marge, voire pas du tout. Une fois le mapping validé et le chargement en base RDF réalisé, les travaux d’enrichissements peuvent commencer.

Il peut s’agir “simplement” d’appeler des webservices, comme par exemple le webservice “classify” d’OCLC qui, à partir d’une interrogation ISBN dans Worldcat permet  de récupérer l’indice Dewey . Mais il peut s’agir aussi d’opérations plus complexes : toujours à partir de l’ISBN, on récupère tous les triplets auteurs affichés dans Worldcat via l’encart “données liées”  (cf schéma ci-dessous), et on obtient les identifiants VIAF associés.

Ex.de données liées pour l’ISBN 978-0-19-877827-1 : http://www.worldcat.org/title/structure-of-words-at-the-interface/oclc/955313180&referer=brief_results

 

Grâce à une fonction développée précédemment par le LIRMM dans le cadre du projet Qualinca, pour un ISBN donné, on peut ainsi comparer  les noms OUP avec les noms Worldcat correspondants. Si la comparaison est satisfaisante, on intègre l’identifiant VIAF dans le graphe, et, de là, on obtient l’identifiant IdReF en interrogeant  le dump mensuel de VIAF via une requête SPARQL.

Ensuite, l’algorithme d’alignement avec IdRef développé dans le cadre du projet Qualinca est lancé sur l’ensemble du corpus. Il est alors possible de récupérer dans le graphe des identifiants que l’on n’aurait pas obtenus avec la méthode précédente, de confirmer les résultats, ou au contraire de mettre en évidence des incohérences qui sont alors identifiées et traitées.

On dispose alors de presque toutes les informations pour faire de « belles notices » pour le Sudoc. Presque … car il manque encore l’information permettant de générer les zones 452$0 (« Autre édition sur un autre support »), ce qui est tout à fait logique : pour traiter les ouvrages électroniques, il faut auparavant finaliser les étapes du workflow “imprimé” pour lancer le workflow “électronique”. Pour ce faire, il reste à exporter les données RDF dans une table Oracle dédiée, effectuer  une série de conversions (de RDF en MARCXML puis de MARCXML en MARC ISO2709) via des procédures Java, et les données sont prêtes pour le chargement.

Troisième étape : chargement

Cette étape a longtemps été manuelle, car des réglages et ajustements effectués au niveau des tables de paramétrages de CBS dépend la qualité globale du Sudoc. C’est en particulier à ce moment que l’on fixe les règles pour définir ce qu’il advient des doublons avérés et suspectés. Pour autant, l’objectif étant de tout automatiser, il a fallu convenir de la meilleure méthode d’identification et de traitement des candidats-doublons sans intervention humaine. C’est désormais chose faite : notices uniques et candidats-doublons sont versés automatiquement en base de production et récupèrent un PPN. Bien évidemment, tout le processus est encore scruté de près afin de s’assurer que ces opérations maintiennent un bon niveau de qualité de la base.

Les triplets comprenant les PPN sont alors injectés dans la base RDF.

Et les notices de ressources électroniques ?

Jusqu’à présent, on ne s’est intéressé qu’aux ouvrages décrit via le flux ONIX d’OUP. Ce service comporte hélas un défaut majeur : il ne comprend que les métadonnées de documents imprimés. Impossible à partir de ces données de reconstituer des notices de documents électroniques : il manque en effet des éléments essentiels, comme l’ISBN électronique ou l’URL d’accès.

Heureusement, ces informations sont disponibles via un autre canal : les fichiers KBART d’OUP. Un autre workflow a donc été créé pour traiter ces données : tout d’abord, les fichiers sont  récupérés par la base de connaissance BACON suivant les procédures habituelles, un programme scannant les fichiers à la recherche d’éventuelles mises à jour. Pour faciliter la suite des opérations, un fichier agrégeant toutes les monographies est constitué à chaque changement. Les données de BACON pertinentes sont ensuite chargées dans un graphe particulier de la base RDF.

L’ISBN de la version imprimée – présent dans les données BACON –  sert de pivot pour raccrocher les données de la manifestation électronique (ISBN électronique, date de publication, URL) aux données d’œuvre, exprimées dans celles de la manifestation imprimée (titre, auteurs, indexation…), ce qui fait le lien entre les manifestations. Ainsi, la fameuse zone 452$0 peut être remplie puisqu’à ce moment du processus, on dispose du PPN de la version imprimée.

Mécanisme pour obtenir une notice « électronique » à partir d’une notice « imprimé » et d’un fichier KBART

 

Pour finaliser le processus, la conversion au format MARC et le chargement dans le Sudoc suivent les étapes décrites précédemment. Nos notices électroniques disposent alors chacune d’un PPN, injecté dans la zone 452$0 des notices imprimées via le programme MarcEdMod, outil interne de modification des données Sudoc. Ces données remontent à leur tour dans la base de graphes via la base XML, synchronisée avec le CBS.

La boucle est bouclée : à partir d’informations bibliographiques provenant de sources diverses, nous obtenons des données en RDF et des notices MARC utilisables par le réseau.

Le workflow d’import utilisé pour OUP

Conclusion

Cette expérimentation, qui met en œuvre une gamme d’outils, processus et concepts développés depuis plusieurs années par l’Abes, démontre qu’il est possible de s’affranchir du format MARC en entrée, pour peu que les métadonnées mises à disposition par l’éditeur soient suffisamment structurées. Si l’heure n’est pas encore au bilan – puisque la peinture sèche à peine, on peut déjà exprimer quelques remarques et aspirations pour l’avenir.

La première remarque offre des perspectives intéressantes : la grande modularité de l’outil de gestion de workflow permet d’envisager autant d’enrichissements que souhaité, pour peu que l’on ait la matière et les outils pour le faire. On pourrait par exemple imaginer inclure dans le workflow un outil d’indexation automatique s’appuyant sur l’analyse des résumés ou des tables des matières.

L’ensemble du processus comporte néanmoins quelques limites. Les notices de la base Sudoc ont vocation à y vivre, à être utilisées, enrichies. Partant du principe que les modifications apportées par les professionnels du réseau sont supérieures en termes de qualité à celles  produites automatiquement,  le choix a été fait de ne pas mettre à jour via les workflows décrits, les notices intégrées lors d’un import antérieur, ce, qui aurait exigé de réfléchir à de complexes règles de fusion d’informations. Inversement, du fait qu’il n’y a pas – pour l’heure – de synchronisation entre le Sudoc et la base RDF de travail, les données n’évolueront malheureusement que dans le Sudoc.

Enfin, même s’il s’affranchit du format MARC, ce workflow suppose que les éditeurs ou agrégateurs aient la volonté d’ouvrir leurs métadonnées, celles-ci étant largement utilisées et diffusées dans les silos que sont les bases des sites de vente en ligne – car c’est bien à cela que sert ONIX ! – ou les outils de découvertes pour bibliothèques. Plusieurs gros éditeurs ont déjà fait ce pari d’ouverture, ce qui va permettre à quelques corpus  d’ores et déjà de rejoindre  le corpus OUP dans le Sudoc.  Il reste à espérer que les initiatives comme Metadata2020  rendront cela encore plus courant !!!

Laisser un commentaire

Tweetez
Partagez
Partagez