Publication robuste sur arXiv

Afin de rendre les articles de recherche publics et facilement accessibles¹¹ il est d’usage en informatique, mathématiques et en physique de publier des versions preprint sur arXiv. Notons qu’utiliser le terme de prépublication est totalement hypocrite, puisque la publication sur arXiv est bien souvent

1. La seule accessible sans “paywall”,
2. La seule contenant les annexes et toutes les preuves techniques,
3. La seule effectivement mise à jour (typos, erreurs, etc.) avec une véritable gestion des versions.

Cependant, n’étant pas revue par les pairs, ce type de publication n’est pas considéré comme une publication “officielle” et il est préférable de citer des versions publiées dans des “journaux/conférences respectables” pour garantir la qualité des résultats.²²

Ainsi, l’auteur ou l’autrice consciencieux·se aura essentiellement trois versions de son papier : une version pour arXiv, une version pour les relecteurs et une version pour la publication finale.³³ Dans cet article, je me concentre sur la publication sur arXiv et les petites astuces qui rendent celle-ci plus facile. Je pars aussi du principe que l’article est écrit en utilisant le système LaTeX et une certaine familiarité avec ce langage et son écosystème.

La gestion des annexes

Plutôt que de faire une version complètement distincte de votre document sur arXiv, ce qui nécessite un travail non-trivial il est parfois plus simple de simplement garder les annexes du papier original. Cependant, la lecture d’un tel papier devient rapidement fastidieuse, avec les allers-retours incessants entre les annexes et le corps du texte. Une solution économique et plutôt élégante est la suivante : utiliser un environnement proofof pour les preuves, et y faire référence avec une commande \proofref, en suivant le code suivant.

% Créé un environnement de preuve pour les résultats en annexe,
% qui prend en argument le label d’un théorème dans le texte principal,
% et produit une preuve
% \begin{proof}[Preuve de \cref{the-label}]
% \phantomsection\label{the-label:proof}
% contenu
% \end{proof}
\NewDocumentEnvironment{proofof}{m}{%
    \IfValueTF{#1}{%
        \begin{proof}[Proof of \cref{#1} on page \pageref{#1}]
        \phantomsection\label{#1:proof}
    }{%
        \begin{proof}
    }
    \let\oldqedsymbol\qedsymbol
    \renewcommand\qedsymbol{\hyperref[#1]{\oldqedsymbol}}
}{%
    \end{proof}
    \renewcommand\qedsymbol{\oldqedsymbol}
}

% Fait référence à une preuve en annexe si elle existe
\NewDocumentCommand{\proofref}{m}{%
    % Si la preuve existe, alors on construit un lien
    % sinon, rien n’est affiché
    % \hyperref[#1:proof]{Proof of \cref{#1}}
    \IfRefUndefinedExpandable{#1:proof}{}{%
        \hfill\hyperref[#1:proof]{(Proof p.\pageref{#1:proof})}
    }
}

Attention. Pour utiliser les macros définies ci-dessus, il est nécessaire d’avoir chargé les paquets hyperref, cleveref et xparse.

Avec cet environnement, il est possible de faire référence à une preuve en annexe avec la commande \proofref{the-label} qui affichera un lien vers la preuve en annexe si celle-ci existe. L’avantage de cette méthode est que produire l’article “publié” devient très facile : il suffit de ne pas inclure les preuves. Notons que cette méthode est aussi utile pour la version destinée aux relecteurs.

\begin{lemma}[Mon lemme préféré]
    \label{assoc:lem}
    Pour tout $x,y,z \in \mathbb{Z}$,
    $(x + y) + z = x + (y + z)$.
    \proofref{assoc:lem}
\end{lemma}

...

\begin{proofof}{assoc:lem}
    Voici ma preuve...
\end{proof}

Lorsque les théorèmes sont complexes il est souvent utile de reformuler les énoncés devant les preuves en annexe. Pour cela, il est possible d’utiliser l’environnement restatable du paquet thm-restate et sa version plus agréable fournie par thmtools, les deux étant souvent déjà inclus dans les modèles de document pour les conférences en informatique. Cette approche se combine particulièrement bien avec les macros précédentes qui sont à changer comme suit.

\NewDocumentEnvironment{proofof}{ m }{
    % Vérifie que la commande \#1 existe
    % Si oui, cela veut dire que l’on peut rappeler le théorème
    % en prenant soin de construire une commande
    % qui signale que nous sommes bien dans un environnement "rappelé"
    \ifcsname #1\endcsname
        \def\isInsideRestatedTheorem{1}
        \csname #1\endcsname*
    \fi
    \begin{proof}[Proof of {\cref{#1}} page {\pageref{#1}}]
        \phantomsection
        \label{#1:proof}
}{
        
        
        \noindent\hyperref[#1]{$\triangleright$ Go back to \cref{#1} on page \pageref{#1}}
    \end{proof}
}

\NewDocumentCommand{\proofref}{ m }{
    \IfRefUndefinedExpandable{#1:proof}{}{
        % Si la preuve existe, mais que l’on est dans un environnement
        % qui est "rappelé", alors la référence n’est quand même
        % pas affichée.
        \ifdefined\isInsideRestatedTheorem
        \else
        \hfill\hyperref[#1:proof]{\textsf{(Proof p.\pageref{#1:proof})}}
        \fi
    }
}

Attention. Pour utiliser les macros définies ci-dessus, il est nécessaire d’avoir chargé les paquets thm-restate, thmtools, hyperref, cleveref et xparse.

Voici un exemple utilisant cette seconde version des macros.

\begin{lemma}[
      name={My Super Lemma}
    , restate={super-lemma}
    , label={super-lemma}
]
    A nice statement.
    \proofref{super-lemma}
\end{lemma}

...

\begin{proofof}{super-lemma}
    Here is the proof of the super-lemma.
\end{proofof}

Les métadonnées

Lors du processus de soumission sur arXiv, il est nécessaire de fournir un certain nombre de métadonnées, dont la liste est décrite sur leur page de FAQ dédiée. Lors de la soumission d’un article, il sera nécessaire ou fortement conseillé de fournir les informations suivantes :

• Titre: Le titre de l’article, où il est possible d’utiliser des commandes LaTeX de base (pour les mathématiques ou des accents). Cependant, je pense qu’il est préférable d’utiliser des caractères unicode standards pour les accents et les symboles mathématiques.
• Auteurs: Les noms des auteurs, rien de bien passionnant ici, mis à part qu’il reste conseillé d’utiliser des caractères unicode plutôt que des commandes LaTeX.
• Résumé: Un court résumé, au format plein texte, pouvant utiliser quelques symboles mathématiques. En particulier, il n’est pas possible d’utiliser des citations dans cette partie ! Il est d’usage que ce résumé soit aussi celui qui sert de préliminaire à l’article lui-même.
• Catégories arXiv: Avant de pouvoir soumettre un article sur arXiv, il est nécessaire de choisir une (ou plusieurs) catégories pour celui-ci. Les plus “traditionnelles” en informatique théorique sont cs.LO (logique en informatique) et cs.FL (théorie des langages formels).
• Mots-clés: Une courte liste de mots clefs, comme weighted automata, finite model theory ou autres.
• Nombre de pages: Ce n’est pas stricto-sensu nécessaire, mais cela permet de faire une somme de contrôle du pauvre.
• Format de document: Normalement celui-ci est facile à remplir, si vous ne marquez pas pdf il y a un problème…
• DOI: Si l’article est déjà publié dans une version légèrement différente dans un journal ou une conférence. Cette information est utile pour permettre aux lecteurs de “remonter” vers une citation “acceptable” des résultats de l’article.
• Licence: Il est possible de choisir une licence pour l’article, par exemple une licence Creative Commons. En général, je sélectionne la licence CC-BY-SA qui permet une réutilisation libre de l’article, à condition de citer les auteurs et de redistribuer l’article sous la même licence.
• Catégorie AMS, ACM: Afin de permettre une meilleure indexation et découvrabilité des articles, il est recommandé de fournir des catégories AMS pour les articles mathématiques et ACM pour les articles en informatique. Voir la section suivante pour plus de détails.

Comme ces informations sont de toute manière demandées par certaines conférences et qu’il est terrible d’utiliser un environnement textarea HTML simple pour écrire du texte, c’est une bonne pratique d’écrire dans un fichier séparé toutes ces informations déjà prêtes. Cela joue le double rôle de simplification de la soumission (il suffit de copier-coller) et de documentation du projet.

La partie la plus “pénible” de ce processus, au moins pour les premières soumissions, est certainement l’écriture des catégories AMS/ACM et arXiv qui font l’objet de la sous section suivante.

Les catégories AMS et ACM

Afin de permettre une bonne indexation des articles, de multiples référentiels existent. Les plus “importants” en informatique théorique sont certainement les codes de l’AMS (American Mathematical Society), de l’ACM (Association for Computing Machinery) et de The arXiv.

Les codes AMS liés à l’informatique théorique se trouvent sur leur page dédiée à l’informatique et leur page dédiée à la logique. En résumé, ceux qui peuvent être utiles pour moi sont les suivants:

Les codes ACM qui peuvent être utiles en logique, automate et théorie des langages sont les suivants dans la sous catégorie “F” pour la théorie du calcul. Si je comprends bien, le site arXiv utilise la liste ACM CSS de 1998, dont je liste ci-après les catégories utiles pour moi.

Cependant, pour certaines conférences, il faudra aussi utiliser des codes ACM plus récents, par exemple en utilisant leur outil visual CCS. Bien que cela ne soit pas stricto-sensu nécessaire à une soumission sur arXiv, il est de bon goût d’avoir les mêmes méta-données dans le document et sur la plateforme qui l’héberge. L’outil fourni par l’ACM permet de générer du magnifique code XML à intégrer directement dans le fichier LaTeX de l’article. Un exemple de code prêt à être intégré dans un fichier LaTeX est le suivant :

\begin{CCSXML}
<ccs2012>
   <concept>
       <concept_id>10003752.10003753</concept_id>
       <concept_desc>Theory of computation~Models of computation</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10003752.10003790</concept_id>
       <concept_desc>Theory of computation~Logic</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10003752.10003790.10002990</concept_id>
       <concept_desc>Theory of computation~Logic and verification</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10003752.10003790.10003792</concept_id>
       <concept_desc>Theory of computation~Proof theory</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10003752.10003790.10003799</concept_id>
       <concept_desc>Theory of computation~Finite Model Theory</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10003752.10003766</concept_id>
       <concept_desc>Theory of computation~Formal languages and automata theory</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10003752.10010124</concept_id>
       <concept_desc>Theory of computation~Semantics and reasoning</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
 </ccs2012>
\end{CCSXML}

\ccsdesc[500]{Theory of computation~Models of computation}
\ccsdesc[500]{Theory of computation~Logic}
\ccsdesc[500]{Theory of computation~Logic and verification}
\ccsdesc[500]{Theory of computation~Proof theory}
\ccsdesc[500]{Theory of computation~Finite Model Theory}
\ccsdesc[500]{Theory of computation~Formal languages and automata theory}
\ccsdesc[500]{Theory of computation~Semantics and reasoning}

Préparer le document

Pour éviter les problèmes de fichiers manquants, de commentaires qui restent à jamais dans une archive publique et pour simplifier le processus de soumission, il peut être utile d’utiliser un petit utilitaire bien pratique : latexpand. Si vous utilisez bibtex, il est possible de l’utiliser pour intégrer les références bibliographiques directement dans le fichier tex principal en utilisant l’option --expand-bbl, si vous avez plutôt un journal qui utilise le biber et biblatex une autre option --biber est à votre disposition. L’utilisation typique est alors la suivante :

latexpand --empty-comments \
          --expand-bbl mon-article.bbl \
          mon-article.tex > mon-article.flat.tex

Bien entendu, il n’est pas possible d’intégrer simplement tous les fichiers dans le code LaTeX principal⁴⁴, il est alors utile de créer une archive un peu minimale contenant les fichiers annexes (principalement des images). Comme il est relativement impossible de se souvenir précisément de l’utilisation de la commande tar je rappelle ci-dessous un exemple d’utilisation pour créer une archive tar.gz.

tar -czf mon-archive.tar.gz \
         mon-papier.arxiv.tex \
         LICENSE \
         mon-image.png 

Pour terminer, une petite remarque sur le fait que si votre code commence par un commentaire (%) alors le système d’arXiv ne le compilera probablement pas correctement, et il faudra indiquer clairement au système d’utiliser pdflatex via une commande \pdfoutput=1 dans les 5 premières lignes du fichier.

Tester le rendu

Lors d’une soumission, le système arXiv compile le code LaTeX de l’article et demande une vérification manuelle du rendu final avant de valider la soumission (qui est rendue publique quelques jours plus tard). Pour éviter les aller-retours inutiles entre le code source, l’archive tar.gz et le rendu final, il est possible d’utiliser une image Docker pour créer un environnement isolé de compilation en utilisant l’image officielle texlive/texlive. Il est aussi possible/conseillé d’utiliser un système d’intégration continue pour vérifier la bonne compilation du papier au fil de l’écriture, comme décrit dans le billet Docker et Actions Github.

Un exemple de Makefile

Pour simplifier la collaboration avec d’autres auteurs et pour ne pas se retrouver perdu quand on revient 5 mois plus tard dans le dossier d’un papier déjà publié, il est particulièrement utile d’avoir une documentation. Comme personne n’écrit jamais de documentation, et que lorsqu’elle existe, elle est obsolète, il est plus raisonnable d’utiliser un Makefile pour automatiser le processus de compilation et de nettoyage. Un exemple de Makefile est donné ci-dessous.

.PHONY: all clean

# Nom du fichier principal
PAPER=mon-article

all: $(PAPER).pdf

# Compilation du fichier principal
# en utilisant latexmk
$(PAPER).pdf: $(PAPER).tex
    latexmk -pdf -pdflatex="pdflatex -interaction=nonstopmode" $(PAPER).tex


# Création d’une version "arXiv" du papier
# qui inclut les fichiers annexes
# et les références bibliographiques
# en supprimant les commentaires
$(PAPER).arxiv.tex: $(PAPER).pdf
    latexpand -o $(PAPER).arxiv.tex \
			  --empty-comments \
			  --expand-bbl $(PAPER).bbl \
			  $(PAPER).tex

# Création d’une archive tar.gz
# pour soumission sur arXiv
$(PAPER).arxiv.tar.gz: $(PAPER).arxiv.tex
    tar -czf $(PAPER).arxiv.tar.gz \
             $(PAPER).arxiv.tex \
             LICENSE \
             mon-image.png

# Compilation autonome de l’archive dans un conteneur
# jetable pour tester le rendu
$(PAPER).arxiv.pdf: $(PAPER).arxiv.tar.gz
    # décompresse l’archive dans un dossier temporaire
    tar -xzf $(PAPER).arxiv.tar.gz -C /tmp/$(PAPER).arxiv
    # compile l’archive dans un conteneur jetable
    docker run --rm -v /tmp/$(PAPER).arxiv:/workdir \
                    -w /workdir \
                    texlive/texlive \
                    latexmk -pdf -pdflatex="pdflatex -interaction=nonstopmode" $(PAPER).arxiv.tex

# Nettoyage des fichiers temporaires
clean:
    latexmk -c
    rm -f $(PAPER).arxiv.tex $(PAPER).arxiv.tar.gz $(PAPER).arxiv.pdf

Conclusion

Vous n’avez plus d’excuse pour ne pas mettre vos articles avec tout le contenu sur une archive ouverte.