Lutter contre le silence des catalogues des bibliothèques grâce aux suggestions de google
Croisé lors de la récente journée d’étude organisée par le CNFPT, j’ai remarqué une innovation très intéressante de la bibliothèque de Saint-Herblain. Sur le très chouette site proposé par Quentin Chevillon, notre bibliothécaire-développeur national, auteur de Moccam-en-ligne et de Moccam. Quentin a eu la très bonne idée d’utiliser l’API de google pour le correcteur de requêtes dans le catalogue.
La saisie d’une requête est automatiquement proposée à google et le catalogue affiche le cas échéant la suggestion, qui peut alors être transformée en requête dans le catalogue. Comme il s’agit d’une connexion entre serveurs, l’opération est transparente pour l’utilisateur.
L’intérêt ? Bénéficier de l’efficacité des suggestions du moteur de recherche le plus utilisé dans le monde pour tous les types de requêtes, y compris les nom propres. 🙂
Exemple pour une requête avec « harry potaire » :
Le résultat est instantanément corrigé… la suggestion provient de google. Essayez avec la même requête dans votre catalogue et comparez !
Brillante idée non ? 🙂
Excellent, oui! L'avantage d'avoir en interne un programmeur ainsi qu'un opac non propriétaire dont on peut modifier le code tant qu'on le souhaite. J'imagine d'ici le devis que nous enverrait notre prestataire d'opac fermé si on lui demandait d'intégrer cette fonction…
Et jamais tu nous dis comment on fait ?? Ce renseignement-là, tu le vends ?? 😉
Effectivement ca serait cool de savoir quelle API est utilisée aussi…
Laurent tu parles d'opac non propriétaire : quel est celui utilisé par Saint Herblain ? Koha ?
Merci Mr Bibliobsessed, encore une demande à rajouter dans notre cahier des charges…
@dbourrion : ok j'ai été un peu léger sur l'info sur ce coup là… le mail est envoyé à Quentin, en attente de sa réponse 🙂
@Nicolu : you're welcome, Saint Herblain utilises Aloès et Quentin a entièrement conçu le site de la bibliothèque. D'ailleurs, il s'est dit tout disposé dans cette journée à libérer certaines briques pour qu'elles soient utilisables. (bon le site est en flash aussi)
Bonjour,
effectivement le logiciel de la bibliothèque est Aloès. Ce logiciel propose un jeu de WebServices pour son OPAC que nous avons utilisés (détournés 😉 pour bâtir notre propre couche présentation (qui se trouve être en Flash).
Cela nous permet effectivement d'adapter à notre guise les fonctionnalités et d'en ajouter de nouvelles soit à partir de sources externes (Amazon, Google), soit à partir d'une base de données 'maison' en MySQL (pour les commentaires sur les notices et la rubrique 'les lecteurs ayant lu xxx ont également lu yyy').
En ce qui concerne la nouvelle fonctionnalité de correcteur orthographique, effectivement on a utilisé la fonctionnalité "Essayez avec cette orthographe" de Google. En fait lorsque quelqu'un fait une requête sur l'OPAC et qu'Aloès retourne 0 résultats, on lance la requête à Google (sur le serveur) et on analyse la page HTML retournée. Si on localise la chaîne de caractères "Essayez avec cette orthographe", on récupère la suggestion de Google et relance la requête dans Aloès pour voir si on trouve des résultats (et combien). Si c'est le cas, on affiche la suggestion de Google avec le nombre de résultats (en cliquant dessus, ça lance la recherche en question).
Si quelqu'un est intéressé par le code utilisé, n'hésitez pas à m'envoyer un mail et je vous le ferai parvenir (code en PHP).
très intéressé par le code
Salut
Ce qui est super amusant, c'est que cette fonctionnalité s'appelle Soundex en programmation. Le procédé date juste de 1918. 90 ans, hein, pas grave. 🙂
Pour ceux que le processus intéresse, petite explication sur le fonctionnement ici.
http://www-lium.univ-lemans.fr/~carlier/recherche…
C'est d'ailleurs une fonction implémentée en Turbo Pascal depuis les années 1980, mais trop souvent absente des logiciels de bibliothèque, quand elle est seulement présente.
Mais bon, vu qu'une simple requête multi-champs (avec une seule zone de saisie) semble hors de portée de ces logiciels, Soundex faut pas trop y compter.
Donc, utiliser Google, oui.
Autant profiter du meilleur en modèle de Soundex/Phonex actuel. 😉
C'est sans doute un peu lourd et dépendant. Mais on peut imaginer qu'il est très facile, par le même système d'API, de pointer des ressources sur le Web… ou des ressources internes, par un moteur recherchant sur le site/blog de la bibliothèque. (commentaires, bibliographies, ressources différentes)
Bien cordialement
Bernard Majour
PS. En Sql, l'instruction s'appelle Soundex… on regardera aussi Difference. Encore faut-il lire l'énorme liste des fonctions proposées dans la doc :-)))
@B. Majour
Effectivement la fonctionnalité Google doit utiliser un algorithme de type soundex mais je pense plus performant. En fait, ça ne m'étonnerait pas que Google mette en oeuvre des fonctions plus poussées (par exemple, une personne fait une première recherche, obtient peu de résultats, puis fait une autre recherche proche et obtient beaucoup de résultats : on en déduit que la première recherche était une approxiamtion de la 2e…)
Par ailleurs, dans notre cas, soundex ne nous aurait servi à rien. En effet, il est très facile d'obtenir le soundex (c'est à dire en gros la transcription phonétique) d'un terme recherché, mais à partir de là, que faire de ce soundex ? Je ne peux pas faire directement une recherche dans Aloès avec un soundex (le logiciel n'en est pas capable).
L'avantage de Google, c'est qu'il ne retourne pas un soundex, mais une vraie suggestion (la plus probable) en langue française que l'on peut retourner à Aloès.
Donc effectivement, ce serait bien que les SIGB intègrent nativement des fonctionnalités de type soundex, mais quand ce n'est pas le cas et que comme nous, on bâtit une interface par dessus le SIGB, soundex ne sert à rien, mais Google si (et je pense vraiment qu'il est plus puissant).
@Quentin
Tout à fait, les logiciels n'en sont pas "capables". On se demande bien pourquoi, alors qu'il s'agit de rechercher de l'information, justement, dans l'OPAC… avec des enfants qui vont taper des mots. Ou même simplement des personnes handicapées.
Etrange analyse Merise me semble-t-il. 🙂
Aussi est-ce aux bibliothécaires d'attaquer le problème. Et comme tu le dis "on bâtit une interface par dessus le SIGB". Embêtant ce par-dessus, lorsqu'on paie de la maintenance évolutive.
Pour Google, je pense – vu leur capacité de traitement – que le Soundex++ est lié à une base de données des frappes "fautives" : Vous avez tapé ceci, vous devriez essayer cela.
Si on y pense, voilà une base de données très utile pour l'océrisation des données.
Comme peuvent l'être certains captcha anti-robot-spammeur avec double mots scannés.
Ceci dit, ce que tu as fait est intéressant. :-)))
Et bientôt indispensable comme Moccam.
Bien cordialement
Bernard Majour
Hmmmmm si la fonctionalité est intéressante je ne suis pas sûr que le scraping des pages de résultat de Google soit en conformité avec leurs termes d'utilisation.
J'ai cherché chevo dans le catalogue de St Herblain, raté ! Il parait que la phonétique d'Opsys aurait fait bien mieux…
Le soundex dépend de la langue de compilation des serveurs de données. MySQL fait cela très bien… en anglais… Ensuite, attention aux exigences bibliothéconomiques… On l'avait fait de notre coté, on l'a vite abandonné parce que la souplesse de tri/affinage/muti-critères/multi-tables-index n'était pas permise par les recherches soundex. On ne peut pas vouloir faire de l'UNIMARC dans le moteur et vouloir chercher avec une méthode encore plus dégradante que "tous les champs" sans générer un vacarme insupportable (comprendre beaucoup de bruit, du vrai).
Il ne faut pas juger d'un service avec un seul exemple… Aucun système ne peut être fiable à 100%. Une des failles de Google, c'est paradoxalement son immense corpus. Pour lui, "chevo" n'est pas une mauvaise orthographe car elle se trouve dans près de 100.000 pages. Cependant, quand on teste avec un nombre important de termes variés (noms propres, communs, connus ou plus rares, avec différentes formes de mauvaise orthographe), on trouve une bonne réponse dans 40 à 50% des cas. Ce n'est pas le Pérou, mais ce n'est pas négligeable non plus.
Le gros avantage de Google, c'est qu'il ne se comporte pas comme un soundex qui retourne effectivement énormément de bruit (chevo = chevaux = cheveu = chauve = chavez …), mais il propose une orthographe alternative (la plus pertinente). Donc pour résumer, on n'obtient pas toujours une alternative, mais quand on en obtient, elle est très souvent pertinente.
juste, avec un peu de retard, pour dire que soundex retourne une chaine de 5 caractères, avec une lettre en 1er, suivie de 4 chiffres.
C'est donc une forte injection (bcp bcp moins de possibilités que les vrais mots
La 1ere lettre est la 1ere lettre du mot à étudier, les 4 chiffres sont calculés.
Ca marche super mal en français. Il y a ici : http://sqlpro.developpez.com/cours/soundex/ un article intéressant sur la question, et sur soundex2, qui est mieux adapté au français.
Une option qui est aussi possible, si vous utilisez du Linux et un langage efficace (comme Perl pour ce qui nous concerne), c'est de faire du Ispell/ Aspell à la volée pour corriger l'orthographe. en Php, ca semble être pspell : http://phpbuilder.com/manual/en/ref.pspell.php
Ca me paraîtrait effectivement plus compatible avec les règles de google, et surement plus rapide (pas de traffic réseau)
@Paul Poulain : c'est marrant l'effet que ça fait de ne rien comprendre à ce débat qui a lieu sur mon blog ! Bref, ce qui est important c'est de comprendre que Koha va utiliser cette fonctionnalité ? Avez-vous eu plus d'infos sur les conditions d'utilisation de cette API ?