KohaBulac

Toutes sortes de types

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.