Journal Mashup de recherche de livres dans les bibliothèques

Posté par .
Tags :
9
3
juin
2009
Mon premier journal pour évoquer un projet perso sur lequel je travaille depuis quelques mois : http://bibli.othequ.es
Il s'agit d'un service permettant de localiser un livre parmi un certain nombre de bibliothèques en France.

Concrètement, il s'agit d'une sorte de catalogue fédéré, recensant pour le moment majoritairement des bibliothèques municipales, mais voué à intégrer également des bibliothèques universitaires, départementales, associatives, etc. C'est ce croisement d'information qui m'a donné l'idée de ce service -- plus les déficiences de nombreux OPAC des bibliothèques...
OPAC = Online_public_access_catalog

Actuellement, "l'interface d'entrée" pour l'interrogation de ce catalogue se fait via une sorte de mash-up à la sauce "Web 2.0", grâce à l'outil Greasemonkey. Ce dernier incruste alors un petit widget dans les pages des principaux sites Web français de vente en ligne (Amazon, Alapage, etc), qui sont, quoiqu'on en dise, de bons OPAC d'un certain côté.

Bien sûr, on peut tout à fait imaginer d'autre utilisations et notamment différents types d'interface utilisateur pour exploiter les données de ce service. J'ai bien pensé documenter une petite API en XML/JSON -- mais ça dépend des besoins et des usages qui en seraient faits. Pour le moment, ça fonctionne avec, en entrée, un ISBN et, en sortie, un résultat de la recherche sur les différents catalogues des bibliothèques sélectionnées.

Si ce genre de service vous semble utile, vos commentaires et vos suggestions m'intéressent !
  • # sympa, mais utile... pas sur

    Posté par (page perso) . Évalué à 1.

    Comment récupère tu les données des Biblio pour les fédérés dans un premier temps deja, depuis leur OPAC, leur serveur Z39-50 ? ( ca doit limité à trés peu de BM vu l'utilisation qu'il est fait des serveur Z39-50.... )

    Sinon après c'est une idée qui techniquement est séduisante, si ensuite elle est utile... Etant donnée que les bibliothèques ne prêtent qu'a leurs adhérents et que les réseaux de prêt fédéré tel que celui du Val d'oise avec revodoc sont encore trés trés trés peu communs en France ( et quoiqu'il en soit, ils ont leur propre OPAC trés light en passant... ).

    Donc fédéré de l'information juste pour la fédéré, je sais pas si il y a un marché d'utilisateurs.
    Bien souvent la personne qui cherche va se contenter de chercher sur l'opac de ça BM.

    Cas concret, j'ai besoin d'un livre, je cherche sur ton programme, il m'indique qu'il est disponible à 500Km de chez moi dans un jolie site agréable, avec de l'information à outrance, de la plus value que tous les OPAC actuel devraient avoir, cool, et aprés ?
    • [^] # Re: sympa, mais utile... pas sur

      Posté par . Évalué à 3.


      Cas concret, j'ai besoin d'un livre, je cherche sur ton programme, il m'indique qu'il est disponible à 500Km de chez moi dans un jolie site agréable, avec de l'information à outrance, de la plus value que tous les OPAC actuel devraient avoir, cool, et aprés ?


      C'est pas vraiment ça l'idée, mais plutôt :
      - tu as sélectionné, une fois pour toute, la (les) bibliothèque(s) proche(s) de chez toi ;
      - quand tu es sur Amazon (ou quelques autres), à côté de chaque bouquin tu as une icône qui t'indique s'il est, ou non, dispo dans ta (tes) bibliothèque(s).

      Il n'y a donc pas à chercher quoi que ce soit que tu n'aurais pas cherché de toute façon (sur Amazon ou autre), et pas de risque de se faire pointer une bibliothèque à 500 km.


      Perso je trouve l'idée très élégante, joliment réalisée, et a priori très utile (on verra bien avec le temps), donc merci à l'auteur.

      Petite suggestion : la signification du symbole /!\ devrait être documentée. Au début je l'ai eu parce que j'avais pas configuré de bibliothèque (arf, c'que c'est de pas lire les explications...), puis parce que je n'avais pas autorisé les cookies pour bibli.othequ.es. Un tooltip sur l'icône peut-être ?
      • [^] # Re: sympa, mais utile... pas sur

        Posté par . Évalué à 2.

        [...]
        Il n'y a donc pas à chercher quoi que ce soit que tu n'aurais pas cherché de toute façon (sur Amazon ou autre), et pas de risque de se faire pointer une bibliothèque à 500 km.


        En effet, c'est une très bonne explication :-)

        Petite suggestion : la signification du symbole /!\ devrait être documentée.

        Pas faux, je vais rajouter des explications pour ce cas. Merci du conseil.
    • [^] # Re: sympa, mais utile... pas sur

      Posté par . Évalué à 3.

      Comment récupère tu les données des Biblio pour les fédérés dans un premier temps deja, depuis leur OPAC, leur serveur Z39-50 ? ( ca doit limité à trés peu de BM vu l'utilisation qu'il est fait des serveur Z39-50.... )

      En effet, j'essaie d'utiliser des serveurs Z39.50 en priorité car c'est très simple à interroger.
      Cependant, il n'y en a pas des masses -- mais il y en a, il faut plus ou moins aller 'à la pêche'. Au final, je suis donc contraint à faire du screen scraping. Pas top mais on fait ce qu'on peut :-)
    • [^] # Re: sympa, mais utile... pas sur

      Posté par . Évalué à 3.

      Dans le même genre d'idée, mais qui répond à cette question des 500Km,
      on travaille actuellement à un petit projet de bibliothèque collective :

      http://dijon.biblio-collective.org/ basé sur pmb (légèrement modifié)

      l'idée étant là aussi de réunir virtuellement les fonds de différentes bibliothèques associatives locales (dijonnaises),
      mais aussi de permettre à n'importe qui de créer sa propre bibliothèque virtuelle en indiquant les livres qu'il accepte de prêter.

      On peut ainsi parcourir les différentes bibliothèques, ou faire une recherche sur toute la base, et ensuite prendre contact avec le propriétaire du livre trouvé.

      (sachant que le nom de domaine biblio-collective.org et nos modifications de pmb sont disponibles à quiconque voudrait faire de même chez lui)
      • [^] # Re: sympa, mais utile... pas sur

        Posté par . Évalué à 1.

        C'est intéressant comme projet.
        Ca me fait penser que faudrait que je m'attaque aux bibliothèques associatives, bien que peu d'entre elles doivent avoir une 'visibilité' sur le Net (catalogue en ligne).
  • # Les bibliothèques universitaires

    Posté par (page perso) . Évalué à 3.

    tu dois déjà le savoir mais le catalogue de la plupart des BU (toutes ?) est accessible en ligne sur www.sudoc.abes.fr

    Il y a également un serveur z39.50 :
    http://www.abes.fr/abes/page,439,mode-public.html
  • # Export en Z39.50 ?

    Posté par (page perso) . Évalué à 2.

    Quel que soit le moyen d'importer les livres, ce que tu pourrais faire c'est peut-être proposer un export en Z39.50. Là, oui, je pense qu'il y aura de la demande. Je trouve ça un peu dommage de réinventer un protocole d'accès aux bouquins, en mettant une surcouche à HTTP/XML, quand un protocole dédié existe déjà.

    L'autre truc qui me dérange, plus au niveau architectural, c'est l'aspect centralisé actuel de la chose (si j'ai bien compris l'idée). Il serait intéressant d'imaginer un système de réplication et/ou fédération de cette information, un peu comme l'architecture DNS.

    Au final, ça donnerait une sorte de bibliothèque décentralisée interrogeable via Z39.50, là j'adopte. Mais j'avoue que le coup de la web-app, ça me fait toujours grincer des dents. On leur en fout pas mal sur le dos à ces pauvres HTTP et XML, ils vont finir par se prendre pour des nouveaux TCP/IP.
    • [^] # Re: Export en Z39.50 ?

      Posté par . Évalué à 1.

      Quel que soit le moyen d'importer les livres, ce que tu pourrais faire c'est peut-être proposer un export en Z39.50.
      L'autre truc qui me dérange, plus au niveau architectural, c'est l'aspect centralisé actuel de la chose (si j'ai bien compris l'idée). Il serait intéressant d'imaginer un système de réplication et/ou fédération de cette information, un peu comme l'architecture DNS.

      Si je comprends bien, tu voudrais pouvoir interroger le catalogue fédéré via Z39.50 ?
      Mais je vois pas bien l'idée de décentralisation. Ou alors ça voudrait dire que mon service ne serait qu'un 'annuaire' de serveurs Z39.50, auxquels il faudrait se connecter au final pour faire les interrogations de catalogues ?

      Un des problèmes avec la technologie -- et les implémentations ! -- Z39.50, c'est qu'il y a toujours plein de subtilités embêtantes. Tous les serveurs n'ont pas le même 'profil Z39.50', c'est-à-dire n'acceptent pas les mêmes critères de recherche, etc. Autre exemple : certains ont besoin de l'ISBN exact (10 ou 13) pour trouver le (bon) résultat, d'autres font la 'traduction' automatiquement.

      (D'ailleurs, c'est pour ça que j'ai basé mon service de recherche sur l'ISBN, car c'est le seul critère de recherche à peu près fiable au final.)

      De plus, comme je fais du screen scraping, tout n'est pas accessible en Z39.50 nativement, c'est moi qui héberge une passerelle Web / Z39.50, via le logiciel SimpleServer.
      Et puis d'ailleurs, le protocole Z39.50, c'est un peu d'une autre époque : pas moyen de faire de mashup avec ça, car 'inatteignable' depuis un navigateur Web...
      Reste SRU/SRW que je pourrais facilement offrir comme service, grâce au logiciel yazproxy que j'utilise déjà en interne (réutilisation/limitation de connexions, cache, etc).

      Mais, même après tout ça, reste le problème que Z39.50/SRU/SRW est trop bas niveau pour la plupart des utilisations de ce service : il faut un genre de 'protocole métier'.
      Exemple : en plus de l'ISBN, mon service Web acceptent les identifiants produits de Chapitre.com et Fnac.com. Impossible à supporter ça en Z39.50, car il y a une étape 'métier' faite sur mon serveur.
      Autre problème : un serveur Z39.50 peut contenir les catalogues de plusieurs bibliothèques différentes (ex: SUDOC, catalogue régional). Mon service Web permet lui de spécifier un ensemble de recherche plus 'fin' que le serveur, comme le niveau d'une ville précise.
      En clair, mon service Web cache toute la complexité des recherches Z39.50 :-)
  • # Nom de domaine

    Posté par . Évalué à 1.

    A mon avis il faudrait considérer un changement vers un autre nom de domaine, pour la simple raison que le site actuel ne semble pas répondre aux critères d'attribution des .es ; et du coup il y a un risque de perte du jour au lendemain du nom de domaine sans aucun recours possible.

    Voici ce que j'avais envoyé à quelqu'un à ce sujet :

    On peut utiliser un site en .es dans les cas suivants :
    _ personnes physiques ou morales établies en Espagne ;
    _ personnes physiques ou morales voulant offrir tout ou partie de leurs services au marché espagnol ;
    _ personnes physiques ou morales voulant offrir des informations, services et/ou produits liés à l'Espagne pour des raisons culturelles, historiques ou sociales


    Deux liens :
    https://www.nic.es/who-can-apply/article/261
    https://www.nic.es/media/2007-12/1197041544918.pdf
    • [^] # Re: Nom de domaine

      Posté par . Évalué à 1.

      Ah zut, ils nous embêtent ces Espagnols :-)
      Moi qui m'étais déjà creusé la tête pour trouver un nom -- et n'en avait pas trouvé de pertinent d'ailleurs, d'où le repli sur un nom branchouille Web 2.0 !
      Reste à faire une version en espagnol :-)
  • # CCF ?

    Posté par . Évalué à 1.

    L'intégration aux sites commerciaux est intéressantes mais j'ai voulu "vendre" ton outil qui me parait bien vu à des gens du métier (bibliothéquaires, chercheuses ;) ) et toutes m'ont envoyé bouler sur le CCF (Catalogue Collectif de France) :

    http://ccfr.bnf.fr/
    • [^] # Re: CCF ?

      Posté par . Évalué à 1.

      Euh, d'après ce que j'ai compris, le CCFr est la combinaison de :
      1. catalogue de la Bibliothèque nationale de France
      2. catalogue des bibliothèques universitaires (SUDOC)
      3. catalogue de fonds 'particuliers' de certaines bibliothèques municipales

      Donc c'est pas vraiment équivalent à mon service, qui est notamment destiné avant tout aux ouvrages 'habituels', que l'on peut emprunter en particulier.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.