QualiMarc : comment se déroulent les tests de l’application par le groupe des testeurs ?

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

logo QualiMarcLe développement de l’application QualiMarc, outil en ligne pour évaluer la qualité des notices bibliographiques créées pour le Sudoc dans WinIBW, se déroule en méthode agile “Scrum”, sur le mode de la co-construction avec des établissements.

Cela signifie que les fonctionnalités sont testées, au fur et à mesure de leur développement, sans attendre la livraison d’une version beta de l’application terminée : dès qu’une fonctionnalité est créée, elle est déployée sur le serveur de test et les membres de l’équipe projet peuvent la tester immédiatement. En fonction de leurs retours, la fonctionnalité est acceptée ou retravaillée, jusqu’à sa validation finale. 

L’application se construit ainsi progressivement, dans un esprit de réactivité, avec la pleine implication des établissements co-concepteurs.
Leur rôle a été prépondérant pendant la phase de recueil des besoins, puis de spécifications des fonctionnalités (voir le billet précédent).
Il l’est encore davantage pendant toute la période de développements informatiques, qui a été découpée en 5 parties (5 “sprints”, selon le vocabulaire de la méthode Agile “Scrum”). 

À l’heure où le cinquième “sprint” vient de s’achever, et par conséquent à la veille de la mise en production de QualiMarc, en mars 2023, voici comment se sont déroulés ces tests, pour les établissements testeurs.

Composition de l’équipe des testeurs

Dans chaque établissement co-concepteur du projet, un agent assure le rôle de “coordinateur local du projet” et prend part aux réunions régulières avec l’Abes. C’est à lui qu’Aurélie Faivre, responsable fonctionnelle du projet (ou “Product Owner”, selon le vocabulaire de la méthode Agile “Scrum”), communique :

  • la liste des fonctionnalités à tester ;
  • la liste des règles à vérifier.

groupe des testeursChaque établissement co-concepteur a défini lui-même en amont ses modalités des tests, en fonction de ses moyens : la taille de l’équipe de testeurs variait entre 1 et 10 catalogueurs. Les testeurs sont des collègues volontaires, mais ils ont parfois été choisis par rapport à leurs expertise sur le calogage de documents spécifiques (le catalogage des cartes, des thèses ou des livres anciens). Comme il est plus motivant de tester en équipe plutôt qu’individuellement, les établissements ont privilégié, à chaque fois que cela était possible, des séances collectives.

 

Fréquence des tests

Chaque semaine, les testeurs disposaient de la liste des nouvelles fonctionnalités et règles à tester, accompagnée d’un jeu de PPN et/ou des consignes.
Les sessions de tests collectives étaient organisées environ tous les mois ; pour des questions d’emplois du temps chargés, il fût parfois difficile de réunir tout le monde plus fréquemment. 

Méthodologie des tests

À l’issue du premier “sprint” et dès que les tests purent commencer, une réunion a été proposée pour présenter le projet, l’outil  et s’accorder sur la méthodologie à appliquer. Cette méthodologie fut plus ou moins la même, dans chaque établissement co-concepteur :

  • réception des consignes de l’Abes sur les tests à réaliser ;
  • complétude d’un fichier collaboratif, contenant fonctionnalités à tester, PPN de tests à soumettre à l’application, et saisie des résultats de chaque testeur ;
  • réunion de débriefing régulières, en présentiel ou via un canal Zoom dédié, pour discuter en direct ;
  • remontée des résultats de test à l’Abes.

L’équipe de développeurs informatiques de l’Abes était soucieuse de recueillir rapidement et correctement les commentaires des testeurs : elle a mis en place un formulaire en ligne, de type “Envoyer un commentaire”, accessible en un clic, sans quitter l’interface de test.
Ainsi en lien direct avec les développeurs, chaque testeur pouvait signaler, dès son constat, un bug, une anomalie à corriger. 

Un formulaire pour faire remonter les résultats des tests en direct


À la DGD BAPSO de Grenoble, les tests de QualiMarc étaient aussi au programme des réunions du pôle Qualité et la Direction Générale a suivi l’avancée du projet.
À la Direction Générale Déléguée aux Bibliothèques et Musées de l’Université Paris Cité, le projet Qualimarc a été inscrit dans la feuille de route de la politique de signalement pour l’année 2022-2023.
Ainsi, à des degrés divers, la progression et les conclusions des tests ont été suivis au-delà de l’équipe, par les services de signalement et, parfois, les directions.

Déroulement d’une session de test

Les premiers tests ont concerné l’ergonomie de l’application : texte des intitulés, des hauts et pieds de page, emplacement des boutons, taille des blocs composants chaque page, recherche, tri et filtre des données, comportement de l’application selon le média utilisé (PC, ordinateur portable, tablette).
Ces premières phases ont permis aux testeurs de prendre en main l’interface et ses fonctionnalités de navigation.

Mais très vite, les tests ont concerné l’évaluation de la qualité des notices et donc les capacités de l’outil à repérer et décrire les erreurs. Pour alimenter ces tests, l’Abes devait créer :

  • les règles de repérage des erreurs et les conditions pour le déclenchement des messages, rédigées en language de programmation YAML.
  • la création et la mise à disposition, sur une base de test du Sudoc, de notices bibliographiques sciemment erronées.

Les testeurs devaient alors soumettre à QualiMarc ces notices erronées, afin de vérifier :

  • le déclenchement correct de chaque règle programmée pour déceler l’erreur ;
  • la clarté du message, ou de la consigne, qu’elle déclenche.

C’est dans cet ensemble de règles (près de 300) que réside la plus-value de l’outil : elles déterminent la pertinence de l’analyse proposée par QualiMarc, la cohérence de son diagnostic et l’intelligibilité de ses commentaires.

 

Le ressenti des testeurs

DGD BAPSO Grenoble : Nous avons beaucoup apprécié de tester l’outil en avant première et de participer aux remontées, même modestement… Cela nous a également permis de nous projeter sur son utilisation à la DGD BAPSO.
SD Université Claude Bernard Lyon 1 : nous avons toutes et tous hâte d’utiliser QualiMarc avec nos propres notices pour voir ce que ça donne !
DGDBM Université de Paris Cité : nous avons un outil similaire qui est utilisé dans le traitement courant des monographies papier. Les collègues qui avaient participé à la conception de VerifSudoc étaient très critiques (…).  L’implémentation des règles au goutte à goutte a été déroutante.  Et nous avons l’impression d’avoir davantage testé la pertinence des fonctionnalités que la pertinence des règles, qui est pourtant le noyau dur de l’outil.

L’équipe des testeurs 

L’Abes remercie chaleureusement les testeurs pour leur investissement et leur précieuse collaboration !

Logo DGD BAPSO de Grenoble Pascale Puget (coordinatrice locale du projet), Yvon Chevet et Lise de Baudouin (Correspondants Catalogage)
Logo Université Claude Bernard Lyon 1 Nuria Pastor Martinez, puis Marie-Hélène Bourrat (coordinatrices locales du projet), Denis Laurent, Céline Robert (coordinateurs Sudoc), Claire Dozier (Correspondante Catalogage), Audrey Bayle-Hinfray
Logo Caen Joséphine Masson (coordinatrice locale du projet), Marie-Christine Chauvat (correspondante autorité), Sandrine Holvas (pour les thèses), Carole Brier (pour les périodiques), Nicolas Cocman, Nicolas Blanpain et Tony Volla (pour les documents cartographiques), Jean-Baptiste Brier, Jocelyne Titon, Muriel Riochet et Lucie Bataille (pour le livre ancien) 
Logo Paris Cité Stéphanie Arneau (coordinatrice locale du projet), Victor Moisan (catalogueur et concepteur de VerifSudoc), Emilie Cosson (coordinatrice Sudoc), Daphnée Frafer, Dominique Devin-Gillouard, Annalisa Marraffino (correspondantes catalogage), Catalina Fournier (cheffe d’équipe catalogage), Laurent Cizeron (correspondant Autorité), Emma Banc, Thérèse Fournial, Sheela Soundiraradjane (catalogueuses)

 

L’équipe projet QualiMarc

Continuer la lectureQualiMarc : comment se déroulent les tests de l’application par le groupe des testeurs ?

Signalement dans Calames du corpus sous licence nationale « Archives du Parlement britannique » : Pas à pas vers l’EAD (2/2)

Du point de vue des processus de traitement de métadonnées de l’Abes, le cas des Archives du Parlement britannique constitue un cas inédit. La bonne manière de l’aborder n’allait pas de soi : pourrait-on réutiliser les méthodes et outils habituels ? Devrait-on imaginer une autre manière de faire ? Paradoxalement, comment traiter ce cas d’espèce tout en tirant des enseignements génériques pour dompter d’autres « ovnis documentaires » ?

Quelle méthode ? Passer par RDF ou rester en XML ?

L’Abes a une longue expérience d’intégration des métadonnées fournies par des éditeurs ou diffuseurs, en MARC ou en XML. Pour traiter les métadonnées obtenues dans le cadre des programmes d’acquisition ISTEX, CollEx-Persée et du Plan de soutien à l’édition scientifique française, l’Abes a conçu et développé un workflow, dont la pièce maîtresse est une base RDF. Habituellement, les métadonnées sont récupérées en XML, converties en RDF, chargées dans une base RDF, enrichies puis redistribuées vers le Sudoc, Bacon ou scienceplus.abes.fr.

Dans le cas de l’achat de ces archives numérisées, il a été décidé de ne pas suivre la voie RDF, mais plutôt d’emprunter un nouveau chemin, où les manipulations sont entièrement en XML, pour les raisons suivantes :

  • le traitement n’a qu’une sortie : il s’agit d’un format XML, en l’occurrence EAD. Le RDF serait un modèle/format pivot adéquat s’il fallait générer différentes sorties.
  • le format EAD de sortie possède une structure foncièrement hiérarchique, qui se prête mieux à une représentation en XML qu’en RDF (dont la vocation est d’exprimer des graphes).
  • le format EAD peut contenir du « contenu mixte », ie un élément XML ayant pour enfants à la fois un autre élément XML et directement du texte : <a>blabla <b>hum</b> blabla</a>. Essayer de modéliser du contenu mixte en RDF serait peu, voire absolument pas, efficient. Notons cependant que, dans ce projet,  l’EAD produit ne contient finalement pas de contenu mixte.
Continuer la lectureSignalement dans Calames du corpus sous licence nationale « Archives du Parlement britannique » : Pas à pas vers l’EAD (2/2)

Signalement dans Calames du corpus sous licence nationale « Archives du Parlement britannique » : Conception et sources pour la description du corpus (1/2)

Dans le cadre du programme d’acquisitions de ressources numériques sous licence nationale porté par le GIS CollEx-Persée, l’Abes a acquis le corpus des archives du Parlement britannique au XIXe siècle numérisées par ProQuest et choisi d’en assurer le signalement dans Calames

Des choix nécessaires pour une première

Le signalement dans Calames d’un corpus d’archives numérisées a posé des questions inédites, aussi bien d’un point de vue intellectuel que technique.

Il était en effet nécessaire de réfléchir au signalement en EAD d’archives numérisées, pour ce corpus mais également pour les suivants qui ne manqueront pas de se profiler, qu’il s’agisse de corpus acquis dans le même cadre ou de besoins spécifiques de la part d’établissements du réseau Calames, notamment dans le cadre de la collecte d’archives de projets de recherche, désormais objets de signalement.

Il a été décidé de décrire les archives dans leur version numérique, le fonds physique originel n’étant décrit qu’à un niveau élevé et général. Les données descriptives des archives originales se trouvent ainsi dans le fichier maître, plus haut niveau d’une arborescence EAD dans Calames, à titre d’informations générales pour contextualiser le corpus. Pour leur part, les niveaux inférieurs décrivent les archives numérisées.

Continuer la lectureSignalement dans Calames du corpus sous licence nationale « Archives du Parlement britannique » : Conception et sources pour la description du corpus (1/2)

QualiMarc : un outil en ligne pour évaluer la qualité des notices bibliographiques du Sudoc

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

La production de notices bibliographiques de qualité est une préoccupation constante de tous les contributeurs du catalogue collectif Sudoc ainsi que de l’Abes (Agence Bibliographique de l’Enseignement Supérieur), qui en administre les données.

Qu’entend-on par « qualité » ? Pourquoi la rechercher ?
Comme il s’agit d’une valeur subjective, il est difficile de définir la « bonne qualité » d’une notice bibliographique. Disons qu’il s’agit de l’addition de critères de cohérence (dans l’utilisation des zones du format Unimarc), de pertinence (dans le choix des éléments retenus pour déc rire une ressource) et d’exactitude (dans leur transcription).
Si cette qualité est souhaitée, c’est pour :
– satisfaire les besoins de recherche des utilisateurs des catalogues ;
– valoriser les ressources acquises par les bibliothèques ;
– améliorer le travail des catalogueurs  : suppression des doublons, désambiguïsation des données, meilleure identification des ressources ;
– mettre les notices en conformité avec le nouveau code de catalogage RDA-FR et préparer la Transition bibliographique ;
– faciliter l’exposition et la réutilisation des données dans d’autres environnements.

L’Agence, comme tête de réseau, s’efforce de placer chaque catalogueur en capacité de produire de telles notices, en édictant des consignes et en délivrant assistance et formations.
Chaque établissement, grâce à l’investissement de ses Correspondants Catalogage et Autorités, ainsi que de son Coordinateur Sudoc, accompagne et prolonge cet effort par de riches et multiples initiatives (“café catalogage”, formations spécifiques, chantiers-qualité, etc.).
Chaque catalogueur, avec sérieux et rigueur, essaie de respecter cet objectif de qualité qui fait la renommée du catalogue collectif des bibliothèques françaises de l’enseignement supérieur et de la recherche.

Pourtant, avec un code de catalogage en pleine transition et un format qui évolue, il devient impossible de connaître toutes les règles, même pour le plus passionné des catalogueurs. Et le manque de moyens alloué à l’activité de catalogage dans beaucoup d’établissements ne permet pas toujours de maintenir l’échelon d’expertise requis et le niveau de qualité souhaité. 

Pour continuer à se sentir reconnus, utiles, et donner du sens à leur travail, les catalogueurs rêvent alors d’un outil qui vérifierait, en un clic, la notice bibliographique créée et leur expliquerait ce qui peut être amélioré et pourquoi. Chacun continuerait ainsi à travailler à la qualité globale du catalogue, pour le bien commun et gagnerait en compétences professionnelles, pour son intérêt personnel.

Image Bienveillance

Un nouvel outil comme un tuteur bienveillant, un ami (catalogueur) qui nous veut du bien.

 

 

Continuer la lectureQualiMarc : un outil en ligne pour évaluer la qualité des notices bibliographiques du Sudoc

Les API de l’Abes disponibles au format OpenAPI sur api.gouv.fr

Depuis sa création, l’Abes développe une gamme d’applications destinées à la production, au traitement et à l’administration des données par les réseaux documentaires de l’ESR. Dès 2010, dans le cadre d’une politique volontariste en faveur de l’ouverture et de l’interopérabilité des données, une nouvelle catégorie de services s’est déployée pour une plus large réutilisation des données par les systèmes d’information :  une gamme de web services a ainsi  été mise progressivement à la libre disposition des professionnels de la documentation et des développeurs afin de faciliter l’extraction et la réutilisation des données en provenance des différentes bases gérées par l’Abes : Sudoc, Calames, IdRef, BACON, Theses.fr, STAR, STEP…

Jusqu’à présent, les web services de l’Abes étaient accompagnés de documentation sous forme de pages HTML, comme par exemple : http://documentation.abes.fr/sudoc/manuels/administration/aidewebservices/index.html.

Cependant, avec une quarantaine de web services disponibles aujourd’hui,  il devenait important d’harmoniser leur présentation, d’optimiser leur exposition et d’affiner leur documentation. Pour ce faire, en conformité avec sa politique de développement,  l’Abes a décidé de décrire ses API avec le standard OpenAPI : https://github.com/abes-esr/abes-politique-developpement/blob/main/08-Documentation.md

A noter : Le vocabulaire et les socles informatiques ayant considérablement évolué depuis 2010, on regroupe désormais ces ensembles de web services sous l’appellation générique d’API – Interface de Programmation Applicative, solution informatique permettant à des applications de communiquer entre elles et de s’échanger mutuellement des données.

Les API de l’Abes en OpenAPI

En 2010, la startup Swagger initiait un projet, devenu populaire au fil des années, qui permettait aux développeurs de définir et documenter des API en y incluant le code source. En 2016, des géants du secteur (Google, Microsoft, etc.) rejoignent l’initiative pour la faire évoluer. La spécification Swagger, alors renommée Spécification  OpenAPI définit, pour les API les plus courantes (de type REST / HTTP), un standard utilisé par les humains comme par les machines.

Lors du développement d’une nouvelle application, il est assez simple de produire la documentation de son API en OpenAPI, à l’aide de librairies logicielles, telles que SpringDoc. En effet, il suffit d’inclure ce type de librairie dans les dépendances de la nouvelle application, et d’utiliser les annotations adéquates, pour que la documentation soit automatiquement générée. Ainsi, les nouveaux web services développés par l’Abes – et bientôt utilisés par l’outil de curation paprika.idref.fr, intègrent une documentation OpenAPI :

En revanche,  cette transformation s’avère plus compliquée pour les API plus anciennes : celles-ci n’utilisant pas forcément de framework  (de type Spring), il n’y a pas de moyen automatique et simple pour produire la documentation OpenAPI. L’effort de rédaction étant plus conséquent, il a été décidé de documenter en priorité les web services les plus utilisés.  Cette démarche s’appuie sur l’éditeur d’OpenAPI, Stoplight, outil gratuit pour la conception de documentation OpenAPI « à la main », via des formulaires qui aident et contrôlent la saisie. Ces documentations sont ensuite versionnées sur un espace Github dédié : https://github.com/abes-esr/openapi

Publication des OpenAPI de l’Abes sur api.gouv.fr

Pour publier les OpenAPI, le choix du site api.gouv.fr  s’est naturellement imposé, le site référençant les API du service public (collectivités, ministères, entreprises…) pour construire des services informatiques pour tous. De plus, les fonctionnalités disponibles facilitent largement l’usage et l’accès aux web services concernés.

Lors du chargement des OpenAPI sur api.gouv.fr,  un formulaire interactif est généré. Celui-ci liste les web services composant l’API et fournit, lorsque c’est pertinent, les liens vers la documentation HTML. Il est facile de saisir rapidement la structure et le fonctionnement de chacune des API, chaque paramètre possédant également sa description et une valeur exemple. Lorsque c’est nécessaire, une expression régulière donne le format attendu. A l’aide de ce formulaire, il est même possible de tester directement un appel au web service.

Retrouver les API mises à disposition sur api.gouv.fr :

 

Continuer la lectureLes API de l’Abes disponibles au format OpenAPI sur api.gouv.fr

Apache Kafka : une nouvelle brique logicielle pour le Système d’Information de l’Abes

Afin de faire face au volume croissant d’informations qu’engendre l’évolution constante des métiers et des technologies, l’Abes relève de nombreux défis. L’un d’entre eux consiste dans le besoin de gérer les flux de grandes quantités de données entre diverses applications, de manière fiable et en temps réel.

Pour y répondre, le Service Urbanisation et Pilotage Informatique (SUPI) a mis en place un démonstrateur basé sur la solution Apache Kafka, solution informatique également utilisée par des collègues de la communauté de la documentation et en particulier par Swissbib et par l’INA avec qui l’Abes a échangé à plusieurs reprises.

Kafka : définition

Bien connu dans le monde de l’informatique, Kafka fait partie de la famille des bus de messages. A noter que dans cette famille, nous retrouvons les outils suivants, chacun ayant quelques nuances : RabbitMQ, ApacheMQ, ZeroMQ, Redis.

Continuer la lectureApache Kafka : une nouvelle brique logicielle pour le Système d’Information de l’Abes

IdRef : chantier qualité autour des notices d’autorité Personnes physiques de statut 1

Logo Chantier Qualité IdRefL’Abes sollicite la participation des Correspondants Autorités pour enrichir des notices d’autorités beaucoup trop succintes,

Le problème et la finalité du chantier

Le chantier concerne des notices de personnes physiques Tp1, issues de chargements de notices élémentaires d’origine BnF faits il y a quelques années. Le plus souvent, elles sont réduites à un point d’accès, sans données codées, sans mention de source, liées à peu de notices bibliographiques (voire mal liées).

Notice exemple
Notice PPN 057140057 en format professionnel, sans données codées, ni 340, ni 810.

 

L’existence de ces notices d’autorité pauvres est un problème pour la qualité globale du catalogue :
– elles génèrent du bruit pour le catalogueur qui souvent, faute d’élément discriminant, ne les traite pas ;
– elles perturbent le fonctionnement des programmes automatisés, notamment d’alignement, que l’Abes a développé depuis quelques années.
L’Abes souhaite aboutir à la disparition de ces notices au profit de notices enrichies et fiabilisées, basculées en statut 5 pour acter ces améliorations.
La finalité du chantier est de faire disparaitre le statut 1 dans les notices d’autorité Personnes physiques.

Continuer la lectureIdRef : chantier qualité autour des notices d’autorité Personnes physiques de statut 1

« Épatant : ça nous bouge ! » : les ressources continues, en direct de la BnF et d’ISSN France

Épatant : ça nous bouge !

Tel est le titre de la première notice en provenance d’ISSN France importée directement dans le Sudoc (PPN 260627062 ; ISSN 2804-715X). En l’occurrence, il s’agit d’un site web, occasion de rappeler que les ressources continues ne se limitent pas aux publications en série et aux collections, mais incluent aussi les « ressources intégratrices », c’est-à-dire des ressources dont le contenu peut être augmenté ou modifié par des mises à jour.

Cette intégration directe constitue une évolution fondamentale, la première de cette importance depuis la mise en place du Catalogue collectif national des publications en série (CCN-PS), ancêtre du Sudoc en matière de signalement et de localisation des ressources continues dans les bibliothèques françaises.

copie de la notice dans winibwi
Copie de la notice dans WinIBW : on remarque le lien vers le site, mais aussi vers sa version archivée via Internet Archive. A noter : la notice ne sera disponible dans le Sudoc public qu’une fois « localisée ».

Continuer la lecture« Épatant : ça nous bouge ! » : les ressources continues, en direct de la BnF et d’ISSN France

L’association KohaLa et l’Abes : une coopération sous le signe de la qualité des données

KohaLa est une association professionnelle francophone qui a pour objet le développement, la documentation, la protection, la promotion, et la diffusion du logiciel libre de gestion de bibliothèque Koha. Elle regroupe des utilisateurs et des développeurs et organise plusieurs événements afin de favoriser les partages d’expérience et de participer à l’évolution de Koha.

Lors de l’assemblée générale 2020 de l’association, nos adhérents membres du réseau Sudoc ont émis le souhait de voir KohaLa collaborer avec l’Abes pour réfléchir aux évolutions possibles dans les échanges entre Koha et les outils de l’Abes. Nous avons donc contacté l’Abes pour faire part de notre souhait de travailler ensemble selon des modalités à définir.

Les webservices de l’Abes à la rescousse

Au printemps 2021, KohaLa s’est lancé dans l’organisation d’un hackaton dont l’une des thématiques était l’amélioration des échanges entre Koha et l’Abes. Des bibliothécaires (dont des correspondants Sudoc) et prestataires Koha ont participé ainsi que des collègues de l’Abes. Les discussions se sont orientées vers l’exploitation possible des webservices mis à disposition par l’Abes et sur la question de l’usage qui pourrait en être fait dans Koha. Un besoin partagé est apparu : avoir un contrôle qualité de son catalogue et par là même du catalogue Sudoc.

Continuer la lectureL’association KohaLa et l’Abes : une coopération sous le signe de la qualité des données

IdRef : chantier qualité autour des notices d’autorité Collectivités pour les besoins de Mir@bel

Logo Chantier Qualité IdRef

 

L’Abes et le réseau Mir@bel s’associent pour améliorer, avec l’aide des professionnels des réseaux Sudoc et Sudoc-PS, le signalement et les métadonnées descriptives des ressources continues publiées par l’édition scientifique française.

Le contexte du chantier

L’Abes est partenaire du réseau Mir@bel dans le projet MIRABEL2022 : « Favoriser la circulation ouverte des données d’identification et de référencement des revues et éditeurs scientifiques français et leur donner une visibilité internationale (DOAJ, Sherpa/Romeo) grâce à la coopération des acteurs impliqués dans l’écosystème de l’édition », financé par le Fonds national pour la science ouverte (FNSO) pour la publication et l’édition scientifiques ouvertes.

Pour l’Abes, l’objectif du projet est d’améliorer le taux de liage entre IdRef et les données éditeurs de Mir@bel, taux qui s’élève actuellement à environ 70% pour les éditeurs français, de façon à obtenir une couverture complète pour le corpus considéré.

Continuer la lectureIdRef : chantier qualité autour des notices d’autorité Collectivités pour les besoins de Mir@bel
Aller au contenu principal