[koha-Infos] RE : import SUDOC

[BERNON Jean]

Cette discussion quoique technique concerne en effet tout à fait les bibliothécaires. En gros il y a trois méthodes pour avoir des tris corrects des zones titre dans un catalogue informatisé :
1 - L'usage de liste d'articles qui sont éliminés pour faire l'indexation et les tris. Deux difficultés : a) il vaut mieux avoir des listes par langue b) même avec des listes par langue on n'échappe jamais à des cas où l'élimination de l'article n'est pas pertinente.
2 - L'usage d'un indicateur avec le nombre de caractères du début du titre qui ne doivent pas être pris en compte pour les tris. Cette technique propre à LCMARC est efficace à condition que le catalogueur ne fasse pas d'erreur.
3 - L'usage de NSB/NSE pour délimiter la zone à ne pas trier. Même remarque que pour la technique précédente.
La troisième technique reste utilisée par la plupart des grandes bases nationales dont les deux principales en France, SUDOC et BnF. Elle est censée régler tous les cas de figure et être utilisable dans n'importe quel format marc et dans n'importe quelle zone marc.
Je suis plutôt partisan  de garder les NSB/NSE dans nos données parce que de manière générale les catalogues survivent à plusieurs logiciels et que des données qui posent difficulté à un logiciel peuvent se révéler indispensables dans le suivant. En même temps il est vrai qu'on peut très bien les regénérer (avec des risques d'erreur sur les cas où ils sont le plus utiles) à l'occasion d'une migration. Les garder n'est donc pas un dogme, même si cela semble préférable.

Cordialement
Jean Bernon
________________________________________
De : infos-bounces at listes.koha-fr.org [infos-bounces at listes.koha-fr.org] de la part de Frédéric Demians [frederic at tamil.fr]
Date d'envoi : mercredi 4 mai 2011 09:19
À : 'paul POULAIN'; discussions générales sur Koha
Objet : Re: [koha-Infos] import SUDOC

 > La suite en privé, donc ;-)

Nonobstant toute considération d'ordre privée :-), il ne serait pas
inintéressant de discuter du sort à réserver à ces fameux caractères NSB
et NSE... De multiples tentatives de phagocytage ont été faites. A
chaque fois, ils réapparaissent ici ou là. C'est une discussion assez
technique qui concerne les développeurs mais qui intéresse également les
bibliothécaires, me semble-t-il.

Les NSB/NSE sont gênants à l'affichage, à l'indexation et dans les
champs des tables MySQL (voir premier message de Pascale Nalon).

Ce qui a pu être fait jusque-là :

   1. Suppression ciblée à l'affichage dans les titres via la feuille de
      style XSL.
   2. Suppression globale à l'affichage via le code Perl qui renvoie
      toutes les pages de Koha (module Output.pm)
   3. Suppression dans les index de Zebra au moyen d'une configuration
      appropriée des règles d'indexation.
   4. Suppression dans les notices bibliographiques avant leur chargement
      dans Koha. C'est ce que peut faire un chargeur SUDOC, BNF, Electre
      ou réseau.

D'où certaines questions.

D'abord faut-il garder les NSB/NSE ? En les éliminant des notices, on
règle une fois pour toute le problème. On peut considérer que ce n'est
pas bien grave dans la mesure où, pour le moment, Koha ne s'en sert pas
pour créer les clés de tri des titres, mais ça peut changer et en les
éliminant on appauvrit son catalogue.

Ensuite, certaines de ces solutions sont redondantes et impactent les
performances du système. 1 et 2 font la même chose. 2 applique une
expression régulière sur toute la longueur de toutes les pages renvoyées
par Koha, pas seulement sur le bloc contenant la notice bibliographique,
avec l'effet de bord signalé, à savoir la disparition des caractères
mêmes dans la page de saisie des notices, là où justement on voudrait
peut-être les conserver.

Le problème signalé par Pascale Nalon -- NSB/NSE dans le champ title de
la table biblio -- n'est résolu que par 4. En effet, ce champ
biblio.title est pour le moment la copie exacte de 200$a. Il faudrait
éliminer NSB/NSE au moment de la copie en 200$a si on voulait à la fois
conserver les NSB/NSE dans ses notices MARC et avoir un champ de la
table MySQL qui soit utilisable.

Cordialement,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html

_______________________________________________
Infos mailing list
Infos at listes.koha-fr.org
https://listes.koha-fr.org/cgi-bin/mailman/listinfo/infos