Archive for April, 2006

Sacré Graal: mon SID – notes

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

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

MySQL Full-text search

Dans le cadre de la réflexion sur l'intégration, je pense qu'on pourrait séparer l'intégration des fonctions personnelles (par ex.: y a-t-il des docs en retard sur le compte lecteur) de la recherche.

Et pour la recherche une piste pourrait être d'avoir en parrallèle 2 systèmes: le SIGB pour la gestion interne (prêt, catalogage, commande, etc.) et un second outil pour la recherche publique; les données sont transférées d'un système à l'autre par batch et on utilise les web services pour faire le lien entre le SIGB et le 2d système pour, par ex, la disponibilité du document, le compte lecteur, etc.

Mais on sépare la recherche. Si les données biblios sont transférées dans un autre outil, on peut utiliser les fonctionnalités présentent dans cet autre outil. Par exemple si on les recharge dans MySQL on peut utiliser les fonctionnalités de recherche propres à MySQL, comme le tilde ~ qui permet de faire un classement par pertinence: '+apple ~macintosh' permet de classer comme moins pertinent un résultat qui aurait apple et macintosh. MySQL gère aussi des mots vides. Et surtout il utilise les modes de recherche que les usagers du web connaissent: +la recherche, "Coke en stock", dada*, etc.

Cf MySQL Manual Boolean Full-text search, et maison bisson

April 26, 2006 at 11:42 am 1 comment

links for 2006-04-21

April 22, 2006 at 12:23 am Leave a comment

atomes et gloubiboulga (suite)

Dans un post récent concernant l'opac je signalais que je ne pouvais pas mettre en forme des éléments intellectuellement différents si le système envoyait tout ça compacté dans une variable dynamique.

En fait c'est possible, mais en bricolant. 

Si je prend l'exemple de la description biblio: elle envoit tout le pavé dans une variable, mais je vais tester le titre de chaque ligne et proposer un affichage différent (gras dans un cas et italique dans l'autre par exemple) en fonction de ce que je trouve dans le champ.

Avec un javascript:

<script language=javascript>
    var field = '$mavriabledetest';
<!-- et là j'ai mes différents cas avec une classe css différente pour chacun-->
   switch(field) {
         case "titre_1_ds_ma_ligne" : document.write("<td class=maclasse1 $AL02><b>"); break;
         case "
titre_1_ds_ma_ligne" : document.write("<td class=maclasse2 $AL02>"); break;
         default : document.write("<td class=td1 $AL02>"); break;
      }
</script>

Bref, rien n'est impossible, mais c'est de la bricole qui n'enlève rien à ce que je disais dans le message précédent: on ne devrait pas avoir de variables gloubiboulga: c'est peu propre, ça prend du temps pour tourner autour du problème, etc. Bref, un mauvais point de TCO

April 21, 2006 at 11:33 am Leave a comment

portails documentaires

J'ai participé hier à une journée à l'enssib sur e-bibliothécaire et e-bibliothèque. Il y avait plusieurs choses très intéressantes, sur OAI, l'archivage de la documentation numérique, et du web en particulier, sur les blogs. Pour tous ces sujets, cf le blog de la journée, tenue par les conservateurs stagiaires de l'enssib, organisateurs. http://ebib.over-blog.com/

Je veux juste détailler ici l'intervention de Guillaume HATT, qui a parlé des portails documentaires, à partir du cas de Valenciennes. Comme c'est un sujet qui préoccupe directement ma BU, je retranscris mes notes ici.

Valenciennes faisait parti du noyau des établissements développeurs de l'ENT Esup-Portail. Guillaume souligne d'emblée un élément politique important: si l'université a une forte volonté politique de faire un ENT, un des premier problèmes qui se posent est de trouver des contenus pour que l'ENT soit autre chose qu'une coquille vide. L'Université pense naturellement aux emplois du temps, et se tourne vers les services des scolarités, mais pense aussi très vite à la BU, qui a plusieurs atouts à faire valoir: la BU a des contenus (opac, doc élec, etc) et a une certaine habitude des normes.

Le problème, vu du côté de la BU, est l'hétérogénéité des ressources: l'opac, les cdroms, la doc élec, le site web institutionnel (la comm' de la bibliothèque), les docs numériques internes, des catalogues collectifs, etc. L'objectif fondamental est dès lors de proposer un seul écran donnant accès à ttes les ressources.

Secondairement, le travail doit être doublé: proposer une intégration au niveau du système de la bibliothèque, et une intégration au sein de l'ENT proprement dite. Sachant que dans le cas de Valenciennes, il est clairement affirmé que le système de la bibliothèque a vocation a disparaître purement et simplement au profit de l'ENT. C'est un point sur lequel je suis réservé: je pense qu'il faut faire la première étape, avec un SID et un ENT en parrallèle, et voire ce que ça donne; je ne suis pour l'instant pas prêt à dire que le SID a vocation à disparaître, dans la mesure en particulier où nous ne savons pas encore ce que l'ENT permettra à la BU de faire ou de ne pas faire.

La réalisation du projet de Valenciennes a été rendue possible grâce à un certain nombre de développements techniques :

  • des standards bien implantés: XML
  • des formats ouverts
  • la prise en compte de l'open source dans les marchés publics: non pas nécessairement pour avoir accès au code source du SIGB, par exemple, mais au moins pour avoir accès à des éléments « bas » du logiciel pour permettre l'interopérabilité
  • une interopérabilité, justement, accrue: de nouveaux protocoles (OAI) ont émergés qui n'étaient pas encore vraiment présents dans le paysage au moment de la conception du projet à Valenciennes, en 2002.

Ce dernier indique clairement, à mon avis, qu'il faut aller vite pour faire une intégration: les techniques évoluent très vite et si vous menez votre projet sur 2 ou 3 ans, il y a de fortes chances pour que ce que vous mettez en oeuvre doive être rapidement revu. Ce qui me renforce dans l'idée qu'il ne faut pas faire un marché global SIGB + Portail, dans la mesure où la mise en oeuvre du SIGB va légitimement primer (il faut que le prêt tourne) et que vous ne vous tournerez vers le portail qu'avec un temps de retard.

Guillaume note aussi un certain nombre de changements induits par la réalisation du portail documentaire.

D'abord, on est engagé en tant que fournisseur d'un accès à la doc, et non plus seulement en tant que gestionnaire d'une collection: la BU s'engage, d'une certaine façon, à fournir un accès. Donc si l'accès, réseau par exemple, est coupé, la bibliothèque en tant que service est engagé. Par conséquent le travail de garantie de l'accès devient une partie des missions de l'établissement, ce qui n'était pas nécessairement le cas auparavant.

C'est un élément d'un mouvement plus important qui, avec le SID, fait passer la BU d'une logique de doc à une logique de service:

  • guiche unique avec accès garanti
  • formation pour les étudiants et des personnels
  • accroître la qualité et la quantité des accès: accroître le nombre de postes publics, wifi, micro-portable étudiants, accès distant, prêt de portables aux étudiants (je voudrais bien mettre en place ce dernier élément, d'ailleurs).

On passe aussi d'une gestion de collection à la gestion de flux. A l'origina il y a toujours un choix documentaire, mais il faut alimenter. Tout se passe bien quand c'est entièrement automatisé, par exemple pour les nouvelles acquisitions qui passent du SIGB à l'ENT. Le problème principal est pour tout ce qui n'est pas automatisé: dès que le bibliothécaire intervient, et qu'il doit mettre à jour une info, c'est difficile: les pratiques professionnelles ne suivent pas forcément.

En réponse à des questions, Guillaument a développé un peu des aspects statistiques et de bilan de l'utilisation du portail.

La case de recherche unique pour l'opac, type Google: elle devient le point d'entrée principal pour l'opac (à env. 90%?), et l'opac natif ou les fonctionnalités de recherche complexe ne sont plus utilisé. Il note d'ailleurs que pour une bibliothèque d'env. 100.000 docs ça permet de trouver ce qu'on cherche.

Autre point: l'accès loggé est très très faible pour tous les postes qui se trouvent à l'intérieur même de la bibliothèque; 95% de la navigation est anonyme. Le taux de connexion identifiée augment un peu depuis des postes extérieurs, mais ne dépasse pas 20%.

La recherche fédérée… qui est un point central de tous les projets de ce type, n'est pas utilisée. C'est un flop complet. Guillaume pense tout simplement que dans une université d'environ 10.000 étudiants très orientée sur les premiers cycles, cela ne correspond à aucun besoin. Ils ont besoin de l'opac pour trouver les bouquins dans la bibliothèque. Ils ont besoin d'éléments personnels comme de savoir, dans le web et sans aller à l'opac, s'ils ont des bouquins en retard. Mais les statistiques d'utilisation semblent indiquer qu'il n'y a pas besoin de recherche fédérée pour les étudiants, en particulier de niveau L.

Ce dernier point est crucial: quel est le besoin pour la recherche fédérée à Angers?

D'après l'exemple de Valenciennes on serait tenté d'extrapoler en disant que cela concerne le niveau recherche; cela concerne des éléments homogènes: tous les périodiques de niveau recherche, mais pas: l'opac local, plus les périodiques de niveau recherche.

Et du coup il y a une question cruciale. Nous avons environ 6000 périos électroniques. Notre base de donnée bibliographique principale est Scopus: quelle est la part de nos périos électroniques qui ne sont pas couverts par Scopus? 300? 500? 1000? Plus de 1000? Moins que 100? Si nous sommes dans ce dernier cas, est-ce qu'il est raisonnable de faire un outil de recherche fédérée à grands frais? Scopus ne répond-il pas à nos besoins?

April 20, 2006 at 8:26 am 2 comments

links for 2006-04-14

April 15, 2006 at 12:20 am Leave a comment

e-bibliothèques / e-bibliothécaires

Mercredi prochain 19 avril je participe à la journée e-bibliothèques / e-bibliothécaires organisée par les conservateurs stagiaires de l'ENSSIB. Pour ce qui me concerne, je ferais une intervention sur le bibliothécaire-blogueur: que peut-on écrire dans son blog quand on est bibliothécaire? Qu'a-t-on le droit de dire? Que peut-on raisonnablement dire? 

Le programme de l'ensemble de la journée se trouve… sur le blog de la journée, comme il se doit: http://ebib.over-blog.com/article-2342369.html 

April 14, 2006 at 11:09 am Leave a comment

Older Posts


Feeds