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

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

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

BACON : évolution des fichiers KBart dédiés aux revues

Pour répondre Logo Bacon carréaux demandes des utilisateurs de la base de connaissances BACON – qui souhaitaient, en particulier pour les fichiers relatifs à la presse,  une évolution de l’affichage du format des dates présentes dans les fichiers KBart des revues, les dates signalées dans les champs « date_first_issue_online » et « date_last_issue_online », jusqu’alors restreintes à l’année, seront désormais exposées au format AAAA-MM-JJ.

Précisons cependant que la présence des dates au format « jour, mois et année » dépendent des données renseignées par les fournisseurs. De fait, si seules les années sont spécifiées, l’équipe en charge de BACON ne complètera pas ces dates. Par défaut, si le jour et le mois ne sont pas indiqués, l’affichage des dates  sera construit sur le modèle : [AAAA]-01-01.

Cette modification sera effective pour les fichiers chargés dans la base à partir du 12 juin 2023. Pour les versions antérieures, les données exactes des jours et des mois ne sont pas récupérables.

Cette évolution est conforme à la recommandation KBart. Consulter :  https://groups.niso.org/higherlogic/ws/public/download/16900/RP-9-2014_KBART.pdf

Pour toute question, le guichet ABESstp BACON est à disposition : https://stp.abes.fr/node/3?origine=Bacon

Continuer la lectureBACON : évolution des fichiers KBart dédiés aux revues

IdRef : le projet ArchéoRef Alignements (ArchéoAl) est terminé

Depuis octobre 2020, l’Abes était partenaire du projet ArchéoRef Alignement – ArchéoAl  relatif aux notices d’autorité de sites archéologiques, projet financé par CollEx-Persée et porté par l’Institut français d’archéologie orientale du Caire (Ifao). Formellement terminé depuis fin 2022, le projet a fait l’objet d’un rapport scientifique publié courant mars 2023. Au printemps 2023, l’Abes a procédé au chargement des alignements PACTOLS dans IdRef.

Dans la continuité du projet ArchéoRef …

Entre 2014 et 2016, le réseau des Écoles Françaises à l’Étranger (EFE), l’Institut français d’archéologie orientale du Caire (Ifao), l’École française d’Athènes (EFA), l’École française de Rome (EFR), l’École française d’Extrême-Orient (EFEO) et la Casa de Velázquez (CVZ) ont mené un premier projet ayant abouti à l’enrichissement de 475 notices d’autorité IdRef décrivant des sites archéologiques. Il s’agissait principalement d’ajouter des coordonnées géographiques dans les notices afin de permettre la géolocalisation des sites.

Consulter les deux billets  publiés à ce sujet sur le blog Punktokomo : ici et ici

…en exploitant la méthodologie du projet RefDivinités

En 2019-2020, l’Abes a été sollicitée par la Bibliothèque interuniversitaire de la Sorbonne et FRANTIQ, Fédération et Ressources sur l’Antiquité (GDS 3378), dans le cadre d’un autre projet CollEx-Persée : RefDivinités. Il s’agissait de travailler sur des divinités et héros du monde méditerranéen antique, décrits à la fois dans IdRef et dans PACTOLS, thésaurus de référence pour les Sciences de l’Antiquité et l’Archéologie.  Ce travail d’enrichissement et d’alignement IdRef <-> PACTOLS a porté sur 663 notices de personnes physiques.

Consulter le billet Punktokomo qui retrace les étapes de ce projet

ArchéoAl : partenaires et finalités du projet

En 2020, sous la houlette de l’Ifao, les mêmes acteurs sont lauréats d’un nouvel appel à projet Collex-Persée : ArchéoAl commence. Le projet a été mené en deux phases :

  •  au sein de chaque école, collaboration entre chercheurs et professionnels de l’IST dans l’objectif d’améliorer les notices IdRef
  • recours à un personnel recruté sur financement Collex-Persée et hébergé par Bibracte afin d’aligner IdRef au thésaurus PACTOLS porté par FRANTIQ et, ainsi, l’ouvrir à d’autres référentiels.
Continuer la lectureIdRef : le projet ArchéoRef Alignements (ArchéoAl) est terminé

CERCLES : lancement d’un nouveau chantier sur le corpus Strada lex

image CERCLES
source : DIYCandy

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 2023, un nouveau corpus de ressources électroniques va bénéficier de ce dispositif : Strada lex. 

 

Le corpus Strada lex

Bien connue des établissements d’enseignement supérieur et universités à composante juridique, cette base de données donne accès à toute l’information juridique européenne.
Elle constitue un bon outil de veille (des actualités sont disponibles, ainsi que la jurisprudence) et une plateforme d’accès à des revues en texte intégral, aux codes et textes réglementaires ainsi qu’à un très grand nombre de monographies électroniques.
Déjà, en 2019, quatre établissements membres du réseau Sudoc, conscients de la nécessité de signaler finement ce corpus, s’étaient associés, de façon informelle, pour cataloguer un grand nombre d’ebooks. Ainsi, grâce à la volonté des SCD des universités de Rennes I (sa dénomination à l’époque), Lille, Paris II Panthéon Assas et Paris Dauphine, 400 notices d’ebooks avaient été créées dans le Sudoc. 

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