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

[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...

[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

[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é le 27 octobre 2018 par Lully

[ghatt]

_Bonjour,

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

_{Bonne journéene}

_{G. Hatt}

[-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é le 29 octobre 2018 par -Fred-

[-Fred-]

Re-bonjour,

 

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

 

Merci.

Modifié le 29 octobre 2018 par -Fred-

[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

[-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é le 29 octobre 2018 par -Fred-

[-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é le 7 novembre 2018 par -Fred-

[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.

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

 

[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é le 7 novembre 2018 par ghatt

[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

[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

[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.

[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 ?

[-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.

[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.

 

 

[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)

 

[-Fred-]

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

[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...

[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é.

[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é le 10 novembre 2018 par Bernard Bibliosurf

[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é le 10 novembre 2018 par Lully

[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...

Modifié le 10 novembre 2018 par Lully
ajout de précisions sur les tests de performance

[-Fred-]

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.

Je n'ai réalisé que des exports en xml pour le moment en demandant l'export des notices bib et des autorités.

Je précise aussi que je ne prend en entrée ici que les notices ayant été alignées avec un seul identifiant ark ou ppn.

 

Problème 1 (uniquement avec fichier à deux colonnes) :

Dans ce cas précis, c'est l'ark suivant qui pose problème --> ark:/12148/cb35089640s

188. ark:/12148/cb349344156
189. ark:/12148/cb36203546z
190. ark:/12148/cb34621139x
191. ark:/12148/cb35089640s
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.6/tkinter/__init__.py", line 1705, in __call__
    return self.func(*args)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 579, in <lambda>
    format_file.get(),
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 363, in callback
    extract1record(row, j, form, headers, parametres)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 314, in extract1record
    bib2aut(identifier, XMLrec, parametres)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 218, in bib2aut
    parametres["format_file"], parametres)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 281, in record2file
    record = XMLrecord2string(identifier, XMLrec, parametres)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 100, in XMLrecord2string
    record_str = correct_record(identifier, record_str, parametres)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 158, in correct_record
    <subfield code="a">""" + agence_uri + """</subfield>
NameError: name 'agence_uri' is not defined

 

Problème 2 (fichier à une colonne et fichier à deux colonnes) :

Lors de la phase d'alignement, certaines données remontées ne sont ni des ark, ni des ppn. Du coup, ça ne fonctionne pas.

213. ark:/12148/cb366183544
214. ark:/12148/cb35172304c
215. ark:/12148/cb34986488x
216. 16972341
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.6/tkinter/__init__.py", line 1705, in __call__
    return self.func(*args)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 579, in <lambda>
    format_file.get(),
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 363, in callback
    extract1record(row, j, form, headers, parametres)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 300, in extract1record
    (test, page) = funcs.testURLetreeParse(ark2url(identifier, parametres))
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/funcs.py", line 454, in testURLetreeParse
    resultat = etree.parse(request.urlopen(url, timeout=param_timeout))
  File "/usr/lib/python3.6/urllib/request.py", line 223, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.6/urllib/request.py", line 511, in open
    req = Request(fullurl, data)
  File "/usr/lib/python3.6/urllib/request.py", line 329, in __init__
    self.full_url = url
  File "/usr/lib/python3.6/urllib/request.py", line 355, in full_url
    self._parse()
  File "/usr/lib/python3.6/urllib/request.py", line 384, in _parse
    raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: ''

 

Problème 3 (fichier à une colonne et fichier à deux colonnes) :

Les fichiers xml des notices autorité ne sont pas valides (manque </collection> à la fin).

Ceux des notices bib sont OK.

 

 

Problème 4 (fichier à une colonne et fichier à deux colonnes) :

Visiblement, l'outil ne veut pas des PPN :/

 

Pour le fichier contenant uniquement ce qui suit par exemple :

NumNot    ark trouvé
frBN001426679    ark:/12148/cb346747516
frBN008480409    ark:/12148/cb35096223k
frBN001598860    ark:/12148/cb34689186m
frBN008662237    PPN008760128
frBN007554244    ark:/12148/cb35054855j

Voilà la trace obtenue :

0. ark:/12148/cb346747516
1. ark:/12148/cb35096223k
2. ark:/12148/cb34689186m
3. 008760128
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.6/tkinter/__init__.py", line 1705, in __call__
    return self.func(*args)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 579, in <lambda>
    format_file.get(),
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 363, in callback
    extract1record(row, j, form, headers, parametres)
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 300, in extract1record
    (test, page) = funcs.testURLetreeParse(ark2url(identifier, parametres))
  File "/home/mediatheque/Applications/bibliostratus-1.24/bibliostratus/ark2records.py", line 68, in ark2url
    url = "https://www.sudoc.fr/" + ark[3:] + ".xml"
NameError: name 'ark' is not defined

 

Sinon, les résultats obtenus lors de la première phase d'alignement sont encourageants (93% OK sur les monographie ; nettement moins bon pour l'audio et la vidéo, de l'ordre de 30% et + de 50% OK pour les périodiques).

Je cherche maintenant à traiter les notices non alignées (soit 0, soit plusieurs ark / ppn trouvés) afin de pouvoir les repasser dans l'outil.

 

texte1-ark.txt

texte-1-resultats_1_ark_trouve.txt

texte1-numNot-ark.txt

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