Refonte de theses.fr : éclairage sur les choix informatiques

  • Auteur/autrice de la publication :
  • Post category:Non classé

La nouvelle version de theses.fr a été mise en ligne jeudi 14 mars 2024. Consulter le billet Fil’Abes

Conduit selon la méthode SCRUM, le projet de refonte de theses.fr illustre parfaitement les concepts de la politique de développement de l’Abes. Il est l’aboutissement de 19 mois de travail pour l’équipe constituée d’une Product Owner, de cinq développeurs – dont un en prestation externe – et d’un devops.

Fidèle à la résolution de l’Abes qui, depuis 2019, publie les codes sources de ses applications sur Github, le projet est entièrement open source. Ses différents modules sont répartis dans plusieurs dépôts, tous hébergés dans l’organisation Github de l’Abes.

L’interface du site

Un premier dépôt contient le code de l’interface de l’application réalisée avec le framework Nuxt, surcouche au framework VueJs. VueJs a été choisi par les développeurs de l’Abes pour sa courbe d’apprentissage jugée plus rapide que pour ses concurrents React ou Angular.

La surcouche Nuxt assure une meilleure indexation du site par les moteurs de recherche du web, notamment grâce au Server Side Rendering, qui permet de préparer, côté serveur, une partie du code client qui sera exécuté dans le navigateur et ainsi le rendre immédiatement lisible par les moteurs d’indexation. De plus, Nuxt propose et préconfigure par défaut un certain nombre de fonctionnalités indispensables, comme le routage qui fournit les URLs de l’application, la gestion des erreurs ou encore la récupération des données depuis les API.

L’accès à l’interface via différents types de terminaux est également facilité par le framework VueJS : une navigation aisée sur mobile est une des nouveautés du site.

Une attention toute particulière a été portée par les développeurs sur l’accessibilité de l’interface, qui respecte les règles édictées dans le Référentiel général d’amélioration de l’accessibilité (RGAA) : polices appropriées, choix des couleurs, contraste, mise en forme de la page et utilisation de balises ARIA pour introduire la sémantique des éléments dans le code HTML.

Une intégration continue

L’intégration continue du projet est assurée par des actions Github, programmes qui se déclenchent à chaque fois qu’un développeur pousse (publie) du code sur une branche (qui propose une fonctionnalité) du projet : le code est alors compilé et, si la compilation et les tests réussissent, la branche en question peut alors être publiée comme image sur la plateforme Dockerhub. Ces images sont alors disponibles pour déploiement sur nos machines de développement, test ou production. A noter que le code de l’intégration continue est versionné sur le même dépôt que le projet, au plus près de ce dernier pour en faciliter la maintenance.

Les API

Côté back-office, theses.fr est composé de trois API, ensemble de services utilisés par l’interface VueJs mais qui peuvent également être appelés depuis des programmes externes.  Ces API, programmées en Java Spring et documentées selon la norme OpenAPI, sont publiées à cette adresse : https://api.gouv.fr/les-api/api-export-donnees-these

Ces services recouvrent trois thématiques :

  • La recherche dans les métadonnées : il est possible d’interroger les données en passant directement une chaine de recherche du langage de requête du moteur d’indexation Elastic Search via l’URL. Les réponses sont renvoyées au format JSON.
  • La diffusion des documents : cette API fournit à la fois les boutons à afficher dans l’interface pour chacune des thèses et les liens avers les documents eux-mêmes, ou des liens vers des ressources externes décrivant les documents, comme les notices du catalogue Sudoc. Les accès aux documents sont contrôlés : il n’est pas possible de visualiser une thèse confidentielle et la récupération d’une thèse sous embargo est soumis à authentification.
  • L’export des métadonnées : les métadonnées des thèses sont fournies dans des formats BIBTEX et RIS qui permettent d’échanger ou d’intégrer facilement la thèse comme référence bibliographique. Elles sont aussi disponibles en RDF, format du web sémantique qui facilite leur intégration dans le Linked Open Data cloud

Le moteur Elastic Search

Les données sont indexées dans le moteur Elastic Search, le choix s’étant porté sur cet outil à la fois pour sa popularité et sa présence dans la pile logicielle Elastic Search – LogStash – Kibana, déjà installée dans  le système d’information de l’Abes.

Elastic Search assure les fonctionnalités essentielles telles que filtres, agrégations, pondération ou encore calcul de pertinence lors de l’exécution des requêtes tout en maintenant un haut niveau de performance en termes de délai de réponse.

Consulter :  https://collection-numerique.amue.fr/numero-27/13.html

Fédération d’identité

Si les thèses en accès restreint ne sont pas disponibles pour le grand public, leur diffusion étant par exemple limitée par un embargo, elles doivent cependant être accessibles aux membres de l’Enseignement Supérieur et de la Recherche. Donner accès à ces thèses constitue donc une des principales nouveautés du nouveau theses.fr.

L’implémentation de cette fonctionnalité a été réalisée grâce à l’inscription de theses.fr en tant que fournisseur de services dans la fédération d’identité RENATER. L’authentification des utilisateurs est ainsi déléguée à cette fédération d’identité qui s’assurera que toute personne disposant d’un compte chez un fournisseur d’identités pourra accéder aux thèses en accès restreint.

Le système, qui repose sur le protocole SAML2, requiert l’installation et la configuration de briques logicielles : à cette fin, nous avons mis en place un proxy Apache chargé de rediriger les URLs des thèses en accès restreint vers une page demandant à l’utilisateur de choisir son fournisseur d’identité afin de s’authentifier pour pouvoir accéder à la ressource.

Continuer la lectureRefonte de theses.fr : éclairage sur les choix informatiques

À la recherche des unicas de la bibliothèque Sainte-Geneviève

En janvier 2022, la bibliothèque Sainte-Geneviève a débuté un projet pluriannuel (2022-2024) de refonte de ses outils de politique documentaire, par la mise à jour du plan de développement des collections et de la charte documentaire.

Dans ce cadre, une analyse quantitative et qualitative de ses collections a été lancée, afin d’identifier et de caractériser plus finement ses pôles d’excellence et ses gisements documentaires rares et remarquables.

Ce billet retrace la méthodologie employée pour une des étapes de cette analyse qui consiste en la catégorisation thématique de l’ensemble des unicas. Pour mémoire, les unicas sont, dans le contexte du Sudoc, des notices bibliographiques sous lesquelles un seul établissement du réseau est localisé. 

L’équipe actuelle en charge de ces opérations se compose de trois personnes, dont deux catalogueuses, pour un total d’environ 30 heures de travail hebdomadaire. Ce chantier est réalisé avec l’appui de la monitrice étudiante et des magasiniers du département des Services aux publics pour les vérifications en magasin. 
– Chef de projet “unica” : Emilie Trompille 
– Chef de projet du plan de développement des collections : Timothée Rony 
– Expertes catalogueuses : Marie Barbier, Clara Dauber 
– Soutien informatique : Clément Croquet, Pauline Rivière et le service informatique de la bibliothèque. 

Vrais ou faux unicas ?

unicaCe chantier résulte d’un constat effectué il y a plusieurs années : sur les 261 560 unicas (données extraites en octobre 2022) que posséderait, d’après l’outil SELF Sudoc, le Fonds général de la bibliothèque,  un certain nombre de notices correspondent en fait à de faux unicas générés lors d’opérations de rétroconversion menées dans les années 1980-1990. Cette situation ne nous permettait donc pas de mesurer réellement la rareté de nos collections. 

L’objectif était donc d’identifier les  notices des véritables unicas parmi les doublons de notices qui avaient été créés par erreur. 

Après avoir sollicité l’aide de l’Abes, il nous a été proposé d’exploiter – de manière un peu détournée – les possibilités offertes par l’outil d’alignement des données Bibliostratus (BBS), de façon à repérer pour une liste de PPN donnés d’éventuels faux unicas sur la base de divers numéros de contrôle (EAN, ISBN) et à défaut d’une requête “titre + auteur”, en choisissant d’aligner de préférence avec le Sudoc, et dans un second temps avec la BnF. 

L’aide apportée par Bibliostratus

logo bibliostratus
CC BY-NC-SA Groupe Systèmes & Données, Transition bibliographique

À l’aide de la liste des PPN unicas de monographies exportée via SELF Sudoc, nous avons demandé l’extraction des données nécessaires à la structuration du fichier d’entrée pour le module alignements de BBS (PPN/FRBNF, ARK, ISBN, EAN, titre, auteur, date, volume-tome et éditeur). Néanmoins, le format d’export initial nous a posé  des problèmes lors de la conversion en UTF-8 sans BOM : des caractères spéciaux apparaissaient à la place des caractères accentués. Il a donc fallu procéder à un nettoyage préalable, ainsi qu’à un tri des données d’autorité, de façon à ne conserver que le premier auteur (par choix,  BBS permettant de traiter plusieurs auteurs d’une même ressource en multipliant le nombre de lignes correspondant à cette ressource autant de fois qu’il y a d’auteurs.)  

Les fichiers divisés par année de publication sont ensuite chargés dans BBS, qui recherche les correspondances possibles dans le catalogue Sudoc et identifie ainsi les notices en doublons. Au départ, une vérification de chaque doublon était réalisée dans WiniBW car BBS n’était alors pas en mesure de comparer certaines informations comme l’éditeur, la pagination, la mention ou non d’une collection. Grâce à nos remarques communiquées au développeur, BBS permet désormais un contrôle sur les éditeurs depuis la version 1.35. Il s’active dans les préférences avec la possibilité de demander un niveau de contrôle plus ou moins fort sur les données Éditeur pour les monographies imprimées (voir la copie d’écran ci-dessous).

La BSG a choisi de conserver pour le moment la valeur 0.

Copie d'écran de Bibliostratus
Extrait de la fenêtre des préférences de Bibliostratus. 4 valeurs possibles pour un contrôle des données concernant les éditeurs

Un travail de dédoublonnage classique pour retrouver ses unicas

illustration : plus d'unicaPlus la date de publication est ancienne, plus les doublons apparaissent et les notices sont lacunaires, ce qui nécessite de procéder à des vérifications livre en main, en magasin. Cela nous a également permis de découvrir d’autres anomalies de catalogage, comme la création, pour les ouvrages en plusieurs volumes, d’une notice globale en plus des notices par volumes. Quand le doublon est avéré, la fusion des notices est lancée dans WinIBW. En cas de doute, nous sollicitons les bibliothèques possédant un ouvrage similaire pour déterminer s’il s’agit ou non d’un unica. 

Au 12 janvier 2024, environ 53 495 notices ont été analysées, 4 380 doublons ont été détectés et 2 055 ont été effectivement supprimés (ou sont en attente de suppression).

Nous tenons à remercier vivement les collègues de l’Abes et Étienne Cavalié (développeur de Bibliostratus) pour l’accompagnement de ce projet via BBS, qui nous permettra à terme une meilleure compréhension de l’unicité de nos collections tout en procédant à un important travail de nettoyage de notre catalogue local et des notices WinIBW correspondantes. Il améliorera également pour les lecteurs la recherche et la sélection des résultats dans le Sudoc. 

Emilie Trompille
    coordinatrice Sudoc et correspondante catalogage, Bibliothèque Sainte-Geneviève

Continuer la lectureÀ la recherche des unicas de la bibliothèque Sainte-Geneviève

Quand IdRef s’aligne sur ROR, ou comment rapprocher des référentiels 

 “Faire de la lumière, pauvres gens, c’est plus difficile que de faire de l’or.” (Paul Claudel, L’annonce faite à Marie)

Prémices de l’intérêt pour ROR Research Organization Registry

Tête de lion rugissant, Eugène Delacroix. Crédits : Photo (C) RMN-Grand Palais (musée du Louvre) / Michel Urtado.

Au printemps 2021, le service Autorités et Référentiels de l’Abes avait mené un travail de veille sur les référentiels dédiés aux structures. Contrairement aux personnes ou aux publications pour lesquelles un identifiant pérenne – respectivement ORCID et DOI – s’est progressivement imposé au plan international, les collectivités, dans le monde de la recherche, sont un secteur pour lequel plusieurs référentiels coexistent, notamment : ISNI, GRID, ROR, RingGold.

Au printemps 2023, nous avons décidé de prendre à bras le corps la question de la qualité des notices IdRef de type ‘Tb’ qui décrivent des collectivités liées à la recherche. Se posait alors alors la question du champ : que devions-nous couvrir ? Par pragmatisme, nous avons défini un premier cercle : les établissements habilités (actuellement ou dans le passé) à délivrer le doctorat. 216 notices ont ainsi été passées en revue, améliorées, et enrichies d’alignements vers le référentiel ROR.

Nous avons découvert que ROR, qui s’était jusqu’alors présenté comme un référentiel des top-level institutions, avait enrichi sa base pendant l’été 2023 avec de nombreuses structures de type laboratoires (unités mixtes de recherche) au moyen des données publiques issues du RNSR.

Cette inflexion semblait nécessaire pour poursuivre l’objectif de ROR, qui est de structurer les données d’affiliation des publications par des PID. Nous avons alors emboîté le pas, en élargissant le cercle : le début de l’année 2024 a vu l’injection de nouveaux alignements ROR dans IdRef, pour des structures, de type unités de recherche, et plus seulement pour des établissements.

Méthodologie

Nous sommes partis du dump des données ROR, avec lequel il est plus facile de travailler qu’avec l’API. En effet, celle-ci pagine les résultats, ce qui est peu pratique pour de gros corpus de plusieurs milliers de structures. La documentation de l’API ROR est d’ailleurs claire sur ce sujet : ce n’est pas le bon point d’entrée quand on veut travailler sur de gros volumes.

Ces données ont été chargées dans un projet OpenRefine pour être manipulées. Nous avons considéré les structures dont le pays est la France, et écarté celles de type privé. Pour ce faire, les types présents dans le modèle de données étant Education, Healthcare, Company, Archive, Nonprofit, Government, Facility, Other, nous avons donc exclu le type Company et conservé tous les autres types.

Nous avons conservé les structures ayant des statuts autres que active (à savoir inactive ou withdrawn – retirée du référentiel) en les considérant comme marginales mais dignes d’intérêt, puisque IdRef possède une profondeur historique certaine.

Étape 1 : Aligner IdRef vers ROR avec Wikidata comme pivot

Nous avons identifié les structures ROR possédant un ID Wikidata, puis interrogé Wikidata pour faire remonter les IdRef connus de Wikidata. Tous les alignements proposés ont été passés en revue : nous avons pu injecter les  ROR ID dans 840 notices IdRef ainsi que, lorsqu’ils n’y étaient pas encore, les ID Wikidata.

Au passage, nous avons corrigé les données dans Wikidata pour une poignée d’entités, et avons signalé à ROR les erreurs constatées. En outre, des doublons IdRef ont trépassé à cette occasion !

Étape 2 : Aligner IdRef vers ROR à l’aide du numéro d’UMR

Nous avons observé dans le dump que certaines entités possédaient un external ID CNRS correspondant au numéro d’UMR. Cette donnée ancienne est issue de GRID. Si vous n’avez pas encore lu l’article du numéro d’Arabesques 112 consacré à ROR, voici un petit rappel : GRID était une base de données créée par la société DigitalScience en 2015. Elle a fourni le premier noyau des données de ROR, lequel s’en est définitivement émancipé en 2021. ROR a défini pour son schéma de métadonnées v2.0 une politique claire : ne mentionner que des référentiels ouverts et pour lesquels les alignements sont maintenus. Ce n’est pas le cas de cette donnée, qui est donc vouée à disparaître.

Nous pensions qu’elle pouvait cependant se révéler utile, non en tant qu’identifiant, mais pour l’apparier avec le contenu des variantes (zones A410) des notices IdRef. Cette étape, un peu fastidieuse, a permis de repérer un nombre important de corrections à signaler à ROR, probablement parce qu’il s’agissait d’entités présentes de longue date dans le registre. Elle a tout de même abouti à l’ajout de 315 ROR ID dans les notices IdRef correspondantes.

Étape 3 : Aligner IdRef vers ROR en comparant des chaînes de caractères

Voici le programme des prochaines semaines. Nous attendons la sortie officielle prochaine de la v 2.0 du schéma pour bénéficier d’une information supplémentaire qui facilitera les traitements : l’étiquette de langue sur chaque appellation.

En effet, dans le registre, de nombreuses structures de type laboratoire ont un intitulé principal en anglais : il sera ainsi plus aisé de les isoler et de rechercher dans les variantes connues la forme en français pour la comparer au point d’accès des notices IdRef.

Par ailleurs, pour faciliter les allers-retours entre les deux référentiels, deux sous-services ont été ajoutés aux webservices IdRef2id et id2IdRef : idref2ror et ror2idref. A partir d’un PPN, on peut facilement savoir si un ROR ID est présent dans la notice. A l’inverse, à partir d’un ROR ID, on peut savoir si une notice IdRef le mentionne (ou plusieurs… mais là commencent les problèmes !)

Quelques chiffres

ROR recense près de 100 000 structures, dont 3 500 structures françaises de statut public. Au printemps 2021, quand l’Abes a commencé à s’intéresser à ROR, seules 72 notices IdRef étaient pourvues d’un ROR ID. La progression en trois ans est pharaonique puisqu’au 15 mars 2024, ce sont 1 561 notices qui sont pourvues d’un ROR : un bond de géant de plus de 2000 % !

Et la vraie bonne nouvelle, c’est que cet effort, pour récent qu’il soit, est partagé.  Parmi ces notices dotées d’un ROR ID, 1 247 ont vu l’injection de cet identifiant au cours du premier trimestre 2024. L’Abes ayant aligné 1 155 nouvelles notices, le reste est à mettre au compte du réseau, qui a été particulièrement actif, avec 92 ajouts pendant ce court laps de temps. Merci à tous les « coraut » !

ROR is the new chic, à n’en pas douter

Pour terminer, et parce que c’est le printemps, un peu de poésie avec une rime suffisante : ROR et OR partageant deux phonèmes, un joli score pour si peu de lettres !

Lire aussi dans le numéro d’Arabesques 112 consacré aux Autorités et Référentiels : https://publications-prairial.fr/arabesques/index.php?id=3836

 

 

 

Continuer la lectureQuand IdRef s’aligne sur ROR, ou comment rapprocher des référentiels 

Quand la base de données d’ITEM a disparu : retour sur l’incident de fin janvier 2024

Date de début de l’incident: 26/01/2024 à 12h20Date de fin de l’incident : 05/02/2024 à 11h04Type d’incident : Critique

Points essentiels à retenir

Précisons tout d’abord qu’une indisponibilité de la base de données d’ITEM ne concerne en rien les exemplaires créés dans le Sudoc ; ces deux processus sont distincts. Ainsi, l’absence de visualisation d’une demande dans le tableau de bord ne reflète pas un problème dans le traitement réel des opérations dans le Sudoc.

De même, il convient de distinguer les fichiers de traitement des informations relatives aux demandes. En cas d’incident sur la base de données, les fichiers de demande sont stockés sur les serveurs de l’Abes et peuvent être retrouvés à partir de leur numéro. Cependant, cela nécessite que l’utilisateur ait mémorisé ce numéro, car il n’est pas possible de retrouver une demande à partir de l’ILN et/ou du RCR. Une réflexion sera menée sur ce point.

Symptômes et impacts de l’incident

Le 26 janvier, un utilisateur constate que ses tableaux de bord sont vides et que le système lui demande de saisir son adresse e-mail après authentification, un comportement anormal puisque cela ne se produit habituellement qu’à la première connexion.

Mesures prises : fermeture de l’application ITEM et envoi d’un mail d’alerte aux professionnels des réseaux.

Le problème identifié révèle un dysfonctionnement de la base de données d’ITEM. Une recherche de solutions de restauration à partir des sauvegardes est entreprise. Cependant, au 29 janvier 2024,  les sauvegardes journalières de la base de donnée s’avèrent vides … depuis le 26 février 2023, un problème dont la source réside dans un désaccord (mismatch) de version entre le serveur PostgreSQL (version 15.1) et l’outil de sauvegarde (version 14.4), qui empêchait  la création de dumps valides. Rappelons qu’un dump représente un instantané de la base de données de l’application contenant toutes les informations relatives aux demandes créées (l’index, le type de demande, etc.).

Mesure prise pour résoudre le problème de compatibilité : mise à jour de l’outil de sauvegarde vers la dernière version (4.0.35)

Le dernier fichier de sauvegarde disponible datant du 26 février 2023, il s’ avère nécessaire de tester la capacité de restauration en environnement de développement. Il a tout d’abord fallu décider quelle base de données utiliser pour la relance d’ITEM : les sauvegardes du 26 février 2023 ou une base vide ?  Ensuite, avant la réouverture en production, il a été nécessaire d’activer les traces SQL de PostgreSQL puis de mettre à jour le dumper vers la dernière version (4.0.35).

Causes et solutions

Du fait du manque de logs, la cause précise de l’incident n’a pas été identifiée avec certitude. Le principal soupçon réside dans un effet de bord d’un paramétrage spring ou d’un batch au sein d’ITEM.

À la suite de l’incident, des mesures ont été prises pour prévenir de futures occurrences similaires. Elles incluent la modification des emplacements de sauvegarde, l’ajout de sondes de surveillance, la notification de l’état des sauvegardes, la réalisation de tests de restauration réguliers, et la réparation du système de logs.

Une certitude : en cas de récidive de l’incident, l’Abes sera en mesure de restaurer plus rapidement – dans la journée en cours – les données relatives aux demandes.

Continuer la lectureQuand la base de données d’ITEM a disparu : retour sur l’incident de fin janvier 2024

CERCLES : lancement d’un nouveau chantier sur le corpus Lextenso par la BU Angers

  • Auteur/autrice de la publication :
  • Post category:Sudoc

Illustration crayons de couleurEn 2015, naissait le dispositif CERCLES (voir le billet) mis en place par l’Abes pour accompagner, aider et valoriser un établissement souhaitant s’investir sur l’enrichissement des données d’un corpus de documents spécifique.

En 2024, un nouveau corpus de ressources électroniques va bénéficier de ce dispositif : Lextenso.

Le corpus Lextenso

Proposant des ressources numériques (revues et  ebooks) de doctrine, de jurisprudence et de codes, la base Lextenso constitue un corpus utile et apprécié des usagers des bibliothèques en sciences juridiques et économiques. Les domaines couverts sont ceux du droit français (public et privé) mais aussi du droit international, de la fiscalité et des finances publiques. Parmi les ressources, on trouve également des collections de manuels juridiques et des documents pédagogiques (Carrés rouges Gualino, Mémentos Gualino, Cours LGDJ et Manuels LGDJ).

Deux corpus au lieu d’un

illustration : deux crayonsEn 2023, la BU Angers affirmait sa volonté de contribuer au signalement des ressources électroniques dans le catalogue collectif Sudoc en participant à son premier chantier CERCLES, en binôme avec le SCD de l’université de Rennes, autour du corpus Strada Lex. Après quelques mois de travail, il s’est avéré que le fonctionnement en binôme ne se justifiait pas sur un corpus sans mises à jour volumineuses. D’un commun accord, les deux établissements responsables du chantier Strada Lex ont donc mis fin au fonctionnement en binôme, pour élargir l’offre d’un signalement de qualité à deux corpus au lieu d’un.

À partir de janvier 2024, la BU d’Angers devient donc responsable du signalement du corpus Lextenso, tandis que le SCD de l’université de Rennes continue son chantier CERCLES sur le corpus Strada Lex, pour le plus grand intérêt des étudiants, chercheurs et enseignants-chercheurs en sciences juridiques.

L’investissement de la BU Angers

  • Corpus : 24 revues juridiques et 108 ebooks
  • Période de travail : à partir du 1er janvier 2024
  • Responsable du chantier : Céline Giraudeau
  • Organisation et ressources humaines mobilisées : l’équipe est constituée d’une catalogueuse, de la correspondante Catalogage, de la Coordinatrice Sudoc et de la responsable des infrastructures numériques.
  • Référent Abes : Thomas Fresneau
  • Axes d’enrichissements :
    • veille sur les mises à jour du fichier KBart disponible sur BACON
    • création régulière de nouvelles notices
    • enrichissements apportés aux notices créées et existantes :
      • vérification ou création des liens en zones B6XX et B7XX
      • création des notices d’autorités correspondantes
      • insertion de la zone B830
      • avertissement du réseau en cas de suppression de titres communiquée par l’éditeur

Les « + » du chantier :

  • l’aide initiale de l’Abes pour déceler les notices manquantes
  • l’insertion de la zone B035, qui permet de retrouver toutes les notices du corpus dans WinIBW, avec la commande CHE SOU LEXTENSO?
  • la création de notices d’autorité liées aux ressources
  • l’usage possible paprika.idref.fr, interface de visualisation et de correction des liens

Au nom du réseau, l’Abes remercie la BU Angers pour son investissement dans ce nouveau chantier CERCLES  !

Consulter le document du suivi pour suivre la progression du travail

 

Continuer la lectureCERCLES : lancement d’un nouveau chantier sur le corpus Lextenso par la BU Angers

Articuler Calames  et Wikimedia Commons : point technique

  • Auteur/autrice de la publication :
  • Post category:Non classé

Ce billet propose un point technique sur la façon d’articuler Calames et Wikimedia Commons. Consulter le billet Fil Abes à ce sujet

Récupérer les données produites dans le cadre du signalement dans Calames afin de les importer sur Wikimedia Commons, plateforme comportant des dizaines de milliers d’utilisateurs dans le monde, semble d’emblée une bonne idée. Pour ce faire, l’Abes se devait de répondre d’un point de vue technique à la question suivante : comment faciliter le liage entre les métadonnées associées aux ressources Calames et Wikimedia Commons ? 

Mise à disposition d’un plugin dédié

Le plugin Pattypan s’est vite imposé comme un choix sûr. Développé par la communauté des wikimédiens, régulièrement mis à jour et librement accessible sur GitHub, ce plugin permet de charger des fichiers en masse, ce dans un large choix de formats (jpg, png, pdf, wav, TIFF,…). De plus, il a l’avantage non négligeable de réunir métadonnées et fichiers numériques en un seul import dans Wikimedia Commons, les données étant prises en charge dans un simple tableau Excel. 

Seul inconvénient identifié, le plugin Pattypan nécessite des compétences en Java pour être exécuté sous Windows. Pour remédier à ce problème, l’Abes a donc décidé de financer une prestation de développement. Celle-ci, réalisée par Wikimédia Suède, a abouti à une version du plugin exécutable directement sous Windows, par un simple double-clic sur une icône dédiée présente sur le bureau. Cette version du plugin est librement téléchargeable sur le GitHub dédié.

Mise en place de nouveaux flux de données

Créer les liens entre Pattypan et les métadonnées descriptives présentes dans Calames s’avère relativement simple. Rappelons que Calames proposait déjà des exports d’EAD vers Dublin Core au format csv (à ouvrir avec Excel ou tout autre tableur). Cependant, du fait du format particulier des métadonnées de Wikimedia Commons, il a fallu définir un mapping d’EAD vers ce format spécifique, les modèles de données utilisés dans Wikimedia Commons étant plus simples que le format EAD. Une fois cette opération réalisée,  l’Abes a mis en production deux nouveaux exports Calames, correspondant aux deux modèles de données, complémentaires, proposés par Wikimedia Commons : les modèles «book» et «artwork». 

Ces deux exports ont été pensés afin que les liens avec les composants EAD de Calames – et, le cas échéant, avec les autorités IdRef et les bibliothèques numériques des établissements – soient récupérés directement puis importés dans Wikimedia Commons. 

Il est donc désormais possible – en quelques minutes voire secondes – d’exporter les données Calames puis d’importer dans Wikimedia Commons, d’une part, le tableau des données descriptives, d’autre part, les fichiers numériques des documents.

Le résultat : des fichiers partagés, de multiples rebonds et des perspectives 

Afin de regrouper les fichiers importés selon la personne, l’entité, le lieu, l’époque ou la thématique, il est vivement recommandé d’assigner des catégories Wikimedia Commons aux fichiers à importer. Chaque établissement public est encouragé à créer sa propre catégorie afin de rassembler l’ensemble des fichiers issus de ses collections. Ces catégories particulières peuvent aussi renforcer la visibilité d’un fonds, d’une collection ou d’un ensemble spécifique à l’intérieur des collections.

Du côté du catalogue Calames, il est possible d’établir des liens réciproques vers Wikimedia Commons. Pour réaliser cette opération, il convient d’en faire la demande à l’Abes qui se chargera de la création en masse des liens pointant vers les documents importés dans Wikimedia Commons. 

De même, les établissements qui le souhaitent peuvent s’engager dans des chantiers de création ou d’alignement entre les identifiants IdRef présents dans les données Calames et les identifiants Wikidata utilisés par Wikipédia. Précisons que l’export depuis Calames n’impose pas un tel chantier : il s’agit d’un choix à définir selon l’investissement de l’établissement sur ces plateformes. 

Notons enfin que certains des établissements Calames – La Contemporaine notamment – ont fait le choix d’organiser des événements, des formations ou des ateliers d’édition dans Wikipédia. On peut aussi imaginer des ateliers – organisés potentiellement avec des chercheurs, doctorants, étudiants…- dédiés à la récupération de fichiers importés dans Wikimedia Commons et à leur utilisation pour illustrer des fiches Wikipédia.  Pour cela, il est vivement conseillé de se rapprocher de Wikimédia France. 

En savoir plus

 

Continuer la lectureArticuler Calames  et Wikimedia Commons : point technique

Focus sur les technologies utilisées pour la publication du projet d’établissement 2024-2028 de l’Abes

  • Auteur/autrice de la publication :
  • Post category:Non classé

Au cours de l’année 2023, l’Abes a préparé son projet d’établissement pour la période 2024-2028. Une équipe Scrum, composée de 10 agents issus des 3 départements de l’Abes, a été mise en place pour travailler de manière itérative sur l’analyse des produits et services de l’Abes, le recueil des besoins utilisateurs, des propositions de services et enfin la rédaction du document de projet. 

Pour cette dernière étape, un site web public, doté d’un système permettant aux utilisateurs de déposer des commentaires, a été mis en place : https://projet2024.abes.fr

Cet article a pour objectif de détailler les technologies utilisées pour la conception de ce site web : 

  • Docusaurus, 
  • Hypothes.is, 
  • CI/CD avec GitHub et Docker

Docusaurus 

Le socle du site est le logiciel libre Docusaurus (dans sa version 2) dont la devise est : « Construisez rapidement des sites web optimisés, concentrez-vous sur votre contenu. 

Il s’agit d’un logiciel très populaire – https://docusaurus.io/showcase – dans le monde de l’IT maintenu par les développeurs de Facebook. Son principal cas d’usage est de simplifier la création et la maintenance de documentation en ligne. Il permet de générer des sites web statiques, fluides au niveau de la navigation et optimisés pour le référencement web. 

Le workflow Docusaurus pour la publication du contenu est le suivant : 

  1. L’auteur rédige ou modifie un fichier au format markdown (syntaxe wiki devenue très populaire avec l’arrivée de GitHub). 


      2 – Le système de compilation de Docusaurus va ensuite générer les pages statiques HTML, CSS, JS du site web à partir des fichiers markdown. Cette opération est automatisée à l’aide  des technologies  CI/CD : Github & Docker.

Les fichiers markdown – qui intègrent le contenu du site – sont consignés dans un dépôt GitHub dédié : https://github.com/abes-esr/projet2024. Les contenus peuvent être modifiés à tout moment, que ce soit directement via Git ou via l’interface wysiwyg de GitHub.

Comme pour tous les développements opensource de l’Abes, nous avons suivi le workflow GitFlow pour déployer le site du projet sur les 3 environnements (développement, test, production) en préservant une correspondance entre les branches et tags du GitFlow et l’environnement cible. Voici par exemple ce que cela donne pour l’application « projet2024 » :  

  • Environnement « dev » (développement) : toutes les modifications de contenus (fichiers markdown) et de configuration du site web sont réalisées sur la branche « develop » qui se retrouve alors automatiquement déployée sur l’URL suivante : https://projet2024-dev.abes.fr  (uniquement accessible depuis le réseau interne de l’Abes) 
  • Environnement « test » : une fois les modifications prêtes à être testées, on fusionne la branche « develop » dans la branche « main » et l’ensemble se retrouve alors automatiquement déployé sur l’URL suivante : https://projet2024-test.abes.fr  (uniquement accessible depuis le réseau interne de l’Abes) 
  • Environnement « prod » (production) : une fois les tests validés sur l’environnement précédent, une release (un tag git) est générée qui permet un déploiement sur l’URL de production : https://projet2024.abes.fr   

Ce système, dont les technologies sont détaillées dans le chapitre « CI/CD : Github & Docker », permet d’assurer une autonomie au rédacteur qui, ainsi, ne dépend pas d’un informaticien pour publier les contenus. 

Nous avons également utilisé la technologie Mermaid, disponible par défaut sous forme d’un plugin Docusaurus. Cette fonctionnalité, qui permet de générer des diagrammes au moyen d’une syntaxe textuelle spécifique, a servi pour tracer les diagrammes de Gantt de la partie « calendrier du projet » : https://projet2024.abes.fr/docs/2.4/projet2024-calendrier  

Syntaxe spécifique de mermaid pour générer un Gantt 

 

Visuel correspondant à la syntaxe Mermaid

 

Hypothes.is 

La seconde technologie utilisée est le logiciel libre Hypothes.is, dans sa version SaaS, dont la devise est : Collaborer avec n’importe qui, de n’importe où (« Collaborate with anyone, anywhere. ») 

Ce logiciel, au code source ouvert – https://github.com/hypothesispermet de déposer des commentaires partout sur le web. Pour le site du projet de l’Abes, nous avons utilisé la version publique hébergée en SaaS également proposée par lentreprise Hypothes.is.

Pour la publication de commentaires sur le site « projet2024 », le wokflow Hypothes.is est le suivant : 

  • L’utilisateur crée un compte sur la plateforme SaaS Hypothes.is 
  • Il peut alors surligner le texte qu’il souhaite commenter puis rédiger un commentaire qui sera accessible publiquement dans le panneau latéral droit 
  • De la même manière, il peut cliquer sur les commentaires des autres utilisateurs et y répondre 
Exemple de commentaires déposés avec Hypotes.is 

 

Ce système, complètement indépendant de la technologie Docusaurus, est pratique du fait qu’il évite de devoir embarquer dans Docusaurus un système potentiellement complexe pour gérer la création de compte et l’authentification. Il permet de déposer et de répondre à des commentaires de manière très ergonomique. 

Enfin, l’intégration d’Hypothes.is dans le site web « projet2024 » a été simple et rapide : il a suffi d’ajouter un morceau de javascript embed.js dans les pages du site web et de rédiger un tutoriel à destination des utilisateurs. 

CI/CD : GitHub & Docker 

Le système d’intégration et déploiement continus de l’Abes a permis de compiler, intégrer puis déployer automatiquement ce site web. Ainsi, ce site est déployé de la même manière que les applications ITEM (cf dépôt GitHub),  QualiMarc (cf dépôt GitHub) ou theses.fr (cf dépôt GitHub). 

Pour mettre en place cette CI/CD sur l’application « projet2024 », la première étape a consisté à déposer son code en opensource sur le GitHub de l’Abes https://github.com/abes-esr/projet2024 – et la seconde  à ajouter deux GitHub Action dans son code source, ce qui permet de : 

Enfin, la troisième étape a consisté à préparer un dépôt GitHub dédié au déploiement de l’application « projet2024 » dans les 3 environnements (développement, test, production) : https://github.com/abes-esr/projet2024-docker 

Ce dernier dépôt comporte trois fichiers clé : 

  • docker-compose.yml : contient la description et la configuration statique des différents conteneurs de l’application, soit, dans notre cas, les deux conteneurs suivants : 
    • projet2024 : conteneur principal comportant un serveur web nginx légèrement configuré et dont le rôle est d’exposer les sources HTML/JS/CSS statiques générées par le logiciel Docusaurus dans la phase de CI
    • projet2024-watchtower :  conteneur particulier du fait qu’on le retrouve dans toutes les applications Abes déployées avec cette CI/CD (pour rappel : ITEM, QualiMarc, theses.fr …). Il utilise le logiciel Watchtower – https://containrrr.dev/watchtower – qui permet de scanner toutes les n minutes dockerhub pour vérifier si une nouvelle version de l’application est prête à être déployée ou non. C’est ce conteneur qui permet de faire le “CD” de “CI/CD”. 
  • .env-dist : contient les paramètres de l’application pouvant être personnalisés entre les trois environnements de déploiement (dev, test et prod). 
  • README.md :  contient les procédures d’exploitation de l’application (comment l’installer, la démarrer, la stopper, la superviser, la sauvegarder) 

Conclusions

L’utilisation des technologies Docusaurus et Hypothes.is a constitué une première à l’Abes. Nous avons particulièrement apprécié la facilité et la rapidité de production  (mise en œuvre d’environ 4 jours de travail à 3 personnes) d’un site web fonctionnel doté d’une navigation rapide et moderne (et responsive). 

Pour sa part, le système d’intégration et déploiement continus (CI/CD), sur lequel repose l’ensemble des nouvelles applications développées à l’Abes, a permis de publier facilement et sereinement les versions successives du projet d’établissement (versionnements Git et Docusaurus). 

En revanche, la fonctionnalité d’édition/publication depuis le format markdown – qui représente pourtant un des points forts de Docusaurus pour gérer collaborativement l’édition et la publication de documentation sur un site web – n’a pas été utilisée : de fait, pour collaborer sur le contenu du document de projet, il a été décidé d’utiliser le logiciel Microsoft Word associé à OneDrive, bien connu des membres de l’équipe du Projet d’établissement. L’intégration des contenus dans le site web final n’a donc pas été aussi fluide et intégrée que cela aurait pu l’être en l’éditant directement à partir du markdown. De fait, pour réaliser la conversion automatique de .docx vers markdown (cf procédure), le logiciel Pandoc a été utilisé.

Le type d’architecture présentée dans cet article nous a donc convaincus. Elle est actuellement utilisée à l’Abes pour la publication de la documentation d’un projet interne et servira également pour la publication d’un site web dédié à la politique de développement informatique de l’Abes, actuellement géré directement en markdown depuis GitHub. 

Continuer la lectureFocus sur les technologies utilisées pour la publication du projet d’établissement 2024-2028 de l’Abes

Nouvel import Sudoc : les notices des vidéos en streaming de la plateforme Arte Campus 

  • Auteur/autrice de la publication :
  • Post category:docelecSudoc

Pour répondre à la demande d’établissements du réseau Sudoc, l’Abes, en collaboration avec le Service de coopération documentaire interuniversitaire (SCDI) de Montpellier, a mis en place un nouveau flux d’import permettant de charger mensuellement les nouvelles notices disponibles depuis la plateforme de diffusion Arte Campus. L’import initial a eu lieu  fin novembre.

Naissance du projet  

Les besoins du réseau Sudoc concernant l’intégration de ce type de notices ont été évalués par un sondage initié par Marie Nikichine (SCDI) via la liste de diffusion Code2bib : c’est Arte Campus qui arrivait en tête des abonnements.

A l’initiative de Régis Griesser, coordinateur Sudoc au SCDI, un workflow – permettant la création des notices en local puis leur chargement dans leur SGB Alma – avait déjà été mis en place.  Après discussion, il a été décidé de créer un flux d’import régulier afin de mutualiser le signalement de ces ressources par l’intégration de leurs notices descriptives dans le Sudoc.   

La transformation des métadonnées : de JSON à UNIMARC

Même si la plateforme Arte Campus ne propose pas d’export de notices aux formats UNIMARC ou MARC 21, elle met à disposition une API permettant la récupération des métadonnées au format JSON :   https://campus.arte.tv/api/list/programs 

Cette première partie du processus est gérée par l’équipe informatique du SCDI de Montpellier. Tout d’abord, un script PHP transforme les données des balises JSON en CSV. Les données sont ensuite converties manuellement en UNIMARC à l’aide de l’outil MarcEdit :  

Balises JSON   Zones UNIMARC 
ID 

 

001  

035 préfixé 035##$aArte_Campus_   

URL
856$u  

Avec une note B371 

371 0#$aAccès en ligne restreint soumis à abonnement  

Editorial 

Title 

Subtitle  

ShortDescription  

Description  

Note  

PublicationDate  

Subjects  

 

200 $a  

200 $e  

330 $a  

Balise vide non exploitable 

Balise non exploitée 

610 $a  

Indexation libre 

Technical 

Duration  

 

ProductionYear  

 

 

Nationality  

Languages  

Versions  

 

230 $aDurée : X minutes  

et 115 $a [sur trois positions]  

100 $a   

et 214 $dC   

(avec 214 #2 $aParis$cArte Campus)  

102 $a  

101 $a  

307 $a   

Staff 

Director 

 

 

 

Actors 

 

Producers 

Presenter 

 

200 $f   

700/701 avec $43   

Si collectivité 

710   

200 $g   

702 avec $4005  

306 $a[Mention de copyright]  

702 $4605  

Media 

Poster 

Trailers  

 

300 $u avec $a[Affiche] 

300 $u avec $a[Bande-annonce] 

Une fois ces opérations de mapping effectuées, un lot de notices au format UNIMARC est envoyé à l’Abes.  

Import et enrichissement des données   

Un catalogage adapté à ce type de ressource  

L’import dans le Sudoc de notices de vidéos en streaming constituant une première, les données ont été adaptées, en concertation avec les experts données de l’Abes, afin de les rendre conformes aux règles de description en vigueur.  

Exemple d’une notice après import

Zoom sur certaines zones   

  • B008 : le statut Oa permet l'identification des ressources électroniques avec un périmètre assez large.   
  • B115 : cette zone contient les données codées pour les images projetées, enregistrements vidéo et films.
  • B230 : durée de la vidéo.  
  • Traitement des épisodes/séries: certaines vidéos sont liées à des séries. Leur traitement est identique à celui effectué pour des monographies en plusieurs volumes, avec une description volume par volume.  Le titre propre de l’épisode est identifié en B200$a $e, tandis que le titre de la série à laquelle est rattachée l’épisode est reporté en 225/461 avec le numéro de l’épisode en $v.   
  • B608 : l’indexation « Webdocumentaires » a été ajoutée dans toutes les notices.   
  • B610 : l’indexation sujet présente dans les métadonnées du diffuseur est reportée ici (indexation libre).   
  • B859 : l’URL d’accès se trouve dans cette zone.    [Update : voir à ce sujet le premier commentaire sous le billet]

Import et enrichissement des notices  

  • B309: cette zone, que l’on retrouve dans certains flux d’imports automatiques, doit être supprimée une fois que les zones 7XX ont été vérifiées et corrigées le cas échéant.  
  • B371 : cette zone, insérée automatiquement par l’Abes,  précise les droits d’accès et d’utilisation.    
  • B7XX : comme il est d’usage pour les imports automatiques, le programme de liage aux autorités est lancé à la fin de chaque import afin d'intégrer les liens vers les notices d’autorité, lorsqu’elles existent.   

Et la suite ?  

L’Abes invite les membres du réseau qui s’exemplariseront sous ces notices à les améliorer. Pour sa part, le SCDI Montpellier va continuer à maintenir le corpus de notices (ajouts et retraits). Le réseau sera informé des mises à jour mensuelles par un message via les listes de diffusion.   

Pour toute demande à ce sujet, l’Abes se tient à disposition via le guichet AbesSTP › sudocpro › Alimentation du Sudoc par chargement.

Continuer la lectureNouvel import Sudoc : les notices des vidéos en streaming de la plateforme Arte Campus 

Abes et Mir@bel : retours sur le chantier d’attribution de n°ISSN pour les revues en accès libre

  • Auteur/autrice de la publication :
  • Post category:Non classé

Visuel Abes Mirabel ISSNDébut 2022,  en s’appuyant sur les données de la base Mir@bel et sur la Base de Connaissance BACON, un corpus d’environ 700 titres étrangers en libre accès ne possédant pas de n°ISSN électronique était identifié. Afin de remédier à ce constat, l’Abes a  lancé, à l’aide de l’application CIDEMIS  (Circuit dématérialisé des Demandes ISSN), un important chantier de demandes d’attribution de n°ISSN auprès du Centre International de l’ISSN et de son réseau, qui gère, au niveau international, l’identification et la description des ressources continues.

Ce chantier, qui vise à améliorer l’identification des ressources en libre accès, et éventuellement de leur généalogie, en demandant leur numérotation ISSN, concerne un large périmètre, soit 88 pays et 75 Centres Nationaux différents. Rappelons par ailleurs que l’inclusion de publications en libre accès dans les principaux répertoires mondiaux – tels que le DOAJ (« Directory of Open Access Journals« ) ou ROAD (répertoire des ressources scientifiques et universitaires en accès libre) – implique l’attribution d’un identifiant ISSN.

Continuer la lectureAbes et Mir@bel : retours sur le chantier d’attribution de n°ISSN pour les revues en accès libre

CERCLES : lancement d’un nouveau chantier sur le corpus Clinical Key

  • Auteur/autrice de la publication :
  • Post category:Sudoc
Crédit image : David_Stewart

En 2015, naissait le dispositif CERCLES (voir le billet) mis en place par l’Abes pour accompagner, aider et valoriser un établissement souhaitant s’investir sur l’enrichissement des données d’un corpus de documents spécifique. 

En septembre 2023, un nouveau corpus de ressources électroniques va bénéficier de ce dispositif : Clinical Key. Le chantier est pris en charge par le SCD de l’Université Paris-Est Créteil Val de Marne. 

 

Le corpus Clinical Key

Clinical Key accompagne les professionnels de santé et les étudiants en médecine, toutes spécialités confondues, en leur offrant l’accès aux dernières publications. La plateforme de l’éditeur Elevier Masson permet de faire des recherches sur le texte inétgral de revues et de monographies.
La collection « Student » contient des images, vidéos en ebooks en santé, dont les Référentiels des collèges, les atlas d’anatomie Gray et Netter et les traités EMC (Encyclopédie médico-chirurgicale).
La collection « Nursing », dédiée aux soins infirmiers, propose des ebooks  (Essentiels en IFSI, guides pratiques) et des revues, ainsi que les EMC Savoirs et Soins infirmiers.

Pourquoi le SCD de l’Université Paris-Est Créteil Val de Marne a-t-il choisi ce corpus ?
La responsable du chantier, Sylvia, nous répond :
« Clinicalkey était un des derniers bouquets francophones pas encore pris en charge, et c’est une ressource importante pour nos étudiants en médecine. Ils sont très demandeurs des manuels type « Collèges » proposés sur cette plateforme. Nous avons envie d’être réactives et de signaler les titres rapidement après leur publication en produisant des bonnes notices pour les partager avec le réseau ».

 

Continuer la lectureCERCLES : lancement d’un nouveau chantier sur le corpus Clinical Key
Aller au contenu principal