Dans sa dernière colonne pour Library Journal, Roy Tennant évoque les développements récents dans le domaine des “logiciels de découverte bibliographique”, i.e. les opacs. Et je trouve intéressant les deux exemples qu’il prend.
Il parle de Primo (déjà évoqué ici) et du nouveau catalogue de NCSU – lui aussi évoqué dans le même post que Primo; je devrais tenir une colonne dans LJ ;-)
Il note que les deux outils proposent les mêmes fonctionnalités nouvelles: navigation à facettes, même type d’interface, etc.
Il note aussi que les deux outils empruntent la même voie pour parvenir à ce résultat: ils sortent les données du SIGB. Je le savais pour Primo, je l’ignorais pour NCSU. Ils ont sorti un peu plus d’1 million de notices de leur SIGB pour les confier à la société Endeca, qui a fait l’interface de recherche. Pas un système d’acquisition, pas un système de prêt, une interface de recherche. Qui ne fait que ça! Vous savez, la devise Unix: ne faire qu’une seule chose, la faire bien. Car en fait le problème de l’opac actuel n’est pas qu’il manque telle ou telle fonctionnalité, les fils RSS ou une meilleure ergonomie, c’est qu’il est collé comme une verrue sur un système qui est fondamentalement conçu pour autre chose: gérer le worklow interne de la bibliothèque.
Ce petit article me fait avancer un peu plus dans ma réflexion sur notre Système d’Information: il ne faut pas suivre la voie du Z3950 ou des web services pour la recherche, il faut sortir les données du SIGB et proposer au public une interface de recherche spécifique. Ce qui laisse malgré tout plein de choix:
- attendre un produit commercial de ce type (Primo)
- faire un outil de ce type dans le cadre d’une relation commerciale avec une société extérieure spécialisée non pas dans les bibliothèques spécialement, mais dans le traitement de l’information et les interfaces (Endeca)
- réaliser un outil de ce type dans le cadre d’un développement interne
Le nouveau catalogue collectif australien (http://librariesaustralia.nla.gov.au) utilise le système central d’OCLC PICA (comme le Sudoc), mais pas l’interface vendue par PICA.
Ils ont rechargé leurs données dans un moteur d’indexation (http://www.teratext.com.au/) développé, à l’origine, par un labo australien.
Je suis d’accord avec toi, Nicolas, sur le principe de réindexer toute la base bibliographique (et les autorités), mais je persiste à penser que cette indexation centrale des données doit coexister avec le recours à des webservices qui peuvent compléter les données indexées (http://www.abes.fr/abes/documents/reseau/journees_reseau/05_ExperimentationWebSudoc.ppt). Le web doit rester décentralisé. Faut-il que chacun maintienne des index aussi monstrueux que ceux de Scopus ou de Los Alamos (http://library.lanl.gov/lww/vision.htm) ?
Bien sûr cela dépend des missions et fonctions qu’on associe à son catalogue.
Au fond je suis d’accord. Je pense que les web services peuvent être utilisés en complément de la recherche. En particulier, dans un cadre BU, pour tout ce qui n’est pas strictement bibliographique: le compte lecteur, par ex.; ou bien la disponibilité des ouvrages.
Là où j’ai des doutes, c’est pour l’utilisation “live” des web services pour la recherche, qui attaquerait les index du SIGB.
On est d’accord.
Dans notre expérimentation, comme tu le sais, on est passé par une passerelle z3950/SRU sur les index Sudoc pour développer très vite un essai d’interface enrichie en repartant des notices brutes (marcxml). D’ailleurs, les performances étaient déplorables. Mais, en l’espèce, l’intérêt était ailleurs.