An API call is needed to add authors to a submission

Feature Requests
1

Describe the problem you would like to solve
Our editors need a way to add authors to a submission. It happens on a regular basis that papers are submitted to our online data journal which result from big international projects. The authors are often many in number - sometimes more than 50. The names are too many to be added by hand.

Describe the solution you’d like
We’d like to add the author names with a script, so an appropriate API would help.

Who is asking for this feature?
Journal Editors

Additional information
Of course, the API should be properly secured.BTW, we are running OJS version 3.4.0.4 …

2

Hi,
have you looked at the REST API documentation? https://docs.pkp.sfu.ca/dev/api/ojs/3.4
I think what you wish for is already there: https://docs.pkp.sfu.ca/dev/api/ojs/3.4#tag/Submissions-Publications-Contributors

3

Dear Martin,
Thank you very much for this answer!
Kind regards,
Stevie

5

Where does one get the userGroupId to create a contributor? This is related to this post.

6

Hey @kmccurley, there isn’t currently a way to do this via the API, but the code for how this is handled can be found in the ContributorForm class. The code linked is for the main branch, but it is largely the same for earlier versions as well.

There most likely shouldn’t be too many of them for the author role in any given journal and this could be gotten manually, then the ID could be used directly when adding contributors via the API. It’s not ideal, but probably the best approach for the time being. Hope that helps!

Regards,

Erik
PKP Team

7

Thanks Erik. I had to guess at the purpose of UserGroup, but I assume it is to separate authors, editors, referees, copy editors, etc (the hint in the code is ROLE_ID_AUTHOR).

My interest in this was motivated by the fact that I wanted to write code for a publishing partner that runs an OJS instance that I don’t have access to. We basically hand them the edited PDFs and JATS metadata for about 50 publications per quarter (maybe 100-150 authors per quarter, but one publication had 32 authors last year). The metadata comes with title, subtitle, abstract, bibliography, citations, author name, author email, surname, ORCID, affiliations with ROR, country, city, state, department, affiliation relationships, funding, license, acceptance date, submission date, etc. At present their only path for import is through the quickSubmit plugin since I can’t get the REST API to work. Unfortunately it’s extremely tedious for them to use quickSubmit. I may just sever our relationship with them since the hosting part is pretty simple anyway, and that’s all they use OJS for with our journals. As I mentioned in the link above, the REST API seems incomplete and not accurately documented. We don’t exactly fit the mainstream need that OJS was designed for, so I can appreciate that the REST API is a low priority.

8

Hi @kmccurley, yes, that’s correct. While the role types are fixed, the exact details of their permissions etc. can be changed on a per journal basis, hence why it’s included as part of the required metadata.

And you’re right that the documentation for the REST API is not kept fully in sync with the reality of it. The documentation is in need of an overhaul, just a matter of finding the time for it!

For the use case you’ve outlined, the REST API directly may not be helpful, but this third-party tool developed by one of the PKP developers may serve as a useful guide for how to do larger imports. It’s an article import plugin specifically for JATS, but the ideas in it may be helpful based on the format you have your data in. PKP Publishing Services has used this for large scale imports in the past, so maybe adapting it for your needs will be easier than relying in manual imports via the QuickSubmit plugin.

Regards,

Erik
PKP Team

9

Thanks for the suggestion. It looks like a reasonable place to start, but I went through some of the code and it looks like it would be a lot of work to adapt it. The version of JATS that it references is 1.0, which is about ten years out of date (we are now at 1.4). I went through some of the parser code and it would take a lot of work to bring it up to the current schema (on both the JATS and the OJS side). Things like abstracts could get mangled because ours sometimes contain sections with titles, as well as mathematics (which is allowed in JATS and crossref, and is supported in OJS via MathJax). The parser wouldn’t pick up ROR or ORCID. Author names sometimes appear untagged in <string-name> because we can’t parse them into surname and given names (some authors don’t have surnames). Affiliations would get merged into the single field that existed in 3.4 (it took four years to get support for multiple affiliations in 3.5). Our structured <element-citation> would be squished into a text format. It doesn’t look like it supports funders to be reported to crossref. I don’t think it handles errata articles that have a <related-article> tag in them. There is just a lot of stuff ignored from JATS, and interpreting the many things it could have would be a lot of work.

Is the intention that this is going to be a supported path for importing articles into OJS beyond 3.5? It could be made to work, but it’s not a small project. I think Alec had mentioned in the past that he expected the REST API to be the way forward for importing articles. That probably makes sense if the UI and the other tools could all target the same API.