====== Comprendre le processus de construction d'une collection ======
Les utilisateurs finals de Greenstone peuvent construire des collections à l'aide du Collector, décrit dans la section [[?do=search&id=making_greenstone_collections @fr:manuals:User|making_greenstone_collections]] du Guide de l'utilisateur de la bibliothèque numérique Greenstone. Il facilite beaucoup la construction de collections sur le modèle de collections existantes, mais avec des contenus nouveaux. Cependant, il n'est pas réellement possible d'utiliser le Collector pour créer des collections avec des structures complètement nouvelles. Le Collector vous invite bien à éditer le fichier de configuration de la collection, qui gouverne cette structure de collection, mais il faut très bien connaître Greenstone pour pouvoir y effectuer des modifications radicales et efficaces. La présente section vous explique ce qu'il faut savoir pour opérer ainsi. Elle décrit également la structure de répertoire de Greenstone et le format interne de stockage des documents.
Tout au long de ce manuel nous supposerons que vous avez installé Greenstone sur votre ordinateur, que ce dernier fonctionne sous Windows ou sous Unix. Si tel n'est pas encore le cas vous devriez consulter le Guide d'installation de la bibliothèque numérique Greenstone. Le nom GSDLHOME représentera le répertoire racine de Greenstone, qui s'appelle %GSDLHOME% sur des systèmes Windows et $GSDLHOME sur des systèmes Unix. On détermine ce répertoire pendant la procédure d'installation.
===== Construire des collections depuis la ligne de commande =====
Commençons par décrire pas à pas les opérations nécessaires pour construire une collection depuis la ligne de commande, ce qui facilitera la compréhension du processus. Bien sûr, c'est le Collector qu'il faut plutôt utiliser pour construire des collections de manière plus agréable. La collection que nous prenons en exemple est l'une des collections distribuées sur le cédérom du logiciel Greenstone, et elle contient les pages web personnelles de nombreux contributeurs au projet de bibliothèque numérique de Nouvelle-Zélande et au logiciel Greenstone.
Les sections suivantes détaillent la construction sous Windows et sous Unix. En réalité, les deux se ressemblent presque complètement -- ne lisez que celle qui concerne votre système. Lorsque vous suivrez ces étapes, vous penserez peut-être que certaines opérations sont mystérieuses ou des arcanes, mais ne les en suivez pas moins fidèlement -- elles prendront tout leur sens plus tard. Suivra un bref résumé des différences entre les processus de construction sous les deux systèmes.
==== Construire des collections sous Windows ====
Le premier défi lors de la construction d'une collection à la ligne de commande sous Windows, c'est de parvenir à l'«interpréteur de commandes», qui est l'endroit où l'on tape les commandes. Dans le menu Démarrer ou le sous-menu Programmes, recherchez une ligne Invite MS-DOS, Invite DOS, ou Interpréteur de commandes. Si vous ne trouvez rien de tel, invoquez l'entrée Exécuter et tentez de taper command (ou cmd) dans la boîte de dialogue qui va apparaître. Si rien de tout ceci ne fonctionne, faites-vous assister par une personne qui s'y connaît, telle que votre administrateur système.
Rendez-vous dans le répertoire d'installation de Greenstone. En supposant que Greenstone a été installé dans l'emplacement standard, vous vous y rendrez en tapant:
cd "C:\Program Files\gsdl "
Les apostrophes doubles sont nécessaires à cause de l'espace dans Program Files. Tapez ensuite à l'invite:
setup.bat
Ce fichier de commandes (que vous pouvez lire si vous en avez la curiosité) explique au système où trouver les programmes de Greenstone((... Greenstone Sur des systèmes Windows 95/98, l'exécution de setup.bat peut échouer avec le message d'erreur Hors de l'espace d'environnement. Dans ce cas, éditez le fichier config.sys de votre système (qui se trouve habituellement sous Cconfig.sys) et ajoutez-y la ligne shell=C:command.com /e:4096 /p (où C représente la lettre de votre lecteur système) pour agrandir la taille de la table d'environnement. Il vous faudra redémarrer l'ordinateur pour que cette modification soit prise en compte. Répétez ensuite les étapes effectuées avant l'obtention de ce message d'erreur.)). Si lors de votre session à l'invite de commandes DOS, vous souhaitez revenir au répertoire racine de Greenstone, vous pourrez toujours ce faire en tapant cd "%GSDLHOME%" (ici encore, les apostrophes doubles sont nécessaires: elles sont dues à la présence d'espaces dans le nom de fichier). Si vous fermez votre fenêtre DOS et en ouvrez une autre, il faudra de nouveau invoquer le fichier setup.bat.
Vous avez maintenant la possibilité de compiler, construire, et construire à nouveau des collections. Le premier programme que vous allons examiner est le programme Perl mkcol.pl, dont le nom signifie «make a collection» (compiler une collection). Commencez par exécuter le programme en tapant perl -S mkcol.pl pour obtenir à l'écran une description de la syntaxe et une liste des arguments possibles -- si votre environnement Windows est configuré de manière à associer l'application Perl aux fichiers se terminant en .pl, il vous suffira de taper mkcol.pl pour obtenir ce résultat. Comme vous pourrez le lire dans le message qui apparaît, l'unique argument obligatoire est creator, qui sert à spécifier qui a construit la collection.
Utilisons cette commande pour créer les fichiers et sous-répertoires initiaux nécessaires à notre collection des pages personnelles des membres du projet de bibliothèque numérique Greenstone. Pour affecter à la collection le nom dlpeople («gens de la bibliothèque numérique» en anglais et en abrégé), j'ai tapé:
perl —S mkcol.pl —creator me@cs.waikato.ac.nz dlpeople
(on peut se contenter de taper//mkcol.pl -creator me@cs.waikato.ac.nz dlpeople//si Perl est associé aux extensions de fichiers en//.pl//). N'oubliez pas de remplacer mon adresse électronique par la vôtre!
Pour visualiser les fichiers nouvellement créés, on se déplace dans le répertoire de la collection en tapant:
cd "%GSDLHOME%\collect\dlpeople "
creator me@cs.waikato.ac.nz
maintainer me@cs.waikato.ac.nz
public true
beta true
indexes document:text
defaultindex document:text
plugin ZIPPlug
plugin GAPlug
plugin TEXTPlug
plugin HTMLPlug
plugin EMAILPlug
plugin ArcPlug
plugin RecPlug
classify AZList -metadata "Title"
collectionmeta collectionname "dlpeople"
collectionmeta iconcollection ""
collectionmeta collectionextra ""
collectionmeta .document:text "documents "
On peut alors lister le contenu du répertoire en tapant dir. Il devrait s'y trouver sept sous-répertoires: archives, building, etc, images, import, index, et perllib.
Il faut maintenant peupler la collection d'échantillons de documents. Les documents source de la collection dlpeople se trouvent sur le cédérom de la distribution Greenstone dans le répertoire collectdlpeople. Insérez d'abord le cédérom dans le lecteur (par exemple, sous D). Copiez ensuite le contenu du répertoire Dcollectdlpeople dans le répertoire import de la collection dlpeople. Vous pouvez procéder comme suit:
> sélectionner le contenu du répertoire dlpeople, et le faire glisser dans le répertoire import de la collection dlpeople.
Vous pouvez aussi taper la commande:
xcopy /s d:\collect\dlpeople\* import
Dans le répertoire etc de la collection, on trouve un fichier appelé collect.cfg. Ouvrez-le dans votre éditeur de texte préféré -- edit est basique mais communément disponible. Il devrait ressembler à ce que présente la figure , qui montre le fichier de configuration de collection créé par la commande:
Nous sommes désormais disposés à «importer» la collection. Il s'agit du processus qui apporte les documents dans le système Greenstone, en normalisant le format des documents, la manière dont les méta-données sont spécifiées, et la structure de fichiers de stockage des documents. Tapez perl -S import.pl à l'invite pour obtenir une liste de toutes les options du programme d'import. L'option -removeold s'assure que tout document préalablement importé est effacé dans un premier temps.
perl —S import.pl -removeold dlpeople
Ne vous inquiétez pas du texte qui défile: il s'agit d'un compte-rendu de la progression de l'import. Sachez que l'import de cette collection prend environ cinq minutes sur une machine à 1 GHz, et d'autant plus longtemps sur des machines plus lentes. Vous remarquerez qu'il n'est pas besoin de se trouver dans les répertoires collect ou dlpeople lors de la saisie de cette commande: la variable GSDLHOME étant déjà positionnée, le logiciel Greenstone peut trouver tous les fichiers nécessaires.
Modifions désormais quelque peu le fichier de configuration de la collection pour en personnaliser la représentation. Donnons d'abord un nom à la collection. Il sera utilisé par les navigateurs web en tant que page de titre pour la première page de la collection, et servira d'icone de collection si aucune image n'est fournie. Remplacez la ligne//collectionmeta collectionname "dlpeople"//par quelque chose comme//collectionmeta collectionname "Les membres du projet NZDL"//(NZDL est l'acronyme anglais du projet de bibliothèque numérique de Nouvelle-Zélande: New Zealand Digital Library Project).
Ajoutez une description de votre collection entre les apostrophes doubles de la ligne collectionmeta collectionextra "". Elle servira de texte pour le paragraphe à propos sur la page d'accueil de la collection. J'ai personnellement ajouté: "Cette collection comprend les pages personnelles de certains membres du projet NZDL.". Il est important de saisir cette description sous la forme d'une seule ligne dans l'éditeur -- ne soyez pas tenté de revenir à la ligne si vous arrivez sur le bord droit de la fenêtre, mais continuez simplement à taper! -- sans quoi le fichier de configuration ne pourra pas être correctement analysé. Si vous souhaitez que votre collection puisse être utilisée avec différentes interfaces de langues, il est possible de faire en sorte que cette description dépende de la langue choisie: ce procédé est décrit dans la section [[#configuration_file|configuration_file]], plus bas.
On peut retenir toute image utilisable dans un navigateur web en tant qu'icone de collection -- l'image que j'ai créée est présentée figure . Tapez l'emplacement de l'image entre les apostrophes doubles de la ligne//collectionmeta iconcollection ""//du fichier de configuration. On peut utiliser le raccourci _httpprefix_ pour remplacer le début d'une URL qui pointe vers une image située dans la zone de fichiers de Greenstone. Cela rend également les configurations plus portables. Vous pouvez par exemple taper://_httpprefix_/collect/dlpeople/images/icon.gif//si vous avez placé une image convenable dans le répertoire images de la collection (collectdlpeopleimages dans l'exemple qui nous intéresse).
Sauvegardez le fichier de configuration de la collection et refermez-le -- vous n'en aurez plus besoin au cours de ce didacticiel.
La prochain étape consiste à «construire» la collection, ce qui crée tous les index et fichiers qui lui permettront de fonctionner. Tapez perl -S buildcol.pl à l'invite pour obtenir la liste des options de construction de collection. Ces options sont présentées plus en détails dans la section section [[#import_and_build_processes|import_and_build_processes]]. Pour l'instant, nous nous contenterons des valeurs par défaut en tapant:
perl —S buildcol.pl dlpeople
à l'invite. Ici non plus, ne vous inquiétez pas en voyant défiler le compte-rendu de progression.
«Activez» la collection comme suit:
sélectionnez le contenu du répertoire building de la collection dlpeople, et faites-le glisser dans le répertoire index.
Vous pouvez aussi effacer le répertoire index (et tout ce qu'il contient) en tapant la commande:
rd /s index # on Windows NT/2000
deltree /Y index # on Windows 95/98
et rebaptiser ensuite le répertoire building en index avec:
ren building index
Enfin, tapez:
mkdir building
en vue de futures reconstructions. Il est important de taper ces commandes dans le bon répertoire (à la différence des commandes mkcol.pl, import.pl et buildcol.pl de Greenstone). Si le répertoire actuel n'est pas dlpeople, tapez://cd "%GSDLHOME%\collect\dlpeople"//avant de procéder à la séquence rd, ren, et mkdir donnée ci-dessus.
Vous devriez pouvoir accéder à la collection nouvellement construite depuis la page d'accueil de Greenstone. Il vous faudra réactualiser ou recharger cette page si elle était déjà ouverte dans votre navigateur, voire fermer le navigateur et le redémarrer (pour éviter les problèmes de tampon ou cache). Il se peut aussi, dans le cas où vous utilisez la version «Bibliothèque locale» de Greenstone, que vous deviez redémarrer le programme library. Pour visualiser la nouvelle collection, cliquez sur l'image. Le resultat devrait alors ressembler à la figure .
{{..:images:dev_fig_2.png?156x120&direct}}
Si nous nous résumons, l'ensemble des commandes tapées pour produire la collection dlpeople sont:
cd "C:\Program Files\gsdl " # assuming default location
setup.bat
perl —S mkcol.pl —creator me@cs.waikato.ac.nz dlpeople
cd "%GSDLHOME%\collect\dlpeople "
xcopy /s d:\collect\dlpeople\* import # assuming D drive
perl —S import.pl dlpeople
perl —S buildcol.pl dlpeople
rd /s index # on Windows NT/2000
deltree /Y index # on Windows 95/98
ren building index
mkdir building
==== Construire des collections sous Unix ====
Commencez par vous rendre dans le répertoire d'installation de Greenstone. Si par exemple Greenstone a été installé dans l'emplacement standard, dans votre répertoire personnel, vous vous y rendrez en tapant:
cd ~/gsdl
Tapez ensuite à l'invite:
source setup.bash # if you're running the BASH shell
source setup.csh # if you're running the C shell
Ces fichiers de commandes (que vous pouvez lire si vous en avez la curiosité) expliquent au système où trouver les programmes de Greenstone. Si lors de votre session à l'interpréteur de commandes, vous souhaitez revenir au répertoire racine de Greenstone, vous pourrez toujours ce faire en tapant cd $GSDLHOME.
Si vous ignorez le type d'interpréteur de commandes que vous utilisez, tapez echo $0 à l'invite -- cela affichera l'information recherchée. Si vous utilisez un autre interpréteur de commandes, demandez conseil à votre administrateur système.
Après avoir chargé le bon fichier de réglages, vous avez maintenant la possibilité de compiler, construire, et construire à nouveau des collections. Le premier programme que vous allons examiner est le programme Perl mkcol.pl, dont le nom signifie «make a collection» (compiler une collection). Commencez par exécuter le programme en tapant simplement mkcol.pl pour obtenir à l'écran une description de la syntaxe et une liste des arguments possibles. Comme vous pourrez le lire dans le message qui apparaît, l'unique argument obligatoire est creator, qui sert à spécifier qui a construit la collection.
{{..:images:dev_fig_3.png?389x409&direct}}
Utilisons cette commande pour créer les fichiers et sous-répertoires initiaux nécessaires à notre collection des pages personnelles des membres du projet de bibliothèque numérique Greenstone. Pour affecter à la collection le nom dlpeople («gens de la bibliothèque numérique» en anglais et en abrégé), j'ai tapé:
mkcol.pl —creator me@cs.waikato.ac.nz dlpeople
N'oubliez pas de remplacer mon adresse électronique par la vôtre!
Pour visualiser les fichiers nouvellement créés, on se déplace dans le répertoire de la collection en tapant:
cd $GSDLHOME/collect/dlpeople
On peut alors lister le contenu du répertoire en tapant ls. Il devrait s'y trouver sept sous-répertoires: archives, building, etc, images, import, index, et perllib.
Il faut maintenant peupler la collection d'échantillons de documents. Les documents source de la collection dlpeople se trouvent sur le cédérom de la distribution Greenstone dans le répertoire collect/dlpeople. Pour lire des informations sur un cédérom depuis Linux, insérez le disque dans le lecteur et tapez
mount /cdrom
à l'invite (cette commande peut varier d'un système à l'autre). Une fois monté, le cédérom peut s'utiliser comme tout autre répertoire; vous pouvez donc taper ls /cdrom/collect. Voilà qui devrait révéler un répertoire dlpeople sur le cédérom.
Copiez ensuite le contenu du répertoire /cdrom/collect/dlpeople dans le répertoire GSDLHOME/collect/dlpeople/import. Pour ce faire, tapez la commande:
cp —r /cdrom/collect/dlpeople/* import/
puis tapez
umount /cdrom
pour fermer le lecteur de cédérom.
Dans le répertoire etc de la collection, on trouve un fichier appelé collect.cfg. Ouvrez-le dans votre éditeur de texte préféré -- emacs est un éditeur populaire sous Linux.Il devrait ressembler à ce que présente la figure 1, qui montre le fichier de configuration de collection créé par la commande://mkcol.pl -creator me@cs.waikato.ac.nz dlpeople//
Nous sommes désormais disposés à «importer» la collection. Il s'agit du processus qui apporte les documents dans le système Greenstone, en normalisant le format des documents, la manière dont les méta-données sont spécifiées, et la structure de fichiers de stockage des documents. Tapez import.pl à l'invite pour obtenir une liste de toutes les options du programme d'import. L'option -removeold s'assure que tout document préalablement importé est effacé dans un premier temps.
import.pl —removeold dlpeople
Ne vous inquiétez pas du texte qui défile: il s'agit d'un compte-rendu de la progression de l'import. Sachez que l'import de cette collection prend environ cinq minutes sur une machine à 1 GHz, et d'autant plus longtemps sur des machines plus lentes. Vous remarquerez qu'il n'est pas besoin de se trouver dans les répertoires collect ou dlpeople lors de la saisie de cette commande: la variable GSDLHOME étant déjà positionnée, le logiciel Greenstone peut trouver tous les fichiers nécessaires.
Modifions désormais quelque peu le fichier de configuration de la collection pour en personnaliser la représentation. Donnons d'abord un nom à la collection. Il sera utilisé par les navigateurs web en tant que page de titre pour la première page de la collection, et servira d'icone de collection si aucune image n'est fournie. Remplacez la ligne//collectionmeta collectionname "dlpeople"//par quelque chose comme//collectionmeta collectionname "Les membres du projet NZDL"//(NZDL est l'acronyme anglais du projet de bibliothèque numérique de Nouvelle-Zélande: New Zealand Digital Library Project).
Ajoutez une description de votre collection entre les apostrophes doubles de la ligne collectionmeta collectionextra "". Elle servira de texte pour le paragraphe «à propos» sur la page d'accueil de la collection. J'ai personnellement ajouté: "Cette collection comprend les pages personnelles de certains contributeurs au projet NZDL.". Il est important de saisir cette description sous la forme d'une seule ligne dans l'éditeur -- ne soyez pas tenté de revenir à la ligne si vous arrivez sur le bord droit de la fenêtre, mais continuez simplement à taper! -- sans quoi le fichier de configuration ne pourra pas être correctement analysé. Si vous souhaitez que votre collection puisse être utilisée avec différentes interfaces de langues, il est possible de faire en sorte que cette description dépende de la langue choisie: ce procédé est décrit dans la section [[#configuration_file|configuration_file]], ci-dessous.
On peut retenir toute image utilisable dans un navigateur web en tant qu'icone de collection -- l'image que j'ai créée est présentée figure . Tapez l'emplacement de l'image entre les apostrophes doubles de la ligne//collectionmeta iconcollection ""//du fichier de configuration. On peut utiliser le raccourci _httpprefix_ pour remplacer le début d'une URL qui pointe vers une image située dans la zone de fichiers de Greenstone. Cela rend également les configurations plus portables. Vous pouvez par exemple taper://_httpprefix_/collect/dlpeople/images/icon.gif//si vous avez placé une image convenable dans le répertoire images de la collection (collect/dlpeople/images dans l'exemple qui nous intéresse).
Sauvegardez le fichier de configuration de la collection et refermez-le -- vous n'en aurez plus besoin au cours de ce didacticiel.
La prochain étape consiste à «construire» la collection, ce qui crée tous les index et fichiers qui lui permettront de fonctionner. Tapez buildcol.pl à l'invite pour obtenir la liste des options de construction de collection. Ces options sont présentées plus en détails dans la section section [[#import_and_build_processes|import_and_build_processes]]. Pour l'instant, nous nous contenterons des valeurs par défaut en tapant:
buildcol.pl dlpeople
à l'invite. Ici non plus, ne vous inquiétez pas en voyant défiler le compte-rendu de progression.
«Activez» la collection en déplaçant toutes les données qui viennent d'être placées dans le répertoire building vers le répertoire index. Si vous avez déjà construit cette collection de par le passé, commencez d'abord par enlever l'ancien répertoire index avec la commande:
rm —r index/*
(en supposant que vous vous trouvez alors dans le répertoire dlpeople). Puis tapez
mv building/* index/
|< - 265 265 >|
| **Windows** | **Linux** |
| Exécuter//setup.bat//pour rendre disponibles les programmes de Greenstone | Charger//setup.bash//ou//setup.csh//pour rendre les programmes disponibles |
| Copier les fichiers depuis le cédérom en utilisant le gestionnaire de fichiers graphique ou des commandes DOS | Copier les fichiers depuis le cédérom en utilisant//mount//et d'autres commandes Unix |
| L'ancien index de collection est remplacé en tapant//rd /s index//puis//ren building index//suivis de//mkdir building//, ou en utilisant le gestionnaire de fichiers graphique | L'ancien index de collection est remplacé en tapant//rm —r index/*//puis//mv building/* index// |
Vous devriez pouvoir accéder à la collection nouvellement construite depuis la page d'accueil de Greenstone. Il vous faudra réactualiser ou recharger cette page si elle était déjà ouverte dans votre navigateur, voire fermer le navigateur et le redémarrer (pour éviter les problèmes de tampon ou cache). Pour visualiser la nouvelle collection, cliquez sur l'image. Le resultat devrait alors ressembler à la figure .
Si nous nous résumons, l'ensemble des commandes tapées pour produire la collection dlpeople sont:
cd ~/gsdl # assuming default Greenstone in home directory
source setup.bash # if you're running the BASH shell
source setup.csh # if you're running the C shell
mkcol.pl —creator me@cs.waikato.ac.nz dlpeople
cd $GSDLHOME/collect/dlpeople
mount /cdrom # assuming this is where CD-ROM is mapped to
cp —r /cdrom/collect/dlpeople/* import/
umount /cdrom
import.pl dlpeople
buildcol.pl dlpeople
rm -r index/*
mv building/* index
==== Différences entre Windows et Unix ====
Les processus de construction de collection sont très similaires sous Unix et sous Windows, mais quelques petites différences demeurent, différences que nous avons résumées dans la table .
===== Les répertoires de Greenstone =====
La figure montre la structure du répertoire GSDLHOME. La table donne une brève description du contenu de chacun des répertoires représentés dans le diagramme. Certains répertoires seront plus détaillés plus loin dans le manuel -- utilisez le guide des sections de la table pour savoir où aller chercher des informations supplémentaires.
{{..:images:dev_fig_4.png?415x143&direct}}
|< - 132 331 66 >|
| | **Contenu** | Section |
| //bin// | Code exécutable, comprenant des binaires dans le répertoire portant le nom de votre système d'exploitation. | — |
| //bin/script// | Scripts Perl utilisés pour la création et la construction de collections (tels que//import.pl//et//buildcol.pl//). Pour obtenir une description de ces programmes, tapez leur nom à l'invite de commandes. | 1.3 |
| //perllib// | Modules Perl utilisés au moment de l'import et de la construction (tels que les greffons, ou//plugins//) | 2.1 |
| //perllib/plugins// | Code Perl pour les greffons (//plugins//) de traitement de documents. | 2.1 |
| //perllib/classify// | Code Perl pour les classificateurs (tels que le code AZList, qui crée une liste de documents en se basant sur l'ordre alphabétique d'un attribut.) | 2.2 |
| //cgi-bin// | Tous les scripts CGI de Greenstone, qui seront déplacés vers le répertoire//cgi-bin//du système. | — |
| //tmp// | Répertoire utilisé par Greenstone pour le stockage des fichiers temporaires. | — |
| //etc// | Fichiers de configuration, journaux d'initialisation et d'erreur, bases de données d'autorisation des utilisateurs. | — |
| //src// | Code C++ utilisé pour servir des collections sur un serveur web. | 3 |
| //src/colservr// | Code C++ pour servir des collections—pour répondre aux requêtes et ce genre de choses. | [[#protocol|protocol]] |
| //src/recpt// | Code C++ pour obtenir des requêtes depuis l'interface utilisateur et mettre en forme les réponses aux requêtes pour cette interface. | 3.9 |
| //packages// | Code source des paquetages logiciels externes à Greenstone mais utilisés par ce dernier. | 2.5 |
| //packages/mg// | Code source de MG, logiciel de compression et d'indexation utilisé par Greenstone. | 2.5 |
| //mappings// | Tables de correspondance Unicode (comme par exemple pour le jeu de caractères chinois GB). | — |
| //macros// | Les fichiers de macros utilisés pour l'interface utilisateur. | 2.4 |
| //collect// | Collections servies par cette copie de Greenstone. | 1.1 |
| //lib// | Code C++ utilisé à la fois par le serveur de collection et par le réceptionniste. | 3.1 |
| //images// | Images utilisées dans l'interface utilisateur. | — |
| //docs// | Documentation. | — |
===== Les processus d'import et de construction =====
Dans le processus de construction de collection décrit à la section [[#building_collections_from_the_command_line|building_collections_from_the_command_line]], on utilise une commande pour importer des documents (import.pl) et une autre commande pour construire la collection (buildcol.pl). Nous détaillons dans la présente section ce que ces programmes font et les options qu'ils acceptent. Nous utiliserons la variable nom_col pour nous référer à la collection en cours de construction ou d'import.
Les processus d'import et de construction sont très similaires, ce qui explique le nombre d'options communes qu'ils comptent, options décrites dans la table (souvenez-vous que pour obtenir la liste des options acceptées par tout script Greenstone, il suffit de taper son nom seul, sans argument, à l'invite de commandes).
|< - 132 104 293 >|
| | **Argument** | **Fonction** |
| //-verbosity// | Nombre de 0 à 3 | Contrôle la quantité d'informations sur le processus qui sont affichées sur la sortie d'erreur standard: «0» en donne un peu, «3» en donne beaucoup. |
| //-archivedir// | Nom de répertoire | Spécifie où les fichiers d'archives de Greenstone sont stockés, c'est-à-dire où//import.pl//les enregistre et où//buildcol.pl//les trouve. La valeur par défaut est//GSDLHOME/collect/nom_col/archives//. |
| //-maxdocs// | Nombre >0 | Nombre maximal de documents à importer ou à construire. Option utile lors de tests de fichiers de configuration d'une nouvelle collection, ou de nouveaux greffons//plugins// |
| //-collectdir// | Nom de répertoire | Spécifie où la collection se trouve. La valeur par défaut est//GSDLHOME/collect// |
| //-out// | Nom de fichier | Spécifie un fichier où écrire tous les messages produits, le comportement par défaut étant de les afficher sur la sortie d'erreur standard (c'est-à-dire l'écran). Option utile lorsque l'on travaille avec des niveaux de débogage. |
| //-keepold// | Aucun | N'efface pas le résultat de l'ancienne opération d'import ou de construction. Dans le cas de l'import, ceci signifie que l'on n'efface pas le contenu du répertoire//archives//; dans le cas de la construction, ceci signifie que l'on n'efface pas le contenu du répertoire//building//. |
| //—debug// | Aucun | Affiche la sortie du greffon//plugin//sur la sortie standard. |
==== Le processus d'import ====
Le processus d'import a pour but principal de convertir les documents depuis leur format d'origine vers le format d'archivage de Greenstone utilisé de manière interne par Greenstone, et d'écrire un fichier de compte-rendu (archives.inf) qui sera utilisé lors de la construction de la collection. Le programme import.pl a besoin de connaître les greffons (plugins) à utiliser, et de savoir où trouver les fichiers des documents originaux. La table montre les options communes aux processus d'import et de construction; la table montre les options propres au processus d'import. L'option OIDtype mérite quelques explications. Chaque document dispose d'un identifiant d'objet associé, ou OID (Object IDentifier). La meilleure façon de calculer un tel identifiant est de calculer une somme de contrôle («hacher») le contenu du document (c'est la méthode hash). Cependant, cette méthode étant lente, il est possible de choisir une solution plus simple, incrémentale, qui se contente de numéroter les documents séquentiellement dans leur ordre de fourniture (c'est la méthode incremental). Vous pouvez utiliser la méthode incremental pour aller plus vite, mais utilisez la méthode hash si vous avez l'intention d'ajouter des documents à votre collection plus tard, sans recommencer tout le processus d'import.
|< - 132 104 293 >|
| | **Argument** | **Fonction** |
| //-importdir// | Nom de répertoire | Spécifie où trouver les contenus à importer. La valeur par défaut est Defaults to//GSDLHOME/collect/nom_col/import//. |
| //-removeold// | Aucun | Efface le contenu du répertoire //archives//avant l'import. |
| //-gzip// | Aucun | Compresse l'archive de documents Greenstone produite par//import//(//ZIPPlug//doit faire partie de la liste des plugins greffons, et le programme//gzip//doit être installé sur votre machine). |
| //-groupsize// | Nombre >0 | Nombre de documents à rassembler dans un fichier d'archive de Greenstone. La valeur par défaut est 1 (c'est-à-dire que chaque fichier ne renferme qu'un document). |
| //—sortmeta// | Nom de balise de méta-données | Trie les documents par ordre alphabétique selon le contenu de la balise de méta-données. Cette fonctionnalité est désactivée si la collection compte plus d'un groupe (c'est-à-dire que//groupsize//>1). |
| //-OIDtype// | //hash//ou
//incremental//
| Méthode de création des //OIDs//pour les documents://hash//calcule une somme de contrôle du contenu mais est lente;//incremental//se contente d'affecter des numéros de documents de manière séquentielle, elle est donc plus rapide. |
{{..:images:dev_fig_5.png?402x379&direct}}
La figure représente le processus d'import tel qu'implémenté par le programme import.pl. Chaque ovale représente un module utilisé pour mener à bien les tâches relatives à une partie spécifique du système Greenstone. On peut trouver tous ces modules dans le répertoire GSDLHOME/perllib.
Pour l'étape 3, remarquez que des variables d'import telles que importdir et archivedir peuvent être positionnées dans le fichier de configuration de la collection ou depuis la ligne de commande. Si elles sont positionnées dans la ligne de commande, toute valeur spécifiée dans le fichier de configuration sera ignorée.
L'étape 6 voit la création du fichier d'information d'archives (archives.inf).
L'étape 7 crée un objet qui saura où sauvegarder les documents, et qui suivra toute instruction particulière de sauvegarde (telle que sortmeta, qui trie les documents selon une balise de méta-données spécifiée).
La plupart du travail effectué par le processus d'import est en fait accompli par les greffons (plugins), qui sont appelés par le module plugin. Ce module met en place un pipe-line des greffons spécifiés dans le fichier de configuration de collection. Il gère aussi l'écriture des documents d'archive de Greenstone (en utilisant un objet document).
==== Le processus de construction ====
Lors du processus de construction le texte est compacté, et les index de corps du texte spécifiés dans le fichier de configuration de collection sont créés. De plus, les informations relatives à la collection qui apparaîtront sur le web sont pré-calculées et incorporées dans la collection -- il s'agit par exemple des informations relatives aux icones et aux titres, ainsi que des informations produites par des classificateurs. Le programme buildcol.pl partage de nombreuses options avec import.pl; elles sont détaillées dans la table . La table présente les options qui lui sont propres.
|< - 132 104 293 >|
| | **Argument** | **Fonction** |
| //-builddir// | Nom de répertoire | Spécifie où trouver le résultat de la construction (la valeur par défaut est//GSDLHOME/collect/nom_col/building//). |
| //-index// | Nom d'index (ex.
//section:Title//)
| Spécifie quels index construire. La valeur par défaut est l'ensemble des index indiqués dans le fichier de configuration de la collection. |
| //-allclassifications// | Aucun | Empêche le processus de construction d'effacer les classifications qui ne contiennent aucun document (comme par exemple la classification «X» dans les titres si aucun document n'a un titre commençant par la lettre «X»). |
| //-create_images// | Aucun | Crée automatiquement les icones de collection (pour utiliser ceci, il faut avoir installé GIMP et le module Perl Gimp). |
| //-mode// | //all//,
//compress_text//,
//infodb//, or
//build_index//
| Détermine ce que le processus de construction doit faire (la valeur par défaut est//all//). Le mode//All//effectue une construction complète,//compress_text//se contente de compacter le texte du document,//infodb//crée une base de données des informations relatives à la collection—nom, fichiers, fichiers associés, informations de classification etc.—et//build_index//construit les index spécifiés dans le fichier de configuration de collection ou à la ligne de commande. |
| //—no_text// | | Ne stocke pas de texte compacté. Cette option est utile pour minimiser la taille des index construits si l'on souhaite toujours afficher les documents originaux au moment de l'exécution. |
{{..:images:dev_fig_6.png?308x234&direct}}
Le diagramme de la figure représente l'exécution du programme buildcol.pl. De nombreuses étapes sont communes avec le processus d'import. La première étape qui diffère est l'étape 4 (à gauche sur la figure). Cette étape n'est effectuée que si l'option create_images a été activée. Les images sont alors créées et consignées dans le fichier de configuration de collection à l'aide d'une fonction du script buildcol.pl. Pour que ceci fonctionne correctement, il faut avoir installé et configuré convenablement GIMP (GNU Image-Manipulation Program, programme de manipulation d'images de GNU) et le module Perl Gimp. Il faut aussi disposer d'un accès en écriture (et en lecture) sur le fichier de configuration de collection.
L'étape 5 contrôle d'abord l'existence ou non d'une procédure de construction propre à la collection. Certaines collections impliquent des traitements particuliers au moment de la construction, auquel cas il faut écrire un constructeur propre à la collection et le placer dans son répertoire perllib, sous le nom de la collection auquel on aura concaténé la chaîne «builder» (constructeur). Les constructeurs propres aux collections héritent de mgbuilder. Dans l'étape 5 le constructeur (qu'il s'agisse du constructeur par défaut ou d'un constructeur propre à la collection) est initialisé avec des informations telles que le nombre de documents à inclure, s'il faut ou non garder l'ancienne version de la collection, et où les répertoires building et archive sont localisés.
L'étape 6 est l'étape de construction, au cours de laquelle le texte des documents est compacté et indexé, les titres et les icones de collection sont stockés dans la base de données d'informations de la collection, et les structures de données sont construites pour supporter les classificateurs appelés par les greffons (plugins) de la collection. Toutes ces étapes sont menées à bien par mgbuilder (ou un constructeur propre à la collection), qui lui-même utilise MG (Managing Gigabytes (gérer les giga-octets), voir Witten//et al.//, 1999), logiciel de compression et d'indexation.
L'option mode permet de spécifier les portions de collection à construire, mais par défaut tout est construit: texte compacté, index, et base de données d'informations de la collection.
Pour publier une collection sur le web après construction, il faut la déplacer du répertoire building vers le répertoire index. Les collections ne sont pas construites directement dans le répertoire index car des collections volumineuses peuvent prendre plusieurs heures ou jours à construire. Il est important que le processus de construction n'affecte pas une copie existante de la collection tant qu'il n'est pas terminé.
===== Documents d'archives de Greenstone =====
Tous les documents source sont importés dans le système Greenstone après conversion dans le format d'archivage de Greenstone. C'est un style XML qui divise les documents en sections, et qui peut renfermer des méta-données au niveau du document ou de chaque section. Vous ne devriez pas avoir à créer des fichiers d'archives de Greenstone manuellement -- c'est le travail des greffons (plugins) de traitement de documents décrits dans le chapitre suivant. Il est cependant utile de comprendre le format des fichiers Greenstone, et c'est pourquoi nous le décrivons ici.
En XML, les mots-clefs sont entourés de chevrons pour le balisage. Le format d'archivage de Greenstone encode des documents déjà en HTML, et tout caractère <, >, ou " compris dans le texte original est échappé grâce à la convention standard <, >, et ".
]>
ec158e.txt
Freshwater Resources in Arid Lands
HASH0158f56086efffe592636058
cover.jpg:image/jpeg:
p07a.png:image/png:
Preface
This is the text of the preface
First and only chapter
Part 1
This is the first part of the first and only chapter
Part 2
This is the second part of the first and only chapter
La première partie de la figure donne la définition de type de document (DTD) pour le format d'archivage de Greenstone. Pour simplifier, un document est divisé en éléments Section, et les sections peuvent être imbriquées. Chaque Section renferme une Description qui comprend zéro ou plusieurs éléments Metadata (méta-données), et un élément Content (contenu), qui peut être vide, et qui renferme les données du document à proprement parler. À chaque élément Metadata on associe un attribut de nom (dont le nom est libre), et des données textuelles. En XML, PCDATA signifie «parsed character data» (données de type caractère analysées), c'est-à-dire du texte, tout simplement.
La deuxième partie de la figure montre un document simple écrit dans ce format, qui est un petit livre avec deux images associées. Le livre consiste en deux sections appelées respectivement Préface et Premier et unique chapitre, la deuxième section se divisant en deux sous-sections. Remarquez qu'il n'existe aucune notion de «chapitre» en tant que tel: un chapitre est simplement représenté comme une section de premier niveau.
|< - 130 400 >|
| //gsdlsourcefilename// | Fichier original à partir duquel on a généré le fichier d'archive de Greenstone |
| //gsdlassocfile// | Fichier associé au document (un fichier d'image par exemple) |
La balise dénote le début de chaque section de document, et la balise fermante correspondante () marque la fin de cette section. À la suite de chaque balise on trouve un élément . S'y trouve un nombre quelconque d'éléments . On peut ainsi associer différentes méta-données à différentes sections du document. La plupart de ces méta-données sont des types particuliers de méta-données tels que (titre). Les deux valeurs de l'attribut name (nom) montrées dans la table <tblref table_greenstone_archive_format_values> reçoivent de Greenstone un traitement particulier; toutes les autres sont considérées comme des méta-données attachées à cette section.
Dans certaines collections les documents dont divisés en pages. Ces dernières sont alors traitées comme des sections. Un livre peut par exemple disposer de sections de premier niveau qui correspondent à des chapitres, au sein desquels on trouvera un certain nombre de «sections» qui correspondront en réalité aux différentes pages du chapitre.
==== Méta-données de document ====
Les méta-données sont des informations de description associées à un document telles que l'auteur, le titre, la date, des mots-clefs, etc. Nous avons déjà signalé que les méta-données étaient stockées avec les documents. En observant la figure <imgref figure_greenstone_archive_format>, on remarque que les balises <Metadata> spécifient le nom du type de méta-données, et lui donnent une valeur. On a par exemple la ligne <Metadata name="Title">Premier et unique chapitre</Metadata> dans la deuxième partie de la figure <imgref figure_greenstone_archive_format_1> -- le titre d'un document est une méta-donnée qui lui est associée. On utilise le standard de méta-données Dublin Core pour définir des types de méta-données (Dublin Core, 2001; Weibel, 1999; Thiele, 1997).
La table <tblref table_dublin_core_metadata_standard> montre les types disponibles dans le standard, les étoiles signalant les entrées disponibles à ce jour sur le site web de la bibliothèque numérique de Nouvelle-Zélande. Si aucun type ne décrit correctement un certain type de méta-données, on peut aussi utiliser des types de méta-données absentes du standard Dublin Core. La collection «Demo» contient par exemple les méta-données how to (comment faire) et Magazine.
<tblcaption table_dublin_core_metadata_standard|Standard de méta-données></tblcaption>
|< - 133 94 305 >|
| **Nom** | **Balise de méta-données** | **Définition** |
| *Title | Title | Nom donné à la ressource |
| *Créateur | //Creator// | Entité principalement responsable de la fabrication du contenu de la ressource |
| *Thème et mots-clefs | //Subject// | Thème du contenu de la ressource |
| *Description | //Description// | Compte-rendu du contenu de la ressource |
| *Éditeur | //Publisher// | Entité responsable de la publication de la ressource |
| Contributeur | //Contributor// | Entité responsable de contributions au contenu de la ressource |
| *Date | //Date// | Date de publication de la ressource ou toute autre date importante associée à la ressource |
| Type de ressource | //Type// | Nature ou genre du contenu de la ressource |
| Format | //Format// | Représentation physique ou numérique de la ressource |
| *Identificateur de resource | //Identifier// | Référence univoque à la ressource dans un contexte donné: il s'agit de l'identifiant d'objet, ou//OID// |
| *Source | //Source// | Référence à une ressource d'où la présente ressource est tirée |
| *Langue | //Language// | Langue du contenu intellectuel de la ressource |
| Relation | //Relation// | Référence à une ressource liée |
| *Couverture | //Coverage// | Portée ou étendue du contenu de la ressource |
| Gestion des droits | //Rights// | Informations sur les droits attachés à la ressource ou dans celle-ci |
==== Au coeur des documents d'archive de Greenstone ====
Le format d'archivage de Greenstone impose peu de structure aux documents individuels. Les document sont divisés en paragraphes. Ils peuvent être divisés hiérarchiquement en sections et en sous-sections, que l'on peut imbriquer jusqu'à une profondeur arbitraire. À chaque document est associé un identifiant de document ou OID -- ces derniers servant aussi à identifier les sections et les sous-sections par l'ajout de numéros de sections et de sous-sections, séparés par des points, à l'OID du document. On se référera par exemple à la sous-section 3 de la section 2 du document HASHa7 sous la forme HASHa7.2.3.
Quand on lit un livre dans une collection de Greenstone, la hiérarchie des sections est reportée dans la table des matières du livre. Les livres de la collection «Demo», par exemple, disposent d'une table des matières hiérarchique qui montre des chapitres, des sections, et des sous-sections, comme l'illustre la figure <imgref figure_hierarchical_structure_in_the_demo_collection>. Les documents de la collection Computer Science Technical Reports (rapports techniques en informatique) ne disposent pas d'une structure hiérarchique de sections, mais chaque document est divisé en pages et on peut naviguer parmi les pages d'un document rapatrié. Les chapitres, les sections, les sous-sections, et les pages sont tous simplement implémentés en tant que «sections» au sein du document.
<imgcaption figure_hierarchical_structure_in_the_demo_collection|%!-- id:318a --%(a) %!-- id:318 --%Structure hiérarchique de la collection «Demo» ></imgcaption>
{{..:images:dev_fig_8a.png?373x251&direct}}
<imgcaption figure_hierarchical_structure_in_the_demo_collection_1|%!-- id:318c --%(b) %!-- id:318b --%Structure hiérarchique de la collection «Demo» ></imgcaption>
{{..:images:dev_fig_8b.png?373x251&direct}}
La structure de document sert aussi aux index de recherche. Il existe trois niveaux possibles d'index://document//,//section//, et//paragraphe//, bien que la plupart des collections ne les utilisent pas tous trois. Un index de//document//contient tout le document -- on peut l'utiliser pour trouver tous les documents contenant un ensemble particulier de mots (qui peuvent alors être éparpillés tout au long du document, loin les uns des autres). Lors de la création d'un index de//section//, toute portion de texte indexée s'étend d'une balise ouvrante <Section> à la prochaine balise <Section> -- un chapitre qui débute immédiatement par une autre section créera donc un document vide dans l'index. Les sections et les sous-sections sont traitées de la même manière: la structure hiérarchique de document est aplatie dans le but de créer des index de recherche. Les index de//paragraphe//considèrent chaque paragraphe comme un document à part entière, et sont utiles pour mener des recherches plus ciblées.
Le menu déroulant de la figure <imgref figure_hierarchical_structure_in_the_demo_collection_1> montre les index de recherche de la collection «Demo». Les chapitres et les titres des sections sont des index au niveau de la section. alors que les livres entiers représentent des index au niveau des documents. À l'instar des index de texte, on peut créer des index pour tout type de méta-données. Certaines collections proposent par exemple des exemples des titres de sections, comme illustré sur la figure <imgref figure_hierarchical_structure_in_the_demo_collection_1>.
===== Fichier de configuration de la collection =====
Le fichier de configuration de la collection gouverne la structure de la collection telle qu'elle est vue par l'utilisateur, ce qui permet d'en personnaliser l'apparence et l'ergonomie, ainsi que la manière dont ses documents sont traités et présentés. Le programme mkcol.pl crée un fichier de configuration de collection simple, en enregistrant votre adresse de courrier électronique en tant que créateur et mainteneur. Nous avons vu lors de l'exploration pas à pas du processus en ligne de commande que le créateur est un argument obligatoire, et il sera également enregistré en tant que mainteneur sauf si on fournit cette information séparément.
<tblcaption table_items_in_the_collection_configuration_file|Éléments du fichier de configuration de la collection></tblcaption>
|< - 132 397 >|
| ''creator'' | Adresse de courrier électronique du créateur de la collection |
| ''<!--i-->maintainer<!--/i-->'' | Adresse de courrier électronique du mainteneur de la collection |
| ''<!--i-->public<!--/i-->'' | La collection doit-elle être rendue publique ou non? |
| ''<!--i-->beta<!--/i-->'' | La collection est-elle une version bêta ou non? |
| ''<!--i-->indexes<!--/i-->'' | Liste des index à construire |
| ''<!--i-->defaultindex<!--/i-->'' | Index par défaut |
| ''<!--i-->subcollection<!--/i-->'' | Définit une sous-collection fondée sur des méta-données |
| ''<!--i-->indexsubcollections<!--/i-->'' | Spécifie quelles sous-collections indexer |
| ''<!--i-->defaultsubcollection<!--/i-->'' | L'//indexsubcollection//par défaut |
| ''<!--i-->languages<!--/i-->'' | Liste des langues dans lesquelles construire des index |
| ''<!--i-->defaultlanguage<!--/i-->'' | Index de langue par défaut |
| ''<!--i-->collectionmeta<!--/i-->'' | Définit des méta-données au niveau de la collection |
| ''<!--i-->plugin<!--/i-->'' | Spécifie un greffon (\lang{plugin}) à utiliser au moment de la construction |
| ''<!--i-->format<!--/i-->'' | Chaîne de formatage (notion expliquée ci-dessous) |
| ''<!--i-->classify<!--/i-->'' | Spécifie un classificateur à utiliser au moment de la construction |
Chaque ligne du fichier de configuration de collection est sur le modèle de la paire «attribut, valeur». Chaque attribut donne une information sur la collection qui affecte la manière dont elle sera représentée ou dont les documents seront traités. La table <tblref table_items_in_the_collection_configuration_file> montre les éléments que l'on peut inclure dans un fichier de configuration de collection, et à quoi sert chaque élément. En plus de ceux-ci, on peut aussi spécifier toutes les options de ligne de commande des programmes import.pl et buildcol.pl dans un fichier de configuration de collection. Par exemple, une ligne disant no_text true (true signifie «vrai» ou «activé» dans ce contexte) positionnera l'option no_text du programme buildcol.pl.
Le fichier de configuration de collection créé par le script mkcol.pl et présenté table <tblref table_collection_configuration_file_created_by_mkcd>, est très simple et ne contient que le strict minimum d'informations. Les lignes 1 et 2 proviennent de la valeur de creator fournie au programme mkcol.pl, et renferment les adresses de courrier électronique des responsables de la création et de la maintenance de la collection (qui peuvent être distincts).
<tblcaption table_collection_configuration_file_created_by_mkcd|Fichier de configuration de collection créé par//mkcd.pl//></tblcaption>
|< - 132 132 265 >|
| | **Attribute** | **Valeur** |
| ''1'' | ''creator'' | utilisateur@email.com |
| ''2'' | ''maintainer'' | utilisateur@email.com |
| ''3'' | ''public'' | True |
| ''4'' | ''beta'' | True |
| ''5'' | ''indexes'' | document:text |
| ''6'' | ''defaultindex'' | document:text |
| ''7'' | ''plugin'' | ZIPPlug |
| ''8'' | ''plugin'' | GAPlug |
| ''9'' | ''plugin'' | TextPlug |
| ''10'' | ''plugin'' | HTMLPlug |
| ''11'' | ''plugin'' | EMAILPlug |
| ''12'' | ''plugin'' | ArcPlug |
| ''13'' | ''plugin'' | RecPlug |
| ''14'' | ''classify'' | AZList metadata Title |
| ''15'' | ''collectionmeta'' | collectionname "collection d'exemple" |
| ''16'' | ''collectionmeta'' | iconcollection "" |
| ''17'' | ''collectionmeta'' | collectionextra "" |
| ''18'' | ''collectionmeta'' | .document:text "documents" |
La ligne 3 indique si la collection sera accessible au public après construction, et peut prendre les valeurs true (valeur par défaut, qui signifie que la collection sera publiquement disponible), ou false (qui signifie que cela ne sera pas le cas). C'est utile lorsque l'on construit des collections pour tester le logiciel, ou pour usage personnel. La ligne 4 indique si la collection est une version bêta ou non (la valeur par défaut ici aussi est true, ce qui signifie que la collection est une version bêta).
La ligne 5 détermine les index de collection à créer au moment de la construction: dans cet exemple, seul le texte du document sera indexé. Il existe trois niveaux possibles d'index://document//,//section//, et//paragraphe//(paragraph en anglais). Ils peuvent contenir les données au format texte (text) ou dans toute méta-donnée -- la plus commune est le titre (Title). On spécifie un index en précisant niveaudonnées. Par exemple, pour inclure également un index des titres de sections, il faudrait remplacer la ligne 5 par indexes documenttext sectionTitle. On inclut plusieurs types de données dans le même index en les séparant par des virgules. Pour créer par exemple un index au niveau de la section de titres, de texte et de dates, il faudrait avoir en ligne 5 indexes sectiontext,Title,Date. Le defaultindex défini en ligne 6 est l'index à utiliser par défaut sur la page de recherche de la collection.
Les lignes 7 à 13 spécifient les greffons (plugins) à utiliser lors de la conversion de documents vers le format d'archivage de Greenstone et lors de la construction de collections depuis des fichiers d'archives. La section [[#plugins|plugins]] détaille les greffons disponibles. L'ordre dans lequel les greffons sont listés est l'ordre dans lequel ils sont appliqués sur chaque document. Dès qu'un greffon a été capable de traiter un document, les suivants de la liste ne sont pas appelés.
La ligne 14 spécifie qu'il faudra créer une liste alphabétique des titres à des fins de navigation. Les structures de navigation sont construites par des «classificateurs». La section [[#classifiers|classifiers]] détaille les classificateurs et leurs possibilités.
Les lignes 15 à 18 servent à spécifier les méta-données au niveau de la collection. L'attribut collectionname définit la forme longue du nom de la collection, qui sera utilisée en tant que «titre» pour le navigateur web. L'attribut collectionicon donne l'URL de l'icone de la collection. Si comme ligne 18 on spécifie un index, la chaîne suivante sera affichée comme le nom de cet index sur la page de recherche de la collection. Une méta-donnée au niveau de la collection particulièrement importante est collectionextra, qui fournit un texte, entouré d'apostrophes doubles, décrivant la collection. Il servira de texte pour le paragraphe «à propos». On peut fournir différentes versions de l'attribut collectionextra pour différentes langues d'interface en ajoutant une spécification de langue entre crochets. Par exemple,
> collectionmeta collectionextra "collection description"
> collectionmeta collectionextra [l=fr] "description en français"
> collectionmeta collectionextra [l=mi] "description en maori"
Si la langue d'interface est positionnée à «fr» ou «mi», la version appropriée de la description sera affichée. Pour d'autres langues c'est la version par défaut qui apparaîtra.
Ce fichier de configuration de collection simple ne fournit aucun exemple de chaîne de formatage, ni des possibilités de sous-collection et de langue proposées par le fichier de configuration. Les chaînes de format seront couvertes plus en détail dans la section [[#formatting_greenstone_output|formatting_greenstone_output]], mais nous traiterons des sous-collections et des langues ici-même.
==== Sous-collections ====
Greenstone permet de définir des sous-collections et de construire des index séparés pour chacune d'entre elles. Une collection comprend par exemple un sous-ensemble important de documents appelé Food and Nutrition Bulletin (bulletin de la nourriture et de la nutrition). Nous l'utiliserons en tant qu'exemple.
Cette collection compte trois index, tous trois au niveau de la section: le premier pour toute la collection, le deuxième pour le Food and Nutrition Bulletin, et le troisième pour les documents restants. On peut lire ci-après les lignes concernées du fichier de configuration de collection:
<code>
indexes section:text
subcollection fn "Title/^Food and Nutrition Bulletin/i "
subcollection other "!Title/^Food and Nutrition Bulletin/i "
indexsubcollections fn other fn,other
</code>
Les lignes deux et trois définissent des sous-collections appelées fn, qui contiendra les documents du Food and Nutrition Bulletin, et other, qui contiendra les documents restants. Le troisième champ de ces définitions est une expression rationnelle de Perl qui identifie ces sous-ensembles en utilisant la méta-donnée Title: on recherche des titres qui commencent par Food and Nutrition Bulletin dans le premier cas, et les titres qui ne commencent pas ainsi dans le second (remarquez le "!" de négation). L'i final rend la reconnaissance de motif indépendante de la casse: majuscules et minuscules seront confondues. Le champ de méta-données, qui dans le cas présent est Title, peut être n'importe quel champ valide, ou Filename (nom de fichier) pour reconnaître le nom de fichier original du document. La quatrième ligne, indexsubcollections, spécifie trois index: un pour la collection fn, un pour la sous-collection other, et le troisième pour les deux sous-collections (c'est-à-dire pour tous les documents). Remarquez que si deux entrées avaient été spécifiées sur la première ligne, indexes, le nombre total d'index générés aurait été de six et non pas de trois.
Si une collection contient des documents dans des langues différentes, on peut construire des index séparés pour chaque langue. La langue est une méta-donnée; les valeurs sont spécifiées à l'aide des codes en deux lettres du standard ISO 639 représentant les noms des langues -- par exemple, en est l'anglais, fr le français, zh le chinois, et mi le maori. Étant donné que l'on peut spécifier des valeurs de méta-données au niveau de la section, on peut avoir certaines portions de documents dans des langues différentes.
Si par exemple le fichier de configuration contenait
<code>
indexes section:text section:Title document:text paragraph:text
languages en zh mi
</code>
les index de texte de sections, de titres de sections, de texte de document et de texte de paragraphe seraient créés en anglais, en chinois, et en maori -- pour un total de douze index. Si on ajoute quelques sous-collections, voilà qui augmente d'autant le nombre d'index, et d'une multiplication! Il faut prendre garde à la surenchère des index.
(On pourrait obtenir une telle spécification d'index avec subcollection plutôt qu'avec la fonctionnalité languages. Mais la syntaxe excluant la création de sous-collections de sous-collections, il serait alors impossible d'indexer chaque langue séparément dans chaque sous-collection.)
==== Recherche inter-collections ====
Greenstone propose une fonctionnalité de recherche transverse aux collections, qui permet d'effectuer une recherche parmi plusieurs collections à la fois, et de combiner les résultats en coulisses de manière à donner à l'utilisateur l'impression qu'il a mené sa recherche dans une unique collection unifiée. On peut rechercher tout sous-ensemble de collections: la page de Préférences laisse choisir quelles collections inclure dans les recherches.
On active la recherche inter-collections par une ligne
<code>
supercollection col _1 col _2 ….
</code>
où les collections impliquées sont appelées col_1, col_2, ... La même ligne devrait apparaître dans les fichiers de configuration de toutes les collections impliquées.