Come collegare il codice alle pubblicazioni

I lavori accademici nel campo dell'informatica scientifica (e molti altri campi, oggigiorno) in genere riguardano una certa quantità di codice o persino pacchetti software interi che sono stati scritti appositamente per quel documento o sono stati usati per ottenere risultati nel documento. Qual è il modo migliore per aiutare i lettori del documento ad accedere al codice? Il mio approccio attuale è quello di inserire un collegamento a un repository Github (insieme a un tag di versione particolare) nel documento o in una citazione.

Bene, penso che tu abbia alcune opzioni.

1. Se hai una pagina stabile, come quella sponsorizzata da un'università o da un'altra istituzione senza scopo di lucro che difficilmente svanirà presto, potresti pubblicare lì.
2. È possibile utilizzare un servizio come Github o Bitbucket o SourceForge per distribuire il codice.
3. Se il codice ha un valore generale marginale (è un codice di analisi per un insieme specifico di condizioni, ecc.), È possibile renderlo disponibile come download di "informazioni supplementari" con il documento in cui lo si utilizza.
4. È possibile utilizzare una combinazione di quanto sopra.

In uno o tutti questi casi, tuttavia, è necessario indicare chiaramente la fonte nell'articolo e indicare che tipo di licenza è (GPL, Creative Commons, ecc.), In modo che non ci siano problemi relativi alla proprietà intellettuale in futuro.

Grande domanda e grandi risposte, ma penso che nessuno affronti adeguatamente la questione della persistenza, se l'obiettivo è quello di raggiungere lo stesso standard accordato alla pubblicazione stessa. (Che può essere sciocco date le possibilità che il codice sia ancora in esecuzione , ma può comunque essere utile almeno quanto la pubblicazione lo stesso).

Supplementi di riviste di siti Web universitari non sono persistenti

È improbabile che i siti web universitari forniscano la stabilità o la ridondanza per preservare il contenuto ospitato. Il contenuto è più difficile da citare e in genere manca di metadati leggibili dalla macchina.

Sfortunatamente sembra che le riviste non stiano facendo molto meglio nel mantenere i loro materiali supplementari (vedi Anderson et al. 2006 ), e potrebbero non accettare i formati necessari o addirittura accettare del materiale supplementare (vedi un esempio notevole ).

Per questi motivi, le persone interessate all'archiviazione a lungo termine dei dati si sono rivolte all'unanimità verso la promozione dell'uso di repository dedicati anziché di siti Web o materiali supplementari e molte riviste ora impongono questa pratica . Sembra giusto che il codice sia conforme a questo standard.

La soluzione di molte copie?

Github e i siti correlati devono ancora dimostrare la longevità nel corso dei 100 anni raggiunti dalle biblioteche universitarie e dagli editori affermati. Facilitando una distribuzione capillare può fornire una soluzione che altri hanno fatto eco nei commenti, incluso un collega che non ha potuto commentare stackexchange,

... salviamo ciò che rimane: non con volte e lucchetti che li proteggono dagli occhi del pubblico e li usano per consegnarli allo spreco di tempo, ma con una tale moltiplicazione di copie, che li metterà fuori dalla portata dell'incidente.

- Thomas Jefferson, 18 febbraio 1791

Figshare e lo standard CLOCKSS

L'unico standard di archiviazione di cui sono a conoscenza è figshare , che può accettare repository di codice completi (come "set di file" per il momento, ma credo che presto avrà la possibilità di essere elencato come tipo "codice"). Il pezzo chiave di figshare non è solo il DOI citabile con metadati programmatici, ma il supporto di CLOCKSS servizio di archiviazione , che conserva copie di tutto il suo contenuto in 12 nodi geograficamente e geo-politicamente distribuiti in tutto il mondo. Se figshare dovesse smettere di funzionare o cessare di esistere, ciò farà sì che tutto il suo contenuto sia liberamente disponibile da CLOCKSS.

Di conseguenza, suggerirei di utilizzare Github per la distribuzione del codice, ma anche di fornire una copia di archivio a figshare al momento della pubblicazione.

Puoi usare alcune fantasiose tecniche pdf per allegare semplicemente il codice al pdf (ovvero, i file di codice sono incorporati nel pdf e possono essere "scaricati" con un clic su un pulsante nel pdf). Questo può essere realizzato con il pacchetto attachfile , ad esempio. Certo, questo funziona con le prestampe (anche se non so se funziona già con arxiv) ma probabilmente hai problemi con i file journal ...

Per i piccoli script specifici di un progetto di ricerca specifico, il posto migliore per la pubblicazione è il sito Web della rivista, come "informazioni supplementari" al documento. Ecco dove è più facile da trovare per qualcuno che legge l'articolo.

Pacchetti più sostanziali che interessano anche altri progetti dovrebbero essere pubblicati separatamente. Purtroppo al momento non esiste una soluzione davvero valida. Idealmente, una pubblicazione di codice sarebbe accessibile in modo permanente tramite un DOI, proprio come un documento, ma non sono a conoscenza di alcun sito di hosting che distribuisca DOI e ne garantisca la permanenza. I repository pubblici come Github o Bitbucket sono forse la scommessa migliore per ora.

La soluzione migliore sarebbe quella di pubblicare la carta impacchettata con il codice e i dati che ne derivano, ma ciò non è ancora tecnicamente fattibile. Sto lavorando a un prototipo di ricerca che esplora questa idea, vedi questo sito per i dettagli.

Ho preso due tattiche, nate dal fatto che prevedo presto di cambiare le istituzioni, quindi il mio URL universitario non è affatto stabile.

Quando il codice è relativamente breve, ho provato a includerlo come appendice supplementare nel diario stesso, supponendo che probabilmente faranno un lavoro decente mantenendo la carta e il codice all'incirca nello stesso posto. Ciò è particolarmente utile per il codice in cui non c'è una grande quantità di interesse generale - codice che è in qualche modo inutile senza il documento in questione per fornire il contesto.

Ma per codice sorgente, software reale e progetti più complicati o di interesse generale, ho seguito la tua tattica di collegamento a un repository GitHub, che dovrebbe essere almeno stabile per la durata media della vita dei miei articoli.

Dai un'occhiata a http://www.runmycode.org . Ospitano siti associati per il codice associato ai documenti di ricerca. Se il codice è R, Matlab o pochi altri, eseguirà effettivamente il codice per te. Non l'ho ancora provato, ma ho intenzione di farlo. Penso che David Donoho e i suoi collaboratori lo usino.

Le biblioteche universitarie potrebbero essere un luogo per questo o il centro di accoglienza dell'università.

Come lettore, sarebbe efficace una dichiarazione nel documento secondo cui il codice può essere ottenuto contattando direttamente l'autore. Come autore, questo potrebbe favorire la collaborazione e darmi l'opportunità di ricordare alle persone di citare il mio articolo se usano il codice nel loro lavoro.