Sacré Graal: mon SID – notes

April 28, 2006 at 10:08 am Leave a comment

Attention: l o n g post.

Je voudrais poursuivre la réflexion entamée dans un post précédent sur l'hypothèse d'un transfert des données biblios du SIGB vers une base externe, suite à une discussion à l'université avec un informaticien avec lequel on travaille souvent: ce ne sont pas des notes de réunion, mais il y a pas mal d'éléments dont on a discuté un peu informellemenet et que je veux garder en mémoire. C'est un peu en vrac, mais ça me permet de poser quelques notes: je me fixe d'avoir un document plus construit autour de toute cette problématique en septembre au plus tard.

Il y a toute la problématique de l'export proprement dit.
Quelles infos exporter? A priori tout ce qui est bibliographique, y compris les informations d'exemplaire, qui dans Aleph peuvent être "remontées" de l'exemplaire dans un champ spécifique de la notice bibliographique elle-même.
Comment réaliser l'export initial? Utiliser le web service de recherche ne semble pas une solution réaliste: avec env. 400.000 documents ça ne passerait pas, ou bien il faudrait découper en plein de requêtes différentes, pour être sûr que ça passe, mais sans pouvoir être sûr qu'on ne ramasse pas deux fois le même document dans deux requêtes de web service différentes. Sauf à ensuite gérer du dédoublonnage, etc. La galère. On peut faire un export iso 2709. On peut attaquer directement la base Oracle en SQL.
La question de l'export quotidien des modifs en fonctionnement courant. Quand on modifie une notice sur Aleph, il a un champ spécifique qui indique la date de modif. Pour l'exemplaire? Un nouveau prêt ou retour sera enregistré avec la date? Une modif? Changement de cote? A voir.
Ce qui me semble important ici, c'est qu'on cherche un compromis: on quitte la base native du SIGB pour gagner en souplesse, en fonctionnalités dans une base et une application indépendantes. Que perd-on: la synchronisation parfaite entre l'interface publique et l'outil de gestion. Est-il important de voir immédiatement dans la recherche publique un nouveau livre catalogué? Non. Un délai de 24h est-il raisonnable? Oui. Par contre: est-il raisonnable d'attendre 24h pour voir que le livre disponible est désormais en prêt? Non, parce que dans ce cas l'info qu'on donne est purement et simplement fausse. Donc: ne pas synchroniser le recherche biblio proprement dite, mais synchroniser le transactionnel: disponibilité des documents, infos de compte lecteur, actions comme "réserver" ou "prolonger".
Donc dans la nouvelle interface il y aura forcément un mélange d'interrogation directe (sur les données biblios rechargées dans la base) et de web services (comme: petit bouton "disponibilité" qui exécute un web service).

Il y a toute la problématique des choix techniques pour le nouveau système: est-ce que MySQL, par exemple, est un bon choix pour un volume d'environ 400.000 documents? Est-ce que PHP est un bon choix? L'environnement matériel?

Quelles fonctionnalités mettre en oeuvre dans le nouvel outil? C'est la partie fun, je ne réponds pas ici. Mais je pense que c'est à définir soigneusement, avec trois idées en point de mire:
* il faut réfléchir à améliorer la façon dont les fonctionnalités actuelles sont proposées et mises en oeuvre. Je pense par ex. à la notion de "panier", qui est actuellement incroyablement complexe: listes, sous-listes, dossier dans le panier, renommer, panier de session, panier permanent, etc. Complexe au point d'être inutilisable. Bref: rationaliser l'existant et le proposer dans un cadre un peu réfléchi du point de vue de l'ergonomie.
* il faut veiller à la cohérence d'ensemble des nouvelles fonctionnalités: pas une liste de gadget, un environnement de travail documentaire. Qui mette en rapport des informations sur les documents avec des informations sur les lecteurs. Des informations récoltées sur les lecteurs (vous avez déjà vu cette notice il y a 3 jours; le ldap me dit que vous êtes étudiant en psycho, etc) et des informations fournies par les lecteurs (tag "pour cours de math" attaché à un bouquin, par ex.). Cf Lorcan Dempsey: notions d'aggregation of supply & demand dans Libraries and the Long Tail.
* il faut travailler sur la notion de recherche. Rapidité: il faut que l'opac réponde en moins d'une seconde. Toujours. La pertinence de la requête. Par ex. dans MySQL vous avez des fonctionnalités de recherche à ce niveau. Il est possible, si vous cherchez "base de données", que le système repère que dans xx% des résultats, il y a le mot MySQL, et donc il cherche aussi les enregistrements où il y a MySQL, même s'ils ne contiennent pas votre terme de recherche "base de données". On peut travailler aussi sur le nombre de prêts: deux bouquins sur les bases de données: le premier de 2005, par un auteur dont le nom commence par A et qui est sorti 2 fois; le second de 2003, par un auteur dont le nom commence par B, mais qui est sorti 15 fois. Un opac aura tendance à classer le 2005/A avant le 2003/B. On pourrait en décider autrement, en pondérant sur le nombre de prêts. Je pense que ça vaut le coût de se pencher précisément sur les questions de ranking. Et trouver un bon équilibre entre rapidité et pertinence.

Il est enfin nécessaire de justifier ce choix hétérodoxe.
Pourquoi ne pas utiliser les web services qui existent pour la recherche?
* un web service ça peut prendre du temps à s'exécuter
* vous n'avez que les web services offerts par le fournisseur: dans notre cas c'est déjà pas mal, mais ça a ses limites malgré tout
* aussi, accessoirement: vous avez beau faire une autre interface, les fonctionnalités restent pour l'essentiel celles de votre SIGB: vous ne pouvez pas facilement "inventer" de nouvelles fonctionnalités sauf à avoir un équilibre inconfortable entre ce qui vient du SIGB et diverses "verrues" fonctionnelles qui sont propres à votre outil.

Un choix de transfert pur et simple, tel que je l'évoque ici, serait-il plus risqué qu'un choix "normal" de web services ou de "HTML scraping"?
Je ne crois pas. Moins que le HTML scraping, en tout cas, car alors la pérennité n'est pas du tout assurée. Plus que les web services? Je ne crois pas: on n'a dans la nouvelle appli que les données biblios brutes. Si demain vous changer non seulement de version, mais même de SIGB, vous aurez toujours ces données brutes. Il restera à reconstruire la moulinette d'export quotidien des données du SIGB.

Advertisements

Entry filed under: MBSSI, Uncategorized.

MySQL Full-text search stats opac

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Feeds


%d bloggers like this: