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

[Lully]

Bonjour @Fred. Avant que j'aille explorer le code : quelle est la version téléchargée (je pense que le formulaire affichera "version 1.25", mais quelle est le nom du zip récupéré) ?

[Lully]

7 hours ago, -Fred- said:

Bonjour,

 

Je suis en train de travailler avec l'outil à l'importation des notices bib et des autorités associées (le module rouge).

 

J'ai rencontré plusieurs problèmes et pour que ce soit plus simple, j'ai copié/collé les traces ic et mis les fichiers contenant quelques alignements en PJ.

....

 

 

Merci beaucoup pour tous ces retours très détaillés et précieux.

Logiquement la version 1.25 en cours de finalisation devrait résoudre tous ces problèmes

Certaines corrections étaient déjà implémentées pour cette version à paraître, les 2 autres corrections apportées le sont désormais (j'espère !) dans la 1.24.11RC

https://github.com/Transition-bibliographique/bibliostratus/tree/master/bin/RC

Sauf pour les cas où vous avez récupéré, dans le résultat des alignements, des identifiants sans préfixe :  ce sont en réalité des PPN, mais où le préfixe "PPN" n'a pas été ajouté. Logiquement, il est désormais systématiquement présent dans les rapports d'alignements, mais pour ceux que vous avez déjà fait tourner il faudra les ajouter "à la main" (en mode chercher-remplacer, ce sera plus rapide). Pour ensuite les faire passer dans le module rouge, version 1.24.11RC, ou dans la future version 1.25

[-Fred-]

Bonjour,

 

Il y a 17 heures, Lully a dit :

Bonjour @Fred. Avant que j'aille explorer le code : quelle est la version téléchargée (je pense que le formulaire affichera "version 1.25", mais quelle est le nom du zip récupéré) ?

 

J'ai effectué mes premiers essais avec une version pas à jour (1.24 datant de début novembre), ce qui n'était pas représentatif de la version actuelle.

 

Avant de poster mon message précédent,  j'ai donc récupéré la dernière version du projet (1.24.10 RC sur github) directement avec une commande "git clone https://github.com/Transition-bibliographique/bibligraphique.git" hier puis j'ai refait les essais.

 

Il y a 14 heures, Lully a dit :

 

Merci beaucoup pour tous ces retours très détaillés et précieux.

Logiquement la version 1.25 en cours de finalisation devrait résoudre tous ces problèmes

Certaines corrections étaient déjà implémentées pour cette version à paraître, les 2 autres corrections apportées le sont désormais (j'espère !) dans la 1.24.11RC

https://github.com/Transition-bibliographique/bibliostratus/tree/master/bin/RC

Sauf pour les cas où vous avez récupéré, dans le résultat des alignements, des identifiants sans préfixe :  ce sont en réalité des PPN, mais où le préfixe "PPN" n'a pas été ajouté. Logiquement, il est désormais systématiquement présent dans les rapports d'alignements, mais pour ceux que vous avez déjà fait tourner il faudra les ajouter "à la main" (en mode chercher-remplacer, ce sera plus rapide). Pour ensuite les faire passer dans le module rouge, version 1.24.11RC, ou dans la future version 1.25

 

Ok, je vais tester ça rapidement avec la version version 1.24.11RC et confirmer que les problèmes remontés n'apparaissent plus.

Concernant les identifiants sans préfixes, ce sera effectivement plus simple de les renommer manuellement car c'est un cas assez peu fréquent.

 

Merci pour ces informations.

Modifié le 6 décembre 2018 par -Fred-

[-Fred-]

Bonjour,

 

Je viens de recharger les sources du projet avec un "git clone https://github.com/Transition-bibliographique/bibligraphique.git" mais ça ne change rien concernant mes divers problèmes.

A tout hasard, j'ai quand même téléchargé le fichier zip pour windows 64 de la version 1.24.11RC de bibliostratus mais j'ai les mêmes résultats.

 

[Lully]

24 minutes ago, -Fred- said:

Bonjour,

 

Je viens de recharger les sources du projet avec un "git clone https://github.com/Transition-bibliographique/bibligraphique.git" mais ça ne change rien concernant mes divers problèmes.

A tout hasard, j'ai quand même téléchargé le fichier zip pour windows 64 de la version 1.24.11RC de bibliostratus mais j'ai les mêmes résultats.

 

OK, donc je me replonge dans les erreurs signalées en détail

 

Problème 1 :

le code s'exécute pour essayer de réécrire la notice (le message d'erreur indique que le programme veut utiliser la fonction correct_record, qui réécrit la zone 001

Or vous indiquez que c'est dans le cas de fichiers à 1 colonne --> incohérence : vous mettez en entrée un fichier à 1 colonne, mais vous avez coché l'option "Fichier à 2 colonnes"

Bon, par ailleurs j'avais une erreur de typographie dans mon code : la variable agency_uri devenait à un moment agence_uri

 

Problème 2 : ce sont des PPN, il faut ajouter l'info, effectivement (et au passage, comme vous les avez passés dans Excel, 2 d'entre eux ont perdu leur 0 initial)

 

Problème 3 : fichier XML Autorités liées n'est pas correctement formé (manque une balise </collection> finale)

Sur mon poste, c'est correct en tout cas ! Je ne reproduis pas l'erreur

 

Problème 4  :  après ajout des préfixes PPN, le problème n'est-il pas résolu ?

 

Bon, suite à ma correction sur la variable agency_uri, voici une version 1.24.12RC https://github.com/Transition-bibliographique/bibliostratus/blob/master/bin/RC/bibliostratus_1.24.12RC_win64_py3.6.zip

[-Fred-]

 

Pour le 1er problème, je constate une erreur lorsque je veux passer mon fichier à deux colonnes et que je coche l'option "2 colonnes" dans le module rouge.

Le traitement s'arrête alors sur la ligne contenant l' ark:/12148/cb35089640s .

Je ne constate pas d'erreur lorsque je travaille avec un fichier contenant uniquement l'identifiant unique et que je sélectionne l'option "1 colonne".

 

Pour le 2nd problème je vais regarder si effectivement je n'ai pas perdu de données en passant par mon tableur.

La solution est peut-être là. Il n'est pas impossible non plus que cela soit à l'origine de mon premier problème.

 

Pour le 3ème problème, cela ne concerne que les notices autorité. Les notices bib sont OK.

Je confirme qu'il manque toujours la balise finale.

 

Pour le 4ème problème, il me semble que ce n'est pas encore résolu.

 

Je vais refaire des tests avec le version 1.24.12RC dès que possible.

[Tredok]

Coucou ! J'ai eu le même soucis que toi Fred (problème 1, mais uniquement lors de la récupération des autorités sujets. J'ai update (à priori en 1.24.12RC) et tout roule ^^

 

 

[Lully]

5 hours ago, Tredok said:

Coucou ! J'ai eu le même soucis que toi Fred (problème 1, mais uniquement lors de la récupération des autorités sujets. J'ai update (à priori en 1.24.12RC) et tout roule ^^

 

 

Ouf ! Merci Tredok !

[kateB]

Bonjour !

 

Nous avons commencé une campagne bibliostratus à Brest à la mi-javier. Tout se passe bien. J'ai juste un problème dans "BST blanc", avec un fichier de notices de périodiques. Pour ce fichier uniquement (sur environ une centaine ou plus de fichiers traités), lorsque je valide le lancement de l'alignement, l'opération est interrompue avec le message 

 

Exception in Tkinter callback
Traceback (most recent call last):
  File "tkinter\__init__.py", line 1699, in __call__
  File "noticesbib2arkBnF.py", line 2778, in <lambda>
  File "noticesbib2arkBnF.py", line 2305, in launch
  File "noticesbib2arkBnF.py", line 2272, in file2row
  File "noticesbib2arkBnF.py", line 2128, in item2id
  File "noticesbib2arkBnF.py", line 2079, in item2ppn_by_id
  File "noticesbib2arkBnF.py", line 1178, in issn2sudoc
  File "funcs.py", line 698, in __init__
IndexError: list index out of range
 

J'ai repéré à chaque fois le n° de notice qui passait au moment de l'arrêt du programme. J'ai bien-sûr fait des tests en n'essayant de charger que cette notice ==> plantage. Je vous envoie le fichier en question. Certaines notices sur lesquelles BST avaient planté ont pu finalement être intégrées en les passant "individuellement" : 1/38103, 1/30521, 1/38234, 1/38589, 1/38655. Les notices problématiques, qui n'ont pu être alignées, même en les passant seules dans BST : 1/38106, 1/38228, 1/38230, 1/38236, 1/38241, 1/38242, 1/38464, 1/38592, 1/38659.J'ai stoppé mes tests à partir de la notice 38359.

 

J'utilise la version bibliostratus_1.24.

 

Merci d'avance pour votre avis d'experts !

 

Bonne semaine.

 

Catherine Bretéché

Médiathèques de Brest

Service Applications informatiques et Traitement des données

catherine.breteche@mairie-brest.fr

Notices_030001_040000-PER-texte-périodiques.txt

[Bernard Bibliosurf]

Bibliostratus est un superbe outil.

Mais avez-vous déjà pensé à récupérer le lien ARK par le SRU directement avec l'ISBN du document ?

C'est ce que je fais sur https://www.bibliosurf.com et ça marche vraiment bien.... oui je sais pour des livres. 
Dès qu'un internaute affiche une notice sans BNF ARK, un script interroge le SRU  et si il trouve la donnée dans la notice UNIMARC la copie dans la base.

Pour info : le taux de recouvrement est de plus 90% sur Bibliosurf.

 

[Lully]

On 2/5/2019 at 2:14 PM, Bernard Bibliosurf said:

Bibliostratus est un superbe outil.

Mais avez-vous déjà pensé à récupérer le lien ARK par le SRU directement avec l'ISBN du document ?

C'est ce que je fais sur https://www.bibliosurf.com et ça marche vraiment bien.... oui je sais pour des livres. 
Dès qu'un internaute affiche une notice sans BNF ARK, un script interroge le SRU  et si il trouve la donnée dans la notice UNIMARC la copie dans la base.

Pour info : le taux de recouvrement est de plus 90% sur Bibliosurf.

 

 Merci pour l'appréciation :-)

Je n'ai pas bien compris ce que tu suggères : Bibliostratus va effectivement interroger les ISBN dans le catalogue pour récupérer les ARK BnF. A défaut d'ISBN, il utilise d'autres métadonnées (pour les autres types de documents, notamment). Et quand il y a un ISBN qu'il le trouve dans le catalogue, il réalise plusieurs contrôles successifs pour éviter le problème des ISBN attribués successivement à plusieurs ouvrages.

[Bernard Bibliosurf]

Effectivement, tu as raison.  Bibliostratus effectue des recherches avec d'autres métadonnées.

Je fais le malin avec Bibliosurf, un cas de figure très simple.

 

[Lully]

 

On 2/5/2019 at 12:37 PM, kateB said:

J'utilise la version bibliostratus_1.24. 

 

Je viens de tester le même  jeu de données sur la version 1.25, sans rencontrer le problème. J'imagine qu'il a été identifié à l'automne dernier et corrigé à ce moment-là.

Par ailleurs, je signale qu'il y avait des problèmes de diacritiques dans le le fichier en question. Cf. en PJ le fichier où j'ai "nettoyé" ces problèmes en faisant simplement du chercher-remplacer

Notices_030001_040000-PER-texte-périodiques.txt

[kateB]

 

il y a 39 minutes, Lully a dit :

 

 

Je viens de tester le même  jeu de données sur la version 1.25, sans rencontrer le problème. J'imagine qu'il a été identifié à l'automne dernier et corrigé à ce moment-là.

Par ailleurs, je signale qu'il y avait des problèmes de diacritiques dans le le fichier en question. Cf. en PJ le fichier où j'ai "nettoyé" ces problèmes en faisant simplement du chercher-remplacer

Notices_030001_040000-PER-texte-périodiques.txt

 

Merci ! En effet j'avais remarqué les diacritiques problématiques. Je suis en train d'aligner le fichier corrigé, il passe impeccablement. Je vais m'empresse de télécharger la version 1.25.

[CFCB Bretagne-Loire]

Bonjour à tous,

Une journée d'étude sur la TB et un atelier Bibliostratus sont proposés à Brest le jeudi 4 avril.

Une journée ouverte à toutes et tous, pour faire le point et approfondir les enjeux et la mise en œuvre la transition bibliographique. La médiathèque François Mitterrand - Les Capucins à Brest accueillera pour la première fois le 4 avril 2019 tous les acteurs de la coopération nationale pour cette journée professionnelle organisée par le CFCB Bretagne Pays de la Loire, le CNFPT Bretagne, la bibliothèque départementale du Finistère et Livre et Lecture en Bretagne.

 

Cette journée d'étude s'adresse à tout public intéressé par la transition bibliographique : administrateurs de SIGB, coordinateurs Sudoc, responsables de départements collections, gestionnaires de données bibliographiques, catalogueurs, confirmés ou débutants, directeurs d’établissements, élus ...

 

Programme et inscriptions à la journée d'étude

 

Elle s'accompagne d'un atelier sur l'outil d'alignement de données Bibliostratus.

Détails, prérequis et inscription

 

Modifié le 20 mars 2019 par CFCB Bretagne-Loire

[Emilie]

Bonjour,

Je rencontre le même problème que la médiathèque de Brest, mais en utilisant la dernière version de Bibliostratus disponible.

Le module bleu plante systématiquement au bout d'une certain nombre de notices (voir la PJ).

Je pensais que c'était dû aux notices où le logiciel s'arrête. Mais en enlevant les notices du fichier, le logiciel s'arrête toujours, environ au même endroit (notice n°1/153009, puis n°1/153008, puis n°1/153006...).

Auriez-vous une idée de ce qui pose problème ? Mon fichier contient beaucoup de notices (environ 150 000). Est-ce que le problème pourrait venir de là ?

Merci

[B. Majour]

Bonjour Emilie

 

errors_encoding_iso indiquerait plutôt un problème de caractères non reconnus dans la notice.

Pas facile de gérer la diversité des multiples encodages.

 

Vous avez regardé le titre de la/les notices correspondantes ?

 

[Lully]

On 5/2/2019 at 12:32 PM, Emilie said:

Le module bleu plante systématiquement au bout d'une certain nombre de notices (voir la PJ).

Je pensais que c'était dû aux notices où le logiciel s'arrête. Mais en enlevant les notices du fichier, le logiciel s'arrête toujours, environ au même endroit (notice n°1/153009, puis n°1/153008, puis n°1/153006...).

 

Ce n'est pas vraiment un problème d'encodage à proprement parler : d'après la librairie Python utilisée (Pymarc), le guide/label de certaines notices contient des informations problématiques qui le font planter.

Si vous convertissez le fichier en XML avec MarcEdit (est-ce que vous y parvenez, d'abord), arrivez-vous à traiter vos notices ?

[B. Majour]

il y a une heure, Lully a dit :

le guide/label de certaines notices contient des informations problématiques qui le font planter.

 

Oui, effectivement.

 

D'après

https://github.com/edsu/pymarc/issues/42

 

Et en recherchant la dernière erreur (In decode_marc pymarc.exceptions.recordDirectoryInvalid : invalid directory), on arrive à cette problématique possible :

 

"The maximum length of data in a variable field in UNIMARC -- as well as MARC21 -- is 9,999 bytes (see the bottom of this page, in the "Directory Map" section). You cannot serialize a MARC record into MARC21 or UNIMARC and have a field over this length because the data format cannot handle that. The field length includes the indicators as well as all of the subfields."

 

Un champ commentaire ou résumé de livre trop gros ? (je me demande si c'est vraiment possible, tiens, il faudra que je teste dans mon SIGB)

Ou autre chose, qui engendre une notice invalide/corrompue.

 

@Emilie

Le 02/05/2019 à 12:32, Emilie a dit :

Je pensais que c'était dû aux notices où le logiciel s'arrête. Mais en enlevant les notices du fichier, le logiciel s'arrête toujours, environ au même endroit (notice n°1/153009, puis n°1/153008, puis n°1/153006...).

 

Si ça s'arrête toujours au même endroit, essaie d'enlever celle qui précède la 153009 / 153008 / 153006.

 

Si la notice est plus longue que 9999 caractères, alors le logiciel va être perdu.

Dans un format aussi strict que l'unimarc, un seul caractère de décalage et c'est tout la notice qui est fichue. Décodage compris. Sans parler de la suite des autres notices.

 

MarcEdit devrait t'aider à le voir.

[Emilie]

Bonjour,

 

Citation

Le 03/05/2019 à 16:38, Lully a dit :

 

Ce n'est pas vraiment un problème d'encodage à proprement parler : d'après la librairie Python utilisée (Pymarc), le guide/label de certaines notices contient des informations problématiques qui le font planter.

Si vous convertissez le fichier en XML avec MarcEdit (est-ce que vous y parvenez, d'abord), arrivez-vous à traiter vos notices ?

 

 

J'ai converti mon fichier en XML et je ne rencontre plus de problème. Merci beaucoup !

 

Le 03/05/2019 à 18:38, B. Majour a dit :

Si la notice est plus longue que 9999 caractères, alors le logiciel va être perdu.

Dans un format aussi strict que l'unimarc, un seul caractère de décalage et c'est tout la notice qui est fichue. Décodage compris. Sans parler de la suite des autres notices.

 

Certaines de nos notices sont très longues car elles contiennent beaucoup de liens, il est possible que ce soit ça qui pose problème avec un fichier iso. La conversion en XML règle ça.

 

Je suis en train de procéder à l'alignement mais mon fichier est très gros, le programme tourne depuis hier.

[Emilie]

Bonjour,

 

Le traitement de notre fichier de notices bibliographiques a pris plusieurs jours, mais nous sommes plutôt satisfaits du résultat.

Sur 151049 notices contenues dans le fichier, 119292 ont trouvé un identifiant ARK correspondant. Nous avons fait quelques tests, les correspondances ont l'air correctes. Nous allons donc intégrer ces identifiants à nos notices.

Par contre, 5957 notices n'ont pas trouvé d'ARK mais un PPN correspondant. Et nous nous demandons s'il est judicieux d'intégrer cet identifiant à nos notices.

 

D'autres bibliothèques territoriales le font-elles ?

 

Merci,

 

[B. Majour]

Il y a 2 heures, Emilie a dit :

Sur 151049 notices contenues dans le fichier, 119292 ont trouvé un identifiant ARK correspondant.

 

Jolie réussite de Bibliostratus : 78,98 % de taux de recouvrement, c'est un très bon résultat.

 

Pour les PPN, je te conseille de les stocker bien au chaud.

 

Si les BU et le SUDOC s'emparent du sujet Ark. (C'est peut-être en cours), il est clair qu'il existera bientôt/un jour un outil du genre

https://www.sudoc.fr/services/isbn2ppn/0195141156

qui donnera aussi l'ARK.

 

ARK, ISBN, PPN réunis dans une même table de correspondance, ça pourrait aider le recouvrement des "absents" de Bibliostratus.

 

Une dernière chose, Emilie, est-ce que tu as la possibilité de créer un fichier avec les notices qui n'ont pas trouvé corde à leur Ark.

C'est toujours intéressant de savoir pourquoi un programme échoue. Si c'est possible, je suis intéressé par le résultat. (hum, vu la taille du fichier, il faudra peut-être utiliser We transfer)

Enfin, à voir bien sûr.

 

Merci pour ton retour.

[mhertig]

Le 11/10/2018 à 12:43, Lully a dit :

Il y a une fonction un peu discrète (c'est plus ou moins exprès, je ne voulais pas ajouter un bouton pour une option qui ne concernerait qu'un petit nombre de personnes) : une fois que vous avez téléchargé le logiciel, il y a dans le dossier bibliostratus\main\files, un fichier preferences.json.

La dernière ligne comporte la valeur "unimarc". Il faut lui substituer "marc21". La conversion de fichiers Marc en tableaux devrait alors être plus satisfaisante (je ne prétends pas qu'elle soit parfaite, elle a été beaucoup moins testée que l'autre).

 

 

Bonjour,

Je teste Bibliostratus sur nos données d'autorité, en MARC21. J'ai testé la conversion du xml vers un fichier tsv, mais seul l'identifiant système est reconnu (champs 001 de la notice MARC21). Il s'agit peut-être d'un problème de mapping. Serait-il possible de consulter le tableau de mapping, pour vérifier ?

Meilleures salutations,

Michael Hertig, Lausanne (Suisse)

[clio1130]

Bonjour,

 

Je viens de faire quelques tests avec la version 1.27 et je rencontre deux problèmes concernant la Conversion d'un fichier Unimarc en tableau (format de fichier iso2708 encodé UTF-8).

 

1. Si dans le fichier iso2709, le nom de l'auteur de l'ouvrage contient un tiret, ce tiret est conservé dans le fichier tableau. Par la suite, quand on utilise la fonction Aligner ses données BIB avec la BnF ou le Sudoc à partir de fichiers tableau (j'ai coché Avec le Sudoc), l'alignement ne se fait pas. (C'est peut-être la fonction Aligner ses données BIB avec la BnF ou le Sudoc à partir de fichiers tableau, qui devrait ignorer les tirets.)

2. Parfois quand il y a 3 auteurs ou plus, les noms et prénoms sont mélangés.

[Lully]

Bonjour @clio1130

 

13 hours ago, clio1130 said:

1. Si dans le fichier iso2709, le nom de l'auteur de l'ouvrage contient un tiret, ce tiret est conservé dans le fichier tableau. Par la suite, quand on utilise la fonction Aligner ses données BIB avec la BnF ou le Sudoc à partir de fichiers tableau (j'ai coché Avec le Sudoc), l'alignement ne se fait pas. (C'est peut-être la fonction Aligner ses données BIB avec la BnF ou le Sudoc à partir de fichiers tableau, qui devrait ignorer les tirets.)

Serait-il possible d'avoir une ligne d'exemple concerné par ce problème (ce sera plus rapide pour que je puisse le reproduire et le corriger) ?

 

13 hours ago, clio1130 said:

2. Parfois quand il y a 3 auteurs ou plus, les noms et prénoms sont mélangés.

Oui, Bibliostratus prend tous les mots des zones auteurs, et il les dédoublonne (je ne sais plus s'il les trie ensuite, il n'a pas de raison de le faire) : ça évite de chercher plusieurs fois le même mot en tant qu'auteur, ce qui n'apporte rien à la recherche. La colonne Auteur est utilisé pour chercher des mots en tant qu'auteur, leur ordre d'apparition n'a pas d'importance pour la pertinence des résultats. Ce module Marc > tableaux n'est (pour l'instant ?) pas un outil d'extraction de métadonnées bibliographiques pour faire avoir des références bibliographiques à peu près propres.

Modifié le 28 juin 2019 par Lully