Le travail d’un éditeur, selon Hugh McGuire

Hugh vient de me donner son accord, et je l’en remercie,  pour que je publie la traduction que j’ai faite de son article, « A Publisher’s Job Is to Provide a Good API for Books » paru hier sur le blog « transforming publishing ».

Le travail d’un éditeur, c’est de fournir de bonnes APIs pour ses livres.

par Hugh McGuire Voici une affirmation radicale : Le travail d’un éditeur, c’est de fournir de bonne APIs pour ses livres. Maintenant que presque tous les livres existent en version numérique, les bons éditeurs du futur sont ceux qui fourniront de bonnes APIs. Dans cet article, je vais explorer – pourquoi je considère que les éditeurs doivent fournir de bonnes APIs – pourquoi c’est vraiment plus simple et moins effrayant que ce que vous pourriez penser. – pourquoi le bon vieil index pourrait être le point de départ des APIs de livres.

Qu’est-ce qu’une API ?

Une API c’est un ensemble d’outils/protocoles qui permettent à différents éléments logiciels de communiquer les uns avec les autres, sous certaines conditions. Comme l’indique Terry Jones : “Tout comme une interface utilisateur donne à des humains accès à l’information, une API donne accès à cette information aux logiciels.” Voici quelques exemples d’APIs avec lesquelles vous êtes déjà probablement entrés en interaction : –  Si un jour vous avez  indiqué avoir aimé un site dans Facebook, vous avez utilisé une API –  Si vous utilisez une application mobile ou un logiciel dédié pour lire et poster sur Twitter, vous utilisez l’API de Twitter –  Si vous avez déjà payé quelque chose avec Paypal,vous avez utilisé une API –  Si vous avez utilisé une application vous montrant une carte, vous avez utilisé une API. Il existe une autre manière de se représenter une API : une API permet à un service d’utiliser les données d’un autre service, selon des modalités bien définies.

Quel rapport avec les livres ?

Quel rapport avec les livres ? Les livres évoquent des émotions, inspirent des réflexions, contiennent et véhiculent des idées. Mais ils contiennent aussi de l’information (“data”). Ils sont, si vous préférez, faits de données. Une photo numérique, un film que vous regardez en streaming, un mp3 que vous écoutez sur votre iPod : ce sont des objets numériques faits de 0 et de 1, ils sont représentés comme des données. Nous y accédons grâce à la technologie. Les livres, et spécialement les livres numériques, sont également faits de données. De 0 et de 1, mais aussi, en fait, de HTML. Si nous commençons à réfléchir aux livres en tant que données, alors le rôle traditionnel de l’éditeur commence à ressembler au rôle d’un fournisseur d’API : le rôle d’un éditeur est de gérer la manière et les circonstances selon lesquelles les gens (lecteurs) et certains services ( librairies, bibliothèques, autres ?) accèdent aux livres (données). Nous savons à quoi ressemble ce job dans le vieux monde du papier et des magasins en dur, et nous sommes presque sûrs de bien le comprendre également dans le monde de l’EPUB et du Kindle. Mais, alors que nous entrons dans un monde où le numérique va être prééminent, les éditeurs pourraient, et bientôt devront, commencer à réfléchir à leurs APIs- d’une manière qui va bien au delà du simple “envoyons nos livres aux libraires”. (Rassurez-vous,  je vais vous indiquer plus loin pourquoi cela ne sera pas trop inquiétant.)

Que fait un éditeur ?

Voici une définition historique d’un éditeur : Éditeur (n.m.) milieu du 15è s., “quelqu’un qui fait une annonce publique, nom de celui qui publie, (v.), La définition suivante :  “celui dont le travail consiste à mettre en vente des livres, des périodiques, des gravures etc.” date, elle, de 1740. (Source: the Online Etymology Dictionary). Le travail d’un éditeur, c’est de rendre publique l’œuvre créée par les auteurs, et, couramment, mais pas toujours, de monétiser ce travail. Ce n’est pas un secret : le numérique change l’environnement dans lequel les éditeurs exercent leur travail. Les librairies physiques sont en voie de disparition, les ventes en ligne augmentent, et les barrières à la publication, spécialement en ce qui concerne les livres numériques, ont déjà disparu. Dans ce monde où l’offre de livres explose, et où l’espace de vente physique des livres diminue, le travail qui consiste à “rendre public” commence à ressembler à quelque chose de vraiment différent. Quelques un des mécanismes selon lesquels les éditeurs atteignent leur but de “rendre public” des livres aux lecteurs et de les monétiser (à savoir : la production, la distribution et la vente) sont aujourd’hui accessibles aux auteurs eux-mêmes. Si les auteurs auto-édités peuvent faire de nombreuses choses que les éditeurs ont l’habitude de faire, alors trouver de nouvelles et de meilleures façons de “rendre public” les textes est ce qui va séparer les bons éditeurs des mauvais à l’avenir. Les meilleurs seront ceux avec qui les auteurs auront envie de travailler.Et un avantage que les éditeurs possèdent, et personne d’autre (même pas Amazon), c’est une connaissance précise du contexte et du contenu de leurs livres. Les éditeurs ont choisi leurs livres, les ont édités, corrigés, leur ont donné forme… Ils connaissent leurs livres de fond en comble. Cette connaissance devrait permettre aux éditeurs de mieux agréger l’intérêt porté à leurs livres. Le problème avec ceci, alors même que les éditeurs possèdent toute cette connaissance au sujet de leurs livres, est qu’ils ne savent pas vraiment comment partager cette connaissance, comment l’utiliser comme un moyen effectif de porter leurs livres à la connaissance d’un large public. Mais ce serait très facile pour les éditeurs de devenir meilleurs à cet exercice.

De quoi les éditeurs ont-ils une connaissance précise, exactement ?

Les livres peuvent être décrits de différentes manières : par leur couverture, leur nom d’auteur, leur titre, la liste de leurs chapitres, une description du livre. C’est ce que vous pourriez appeler les “métadonnées” ou bien “les informations que l’on communique aux libraires”. AAA l’intérieur du livre nous avons des mots et des phrases, peut-être quelques images. Et si vous regardez attentivement ces mots et ces phrases, vous pouvez définir un certain nombre de choses que vous trouvez dans ces phrases, telles que :
– des gens (véritables, ou personnages de fiction)
– des lieux (véritables ou de fiction)
– des époques, des dates.
Et il y a certaines autres choses que vous pourriez extraire :
– des concepts
– la référence à d’autres textes
– des citations de gens, de livres, d’articles, de films ou de chansons
– des exemples
Cette liste peut se prolonger encore et encore, et bien sûr dépend du genre de livre que vous produisez.

Et si je vous demandais de construire un index plutôt qu’une API ?

Si vous regardez la liste qui précède, particulièrement si vous produisez non pas de la fiction mais des livres scolaires ou des documents, vous êtes en train de hocher la tête et de dire : « … oui, c’est bien le genre de choses que nous mettons dans un index. »Et vous avez raison : un index est une sorte de “carte de ce qui se trouve à l’intérieur de votre livre, et de comment le trouver”. Un index, dans un livre papier traditionnel, est un outil fantastique pour savoir quel genre de choses se trouve dans un livre. Cela ne demande pas un gros effort de transformer un index lisible par un être humain en un index lisible par un ordinateur, ce qui en fait, plus ou moins, une API. (C’est ainsi que fonctionnent les moteurs de recherche : ils “indexent” chaque mot d’une page HTML, et chaque page d’un site, et ils fournissent une API qui permet aux gens et aux programmes de trouver des choses.)

Dans le cas des livres imprimés, la manière habituelle d’indexer un livre est de dresser la liste de ce qui vous semble important (les gens, les lieux, les dates, les références, les concepts etc.) et d’indiquer au lecteur à quelle page il pourra retrouver ces éléments. Vous imprimez cette liste et les références de pages et vous l’ajoutez à la fin de votre livre. Dans le cas des livres numériques, un (bon) index fera quelque chose de tout à fait différent : il listera les gens, les places, les concepts etc… et il les fera pointer directement vers l’endroit où ces items apparaissent dans le texte, via un lien, car les numéros de page n’ont pas beaucoup de sens pour les livres numériques. Donc, dans un livre numérique, qui, après tout n’est rien d’autre qu’une série de fichiers HTML avec quelques petits trucs en plus, une entrée d’index est associée à une ancre située à l’intérieur du fichier HTML, là où l’entrée apparait.   Ainsi, vous avez un texte qui dit  :

et le balisage HTML de la page, qui vous permet de lier votre fichier d’index est :

À la fin de votre livre numérique, qui possède une liste correspondante d’items reliés à votre ancre dans le corps du texte qui ressemble à ça :
Le fichier HTML/page sera une liste de liens qui pointent vers l’intérieur de votre livre là où apparaissent les entrée de votre index. Ajoutez un peu de données sémantiques, remuez, et vous vous êtes dotés d’une API – ou du moins une carte à partir de laquelle bâtir votre API. Si au lieu de simplement faire un lien vers une ancre au niveau de votre index, vous passez un peu de temps supplémentaire pour ajouter quelques données, vous pourriez faire quelque chose comme ceci, qui spécifie qu’à cet endroit précis du texte, vous avez défini une personne nommée John Smith
et vous pourrez également mentionner le fait qu’un élément du texte est un lieu de la manière suivante :
Et plus loin, vous pourrez tagger des concepts comme ceci :

Si vous voulez être encore plus sympa, vous pourriez réaliser ce balisage sémantique en vous basant sur des schémas comme schema.org ou bien microformats. Cela vous permettrait, à vous et à d’autres éditeurs, de standardiser la manière dont vous parlez des “choses qui figurent dans les livres.” Maintenant, si vous faites ça avec votre livre complet, ou bien si vous le faites faire par quelqu’un d’autre, vous pourrez ensuite : a) générer un index (que vous auriez fait de toute manière) mais, et c’est bien plus intéressant, vous pourriez b) générer un index intelligent qui sait non seulement où apparaissent toutes les instances du terme “John Smith” mais : – où apparaissent tous les gens – où sont toutes les instances de gens nommés John – où apparaissent toutes les instances des gens nommés Smith – que “ma chère Granny Smith” est une personne et que “ma délicieuse Granny Smith” est une pomme Et maintenant, en lieu et place d’un simple index, vous avez une carte sémantique complète de votre livre, une carte qui a été juste un petit peu plus difficile à produire qu’un index standard que vous auriez réalisé de toute manière. Et alors ? Avec une telle carte sémantique vous avez l’amorce d’une API incroyablement puissante. Si en plus d’avoir une carte sémantique… vous avez également votre livre disponibles en ligne (derrière un accès payant ou non) cela signifie que vous pouvez rendre cette API/carte sémantique  accessible au monde enter, (gratuitement, ou bien à certaines conditions commerciales) et dire : je vous en prie, trouvez de merveilleuses idées pour utiliser le contenu de mon merveilleux livre !

Qu’est-ce que le monde va bien pouvoir faire avec votre API ?

Voici quelques unes des choses que vous aimeriez peut-être que les autres (ou bien vous mêmes) réalisent avec votre API : – extraire une liste des personnages dans le livre, et donner à chacun d’entre eux une petite biographie. Rassembler ces biographies dans un “guide biographique”. – Extraire une liste de localisations dans le livre et les placer sur une carte – Extraire les 500 mots autour de chaque apparition du concept “existentialisme” … parmi tous les livres édités par des éditeurs qui ont rendu disponibles leur carte sémantique, et trier par décennie, influence, ou nationalité de l’auteur – Construire une frise chronologique indiquant où se trouvent les différents personnages à différentes périodes du récit. – Faire pointer cette frise chronologique vers une carte – Construire un outil de navigation permettant aux utilisateurs d’explorer un livre par ses personnages, ses lieux, ses dates, ses concepts. Vous pourrez également vouloir publier cette carte sémantique sur le web, ainsi Google et d’autres moteurs de recherche auront une compréhension détaillée de ce qu’il y a dans votre livre, et ainsi lorsque des gens rechercheront un type précis d’information qui apparaît à la page 119 de votre livre, le moteur sera capable de pointer vers chez vous. Il y a tant d’ « et cetera” ici, et nous venons à peine de commencer.  Nous pouvons déjà trouver quelques petits reflets de tout cela : – Small Demons extrait des gens/lieux/choses via une API, il demande aux éditeurs leurs fichiers EPUB afin de pouvoir parcourir les fichiers, et ensuite afficher les produits, les autres livres, les films et les musiques trouvés à l’intérieur des livres. – Dracula Dissected s’appuie sur le texte de Bram Soker, et permet d’y accéder par personnages, dates, lieux et vous pouvez ainsi explorer le livre de différentes manières. – Pearson’s FT Press API vous permet d’extraire de l’information de certains EPUBS et de faire diverses choses avec. – Wordnik.com extrait des phrases de définition de livres publiés par Simon and Schuster et les utilise comme phrases exemples pour les entrées d’un dictionnaire. Nous n’en sommes qu’aux balbutiements, aux premiers exemples. Nous n’avons encore rien vu. Nous allons en voir beaucoup plus parce que le travail d’un éditeur est de “rendre public” et qu’une API est précisément faite pour mettre les données en capacité d’être rendues publiques. C’est exactement ce à quoi elles servent. Nous allons en voir plus parce qu’il apparaît que faire des APIs pour les livres est quelque chose de facile.

Et ça va arriver comment ?

Des outils comme PressBooks, qui est un outil de production de livres nativement web, rend très simple l’ajout d’une indexation sémantique, ou bien vous laisse le faire à la main; où, plus efficacement, vous permet de combiner les deux. Sélectionner le texte que vous souhaitez ajouter à votre fichier d’index, ajoutez les métadonnées qui vont bien (est-ce une personne, un concept ?) et appuyez sur “go”. Le défi, c’est de faire un bon  fichier d’index, bien sûr, avec de bonnes métadonnées et selon un bon schéma. Nous savons bien maintenant faire des livres numériques. Voyons maintenant comment traiter la manière dont on peut relier les livres entre eux via des APIs. Y arriver n’est pas si difficile : la clé pour pour réaliser ces fameuses APIs , c’est ce bon vieil index. (Merci à Brian O’Leary, Laura Dawson, Terry Jones, Erin McKean, et Dac Chartrand, qui m’ont aidé à améliorer la première version de cet article.)