Recommandation de Web Services pour le SIGB

La Digital Library Federation (DLF) a une certaine influence: quand elle fait un groupe sur les besoins de gestion de la documentation électronique (ERMI), les systèmes de gestion commerciaux (Verde par exemple) implémentent ses recommandations.

DLF vient de mettre sur pied un nouveau groupe, qui devra faire des recommandations sur un sujet cher à mon coeur: les web services des SIGB.

C’est indispensable pour deux choses:

• une bonne intégration dans l’environnement web global de l’institution (voir son compte lecteur et prolonger un livre depuis le web de l’institution sans aller dans l’opac)
• construire une interface de recherche spécifique, séparée de l’outil de gestion SIGB

Le groupe a un wiki, et les participants les plus avancés, en l’espèce NCSU, ont un prototype en ligne pour les premiers web services.

Les WS envisagés relèvent de quelques catégories générales.

L’aggrégation de données. Les OPACs modernes fonctionnent de plus en plus sur le modèle de la synchronisation régulière en batch des données depuis le SIGB vers un “outil de découverte” – l’interface publique – qui a sa propre base de données. Il faut donc définir le mode de communication entre les deux systèmes.

la recherche en temps réel: interroger, via une API XML, le SIGB sans passer par l’opac.

les services: id est, le compte lecteur, les réservations, prolongations, amendes, disponibilités, etc.

Le prototype de NCSU est intéressant. Pour la disponibilité, vous fournissez dans un service REST très simple un isbn, et le système vous renvoie du xml:

<?xml version="1.0" encoding="UTF-8"?>
<availabilityResponse xmlns="http://www.lib.ncsu.edu/catalogws/1.0">
 <item>
  <isbn>0125184050</isbn>
  <totalAvailable>3</totalAvailable>
  <totalUnavailable>0</totalUnavailable>
  <availableLibraryName>D.H. Hill Library</availableLibraryName>
  <catalogLink>http://www2.lib.ncsu.edu/catalog/?
N=0&Ntk=ISBN&Ntt=0125184050</catalogLink>
 </item>
</availabilityResponse>


Par rapport à ce que je connais par ailleurs (le X-Server d’Aleph, qui a l’avantage d’exister) c’est un progrès dans la mesure où le WS est ciblé. X-Server a tendance à recracher tout ce qu’il a, sans traitement (les tables Oracle), dans des fichiers xml énormes qui doivent servir à tout. Ici, on a un WS très simple ET très focalisé: juste la disponibilité.

Ceci étant, le potentiel le plus important réside certainement dans le passage sous forme d’API XML de l’agrégation des données: on aura alors une vraie coupure, propre, entre un outil de gestion (SIGB) et un outil de consultation publique.