First of all, thank you for all your effort in providing high quality open source projects. I have personally not used them yet, but I am a developer considering to implement and use OJS.
I hope my question does not sound silly. I was looking at the OJS Rest API development and wondering if there is a current expectation as when more APIs such as the payment ones and the rest of the project will be completed. This will help me better understand how to plan the release of our idea and possibly contribute to the OJS project.
Not a silly question at all! Our API development is driven by use cases at the moment, and one of those is a goal of gradually rewriting MVC-style parts of the code to use the API natively. However it’s a big codebase and our need to do that is generally driven by some other need to improve that code in a way that justifies a rewrite. The payment stuff traditionally hasn’t received a ton of emphasis as much of our community doesn’t use it.
Meanwhile there are two paths forward:
Contribute to the API! This is the best of all worlds. We would be happy to guide you on standards and conventions.
If you need to interact with an outside system but don’t want to develop a full fledged API endpoint, you could use existing tools like a gateway plugin to expose a part of the system for invocation by an external service.
Regards,
Alec Smecher
Public Knowledge Project Team
Hello @asmecher,
Thank you so much for your answer. If we start this project we will definetly end up contributing to OJS!
The gateway plugin looks interesting. Do you know where all the available plugins are listed or where I could find a gateway plugin that could help with our project?
There are a lot of plugins that come with OJS (arranged by category in the plugins directory). Other plugins are available via the Plugin Gallery, though I don’t believe there are any pure gateway plugins there yet. Among the developer documentation, there’s the Plugin Guide in particular: Plugin Guide for OJS and OMP
And if you get lost on a particular aspect, feel free to post here!
Thanks,
Alec Smecher
Public Knowledge Project Team
The field of computer science is evolving from conference publication toward journal publication, but often through a model with synchronized deadlines where a committee will perform reviews on all papers that were submitted by that deadline. An example is VLDB. This requires customization of the submission and reviewing workflow, including automatic flagging of potential conflicts of interest and assignment of reviewers through an external API using the Toronto paper assignment system or some variant. We have been debating whether to use OJS to start a new journal, but have been unable to figure out a way to customize the workflow and control it through an API. It’s hard for me to tell if that is even possible (swagger is inadequate documentation). We’ve through about using an alternative review system, and importing papers to OJS only after the editing phase was completed (we require LaTeX). Unfortunately we were warned by a librarian that the bulk import plugin is extremely unreliable, and when I tried to read the XML specification I came across broken links and ambiguous specifications so I didn’t consider it feasible to implement something for that format. In the long run I think PKP would benefit greatly from concentrating on these API surfaces.
As an example for the reviewing part, there is a new platform called openreview.net that is being built from the data model up, with an API to handle customization of workflows. It is currently being used for the NeurIPS conference, which had about 10,000 submissions in a few days. Of course it is much less mature than OJS and offers nothing for the editing and publishing phases, but in the long run I think this kind of architecture will survive, whereas monolothic MVC architectures will struggle to adapt and scale. Maybe that is something for OJS 4.
We’re currently in the middle of a years-long process of rebuilding our editorial UI to run entirely on our API. Our goal is for all actions in the editorial backend to run off the API: journal settings/configuration, submission, reviewer assignment, discussions, decisions, etc. We’re not there yet, but we’re on our way.
At the moment, our REST API can:
Get submissions
Get reviewers
Get/Add/Edit/Delete publications, publish/unpublish them, and version them
Get/Add/Edit/Delete submission files
Get/Add/Edit/Delete users
Configure settings for journals and the site
Get issues
Get/Add/Edit/Delete announcements
Get/Add/Edit/Delete email templates
Get usage, editorial and user statistics
As of 3.4, our submission wizard will also run on the REST API. That still leaves a lot of gaps during the editorial workflow, so we’re not yet ready for a fully custom, API-driven editorial workflow.
However, there are other options available to you. Every page in our editorial UI can be completely overridden by a plugin. That means that you can replace our submission workflow page with your own, write your own API endpoints, and basically remake the workflow however you want. This would require a significant investment of resources to build and maintain, but it’s possible within our current system.
We are also keen to expand our REST API, so if you’re willing to collaborate closely with us, we are open to PRs which extend our API to support objects that we don’t yet support. In this way, you could work on a custom editorial UI with custom API endpoints, and also work towards getting the API side of your work merged into core to reduce your long-term maintenance burden. I’m not going to pretend this is easy! It’s a lot easier to build an API endpoint for one use case than for the thousands of use cases we have to consider for our community. But if you have the energy and the resources to devote to this, we love collaborating with our community to expand the core software.
It sounds like you’ve already found our API documentation, but here are some other developer documentation which might help you evaluate whether you can adapt the software to your needs: