Utiliser un webservice de l’ABES sans être développeur : vers l’infini et au-delà

punktokomo_these_5logo_-abes1.pngSuite aux Journées ABES 2018 et  au tutoriel de Sylvain Machefert (Bibliothèques de l’Université Bordeaux Montaigne) sur l’utilisation des WebServices de l’Abes (NNT2PPN, PPN.xml, etc.) via OpenRefine, le service des Thèses de l’Abes s’est dit que, oui, vraiment, mettre en regard le nombre de thèses de doctorat publiées en version commerciale et le périmètre de diffusion en ligne choisi par les docteurs était une bonne idée !

Nous avons donc reproduit le projet de Sylvain Machefert en l’élargissant à l’ensemble des thèses de doctorat soutenues, déposées au format électronique et traitées dans STAR.

Rappelons au préalable quelques éléments :

  • avec l’arrêté du 7 août 2006, le dépôt électronique des thèses de doctorat était laissé au choix des établissements. Depuis l’arrêté du 25 mai 2016, ce dépôt est désormais obligatoire ;
  • sauf confidentialité prononcée par le jury, la diffusion des thèses  est une obligation légale, a minima via l’intranet de l’établissement de soutenance. Les docteurs peuvent choisir de doubler cette diffusion restreinte d’une diffusion en ligne ;
  • les raisons qui poussent un docteur à choisir une diffusion restreinte sont multiples. Parmi elles, figure le souhait de faire publier sa thèse chez un éditeur.

Thèses soutenues VS thèses publiées

L’opération a révélé que,  parmi les 80 000 thèses archivées via STAR depuis 2007, 1403 thèses ont effectivement fait l’objet d’une publication « commerciale ». Comment les avons-nous repérées ?
Les notices originelles de ces thèses disposent, dans les données exposées en RDF (ex : https://www.sudoc.fr/15812989X.rdf ), d’un bloc <dcterms:hasVersion> dédié aux autres éditions de la thèse. Dans les notices en Unimarc, ce bloc se traduit par la présence d’un lien, dans les zones Unimarc 451 ou 452, faisant la jonction entre la notice « mère » originelle, qui décrit la version de soutenance de la thèse, et la notice « fille », qui décrit l’autre édition de la thèse (ici l’édition commerciale).
Ce sont ces informations que nous avons exploitées en suivant la procédure de Sylvain Machefert.

Par ailleurs, depuis la mise en production du webservice Unimarc/MarcXml, il est possible d’extraire via OpenRefine d’autres données intéressantes qui permettent d’affiner l’analyse.

Les disciplines les plus publiées

On peut par exemple déterminer à quelle discipline se rattachent les thèses publiées. [IMPORTANT : le périmètre d’analyse est toujours restreint aux thèses électroniques, les thèses ayant fait l’objet d’un dépôt sous forme imprimée sont exclues].

Partant de l’identifiant PPN de la notice récupéré via le webService NNT2PPN, on ajoute dans OpenRefine une colonne [« add column by fetching URLs »] contenant le résultat de la formule :

 https://www.sudoc.fr/"+value+".xml

Les données implémentées dans la colonne sont en MarcXml, format que l’on parse (le programme analyse la structure des données) pour extraire le code « discipline » contenu dans la zone Unimarc 686 :

value.parseHtml().select("datafield[tag=686]")[0].select ("subfield").toString()

La zone 686 contient le code de classification Dewey des thèses (Dewey simplifiée).

Sur les 1403 thèses recensées comme ayant donné lieu à une publication, 461 (42%) sont des thèses de droit et 120 (11%) des thèses de littérature. On peut en faire de jolis camemberts Excel !

punktokomo_these_1

Thèses à diffusion en ligne restreinte VS thèses publiées

Il est également possible d’analyser les stratégies des docteurs en ce qui concerne le type de diffusion en ligne de leur thèse (accès ouvert ou restreint). Pour ce faire, on exploite la présence d’au moins une zone 856$u dans les notices de thèse provenant de STAR :

value.parseHtml().select("datafield[tag=856]")[0].select ("subfield").toString()

La zone 856$u du .xml contient l’URL de diffusion des thèses électroniques, internet ou intranet (et donc le lien renseigné en E856 en Unimarc). Ces deux types de données (niveau bibliographique pour la 856 ou niveau exemplaire pour la E856) sont distingués dans le .xml par la présence, à la suite du champ considéré, d’un punktokomo_these_6, qui est le $5 du format Unimarc d’export dédié aux données locales.

Les balises permettent d’identifier qu’on a ici affaire à un lien intranet :

<datafield tag="856" ind1="4" ind2=" "> <subfield code="5">690292101:443703647</subfield> <subfield code="q">html</subfield> <subfield code="u">http://theses.univ-lyon2.fr/documents/lyon2/2011/dargere_cj</subfield> </datafield>

Sur nos 1403 notices de thèses publiées, on trouve 483 liens URL dépourvus d’un punktokomo_these_6 ce qui indique une diffusion sur internet : comme quoi Open Access et publication commerciale cohabitent dans 1 cas sur 3 …

punktokomo_these_2

En revanche, la perspective d’une édition commerciale a clairement une incidence sur le choix de diffusion de la thèse originelle. Sur l’ensemble des thèses soutenues traitées dans STAR, on compte 2 thèses diffusées en libre-accès pour 1 thèse diffusée en intranet.
Sur le corpus des thèses publiées, c’est l’inverse.

punktokomo_these_3

Pour conclure

1403 thèses électroniques sur 80 000 ont donné lieu à une publication, dont 42% sont des thèses de droit.
Les docteurs qui souhaitent être publiés chez un éditeur ont davantage tendance à restreindre la diffusion en ligne de leur thèse, ce qui n’empêche pas un tiers d’entre eux de concilier publication commerciale d’une version remaniée de leur thèse et diffusion en libre accès de la version soutenue.

punktokomo_these_4Pour obtenir plus de détails sur la façon dont nous avons procédé, et pouvoir à votre tour déterminer le nombre de thèses soutenues au sein de votre établissement ayant fait l’objet d’une publication, nous vous conseillons de consulter les documents d’accompagnement très utiles que Sylvain Machefert a produit et mis en ligne.

L’équipe Thèses de l’Abes, en collaboration avec Sylvain Machefert.

 

Signaler les thèses déposées sur TEL dans le Sudoc et theses.fr

35 000 thèses TEL proviennent de Star : et les autres ?

logo_telActuellement, 75 000 documents  estampillés « thèses » sont déposés sur TEL. Or, si 35 000 documents  – qui proviennent de l’application Star – sont bien estampillés « version validée par le Jury », 40 000  d’entre eux ne sont signalés ni dans le Sudoc ni sur theses.fr, alors même que le lien vers le texte intégral de la thèse peut avoir un intérêt pour les lecteurs. Suite à ce constat, plusieurs établissements, soucieux d’offrir une visibilité plus importante à ces travaux de recherche, ont sollicité l’Abes en vue de leur signalement automatique. Deux options s’offraient :

  • importer les notices de TEL en s’appuyant sur leurs métadonnées (XML TEI) pour les transformer en Unimarc.
  • décrire ces documents via les notices des thèses originelles déjà présentes dans le Sudoc.

Pour une plus grande simplicité de mise en œuvre et une bonne cohérence des données – notamment des liens aux autorités IdRef « Nom de personnes » et Rameau, il a été décidé de partir du socle constitué par la notice Sudoc décrivant la thèse originelle papier et d’en faire la matrice de la future notice du document TEL.

Recouper les données de TEL avec celles du Sudoc

L’étape dite « de recouvrement » des données de TEL avec celles du Sudoc a été complexe.

Dans un premier temps, les données de TEL ont été récupérées dans OpenRefine via une requête sur l’API-HAL – https://api.archives-ouvertes.fr/docs en demandant en sortie : URI, Date de soutenance, Auteur et Titre français du document.

Puis, via un test de recouvrement (sur Date, Auteur, Titre), les thèses TEL auxquelles correspondent une notice de thèse originelle papier (notice « mère ») dans le Sudoc, ont été identifiées. Dans un cas sur trois, le taux de recouvrement a échoué (soit 0 notices trouvées dans le Sudoc ou plus de 5)

Ensuite, à partir du NNT,  les différentes notices de reproduction (notices « filles ») rattachées à une notice « mère » ont été identifiées dans le Sudoc, ce qui a permis d’exclure les thèses possédant déjà une notice de reproduction et faisant mention, en zone 856, d’une URL (vers TEL ou Pastel) et pour lesquelles le  signalement avait déjà été effectué.

Après un passage par ces différents tamis, il restait environ 22 000 documents TEL disposant d’une notice de thèse originelle dans le Sudoc. Parmi ces 22 000 documents, n’ont pu être conservées que 15 500 thèses dont la notice de thèse originelle « passait l’AlgoSudoc » et apparaissait dans theses.fr [afin d’améliorer le référencement des thèses dans theses.fr, rappelons que les établissements sont invités à corriger les notices WinIBW qui ne « passent pas l’AlgoSudoc »].

Theses_TEL_image1

Theses_TEL_image2

Les thèses de TEL : reproductions exactes ou autres versions des thèses ?

Une fois identifiés les documents potentiellement à signaler dans le Sudoc,  la question de la méthode s’est posée : dans la mesure où les notices de reproduction décrivant les thèses TEL allaient être générées en masse à l’aide de scripts, il fallait en effet rester prudent.

L’Abes n’étant pas en mesure de vérifier la conformité du dépôt TEL avec la thèse originelle archivée par l’établissement de soutenance, il a été décidé de ne pas signaler les documents déposés sur TEL en tant que reproductions exactes, mais en tant qu’« autres versions » des thèses archivées en bibliothèques.

En lieu et place de l’habituelle zone 455/456 (reproduction de/reproduit comme), nous avons donc opté pour une paire de zones 452 (autre édition sur un autre support), ce qui permet de ne pas statuer sur l’identité de contenu entre la version originelle de la thèse et la version déposée sur TEL.

Ce choix a été renforcé par la suppression, dans la notice ainsi créée, du Directeur de thèse, de l’Université de soutenance, des membres du jury et du NNT, de sorte que le traitement de ces documents corresponde à celui réservé habituellement à une « version commerciale » de thèse. Ce traitement catalographique est applicable à toutes les « autres éditions » et « autres versions » d’une thèse, qui ne sont pas des reproductions exactes ou ne peuvent être considérées comme telles en l’absence de vérification.

La note de thèse (zone 328 : Texte remanié de …) a été conservée [on peut, dans WinIBW, interroger l’index nth pour retrouver les thèses par établissement de soutenance]. De son côté, le NNT est déplacé à la fois en zone de note (zone 305 : « Cette édition peut différer de la version de soutenance enregistrée sous le Numéro National de Thèse : 20XXZZZZ0001 ») et en tant qu’identifiant dans un autre système (zone 033) pour pointer sur la page correspondante sur theses.fr.

Theses_TEL_image4

Bilan

Après plusieurs mois de réflexion, le chantier de signalement des thèses de TEL dans le Sudoc lancé le 26 avril 2018 s’est achevé le 4 mai 2018. Il a donné lieu à la création de quelques 15 500 notices Oa liées à une notice de thèse originelle Aa [on peut les retrouver en interrogeant la zone 035 avec la requête « che sou tel? OU pastel? OU hal? »].

a_noter [voir en fin d’article le nombre de notices créées par établissement].

Le lien d’accès au fichier de la thèse s’affiche désormais sur theses.fr de la façon suivante :  Theses_TEL_image3

Par ailleurs, toutes les notices créées se sont vues attribuer un « exemplaire Abes » afin d’apparaître sur le catalogue Sudoc public.

Dans la mesure où il s’agissait d’une première, la prudence a été de mise, aussi bien en ce qui concerne le périmètre choisi que le traitement retenu pour la création de ces notices. Notre objectif a été, avant tout, de permettre l’intégration dans la notice Sudoc d’un lien vers le texte intégral là où on ne disposait que d’une notice de thèse originelle papier.

Si la procédure choisie – notamment le test de recouvrement – mérite encore d’être affinée, l’objectif est  de parvenir au signalement dans le Sudoc de l’ensemble des thèses de doctorat déposées sur TEL. Pour ce faire, le chantier sera relancé l’année prochaine, puis tous les deux ans.

Après l’Abes, c’est au tour des établissements de jouer

Les établissements sont libres de compléter ou corriger les notices créées, notamment afin de remplacer la zone 452 par une zone 456 – après vérification de la conformité du dépôt TEL avec la version de soutenance – et d’appliquer le traitement habituellement réservé aux reproductions de thèses de doctorat.

Ils peuvent également demander à l’Abes une exemplarisation automatique sur un lot de thèses TEL, afin d’enrichir leur catalogue local.

Enfin, ceux qui souhaitent améliorer le signalement de leurs thèses dans le Sudoc afin, d’une part, de permettre leur référencement dans theses.fr, et, d’autre part, d’obtenir une meilleure couverture Sudoc / TEL, sont invités à contacter le service des Thèses qui pourra leur fournir la liste des thèses ayant été écartées du chantier et dont la reprise est nécessaire.

N’hésitez donc pas à nous solliciter via ABESstp en cas de problèmes ou pour avoir plus de détails sur les outils utilisés et la méthode suivie.

Annexe : Nombre de notices créées par établissement (code court)

Etab. Nb de notices créées Etab. Nb de notices créées Etab. Nb de notices créées
AGPT 46 ENST 117 NAN2 8
AGUY 12 ENSU 8 NANT 285
AIX1 192 EPHE 16 NCAL 1
AIX2 80 EPXX 310 NICE 362
AIX3 94 ESAE 29 NSAM 1
AIXM 1 ESMA 56 NSAR 13
AMIE 31 ESTA 6 OBSP 30
ANGE 16 EVRY 19 ORLE 182
ARTO 5 GLOB 18 PA01 283
AVIG 10 GRE1 1616 PA02 3
BESA 169 GRE2 28 PA03 39
BOR1 284 GRE3 22 PA04 33
BOR2 24 GREN 163 PA05 72
BOR3 44 IEPP 17 PA06 1885
BOR4 45 INAL 7 PA07 625
BORD 1 INAP 75 PA08 45
BRES 115 INPG 890 PA09 49
CAEN 380 INPL 22 PA10 97
CERG 13 INPT 33 PA11 901
CHAM 130 ISAL 1 PA12 12
CLF1 6 ISAM 11 PA13 28
CLF2 270 ISAR 72 PAUU 66
CNAM 34 ISAT 48 PERP 30
COMP 54 LARE 2 POIT 110
CORT 16 LARO 49 POLF 1
DENS 20 LEHA 40 REIM 6
DIJO 107 LEMA 6 REN1 466
DUNK 18 LIL1 42 REN2 43
ECAP 70 LIL2 25 ROUE 123
ECDL 22 LIL3 15 STET 33
ECDM 1 LIMO 6 STR1 136
ECDN 52 LORI 46 STR2 8
ECLI 10 LYO1 79 STR3 2
EHEC 36 LYO2 4 STRA 33
EHES 196 LYO3 12 TELB 9
EIAA 11 LYON 1 TELE 3
EMSE 23 LYSE 1 TOU1 13
ENAM 296 MARN 58 TOU2 69
ENCR 1 METZ 30 TOU3 453
ENGR 40 MNHN 37 TOUL 9
ENMP 291 MON1 29 TOUR 62
ENPC 290 MON2 303 USPC 52
ENSA 11 MON3 27 VALE 58
ENSF 5 MULH 13 VERS 71
ENSL 63 NAN1 78

La géolocalisation des autorités géographiques dans le Sudoc – partie 1

Cette série de billets écrite par Elena Avellino présente le travail de géolocalisation de notices d’autorité géographiques dans le Sudoc, réalisé par l’Ecole française de Rome.

  1. Finalités, modalités et applications (ce billet)
  2. Mode d’emploi de la géolocalisation

Pourquoi la géolocalisation ?

Entre 2014 et 2016, en collaboration avec l’Abes, les Écoles françaises à l’étranger (École française d’Athènes, École française de Rome, Casa de Velàzquez à Madrid, Institut français d’archéologie orientale du Caire et École française d’Extrême-Orient) ont conduit le projet « ArchéoRef : signalement de publications archéologiques dans le Sudoc » (voir le poster présenté aux JABES en 2015).
C’est à l’occasion de ce projet qu’ont eu lieu les premières géolocalisations de notices d’autorité géographique dans le Sudoc. À l’EFR, le groupe de travail était composé de Nadia Marconi -archéologue et documentaliste- et moi-même, bibliothécaire et archéologue. Il s’agissait de géolocaliser les notices d’autorité décrivant des sites fouillés par l’Ecole française de Rome.

La géolocalisation vise 3 objectifs :

  • enrichir les notices d’autorités géographiques (Tg),
  • contribuer à la pertinence des recherches bibliographiques dans le Sudoc
  • faciliter l’accès aux ressources liées à un site.

Son intérêt ici est strictement documentaire : en aucun cas; elle n’a la prétention de constituer une base de données proprement topographique ou géographique.

Le travail pour ArchéoRef  a abouti à la mise  au point d’un outil de recherche qui met en relation :

  • une entité géographique
  • l’accès aux données bibliographiques recensées dans le Sudoc qui la concernent
  • sa visualisation sur une carte

Quel est le principe de la géolocalisation dans les notices d’autorité ?

Les coordonnées géographiques saisies dans la notice d’autorité géographique du Sudoc – accompagnée si nécessaire d’un contrôle de la qualité de la notice, de doublons ou encore de la pertinence des liens – sont répercutées immédiatement dans l’interface publique IdRef, qui donne l’accès au positionnement sur une carte géographique et aux notices bibliographiques liées.

Saisie dans WinIBW, l’outil de production du Sudoc :

geolocalisation_notice_winibw

Notice Tg « Pompéi (ville ancienne) » PPN 027243303

Visualisation des données dans l’interface publique IdRef :

geolocalisation_notice_idref

Notice « Pompéi (ville ancienne) » affichée dans IdRef (https://www.idref.fr/027243303)

Accès à la géolocalisation du site archéologique  (bouton « GÉOLOCALISATION » d’IdRef) :

geolocalisation_bouton

Quelles sont les applications, actuelles et à venir  ?

A l’EFR, la géolocalisation dans le Sudoc a été associée à une analyse du référencement bibliographique des sites fouillés par l’établissement et a été utilisée pour enrichir leur présentation dans notre page web. Exemple : Porta Nocera, Pompéi (Italie)  :

Le développement de la géolocalisation des entités géographiques pourrait aboutir à des véritables cartes interactives thématiques qui donneraient accès à la localisation du site, à la notice d’autorité et à sa bibliographie (monographies). L’EFR étudie d’ailleurs, comme suite possible au projet ArchéoRef, le projet d’une carte interactive des monuments de la Rome antique. Contrairement à d’autres projets similaires qui demandent une saisie spécifique des références, la bibliographie de ces cartes thématiques serait alimentée de manière autonome et en temps réel par le catalogage et l’indexation du Sudoc : il s’agirait d’une « bibliographie thématique dynamique ».

Simulation de carte thématique sur les monuments de Rome :

geolocalisation_carte_rome

Géolocalisation de l’Arc de Titus (à gauche) et du Colisée (à droite), visualisation de leur notice d’autorité, puis de leurs bibliographies respectives.

D’autres possibilités sont également envisageables, par analogie à celles qui s’appliquent aux autorités Nom de personne. Par exemple, le renvoi dans les articles de Wikipédia :

geolocalisation_simulation_wikipedia

… ou l’insertion du lien dans d’autres bases de données bibliographiques. À titre d’exemple, pour les Mélanges de l’Ecole française de Rome Antiquité  (Revue.org), on pourrait insérer le renvoi à la notice IdRef dans les index :

geolocalisation_simulation_revue_org

Simulation de l’écran de présentation de la revue, sur revue.org

En conclusion

Les interfaces de consultation peuvent encore être améliorées et adaptées à l’usage. Naturellement, les développements que nous avons évoqués, si jugés utiles et pertinents, demanderaient certainement d’autres aménagements techniques. Il nous semble en revanche intéressant de disposer potentiellement d’un outil qui permettrait de conjuguer une carte interactive d’entités géographiques normalisées et une bibliographie automatiquement mise à jour, qui puiserait ses références dans le riche catalogue collectif du Sudoc.

                     Elena  Avellino
 Bibliothèque de l’École française de Rome
elena.avellino[at]efrome.it
logo_EFR

 

 

 

 

 

La géolocalisation des autorités géographiques dans le Sudoc – partie 2

Cette série de billets écrite par Elena Avellino présente le travail de géolocalisation de notices d’autorité géographiques dans le Sudoc, réalisé par l’École française de Rome.

  1. Finalités, modalités et applications
  2. Mode d’emploi de la géolocalisation (ce billet)

Ce billet expose les modalités de géolocalisation et la transcription de ces données dans l’outil de production du Sudoc, WinIBW.

Étape 1 : définir la référence cartographique

Dans le cadre d’ArchéoRéf, nous avons choisi d’utiliser Google Earth qui permet le relevé des coordonnées sexagésimales et décimales. Les coordonnées obtenues doivent être converties dans le format Unimarc Autorités dans la zone 123. La visualisation sur la carte est réalisée avec Google Map qui ne lit que les coordonnées décimales du champ 123 ($q $r $s $t). Les données sexagésimales ne sont donc pas obligatoires. Par ailleurs, la géolocalisation peut s’effectuer avec d’autres systèmes de référencement cartographique (ex. Geonames).

Étape 2 : établir le degré de précision du pointage

Il est nécessaire ensuite d’établir le degré de précision du pointage. Ce paramètre peut être élaboré en fonction de la fiabilité des sources de localisation et des références des coordonnées cartographiques. Ainsi l’Ecole française d’Athènes a élaboré des paramètres un peu différents de ceux de l’EFR (référence cartographique prise à partir du WebSIG mis au point par les fouilleurs).  Il est en revanche indispensable de toujours mentionner, dans la notice, les modalités de localisation.

L’EFR a fixé trois paramètres de pointage :

  • point exact : pour localiser les structures dont la localisation est certaine comme un bâtiment déterminé ou les petits sites (ex. Amphithéâtre de Pompéi)
  • central : pour les sites plus étendus comme les villes. Dans ce cas nous avons pointé une aire centrale (ex. pour Pompéi, le forum)
  • approximatif : en absence de données exactes nous avons choisi de prendre les coordonnées d’une aire géographique plus étendue.

Étape 3 : relever les coordonnées

À partir de Google Earth :

a) Saisir le nom de la localité (pays, ville ; ici : Pompéigeolocalisation_google_earth_1

b) Visualiser la zone plus ou moins étendue proposée en résultat :

geolocalisation_google_earth_2

c) Cibler, avec le pointeur, le point qui intéresse (ici : l’amphithéâtre de Pompéi)

geolocalisation_google_earth_3

On obtient pour l’Amphithéâtre de Pompéi  –  Coordonnées Google Earth (Est du méridien de Greenwich):

Coordonnés décimales : 40.751297° latitude Nord, 14.495274° longitude Est.

Étape 4 : transcrire la géolocalisation dans WinIBW

Dans la notice d’autorité Tg « Pompéi (ville ancienne) — Amphithéâtre » :

a) insérer la zone Unimarc 123 : coordonnées géographiquesgeolocalisation_zone_123warning_48Attention ! dans chaque sous-zone, il ne faut pas dépasser 8 caractères. Si les coordonnées de géolocalisation sont plus longues, il faut supprimer les derniers chiffres. Les coordonnées des lieux à l’Ouest du méridien de Greenwich dans Google Earth sont signalés par le signe « -« , qui se transcrit dans WinIBW par « 00 ».

Exemple : les coordonnées de Google Earth pour Baelo Claudia (Espagne ; site archéologique ») se transcrivent ainsi :
123 ##‎$de0054630‎$ee0054630‎$fn3605226‎$gn3605226

b) compléter les autres zones Unimarc :

  • 356  : « Note géographique », dans laquelle sont renseignés la base cartographique de référence et le degré de précisiongeolocalisation_zone_356
  • 686 : « Autres classifications », où on indique éventuellement le cadre du projet de géolocalisationgeolocalisation_zone_686
  • 899 : « Note du catalogueur interne au Sudoc » : c’est une zone spécifique aux notices géographiques dont le point d’accès contient une subdivision Rameau $x, $y ou $z, notices dérivées de la BnF et dont la mise à jour est automatique dans le Sudoc (identifiées par la zone 035). La zone sert à éviter que les imports automatiques de la BnF écrasent les données insérées dans le Sudoc, tout en conservant une trace de l’alignement des notices dans les deux catalogues.

899 ##$aIdentifiant RFBNF de la notice à ne pas placer en 035 pour ne pas risquer de perte de données : « FRBNFXXXXXXXXX »

d) faire les liens :

  • 515 : « point d’accès en relation – Nom géographique ». Il s’agit de lier aux sous-unités pertinentes, et réciproquement

geolocalisation_zone_515-bis

En conclusion

L’opération de géolocalisation et la saisie dans le SUDOC se font assez rapidement. À partir de notre expérience, en revanche, le travail de révision et la rétroconversion du corpus des notices bibliographiques liées a été le plus chronophage. Nous avons rencontré également quelques problèmes pour localiser et identifier les sites fouillés anciennement et dont la publication était fragmentaire et incomplète (par exemple,  quelques sites de l’Afrique du Nord).

Elena Avellino
Bibliothèque de l’École française de Rome
elena.avellino[at]efrome.it
logo_EFR

 

 

Synthèse de l’enquête « Évaluation du dispositif CERCLES »

CERCLES_pencils_by_art_sourse

Le dispositif CERCLES (Corrections et Enrichissements par le Réseau de Corpus de l’Enseignement Supérieur) a été lancé en 2015.
Depuis, 17 chantiers ont été lancés, dont 9 encore en cours.

Avec le double objectif d’évaluer les modalités de fonctionnement actuelles et de réfléchir à l’évolution du dispositif, une enquête a été menée, en février 2018, auprès des 18 responsables de chantiers CERCLES.

Voici un résumé de leurs opinions sur le dispositif.

Taux de participation : 77,7 %

18 responsables de chantier ont été sollicités, 14 ont validé le questionnaire. Cela constitue le corpus de réponses complètes et exploitables.
Ceux qui n’ont pas répondu appartiennent à des chantiers co-gérés ; à chaque fois, leurs binômes ont validés leurs réponses, de telle sorte qu’on peut affirmer que, si l’enquête ne reflète pas la totalité des établissements CERCLES, elle reflète en revanche la totalité des chantiers.

Sur l’organisation mise en place par le responsable de chantier :

  • le plus souvent, une petite équipe est mise en place, sans organisation très formelle (échanges sans réunions systématiques et planifiées), mais avec un document collaboratif.
  • s’il n’y a qu’1 agent sur le chantier, l’organisation se met en place en tenant compte de ces moyens limités ; la conduite solitaire d’un chantier n’entrave pas sa réalisation.
  • tous les responsables évoquent la difficulté à faire du « reporting » auprès de leur direction, par manque de document modèle.
  • chacun ressent le besoin de créer des documents spécifiques (procédures, scripts).
  • il semble difficile de prévoir en amont la durée du chantier :
    • le travail en mode projet (estimation, contrôle, révision) n’est pas systématiquement appliqué ;
    • les tâches d’organisation, de coordination ne sont pas quantifiées, au départ, dans le temps estimé nécessaire pour le chantier ;
    • il faut gérer des aléas et des charges de travail imprévues.
  • par contre, le travail CERCLES reste souvent prioritaire, en cas d’aléas.

Sur la reconnaissance de la fonction de responsable de chantier :

  • le plus souvent, un chantier est lancé à l’initiative de l’équipe de catalogage.
  • le travail CERCLES est davantage lié à l’agent (la personne) qu’à sa fonction (la fiche de poste). Ainsi :
    • il n’y pas d’objectifs et d’indicateurs associés dans la fiche de poste des agents responsables de chantier ;
    • aucune pérennité du chantier n’est assurée si l’agent quitte l’établissement.

Sur les enrichissements apportés par le chantier :

  • les axes d’enrichissements s’avèrent toujours plus importants que ceux prévus au départ.
  • les difficultés rencontrées pour les corrections sont liées aux difficultés du traitement des documents électroniques, pas au dysfonctionnement du dispositif CERCLES.
  • la collaboration avec l’éditeur du corpus, au sein du chantier, est utile, mais pas obligatoire.

Sur l’apport de l’ABES :

  • les services sont appréciés, à part l’espace de travail collaboratif, perfectible dans sa forme et dans son usage.

Sur la reconnaissance du réseau :

  • les responsables de chantier n’ont pas vraiment d’avis sur la question. Mais ignorer si on est reconnu ne veut pas dire qu’on ne l’est pas. Cela signifie simplement qu’on n’a jamais eu le moyen de mesurer cette reconnaissance (par exemple, l’ABES n’ pas inclut cette question dans l’enquête 2017 sur les usages professionnels du Sudoc).

Sur les évolutions du dispositif CERCLES :

  • les responsables actuels n’envisagent pas forcément de nouveaux chantiers, puisque la charge de travail est déjà importante.
  • le besoin de lancer des chantiers liées aux données d’autorités de leurs corpus n’apparait pas comme une priorité.
  • les chantiers à venir devraient être d’une volumétrie moins importante, pour attirer d’autres bibliothèques.

 

CERCLES_crayonsEt maintenant… ?

L’équipe de l’ABES en charge de coordonner le dispositif CERCLES analyse ces résultats pour formuler une série de préconisations, qui seront ensuite communiquées au réseau.

La synthèse complète et détaillée des résultats est disponible  ICI.

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

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