[OPS] Rewording of preprint "relations"

[alexxxmendonca]

This is neither a bug or a feature request, but I feel like this falls a little more into the "feature request" category.

Describe the problem you would like to solve Currently, the "Relations" lists the following predetermined statuses:

• Preprint has not been submitted for publication
• Preprint has been submitted for publication in journal
• Preprint has been published in a journal as an article

The above needs to be reworded because it does not fit in all cases.

All preprints should show a warning stating that the preprint has not yet been peer reviewed by a journal (that is, until they actually do and the status changes).

The first and second statuses, "Preprint has not been submitted for publication" and "Preprint has been submitted for publication in journal" are ultimately stating the same thing: the preprint has not yet been peer-reviewed by a journal.

In the second status, it's not a given that the paper will get accepted. In case the paper doesn't get accepted, the author might as well decide not to ever submit the paper to any other journal and let the preprint as a preprint. Therefore the status would have to change back to "Preprint has not been submitted for publication" (even though it has been, it just wasn't accepted).

Therefore, statuses 1 and 2 should be a combination of "Preprint has not been peer-reviewed by a journal"

The 3rd status, "Preprint has been published in a journal as an article" needs rewording too.

1) It would be good to be able to add the journal title. 2) The preprint might not be an article so we should avoid using the term "article". Preprints can be documents other than articles.

Describe the solution you'd like SciELO proposes a rewording to the following:

• Preprint has not been peer-reviewed by a journal
• Preprint approved by a journal and not yet published
• Preprint has been published by a journal

The second status is used when a journal accepts a paper and wants to quickly share it as a preprint. A lot of journals are doing that (including SciELO journals) during the COVID-19 pandemic.

There is more information about these two types of preprints (from authors/from journals) in this article: https://www.scholcommlab.ca/2020/04/08/preprint-recommendations/

Who is asking for this feature? Readers and users of OPS in general.

Additional information Status 1 is currently not showing in any preprint that is posted. Specially after this implementation, all statuses should always be shown.

[ajnyga]

A related comment from John here: https://github.com/pkp/pkp-lib/issues/5957#issuecomment-669588968

[ajnyga]

The suggestion above changes the translations and the content of the current three statuses in a way that will affect all translations. Therefore, I would like to hear from native speakers before going forward with any changes here: @asmecher @NateWr ?

The Journal name could be maybe fetched based on the DOI?

If we change the labels like suggested above, can we assume that all preprints submitted to a journal are peer-reviewed before being published? We could have cases with review articles etc. maybe?

Currently the landing page mentions has a "Preprint" label above the fold as suggested by Crossref. A server could add more "warnings" either by editing their theme or we could add more warnings to the default theme as well. Again something where I would need input from other's as well.

[alexxxmendonca]

If we change the labels like suggested above, can we assume that all preprints submitted to a journal are peer-reviewed before being published? We could have cases with review articles etc. maybe?

This is a very valuable point and I've been meaning to reconsider the original suggestion to:

• Preprint has not been published by a journal
• Preprint approved by a journal and not yet published
• Preprint has been published by a journal

That way, whether the published article has been peer reviewed or not depends on the journal's editorial policy.

[NateWr]

Yes, that's a good update @alexxxmendonca. I'm also worried about "Preprint approved by a journal and not yet published". Each of the existing options can be validated by anyone. If someone says that something is published, I can go and validate that this is true. However, if an author says that a preprint is approved but not yet published, there's no way for me to validate this claim.

I know that Scielo has a close relationship between the preprints it publishes and the journals where those preprints are published. So it makes more sense for you to make this assertion. But I worry about having this as a core option, and what it would mean for the integrity of preprints where there is less coordination between the preprint server and journals. There is room here for scholars to misuse this assertion to claim an article is forthcoming when it is not, and scholars have a lot of incentive to make this claim.

I think that this is an area where a plugin could be used. It would be fairly easy to extend the form with a plugin for Scielo's use-case, so that the additional option was available in Scielo.

[alexxxmendonca]

Hi @NateWr

I understand the concern, but I also need to point out that the preprints posted in SciELO Preprints are not necessarily submitted later to a SciELO journal. What I am trying to say is that to some extent we won't have that control either -- if a preprint is accepted by a non-SciELO journal, there is no way for us to certify that.

Preprints are author-centric and we need to find the right balance between offering authors freedom while at the same time being responsible to what is shared at the server.

With that being said, are we still going for 3 relations choices? What are we going to do with number 2?

[NateWr]

With that being said, are we still going for 3 relations choices? What are we going to do with number 2?

So I still think that (2) is a meaningful distinction from (1). My understanding is that a scholar may put a very early draft up as a preprint, either because they want to practice open/collaborative science or because they want to stake a claim to being the first to a research finding. In such cases, I think moving from (1) to (2) is a signal from the author that they believe their paper is now ready for submission.

I could be wrong on this, though. It is probably worth looking at what other preprint norms are around the status of preprints. @jalperin, would you have any insight here?

[alexxxmendonca]

I should also add that several preprints servers, including SciELO Preprints, accept post-prints, which are exactly that: articles that have been accepted for publication by a journal but are not yet published.

It isn't a SciELO only policy and other preprint servers (arXiv, for instance) do this too.

[NateWr]

other preprint servers (arXiv, for instance) do this too.

Do you know what different statuses they support, what their wording is, and who is authorized to set those statuses?

[alexxxmendonca]

Do you know what different statuses they support, what their wording is, and who is authorized to set those statuses?

I am not 100% sure but I think they are using the "Comments" section to inform that, very freestyle.

Check here: https://arxiv.org/abs/2010.02944?context=astro-ph.GA (use the "< prev" and "next >" buttons on the right sidebar to navigate).

[NateWr]

Thanks! Yeah that doesn't seem like a great approach to me... Let's see if Juan has any input based on his preprint research.

[alexxxmendonca]

Thinking again about this, I think we can keep them as they originally were:

• Preprint has not been peer-reviewed by a journal
• Preprint approved by a journal and not yet published
• Preprint has been published by a journal

The concern was whether we could assume that every journal does peer-review and we know for a fact that it's not true. Some journals don't perfom peer-review. However, while the preprint is still a preprint, it's safe to say that it hasn't been peer-reviewed by a journal.

Even if it gets accepted by a journal that does not perform peer-review, the final status doesn't mention anything about peer review:

• Preprint has been published by a journal

We could leave the editorial policy of whether the journal does peer review or not up to the reader to find out,

I agree that we can't assume that every Version of Record is peer-reviewed, but we can definitely assume that a preprint in its initial form has not been peer reviewed by a journal.

I think it's important to highlight the fact that it's not been peer reviewed by a journal. I feel that after our discussion, that detail has lost a lot of weight.

What do you think?

[NateWr]

I think we should seek more feedback on this. The more I think about it the more uncomfortable I am with the declarations in general. I looked at the preprint recommendations you linked in your first comment, and they only suggest a distinction between unpublished preprint and published (peer-reviewed) record.

Our system only ever deals with the first. The "Relations" form we're discussing is not really about defining the status of the preprint we're hosting, but about linking to other versions of the preprint elsewhere (like a published one in a peer-reviewed journal).

The recommendation document makes a presumption that the published (peer-reviewed) record is hosted on the preprint server as well, which I think is not going to be the case and anyway is not how our Relations form is set up.

At the moment, I'm leaning toward reducing our Relations to just two options: not published and published. This is also the only two options to which we can attach meaningful metadata. For example, we either add a linked version's DOI to the Crossref deposit or we don't.

Is there any other status information that we should be providing to Crossref based on these options? I think we need to look at what metadata we can provide, and work backwards from there to provide clear descriptions that accurately map to that metadata. And I suspect that the status information (whether something has been peer reviewed or not) is going to need to be attached to a specific version, not necessarily the preprint as a whole.

[asmecher]

(See also CrossRef Relations; I don't think JATS provides as typed a standard here.)

[jalperin]

In our recommendations, we suggest 2 top-level distinctions: published elsewhere and not published elsewhere. Then, between those, we suggested a few sub-categories:

1. unpublished record (preprint):
   • first preprint version: the first version shared with the public.
   • updated preprint version: an updated version of a previously posted preprint. Ideally each updated version should contain a version number and include description of what has changed from the previous version. Version numbers can be sent to Crossref (I think) or at least could be handled with Versioned DOIs.
2. published (peer reviewed) record:
   • record accepted for publication: the version of the record that has been accepted for publication (i.e., after peer review but before final typesetting and editing). In Crossref, this type of record is classified as “pending publication.”
   • version of record: the version as it appears in another publication (e.g., scientific journal, conference proceedings, book, etc.).
   • updated version of record: a revised or updated version of the version of record. It may include changes introduced due to post-publication comments or discovered errata.

I am not sure how this last one can be indicated in metadata. The "relation" would be to the published DOI, but it would be good to have some marker, that the author could select, saying that the preprint has been updated since publication.

[ajnyga]

(See also CrossRef Relations; I don't think JATS provides as typed a standard here.)

Yes, isPreprintOf is the relation Crossref is interested about and that we can add to the deposit data based on the VoR DOI given for status 3 in the current relations fields. This I do not have in the Crossref plugin yet, but will get it there after a decision here. The versioning relation is already present in deposits and uses the isVersionOf relation.

When I made the current three options I looked both at Crossref recommendations and the recommendations Juan mentions above. It was definitely an initial set of options.

The current option 2 could be something of interest to Crossref as well, but I am not sure if the posted content schema has a field for this information. It is more "nice to have" on the landing page, unless we decide otherwise.

[NateWr]

I've had some time to think about this and I think that there are two concerns here that need to be split out:

1. Identify the relationship of a preprint to a published version of record that is not hosted on the preprint server.

2. Identify the status of a preprint, including whether a particular version is a major or minor revision, whether it has been accepted for publication, and whether the preprint has been updated with the version that was accepted for publication.

I think the Relations setting in OPS handles number 1 and I think this needs to be an either/or relationship to reflect the precision of the underlying metadata. A preprint either has a published version of record or it doesn't, and OPS should capture this version of record, ideally in a machine-readable format like a DOI. This asserts a relationship in order to aid discovery, but should not make assertions about whether or not something has undergone peer review. The quality of machine-readable metadata is important here. I'd even suggest that we don't allow a version of record to be indicated without providing either a DOI or a URL to that version of record.

OPS does not currently allow any indication of the status of a preprint (2), but it should. The status needs to be handled separately from the relations, because any assertions made about the status of a preprint must be made about a specific version of the preprint. To do this, we probably need to look at proposals to track publication types and summaries, and adapt this to work with preprints. When publishing a particular version of a preprint, the author/moderator should be prompted to provide the necessary information about the new version: is it a major or minor revision, does it reflect a "pending publication" (ie - include all revisions made to pass peer review)?

With the status of the preprint, we still face the question about the accuracy of the information being asserted by authors. As questions are being raised about the integrity and validity of preprints, I think we should tread carefully. However, it does seem that a preprint server is more like a social network, where the author is considered to be the "one making claims". The preprint server is not necessarily providing a stamp of approval in the way that a journal does when it publishes an article.

As long as we clearly identify the status information as something that is provided by the author, I think it's ok to make assertions about peer review status or pending publication, even when these assertions can't be validated. The arXiv example that @alexxxmendonca provided above lists this status information under a "Comments" section, which seems like an appropriate indication of the source of the information.

Sorry for the long text. But does this sound like it addresses the concerns raised in this issue? Would this solution let us provide the information that @jalperin recommends while also accounting for the need to make reliable assertions about related publications?

If this sounds ok, I can try to draw up some more specific recommendations to work on.

[alexxxmendonca]

A preprint either has a published version of record or it doesn't, and OPS should capture this version of record, ideally in a machine-readable format like a DOI. This asserts a relationship in order to aid discovery, but should not make assertions about whether or not something has undergone peer review. The quality of machine-readable metadata is important here. I'd even suggest that we don't allow a version of record to be indicated without providing either a DOI or a URL to that version of record.

Agreed.

When publishing a particular version of a preprint, the author/moderator should be prompted to provide the necessary information about the new version: is it a major or minor revision, does it reflect a "pending publication" (ie - include all revisions made to pass peer review)?

I see value in this and some preprint servers have that. It would be great if OPS could have it too.

However, it does seem that a preprint server is more like a social network, where the author is considered to be the "one making claims". The preprint server is not necessarily providing a stamp of approval in the way that a journal does when it publishes an article.

Agreed.

provided by the author,

I think that's key.

So are we completely ignoring the "post-print" relation where it is known that a preprint has been accepted but not yet published by a journal?

[NateWr]

So are we completely ignoring the "post-print" relation where it is known that a preprint has been accepted but not yet published by a journal?

I don't think we are ignoring it. But we are redefining it as a particular version rather than a relationship. So it would no longer be in the Relations area. Instead it would be captured when publishing a new version of a preprint. Does that sound right?

[alexxxmendonca]

Is it going to be visible for the reader at the user interface?

[NateWr]

Yeah I think any version summary would be visible on the article/preprint landing page.

[alexxxmendonca]

Then it should be alright!

[ajnyga]

@NateWr So to sum up, should I now:

1. Change the relation pull down menu to include two options
   • Preprint has not been published by a journal
   • Preprint has been published by a journal (+ the option of adding a DOI)

• Note, do we want to talk specifically about journals? The preprint could end up as a book chapter as well?

2. Add a new option where the author can describe on publication level the status of the preprint. This is then shown on the public landing page as well.
   • Where should this setting go to?
   • What kind of setting are we talking about, a free text field?

[alexxxmendonca]

The preprint could end up as a book chapter as well?

Yes, this could happen. It's a very good point. Maybe we shouldn't restrict it to journals.

Maybe something like:

• This preprint has not been formally published
• This preprint has been formally published (+ the option of adding a DOI)

What kind of setting are we talking about, a free text field?

A free text field should be enough. If we need to have specifics and if we want to run some reports, we could add options "Minor revision" or "Major revision" for the author to select prior to submitting a new revision.

[alexxxmendonca]

Back into the topic of adding a relation field to treat "postprints" (preprints that have been accepted by a journal but not yet published), SRRN does something interesting where they indicate the name of the journal where it's supposed to soon be published: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3690578

"Latin American Research Review, Forthcoming"

[NateWr]

Change the relation pull down menu to include two options

• This preprint has not been published.
• This preprint has been published (+ option to add DOI)

Add a new option where the author can describe on publication level the status of the preprint.

Let's take this to https://github.com/pkp/pkp-lib/issues/4860. We'll need to line this up with metadata/depositing standards.

@alexxxmendonca can you add that information on preprint status to this issue?

[ajnyga]

This preprint has not been published.
This preprint has been published (+ option to add DOI)

Why do I have the feeling that saying that the "preprint has not been published" will confuse people? Will they confuse that with the preprint being posted.

[alexxxmendonca]

Which is why I suggested "This preprint has not been formally published"

It might not be the perfect solution (open for suggestions here) but we need a solution that is broad enough to include journals, books and other types of formal publications.

[NateWr]

Yeah I get the ambiguity here but I think "formal" just compounds the problem because it's not clear what "formal" means. All we're doing is asserting a relationship, not saying anything about that relationship. Let's try:

This preprint has [not] been published elsewhere.

[alexxxmendonca]

This preprint has been published elsewhere.

This could work.

What about using Version of Record?

Does anyone know if the concept of Version of Record is exclusive to journals?

This preprint has a Version of Record: [DOI]

[NateWr]

I don't think Version of Record is widely understood among academics. And also we should accommodate preprints published in non-scholarly locations: reviews, editorials, government reports, etc. If a preprint wants to, it can easily use more specific terminology simply by adjusting the locale string.

[ajnyga]

I agree that VoR might be an unknown term. We don't want another "galley" to the system right? :D

Also with a short googling it seems that it almost always refers to a journal article. Of course I have to admit that I do not know for sure to what extend the term preprint is used in other cases than journal articles? But I do think that if we have the option, we should choose a translation that covers as much ground as possible.

[asmecher]

We had a discussion on Slack about how to move forward practically (@ajnyga, @alexxxmendonca, @carolinatanigushi, and @NateWr) and are OK with the following principles:

• Separate Relations (links to other forms of the submission, primary published journal articles) from Status (whether it's been submitted elsewhere, peer reviewed, etc). Relations can be dealt with here, and Status will be dealt with in https://github.com/pkp/pkp-lib/issues/4860.
• Keep this issue focused on what is machine-readable and verifiable. For example, we can't know that something was published in a peer-reviewed journal just because we have a URL or DOI to an article in an OJS instance.

Practical steps:

• Adjust the "Relations" dropdown so that it has two choices:
  • This preprint has not been published elsewhere.
  • This preprint has been published elsewhere (+ option to add DOI)
• Implement an upgrade such that the previous options "Preprint has not been submitted for publication" and "Preprint has been submitted for publication in journal" both map to "This preprint has not been published elsewhere."
• Ideally, implement enough of https://github.com/pkp/pkp-lib/issues/4860 so that the distinction between the above two Relations options gets captured for use there rather than discarded on upgrade.

[ajnyga]

OPS: https://github.com/pkp/ops/pull/334

[jalperin]

Recent recommendations from CrossRef: https://t.co/br4zGCYKYs

On Sun., Aug. 21, 2022, 22:44 Antti-Jussi Nygård, @.***> wrote:

OPS: pkp/ops#334 https://github.com/pkp/ops/pull/334

— Reply to this email directly, view it on GitHub https://github.com/pkp/pkp-lib/issues/5774#issuecomment-1221863251, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA7UZUP5YWAR44PRQI6ND3V2MHTJANCNFSM4MOMXALQ . You are receiving this because you were mentioned.Message ID: @.***>

[asmecher]

@jalperin, was there something specific there that's related to this proposal?

[ajnyga]

Was going to ask the same thing!

Section 6 talks about this topic, but mostly about automation in this field whereas the functionality we now have is purely manual.

[alexxxmendonca]

That's right. There's no recommendation on the actual wording, only at the metadata level.

[jalperin]

It was section 6 that seemed relevant, and it also seemed generally useful to know what CR is recommending.

Apologies if not directly applicable. Wanted to share and this seemed like a useful place to do so.

On Mon, 22 Aug 2022 at 11:21, Antti-Jussi Nygård @.***> wrote:

Was going to ask the same thing!

Section 6 talks about this topic, but mostly about automation in this field whereas the functionality we now have is purely manual.

— Reply to this email directly, view it on GitHub https://github.com/pkp/pkp-lib/issues/5774#issuecomment-1222750507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA7UZQRUJPNITENU34M7RTV2PALFANCNFSM4MOMXALQ . You are receiving this because you were mentioned.Message ID: @.***>

[ajnyga]

no problem, we maybe need a new issue to track down discussion around the automation and need to add the Crossref guidelines there. Or is this more a topic for github discussion? @asmecher

[asmecher]

If it's a specific proposal (scoped, concrete, somewhere on the horizon as a priority) then either a Github issue or a discussion would be OK. If it's just aspirational ("someone should review this and see if there's anything for us to do") then no, I don't think it's worth creating an entry.

[ajnyga]

Just thinking that it is probably something we want to pursue at some point when the infrastructure is available, but was not sure how you want to track these kinds of things.

btw, the test passed for this https://github.com/pkp/ops/pull/334 so it would be ready for review

[asmecher]

Thanks, @ajnyga, and sorry for the wait. I've just added some minor comments to https://github.com/pkp/ops/pull/334; please have a look and let me know, and I'll get it merged!

[asmecher]

Merged -- thanks, @ajnyga!