Skip to content

Quai Branly, Primo et Zotero

25/03/2011

Comme nous le signale l’ACEF (association des clients d’Ex Libris France) – info aussi présente sur le site d’Ex Libris —  la médiathèque du musée du Quai Branly vient d’ouvrir un opac Primo (version 3), qui illustre bien, une nouvelle fois, toute la problématique des bibliothèques qui se demandent constamment comment intégrer leurs outils documentaires au sein du site de leur tutelle (université, municipalité, ici : musée), quitte à ce que la réponse soit parfois : on fait site à part…

Je ne pèse pas ici le pour et le contre sur l’une de ces solutions : je signale simplement que la question ne pourra vraisemblablement jamais être résolue  une bonne fois pour toutes.

Et je ne cherche pas à faire des critiques (masquées ou non) aux collègues de cette médiathèque : le résultat est sympa. Il est simplement l’occasion pour moi de rendre « visibles » certains éléments internes. Que ces collègues en soient donc remerciés.

Donc, sur la question de l’intégration opac – site web, la solution retenue au Quai Branly est la suivante :

  • quand vous arrivez pour la première fois sur la page de recherche du catalogue, le formulaire est présent dans la page générée par le CMS (Typo3, en l’occurrence).
  • Si vous lancez la recherche, on change complètement de structure : le formulaire et les résultats de Primo sont intégrés dans un frame. L’URL garde la mémoire de la requête effectuée sous la forme : http://www.quaibranly.fr/fr/documentation/le-catalogue-de-la-mediatheque/resultat.html?request=lévi-strauss&rechercher=Ok&no_cache=1. La page principale contient un frame qui appelle les résultats, et on peut récupérer l’URL de la page en question : si vous l’envoyez par mail, votre correspondant pourra ouvrir cette liste.
  • L’internaute ne se rend compte de rien (sauf, sans doute, que le menu latéral gauche a disparu entre temps, ce qui n’est pas plus mal car avec les facettes ça aurait constitué deux menus sans rapport l’un avec l’autre), il ne voit pas qu’il est passé d’une page « normale » à une structure de frames. Il peut relancer une recherche, passer en recherche simple, etc.
    En naviguant dans les résultats (à l’intérieur du cadre Primo), il n’agit que sur la partie inférieure, encapsulée, de la page.

L’ergonomie est agréable, la charte graphique respectée (je note aussi, pour mes propres projets, que les temps de réponse d’affichage des onglets sous chaque notice abrégée sont très bons).

(en terme de navigation, il reste ce qui est je pense une scorie, ou un bug : quand à la droite d’une notice abrégée on a un lien « 4 versions », qui signifie que le système a repéré quatre ouvrages ayant même titre et même auteur, mais avec 4 années de publication différentes — c’est du FRBR, en gros — en cliquant sur ce lien on ouvre directement Primo, en perdant donc la navigation du frame supérieur)

Je vois tout de même deux inconvénients à ce choix

(précision encore : chaque choix a ses inconvénients, il s’agit de choisir ceux qui vous semblent les moins gênants pour les besoins que vous projetez sur votre opac)

1. Après avoir lancé une première recherche, l’URL garde la mémoire des mots entrés dans le formulaire initial. Si je relance de nouvelles recherches dans le frame Primo, je n’agis que sur la partie inférieure, et l’URL ne change pas. Donc il devient impossible de récupérer l’URL d’une liste de résultats.

Mais je reconnais que je suis parfois obsédé par la manipulabilité des opac. Est-ce précieux pour un internaute ? Je n’en sais rien. C’est juste que, comme on peut le faire sur tous les sites web et moteurs de recherche, c’est dommage de ne pas pouvoir le faire sur un catalogue de bibliothèque (et ils sont nombreux, les catalogues dans ce cas-là !).

2. le catalogue cesse d’être Zotero-compatible. C’est l’occasion d’une petite explication technique (courte)

Petite explication Zotero

Pour chaque type de site, Zotero regarde dans sa base de translators s’il en a un qui pourrait correspondre. Si on est sur Amazon, Zotero va reconnaître le site Amazon et utiliser le screen scraping (merci à Sylvain de m’avoir fait comprendre l’expression !). Idem sur un site Aleph, ou sur le Sudoc.

Comment fait-il ?

Chaque fichier paramétrant un translator Zotero commence par une série de métadonnées. Voici celles du translator Primo :

{
« translatorID »: »1300cd65-d23a-4bbf-93e5-a3c9e00d1066″,
« label »: »Primo »,
« creator »: »Matt Burton »,
« target »: »/primo_library/ »,
« minVersion »: »1.0.0b4.r5″,
« maxVersion »: » »,
« priority »:100,
« inRepository »: »1″,
« translatorType »:4,
« lastUpdated »: »2011-03-18 09:36:45″
}

La ligne en gras signifie : ce translator s’applique si dans l’URL de la page, on trouve la séquence de caractères « /primo_library/ ». Dans le cas d’un frame, c’est foutu : l’URL est celle de la page supérieure.

Une astuce serait peut-être (mais c’est à tester — sans garantie) que la page contenant le frame soit rangée dans un répertoire de ce nom. Ce qui permettrait au translator Primo de s’activer.

Là où je veux en venir, c’est que si vous mettez en place, allez mettre en place ou venez de mettre en place un opac que vous avez bien personnalisé, jetez un coup d’oeil au translator Zotero, pour voir si votre opac s’y conforme.

Dans ce cas précis, de toute façon, le translator de Primo ne fonctionne pas pour la v3 : il faut attendre la mise à jour (demandée il y a une semaine).

Les commentaires sont fermés.

%d blogueurs aiment cette page :