Preprints: All metadata values should be tied to a single version

[alainna]

Is your feature request related to a problem? Please describe.

Currently Janeway supports multiple file versions, but only one persistent set of core metadata values. However preprints are mutable and their metadata are too.

A preprint may start as a preregistration, then move to preprint/manuscript to author’s accepted manuscript to postprint, and authors expect that each version is clearly labeled and identified. One version may also need to be withdrawn and not simply updated by a new version, and that version’s withdrawal status should be clearly identified. Finally, Crossref recommend that versions include a brief note indicating the change between versions. (Ref: Crossref Preprint AG recommendations - 2022, sec 5.2.2.b )

As Preprint Administrators, we expect that every version of the preprint be represented on its own page and with its own unique identifier. Each version page would represent all metadata related to that version of the preprint; non-current versions should have a prominent link to the current version’s page. It should include clear identification of how to cite that version, whether it is the latest version, and a note about what differentiates that version from previous versions.

Describe the solution you'd like

1. A “preprint” should be a collection of versions:

• Canonical URL: The canonical URL for the preprint should be the URL currently used, e.g. /repository/view/1000 The canonical URL should display the metadata and PDF/files for the latest version of the preprint, as well as link to
• Canonical PID: The main PID (DOI) for the article should resolve to the canonical URL
• Version URLs: Each version should have its own accessible URL, e.g. /repository/view/1000v2 There should be clear indications as to the version’s status (e.g. withdrawn, superseded by newer version)
• Version PIDs: Each version should have its own PID which directs to the corresponding version’s URL and which notes that it is a “version of” the canonical PID
• Version type: Each version should have its own "type", which can be set by a preprint server admin (eg, pre-registration, preprint, post print). The type selected should be reflected in the preprint disclaimer ("This is a pre-registration and it has not been peer reviewed....")

2. Each version should have its own page representing the full and complete metadata for that version, along with a version note (change note):

• Each version should be formed from ID+vx, e.g. 1001v1, 1010v2.
  • When a Preprint is Published, both 1000 and 1000v1 should be immediately accessible
• The version note for the first version of the preprint should be automatically generated as per a template in the repository’s configuration settings, example: This is the first version of the preprint.

3. When a preprint is submitted, the submission metadata and PDF should be considered as “version one”:

• https://github.com/BirkbeckCTP/janeway/issues/3755 moderators expect to be able to review metadata & PDF, then click “Accept” – they are confused when they are told that they must first select a PDF to serve as version 1
  • Bug: https://github.com/BirkbeckCTP/janeway/issues/2810
• If the author updates the preprint PDF and its metadata before a preprint is accepted, that metadata and the PDF should fully replace the V1 data (upon approval from the moderator) and be considered V1. The version accept/reject template should also have a method of addressing this situation.
• https://github.com/BirkbeckCTP/janeway/issues/3087 Authors shouldn't be able to update / upload new version of rejected preprint if the repository has enabled the setting to “allow no updates of rejected / withdrawn preprints” or the item has been flagged “locked preprint - no more updates”

4. Author/moderator accessing metadata view (/repository/dashboard/<ID> or /repository/manager/<ID>) of the preprint should by default see the current version’s metadata and PDF flagged/embedded:

• They should also have the option to view/update previous versions (info/nav box at top right?)

Creating a new version / Updating preprints

5. Authors should be able to update all available preprint metadata fields (as set by Repository Admin):

• Every primary preprint metadata field should have a toggle setting “can update” which controls whether an author may edit the field when updating a preprint
• Every Additional Field added to a preprint should have a toggle setting “can update” which controls whether an author is able to edit the field when updating a preprint; by default, any Additional Field which is visible on a submission page should be set to true:

• If a field is visible to the author on the submission form but cannot be updated post-submission, there should be an automatic notice added below the field in the submission form

  and something similar in the item metadata view (/repository/dashboard/<ID>) and update/correction screen:

6. “Update preprint” needs to clarify the difference between minor updates (corrections) and major updates (new version) by reordering the options and grouping “Update PDF” and “Correction [of metadata]”.

   

   • Authors should continue to be able to make minor updates (corrections) to PDF and metadata without generating a new version: Authors may need to correct typos, etc
   • New versions should be what triggers a “new version” being created

7. Individual versions may be withdrawn:

• When requesting withdrawal, authors should have the options:
  • Withdraw specific version
  • Withdraw full preprint

[ajrbyers]

I look forward to a PR implementing this @alainna...

[alainna]

@ajrbyers I probably should split it out into multiple ones eh? 😅