Date submitted: 06/08/2009 Une évaluation des fonctions multi-langue/multi-script dans Koha Naicheng Chang Centre d Education Générale, Université de Tatung, Taiwan Taipei, China ncchang@ttu.edu.tw Yuchin Tsai Centre National de Haute Technologie en Informatique, Laboratoires Nationaux en Recherche Appliquée, Taiwan Taipei, China Thomas@nchc.org.tw Traduction : Philippe Bourdenet Responsable informatique au SCD (Service Commun de la Documentation) de l'université du Maine; membre du Comité français UNIMARC et de la FULBI (Fédération des utilisateurs de logiciels pour bibliothèques) Meeting: 135. UNIMARC WORLD LIBRARY AND INFORMATION CONGRESS: 75TH IFLA GENERAL CONFERENCE AND COUNCIL 23-27 August 2009, Milan, Italy http://www.ifla.org/annual-conference/ifla75/index.htm Résumé : Les systèmes de gestion de bibliothèques ont été marqués par une récente tendance au logiciel libre. Les programmes informatiques utilisés en bibliothèque sollicitent un ensemble de standards universellement répandus à travers le monde, parmi ceux-ci, UNIMARC, qui a de nombreux dialectes. Cet article se penche sur la mise en œuvre d UNIMARC et de CMARC (Chinese MARC) dans Koha, l un des logiciels libres les plus largement établis. Il fera état des spécificités d UNIMARC et de CMARC absentes de MARC21, comme par exemple les zones de liens, montrera jusqu à quel point elles peuvent être gérées par Koha, et ce qui est nécessaire pour les mettre en œuvre si elles ne sont pas prises en compte. 1. Contexte L environnement des Systèmes Intégrés de Gestion de Bibliothèque (SIGB) a considérablement évolué ces dernières années. Une récente tendance a vu le développement des SIGB open source. Les bibliothèques se tournent vers des solutions open source principalement parce que plusieurs 1
systèmes libres de gestion de bibliothèque, tels Koha, sont considérés comme des systèmes assez modernes et matures pour pourvoir aux besoins des bibliothèques : les logiciels open source sont plus enclins à une adaptation pour aller au-devant des attentes spécifiques des bibliothèques ; ces fonctionnalités spécifiques proviennent de la communauté des utilisateurs qui ont géré des contrats ou des développements et ont contribué, si bien que d autres bibliothèques peuvent les utiliser et en bénéficier. De plus, les bibliothèques utilisant des logiciels open source ont des capacités de support plus étendues que celles qui utilisent des logiciels propriétaires (Breeding, 2007). Aujourd hui, un système de bibliothèque demande un plus haut niveau de traitement du texte que la plupart des autres systèmes d information car il a besoin de prendre en compte les signes diacritiques. L informatique a débuté aux Etats-Unis où le jeu de caractères basique sans signes diacritiques est utilisé de façon prédominante. Pourtant, on peut avoir besoin de savoir si eleve doit recouvrer sa forme élève ou pas. On doit être capable de distinguer eleve d élève. La situation devient encore plus complexe avec les alphabets non-latins. Unicode a été développé dans ce but. Un logiciel de gestion de bibliothèques utilise un certain nombre de normes qui sont presque universellement appliquées dans le monde des bibliothèques, si bien que les systèmes de chaque bibliothèque devraient les incorporer. L'un de ces standards, on peut dire le plus important puisqu'il permet la récupération de notices créées dans n'importe quelle bibliothèque dans le monde, est le format MARC ("Machine-Readable Cataloguing"). Malheureusement, il comporte divers dialectes, et l'un des plus intensivement utilisés dans le monde est le format UNIMARC (UNIversal MARC). A Taiwan, l'un des sous-dialectes de celui-ci, CMARC (Chineese MARC), est de loin le format MARC le plus employé au sein des bibliothèques. Le plus commun de tous ces dialectes est celui qui a été développé à l'origine par la Bibliothèque du Congrès aux Etats-Unis, aujourd'hui connu sous l'appellation MARC21. Toutes les distributions de logiciels libre sont susceptibles de mettre en application ce format, mais d autres dialectes ont de meilleures dispositions, puisqu ils ont été développés plus récemment que LC MARC/MARC21 Par exemple, UNIMARC introduit plus de souschamps, propose donc un plus haut niveau de granularité que MARC21 et offre différentes méthodes pour créer des relations, qui nécessiteraient une exécution séparée dans la plupart des logiciels. UNIMARC, avec sa troisième édition (2008), a été mis à jour récemment pour accueillir les dernières modifications survenues dans la structure des notices, communément acceptée au niveau international, afin de prendre en compte Unicode. En 2004, la Bibliothèque Centrale Nationale (Taiwan) a hébergé un groupe de travail non officiel sur Unicode dont l objectif était de trouver une solution aux problèmes provenant de l'utilisation interne de multiples codages notamment le Codage des Caractères Chinois pour l'echange d'informations (CCCII) et Big5, codages internes chinois plus largement répandus parmi les bibliothèques de Taiwan (Mao et Hsu, 2006). A l origine, Koha a été développé pour utiliser MARC21, qui est employé dans le monde anglophone. Dans le chapitre suivant, nous verrons l application d UNIMARC et CMARC dans Koha pour évaluer jusqu à quel point les diverses caractéristiques d UNIMARC et CMARC non présentes dans MARC 21, comme les blocs des liens avec d autres notices (par exemple la méthode pour lier une notice de périodique avec ses parutions suivantes ou antérieures) peuvent être supportées par Koha, et ce qui est nécessaire pour les développer si elles ne sont pas gérées. 2
A l origine, Koha a été mis en œuvre pour la Horowhenua Library Trust par Katipo Communications en 1999. Koha a été mis en production à la Nelson Library (Athens County, Ohio) à l automne 2003. D après Breeding (2008) Koha s est élevé au rang de premier SIGB open source, en nombre, à servir dans les bibliothèques, surtout dans des bibliothèques publiques, aux Etats-Unis. Koha en est seulement à son stade le plus précoce au Royaume Uni comme à Taiwan, mais les premiers développements dans ces deux pays sont prometteurs. 2. Une plate-forme Koha en UNIMARC/CMARC/MARC21 au banc d essai. La procédure de tests qui nous occupe consiste à prendre Koha comme s il s agissait de notre propre système de bibliothèque pour examiner les diverse caractéristiques des formats MARC, c'est-à-dire UNIMARC, CMARC et MARC21. Dans le banc d essai 24 notices bibliographiques en UNIMARC conformes à iso2709 et 100 notices en CMARC et en MARC21 ont été testées La définition de l ossature de Koha Avant de mettre Koha au travail, nous avons défini le schéma de champs et de sous-champs MARC avec les outils proposés par Koha. Actuellement, Koha propose officiellement par défaut les modèles MARC21 et UNIMARC. Il est possible de redéfinir l ossature du module de catalogage en fonction des pratiques de la bibliothèque. L équipe Koha de Taiwan a développé un modèle CMARC libre d emploi qui est en ce moment déployé dans la plupart des bibliothèques de Taiwan utilisant Koha (Mao, 2006). Un exemple d adaptation de CMARC est montré dans la figure 1 ci-dessous où dans la partie gauche nous voyons le format par défaut CMARC de Koha, et dans la partie droite un sous-champ $s qui a été ajouté dans le champ 700, et qui est ainsi affiché dans la notice du catalogue. La donnée contenue dans le sous-champ $s reste dans Koha même sans qu il ait été nécessaire de le redéfinir. Figure 1 : La redéfinition de l ossature de Koha en CMARC Dans la plate-forme d essai, nous nous sommes basés sur la troisième édition d UNIMARC (2008), la 4 e édition de CMARC révisée en 2001 et l édition 1999 de MARC21 mise à jour en 2008. 3
L import de notices MARC Nous n avons pas rencontré de difficultés en important des notices bibliographiques dans les trois formats MARC si ce n est que l encodage par défaut de Koha est UNICODE (ici, de l UTF-8), et qu à Taiwan, les codages les plus répandus sont CCCII et Big5. Un programme spécifique a été nécessaire pour importer dans Koha les notices bibliographiques en chinois et pour afficher proprement les données (Tsai, 2007). On peut voir un exemple des données importées dans la figure 2. Si l on clique sur le chiffre dans la colonne intitulée Bib, située le plus à droite, le système montre la notice au format MARC. Figure 2: Notices UNIMARC 4
Vue MARC et Vue Simple Les données bibliographiques peuvent être affichées au format MARC, dans une vue simplifiée ou au format ISBD, dans l interface du bibliothécaire comme dans l OPAC. Avant de charger les vues, nous avons défini des formats d affichage pour les champs et les sous-champs. Dans la figure 3 une notice UNIMARC propose 3 options d affichage : une Vue Normale, une Vue MARC et une Vue ISBD. Figure 3 : Vue ISBD d une notice UNIMARC Encodage de la langue et échange de données Il est essentiel d avoir connaissance des systèmes d encodage avant de travailler sur une plate-forme Koha. ISO 2709 définit la longueur des champs et cette longueur varie en fonction des caractères. Par exemple, les caractères chinois prennent 2 octets, à la différence des caractères occidentaux, ce qui occasionne un travail supplémentaire et ce qui demande un développement spécifique lorsque l on travaille avec Koha. Cette situation est partagée par les pays asiatiques, aussi bien par la Chine que par le Japon et la Corée. Dans la plate-forme d essai, nous avons testé trois formats MARC et montré que les bibliothèques ont besoin de définir l ossature MARC avant d importer leurs données, et le résultat obtenu prouve qu aucun des formats MARC ne présente de difficulté pour faire travailler Koha proprement. 3. Comparaison et évaluation Il y a un grand nombre de différences, assez subtiles, entre les formats mais ils sont tous très étroitement liés entre eux parce qu ils véhiculent tous les Règles de Catalogage Anglo-Américaines. Le développement d UNIMARC visait à s éloigner de la fiche de catalogue, ce qui est propre à MARC dès l origine : les étiquettes MARC sont généralement ordonnées comme dans une fiche de catalogue, avec une entrée principale, une description, des accès sujet, et d autres entrées additionnelles, dans cet ordre. UNIMARC dispose en plus d une hiérarchie logique où les étiquettes sont ordonnées par fonction. Après les identifiants et les zones de données codées, ( MARC21 commence avec les données codées, viennent ensuite les identifiants), nous trouvons la zone de description (ISBD), la zone de notes (comme dans l ISBD), la zone de liens (qui suit la zone de notes probablement parce que l on peut considérer la production d un lien comme une note), la zone de 5
sujet, et enfin le point d accès par nom en 700. Les étiquettes individuelles à l intérieur des blocs sont différentes. Cependant ces distinctions paraissent, en un sens, insignifiantes. Les questions concernant la granularité au niveau des sous-champs et les méthodes de gestion des liens sont plus importantes. Pour ce qui est de la mise en œuvre, les deux spécificités qui doivent impérativement être testées sont les techniques de liens et les champs de données codées. Les liens constituent un problème complexe. Les champs qui contiennent des données codées sont difficiles à démêler. Ils exigent un décompte soigneux des codes d entrée, et afin d éviter cette étape onéreuse, nous avons besoin d établir une méthodologie sur-mesure. Ces données sont très importantes pour les fonctions multi-script et multi-langage et sont mieux stockées en tant que données codées. Nous avons effectué un travail aussi important sur la définition de la langue au niveau des pages web, en vue de faciliter la récupération des informations par des moteurs de recherche, autant qu il est pertinent de définir la langue d un texte au niveau du catalogue. En outre, les utilisateurs finaux sont en général intéressés par l information sur la langue dans les références bibliographiques aussi bien que dans l œuvre originale. Ces données sont stockées sous leur forme codée. Si un système ne peut pas traiter un script, une transcription appropriée de l information est nécessaire pour assurer sa conversion dans un système capable de l interpréter, afin que l on puisse la retrouver. Comparaison A. Champs de données codées Nous avons testé les champs qui contiennent des données codées, c'est-à-dire ceux de longueur fixe, dans UNIMARC et CMARC, dans les zones 100, 101, 105, 110, 115, 116, 117, 120, 121, 125, 126, 128, 129, 130, 135, 140, 141 et dans MARC21 dans les zones 007 et 008. Nous avons découvert que dans la version de base de Koha, seuls se trouvent par défaut les champs 100, 101 et 105 avec un sous-champ $a pour UNIMARC et CMARC, comme indiqué dans le tableau 1, tandis que MARC 21 propose les champs complets 007 et 008 comme le montre la figure 4, par un clic sur l icône à l extrême fin de la ligne. Cela implique que les administrateurs système doivent rendre accessibles ces sous-champs en redéfinissant l ossature de Koha lorsque l on travaille avec UNIMARC ou CMARC, alors que tous les sous-champs de données codées sont déjà disponibles avec MARC21. Du point de vue de la mise en œuvre technique, c est un avantage de MARC21 lors du déploiement de Koha dans une bibliothèque car cela exige peu de travail supplémentaire. Etiquette Code de sous-champ Bibliothécaire 100 A Données générales de traitement 101 A Langue de la ressource 105 A Données codées sur les monographies textuelles Table 1: Les sous-champs par défaut d UNIMARC 6
Figure 4 : L écran de saisie des champs 007 et 008 en MARC21 B. Les champs liés Lorsque nous avons testé les champs liés dans les trois formats MARC, nous avons découvert que Koha ne fait défaut à aucun des formats. Par exemple il n existe pas de 4xx dans le jeu de champs par défaut d UNIMARC. Les utilisateurs doivent activer ces champs en redéfinissant l ossature. Cela peut provenir du fait que les champs de liens ne sont pas considérés comme des éléments principaux, comme les champs codés, lorsque le but poursuivi est l affichage des notices du catalogue de bibliothèque. Une autre hypothèse serait que les bibliothèques ne possédant pas beaucoup de publications en série n éprouvent pas le besoin d afficher les champs liés. Nous comprenons bien que certains pays qui utilisent UNIMARC n utilisent pas les champs liés. De plus, il existe d autres techniques, et pour que cela devienne opérationnel, il faudrait plus de programmation et de développements dans la mise en œuvre de Koha avec UNIMARC. La création de lien en temps réel est réalisée principalement par l administrateur. Si l on prend l exemple d UNIMARC, le sous-champ 410$d (Date de publication) est lié au sous-champ 210$d et le sous-champ 410$t (Titre) est lié à l un de ces trois sous-champs : 200$a, 225$a ou 500$a. Koha permet aux usagers de redéfinir les liens dans sa structure, en fonction des pratiques usitées dans l institution. Par ailleurs, le champ 481 (Est aussi relié dans ce volume) et ses sous-champs jouent un rôle réel dans la construction de liens en temps réel dans Koha. L exemple ci-dessous est tiré de nos notices bibliographiques. 7
<datafield tag="481" ind1=" " ind2="1"> <subfield code="1">001295852</subfield> <subfield code="a">loura, Lu?s Armando de</subfield> <subfield code="c">lisboa. -[s.n.,</subfield> <subfield code="d">d.l. 1956]</subfield> <subfield code="t">regula??o de avaria grossa pela arribada a Durban do N. M. "Benguela", em 12 de Agosto de 1952</subfield> <subfield code="5">ptbn: S.A. 5516//3 A.</subfield> </datafield> Evaluation Comme nous l avons vu au chapitre 3, UNIMARC dispose de plus d étiquettes pour l organisation hiérarchique que MARC21, du point de vue des systèmes de bibliothèque. MARC21 jouit d un avantage pour être mis en application dans Koha par rapport à UNIMARC ou CMARC. Cela est dû au fait que dans MARC21, les données codées les plus importantes sont prises en compte par les champs 007 et 008 et leurs sous-champs sont tous définis, tandis que dans UNMARC et CMARC, les données codées sont distribuées dans plus de 10 champs, et plus de 90% de leurs sous-champs ne sont pas définis. Peut-être que cela explique la raison pour laquelle Koha prend de l ampleur sur le marché américain, plus que dans d autres régions du monde. Du point de vue des institutions, les organisations qui disposent d une équipe technique suffisante pour assurer le support peuvent décider de ne pas adopter un système intégré de gestion de bibliothèque libre, mais pour les autres qui n ont pas les ressources en personnel technique nécessaire et qui veulent utiliser un système libre, MARC21 pourrait être leur premier choix si l on s en tient à l aspect système de Koha. Dans le chapitre Comparaison, nous avons expliqué que, bien que tous les champs liés ne soient pas présents dans les sous-champs par défaut de Koha, les institutions peuvent toujours les redéfinir en fonction de leurs besoins. Conclusion Koha est un système intégré de bibliothèque mature qui a de grands mérites. Ainsi, l'on peut affirmer que Koha propose bien par défaut les modèles MARC21 et UNIMARC. Cela implique que Koha est tout désigné pour utiliser aussi bien MARC21 qu UNIMARC, mais pas pour des formats multi-scripts comme CMARC, Japanese MARC ou Korean MARC qui vont nécessiter un développement spécifique. Pour les pays à plus faible niveau de développement des technologies de l information, un travail technique en matière de système intégré de bibliothèque est une chose complexe et demande, pour les institutions désireuses d une telle mise en œuvre, un certain degré d expertise en informatique, ce qui ne se trouve pas dans tous les pays en développement. Koha a déjà atteint un niveau substantiel de développement sur le marché des Etats-Unis, où MARC 21 est le format majoritairement en usage. Au Royaume Uni, même si certaines bibliothèques utilisent à présent MARC21, il en reste qui suivent encore le modèle UKMARC qui est plus intimement lié à UNIMARC dans la granularité de ses champs, ce qui est probablement la raison principale pour laquelle Koha est y est à peine en train de prendre son essor. A Taiwan, CMARC colle de près à UNIMARC, et, bien que la communauté d utilisateurs Koha de Taiwan fasse de gros efforts 8
basés sur le volontariat pour maintenir le logiciel et fournir aide et assistance aux institutions intéressées, celle-ci reste modeste et peu organisée. Nous conclurons que pour la mise en œuvre des formats UNIMARC et MARC21, ou même tout autre type de format MARC dans Koha, nous recommanderions un niveau de support commercial fondé sur le modèle de vente tel qu il existe sur le marché aux Etats-Unis. Bibliographie Breeding, Marshall, An Update on Open Source ILS, Computers in Libraries, 27(3): 27-29, 2007. Breeding, Marshall, The Viability of Open Source ILS, ASIS&T Bulletin, 35(2): 20-25, 2008. Mao, Ching-chen, Koha Taiwan, Google Groups, 2006, http://groups.google.com/group/kohataiwan, accessed at 20 March 2009. Mao, Ching-chen and Hsu, Ching-fen, Chinese MARC (Taiwan) and Its Bibliographic Database, World Library and Information Congress: 72nd IFLA General Conference and Council 20-24 August 2006, Seoul, Korea. Tsai, Yu-Chin, 2007, /trunk/cmarc/marc_to_utf8.pl - Koha Taiwan - Trac. http://trac.kohatw.org/koha/browser/trunk/cmarc/marc_to_utf8.pl. /trunk/cmarc/new_split.pl - Koha Taiwan - Trac. http://trac.koha-tw.org/koha/browser/trunk/cmarc/new_split.pl, accessed at 20 March 2009. 9