Bernard vient de finaliser un premier import de test dans notre maquette Koha. Il a pour cela construit un certain nombre de moulinettes PERL. Le volume ? Cela représente la totalité des notices bibliographiques, d'autorités et d'exemplaire présentes au 1er mars dans notre SIGB Millennium, soit : environ 205 000 notices d'autorités879 259 notices bibliographiques1 087 547 notices d'exemplaires Le contenu ? Les données de notre maquette couvrent les 15 types d'alphabet reconnus par Unimarc (cf. 100$a, positions 34-35) plus l'alphabet tibétain (5 notices bibliographiques pour l'instant). 382 langues sont présentes dans ce catalogue. Comment ? Les données sont consultables sur notre maquette à l'adresse suivante : http://koha.bulac.fr. Vous pouvez plus particulièrement voir ce que donnent nos données dans les différents alphabets en saisissant le critère title-script=code de l'alphabet (cf. liste dans 100$a, positions 34-35) dans la zone de recherche simple. NB : Pour le tibétain le code de l'alphabet est zz (autres) parce qu'il n'est pas encore reconnu par UNIMARC, mais cela viendra :o) Pour terminer... Je tenais tout particulièrement à féliciter Bernard pour la qualité du travail accompli...la route est encore longue vers un chargeur SUDOC opérationnel mais je ne doute pas qu'il y arrivera !!!

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 !!!