Pkp-lib: Implement megajournal support

[asmecher]

See http://pkp.sfu.ca/wiki/index.php?title=Mega-Journals

[hauschke]

I cannot edit the wiki, so I'll dump my considerations here.

"Megajournal" means to me that there are no more issues. This can be handled via "virtual" issues, for example one per year. There should be a built in mode for showing the latest articles in descending chronogical order on the frontpage.

Another important feature is the ability to build "collections":
Peerj calls this "subject overlay": https://peerj.com/subjects/science-policy/
PLoS Collections: http://collections.plos.org/s/computer-information-sciences
Editors should be able to curate such a collection. Maybe it could be useful to be able to assign editors specifically to one collection, comparable to a section editor.

[asmecher]

Thanks, @hauschke, I've dropped a link into the wiki that points back here.

[ajnyga]

Hi,

Just a small comment here, hope we will see this in 3.1.

I have seen discussion about having an issues based publication or the publish-as-you-go type of publication. I think that there should be also a option for the combination of these two, namely the preprint model where you publish issues, but also want to publish single articles in advance.

What is also worth thinking is that when the articles are shown in for example OAI-PMH. I think that you do not want to show preprints there, but I could be wrong?

I have tried to do this in a plugin, but core modification would of course be a lot better.
https://github.com/ajnyga/preprints

[asmecher]

I'm not sure about OAI-PMH and pre-prints -- I could foresee any of the following use cases being desirable:

1. Pre-print included, with the finalized article "replacing" it upon publication
2. Pre-prints excluded
3. Pre-prints included, with the finalized article appearing separately upon publication (perhaps linked by relations)

Until we have a concrete request for all that complication, I would suggest door number 3.

The main feature in megajournal publication, I think, is that the means of access becomes a huge chronological list (almost like presenting an RSS feed directly rather the issues-based browse we currently have). I could see both means of browsing being important. So perhaps we should consider...

• Making sure there are enough tools to enable issue-based browsing (e.g. showing/hiding the "Archive" link, etc)
• Adding a separate, chronologically-organized browse area with similar tools to show/hide access
• Permit either to appear on the homepage ("current issue" vs chronological listing)

[ajnyga]

I agree that the main feature here is the option between the current issue based model and the new chronological model (blog model so to speak) and the latter is definitely a good feature for many journals. Probably in general publishing is moving to that direction.

I think that many issue based journals would also benefit from a "browse area", I mean a possibility to show both the issue archive and the browse area at the same time. This is probably what you meant.

The browse area could be chronological as default, but maybe there could be quick filters to re-organize it some other way as well? By section, by date/year, free search etc. This would of course come close to the search page.

For the journal front page, it would be really nice to have an easy way to add either the latest issue toc OR a short list of latest articles.

---

However, I do think that there have been a lot of requests for the preprint option as well:
http://forum.pkp.sfu.ca/t/forthcoming-articles/13793
http://forum.pkp.sfu.ca/t/cant-access-articles-in-future-issue/27730
http://forum.pkp.sfu.ca/t/future-issue-plugin/4012

The important question here is that would it make sense to handle this using the issue publishing model + a plugin? Or should this be part of the core?

If you choose to take this into the core then I think that option 3 is very possible. I do not however know how a preprint would show there, I mean how you would see the difference between that and the final version?

Worth thinking is linkage to versioning: https://github.com/pkp/pkp-lib/issues/2072
I think that if a journal is publishing preprints, then using versioning may make sense? I wonder if @lilients has thought whether the different versions would receive a label of some sort?

Also worth noticing is CrossRef support for preprints: https://www.crossref.org/blog/preprints-are-go-at-crossref/. Implementing this would however complicate things a lot more. In my plugin the DOI is not shown at all, even if it exists.

[asmecher]

@ajnyga, thanks, fully agreed.

[ajnyga]

I think that preprints are something that we will need to implement sooner or later, because there is a large demand for them at the moment. Or at least a big buzz.

When thinking this more carefully, I think that there are two separate things that I mix above:

1. preprints = publishing manuscripts even before the peer review and adding ways for users to collaborate. These should be available also site wide.
2. Forthcoming articles = showing production ready articles before the issue is published. This can be handled with a plugin fairly easily: https://github.com/ajnyga/preprints (will have to rename that plugin!)

So @asmecher
Maybe we could aim to 3.2 with these two new fairly large additions:

1. Enabling the chronological publishing model described (blog model) and adding the needed tools for filtering articles
2. Enabling a site wide preprints support, described here: https://forum.pkp.sfu.ca/t/preprints-in-ojs3/33442 <= this need a new issue in my opinion, because it is actually totally different from the original issue

The filtering tools could be used in both cases, because both views are chronological by default and rely on the same metadata.

[asmecher]

@jmacgreg, I know you were working on a preprint-type display for OJS -- can you describe that here?