Comment lier le code aux publications

Les articles savants en informatique scientifique (et dans de nombreux autres domaines, de nos jours) impliquent généralement une certaine quantité de code ou même des progiciels entiers qui ont été écrits spécifiquement pour cet article ou qui ont été utilisés pour obtenir des résultats. Quel est le meilleur moyen d'aider les lecteurs du journal à accéder au code? Mon approche actuelle consiste à mettre un lien vers un référentiel Github (avec une balise de version particulière) dans le document ou dans une citation.

Eh bien, je pense que vous avez quelques options.

1. Si vous avez une page stable, telle qu'une page sponsorisée par une université ou une autre institution à but non lucratif, susceptible de disparaître de si tôt, vous pouvez publier sur cette page.
2. Vous pouvez utiliser un service tel que Github, Bitbucket ou SourceForge pour distribuer le code.
3. Si le code a une valeur générale marginale (c'est un code d'analyse pour un ensemble spécifique de conditions, etc.), vous pouvez le rendre disponible sous forme de téléchargement "d'informations supplémentaires" avec le papier dans lequel vous l'utilisez.
4. Vous pouvez utiliser une combinaison de ce qui précède.

Toutefois, dans tous ces cas, vous devez indiquer clairement la source dans l'article et indiquer le type de licence (GPL, Creative Commons, etc.), afin d'éviter tout problème lié à la propriété intellectuelle.

Excellente question et bonnes réponses, mais je pense qu'aucune ne répond de manière adéquate à la question de la persistance, si l'objectif est d'atteindre le même standard que celui appliqué à la publication elle-même. (Ce qui peut paraître idiot étant donné les chances que le code fonctionne toujours , mais reste tout de même aussi utile que la publication).

Les suppléments de journaux des sites Web universitaires ne sont pas persistants

Il est peu probable que les sites Web des universités offrent la stabilité ou la redondance nécessaires pour préserver le contenu hébergé. Le contenu est plus difficile à citer et manque généralement de métadonnées lisibles par machine.

Malheureusement, il semble que les revues ne se débrouillent pas beaucoup mieux dans la maintenance de leurs matériels supplémentaires (voir Anderson et al. 2006 ), et n'acceptent peut-être pas les formats nécessaires, voire n'acceptent même pas de supports supplémentaires (voir un exemple notable ).

Pour ces raisons, les personnes concernées par l'archivage à long terme des données se sont unanimement tournées vers le plaidoyer en faveur de l'utilisation de référentiels dédiés plutôt que de sites Web ou de matériels supplémentaires, et de nombreuses revues exigent maintenant cette pratique . Il semble juste que le code soit tenu à cette norme.

La solution de nombreux exemplaires?

Github et les sites associés n'ont pas encore prouvé leur longévité sur l'échelle des centaines d'années atteinte par les bibliothèques universitaires et les éditeurs établis. En facilitant la diffusion à grande échelle, cela pourrait fournir une solution que d’autres ont évoquée dans les commentaires, y compris un boursier qui ne pouvait commenter le stackexchange,

... sauvons ce qui reste: non pas par des coffres et des serrures qui les isolent du public et les utilisent pour les consigner dans une perte de temps, mais par une multiplication des copies qui les mettrait hors de la portée d'un accident.

- Thomas Jefferson, le 18 février 1791

Figshare et le standard CLOCKSS

Le seul standard d'archivage que je connaisse est figshare , qui peut accepter des référentiels de code complets (en tant que "ensembles de fichiers" pour le moment, mais je pense que nous aurons bientôt la possibilité d'être répertoriés sous le type "code"). La pièce maîtresse de figshare est non seulement le DOI citable avec des métadonnées programmatiques, mais également le support du service d’archivage CLOCKSS , qui conserve des copies de tout son contenu dans 12 nœuds répartis géographiquement et géopolitiquement dans le monde. Si figshare cesse ses activités ou cesse d’exister, cela signifie que tout son contenu sera disponible gratuitement auprès de CLOCKSS.

Par conséquent, je suggérerais d'utiliser Github pour la distribution du code, mais également de fournir une copie d'archive à figshare au moment de la publication.

Vous pouvez utiliser des techniques de PDF sophistiquées pour attacher simplement le code au fichier PDF (c’est-à-dire que les fichiers de code sont intégrés au fichier PDF et peuvent être "téléchargés" en cliquant sur un bouton du fichier PDF). Cela peut être accompli avec le paquet attachfile , par exemple. Bien sûr, cela fonctionne avec des preprints (bien que je ne sache pas si cela fonctionne déjà avec arxiv) mais vous avez probablement des problèmes avec les fichiers journaux ...

Pour les petits scripts spécifiques à un projet de recherche spécifique, le meilleur endroit pour la publication est le site Web de la revue, en tant qu '"information complémentaire" du journal. C'est là qu'il est le plus facile de trouver quelqu'un qui lit l'article.

Des paquets plus substantiels qui intéressent également d'autres projets devraient être publiés séparément. Malheureusement, il n'y a pas vraiment de bonne solution pour le moment. Idéalement, une publication de code serait accessible en permanence via un DOI, tout comme un document, mais je ne suis au courant d'aucun site d'hébergement qui distribue des DOI et garantit leur permanence. Les dépôts publics comme Github ou Bitbucket sont peut-être le meilleur choix pour le moment.

La meilleure solution serait de publier le papier emballé avec le code et les données qui l'accompagnent, mais cela n'est pas encore techniquement réalisable. Je travaille sur un prototype de recherche explorant cette idée, consultez ce site pour plus de détails.

J'ai choisi deux tactiques, parce que je prévois de changer d'institution prochainement. L'URL de mon université n'est donc pas du tout stable.

Lorsque le code est relativement court, j'ai essayé de l'inclure en tant qu'annexe supplémentaire dans le journal lui-même, en supposant qu'ils fassent probablement un travail décent en conservant le texte et le code au même endroit. Ceci est particulièrement utile pour le code où il n'y a pas une grande quantité d'intérêt général - code qui est quelque peu inutile sans que le papier en question fournisse un contexte.

Mais pour le code source, les logiciels actuels et les projets plus complexes ou d’intérêt général, j’ai suivi votre tactique consistant à vous connecter à un référentiel GitHub, qui devrait au moins être stable pendant la durée de vie moyenne de mes documents.

Jetez un coup d'oeil à http://www.runmycode.org . Ils hébergent des sites compagnons pour le code associé aux documents de recherche. Si le code est R, Matlab ou quelques autres, le code sera exécuté pour vous. Je ne l'ai pas encore essayé, mais j'ai l'intention de le faire. Je pense que David Donoho et ses collaborateurs l'utilisent.

Les bibliothèques universitaires pourraient être un lieu pour cela ou le centre d'hébergement de l'université.

En tant que lecteur, une déclaration dans le document indiquant que le code peut être obtenu en contactant directement l'auteur serait efficace. En tant qu'auteur, cela pourrait favoriser la collaboration et me donner l'occasion de rappeler aux gens de citer mon article s'ils utilisent le code dans leur travail.