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

Continuer la lecture

Récit d’une immersion. Traiter les ebooks Dalloz avec les données Sudoc, les données de l’éditeur et les outils du hub

Ce billet relate à la première personne l’immersion effectuée par Catherine Storne (Université de Strasbourg) au sein de l’équipe hub de l’ABES, entre le 1er et le 5 février 2016. Catherine a eu l’occasion de partager cette expérience aux dernières journées ABES. Merci pour tout, Catherine !

Placée en face de la nouvelle « Metadaten Weltanschauung » au travers de la réflexion locale sur l’abonnement à un outil de découverte (discovery tool) ou sur les réalisations de la plateforme ISTEX sur les licences nationales, je ressentais le besoin de monter en compétences sur la manipulation des métadonnées. J’ai donc souhaité faire une immersion à l’ABES pour mieux comprendre les projets de l’établissement tournant autour des métadonnées dont les noms parvenaient aux confins de nos bibliothèques : BACON, hub de métadonnées, CERCLES, ainsi que les liens entre eux. Mon objectif étant de travailler au rapprochement, au sein du SCD de Strasbourg, des équipes de la documentation électronique et du catalogage, la participation à un projet concret, au travers d’un chantier CERCLES me semblait de nature à y contribuer.

Continuer la lecture

Mettre nos données en réseau – un démonstrateur. [1] Introduction.

Ce démonstrateur est un plaidoyer en faveur d’une approche “web sémantique” de l’interopérabilité des données de l’IST. Mais, cette fois, il s’agit de montrer et non d’argumenter. Il s’agit de défendre, en illustrant cette approche par des études de cas. Alors, si vous fuyez les plaidoyers, si vous exigez du concret, de la donnée (RDF), de la requête (SPARQL), passez cette introduction et lisez l’un des billets suivants :

  1. Introduction (ce billet)
  2. Inventaire des données
  3. Suivez le guide ! Le modèle de données
  4. Études de cas

SPARQL endpoint : https://lod.abes.fr/sparql
Interface de recherche full text et de navigation : https://lod.abes.fr/fct

Continuer la lecture

Mettre nos données en réseau – un démonstrateur. [2] Inventaire des données.

[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

Pour les besoins de la démonstration, nous avons agrégé des données diverses et variées, mais finalement cette auberge espagnole n’est pas si anarchique : tout mène à tout, et on peut regrouper les jeux de données de différentes manières :

  • Données descriptives vs Référentiels
  • Données produites par les réseaux ABES vs Données de tiers
  • Données du monde des bibliothèques vs Données d’autres mondes (science, administration, etc.)
  • Données récupérées en RDF vs Données produites en RDF

Mais dans ABES, il y a B : notre réseau de données se déploie autour des données bibliographiques, qui décrivent des livres, des revues, mais également des chapitres et des articles.

Continuer la lecture

Le SUDOC en RDF : du nouveau ! 1/2

A propos du  web de données, et du Sudoc en RDF, voir notamment les billets précédents ici et .

L’été 2013 avait vu la mise en ligne d’une documentation sur l’exposition du SUDOC en RDF, et l’annonce d’un chantier visant à enrichir et affiner progressivement celle-ci. Ce chantier a produit ses premiers résultats au cours de l’année universitaire écoulée, par petites touches successives. Zoom sur les nouveautés.

Alignements

Dans un souci d’interopérabilité avec Data.bnf.fr, le FRBNF des notices BNF a été ajouté, à côté des OCN d’OCLC déjà présents : onto-bnf :FRBNF (propriété maintenue par la BnF elle-même). Les identifiants ark – présents dans une partie des notices du Sudoc, devraient suivre un peu plus tard.

Continuer la lecture

Un serveur SPARQL pour le Sudoc

Depuis juillet 2011, l’ensemble des données Sudoc est accessible en RDF. Si on connaît son identifiant, chacune des dix millions de notices du Sudoc peut être affichée en RDF/XML. Mais encore faut-il connaître cet identifiant… Ce dispositif est utile pour permettre à un programme de naviguer de notice en notice, y compris en rebondissant sur les données RDF d’IdRef par exemple, mais cela ne permet pas d’explorer systématiquement le Sudoc ni d’effectuer une recherche.

Continuer la lecture

IdRef dans VIAF et après … #2 Faciliter et améliorer le catalogage par dérivation

Ce post de fil.abes.fr annonce l’intégration du référentiel IdRef à VIAF et en présente les enjeux stratégiques. Punktokomo prend le relais pour détailler quelques implications pratiques. En voici la deuxième.

Grâce à MARC et Z39.50, le catalogage est d’ores et déjà une pratique professionnelle locale qui fonctionne dans un cadre global. L’idéal visé est le suivant : pour chaque livre, sa notice bibliographique est créée une fois, par quelqu’un, quelque part, puis échangée, reprise, exemplarisée autant de fois que nécessaire, partout, par tous.

Dans le cadre du Sudoc, plutôt que de créer ex nihilo une notice qui manque, le catalogueur interroge d’autres catalogues à la recherche de cette notice. S’il la trouve, il la récupère dans l’outil de catalogage du Sudoc et l’intègre telle quelle, … à beaucoup de détails près… C’est ce qu’on appelle du catalogage par dérivation. En voici un tutoriel, propre au contexte du Sudoc :

Continuer la lecture

IdRef dans VIAF et après … #1 Passer d’un identifiant à l’autre (VIAF, IdRef, LC, BnF, Wikipedia, …)

Ce post de fil.abes.fr annonce l’intégration du référentiel IdRef à VIAF et en présente les enjeux stratégiques. Punktokomo prend le relais pour détailler quelques implications pratiques. En voici la première.

Tout l’intérêt de VIAF repose dans son travail d’interconnexion entre des notices d’autorité d’origines différentes. En effet, les algorithmes de VIAF cherchent à identifier toutes les notices d’autorité qui « parlent’ de la même chose, qu’il s’agisse d’une personne, d’une collectivité ou d’une oeuvre. Ils génèrent alors des grappes (clusters) d’autorités. Ces grappes VIAF possèdent elles-même un identifiant unique, en bijection avec chacun des identifiants des autorités membres de la grappe.

Continuer la lecture

Sudoc, IdRef : de nouveaux Micro Web Services

De nouveaux Micro Web Services Sudoc et IdRef ont été développés :

  • merged : à partir d’un PPN de notice Sudoc ou IdRef fusionnée, trouver le PPN actif (notice valide)
  • multiwhere : localiser (RCR de localisation) un ou plusieurs document(s) à partir de leur identifiant Sudoc (PPN)

A noter : un service where a été précédemment développé pour permettre la localisation d’un seul document à partir de son identifiant (PPN). Il est dorénavant conseillé d’utiliser le multiwhere qui est plus riche que le where : non seulement il permet de traiter plusieurs notices à la fois, mais il contient également les coordonnées géographiques de chaque bibliothèque.

  • frbn2ppn, ocn2ppn, etc. : connaitre l’identifiant Sudoc à partir d’un identifiant externe (BnF, WorldCat, etc.)
  • iln2rcr : connaître la liste des RCR rattachés à un ILN

Pour  retrouver l’ensemble de la documentation technique :

Continuer la lecture

SudocAD : résumé du projet

Voici le résumé du rapport final (+ annexes) du projet SudocAD, mené par l’ABES et le LIRMM en 2010-2011 et co-financé par le TGE ADONIS :

Mené par l’ABES et l’équipe de recherche GraphIK du LIRMM, co-financé par le TGE ADONIS dans le cadre de son appel à projets 2009-2010, le projet SudocAD vise à interconnecter entre eux différents corpus de métadonnées agrégés par la plateforme de recherche ISIDORE, en les reliant au référentiel IdRef. Ce qui est en jeu, ce n’est pas seulement l’efficacité de la recherche dans Isidore, mais l’intégration des données SHS françaises au web de données, auquel IdRef est déjà connecté.

L’objectif opérationnel du projet était d’enrichir automatiquement des notices d’articles du portail Persée, en identifiant (quand elle existe) l’autorité IdRef correspondant à chacun des auteurs de l’article. 13 444 notices ont ainsi été traitées et livrées à ADONIS et à l’équipe Persée.

Pour identifier la notice d’autorité IdRef qui correspond à l’auteur Persée, SudocAD ne se contente pas d’utiliser les informations contenues dans la notice d’autorité mais exploite les connaissances enfouies dans les notices bibliographiques Sudoc liées. Toutes ces connaissances sont exprimées en RDF, selon le vocabulaire FRBROO. Il devient possible alors de raisonner à propos de ces connaissances, grâce aux outils sémantiques conçus et développés par GraphIk.

Les principales étapes du traitement opéré par SudocAD sont les suivantes : le nom et le prénom de l’auteur Persée sont utilisés pour sélectionner une liste parfois longue d’autorités IdRef candidates ; le raisonneur du LIRMM charge un ensemble de données RDF composées de la notice Persée, des autorités candidates et des notices bibliographiques Sudoc liées à ces autorités ; enfin, après avoir analysé ces données au moyen de règles logiques, le raisonneur répartit les autorités candidates en sept catégories de liage, de Strong à Impossible.

SudocAD ne donne donc pas directement un verdict sur la bonne autorité à lier. Mais, à partir du rapport d’analyse en XML et des sept catégories, il est facile de définir un algorithme qui détermine automatiquement l’autorité à lier. Mais il existe plusieurs manières de construire un tel algorithme. Ce rapport distingue les algorithmes de liage automatique qui paraissent les plus pertinents.

A côté du liage automatique, le rapport d’analyse généré par SudocAD peut également être utilisé dans une perspective d’aide à la décision. Il s’agirait d’utiliser ce rapport pour présenter les autorités candidates d’une manière qui facilite et fiabilise le travail manuel du catalogueur qui cherche à lier une notice bibliographique à une autorité.

Afin d’évaluer l’approche de SudocAD, un protocole a été établi pour comparer les résultats d’un traitement automatique aux décisions de liage prises par un catalogueur. Sur un échantillon de 150 notices Persée, elle montre que SudocAD atteint un très bon taux de bonnes décisions (liage ou non liage), autour de 80%, et surtout un taux d’erreur (création de liens erronés) inférieur à  2%.

Au-delà du projet SudocAD, l’ABES et l’équipe GraphIK ont la volonté d’éprouver la validité de cette approche sur d’autres corpus de métadonnées et d’améliorer encore son efficacité en corrigeant les défauts actuels et surtout en élargissant le spectre des informations prises en compte, notamment en exploitant de manière sémantique les co-auteurs et le vocabulaire Rameau.

Continuer la lecture