Archives mensuelles : juillet 2006

Lodel — Logiciel d’édition électronique — Version 0.8 beta

PNG - 15 ko
Lodel 0.8 beta
Une cap­ture d’écran de l’interface de Lodel 0.8 beta.

L’équipe de déve­lop­pe­ment de Lodel, for­te­ment renou­ve­lée, vient d’annoncer la sor­tie de Lodel 0.8 beta. Comme son nom l’indique, cette ver­sion n’est pas des­ti­née à être uti­li­sée pour la pro­duc­tion de sites pro­fes­sion­nels, mais peut être mis en oeuvre pour des tests, des essais et des expé­ri­men­ta­tions. Les reports de bugs sont bien­ve­nus. Signa­lez les bugs sur la liste de dis­cus­sion lodel-​users ou lodel-​devel. Pour vous abon­ner à ces listes, allez sur Sour­ce­sup, espace uni­ver­si­taire d’hébergement de logi­ciels libres : http://​sour​ce​sup​.cru​.fr/​p​r​o​j​e​c​t​s​/​l​o​d​el/

Vous pou­vez la télé­char­ger à l’adresse sui­vante : http://​sour​ce​sup​.cru​.fr/​f​r​s​/​?​g​r​o​u​p​_​i​d​=​193

Quelles sont les prin­ci­pales nouveautés ?

Modèle édito­rial

Prin­ci­pales améliorations :

-Pos­si­bi­lité de défi­nir un nombre (théo­ri­que­ment) infini de classes d’entités, d’index et d’index de per­sonnes, cha­cune des classes pou­vant conte­nir elles-​mêmes un nombre infini de types.

- Amé­lio­ra­tion du sys­tème d’options pour un site : pos­si­bi­lité de créer des groupes d’options, de défi­nir le niveau uti­li­sa­teur requis pour éditer l’option, nom­breux types de champs.

- Pos­si­bi­lité de copier un élément (classe, type, etc.) du ME pour éviter d’avoir à reta­per des infor­ma­tions iden­tiques.

- Pos­si­bi­lité de créer des types publics, qui sont sou­mis par les inter­nautes (expérimental).

Suivi du site

Un tableau de bord per­met de suivre les modi­fi­ca­tions du site. Deux pages sont actuel­le­ment dis­po­nibles : une file d’attente (les docu­ments en attente de publi­ca­tion), un his­to­rique (les der­niers docu­ments modi­fiés). Des flux RSS per­mettent de suivre cha­cune de ces pages (authen­ti­fi­ca­tion HTTP requise).

Par ailleurs, des pages d’information per­mettent de consul­ter les sta­tis­tiques sur le nombre, le type et le sta­tut des enti­tés du site, les infor­ma­tions tech­niques sur la confi­gu­ra­tion du site et du sys­tème, ainsi que la des­crip­tion du modèle édito­rial (ME).

Moteur de recherche

Un moteur de recherche est dis­po­nible pour chaque site. Dans l’interface d’édition, il per­met de cher­cher parmi l’ensemble des docu­ments, qu’ils soient publiés ou non. Côté site, il per­met de dis­po­ser d’un petit moteur de recherche sur les docu­ments publiés.

OAI

Sup­port natif de l’OAI (après configuration).

Plu­gins

Lodel est fourni avec l’éditeur WYSIWYG FCKe­di­tor (http://​www​.fcke​di​tor​.net ), qui peut être uti­lisé dans les for­mu­laires pour l’édition des don­nées. Il consti­tue une alter­na­tive à l’importation de docu­ments sty­lés. Il ne faut cepen­dant pas modi­fier avec FCK des docu­ments impor­tées ini­tia­le­ment par Servoo.

Inter­face

Refonte com­plète de l’interface com­pre­nant, en par­ti­cu­lier, l’ajout des fonc­tion­na­li­tés suivantes :

-Double fil d’ariane, actif côté site.

- Pos­si­bi­lité d’effectuer des actions côté site, en mode pré­vi­sua­li­sa­tion (éditer, publier, sup­pri­mer, etc.).

- Aban­don du bou­ton « Fonc­tions ». Les fonc­tions avan­cées sont regrou­pées dans la page d’édition du docu­ment.

- Sépa­ra­tion plus nette des espaces d’édition et d’administration.

- Pos­si­bi­lité de dépla­cer toute type d’entité.

- Pos­si­bi­lité de modi­fier le type des enti­tés après leur créa­tion (en cohé­rence stricte avec les règles établies par le Modèle édito­rial).

- Niveau de com­plexité asso­cié à l’utilisateur (Expé­ri­men­tal).

- Limites de cette interface :

En savoir plus

Lodel​.org et l’annonce com­plète des nouveautés.

Écrire à l’équipe de Lodel : lodel@​lodel.​org

Il n’est pas de document scientifique qui ne soit citable

JPEG - 15.3 ko
Daddy Long Legs on Mus­ca­dine Leaf
CC by Old Shoe Woman

Il n’est pas de docu­ment scien­ti­fique qui ne soit citable. Dès lors, les efforts des archives ouvertes et des pro­jets d’édition élec­tro­nique s’appuieront sur une base fra­gile si le lec­teur ne sait pas citer en tout cer­ti­tude un docu­ment qu’il vient de lire. Cette ques­tion consti­tuera d’ailleurs pro­ba­ble­ment un frein au dépôt, si les auteurs ne com­prennent pas clai­re­ment à quoi sert leur dépôt. Pour ser­vir la science (avant de ser­vir les évalua­teurs et les mesu­reurs à la sauce Shan­gaï), les dépôts doivent pré­sen­ter une sûreté dans l’usage scien­ti­fique qui en sera fait (citer), bien avant tout autre chose (évaluer, sto­cker, conser­ver, indexer, etc.).

Pour lever cette incer­ti­tude il fau­dra que le docu­ment dis­pose d’un iden­ti­fiant unique stable, très très stable, très simple, très effi­cace. L’OAI ne devrait pas ser­vir à ça, mais on a ten­dance à le faire un peu, ce qui revient à for­mu­ler l’hypothèse d’un dépôt unique mon­dial, qui me semble rela­ti­ve­ment contraire à la logique dis­tri­buée de l’Open archives ini­tia­tive. Le DOI sert à ça, mais il me semble pré­sen­ter des défauts graves (et je suis content d’apprendre que je ne suis pas le seul à le pen­ser). Consé­quence : aujourd’hui, pour l’essentiel des Sciences humaines en France, point d’identifiant unique, seule­ment des URL. Mais même si elles sont l’objet de tous les soins des éditeurs élec­tro­niques, celles-​ci ont ten­dance à bou­ger. Si leur valeur d’usage est très bonne, leur fia­bi­lité l’est moins (même si on constate des évolu­tions notables et plus de rigueur dans leur gestion).

Mais ma pré­oc­cu­pa­tion pre­mière concerne la dif­fu­sion des usages. Si nous adop­tons un iden­ti­fiant unique (IU), il fau­dra être capables de l’expliquer aux lec­teurs, afin qu’ils l’utilisent pour citer la réfé­rence. Il fau­dra donc qu’ils com­prennent com­ment marchent les résol­veurs de noms. Qu’ils aient confiance dans leur fonc­tion­ne­ment. Que ce sys­tème ne leur appa­raisse pas comme une enième péri­pé­tie issue d’une tutelle chan­geante, sou­mise au jeu des chaises musi­cales. Ce sys­tème devra donc avoir des chances d’être mieux que franco-​français : il doit être –ou pou­voir deve­nir– un stan­dard dépas­sant une dis­ci­pline ou un pays. Culti­ver notre excep­tion natio­nale ne me semble pas vrai­ment pertinent.

Il fau­dra aussi que le sys­tème soit simple : je pré­fère des iden­ti­fiants res­sem­blant à un numéro de plaque d’immatriculation plu­tôt que des iden­ti­fiants res­sem­blant à une clé WEP 128 bits ! Les URL uti­li­sées par lemonde​.fr sont signi­fi­ca­tives de ce qu’un pilo­tage par la tech­nique (et/​ou le com­merce) peut don­ner comme résul­tat (désas­treux). Je pré­fère des iden­ti­fiants courts, qui ne seront pas cou­pés dans les cour­riels, qui ne cas­se­ront pas la mise en page d’une note de bas de page, bref, qui s’insèrent dans des usages quo­ti­diens sans pro­vo­quer de conflit, d’interrogation, d’effets secondaires.

Ma convic­tion est que l’URL est un excellent sys­tème, c’est d’ailleurs le seul qui soit aujourd’hui uni­ver­sel, mais qu’il est trop pauvre et fra­gile. Il n’est pas besoin d’expliquer la façon de s’en ser­vir. D’où l’hypothèse d’un IU qui pas­se­rait par le pro­to­cole http. Et la ten­ta­tion de cher­cher du côté des résol­veurs de noms des­ti­nés à réduire la lon­gueur des URL (tinyURL, par exemple). Cette solu­tion per­met­trait de nour­rir les textes de liens stables. L’adoption d’IU igno­rant tota­le­ment l’hypertexte et http pro­vo­que­rait un obs­tacle puis­sant à son usage dans les textes en ligne. Il y aurait, d’une part, la chaine de l’hypertexte, le monde réel, et, d’autre part, le monde idéal des normes par­faites, inuti­li­sées (cf. le cla­vier Dvo­rak et l’espe­ranto). C’est bien d’une inno­va­tion que nous avons besoin, plu­tôt que d’une invention.

Idéa­le­ment, un bon sys­tème d’IU résou­drait le pro­blème de la publi­ca­tion en ligne, d’une part, et du dépôt, d’autre part, c’est-à-dire des dou­blons. Même en uni­fiant les dépôts d’archives ouvertes, il fau­dra prendre en compte la diver­sité des pla­te­formes d’édition élec­tro­nique, qui ont plus voca­tion à se déve­lop­per qu’à dis­pa­raître (Eru­dit, Per­sée, Cairn, Revues​.org pour ne citer que cer­taines, qui relèvent des SHS). Il serait bon de pen­ser à un sys­tème qui soit capable de signa­ler les dépôts sur l’archive natio­nale, d’une part, et la ver­sion éditée en ligne, d’autre part. Une expé­rience sera menée en ce sens entre Revues​.org et HAL l’année pro­chaine, afin de faire en sorte que les dépôts et l’édition élec­tro­nique ne se fassent pas concur­rence, mais au contraire se sou­tiennent. Pour ça, le par­tage d’un IU entre les pla­te­formes me semble indispensable.

Conti­nuons à réflé­chir à un sys­tème d’IU idéal :

- il serait très simple tech­ni­que­ment, donc très robuste

- l’obtention d’un iden­ti­fiant serait gra­tuite

- son attri­bu­tion ne néces­si­te­rait pas de lourdes pro­cé­dures

- il serait très simple dans sa forme, ce qui favo­ri­se­rait son usage quo­ti­dien, et com­pa­tible avec des usages en PAO, trai­te­ment de texte, cour­riel, mes­sa­ge­rie ins­tan­ta­née et dans des articles en ligne (IU cli­quable)

- il ne néces­si­te­rait aucun inves­tis­se­ment tech­nique de la part des cher­cheurs (pas de nou­veau logi­ciel sur le poste du cher­cheur)

- il serait exploi­table par les logi­ciels de biblio­gra­phie (End­note, etc.), par les biblio­thèques, par les éditeurs (et ce, quel que soit le sup­port, ce qui impose un fonc­tion­ne­ment très souple et très rapide)

- il serait capable de dis­tin­guer les ver­sions des docu­ments et, éven­tuel­le­ment, leur sup­port

- il s’appuierait sur un sys­tème rela­ti­ve­ment cen­tra­lisé et serait inter­ro­geable sur autant de sys­tèmes dis­tants que néces­saire (un sys­tème proche du DNS semble assez inté­res­sant à creu­ser)

- il com­por­te­rait peu (pas ?) d’erreurs

- sa main­te­nance édito­riale serait rela­ti­ve­ment économe en moyens humains

- il per­met­trait de décrire des objets très divers (sources his­to­riques, articles scien­ti­fiques, ouvrages, etc.)

- il per­met­trait de jouer, a minima, sur la gra­nu­la­rité de l’information, c’est-à-dire de citer une sub­di­vi­sion du docu­ment. Je pense bien sûr au para­graphe, dont la prise en compte dans le sys­tème pré­sen­te­rait un inté­rêt immense. Mais j’ai conscience que les obs­tacles sont nom­breux.

- il serait adop­table, à terme, par l’édition papier, au même titre que l’ISBN. On obtien­drait ainsi une conti­nuité entre les éditions, et pas un hia­tus voire un conflit entre les uni­vers ana­lo­giques et numé­riques.

- il gère­rait les dou­blons, non par l’ignorance, mais par leur signa­le­ment (conver­gence des ver­sions plu­tôt que conflit des ver­sions, quel que soit le sup­port, quelle que soit la plateforme).

Voici donc le début d’un « cahier des charges idéal », qui se construit en igno­rant volon­tai­re­ment ce qui existe déjà. Vien­dra le temps de l’établissement d’un état de l’Art, qui devra débou­cher sur un tableau com­pa­ra­tif des solu­tions exis­tantes au regard de ce cahier des charges. Espé­rons que des solu­tions concrètes et appli­cables en sortiront.