Publication itself has to be done when the DOI is assigned to the article.
For each repository:
1. Check/update usage guide.
2. Probably better adding datacite separately (with temporary placeholders).
3. Publish when we obtain a DOI for the article.
Prepared everything except for the DOI of the paper.
@jcolomb can you check if the [repository](https://gin.g-node.org/larkumlab/RealtimeDLC_DataRepository) is well-formatted?
better title would be dataset and code for TITLEOFPAPER
Please update the main readme file:
- link do not work
- add link to paper
- add details about what is to be found, how one could reuse it (if not in the paper),
You may want to erase all unnecessary readme files coming from the template, i.e. get rid of empty folders.
what about https://github.com/gwappa/python-ksdlc
you have datasets in the code folder (https://gin.g-node.org/larkumlab/Keisuke_Sehara_RTDLC/src/master/30_code/whisker_model_A22-Keisuke-2019-09-09/training-datasets/iteration-1/UnaugmentedDataSet_whisker_model_A22Sep9/CollectedData_Keisuke.csv) why?
better title would be dataset and code for TITLEOFPAPER
You may want to add some info about relation between figures, code and data, the main readme could be a place for that ?
but
a spreadsheet may be better
You may want to add some info about relation between figures, code and data, the main readme could be a place for that ?
but
a spreadsheet may be better
Currently we do not have a link to the paper. We are still waiting for it...
Actually the repository to be published is here:
https://gin.g-node.org/larkumlab/RealtimeDLC_DataRepository
- Manuscript / rebuttal are not included.
- Currently we do not have a link to the paper. We are still waiting for it...
ok, need to look what happens to submodules when pushing register doi.
I am afraid the submodules will not be included in the snapshot.
@msonntag , @achilleas ?
ok, need to look what happens to submodules when pushing register doi.
I am afraid the submodules will not be included in the snapshot.
@msonntag , @achilleas ?
You're right. Submodules aren't included in the snapshot (archive) nor the fork when registering a DOI. In fact we recently discovered that submodules cause issues with our registration process.
You're right. Submodules aren't included in the snapshot (archive) nor the fork when registering a DOI. In fact we recently discovered that submodules cause issues with our registration process.
I guess that's up to you. If you want to create a single archive and publication, maybe combining them is better. Perhaps @msonntag has a different suggestion?
I guess that's up to you. If you want to create a single archive and publication, maybe combining them is better. Perhaps @msonntag has a different suggestion?
I guess that's up to you. If you want to create a single archive and publication, maybe combining them is better. Perhaps @msonntag has a different suggestion?
I guess that's up to you. If you want to create a single archive and publication, maybe combining them is better. Perhaps @msonntag has a different suggestion?
If I request a DOI only for the root data repository, you guys say the submodules will not get archived together.
Does that mean, technically, the submodules will not be associated with the DOI?
And when you @achilleas say "combining them", do you mean to remove the submodules and load the original data back for the root repository to manage them directly?
OK, now I am getting confused.
If I request a DOI only for the root data repository, you guys say the submodules will not get archived together.
Does that mean, technically, the submodules will not be associated with the DOI?
And when you @achilleas say "combining them", do you mean to remove the submodules and load the original data back for the root repository to manage them directly?
If I request a DOI only for the root data repository, you guys say the submodules will not get archived together.
The DOI archive will include everything in the root data repository. In other words, everything you get when you git clone the repository + annexed data.
Does that mean, technically, the submodules will not be associated with the DOI?
Technically, no, the submodules wont be part of the DOI. However, the archive will include the .gitmodules file, which includes URLs to the submodules. Which also means that the fork of the repository will point to the original locations of the submodules.
Whether this is desirable or not is up to you.
I should note that if you plan to publish a repository with submodules, you should talk to us first, since it might cause issues with the cloning process on the server.
And when you @achilleas say "combining them", do you mean to remove the submodules and load the original data back for the root repository to manage them directly?
Yes, it was just a suggestion though. I don't know if this works for you. I mean you could just create a new "publication-ready" repository that includes everything and publish that and keep it separate from your working copy with the submodules.
Sorry for the confusion.
> If I request a DOI only for the root data repository, you guys say the submodules will not get archived together.
The DOI archive will include everything in the root data repository. In other words, everything you get when you `git clone` the repository + annexed data.
> Does that mean, technically, the submodules will not be associated with the DOI?
Technically, no, the submodules wont be part of the DOI. However, the archive will include the `.gitmodules` file, which includes URLs to the submodules. Which also means that the fork of the repository will point to the **original locations of the submodules**.
Whether this is desirable or not is up to you.
I should note that if you plan to publish a repository with submodules, you should talk to us first, since it might cause issues with the cloning process on the server.
> And when you @achilleas say "combining them", do you mean to remove the submodules and load the original data back for the root repository to manage them directly?
Yes, it was just a suggestion though. I don't know if this works for you. I mean you could just create a new "publication-ready" repository that includes everything and publish that and keep it separate from your working copy with the submodules.
Publication itself has to be done when the DOI is assigned to the article.
For each repository:
Prepared everything except for the DOI of the paper.
@jcolomb can you check if the repository is well-formatted?
Please update the main readme file:
You may want to erase all unnecessary readme files coming from the template, i.e. get rid of empty folders.
what about https://github.com/gwappa/python-ksdlc
you have datasets in the code folder (https://gin.g-node.org/larkumlab/Keisuke_Sehara_RTDLC/src/master/30_code/whisker_model_A22-Keisuke-2019-09-09/training-datasets/iteration-1/UnaugmentedDataSet_whisker_model_A22Sep9/CollectedData_Keisuke.csv) why?
better title would be dataset and code for TITLEOFPAPER
you need to check with the publisher if you are legally allowed to publish the rebuttal letters
You may want to add some info about relation between figures, code and data, the main readme could be a place for that ?
but a spreadsheet may be better
Actually the repository to be published is here:
https://gin.g-node.org/larkumlab/RealtimeDLC_DataRepository
I will reorganize this repository, too.
ok, need to look what happens to submodules when pushing register doi.
I am afraid the submodules will not be included in the snapshot. @msonntag , @achilleas ?
You're right. Submodules aren't included in the snapshot (archive) nor the fork when registering a DOI. In fact we recently discovered that submodules cause issues with our registration process.
Then do I need to ask for DOIs of all the submodules separately?
I guess that's up to you. If you want to create a single archive and publication, maybe combining them is better. Perhaps @msonntag has a different suggestion?
I guess that's up to you. If you want to create a single archive and publication, maybe combining them is better. Perhaps @msonntag has a different suggestion?
OK, now I am getting confused.
If I request a DOI only for the root data repository, you guys say the submodules will not get archived together. Does that mean, technically, the submodules will not be associated with the DOI?
And when you @achilleas say "combining them", do you mean to remove the submodules and load the original data back for the root repository to manage them directly?
Sorry for the confusion.
The DOI archive will include everything in the root data repository. In other words, everything you get when you
git clonethe repository + annexed data.Technically, no, the submodules wont be part of the DOI. However, the archive will include the
.gitmodulesfile, which includes URLs to the submodules. Which also means that the fork of the repository will point to the original locations of the submodules.Whether this is desirable or not is up to you.
I should note that if you plan to publish a repository with submodules, you should talk to us first, since it might cause issues with the cloning process on the server.
Yes, it was just a suggestion though. I don't know if this works for you. I mean you could just create a new "publication-ready" repository that includes everything and publish that and keep it separate from your working copy with the submodules.
A future job for Tonic ;)
Thanks @achilleas and @jcolomb!
Then I will combine all the data into the root data repository.
Now the data repository is stand-alone. https://gin.g-node.org/larkumlab/RealtimeDLC_DataRepository
I am still waiting for the DOI of the paper...
Did it