Skip to content

Opac Aleph non Zotero-compatible — Problème en suspens

22/07/2010

Billet traitant de certains rouages de Zotero. Prenez ce que vous voulez, rendez ce que vous pouvez🙂

A force de personnalisations (y compris réussies), certains opac Aleph ont cessé d’être Zotero-compatibles.

En regardant comment fonctionne le script Zotero qui récupère les métadonnées des notices Aleph, on peut essayer de comprendre pourquoi.

Je n’ai pas forcément la réponse à tous les cas, mais peut-être les éléments présentés ici permettront-ils à certains d’aller plus loin que moi… Ou à d’autres (qui connaissaient déjà tout cela) d’y répondre.

Quant aux autres – eh bien ! ils peuvent y trouver une occasion de comprendre un peu comment fonctionne un translator Zotero.

Types de translators

Dans votre profil Firefox, se trouve un répertoire zotero qui contient un répertoire translators

Il y a 3 types essentiels de translators :

  • les programmes qui permettent d’importer des notices dans Zotero, en décryptant les interfaces rencontrées
  • les scripts qui permettent d’exporter une ou plusieurs notices selon un certain format (RIS, BibTex, Unimarc XML, etc)
  • le translator CrossRef.js (translatorType = 8) qui sert de baguette magique pour importer des notices bib à partir d’un seul identifiant : ISBN, DOI, n° Pubmed

Le translator qui permet d’importer des notices Aleph est de type 4, qui signifie « Import ».

La ligne target indique qu’il faut utiliser ce translator quand l’URL ressemble à une certaine structure.

Pour ceux qui ont mis en pratique les quelques tutoriels Yahoo Pipes, vous devriez y reconnaître des expressions régulières.

Pour les autres : cette ligne signifie qu’on reconnaît un opac Aleph à une URL ressemblant à :

Structure http:// URL racine (nom de domaine) /F une série de chiffres ou lettres ?func-findou?fund-scan

ou

?func-short

Commentaires (c’est l’identifiant de session) Notice détaillée ou abrégée
Exemple 1 http:// catalogue.univ-angers.fr /F 189749879879873-BAXDE2 ?func-find&docs=

A noter : si vous voulez pointer proprement vers une notice détaillée, vous allez prendre l’URL

http://catalogue.univ-angers.fr/F/CLLTSRIEAJG4E7PPFKG6X3CVH3J4MXIH8U1DY1XBL9BGCXSQEY-52898?func=full-set-set&set_number=000160&set_entry=000003&format=999

et en enlever l’identifiant de session :

http://catalogue.univ-angers.fr/F/?func=full-set-set&set_number=000160&set_entry=000003&format=999

Mais dans ce cas-là le test ci-dessus ne fonctionne pas (il ne trouve pas d’identifiant de session) et ne propose donc pas la petite icône  proposant de récupérer la notice.

Liste de résultats et notice détaillée

Ensuite, un translator doit détecter s’il s’agit

  1. d’une liste de résultats (à la suite d’un test sur la présence d’un test sur la structure de l’URL ou sur le contenu de la page, il renvoie la commande return "multiple";)
  2. d’une notice détaillée

Cette détection est dans le paragraphe qui commence par

function detectWeb(doc, url) {

S’il s’agit d’une liste de résultats, le programme doit suivre l’URL qui pointe vers chaque notice détaillée, et appliquer pour chacune le cas « Notice détaillée ».

S’il s’agit d’une notice détaillée, il applique la règle qui commence par :

function doWeb(doc, url) {

Entre cette accolade de début et l’accolade de fin qui lui correspond, la notice est décomposée en champs. Chaque champ est rattaché au champ Zotero qui lui correspond.

Translator Marc

Le translator Aleph a une particularité : il faut partie des catalogues de bibliothèques, qui permettent d’avoir accès à la notice au format Marc.

Comme plusieurs types de sites le permettent, les développeurs Zotero ont trouvé plus simple

  • de faire un translator Marc.js qui pour chaque champ Marc indique quel est le champ Zotero correspondant.
  • d’indiquer dans le translator Aleph (mais aussi les translators BIUM.js, Sirsi, InnOpac, Voyager, VTLS, etc.) qu’une fois affichée la notice Marc, il faut utiliser la correspondance de champs définie dans le translator Marc.js

Récapitulons

1. Le translator Aleph reconnaît une URL de notice détaillée Aleph

2. Dans l’URL de la notice, il transforme « &format=999 » (qui désigne l’affichage standard) en « &format=001 » (affichage de la notice équivalente, en Marc

3. Le translator décrypte le tableau produit, qui liste dans la première colonne les champs Marc, et dans la seconde les sous-champs et leurs valeurs.

4. Une fois récupérées toutes ces variables (010$a, 200$a, 200$c, etc.), il appelle le translator Marc.js qui fait une correspondance : 010$a=ISBN, etc.

Où est le problème ?

S’il y a un problème, il se situera certainement à l’étape 3.

Tous les opac Aleph que j’ai testés ont bien conservé (souvent à l’insu des bibliothécaires, je suppose) la possibilité d’afficher un format Marc en changeant un paramètre dans l’URL.

De même, avoir un tableau à 2 colonnes sur le modèle

LDR BK
010 $a978-2323-29489$c25 EUR
200 $aBleu : Histoire d’une couleur$b[Texte imprimé]$cMichel Pastoureau
etc

est relativement facile à décoder : on prend la première colonne comme nom de champ, et la seconde comme valeur du champ.

Donc je pense que le problème pour Zotero sera de trouver le tableau.

En effet la page en question ne contiendra certainement pas un seul tableau. Dans ce genre d’affichage, on trouve plusieurs tableaux imbriqués, l’un en bandeau pour afficher le menu, un autre à droite pour lister des options, etc.

Le script Zotero Aleph.js prévoit plusieurs tests pour essayer de trouver le bon tableau :

if (newDoc.evaluate('//*[tr[td/text()="LDR"]]/tr[td[2]]', newDoc, nsResolver, XPathResult.ANY_TYPE, null).iterateNext()) {

xpath = '//*[tr[td/text()="LDR"]]/tr[td[2]]';

} else if (newDoc.evaluate('//*[tr[th/text()="LDR"]]/tr[td[1]]', newDoc, nsResolver, XPathResult.ANY_TYPE, null).iterateNext()) {

xpath = '//*[tr[th/text()="LDR"]]/tr[td[1]]';

th = true;

} else if (newDoc.evaluate('//tr[2]//table[2]//tr', newDoc, nsResolver, XPathResult.ANY_TYPE, null).iterateNext()) {

xpath = '//tr[2]//table[2]//tr[td[2]]';

nonstandard = true;

} else if (newDoc.evaluate('//table//tr[td[2][@class="td1"]]', newDoc, nsResolver, XPathResult.ANY_TYPE, null).iterateNext()) {

xpath = '//table//tr[td[2][@class="td1"]]';

nonstandard = true;

} else if (newDoc.evaluate('//tr/td[2]/table/tbody[tr/td[contains(text(), "LDR")]]', newDoc, nsResolver, XPathResult.ANY_TYPE, null).iterateNext()) {

xpath = '//tr/td[2]/table/tbody[tr/td[contains(text(), "LDR")]]/tr';

nonstandard = true;

}

En gras : Zotero teste l’existence de balises HTML <td> correspondant à un certain chemin XPath.

Par exemple dans le code //table//tr[td[2][@class="td1"]] (présent ci-dessus)

Zotero cherche s’il existe, n’importe où dans le document, une balise <table> dont dépend une balise <tr> (ligne de tableau) – cette balise <tr> doit avoir au moins deux balises <td> (càd que la ligne a au moins deux colonnes) et la seconde balise <td> doit avoir un attribut class="td1".

Bref, ce test est vérifié si la page contient par exemple :

<table>
<tbody>
<tr>
<td>200</td>
<td class=”td1”>$$aBleu : Histoire d’une couleur</td>
</tr>
</tbody>
</table>

Ce qui correspond à :

200 $$aBleu : Histoire d’une couleur

Il faut donc que le chemin jusqu’à l’information, tel que prévu dans le translator, existe toujours dans l’interface en dépit des personnalisations successives.

Un cas plus vicieux

Donc a priori, la plupart du temps un problème sur une interface censée être reconnue par Zotero viendra du fait que le chemin a été modifié pour cause de personnalisation poussée. Mais à Angers, non…

Concernant l’opac du SCD d’Angers, c’est plus vicieux encore. Le problème est perturbant, et intéressant même s’ils viennent de lancer un appel d’offres pour un nouvel Opac.

Voici ce qu’on observe :

  1. Allez sur cet opac, faites une recherche et affichez une notice
  2. Vous constatez que son URL se termine en format=999 (exemple)
  3. Essayez de récupérer la notice dans Zotero : vous aurez un message d’erreur
  4. Dans cette fin d’URL, vous remplacez le 999 par 001 : vous affichez ainsi la notice en MARC
  5. Revenez en arrière (ou remplacez de nouveau 001 par 999) pour afficher la notice en format standard
  6. Essayez de récupérer la notice Zotero : le chargement de la notice fonctionne

Le code des deux pages (avant et après affichage de la notice en MARC) est bien le même. Mais Zotero n’est capable de récupérer les zones MARC qu’après que le navigateur les a affichées.

Evidemment, ce comportement n’est pas systématique avec Aleph, et la quasi-totalité des opac Aleph fonctionne bien (Brest, Montpellier, etc.). J’ai tout de même observé la même chose avec le catalogue du SCD de Paris 5.

Si quelqu’un a une explication ???

(Si ça peut aider : à ma connaissance le phénomène ne se retrouve pas pour les version anglophones)

15 commentaires
  1. symac permalink
    22/07/2010 10:24

    Merci lully pour cette analyse de de problème.

    La solution par contre ne semble pas couler de source, d’autant que les différences sur les pages au format marc entre les sites où ça fonctionne et ceux où ça ne fonctionne pas ne saute pas aux yeux. Les premiers tests ne m’ont pas permis de comprendre la différence mais je pense que je reviendrai sur ce point, c’est assez intrigant !

  2. franceBIB permalink
    22/07/2010 12:44

    intéressant !
    même problème avec le catalogue de la BCX
    http://bibli.polytechnique.fr/F/?func=file&file_name=find-b&local_base=CATAL

  3. 22/07/2010 13:16

    @franceBIB : merci pour ce nouvel exemple.
    En fait, au regard des cas constatés, j’en viens de plus en plus à penser que ça n’a rien à voir avec la personnalisation, puisque manifestement le code des pages (chemin XPath vers les valeurs dans la page HTML) n’est pas en cause, mais plutôt avec un paramètre quelconque, du genre qui gère les cookies, le cache ou quelque chose comme ça.

  4. 22/07/2010 13:50

    Quelques pistes supplémentaires qui vont dans ton sens Lully. Au niveau du processDocuments dans le translator Aleph, on récupère une variable newDoc. Si tu essaies de parcourir ce document sans avoir visité la page marc, il ne semble récupérer que le head, mais pas le body. Si en revanche tu as déjà visité la page marc il va charger le head & le body.

    Tu peux tester sur une notice détaillée en ajoutant dans la boucle processDocuments le code suivant : http://gist.github.com/485917 . On voit dans le debug qu’il trouve un « object HTMLHeadElement » et un « object HTMLBodyElement » si on a déjà chargé la page marc.

    Les cookies n’ont pas l’air d’entrer en ligne de compte. Par contre le cache oui. Avec la web developper toolbar de firefox, si on utilise l’option Désactiver > Désactiver le cache, il semble que l’astuce consistant à consulter la vue marc pour que ça fonctionne n’est plus bonne.

    Voilà quelques pistes, je pense qu’un poste indiquant ces éléments sur zotero-dev serait tout indiqué pour trouver des pistes, j’avoue être à cours d’idées.

  5. 22/07/2010 13:50

    Comme je te le disais en « off », le fait qu’un appel d’offres soit en cours n’enlève rien à mon intérêt pour ce mystère parce que :

    – Aleph est toujours notre SIGB ( et que je n’ai nulle intention d’en changer – on ne change pas un outil qui fonctionne bien et rend tous les services que l’on attend de lui) ;
    – je n’ai jamais eu le temps (en vrai, les capacités) de trouver le pourquoi du comment, et ça m’agace de ne pas savoir ;
    – ça servira toujours à quelqu’un si une solution émerge (ce quelqu’un pouvant être moi😉 )
    – corriger ce problème reste intéressant, en soi🙂

  6. 22/07/2010 13:57

    @symac : Merci beaucoup pour les éléments que tu donnes déjà. Je vérifie aussi grâce à ton commentaire qu’il me manque complètement la méthodologie pour aborder ce genre de problème.
    Quand on poster sur zotero-dev, je suis d’accord sur le principe, certes. Mais je t’avoue, là, comme ça, que je serais bien en peine de savoir quoi décrire effectivement (quelle information est effectivement importante ?, quelle info est inutile ?).
    Donc si tu te sens…😉

    @dbourrion : tu noteras que la formulation retenue ne suggère rien qui contredise ton commentaire (ce qui n’était pas le cas, je le reconnais, de la précédente version !)

  7. 23/07/2010 12:42

    J’ai essayé de synthétiser les problèmes sur la liste zotero-dev ici : http://groups.google.com/group/zotero-dev/browse_thread/thread/774562a0f3b9ca8f on verra ce qu’il en ressort …

  8. 23/07/2010 12:49

    @Symac : j’ai lu ça – merci beaucoup !

  9. Jordi Gasull permalink
    26/07/2010 16:16

    Dans la même ligne que Dbourrion
    – je n’ai jamais eu le temps (en vrai, les capacités) de trouver le pourquoi du comment, et ça m’agace de ne pas savoir ;
    j’avais remarqué dans le passé que notre opac (http://ec.europa.eu/eclas langage par default: l’anglais) se resistait à fonctionner avec Zotero … dans notre serveur production. Par contre, en serveur test, pas de problème!!! (sauf si l’usager veut personnaliser bcp son navigateur avec des ‘personnas’, etc.)
    Donc, je soupçonnais plutôt que quelques détails de configuration des deux serveurs pouvaient être differents à niveau de cache, cookies, etc.
    Il m’aurait fally suivre cette voie d’investigation, mais puisque Firefox n’est pas le navigateur de choix chez nous, je n’ai pas eu trop l’occasion de m’y investir.
    Merci pour avoir soulevé la question, aussi auprès du group de developpeurs

  10. 26/07/2010 18:33

    @Jordi Gasull : dans votre cas, la raison est très simple (mais pour la résolution, c’est à voir avec le service informatique) : Zotero ne reconnaît un opac Aleph que si l’URL est en
    http://nomdedomaine.xx/F/cookie?etc
    Or dans votre cas, vous avez :
    http://ec.europa.eu/eclas/F/
    En fait, il y a un nom et un slash de trop, qu’il faudrait supprimer.
    Si vous obtenez par exemple :
    http://ec-eclas.europa.eu/F/, ça passerait.

  11. Jordi Gasull permalink
    27/07/2010 07:50

    @Lully
    wow! c’est vrai!
    C’était bcp plus simple et basique que ce que je soupçonnais!! Merci pour le tuyeau! 🙂

  12. Ming Yeung permalink
    28/07/2010 13:56

    J’ai essayé d’abord d’ajouter des documents au panier, et puis je pouvais les ajouter à Zotero du panier. Ça marche avec le catalogue d’univ-angers et aussi avec celui de K.U.Leuven. (Excusez-moi, je ne parle pas bien le français.)

  13. 29/07/2010 08:30

    @Ming Yeung : outre que votre français est parfait, je vous remercie pour cette indication complémentaire, qui va peut-être permettre d’avancer dans la compréhension du problème.
    Par ailleurs, le passage par le panier ne peut vraisemblablement pas être une « solution de contournement » satisfaisante, puisqu’il n’est (je pense) pas envisageable de la proposer à des lecteurs-internautes.

  14. Ming Yeung permalink
    24/03/2011 18:52

    J’ai un peu de succès sur ce problème et j’ai affiché mes progrès sur Google Group: https://groups.google.com/d/msg/zotero-dev/d0VioPO5yo8/ss_XZkySoIkJ

    Veuillez-vous jeter un coup d’oeil si vous êtes interessé? Merci.

Trackbacks

  1. De Moccam à Zotero : on avance à petits pas « Bibliothèques [reloaded]

Les commentaires sont fermés.

%d blogueurs aiment cette page :