[GRASS-PSC] Introducing DOI for software, documentation and data in the GRASS project

[Helmut Kudrnovsky]

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.