Open peer review of the preprint in the public journal website

Describe the problem you would like to solve
We need to manage open peer review of the submission in the public journal website, made of submission import (if preprint is already published in a preprint servwer like OPS), immediate publication (or link to the preprint server) and publication of the review stage (all passages)

Describe the solution you’d like
We think that OJS/OMP should allow submitter to import manuscript from preprint server (at least by DOI), then OJS/OMP should publish it in a dedicated part of the journal website. Moreover, OJS/OMP should publish all the steps of the review stage. At the end, if the manuscript pass the peer review the final version should link to the preprint page with review stages, or all the data should be published in the article landing page e.g. in a separate tab called “review”.

Who is asking for this feature?
Milano University Press, Journal Editors, Journal Administrators, Authors, Reviewers

Additional information
Alternative solutions can be implemented, e.g. OPS could manage the open peer review with OJS/OMP importing the manuscript and review and starting the workflow from copyedit

Hi @bolelligallevi,

There are three parts to this, I think:

1. Transfer of submissions from OPS to OJS

Using the SWORD protocol, submissions can be turned from OPS submissions into OJS submissions. To do this, you’ll need two plugins:

  • In the OPS installation, the SWORD Client plugin (previously called the SWORD plugin), and
  • In the OJS installation, the SWORD Server plugin.

We are currently working on some refinements to these that’ll make them more user-friendly, but the basics are already there.

2. Presentation of unpublished content on the OJS website

To present content on the OJS website before it has formally finished the publication process, you can use the Forthcoming plugin (https://github.com/ajnyga/forthcoming). Unfortunately this is not yet compatible with OJS 3.3.0, I don’t think, but updating it would not be a tremendous amount of work.

3. Presentation of OJS reviews on the journal website

This can be achieved using a plugin or even a child theme plugin, which would augment the existing article display to show peer review content.

Does that sound like a comprehensive summary of the pieces that would be required, @bolelligallevi?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher, thanks for your answer.
On point 1, thanks for insight on OPS to OJS communication, I have not tried OPS yet but I think the refinements you are working on match the possibility to have an open peer review path involving the two apps.
On point 2, open peer review involves the manuscript before and during the publication process (precisely the review stage), i.e. the preprint, while the forthcoming plugin shows online firsts, i.e. published version before issue publication (maybe @ajnyga can give more details).
In other words, OJS content I need to be published is:
a) the submission manuscript, as provided by the submitter or transfered by OPS
b) all the data (reviewers, decisions, manuscript versions…) of the review stage
Is that possible now?

On point 3, can you confirm that a plugin or a child theme could show all the data I mentioned before in b)?

Finally, trying to be more clear on requirements, I would like OPS/OJS could manage open peer review in a similar way to https://open-research-europe.ec.europa.eu/
That could mean (on a future development point of view) that OJS and OMP should manage manuscript and review data publication by default as open peer review features.

Thanks and best regards
Stefano

Hi,

Yes the plugin mentioned is meant for publishing articles before they appear in any issue. So it is not for preprint at all. On the background an issue labeled as “Forthcoming” is still used. The plugin also takes advantage of versioning meaning that version 1 is published in the forthcoming issue and version 2 is then scheduled to the actual issue.

Note that there are always ways the OJS might change that will affect how the plugin works. For example there has been discussion on whether the issue data should be stored in the submission level instead of the publication level. This would affect the way the plugin works. I have not yet considered how it would work after such changes.

The reason I still use issues in the background is that OJS requires an issue for a published article. It is difficult to show article data using the default article handlers without it, impossible that last time I tried. Also things like statistics and DOI registration would require some own solutions in the plugin if there would be no issue set when the article becomes public. With DOIs I have not yet checked the latest main branch of OJS on how it behaves on this.

While the plugin uses the official publishing action in OJS there are limitations on which stage you can publish it (I think you need to be in Copyeditin at least?).

It would be easy to reveal article data using a plugin with its own handler. The Forthcoming plugin used to do this (see GitHub - ajnyga/forthcoming at ojs-3-1-2). As you can see, the article was made public without actually publishing it just by marking it as forthcoming. The plugin then created a public handler and fetched all submissions that had that mark. But as mentioned above, the downside was that you lost statistics and DOIs, probably something else as well.

But based on GitHub - ajnyga/forthcoming at ojs-3-1-2 branch you could try writing a more complex preprint plugin for OJS.

The big thing to solve would be statistics and DOIs.

With statistics the problem is that the stats features in OJS search for a particular kind of url paths. The paths are used to recognise what was loaded. When you have your own handler path, the stats actions will not notice those in the log file. I know that the stats have been rewritten, so not sure if that could be affected now. But you would also have to solve how to show those stats, because they would be separate for the preprint and for the article.

With DOIs the problem is that for a preprint you would require a separate DOI. It can not bee the same as the one for the final article. So you would have to have an inbuilt action in the plugin for creating and storing DOIs to the metadata AND registering it when the preprint is made public. From the top of my head I would say that this is actually the most work in the plugin.

Hi @ajnyga, thanks for your hints.
What if open peer review of preprint whould be managed in OPS?
I think that this would solve all the problems you mention: it would be possible to assign a DOI there, it would be possible to avoid problems related to issues, it would be possible to develop stats related to preprint in OPS (if not already developed).
In a workflow OPS->OJS, the open peer reviewed preprint could be published in OJS jumping the review stage, with a separate decision (e.g. “already reviewed”) or using the possibility to skip review already built in.
Finally, this solution is probably similar to current best pratice: open peer review of preprints hosted in preprint servers is managed separately and previously from submission to journal.
Best regards
Stefano

Hi,

Using OPS is of course an easy solution if you do not have to solve this inside OJS.

Like @asmecher mentions above, there is also a SWORD plugin for moving submissions between the two systems.

Hi @ajnyga, thanks for your answer.
Is not clear to me if OPS can assign DOIs to preprints, do you have any hint?
There is also the problem of review, I think it is missing from OPS now, am I right?
So the problem is: adding review to OPS (maybe a review only devoted to open peer review) is more or less effort than apply changes to OJS to manage early publication of submission files?
@asmecher, can you help on this? Below the request rewritten using OPS for preprint DOIs and open peer review.
Best regards
Stefano

Describe the solution you’d like
We think that OPS could assign a DOI to the preprints and then manage the review (assigning DOI to review itself should be considered),publishing all review data.
Then preprint could then be passed to OJS/OMP by sword, and OJS/OMP should publish at least a link to the preprint and open peer review in OPS.

OPS already supports DOIs for preprints and has a plugin for Crossref

Concerning the review part, it depends what kind of review you are thinking. There is no inbuilt public commenting system in OPS. You can create a plugin that will allow public commenting like GitHub - ajnyga/disqus: Disqus plugin for OJS/OPS/OMP 3.2+ or GitHub - asmecher/hypothesis: A Hypothes.is integration plugin for OJS

These are examples of plugins that use 3rd party commenting but of course you could create one that has it’s own db tables in the OJS installation. It really depends on what kind of commenting you are thinking of.

There is also the PREreview used in
SciELO Preprints, for example: https://preprints.scielo.org/index.php/scielo/preprints-review

SciELO Preprints also uses the Hypothes.is mentioned by the @ajnyga. You can see examples of its use in production at: https://preprints.scielo.org/index.php/scielo/annotations

1 Like