[OSGeo-Discuss] Fwd: DataCite: Persistent identifers for GRASS GIS - and OSGeo

[Jeff McKenna]

(sharing this as it potentially affects all of the OSGeo family, in a 
good way!)


-------- Forwarded Message --------

Dear GRASS PSC, Allen, and Helmut, (cc: Britta Dreyer, DataCite)

a happy new year to all of you !

Thanks for your feedback regarding the use of persistent identifiers 
(PID) (like DOI and handles) and sharing the experiences by CoMSES/ASU.
Sorry for taking so long to reply !

As Michael has pointed out, GRASS is indeed a dynamic, living digital 
object, consisting of different branches of code and documentation, 
augmented with add-on modules. The use of persistent digital identifiers 
like Digital Object Identifiers (DOI) or handles for all aspects of the 
research cycle (including software like GRASS GIS) is still evolving. 
Currently, it is easy to asssign a PID to relatively static content, 
like a software release or a data set, while a dynamic digital 
object(-cluster?), like GRASS, is still a challenge. On the good side, 
there are already options available how to handle this (recommendations 
by FORCE11, depending on the use case).

A dialogue on how to address and overcome such challenges would be 
welcomed by the DataCite organisation, which drives scientific data 
citation by DOI. DataCite is a NGO, headquartered in Germany. DataCite 
itself is non-commercial (https://en.wikipedia.org/wiki/DataCite). 
However, DataCite members _can_ elect to be commercial, by requiring 
service charges for DOI minting from its customers as they provide 
infrastructure  (for landing pages, servers, archiving/backup).

I suggest to start a discussion within the GRASS community, to clarify 
potential benefits by assigning PIDs to aspects of the GRASS project, 
like GRASS releases, devel-snapshots, add-on modules and the like (-> a 
topic for FOSS4G ?).

As a lot of potential GRASS add-ons are created in various fields of 
Academia, I assume that a workflow which assigns PID to GRASS add-on 
module code which is uploaded into the repository (meeting basic quality 
criteria) would be beneficial in at least three ways: 1) the researchers 
receive a reward in the "coin of their realm" for their scientic code, 
which can be cited in publications; 2) the GRASS community benefits as 
additional code/functionalities becomes visible/usable for all of us, 3) 
GRASS as a whole receives more visibility within Academia through search 
portals for PID.
Example: The DataCite search engine already provides a significant 
number of GRASS-related content 
(http://search.datacite.org/works?query=GRASS+GIS), dating back to 1987 
(https://doi.org/10.5446/12963 )). BTW, it is also worthwile to run 
queries for the names of PSC members on it...

Provided that the GRASS community, or some other OSGeo software project, 
should decide that they want to start using PID, especially DOI, some 
strategic opportunities arise:

- Using the services of an existing DataCite member would require an 
annual fee of "x" USD/EUR to mint up to "y" DOI (ca. 150USD for 
1000DOI). Currently this is only viable for git-based repositiories. As 
GRASS is still using SVN, there's a problem.

- Alternatively, GRASS, or OSGeo(!), could elect to become a DataCite 
member by itself. This also comes for an annual fee, but would enable 
GRASS/OSGeo to mint as many DOI as needed and would solve the SVN-issue. 
With the already existing OSGeo infrastructure, meeting the DataCite 
infrastructure requirements (landing pages, archiving/backup, best 
practices) will not be difficult.
As already said, DataCite would highly value a dialogue with GRASS / 
OSGeo on how to better address software communities. They are suggesting 
to enable access to their API via a test account, to investigate 
mappings between the metadata standards of GRASS / OSGeo and DataCite. 
This would allow us on the GRASS/OSGeo side to mint DOI with an 
expiration date: These "short-lived DOI" expire after 3 months, as they 
are only good for testing/evaluation purposes.

This could be investigated as part of a Google Summer Of Code (GSOC) 
Project, like we already had in past years (example: 
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_2012_Image_Segmentation).

Please let me know what you think of this.

best,
Peter


<peter.loewe at gmx.de>