Allow JEs to assemble published articles into thematic collections

mfelczak commented 5 years ago

Allow JEs to publish curated collections dedicated to journal themes.

Each collection should include the following:

introductory articles written by JEs and other authors (newly published)
list of thematic articles selected by JEs (previously published)

Introductory articles should be accessible via an article landing page like all other articles, including title, authorship, citation, etc.

All articles (introductory + previously published) included in a collection should include backlinks to the collections in which they're included on their article landing page.

JEs should be able to:

create and order collections
add introductory articles to a collection
assign published articles to a collection
order articles within a collection
publish/unpublish a collection

Some examples from a non-OJS site:

asmecher commented 5 years ago

See the related conversation at https://github.com/pkp/pkp-lib/issues/1407#issuecomment-427072025 and below.

NateWr commented 5 years ago

Introductory articles should be accessible via an article landing page like all other articles, including title, authorship, citation, etc.

Can you describe what you mean by this in more detail? What does a citation look like for an introductory article of a collection? How should it be generated in the CSL styles? Does an introductory article have galleys? Does it have metadata? If so, how is the relationship between the article and the collection defined in the metadata? If introductory articles are treated like articles in other ways, do they also need workflow and peer review?

In the example provided (Sovereignty), the introduction can be accomplished with two text fields. But if we want the introductions to be treated as full articles, we will encounter a much larger set of problems.

mfelczak commented 5 years ago

Hi Nate, a few follow-up thoughts but Marcel may have additional suggestions and preferences here: there's a sample citation on the landing page for the intro article to the Sovereignty collection. My sense is that if introductory articles are in fact published articles they should be treated as such since they may be cited, should be indexed with metadata, etc. Galley and supp file support would also seem useful if the editors want to publish e.g. audio/video interviews with the authors to accompany the text.

mlafl commented 5 years ago

Sorry for the delay in chiming in here! I actually don't think that these collections need to have freestanding introductory articles of their own. At CA, we have a collection landing page with some intro text plus an image and then original content under the Discussion heading on the right side. Here's another example with multiple Discussion elements:

https://culanth.org/curated_collections/19-everyday-islam

But those pages are not freestanding, peer-reviewed articles of their own: they are more like blog posts or static pages (not sure which is a better reference point within OJS). Our current site includes citations for them, but we provide citations for all blog-style content: we structure them differently, though, with just the name of the section and the publication date, rather than volume, issue, and page number. Does that simplify things a little?

mlafl commented 5 years ago

Also, a possible point of comparison is the Special Collections feature at Open Library of Humanities:

https://www.openlibhums.org/site/academics/special-collections/

https://olh.openlibhums.org/collections/special/

We're not set up to do continuous publication and we wouldn't be soliciting original articles for these collections (in some ways, that seems specific to the megajournal model), but I do like how the special collection title appears on article pages—not quite sure why it appears twice, though.

mfelczak commented 5 years ago

Thanks @mlafl, that's helpful.

asmecher commented 5 years ago

I'll second @NateWr's suggestion that we not involve citations in this. My sense is that most journals will publish in their normal way (megajournal/continuous publication, or traditional issue-based) but then want another way of organizing content for access by readers. Shifting an article from one collection to another shouldn't change its citation (whereas it would if, for example, you moved it to another issue).

mlafl commented 5 years ago

Agreed that the citations for articles included in a collection should not change. Could we, though, include some guidance on how to cite the collection itself and any original content included in it, as with the "How to Cite" box that I've seen in journals like Substantia?

https://riviste.fupress.net/index.php/subs/article/view/55

One other realization I had today: in the past we've formally credited our Curated Collections to particular authors, but I'm wondering if it would be better to just have a metadata field for contributors? Some of our collections are ten years old and it would be good to update them, but then we'd want to credit the people doing updates as authors and we'd run into a whole version control problem. So, to avoid that going forward, I'm thinking no credited authors (implicitly, the corporate author is the journal): @asmecher, @NateWr, how does that strike you?

NateWr commented 5 years ago

Could we, though, include some guidance on how to cite the collection itself and any original content included in it, as with the "How to Cite" box

In short: not without a lot of work. The citation formats rely on a full suite of article metadata, which is then transformed into any one of thousands of citation formats (we use a small handful by default). Without turning the introduction into a full article, we won't have the data we need to generate the citation formats.

It would be possible, and easy, though, for a recommended citation for the introduction/collection to be written directly into a text field. So instead of getting the automatic citation generation, the author/editor will need to write it out themselves.

(Early warning to @asmecher: when we add collections people will want them to have DOIs. :sob:)

So, to avoid that going forward, I'm thinking no credited authors (implicitly, the corporate author is the journal)

Easy solutions like this make for happy developers. :joy:

twakeford commented 5 years ago

I think that adding citation information/complexity here isn't necessary, and adding an introductory article within the actual article list won't be needed (they can publish an Editorial if they want a full publication with citation and just add it to the collection).

To keep it simple, a collection setting seems to need:

title
description (in the OLH/Ubiquity Press platform example given above, there is a short description for the collections page - e.g. https://olh.openlibhums.org/collections/special/ - and then a long description for the collection landing page - e.g. https://olh.openlibhums.org/collections/special/remaking-collections/)
and then the ability to associate a submission to the collection

There are then the option additional features that may make the interface nicer or better to use:

option to dictate the URL so they don't get too long
have a set date that the collection launched/becomes live on the site, allowing them to be prepared in advance but not show on the journal until the editor wants it to
have an image associated with the collection (this can be important if the collection is associated with the conference or society)

One thing that I don't think has been mentioned above is when a submission can be assigned to a collection. Our current system only allows us to add papers after they have been published, but this has drawbacks, as it a) adds risk that the production team forget to associate it, b) editors cannot see submissions associated with a collection during the editorial process and c) submissions are not tagged in any way when they are submitted, meaning editors may miss their association and not pass them to the correct editor. Feedback from our editors has specifically asked us to update so that:

authors can tag their submission to an open collection during submission (adding a new journal section per collection is not an option)
the tag should show in the editor dashboard, so that these submissions can be identified by an EiC
ideally, a collection can have specific Editor(s)/Section Editor(s) associated with it, so that when a tagged submission comes in they are auto assigned

asmecher commented 5 years ago

Essentially I'm leaning towards having a big TinyMCE control to allow the creation of summaries, credits, etc. at the head of any collection's homepage. There's likely to be a lot of variation in what journals want (e.g. author/editor/curator credits, introductory content, images, etc) and that's the only way I can see that covers them all.

mlafl commented 5 years ago

Agreed with @twakeford for the most part: one other baseline decision will be in what order articles are displayed within a collection and whether this is customizable. Maybe two options: chronological ascending and chronological descending?

I can surely see a use case for authors themselves associating submissions with a collection, but it would be great to be able to enable or disable this: at least right now, we are focused on generating interest in back content and would not be using the collections feature in this way.

Thanks to @asmecher for preserving some of that customizability: in our case, being able to credit editors/curators is socially important, even if those credits aren't robustly integrated into the rest of OJS. Being able to specify a recommended citation is more in the nice-to-have category.

mlafl commented 5 years ago

Just reading back through the thread and wanted to make sure something doesn't disappear from view: while we don't need original articles associated with a collection, we would like to preserve the ability to have one or more blog posts associated with it. That's in line with the Discussions section of our existing site:

https://culanth.org/curated_collections/19-everyday-islam

I know that OJS sites have the option of a blog feature, so would it just be a question of associating those posts with a collection and being able to display them at the appropriate spot? For our site in particular, could we do this without having to add a Blog feature to the site nav?

NateWr commented 5 years ago

@mlafl given your timeline (Feb 2019?), I think @asmecher's approach is probably the best fit, and associating blog posts may need to be a custom approach we build that is unique to your journal (especially since these posts are usually published in a separate CMS, right?).

@asmecher I can see that this feature is going to attract a lot of knock-on requests (assigned editors, DOIs for collections, sorting, scheduling, descriptions/cover images/introductory articles, one-off collections vs rolling collections and continuous publishing). Looking beyond 3.2, I wonder if we should explore a base SubmissionGroup class where we house these features, and on top of which we can build Issues, Sections and Collections, cater better to Special Issues, and also bring in common functionality from OMP's Series and Categories?

Here's a first-draft brainstorm using the following types of submission groups:

Issue - As-is with some extra stuff for special issues
Collection - One-off collections of previously published material
Section - Submission types (Articles/Reviews/etc)
Series - Book series'
Category - Continuous publishing, pre-prints, thematic groups, and mega-journal subjects

Feature	Issue	Collection	Section	Series	Category
Allow authors to submit to this group	✓ (special issues)	✓	✓	✓	✓
Allow editors to submit to this group	✓ (special issues)	✓	✓	✓	✓
Submissions are/aren't peer reviewed	✓	✓	✓	✓	✓
Automatically assign editors	✓	✓	✓	✓	✓
Path, description, title and cover image	✓	✓	✓	✓	✓
DOIs	✓	✓	✓	✓	✓
Sorting defaults	✓	✓	✓	✓	✓
Manual sorting override	✓	✓	✓	✓	✓
Option to display published articles or any submissions passed X stage	✓	✓	✓	✓	✓
Schedule for later publication	✓	✓	✓	✓	✓
Unpublishing/Disable	✓	✓	✓	✓	✓
Page that lists all groups (eg - Archives)	✓	✓	✓	✓	✓
Page that lists all articles by group (eg - Browse By)		✓	✓	✓	✓
Vol/No/Year and combined "identification"	✓
Current/latest group	✓	✓
Introductory article(s) with contributors/metadata		✓
Group-specific submission policies		✓	✓	✓	✓
Do not request abstract during submission	✓ (special issues)	✓	✓		✓
Abstract length restrictions (OJS)	✓ (special issues)	✓	✓		✓
Identify items as			✓
ISSN				✓
Nested Groups					✓

ajnyga commented 5 years ago

Having shared code base is an excellent idea.

A couple of comments:

not all of the items listed there probably can not get a DOI at least from Crossref: https://www.crossref.org/services/content-registration/

About the Category column. I do not see preprints as a "category". A preprint is a "stage" of an article. Meaning that a preprint could belong to a category.

Below is a rough visualization how I think OJS should handle the whole different stages of an article:

asmecher commented 5 years ago

@ajnyga and @NateWr, thanks for this; I've been thinking about preprints as well.

My line of thinking has been that preprints do not "mature" into an article, i.e. a preprint with submission ID 123 does not become an article with submission ID 123. A preprint has its own life cycle and if it later becomes the basis for a submission then that submission lives and dies separately, with its own ID, DOI, metadata set, etc. Essentially turning a preprint into an article is like a SWORD deposit.

That's distinguished from e.g. open peer review, where the reader gets a glimpse at an article in an early stage of development. The metaphor I've been using is "putting a window into the cow's stomach" -- you get to see what would normally be hidden. The eventual published article ID is the same as the ID of the submission that was undergoing open peer review.

I haven't been thinking of much overlap between thematic collections and preprints. But a process to publish preprints should allow them to be collected just like articles into thematic collections. Essentially our long-term goal of transforming OJS and OMP into "configurations" of the same base software might be useful here -- adding preprints into the mix as something like "articles" and "monographs" but without most of the workflow.

NateWr commented 5 years ago

Thanks for that @asmecher and @ajnyga. That's useful detail on pre-prints. I must confess I haven't thought much about pre-prints and I only threw them into the mix to demonstrate that Categories might satisfy many kinds of scenarios where there is repeated publishing into a group, rather than one-offs like Issues/Collections.

ajnyga commented 5 years ago

Hi,

Is there a specific reason why a preprint could not mature into an article inside OJS? There are not that many differences between an article and a preprint. Basically it is just about creating and publishing a galley before the review and adding handlers to show those. Preprint is by definition a version of an article that precedes a published article.

Regarding DOIs, preprints and articles of course have to have separate DOIs, but the DOIs should be connected when the metadata is sent to Crossref.

Open peer-review comes of course in many forms. Above I was thinking about the one where anyone can come in and comment a paper ("public review"). For that to happen, the paper has to be public and having a preprint landing page would be an easy way of solving that.

asmecher commented 5 years ago

@ajnyga, consider interfaces like OAI-PMH. If an OAI-PMH endpoint exposes preprints, it should expect them to stay preprints, rather than suddenly seeing them transform into articles. I'm also considering metadata aspects -- it'll be pretty common for an editor to transform an article's metadata for journal standards after its preprint form has been exposed, and changes to the article's metadata should IMO not affect changes to the preprint's metadata.

ajnyga commented 5 years ago

I do not see that publishing the proof version of the article means that the preprint disappears? The preprint is an early version of the article with it's own metadata (versioning comes into play here), own full text and own url (article/view/123 vs. preprint/view/123). If you add a preprint galley, you do not need to remove it after publishing the final article.

I agree that metadata changes. That is why I suggested in the versioning thread that preprints should be considered there.

NateWr commented 5 years ago

I think that we will face demands to accommodate both approaches to preprints that are being raised here, and probably many other approaches as well. There are also the cases of institutional and disciplinary repositories which may not want to publish the final article or any preprint metadata.

A SubmissionGroup is one possible way to handle preprints but not the only way. Versioning is another one that sounds equally plausible to me (and once we get it in it will be easier to build on what we've got).

But in either case I think it's beyond the scope of this issue.

Do we need a preprints issue or project to collect these discussions? I'd be happy to file something and move comments over so they're not lost.

twakeford commented 5 years ago

In my head, themed collections and preprints are very different from the user perspective - collections are collating 'traditional' published output, albeit with added data on the collection page, whilst preprints are not necessarily associated with a specific journal or may not ever get submitted anywhere = sounds to be like they should be treated as separate issues (and best to define 'preprint' from the start, as they may mean different things to different people)

jmacgreg commented 5 years ago

+1 for splitting the preprints question off into a separate issue. Maybe we can gather these separate but similar threads into some sort of "Alternative publishing models" project? Versioning, preprints, open peer review and themed collections group nicely but should be treated individually.

asmecher commented 5 years ago

@NateWr and @jmacgreg, I agree that preprints should be discussed elsewhere, but IMO we're at the level of writing up a general specification rather than using git issues. We already have a rough document circulating (c/o @willinsky) and can break it out from there into git issues when we're ready.

asmecher commented 5 years ago

Initial PRs:

asmecher commented 5 years ago

PRs merged to stable-3_1_2:

asmecher commented 5 years ago

PRs for master:

asmecher commented 5 years ago

Merged into ojs-stable-3_1_2 and master. @mfelczak, when is our deadline for having this available? I could back-port to ojs-stable-3_1_1 but would rather avoid it if we could go with 3.1.2.

asmecher commented 5 years ago

All committed. It'll be included in the OJS 3.1.2 release, but for 3.1.1, it's available in the ojs-stable-3_1_1-i4158 branch of asmecher/ojs and asmecher/pkp-lib.

pkp / pkp-lib

Allow JEs to assemble published articles into thematic collections #4158