User Tools

Site Tools


legacy:manuals:fr:develop:getting_the_most_out_of_your_documents

Exploitez vos documents au maximum

On peut individualiser les collections pour rendre accessibles les informations qu'elles contiennent de diverses manières. Le présent chapitre décrit la manière dont Greenstone extrait l'information des documents et la présente à l'utilisateur: le traitement des documents (section plugins), les structures de classification (section classifiers), et les outils d'interface utilisateur (sections formatting_greenstone_output et controlling_the_greenstone_user_interface).

Greffons (plugins)

Les greffons analysent les documents importés et en extraient les méta-données. Par exemple, le greffon HTML convertit des pages HTML en format d'archivage de Greenstone et extrait les méta-données explicites dans le format de document – telles que les titres, entourés de balises <title></title>.

Les greffons sont écrits en Perl. Ils sont tous inspirés d'un greffon de base appelé BasPlug, qui effectue les opérations partout nécessaires, telles que créer un nouveau document d'archive de Greenstone avec lequel travailler, affecter un identifiant d'objet (OID), et gérer les sections d'un document. Les greffons se trouvent dans le répertoire perllib/plugins.

Pour en savoir plus sur un greffon particulier, tapezpluginfo.pl nom-de-greffonà l'invite de commandes (il vous faudra d'abord invoquer le script de réglages approprié si vous ne l'avez pas encore fait, et sous Windows il vous faudra taper perl -S pluginfo.pl plugin-name si votre environnement n'est pas réglé pour associer les fichiers se terminant en .pl à l'interpréteur Perl). Ceci affichera des informations relatives au greffon à l'écran – les options spécifiques qu'il accepte, et quelles options générales sont autorisées.

On peut facilement écrire de nouveaux greffons qui traitent des formats de documents non couverts par les greffons existants, mettent les documents en forme d'une manière particulière, ou extraient un nouveau type de méta-données.

Options générales

La table <tblref table_options_applicable_to_all_plugins> montre les options acceptées par tout greffon héritant de BasPlug.

<tblcaption table_options_applicable_to_all_plugins|Options valables pour tous les greffons></tblcaption>

< - 132 397 >
input_encoding Encodage de caractères utilisé dans les documents source. Par défaut Greenstone devine automatiquement l'encodage utilisé dans chaque document. Il est parfois utile cependant de positionner cette valeur: si par exemple vous savez que tous vos documents sont en ASCII brut, positionner l'encodage en entrée à la valeurasciiaugmentera considérablement la vitesse d'import et de construction de votre collection. Il existe de nombreuses valeurs possibles; tapezpluginfo.pl BasPlugpour en obtenir la liste complète.
default_encoding L'encodage utilisé siinput_encodingvautautoet que la détection automatique d'encodage échoue.
process_exp Une expression rationnelle de Perl à utiliser sur les noms de fichier (pour localiser par exemple un certain type d'extension de fichier). Ceci dicte les fichiers qu'un greffon doit traiter. Chaque greffon dispose d'une valeur par défaut (la valeur par défaut deHTMLPlugest(?i).html?—c'est-à-dire tout fichier d'extension.htmou.html).
block_exp Une expression rationnelle de Perl à utiliser sur les noms de fichier qui ne doivent pas être passés aux greffons suivants. Ceci peut éviter l'apparition d'ennuyeux messages d'erreur qui ne vous intéressent pas. Certains greffons disposent d'expressions de blocage par défaut—par exemple, le greffonHTMLPlugbloque les fichiers d'extensions.gif,.jpg,.jpeg,.png,.rtfand.css.
cover_image Recherche un fichier.jpg(portant le même nom que le fichier en cours de traitement) et l'associe au document en tant qu'image de couverture.
extract_acronyms Extrait les acronymes des documents et les ajoute en tant que méta-données aux documents d'archive de Greenstone correspondants.
markup_acronyms Ajoute des informations sur les acronymes dans le texte du document.
extract_language Identifie la langue de chaque document et l'associe en tant que méta-donnée. Ceci est automatique si l'option input_encodinga la valeurauto.
default_language Si l'extraction automatique de la langue échoue, la méta-donnée de langue est positionnée à cette valeur.
first Extrait une liste séparée par des virgules de la première portion de texte et l'ajoute en tant que méta-donnée FirstNNN(souvent utilisé en remplacement deTitle).
extract_email Extrait les adresses de courrier électronique et les ajoute aux méta-données du document.
extract_date Extrait les dates relatives au contenu de documents historiques et les ajoute en tant que méta-données de typeCoverage.

Greffons de traitement de documents

<tblcaption table_greenstone_plugins|Greffons (plugins) de Greenstone></tblcaption>

< - 60 72 236 85 76 >
Purpose File types Ignores files
Généraux ArcPlug Traite les fichiers mentionnés dans le fichierarchives.inf, qui est utilisé comme vecteur de communication entre les processus d'import et de construction. Doit être inclus (sauf siimport.pln'est pas utilisé).
RecPlug Explore récursivement une structure arborescente de répertoire en regardant si les fichiers sont des répertoires et si c'est le cas, en insérant tous les fichiers du répertoire dans le pipe-line des greffons. Affecte les méta-données si l'option—use_metadata_filesest positionnée et si des fichiersmetadata.xmlsont présents.
GAPlug Traite les fichiers d'archive de Greenstone générés par le programmeimport.pl.Doit être inclus (sauf si import.pln'est pas utilisé). .xml
TEXTPlug Traite le texte brut en le plaçant entre balises<pre> </pre>(et en le traitant comme s'il était pré-formaté). .txt, .text
HTMLPlug Traite le HTML en remplaçant les liens hypertexte de manière appropriée. Si le document cible d'un lien n'est pas dans la collection, une page intermédiaire est insérée, avertissant l'utilisateur qu'il quitte la collection. Extrait les méta-données déjà disponibles telles queTitle. .htm, .html, .cgi, .php, .asp, .shm, .shtml .gif, .jpeg, .jpg, .png, .css, .rtf
WordPlug Traite les fichiers au format Microsoft Word, en extrayant l'auteur et le titre s'ils sont disponibles, et en laissant les diagrammes et les images aux endroits appropriés. Les outils de conversion utilisés par ce greffon produisent parfois du HTML mal mis en forme, et nous recommandons que vous fournissiez les documents originaux à des fins de visualisation lors de la construction de collections de fichiers Word. Le texte extrait est cependant convenable à des fins de recherche et d'indexation. .doc .gif, .jpeg, .jpg, .png, .css, .rtf
PDFPlug Traite les documents PDF, en extrayant la première ligne de texte en tant que titre. Le programmepdftohtmlne parvient pas à traiter certains fichiers PDF. Le processus de conversion prend un temps exponentiellement long, et on voit souvent apparaître à l'écran un message traitant de ce processus. Si cela se produit, la seule solution que nous puissions proposer est d'ôter le document concerné de la collection et de recommencer le processus d'import. .pdf .gif, .jpeg, .jpg, .png, .css, .rtf
PSPlug Traite les documents PostScript, en extrayant optionnellement les méta-données de date, de titre, et de numéro de page. .ps .eps
EMAILPlug Traite les messages de courrier électronique, en reconnaissant l'auteur, le thème, la date, etc. Ce greffon ne traite pas encore correctement les courriers électroniques encodés au format MIME—bien que lisibles, ils ont souvent un aspect étrange. Doit se terminer par des chiffres ou des chiffres suivis de.Email
BibTexPlug Traite les fichiers de bibliographie au formatBibTex. .bib
ReferPlug Traite les fichiers de bibliographie au formatrefer. .bib
SRCPlug Traite les fichiers de code source Makefile, Readme, .c, .cc, .cpp, .h, .hpp, .pl, .pm, .sh .o, .obj, .a, .so, .dll
ImagePlug Traite les fichiers d'images pour créer une bibliothèque d'images. Ne fonctionne que sous Unix. .jpeg, .jpg, .gif, .png, .bmp, .xbm, .tif, .tiff
SplitPlug À l'instar de BasPlug et de ConvertToPlug, il ne faut pas appelé ce greffon directement; il faut plutôt que des greffons qui ont besoin de traiter des fichiers contenant plusieurs documents en héritent.
FOXPlug Traite les fichiers dbt de FoxBASE .dbt, .dbf
ZIPPlug Décompacte les fichiersgzip,bzip,zip, ettarfiles, pour peu que les outils GNU appropriés soient disponibles. .gzip, .bzip, .zip, .tar, .gz, .bz, .tgz, .taz
Propres à une collection PrePlug Traite la sortie HTML en utilisant PRESCRIPT, divisant les documents en pages pour la collection Computer Science Technical Reports. .html, .html.gz
GBPlug Traite le texte électronique du projet Gutenberg—qui comprend des informations de titre saisies manuellement. .txt.gz, .html, .htm
TCCPlug Traite les documents de courrier électronique de la collectionComputists' Weekly(l'hebdomadaire des informaticiens) Doit commencer partccoucw

Les greffons de traitement de documents sont utilisés par le logiciel de construction de collection pour analyser chaque document source d'une manière qui dépend de son format. Le fichier de configuration d'une collection liste tous les greffons utilisés lors de sa construction. Lors de l'opération d'import, chaque fichier ou chaque répertoire est passé tour à tour à tous les greffons jusqu'à ce qu'un greffon soit trouvé qui puisse traiter l'objet – c'est pourquoi les premiers greffons listés ont la priorité sur des greffons apparaissant plus tard dans la liste. Si aucun greffon ne peut traiter le fichier, un avertissement est affiché (sur la sortie d'erreur standard) et le traitement passe au fichier suivant (c'est pourquoi l'option block_exp peut être utile – pour éviter ces messages d'erreur dans le cas de fichiers qui sont peut-être présents mais n'ont pas besoin d'être traités). Lors de la construction, on utilise la même procédure, mais c'est le répertoire archives qui est traité en lieu et place du répertoire import.

Les greffons standard de Greenstone sont listés table <tblref table_greenstone_plugins>. Il est nécessaire d'utiliser un processus récursif pour traverser des hiérarchies de répertoires. Bien que les programmes d'import et de construction n'effectuent pas de récursion explicite, certains greffons provoquent une récursion indirecte en passant des noms de fichiers ou de répertoires dans le pipe-line des greffons. Par exemple, la manière habituelle d'opérer récursivement à travers une hiérarchie de répertoire est de spécifier RecPlug, qui travaille exactement ainsi. S'il est présent, il devrait être en dernière position dans le pipe-line. Seuls les deux premiers greffons de la table <tblref table_greenstone_plugins> provoquent une récursion indirecte.

Certains greffons sont écrits pour des collections spécifiques, avec un format de document que l'on ne trouve nulle part ailleurs, tel que le texte électronique utilisé dans la collection Gutenberg. Ces greffons spécifiques à une collection se trouvent dans le répertoire perllib/plugins de la collection. On peut utiliser des greffons spécifiques à une collection pour remplacer des greffons généraux portant le même nom, qui ne seront alors pas appelés.

Certains greffons de traitement de documents utilisent des programmes externes qui analysent des formats de fichiers propriétaires spécifiques – tel que par exemple Microsoft Word – et les transforment en texte brut ou en HTML. Un greffon général appelé ConvertToPlug invoque le programme de conversion approprié et en passe le résultat aux greffons TEXTPlug ou HTMLPlug. Nous décrirons cette opération plus en détail sous peu.

Certains greffons disposent d'options individuelles, qui les contrôlent de manière plus fine que ce que permettent les options générales. C'est la table <tblref table_plugin-specific_options> qui décrit ces options individuelles.

<tblcaption table_plugin-specific_options|Options propres aux greffons></tblcaption>

< - 132 132 265 >
Option But
HTMLPlug nolinks Ne piège pas de liens dans la collection. Ceci accélère les processus d'import et de construction, mais tout lien contenu dans la collection sera cassé.
description_tags Interprète les fichiers de documents balisés comme dans la sous-section 2.1.5.
keep_head N'enlève pas les en-têtes HTML.
no_metadata Ne recherche aucune méta-donnée (ceci peut accélérer les processus d'import et de construction).
metadata_fields Prend une liste séparée par des virgules de types de méta-données à extraire (dont la valeur par défaut estTitle).Pour changer le nom des méta-données dans le fichier d'archive de Greenstone, utilisezbalise<nouveaunom>baliseest la balise HTML recherchée etnouveaunomson nouveau nom.
hunt_creator_metadata Trouve autant de méta-données que possible relatives à la paternité du document et les consigne dans le document d'archive de Greenstone sous la forme de méta-donnéesCreator. Il faut aussi inclureCreatoravec l'optionmetadata_fields.
file_is_url Utilisez cette option si un programme de miroir web a été utilisé pour créer la structure des documents à importer.
assoc_files Donne une expression rationnelle de Perl qui décrit les types de fichiers à traiter comme des fichiers associés. Les types par défaut sont.jpg,.jpeg,.gif,.png,.css
rename_assoc_files Change le nom des fichiers associés aux documents. Lors de ce processus la structure de répertoire de tout fichier associé rétrécira beaucoup (ce qui est utile s'il faut stocker la collection dans un espace disque limité).

| title_sub | Expression de substitution Perl pour modifier les titres. |

PSPlug extract_date Extrait la date de création de l'en-tête PostScript et la stocke en tant que méta-donnée.
extract_title Extrait le titre du document de l'en-tête PostScript et le stocke en tant que méta-donnée de titre.
extract_pages Extrait les numéros de pages du document PostScript et les ajoute aux sections appropriées en tant que méta-données sous la balisePages.
RecPlug use_metadata_files Affecte des méta-données à partir d'un fichier tel que décrit dans la sous-section 2.1.4.
ImagePlug Diverses options VoirImagePlug.pm.
SRCPlug remove_prefix Donne une expression rationnelle de Perl d'un motif à chercher en tête et qu'il faut ôter du nom de fichier. Le comportement par défaut est d'ôter tout le chemin.

Greffons d'import de formats propriétaires

Les formats propriétaires posent des problèmes difficiles pour tout système de bibliothèque numérique. Bien qu'ils soient parfois documentés, ils sont susceptibles de changer sans préavis, et il est difficile de suivre le rythme des changements. Greenstone a fait le choix d'utiliser des outils de conversion publiés selon les termes de la GPL (licence publique générale de GNU) par des gens focalisés sur telle ou telle tâche de conversion. Les outils pour convertir les formats Word et PDF sont inclus dans le répertoire packages. Tous convertissent des documents au format texte ou au format HTML. Les greffons HTMLPlug et TEXTPlug prennent ensuite la relève et convertissent ce résultat intermédiaire au format d'archivage de Greenstone. C'est ConvertToPlug qui est utilisé pour inclure les outils de conversion. BasPlug n'est jamais appelé directement, mais les greffons traitant des formats particuliers en héritent, comme illustré figure <imgref figure_plugin_inheritance_hierarchy>. ConvertToPlug utilise le système d'héritage dynamique de Perl pour hériter soit de TEXTPlug soit de HTMLPlug, selon le format dans lequel le document source a été converti.

<imgcaption figure_plugin_inheritance_hierarchy|%!– id:537 –%Hiérarchie d'héritage des greffons (plugins) ></imgcaption>

Quand ConvertToPlug reçoit un document, il appelle gsConvert.pl (qui se trouve dans le répertoire GSDLHOME/bin/script) pour invoquer l'outil de conversion approprié. Après conversion, le document est renvoyé vers le greffon ConvertToPlug, qui invoque ensuite le greffon texte ou HTML, selon les cas. Tout greffon héritant de ConvertToPlug dispose d'une option convert_to (convertit vers), dont l'argument est soit text (texte) soit html, pour spécifier le format intermédiaire préféré. Le format texte est plus rapide, mais le format HTML rend mieux en général, et comprend des images.

Il existe parfois plusieurs outils de conversion pour traiter un format particulier, et le programme gsConvert peut en essayer plusieurs sur un document donné. Par exemple, l'outil habituel de conversion du format Work, wvWare, ne traite pas les formats antérieurs à Word 6, et c'est un programme appelé AnyToHTML, qui se contente d'extraire toutes les chaînes de texte qu'il peut trouver, qui est appelé pour convertir les documents au format Word 5.

Voici les étapes nécessaires pour ajouter un nouvel outil externe de conversion de document:

  1. Installez le nouvel outil de conversion de manière qu'il soit accessible à Greenstone (placez-le dans le répertoire packages).
  2. Modifiez gsConvert.pl pour utiliser le nouvel outil de conversion. Il s'agit d'ajouter une nouvelle clause à l'instruction if de la fonction main, et d'ajouter une fonction qui appelle l'outil de conversion.
  3. Écrivez un greffon de premier niveau qui hérite de ConvertToPlug pour intercepter le format et le passer à la suite de la chaîne.

Affecter des méta-données à partir d'un fichier

Le greffon standard RecPlug incorpore également une méthode pour positionner des méta-données dans les documents de manière manuelle (ou automatique) à partir de fichiers XML créés manuellement (ou automatiquement). Nous détaillons quelque peu ceci, de manière que vous puissiez créer des fichiers de méta-données dans le format approprié. Si l'option use_metadata_files est précisée, RecPlug utilise un fichier de méta-données auxiliaire, metadata.xml. La première partie de la figure <imgref figure_xml_format> illustre la définition de type de document (DTD) XML pour le format du fichier de méta-données, et la deuxième partie de la figure <imgref figure_xml_format_1> montre un exemple de fichier metadata.xml.

<imgcaption figure_xml_format|%!– id:547 –%(a) %!– id:546 –%Format XML: (a) Définition de type de document (DTD); (b) Fichier de méta-données d'exemple ></imgcaption>

<!DOCTYPE GreenstoneDirectoryMetadata [
   <!ELEMENT DirectoryMetadata (FileSet*)>
   <!ELEMENT FileSet (FileName+,Description)>
   <!ELEMENT FileName (#PCDATA)>
   <!ELEMENT Description (Metadata*)>
   <!ELEMENT Metadata (#PCDATA)>
   <ATTLIST Metadata name CDATA #REQUIRED>
   <ATTLIST Metadata mode (accumulate|override) "override">
]>

<imgcaption figure_xml_format_1|%!– id:549 –%(b) %!– id:548 –% ></imgcaption>

<?xml version="1.0" ?>
<!DOCTYPE GreenstoneDirectoryMetadata SYSTEM
"http://greenstone.org/dtd/GreenstoneDirectoryMetadata/<br/>1.0/GreenstoneDirectoryMetadata.dtd">
<DirectoryMetadata>
   <FileSet>
       <FileName>nugget.*</FileName>
       <Description>
       <Metadata name="Title">Nugget Point Lighthouse</Metadata>
           <Metadata name="Place" mode="accumulate">Nugget Point</Metadata>
       </Description>
   </FileSet>
   <FileSet>
       <FileName>nugget-point-1.jpg</FileName>
       <Description>
           <Metadata name="Title">Nugget Point Lighthouse , The Catlins </Metadata>
           <Metadata name="Subject">Lighthouse</Metadata>
       </Description>
   </FileSet>
</DirectoryMetadata>

Le fichier d'exemple contient deux structures de méta-données. Dans chacune, l'élément filename décrit les fichiers auxquels les méta-données s'appliquent, sous la forme d'une expression rationnelle. <FileName>nugget.*</FileName> indique ainsi que le premier enregistrement de méta-données s'applique à tous les fichiers dont le nom commence par «nugget»1). Pour ces fichiers, la méta-donnée Title vaudra «Phare de Nugget Point».

Les éléments de méta-données sont traités dans l'ordre dans lequel ils apparaissent. La deuxième structure de la figure 10 positionne la méta-donnée Title pour le fichier nugget-point-1.jpg à la valeur «Phare de Nugget Point, Catlins», en écrasant la spécification précédente. Elle ajoute également un champ Subject dans les méta-données.

Parfois, les méta-données sont multi-valuées et les nouvelles valeurs devraient s'accumuler au lieu d'écraser les précédentes. L'attribut mode=accumulate a cet effet. Il est appliqué à la méta-donnée Place (lieu) dans la première spécification de la figure 10, cette méta-donnée sera donc multi-valuée. Pour revenir à une méta-donnée simple, écrivez<Metadata name="Place" mode="override">Nouvelle-Zélande</Metadata>En fait, on peut négliger de préciser cette spécification de mode puisque tout élément écrase le précédent par défaut, sauf indication contraire. Pour accumuler les méta-données dans un champ particulier, il faut préciser mode=accumulate à chaque occurrence.

Quand son option use_metadata_files est activée, le greffon RecPlug recherche dans chaque répertoire en entrée un fichier XML appelé metadata.xml et applique son contenu à tous les fichiers et sous-répertoires du répertoire courant.

Le mécanisme metadata.xml instancié dans le greffon RecPlug n'est qu'une manière de spécifier des méta-données pour des documents. Il est facile d'écrire des greffons différents qui accepteront des spécifications de méta-données dans des formats complètement différents.

Baliser les fichiers de documents

Il faut souvent structurer les documents source en sections et sous-sections, et donc communiquer cette information à Greenstone de manière qu'il puisse reproduire la structure hiérarchique du document. On peut aussi associer à chaque section et sous-section des méta-données, et en particulier un titre.

La manière la plus simple de procéder est souvent d'éditer les fichiers source, tout simplement. Le greffon HTML dispose d'un option description_tags qui traite les balises dans le texte comme suit:

<!--
<Section>
   <Description>
       <Metadata name="Title"> Realizing human rights for poor people: Strategies for achieving the international development targets</Metadata>
   </Description>
-->

(texte de la section)

<!--
</Section>
-->

On utilise les marqueurs%!– … –%car ils dénotent des commentaires en HTML; ces balises de section n'auront donc aucun impact sur la mise en forme du document. On peut spécifier d'autres types de méta-données dans la portion Description, mais ce n'est pas le cas du style de collection décrit ici. On peut aussi imbriquer des balises, de telle sorte que la ligne(texte de la section)ci-dessus peut elle-même inclure des sous-sections, telles que

(texte de la première partie de la section)

<!--
<Section>
   <Description>
       <Metadata name="Title"> The international development targets</Metadata>
   </Description>
-->

(texte de la sous-section)

<!--
</Section>
-->

(texte de la dernière partie de la section)

Cette fonctionnalité est héritée par tout greffon utilisant HTMLPlug. En particulier, le greffon Word convertit les données qu'il reçoit au format HTML: on peut donc procéder exactement de la même manière pour spécifier des méta-données dans les fichiers Word (et RTF). Ceci implique un peu de travail en coulisses, puisque lors de la conversion de documents Word vers HTML, le programme prend soin, normalement, de neutraliser les caractères significatifs pour HTML, tels que<et>; nous nous sommes arrangés pour contourner cette neutralisation dans le cas des spécifications mentionnées ci-dessus. Il faut alors utiliser exactement le même format, même dans des fichiers Word, et ne pas oublier les%!–et–%qui entourent les méta-données. Le choix des polices et l'espacement n'ont aucune importance.

Classificateurs

Les classificateurs servent à créer les index de navigation d'une collection, comme par exemple l'index titres A-Z de la collection dlpeople, et les index thème, comment faire, organisation et titres A-Z dans la bibliothèque de développement pour l'humanité, dont la collection «Demo» est un sous-ensemble. La barre de navigation située au sommet des copies d'écran dans les figures 3 et 8a inclut la fonction Rechercher, qui est toujours disponible, suivie par autant de boutons que de classificateurs définis. Les informations servant à la navigation sont stockées dans la base de données d'informations de la collection, et y sont placées par des classificateurs lors de la phase finale du programme buildcol.pl.

<imgcaption figure_azlist_classifier|%!– id:566 –%ClassificateurAZList ></imgcaption>

Les classificateurs, à l'instar des greffons, sont spécifiés dans le fichier de configuration de la collection. À chacun correspond une ligne débutant par le mot-clef classify et suivie du nom du classificateur et des options qu'il accepte. Le fichier de configuration de collection simple étudié dans la section configuration_file comprend la ligne classify AZList -metadata Title, qui crée une liste alphabétique des titres en prenant tous les documents pourvus d'un champ de méta-données Title, en triant ces derniers et en les ventilant en intervalles alphabétiques. On trouvera un exemple dans la figure <imgref figure_azlist_classifier>.

<imgcaption figure_list_classifier|%!– id:568 –%ClassificateurList ></imgcaption>

Un classificateur plus simple, appelé List, et illustré dans la figure <imgref figure_list_classifier>, crée une liste triée d'une méta-donnée spécifiée et l'affiche sans créer de tranches alphabétiques. Un exemple est la méta-donnée how to de la collection «Demo», qui est produite par la ligne classify List -metadata Howto dans le fichier de configuration de la collection2). Un autre classificateur de liste générique est DateList, illustré dans la figure <imgref figure_datelist_classifier>, qui engendre une liste de sélection d'intervalles de dates (le classificateur DateList est également utilisé dans la collection «Archives» de Greenstone).

<imgcaption figure_datelist_classifier|%!– id:570 –%ClassificateurDateList ></imgcaption>

D'autres classifications engendrent des structures de navigation qui sont explicitement hiérarchiques. Les classifications hiérarchiques sont utiles pour des classifications et sous-classifications de thèmes, et les hiérarchies organisationnelles. Le fichier de configuration de la collection «Demo» contient la ligne classify Hierarchy -hfile sub.txt -metadata Subject -sort Title, et la figure <imgref figure_hierarchy_classifier> ontre la hiérarchie de thèmes que cette ligne produit. L'étagère portant un titre en gras et l'étagère actuellement utilisée; la classification de thème à laquelle elle appartient la surplombe. Dans cet exemple la hiérarchie utilisée pour la classification est stockée dans un simple fichier texte, sous le nom sub.txt.

<imgcaption figure_hierarchy_classifier|%!– id:572 –%ClassificateurHierarchy ></imgcaption>

Tous les classificateurs génèrent une structure hiérarchique qui est utilisée pour afficher un index de navigateur. Les niveaux les plus bas de la hiérarchie (les feuilles) sont généralement les documents, mais dans certains classificateurs ce sont les sections. Les noeuds internes de la hiérarchie sont Vlist, Hlist, ou Datelist. Un noeud Vlist est une liste d'objets affichés verticalement et descendant la page, telle que l'index «comment faire» de la collection «Demo» (figure <imgref figure_list_classifier>). Un noeud Hlist est affiché horizontalement; par exemple l'affichage AZList de la figure <imgref figure_azlist_classifier> est une hiérarchie à deux niveaux de noeuds internes consistant en un noeud Hlist (donnant le sélecteur A-Z) et dont les enfants sont des noeuds Vlist – parents, à leur tour, de documents. Un noeud Datelist (figure <imgref figure_datelist_classifier>) est un cas particulier de noeud Vlist qui permet d'effectuer des sélections par année et par mois.

Les lignes spécifiant des classificateurs dans les fichiers de configuration de collection contiennent un argument metadata qui identifie les méta-données selon lesquelles classifier et trier les documents. Tout document de la collection ne disposant pas de cette méta-donnée sera omis par le classificateur (mais il sera quand même indexé, et les recherches le prendront donc en compte). En l'absence de spécification d'argument metadata, tous les documents sont inclus dans le classificateur, dans l'ordre dans lequel le processus de construction les a trouvés. C'est utile si vous souhaitez obtenir une liste de tous les documents de votre collection.

<tblcaption table_greenstone_classifiers|Classificateurs de Greenstone></tblcaption>

< - 132 92 305 >
Argument But
Hierarchy Classification hiérarchique
hfile Fichier de classification
metadata Élément de méta-donnée à confronter à l'identifianthfile
sort Élément de méta-donnée utilisé pour trier les documents au sein des feuilles (valeur par défaut:Title)
buttonname Nom du bouton utilisé pour accéder à ce classificateur (valeur par défaut: valeur de l'argumentmetadata)
List Liste alphabétique des documents
metadata Inclut les documents contenant cet élément de méta-donnée
buttonname Nom du bouton utilisé pour accéder à ce classificateur (valeur par défaut: valeur de l'argumentmetadata)
SectionList Liste des sections dans les documents
AZList Liste des documents ventilés en intervalles alphabétiques
metadata Inclut les documents contenant cet élément de méta-donnée
buttonname Nom du bouton utilisé pour accéder à ce classificateur (valeur par défaut: valeur de l'argumentmetadata)
AZSectionList CommeAZListmais inclut chaque section du document
DateList Similaire àAZListmais en triant par date

Les classificateurs actuellement disponibles sont listés dans la table <tblref table_greenstone_classifiers>. De même que l'on peut utiliser le programme pluginfo.pl pour en savoir plus sur un greffon quelconque, on peut utiliser le programme classinfo.pl pour en savoir plus sur un classificateur et sur les options qu'il propose.

Tous les classificateurs acceptent l'argument buttonname, qui définit ce qui est écrit sur le bouton de navigation de Greenstone qui invoque le classificateur (sa valeur par défaut est le nom de l'argument metadata). Des boutons sont fournis pour chacun des types de méta-données du système Dublin Core, ainsi que pour quelques autres types de méta-données.

Chaque classificateur reçoit un nom implicite en fonction de sa position dans le fichier de configuration. Par exemple, le troisième classificateur spécifié dans le fichier s'appellera CL3. Ces noms sont utilisés dans les champs de la base de données d'informations de la collection, qui définit la hiérarchie des classificateurs.

On peut écrire des classificateurs propres à une collection; ils sont alors stockés dans son répertoire perllib/classify. La bibliothèque de développement pour l'humanité dispose d'un classificateur propre de collection qui s'appelle HDLList, et qui est une variante mineure d'AZList.

Classificateurs de listes

Voici les différentes possibilités de classificateurs de listes:

  • SectionList – comme List mais les feuilles sont des sections et non pas des documents. Toutes les sections du document sont incluses à l'exception des sections de premier niveau. Cela sert à créer des listes de sections (ou d'articles, de chapitres, ou …) cVoici les différentes omme dans la collection Computists' Weekly (l'hebdomadaire des informaticiens), disponible depuis le site webnzdl.org, dont chaque numéro est un unique document qui comprend plusieurs dépêches indépendantes, chacune étant placée dans sa propre section.
  • AZList – génère une hiérarchie à deux niveaux comprenant un noeud HList dont les enfants sont des noeuds VList, parents à leur tour de documents. Le noeud HList est un sélecteur A-Z qui divise les documents en intervalles alphabétiques. Les documents sont triés alphabétiquement selon des méta-données, et la liste résultante est ventilée en intervalles.
  • AZSectionList – comme AZList, mais les feuilles sont des sections, et non pas des documents.
  • DateList – comme AZList à ceci près que le noeud HList de premier niveau permet des sélections par année et que ses enfants sont des noeuds de type DateList et non pas de type VList. La valeur par défaut de l'argument metadata est Date.

Le classificateur hierarchy

Tous les classificateurs sont hiérarchiques. Cependant, les classificateurs de la section 2.1.1 disposent d'un nombre fixé de niveaux, alors que le classificateur hierarchy décrit dans la présente section peut créer un nombre de niveaux arbitraire: il est plus complexe à spécifier que les classificateurs de listes.

<imgcaption figure_part_of_the_file_sub|%!– id:618 –%Portion du fichier sub.txt ></imgcaption>

1           1       "General reference"
1.2       1.2       "Dictionaries, glossaries, language courses, terminology
2           2       "Sustainable Development, International cooperation, Pro
2.1       2.1       "Development policy and theory, international cooperatio
2.2       2.2       "Development, national planning, national plans"
2.3       2.3       "Project planning and evaluation (incl. project managem
2.4       2.4       "Regional development and planning incl. regional profil
2.5       2.5       "Nongovernmental organisations (NGOs) in general, self-
2.6       2.6       "Organisations, institutions, United Nations (general, d
2.6.1   2.6.1       "United Nations"
2.6.2   2.6.2       "International organisations"
2.6.3   2.6.3       "Regional organisations"
2.6.5   2.6.5       "European Community - European Union"
2.7       2.7       "Sustainable Development, Development models and example
2.8       2.8       "Basic Human Needs"
2.9       2.9       "Hunger and Poverty Alleviation"

L'argument hfile donne le nom d'un fichier, tel que celui de la figure <imgref figure_part_of_the_file_sub>, qui définit la hiérarchie de méta-données. Chaque ligne décrit une classification, et les descriptions comptent trois parties:

  • Un identifiant, qui fait correspondre la valeur de la méta-donnée (donnée par l'argument metadata) à la classification.
  • Un marqueur de position dans la hiérarchie, sous forme numérique en plusieurs parties, comme par exemple 2, 2.12, 2.12.6.
  • Le nom de la classification (s'il contient des espaces, il faut le placer entre apostrophes doubles).

La figure <imgref figure_part_of_the_file_sub> est une portion du fichier sub.txt, utilisé pour créer la hiérarchie de thèmes dans la bibliothèque de développement pour l'Humanité (et dans la collection «Demo»). Cet exemple n'est pas très clair puisque le nombre représentant la hiérarchie apparaît deux fois sur chaque ligne. Le type de méta-donnée Hierarchy est représenté dans les documents avec des valeurs sous forme numérique hiérarchique, ce qui correspond à la première occurrence. C'est la deuxième occurrence qui est utilisée pour déterminer la hiérarchie implémentée dans la hiérarchie de navigation.

Le classificateur hierarchy dispose d'un argument facultatif, sort, qui détermine la manière dont les documents sont ordonnés au niveau des feuilles. On peut spécifier n'importe quelle méta-donnée comme clef de tri. Le comportement par défaut est de produire la liste dans l'ordre dans lequel le processus de construction rencontre les documents. Au niveau des noeuds internes, l'ordre est déterminé par celui des spécifications dans l'argument hfile.

Fonctionnement des classificateurs

Les classificateurs sont des objets Perl, héritant de BasClas.pm, et stockés dans le répertoire perllib/classify. Ils sont utilisés lors de la construction de la collection. Leur exécution se fait en quatre étapes:

  1. La méthode new crée l'objet classificateur.
  2. La méthode init initialise l'objet avec des paramètres tels que le type de méta-donnée, le nom du bouton, et le critère de tri.
  3. La méthode classify est invoquée une fois par document, et stocke les informations de la classification effectuée dans l'objet classificateur.
  4. La méthode get_classify_info renvoie la classification stockée localement vers le processus de construction, qui l'écrit à son tour dans la base de données d'informations de la collection à des fins d'utilisation lors de l'affichage de la collection, au moment de l'exécution.

La méthode classify rapatrie l'OID de chaque document, la valeur de méta-donnée selon laquelle classifier le document, et, si nécessaire, la valeur de méta-donnée selon laquelle trier les documents. La méthode get_classify_info s'occupe du tri et de tout traitement propre au classificateur. Dans le cas du classificateur AZList par exemple, elle ventile la liste en intervalles.

Le processus de construction initialise les classificateurs dès que l'objet builder est construit. Les classifications sont créées pendant la phase de construction, lors de la création de la base de données d'informations, par classify.pm, qui réside dans le répertoire perllib de Greenstone.

<tblcaption table_items_appearing_in_format_strings|Objets apparaissant dans les chaînes de formatage></tblcaption>

< - 132 397 >
[Text] Texte du document
[link] … [/link] Portion de HTML à relier au document lui-même
[icon] Une icone appropriée (telle que la petite icone de texte dans une chaîneRésultats de la recherche)
[num] Numéro du document (utile pour déboguer)
[metadata-name] Valeur de cet élément de méta-donnée pour le document, tel que[Title]

Mettre en forme la sortie de Greenstone

Les pages web que vous pouvez voir lorsque vous utilisez Greenstone ne sont stockées nulle part; elles sont générées «à la volée» en fonction des besoins. L'apparence de nombreux aspects de ces pages est contrôlée à l'aide de «chaînes de formatage» (dans le sens de «mise en forme», et pas de «remise à zéro»). Les chaînes de formatage se trouvent dans le fichier de configuration de la collection, introduites par le mot-clef format lui-même suivi du nom de l'élément concerné par la mise en forme. Il existe deux types d'éléments de page contrôlés par des chaînes de formatage. Le premier comprend les éléments de la page qui affichent des documents ou des portions de documents. Le second comprend les listes produites par les classificateurs et les recherches. Toutes les chaînes de formatage sont interprétées au moment de l'affichage des pages. Elles prennent donc effet dès que le fichier collect.cfg est modifié et sauvegardé; il est par conséquent rapide et facile de faire des expériences avec les chaînes de formatage.

La table <tblref table_items_appearing_in_format_strings> montre les instructions qui affectent la représentation des documents. L'option DocumentButtons contrôle les boutons qui sont affichés sur une page de document. Ici, chaîne est une liste de boutons (séparés par|), dont les valeurs possibles sont Detach (détacher), Highlight (mettre en valeur), Expand Text (développer le texte), et Expand Contents (développer la table des matières). Modifier l'ordre de la liste a le même effet sur les boutons.

<tblcaption table_the_format_options|Les options du mot-clefformat></tblcaption>

< - 246 283 >
format DocumentImages true/false Si la valeur esttrue, affiche une image de couverture en haut à gauche de la page du document (la valeur par défaut estfalse).
format DocumentHeading chaîne_de_formatage Si l'optionDocumentImagesa la valeurfalse, la chaîne de formatage contrôle la représentation de l'en-tête de document apparaissant en haut à gauche de la page du document (la valeur par défaut est[Title]).
format DocumentContents true/false Affiche la table des matières (si le document a une structure hiérarchique), ou des flèches pour se rendre à la section précédente ou suivante et le texte «page k sur n» (dans le cas contraire).
format DocumentButtons chaîne Contrôle les boutons affichés sur une page de document (la valeur par défaut estDetach|Highlight).
format DocumentText chaîne_de_formatage Format du texte à afficher sur une page de document; la valeur par défaut est
    <center><table width=537>
      <tr><td>[Text]</td></tr>
      </table></center>
format DocumentArrowsBottom true/false Affiche des flèches pour se rendre à la section précédente ou suivante au pied de la page du document (la valeur par défaut esttrue, qui active ce comportement).
format DocumentUseHTML true/false Si la valeur esttrue, chaque document sera affiché dans un cadreframedifférent. La page dePréférenceschangera un peu également, et proposera de nouvelles options pour les documents HTML, telles que la possibilité de se rendre directement sur le document source original (partout sur le web) plutôt que sur la copie faite par Greenstone.

Formatage des listes de Greenstone

Les chaînes de formatage qui contrôlent l'apparence des listes peuvent s'appliquer à divers niveaux de la structure d'affichage. Elles peuvent altérer toutes les listes d'un certain type au sein d'une collection (comme par exemple DateList), toutes les parties d'une liste (comme par exemple toutes les entrées de la liste Rechercher), ou des portions spécifiques d'une liste particulière (comme par exemple la portion verticale de la liste du classificateur AZList appliqué sur des titres).

Le mot-clef format précède un mot-clef en deux parties, dont une seule est obligatoire. La première partie identifie la liste où s'applique le format. La liste générée par une recherche s'appelle Search (rechercher), tandis que les listes générées par des classificateurs sont appelées CL1, CL2, CL3,… pour respectivement le premier, le deuxième, le troisième… classificateur spécifié dans le fichier collect.cfg. La deuxième partie du mot-clef est la portion de la liste à laquelle appliquer la mise en forme – soit HList (pour une liste horizontale, telle que le sélecteur dans un noeud AZList), VList (pour une liste verticale, telle que la liste des tous les titres sous un noeud de type AZList), ou DateList. Par exemple:

format CL4VList … s'applique à tous les VList de CL4
format CL2HList … s'applique à tous les HList de CL2
format CL1DateList … s'applique à tous les DateList de CL1
format SearchVList … s'applique à la liste de Résultats de la recherche
format CL3 … s'applique à tous les noeuds de CL3, sauf indication contraire
format VList … s'applique à tous les VList de tous les classificateurs, sauf indication contraire

Les"…"de ces exemples représentent des spécifications de formatage HTML qui contrôlent l'information et sa représentation, apparaissant sur des pages web représentant le classificateur. Comme pour les spécifications HTML, toute méta-donnée peut apparaître entre crochets: sa valeur est interpolée à l'endroit indiqué. Tout élément de la table <tblref table_the_format_options> peut également apparaître dans des chaînes de formatage. La syntaxe des chaînes prévoit également une instruction conditionnelle, qui est illustrée plus bas.

Rappelez-vous que tous les classificateurs produisent des hiérarchies. Chaque niveau de la hiérarchie est affiché de l'une de quatre manières possibles. Nous avons déjà mentionné HList, VList, et DateList. Il existe également Invisible, qui est la manière dont les tous premiers niveaux des hiérarchies sont représentés – le nom du classificateur apparaît déjà séparément, en effet, sur la barre de navigation de Greenstone.

Exemples de classificateurs et de chaînes de formatage

<imgcaption figure_excerpt_from_the_demo_collection_collect|%!– id:674 –%Extrait du fichier collect.cfg de la collection «Demo» %!– withLineNumber –%></imgcaption>

classify Hierarchy -hfile sub.txt -metadata Subject -sort Title
classify AZList       -metadata Title
classify Hierarchy -hfile org.txt -metadata Organisation -sort Title
classify List           -metadata Howto
format SearchVList " <td valign=top [link][icon][/link]</td><td>{If}
                                       {[parent(All':'):Title],[parent(All':'):Title]:}
                                       [link][Title][/link]</td> "
format CL4Vlist                 "<br>[link][Howto][/link] "
format DocumentImages   true
format DocumentText       "<h3>[Title]</h3>\\n\\n<p>[Text]"
format DocumentButtons " Expand Text|Expand contents|Detach|Highlight"

La figure <imgref figure_excerpt_from_the_demo_collection_collect> représente une portion du fichier de configuration de la collection «Demo». Nous l'utilisons comme exemple, car il comprend plusieurs classificateurs avec un formatage riche. Remarquez que les instructions des fichiers de configuration ne peuvent pas contenir de retour à la ligne, et que dans la figure, nous avons scindé les lignes les plus longues pour des raisons de lisibilité.

La ligne 4 spécifie le classificateur How To (comment faire) de la collection «Demo». C'est le quatrième classificateur du fichier de configuration de la collection; on s'y réfère donc sous le nom CL4. L'instruction de formatage correspondante est la ligne 7 de la figure <imgref figure_excerpt_from_the_demo_collection_collect>. Cette information d'«indice» est engendrée par le classificateur List, et sa structure est la liste brute des titres affichés figure <imgref figure_list_classifier>. Les titres sont reliés aux documents eux-mêmes: cliquer sur un titre affiche le document correspondant. Les enfants du premier niveau de la hiérarchie sont affichés sous la forme d'une VList (liste verticale), qui liste les sections verticalement. Comme l'indique l'instruction format associée, chaque élément de la liste apparaît sur une nouvelle ligne ("<br>") et contient le texte de Howto, lui-même relié par lien hypertexte au document lui-même.

La ligne 1 spécifie la classification Subject (Thème) de la collection «Demo», à laquelle on se référera sous le nom CL1 (puisqu'elle est la première du fichier de configuration), et la ligne 3 spécifie la classification Organisation CL3. Toutes deux sont générées par le classificateur Hierarchy et comprennent donc une structure hiérarchique d'objets VList.

La ligne 2 spécifie la dernière classification de la collection «Demo», titres A-Z (CL2). Remarquez qu'il n'existe pas de chaînes de formatage associées aux classificateurs CL1 à CL3. Greenstone dispose de valeurs par défaut pour chaque type de chaîne de formatage; il n'est donc pas nécessaire de positionner une chaîne de formatage quand on ne souhaite pas obtenir un comportement différent du comportement par défaut.

<imgcaption figure_formatting_the_document|%!– id:679 –%Mise en forme du document ></imgcaption>

Voilà pour les quatre lignes classify de la figure <imgref figure_excerpt_from_the_demo_collection_collect>. On y trouve aussi quatre lignes format. Nous avons déjà expliqué la ligne CL4Vlist. Les trois lignes restantes sont du premier type de chaîne de formatage, documenté dans la table <tblref table_items_appearing_in_format_strings>. Par exemple, la ligne 8 place l'image de couverture en haut à gauche de chaque page de document. La ligne 9 formate le texte du document à proprement parler, et place le titre du chapitre ou de la section concernée juste avant le texte. Tous ces effets sont illustrés dans la figure <imgref figure_formatting_the_document>.

<imgcaption figure_formatting_the_search_results|%!– id:681 –%Mise en forme des résultats de la recherche ></imgcaption>

La ligne 5 de la figure <imgref figure_excerpt_from_the_demo_collection_collect> est une spécification quelque peu complexe qui formate la liste de résultats à une requête renvoyée par une recherche, dont les portions sont illustrées à la figure <imgref figure_formatting_the_search_results>. Voici une version simplifiée de la chaîne de formatage:

<td valign=top>[link][icon][/link]</td>
<td>[link][Title][/link]</td>

Ceci est conçu pour apparaître comme une ligne dans un tableau, ce qui est la manière dont la liste de résultats à une requête est mise en forme. Comme d'habitude, on obtient une petite icone cliquable qui mène au texte, et le titre du document, ancre d'un lien hypertexte qui mène au document à proprement parler.

Dans cette collection, les documents sont hiérarchiques. En fait, l'ancre de lien hypertexte ci-dessus se transforme en le titre de la section renvoyée par le requête. Il serait néanmoins préférable de lui adjoindre également le titre de la section qui la contient, du chapitre qui contient cette dernière, et du livre où ce chapitre apparaît. Il existe un objet de méta-donnée particulier, parent, qui n'est pas stocké dans les documents mais qui est implicite dans tout document hiérarchique, qui produit une telle liste. Elle renvoie soit le document parent ou, si elle est utilisée avec le qualificateur All (tout), la liste de tous les ancêtres au sens hiérarchique, séparés par une chaîne de caractères que l'on peut préciser après le qualificateur All. Ainsi:

<td valign=top>[link][icon][/link]</td> <br/><td>{[parent(All': '):Title]: }[link][Title][/link]</td>

a pour effet de produire une liste contenant le titre du livre, le titre du chapitre, etc., qui entourent la section cible; titres séparés par des caractères deux points, et un dernier caractère deux points est suivi d'un lien hypertexte menant au titre de la section cible.

Malheureusement, dans le cas où la cible est un livre, elle n'aura aucun parent et on verra donc apparaître une chaîne vide suivie d'un caractère deux points. Pour éviter de tels problèmes, on peut utiliser dans une chaîne de formatage des instructions conditionnelles if and or … else (si et ou … sinon):

{If}{[metadata], action-if-non-null, action-if-null}
{Or}{action, else another-action, else another-action, etc}

Dans chaque cas les accolades signalent que les instructions doivent être interprétées, et non pas simplement affichées comme du texte. L'instruction If teste si la méta-donnée est vide, et prend la première clause si ce n'est pas le cas, et la deuxième clause si c'est le cas (et si une deuxième clause est fournie). On peut utiliser tout élément de méta-données, y compris la méta-donnée spéciale parent. L'instruction Or évalue chaque action tour à tour jusqu'au moment où elle en rencontre une qui n'est pas vide. Cette action est alors renvoyée en sortie et le reste de la ligne est ignoré.

Si l'on revient à la ligne 5 de la figure <imgref figure_excerpt_from_the_demo_collection_collect>, la chaîne de formatage complète est:

<td valign=top>[link][icon][/link]</td>
<td>{If}{[parent(All': '):Title],
           [parent(All': '):Title]:}
      [link][Title][/link]</td>

Ceci fait précéder la spécification parent d'un test qui examine si le résultat est vide et n'affiche la chaîne du parent que lorsque ce dernier est présent. On peut aussi qualifier parent par Top (sommet) au lieu de All (tout), ce qui donne le nom de document de niveau le plus élevé qui entoure une section – dans le cas présent, le nom du livre. Nul besoin, avec Top, de chaîne de séparation.

Voici quelques derniers exemples pour illustrer d'autres fonctionnalités. Le classificateur DateList, dans la figure <imgref figure_datelist_classifier>, est utilisé dans la classification Dates de la collection Computists' Weekly (l'hebdomadaire des informaticiens), et il se trouve qu'il en est le deuxième classificateur, soit CL2. Le classificateur et les spécifications de formatage sont indiqués ci-dessous. Le classificateur DateList diffère d'AZList en ce sens qu'il trie toujours selon la méta-donnée Date, et que les branches situées au pied de la hiérarchie de navigation utilisent DateList au lieu de VList, ce qui ajoute à gauche des listes de documents, l'année et le mois.

classify AZSectionList metadata=Creator
format CL2Vlist "<td>[link][icon][/link]</td> <br/><td>[Creator]</td> <br/><td>&nbsp;&nbsp;[Title]</td> <br/><td>[parent(Top):Date]</td> "

La spécification de formatage affiche ces VLists de manière appropriée.

Le mécanisme de chaîne de formatage est souple mais difficile à apprendre. La meilleure manière de procéder est d'étudier des fichiers de configuration de collections existantes.

Tirer des liens vers différentes versions d'un document

Utiliser le mécanisme[link] … [/link]dans une chaîne de formatage a pour effet d'insérer un lien hypertexte menant au texte du document, en version HTML. Il est utile dans certaines collections de pouvoir afficher d'autres versions du document. Dans une collection de documents au format Microsoft Word, par exemple, il est bon d'être capable d'afficher la version Word de chaque document plutôt que le HTML qui en fut extrait; de même pour des documents PDF.

Pour pouvoir afficher différentes versions d'un document, la clef est d'embarquer les informations nécessaires (c'est-à-dire où se trouvent les autres versions du document) dans le format d'archivage de Greenstone du document. On représente cette information sous la forme de méta-données. Souvenez-vous qu'en plaçant

[link][Title][/link]

dans une chaîne de formatage, on crée un lien vers la version HTML du document, lien dont l'ancre est le titre du document. Les greffons Word et PDF générent tous deux la méta-donnée srclink de telle sorte qu'écrire

[srclink][Title][/srclink]

dans une chaîne de formatage créera un lien vers la version Word ou PDF du document; lien dont l'ancre sera dans cet exemple aussi, le titre du document. Pour permettre d'afficher l'icone appropriée pour les documents Word et PDF, ces greffons générent aussi la méta-donnée srcicon de telle sorte que

[srclink][srcicon][/srclink]

créera un lien étiqueté par l'icone standard pour le format Word ou PDF (selon le cas), et non pas par le titre du document.

Contrôler l'interface utilisateur de Greenstone

L'interface utilisateur de Greenstone est entièrement contrôlée par des macros placées dans le répertoire GSDLHOME/macros. Elles sont écrites dans un langage conçu spécialement pour Greenstone, et sont utilisées au moment de l'exécution pour engendrer des pages web. La traduction du langage de macros en HTML est la dernière étape de l'affichage d'une page. Ainsi, toute modification à un fichier de macros affecte immédiatement l'affichage, il est donc rapide et facile de faire des expériences avec les macros. Tous les fichiers de macros utilisés par Greenstone sont listés dans le fichier GSDLHOME/etc/main.cfg et sont chargés à chaque démarrage. Signalons l'exception de la version «Bibliothèque locale» sous Windows; dans ce cas il est nécessaire de redémarrer le processus.

Les pages web sont générées à la volée pour de nombreuses raisons, et le système de macros est la manière dont Greenstone implémente la souplesse nécessaire. On peut présenter des pages dans de nombreuses langues différentes, et on utilise un fichier de macros différent pour stocker tout le texte de l'interface dans chaque langue. Quand Greenstone affiche une page l'interpréteur de macros consulte une variable de langue et charge la page dans la langue appropriée (ce système ne va pas, malheureusement, jusqu'à traduire le contenu du document). De même, les valeurs de certaines variables d'affichage, telles que le nombre de documents trouvés par une recherche, ne sont pas connues à l'avance: elles sont interpolées dans le texte de la page à l'aide de macros.

Le format des fichiers de macros

Les fichiers de macros ont pour extension .dm. Chaque fichier définit un ou plusieurs paquetages, et chaque paquetage définit une série de macros utilisées dans un but précis et unique. À l'instar des classificateurs et des greffons, il existe une base à partir de laquelle construire des macros, appelée base.dm; ce fichier définit le contenu de base d'une page.

Les macros portent des noms qui commencent et finissent par un caractère de soulignement, et leur contenu est défini à l'aide d'accolades. Leur contenu peut consister en du texte brut, du HTML (y compris de liens vers des appliquettes (applets) Java ou du JavaScript), des noms de macros, ou toute combinaison de ces éléments. La macro suivante, extraite du fichier base.dm, définit le contenu d'une page en l'absence de toute macro de remplacement:

_content_ {<p><h2>Oops</h2>_textdefaultcontent_}

Cette page affichera «Oops» à son sommet, suivi du contenu de la macro d'erreur correspondante, _textdefaultcontent_ qui est en anglais définie comme suit: Global:textdefaultcontentThe requested page could not be found. Please use your browsers 'back' button or the above home button to return to the Greenstone Digital Library.; dans d'autres langues, elle affichera une traduction appropriée de cette phrase. En français, on obtiendra par exemple Global:textdefaultcontentLa page demandée n'a pu être trouvée. Utilisez s'il-vous-plaît le bouton «retour» de votre navigateur, ou le bouton «accueil» pour retourner à la Bibliothèque Numérique Greenstone.

Les deux macros _textdefaultcontent_ (contenu textuel par défaut) et _content_ (contenu) se trouvent dans le paquetage global car elles sont requises dans toutes les portions de l'interface utilisateur. Les macros peuvent utiliser des macros d'autres paquetages en tant que contenu, mais il faut alors qu'elles en préfixent les noms par le nom du paquetage. Exemple:

_collectionextra_ {This collection contains _about:numdocs_ documents. It was last built _about:builddate_ days ago.)

provient du fichier french.dm (macros pour le français), et elle est utilisée comme description par défaut d'une collection. Elle fait partie du paquetage intitulé global, mais les macros _numdocs_ et _builddate_ se trouvent toutes deux dans le paquetage about (à propos de…) – d'où le about qui préfixe leurs noms.

Les macros renferment souvent des conditionnelles, qui ressemblent aux conditonnelles de chaînes de formatage décrites plus haut, à ceci près que leur apparence est un peu différente. Le format de base est _If_(x,y,z), où x est une condition, y est le contenu de macro à utiliser si cette condition est vérifiée, z le contenu à utiliser dans le cas contraire. Les opérateurs de comparaison sont les mêmes que les opérateurs simples utilisés dans Perl (moins que, plus que, égale, différent de). L'exemple suivant, extrait du fichier base.dm, sert à déterminer comment afficher le sommet de la page À propos de cette collection d'une collection:

_imagecollection_ {
       _If_( "_iconcollection_ " ne "",
                 <a href = "_httppageabout_ "> 
                         <img src = "_iconcollection_ " border = 0>
                         </a>,
                 _imagecollectionv_)
}

Voilà qui peut sembler abscons. La macro _iconcollection_ vaut la chaîne vide si la collection ne dispose pas d'une icone, ou le nom de l'image dans le cas contraire. Pour paraphraser le code ci-dessus en français: s'il existe une image de collection, afficher l'en-tête de page à propos (à laquelle on se réfère par _httppageabout_) et puis cette image; sinon afficher la solution de secours _imagecollectionv_.

Les macros peuvent prendre des arguments. Voici une autre définition de la macro _imagecollection_, suivant immédiatement la définition donnée plus haut, dans le fichier base.dm:

_imagecollection_[v=1]{_imagecollectionv_}

L'argument [v=1] spécifie qu'il faut utiliser cette deuxième définition quand Greenstone fonctionne en mode texte seul. Les macros de langue fonctionnent de manière similaire – à l'exception du fichier english.dm, qui est le fichier utilisé par défaut, toutes les macros de langue spécifient leur langue en argument. Par exemple:

_textimagehome_ {Home Page}

apparaît dans le fichier de macros pour la langue anglaise, alors que la version allemande est:

_textimagehome_ [l=de] {Hauptaseite}

Les versions anglaise et allemande se trouvent dans le même paquetage, bien qu'elles soient stockées dans des fichiers séparés (les définitions de paquetages peuvent occuper plusieurs fichiers). Greenstone utilise son argument l au moment de l'exécution pour décider quelle langue afficher.

<imgcaption figure_part_of_the_aboutdm_macro_file|%!– id:714 –%Portion du fichier de macro about.dm ></imgcaption>

package about
##############################################
# about page content
###############################################
_pagetitle_ {_collectionname_}
_content_ {
<center>
_navigationbar_
</center>
_query:queryform_
<p>_iconblankbar_
<p>_textabout_
_textsubcollections_
<h3>_help:textsimplehelpheading_</h3>
_help:simplehelp_
}
_textabout_ {
<h3>_textabcol_</h3>
_Global:collectionextra_
}

Comme dernier exemple, la figure <imgref figure_part_of_the_aboutdm_macro_file> montre un extrait du fichier de macros about.dm, utilisé pour générer la page à propos de chaque collection. Elle montre la définition de trois macros, _pagetitle_ (titre de page), _content_ (contenu), et _textabout_ (texte «à propos de…»).

Utiliser les macros

Les macros sont puissantes, et peuvent sembler un peu obscures. Mais avec une bonne connaissance de HTML et un peu de pratique elles deviennent une manière rapide et facile de personnaliser votre site Greenstone.

Supposons par exemple que vous souhaitiez créer une page statique qui ressemble à votre site Greenstone actuel. Vous pouvez créer un nouveau paquetage, que vous appellerez static par exemple, dans un nouveau fichier, et y redéfinir la macro _content_. Ajoutez ce nom de fichier dans GSDLHOME/etc/main.cfg, que Greenstone charge à chaque fois qu'il est invoqué. Vous accéderez à la nouvelle page en utilisant votre URL habituelle pour Greenstone et en lui ajoutant les arguments ?a=p&p=static (on obtiendra par exemple l'URL complète suivante: http://serveur/cgi-bin/library?a=p&p=static).

Pour modifier l'apparence et l'ergonomie de Greenstone vous pouvez éditer les paquetages base et style. Pour modifier la page d'accueil de Greenstone, éditez le paquetage home (ceci est décrit dans le Guide d'installation de la bibliothèque numérique Greenstone). Pour modifier la page de requêtes, éditez le fichier query.dm.

Expérimentez sans crainte avec les macros. Les modifications apparaissent instantanément, puisque les macros sont interprétées lors de l'affichage des pages. Le langage de macros est un outil puissant que vous pouvez utiliser pour vous approprier vraiment votre site Greenstone.

Le répertoire packages

<tblcaption table_the_packages_directory_1|Le répertoirepackages></tblcaption>

< - 132 217 180 >
Paquetage URL
mg MG, abréviation de “Managing Gigabytes” (gérer les giga-octets). Logiciel de compression, d'indexation et de recherche utilisé pour gérer les données textuelles dans les collections de Greenstone. www.citri.edu.au/mg
wget Logiciel de miroir web utilisé par Greenstone. Écrit en C++. www.tuwien.ac.at/~prikryl/ wget.html
w3mir Logiciel de miroir web écrit en Perl. Ce n'est pas le programme de miroir web préféré par Greenstone car il repose sur une version spécifique mais dépassée d'un certain module Perl (qui est distribué dans le répertoirew3mir). www.math.uio.no/~janl/w3mir
windows Paquetages utilisés lors de l'exécution sous Windows.
windows/gdbm Version du gestionnaire de bases de données de GNU créée pour Windows. GDBM est fourni en standard sous Linux.
windows/crypt Programme de chiffrement utilisé pour les mots de passe des fonctions administratives de Greenstone.
windows/stlport bibliothèque standard de patrons (templates), utilisée lors de la compilation de Greenstone avec certains compilateurs pour Windows.
wv Convertisseur du format Microsoft Word (pour construire des collections à partir de documents Word), allégée pour Greenstone. sourceforge.net/projects/wvware
pdftohtml Convertisseur du format PDF utilisé pour construire des collections à partir de documents PDF. www.ra.informatik.uni-stutt gart.de/~gosho/pdftohtml
yaz Programme client Z39.50 utilisé lors des expérimentations de recherche pour rendre Greenstone compatible Z39.50. Le fichierREADME.gsdlrend compte des progrès à ce sujet. www.indexdata.dk

Le répertoire packages (paquetages), dont le contenu est représenté dans la table <tblref table_the_packages_directory_1>, est l'endroit de stockage de tout le code utilisé par Greenstone mais écrit par des tiers ou d'autres équipes de recherche. Tout le logiciel distribué avec Greenstone a été publié sous la licence publique générale de GNU (GPL). Les exécutables produits par ces paquetages sont placés dans le répertoire bin de Greenstone. Chaque paquetage est stocké dans son propre répertoire. Les différents paquetages ont des fonctions très diverses, allant de l'indexation et de la compression à la conversion de documents du format Microsoft Word en HTML. Chaque paquetage dispose d'un fichier README (lisez-moi) qui fournit des informations complémentaires le concernant.

1)
…nugget» Attention: dans Greenstone, les expressions rationnelles sont interprétées dans le langage Perl, et les conventions diffèrent subtilement d'autres conventions. Par exemple, «*» correspond à zéro ou plusieurs occurrences du caractère qui précède, et «.» remplace n'importe quel caractère – donc «nugget.*» correspond à toute chaîne commençant par «nugget», que ce préfixe soit suivi d'un point ou non. Pour imposer un point à cette position il faudrait échapper le point, et écrire «nugget..*» à la place.
2)
… collection Remarquez que les versions les plus récentes de la collection «Demo» utilisent un classificateur Hierarchy pour représenter les méta-données how to (comment faire). Dans de tels cas de figure, elles apparaîtront un peu différemment que dans la figure <imgref figure_list_classifier>.
legacy/manuals/fr/develop/getting_the_most_out_of_your_documents.txt · Last modified: 2023/03/13 01:46 by 127.0.0.1