Support version types and summaries

[NateWr]

Update

See https://github.com/pkp/pkp-lib/issues/4860#issuecomment-535934794

Original Comment

Publications should introduce three new data fields: publicationSummary and publicationDateType.

• [x] Discuss what types of publications we should support and if there is an existing third-party specification we want to follow. The obvious examples for us to start are preprint and publication. But if there's a standard to follow, that'd be great. This should be a controlled list. Conclusion: JATS uses publicationDateType and there is no need for a separate publicationType.
• [ ] Add a select field for the publicationDateType from the list supported in JATS: https://jats.nlm.nih.gov/archiving/tag-library/1.1d1/n-u252.html
• [ ] Add a text input field for publicationSummary that allows someone to enter a short description of the version. Think of this like a commit message.
• [ ] Use the publicationDateType and publicationSummary in the publication UI, to identify the versions in the version dropdown.
• [ ] Add the publicationDateType and publicationSummary to the reader interface to identify versions.

[NateWr]

@ajnyga on possible publicationTypes:

Crossref supports preprints and articles, JATS has this, but no defined set of values https://jats.nlm.nih.gov/archiving/tag-library/0.4/n-ugk2.html then there is this: http://vocabularies.coar-repositories.org/documentation/version_types/ note that it does not have a value called "preprint", in OJS context preprint would be "submitted version" but the COAR vocabulary is probably the most detailed

I think we should definitely look at what Crossref supports and consider following them as a standard since it links up with DOIs and other key things we're working with.

[withanage]

Hi @NateWr , I added the comments and thoughts between the lines.

Discuss what types of publications we should support and if there is an existing third-party specification we want to follow. The obvious examples for us to start are preprint and publication. But if there's a standard to follow, that'd be great. This should be a controlled list.

Add a select field for the publicationType from the options we settle on above in the publication UI, as well as adding validation rules for them.

In Onix they have publishing status, which only addresses the status related to selling.

https://onix-codelists.io/codelist/64

My suggestion would be to consider the best practise guide-lines from here.

https://jats.nlm.nih.gov/extensions/bits/tag-library/2.0/attribute/publication-format.html

Add a select field for the publicationDateType from the list supported in JATS: https://jats.nlm.nih.gov/archiving/tag-library/1.1d1/n-u252.html

yes, this list is also the same for books, therefore I also think this is the best possible. https://jats.nlm.nih.gov/extensions/bits/tag-library/2.0/attribute/date-type.html

Add a text input field for publicationSummary that allows someone to enter a short description of the version. Think of this like a commit message.

Sure a short description is very nice to have. I also would prefer the message in multilingual.

JATS/BITS has a event description concept for that.
https://jats.nlm.nih.gov/extensions/bits/tag-library/2.0/element/event.html

<pub-history>
<event>
<event-desc>pre-conference proceedings</event-desc>
<date iso-8601-date="2013-07" date-type="pub" 
publication-format="online">
<month>July</month><year>2013</year></date>
</event>
<event>
<event-desc>post-conference proceedings</event-desc>
<date iso-8601-date="2013-10" date-type="pub" 
publication-format="online">
<month>October</month><year>2013</year></date>
</event>
</pub-history>

Use the publicationType and publicationSummary in the publication UI, to identify the versions in the version dropdown.

Sure, I agree.

Add the publicationType and publicationSummary to the reader interface to identify versions.

Only addtion here is, may be there can be a future requirement to display date alongside the type and summary or only type and date without summary.

[NateWr]

Thanks @withanage!

It doesn't look like Onix or the BITS publication-format is a good fit for this (though maybe properties to add to OMP).

I am looking for something that specifies the version itself -- ideally something like preprint, publication, revision, etc. Maybe the publicationDateType is the appropriate place for this, and we should abandon publicationType until we've found a suitable standard.

Sure a short description is very nice to have. I also would prefer the message in multilingual.

:heavy_check_mark:

a future requirement to display date alongside the type and summary or only type and date without summary.

Yeah, this will likely be something changed on a theme-by-theme basis. And if we remove publicationType then using the publication date, publicationDateType and summary will be useful.

[withanage]

I am looking for something that specifies the version itself -- ideally something like preprint, publication, revision, etc. Maybe the publicationDateType is the appropriate place for this, and we should abandon publicationType until we've found a suitable standard.

Yes, I agree publicationDateType with the chronological order can cover the revisions for the submissions.

Submission Workflow

accepted, corrected, received, resubmitted , retracted, rev-request, rev-recd with date and summary.

https://jats.nlm.nih.gov/archiving/tag-library/1.2/attribute/date-type.html

Galley

pub , Preprint

The names are used in very different ways by large publication houses.

preprint = "Advance online publication"

https://www.nature.com/nature-research/for-authors/publish#about-aop

One thing which can also be a long-term requirement is , how to associate a specific workflow version with a galley version? Or even search for a specific published version of a submission workflow file. I think sooner or later, this will also come.

[NateWr]

One thing which can also be a long-term requirement is , how to associate a specific workflow version with a galley version? Or even search for a specific published version of a submission workflow file. I think sooner or later, this will also come.

Hopefully later... :joy: We don't have any way to make this association with the implementation we're pursuing now, and to do so would require a major intervention into the workflow. For now, we've managed to separate out versioning from the workflow in order to limit our refactoring work.

[NateWr]

COAR released a new version July, 2019: https://www.coar-repositories.org/activities/repository-interoperability/coar-vocabularies/deliverables/

[NateWr]

It looks like the only meaningful entries for publicationDateType at this time are preprint, pub and corrected. Since we won't support preprints in 3.2, that leaves pub (the original publication date) and corrected (all other versions).

This doesn't provide us with much information, and the data would probably be better handled automatically based on a journal's publishing workflow, rather than making editors set it for each version (and likely set it incorrectly). I'm going to leave it out for now. We can revisit this down the road if things change.

I'm also going to put publicationSummary on the backlog for now, so it won't be included with v3.2. It would be nice to have a summary of revisions, but whether to make it a text field or a tinymce field is up for debate. And in either case I think we can ship without this and add it as requested.

[alexxxmendonca]

When dealing with preprints, two (ideally three) statuses should be taken into account:

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

Ideally, one third option would sit between those two mentioned above, to be used for cases where the preprint has been accepted in a journal but not yet published (also known as "postprint"):

• This preprint has been accepted by a journal but not yet published

SRRN preprint server indicates 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"

Preprint authors as well as preprint server managers should be able to change these statuses. Such changes should appear immediately at the preprint landing page as labels:

[NateWr]

I don't think that we'll make a formal distinction between publication status unless those distinctions are mirrored in widely adopted third-party systems (ie - JATS/Crossref). Any distinctions which don't emerge from such standards will need to be accounted for through a generic text field that describes the status.

As far as I'm aware, none of these systems use forthcoming as a status or indication. But perhaps others know if they do support such a status and how.

[alexxxmendonca]

@NateWr that makes sense.

An optional generic text field further describing the status is desirable, unless there is support for such a status.

[NateWr]

I've converted this to a feature request on the forum. Please add any future comments there.

[asmecher]

Hi @Devika008 and @defstat! I've run through this with Dimitris and he's interested in working on it. I've updated the issue summary as it was quite old. Devika, Dimitris has some things to work on before he'll need design work to get further.

[ajnyga]

This is an important feature and closely connected to continous publishing and showing things like "Forthcoming articles". Ideally we should be able to query content based on the version type also in the frontend. My Forthcoming plugin does this now based on the Issue. One of the issues is marked as forthcoming and an article version attached to that issue is shown in the Forhtcoming page. When a new version is published, that is attached to the actual issue it belongs to. This would work far better if I can say that this version of the article is "AM" and would be able to build a frontend handler to show these versions.

The feature is closely related to something we have suggested in the CRAFT-OA work which is Content Types. By content type I mean things like editorials, reviews, peer-reviewed articles, news etc.

[bozana]

Maybe also a note that Crossref understands/uses these update types: addendum, clarification, correction, corrigendum, erratum, expression_of_concern, ew_edition, new_version, partial_retraction, removal, retraction, withdrawal. S. https://www.crossref.org/documentation/crossmark/participating-in-crossmark/#00279

[defstat]

@Devika008 I am checking the workflow on the figma added to the first issue comment. I see the following Publication naming:

I think that if a version stage is assigned to a publication, then the naming will be something like "Accepted Manuscript M.m" for example "Accepted Manuscript 1.0".

[Devika008]

Hi @defstat

I think there was a discussion where naming it with DD-MM-YYYY made much more sense than naming it with M.m or did I get the discussion wrong ? Have shared it with you on Mattermost!

Was it just Unassigned Version or was it all versions?

[defstat]

Hi @defstat

I think there was a discussion where naming it with DD-MM-YYYY made much more sense than naming it with M.m or did I get the discussion wrong ? Have shared it with you on Mattermost!

Was it just Unassigned Version or was it all versions?

Hi @Devika008 thanks. I think that the date distinction will apply only for "Unassigned Version". When ever there will be an assigned version stage like "Author Original" or "Version of Record", for example, the "Major.minor" version numbering will be applied, like "Version of Record 1.0" for example