Comment lier le code aux publications

40

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.

David Ketcheson
la source
2
Le partage du code est une excellente idée et devrait être fait davantage. Je sais que je pourrais être mieux à même de fournir le code correspondant à un papier. Un dépôt Github semble être une bonne solution. Certainement beaucoup mieux que d’inclure le code source dans une annexe, ce que j’ai vu faire pour des efforts de codage moins importants.
Barron
4
Ceci est une question connexe MO.
JM
@JM Merci, les réponses sur MO sont très bonnes!
David Ketcheson le
notez que vous pouvez publier des blocs-notes ipython sur github et qu’ils sont rendus, à l’exception des parties interactives
denfromufa
1
@denfromufa Malheureusement, Github désactive Mathjax, les calculs ne sont donc pas rendus non plus. Cela le rend plutôt inutile pour la plupart des domaines pertinents. Mais il y a toujours nbviewer.
David Ketcheson

Réponses:

17

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.

aeismail
la source
6
Je pense qu'on devrait mettre son code à l'endroit le plus probable pour survivre, et à plusieurs endroits si possible. Les pages universitaires semblent moins susceptibles de survivre que les services d'hébergement, par exemple. Il est tout à fait judicieux que le journal rende disponible un instantané. Malheureusement, aucun journal à ma connaissance ne propose d'hébergement.
Faheem Mitha
1
Un étudiant ne devrait probablement pas mettre de logiciel sur une page d’accueil personnelle; Cependant, je dirais que pour un code de recherche typique, il est probablement plus avantageux de le distribuer sur une page associée à un groupe de recherche qu'une page externe où l'attribution risque d'être perdue. En ce qui concerne les revues, il est vrai qu’elles n’hébergent pas de référentiel. Cependant, la possibilité d'avoir des "informations supplémentaires" sous la forme du code de recherche répond à la plupart des exigences d'un développement logiciel scientifique responsable. (Si besoin est.)
aeismail
Mon sentiment est que les pages universitaires risquent davantage de se perdre que les sites d'hébergement habituels. Bien sûr, la plupart des sites d'hébergement populaires (Bitbucket, Github, Google Code) n'ont pas existé aussi longtemps. Par contre, Sourceforge par exemple existe depuis un moment.
Faheem Mitha
Il y a d'autres problèmes à prendre en compte; Les préoccupations en matière de propriété intellectuelle et les réglementations des universités ou des gouvernements peuvent également contrôler le choix des référentiels. Mais le contre-argument est qu’un certain nombre de codes (le NAMD en est un exemple majeur) ont été distribués avec succès sur des sites appartenant à des universités. En général, la "signification" du code déterminera sa visibilité. Je doute qu'un code qui développe une base d'utilisateurs significative disparaisse complètement.
aeismail
1
C'est vrai, mais si le code est obscur, cela ne signifie pas qu'il est OK s'il disparaît. Et on espérerait que la plupart des codes scientifiques seraient sous licence libre et sans restriction déraisonnable. Je crois que les NIH, par exemple, exigent maintenant cela pour les travaux réalisés avec l'argent des NIH (contribuables). Je pense que cela devrait être le cas pour tous les projets financés par les contribuables.
Faheem Mitha
8

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.

cboettig
la source
1
figshare est un grand pas en avant, bien que la licence CC-BY ne soit pas une licence de logiciel, et je ne sais pas combien de scientifiques sont prêts à publier leur code sous CC0, c'est donc un problème à résoudre. J'apprécie qu'ils utilisent DOI et CLOCKSS, mais c'est excellent.
Aron Ahmadia
Oui, il est intéressant de noter que les licences posent encore des problèmes, en particulier pour les logiciels les plus développés. Pour que les scripts répliquent une analyse, je pourrais voir que CC0 est plus approprié.
cboettig
Le code Google pourrait être légèrement meilleur pour le grand public car vous pouvez avoir une page Web plus agréable avec un résumé, des images, un lien DOI, une visibilité accrue dans la recherche, etc. Vous devez absolument mettre un tgz dans la section Téléchargement et fournir un lien sur la page d'accueil. Rappelez-vous que la majorité des non-développeurs ne sont même pas familiarisés avec le contrôle de version, encore moins avec git / hg. Subversion est aussi loin que je le souhaiterais pour un public plus large.
Stali
1
@stali rappelle que github prend également en charge les pages Web personnalisées pour les référentiels via gh-pages et les archives compressées téléchargeables. Mais ni Google ni Github ne fournissent de code DOI distinct pour le code et ne traitent pas de la longévité des archives au-delà de la vie de l'entreprise.
cboettig
4

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 ...

Poignard
la source
Très sympa! Je ne savais pas que LaTeX pourrait faire ça.
Qubyte
4

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.

Khinsen
la source
1
+1 pour ActivePapers. Je ne pense pas que cela réponde à mes besoins maintenant, mais je suis heureux de voir quelqu'un travailler sur une solution!
David Ketcheson
figshare fournit des DOI: voir figshare.com/blog/…
Jeromy Anglim le
3

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.

Fomite
la source
2

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.

Paul G. Constantine
la source
Ah Vous avez déjà utilisé cela. runmycode.org/CompanionSite/site.do?siteId=158
Paul G. Constantine
@David Ketcheson et moi avons également effectué une expérience en décembre en utilisant la pile wakari.io et les cahiers IPython pour l'un de nos codes basés sur Python. Vous pouvez consulter les cahiers de reproductibilité PyClaw ici .
Aron Ahmadia
0

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

vanCompute
la source
-2

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.

JxB
la source
4
C'est un point de vue intéressant et je suis curieux de voir à quel point c'est courant. Personnellement, c'est ce que j'essaie de fuir. Je pense que c'est comme publier un article incomplet et demander aux lecteurs de demander le texte intégral. Voir sciencecodemanifesto.org .
David Ketcheson
2
Étant donné que l'adresse de contact de l'un de mes journaux les plus importants est essentiellement morte - et incertaine à propos de certains autres - je suis généralement opposée à cette solution. "Me contacter" n'est pas forcément la chose la plus facile au monde, surtout une décennie plus tard.
Fomite
2
L'approche "me contacter" ne garantit pas non plus la reproductibilité. Lorsque vous me contactez pour me demander du code, je vous enverrai probablement la version la plus récente, et non celle que j'ai utilisée dans le document d'origine. Si seulement parce que je n'aurais plus la version originale.
Khinsen
3
Des études empiriques ayant en réalité contacté un auteur pour lui demander des données, même lorsque l’auteur avait signé un contrat de licence lui permettant de le fournir sur demande, ont montré qu’étonnamment peu d’auteurs s’y pliaient. Par exemple, voir dx.doi.org/10.1371/journal.pone.0007078 et les citations qui y figurent. Si cela ne fonctionne pas bien pour les données, je suppose que ce n'est pas non plus une bonne solution pour le code.
dimanche