Today I was reading the draft of an upcoming thesis defense in our library, and noted the student in question had been using a nice number of codes to support her research. All properly referenced via footnotes, and even some routine names in a “typewriter” font to make them stand out.
Later that afternoon after the weekly graduate un-journal club talk she gave, we and another graduate student got to talking about the ASCL, and explaining to them the triad of paper/data/code that one can view as the three ways our research is now peer review published. In fact, if you look at some recent publications, just after the Acknowledgements, you can find a “Facilities:” line, in which the various facilities (read: observatory/instrument pairs) are listed from which the data in this particular paper were used. We in ASCL have been suggesting that one should add a “Codes:” line as well, with (ASCL) codes used in the paper. Now that ASCL entries are searchable via ADS, there is no reason not to make searching for codes in papers easier. In fact, if you look at the next ADASS conference proceedings, you will find a separate ASCL index in the back of the book!
What do people think, should we ask the editors of journals to make this “Codes:” line a standard feature of papers?
I like the idea of a Codes: line, and wonder exactly what should be listed there. If a code has a published reference in the References section, should it still be listed? Is this a good place to put the version of the code to more completely specify what was used? If it’s an independently-developed part of a larger system such as IRAF, should both be referenced here, with their versions? This is a good subject for further discussion!
I think having the Codes: line is useful even if the code has a published reference, because there will be software with publications that predate the ASCL and thus will not have an ASCL ID within them. Or the URL might have changed since then (e.g., moving a project from a private repo to github), and the ASCL entry will always point to the current location.
Versions would be ideal, though I think that could be very difficult to get straight in the case of using code that’s under continuous development.
Pingback: Software in Astronomy Symposium Presentations, Part 6 – ASCL.net