Accueil Revue Numéro Article

Documentaliste-Sciences de l'Information

2014/3 (Vol. 51)

  • Pages : 80
  • DOI : 10.3917/docsi.513.0017
  • Éditeur : A.D.B.S.

ALERTES EMAIL - REVUE Documentaliste-Sciences de l'Information

Votre alerte a bien été prise en compte.

Vous recevrez un email à chaque nouvelle parution d'un numéro de cette revue.

Fermer

Article précédent Pages 17 - 18 Article suivant

1

Dans le web de données, une API [1][1] Application Programming Interface ou interface de ... permet à un système source d’exposer ses données à des fins d’exploitation par d’autres systèmes. Dans le monde du livre, les API ont été développées au départ par les principaux acteurs de la vente en ligne d’ouvrages et autres biens culturels afin de démultiplier les points de vente virtuels de leurs produits. Dans le monde des bibliothèques, la production d’API est plus rare. Les grandes bibliothèques (Bibliothèque du Congrès, Bibliothèque nationale de France, etc.) se sont longtemps contentées de mettre en place un serveur Z3950 ou éventuellement un serveur SRU [2][2] Le protocole d’échange de métadonnées SRU (Search/Retrieval... pour rendre interrogeables leurs données bibliographiques. Toutefois, le phénomène récent d’ouverture des données devrait favoriser la création d’API dans le monde de la documentation.

2

En dehors de l’interrogation par le protocole Z3950, il est impossible d’interroger le catalogue du Sudoc [3][3] Système universitaire de documentation pour une intégration sur une plate-forme extérieure. L’Abes ne donne l’accès à ses notices bibliographiques que par le biais des auteurs, ce qui limite la portée de la recherche. À défaut d’avoir créé une API Web d’interrogation de ses données, à l’instar du réseau équivalent Copac [4][4]  http://copac.ac.uk pour la Grande-Bretagne, l’Abes a lancé plusieurs API à travers des services web spécifiques [5][5]  http://m.abes.fr/Acces-direct-a/Pour-les-develop....

Mettre en place un contrôle qualité du catalogue

3

Lorsque l’on travaille dans un système de catalogage partagé tel que celui du Sudoc, l’un des objectifs est d’avoir le même niveau d’information dans le catalogue commun que dans le catalogue local où redescendent les notices, en particulier en ce qui concerne les données d’exemplaires. En effet, il faut éviter d’avoir un écart trop important d’information entre les deux niveaux afin d’assurer une information de qualité aux lecteurs. C’est ce que permettent plusieurs services web.

4

Les services isbn2ppn, ean2ppn, issn2ppn renvoient un identifiant de notice Sudoc à partir d’un numéro international de document. Ils permettent de voir s’il existe une notice bibliographique dans le Sudoc à partir d’un ISBN, EAN (code-barre) ou ISSN et de renvoyer l’identifiant (PPN) de la notice en question.

5

Le service Multiwhere affiche les localisations d’un document catalogué dans le Sudoc. Il permettra de voir si vous avez bien créé un exemplaire (ou une localisation) pour un ouvrage donné. Un différentiel d’information peut apparaître entre le catalogue local et celui du Sudoc si, lors d’un désherbage, vous n’avez pas répercuté l’information dans le catalogue commun. Une fois votre notice bibliographique redescendue du Sudoc, son identifiant (PPN) peut changer en raison de la fusion de plusieurs notices correspondant au même document. Le service web Merged fournira alors l’identifiant retenu, l’interrogation s’effectuant à partir d’un identifiant devenu obsolète.

6

L’ensemble de ces services peuvent être utilisés en amont d’une migration de données d’un système intégré de gestion de bibliothèque à un autre afin de repérer les anomalies (notices provenant du Sudoc mais non localisées dans ce dernier, notices Sudoc supprimées, modification des identifiants des notices suite à des fusions). Mais ils peuvent être exploités également dans l’interface professionnelle de votre SIGB (surtout si c’est une application full web) pour indiquer les anomalies éventuelles de chacune des notices de votre catalogue (illustration 1).

Illustration 1 - Exemple d’une notice avec anomalie dans le SIGB Koha du SCD de l’Université Paris-Sud Illustration 1

Enrichir un catalogue en ligne (Opac)

7

Les services web de l’Abes permettent également d’enrichir les données d’un catalogue en ligne en y intégrant en particulier les services Biblio, Sudoc en RDF et Multiwhere. En effet, en récupérant l’identifiant (PPN) d’un auteur situé dans la sous-zone Unimarc $3 des zones 700,701 et 702, il est possible de proposer un rebond pour afficher tous les titres référencés dans le Sudoc auxquels un auteur est lié. Le service Biblio (illustration 2) fournira les titres en question en fonction des rôles de l’auteur (auteur principal, préfacier, traducteur, directeur de thèse, éditeur scientifique, etc.).

Illustration 2 - Exemple d’interrogation dans le service Biblio+ avec le nom « Badinter » Illustration 2
8

Une fois ces titres obtenus, il s’agit d’afficher les notices grâce au service Sudoc en RDF et les localisations des documents avec le service Multiwhere. Le service Sudoc en RDF propose les données bibliographiques de base. Néanmoins, il s’agit d’une version appauvrie de la notice d’origine.

9

Ainsi, vous proposez à vos lecteurs un service utile sans sortir de l’environnement de votre Opac. Non seulement ils peuvent rebondir sur le nom d’un auteur afin de lister tous ses ouvrages dans votre catalogue en ligne, mais ils peuvent aussi accéder aux titres de cet auteur référencés dans le Sudoc ainsi qu’aux localisations dans les autres bibliothèques, si votre bibliothèque ne possède pas le document (illustration 3).

Illustration 3 - Exemple d’une notice d’un ouvrage avec la localisation des différents exemplaires Illustration 3

Créer une application

10

La mise à disposition des données d’un système quelconque par l’intermédiaire d’API permet de créer des applications ou des fonctionnalités que le site d’origine n’aurait pas nécessairement implémentées. Aujourd’hui, des sites internet reposent exclusivement sur des API. Toutefois, cela n’est pas sans comporter de risque car ces applications sont dépendantes de données externes et de services web dont on ne peut garantir la pérennité et parfois le bon fonctionnement.

11

L’outil en ligne DoMyBiblio édite de manière automatisée des listes bibliographiques à partir des donnés du catalogue du Sudoc. Il s’agit de saisir dans un formulaire une liste d’ISBN ou ISSN, ou encore une liste de PPN pour produire la bibliographie souhaitée. Cet outil exploite plusieurs services web de l’Abes : isbn2ppn, issn2ppn, Sudoc en RDF. DoMyBiblio permet également d’agréger d’autres données (données locales relatives aux exemplaires par exemple) à celles du Sudoc.

Créer une API à partir d’autres API

12

Élaborer des API à partir de plusieurs API provenant ou pas du même site/système d’origine, cela se pratique déjà dans le domaine de la musique [6][6] Par exemple The Echo Nest, http://the.echonest.com.... Il s’agit de fournir des métadonnées provenant de multiples sources à travers une nouvelle API, elle-même créée par l’exploitation de plusieurs autres. UnivDoc est une interface d’interrogation des données du Sudoc reposant sur les services web de l’Abes [7][7]  http://domybiblio.net/search/ . Ce système propose désormais une API de recherche agrégeant elle-même plusieurs autres API. Ainsi, les résultats renvoyés fusionnent les données des services Sudoc en RDF et Multiwhere. Dans le cas de recherche portant sur l’ISSN, les résultats proposés comportent également des données provenant de la base JournalTOCs référençant plus de 24 000 revues [8][8]  www.journaltocs.ac.uk . Ces données agrégées fournissent alors les derniers articles parus ainsi que les liens vers les textes en ligne.

13

Les données des catalogues des bibliothèques constituent une importante source pour la création d’applications et API d’agrégation de métadonnées. Toutefois, les réalisations dans ce domaine sont plutôt rares (data.bnf.fr) et se limitent aux seules données de l’établissement en question. L’un des enjeux du web de données est de créer des services agrégeant les données de plusieurs sources sur un sujet ou un auteur donné.

Notes

[1]

Application Programming Interface ou interface de programmation

[2]

Le protocole d’échange de métadonnées SRU (Search/Retrieval via URL) est l’équivalent fonctionnel du protocole Z39.50 mais appliqué aux standards technologiques du Web (protocole http et format XML).

[3]

Système universitaire de documentation

[6]

Par exemple The Echo Nest, http://the.echonest.com

Résumé

Français

[Technique] À quoi peuvent bien servir les API ? Elles permettent notamment, à l’instar de celles de l’Agence bibliographique de l’enseignement supérieur (Abes), de contrôler la qualité d’un catalogue, de l’enrichir, de créer une application ou encore de créer une API à partir d’autres API.

Plan de l'article

  1. Mettre en place un contrôle qualité du catalogue
  2. Enrichir un catalogue en ligne (Opac)
  3. Créer une application
  4. Créer une API à partir d’autres API

Article précédent Pages 17 - 18 Article suivant
© 2010-2017 Cairn.info