Mais où l'ai-je donc mis ? - Une analyse comparée de trois outils de recherche de fichiers

Linux Pratique

n°

septembre 2010

Par

Bouy Michel

Système

Tag(s)

recherche

N'avez-vous jamais regardé le nombre de fichiers et dossiers dans votre répertoire personnel ? En ce qui me concerne, 158734 fichiers dans 7856 dossiers ! Certes, il y a tous les fichiers cachés, mais tout de même ! La taille gigantesque des disques actuels permet de stocker ses données sans besoin de trier. Encore faut-il les retrouver quand on en a besoin ! Qui n'a jamais parcouru avec agacement l'intégralité de son arborescence à la recherche d'un document ? Voilà donc l'utilité des outils de recherche de bureau (ORB), qu'ils se nomment Beagle, Tracker ou Nepomuk.

1. Un peu d'histoire

Au commencement étaient find et grep

La façon la plus simple de rechercher un fichier est la séquence suivante : l'utilisateur indique un nom de fichier puis l'application parcourt intégralement le ou les répertoires à la recherche de ce fichier. Simple mais efficace. C'est ce que fait la commande find utilisable en ligne de commandes ou au travers d'interfaces graphiques telles que Catfish.

Si l'on veut chercher non plus selon le nom du fichier, mais aussi en fonction de son contenu, il existe la commande grep, pourvue elle aussi d'un nombre ahurissant d'options.

En associant find et grep et à condition d'utiliser leurs nombreuses options, les possibilités de recherche sont extrêmement puissantes. Néanmoins, en pratique, ces deux commandes sont surtout utilisées par les développeurs.

Puis vint la mise à l'index (locate, ...)

Mais au-delà de la complexité syntaxique, find et grep possèdent une première limite : à chaque recherche, il leur faut parcourir intégralement les répertoires. Le temps nécessaire peut enfler de façon rédhibitoire, d'où l'idée de lire tous les noms de fichiers et de les stocker dans un fichier qui sera lu à chaque requête. Il s'agit d'un index et c'est ce que fait la commande locate.

Pour plus d'approfondissement sur ces trois commandes, nous renvoyons le lecteur au Linux Pratique Hors-Série n°18.

FTS et métadonnées (Beagle, Strigi, Tracker, ...)

Mais lorsque l'on recherche des fichiers, il n'est pas sûr que le mot-clé que l'on utilise se trouve dans le nom de fichier. Dans ce cas, find ou locate sont inefficaces, d'où l'idée d'une indexation qui ne se limite pas aux seuls noms de fichier, mais aussi à leur contenu : il s'agit là de la recherche plein texte (full text search). Lors de l'indexation, le programme lira le contenu des fichiers et stockera les mots dans le fichier index. On comprendra qu'il s'agit d'un travail nettement plus important et donc l'indexation est parfois gourmande en ressources, surtout la première fois.

Les types des fichiers dont le contenu est indexé sont nombreux : tous les documents de bureautique (Openoffice.org, Microsoft Office, KOffice, Abiword, PDF), tous les fichiers texte simples, y compris les codes de programme, les fichiers d'aide et de documentation, les mails, les conversations, les historiques de navigation, etc. Parfois, les fichiers contenus dans les archives sont aussi indexés.

Le contenu des fichiers image, son, ou vidéo ne pouvant être indexé, ce sont les métadonnées qui seront récoltées. Si pour les fichiers audio la situation est assez simple, il n'en est pas de même pour les fichiers image qui peuvent embarquer différents types de métadonnées : EXIF, IPTC, XMP, etc. Tous les ORB ne sont pas capables d'indexer la totalité des métadonnées des images.

Puis arrivèrent les ontologies et le bureau sémantique (Nepomuk)

L'indexation est un outil formidable, mais sa puissance n'a d'égal que son aveuglement : un index entasse des dizaines de milliers de mots en vrac sans aucun lien avec leur sens. Si l'on effectue une recherche sur la base du mot-clé « cheval », tout ORB renverra notamment les fichiers contenant le mot « chevalier », y compris s'il s'agit du nom propre d'un auteur de courriel, mais ne tiendra aucun compte de ceux qui contiennent le mot « jument », « poulain » ou « équitation ». Pour pallier ce problème, il est nécessaire de mettre l'index en relation avec des « ontologies » (cf. encadré).

Qu'est-ce qu'une ontologie ?

« Une ontologie est l'ensemble structuré des termes et concepts représentant le sens d'un champ d'informations, que ce soit par les métadonnées d'un espace de noms, ou les éléments d'un domaine de connaissances. L'ontologie constitue en soi un modèle de données représentatif d'un ensemble de concepts dans un domaine, ainsi que des relations entre ces concepts. » - Extrait de l'article Wikipédia [1].

Il s'agit donc d'une modélisation des connaissances dans un domaine défini. Il existe un nombre potentiellement infini d'ontologies relatives chacune à un champ précis de connaissance. En informatique, le développement des standards et syntaxes en lien avec les ontologies a principalement concerné le problème du Web. Les moteurs de recherche qui indexent le contenu du Web sont face au même problème d'absence de sens dans un contexte où le nombre de mots-clés indexés se compte par milliards.

À l'échelle de notre ordinateur, l'approche par les ontologies dans les ORB est principalement portée par le projet Nepomuk (Networked Environment for Personalized, Ontology-based Management of Unified Knowledge). Nepomuk est un projet cofinancé par l'Union Européenne et porté par de nombreuses sociétés, universités et centres de recherche visant à permettre la constitution d'ontologies à l'échelle de chaque utilisateur, puis l'échange et la discussion sur ces ontologies au sein du net et des réseaux sociaux.

Plus concrètement, il s'agit de fournir des outils permettant de constituer un bureau sémantique puis d'en partager la logique d'organisation pour bénéficier des apports des autres et réciproquement. Un bureau sémantique est un ordinateur dans lequel les différents éléments (fichiers, contacts, mails, etc.) sont annotés, reliés en fonction de leur significations et représentés de façon globale.

Dans le monde Linux, c'est KDE, Mandriva et, dans une moindre mesure, Mozilla qui sont impliqués dans le projet Nepomuk. Cela a pour conséquence que seuls les utilisateurs de KDE peuvent pour l'instant en bénéficier. Précisons en outre que Nepomuk est un projet en plein développement et dont les applications pratiques au niveau des applications restent encore limitées. L'utilisation que l'on peut faire actuellement de Nepomuk au sein d'un bureau KDE ne reflète pas encore toutes les possibilités que pourra offrir un bureau sémantique.

2. Quoi et comment chercher ?

Quel que soit le moteur de recherche utilisé, il existe des problèmes communs propres à la recherche de données dans un index.

Précision contre retour : bien choisir son indexation

Quand on tape un ou plusieurs mots-clés, on s'attend à ce que l'application nous renvoie tous les fichiers concernés et seulement ceux-là : il faut donc à l'ORB une bonne sensibilité (ne pas oublier de fichiers) mais aussi une forte spécificité (ne pas renvoyer des fichiers qui ne correspondent pas à la requête). Étant donné le caractère polysémique du langage naturel, il n'est jamais possible d'atteindre la perfection (sensibilité et spécificité de 100%), d'autant plus que si la spécificité tend à diminuer, la sensibilité augmente et vice-versa.

Une des façons d'améliorer la qualité de la recherche est de définir raisonnablement ce que l'on indexe : Un outil comme Beagle (Fig. 1) est potentiellement capable de rechercher du texte ou des métadonnées dans presque toutes les applications : courrier électronique, messagerie instantanée, lecteur RSS, etc.

Fig. 1 : Beagle propose d'indexer des données issues d'une liste impressionnante d'applications.

C'est extraordinaire, mais peut rendre une requête totalement inutilisable par le nombre trop élevé de retours sans intérêt. Le problème est particulièrement marqué avec les courriers électroniques car les messages ne sont généralement pas stockés séparément mais dans des fichiers correspondant à l'arborescence (inbox, outbox, etc.). Sur la base d'une requête dans un ORB, il est en général impossible d'ouvrir le message. Maintenant que les applications de messagerie électronique, telles Thunderbird, possèdent des moteurs de recherche très évolués, il est peut-être plus raisonnable de ne pas chercher à indexer les messages électroniques dans un ORB généraliste. Cette démarche est contradictoire avec la notion de bureau sémantique, mais il me semble que les outils actuellement disponibles (à l'exception peut-être de Kmail-nepomuk sous Mandriva 2010 et de Recoll) sont mal adaptés à une indexation incluant les courriels.

Afin d'améliorer les résultats d'une recherche, chaque utilisateur doit définir le type de fichiers qu'il veut indexer. Certains peuvent être éliminés dès la mise en place de l'ORB, mais le plus efficace est de faire le ménage au fur et à mesure que l'on effectue des requêtes.

Racination, caractères « joker », accentuations et formes grammaticales

Nous avons vu que la recherche par mots-clés pose le problème du sens du mot, mais en amont se pose déjà le problème de la forme grammaticale : si l'on recherche sur le mot « étable », l'ORB doit-il renvoyer les fichiers contenant aussi le mot au pluriel ? Qu'en est-il des verbes conjugués ? Le fait d'élargir la recherche à des mots proches de l'expression saisie s'appelle le stemming (du verbe to stem = découler ou du substantif stem = racine). Le stemming, qui se traduit par lemmatisation (ou racination), consiste à réduire un mot à son lemme (ou forme canonique) : par exemple, « petit » est la forme canonique de « petite », « petits », « petites », etc. La lemmatisation concerne aussi les accents.

Pour pallier les recherches trop strictes, il est aussi possible d'introduire un caractère joker qui remplace un ou plusieurs caractères. Habituellement, en informatique, le caractère « * » remplace une chaîne de caractères (éta* peut signifier étable, établir, établissement, etc.), tandis que « ? » ne remplace qu'un seul caractère (éta ? ne peut renvoyer que état, étal, etc.). Pourtant, la majorité des ORB un peu évolués ne reconnaissent pas ce dernier caractère, et certains acceptent mal le caractère « * ».

Dans tous les cas, on se retrouve face au problème souligné précédemment entre sensibilité et spécificité : des moteurs au comportement strict risquent d'oublier des fichiers importants, ceux qui balayent trop large risquent de noyer l'utilisateur sous un nombre ingérable de réponses.

Opérateurs booléens

Une requête sera d'autant plus précise que l'on utilisera plusieurs mots-clés. Ceux-ci sont liés par des opérateurs booléens qui sont au nombre de 3 : ET, OU, SAUF. Dans la majorité des ORB, l'utilisation de deux mots-clés sans opérateur correspondra à une requête ET (fichiers possédant les deux mots-clés à la fois). Si l'on veut faire une recherche OU, il faudra en général écrire OR entre les deux mots-clés. Il s'agit là d'un OU inclusif, c'est-à-dire que le moteur de recherche renverra une liste de fichiers possédant un des deux mots-clés ou les deux à la fois. L'opérateur OU exclusif qui renverrait les fichiers possédant l'un ou l'autre des critères sans posséder les deux à la fois n'est pas utilisable. L'opérateur SAUF consiste à rechercher les fichiers ne possédant pas le critère cité.

L'utilisation d'un opérateur booléen donne beaucoup de puissance aux ORB. Mais le recours à deux opérateurs successivement est difficile puisque, contrairement à une formule mathématique, l'utilisation des parenthèses est impossible.

3. Beagle, Tracker et Nepomuk, petite analyse comparative

Motivation du choix

Mais alors, concrètement, qu'en est-il des ORB sous Linux ?

En fait, il existe un choix assez vaste. Dans ce comparatif, nous avons décidé de ne retenir que des moteurs de recherche possédant les caractéristiques suivantes : indexation des fichiers, possibilité de recherche plein texte, indexation et recherche sur la base des métadonnées, utilisation rapide et simple. De ce fait, nous n'analyserons pas les outils en ligne de commandes (find, locate, grep), ni GoogleDS (qui n'indexe pas les métadonnées). Il restait donc Beagle, Tracker, Strigi, Recoll et Nepomuk-KDE.

Strigi était l'ORB de KDE jusqu'à ce qu'apparaisse Nepomuk, qui s'appuie sur lui dans les premières versions. Il risque de disparaître au fur et à mesure de l'avancée de Nepomuk. Recoll est un programme qui semble extrêmement puissant dans la recherche textuelle, mais il n'indexe que les métadonnées EXIF des images, ce qui est un peu limité. C'est un logiciel à recommander pour les personnes recherchant uniquement sur des fichiers texte. Pinot est écarté pour les mêmes raisons (pas d'indexation des métadonnées IPTC ou XMP).

Le comparatif portera donc sur Beagle, Tracker et Nepomuk-KDE.

Indexation et paramétrage

Ces trois ORB fonctionnent sur le principe d'un démon (beagled ou trackerd) qui se lance au démarrage du système et indexe en temps réel les répertoires et fichiers définis (Fig. 2).

Fig. 2 : Les différents programmes de recherche chargent un démon qui surveille en permanence les répertoires à indexer.

Nepomuk, au travers de la commande nepomukserver, lance un plus grand nombre de services et on peut constater que, même au repos, son indexeur virtuoso occupe une place en mémoire conséquente (Fig. 3). C'est la limite des démons d'indexation qui, notamment en début d'indexation, consomment une quantité de ressources RAM et processeur non négligeable.

Fig. 3 : Nepomuk charge de nombreux services en mémoire vive et son indexeur virtuoso est très gourmand.

Dans la zone de notification apparaissent les applets permettant une utilisation rapide de ces ORB (Fig. 4). Le raccourci [F12] va lancer la fenêtre principale de Beagle qui permettra le paramétrage. Un clic droit permet d'accéder aux menus de paramétrage de Tracker (Fig. 5) ou Nepomuk (Fig. 6). Le paramétrage des index est similaire dans les trois applications. Par défaut, le répertoire personnel est indexé et un certain nombre de fichiers sont exclus de l'indexation. Il est possible d'ajouter ou d'exclure d'autres répertoires et d'éviter l'indexation de certains fichiers (Fig. 7). Dans le cas de Nepomuk, la présentation est un peu différente (Fig. 8).

Beagle offre la possibilité de choisir les applications dont les fichiers seront indexés (Fig. 1), ou de façon plus simple, une alternative via le menu recherche.

L'exclusion de certains fichiers de l'indexation est à faire plutôt au fur et à mesure que l'on utilise l'ORB, car c'est par l'expérience que l'on constate l'absence d'intérêt de certains types de fichiers.

Comme le montre la figure 9, l'index est consultable quelle que soit l'application. Il existe d'autres éléments de paramétrage touchant aux performances, permettant d'éviter une indexation durant l'utilisation de l'ordinateur ou lorsque celui-ci fonctionne sur batterie. C'est Tracker qui propose les paramétrages les plus détaillés, tandis que Nepomuk est, pour l'instant, assez pauvre dans ce domaine. Beagle offre en théorie la possibilité d'effectuer des recherches sur des index externes, mais nous n'avons pas eu l'occasion de tester cette fonctionnalité.

Fig. 4 : La zone de notification permet d'accéder aux outils de recherche et à leur paramétrage.

Fig. 5 : Tracker offre un menu contextuel assez détaillé.

Fig. 6 : Par contre, le menu contextuel de Nepomuk est très sobre.

Fig. 7 : Le menu de paramétrage de l'indexation de Tracker propose diverses possibilités d'ajouts ou d'exclusions de répertoires, mais permet aussi d'écarter certains fichiers.

Fig. 8 : Nepomuk permet de choisir les répertoires à indexer ou à exclure de façon assez simple.

Fig. 9 : Quel que soit l'ORB, il est possible de consulter l'état de l'indexation.

Interface de recherche

La touche [F12] permet de lancer l'interface de recherche de Beagle (Fig. 10), tandis que pour Tracker (Fig. 11), il faut cliquer sur l'icône de la zone de notification. Dans les deux cas, les fenêtres sont assez similaires. Notons que Beagle recherche à la volée quelques secondes après que l'on ait inscrit le texte recherché. Ce comportement (qui peut être désactivé) associé au lancement par [F12] donne une fluidité particulièrement agréable à Beagle. Beagle trie les fichiers par type, tandis que Tracker offre la possibilité de n'afficher que certains types de fichiers.

Fig. 10 : Beagle se caractérise par une grande rapidité d'affichage et de recherche.

Fig. 11 : Le contenu du fichier est plus détaillé avec Tracker.

L'affichage des miniatures des images ou de la partie de texte correspondant à la recherche est un atout important de Beagle et Tracker. Ces deux applications possèdent en revanche un inconvénient qui peut sembler un détail, mais s'avère pénible à la longue : ils n'affichent qu'une dizaine de fichiers à la fois et il faut recourir à la flèche de droite pour connaître les fichiers suivants. Le défilement avec la molette de la souris aurait offert une bien meilleure ergonomie.

Pour Nepomuk (Fig. 12), l'expression est saisie dans le champ de recherche et le résultat renvoyé comme une liste de fichiers d'un répertoire. Il est ainsi possible de trier les fichiers, de consulter l'ensemble de la liste assez rapidement et d'utiliser le menu contextuel de Dolphin.

Fig. 12 : L'accès à Nepomuk est bien différent puisqu'il se fait aujourd'hui via Dolphin.

Nepomuk a la particularité d'afficher des choix possibles au fur et à mesure de la frappe (Fig. 13) : il s'agit soit d'étiquettes qu'il a répertoriées, soit de critères de recherche particuliers (taille des fichiers), soit d'opérateurs logiques. Si l'on tape par exemple « afghanistan » dans le champ de recherche sans cliquer sur l'étiquette qui apparaît, Nepomuk renverra tous les fichiers ayant ce mot soit dans leurs étiquettes, soit dans le nom de fichier, soit dans le texte. Dans cette liste de fichiers, on trouvera notamment un fichier avec l'icône de Nepomuk correspondant à tous les fichiers portant l'étiquette « afghanistan ».

Fig. 13 : Le champ de recherche de Nepomuk est interactif.

Mais la grande nouveauté avec Nepomuk est bien de pouvoir étiqueter des fichiers « à la volée » dans les diverses applications du bureau sémantique (Fig. 14). Avec Dolphin, il suffit de cliquer sur les liens dans le volet de droite et de cocher la case correspondante à l'étiquette ou d'en saisir une nouvelle.

Malgré ses limites, c'est une fonction intéressante permettant de « classer » ses fichiers : si j'effectue une recherche sur les mots « pneumonie » et « agneau », Nepomuk me renverra un certain nombre de fichiers sans intérêt pour moi. Mais dans cette liste, il me devient possible d'étiqueter ceux des fichiers qui m'intéressent avec les étiquettes « pneumonie » et « agneau ». La prochaine recherche, via les étiquettes, sera beaucoup plus simple et efficace.

Fig. 14 : L'étiquetage avec Nepomuk est une fonction encore rudimentaire : il n'y a pas de hiérarchie dans les étiquettes, la fenêtre est petite, sans autre champ de saisie que la création (d'où la nécessité de dérouler à la souris et non au clavier).

À la différence des métadonnées IPTC/XMP ou des tags audio, les étiquettes Nepomuk ne sont pas incluses dans les fichiers, mais portées par un fichier externe. Si on change d'ordinateur, ces étiquettes disparaissent. Cela en limite beaucoup l'intérêt.

Mais revenons à la fonction de recherche.

Si l'on associe deux mots, les trois ORB considéreront par défaut qu'ils sont liés par l'opérateur ET. À l'inverse, il faut spécifier OR dans Beagle, ou OU dans Nepomuk si l'on veut des fichiers correspondant à l'une ou l'autre des expressions saisies. Pour utiliser l'opérateur booléen SAUF, il faut écrire le mot NON dans Nepomuk ou un « - » dans Beagle. Par contre, Tracker ne connaît pas les opérateurs booléens.

Avec Nepomuk et Beagle, il est possible de rechercher une expression entière à condition de l'écrire entre guillemets. Tracker n'offre pas cette possibilité.

Enfin, il est possible d'effectuer des recherches sur les extensions de fichiers, des valeurs EXIF (nom de l'appareil photo, par exemple), ou même des nombres. Dans ce dernier cas, le retour est parfois imprévisible car il peut s'agir de la résolution d'une image, de la date de création/modification du fichier, de la valeur ASA d'une photo, etc.

Une fois la liste des fichiers recherchés obtenue, un menu contextuel peut être affiché par un clic sur le bouton droit et permet d'ouvrir le fichier ou le répertoire dans lequel il se trouve. Ce menu est plus riche dans Beagle que dans Tracker. Avec Nepomuk, il est bien sûr beaucoup plus détaillé puisque les fichiers sont affichés dans Dolphin.

Puissance et efficacité

Fichiers texte et métadonnées

Quels sont les types de fichiers indexés par chacun des moteurs ? Seul le site de Beagle en donne une liste exhaustive [2]. Il semble que Nepomuk et Tracker soient capables d'indexer les mêmes types de fichiers : tous les fichiers texte, les fichiers de bureautique, les fichiers image, son et vidéo, les codes source, les fichiers d'aide, etc.

Ces trois moteurs indexent aussi les métadonnées des images, mais de façon différente selon les ORB. Ils indexent tous les trois les données EXIF (conditions de prise de vue), mais Beagle n'indexe que les métadonnées IPTC, Tracker les métadonnées XMP et Nepomuk n'indexe aucune de ces métadonnées. Pour celui qui utilise Digikam en gestionnaire d'images, il est donc impératif de le configurer afin qu'il lise/écrive les données IPTC/XMP et Nepomuk. Cela entraîne une homogénéisation des « tags » permettant une indexation quel que soit l'ORB. Par contre, contrairement à ce qui est annoncé sur le site web, Beagle ne semble pas indexer les étiquettes F-Spot. Il indexe en revanche très bien les fichiers inclus dans des archives (.zip, .tar.bz, etc.), ce que ne savent faire ni Tracker, ni Nepomuk.

Des modes de lemmatisation différents

Au-delà d'une apparence assez similaire, Beagle et Tracker offrent un fonctionnement bien différent. Si l'on recherche le simple mot « porter », Beagle renvoie 18 documents, tandis que Tracker en propose beaucoup plus (Fig. 15) !

Fig. 15 : Pour la même recherche, Beagle renvoie beaucoup moins de réponses que Tracker car ce dernier procède à une lemmatisation assez large.

En fait, Tracker, comme Beagle ou Nepomuk, pratiquent la lemmatisation, mais chacun suit des règles différentes. Pour comprendre les nuances, il faut effectuer un test sur une série de fichiers simples portant des variations autour d'un même mot (singulier, pluriel, accents, conjugaison, substantif, etc.). La figure 16 récapitule les résultats de ce test.

Fig. 16 : Ce tableau récapitule la différence des modes de lemmatisation entre les trois ORB. La ligne du haut correspond au mot « taper » dans le champ de recherche, tandis que la 1ère colonne représente les fichiers possédant ce mot. Par exemple, pour trouver le fichier contenant le mot « arrimeront », il faut écrire exactement ce mot dans le champ de recherche de Beagle, mais il suffit d'écrire « arrime » ou « arrim » avec Nepomuk ou Tracker.

On constate que Tracker procède à une racination incluant les formes avec accent ou conjugaison. À l'inverse, Beagle est assez strict, particulièrement avec les accents et les formes pronominales. Nepomuk est intermédiaire entre les deux. En particulier, il n'accepte pas de forme pronominale (« s'arrime ») dans la barre de recherche. Sur des saisies incomplètes (« arrim »), Tracker comme Nepomuk renvoie presque toutes les variations sur le mot « arrimer ».

Beagle est donc très spécifique mais peut manquer de sensibilité, tandis que les deux autres moteurs risquent de renvoyer beaucoup trop de résultats (faible spécificité), mais oublieront peu de fichiers (bonne sensibilité).

Réindexation et rapidité

Beagle a la particularité d'indexer les nouveaux fichiers avec une rapidité stupéfiante : créez un nouveau fichier (.odt, par exemple) avec un mot spécifique dedans. Enregistrez-le et effectuez une recherche via Beagle : il est déjà indexé ! Nepomuk se montre, lui, d'une lourdeur assez inquiétante : Virtuoso, le moteur d'indexation occupe plus de 700 Mo de mémoire vive, soit à peu près autant que la somme de tous les autres programmes ouverts au même moment ! Le temps nécessaire pour fournir une réponse à une recherche est aussi bien plus élevé que celui nécessité par Beagle ou Tracker.

Des ORB parfois facétieux

On ne peut finir cette analyse sans rapporter quelques anomalies dans le fonctionnement de ces trois outils de recherche. Après saisie d'une expression donnée, Beagle renvoie parfois « désolé cette re... ». On s'apercevra ensuite que, quelle que soit l'expression tapée, la réponse sera la même. La consultation de l'état de l'index via le menu montre que tous les compteurs sont à zéro : l'index est vide, ou plutôt, pour une raison inconnue, Beagle a perdu son index. Seule solution, le forcer à réindexer en allant dans le répertoire ~/.beagle effacer le sous-répertoire /index. C'est un peu agaçant, mais...

Tracker offre parfois une autre facétie : il se trompe dans le décompte des fichiers présentés à la suite d'une recherche. Il en double le nombre sans raison. Ce problème semble se résoudre, là encore, en forçant une réindexation par le biais de la petite icône de la barre des tâches (clic droit et re-index). Comme pour Nepomuk, Tracker offre la possibilité d'étiqueter les fichiers issus de la recherche (image), mais ces étiquettes sont inutilisables dans la version 0.6.95 et disparaissent en cas de réindexation.

Comme le montre l'image, Nepomuk a la fâcheuse tendance à renvoyer une quantité de fichiers étranges sans aucune utilité actuelle, mais correspondant sûrement à des fonctions de bureau sémantique non encore mises en œuvre (Fig. 17).

Fig. 17 : Lors de certaines recherches, Nepomuk renvoie une grande quantité de fichiers portant son icône et probablement créés par lui-même.

4. Alors finalement...

Nepomuk, un chantier en cours

Nepomuk apparaît comme un mastodonte. Il occupe une place considérable en mémoire et les recherches sont un peu longues. Mais surtout, c'est un projet en cours d'évolution qui ne donne probablement pas encore toute la puissance que peuvent offrir les outils d'un bureau sémantique. L'intégration dans l'explorateur de fichiers, l'affichage en cours de frappe des étiquettes existantes, la possibilité d'étiqueter « à la volée », etc., sont des fonctionnalités particulièrement intéressantes.

Nepomuk nécessite un ordinateur puissant et reste évidemment réservé aux utilisateurs de KDE, bien qu'il soit possible de le démarrer sous GNOME en tapant la commande nepomukserver. C'est un outil à suivre de près.

Tracker, un outil robuste et prometteur

Tracker est un ORB robuste, parfois un peu lent mais possédant deux avantages. D'une part, il pratique une racination large permettant une recherche étendue à toutes les formes syntaxiques et grammaticales d'un mot. Et d'autre part, l'affichage de l'expression recherchée dans son contexte est plus détaillé que pour Beagle.

Beagle, un ORB rapide mais en sommeil

Beagle est un ORB léger, véloce, très ergonomique par sa recherche en cours de frappe et précis dans les expressions à trouver. Cela en fait un outil que l'on peut toujours avoir sous la main, mais dont il faut connaître les quelques défauts : perte d'index, sensibilité aux accents, absence d'indexation des étiquettes XMP.

Notons que Beagle comme Tracker ont des envies d'ontologie. Il s'agit d'un côté du projet Beagle++ et de l'autre, des versions à venir de Tracker (0.7 et surtout 0.8). Hélas, il semble que le développement de Beagle++ soit à l'arrêt. D'une manière générale, Beagle n'est plus en développement actif, ce qui risque de le condamner à terme.

Et pour les indécis, pourquoi ne pas utiliser l'un ou l'autre de ces ORB. C'est la possibilité qu'offre la deskbar du bureau GNOME ou une petite application fort intéressante dénommée Catfish – développée par le créateur de Midori [3] – et qui permet le choix entre plusieurs outils de recherche (find, locate, beagle, tracker, pinot, doodle). Bien que manquant un peu d'ergonomie, Catfish peut s'avérer très pratique.

Mais rêvons un peu à l'ORB idéal

Il serait rapide, léger en mémoire, démarrant d'une touche ou intégré dans diverses applications courantes, indexant tous les types de métadonnées et le plein texte. Pratiquant une racination raisonnable et incluant les fonctions du bureau sémantique, il faudrait qu'il offre des fonctionnalités encore absentes ou mal mises en œuvre actuellement : ainsi, il pourrait proposer d'un côté les différents sens (ontologies) et formes dérivées (racination) de l'expression recherchée, permettant d'un clic de passer de l'une à l'autre. Il devrait permettre d’ajouter des mots-clés au fur et à mesure de la recherche afin d'affiner celle-ci.

L'affichage du contenu du fichier pourrait se faire par survol de la souris, mais surtout, un tel ORB pourrait tirer parti des possibilités d'affichage 3D que possèdent KDE et Gnome en offrant un graphe qui lierait les différents mots-clés. La figure 18 est un mock-up d'un tel moteur qui s'inspire de l'outil fourni par le CNTRL (Centre National de Ressources Textuelles et Lexicales)... site à consulter absolument pour les amoureux des mots [4].

Fig. 18 : ATTENTION, ceci est un MOCK-UP : Après la saisie du mot recherché, l'ORB affiche un graphe 3D montrant toutes les relations sémantiques du mot avec ceux qui ont été indexés (plein texte ou métadonnées quand le terme est souligné). Il est possible de faire pivoter ce graphe et par un double-clic, de remplacer le mot recherché par un autre. Le champ secondaire permet d'ajouter d'autres mots-clés afin de préciser la recherche, tandis que le champ de droite affiche au fur et à mesure la liste des fichiers trouvés. Un simple survol à la souris fournit les informations sur le fichier.