Aller au contenu
Renaud @ruralsmart

Bibliostratus : mettre en correspondance ses notices avec celles de la BnF

Messages recommandés

FabM

@Lully Oui, le programme n'a pas repris après l'erreur 502. Je l'ai fermé moi-même, après avoir attendu (pas de massage "programme terminé"). Dans les résultats, j'ai récupéré environ 2600 lignes traitées sur 3800 (toujours environ). Erreur de débutante : j'ai laissé le programme tourner sur mon ordinateur sans penser à la mise en veille automatique de celui-ci, laquelle a coupé le wifi, et donc interrompu le programme...

Partager ce message


Lien à poster
Partager sur d’autres sites
ghatt

Bonjour,

en préparation de la transition bibliographique pour la bibliothèque municipale de Grenoble, j'utilise Bibliostratus pour récupérer des notices normalisées de la BnF et faire des études de politique documentaire.

J'ai pu traiter sans problème il y a quelques semaines plusieurs dizaines de milliers de notices bibliographiques sans souci, toutes étapes confondues.

Aujourd'hui, je tombe sur une erreur régulière, lors de l'étape d'alignement, qui ressemble à un time out lié à l'emploi d'une adresse https (à la BnF ?).

Au bout de quelques alignements, le message d'erreur en pièce jointe apparait systématiquement.

Est-ce que qu'il y a quelque chose que j'ai raté ?

Merci d'avance.

 

Cordialement,

G. Hatt

bug_bibliostratus_timeout_SSL_26102018.png

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully

@ghatt Bonjour

quelle est la version de Bibliostratus utilisée ? Je pense que j'aurai surtout besoin du fichier en entrée (les 20 premières lignes suffiront). Le message d'erreur vient d'une erreur de certificat HTTPS quand Bibliostratus essaie d'ouvrir une notice détaillée du Sudoc. Est-ce que tu pourrais 1. m'envoyer le fichier testé. Et 2. installer (ailleurs ou à la place) la version RC 1.24 de Bibliostratus https://github.com/Transition-bibliographique/bibliostratus/tree/master/bin/RC pour voir si le problème persiste (il me semble qu'elle intègre des corrections liées à ce problème).

(Mais je viens de rajouter d'autres gardes-fous pour la future vraie version 1.24, pour le cas où la version 1.24RC actuelle ne suffirait pas)

Modifié par Lully

Partager ce message


Lien à poster
Partager sur d’autres sites
ghatt

Bonjour,

l'utilisation de la version RC 1.24 semble résoudre le problème. Un grand merci.

Bonne journéene

G. Hatt

Partager ce message


Lien à poster
Partager sur d’autres sites
-Fred-

Bonjour,

 

Je travaille pour la médiathèque de Lorient et j'ai commencé à tester Bibliostratus. Voici un petit retour d'expérience :

 

Pour le contexte, notre SIGB est Horizon de Sirsidynix et Bibliostratus en version 1.23 est installé sur un système GNU/Linux Debian. L'installation s'est déroulée correctement dans la mesure où ce ne sont que des scripts Python. Il faut juste bien vérifier que les dépendances sont OK (dans mon cas par exemple, passer de python 3.5 à python 3.6 ; j'ai perdu bêtement du temps sur ça mais c'est de ma faute).

 

J'ai rencontré des problèmes pour concernant les données exportées depuis notre catalogue. Comme d'autres, j'ai pu constater que l'export de nos notices directement par notre SIGB ne se faisait pas en UTF-8 ou en 8859-1 mais selon un autre encodage (et bien entendu, pas la moindre information sur l'encodage utilisé). En présentant ce fichier, seules 3% de mes notices étaient traitées par l'outil de conversion de Bibliostratus. J'ai pu déterminer que l'encodage en question ressemblait à de l'ISO6937. Malheureusement, même avec cette information, impossible de réencoder proprement mon export natif SIGB (pas possible avec MarcEdit, je me suis donc rabattu sur les outils iconv et rencoder mais même là, le réencodage échoue à cause de séquences d'échappement non permises). Ces problèmes ne sont pas du fait de Bibliostratus mais j'en parle car forcement, on ne peut pas vraiment y échapper.

 

J'ai toutefois pu m'en sortir de la manière suivante : Horizon est fourni avec un outil d'interrogation (Biblio GQL). L'outil en lui même est une surcouche à SQL et qui a le mérite de bien gérer les diacritiques. Les résultats sont retournés sous forme de tableaux (avec le caractère tabulation comme séparateur de colonnes). A ce stade, je peux donc avoir mes notices dans un fichier texte tabulé avec un encodage UTF-8. Par contre, ce fichier n'est pas directement utilisable par Bibliostratus. J'ai donc développé un petit script python pour produire les différents fichiers textes tabulés qui peuvent ensuite être présenté au processus permettant l'alignement des données.

 

 

Maintenant, je rencontre parfois des erreurs que je n'arrive pas encore à résoudre ou à comprendre :

 

Il m'arrive que Bibliostratus me retourne un timeout gateway (erreur 502). En relançant Bibliostratus, ça passe. Je ne sais pas si cela est lié au réseau où je me trouve ou si c'est un problème propre à l'outil (je vais creuser un peu plus ; c'est peut être un problème résolu par la dernière version de Bibliostratus).

 

Il m'arrive aussi, et c'est plus embêtant, que certaines de mes notices fassent lever une exception à Bibliostratus. Forcement, le traitement s'arrête. Là, je pense que le problème se trouve au niveau de mes notices mais je ne vois pas encore ce qui ne va pas. J'ai joint à ce message les fichiers nécessaires pour illustrer et reproduire ce problème (le fichier à prendre en entrée est BUG-TEX.txt ).

 

 

 

Le 18/04/2018 à 16:27, B. Majour a dit :

Export dans le dossier d'origine, avec tout un tas de fichiers txt  (ce serait mieux d'avoir un dossier d'exportation)


Dans ce cas précis, on peut spécifier un nom de dossier existant dans le préfix (chemin relatif depuis le répertoire courant d'où est lancé Bibliostratus ou chemin absolu). Mais effectivement, un répertoire par défaut serait une bonne idée rien que pour ne pas effacer par erreur un fichier de Bibliostratus.

 

 

 

 

 

 

 

 

 

 

TestsBibliostratus.zip

Modifié par -Fred-

Partager ce message


Lien à poster
Partager sur d’autres sites
-Fred-

Re-bonjour,

 

Manifestement, comme pour ghatt, le passage en version 1.24 a aussi résolu mon problème d'exception.

 

Merci.

Modifié par -Fred-

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully
2 hours ago, -Fred- said:

le fichier à prendre en entrée est BUG-TEX.txt

n'est-ce pas problématique d'avoir un peu partout "non présent" dans les différentes zones ? On est là sur des notices avec ISBN, donc l'alignement se fait sur l'ISBN, avec contrôle sur le titre et la date, mais à terme je dois ajouter un contrôle sur le n° de volume.

La date (sous la forme AAAAMMJJ) peut aussi être problématique : les dates telles que renseignées dans le catalogue BnF et le Sudoc sont plutôt des années simples, pas des jours

Partager ce message


Lien à poster
Partager sur d’autres sites
-Fred-

Pour mes premiers tests avec l'outil, ça ne semble pas pénalisant. Toutefois à terme, oui effectivement ça peut être problématique en fonction de ce qui est (ou sera) recherché dans ces différents champs.

 

Je vais modifier mon script en conséquence.

Modifié par -Fred-

Partager ce message


Lien à poster
Partager sur d’autres sites
-Fred-

Bonjour,

 

Suite à la présentation ce lundi de l'outil à la BNF, j'ai pu lever mes dernières interrogations quand à l'utilisation de bibliostratus. Je commence donc à rechercher à aligner l'ensemble de nos notices (160000 notices de monographies texte environ et un total tout confondu de 250000 notices pour donner un ordre de grandeur) et fatalement se posent des questions de passage à l'échelle.

 

Il n'est pas envisageable de traiter en une fois toutes nos monographies. J'ai cru comprendre (et j'ai constaté) qu'il était plus sage de procéder à l'alignement des notices par groupe de 1000 (ceci afin de ne pas avoir à tout relancer en cas d'aléa durant l'alignement). Il serait peut être intéressant de proposer cela dans le module bleu pour ceux qui l'utilise (split des résultats par groupe de 1000).

 

Sinon, je trouverais intéressant de proposer un répertoire dans l'arborescence où stocker les fichiers issus des divers traitements (répertoire data). Je sais que l'utilisation de bibliostratus n'a pas vocation à être récurrente et qu'il est impératif d'être rigoureux notamment en choisissant des préfixes adéquates. Toutefois sur des gros jeux de données, on est amené à revenir régulièrement chercher nos données au milieu des scripts et à supprimer celles devenues inutiles après traitement.

 

En tout cas, merci encore pour cet atelier.

Modifié par -Fred-

Partager ce message


Lien à poster
Partager sur d’autres sites
B. Majour
Il y a 18 heures, -Fred- a dit :

Il serait peut être intéressant de proposer cela dans le module bleu pour ceux qui l'utilise (split des résultats par groupe de 1000).

 

Plus qu'intéressant, c'est nécessaire.

Il faut toujours lancer des découpes de très grosses masses en petites quantités digestes par le serveur ou programme en face.

 

160 à 250 000 notices, ce n'est plus un petit traitement, c'est un chantier de données.

 

Donc, il est évident que, à termes, il faudra songer à une découpe faite par bibliostratus car tout le monde n'aura pas la capacité de Fred à jouer dans les scripts. :wink:

Mais le logiciel est encore jeune et en phase de bêta-test.

 

Partager ce message


Lien à poster
Partager sur d’autres sites
ghatt

Bonjour,

suite à mes tests et à la journée organisée par le groupe Systèmes et Données (avec un excellent atelier Bibliostratus dans la salle d'attente du train), je me permets une suggestion qui pourrait sauver la vie de beaucoup de bibliothèques qui ne souhaitent pas ou ne peuvent pas demander de prestation à leur fournisseur de SIGB :

conserver le numéro de notice local dans l'écriture de la notice BnF ou Sudoc récupérée à l'étape rouge pour pouvoir écraser directement la bonne notice locale ou simplement ajouter les champs nécessaires à l'alignement dans la notice locale.

Je vois quelques complications pour le développement de Bibliostratus (garder 2 colonnes dans l'étape rouge, NumNot et Ark; donner le choix de la zone MARC à écrire ou imposer la zone 001) mais le bénéfice serait réel pour tous les administrateurs de SIGB qui peuvent charger un fichier ISO 2709 en déterminant des points de correspondances à valider au moment de l'importation des notices. A mon avis, ils sont nombreux.

Au plaisir d'en rediscuter pour affiner le besoin.

Cordialement,

G. Hatt

 

Modifié par ghatt

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully
17 hours ago, ghatt said:

conserver le numéro de notice local dans l'écriture de la notice BnF ou Sudoc récupérée à l'étape rouge

 

Effectivement, cette possibilité a été évoquée lors de l'atelier de lundi. Ca ne me semble pas infaisable, mais j'avais précisé que ça méritait discussion pour s'assurer que ça correspondait à une situation et un besoin réels. Je note donc +1 pour cette proposition

et je l'inscris pour mémoire dans la liste (non exhaustive) des issues https://github.com/Transition-bibliographique/bibliostratus/issues/37

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully
19 hours ago, B. Majour said:

Plus qu'intéressant, c'est nécessaire.

 

Il m'est arrivé encore la semaine dernière de fournir 2 fichiers de 100.000 notices à Bibliostratus, sans problème.

Donc même s'il s'avère nécessaire d'ajouter une option "Découper les fichiers par paquets de X" (rien d'infaisable en soi), il faut que ce soit pour une autre raison que : "le programme plante au bout de 20.000 lignes".

Attention, je ne conteste pas du tout qu'il plante : mais je veux savoir quels sont les mécanismes (non reproduits sur mon PC) qui le font planter. Et j'ai prévu notamment de lancer un alignement massif depuis mon domicile pour voir si c'est un problème d'accès externe au SRU, ou s'il faut chercher complètement ailleurs.

 

Affaire à suivre, donc

Partager ce message


Lien à poster
Partager sur d’autres sites
B. Majour
il y a une heure, Lully a dit :

Il m'est arrivé encore la semaine dernière de fournir 2 fichiers de 100.000 notices à Bibliostratus, sans problème.

 

D'où les as-tu lancés ?

 

Si c'est directement de la BNF, tu commets l'erreur classique de croire que tout le monde a la fibre partout.

En plus, si c'est d'un poste BNF directement relié au serveur BNF, tu as un accès prioritaire sur ton propre réseau interne. Les gens de l'extérieur passent par d'autres serveurs (Internet). Bonne idée de tester de chez toi, mais insuffisante.

 

Essaie de trouver des collègues dans des universités/bibliothèques de province, mal desservies par la fibre.

Et là, tu auras toute l'ampleur du problème.

 

A moins, bien sûr que tu n'offres un service directement depuis ton poste pour les gros chantiers.

Sauf que c'est du boulot et qu'il te faudra sans doute un poste dédié pour ça. :wink:

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully
49 minutes ago, B. Majour said:

l'erreur classique de croire que tout le monde a la fibre partout.

 

Je ne sais pas si le fait d'avoir un réseau moins performant suffit à expliquer que le logiciel ralentisse ?

Partager ce message


Lien à poster
Partager sur d’autres sites
-Fred-

J'ai lancé hier plusieurs traitements en parallèle (environ 40 traitements de 1000 notices) et j'ai constaté ce matin que 4 de ces traitements étaient figés. Pas de plantage mais pas terminés non plus. J'avais constaté la même chose avec un seul traitement lancé depuis mon domicile, figé lui aussi plusieurs heures avant que je ne le stoppe manuellement.

 

Je ne pense pas que ce soit réellement un problème de bande passante ou d'éventuels réglages spécifiques à un réseau car d'une part, ça aboutit généralement lorsque l'on relance le traitement et parce que la bande passante consommée par l'outil est ridicule (quelques dizaines de Kbit/s en upload et en download pour un seul traitement par bibliostratus). Il n'y a donc pas de raison que la qualité du réseau lui même ai une influence là dessus si le réseau est normalement utilisable par ailleurs.

Partager ce message


Lien à poster
Partager sur d’autres sites
B. Majour
il y a 14 minutes, Lully a dit :

Je ne sais pas si le fait d'avoir un réseau moins performant suffit à expliquer que le logiciel ralentisse ?

 

Le logiciel ne "ralentit" pas en lui-même, par contre, ce sont les temps d'accès qui peuvent le mettre en mode ralenti.

Si ton logiciel attend la réponse du réseau, alors le système le passe en attente pour faire autre chose.

 

Tout le problème d'une connexion réseau va se trouver là. A quelle vitesse réagit le réseau dans son ensemble, et en particulier le point le plus faible.

C'est toujours la machine la plus lente qui donne la cadence à toutes les autres. (c'est le goulet d'étranglement)

 

Sinon, si ton logiciel ralentit vraiment, il est possible que la gestion de la mémoire entre en jeu.

Traiter 1000 notices que le logiciel met en mémoire vive, ce n'est pas en traiter 100 000 que le logiciel finit par stocker sur le disque. On passe alors de la nano seconde, à la milli seconde.

 

Au niveau algorithmique, il n'y a en théorie aucune différence. Au niveau physique on est sur une différence de 1 000 000.

Pareil pour la gestion du disque, lire des petits paquets de 1000, ce n'est pas lire un gros paquet de 100 000, ou plus. Le temps d'accès disque devient impactant.

 

Tu as là tout le problème de la gestion de masse.

 

Rajoute que sur Internet, ça passe sur des dizaines de disques très sollicités, et tu comprends d'un coup pourquoi tout le réseau internet travaille par petits paquets de données.

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully

Logiquement, Bibliostratus réalise un alignement à la fois, et je ne crois pas qu'il stocke les résultats au fur et à mesure. Donc pas de raison que la RAM finisse par saturer. Une autre piste : je n'exécute le programme qu'à partir du code source, et je n'ai pas évalué la compilation (pas assez compétent pour ça : j'ai juste récupérer une librairie sur Internet qui convertit du Python en exécutable). J'examinerai cette piste-là aussi (et d'autres qui pourraient émerger)

 

Partager ce message


Lien à poster
Partager sur d’autres sites
-Fred-

Je passe moi aussi directement par le code source, sans passer par la version compilée.

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully
3 minutes ago, -Fred- said:

Je passe moi aussi directement par le code source, sans passer par la version compilée.

 

Bon, ben ça c'est fait...

Partager ce message


Lien à poster
Partager sur d’autres sites
B. Majour
il y a une heure, Lully a dit :

je n'exécute le programme qu'à partir du code source, et je n'ai pas évalué la compilation (pas assez compétent pour ça : j'ai juste récupérer une librairie sur Internet qui convertit du Python en exécutable)

 

D'après lectures sur le Web, l'exe n'est qu'un package de l'interpréteur de script + ton script. Donc, rien de transcrit en assembleur/langage machine. Soit  aucun gain de performances à attendre de ce côté. :wink:

Partager ce message


Lien à poster
Partager sur d’autres sites
Bernard Bibliosurf

Remerciements avec un peu de retard

En venant à l'atelier Bibliostratus de la BNF, j'avais installé la config, testé le module bleu, savais à quoi servait ce logiciel, mais n'avais pas du tout exploré celui-ci et ne connaissais rien aux différentes étapes du processus.

Je remercie donc les animateurs de cet atelier qui ont fait passer la pilule sans difficultés. ;-) Il y avait aussi une ambiance d'entraide entre les "stagiaires" très propice à glaner du savoir-faire.

Encore merci.

 

Modifié par Bernard Bibliosurf

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully

@Bernard Bibliosurf Merci beaucoup pour le retour (enfin, je remercie au nom des vrais formateurs)

C'est vrai que la constitution d'une communauté d'utilisateurs, pour favoriser les retours d'expérience et faire remonter les bonnes idées (construire du réseau) pour une utilisation concrète de Bibliostratus, est quelque chose qui nous tient à coeur

Modifié par Lully

Partager ce message


Lien à poster
Partager sur d’autres sites
Lully

J'ai lancé un gros fichier d'alignement depuis chez moi. Il s'est immobilisé (plutôt qu'arrêté), effectivement, comme décrit par d'autres collègues. Mais déjà, c'était au bout de 30.000 lignes. Par ailleurs, j'ai l'impression que ça peut concerner les cas où il y a très peu de métadonnées (par exemple : juste un titre comme "L'homme"), ce qui génère une requête de mille notices SRU, et que ça bloque entre les deux. Je vais tester avec un time out sur ces requêtes, pour voir si ça change quelque chose.

 

En attendant, j'ai ajouté en test un horodatage à chaque ligne, et voici le résultat pour les 30.000 lignes en question :

127 cas de plus de 10 secondes, une moyenne et une médiane à 1 seconde, un maximum à 8 minutes

 

Le corpus n'est pas représentatif pour 2 raisons :

1. c'est essentiellement un fonds antérieur aux années 1970, donc pas d'ISBN, si bien que l'alignement se fait presque uniquement sur des mots-clés (plus long que sur identifiant)

2. ce sont des données BnF, donc généralement la recherche SRU suffit, et Bibliostratus ne passe pas par DoMyBiblio ("généralement", parce que quelquefois -- très rarement -- le nettoyage des données en entrée a pour conséquence l'impossibilité de retrouver la notice initiale dans le catalogue). Donc pour cette raison c'est plus rapide qu'un corpus de bibliothèque municipale...

horodatage 30000 alignement - différentiel.png

Modifié par Lully
ajout de précisions sur les tests de performance

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

×