http://mail.gnome.org/archives/tracker-list/2007-January/pdf(...)
Un petit article assez intéressant et plutôt objectif sur l'état actuel de ces petits outils que l'on risque de retrouver sur tous nos bureaux bientôt.
L'auteur y compare Beagle, JIndex, Meta-Tracker et Strigi sur les performances de chacun en terme de support de fichiers (beagle gagnant), de consommation CPU (gagnant strigi), de taille de la base d'indéxation (gagnant beagle), de temps d'indéxation (gagnant strigi), de consommation mémoire (gagnant strigi), de pertinence de résultats (gagnant JIndex), etc...
Globalement, les plus récents Meta-tracker et surtout Strigi obtiennent de très bons résultats, alors que Beagle apporte un outil éprouvé mais poussif.
En tout cas, un document assez instructif sur l'état de l'art.
Journal Etatde l'art des outils de recherches pour le bureau
18
jan.
2007
# Et locate ?
Posté par zebra3 . Évalué à 10.
Bien sûr, ça n'indexe pas le contenu, et ça n'est pas en temps réel, mais bon au moins :
* c'est un standard UNIX, donc présent par défaut quasiment partout,
* on sait que ça marche,
* c'est rapide (à la recherche comme à l'indexation),
* c'est du C, donc pas de Mono ou de Qt à installer,
Perso, ça me suffit amplement, je ne fais des recherches que par nom.
En plus, avec kio-locate, on peut créer des dossiers virtuels sous Konqueror (en tapant "locate:terme recherché" dans la barre d'adresse).
Je ne comprends pas que cela soit si peu utilisé...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Et locate ?
Posté par Colin Pitrat (site web personnel) . Évalué à 1.
[^] # Re: Et locate ?
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Et locate ?
Posté par lamiricore . Évalué à 3.
[^] # Re: Et locate ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 10.
Ensuite, il existe une interface kde/qt, il ne manque plus qu'un gnomiste fasse une interface Gnome....
A noter que strigi apporte aussi deepgrep et deepfind, qui va chercher dans les RPM, pdf, mail, ... l'art d'ajouter la puissance des outils moderne a notre puissante ligne de commande pour nos scripts.
[^] # Re: Et locate ?
Posté par yoplait . Évalué à 2.
On peut remplacer strigi par tracker, qt par GTK+ et c++ par C et la phrase resterait juste ;-).
Si le type de Strigi tient toujours à une solution Freedesktop, on peut parier sur le succès prochain de Wasabi. L'idée c'est de construire des specs/apis pour les indexeurs et les BDD de métadatas afin de pouvoir changer la machinerie de manière transparente.
http://mail.gnome.org/archives/desktop-devel-list/2007-Janua(...)
[^] # Re: Et locate ?
Posté par Infernal Quack (site web personnel) . Évalué à 4.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Et locate ?
Posté par Pol' uX (site web personnel) . Évalué à 4.
Personnellement, je sais où je range mes fichiers et mes bookmarks. J'ai beagle, installé par défaut avec fc6, mais je ne l'utilise jamais. Quant à locate, ce n'est pas posix, donc ce n'est pas partout, contrairement à find.
find n'est pas conçu pour indexer, mais vu le nombre de recherches que je fait par an, ça me suffit ;-) et si je dois faire plusieurs recherches à la suite, je me rend rapidement compte de l'intérêt des mémoires caches.
Adhérer à l'April, ça vous tente ?
[^] # Re: Et locate ?
Posté par jerome (site web personnel) . Évalué à 4.
En fait, l'intérêt en tant qu'outil de recherche tient aussi à la possibilité de trouver des fichiers difficilement classables si ce n'est via un logiciel spécialisé :
- client mail pour les mails (pour retrouver un mail dans une arborescence de Maildir, c'est pas forcément facile)
- une bibliothèque pour les images, films, musique
- etc
De plus, ces outils peuvent être à l'origine de fonctionnalités conviviales et factorisables à l'échelle d'un DE comme KDE, GNOME ou XFCE en permettant par exemple dans une appli de fournir des liens vers d'autres fichiers proches selon certains critères du contexte courant.
Ex: tu regardes une photo, ça te créé directement des liens vers les photos portant les mêmes tags, les mails contenant cette photo en pièce jointe, etc, etc.
[^] # Re: Et locate ?
Posté par Nÿco (site web personnel) . Évalué à 6.
[^] # Re: Et locate ?
Posté par Aldoo . Évalué à 3.
Ainsi, il conviendrait de faire un alias de locate sur une recherche de nom de fichier par strigi/beagle/... .
Voire de programmer une nouvelle commande locate qui serait un frontend pour ces moteurs, qui hériterait des options de ligne de commande de locate, mais proposerait des options supplémentaires pour utiliser les fonctionnalités des nouveaux moteus (requête sur les métadonnées, par exemple).
[^] # Re: Et locate ?
Posté par ola . Évalué à 10.
Surement parce que, comme tu le dis tres bien toi meme :
1) ca n'indexe pas le contenu
2) ca n'est pas en temps reel
et que donc, ne repondant pas a la problematique "indexer le contenu en temps reel", ca risque pas d'etre utilise pour repondre a la problematique...
Un peu comme si tu te demandais pourquoi les gens n'utilisent pas un tournevis cruciforme pour visser des vis plates...
[^] # Re: Et locate ?
Posté par kowalsky . Évalué à 0.
peut etre deja bon à l'heure pres, non...?
Mais bon, locate à ces limites, comme chaque outils.
[^] # Re: Et locate ?
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
1) il est hors de question d'utiliser find lorsqu'il s'agit de parcourir 1 To de données.
2) il est hors de question d'avoir 50 beagle qui tourne simultanément !!!!
3) locate est instantanée et largement suffisant pour retrouver des fichiers.
idem sur un poste perso
Je veux bien d'un indexeur de contenu en temps réel, mais il a interet d'être vachement performant, pour me faire abandonner locate.
Je n'ose pas imaginer la taille de l'index de ce genre d'indexeur si il tombe malhencontreusement sur une arborescence SVN du projet GNOME...
Le seul endroit où je fait des recherches dans le contenu, c'est pour mes mails, et pour ça j'utilise SQUAT directement sur mon serveur IMAP...
[^] # Re: Et locate ?
Posté par ZeroHeure (site web personnel) . Évalué à 0.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Et locate ?
Posté par ola . Évalué à 5.
Version moins sarcastique : effectivement, techniquement c'est possible, maintenant quitte a faire un gros truc, autant le faire proprement plutot qu'en detournant des outils dont ce n'est pas la finalite.
Tu vas pas t'infliger un updatedb tous les quart d'heure...
# Pourquoi en faire des concurrents ?
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Ceci éviterait d'avoir des projets "bon en support de fichier", "lent en indexation", "moyen en consommation de CPU" :-/
Moi je verrai même ça comme un système multi-agents. Pour que le tout fonctionne ensemble, il faut juste qu'ils parlent la même langue (encodage des informations). Par contre, l'implémentation (langage, architecture, agent local/distribué, ...) en s'en fout.
Haypo
[^] # Re: Pourquoi en faire des concurrents ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Pourquoi en faire des concurrents ?
Posté par Yann KLIS (site web personnel) . Évalué à 4.
[^] # Re: Pourquoi en faire des concurrents ?
Posté par phoenix (site web personnel) . Évalué à 1.
Par exemple :
Le fait que JIndex soit plus performant peut être lié à sa "base de donnée". Mais cette base de donnée performante, peut-être lente de construction.
Ce qui signifie que le choix du projet dépend aussi du genre de performance qu'on veux (plus rapide à indexer, plus rapide à rechercher, plus pertinent dans les résultat, plus de type de fichier).
Je pense que la recherche dépend non seulement du logiciel, mais pas seulement, il doit aussi dépendre de la construction de la base de données.
[^] # Re: Pourquoi en faire des concurrents ?
Posté par feth . Évalué à 2.
C'est peut être un marteau un peu gros pour l'avantage qu'on en retirerait : la réutilisabilité (when all you have is a hammer, everything looks like a nail).
Par contre le MAS nous amène à mentionner un format qui se veut universel pour décrire le monde : les ontologies. Toi qui écris une machine à extraire les données, penses-tu qu'avoir un seul "parseur" dans hachoir serait possible, si on donne à ce parseur deux types d'entrées : 1) ontologie 2) flux à parser.
Une ontologie peut parfaitement être partielle, c'est une propriété très utile : cela permettrait :
1) de parser les flux en ne tenant compte que des informations qui nous intéressent (en supprimant des parties de l'ontologie
2) de recevoir des contributions autosuffisantes.
Ce post appelle la relecture par des gens du métier, s'il y en a qui passent.
[^] # Re: Pourquoi en faire des concurrents ?
Posté par feth . Évalué à 3.
Une ontologie est la spécification d'une conceptualisation d'un domaine de connaissance. (merci wikipedia).
http://fr.wikipedia.org/wiki/Ontologie_(informatique) L'article a l'air complet, désolé, je n'ai pas le temps de creuser maintenant.
[^] # Re: Pourquoi en faire des concurrents ?
Posté par Rémi Pannequin . Évalué à 2.
Un atelier reconfigurable de production industriel est un exemple d'un tel système (j'utilise cet exemple car c'est ce que je connais le mieux...). On associe un agent à chaque élément du système (machine, commande client, etc...), les agents sont capables de communiquer de manière intelligible avec les autres agents (par l'utilisation d'un langage et d'une ontologie commune).
L'idée principale concerne la gestion de la complexité :
- pour représenter l'information, pas besoin d'un modèle global, chaque agent est muni d'un modéle local plus facile à maintenir.
- pour résoudre les problèmes, on peut se contenter de définir des régles locales simples (le comportement de chaque agent), plutôt qu'un comportement global complexe (un exemple, l'optimisation par colonie de foumis).
Dans le cas de l'indexation en temps réel du contenu de fichiers, je ne pense pas qu'une approche multi-agent soit judicieuse. En effet, le multi-agent permet de s'adapter à des systèmes complexes et en évolution, mais ce n'est pas gratuit : le développement d'un MAS est beaucoup plus complexe.
Donc le marteau MAS me parait effectivement un peu gros...
[^] # Re: Pourquoi en faire des concurrents ?
Posté par Jean Roc Morreale . Évalué à 2.
# Fonctionnalités
Posté par SF . Évalué à 4.
De même, quelle est leur vitesse de réponse à une requête complexe ? Car bon moi le temps d'indexation je m'en moque un peu si elle se fait pendant que je ne m'occupe pas du micro et si l'indexation ne se relance pas inutilement tout le temps (ça peut faire une différence ça aussi, la capacité à indexer tous les documents sans forcément tout re mouliner).
J'ai vu aussi que certaines utilisations annexes comme utiliser tracker comme base de données de lecteur multimédia ou pour tagger les fichiers et créer des dossiers virtuels dans les explorateurs de fichiers étaient envisagées. Je trouve ça plus intéressant à terme que la recherche de fichiers, tous ces outils permettront-ils cela facilement ?
La recherche c'est bien mais j'avous que je l'utilise très rarement sur mon poste (sur les postes des autres par contre ça devient indispensable) donc je suis plus enclin à m'intéresser à aux fonctionnalités annexes.
# au moins un truc est clair
Posté par abramov_MS . Évalué à 7.
Perso j'ai teste beagle il y a quelques mois mais j'ai vite arrete lorsque le repertoire contenant l'index a commence a depasser le giga (ie 1/20 de mon home) et que ca ralentissait trop mon pc. Le premier probleme est "resolvable" en effacant regulierement le repertoire mais apres ca ralenti encore plus le pc vu qu'il faut refaire l'index et de plus cela n'est pas une solution viable surtout que cela ne restait pas dans des limites correctes plus d'une semaine.
Ces outils seront tres utiles probablement dans le futur mais ce n'est pas mur et clairement strigi et celui qui a le plus de potentiel.
[^] # Re: au moins un truc est clair
Posté par abramov_MS . Évalué à -5.
Enfin comme d'hab sur ce site je pense que certaines personnes ont un probleme de vocabulaire (moi j'ai celui de l'orthographe) et qu'ils devraient consulter un dico pour la definition du mot pertinent.
Le sujet de la news concerne les moteurs de recherche pour le bureau que sont beagle, strigi etc. La premiere ligne fait un commentaire sur l'article pdf qui a conduit a ce journal. Si j'ai mal analyse les resultats dites le et montrez quel page montre la superiorite des mono/java dans l'utilisation de la memoire.
Le reste de mon commentaire sur une utilisation par un utilisateur lambda de beagle (tiens un des logiciels de la news donc cela semble etre pertinent dans une certaine mesure) peut ne pas plaire. Cela n'enleve la realite de la chose, les index produit par beagle grossissent avec le temps et deviennent totalement aberrant niveau taille (meme avec les DD actuels). Maintenant cela etait un peut etre un probleme de la version teste (celle de ubuntu dapper puis celle de edgy), cela veut dire que ces outils ne sont pas encore mure (pas qu'ils sont mauvais).
Bon apres le fait que j'evite par dessus tout d'avoir un VM mono+ une VM java + un VM python etc en meme temps (la memoire de mon ordi ne tendant pas vers l'infini) est un autre probleme.
[^] # Re: au moins un truc est clair
Posté par TImaniac (site web personnel) . Évalué à 6.
Si Beagle est JIndex prennent plus de mémoire c'est pour 2 raisons (page 12) :
- Ils utilisent beaucoup moins de processeur que les autres : visiblement ils favorisent l'utilisation mémoire et donc probablement le cache plutôt que de faire faire beaucoup d'opération par le CPU.
- Intrinséquement Mono et Java gèrent eux même la mémoire, s'il y a de la mémoire dispo, ben le runtime l'utilise et ne la libère pas forcement dès qu'elle n'est plus utilisée : elle peut être recyclée (gain de temps à l'allocation) ou bien libéré en temps voulu (genre l'utilisation mémoire arrive à saturation).
Si c'est bien fait, un programme écrit en Mono Java peut se permettre d'utiliser un cache "automatique" basé sur le garbage collector (gestionnaire mémoire) : un objet est marqué comme "peut être recyclé" : la mémoire est utilisé (même si c'était pas nécessaire) comme un cache : gain de temps, moins de calcul CPU et/ou moins d'accès disque. Si un besoin mémoire se fait sentir à l'extérieur, le cache est "purgé", les objets sont donc nécessairement reconstruit lorsque le runtime tente d'y accéder, avec utilisation de CPU/Accès disque, mais moins de consommation mémoire (le cache est vidé).
Ce mécanisme n'est pas proposé "par défaut" en C/C++, c'est pourquoi les autres moteurs d'indexations font largement gaffe à l'utilisation mémoire, mais cela se traduit visiblement par une consommation CPU plus poussée, et sans doute une base de données plus grosses (qui contient probablement plus de tables d'index pour en fait reproduire la vitesse d'accès proposé par un cache mémoire).
Arrêtez moi si je dis des conneries :)
[^] # Re: au moins un truc est clair
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 6.
En fait, plutot que de ralentir artificiellement l'utilisation CPU (il cite beagle), au risque de se planter et de géner l'utilisateur dans ces taches courante, il l'utilise a fond le CPU, mais lui donne une priorité d'utilisation (au niveau noyau) plus faible que toutes les autres applications, Du coup, le CPU est utilisé au max, mais l'utilisateur ne se rend compte de rien, ce n'est que du CPU inutilisé qui est pris. Du coup, le user de base ne se rend compte de rien.
[^] # Re: au moins un truc est clair
Posté par yoplait . Évalué à 9.
Sauf quand les ventilos de sa machine se mettent en route sans qu'il comprenne pourquoi :/
[^] # Re: au moins un truc est clair
Posté par abramov_MS . Évalué à 1.
Enfin le coup de la memoire pour toi cela ne parait pas genant mais pour moi c'est redhibitoire, je suis amene a travaille sur de grosses images regulierement et si j'ai un truc en background qui me mange une grosse partie de ma memoire cela ralenti tout mon traitement et ca me fait pas rire du tout. Apres ce sont des choix conceptuel et c'est la ou le libre a un gros avantage 1) on peut degager ce genre d'outils facilement 2) on peut choisir celui qui nous convient le mieux suivant nos objectifs.
[^] # Re: au moins un truc est clair
Posté par TImaniac (site web personnel) . Évalué à 1.
Bah si à la place t'as un un truc en background qui à la place de bouffer de la mémoire bouffe du proc, je te garantie que ca ne va pas arranger ton temps de traitement :)
Plus sérieusement, y'a pas de mystère, indexer un grand nombre de contenu, ca consomme des ressources (mémoire de "travaille", mémoire sur disque, ressources de calcul), on a là plusieurs stratégies, elles ont toutes des avantages et des inconvénients, mais je ne suis pas sûr qu'il y en ai une de forcement meilleure : le tout est de savoir adapter cette consommation. Moi je t'ai montré que dans des environnements "conçus pour", la consommation mémoire qui bien que paraissant importante peut être paradoxalement beaucoup plus flexible en fonction des ressources de la machine. C'est pareil pour la consommation processeur : on peut bouffer beaucoup de proc, mais en étalant intelligement dans le temps cette consommation (comme il a été dit dans un commentaire juste au dessus) on peut également rendre cette consommation relativement transparente.
Bref, je pense qu'en l'état actuelle on a que des embrayons de solutions dont aucune n'est parfaite et vraiment mature, les algos et stratégies sont largement peaufinables.
Moi ce que je voulais juste faire remarquer, c'est que :
- les solutions basés sur des VM avec gestion automatique de la mémoire bouffe "naturellement" plus de mémoire, mais savent visiblement bien l'exploiter : ils n'ont pas besoin d'autant de proc que les autres solutions pour faire le même taf.
- les solutions "pure et dur" ala C/C++ qui ont une gestion moins flexible de la mémoire (en tout cas beaucoup plus manuelle et lourde si on voulait simuler le même type de comportement) font naturellement le choix d'une consommation mémoire largment moindre, mais qui est pénalisé par une plus grande consommation de CPU, ce qui là encore peut être facilement contourner par une gestion "intelligente" des ressources processeur en fonction du contexte d'utilisation de la machine.
[^] # Re: au moins un truc est clair
Posté par abramov_MS . Évalué à 3.
euh je sais pas si tu connais mais il existe une commande vachement pratique pour choisir quel programme utilise le CPU en priorite cela s'appelle nice... Je ne connais pas d'equivalent pour l'utilisation de la memoire (ca existe peut etre mais JE ne connais pas).
En ce qui concerne la suite, encore une fois les VM c'est bien beau mais 36 000 differentes en meme temps c'est n'importe quoi (a mon avis). Il y a 1 an l'utilisation de la memoire par beagle etait deja un gros probleme et visiblement cela n'a toujours pas evolue malgre les soit disant optimisations possibles.
[^] # Re: au moins un truc est clair
Posté par gasche . Évalué à 4.
Si tu regardes le tableau 5 du papier, tu verras que les solutions "basées sur des VM" ont besoin de plus de "proc" que strigi : si tu multiplies le temps d'indexage par le pourcentage d'utilisation CPU, tu obtiens un "temps CPU utilisé". Pas besoin de faire le calcul, c'est donné dans le tableau : 3 minutes 44 pour Strigi, 9 minutes 15 pour Jindex et 12 minutes pour Beagle.
Donc pour résumer, Beagle utilise plus de trois fois plus de CPU que Strigi, et donc ce que tu dis est inexact.
(évidemment, je pense que tu voulais parler du pourcentage de CPU utilisé, mais cette mesure n'a pas grand sens parce que tu peux demander au programme de faire de grandes pauses pour soulager le CPU, alors que la quantité "temps de CPU", elle, reste invariante)
[^] # Re: au moins un truc est clair
Posté par TImaniac (site web personnel) . Évalué à 3.
Oué enfin faudrait comparer ce qui est comparable : Tracker, Beagle et JIndex ont des résultats comparables en terme de requête, Strigi semble "oublier" pas mal de résultat... Alors que bon c'est quand même le but premier de chercher. Alors forcement si son algo d'indexation est rapide mais pourri...
Donc pour résumer, Beagle utilise plus de trois fois plus de CPU que Strigi, et donc ce que tu dis est inexact.
Si je compare par rapport à ce qui es comparable, c'est à dire avec Tracker qui retourne grosso modo des résultats très similaire (et donc une même qualité d'indexation), non ce que je dis n'est pas inexact.
# et kat ?
Posté par Erwann Robin (site web personnel) . Évalué à 3.
ca marche pas ?
et on pourrais imaginer d'intégrer kat et le hachoir ?
et on pourrais le renommer HappyHamster ?
[^] # Re: et kat ?
Posté par Erwann Robin (site web personnel) . Évalué à 1.
sur http://strigi.sourceforge.net/index.php/Main_Page
et pour ceux qui veulent le site officiel du logiciel qui semble sortir grand vainqueur de cette étude, c'est : http://www.vandenoever.info/software/strigi/
[^] # Re: et kat ?
Posté par soulflyb (Mastodon) . Évalué à 4.
et en plus ça ne marchait pas ;)
pourtant, cela semblait prometteur, mandriva avait parié dessus et l'avait mis sur le devant de la scène, mais apparemment kat n'a pas survécu à sa (courte) notoriété ;)
kat était hebergé par mandriva : http://kat.mandriva.com/ :
d'ailleurs qu'est il advenu de l'auteur (que la page dit de contacter sans donner d'adresse ni d'autres moyens) ? il a complètement abandonné le projet ? il bosse sur strigi ?
aucune idée
[^] # Re: et kat ?
Posté par Zorro (site web personnel) . Évalué à 2.
# Aucun intérêt
Posté par Gabriel Linder . Évalué à -1.
Le seul truc bordélique chez moi c'est ~/tmp, et il est rare qu'il dépasse 20 documents vu qu'après quelque temps j'efface ou je classe :)
[^] # Re: Aucun intérêt
Posté par TImaniac (site web personnel) . Évalué à 4.
Mais bien sûr, si je te demande de me retrouver la conversation où on a parlé de trucbidulechouette, tu vas me la retrouver toute seule comme un grand très rapidement, n'est-ce pas ?
[^] # Re: Aucun intérêt
Posté par zebra3 . Évalué à 0.
* Choix du contact
* Champ "Recherche" : trucbidulechouette
* Clic sur "Chercher"
Et voili !
J'imagine que pour Gaim, Psi ou d'autre, ça ne doit pas être si différent.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Aucun intérêt
Posté par Thomas Douillard . Évalué à 2.
Et si un outil te rapporte tout ça d'un seul coup parce que ce qui t'intéresse c'est une info relative à trucbidullechouette et pas de quel outil tu t'es servi pour les avoir ?
[^] # Re: Aucun intérêt
Posté par abramov_MS . Évalué à 2.
[^] # Re: Aucun intérêt
Posté par Thomas Douillard . Évalué à 2.
Sinon c'est de l'ingénierie des connaissances et là c'est plus tendu effectivement ^^
À défaut de créér sa base de donnée, un truc qui gère les ontologies, des technos genres RDF avec son système de requêtes et des meta données sur les fichiers on doit pouvoir faire ce genre de truc. Web sémantique toussa. Mais bon effectivement c'est pas complètement automatique et pas trivial de construire une ontologie.
Ça reste encore du domaine de la recherche. Quoi que niveau théorique on doit avoir les outils, c'est la mise en pratique qui est plus tendues, c'est difficile de le faire automatiquement et lourd à mettre en place pour l'utilisateur, genre remplir les meta données à la main, déja que les tags sont souvent mal fait pour la musique. Mais un peu plus général et souple qu'une BD pour toi tout seul.
[^] # Re: Aucun intérêt
Posté par abramov_MS . Évalué à 3.
[^] # Re: Aucun intérêt
Posté par Thomas Douillard . Évalué à 2.
http://www.xml.com/pub/a/2001/01/24/rdf.html
RDF permet en quelque sorte de généraliser le principe des tags ID3 avec des relations type "document à pour auteur1 auteur" etc. En bien plus souple puisqu'on peut rajouter ses propres realations et pas limité aux quelques trucs d'ID3 pour la musique et qu'on peut en rajouter arbitrairement.
Maisz bon ce genre de techno c'set pas pour maintenant tout de suite sur notre desktop, et pour les documents un peu aniciens, effectivement ça marche pas trop à moins de remplir à la main, si on a l'ontologie correspondante.
Reste qu'une recherche rien que textuelle dans ce genre de documents ça peut marche pas trop mal, cf google et les autres qui indexent quand même le wen en entier et qui permettent de trouver des trucs.
[^] # Re: Aucun intérêt
Posté par abramov_MS . Évalué à 2.
# Une étude plus générale sur la question
Posté par Denis Szalkowski . Évalué à 1.
http://dszalkowski.free.fr/dotclear/index.php?2006/08/27/988(...)
# Attention à la version de Beagle
Posté par Zorro (site web personnel) . Évalué à 2.
Je l'utilise quotidiennement (avec Gnome 2.16 sous Mandriva 2007), intensivement, j'ai des centaines d'images et de documents textes à indexer, et j'en suis plutôt content. Son index fait moins de 43 Mo, ce que je trouve tout à fait honnête, et je n'ai jamais été gêné par une utilisation mémoire particulièrement méchante.
Par contre, je n'ai pas activé l'indexation d'Evolution (j'ai quand même près de 400 contacts), ni celle de l'historique de Firefox, c'est peut-être pour ça que l'index est de taille encore raisonnable.
Je pense que pour quelqu'un qui utilise son PC essentiellement pour la bureautique, en générant de nombreux documents (texte, PDF, tableurs, images,...), un tel outil est absolument indispensable, et que locate, dans ce cas, est totalement insuffisant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.