Copyright 2004 Paul Poulain <paul.poulain AT free.fr>

This document is related to Koha and is licensed to you under the GNU General Public License version 2 or later (http://www.gnu.org/licenses/gpl.html).

Koha-related documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies.

You may create a derivative work and distribute it provided that you:

Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.

No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility.

All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.

L'une des contraintes majeures de l'équipe de développement de Koha est de fournir une application qui puisse être "multi-MARC".

Or, si toutes les déclinaisons MARC ont la même forme (l'iso2709), la signification de chaque champ/sous champ diffère totalement d'une déclinaison à une autre.

Par exemple, en UNIMARC, le champ 200$a contient le titre.

En MARC21, le titre est dans la zone 245$a.

Le 245$a en UNIMARC contient ... rien (la zone n'existe pas !)

Bref, il n'est pas possible de manière simple de gérer ces différences.

L'équipe de développement de Koha a donc choisi une méthode pour contourner ce problème, sans gréver les performances : tout est stocké en double

: sous la forme "MARC" (200$a, qui ignore le sens du champ) et sous la forme "décodée" (title qui ignore la position MARC).

Une table de paramétrage est mise en place lors de l'installation. Cette table contient non seulement les libellés de tous les champs et sous-champs UNIMARC (ou MARC21), mais également les liens entre les deux bases.

L'application, lors de l'ajout ou la modification des notices, se charge de stocker l'information deux fois.

Cela augmente fortement la complexité des opérations d'ajout/modification des notices. Mais simplifie d'autant les opérations de recherche et de lecture. Comme dans un SIGB 90% des accès sont des recherches et moins de 10% des ajouts/modifications, la rapidité de l'application s'en trouve renforcée.

Par exemple, lors de l'affichage d'une liste de résultats à une requète, on récupère le "title" directement. Si on devait passer par la notice unimarc, on devrait récupérer toute la notice pour en extraire le seul titre !

Notez que Koha sait gérer différentes grilles de catalogage. Je vous conseille de peaufiner la première grille avant de créer les autres.

Pour l'instant, on ne s'occupe pas des autorités.

Selectionnez la grille de catalogage par défaut, et modifiez les champs les uns après les autres.

Pour chaque champ, vous pouvez préciser :

Pour chaque sous-champ, vous pouvez préciser :

Il y a également 3 options qui permettent de préciser les contraintes de saisie sur les sous-champs :

Vous pouvez laisser ces éléments, nous y reviendrons ultérieurement.

Vous pouvez ensuite aller dans le menu catalogage, et ajouter une nouvelle notice vierge. Vérifiez là que vous avez bien activé ce que vous souhaitiez.

Vous pouvez vérifier rapidement les connexions entre les bases MARC et non MARC à l'aide de

Koha >> Liens Koha <=> MARC-DB

Cet écran vous montre en un coup d'oeil les connexions entre tous les champs de la partie non-MARC et le champ/sous-champ MARC.

Vous pouvez également modifier les liens depuis cette interface, mais attention : chaque modification est faite dans TOUTES les grilles de catalogage.

Lorsque le script est terminé ou que vous l'avez interrompu, vous pouvez aller voir le résultat sur le catalogue.

En général, ce ne sera pas terrible. Cherchez un terme utilisé très fréquemment, et regardez si vous trouvez des notices d'exemplaires (dans la grille simplifiée comme dans la grille complète les exemplaires sont bien en évidence dans un "bloc" spécifique.

S'il n'y en n'a pas, vous devez reprendre le paramétrage de Koha pour les faire apparaitre.

Vérifiez aussi que les grilles "simplifiées" (non-MARC) et "complètes" (MARC) sont bien remplies.

S'il vous semble qu'il manque des sous-champs dans la grille MARC (en visualisation), deux cas sont possibles :

Si vous voyez dans la notice "complète" (MARC) des données qui ne se trouvent pas dans la notice "simplifiée" (non-MARC), c'est peut-être normal, peut-être pas.

En effet, le nombre de champs de la partie "non-MARC" est limité. On peut y trouver seulement :

Toutes ces zones sont NON répétables dans la partie "non-MARC" de la base, partie qui apparaît dans la vue simplifiée. Si la zone est répétée, seule la première valeur sera affichée, ou, dans certains cas, les zones seront séparées par le caractère |

Il y a également 3 zones supplémentaires, qui sont répétables :

Vous pouvez aussi lancer des requètes SQL sur la base pour effectuer quelques vérifications.

La requète suivante affiche tous les champs et sous champs avec leur usage. C'est utile pour détecter les erreurs de paramétrage de la grille de catalogage :

SELECT tab, tagfield, tagsubfield, count( * ) AS tot FROM marc_subfield_structure LEFT JOIN marc_subfield_table ON marc_subfield_table.tag = marc_subfield_structure.tagfield AND marc_subfield_table.subfieldcode = marc_subfield_structure.tagsubfield GROUP BY tab, tag, subfieldcode

Vous pouvez itérer les imports sur le catalogage jusqu'à avoir un résultat qui vous convienne.

Notez que le script bulkmarcimport.pl ne modifie en rien les notices bibliographiques.

Une migration est probablement une bonne raison de faire du nettoyage dans les notices, pour supprimer des choses inutiles ou en modifier d'autres pour être plus conformes à la norme.

Modifier le script bulkmarcimport.pl demande des connaissances assez approfondies en matière de Perl, et notamment dans la manipulation des notices MARC.

La manipulation des notices MARC passe par le package Perl MARC::Record.

Vous en trouverez la description à l'aide de Perldoc :

perldoc /usr/lib/perl5/site_perl/5.8.3/MARC/Record.pm

(le chemin est celui de ma machine Mandrake 10.0, il peut être différent selon votre distribution linux/unix)

Vous pouvez aussi trouver la même documentation sur le net :

http://marcpm.sourceforge.net/MARC/Record.html

et

http://marcpm.sourceforge.net/MARC/Field.html

MARC::Record permet de faire n'importe quelle manipulation sur la notice. Son seul défaut est la complexité de son interface. Mais cette complexité est imposée par la complexité de la norme iso2709.

Les listes de valeurs autorisées permettent de définir les valeurs possibles pour un sous-champ donné. C'est particulièrement utile pour les sous-champs qui ne peuvent contenir selon la norme qu'un nombre limité de valeurs.

On peut citer par exemple :

Nous allons voir comment activer les valeurs autorisées pour les langues.

Lorsque ce sera fait, le sous-champ ne sera plus une zone de saisie libre, mais une liste déroulante.

$KOHA/misc/migration_tools/buildLANG.pl

Je ne vous ferai pas l'affront de vous expliquer ce que sont les autorités selon la norme UNIMARC.

Koha sait gérer les autorités au format MARC (UNIMARC ou une autre déclinaison). Le présent chapitre vous apprendra comment paramétrer les différentes catégories de thésaurus/autorités, et comment migrer un thésaurus.

Koha >> Paramètres >> biblio structure

build6xx.pl, qui reconstruit le 606, avec la gestion des $x.

Les plugins sont des modules complémentaires qui permettent de réaliser toutes sortes de traitements pour aider à la saisie des notices bibliographiques (ou d'autorité)

Par exemple, pour UNIMARC, vous trouverez des plugins qui vons vous simplifier la vie pour :

Ajoutez un type d'autorité appelé impérativement EDITORS.
Le résumé sera [200a ][ / 200b]
le champ de report sera 200

200$a => ISBN
200$b => Editeur
200$c (répétable) => collections

Je dispose de quelques routines pour migrer une base Texto. Je ne les mets pas ici parce que chaque installation de Texto A ses propres déclarations de champ.

Mais l'exploitation d'un fichier d'ajout piloté Texto peut se résumer ainsi :

$/ = "";
while (<AJOUT_PILOTE>)
{
    my @fichier = split/\n/,$_; 
# print "taille fichier".$#fichier."\n";
    foreach my $ligne (@fichier) {
# on examine le contenu de la fichier
if ($ligne eq "") {# separateur de fichiers

}

my @mots = split(/\./, $ligne);
$mots[0] =~ s/ //g;
$last=$mots[0] if $mots[0];
$resul{$last}.=$mots[1]." ";
    }

# ok, on a l'enregistrement, on construit le MARC::Record.
my $newRecord = MARC::Record->new();

Ce bout de code va construire une table de hashage pour chaque notice. On peut ensuite en faire une notice iso2709, et l'importer normalement

$resul{ISBN} =~ s/-//g;
my $newField = MARC::Field->new(
  '010','','',
  'a' => $resul{ISBN},
);
$newRecord->insert_fields_ordered($newField);
$newField = MARC::Field->new(
  '011','','',
  'a' => $resul{ISSN},
);
newField = MARC::Field->new(
  '200','','',
  'a' => $resul{TIT},
  'b' => $resul{TYP},
  'e' => $resul{STI},
  'f' => $resul{AUT},
  'g' => $resul{NOT},
);
$newRecord->insert_fields_ordered($newField);
my ($bibid,$oldbibnum,$oldbibitemnum) = NEWnewbiblio($dbh,$newRecord,'') unless ($test_parameter);

Notez que le code qui précède ne traite pas des notices d'exemplaire (là, c'est vraiment trop spécifique)