ReScience
Corrections to published articles
@ReScience/editors Do we have a policy for corrections to already published articles? I don't remember if this has already happened. I am pretty sure we don't publish separate errata, 20th century style.
Context: @rdicosmo has corrected two links in his contribution to the ten-year challenge (the commit is https://gitlab.inria.fr/dicosmo/ocamlp3l-rescience/-/commit/4c2831bd724c0ac13d145482b01f79e5be592b4d) and would like to have the corrected version referenced by ReScience.
Technically I see no problem: I upload the new PDF to Zenodo and mark is as an update to the older file. Zenodo gives me a new DOI, which I put on the ReScience Web site, together with an updated link. This makes ReScience point to the updated text, with Zenodo allowing to find the original one.
We could, however, also keep a trace of corrections in the ReScience table of contents.
One perhaps radical idea that springs to mind is to also contact anybody who has cited the paper, just to let them know of the change too.
If a paper to ReScience was peer-reviewed, I don't think it's proper to simply update the link on ReScience to a new version of the paper (new DOI, or new version of the DOI). The new version could be shown with a new link, perhaps, along with the old, with an "UPDATE
We can publish an errata (with a special section for this) and I can check how to make it appear on the original entry.
How do other online-only journals handle this? Errata are a technique from the print era.
Thanks everybody for looking into this: I'm sorry for taking your time on this issue, but it's an opportunity to look at the policy for fixing errors in published articles.
In my experience, traditional "errata" are published when a substantial mistake has been found in a published article: this may be a wrong theorem, a wrong proof of a theorem, etc.
When we are confronted with material errors (spelling, wrongly typeset sentences, broken links, etc.) that would have been normally caught during the editing process, then there is no mistake in the article itself, only a publishing/processing error, and what we want is to make sure that when a reader comes to the article, she finds the most recent version with the typos fixed.
Here we are in this second case, correcting a factual error in the hyperlinks included in the paper (2 in the bibliography, 1 in the paper text).
Indeed, you can verify that there is no difference in the article text itself, by looking at the diff here: https://gitlab.inria.fr/dicosmo/ocamlp3l-rescience/-/commit/4c2831bd724c0ac13d145482b01f79e5be592b4d
Here it seems to me that the right process would be to just replace the old PDF with the new one containing the fixes, without changing the DOI, so readers looking at articles referencing it will access the copy with the typos corrected.
For the record (and from the printing era), we have the choice between:
- (1) addendum
- (2) clarification
- (3) correction
- (4) corrigendum
- (5) erratum
- (6) expression of concern
- (7) new edition
- (8) new version
- (9) partial retraction
- (10) removal
- (11) retraction
- (12) withdrawal.
- (13) full retraction
Zenodo offers "versioned DOI" that point to the most recent version of a record while listing the earlier versions. This can be helpful here, remembering of course that the process must be transparent to our readers.
That's what I had in mind on the Zenodo side. The question is how the present the update within ReScience. In @rougier's 13-point list, I think we are at 3) correction, though as @rdicosmo explained, this is really a type of correction that didn't exist in the print era. I'd assimilate this to a wrong page number in a literature reference.
On Zenodo they published a policy that seems relevant to this particular case, see https://help.zenodo.org/
Can I change the file in the already published record? [snip] The recommended way is to create a new version of a record (more details available here). [snip] Exceptionally, we allow small modifications to the record's files, if and only if the record was published recently (less than one week). If you have spotted mistakes such as typos, accidental omission of important files/inclusion of hidden files or confidential files and would like to update them, please contact us.
We can try this solution for Roberto's article (contacting Zenodo) but we should also think about an official guideline for errata/addendum/etc. @konrad can you try to contact zenodo since you edited the article ?
Hey @rougier - you mentioned the wrong Konrad - you meant @khinsen, I guess. :)
Since the article has been published more than a week ago, I have uploaded the corrected article as a new version on Zenodo. The versioned DOI is https://doi.org/10.5281/zenodo.3763415, it resolves to a landing page that shows the new version along a list of all versions. This looks good to me.
On the ReScience side, the open question is what should appear on the article's main page at https://rescience.github.io/bibliography/DiCosmo_2020.html. Everywhere else, in particular in the BibTeX record, I'd be happy to just update the DOI. But... I have no idea how this page is actually generated and what options we have (with reasonable technical effort) to add information to is. @rougier ?
The landing page is generated from the bibtex entry in _bibliography/published.bib. If you modify Roberto's entry, that should be fine (but I would nee to rebuild the website though).
@rougier OK, so that means I can change the DOI but I cannot add information about the update having happened, right? It would be accessible on Zenodo (for those who click on the DOI rather than on the PDF link), plus of course in the git log of the Web site, but not in any obvious hard-to-miss place.
For this particular correction I don't see a problem with that, but if we ever get a case of a more substantial correction, I would hope for more.
We can add a note or field in the bib item and I can update the paper template to show it.
@rdicosmo There is a problem with the PDF file you sent me: it contains the DOI of the original version. This actually looks like a tricky issue because I don't see a way to pre-reserve a new DOI when updating a file, only when uploading a new one. I'll check with Zenodo if they have a solution, but that may take a while, sorry.
Update done! DOI reservation actually works fine on Zenodo, but you need to be careful at each step. I find it a bit counter-intuitive to have a button "reserve DOI" that leads to the reserved DOI being shown above the button, as if it had been there before.
In summary, here is what I did:
- Find the upload on Zenodo, click "new version".
- Click on the "reserve DOI" button and note the new DOI displayed a few lines above the button.
- Clone the article repository (in this case on gitlab.inria.fr).
- Edit
metadata.yamlto update the DOI to the freshly reserved one. - Recompile
article.pdf(just amakeif you have a reasonably complete and recent TeXLive installation) - Delete the original article.pdf on Zenodo.
- Upload the new article.pdf.
- Click "publish".
- Update article.pdf, article.yaml, and article.bib in https://github.com/ReScience/articles/tree/master/10.5281_zenodo.3763416. In article.bib, add a
notefield explaining the correction, with a reference to the original DOI - Update https://github.com/ReScience/rescience.github.io/blob/sources/_bibliography/published.bib (with a copy of the updated article.bib)
All that should be scriptable in the same way as an original submission. If we get corrections more frequently, that's worth exploring. A potential issue with the procedure outlined above is that you must keep the Zenodo page live in your browser in between steps 3 and 7. That's no big issue if you can re-generate the article.pdf yourself, but if you have to ask the authors to do it, the wait could be problematic.
@rdicosmo I have opened an issue with the new DOI on your article repository at gitlab.iniria.fr (profiting from having an account there).
@khinsen do we want to write this up (somewhere more easily discoverable) for others to make use of in the future as a way of correcting articles?
Might be a good idea to keep some notes abut this yes. Problem is I don't know where exacty.
I'd say it makes sense to add this to https://github.com/ReScience/articles/blob/master/README.md, which is where we have technical instructions for editors. If you agree I'll add a section this week.