Closed paigem closed 1 year ago
Thanks for the super useful comments. I think rather than answer everything here I'll use them for the guidance for contributors. So we have a central place where contributors can clarify find answers to similar questions. Said so I'll ad something about the last 2 points and the doi, as they can have the biggest impact.
DOI
You should list the DOI of the resource you are describing if it exists already. So in your case if the original paper publication is not just a reference but it is what you are describing then you should use its DOI.
As currently we have the DOI enabled it always expects a DOI to be already present or it will try to produce one.
So if a record doesn't have a DOI (as for a data portal) what you want to do is to give it a fake one using "10.1234567/
When you create a new version for. a record it will expect a new DOI, that can be an issue if we want to add related files after publishing. As the actual DOI is not changing. This behaviour might change in the future but I'm also testing another workaround today
I just added an entry for an idealized model that I used in my PhD. Because this is an idealized model and so built around the code (not the model output), I have a points of confusion to bring up. Some may require their own issue, but some may be simple answers, so I'm adding them all in a single issue for now:
Dates
fields. There are several different places to include relevant dates (e.g. publication, updates, timespan of model, ...). The first instance of the publication date is unclear to me - is this when the code was first published? Or the newest version released? I ended up going with the date of first publication, then adding the newest version release asDate Updated
.