|Status:||Closed||Start date:||May 09, 2016|
|Priority:||Normal||Due date:||Oct 31, 2016|
|Assignee:||Gabriele Giammatteo||% Done:|
#2 Updated by Gabriele Giammatteo over 3 years ago
- Parent task deleted (
- % Done changed from 0 to 30
- Status changed from New to In Progress
- Subject changed from Find a way to publish gCube code on Zenodo to publish gCube code on Zenodo
A proposal to model gCube components in Zenodo has been prepared here: https://docs.google.com/document/d/1sNvxw5--Z5fzJ-x3P730S84fpslFYkT-BXQP0ce3tBk/edit#heading=h.fhtgf0nds2av
(a copy is also in the workspace: https://goo.gl/8qWZRY)
#4 Updated by Leonardo Candela over 3 years ago
Some early feedback (by reading the doc):
- the same DOI should be "maintained" (thus be specified) across the diverse versions of the "component"/"deposition" ... it is possible to manage "versions" / associate this with version;
- subjects and keywords are quite useful, I would suggest to try to compile them also. Some "generic" subjects can be taken from ACM CSS, http://dl.acm.org/ccs/ccs.cfm e.g.
- Software and its engineering -> Software infrastructure
- Computer systems organization -> Distributed architectures
- for portlets: Human-centered computing → Graphical user interfaces
- ... I would suggest to reinforce this part;
- for Keywords, I would suggest to have HDI (https://en.wikipedia.org/wiki/Hybrid_Data_Infrastructure), VRE (https://en.wikipedia.org/wiki/Virtual_research_environment), https://en.wikipedia.org/wiki/E-Science, gCube, Java ...
#5 Updated by Gabriele Giammatteo about 3 years ago
- Due date set to Oct 31, 2016
thanks for the feedback, I updated the document with a proposed list of subjects and keywords. They will be further refined before the actual publication on Zenodo.
Concerning having the doi across versions, I was inaccurate. I did some other tests and I found that we cannot have two depositions with the same doi (quite obviously). The actual meaning of having user-specified doi seems to be to have in Zenodo depositions that points to dois already assigned by external authorities. I'm not sure I got your suggestion
it is possible to manage "versions" / associate this with version
but a solution could be to have a deposition to represent the component and n depositions to represents each of its releases. I added a section "Deposition types and their relationships" to the shared document  with the details of this solution.
#6 Updated by Gabriele Giammatteo about 3 years ago
- % Done changed from 30 to 100
- Status changed from In Progress to Closed
Zenodo Publisher has been completed. It is able to publish on Zenodo the source code and generated metadata for gCube components integrated in gCube releases. Some minor features have been left out from the current implementation (e.g. component-level depositions, wikidoc urls). They can be added in the future quite easily and in any case, they do not prevent the primary objective of being able to make gCube code citable.
Releases starting from gCube 4.0.0 are being published in the next few days. For future releases, the publication will happen just after the end of each release. Artifacts are being published on a dedicated Zenodo Commiunity: https://zenodo.org/communities/gcube-system/
Source code of the Zenodo Publisher is available at
and it's documentation is at