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 Fabrice (site web personnel) . Évalué à 1.
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 tgl . É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 snotling0 . É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 snotling0 . Évalué à 3.
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 nnn . Évalué à 3.
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 snotling0 . Évalué à 1.
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 Mjules (site web personnel) . Évalué à 3.
Il y a également un serveur z39.50 :
http://www.abes.fr/abes/page,439,mode-public.html
[^] # Re: Les bibliothèques universitaires
Posté par snotling0 . Évalué à 1.
En fait, j'ai prévu de le faire mais c'est pas trivial à mettre en place : http://bibli.othequ.es/blog/?p=16
# Export en Z39.50 ?
Posté par davux (site web personnel) . Évalué à 2.
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 snotling0 . Évalué à 1.
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 nigaiden . Évalué à 1.
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 snotling0 . Évalué à 1.
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 Paul . Évalué à 1.
http://ccfr.bnf.fr/
[^] # Re: CCF ?
Posté par snotling0 . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.