Journal Une nouvelle manière de publier des articles scientifiques ... HTML, métadonnées et linkeddata

Posté par  . Licence CC By‑SA.
Étiquettes :
12
24
mai
2015

Amis chercheurs, cette nouvelle pourrait vous intéresser.

Une nouvelle manière de rédiger et publier vos article vient d'apparaître : ça s'apelle RASH et ça a peu de rapport avec la méthode au nom similaire. C'est une sorte de sous ensemble du HTML utilisant les technos associées, ça s'annote avec des annotations sémantiques, et ça se transforme en LaTeX style LNCS : post de présentation sur la liste semantic web, et ça a déjà été utilisé dans quelques publications.

Intéressant à l'heure ou le web est devenu capital dans la recherche des documents académique et ou les technos données reliées et web sémantique pourraient trouver toutes leur pertinence. Et puis ou le monde de la publication académique commence à digérer tout les changements récents (à l'échelle des générations de chercheurs) Open Data et Internet …

  • # C'est une excellente idée !

    Posté par  (site web personnel) . Évalué à 2.

    Je trouve que c'est une très bonne idée, et ça rend plutôt bien ! Si ça se généralise, Latex sera peut-être moins utilisé.

    Par contre, pour les formules mathématiques, le MathML, c'est vraiment illisible pour un humain, et ça fout à la poubelle tes connaissances en formules du type Latex. Ça veut donc dire que les formules doivent êtres tapées via un outil. C'est un mauvais choix je trouve.

    C'est une bonne direction, et ça serait parfait avec les deux points suivants :

    • « recherche reproductible » : les données externes et codes sources utilisées pour générer les graphiques de l'article sont également publiées (ce qui permet de reproduire, et de mieux analyses, voire de faire des méta-analyses plus simplement) ;
    • toute publication scientifique est en accès libre (payer pour être publié, droit de lecture gratuit après publication).

    À voir si l'usage se généralise (et merci pour ce journal).

    • [^] # Re: C'est une excellente idée !

      Posté par  . Évalué à 3.

      Par contre, pour les formules mathématiques, le MathML, c'est vraiment illisible pour un humain, et ça fout à la poubelle tes connaissances en formules du type Latex. Ça veut donc dire que les formules doivent êtres tapées via un outil. C'est un mauvais choix je trouve

      C'est incompatible avec Mathjax ?

    • [^] # Re: C'est une excellente idée !

      Posté par  . Évalué à 2.

      Si ça se généralise, Latex sera peut-être moins utilisé.

      Et ça, c'est un but en soi ?..

      • [^] # Re: C'est une excellente idée !

        Posté par  (site web personnel) . Évalué à 3.

        Je plussoie. Pour ma part, je souhaite simplement produire des fichiers HTML 5 dignes de ce nom avec Latex — sans que soit nécessairement respectée la mise en page.

        RASH semble prometteur. Mais pourquoi se poser comme un nouveau langage de balise, et réduire HTML à 25 éléments ?

        Debug the Web together.

      • [^] # Re: C'est une excellente idée !

        Posté par  . Évalué à 2.

        J'ai pas lu ça comme un souhait. Mais c'et certain que LaTeX n'a pas été conçu pour la publication web, mais pour la publication papier.

  • # LNCS

    Posté par  . Évalué à 4.

    Quid des autres formats ? Y'a pas que LNCS dans la vie :/

    • [^] # Re: LNCS

      Posté par  . Évalué à 6.

      Bon j'ai lu un peu plus : évidemment d'autres styles vont être supportés et c'était un peu évident en fait parce que c'est du xml et que donc un style peut prendre la forme d'une transformation XSLT.

  • # Et l'inverse?

    Posté par  . Évalué à 5.

    En parcourant la doc, je me suis demandé si ça n'était pas plutôt le genre de trucs qui pourrait être généré à partir du Latex, et pas le remplacer. Pour l'instant, ça a l'air d'une sorte de régression par rapport à Latex : les maths sont une rigolade, il y a tout à refaire pour les styles (articles et bibliographie) des journaux, je n'ai pas compris s'il existait un outil comme bibtex pour générer la liste des références à partir d'une base de données, etc. Je n'ai pas non plus compris comment le machin gérait la mise en page, ce que Latex fait très honorablement : emplacement des figures, césure des fins de ligne, espacements verticaux dans la page (et je ne parle pas des ligatures et autre détails typographiques). Bref, j'ai l'impression qu'on pourrait faire une moulinette pour tranformer du Latex en RASH (par exemple pour la publication web), mais qu'il ne semble pas très utile d'écrire directement en RASH (apprendre un nouvel outil et gérer tous les bugs de jeunesse doit être compensé par des avantages évidents).

    • [^] # Re: Et l'inverse?

      Posté par  . Évalué à 3.

      Pour la biblio, ça devrait être un jeu d'enfant de générer une biblio à partir d'annotations rdf qui pointent genre sur http://www.wikidata.org/entity/Q3554851 Ce serait un comble qu'il en soit autrement dans le web sémantique que des métadonnées soint mal gérées.

      Pour les maths, j'ai cru lire qu'il y aura du js … donc pas pire que Wikipédia quoi.

      • [^] # Re: Et l'inverse?

        Posté par  . Évalué à 3.

        IMO, latex fournit tout ce que l'on peut attendre d'un système de traitement de texte adapté au contenu scientifique, et ce, avec une syntaxe relativement claire et concise (gestion puissante et simple de la biblio, syntaxe concise pour écrire des équations, etc). Le RASH semble plutôt être un format d'archivage des publications, mais en aucun cas je pense qu'il ne pourrait se substituer à un format source aussi puissant que latex.

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: Et l'inverse?

          Posté par  . Évalué à 1.

          Mouais, pour la biblio faut quand même se taper la récupération et/ou le nettoyage des bibtex plus ou mons bien faits par exemple. Pour trouver les articles qui en référencent un en particulier il faut soit le faire à la main soit avec des services spécialisé genre scholar ou citeseer. Il y a moyen d'améliorer ça. Pour chercher les articles qui parlent d'un sujet donné on peux faire mieux aussi.

          • [^] # Re: Et l'inverse?

            Posté par  . Évalué à 2.

            Mouais, pour la biblio faut quand même se taper la récupération et/ou le nettoyage des bibtex plus ou mons bien faits par exemple.

            J'ai du mal à comprendre la remarque : oui, certes, il existe des erreurs dans les bases biblio, mais il en existera toujours. Et comme il est inconcevable d'avoir des bdd de références scientifiques communautaires, elles seront toujours entretenues par les journaux eux-mêmes et/ou par des boîtes qui tirent bénéfices de telles bases (Google, Reuters/Web-of-Knowledge, etc). Du coup, même si on peut réflechir à des systèmes plus pratiques, il faudra toujours téléchager les références en local sous un format spécial, corriger les erreurs, et faire des références vers ces bdd locales au moment de la compilation.

            Pour trouver les articles qui en référencent un en particulier il faut soit le faire à la main soit avec des services spécialisé genre scholar ou citeseer. Il y a moyen d'améliorer ça

            Euh, genre, comment? Il faut une énorme bdd online qui a accès à des articles dont une bonne partie ne sont pas disponibles gratuitement. Il faut ensuite parser les références (dont les formats sont systématiquement différents) pour les connecter avec d'autres références dans la base, avec une tolérance aux erreurs, tout en gérant les trucs aussi complexes que de ne pas pointer vers les preprints arXive, les thèses et mémoires qui ont le même titre ; savoir gérer les "companion papers" qui ont le même titre et les mêmes auteurs, les bouquins, les chapitres de bouquins, les manuels de logiciel… Il faut qu'une telle base soit exhaustive et mise à jour très rapidement. Quand le nombre de citations devient aussi un moyen d'évaluer les chercheurs et les laboratoires, la moindre erreur peut avoir des conséquences importantes dans le monde réel!

            Bref, on peut toujours améliorer l'existant, mais c'est un projet gigantesque et très coûteux.

            Pour chercher les articles qui parlent d'un sujet donné on peux faire mieux aussi.

            Tu veux dire, fournir un moteur de recherche plus efficace que celui de Google? Ouais ouais, passe devant, je te suis.

            • [^] # Re: Et l'inverse?

              Posté par  . Évalué à 2.

              De un, je vois pas ce qu'il y a d'inconcevable à une base de biblio en opendata. Pourquoi pas Wikidata ou une déclinaison.

              De deux, le post vient de la liste "semantic web" et c'est pas par hasard. Ca y cause annotation RDF des documents ou requêtes SPARQL à l'échelle du web sémantique, par exemple. Si les documents sont annotés à leur rédaction, les éditeurs peuvent publier ces annotations.

              Des trucs comme Wikidata permettent d'identifier et de classer des tas de sujets avec des propriétés RDF like pour référencer par exemple les sujets d'article. Mais ça demande de penser différemment la publicaction, ce que tu ne sembles encore pas prêt à faire :)

            • [^] # Re: Et l'inverse?

              Posté par  . Évalué à 2.

              Et note que dans une base collaborative, accessible et modifiable par le net, ben faut faire le boulot … une seule fois par publi. Ensuite un bout de js qui requête cette base et te génère ta liste de refs et hop.

              Tu n'a plus qu'a garder les ids des publis qui t'intéressent, genre dans tes bookmarks navigateurs … des annotations dans ta publi pour les citations, et ta moulinette js va chercher les infos proprement et te génère la biblio au passage.

              • [^] # Re: Et l'inverse?

                Posté par  . Évalué à 4.

                Je n'ai pas compris ta proposition : qui va mettre à jour en temps réel ta base de données bibliographique? Des millions de refs annuelles mises à jour de manière bénévole par des gens qui sont déja occuppés à faire un vrai boulot (genre publier)? Si chaque article est cité 3 fois en moyenne la première année et que 10% des chercheurs (c'est énorme!) utilisent ta base de données, alors quelle est la probabilité que la ref que tu cherches soit déja dans la base quand tu écris ton article? Pas loin de 0. Tu vas donc devoir systématiquement remplir la base en ligne comme tu le ferais avec ton bibtex, tu vas y trouver des erreurs comme dans ton bibtex. Tu vas aussi y trouver des doublons, des homonymes, des articles qui n'existent pas… Bref, les trucs collaboratifs, ça marche quand des millions de personnes sont intéressées à travailler sur des milliers de données, pas quand 100 personnes sont intéressées par des millions de données.

                Si ton système, c'est d'utiliser un identifiant unique en ref biblio et d'avoir un système te permettant de récupérer les métadonnées associées en ligne, ça existe déja : tu peux taper les DOI dans Google Scholar et récupérer les données en bibtex. Mais une telle moulinette n'a rien de révolutionnaire : plein d'articles n'ont pas de DOI (vieux articles), les livres n'ont pas de DOI, les thèses non plus, etc. Donc tu vas te taper une bdd locale de toutes manières, tu proposes juste de la remplir "automatiquement" en remplissant ton document Latex de DOI cryptiques à la place d'identifiants classiques. Comme les DOI sont en général assez chiants à trouver et à retaper, ton système tourne un peu en rond.

                Attention, hein, je ne dis pas que toute amélioration est impossible. Par exemple, ça serait vraiment bien qu'il soit possible de citer les publis de manière traditionnelle (genre "Machin et al 2001") et qu'un outil logiciel cherche dans les bases de données les articles qui correspondent à ça, en proposant une liste de choix en fonction du contexte de ton article.

                • [^] # Re: Et l'inverse?

                  Posté par  . Évalué à 1.

                  C'est pas malin comme raisonnement. Le travail que tu fais en local te coute pas plus cher à faire en ligne, avec en bonus la proba non nulle gue ça serve à d'autres.

                  Par contre dans un tel système lors de l'écriture de ton doc t'aurais juste à y mettre l'id, si soit tu as déja cité le papier, si un autre l'a fait …

                  Scholar pourrait l'intégrer sans difficulté si c'est basé sur Wikidata vu qu'ils remplacent Freebase par Wikidata. Créer un item sur Wikidata, c'est trivial (faut juset que la communauté accepte de tels items).

                  L'utilisation de la moulinette je c'est jiste un include dans le html. Et évidemment elle pourrait utiliser également un DOI ou autre.

                • [^] # Re: Et l'inverse?

                  Posté par  . Évalué à 2.

                  Sinon ton problème "tradi > ID" me fait penser à un outil vu ce matin dans le résumé hebdo Wikidata, un truc qui fait traduction d'une question en langage naturel vers une requête SPARQL.

        • [^] # Re: Et l'inverse?

          Posté par  . Évalué à 6.

          Pour appuyer ta remarque sir la verbosité du rash vis à vis du latex, voici un exemple du lien tiré du journal pour écrire une pauvre formule à deux balles :

          <!-- Formula defined using the MathML specification -->
<div id="formula_2" class="formula">
    <p class="math_block">
        <math xmlns="http://www.w3.org/1998/Math/MathML">
            <mrow>
                <msup>
                    <mfenced open="[" close="]">
                        <mrow>
                            <mi>a</mi>
                            <mo>+</mo>
                            <mi>b</mi>
                        </mrow>
                    </mfenced>
                    <mn>260</mn>
                </msup>
                <mo>+</mo>
                <msub>
                    <mfenced open="{" close="}">
                        <mrow>
                            <mi>a</mi>
                            <mo>+</mo>
                            <mi>b</mi>
                        </mrow>
                    </mfenced>
                    <mi>i</mi>
                </msub>
            </mrow>
        </math>
    </p>
</div>

          pour le rash, contre

          \begin{equation}
[a+b]^260+\{a+b}_i
\end{equation}

          pour le latex.

          Il va falloir se lever de bonheur pour convertir (à ce niveau on parlera plutôt d'évangélisation) les scientifiques à ce nouveau langage. Sachant que certains écrivent encore en Tex.

          Par contre, une vraie routine qui vous transforme du latex en rash, pourquoi pas. Mais tout seul comme ça, c'est juste un jouet.

    • [^] # Re: Et l'inverse?

      Posté par  (site web personnel) . Évalué à 3.

      j'ai l'impression qu'on pourrait faire une moulinette pour tranformer du Latex en RASH

      J'ai l'impression que ce serait un intéressant format de sortie pour pandoc (qui produit déjà du latex).

      Pandoc peut déjà gérer les bibliographies, les formules mathématiques pour les sorties html et latex. Générer du RASH pourrait instaurer un peu plus de structure dans le html généré et un style standard acceptable.

      Pour ce qui est de la présentation (césures, ligatures, mise en page), les navigateurs web et les bibliothèques javascript s'améliorent là-dessus. Mais pour une sortie papier, latex reste le meilleur.

      • [^] # Re: Et l'inverse?

        Posté par  . Évalué à 2.

        Je trouve pandoc un peu limité pour écrire des publications scientifiques : il ne fournit pas de moyens pour factoriser, ou définir ses propres commandes pour donner une sémantique riche au contenu, ou faciliter l'écriture de certaines équations avec des motifs qui se répètent, etc. Aucun moyen de distinguer l'emphase d'un mot écrit en latin, par exemple. À moins d'inclure du LaTeX complexe tel quel, mais alors c'est mort pour exporter vers autre chose correctement.

  • # Plus de honte

    Posté par  (site web personnel) . Évalué à 7.

    Maintenant on peut le dire sans honte : "Je viens de publier mon article à la RASH" :-D

    Oui je suis déjà loin. ---> [] -->

    kentoc'h mervel eget bezan saotred

  • # EPUB 3 ?

    Posté par  . Évalué à 7.

    C'est pas justement le but d'EPUB 3 de permettre la description de documents techniques/mathématiques via un sous-ensemble d'HTML5 ? Ça a certes du mal à prendre (EPUB 2 semble suffire à la majorité des publications), mais on peut au moins espérer que le statut de standard lui permette à terme d'être lisible sur tout un tas d'appareils sans devoir passer par un convertisseur.

    D'autant que certains choix de mise en forme me laisse dubitatif : à quoi bon un span code (clé de pur style) quand l'élément code est disponible depuis belle lurette ? Là, sans javascript, le rendu des blocs de code est juste dégoûtant, alors qu'un pre immédiatement suivi d'un code aurait eu le même résultat mais compréhensible par n'importe quel navigateur.

    • [^] # Re: EPUB 3 ?

      Posté par  . Évalué à 2.

      Faudrait poser les questions à l'auteur, elles sont pertinentes mais je ne fais que retrancrire pelle mêle.

      • [^] # Re: EPUB 3 ?

        Posté par  . Évalué à 4.

        J'entends bien. En fait il semble que javascript soit un pré-requis (section 10 de la présentation), de même que la CSS. C'est un choix, mais qui reste assez curieux quand il existe déjà des solutions de rendu purement HTML bien établies (par exemple, en enlevant juste la CSS, on perd les numéros des notes en bas de page gérées via des div, ce qui ne serait pas arrivé en passant par une liste ordonnée comme cela se pratique classiquement).

        Je me trompe peut-être, mais ça donne l'impression d'avoir été conçu selon une logique avant tout visuelle, WYSIWYG au lieu de WYSIWYM.

        • [^] # Re: EPUB 3 ?

          Posté par  . Évalué à 2.

          Ouais, c'est un assemblage bizarre par rapport à la volonté d'avoir des annotations sémantique. Mais c'est pas au même niveau de sémantique : section/paragraphe / phrase importante vesus ce bout du document parle de …

        • [^] # Re: EPUB 3 ?

          Posté par  . Évalué à 2.

          On voit aussi qu'il parle de RDFa, qui serait logique avec du *ML, mais en fait dans le document de présentation il préfère utiliser du Turtle et du JSON-LD… et aucun RDFa équivalent ! (je parle pour les relations foaf qu'il définit au début) Et effectivement, sans javascript, ça ne marchera pas. Une telle dépendance à JS alors que des équivalents plus « corrects » existent en langage à balise me laisse une impression vraiment bizarre.

  • # PeerJ

    Posté par  . Évalué à 1.

    A noter également l'initiative du journal PeerJ (un journal open access plutôt innovant où pour 200$, vous pouvez publier 2 articles par an à vie) qui propose de rédiger (Markdown) et d'afficher vos articles sur github en clonant le dépôt template https://github.com/PeerJ/paper-now

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.