Skip to content

Ajouter des COinS dans Primo

08/12/2010

Nous avons modifié notre catalogue en ligne, qui tourne avec Primo (d’Ex Libris), pour qu’il intègre des COinS.

Pour mémoire (mais vous pouvez suivre le lien fourni), les COinS sont une manière d’intégrer les métadonnées bibliographiques dans une page (en plus d’afficher joliment ces mêmes métadonnées) dans un format normalisé, afin que divers logiciels puissent les utiliser.

Principalement, l’OpenURL est fait pour permettre d’accéder rapidement à une ressource rencontrée quelque part sur Internet : un lien OpenURL tient compte du résolveur auquel vous êtes (institutionnellement) rattaché et vous propose

  • un lien vers l’article en ligne, s’il s’agit d’une ressource en ligne
  • un lien vers la notice dans le catalogue de votre bibliothèque, s’il s’agit d’un document papier

Zotero se sert également de ces COinS pour récupérer les métadonnées et les ajouter à votre base locale (cf. d’ailleurs un récent billet de Davidolib Eso62 sur le blog de Davidolib sur le sujet).

Concernant Primo, l’ajout de COinS ne le rend pas plus Zotero-compatible qu’avant : un translator existait déjà, s’appuyant sur le format de métadonnées spécifique à Primo, le PNX (Primo Normalized XML), fichier XML existant parallèlement à chaque notice mise en forme dans un catalogue (exemple de notice sur l’Opac, et son équivalent en PNX).

Cela dit, et en réaction notamment aux « plaintes » d’administrateurs Primo constatant que pour la récupération de l’ISBN, notamment, ce translator est fait n’importe comment, la suppression de celui-ci au profit d’un paramétrage systématique de COinS rendrait les choses plus souples et permettrait à chacun d’y mettre ce qu’il veut.

(soit dit en passant, quelqu’un s’était mis à chercher comment exploiter l’export RIS de Primo plutôt que la notice PNX. Donc plusieurs pistes sont ouvertes)

Pourquoi ?

D’abord pour le principe. A partir du moment où nous mettons en ligne des métadonnées, il est normal de les fournir dans un format à peu près standard, permettant de les réexploiter. Et ceci indépendamment des usages que, moi-même, je pourrais imaginer : ce sont aux internautes de les envisager — et ils ne peuvent le faire que si je leur en donne les moyens.

Ensuite, pour mettre en application ce que j’écrivais en mars 2009. Nos catalogueurs en médecine indexent les ouvrages permettant de préparer les épreuves de l’ECN (ex-internat de médecine). A l’époque nous avions une base spécifique de recherche, indépendante du catalogue. Désormais ces notices et leur indexation existent à l’intérieur du catalogue Primo.

Donc si une bibliothèque de médecine dispose d’un résolveur OpenURL, elle peut indiquer notre catalogue à ses étudiants : ils font une recherche par épreuve, trouve des résultats et rebondissent ensuite vers leur propre BU, grâce au plugin LibX que celle-ci aura pris soin de leur proposer.

En écrivant cela, j’ai conscience d’être dans le fantasme le plus absolu.

Cela dit, je pose ma propre pierre (la seule que je puisse poser) dans la vision d’un web où les catalogues de bibliothèques, et toutes les bases de données de manière générale, favorisent la circulation de l’internaute de l’une à l’autre de toutes les manières possibles.

Celle-ci en est une.

Pour les administrateurs de Primo : Comment ?

1. Utilisation d’un champ local dans la section <addata>. Par exemple, le champ lad02 (le lad01 étant déjà utilisé).

Dans ce champ, j’ai concaténé toutes les informations utiles, en utilisant les variables des COinS. Pour savoir le nom de chaque variable, j’ai utilisé le COinS Generator en y indiquant diverses valeurs. Et j’ai repris comme valeurs à intégrer, celles qui étaient utilisées dans la notice PNX.

Ce qui donne donc :

1. Deux variables Titre : title et btitle (pour les monographies)

La valeur display/title de lanotice PNX est reprise, et est précédée de la chaîne de caractère &amp;rft.title= une première fois, puis &amp;rft.btitle= une seconde fois

2. Une variable Auteur : au (prenant en compte les creator et les contributor)

Idem, la variable display/creator, puis la variable display/contributor, sont récupérées et précédées de la chaîne de caractère &amp;rft.au=


3. Une variable Genre

La variable display/type (book, journal, etc.) est reprise, préfixée de &amp;rft.genre=

4. Une variable ISBN

La valeur est récupérée du champ Unimarc 010$$a, et préfixée de : &amp;rft.isbn=


5. Une variable ISSN

De même, l’ISSN est récupéré du champ Unimarc 011$$a, et préfixé : &amp;rft.issn=

6. Une variable Publisher

Récupération du champ Unimarc 210$$c, préfixé : &amp;rft.pub=

7. Une variable Place (lieu de publication)

Récupération du champ Unimarc 210$$a, préfixé : &amp;rft.place=

8. Une variable Date de publication

Récupération du champ Display/creationdate, préfixé : &amp;rft.date=

9. Une variable Pages

Unimarc met dans le même champ les indications de volumes et du nombre de pages. Pour l’instant j’ai récupéré le champ tel quel (stocké dans display/format) et l’ai mis comme si c’était l’indication du seul nombre de pages, préfixé : &amp;rft.pages=

Au final, le champ lad02 contient (pour un livre comme celui-ci) quelque chose comme :

&amp;rft.title=Le petit livre des couleurs&amp;rft.btitle=Le petit livre des couleurs&amp;rft.au=Pastoureau, Michel [1947-...]&amp;rft.isbn=978-2-7578-0310-3&amp;rft.pub=L'Harmattan&amp;rft.place=Paris&amp;rft.date=2003&amp;rft.tpages=1 vol. (121 p.) : couv. ill. en coul. ; 18 cm.

Où caser ces informations dans l’affichage des notices ?

J’ai un peu tâtonné, et je suis preneur de meilleures idées.

Si on rajoute ces infos à la fin du titre, on a le problème suivant : dans la liste des résultats (après une recherche) la notice abrégée affichera le titre + lien COinS, mais si on clique sur le COinS, celui-ci est en fait englobé dans le lien vers la notice détaillée (puisque le titre est cliquable et pointe vers la notice détaillée).

Alors j’ai fait deux choses :

  1. Pour l’affichage dans la notice abrégée :
    1. création d’un champ local dans la section Display (chez nous, c’est déjà le champ lds12) construit ainsi :
      1. récup de la valeur du addata/lad02
      2. ajout au début de la chaîne de caractères
        <span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&amp;rfr_id=info%3Asid%2Fcatalogue.unice.fr
      3. Ajout à la fin de la chaîne de caractères
        "/>
    2. Ce champ est affiché sur la deuxième ligne dans les notices abrégées (Ongoing Configuration > View Wizard > sélection de la vue, de l’onglet, des Tiles, etc. > Brief Display)
  2. Pour l’affichage dans la notice détaillée : à la fin du champ Display/format, je rajoute la valeur du addata/lad02 en ajoutant la même chaîne de caractères en début et en fin que dans le champ lds12

Ainsi le lien OpenURL apparaît après le champ Auteur dans la notice abrégée, et après le champ Format dans la notice détaillée. Je l’ai mis dans le champ Format parce que c’est le seul dont je suis (à peu près) sûr qu’il existe pour toutes les notices…

Exemple en utilisant le plugin LibX de la BU d’Angers :

Notice abrégée


Notice détaillée


La visibilité en est assez mauvaise, je l’avoue. Mais pour l’instant je n’ai pas trouvé de meilleure manière de l’afficher.

Par ailleurs c’est encore largement perfectible. Notamment :

  • la récupération du nombre total de pages :  L’outil « Règles de normalisation » de Primo permettrait de ne garder que cette valeur, et d’enlever le reste (dimensions, etc.).
  • les noms d’auteur : là encore, Primo permet de scinder le nom du prénom, et d’enlever les dates de naissance et de mort.

Mais bon, j’ai trouvé que j’avais déjà assez prospecté comme ça, et je me suis arrêté là.

Publicités
6 commentaires
  1. davidolib permalink
    09/12/2010 12:50

    Rendons à César ce qui est à César et laissons à @eso62 ce qui lui appartient. Il est bel et bien l’auteur du billet sur Zotero sur mon blog ( d’ailleurs, il a les clés et il vient quand il veut). C’est aussi grâce à lui que j’ai réussi à rendre zotero compatible mon portail Archimed plus récent. Billet à suivre là dessus.

  2. 09/12/2010 13:27

    @Davidolib : c’est juste, je m’en étais fait la réflexion lors de la lecture du billet en question. Et plus tard, encore. Mais pas au moment où j’ai rédigé le mien…
    Je corrige, merci !

  3. François-Xavier Boffy permalink
    31/01/2011 16:37

    Bonjour et merci pour cet ancien post toujours d’actualité…

    En le survolant je me disais qu’a priori le processus d’ajout de champs dans la notice devrait permettre de poser dans la BDD des liens avec comme cible une carte indiquant la localisation physique des livres si la répartition des cotes d’ouvrages est cohérente. Me trompe-je ?

    Bon courage pour tout, y compris pour une éventuelle réponse.
    Très cordialement.

  4. 31/01/2011 18:28

    @F-X Boffy : Bonjour
    Cet « ancien post » a un mois… Je suis d’accord avec vous, il n’est pas encore complètement désuet et suranné.
    Si votre idée est de stocker quelque part un plan de la bibliothèque, et d’avoir pour chaque tranche de cote une image de ce plan avec une flèche (ce qui représente 10-20 images, je suppose), oui, c’est possible de générer dans les notices un lien vers l’une de ces images, en fonction de la valeur contenue dans la cote.
    Mais ai-je bien compris l’idée ?

  5. F-X Boffy permalink
    01/02/2011 15:51

    Sur l’ancienneté du post, c’est vrai que notre notion du temps est quelque peu changée sur le web… Mais par ailleurs Bibliothèques [reloaded] propose beaucoup de posts intéressants, très souvent, donc il m’a fallu remonter dans l’agrégateur pour le retrouver, d’où cette impression.

    En un mot : oui ! C’est exactement l’idée (avec des mises en couleur plus qu’avec des flèches pour signaler l’emplacement, mais c’est un détail cosmétique). C’est beau, une étude de faisabilité en une nuit 🙂

    Bon pardon pour l’excursus hors du sujet sur COinS.
    Et au plaisir de lire de nouveaux vieux posts…

Trackbacks

  1. Tweets that mention Ajouter des COinS dans Primo « Bibliothèques [reloaded] -- Topsy.com

Les commentaires sont fermés.

%d blogueurs aiment cette page :