Koha BULAC

Un des plus gros morceaux de notre future reprise de données concerne les données d’exemplaires. En attendant l’arrivée de la version 3.2 et les changements sur la structure des données d’exemplaires qu’elle devrait nous apporter (cf. wiki Koha) ; le chargement automatiquement des données d’exemplaires dans Koha se fait à partir de la zone 995 des notices bibliographiques. Dans un contexte SUDOC dans lequel se trouvera notre application Koha, la structure de cette zone 995 est censée être conforme aux préconisations de la recommandation 995. Or, j’ai constaté que cela n’était pas toujours le cas. Un travail de redéfinition cette zone 995 de manière plus cohérente avec la dite recommandation et nos besoins de reprise de données d’exemplaires a donc été fait en collaboration avec Bernard. J’ai fait une synthèse de ce travail dans un document que vous pouvez télécharger ici. Vous y trouver à la fois notre première version de notre structure de données d’exemplaires Koha et des commentaires sur les « digressions » constatées par rapport à la recommandation 995. Tous vos commentaires sont les bienvenus !!!

Les discussions animées qui ont eu lieu entre Corinne et moi-même sur la question des « types de documents » semblent nous avoir menés à une solution satisfaisante et fonctionnelle.L'idée est de pouvoir utiliser une typologie des « catégories de prêt » pour définir les règles de prêt, qui soit indépendante du type de document ou plutôt du « type de support » qui sert à filtrer les requêtes dans la recherche avancée. Deux paramètres système permettent de gérer cette problématique : item-level_itypes, qui détermine si les règles de prêt sont basées sur le « type » de document défini au niveau de la notice bibliographique (champ itemtype de la table biblioitems de la base de données), ou bien au niveau de l'exemplaire (champ itype de la table items de la base de données). Nous avons choisi le niveau exemplaire, afin que plusieurs exemplaires du même ouvrage puissent obéir à des règles de prêt distinctes. advancedSearchTypes, qui détermine si les catégories de filtrage offertes pour la recherche avancée sont celles du champ itype de l'exemplaire (catégories de prêt), ou du champ ccode de l'exemplaire (type de collection). Nous avons choisi le ccode, pour que les catégories proposées à la recherche correspondent à ce que l'on entend généralement par « type de document » (ou plutôt type de support...), et surtout pas les catégories de prêt. Deuxième aspect du problème : les champs itype et ccode sont des champs de la base de données ; mais à quoi doivent-ils correspondre dans nos notices ? Le ccode, le « type de document » (ou plutôt le type de support ?) est de manière relativement évidente saisi dans le 200$b, au niveau bibliographique. Nous utiliserons donc une liste de valeurs identique pour le 995$r (type de document et support matériel, conformément à la recommandation 995). Il faudra nous assurer, lors des chargements de notices, que le 200$b y sera reporté. Lors de la création manuelle d'exemplaire, une valeur pourra être choisie dans la liste. Le itype, autrement dit nos catégories de prêt, sera quant à lui renseigné dans le 995$y, spécifiquement dédié à cet usage. (La zone 995, si je comprends bien, ne sert en fait que de « véhicule MARC » pour les données d'exemplaires, et ne porte pas réellement de sens en elle-même. D'ailleurs la version 3.2 de koha devrait autoriser une très grande souplesse d'utilisation de cette zone 995, avec la possibilité de définir et d'utiliser plusieurs schémas de mappage entre les sous-zones du 995 et les champs SQL de la table des exemplaires.) Dernière couche : pour que le tout fonctionne, les index ont été nettoyés. mc-ccode (ou ccode) indexe désormais les 995$r et 200$b. mc-itype (ou itype) indexe les 995$y, à savoir les types de documents pour la circulation. Ouf.

A l'occasion d'un projet de migration vers un logiciel libre, souvent bien démuni, se retrouve le chef de projet... quand il s'agit de produire des documents qui doivent permettre d'organiser l'information/formation de ses utilisateurs internes ainsi que le suivi/la validation des paramétrages/développements du futur applicatif. Note technique ? La note technico-fonctionnelle est à mon sens un bon moyen de commencer mine de rien l'information/formation des utilisateurs avant de les jeter dans le grand bain des journées marathon de formation ("cliquez ici", "saisissez là", "n'oubliez pas de", etc.) et de leur fournir des supports de formation plus consistants. La première de cette note version bulacienne est une note sur la gestion des réservations de documents dans Koha. Vous pouvez la télécharger ici. Dossier de paramétrage ? Quand au dossier de paramétrage, il peut sembler parfois bien fastidieux à remplir surtout quand les paramétrages sont assurés en interne ; mais de quel autre moyen disposons-nous pour nous assurer de la cohérence de nos futurs paramètres/développements et gagner en efficacité lors des phases de recettage ? Un brainstorming intensif au sein du groupe de travail communication de la BULAC nous a permis de peaufiner une première version du dossier de paramétrage pour le module de communication. Je mets une version vierge de ce document à votre disposition. Là encore il suffit de cliquer ici pour télécharger le fichier... Quelle version de Koha pour quels paramètres? Pour finir, au cas cela ne serait pas assez clair dans les documents joints, la version concernée de Koha est la 3.00...certains paramètres tels que nous les présentons dans le dossier de paramétrage sont soit à venir dans la 3.2 (ex : pénalité de retard en jour) soit restent encore à faire (ex : gestion de la réservation des salles). Bonne lecture !!!

Je mets ici à disposition de ceux qui le souhaitent, notre paramétrage actuel sur la structure des tables et grilles de saisie d’autorité UNIMARC/SUDOC. Le fichier à télécharger contient un export csv de : authorised_values (une pour les listes unimarc et une autre pour les listes autorités), auth_subfield_structure (étiquettes), auth_tag_structure (zones) et auth_types (type d’autorités) Mon souci a été avant tout d’être conforme au format actuellement en cours (version 2004 diffusée sur le site de la BNF) ; tout en restant le plus près possible du SUDOC avec l’espoir de faciliter nos futurs travaux de paramétrage sur les transferts réguliers via le très attendu chargeur SUDOC. Ainsi, dans le schéma que je propose, c'est un même type d'autorité "auteur personne physique" qui est utilisé que nous soyons en 600 ou en 71X. J’ai aussi pris le parti de créer de nouvelles tables d'autorité moins communément utilisées comme celle des Lieu d'édition car on ne sait jamais cela peut toujours servir. Ce qui au final, donne les types d'autorités suivantes : TA : Nom de familleTB : Collectivité/CongrèsTD : Nom communTE : Lieu d'éditionTF : Forme/GenreTG : Nom Géographique ou de territoireTM : Nom de marqueTP : Nom de personneTQ : Auteur/TitreTR : Auteur/Rubrique de classementTU : Titre Uniforme Pour finir, j’ai également ajouté quelques zones propres au format UNIMARC/SUDOC (ex : zone 128 pour les titres uniformes). Reste un travail sur la modification ou la création d’un certain nombre de plugins…toutes les bonnes volontés partageuses sont les bienvenues !!!