Titre : édition libre.
Intervenants :

• Christophe Masutti, Framasoft, coordonnateur et auteur du livre « Richard Stallman et la révolution du logiciel libre » ;
• Chloé Girard, du projet La Poule ou l’Œuf ;
• Julie Wojcicki et Mathias Valais-Gérard, du projet Scenari.

http://radio2010.rmll.info/ep/edition-libre

Durée : 40 minutes

Une amicale dynamique Scénari vs La Poule ou l’Oeuf qui permet de différencier les objectifs et approches des deux chaînes éditoriales ainsi que d’évoquer les problématiques actuelles de l’édition, des exploitations papier et électroniques des livres, etc.

Et merci à la radio des RMLL qui chaque année offre aux intervenants du Libre de présenter leur travail et de croiser leurs idées sous cette forme éminemment conviviale et baladeuse.

De l’un des aspects de la plus-value du livre Web… (4min05s)

• surlignement,
• création d’un index de lecture,
• insertion de notes simples à l’intérieur d’un paragraphe,
• insertion de notes complexes à la suite d’un paragraphe,
• extraction de citations et de leurs références (url, métadonnées).

La vidéo ci-dessous présente les outils d’annotation liés aux livres (Html et Html zippé) produits avec La Poule ou l’Œuf une fois que ceux-ci ont été clos par leur auteur (éditeur).

À venir
Nous travaillons sur l’extraction de ces notes de lecture pour la constitution de fiches de lecture réexploitables (en ODT) et sur leur interfacage avec une plateforme Web de partage de notes. Ces outils ont présentés ici dans un reader permettant de manipuler, en local ou en ligne, les livres Html zippés issus du logiciel. Une extension pour Firefox permet d’en faire autant depuis le navigateur, l’avantage de ce petit reader multi-plateformes étant de pouvoir le “designer” à ses propres couleurs, logos, etc, et d’offrir une interface réservée à son catalogue, sans barres d’adresse et autres marque-pages…

Reader, extension FireFox et outils d’annotation seront livrés avec la prochaine mise à jour de La Poule ou l’Œuf

Jusqu’à maintenant un document informatique ressemblait grosso-modo à un fichier, toujours offert − accessible − sous la même forme. Le Web est en train de transformer cette évidence. Le concept d’objet Web n’est pas encore bien formalisé mais les changements importants dans le partage et l’exploitation documentaire nous obligent à réviser nos idées sur le sujet.

Prenons un exemple simple pour montrer le changement de forme qu’ont subi les documents en passant sur le Web. La méthode la plus « simple » pour lire une vidéo, jusqu’à récemment, était de la télécharger puis de la lire avec un logiciel approprié. Des portails comme Dailymotion et Youtube offrent en plus du visionnage, à l’intérieur du navigateur, un ensemble de données supplémentaires. On trouve tags, channels, notes, commentaires, quelques méta-données (durée, posteur… ) Bref il ne s’agit déjà plus un document comme on le connaissait.

Ce qui caractérise le plus un objet Web, en plus des informations supplémentaires ou méta-données, ce sont les services qui peuvent lui être rattachés du fait de la distinction des informations qui le constituent, sans remise en cause de son unité.

Les services de communication :

La façon la plus évidente de rentrer en interaction avec un objet Web c’est la « publication web » faite principalement de pages écrites en Html. Mais on peut imaginer d’autres formats plus appropriés dans d’autres situations d’utilisations. Ici le format, prend un sens particulier par rapport à notre utilisation courante. Il devient synonyme de « méthode de communication » et implique d’utiliser des formats/protocoles ouverts.
En plus des humains et des machines qui ne cessent d’indexer, répertorier, trier… ce sont nos méthodes de connexion au Net qui ne cessent, elles aussi, de s’accroître : mobiles, netbook, gps, reader… Un ojet Web a ainsi l’obligation de la polymorphie pour offrir des services pour chacun des utilisateurs, machines comprises, avec leurs propres besoins.

Dans l’application Web La Poule ou l’ŒUF , faite pour fabriquer des objets Web-livres, nous essayons de reprendre cette logique. La polymorphie commence ici avec la construction de l’objet en facilitant l’importation depuis d’autres formats (texte « wikiisé », ODT, et dans un avenir proche Latex et epub) mais aussi avce la communication extérieure avec le PDF (pour créer une version papier), LaTeX, ODT, TEI, epub, DocBook et txt.

Des services spécialisés :

La demande peut être plus précise et porter sur certains points de l’objet Web. Au-delà des méta-données on peut ne vouloir que certains morceaux, certaines parties. Dans le cadre des objets Web-livres il peut s’agir uniquement de la bibliographie, de la table des matières, de l’index, de l’historique d’un chapitre, des notes de(s) l’auteur(s), d’un résumé, d’une dimension particulière, des noms propres dans le texte ou tout élément qui aura été marqué sémantiquement etc.

Le concept d’objet Web permet de clarifier la forme que prend le « document » sur Internet. Mais il reste beaucoup à faire et nous devons nous inspirer des métaphores mises au point dans le monde de la programmation orientée objet. Dans ce cadre les objets ont la possibilités de s’adjoindre « facilement » de nouvelles propriétés, de nouvelles fonctions. Nous n’en sommes qu’aux premierx balbutiement de ce concept promis à un grand avenir.

Il existe typiquement trois modèles différents, divisés en deux catégories, de fabrication de contenu texte dirigé vers l’édition:

1. Le modèle appplicatif qui se présente sous deux formes possibles: l’application CLIENT et l’application WEB.
   Dans les deux cas, la numérisation des données en entrée est pensée pour être le plus transformable possible, pour pouvoir jouer avec les options de création de contenu et produire les formats attendus ou à venir pour répondre à un ou des besoins spécifiques. Dans la plupart des cas personne ne se soucie de la façon dont les contenus sont créés. L’accent est mis sur la finesse et l’évolutivité de la création et de ses outils. Seuls importent ensuite les formats de sortie, non plus pour création mais pour diffusion, exploitation, conservation. Savez-vous comment sont numérisés les contenus dans Indesign ou QuarkXPress? Non, et cela ne vous pose aucun problème.
2. Vient ensuite le modèle “chaîne” de formats” avec par exemple la plate-forme CybersDocs, pour la publication des thèses en ligne, ou O’Reilly avec son schéma XML Docbook.Selon ce modèle, un format produit pour répondre à un besoin sert de base pour la production d’un autre format destiné à répondre à un autre besoin. La chaîne implique que les transformations vont se suivre les unes après les autres.

Devant la recrudescence des discours encensant les “chaînes XML” nous voulons nous arrêter sur la différence logique qui sépare ces deux approches et inciter à retourner vers le modèle applicatif.

Deux idées erronées, qui n’en sont qu’une, poussent à se tourner vers le modèle de la chaîne XML:

1. La première idée est qu’un format est séparable du processus auquel il appartient: In, Out et média/ outils associés.
2. La seconde consiste à penser que le passage d’un format à un autre (modèle chaîne) ne représente pas une perte dans le processus d’édition, de diffusion et d’exploitation des contenus édités. Le corollaire étant qu’il existe un BON format (global, universel, intemporel) en entrée pour toutes les sorties.

Exemple de la chaîne CyberDocs

Prenons comme exemple la chaîne CyberDocs, plate-forme de conversion principalement maintenue à travers le projet Cyberthèses:

Le module de conversion de la plate-forme Cyberdocs vise à automatiser un processus de conversion depuis un format traitement de texte vers un document structuré en format XML, selon la DTD TEI Lite. Une telle opération consiste donc à identifier le plus de structure possible dans le document original pour rendre le document XML le plus riche possible.

[...]

Le module de conversion de la plate-forme Cyberdocs ne se contente pas de produire ce

document XML de référence. En effet, une fois celui-ci obtenu, le module peut produire des versions du document prêt à une publication statique, en format HTML, XHTML ou PDF. De plus, le module va préparer un ensemble de documents qui alimenteront le module de publication pour rendre l’interface de consultation encore plus riche.(Documentation PDF, p.26)

Les objectifs:

1. production d’un document sémantiquement structuré pour un archivage pérenne (TEI Lite),
2. publication “statique” (HTML, XHTML, PDF)
3. recherches documentaires précises à l’intérieur d’un document ou dans une collection de documents publiés.

Le IN: dans ce processus est déterminé par la production des auteurs dans leur logiciel bureautique de traitement de texte, par une habitude, ce qui est parfaitement légitime. C’est la contrainte de départ, du ODT.

Un OUT primaire:

• TEI Lite comme format sémantiquement structuré, pour archivage pérenne (dont on sous-entend par ailleurs qu’il serait “dynamique”).

Les OUTs secondaires (issus de TEI Lite):

• Fiche de métadonnées,
• HTML statique destiné à l’affichage en flux et à produire un fichier Html de transport.
• PDF destiné à l’impression.

Analyse de la chaîne CyberDocs

Nous avons plusieurs chaînes du type: ODT-> TEI Lite -> Format X (Html, PDF, XML métadonnées)

1. 1ère étape: passage ODT-TEI Lite
   • la feuille de style qui prépare le document ODT à cette transformation exclut de l’importation un certain nombre d’éléments: maths, dessins, graphiques, xlink, formulaires…
   • la présence de cette feuille de style implique que l’on ne peut importer du ODT dans cette chaîne QUE s’il a été structuré à cette fin, il ne s’agit plus d’une importation de ODT comme format de “traitement de texte” mais uniquement comme format “ODT destiné à être validé en tant que TEI Lite”. Si votre thèse n’a pas été produite avec cette feuille de style son importation demandera un travail de préparation important.

Cette première étape, qui pallie à l’absence de structuration sémantique “littéraire” pour laquelle ODT n’est pas fait, impose donc une perte en universalité du processus.

2. 2nde étape: Passage TEI Lite-Html et TEI Lite-PDF

Le document “XML de référence”, l’axe de la chaîne est TEI Lite, un schéma XML (vocabulaire et grammaire) développé pour l’échange des données textuelles, notamment pour les sciences humaines et les études sur les textes littéraires. Du fait de son orientation “structuration sémantique” et de son mode de production hors ligne il convient à la production de documents statiques de stockage et d’interrogation ainsi que de fiches de métadonnées riches.

C’est à partir de ce document que CyberDocs cherche à produire du HTML et du PDF, à répondre aux besoins “affichage et diffusion en flux dynamique en réseau” et “structuration typographique destinée à l’impression”. C’est oublier que TEI Lite répond déjà à une intention précise et est presque la fin d’un processus, que nous appellerons “structuration littéraire concertée pour échange de données textuelles”. Cela revient à vouloir utiliser le OUT d’un processus comme IN dans des processus qui ne lui correspondent pas et qu’en conséquence il appauvrit.

La structure TEI Lite permet de répondre en partie aux besoins de ces deux processus. CyberDocs produit bel et bien des thèses en Html (statique, enfermé dans des cadres (frameset), peu ou pas accessible aux handicapés ou aux moteurs de recherche) et en Pdf (et pourrait en produire des versions plus riches à partir de la TEI native) .

En partant de TEI Lite statique CyberDocs renonce cependant à la part collaborative du Html puisque les contenus de production ne sont ni en ligne ni associés à des outils pouvant les rendre dynamiques. Cet aspect du Web n’est sans doute pas un argument de taille pour les universités et les chercheurs dont le travail tient encore à rester “encapsulé” avant publication officielle. Mais CyberDocs renonce également à l’intégration des contenus au Web pour une exploitation raffinée des connaissances après publication (Web services). À l’exception du catalogage et de la publication de fiches de métadonnées (localisation) les contenus ne peuvent être extraits et/ou réutilisés de façon dynamique dans d’autres ouvrages, analyses, hyper indexations, etc.

Conclusion

La première étape de la chaîne nous fait perdre en universalité, la seconde en fonctionnalités.

Qu’est ce qui même au choix d’une telle chaîne de formats?

1. L’idée d’un format ad hoc
   • TEI, TEI Lite, Docbook sont des formats de stockage et d’interrogation exprimant chacun des besoins spécifiques…,
   • ODT pour une lecture sur un bureau et sa qualité de traitement de texte Wysiwyg en relation avec l’imprimante,
   • HTML pour une présentation en flux…
   • PDF pour une impression papier…

Cette pauvreté relative (perte de l’universalité de production des contenus et staticité de la sortie Web en particulier) est ici inévitable parce que l’on fait du résultat de l’objectif 1 (TEI Lite statique hors ligne) le IN des objectifs 2 et 3.

Ce choix provient de l’idée selon laquelle un format, et notamment le XML, est une information qui peut toujours être transformée. Or, un format, quel qu’il soit, est une réponse à un besoin. Il est engagé dans un processus qui a transformé les données…. C’est le vieux principe de McLuhan, “le message est le médium”. Il n’y a pas de transmission linéaire de l’information. D’ailleurs il n’y pas d’information au sens de message portant à lui seul un sens univoque et par conséquent compris par tous de la même façon quel que soit le contexte. Il faut donc dans un premier temps oublier cette quête quasi mystique du BON format (global, universel, intemporel).

Dans une chaîne il y a orientation à chaque étape, orientation irréversible. Cette orientation peut être de grande qualité dans un objectif donné:

Pour autant, faire un passage horizontal d’un format vers un autre fait toujours prendre le risque d’une perte, quoi qu’il en soit de la qualité de la feuille de transformation. La perte tient dans la négligence des différences d’objectif que sous-tendent chacun des formats, le processus auquel ils appartiennent et les outils qui y sont associés. Un format est toujours une réponse à un objectif. Ou plus exactement format et objectif fusionnent.

2. La séparation format/processus

L’autre idée qu’il faut ici démonter est celle selon laquelle un format est séparable du processus auquel il appartient: In, Out, et média, outils associés.

Le XML est partout présenté comme LE format qui offre structuration sémantique, capacité de transformation illimitée vers une multitude d’autres formats, garant de la plus grande pérennité, et qui transporte donc toute l’information nécessaire sur un contenu donné pour son utilisation actuelle et future dans tous les contextes. N’en déplaise aux “experts”, c’est une erreur.

D’une part, le xml n’est pas un format. C’est un niveau de “numérisation” règlementé, un langage de balisage générique destiné à ranger des données textuelles, et dont le vocabulaire et la grammaire ne sont pas définis a priori. Lorsque l’on détermine des règles pour le balisage, des grammaires, celles-ci s’expriment en des schémas (DTDpar exemple), qui permettent notamment de valider automatiquement un document sur sa conformité à ce modèle. Le xml est une technique et c’est quand il est associé à un schéma qu’il devient un format! Donc, dire que le XML garantit pérennité, capacité de transformation universelle, revient à dire que l’encodage en O et 1 garantit pérennité, capacité de transformation, etc. Autant ne rien dire.

D’autre part lorsqu’il est associé à une DTD, et devient un format, le XML est déjà engagé dans un processus spécifique, une réponse à un besoin, lié à des outils (scripts), à des modes de présentation (supports de lecture) et pour lequel cette DTD a été élaborée. Il ne peut plus (ni ne dois) dès lors être appelé à répondre à tous les besoins.

Comme pour les autres formats (non xml), pas plus TEI que Docbook, xhtml, mathml, svg, etc, ne peuvent répondre à tous les besoins. Aucun d’entre eux ne peut constituer un bon IN pour tous les autres processus d’édition: Web, papier, eBook, Mobile…

Comment sortir alors de cette recherche du format ad hoc, répondre au besoin de pérennité et à la peur de la multiplication des sorties?

Revenir à la logique applicative:

• mieux regarder l’ensemble des composants, outils de fabrication, formats d’exploitation, d’utilisation, et ainsi penser en terme de processus et non pas d’objet,
• s’assurer de la finesse et de l’évolutivité des outils de création: pour cela ne pas chercher un format de données “brutes” normé mais au contraire hybridable avec d’autres techniques (comme LaTeX et XML) qui créent une donnée “brute” la plus transformable possible. Déhiérarchiser les processus d’édition.
• à partir de cette donnée transformable, non normée, penser publication en étoile, chaque branche correspondant à un processus (une intention) donné. Il ne faut pas d’axe majeur, de “format de référence”.
• s’assurer de l’accessibilité, de l’ouverture des formats et langages utilisés afin qu’ils puissent évoluer en fonction des nouveaux besoins, machines, lecteurs…
• ne pas oublier que tous les OUT/exploitation/supports de lecture à venir ne peuvent être prévus.

__________________

Schéma (image cliquable pour une meilleure lecture) : Édition numérique à partir d’une application Web comparée à une “chaîne de formats”.

Attention!

Les Complexes mettra son serveur à jour ce lundi 4 août.

Inspirés auteurs  de livres dans La Poule ou l’Oeuf, lecteurs assidus de notre Blog, exégètes du Manuel de l’utilisateur et furieux fureteurs du Forum ne craignez rien, David Dauvergne est un AS, cela ne sera pas long!

Serveur mis à jour !!

Une fois définies les balises qui distinguent le livre comme mode de pensée (structure, clôture, intégrité, planification, malléabilité, références) nous pensons qu’il est indispensable d’offrir aux auteurs, aux éditeurs, aux lecteurs, c’est à dire au livre, l’intégration dans le Web.

Et nous parlons bien d’intégration dans le Web, par opposition à la transition au travers du Web. Dans le premier cas nous parlons d’un Web comme flux de contenus structurés au gré des besoins et non seulement d’un lieu dans lequel transiteraient des contenus statiques.

Un flux ne menace en aucun cas l’intégrité des contenus, en lecture seule. C’est la réponse à une demande de service, à un besoin, à un projet.

A titre d’exemple un flux RSS, c’est à dire un fichier XML construit à partir d’éléments choisis, ne met pas en danger l’intégrité d’un Blog. C’est un service que rend l’application qui sous-tend le Blog.

Il ne s’agit pas d’une personnalisation mais d’une sélection et d’une mise à disposition de tout ou parties du livre selon une logique différente, pour répondre à un besoin donné. Une table des matières, un index, une liste des figures ou un niveau “débutant” ne menacent pas l’intégrité d’un livre. Ce sont des sélections qui informent le lecteur, le chercheur, le bibliothécaire et l’auteur! Informent au sens de “donnent des renseignements” mais aussi au sens de “permettent à la pensée de prendre forme, d’articuler les idées d’une façon différente”.

Le livre doit pouvoir être pensé de la même façon comme un ensemble de contenus XML liés entre eux. Le flux principal est le livre entier, les contenus liés entre eux par le plan. Ce flux est publié ensuite en différents formats statiques de publication (Html, Pdf, etc.). Il répond au premier désir de l’auteur.

Mais on peut également décider d’exploiter cette source première pour créer d’autres flux:

• flux RSS;
• flux de telle ou telle balise structurelle ou sémantique, pour fournir à un bibliothécaire ou à un chercheur les données dont il a besoin: table des matières, notice bibliographique, liste des métaphores, nom des personnages et chapitres d’apparition;
• flux pour une lecture différentielle: imaginons un manuel d’informatique se présentant sous trois flux différents; “débutant”, “intermédiaire” et “avancé”. Ou un roman avec ses historiques de rédaction, un classique avec son édition commentée, un roman à plusieurs voix;
• un flux public, un flux privé;
• un ou des flux d’accessibilité aux handicapés;
• …

Les besoins restent à imaginer. Quels sont, quels seront ceux des auteurs, lecteurs, éditeurs, libraires ? Et avec quels objectifs? Partage, recherche, analyse, classification, information, collaboration, création… Quels qu’ils soient ils ne pourront évoluer mieux que dans le Web, lieu de rencontre inédit entre sources (intègres), projets et outils.