Comment favoriser la co-construction d’applications au sein des réseaux de l’Abes ?

            Crédits Pixabay

Lors des Journées Abes 2019, la session parallèle  “Comment faciliter la co-construction d’applications au sein des réseaux de l’Abes ?” a donné l’occasion de présenter deux retours d’expériences :

  1. L’équipe ezPAARSE a montré comment les principes de contribution au logiciel libre ont été exploités lors de la co-construction d’ezPAARSE – logiciel destiné à l’analyse des logs d’accès aux ressources électroniques des bibliothèques – avec la communauté de l’enseignement supérieur et de la recherche, et au-delà. – voir la présentation

  2. L’équipe de « bibliothécaires-système » de la BU Vauban – Université catholique de Lille a souhaité partager ses développements autour d’ezLibrAPI, plateforme qui met à disposition des outils bibliographiques reposant, entre autres, sur les web services de l’Abes – voir la présentationvoir le poster

Par ailleurs, cette session était l’occasion de présenter les  principaux éléments de la nouvelle politique informatique ouverte de l’Abes et de recueillir les besoins et idées des membres des réseaux Abes afin de faciliter la co-construction d’applications – voir la présentation

La première proposition de l’Abes concerne l’ouverture des codes sources des réalisations de l’Abes et des établissements. Les échanges avec la salle ont confirmé la pertinence de cette proposition.

Voici la synthèse des besoins et idées recensés à l’occasion de cette session. Notons que, pour favoriser les interactions dynamiques avec la salle (environ 100 personnes),  l’outil Mentimeter a été utilisé.

Première question  : Quels outils pour exprimer et recenser les besoins ?

Réponse : un kanban des projets Abes ouvert aux utilisateurs constitue l’outil qui ressort en premier pour exprimer et recenser les besoins. En seconde position, arrivent ex aequo l’utilisation des tickets via GitHub et les Journées Abes.

A noter : à travers sa fonctionnalité « project boards », GitHub propose la fonctionnalité de tableau kanban. Le couplage « tickets GitHub » – nommés « issues » dans la terminologie GitHub – et « project board » permettrait de donner une première réponse concrète pour recenser des besoins.

Nous remarquons également que les Journées Abes sont un espace privilégié pour des discussions directes avec les acteurs concernés.

Seconde question  : Quels développements voudriez-vous partager ?

Voici la liste complète (dans le désordre) obtenue lors de la session :

  • EzLibrAPI
  • NumaHop
  • BiblioTouch
  • Lama+
  • Holdings
  • Délocalisation
  • Adria
  • BiblioLabs
  • Mir@bel
  • Contrôle qualité des notices, évolutif en fonction des évolutions des formats et de la transition bibliographique
  • Script de contrôle de la qualité des notices
  • Récupération des indices Dewey via classify.org
  • IdRef vers IdHAL
  • Connecteurs EndPoint SparQL
  • Scripts Koha
  • Gestion d’un cadre Dewey
  • Gestion d’exemplaires par application mobile
  • API SGBm

On peut se réjouir du grand nombre de développements déjà proposés lors de cette session ! Les participants sont invités à nous écrire pour préciser et échanger sur les modalités pratiques d’un partage du code via https://github.com/abes-esr

Troisième question :  Quels moyens pour communiquer sur les réalisations ?
Les outils de type blog, Twitter et Github ressortent parmi d’autres propositions.

En tant que blog utilisé par l’Abes pour communiquer au sujet des réalisations d’un point de vue technique / informatique, Punktokomo est déjà ouvert aux contributions des établissements des réseaux. Ce moyen de communication pourrait être avantageusement systématisé et devenir un réflexe pour les établissements souhaitant présenter leurs réalisations.

Par ailleurs, rappelons que l’Abes met progressivement en place les méthodes Agiles pour faciliter les développements des applications. Dans ce cadre, les revues de sprints  constituent des opportunités pour faciliter la co-construction d’applications. Ce sont des moments privilégiés où des utilisateurs au sein des réseaux de l’Abes pourraient être invités pour assister à des démonstrations et apporter leurs retours sur les applications pendant les phases de développement. Ce type d’interactions permettrait une prise en compte plus rapide des retours utilisateurs mais également une meilleure appréhension des besoins du terrain par les équipes Abes.

A la dernière question ouverte : Aurions-nous oublié quelque chose ? – on relève les propositions suivantes :

  • L’Abes comme fournisseur de plateforme d’hébergement d’applications développées par le réseau
  • Avenir du protocole PICA utilisé par CBS ?
  • Serveur SRU et WinIBW
  • Webinaires techniques
  • Mènerez-vous une réflexion sur la pérennisation de tous ces développements ? Comment survivre au départ d’un développeur ?

Voici quelques éléments de réponses et précisions :

  • la mise en service d’une plateforme d’hébergement et la pérennisation des développements sont des questions complexes qui nécessitent des réflexions plus poussées
  • l’Abes n’est pas en capacité de répondre à la question concernant l’avenir de PICA (protocole utilisé par CBS) : il s’agit justement de l’objet d’études sur le futur des flux dans le SI de l’Abes, présenté par ailleurs lors des Journées Abes – voir la présentation – voir la vidéo.
  • les propositions ou besoins concernant SRU et WinIBW seront à préciser 
  • l’idée de webinaires techniques s’inscrit dans une proposition qui sera prochainement mise en œuvre dans le cadre des J.e-cours.

Nous remercions encore les participants à cette session parallèle très riche et comptons sur les « bibliothécaires système » des réseaux pour co-construire les applications de demain mais aussi pour « co-construire la meilleure manière de co-construire » !

Continuer la lecture

Une politique informatique ouverte pour l’Abes

En ce mois de juin 2019, le schéma directeur informatique est en cours de définition à l’Abes. Venant en soutien au projet d’établissement 2018-2022, ce schéma, entre autre thèmes abordés, promeut l’ouverture des codes sources des applications développées pour les réseaux de l’Abes. Voici les principaux gains attendus  :

  • faciliter les échanges et les partages
  • faciliter les innovations collaboratives qui peuvent se traduire par la co-construction d’applications au sein des réseaux de l’Abes
  • améliorer la qualité et la sécurité logicielle par la transparence
  • valoriser les réalisations techniques

Un Git Hub pour l’Abes et les établissements

L’Abes décide d’ouvrir les codes sources de toutes les applications qu’elle développera à partir de maintenant pour les réseaux de l’Abes. Ces codes sont et seront versés sur la très populaire plateforme GitHub pour en maximiser la visibilité et faciliter la collaboration. L’organisation Github se nomme « abes-esr », elle est accessible ici :

https://github.com/abes-esr/

Continuer la lecture

Vers un nouveau workflow d’imports de données dans le Sudoc : les notices des ouvrages publiés par Oxford University Press


[English abstract at the bottom of this blog’s post]D’un point de vue technique, charger des corpus de livres dans le Sudoc n’est pas très difficile. Depuis plusieurs années, les équipes de l’Abes importent régulièrement des ensembles de notices MARC en provenance de différents éditeurs (Springer, CAIRN …) et, globalement, ces notices sont bien utilisées par les bibliothèques du réseau.

Pourquoi un nouveau workflow d’imports de données dans le Sudoc ?

Pour autant, on a pu constater que ce système comporte des limites : en amont, il n’est pas toujours évident de récupérer auprès des éditeurs des notices MARC – si possible de bonne qualité, cette démarche exigeant généralement de nombreux aller-retours. En aval, ce type d’opérations de chargement dans le Sudoc requiert des interventions et compétences spécifiques, relativement rares à l’Abes. Autant d’éléments qui rendent les processus actuels difficilement scalables et difficile aussi l’atteinte de l’objectif de signalement total. Aussi, il s’est avéré indispensable de réfléchir  à la conception de nouveaux  workflows,  afin de réaliser automatiquement les opérations d’ingestion,  transformation, enrichissements et chargement dans le Sudoc.

Continuer la lecture

Récit d’une immersion. Traiter les ebooks Dalloz avec les données Sudoc, les données de l’éditeur et les outils du hub


Ce billet relate à la première personne l’immersion effectuée par Catherine Storne (Université de Strasbourg) au sein de l’équipe hub de l’ABES, entre le 1er et le 5 février 2016. Catherine a eu l’occasion de partager cette expérience aux dernières journées ABES. Merci pour tout, Catherine !

Placée en face de la nouvelle « Metadaten Weltanschauung » au travers de la réflexion locale sur l’abonnement à un outil de découverte (discovery tool) ou sur les réalisations de la plateforme ISTEX sur les licences nationales, je ressentais le besoin de monter en compétences sur la manipulation des métadonnées. J’ai donc souhaité faire une immersion à l’ABES pour mieux comprendre les projets de l’établissement tournant autour des métadonnées dont les noms parvenaient aux confins de nos bibliothèques : BACON, hub de métadonnées, CERCLES, ainsi que les liens entre eux. Mon objectif étant de travailler au rapprochement, au sein du SCD de Strasbourg, des équipes de la documentation électronique et du catalogage, la participation à un projet concret, au travers d’un chantier CERCLES me semblait de nature à y contribuer.

Continuer la lecture

Mettre nos données en réseau – un démonstrateur. [1] Introduction.


Ce démonstrateur est un plaidoyer en faveur d’une approche “web sémantique” de l’interopérabilité des données de l’IST. Mais, cette fois, il s’agit de montrer et non d’argumenter. Il s’agit de défendre, en illustrant cette approche par des études de cas. Alors, si vous fuyez les plaidoyers, si vous exigez du concret, de la donnée (RDF), de la requête (SPARQL), passez cette introduction et lisez l’un des billets suivants :

  1. Introduction (ce billet)
  2. Inventaire des données
  3. Suivez le guide ! Le modèle de données
  4. Études de cas

SPARQL endpoint : https://lod.abes.fr/sparql
Interface de recherche full text et de navigation : https://lod.abes.fr/fct

Continuer la lecture

Mettre nos données en réseau – un démonstrateur. [2] Inventaire des données.


[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

Pour les besoins de la démonstration, nous avons agrégé des données diverses et variées, mais finalement cette auberge espagnole n’est pas si anarchique : tout mène à tout, et on peut regrouper les jeux de données de différentes manières :

  • Données descriptives vs Référentiels
  • Données produites par les réseaux ABES vs Données de tiers
  • Données du monde des bibliothèques vs Données d’autres mondes (science, administration, etc.)
  • Données récupérées en RDF vs Données produites en RDF

Mais dans ABES, il y a B : notre réseau de données se déploie autour des données bibliographiques, qui décrivent des livres, des revues, mais également des chapitres et des articles.

Continuer la lecture

Le SUDOC en RDF : du nouveau ! 1/2


A propos du  web de données, et du Sudoc en RDF, voir notamment les billets précédents ici et .

L’été 2013 avait vu la mise en ligne d’une documentation sur l’exposition du SUDOC en RDF, et l’annonce d’un chantier visant à enrichir et affiner progressivement celle-ci. Ce chantier a produit ses premiers résultats au cours de l’année universitaire écoulée, par petites touches successives. Zoom sur les nouveautés.

Alignements

Dans un souci d’interopérabilité avec Data.bnf.fr, le FRBNF des notices BNF a été ajouté, à côté des OCN d’OCLC déjà présents : onto-bnf :FRBNF (propriété maintenue par la BnF elle-même). Les identifiants ark – présents dans une partie des notices du Sudoc, devraient suivre un peu plus tard.

Continuer la lecture

Un serveur SPARQL pour le Sudoc


Depuis juillet 2011, l’ensemble des données Sudoc est accessible en RDF. Si on connaît son identifiant, chacune des dix millions de notices du Sudoc peut être affichée en RDF/XML. Mais encore faut-il connaître cet identifiant… Ce dispositif est utile pour permettre à un programme de naviguer de notice en notice, y compris en rebondissant sur les données RDF d’IdRef par exemple, mais cela ne permet pas d’explorer systématiquement le Sudoc ni d’effectuer une recherche.

Continuer la lecture

IdRef dans VIAF et après … #2 Faciliter et améliorer le catalogage par dérivation


Ce post de fil.abes.fr annonce l’intégration du référentiel IdRef à VIAF et en présente les enjeux stratégiques. Punktokomo prend le relais pour détailler quelques implications pratiques. En voici la deuxième.

Grâce à MARC et Z39.50, le catalogage est d’ores et déjà une pratique professionnelle locale qui fonctionne dans un cadre global. L’idéal visé est le suivant : pour chaque livre, sa notice bibliographique est créée une fois, par quelqu’un, quelque part, puis échangée, reprise, exemplarisée autant de fois que nécessaire, partout, par tous.

Dans le cadre du Sudoc, plutôt que de créer ex nihilo une notice qui manque, le catalogueur interroge d’autres catalogues à la recherche de cette notice. S’il la trouve, il la récupère dans l’outil de catalogage du Sudoc et l’intègre telle quelle, … à beaucoup de détails près… C’est ce qu’on appelle du catalogage par dérivation. En voici un tutoriel, propre au contexte du Sudoc :

Continuer la lecture

IdRef dans VIAF et après … #1 Passer d’un identifiant à l’autre (VIAF, IdRef, LC, BnF, Wikipedia, …)


Ce post de fil.abes.fr annonce l’intégration du référentiel IdRef à VIAF et en présente les enjeux stratégiques. Punktokomo prend le relais pour détailler quelques implications pratiques. En voici la première.

Tout l’intérêt de VIAF repose dans son travail d’interconnexion entre des notices d’autorité d’origines différentes. En effet, les algorithmes de VIAF cherchent à identifier toutes les notices d’autorité qui « parlent’ de la même chose, qu’il s’agisse d’une personne, d’une collectivité ou d’une oeuvre. Ils génèrent alors des grappes (clusters) d’autorités. Ces grappes VIAF possèdent elles-même un identifiant unique, en bijection avec chacun des identifiants des autorités membres de la grappe.

Continuer la lecture