Pkp-lib: Adapt OMP catalog management into OJS for continuous publication

[stranack]

Providing the option in OJS 3 (or 3.1) to treat articles like stand-alone items (like books in OMP), catalog management could allow for a continuous publication option as well as give us some interesting content display choices on the journal home page.

Featured Articles, Spotlights, New Releases would all apply well in this scenario. Journals could also add major themes as categories or even create a volume or issue category.

[asmecher]

From @stranack, https://github.com/pkp/pkp-lib/issues/1397#issuecomment-218846778:

For continuous publishing, categories (as in OMP) could serve a useful purpose in OJS 3. Journals could use a feature much like the Catalogue to organize and display articles on the home page, and in categorized lists. I think it is at least worth considering, even for 3.1.

[NateWr]

I'd like to see "Sections" used for categorizing articles for continuous publishing, instead of adding a new Categories system. Any reservations there?

In terms of the UI for continuous publishing, I'd love to see us accomplish the user-facing side of this by simply removing one element in the submission metadata modal. The Publication Date could then be a "scheduled posting" so it will just go live at that date:

Should we peg this issue against a milestone so that it's not lost?

[asmecher]

Nate, I like that proposal. Nice and simple.

Some journals will probably want to use both continuous publishing and issues -- effectively there would be a pool of articles without issues that would build up somewhere, and get periodically reshuffled into issues -- so rather than forcing JMs into one track or the other we might...

• Disentangle the selection of an issue from the publishing action for an article. Currently scheduling an article into an issue either publishes the article (if the issue is published) or delegates control over publishing the issue (if the issue is unpublished).
• Make the association of published articles and issues optional in the back end. This will take some vetting of 3rd-party formats (e.g. OAI, export plugins, etc.) to ensure that they can handle articles without issues.
• Add setup options for the front end permitting a mix of presentations... (Perhaps this would be better done as e.g. a continuous-publication theme rather than adding lots of permutations?)
  
  
  
  • Enable/disable browse by issue tools (e.g. Archive listing of issues)
  
  
  • Enable/disable continuous publication presentation (on the homepage? Or would this e.g. replace the Archive page?)
  
  

[NateWr]

I think that we'll have a few homepage options in the default theme which allow a JM to kind of choose how they present their publishing schedule. For instance, I'm hoping that we'll have options to display the latest issue and/or a list of latest articles, and journals can choose what they want to prioritize.

This may not be a 3.0 thing, but I raised some of this in that email I sent out about homepage blocks.

Either way, I'm very much a fan of the idea of having a theme that's geared more directly towards continuous-publication. That's obviously a post-3.0 thing, but it makes a lot of sense to treat the frontend very differently for that model.

[amandastevens]

It would also be great if editors of journals published on a rolling basis could have more control over when to send notifications of a newly published issue or article. If an issue is published and then articles gradually added to it, the notification can only go out when the issue is initially published or if the editor un-publishes and re-publishes it.

[asmecher]

We've recently been discussing using OMP's "categories" tools for organizing special collections (e.g. based on theme).

[NateWr]

I think using OMP's categories could work. Let's think about them as broadly as possible, as nothing more than an arbitrary collection, to which any meaning can be given.

• Themes could have an option to "show collection on homepage in X slot" and that could mean: the latest X from that collection, the top X from that collection, etc.
• Sidebar blocks could be created with manually curated lists of collections. So I could have one block which lists "theme" collections, one which lists "area" collections, etc.
• Each collection archive could have a custom template if desired.

This raises some questions:

1. How will we display on an article's landing page it's inclusion in a collection? It seems to me like we would need some concept of a collection "type" to do this effectively, eg:

Area: Latin America
Theme: indigenous artwork

Otherwise our only out-of-the-box display option will be something like this:

This article is included in the following: Latin America, indigenous artwork

1. In what ways does this overlap with metadata, and should it interact with metadata? Does an article's inclusion in a collection constitute metadata? My sense is that people are typically drawn to what they can see and browse, and that means editors may focus on these categories and neglect the article metadata. If editors are focused on creating all this customized browsing data, should we instead be encouraging them to accomplish what they want by creating metadata that's part of the article's wider distribution? Would it make sense to make our metadata provision more robust, and tie the collections feature-set to that?

[mlafl]

I'll just add that, while for some journals, being able to define a collection type would probably be useful, at CA we're just envisioning one type. The question about metadata is an interesting one: just a reminder, though, that we'll be grouping previously published articles into collections and so it would be a question of updating metadata for those articles, rather than including it in initial distribution.

Also, in terms of showing a collection on the journal's homepage, we would want to display a teaser from the intro text and possibly an image, rather than the latest or top article to be included in the collection. The idea (on the homepage) is to present the collection as a unit, rather than calling attention to its constituent articles.

[ajnyga]

There are many issues here that discuss the continuous publication model (one of the oldest issues here https://github.com/pkp/pkp-lib/issues/382) and/or things connected to it. I am finding it hard to follow what kind of selections are being made.

This is a major feature in OJS and connected to many things in the system (versioning, preprints, ahead-of-print features, DOIs, DOAJ registration and other metadata exports, OAI-PMH etc.). Maybe a clear roadmap of the planned features would be a good idea at some point before actual coding starts to happen?

[asmecher]

Agreed, @ajnyga. I suggest hiving off the discussion of curated collections (categories in OMP) to https://github.com/pkp/pkp-lib/issues/4158. I'll have a look through other Continuous Publication related issues and bring them together in a project, or else link and close the others if one is a clear leader.

[mlafl]

Sorry, all, didn't mean to fork the thread in a different direction!

[asmecher]

Not at all, @mlafl, we're constantly in the process of re-organizing this crazy thing.

[mfelczak]

Just wanted to add a +1 to provide editors with more control over when to send notifications for newly published issues or articles. We have received requests from hosted journals that would like to send a new notification each time a new article is added to an existing, continuous publishing issue.