Calames : les statistiques 2017

calamesEn ce début d’année, voici venu la traditionnelle épiphanie en chiffres du réseau Calames. Le présent billet se propose de fournir aux établissements déployés dans Calames des éléments complémentaires aux statistiques accessibles via Webstats : jauges quantitatives des données produites via l’outil de catalogage ; répartition actualisée des niveaux descriptifs indexés dans la base de données et exposées sur le web ; étiage du trafic sur le catalogue en ligne.

Mais au-delà de ces aspects quantitatifs, c’est la qualité des données qui est au cœur des préoccupations de l’équipe Calames. Si en 2017, les contrôles qualité ont été concentrés sur les inventaires dont l’encodage a été co-financé par l’Abes dans le cadre de sa mission d’encouragement aux rétroconversions, d’autres sondages, plus globaux, ont été effectués : une inspection des liens vers les numérisations (éléments <dao> et <daogrp>) a par exemple permis une correction générale de centaines de liens au cours de l’été 2017. La remise en place progressive d’une cellule nationale de l’EAD en bibliothèques, le (ré-)examen de diverses consignes de catalogage et la poursuite d’une homogénéisation des bonnes pratiques, laissent espérer que ce travail de monitoring et d’aide à une production de qualité s’amplifiera en 2018.

Nota bene : les termes « composants » et « niveaux descriptifs » se trouvent souvent assimilés dans la présentation de ces statistiques. Ils ne sont pourtant pas strictement synonymes, puisque les hauts niveaux d’inventaires (dont les identifiants Calames commencent par le préfixe « FileId-« , en reprenant le numéro interne de chaque instance EAD dans la base de données), qui ne correspondent donc pas à des composants <c>, représentent 1446 des 873 504 niveaux descriptifs comptabilisés.

État de la base publique Calames au 31 décembre 2017

Répartition  des niveaux descriptifs publiés dans Calames : par établissement

repartition-c-publies-fin-2017-par-RCR_png

Répartition des niveaux descriptifs publiés dans Calames : par tranches chronologiques de production

OriginesDonneesCalames2017_png

Répartition  des composants publiés dans Calames : par cercles de déploiement (1er cercle déployé en 2008, 10ème cercle début 2018)

repartition-c-publies-fin-2017-par-cercles_png

Nouvelles données publiées dans Calames

La catalogue public Calames a soufflé sa 10ème bougie en décembre 2017 en approchant des 875 000 niveaux descriptifs publiés :

evolution-c-publies-2007-2017_png

La quantité de données nouvellement publiées a connu un léger tassement en 2017. Elle est largement due à trois grands « publiants » : la BDIC, l’INHA et la BIU Sorbonne. Ces tendances viennent en écho direct aux travaux d’encodage de l’année (cf. infra).

surcroit-c-pub-2017-par-RCR_png

Travaux de catalogage dans l’outil Calames Prod

Pour la cinquième année consécutive, le nombre d’identifiants nouvellement attribués par l’outil Calames Prod au cours de l’année est resté au-dessus de la barre des 100 000 composants, quasiment tous créés en base de production (et non de formation, dont l’usage doit être cantonné à des tests techniques ou à des exercices pédagogiques).
Cependant la majorité de cette production n’est pas aussi également répartie que les années précédentes : la BDIC (qui sera rebaptisée « La Contemporaine » en mars 2018) tient très nettement le haut du pavé avec un tiers des niveaux descriptifs créés dans l’année. Situation dont le seul point de comparaison est 2010 (le Muséum ayant alors produit près de 45% des <c>), alors que le réseau Calames était moins développé.
Viennent ensuite six établissements ayant produit 6 à 7% des <c> de l’année 2017 : Muséum National d’Histoire Naturelle, École Centrale Supélec, BIU Sorbonne, Bibliothèque Littéraire Jacques Doucet, Bibliothèque Mazarine, et Institut National d’Histoire de l’Art.
Le palmarès des 5 établissements ayant créé la plus grande quantité (env. 60%) de niveaux descriptifs dans Calames depuis son origine reste inchangé par rapport à 2016 : Muséum National d’Histoire Naturelle (165 955 <c> créés dans l’outil depuis 2008), BDIC (146176), Institut de France (906 56), Bibliothèque Littéraire Jacques Doucet (73 151) et Académie de Médecine (640 870).

catalogage-dans-calames-2017_png

Pour compléter un peu ce paysage très métrique et brossé à grands traits, le graphique ci-dessous tente de nous en dire plus sur le temps et la fréquence d’usage de l’outil de catalogage Calames Prod. Ainsi, s’il est vrai que la BLJ Doucet a produit un peu plus de 7400 <c> en 2017, elle l’a fait au prix d’un recours plus important à l’outil d’encodage que les autres établissements, effectuant 698 interventions quotidiennes sur fichiers EAD unitaires (soit près de 700 « jours-fichiers »). L’École Centrale, qui est essentiellement intervenue sur deux à trois inventaires distincts au cours de l’année, présente logiquement ici des chiffres plus bas (127 « plages journalières d’interventions sur inventaire » en 2017, et ce quelque soit la durée ou la qualité de l’intervention en question). Au-delà de toute possibilité d’analyse plus précise des modifications effectuées sur des <c> déjà existants, de leur nature et de leur ampleur, un ratio se dégage depuis trois ans : pour une session quotidienne de catalogage sur fichier EAD, compter un vingtaine de <c> nouvellement créés et identifiés.

temps-frequence-catalogage-calames-2017_png

Ventilation des résultats de 10 années de catalogage dans Calames (en production et en publication/indexation)

c-publies-produits-2008-2017_png

Le décalage entre ces deux représentations des composants créés via l’outil Calames (<c> publiés / <c> créés) tient au fait qu’on dénombre en permanence dans la base, et ce depuis quelques années, environ 100 000 composants présents mais n’ayant jamais connu de première publication (fin 2017, en effet, on frôle le million de composants présents en base de production). L’étiage des chantiers d’encodage étant assez stable depuis 2012, on doit aussi lire ce double histogramme en se rappelant qu’une (petite) proportion de niveaux descriptifs sont soit ré-identifiés au fil du temps (ce qui peut se justifier en cas de restructuration des descriptions), soit créés pour en remplacer d’autres (versions multiples d’un même inventaire par exemple).

Statistiques de consultation 

De même qu’en 2015 et en 2016, la hausse continue de la quantité de données exposées, ainsi que plusieurs épisodes de popularité liés aux recherches ponctuelles de certains mots-clés sur les moteurs de recherche généralistes, se sont soldés par un nombre de visites sur le catalogue public en accroissement.

La moyenne du trafic se situe à environ 25 000 visites/mois (soit 8 000 de plus qu’en 2016, ce qui est lié notamment à un important épisode de popularité du site en mars 2017). Le phénomène de « zapping » des internautes reste cependant très sensible, les deux tiers de visites étant « courtes » voire « très courtes ».

Jean-Marie Feurtet, responsable Calames

Chantier Qualité des données de thèses : bilan 2017

En février 2017, l’Abes annonçait via les listes de diffusion des réseaux Sudoc et Thèses que les établissements intéressés pouvaient demander des  traitements automatiques sur les notices de thèses du Sudoc. Ce billet fait le point sur les modifications réalisées entre février et novembre,  ce à l’initiative soit des établissements, soit de l’Abes.

Rappel

thesestheses.fr, moteur de recherche des thèses de doctorat, a pour objet d’afficher les thèses soutenues en France depuis 1985 ainsi que les thèses en préparation ( depuis 10 ans au maximum). Il s’agit donc de données en provenance des applications nationales STEP et STAR et du Sudoc.
Pour les thèses soutenues, le parti pris de theses.fr consiste à regrouper en une seule page l’œuvre « thèse »,  quelle que soit la variété de ses supports matériels et en mettant en avant sa version de soutenance, estampillée d’un tampon «validée par le jury ». Il s’agit donc d’une FRBRisation des données de thèses de doctorat présentes dans le Sudoc.
Dans un monde parfait, les données du Sudoc  trouvent naturellement leur place  dans theses.fr. Hélas, les données du Sudoc ne sont pas parfaites. Grâce au programme de FRBRisation AlgoSudoc, les principales erreurs empêchant le versement dans theses.fr ont été détectées et, depuis le printemps 2015, les établissements ont accès à ces erreurs et peuvent y remédier.

Opérations menées

En 2017, l’Abes a eu l’opportunité de travailler à nouveau sur cette question.  Grâce au renfort d’un collègue contractuel recruté pour cette activité et à un nouvel outillage technique – développé à l’Abes  et à usage strictement interne, ces travaux sont venus en complément des outils traditionnels d’administration des données fournis par OCLC.

Ainsi, de février à novembre 2017, plus de 160 000 notices Sudoc ont été modifiées en utilisant ce nouvel outil d’administration de données. Pendant l’été 2017, une part importante des corrections a été traitée « à la main », principalement des fusions de notices et des corrections de liens erronés entre notices bibliographiques. L’objectif était double :

  • charger dans theses.fr des notices en provenance du Sudoc n’ayant pu être chargées du fait de leur médiocre qualité

Il s’agissait de corriger des erreurs manifestes et, à cette occasion, d’enrichir les notices originelles, notamment celles dépourvues de numéro national de thèses (zone 029), de note de thèse structurée (328$bDiplôme$cDiscipline $eEtablissement de soutenance$dDate de soutenance) ou de code domaine TEF (zone 686).
Des lots ont été constitués établissement par établissement, afin de permettre un versement des modifications dans les SIGB et de compléter les points d’accès 712 à l’établissement de soutenance.

  •  mettre de l’ordre dans les données déjà visibles dans theses.fr

En 2013, lors du versement des données Sudoc dans theses.fr, des choix devaient être faits  – tout verser ou ne verser que les notices de meilleurs qualité ? C’est une voie médiane qui a été retenue : les données Sudoc chargées dans theses.fr comportaient les zones essentielles, même si le contenu de ces zones était parfois peu exploitable ou non conforme aux recommandations du Guide Méthodologique.
Ainsi, par exemple, chaque occurrence distincte d’une zone 328$eEtablissement de soutenance dans une notice de thèse en provenance du Sudoc a créé une entrée au niveau de la facette « Établissements » dans theses.fr. Cette facette n’aurait dû contenir qu’environ 200 entrées puisqu’il existe une liste fermée des libellés des établissements de soutenance …. cependant, le recours à cette liste n’étant pas contrôlé dans WinIBW, n’importe quoi peut en réalité être saisi en 328$e, ce qui a parasité le fonctionnement de la facette « Etablissements » dans theses.fr.

Dans d’autres cas, le désordre dans theses.fr n’était pas dû à des consignes de catalogage non respectées mais à l’évolution des consignes de catalogage. Par exemple, longtemps il n’a pas été possible – dans le Sudoc (alors que STAR le permettait) – de qualifier finement les rôles de personnes en relation avec la thèse (membre du jury, président, rapporteur) ou les rôles des organismes (établissement de cotutelle, école doctorale, autre partenaire de recherche…). Fin 2014, l’Abes a créé  de nouveaux codes de fonction dans le Sudoc et a incité les catalogueurs à s’en servir (cf J.e-cours du 14/12/2014 « Description des thèses de doctorat » ). Évidemment, une grande partie des données rétrospectives du Sudoc étaient à corriger. Même si toutes les données n’ont pu être traitées en 2017, cela a constitué un axe majeur des modifications réalisées.

Résultats

Quantitativement, le nombre de page décrivant des thèses soutenues a fortement augmenté en 2017 [ie : nombre de thèses soutenues en 2016 et 2017  et signalées pour la première fois dans theses.fr au cours de l’année 2017]. Ainsi, alors qu’en 2016, le taux d’accroissement était de 4,04%, de février à décembre 2017, le nombre de pages de thèses soutenues dans theses.fr a connu un accroissement de 10,88%.

Qualitativement, les efforts ont principalement portés sur les organismes liées à la thèse, ce qui a permis de nettoyer les facettes ainsi que les pages dédiées aux organismes. Voici par exemple une copie d’écran de la facette «Établissements» réalisé le 10/02/2017. On y voit, surlignées en jaune, les entrées erronées (faculté),  autant d’éléments aujourd’hui corrigés.

 

 

 

 

 

 

 

 

 

 

Dans la mesure du possible, les zones de texte libre présentes dans la note de thèse – indiquant par exemple la discipline – ont été harmonisées.

Par ailleurs, suite à l’appel lancé via les listes de diffusion, quelques établissements ont sollicité l’Abes pour corriger des lots de données. Parmi les cas les plus fréquents : les notices de reproduction ou les versions électroniques de thèse versées dans une archive institutionnelle locale, pour lesquelles l’URL de diffusion dans la zone 856 devait être corrigée.

Conclusion

Malgré ces forces supplémentaires qui ont permis d’améliorer la qualité des données de thèses dans le Sudoc, ce dossier n’est hélas pas clos. En effet, le programme AlgoSudoc de FRBRisation des données du Sudoc en vue de leur chargement dans theses.fr détecte encore des milliers d’erreurs et les rend publiques.

Afin  que le slogan de theses.fr «Signaler l’ensemble des thèses de doctorat soutenues en France depuis 1985 » devienne réalité, l’Abes invite les établissements qui ne se sont pas encore emparés de ce dossier à prendre en main les données qui leur incombent.

IMR

Déploiement d’OATAO dans IdRef : une nouvelle visibilité sur le web

logo_oatao      idrefOSM

OATAO – l’archive institutionnelle et mutualisée des établissements Toulouse INP (Institut National Polytechnique de Toulouse), ENVT (École Nationale Vétérinaire de Toulouse), ISAE-SUPAERO (Institut Supérieur de l’Aéronautique et de l’Espace) et ENSFEA (École Nationale Supérieure de Formation de l’Enseignement Agricole) – et IdRef – application qui permet d’attribuer des identifiants fiables et pérennes, notamment aux membres de la sphère ESR – viennent de réussir leur connexion.  Autrement dit, les dépôts dans OATAO s’accompagnent désormais d’un liage des auteurs à leur autorité dans IdRef ; corrélativement, le cercle des contributeurs IdRef s’élargit pour accueillir en production une Archive Institutionnelle, une première !

Côté IdRef, les notices des quelques 500 auteurs de l’archive institutionnelle OATAO sont désormais enrichies d’un encart bibliographique supplémentaire. Deux modalités d’accès à leurs dépôts sont proposées dans les notices IdRef des auteurs concernés : accès par source dans la page dynamique et accès par rôle dans la page pérenne.

Ainsi, dans la notice « dynamique » d’IdRef (termes de recherche : « Merlina, Georges »), on peut consulter toutes les ressources émanant de l’archive pour cet auteur :

image1

De la même façon, dans la notice « pérenne » d’IdRef https://www.idref.fr/081940807, on accède à l’ensemble des ressources liées à cette personne en fonction de son rôle dans le dépôt, en l’occurrence auteur :image2

Dans les deux cas, on peut rebondir sur le full text des articles en cliquant sur l’identifiant numérique de la ressource. Toute la production de recherche des 4 établissements toulousains est ainsi propagée sur le web via IdRef.

De plus, dans l’application OATAO, il est désormais possible d’effectuer une recherche à l’aide d’un identifiant IdRef. On obtient ainsi pour résultat toutes les ressources liées à un auteur :

Image OATAO 1

La boucle est bouclée puisque sur la page d’une publication, le rebond est possible depuis les auteurs alignés vers leur notice IdRef correspondante via l’icone idoine.Image OATAO 2

Autre exposition, les identifiants IdRef seront poussés dans les exports notamment via le serveur OAI-PMH. Enfin, l’utilité de l’index des identifiants IdRef -index nouvellement créé et dédié aux gestionnaires OATAO, va au-delà puisqu’il permettra de proposer un index limité aux chercheurs des 4 établissements, demande récurrente des instances d’OATAO.

Workflow OATAO de connexion à IdRef

Pour initialiser l’interconnexion des bases, OATAO a eu recours au service d’identification des Personnes proposé par l’Abes. Les algorithmes d’identification ont une nouvelle fois rendu un fier service afin d’aligner les auteurs OATAO présents dans plus de 3 000 articles déjà en base.

  • Signalement des métadonnées d’un article : liste des auteurs

image5

  • Interrogation du moteur Solr d’IdRef :

image6

  • Si la requête SolR ne remonte pas de résultat, on bascule sur l’iframe d’IdRef :

image7

  • Dans IdRef, on retrouve alors la possibilité de « lier une notice » existante ou de créer une notice :

Image8

Retour dans l’interface de dépôt, l’identifiant Idref a été rapatrié dans la colonne « ppn » : les 2 auteurs sont alignés au sein des 2 applications.

image9

Éléments de politique documentaire

Côté politique documentaire, le recours aux autorités lors du dépôt d’un article est désormais une obligation pour les bibliothécaires-administrateurs de l’archive sur le périmètre des auteurs OATAO. Cette évolution, facilitée par la fluidité de l’interconnexion à IdRef, n’en représente pas moins une charge de travail supplémentaire. Si le jeu de l’interopérabilité en vaut la chandelle, il s’agira de mesurer plus finement dans les mois à venir l’impact sur le temps de traitement d’un dépôt dans l’archive, des nécessaires vérifications dans IdRef pour être sûr de lier à la bonne autorité ainsi que des éventuelles créations de notices d’autorité.

Par chance, l’équipe d’administrateurs OATAO peut compter sur l’aide du Correspondant Autorités de l’INP, qui œuvre depuis plusieurs années dans l’archive. Si le rappel des consignes et le traitement des anomalies (ex : doublons) ont augmenté sa charge de travail, sa « casquette » au sein de l’équipe est également plus affirmée et cette expertise est un plus au quotidien pour toute l’équipe. De plus, les cas d’investigation avancée sont l’occasion de « reprendre » contact avec les chercheurs afin d’assurer des attributions bibliographiques ou des informations dans l’autorité.

Autre heureuse perspective : IdRef offre une fonctionnalité de pré-remplissage des notices d’autorité dont OATAO peut escompter un gain important pour fluidifier son workflow. Déjà activée dans STAR pour la création des notices de docteurs, OATAO pourra ainsi pousser des données bibliographiques de l’article en traitement pour éviter aux administrateurs de ressaisir des informations déjà enregistrées dans l’archive.

Et plus loin encore, les chercheurs-déposants pourront-ils aussi se lier à leur notice ? Les auteurs extérieurs se verront-ils également liés ? A suivre !

D’ici là, un grand merci à Jean-Marie Le Bechec et à Yann Sérot, pour une coopération agréablement et rondement menée.

François Mistral, responsable IdRef

Si vous êtes intéressé par ce service pour votre Archive institutionnelle, n’hésitez pas à contacter : idref@abes.fr

 

 

 

Quand ScanR et IdRef s’associent pour identifier les acteurs de la recherche et de l’innovation

ScanR, moteur de la Recherche et de l’Innovation, outil désormais bien connu dans la sphère ESR, propose à la réutilisation de nombreux jeux de données sous licence ouverte. Ces données, également accessibles via la plateforme OpenData du MESRI sont synchronisées avec data.gouv.fr, plateforme des données publiques françaises mis à disposition par Etalab.

 

S’inscrivant dans la logique d’ouverture portée par ScanR, l’Abes a utilisé les données IdRef et ses algorithmes d’identification afin de lier 3 jeux de données exposés et utilisés dans ScanR via son référentiel auteurs.

 

Lauréat-e-s du trophée « Les Étoiles de l’Europe »

Sur 48 entrées, 42 personnes (soit 87, 5 %) ont été identifiées de façon certaine La recherche n’a pas été poussée plus avant pour les 6 personnes manquantes, les résultats fournis par l’algorithme étant estimés satisfaisant. Les identifiants sont disponibles dans le jeu de données.

Finalistes et lauréats du concours « Ma Thèse en 180 secondes »

Sur 71 entrées, seulement 13 (soit 18, 3%) ont été identifiés en tant que « thèses soutenues ». Un taux de rappel très faible qui s’explique  du fait du délai de signalement des thèses (360 jours en moyenne). En effet, vérification faite de la présence des données dans theses.fr,  la très grande majorité d’entre elles sont effectivement signalées mais en tant que « thèses en préparation ».

Membres de l’Institut Universitaire de France (IUF)

Ce corpus, dont l’historique remonte à 1991, possède le volume le plus conséquent : après dédoublonnage, les 2041 entrées renvoient à 1 700 personnes distinctes. Les opérations d’alignement comportent 2 dimensions complémentaires :

  • la couverture (ou taux de rappel) : toutes les personnes ont été identifiées, avec une fourniture de 1 700 identifiants IdRef distincts. La couverture pour ce corpus est donc totale. Les membres de l’IUF figurent bien tous dans IdRef.
  • la fiabilité  (ou taux de précision) : l’identification se doit d’être évaluée, notre parti pris étant de fournir des identifications à la fiabilité très élevée, ce que dénote le choix des algorithmes utilisés.

D’un point de vue méthodologique, le programme de liage a confronté les données du jeu de données en entrée avec le contenu des notices d’autorité IdRef, enrichies du contenu des notices bibliographiques Sudoc liées. Plusieurs heuristiques ont été exploitées :

  • cocontrib : si deux personnes ont des noms très proches et des co-contributeurs aux noms très proches
  • collectivités + Dewey : si deux personnes ont des noms identiques et sont associées à une même collectivité (laboratoire ou université) et que la thématique de recherche correspond à un indice Dewey connu pour la personne
  • laboratoire : si deux personnes ont des noms identiques et sont associés à un même laboratoire
  • université : si deux personnes ont des noms identiques et sont associées à une même université

Précisions que, bien qu’absente de cette fourniture,  l’heuristique Unica est également régulièrement utilisée : si deux personnes ont des noms identiques et qu’il n’y a aucune autre autorité candidate dont le nom est approchant, on peut conclure qu’il s’agit de la même personne.

Tableau de ventilation des matchs par heuristique

Heuristique                     Nombre de match
 Cocontrib                           782
 Collectivé+Dewey                    184
 Laboratoire                         248
 Université                          381
 Vérifié                             446
 Total général                      2041

A l’aune des évaluations précédemment réalisées, on sait que Cocontrib possède un taux de précision moyen de 98% (estimé supérieur à un catalogage « pressé »). Pour les heuristiques associant des collectivités, le corpus IUF a servi de premier test. A défaut d’une évaluation systématique, les sondages réalisés – dont témoignent les matchs en statut « vérifié », nous permettent d’accorder une confiance de niveau « très élevé » à Collectivités + Dewey et Laboratoire, et une confiance de niveau « élevée » à Université.

Au vu de ces règles, chaque réutilisateur peut déterminer son propre seuil de confiance. Si le risque d’erreur existe, dans le cas présent avec le corpus IUF, de façon très concrète, les données fournies sont considérées comme fiables par l’Abes. Elles seront donc intégrées au jeu de données sur les IUF lors de sa prochaine actualisation.

Pour conclure la relation de cette fructueuse coopération associant l’équipe du Département des outils d’aide à la décision du MESRI et l’Abes, il nous semble important de mettre en exergue deux bénéfices en particulier :

  • l’enrichissement des données publiques
  • la démonstration que l’ouverture des données à tous contribue à améliorer leur qualité – ici leur interopérabilité – grâce à une identification fiable et pérenne !

François Mistral, pour l’équipe IdRef

Remerciements à l’équipe du Département des outils d’aide à la décision du MESRI

CERCLES OPENEDITION : UN ALGORITHME POUR AUTOMATISER LES LIENS 7XX

Le chantier CERCLES OpenEdition

CERCLES_Sarah8Klocars_Clauser_via_OpenPhoto

Sarah Klocars Clauser (via OpenPhoto)

Lancé en 2015 par le SCD de l’Université François Rabelais de Tours – l’un des établissements ayant activement milité pour la création du dispositif –   le chantier CERCLES OpenEdition consiste principalement à l’enrichissement des notices bibliographiques du corpus OpenEdition (3959 notices au 01/07/2017), un travail réalisé par une équipe de catalogueurs du SCD, sous la responsabilité de Véronique Lacan, coordinatrice Sudoc.

Étapes à la loupe

Pour le traitement des notices d’e-books, il convient de  procéder dans un premier temps à la visualisation de 2 notices : celle de l’e-book à enrichir et celle de la manifestation imprimée, quand celle-ci existe. Pour cela, l’option « multifenêtrage » de WinIBW est activée.

Image1

Menu Fenêtre > Mosaïque verticale

En plus de la relecture complète, l’attention est ensuite portée sur les zones à vérifier et/ou enrichir particulièrement :

  • 035 : vérification du code source à partir du site Open Edition Books (OEB)
  • 010 : vérification de l’ISBN à partir du site OEB
  • 1XX : vérification des données codées, dont les dates
  • 200 : vérification du titre et des mentions de responsabilité (nombreux contributeurs reportés en 314)
  • 307 : ajout de la pagination de l’édition imprimée (si elle existe)
  • 310 : vérification des modalités d’accès et mise en cohérence de cette information dans les zones 856 ou 859
  • 452 : lien vers la notice de l’édition imprimée et lien réciproque
  • 6XX : complétude de l’indexation matière
  • 70X : lien à la notice d’autorité du contributeur (le plus souvent :  zones 701)

C’est principalement  l’enrichissement de cette zone 70X qui peut s’avérer complexe : soit la notice d’autorité n’existe pas encore, soit un choix doit être effectué entre plusieurs notices d’autorité, en cas d’homonymie par exemple :

  CERCLES_doublon_autorite

De plus, ce traitement peut s’avérer long et fastidieux, les notices d’e-books proposant de nombreux contributeurs, comme par exemple  :

CERCLES_contributeurs

Une vingtaine de contributeurs pour cette notice : autant de liens à créer

L’intérêt du traitement automatique

CERCLES_hula_hoop_by_Lars_Plougmann_via_Flickr_CC_BY_SA_2_0

Un algorithme au service du CERCLE…

Menée au SCD de l’université Picardie Jules Verne dans le cadre d’un autre chantier CERCLES comportant également de nombreux accès Auteurs à créer (voir le billet à ce sujet), une première expérimentation a démontré la capacité du programme de traitement automatique mis au point par les équipes de l’Abes.  A l’aide de cet algorithme conçu pour rechercher puis lier automatiquement les points d’accès 70X aux notices d’autorité correspondantes, un lien 7XX a été ajouté automatiquement à 749 notices sur 987, soit un taux d’erreur d’à peine 0,5 %. Une expérimentation globalement positive dont l’Abes a fait la promotion, notamment lors de l’atelier  « Aligner, le signalement augmenté » présenté par Yann Nicolas lors des Journées Abes 2017.

Saisissant cette opportunité, le SCD de Tours a sollicité les équipes de l’Abes pour bénéficier d’un traitement similaire sur le corpus OpenEdition, expérimentation lancée lors de la rencontre de travail avec un membre de l’équipe OpenEdition. Ainsi, en juin dernier, l’algorithme a  tourné sur le dernier fichier d’import de notices OpenEdition chargé dans le Sudoc. Les résultats  sont tout aussi satisfaisants : le programme est parvenu à lier automatiquement 733 sur 977 points d’accès, soit 75 % de réussite. Ce sont donc des notices avec des zones 7XX liées et validées qui ont été importées dans le Sudoc, facilitant considérablement le travail du SCD de Tours et bénéficiant à tous les établissements du réseau.

L’aide à la décision

Autre avantage de ce traitement :  pour les notices n’ayant pu bénéficié du traitement automatiquement, un rapport d’aide à la décision – résultat d’une analyse et d’un décryptage – est fourni au responsable du chantier CERCLES,  coupe de pouce bien utile pour organiser le travail de correction et témoignage que l’Abes respecte son engagement dans le dispositif CERCLES : « contribuer aux enrichissements, par un travail d’expertise préalable, par la fourniture d’outils automatisés et enfin par l’analyse et le conseil pour organiser le travail d’enrichissement« .

Ainsi, la responsable du chantier OpenEdition a disposé d’une grille de corrections à effectuer sur une partie des 244 points d’accès non traités,  pour lesquels des suggestions de liens ont été exprimées :

  • sur la base de rapprochement avec des titres similaires (73 cas)
  • sur la base de rapprochement avec des éditeurs similaires (33 cas)
  • sur la base de rapprochement avec des co-contributeurs similaires (2 cas)

Dans 10 cas seulement, aucune proposition n’a pu être opérée par le programme, les notices d’autorités potentiellement liables comportant des erreurs de catalogage, à corriger au préalable.

Image2

Extrait de l’analyse du traitement et sa grille de lecture

A partir de ce traitement automatisé, les catalogueurs du chantier CERCLES OpenEdition disposent donc d’un guide de corrections, de listes de PPN toutes prêtes sur lesquels ils peuvent intervenir. Ainsi, l’essentiel de leur travail peut se concentrer sur l’analyse et le choix de liens « problématiques », plutôt que sur la tâche purement technique et répétitive, de liages « indiscutables » aux autorités.

C’est en effet dans ce travail d’analyse et de choix complexes que s’exercent véritablement les compétences des catalogueurs, et non dans l’acte technique de simple liage qui peut être, sans remords, délaissé aux machines.

 

Visualiser les données de BACON grâce à OpenRefine

Avec près de 80 diffuseurs et plus de 400 bouquets décrits, les données BACON constituent un vivier d’informations que l’on peut exploiter de multiples manières. Non seulement elles sont utiles pour améliorer le signalement de la documentation en ligne, mais elles peuvent de plus être manipulées dans tous les sens, grâce à l’ouverture technique sur laquelle on avait misé dès le début.
L’objet de ce billet est de montrer comment BACON peut répondre à une question fréquemment posée : où se trouve cette revue, chez qui est-elle gratuite, chez qui est-elle payante, et sur quels intervalles chronologiques ? Cette question a notamment été soulevée sur le blog Biblioweb. Ici, on va s’intéresser au mode de distribution des revues qui par ailleurs sont disponibles sur CAIRN.
Les données de BACON peuvent répondre à toutes ces questions grâce aux informations structurées en KBART v2. On connaît en effet l’état de collection d’une revue (date_first_issue_online – date_last_issue_online), on sait si elle est sur abonnement ou gratuite (access_type) et on sait combien d’années peuvent s’écouler entre la mise en ligne où l’accès est payant et l’ouverture à tous (embargo_info). Il nous suffit ensuite de partir d’une liste d’ISSN, imprimés ou électroniques, qui nous intéressent, utiliser les webservices BACON adéquats et de mouliner le tout.
Les résultats peuvent prendre l’apparence d’un simple tableau, mais dans ce cas précis il est sans doute plus pertinent de voir d’un coup d’œil l’ensemble des informations qui nous intéressent afin d’obtenir quelque chose qui ressemble à ça :


La démarche que je vous propose pour aboutir à ce résultat est une démarche « bidouille » : on trouve quelque chose qui se rapproche de ce que l’on souhaite faire, on regarde comment ça marche, on l’adapte avec les outils à sa disposition et/ou que l’on maîtrise. En l’occurrence, tout ce qui sera montré ici sera fait avec OpenRefine.

Le modèle à trouver et à comprendre

C’est sans doute la partie la plus simple. En parlant autour de moi de cette idée de visualisation, un collègue m’a tout de suite orienté vers ceci https://developers.google.com/chart/interactive/docs/gallery/timeline, une bibliothèque javascript issue de Google Charts qui permet justement de créer des frises chronologiques. L’idée générale est donc de créer une page html, lisible par n’importe quel navigateur, qui contiendra les données que l’on veut afficher ainsi que le code pour les mettre en forme. On ne s’occupera que de la partie « données ». Tout le reste sera géré par le code que l’on se contentera de recopier (mais qu’il faut comprendre un tout petit peu).
L’exemple ci-dessous correspond exactement à ce que l’on veut faire : on veut pouvoir grouper par type (ici Président, Vice Président et Secrétaire d’Etat mais pour nous Gratuit et payant) des états de collection correspondant à différents fournisseurs (ici Washington, Adams, Jefferson, pour nous Persée, Open Edition, CAIRN par exemple). La structure du script n’est pas difficile à comprendre :


<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script>
<div id="example3.1" style="height: 200px;"></div>
<script type="text/javascript">
google.charts.load("current", {packages:["timeline"]});
google.charts.setOnLoadCallback(drawChart);
function drawChart() {

var container = document.getElementById('example3.1');
var chart = new google.visualization.Timeline(container);
var dataTable = new google.visualization.DataTable();
dataTable.addColumn({ type: 'string', id: 'Position' });
dataTable.addColumn({ type: 'string', id: 'Name' });
dataTable.addColumn({ type: 'date', id: 'Start' });
dataTable.addColumn({ type: 'date', id: 'End' });
dataTable.addRows([
[ 'President', 'George Washington', new Date(1789, 3, 30), new Date(1797, 2, 4) ],
[ 'President', 'John Adams', new Date(1797, 2, 4), new Date(1801, 2, 4) ],
[ 'President', 'Thomas Jefferson', new Date(1801, 2, 4), new Date(1809, 2, 4) ],
[ 'Vice President', 'John Adams', new Date(1789, 3, 21), new Date(1797, 2, 4)],
[ 'Vice President', 'Thomas Jefferson', new Date(1797, 2, 4), new Date(1801, 2, 4)],
[ 'Vice President', 'Aaron Burr', new Date(1801, 2, 4), new Date(1805, 2, 4)],
[ 'Vice President', 'George Clinton', new Date(1805, 2, 4), new Date(1812, 3, 20)],
[ 'Secretary of State', 'John Jay', new Date(1789, 8, 25), new Date(1790, 2, 22)],
[ 'Secretary of State', 'Thomas Jefferson', new Date(1790, 2, 22), new Date(1793, 11, 31)],
[ 'Secretary of State', 'Edmund Randolph', new Date(1794, 0, 2), new Date(1795, 7, 20)],
[ 'Secretary of State', 'Timothy Pickering', new Date(1795, 7, 20), new Date(1800, 4, 12)],
[ 'Secretary of State', 'Charles Lee', new Date(1800, 4, 13), new Date(1800, 5, 5)],
[ 'Secretary of State', 'John Marshall', new Date(1800, 5, 13), new Date(1801, 2, 4)],
[ 'Secretary of State', 'Levi Lincoln', new Date(1801, 2, 5), new Date(1801, 4, 1)],
[ 'Secretary of State', 'James Madison', new Date(1801, 4, 2), new Date(1809, 2, 3)]
]);

chart.draw(dataTable);
}
</script>

Les éléments qui se rapportent aux données sont :

  • Un « id », que l’on trouve à deux endroits
    • var container = document.getElementById('example3.1');)
    • <div id="example3.1" style="height: 200px;">
    • Le premier permet de lier un identifiant au set de données que l’on va inscrire, le deuxième permet d’afficher notre frise. Dans notre cas on a besoin d’un id par revue.
  • La description de nos colonnes, par exemple ici dataTable.addColumn({ type: ‘string’, id: ‘Position’ }); Il faut donc donner le type d’information (‘string’, simples chaînes de caractères ou ‘date’) et le nom (id) de la colonne. Nous aurons besoin d’une colonne ‘prix’ (payant/gratuit), d’une colonne ‘diffuseur’ et de deux colonnes de date (début et fin). Ces informations seront toujours les mêmes, quelle que soit la revue.
  • Nos données à proprement parler se trouvent après dataTable.addRows, par exemple [ ‘President’, ‘George Washington’, new Date(1789, 3, 30), new Date(1797, 2, 4) ]. Dans notre cas ce sera par exemple [ ‘payant’, ‘CAIRN’, new Date(2008, 0, 0), new Date(2016, 11, 30) ]. Dans les objets dates Javascript, les mois et les jours sont indexés en partant de 0. Le premier janvier est donc ‘0,0’, le 31 décembre ‘11,30’).

La bibliothèque se charge de tout mettre dans l’ordre, il n’est donc pas nécessaire de grouper les « gratuits » ensemble ni de mettre les différents éléments dans l’ordre chronologique.

Si l’on reprend notre structure, on cherche donc à  avoir pour chaque revue  (les variables sont entre ##):


#titre_revue# – #editeur_scientifique#<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script>
<div id="#ISSN_revue1#'" style="height: 200px;"></div>
<script type="text/javascript">
google.charts.load("current", {packages:["timeline"]});
google.charts.setOnLoadCallback(drawChart);
function drawChart() {

var container = document.getElementById('#ISSN_revue1#');
var chart = new google.visualization.Timeline(container);
var dataTable = new google.visualization.DataTable();
dataTable.addColumn({ type: 'string', id: 'prix' });
dataTable.addColumn({ type: 'string', id: 'diffuseur' });
dataTable.addColumn({ type: 'date', id: 'debut' });
dataTable.addColumn({ type: 'date', id: 'fin' });
dataTable.addRows([
[ '#prix#', '#diffuseur#', new Date(#debut#, 0, 0), new Date(#fin#, 11, 30) ],
[ '#prix2#', '#diffuseur2#', new Date(#debut2#, 0, 0), new Date(#fin2#, 11, 30) ]
]);

chart.draw(dataTable);
}
</script>

La page finale que l’on cherche à générer sera un tableau html où chaque ligne comportera le code correspondant à une revue.

Préparer la requête BACON

On veut maintenant trouver une liste de toutes les revues distribuées par CAIRN. BACON est bien entendu le bon endroit où chercher. Un rapide tour sur l’interface https://bacon.abes.fr permet de récupérer ce qui nous intéresse. En allant sur « Exporter », en faisant une recherche par fournisseur puis en décochant « Bouquet courant », on obtient la liste complète des titres de revues disponibles sur CAIRN. Un clic sur la flèche rose permet de télécharger le fichier.
Dans le cas des revues à barrière mobile (les dernières années sont payantes, les années antérieures deviennent progressivement gratuites au bout de 2, 4, 5 ans voire plus) les master lists BACON proposent deux lignes par revue : une ligne décrivant la partie gratuite, une autre la partie sur abonnement. Le champ « embargo_info » permet de décrire la durée au bout de laquelle la revue devient gratuite.
Après avoir ouvert le fichier (en vérifiant bien que le séparateur compris est la tabulation et que l’encodage est l’UTF8) nous allons donc supprimer les doublons. Nous allons utiliser OpenRefine pour lancer cette opération. Le chargement du fichier s’effectue en cliquant sur « parcourir » et en sélectionnant le fichier CAIRN qui nous intéresse.  Après un clic sur « next », OpenRefine propose quelques options d’import. Il faut bien vérifier que l’encodage est UTF8, puis on peut cliquer sur « create project ». On arrive alors sur l’interface de travail d’OpenRefine, nous présentant une vue de nos données de manière tabulaire.
Nous allons utiliser la fonction « Blank down », qui permet de supprimer la valeur d’une cellule si la valeur de la cellule précédente est identique. Les fichiers KBART étant classés dans l’ordre alphabétique du titre, on sait que ce cas de figure se présentera pour le fichier CAIRN.
En cliquant sur la flèche à gauche de l’en-tête de colonne « publication_title », le menu déroulant propose de sélectionner « Edit cells » puis « Blank down ». Un clic et toutes les cellules en doublons disparaissent.
Pour supprimer les lignes correspondantes, il faut faire une facette permettant de faire remonter les cellules vides. Pour ce faire, il faut cliquer sur la même flèche à gauche de « publication_title », puis cliquer sur « Facet », puis sur « Customized facets » et enfin sur « Facet by blank ».

Dans le panneau de gauche apparaît alors les facets. « False » signifie que la cellule n’est pas vide, « True » qu’elle l’est bien. On va donc cliquer sur « True », ce qui a pour conséquence de n’afficher que les lignes qui ont un « publication_title » vide. Il faut enfin cliquer sur la flèche à gauche de « All », aller sur « Edit rows » et enfin sur « Remove all matching rows ».
Tout disparaît alors de votre vue tabulaire, mais pas de panique : en supprimant la facette (petite croix à gauche du titre de la facette) apparaissent toutes les lignes, sans aucun doublon.
On a besoin ensuite d’être sûr d’avoir une colonne avec un identifiant à chaque ligne. Ce n’est pas le cas ici puisque certaines revues n’ont pas d’ISSN papier, uniquement un ISSN électronique. On va donc créer une colonne qui donnera tout le temps l’ISSN papier et qui mettra un eISSN s’il n’y a pas d’autre identifiant.
La procédure est la suivante :

  • Cliquez sur la flèche à gauche de l’étiquette de colonne « print_identifier »
  • Sélectionnez « Edit Column »> « Add column based on this column… »
  • Attribuez un nom à la nouvelle colonne (par exemple « ISSN ») dans le champ « New column name »
  • Entrez dans le champ « Expression » le code suivant :
    • if(isBlank(value),cells['online_identifier'].value,value)
    • Ce code regarde si le champ « print_identifier » est vide ; si c’est le cas, il ajoute la valeur du champ « online_identifier » ; si ce n’est pas le cas, il conserve la valeur d’origine

Lancer et traiter la requête BACON

Nous disposons d’une liste d’ISSN sur laquelle nous allons pouvoir utiliser le webservice id2kbart. Ce webservice permet de connaître l’ensemble des packages où figure un périodique donné en fonction de son ISSN (version « papier » ou version électronique) et remonte l’ensemble des informations KBART correspondantes. Le webservice n’interroge que la version la plus à jour de chaque package.
L’étape suivante va consister à lancer le webservice sur toutes les lignes. Rien de plus simple :

  • Cliquez sur la flèche à gauche de l’étiquette de colonne « issn ».
  • Sélectionnez « Edit Column »> « Add column by fetching URL… »
  • Attribuez un nom à la nouvelle colonne (“BACONjson” par exemple) ») dans le champ « New column name »
  • Mettez le « Throttle delay » à 5 millisecondes
  • Entrez dans le champ « Expression » le code suivant :
    • "https://bacon.abes.fr/id2kbart/"+value+".json"
    • Ce code va prendre la valeur de la cellule id et va lui concaténer par un + les informations permettant de construire l’URL d’interrogation du webservice
  • Allez prendre un café. Ça va être LONG.

Le json récupéré ressemble à ceci : https://bacon.abes.fr/id2kbart/1293-6146.json
Tout cela est très verbeux car toutes les informations contenues dans la ligne KBART sont remontées, et cela autant de fois qu’il y a de bouquets dans lesquels se trouve le titre. La prochaine opération consiste donc à parcourir le json pour ne sélectionner que les informations qui nous intéressent.
La réponse est typiquement un objet JSON « bacon » dont le contenu est compris entre accolades et à l’intérieur duquel se trouve un tableau « query » qui contient lui-même, entre crochets carrés, un objet « id » (ISSN) et autant d’objet « provider » qu’il y a de bouquets où se trouve la revue dont l’ISSN est interrogé.
Le problème est que le code json est structuré de manière différente en fonction du nombre d’éléments correspondant à la requête.
Par exemple, s’il y a une seule ligne KBART correspondant à un identifiant dans un paquet donné, « kbart » est un objet json contenant un objet « element » décrit par des paires clés-valeurs (par exemple « publication_title »: « Mille huit cent quatre-vingt-quinze ») séparées entre elles par des virgules et encadrées par des accolades, comme le montre l’exemple ci-dessous :


"provider": {
"name": "CAIRN",
"package": "CAIRN_COUPERIN_REVUES-HUMANITES_2016-09-15",
"kbart": {
"element": {
"publication_title": "Mille huit cent quatre-vingt-quinze",
"print_identifier": "0769-0959",
"online_identifier": "1960-6176",
[…]
"access_type": "P"
}

En revanche, s’il y a deux lignes correspondant au même identifiant, comme c’est le cas dans les master lists, « kbart » devient un tableau contenant deux objets « elements », comme ci-dessous :

"provider": {
"name": "CAIRN",
"package": "CAIRN_GLOBAL_ALLJOURNALS_2016-11-15",
"kbart": [{
"element": {
"publication_title": "Mille huit cent quatre-vingt-quinze",
"print_identifier": "0769-0959",
"online_identifier": "1960-6176",
[…]
"access_type": "F"
}
}, {
"element": {
"publication_title": "Mille huit cent quatre-vingt-quinze",
"print_identifier": "0769-0959",
"online_identifier": "1960-6176",
[…]
"access_type": "P"
}
}]
}
}

On pourrait faire un seul script parcourant le json qui prendrait en compte tous les cas de figure (si « kbart » est un tableau tu fais ça, si « kbart » est un objet tu fais autre chose) mais on peut également faire les choses en plusieurs fois et combiner les résultats, comme le permet Openrefine.
On souhaite avoir par bouquet une réponse sous cette forme, et séparer chaque bloc par un point-virgule :
« Name » : « date_first_issue_online »-« date_last_issue_online »:« embargo_info»-« access_type»
Soit par exemple « OPENEDITION:2000-2012:P36M-P ; »
On va donc d’abord créer une colonne à partir de la colonne BACONjson (flèche descendante à gauche du nom puis « Edit column » et « Add column based on this column »), appeler cette colonne « parse1 » et appliquer le script suivant :

join(forEach(value.parseJson().bacon.query,v,v.provider.name+':'+v.provider.kbart.element.date_first_issue_online+ '-'+v.provider.kbart.element.date_last_issue_online+':'+v.provider.kbart.element.embargo_info+'-'+v.provider.kbart.element.access_type),";")

Décortiquons un peu :
« Value » est la variable comprenant l’ensemble de la cellule qui nous intéresse. On dit donc au script de parser cette variable écrite en json (value.parseJson()) en remontant le contenu de l’objet query inclus dans l’objet bacon. Comme query est un tableau contenant plusieurs objets on doit faire un « forEach » permettant de le parcourir. On crée ensuite une variable (ici appellée « v », mais on peut l’appeler comme on veut) qui prendra la valeur attachée à la clef « name » contenue dans l’objet « provider », concatène avec « : », ajoute la valeur attachée à la clef « date_first_issue_online » contenue dans l’objet « element » lui-même contenu dans l’objet « kbart » à son tour contenu dans l’objet provider. Le reste du code est à l’avenant. On obtient donc lors du premier passage de l’itération une réponse sous forme de tableau ressemblant à ça :

[OPENEDITION:2000-2012:P36M-P]

Un « forEach » renverra autant de tableaux que de réponses potentielles. Pour les manipuler, la forme tableau n’est pas adaptée. Il faut donc les transformer en chaîne de caractères. C’est là qu’intervient la première instruction « join », qui va concaténer les différents éléments du tableau au moyen d’un point-virgule, comme on le lui indique par le dernier argument du script.
La réponse visible dans Refine ressembera donc à ça :

Object does not have any field, including provider;CAIRN:2003-null:null-P;Object does not have any field, including element;CAIRN:2003-null:null-P;CAIRN:2003-null:null-P;CAIRN:2003-null:null-P;EBSCO:2007-2015:null-P

A chaque fois que le script tombe sur une expression qu’il ne peut parser il l’indique. La réponse commencera systématiquement par « Object does not have any field, including provider » dans la mesure où le script tombe d’abord sur un objet contenant la paire clef/valeur « id » avant de tomber sur l’objet valeur qui nous intéresse. On s’occupera plus tard de supprimer toutes les mentions inutiles.
On peut ensuite toujours s’appuyer sur la colonne « BACON_json » pour créer les colonnes « parse2 » et « parse3 » afin de pouvoir traiter les cas décrits ci-dessus où le json n’a pas exactement la même tête. On aura donc les scripts suivants :

join(forEach(value.parseJson().bacon.query,v,v.provider.name+':'+v.provider.kbart[0].element.date_first_issue_online+'-'+v.provider.kbart[0].element.date_last_issue_online+':'+v.provider.kbart[0].element.embargo_info+'-'+v.provider.kbart[0].element.access_type),";")

Ici « kbart » est un tableau dont on ne récupère que les valeurs contenues dans la première série d’objet (d’où le [0] puisqu’en json on commence à compter à partir de 0). On sait en effet que c’est dans cette première série que l’on aura les informations concernant l’accès gratuit à la revue, et c’est ça qui nous intéresse.

value.parseJson().bacon.query.provider.name+':'+value.parseJson().bacon.query.provider.kbart.element.date_first_issue_online+'-'+value.parseJson().bacon.query.provider.kbart.element.date_last_issue_online+':'+value.parseJson().bacon.query.provider.kbart.element.embargo_info+'-'+value.parseJson().bacon.query.provider.kbart.element.access_type

Ici il n’y a qu’une valeur possible (il s’agit de revue en OA qui ne sont présentes dans aucun bouquet), donc pas de tableau à parcourir.
L’étape suivante consiste à concaténer ligne à ligne l’ensemble des valeurs parse1, parse2 et parse3 afin d’opérer ensuite toute une série de traitement.
On va donc créer une colonne à partir de parse3, l’appeler parsefinal et appliquer le script suivant :

forNonBlank(value,v,v,cells['parse1'].value+','+cells['parse2'].value)

Le script regarde si la valeur de « parse3 » existe. Si c’est le cas, il l’associe à la variable v (le premier « v » de l’expression), puis l’affiche (le deuxième « v » de l’expression). Sinon, il affiche le quatrième argument, soit les valeurs concaténées par une virgule de « parse1 » et « parse2 ».
On a donc quelque chose comme ça :

Object does not have any field, including element;CAIRN:2008-null:P5Y-F,Object does not have any field, including provider;CAIRN:2008-null:null-P;CAIRN:2008-null:null-P

Avant de passer aux choses sérieuses, on va enfin nettoyer un petit peu les résultats afin notamment de pouvoir faciliter les calculs que nous allons faire sur les couvertures chronologiques.
Je passe rapidement sur la suppression des embargos relatifs aux revues OpenEdition. Ces embargos sont faux et n’ont pas encore été corrigés par l’éditeur à l’heure où j’écris ce texte. Il faut donc les supprimer pour éviter toute incohérence.
Nous allons tout d’abord remplacer les mentions « F » et « P » par « gratuit » et « payant ». Un simple script comme ci-dessous fait l’affaire. Pour l’appliquer, il faut aller sur la colonne « parsefinal » puis « Edit cells » et « transform » :

value.replace('-F','-gratuit')

Dans un fichier KBART, une revue dont le dernier fascicule est accessible n’a pas de date de fin explicitement indiqué. Nous allons remédier à cela grâce à l’expression suivante :

value.replace('-null','-2017')

Nous allons enfin transformer la mention d’embargo en un simple chiffre. En effet, les revues gratuites avec barrière mobile n’ont normalement pas de date de fin dans les fichiers KBART. Pour connaître la date effective du dernier fascicule librement accessible, il faut soustraire le nombre d’années d’embargo à la date de l’année en cours. Pour transformer une expression du type P2Y, P4Y ou P10Y nous allons utiliser des expressions régulières au sein du script ci-dessous :

value.replace(/(P)(\d+)(Y)/,'$2')

Les expressions régulières permettent de repérer un motif et d’opérer des traitements sur celui-ci. Dans openrefine, les expressions régulières sont encadrées de //. Ici l’expression est assez facile à comprendre : on recherche une chaîne qui contient d’abord un P, puis un ou plusieurs chiffres (\d est un raccourci qui désigne n’importe quel chiffre, + indique qu’il y en a au moins un), puis un Y. Le script remplace ensuite toute l’expression par le 2e élément (eh oui, en expressions régulières on compte à partir de 1…), à savoir le chiffre.
Toujours dans cette idée,  nous allons convertir les embargos exprimés en mois en embargos exprimés en années. Bien évidemment, on perd en précision ce que l’on gagne en facilité de manipulation. On utilise alors une expression du type :

value.replace('P24M', 'P2Y')

Normalement, dans notre expression, ‘null’ ne désigne maintenant que des titres qui n’ont pas d’embargo. Nous allons donc transformer cette chaîne en chiffre :

value.replace('null', '0')

Maintenant, notre expression ressemble à ça :

Object does not have any field, including element;CAIRN:2008-2017:5-gratuit,Object does not have any field, including provider;CAIRN:2008-2017:0-payant;CAIRN:2008-2017:0-payant

Préparer la visualisation

Nous avons tous les éléments pour la transformer assez facilement en :

[ 'payant', 'CAIRN', new Date(2008, 0, 0), new Date(2017, 11, 30) ], [ gratuit, 'CAIRN', new Date(2008, 0, 0), new Date(2012, 11, 30) ]

Jusqu’à présent, nous avons utilisé un langage de script propre à Openrefine qui s’appelle GREL. Ce langage est très facile d’usage et efficace pour les manipulations simples. Dans notre cas, nous avons besoin de quelque chose d’un peu plus poussé, notamment pour la manipulation des expressions régulières. Nous allons donc utiliser le langage jython, proche du python, qui est l’un des langages nativement intégré à Openrefine. Le script en question étant assez long, les commentaires se font au fur et à mesure. Ces commentaires sont intégrés au code et se manifestent par un # en tête de chaque ligne de commentaire.


import re
#on importe la bibliothèque re, qui comporte les fonctions dont on a besoin
p = re.compile(ur'([A-Z]+:[0-9]{4}-[0-9]{4}:[0-9]{1,2}-[a-z]{6,7})')
#ici, on crée une variable avec le motif de ce que l'on cherche codé comme une "expression régulière"
#[A-Z]+: signifie "trouve moi toutes les chaînes qui ont une ou plusieurs (+) lettres en majuscules([A-Z]) puis deux points (:) par exemple "CAIRN:"
# [0-9]{4}-[0-9]{4}: signifie "trouve moi toutes les chaînes ayant 4({4}) chiffres([0-9]), un tiret(-), et 4 chiffres puis deux points (:) par exemple "2008-2017:"
#[0-9]{1,2}- signifie "trouve moi toutes les chaînes sur 1 à 2 ({1,2}) chiffres ([0-9]) puis un tiret (-) par exemple 5-
#[a-z]{6,7} signifie "trouve moi une chaîne de 6 à 7 ({6,7}) lettres en minuscule [a-z] par exemple "payant" (l'autre valeur étant "gratuit").
#L'expression régulière permet donc de ne prendre en considération que les chaînes qui ressemblent à CAIRN:2008-2017:0-payant ou CAIRN:2008-2017:5-gratuit
reg=re.findall(p, value)
#Recherche toutes les chaînes qui correspondent à l'expression régulière dans "value" qui correspond à tout ce que contient la cellule traitée. Le résultat est une liste. Dans notre exemple ['CAIRN:2008-2017:5-gratuit','CAIRN:2008-2017:0-payant','CAIRN:2008-2017:0-payant']
liste_ec=sorted(list(set(reg)))
#On transforme une première fois la liste en set afin de supprimer les doublons (set(reg)), puis on en refait une liste (list(set(reg)) que l'on trie (sorted) et on attribue le tout à la variable liste_ec. Il est indispensable de disposer d'une liste afin de pouvoir isoler et traiter individuellement chaque élément de la liste, ce qui ne serait pas possible avec une chaîne de caractères simple. Le résultat est donc ['CAIRN:2008-2017:5-gratuit','CAIRN:2008-2017:0-payant']
for i in range(0, len(liste_ec)):
#on parcourt ensuite tous les éléments de la liste en partant du premier élément de la liste (0), jusqu'à son dernier qui a un numéro d'ordre qui correspond à la longueur de la liste (len(liste_ec)). On va récupérer un par un chaque élément qui nous intéresse (éditeur, état de collection, nombre d'années d'embargo, mode d'accès).
    regxnom = re.compile(ur'([A-Z]+):[0-9]{4}-[0-9]{4}:[0-9]{1,2}-[a-z]{6,7}')
#on reprend la même expression régulière que ci-dessus, mais avec une grosse différence : on entoure de parenthèses l'expression que l'on veut faire remonter, ici le nom de l'éditeur.
    nom=re.findall(regxnom,liste_ec[i])
#Recherche tous les résultats correspondant à l'expression régulière à l'endroit de la liste où l'on se trouve (liste_ec[i])
    stringnom=":".join(nom)
#Il ne peut y avoir qu'un seul éditeur par expression, on n'a donc normalement pas besoin de concaténer plusieurs valeurs (ce que fait le ":".join qui concatène en séparant par deux points). Mais le résultat d'un re.findall est une liste, et j'ai besoin d'une simple chaîne de caractère (string). C'est une manière d'y arriver. Il y a sans doute des manières plus élégantes.
    regxdatedeb = re.compile(ur'[A-Z]+:([0-9]{4})-[0-9]{4}:[0-9]{1,2}-[a-z]{6,7}')
#mêmes opérations pour la date de début
    datedeb=re.findall(regxdatedeb,liste_ec[i])
    stringdatedeb=":".join(datedeb)
    regxdatefin = re.compile(ur'[A-Z]+:[0-9]{4}-([0-9]{4}):[0-9]{1,2}-[a-z]{6,7}')
#mêmes opérations pour la date de fin
    datefin=re.findall(regxdatefin,liste_ec[i])
    stringdatefin=":".join(datefin)
    regxprix = re.compile(ur'[A-Z]+:[0-9]{4}-.{4}:[0-9]{1,2}-([a-z]{6,7})')
#mêmes opérations pour gratuit/payant
    prix=re.findall(regxprix,liste_ec[i])
    stringprix=":".join(prix)

    regxemb = re.compile(ur'[A-Z]+:[0-9]{4}-.{4}:([0-9]{1,2})-[a-z]{6,7}')
#mêmes opérations pour le nombre d'années d'embargo
    emb=re.findall(regxemb,liste_ec[i])
    stringemb=":".join(emb)
    liste_ec[i]='[\''+stringprix+'\',\''+stringnom+'\', new Date ('+stringdatedeb+',0,0), new Date ('+str(int(stringdatefin)-int(stringemb))+',11,30)]'
#on concatène tous les éléments afin que cela ressemble à l'expression que l'on veut écrire. On raffine en calculant la date de fin en fonction de l'embargo (qui est à 0 pour les titres payants) en transformant en nombre entier la date de fin ((int(stringdatedefin)) et le nombre d'années d'embargo, en soustrayant le deuxième au premier et en reconvertissant le tout en chaîne de caractère (str).
# On arrive à ça, sous la forme d'une liste : ['['payant','CAIRN', new Date (2008,0,0), new Date (2017,11,30)]','['gratuit','CAIRN', new Date (2008,0,0), new Date #(2012,11,30)]']
liste_script=','.join(liste_ec)
#Afin de pouvoir utiliser ces informations, on a besoin de les retransformer en chaîne de caractères. Dans le modèle de script pour obtenir une frise chronologique, on voit que chaque élément doit être séparé par une virgule, d'où le ','.join.
return liste_script
#La fonction return permet l'affichage, on obtient donc la chaîne ['payant','CAIRN', new Date (2008,0,0), new Date #(2016,11,30)],['gratuit','CAIRN', new Date (2008,0,0), new Date (2011,11,30)]

L’avant dernière étape consiste à habiller les expressions que l’on a générées avec le reste du script présenté en début de billet qui s’occupe de l’affichage de la frise chronologique en tant que tel. On va donc transformer notre cellule avec l’expression suivante (à nouveau en GREL) :

cells['publication_title'].value+' - '+cells['publisher_name'].value+ '<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script> <div id="' +cells['issn'].value+ '" style="height: 280px ; width:100%"></div> <script type="text/javascript"> google.charts.load("current", { "packages": ["timeline"] }); google.charts.setOnLoadCallback(drawChart); function drawChart() { var container = document.getElementById("' +cells['issn'].value+ '"); var chart = new google.visualization.Timeline(container); var dataTable = new google.visualization.DataTable(); dataTable.addColumn({ type: "string", id: "prix" }); dataTable.addColumn({ type: "string", id: "titre" }); dataTable.addColumn({ type: "date", id: "Start" }); dataTable.addColumn({ type: "date", id: "End" }); dataTable.addRows([' +value+ ']); chart.draw(dataTable); } </script>'

Il ne nous reste plus qu’à exporter le résultat. On peut au préalable faire un tri par exemple sur la colonne publisher_name afin de regrouper par éditeur (flèche à gauche de publisher_name puis clic sur Sort, puis encore clic sur Sort qui apparaît juste au-dessus des en-têtes de colonnes et clic sur « Reorder rows permanently).
Pour exporter le résultat en une page html, il convient de cliquer sur Export puis « Custom tabular exporter ». Nous n’allons sélectionner que la colonne qui nous intéresse (de-select all puis clic sur la colonne qui a la version finale du script), décocher la case « output colum headers », puis dans l’onglet « Download » sélectionner « html table » dans « other formats », et enfin cliquer sur « Download ».
Le résultat est visible dans n’importe quel navigateur. Le fichier html de résultats peut être téléchargé ici . Il faut l’enregistrer sur son poste avant de l’ouvrir avec un navigateur.

Quelques remarques conclusives

  • Ce code est générique, il peut être utilisé avec n’importe quelle liste d’ISSN en entrée (si on ne dispose pas des noms des éditeurs il suffit d’adapter la dernière étape du code)
  • Il n’est pas du tout optimisé : il faut 1-2 minutes pour que tout s’affiche, dans le cas de notre exemple. N’hésitez pas à apporter des améliorations !
  • La visualisation permet rapidement de se rendre compte de certaines incohérences dans les données : il y en a, elles sont corrigées au fur et à mesure.

B.Bober

Autorités vs référentiels : 3 questions aux experts de l’Abes

arabesques85Autorités, identifiants, entités : L’expansion des référentiels. Tel est le titre du dossier de la revue Arabesques n°85 consacré aux référentiels d’autorités.

Le volume et la diversité des métadonnées en circulation dans les systèmes d’information – de l’enseignement supérieur, de la recherche, de la culture-  exigent de repenser le rôle des référentiels d’autorité. Considérés comme données de confiance au service du développement de l’open data et du web sémantique, ils constituent un capital précieux, une garantie d’indépendance, tout en interrogeant en profondeur les pratiques catalographiques classiques.

Le comité de rédaction  a souhaité apporter un éclairage terminologique en posant 3 questions aux experts de l’Abes en ce domaine : François Mistral, responsable IdRef, Yann Nicolas, expert Métadonnées, Philippe Le Pape, mission Normalisation, Olivier Rousseaux, chef du service Métadonnées. Voici  leurs réponses in extenso.

1 – En tant que professionnel de la documentation, quelles distinctions faites-vous entre « référentiel » et « base d’autorités » ?

François Mistral : Afin d’éviter toute confusion par omission, ajoutons un troisième terme dans ce jeu des distinctions : celui de « nomenclature ». En catalogage, ce seront les données codées – comme par exemple les codes de pays, nomenclature internationale maintenue officiellement par l’ISO 3166 Maintenance Agency (ISO 3166/MA).

Par « référentiel », je retiens surtout l’idée de données de référence et de repère. Cela signifie qu’un référentiel est un jeu de données,  suffisamment vraies, justes, certaines pour être utilisées en confiance afin d’en produire ou d’en agréger d’autres. De fait, ces données de référence sont des points de repère à partir desquelles en situer d’autres avec économie.

Par  « données d’autorité », je retiens la double dimension de contrôle et de légitimité à assurer ce contrôle : ces données font autorité en ce qu’elles contrôlent des données bibliographiques, ce qui met en évidence la nécessaire qualité des données d’autorité, la pratique des sources constituant une de leur plus-value essentielle.

Cependant, outre les différences entre ces termes, je voudrais mettre en évidence l’horizon de leur convergence.  Que les bibliothécaires se persuadent qu’eux-mêmes et les données qu’ils produisent ont la légitimité de coloniser de nouveaux espaces de l’information au profit d’un intérêt tant professionnel que général.

Yann Nicolas :  Selon moi, quand on parle référentiel à l’Abes, on entend « des données qui permettent de décrire nos documents en minimisant le recours à du texte libre », de type listes fermées de « termes » (ex : code pays…) ou listes d’entités (ex :  entité de type Pays)

Décrire les entités de type « Document » étant notre cœur de métier, les entités qui gravitent autour sont considérées comme des entités secondaires « pour nous », comme des moyens et non des fins. Ce qui est tout relatif : un système de gestion des chercheurs français prendra nos documents pour entités secondaires, le Sudoc ou theses.fr devenant un référentiel « pour eux ». Bref, les référentiels des uns peuvent être les données centrales des autres. Ce qui ne veut pas dire que tout peut devenir référentiel.

La tendance actuelle est de transformer les référentiels « liste de termes ou de codes » en référentiels d’entités clairement identifiées : autrement dit, en langage Web sémantique, on passe de « littéraux » (chaînes de caractères simples, ou bien typées) à des « ressources », possédant une URI pour identifiant,  ces ressources pouvant elles-mêmes avoir des attributs, être décrites, succinctement ou longuement, ici ou ailleurs. Connecter nos données à ces référentiels, c’est indirectement enrichir nos données des attributs de ces entités secondaires, et, par transitivité, de proche en proche, à beaucoup d’autres informations.

Traditionnellement, une notice d’autorité remplit ces deux fonctions : identifier clairement une entité grâce à un identifiant précis ; mais également associer à cette entité un nom, un libellé, une étiquette linguistique, un « littéral », un nom propre à retenir comme son nom de référence. En effet, les autorités, de plus en plus ouvertes, vivent dans différents contextes (langues, cultures, types d’application, etc.) et le « bon » terme à afficher peut ne pas être toujours le même. De ce fait, la fonction « terme retenu » est de moins en moins centrale … même s’il faut bien de la chair attachée au squelette de l’entité : des attributs, et parmi eux, des libellés, multiples, qualifiés.

Bref, nos autorités traditionnelles se normalisent : rejoignent d’autres référentiels en tant que liste d’entités clairement identifiées, possédant des attributs et des relations (qualifiées) avec d’autres d’entités (de même type ou non, de même référentiel ou non). Cette normalisation est à la fois intellectuelle et technique. Le paradigme « web sémantique » constitue le vecteur principal de cette normalisation : tout devient Ressource, identifiée de manière univoque à l’échelle universelle grâce à sa (ou ses !) URIs, et ce sont les triplets RDF qui en parlent le mieux…

Philippe Le Pape : Les deux termes s’appliquent à des jeux de données « de référence », statut consacré soit par une labellisation (ex : norme ISO 3166 Codes des noms de pays ; norme ISO 80000-3 Système international de grandeurs, espace et temps ; standard RDA ; standard Unimarc) soit par l’usage (ex : données de theses.fr, de la Bibliographie nationale française). Il s’agit selon moi avant tout d’une distinction d’ordre technique, opérante dans le cadre d’un système de production et d’administration d’un ensemble de métadonnées complexes et organisées.

On nommera « référentiel », l’ensemble de données « outils » auquel on recourt pour garantir la qualité des métadonnées administrées, leur interopérabilité et leur conformité à un standard partagé. Dans cette catégorie entrent les modèles de données, les règles de catalogage, les formats, les nomenclatures (noms et codes de pays, de langue, unités de mesure, coordonnées géographiques..).

Dans un système bibliographique classique, fondé sur le modèle du fichier de notices descriptives dont certains  points d’accès sont contrôlés, les données d’autorité servent à normaliser, unifier et documenter certains de ces points d’accès.  Les données d’autorité ont donc vocation à faire référence pour des tiers, ce qui revient à dire que, dans le cadre d’un système de production de métadonnées, on utilise des référentiels pour produire des données d’autorité.

On remarque que les modèles conceptuels FRBR, FRAD et FRSAD – qui ont ouvert la voie à une conception nouvelle des systèmes bibliographiques, utilisent encore cette terminologie. En revanche, pour le modèle LRM, l’ancienne distinction entre données bibliographiques et  données d’autorité n’existe plus : le modèle ne reconnaît que des entités fonctionnelles en relation les unes avec les autres.

Olivier Rousseaux : « Référentiel : Ensemble auquel doivent appartenir les éléments, les solutions d’un problème posé » (dictionnaire Larousse).

Dans le contexte de l’Abes, les fichiers d’autorités, de même que les listes de données codées, servent à contrôler la cohérence des métadonnées bibliographiques. Ils participent à un ensemble plus vaste qui organise et contraint les métadonnées produites et qui comprend les modèles de données, les formats de saisie, les règles normatives de description, le tout s’inscrivant dans un cadre international – Principes internationaux de catalogage, modèle IFLA LRM (successeur des modèles conceptuels FRBR, FRAD et FRSAD) ou code de catalogage RDA. Des éléments de référence qui s’ajoutent comme autant de « briques », indispensables pour rendre des services tels que le partage de données entre applications, la fourniture à des tiers ou l’exposition.

J’appliquerais donc plutôt le terme de référentiel à cet ensemble qui fonctionne comme un tout avec des règles d’interdépendance et d’interopérabilité de ses constituants. Il permet tout à la fois la cohérence des métadonnées produites, la communication entres les applications documentaires de l’Abes mais également les services de fourniture et d’exposition associés à ces métadonnées.

2 – Ces dernières années, on assiste à la montée en puissance du rôle des référentiels. Comment cela impacte-t-il concrètement votre travail auprès des réseaux de l’Abes / les pratiques de catalogage des professionnels des réseaux ?

François Mistral : En tant que responsable IdRef depuis mon arrivée à l’Abes en 2014, mon activité consiste à encourager cette montée en puissance et à accompagner les professionnels des réseaux en ayant une démarche systémique reposant sur 3 piliers :

  • l’animation du réseau des catalogueurs et notamment des Correspondants autorité, interlocuteurs experts ;
  • l’amélioration de l’outillage professionnel visant à accroître la maîtrise de la production par les producteurs ;
  •  la dissémination multi-canaux et multi-formats des données d’autorité dans et « hors les murs ».

Il reste  encore beaucoup à faire pour informer sur le rôle des référentiels et convaincre des considérables bénéfices attendus et plus encore constatés de leur utilisation dans les Systèmes d’Information, documentaires, de recherche ou autres. Valoriser les données produites par nos réseaux depuis plus de vingt ans et de convaincre de leur capacité à rendre service, sont une source de motivation quotidienne. Nous avons pu étoffer l’offre de service d’IdRef – notamment en matière d’alignements –  afin de la rendre plus attractive. Cette offre est un levier pour démarcher des nouveaux partenaires et intégrer des nouveaux projets, dans lesquels l’un de nos apports spécifiquement «ABES» consiste à promouvoir l’idée centrale et précieuse de « mutualisation ».

Yann Nicolas : Je ne pense qu’à ça !  Ces dernières années, certains collègues et moi avons travaillé sur deux projets : Qualinca et le Hub de métadonnées.
Qualinca est un projet de recherche ANR qui vient de se terminer. L’idée était de produire des algorithmes qui auscultent et améliorent la qualité des liens entre notices bibliographiques et notices d’autorité. Entre Sudoc et IdRef, par exemple. Mais il faut penser plus générique, moins nombriliste : au-delà des données bibliographiques Sudoc et au-delà des autorités IdRef.

Côté hub de métadonnées, on récupère des données hétérogènes en provenance des éditeurs. Notre boulot est d’homogénéiser tout ça, mais aussi de l’enrichir, notamment grâce aux référentiels de toutes sortes : langues, auteurs, sujets, types de document… Il s’agit bien de remplacer (ou compléter) des mots par des identifiants : remplacer un nom d’auteur par un lien vers une URI (IdRef, ISNI, ORCID…) ou remplacer le code « J63 », non pas par le terme « Turnover » du thésaurus JEL (Journal of Economic Literature), mais par un lien vers l’URI de ce concept dans la version Web sémantique de ce thésaurus multilingue – voir : https://punktokomo.abes.fr/2016/05/16/mettre-nos-donnees-en-reseau-un-demonstrateur-4b-les-revues-doxford-up-et-la-classification-jel-economie/
Dans les deux cas, il s’agit de connecter l’information bibliographique à des référentiels, pour mieux la structurer et mieux la connecter, non seulement à l’échelle d’un catalogue, -même collectif ou national, mais à l’échelle du Web !

Philippe Le Pape : On assiste plutôt à une prise de conscience du rôle des référentiels. Dans des systèmes de production partagée de métadonnées tels que le Sudoc, le rôle de la normalisation – qui intègre l’emploi de référentiels – a toujours été crucial. Mais avec la mise en application de RDA, le recours à des vocabulaires contrôlés s’accroît encore – « type de contenu », « type de médiation », « type de support » en sont des exemples.

Olivier Rousseaux : L’Abes est confrontée à ces questions pour avoir posé comme principe, lors de la mise en place même du Sudoc, la réutilisation de référentiels existants : RAMEAU ou FMeSH pour les accès matière, fichiers d’autorités « personnes, collectivités, titres » de la BnF pour les accès auteur ou titre uniforme ; listes de codes ISO (langues, pays) ou Unimarc (codes fonctions pour les auteurs).

Les évolutions les plus importantes : l’accès – foisonnant dans le contexte du web de données – aux métadonnées d’autres référentiels bibliographiques, administratifs ou autres de type  VIAF , base SIRENE de l’INSEE ou Répertoire des structures de recherche au niveau national  (RNSR)  ainsi que les évolutions techniques qui permettent de se projeter dans leur exploitation (solutions d’alignement et/ou d’enrichissement des métadonnées).

A l’Abes, la réflexion porte donc sur les manières d’appréhender les métadonnées de référentiels tiers pour bénéficier de leurs apports potentiels. A minima, il s’agit d’une opportunité d’améliorer, dans nos bases de production, les méthodes de liage automatique  entre notices bibliographiques et autorités de manière à diminuer cette activité pour les catalogueurs. En ce qui concerne le travail de catalogage au quotidien, les perspectives sont également d’exploiter les référentiels afin de développer des outils d’aide à la décision (ex : projet de recherche Qualinca)

3 – Comment envisagez-vous/imaginez-vous le rôle des référentiels dans le paysage de l’IST / au-delà ?

François Mistral : Selon moi, les référentiels actuels laissent entrevoir certaines des évolutions à venir du métier de catalogueur. Les données produites par les bibliothécaires sont promises à un grand avenir, tout l’enjeu étant dans leur structuration. A ce titre, les référentiels vont continuer de croître en importance. En conséquence, le rôle et l’expertise des producteurs de données structurées et structurantes doivent être au centre de nos préoccupations prospectives.

Un point délicat réside dans le fait que « nous autres catalogueurs » devons prendre conscience que nous sommes, aux premières loges, à la fois spectateurs et acteurs de ce phénomène qui dépasse largement notre secteur professionnel. Avec ou malgré nous, les choses se jouent dans notre communauté.

A ce titre, on pourrait imaginer que les référentiels jouent, comme pour les données, un rôle structurant pour l’IST. Ils pourraient amener une reconfiguration plus rationnelle des missions de ses opérateurs, reconfiguration façonnée à leur image : toute entière de spécialisation et de coopération pour un service rendu de haut niveau.

Yann Nicolas  : Vu de l’Abes, en caressant du regard le paysage un peu cacophonique de l’IST en France, j’espère encore une politique publique des référentiels claire. Que chacun joue sa partition, c’est-à dire maintienne et mette à disposition les référentiels qui sont de son ressort. Qu’on évite les doublons où plusieurs font plus ou moins correctement la même chose. Mieux vaudrait qu’un seul le fasse, et de manière excellente ! Par exemple, que le Référentiel national des structures de recherche (RNSR) administré par le MENESR soit, de droit et de fait, reconnu comme LE service public national qui fournit identifiants et attributs de référence pour les laboratoires français. Ce qui n’empêche en rien des clients – comme STAR ou theses.fr – de gérer leurs propres attributs complémentaires, en sus des attributs RNSR, à des fins propres, bibliographiques ou pas. Si possible, gérons nos propres attributs de laboratoires, mais pas nos propres identifiants : accrochons nos attributs aux identifiants RNSR. Même chose pour les autorités de type Entreprise : le référentiel SIRENE de l’INSEE est désormais ouvert !
L’Abes doit être un bon client des référentiels des autres, en même temps qu’un bon fournisseur de référentiels pour les autres, dès lors que son positionnement, son organisation et son capital de données la rendent légitime. C’est le cas, sans conteste, du référentiel des thèses françaises ou celui des chercheurs français.

Philippe Le Pape : On va vers une importance grandissante des identifiants de confiance dans lesquels le « nom », la « forme d’autorité », les données elles-mêmes se trouvent de plus en plus ramassés : le passage des métadonnées bibliographiques de systèmes fermés au Web renforce la nécessité de les normaliser et de les étiqueter en fonction des standards du Web, selon des systèmes d’identification qui pour être efficaces doivent jouir d’une large reconnaissance.

Olivier Rousseaux : Je ne vois pas leur rôle évoluer radicalement dans l’immédiat car leur nature et leurs fonctions perdurent sans être remises en question. J’envisage plutôt une tendance à des rapprochements – entre alignements et fusion- de référentiels existants.
Cependant, pour chaque rapprochement envisagé, les mêmes questions devront être examinées, tout référentiel tiers visé fonctionnant dans un contexte défini et circonscrit qui lui est propre : à quels objectifs répond-il ? à quelles contraintes ? sur quel modèle de données est-il fondé ? quelles en sont les règles d’alimentation ? nos besoins sont-ils couverts par ce référentiel en termes de granularité des données, d’évolutivité et de traçabilité des évolutions apportées ? quels risques et quels avantages y aurait-il à fusionner avec ce référentiel tiers? quelle gouvernance en résultera (technique comme scientifique) et sera-t-elle adaptée à notre contexte ?

Un référentiel tiers est donc à aborder avec prudence afin de mesurer le degré de rapprochement optimal qu’on peut en espérer. De ce point de vue, le projet de « Fichier national des entités » amorcé en mars 2017 entre la BnF et l’Abes répond à ces questions en se positionnant résolument dans la recherche d’une solution de fusion des « traditionnels » fichiers d’autorités existants de part et d’autre au profit d’un fichier national unique géré en co-production.