Univ-Droit et IdRef : une coopération ambitieuse et réciproque

Retours sur une coopération fructueuse entre  l’équipe IdRef de l’Abes et l’équipe d’Univ-Droit dans le cadre de l’UNJF – Université Numérique Juridique Francophone, dont Gilles Dumont, professeur de droit public, est le directeur.

Le portail Univ-Droit

univ-droit_logoUniv-Droit, site dédié au Droit et aux Sciences Politiques, porté par la Conférence des doyens des Facultés de droit, est un outil incontournable pour aborder le champ juridique national. On y trouve des informations sur l’ensemble des formations juridiques universitaires, des structures de recherche et des instances professionnelles ainsi qu’une offre conséquente de ressources pédagogiques (cours en ligne).

Deux annuaires sont également disponibles, qui consacrent une page propre aux entrées de type :

enseignants

structure

Conçus pour la diffusion des informations autant que pour leur bonne gestion interne et relationnelle, ces annuaires s’appuient sur des listes contrôlées et des référentiels, une démarche indispensable pour assurer les liens entre ressources et acteurs. Initiée dès l’origine du portail, cette étape d’identification concerne les données de type  :

  • Structures : la quasi-totalité des entrées s’appuie sur un référentiel national (RNSR pour les laboratoires, UAI pour les structures d’enseignement, Numéro national pour les Ecoles doctorales). Ce travail d’identification a été effectué en coopération avec l’équipe ScanR, et est donc sécurisé.
  • Personnes : certaines pages d’enseignants-chercheurs comportent déjà des renvois vers leur notice d’autorité dans IdRef (exemple : https://univ-droit.fr/universitaires/24364-alain-supiot) sans toutefois que cette identification ne soit exhaustive.

noticeidref

Coopération avec l’Abes

A l’automne dernier, suite à une présentation d’IdRef dans le cadre du groupe de travail “Moteur de recherche” de  SupNumérique, initiative ministérielle destinée à la valorisation des Ressources Pédagogiques Numériques, l’Abes a été sollicitée par l’équipe d’Univ-Droit afin de généraliser l’identification fiable et pérenne des données de type Personnes. En effet, disposer d’identifiants fiables, pérennes et partagés pour l’ensemble des acteurs recensés – personnes physiques ou morales – est une garantie pour l’interopérabilité des données.

Alignement des enseignants-chercheurs

La première opération, similaire à celle détaillée ici, a consisté à identifier automatiquement plus de 90 % des 3 728 enseignants-chercheurs recensés dans Univ-Droit. Et cette fois encore, les alignements produits par l’algorithme se sont révélés très fiables. Enfin, pour les alignements considérés moins sûrs, les données inscrites dans les notices d’autorité sont venues valider les candidats.

Comme à l’accoutumée, cette opération d’alignement a mis en évidence bon nombre d’anomalies dans les données de type Personnes (coquille dans les noms, doublons…), ce qui a donné lieu à autant de corrections, étape importante pour l’amélioration qualitative des données.

Au final, c’est maintenant l’ensemble de la communauté des juristes et politologues français qui dispose désormais d’une identification fiable !

Enrichissements réciproques

Côté IdRef : seront intégrées au sein des notices IdRef, les URL des pages personnes d’Univ-Droit ainsi que des données disciplinaires ou d’affiliation qui en seront extraites pour enrichir et consolider le contenu des autorités. Concrètement, pour ceux qui « parlent Unimarc », le résultat sera l’ajout d’une zone 035 – numéro source dans Univ-Droit, ajout/modification d’une zone 340 – note sur la biographie et les activités.

Côté Univ-Droit : dans les pages Personnes d’Univ-Droit, les renvois vers les notices d’autorité IdRef ont été systématisés. Il en sera probablement de même avec les renvois vers les pages Personnes de theses.fr : https://www.theses.fr/027151808.

Cette démarche double permet à la fois de multiplier les rebonds web et le référencement réciproque, de désambiguïser les personnes d’Univ-droit et de consolider les notices autorités parce qu’elles sont maintenant reliées “physiquement” à Univ-Droit.

Récupération par Univ-Droit des données bibliographiques liées

L’affichage des publications dans les pages d’enseignants-chercheurs va pouvoir évoluer. Pour ce faire, Univ-Droit a l’intention d’exploiter le nouveau web service d’IRef – «References », disponible depuis la V2 d’IdRef (octobre 2017) : pour un identifiant IdRef donné, le webservice renvoie l’ensemble des documents associés dans les différents catalogues ou sources de données bibliographiques connus d’IdRef, à savoir le catalogue Sudoc bien entendu mais aussi theses.fr, Calames, Persée et d’autres.

Jusqu’à présent, dans Univ-Droit, les publications Sudoc proviennent d’une interrogation de HAL – le plus souvent suite à une requête forgée du nom-prénom croisé avec le labo de rattachement – pour aller chercher les rares ISBN dans les résultats de la recherche HAL de type “ouvrage”, qui sont ensuite croisés avec le web service “ISBNtoPPN” pour aboutir, enfin,  à la notice Sudoc.

Prenons l’exemple de Véronique Champeil-Desplats. Cette méthode permet de remonter comme résultats 3 monographies dotées d’un ISBN. En interrogeant le web service « references » d’IdRef avec comme seul paramètre l’identifiant IdRef de Véronique Champeil-Desplats – http://www.idref.fr/services/references/05505563X – on obtient 27 monographies ainsi que son rôle dans chacune. C’est plus simple et plus complet !

L’Abes espère que cette nouvelle exposition des données Sudoc dans Univ-Droit engendrera des retours des enseignants-chercheurs qui constateront que des intrus figurent parmi la liste de leurs ouvrages.

Une nouvelle rubrique pour les thèses

En plus des rubriques déjà présentes, une nouvelle rubrique Thèses va voir le jour puisque le web service “references” utilise theses.fr comme source.
thesesEn conclusion, parce qu’Univ-Droit connaît les identifiants IdRef, l’exposition et la moisson des publications des enseignants-chercheurs en droit et sciences politiques est sécurisée. Parce qu’IdRef connaît Univ-Droit, les notices de ces enseignants-chercheurs sont enrichies et les liens aux données bibliographiques des catalogues sources fiabilisées.

Cette coopération fructueuse entre l’Abes et Univ-Droit démontre, si besoin est, que les chantiers de mise en interopérabilité des données – ici l’identification fiable et pérenne des enseignants-chercheurs – constituent un moteur puissant pour l’amélioration concrète de leur qualité, et conforte l’ambition de construire progressivement un véritable “réseau numérique de confiance” au service  des ressources de l’ESR.

François Mistral, responsable IdRef

 

Publicités

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