KaliDoS, un outil de vérification des règles de catalogage bibliographique – partie 2

Ce billet est le second d’une série de deux :
1. la partie 1 détaille la modélisation des règles de vérification
2. la partie 2 détaille l’architecture de l’application et ses interfaces

Afin d’améliorer la qualité de son catalogue et de rendre le contrôle qualité des notices bibliographiques plus efficace, le SCD de l’UCBL a souhaité se doter d’un outil de diagnostic, KaliDoS (Qualité des Données du Sudoc). Après une présentation sur la modélisation des règles, nous décrivons dans ce second billet l’architecture de KaliDoS ainsi que les fonctionnalités et les interfaces de l’application.

Architecture de KaliDoS

L’application suit une architecture client-serveur : sur la figure suivante, le serveur stocke les jeux de règles et les résultats dans des fichiers JSON. En plus de la présentation des interfaces, le côté client est en charge d’exécuter le contrôle qualité, après avoir récupéré les notices auprès de deux fournisseurs (IdRef et Sudoc) ainsi que le jeu de règles depuis le serveur. La dockerisation facilite le déploiement de l’application ainsi que son redémarrage en cas d’arrêt critique.

Architecture de KaliDoS

Fonctionnalités et interfaces de KaliDoS

L’application KaliDoS a été développée avec le souci de proposer une interface la plus épurée mais aussi la plus ergonomique possible. Elle est notamment responsive design afin de s’adapter aux différents dispositifs et permet d’exécuter l’ensemble des règles, d’afficher les résultats et offre l’accès à un éditeur de règles.

Quatre interfaces la composent :

Saisie des identifiants

Cette interface permet la saisie d’un ou plusieurs PPN à contrôler, soit par copier-coller, soit en glissant un fichier txt. Avant de lancer la vérification, un menu déroulant propose de choisir le type de règles à appliquer aux notices selon le type de document qu’elles décrivent (voir la partie 1). Les contrôles s’effectuent par une interrogation de la base XML du Sudoc et d’IdRef pour les zones qui attendent un lien vers des autorités (mentions de responsabilité et sujets).
L’interface offre des temps de réponse très courts (500 notices sont analysées en moins d’une minute). En revanche, elle rend complexes, voire impossibles, certains contrôles du fait des différences entre le format de production dans le Sudoc et le format d’export XML, et surtout par l’absence de certaines données.

Interface de saisie des identifiants
Interface de saisie des identifiants

 

Interface de vérification

Lorsque l’utilisateur lance un contrôle, il bascule sur l’interface de vérification. Les résultats s’affichent au fur et à mesure de l’analyse et une jauge permet de suivre le pourcentage de notices contrôlées.
Une fois le contrôle terminé, celle-ci est remplacée par un résumé du nombre de PPN testés et du nombre d’erreurs identifiées. La liste de notices comportant des erreurs s’affiche à gauche de l’écran (n° PPN et nombre d’erreurs) et il est possible de cliquer sur chacune des notices pour afficher, à sa droite, le détail des erreurs détectées.
Un export Excel de ces résultats est également possible pour une analyse globale.

Interface de vérification
Interface de vérification

 

Interface des règles

La véritable plus-value de KaliDoS réside dans son éditeur de règles, résultat d’un travail de modélisation. Celui-ci permet d’afficher, de tester et de modifier les règles existantes mais également d’en créer de nouvelles sans avoir de compétences en informatique. Avec les évolutions permanentes des règles et des consignes de catalogage dans le cadre de la Transition bibliographique, cette fonctionnalité s’est révélée essentielle afin de garantir la mise à jour des règles.

Interface des règles
Interface des règles

 

Par défaut, toutes les règles s’affichent dans cette interface mais un champ de recherche permet d’affiner l’affichage à partir d’une zone UNIMARC (par exemple, tous les contrôles qui interviennent sur la zone de la collation B215) ou d’un mot clé (par exemple, « rameau » affichera les contrôles sur les zones B6XX avec une sous-zone $2rameau).
Pour l’ajout d’une nouvelle règle, l’utilisateur doit choisir parmi les différents types de règles. Enfin, une aide dynamique explique simplement comment doivent être remplis les différents champs de chaque règle.

Fonctionnalité d'ajout de règle
Fonctionnalité d’ajout de règle

Historique

Il est possible de retrouver l’ensemble de contrôles effectués. Chacun d’eux peut être relancé, par exemple après la correction des notices erronées, ou supprimé de l’historique.

Interface "Historique"
Interface « Historique »

 

Conclusion et perspectives

L’application KaliDoS répond aux enjeux prévus au départ. Elle est utilisée régulièrement au SCD de l’UCBL depuis février 2021 pour l’identification des notices à corriger mais aussi pour les besoins en formation lorsque des erreurs sont récurrentes. Son éditeur de règles offre à l’application une réelle évolutivité. Il pourrait aussi permettre à un autre établissement d’adapter les règles à ses besoins, ceci d’autant plus que le code est disponible sous licence libre : https://github.com/abes-esr/kalidos

En dehors des aspects fonctionnels, ce projet a également permis une collaboration enrichissante entre deux services de l’Université et ses étudiants, ce qui n’est malheureusement pas très fréquent. Il a également ouvert la porte à une collaboration avec l’Abes puisque, face au développement de différents outils au sein des établissements du réseau et au besoin croissant des catalogueurs de disposer d’un outil fiable et conforme aux évolutions des règles de catalogage RDA-FR, l’Agence s’est engagée dans le développement d’un outil unique de contrôle bibliographique qui permettra l’accompagnement des catalogueurs du réseau.

 

Logo Université Claude Bernard Lyon 1 Nuria Pastor Martinez, responsable du Pôle Données et Signalement (SCD de l’UCBL)

Fabien Duchateau, enseignant-chercheur (UCBL et laboratoire LIRIS)

 

Continuer la lectureKaliDoS, un outil de vérification des règles de catalogage bibliographique – partie 2

KaliDoS, un outil de vérification des règles de catalogage bibliographique – partie 1

Ce billet est le premier d’une série de deux articles :
1. la partie 1 détaille la modélisation des règles de vérification
2. la partie 2 détaille l’architecture de l’application et ses interfaces

Chaque année, l’Université Claude Bernard Lyon 1 (UCBL) signale, en moyenne, 23 000 nouveaux titres dans le Sudoc, dont environ 5 000 qui nécessitent la création d’une notice bibliographique et sont, pour la plupart, des ‘unicas’ (documents possédés uniquement par le SCD de l’UCBL, par exemple des thèses, des mémoires, des fonds anciens numérisés).
La qualité de ces notices bibliographiques est primordiale pour garantir l’accès aux ressources. Pourtant, peu d’applications existent pour faciliter le contrôle qualité. De plus, elles sont non exhaustives voire obsolètes du fait de l’évolution des règles de catalogage.
En collaboration avec le SCD, un groupe de six étudiant.e.s du Master 2 « Technologies de l’information et du web » de l’UCBL a donc été chargé de développer une application, nommée KaliDoS (Qualité des Données du Sudoc), permettant de détecter, parmi un lot de notices, celles qui ne respectent pas un ensemble de règles.
La modélisation des règles à appliquer pour valider (ou non) les notices constituait un des enjeux majeurs de ce projet.

Modèles de règles

L’un des défis pour l’implémentation de KaliDoS réside dans la gestion des règles, que ce soit pour leur représentation ou leur utilisation. Différents types de règles ont été identifiés. Cette catégorisation permet de rendre générique la définition de ces règles, et donc d’en ajouter plus facilement.

Voici un aperçu de ces catégories :

Catégorie Définition
Comptage Vérifie que le nombre de sous-zones d’une zone soit égal au nombre de sous-zones d’une autre zone.
Exemple : plusieurs sous-zones 101$d nécessitent autant de sous-zones 330$a
Dépendance Compare la valeur de deux zones contenues dans un même PPN.
Exemple : les 4 premiers caractères de la sous-zone 029$b doivent être égaux ceux de la sous-zone 328$d
Les opérateurs de comparaison sont l’égalité, l’inégalité et les relations inférieure et supérieure (strictes ou non).
IdRef Vérifie si une zone soumise à autorité est valide en interrogeant un référentiel externe.
Exemple : une notice contenant une sous-zone 606$2 avec la valeur « rameau » indique qu’il faut vérifier si le PPN enregistré en sous-zone 606$3 renvoie bien sûr une autorité Rameau, via l’analyse de sa zone de contrôle 008
Matching Vérifie si la valeur d’une sous-zone correspond à une expression régulière.
Exemple : la sous-zone 339$d ne doit pas contenir « Année de mise en ligne »
Ordonnancement Vérifie qu’une liste de zones possédant le même tag soit triée par indicateur.
Exemple : s’il y a plusieurs zones 214, elles doivent être ordonnées selon l’indicateur « ind2 »
Précédence Vérifie, au sein d’une zone, qu’une sous-zone est bien précédée par une autre.
Exemple : une sous-zone 608$2rameau doit être précédée d’une 608$3
Structure Vérifie la présence d’une zone, d’une sous-zone ou d’indicateur.
Exemple : la zone 328 doit contenir un indicateur « ind2 » avec la valeur 0
Différents types de vérifications sont proposés, par exemple l’absence ou la présence d’une zone dans la notice, l’obligation de fournir une valeur à une zone, ou la présence d’un code pour une zone.
DépendanceConditionnelle Vérifie une règle de dépendance si la notice répond à une condition particulière.
Exemple : s’il y a une zone 455, alors la date en sous-zone 455$d doit correspondre à la date indiquée en zone 100 position 13-16
MatchingConditionnel Vérifie une règle de matching si la notice répond à une condition particulière.
Exemple : si la sous-zone 328$z ne mentionne pas « Reproduction de », alors il ne doit pas y avoir de zone 608 $3027253139Thèses et écrits académiques
StructureConditionnel Vérifie une règle de structure si la notice répond à une condition particulière.
Exemple : si la zone 008 commence par Oa, une zone 304 doit être présente

 

Jeu de règles

Chaque type de document est vérifié selon un jeu de règles qui lui est propre. Par défaut, cinq jeux de règles sont créés avec KaliDoS (« Thèses et mémoires en version de soutenance », « Thèses et mémoires reproduites », « Monographies électroniques », « Monographies imprimées et autres documents », « Jeu général ») et une interface graphique permet d’éditer les jeux de règles ainsi que le contenu de chaque règle. Si la majorité des règles sont communes à tous les établissements du réseau, il peut exister des règles locales, qui n’ont donc pas vocation à être utilisées ailleurs (par exemple, pour les thèses, le libellé normalisé de chaque université en sous-zone 328$e ou le point d’accès à l’établissement de soutenance en sous-zone 711$3).

Les règles sont stockées au format JSON (un fichier par jeu). Plusieurs exemples sont disponibles dans la documentation sur les règles.

Kalidos_partie_1_exemple_de_règles
Règle qui vérifie que la zone 230$a, stocke la taille d’une ressource électronique, ne contient pas l’unité « Mo »

 

Limitation du modèle

La gestion des règles est limitée sur trois points :

  • la distinction entre règle spécifique locale et règle collective n’est pas stricte : une application utilisée par plusieurs établissements se doit donc de marquer cette différence afin de ne partager que les règles communes à tout un réseau.
  • il n’y a pas de notion d’héritage :  un jeu de règles spécifique ne peut pas hériter des règles d’un jeu général. Ce choix se justifie par le fait que les règles évoluent peu fréquemment, mais une application nationale devrait permettre cet héritage afin de faciliter la réutilisation et le partage des règles entre établissements.
  •  il n’y a aucun opérateur pour combiner des règles : un type de règle qui doit vérifier à la fois une condition et la structure de la notice a donc été défini au lieu de combiner une règle conditionnelle et une structurelle. Il y aurait donc matière à repenser ce modèle de règles afin de permettre de combiner des règles existantes.

Conclusion

Une application dédiée au contrôle qualité des notices bibliographiques doit inclure un modèle de règles extensible.
Celui de KaliDoS répond bien aux besoins actuels, mais pourra nécessiter des adaptations s’il était utilisé par un réseau d’établissements. Dans un second billet, nous décrirons l’architecture et les interfaces de KaliDoS.

Logo Université Claude Bernard Lyon 1 Nuria Pastor Martinez, responsable du Pôle Données et Signalement (SCD de l’UCBL)

Fabien Duchateau, enseignant-chercheur (UCBL et laboratoire LIRIS)

 

Continuer la lectureKaliDoS, un outil de vérification des règles de catalogage bibliographique – partie 1

Projet Sudoc21 : retours sur l’exploration des solutions informatiques

Dans ce dernier billet consacré au projet Sudoc21, sont abordées les solutions informatiques choisies pour tester l’implémentation du modèle de données (format pivot) conçu par les experts de la modélisation bibliographique.

  1. Nom de code Sudoc21
  2. Les données en diptyque
  3. Retours sur l’exploration des solutions informatiques

A partir des différentes solutions logicielles permettant de stocker, interroger et mettre à jour les données structurées selon le format pivot, il s’agissait d’évaluer l’aptitude à traduire en terme de système d’information les différents cas d’usages, et notamment d’évaluer leur complexité technique et leur facilité d’implémentation. De manière générale, le volet « expérimentation des solutions informatiques » a constitué un espace d’échanges et de réflexion entre les membres de l’équipe Sudoc21, indépendamment du domaine de compétences de chacun, ce qui a renforcé la diffusion et le partage d’expertises.

Un projet tourné vers l’avenir

L’équipe informatique du projet Sudoc21 a conservé à l’esprit le fait que le système d’information va être amené à gérer des volumes de plus en plus conséquents : si, en l’état actuel, l’éclatement des données Sudoc en entités s’évalue en milliards, l’objectif est d’atteindre une granularité plus fine encore, comme en témoigne le « en deçà » (ie. chapitres, articles, numéros et volumes) évoqué dans le précédent billet Punktokomo à ce sujet : Les données en diptyque : exercice d’apagogie négative:

Ce modèle a mis en exergue l’importance de la notion de “granularité” : en deçà, granularité de description documentaire – livres et revues, mais aussi leurs parties composantes -chapitres, articles, numéros et volumes” 

Il s’agissait également de tenir compte des assouplissements à prévoir lors de la conception et de l’évolution des schémas de données.

Pour prendre en charge ces contraintes, l’équipe a envisagé, en complément des solutions relationnelles classiques, d’autres solutions de stockage et d’interrogation, qui intègrent des mécanismes plus flexibles. Il existe en effet différentes possibilités techniques permettant :

  • soit d’«éclater» des données dans une granularité très fine (« atomique ») – chaque instance pouvant avoir des relations différentes –  et de les lier entre elles
  • soit d’obtenir un compromis entre de la donnée « tabulée » – classique, relationnelle – et de la donnée « orientée » – composite et faiblement structurée-  qui bénéficie peu ou pas des avantages d’un stockage en tables

Dans le cadre du projet Sudoc21, les explorations techniques ont donc été réalisées selon trois approches : une approche relationnelle classique, une approche « graphe »  et une approche « mixte »

Continuer la lectureProjet Sudoc21 : retours sur l’exploration des solutions informatiques

Les données en diptyque : exercice d’apagogie négative [2-2]

Ces billets sont la seconde partie d’une trilogie consacrée au projet Sudoc21. Ils reviennent sur les enjeux de la modélisation des données posés dans le premier billet, et sur la manière dont l’équipe en charge du projet s’y est confrontée.

Tout en cherchant à conceptualiser ce modèle cible, nous avons parallèlement exploré certaines logiques de modélisation, pour en évaluer l’intérêt, ou les écueils. Ces expérimentations nous ont conduits à des choix de modélisations parfois hétérodoxes, parfois même pas totalement cohérents, et ce volontairement. Voici quelques exemples de ces choix, des réflexions qui nous y ont menés et des leçons que nous en avons tirées.

Être ou ne pas être… un Nomen

Nous avons ainsi beaucoup joué avec les Nomens, qui dans le modèle LRM portent les appellations des autres entités, quelles qu’elles soient : titres, noms, libellés. Nous avons pris parti de les considérer comme des entités à part entière, ils sont donc vite devenus omniprésents. Seule entorse au principe, nous n’avons pas poussé cette logique jusqu’à faire des identifiants eux-mêmes des Nomens, comme ils sont censés l’être. Excepté, à titre expérimental, pour l’ISSN-L (ISSN de lien, attribué par le Registre ISSN, commun aux différents supports de publication d’une ressource continue).
Notre retour d’expérience sur ce point, après avoir travaillé sur les cas d’usages en écrivant des requêtes au cours de nos tests des différentes solutions, est mitigé. L’intérêt du Nomen comme entité, est de pouvoir en “dire quelque chose” en plus de sa valeur via des propriétés : langue, écriture, parfois sous-éléments (comme le nom et le prénom pour les personnes), données de gestion…
A contrario, les requêtes portant bien souvent sur la valeur littérale de ces entités, leur présence en « bout de chaîne » alourdit considérablement, à la fois l’écriture de la requête et le parcours des données.
Si c’était à refaire, nous reconsidérerions ce choix : il serait plus économique et efficace de les repenser comme propriété de leur entité mère, à condition de disposer d’un mécanisme permettant de qualifier cette propriété, comme nous l’avons fait pour les affiliations.

Continuer la lectureLes données en diptyque : exercice d’apagogie négative [2-2]

Les données en diptyque : le noyau de la cerise ou la culture du pivot [2-1]

Ces billets sont la seconde partie d’une trilogie consacrée au projet Sudoc21. Ils reviennent sur les enjeux de la modélisation des données posés dans le premier billet, et sur la manière dont l’équipe en charge du projet s’y est confrontée.

Façonner un top-modèle…

Des silos au modèle commun

Pour rappel, les enjeux du projet Sudoc21 étaient d’expérimenter à la fois comment :

  • “Désiloter” les différents types de données, aujourd’hui dispersés dans des environnements et formats qui ont du mal à se parler.
  • Ouvrir la voie à leur migration vers le modèle IFLA-LRM en faisant le choix d’une instanciation commune de ce modèle à tous les types de données traitées. C’est ce modèle cible que nous évoquerons plus loin sous le raccourci “pot commun”.

Dans cette première partie consacrée aux données, il sera question des choix opérés par l’équipe pour l’instanciation du modèle et le passage par un format pivot pour leur conversion.

Pour ce faire, nous avons constitué des jeux de données représentatifs de chaque source. Puis, afin de rendre tangible l’articulation qui existe entre ces données et qui n’est aujourd’hui pas exploitable, nous avons sélectionné un sous-ensemble de ressources présentes à la fois dans le Sudoc, dans BACON et en base RDF auquel est venu s’ajouter un échantillon de métadonnées TEF pour les thèses.

Continuer la lectureLes données en diptyque : le noyau de la cerise ou la culture du pivot [2-1]

Nom de code Sudoc21

Ce billet est le premier d’une trilogie consacrée au projet dit Sudoc21. Il revient sur les enjeux de la modélisation des données, et sur la manière dont l’équipe en charge du projet s’y est confrontée.

Flash-back

Les JABES 2019, une présentation en plénière sur l’avenir du Sudoc, la refonte du SI de l’Abes, enthousiasme et anxiété de venir dire où nous voulions aller. Depuis ? Ce que nous ne pouvions pas prévoir : le monde mis sens dessus dessous les mois suivants, où le sens de la mesure allait s’inverser – jamais assez loin des autres, toujours trop proche de chez soi. Ce que nous pouvions encore moins imaginer : que Stéphane Rey, responsable informatique du projet, meure brutalement en avril 2020. Et après. Et pourtant. Et malgré. Nous voici au bout de ce projet de deux années, nom de code Sudoc21. Vingt-et-un comme XXIème siècle davantage que 2021, si c’est d’échéance qu’il s’agit. Car au risque de vous décevoir, l’irruption du nouveau système ne sera pas immédiate. Mais au moins avons-nous pu prendre le temps, dans un travail très étroit entre bibliothécaires et informaticiens, de poser correctement les questions pour mesurer le chemin qui nous reste à parcourir.

Continuer la lectureNom de code Sudoc21

Le Sudoc PS est dans le graphe !

A la disposition des membres du réseau Sudoc PS, l’application présentée ci-dessous a été conçue par Géraldine Geoffroy (SCD Université Côte d’Azur) et Emmanuelle Rauzy (responsable CR Sudoc PS  PACA/Nice ). Qu’elles en soient ici remerciées !

Cette réalisation s’inscrit tout naturellement dans l’esprit d’ouverture des codes sources et de collaborations applicatives porté par l’Abes avec la mise à disposition du code documenté et des consignes d’installation d’une instance locale via le GitHub de l’Abes.

Le contexte

Dans le cadre de sa précédente convention sur objectifs (2018-2020) avec l’Abes, le Centre du Réseau Sudoc PS PACA/Nice s’est concocté un programme ambitieux, basé sur les activités «classiques» d’un CR en terme d’animation de son réseau (visites, formation, communication, prospection), mais également sur un projet de valorisation de deux corpus issus des collections de son périmètre et considérés comme prioritaires :

  • le corpus des unicas du CR : il s’agit des titres de périodiques pour lesquels un seul exemplaire est disponible (et localisé dans le Sudoc) dans une des bibliothèques du CR, ce qui confère à celui-ci une responsabilité particulière quant à la qualité des métadonnées signalées
  • le corpus des titres de presse locale ancienne : il s’agit des titres de périodiques identifiés par la BnF sur son site dédié de référencement de la presse locale ancienne (ex : BIPFPIG), et qui revêtent, d’un point de vue local, un intérêt scientifique et patrimonial certain.

L’ambition de ce projet était de se doter d’un outil (idéalement d’une application web) d’exploration multi-scalaire, qui permette,  au niveau global du CR ainsi que pour chacune des bibliothèques du réseau, de réaliser les opérations suivantes :

  • visualiser tout ou partie des 2 ensembles de notices
  • croiser les données des corpus afin de :
    • visualiser les éventuels recoupements entre corpus et collections conservées (du point de vue d’une ou plusieurs bibliothèques, et d’un point de vue territorial)
    • proposer des vues agrégatives où les métadonnées issues de l’environnement Sudoc enrichissent et complètent celles provenant de l’écosystème BnF, et vice-versa
  • analyser les métadonnées sur le plan de leur qualité et de leur complétude
  • exporter tout ou partie des métadonnées pour constituer des listes de travail ou pouvoir les exposer dans d’autres environnements ou interfaces tierces.
Continuer la lectureLe Sudoc PS est dans le graphe !

Accès national aux thèses de doctorat de l’UGA : réalisations et mise en œuvre

A l’université Grenoble Alpes (UGA), l’élargissement du périmètre a minima de diffusion des thèses de doctorat, prévu par l’arrêté du 25 mai 2016, a nécessité la refonte de l’outil de gestion des dépôts et des accès aux thèses intranet. L’application développée en interne pour répondre à ce nouvel impératif a été déployée au sein du SID (Service Interétablissement de la Documentation) en 2018. Pour autant, la mise en œuvre effective de ces accès à l’ensemble de la communauté universitaire n’a été effective qu’au premier semestre 2020.

Aujourd’hui, sur les quelques 900 « thèses intranet » (sur environ 7 000 thèses électroniques) des 13 écoles doctorales du site, seules les thèses soutenues à partir du 1er septembre 2016 (environ la moitié) sont concernées par l’élargissement du périmètre de diffusion à l’ensemble de l’enseignement supérieur et de la recherche. En 2020, celles-ci totalisaient 74 % des 1 128 consultations effectives des « thèses intranet ».

Mise en place d’un accès national aux thèses électroniques grenobloises

De Thares 1.0 à Thares 2.0

Développée dès 2009 – soit avant l’ouverture de theses.fr – en vue du passage au dépôt électronique des thèses à Grenoble, l’application pour la gestion des dépôts et des accès aux thèses intranet grenobloises, Thares, était alors liée à Absysnet, l’un des SIGB du site. Complexe à maintenir, il est apparu, au moment de penser la mise en œuvre de l’accès élargi aux thèses intranet, que cette solution était impossible à faire évoluer pour répondre à cet attendu.

Le choix a donc été fait de développer un nouveau Thares. Cette nouvelle mouture devait se démarquer de la précédente par une conception simple et robuste. Nous avions décidé d’éliminer tout lien avec le SIGB, de ne pas utiliser de base de données et de stocker les fichiers de thèse de façon simple et sécurisée sur les serveurs de l’université pour qu’un administrateur puisse, le cas échéant, y accéder.

Continuer la lectureAccès national aux thèses de doctorat de l’UGA : réalisations et mise en œuvre

STAR : des affiliations protégées lors des dépôts de thèses sur la plateforme TEL

Ce billet s’adresse aux établissements diffusant les thèses de doctorat de STAR vers la plateforme TEL.

Nouvelles consignes du CCSD pour le référentiel AuréHAL

À l’été 2020, le CCSD a diffusé de nouvelles consignes concernant le signalement des structures dans le référentiel AuréHAL. En tant que référentiel reposant sur la hiérarchie des structures, chaque structure, de même que les équipes de recherche et les laboratoires, est subordonnées à une structure de rattachement (université, ComUE, regroupement expérimental). Or, avec les nouvelles consignes du CCSD, lorsqu’une structure de rattachement disparaît ou évolue, sa fiche AuréHAL doit être clôturée, ainsi que celles de l’ensemble des structures qui lui sont subordonnées. De nouvelles fiches structures doivent ensuite être créées afin de décrire la nouvelle structure de rattachement et celles qui lui sont subordonnées.

Cette pratique diffère radicalement de celle mise en place dans IdRef, qui consiste à l’inverse à n’avoir qu’une seule notice d’autorité pour les laboratoires ou les équipes de recherche : si la tutelle évolue, cette information est  être saisie dans la notice IdRef. On se trouve donc aujourd’hui avec la situation suivante : pour un laboratoire décrit dans IdRef, il peut exister plusieurs laboratoires dans AuréHAL….

Continuer la lectureSTAR : des affiliations protégées lors des dépôts de thèses sur la plateforme TEL

Cidemis version 3.0.0 : des améliorations à l’écoute des besoins des utilisateurs


logo CidemisEn production depuis 2015, l’application professionnelle CIDEMIS – Circuit des Demandes ISSN est un outil de workflow dédié aux demandes de correction/numérotation ISSN des ressources continues signalées dans le Sudoc. Il a été conçu afin de fluidifier les échanges entre les bibliothèques membres des réseaux Sudoc/Sudoc-PS, le CIEPS et les différents Centres ISSN, notamment le Centre ISSN France. Les modalités de collaboration entre le CIEPS et l’Abes, de fait antérieures à la création de l’Abes, ayant été détaillées dans un précédent billet Punktokomo, il n’en sera donc pas question dans le présent billet.

Rappelons que Cidemis a été conçue initialement comme une application « one shot » – c’est-à-dire non susceptible d’évolutions majeures mais pour laquelle des améliorations peuvent être apportées pour répondre aux besoins exprimés par ses utilisateurs professionnels. Dans cet esprit, au cours de l’hiver 2018, certaines évolutions ont été réalisées principalement en vue d’améliorer le confort d’usage des catalogueurs de la BnF et du centre ISSN France, qui traitent à eux seuls plus de la moitié des demandes.

Il restait cependant à développer certaines améliorations demandées à plusieurs reprises par les responsables des Centres du Réseau Sudoc-PS, principaux utilisateurs de Cidemis en dehors du CIEPS et des centres qu’il coordonne. De plus, victime de son succès, et du nombre de demandes enregistrées, il fallait songer à «apurer» la base en archivant un certain nombre de demandes, un archivage prévu dès l’origine par les concepteurs de Cidemis comme devant être régulièrement pratiqué.

Enfin, même si l’opération est a priori transparente pour les utilisateurs, Cidemis devait bénéficier de la réécriture d’une large partie de son code, en vue d’en améliorer la portabilité et de la rendre conforme aux principes du schéma directeur informatique de l’Abes.

Continuer la lectureCidemis version 3.0.0 : des améliorations à l’écoute des besoins des utilisateurs
Aller au contenu principal