Michael Barton wrote > Markus and Co. > > This is something CoMSES Net (Network for Computational Modeling in Social > and Ecological Sciences: http://www.comses.net) has been working with for > some years now. We maintain a software code library, where researchers can > publish model code. We also provide for the option of code peer review, > which can happen when code is submitted to the library for review along > with a paper sent to a journal, or independent of any paper review. Code > that has passed peer review is currently assigned a “handle” from > handle.net<http://handle.net>. Handle.net<http://handle.net> > is the organization that oversees the digital identifier ecosystem. DOI’s > are commercial instances and handles are open source instances, but both > are ultimately under the purview of handle.net<http://handle.net>. > With a new grant from NSF, CoMSES Net is now part of a new national data > infrastructure network in the US. One of our plans is to transition from > handles to DOI’s because these are more widely recognized. > > Given all this, we’ve had to think quite a bit about how to ‘publish’ > model code and assign identifiers. As Vaclav points out there are > significant issues with versioning. What happens with a new version? We’ve > adopted a conceptual position that we are not a versioning repository > primarily, but a place where authors can publish ‘finished’ code used in a > research project or product. We are trying to treat this like a library > and journal environment in that sense. We allow for minor revisions to > correct errors (including as a response to reviews). But if a new product > (e.g., a research paper) uses a new version of model code, we consider > that a new digital object published, which could get a new handle/DOI > distinct from a version of a model used for an earlier product. This > remains something that is complicated to implement in practice. But the > concept involves the reason for giving out the handle/DOI in the first > place. > > Currently, only about 10% of published model based science makes code > available for review or reuse. We think it is increasingly important that > researchers share the code that is an important component to scientific > practice in the same way they share research protocols and results—and are > increasingly encouraged to share data. But sharing code takes effort, and > even researchers with the best intentions may find it difficult to find > the time or energy to make code available. So we are trying to create > incentives that will have some value in the academic/research world, > including citable products. All models published in the CoMSES Net library > have automatically generated citations. Those that have passed peer > review, verifying some degree of software quality, are also given > permanent identifiers (handles/DOIs), with the idea that researchers can > put them on their CVs where they at least have the possibility of gaining > them some recognition for the work carried out. That is, we consider a DOI > as an incentive for sharing code and a bit of a lever to get others to > cite that code if they use it. > > We are still trying to work out how best to handle improvements (bug > fixes) to a model vs. new models. We are moving our library to a Git > environment, but are still working out how to implement our concept of > “published” snapshots of code in a library/journal in versions and > releases in Git. We do have a roadmap and are working on it, but we don’t > yet have a solution in place. > > Where is all this leading? We need to ask what is the value to assigning > DOIs to GRASS code, how might they benefit GRASS developers, and how might > they be used by GRASS software users? I don’t see that they provide the > kind of incentives that CoMSES Net is envisioning for computational model > developers. Most DOIs are assigned to finished products as digital > objects. From that perspective, GRASS could get a DOI, but not its > component modules. But what about each version of GRASS? GRASS has formal > releases, but not its components. Some code is in the released code base > and other is in addons. There is ongoing development in the SVN. GRASS is > a digital object of course, as are its component code modules, but it is a > dynamic, living one and not a static one. Perhaps there are other benefits > to working out the complications of where and when to assign DOIs in the > GRASS ecosystem. But it will be good to start with a discussion of why and > for whom we would do it. > > (I’m copying Allen Lee from the CoMSES Net leadership team as he has > thought a lot about this and might have other things to add.) > > Cheers > Michael
some kind of related: http://ivory.idyll.org/blog/2016-using-zenodo-to-archive-github.html https://zenodo.org/ ----- best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Introducing-DOI-for-software-documentation-and-data-in-the-GRASS-project-tp5296235p5296759.html Sent from the GRASS-PSC mailing list archive at Nabble.com. _______________________________________________ grass-psc mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-psc
