Go to content

AgrégationChimie

Récupérer des informations sur un livre à partir de l'ISBN

Les principes généraux

Pour créer une base de données de livres pour des besoins personnels, j'ai eu besoin de récupérer des méta-données à partir de différentes bases de données afin d'en faciliter la saisie. Mon but était d'avoir accès à un maximum de données de manières automatique afin de faciliter l'expérience utilisateur et éviter que les trois quarts des champs restent vide.

Pour cela, il a fallu identifier les informations qui m'intéressaient. J'ai donc essayé d'être complet sans être trop exigeant afin d'avoir une haute probabilité que tous les champs soient remplis. J'ai donc établi la liste suivante :

  • l'ISBN ;
  • le titre ;
  • les auteurs ;
  • la couverture ;
  • l'éditeur ;
  • l'année de parution ;
  • le nombre de pages ;
  • une courte description ;
  • l'identifiant google books ;
  • l'ASIN (identifiant amazon).

Pour moi, la couverture est très importante car elle permet d'identifier un livre de manière visuelle.

Sur le plan technique, j'ai codé l'ensemble avec PHP, et la librairie jQuery. Mes connaissances techniques étant limitées, surtout en javascript et le reste de mon site était déjà codé avec ces éléments (la partie SQL étant inutile ici). La possibilité de faire des requêtes asynchrones de javascript (AJAX) est en effet très intéressante.

Une fois les besoins identifiés, j'ai rapidement vu que consulter une seule base de donnée via une unique API n'allait probablement pas suffire. En effet, les livres de la collection combinent des livres anglo-saxons et français, sont plutôt réservés à un public de niche, et la date de parution peut remonter à plusieurs dizaines d'années. De plus, j'ai rapidement vu que Worldcat allait être la base la plus complète et la plus fiable, mais sans couverture, tandis qu'Amazon propose les couvertures, mais les données sont beaucoup moins fiables et Google books est un peu entre les deux. L'interrogation d'une unique base de donnée est abondamment traitée sur internet, cependant, les sujets sur l'interrogation de multiples bases pour combiner leurs puissances respectives ne sont pas légion.

Le code

Vous pouvez télécharger le code source. Il contient :

  • add_livres.html : La page html qui permet de lancer la requête ;
  • add_livres.js : le code javascript pour pour faire les requêtes AJAX, traiter la requête Google books, combiner les résultats, afficher le résultat final et les trois résultats intermédiaires -- il est possible ou non d'afficher l'URL des pages interrogées. Pour un nombre de requêtes illimité, il faut mettre votre clé pour l'API google (normalement, c'est mal car elle est visible par tous) ;
  • worldcat.php : le script pour faire la requête worldcat et l'analyser. Il faut mettre votre clé worldcat (il faut s'inscrire ici). (Attention, pour obtenir une clé worldcat, il faut avoir rempli votre nom lors de l'inscription, sinon il y a une erreur lors de la demande de clé) ;
  • amazon.php : le script amazon : il faut mettre votre clé publique, votre identifiant (sans passer par IAM !) et votre AssociateTag.

Le résultat

Voilà une page statique du résultat, le principe est de taper l'ISBN. Ensuite, via javascript, il est envoyé à trois bases de données avec des API différentes, et pour finir, je combine les trois résultats pour proposer l'ajout du livre avec tous les renseignements. Pour la qualité des informations, en général, je choisis worldcat pour les méta-données, Amazon pour la couverture et Google Books pour la description. Sur cet exemple, on voit bien que séparément, aucune base de donnée n'est capable de donner toutes les données requises mais qu'ensemble, elles donnent un résultat complet et cohérent.

Et voilà un exemple de page de type bibliothèque (2 Mo) avec environ 350 livres que l'on peut obtenir après avoir ajouté des livres dans notre base de données, le tout avec des micro-données suivant la syntaxe schema.org. L'ajout des livres m'a pris 2 soirées car je ne voulais pas automatiser le processus afin d'être sûr de la qualité des entrées que j'avais et car j'avais dépassé mon quota de requête en une journée sur WorldCat.

Les bases de données

Les livres concernés pour mon application sont des livres pour un concours de chimie, il y a donc des livres de cours, des livres en français ainsi que des livres en anglais. De plus la plupart de ces livres sont des livres "de niche" avec un faible tirage. Une seule base de donnée n'est pas suffisante pour avoir toutes les données voulues : soit le livre peut être manquant, soit il manque la couverture. J'ai donc commencé par l'API google books qui a été la plus simple à traiter. Ensuite, je me suis tourné vers la base de données de Worldcat, beaucoup plus complète que celle de Google. Pour finir, j'ai également pris l'API d'amazon pour les couvertures de livre. Les données sur Amazon sont moins fiables mais la base de donnée est également très complète.

L'API google books

Je suis parti du site code 18 pour avoir une base de script. Une fois que l'on a les paramètres pour faire une requête, il est facile de faire des requêtes. Google envoie un résultat sous forme JSON. Il a ensuite été simple de récupérer les données à partir du résultat, de plus, comme l'ISBN est un identifiant unique, on a généralement un unique résultat. Bref, ça a été super simple.

  • Les points positifs :
    • La simplicité de mise en œuvre ;
    • Les résultats directement en JSON donc facilement exploitable ;
    • Pas d'identifiants ou d'inscription nécessaire ;
    • Accepte les requêtes cross-domain (CORS) ;
    • Une description brève disponible pour leurs livres ;
    • Nombre de requête illimité si on prend une clé.
  • Les points négatifs :
    • La fiabilité des informations ;
    • Encore beaucoup de livres manquants.

L'API Worldcat

Pour l'API Worlcat, mon plus gros souci a été la non possibilité de faire des requêtes cross-domain. Du coup j'ai été bloqué pendant un certain temps à comprendre que CORS n'était pas activé par Worldcat et donc que je ne pouvais pas me contenter d'une requête en AJAX. En plus de cela, après avoir compris qu'il fallait un script php pour faire la requête, il a fallu comprendre comment la fonction simplexml_load_file convertit le fichier XML retourné en tableau.

  • Les points positifs :
    • La base de données très complète ;
    • La gratuité totale et l'esprit du libre ;
    • Les livres anglo-saxons ;
    • La documentation très complète sur le système MARC21 ;
    • La richesse des informations (collection, numéro de collection)
  • Les points négatifs :
    • N'accepte pas les requêtes cross-domain (CORS) donc oblige la création d'un script annexe ;
    • La non-uniformisation des données (mais c'est tout de même la base la plus homogène parmi les trois).
    • La clé ne dure qu'un an.

L'API d'amazon

Pour amazon, comme beaucoup de personnes l'utilise aussi, c'est très facile de trouver de l'aide, mais la soumission des requêtes est un peu plus technique, heureusement, je suis tombé sur cette page pour avoir l'obtention de la signature sans trop me casser la tête. Le plus compliqué est de s'y retrouver parmi les possibilités pour les identifiants, l'IAM inutile, la nécessité d'avoir aussi un compte affilié, bref, plus les petites tracasseries liées à la création de multiples comptes que des difficultés techniques.

  • Les points positifs :
    • Les couvertures de livre à gogo et dans toutes les dimensions ;
    • La base de données très complète ;
    • La documentation assez bien fournie ;
  • Les points négatifs :
    • Les informations qui sont en général de mauvaise qualité (auteurs en particulier)
    • Les tracasseries pratiques : la nécessité d'avoir un compte AWS, mais pas besoin d'IAM, mais d'avoir un compte affilié ;
    • Le côté commercial : la nécessité de donner son numéro de carte bleue pour un compte AWS même si c'est gratuit.
    • Le côté commercial une deuxième fois : la nécessité de faire des rétroliens publicitaires avec le compte "associates" pour qu'il reste ouvert.
    • La complexité pour avoir une signature qui marche.


Du synchrone et de l'asynchrone

Une fois les données récupérées via les différents canaux, il faut ensuite les compiler pour proposer une entrée complète. Mais... les requêtes AJAX étant asynchrones, il faut attendre qu'elles soient toutes finies avant de pouvoir les traiter. Ce problème est magnifiquement illustré par le gif animé ci-contre. Je me suis donc battu pour avoir un traitement asynchrone des données. J'ai d'abord cru que c'était un problème de closure, puis de callback, et au final, j'ai utilisé des deferred objects si j'ai bien compris. Heureusement, pour y voir un peu plus clair, je suis tombé sur cette page de Stackoverflow qui m'a permis de découvrir la magnifique fonction $.when() de jQuery.

Synchrone vs asyncrone

Conclusion

Ici, je vous ai présenté la preuve de la mise en œuvre des requêtes de méta-données. Bien évidemment, ensuite, il faut gérer l'ajout dans une base de données via SQL. J'ai également fait quelques améliorations dans mon code final :

  • J'ai transformé les différents données en champs cliquables afin de pouvoir faire de l'édition directe du résultat si nécessaire.
  • J'ai également ajouté une requête afin de savoir si le livre a déjà été entré dans la base de données afin d'éviter les doublons.
  • etc.
Pour finir, la limitation reste l'inhomogénéité des entrées. Il faut toujours corriger un peu pour éviter le principe du garbage in garbage out. Mais c'est inhérent à l'automatisation et le travail est grandement simplifié.

Go to top
Go up