Salut tout le monde,

Bon, c'est commité, mais assez brut (j'ai laissé l'ancien
code en commentaires), plus deux messages à rajouter dans
fichiers de loc. Pour l'instant, cela ne crée pas la barre
d'indice, j'affiche juste un pourcentage :
(indice_rech/indice_max_rech)*100.

note : pour ma culture, est-ce que quelqu'un à une méthode
simple pour limiter à 2 chiffres après la virgule ? C'est
con, mais j'y arrive pas ;-)

Au niveau de l'indice de confiance, je suis qu'à moitié
satisfait pour les regexp. Il faudrait trouver une autre
forme de pondération, peut-être tenir compte du nombre de
mots dégagés de la saisie, ou affiner les facteurs... Y'a à
réfléchir là... Je suis pas trop pour expliquer la bidouille
dans l'application même, ça ne concerne que nous et
l'utilisateur final, je pense qu'il n'en a rien à cirer ;-)

J'y retourne de ce pas, car j'ai l'impression que la
recherche switche pas sur une regexp en cas d'échec du
match/against !!! Merci de tester quand même le truc et de
faire des commentaires...

A+

PS. Au fait, Gautier, pour cette petite barre, tu n'aurais
pas un de ces trucs killer à base d'images et de CSS ? Ca me
gonfle d'utiliser un tableau...


Selon Eric ROBERT <[EMAIL PROTECTED]>:

> je suis OK sur ta méthode mais je pense qu'il va falloir
> indiquer quelle a
> été le type de recherche utilisée, histoire que le
> chercheur ne soit pas
> surpris le coup des indices de pertinence avec les regexp
> n'est pas
> forcément idéal, il va falloir indiquer que les mots ont
> plus de poids s'ils
> sont stockés dans le titre plutôt que dans le résumé, etc
> etc !
> 
> Commit ton truc et on va tester !
> 
> Eric
> 
> 
> ----- Original Message ----- 
> From: "François Lemarchand"
> <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, September 22, 2003 12:27 AM
> Subject: [PMB-DEVEL] Re: [PHPMYBIBLI-DEVEL]
> FULLTEXT/REGEXP, le retour
> 
> 
> > Bon, voila comment j'ai procédé, mais cela peut être
> adapté
> > suivant les commentaires que vous pourrez faire.
> >
> > Je prend un exemple pour simplifier (issu de la base
> de
> > bueil) et assez tordu en même temps pour me permettre
> de
> > pointer un des problèmes de la recherche par titre où
> il
> > n'y a pas d'autorités (et ça, on n'y pourra jamais
> rien...)
> >
> > Rappel du problème :
> > l'utilisateur fournit une chaîne.
> > la chaîne est divisée en mots.
> > si tous les mots ont plus de trois caractères, on
> utilisera
> > la méthode MATCH/AGAINST (fulltext).
> > si les ou un des mots comprennent 3 ou moins
> caractères, on
> > switche sur la recherche REGEXP.
> > Les mots vides sont éliminés de la requête utilisateur
> (le,
> > la, les, l', typiquement.
> > Si l'utilisateur a saisi des caractères utilisés dans
> les
> > masques d'expressions régulières (|$, ^ et autres),
> j'ai
> > considéré qu'il avait saisi une expression régulière et
> il
> > n'y a aucun traitement (je pars du principe que dans
> ce
> > cas, il sait ce qu'il fait).
> > Là dessus vient se greffer la nécessité de retourner
> un
> > indice de pertinence pour chaque résultat retourné (tri
> par
> > ordre décroissant de pertinence + on fera une petite
> image
> > pour visualiser l'indice de confiance du résultat).
> >
> > Je prend l'exemple 'vietnam' saisi en recherche titre
> > Le mot fait plus de 4 caractères, donc MATCH/AGAINST :
> la
> > requête générée par la fonction test_title_query() est
> :
> >
> > select *,MATCH (index_tit1,index_tit2,index_tit3,
> > index_tit4, index_serie) AGAINST ('vietnam') AS indice
> from
> > notices WHERE MATCH (index_tit1,index_tit2,index_tit3,
> > index_tit4, index_serie) AGAINST ('vietnam') ORDER BY
> MATCH
> > (index_tit1,index_tit2,index_tit3, index_tit4,
> index_serie)
> > AGAINST ('vietnam') DESC
> >
> > 1 résultat avec son indice de pertinence :
> >
> > Ho Chi Minh 7.2678657682646
> >
> > Ca colle : le sous-titre est 'de l'Indochine au
> Vietnam'
> > donc c'est normal que ça sorte.
> > Cependant, je trouve ça bizarre parce que j'ai un peu
> > parcouru la base de Bueil. J'ai l'impression que je
> devrais
> > avoir plus de résultats.
> >
> > Comme je suis un bibliothécaire avec de l'expérience
> ;-),
> > je me dis : 'à 100 contre un, la BDT a saisi vietnam
> avec
> > un tiret !!!' (les deux orthographes sont admises et
> la
> > rêgle de catalogage dit qu'on doit saisir le titre
> > exactement comme il figure sur la page de titre du
> livre).
> > De toutes les façons, pour cet exemple, je suis sûr que
> les
> > trois quarts des gens seraient passés par la recherche
> > catégorie où c'est une autorité, donc le problème se
> lève.
> > On aurait pu faire aussi en titre 'vietnam|viet-nam'
> pour
> > aboutir, mais il faut connaître un peu les regexp...
> >
> > Je saisis donc 'viet-nam'.
> >
> > première chose que fait la fonction test_title_query()
> :
> > virer le tiret pour diviser tout ça en mots (de toute
> > façon, il est exclu de index_tit1 quand on fait le
> 'pseudo-
> > index' qui sert à la recherche).
> >
> > Ca devient 'viet nam' (mot avec moins de 4 caractères :
> on
> > switche en regexp).
> >
> > La requête générée est :
> >
> > select *,5*(index_serie REGEXP 'viet') + 4*(index_tit1
> > REGEXP 'viet') + 3*(index_tit4 REGEXP 'viet') + 2*
> > (index_tit3 REGEXP 'viet') + 1*(index_tit2 REGEXP
> 'viet') +
> > 5*(index_serie REGEXP 'nam') + 4*(index_tit1 REGEXP
> 'nam')
> > + 3*(index_tit4 REGEXP 'nam') + 2*(index_tit3 REGEXP
> 'nam')
> > + 1*(index_tit2 REGEXP 'nam') AS indice from notices
> WHERE
> > (index_serie REGEXP 'viet' OR index_tit1 REGEXP 'viet'
> OR
> > index_tit2 REGEXP 'viet' OR index_tit3 REGEXP 'viet'
> OR
> > index_tit4 REGEXP 'viet') AND (index_serie REGEXP 'nam'
> OR
> > index_tit1 REGEXP 'nam' OR index_tit2 REGEXP 'nam' OR
> > index_tit3 REGEXP 'nam' OR index_tit4 REGEXP 'nam')
> ORDER
> > BY 5*(index_serie REGEXP 'viet') + 4*(index_tit1
> > REGEXP 'viet') + 3*(index_tit4 REGEXP 'viet') + 2*
> > (index_tit3 REGEXP 'viet') + 1*(index_tit2 REGEXP
> 'viet') +
> > 5*(index_serie REGEXP 'nam') + 4*(index_tit1 REGEXP
> 'nam')
> > + 3*(index_tit4 REGEXP 'nam') + 2*(index_tit3 REGEXP
> 'nam')
> > + 1*(index_tit2 REGEXP 'nam') DESC, index_serie DESC,
> > index_tit1 ASC
> >
> > Joli non ? Le AND du milieu de la requête est généré
> > suivant un paramètre qu'on passe à la fonction. Suivant
> la
> > valeur, ce sera AND ou OR (bouton radio dans le form
> de
> > recherche : tous les mots/au moins un des mots).
> >
> > Ca me retourne deux résultats (avec indice de
> > pertinence) :
> >
> > Viêt-Nam 8
> > Ho Chi Minh 6
> >
> > C'est mieux déjà. J'ai fixé l'indice de la façon
> suivante :
> > si la séquence figure dans le titre de série,
> j'attribue un
> > facteur de 5. Si elle est dans le titre propre un
> facteur
> > de 4. sous-titre, etc...
> >
> > Le tout est trié sur indice de pertinence décroissant,
> > titre de série décroissant (pour avoir les séries au
> début)
> > et titre propre ascendant (pour trier quand même si
> > l'indice est identique).
> >
> > résultat des courses : pour moi, ça marche (j'en suis
> même
> > assez content car cela élimine un certain bordel en
> > recherche fulltext). Le bémol est dû à la nature même
> de la
> > recherche par titre : il faut réfléchir
> > des fois. Le problème du tiret est insoluble d'ailleurs
> :
> > comment faire comprendre au logiciel que ça peut être
> une
> > limite de mot et parfois pas une limite de mot ?-)
> >
> > Jetez y un coup d'oeil (c'est
> > dans ./includes/misc.inc.php). Si c'est OK pour vous,
> > j'implémente ça dans le biniou en vrai et on aura la
> > recherche avec
> > les opérateurs booléens !!!
> >
> > J'ai encore un petit truc à résoudre : il faudrait
> pour
> > faire la minibarre retourner aussi l'indice maximum
> pour la
> > recherche en cours. C'est pas difficile, je m'en vais
> > vérifier que la fonction MAX existe en MySQL...
> >
> > A+
> >
> >
> >
> > Selon François Lemarchand
> <[EMAIL PROTECTED]>:
> >
> > > Je vois qu'il y a du monde même le dimanche ;-)
> > >
> > > Je suis sur la refonte de la recherche titre. Pour
> > > l'instant, je bosse sur une fonction
> 'test_title_query()'
> > >
> > > dans misc.inc.php. Normalement, ça vient remplacer
> > > analyze_title_query().
> > >
> > > Ca commence comme ça (le reste est commité, mais pas
> > > utilisé encore) :
> > >
> > > function test_title_query($query, $operator=TRUE,
> > > $force_regexp=FALSE)
> > > {
> > >     // fonction d'analyse d'une recherche sur titre
> > >     // la fonction retourne un tableau :
> > >
> > >     $query_result = array(  'type' => 0,
> > >                             'restr' => '',
> > >                             'order' => '');
> > >     // $query_result['type'] = type de la requête :
> > >     // 0 : rien (problème) 1: match/against 2:
> regexp
> > >     // $query_result['restr'] = critères de
> restriction
> > >     // $query_result['order'] = critères de tri
> > >
> > >     // si operator TRUE La recherche est booléenne
> AND
> > >     // si operator FALSE La recherche est booléenne
> OR
> > >     // si force_regexp: la rech. est forcée en mode
> > > regexp
> > > ...
> > >
> > > Si je cherche 'mouvement libération femme' avec
> recherche
> > >
> > > regexp forcée, j'obtiens ce restricteur :
> > >
> > > WHERE (index_tit1 REGEXP 'mouvement' OR index_tit2
> > > REGEXP 'mouvement' OR index_tit3 REGEXP 'mouvement'
> OR
> > > index_tit4 REGEXP 'mouvement' OR index_serie
> > > REGEXP 'mouvement') AND (index_tit1 REGEXP
> 'liberation'
> > > OR
> > > index_tit2 REGEXP 'liberation' OR index_tit3
> > > REGEXP 'liberation' OR index_tit4 REGEXP 'liberation'
> OR
> > >
> > > index_serie REGEXP 'liberation') AND (index_tit1
> > > REGEXP 'femme OR index_tit2 REGEXP 'femme' OR
> index_tit3
> > >
> > > REGEXP 'femme' OR index_tit4 REGEXP 'femme' OR
> > > index_serie
> > > REGEXP 'femme')
> > >
> > > Ca me paraît OK sur la forme, mais question
> utilisation
> > > de
> > > ressources ça te dit quoi ? (pas un peu lourd ?).
> > >
> > > J'ai une autre soluce sous le coude :
> > >
> > > WHERE index_tit1 REGEXP 'mouvement|liberation|femme'
> OR
> > > index_tit2
> > > REGEXP 'mouvement|liberation|femme' OR index_tit3
> > > REGEXP 'mouvement|liberation|femme' OR
> > > index_tit4 REGEXP 'mouvement|liberation|femme' OR
> > > index_serie
> > > REGEXP 'mouvement|liberation|femme'
> > >
> > > qui me semble moins gourmande, mais je tiens à
> appliquer
> > > le
> > > booléen fourni en param même si ça switche sur
> REGEXP.
> > >
> > > Si je ne force pas la REGEXP, j'obtiens cela
> (beaucoup
> > > plus
> > > civilisé...) :
> > >
> > > WHERE MATCH (index_tit1,index_tit2,index_tit3,
> > > index_tit4,
> > > index_serie) AGAINST ('mouvement') AND MATCH
> > > (index_tit1,index_tit2,index_tit3,index_tit4,
> > > index_serie)
> > > AGAINST ('liberation') AND MATCH
> > > (index_tit1,index_tit2,index_tit3,index_tit4,
> > > index_serie)
> > > AGAINST ('femme')
> > >
> > > Une fois que j'ai fini le restricteur, reste le
> problème
> > > de
> > > la création d'un indice de confiance pour les
> REGEXP.
> > >
> > > apparemment, champ REGEXP 'montruc' me retourne 0 ou
> 1,
> > > donc si je construit mon indice comme ça :
> > >
> > > SELECT stuff, champ1 REGEXP 'truc' + champ2 REGEXP
> 'truc'
> > >
> > > + ... AS indice
> > >
> > > j'obtiens une approximation d'un simili indice ?
> > >
> > > (je m'occuperais de la mise à l'echelle pour la
> > > mini-barre
> > > sur le moment de sa génération...)
> > >
> > > A+
> > >
> > > -- 
> > > François Lemarchand
> > > homepage : http://balno.free.fr/
> > > PhpMyBibli : http://phpmybibli.sourceforge.net
> > >
> > > Liste de diffusion phpmybibli.devel
> > > Pour se désinscrire :
> > > mailto:[EMAIL PROTECTED]
> > subject=unsubscribe
> > >
> > >
> >
> >
> > -- 
> > François Lemarchand
> > homepage : http://balno.free.fr/
> > PhpMyBibli : http://phpmybibli.sourceforge.net
> >
> > Liste de diffusion phpmybibli.devel
> > Pour se désinscrire :
> mailto:[EMAIL PROTECTED]
> >
> >
> 
> 
> Liste de diffusion phpmybibli.devel
> Pour se désinscrire :
> mailto:[EMAIL PROTECTED]
> 
> 


-- 
François Lemarchand
homepage : http://balno.free.fr/
PhpMyBibli : http://phpmybibli.sourceforge.net

Liste de diffusion phpmybibli.devel
Pour se désinscrire : mailto:[EMAIL PROTECTED]

Répondre à