Journal moteur de recherche dans un filesystem

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
0
1
fév.
2005
Hello !

Après la lecture de http://www.lemonde.fr/web/article/0,1-0@2-3238,36-396308,0.html(...) sur les moteurs d'indexation et de recherche ds un filesystem local, je me suis dit que windows était bien fourni de ce coté là, et même microsoft pourrait se faire doubler si son WinFS est trop en retard. Coté Apple, il existe SpotLight, intégrée a Tiger, nouvelle version d'OSX qui sera disponible probablement en juin http://www.apple.com/macosx/tiger/spotlight.html(...) .
Je me demandais donc si l'équivalent était à l'étude pour linux. Des infos à ce sujet ? Des feedback sur d'autres plateformes ?

Merci pour vos contributions !

  • # beagle

    Posté par  . Évalué à 6.

    Ça existe : c'est beagle, en cours de développement...
    http://nat.org/demos/(...)

    • [^] # Re: beagle

      Posté par  . Évalué à 3.

      ( Developpement special Gnome )

      • [^] # Re: beagle

        Posté par  (site web personnel) . Évalué à 6.

        non, beagle est un deamon a la base, il existe aussi un client KDE et des outils ligne de commande. Et puis l'outil graphique s'integre dans un systray, API commune a KDE et GNOME.

  • # D'un autre coté...

    Posté par  . Évalué à 2.

    D'un autre coté si les gens laissent trainer leur fichier n'importe où au lieu de creer des hierarchies de répertoire, c'est leur problème :)

    Est-ce qu'on prévoit de créer des robots de recherches automatique d'objets pommés dans le foutoir de certaines chambres aussi (la mienne par exemple ;) ?

    • [^] # Re: D'un autre coté...

      Posté par  . Évalué à 8.

      Oui mais l'arborescence ne résoud pas tout !
      Comment trier facilement un fichier qui rentre dans plusieurs catégories ?
      Puis fouiller dans l'arborescence reste plus chiant que de taper le mot que tu veux dans l'appli de recherche...

      • [^] # Re: D'un autre coté...

        Posté par  . Évalué à 0.

        Pour les fichiers qui rentrent dans plusieurs catégorie : les liens.

        Et puis fouiller une arbo bien faites, c'est rapide, il suffit pour cela que chaque repertoire commence par une lettre différente pour profiter au maximum de la completion automatique

        • [^] # Re: D'un autre coté...

          Posté par  (site web personnel, Mastodon) . Évalué à 7.

          Une arborescence est un classement. Unique classement. Gérer avec des liens impose de les mettre a jours lorsque des items se balade d'un repertoire a l'autre. Tu peux trier tes fichiers à ta convenance en fonction du classement qui te semble le plus intuitif, mais :
          - multiplier les classement a l'aide de lien ne propose que des classement alternatifs qui ne seront jamais exhaustifs,
          - ce ne sont pas forcément ces classements qui sera le plus intuitifs pour des tiers (probleme d'espace disque commun a plusieurs personnes, gestion de projets a plusieurs)
          - pour une recherche sur des documents anciens dont le classement était complexe, il peut dans certains cas etre très difficile de s'y retrouver.

          Par exemple concernant les photos numériques: tu peux les classer par date puis par lieu, ou par lieu puis par date. Mais si tu recherches toutes les photos prises en juillet 2003 ou toute les photos prises pdt des vacances a tombouctou, tu sera obligé de faire plusieurs recherches. D'où l'intéret d'un soft comme kimdaba par exemple. Et d'où l'intéret d'élargir le concept à d'autres types de fichiers.

          En gros, ce n'est pas pour rien que sur internet, tout le monde ou presque utilise une recherche par mot clé plutot qu'une recherche par catégorie, meme si les deux cohabitent.

          • [^] # Re: D'un autre coté...

            Posté par  . Évalué à 2.

            Je n'ai bien compris comment ces systèmes de fichiers avec recherche fonctionneront en pratique. Mes photos de vacances à Tombouctou en 2003 je les mets dans le répertoire vacances/2003/tombouctou et c'est fini. Un système où je peux rechercher par mots clés signifie que l'utilisateur a indiqué pour chaque photo une série de mots clés. A moins d'être maniaque, l'utilisateur va rapidement se lasser. Les répertoires c'est peut-être pas parfait mais c'est rapide à utiliser.

            • [^] # Re: D'un autre coté...

              Posté par  . Évalué à 4.

              Pas forcément.

              Si tu l'année suivante tu as des photos d'un séminaire à tombouctou, tu vas avoir un second répertoire de photos: boulot/2004/tombouctou. Si tu veux voir la liste de toutes tes photos de tombouctou? facile, un simple ls */*/tombouctou/*.jpg. Ok. Mais tu commences à pressentir que ça sera pas aussi facile tout le temps. Si tu commences à avoir des photos sur plusieurs niveaux, ça devient carrément bancal. Et pourtant, tu n'as associé à chacune de tes photos aucune métainformation, excepté le répertoire dans lequel elle est rangée.

              • [^] # Re: D'un autre coté...

                Posté par  . Évalué à 3.

                une technique est de repeter l'information de la hierarchie dans le nom de fichier exemple :
                boulot/2004/tombouctou/toto.jpg -> boulot/2004/tombouctou/boulot_2004_tombouctou_toto.jpg

                Ca permet des recherches plus faciles et surtout en cas de deplacement de fichier intempestif de pouvoir retrier tout ca. Par ce que bon en 10 ou 20 ans d'archivage on arrivera facilement a faire au moins une connerie :-)

        • [^] # Re: D'un autre coté...

          Posté par  . Évalué à 7.

          Dans mon ~/Doc je dois avoir pres de 3000 fichiers qui ne sont pas de moi mais qui est de la doc interessante. Ca va du C99, aux rapports USENIX, en passant par des RFCs et autres conneries des choses sur lesquels j'ai bossé.

          Tu penses que j'ai que ca a faire que ce trier ca ? Et de leur donner un nom significatif. Ranger *ton* travail est une chose, pour un developpeur de tout facon c'est dans un svn et ranger son ~ se resume a rm. Pour le mec qui ecrit 4 .doc par jour c'est une hierarchie.

          Mais vouloir tout trier ca ne marche pas toujours et ca marche même rarement.

          Pour ce qui est des liens laisse moi rire. Je gère aussi un repository en ligne, qui doit arriver à 30 000 fichiers textes. Je te laisse t'amuser avec tes liens dans tout les sens.

          Le moteur de recherche à un sens car le volume d'information que l'on manipule tout les jours est tellement important que c'est perdre son temps de l'ordonner a la main. Est ce que tu tri tes mails ? Je pense que comme tout le monde tu as 4..15 dossiers et après tu utilises la fonction recherche ? Après tout l'informatique c'est le traitement automatique de l'information non ?

    • [^] # Re: D'un autre coté...

      Posté par  (site web personnel) . Évalué à 4.

      Et pourquoi s'arrêter à la recherche sur nom de fichier quand on peut faire de la recherche sur le contenu ? Avec une seule arbo', tu arrives à tout classer impeccablement selon tout un tas de critères ?

  • # c'est presque ca

    Posté par  (site web personnel) . Évalué à 2.

    Personnellement quand je veux faire une recherche j'utilise ou :
    find / -name "mon_fichier" -print

    Ca marche mais attention ca rame, sinon il y a plus propre :
    slocate mon_fichier

    Au préalable il faut avoir créé la base qui va bien
    slocate -u /

    Il manque plus qu'une belle interface graphique et ca pourrait être bien.

    Born to Kill EndUser !

    • [^] # Re: c'est presque ca

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      ca irait pour un simple listing, mais pas de classement par pertinence ou par par catégorie, ni de recherche dans les fichiers. Un grep recursif pourrait presque aller, mais serait limité au matching dans des fichiers textes, et donc pas aux PDF, ni openoffice, ni archives, ni images, ni tags des fichiers audio, etc).

      • [^] # Re: c'est presque ca

        Posté par  . Évalué à 3.

        ca irait pour un simple listing, mais pas de classement par pertinence ou par par catégorie, ni de recherche dans les fichiers. Un grep recursif pourrait presque aller, mais serait limité au matching dans des fichiers textes, et donc pas aux PDF, ni openoffice, ni archives, ni images, ni tags des fichiers audio, etc).

        Tu peux toujour faire un script qui pour chaque fichier regarde son type et en consequence utilise la commande adequate (pdf2text | grep, ...)

        Comment ça, ça va ramer...

        • [^] # Re: c'est presque ca

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          déjà fait, mais impossible de donner une pertinence à moins de remettre a jours des index toutes les 2 secondes et faire des stats sur "les mots de plus de deux lettres, avec une majuscule, et dans une seule langue"... => solution ingérable...

        • [^] # Re: c'est presque ca

          Posté par  . Évalué à 8.

          Allez-y, continuez le brainstorming. Alors finalement ce serait bien de garder un index des fichiers pour pas que ca rame a chaque fois. Et il faudrait savoir quand un fichier est modifie/cree pour mettre a jour l'index de ce fichier.

          Et bien voila, vous avez reinvente Beagle.

    • [^] # Re: c'est presque ca

      Posté par  . Évalué à 5.

      Il manque plus qu'une belle interface graphique et ca pourrait être bien.


      Si t'as KDE, installe kio-locate et tappe "locate:recheche" dans la barre d'url de konqueror (ou du selecteur de fichiers), ça t'affiche la liste des fichiers correspondant à la recherche.

      http://kde-look.org/content/show.php?content=17201(...)

  • # Possibilités existent déjà

    Posté par  . Évalué à 5.

    Le problème existe depuis longtemps, et j'ai envie de dire que les solutions aussi. Mais bon, ces derniers temps, pas mal de "bruits" à été fait autour des moteurs de recherche locaux, et les gens en redécouvrent l'intérêt (Google, Yahoo, Microsoft).
    Donc, sous Linux, comment faire pour retrouver des infos contenues dans les documents (donc, on exclu les solutions à base de find, locate, etc) ? Je me souviens d'un post précédent, cfr http://linuxfr.org/forums/12/5120.html
    Grosso modo, on peut installer un moteur de recherche (Lucene, swish++, htdig, etc), et organiser les choses de manière à ce que les fichiers que l'on souhaite indexer le soit.
    Entretemps, j'ai continué mes recherches et mes lectures dans le domaine, et j'ai encore trouvé 3 autres outils :
    - mg
    - seft
    - libbow
    Pour le premier outil, il s'agit d'un soft développé pour illustrer le contenu d'un bouquin : "Managing gigabytes : compressing and indexing documents and images" / Ian H. Witten, Alistair Moffat, Timothy C. Bell. Il est vraiment chouette, mais bon, à utiliser dans le cadre académique. A compiler soi-même, et tout le tralala.
    Pour seft, il existe un front-end en GTK+. Son objectif est de faire des recherches full-text. J'ai peu d'info (j'ai trouvé le programme dans la liste des outils offerts à partir de la page d'accueil du bouquin sus-mentionné). A compiler soi-même et tout le tralala.
    Pour libbow, contrairement aux autres, existe pour debian. Il se compose d'une bibliothèque, et de 3 programmes. Un pour chercher, un pour classer automatiquement des documents, et je ne sais plus ce que fait le troisième. De loin mon préféré.
    En ce qui me concerne, je n'ai pas vraiment envie de voir indexé l'entièreté de mon disque dur. Je peux comprendre l'intérêt, mais je trouve que c'est un choix qui revient à l'utilisateur. Pour le reste, je pense mettre en place une solution personnelle, cela me donnera l'occasion de mettre en pratique les connaissances acquises dans la lecture du bouquin ci-dessus.
    J'espère que cela pourra aider.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.