Pkp-lib: ROR Plugin for OJS

[paulvierkant]

Describe the problem you would like to solve
When submitting a manuscript, authors and contributors can indicate their affiliation in a free text field. A free-text field lends itself to many different ways of writing a name (e.g., UC Berkeley vs. University of California, Berkeley). A result of many different name variations is that searching/tracking research outputs by institutions is not always going to be accurate or comprehensive.
The unambiguous statement of their affiliation is also important to the editors of a journal influencing the reputation of their journal. It can also be useful for the publisher to have this information in an unambiguous way in case they have a specific publication/pricing arrangement with specific institutions.

Describe the solution you'd like
In contrast to a free-text field a single unique identifier would allow for an institution to be designated in the same way every time. The Research Organization Registry offers a globally unique, open, and persistent identifier for research organizations that could be integrated into OJS via the ROR API. In the user profile from each user (submitting author, contributor, or editor) starts to type in the affiliation field and the corresponding institution from ROR is suggested. The user’s affiliation could be displayed on the landing pages of articles and on the about pages (in the editors section). The affiliation information should be pulled into the different OJS metadata outputs (Crossref, DataCite) so that the information can be shared in a machine-readable way.

Who is asking for this feature?
Journal editors, journal administrators, authors, publishers, funders

Options to Consider

| Remarks | Suggested by | Status|
| ---| --- | --- |
| Start and end dates of the information for multiple institutions| @mfenner | General Comment |
| Granalarity of the ROR | @mfenner | Has to be considered, when ROR has this support|
| extra fields for postal adress| @mfenner | Thoughts welcome |

Additional information

_The name of the affiliated institution could be linked to the ROR entry on the article landing page (optionally followed by the ROR icon)._

_The name of the affiliated institution could be linked to the ROR entry on the editorial team page (optionally followed by the ROR icon)._

_The ROR auto-suggest functionality could be implemented in OJS similar to the Dryad implementation of ROR._

Issues related to this feature request:

The functionality of the OJS funder plugin is similar to what could be the ROR plugin.
https://github.com/pkp/pkp-lib/issues/2787 , the only difference being that it should be piped into the DataCite and Crossref outputs (DataCite currently accepts ROR, Crossref will start to do so from Q3 2020).

Being able to collect and add RORs in association with OJS users (editors, reviewers, authors) so that in the review process journals could avoid conflicts of interest in accidentally inviting a reviewer from the same institution of the submitting author (of course there are cases where this would be fine).

[ajnyga]

Looks good! I think it would be important that besides saving the label (the name of the organisation) we would also save the unique identifier of the organisation to the OJS database.

[jhagedoorn]

This Plugin would be an significant improvement on the road to institutional identifier!!!

[TimBoxH]

I can only support @paulvierkant 's request and would like to add the need to specify more than one affiliation per author.

From my personal experience (as a scientist), authors can be employed at more than one institute at the same time, or authors would like to indicate two affiliations on the same publication as they were employed at institute (A) during data acquisition but have moved to institute (B) at the time of publication of the resulting manuscript.

[CFanselow]

Would also be interesting for us! Both for the user accounts (table "user_settings") and the article metadata (table "author_settings").

[withanage]

As some of you already know, TIB is going to implement Research Organization Registry (ROR) plugin for OJS3.

I have done a basic prototyping to visualize the functionality, that we are going to add.

I would love to hear your thoughts on the following questions.

• ROR contains translated names. E.g. University of Pisa
  What would be the suggestion for multilingual affiliations ? should we allow each multilingual entry to be added explicitly controlled by referring to the ROR API?
  Another option would be to disable the multilingual functionality by allowing only one field and automatically fetching the languages, (if they match with the languages defined in the current context / journal)

• There is a requirement for saving multiple affiliations per author and user . @asmecher, would you recommend adding multiple user affiliations in the user_settings /author_settings e.g affiliation-2 or would you rather recommend a separate table . Alongside the name string, I would be saving ROR ID (mandatory) and later other metadata fields e.g. grid id and more fields in future similar to orcid .

---

FYI @jmacgreg @mtub @NateWr

[ajnyga]

Are we saving the label or the identifier to the db or both?

Edit: because we definitely need the identifier

[NateWr]

In terms of multilingual inputs, the user should not be responsible for setting the name. The user should select their appropriate ROR ID and the application should take care of showing the correct, localized name based on the viewing user.

So the plugin should save the ID to a new property, like rorIds, and the affiliation names should be fetched from the API and saved to the correct localized affiliation properties on save. That way themes can use the localized affiliation string values regardless of whether the ROR plugin is being used.

[withanage]

@ajnyga

Are we saving the label or the identifier to the db or both?

was planning to saving both, otherwise, if people disable the plugin, they would not have the name of the organization in db.

@NateWr thanks for the clarification.

[ajnyga]

@withanage agree.

I have talked about this before, but OJS would need a data structure that allows saving label + identifier pairs. This would be helpful here, but also in things like connecting thesauruses to the keywords field with an API endpoint.

[withanage]

Thanks @ajnyga

Yes, something in the direction would be nice. If we add a new structural support or we can use the already existing control_vocab* tables, I am not sure.

Let us wait for @asmecher s suggestions.

[asmecher]

I have talked about this before, but OJS would need a data structure that allows saving label + identifier pairs. This would be helpful here, but also in things like connecting thesauruses to the keywords field with an API endpoint.

I think what @NateWr proposes above would resolve it well:

So the plugin should save the ID to a new property, like rorIds, and the affiliation names should be fetched from the API and saved to the correct localized affiliation properties on save.

It might seem strange to store them separately, but it has some definite benefits that I think are requirements:

• Other code doesn't have to be written with knowledge of the ROR plugin
• Disabling the ROR plugin won't cause affiliation data to disappear
• Enabling the ROR plugin will preserve existing data (text only) while forcing new data to be linked

Multiple affiliations are a good question... I can imagine two approaches:

• Add support for multiple affiliations to OJS
• Support multiple RORs (as we should), and concatenate them into a single field when storing the localized affiliation data

The first is better, the second is lower impact. I'd suggest doing a quick survey of JATS, CrossRef, etc. to ensure that whatever data design we land on is well-supported both with RORs and without.

[withanage]

Thanks a lot @asmecher for the comment.

For saving one affiliation, I will work on that according to the above specification.

Regarding multiple institutes, I prefer the multiple affiliations approach.
As it requires more effort, (and with one affiliation, we can surely serve most of the use cases), we can think of it in a more generic way, if that is not easily extendable with a plugin.

I'd suggest doing a quick survey of JATS, CrossRef,

• @paulvierkant investigated the crossref compatibilty and confirmed the crossref support for multiple affiliations.

• I have taken a quick look at the JATS schema and can confirm it is also there.
  JATS has a generic support for a institution-id-type attribute and a contributorcan have multiple affiliations.

<contrib contrib-type="author">
    <name>
        <surname>Crutchley</surname>
        <given-names>Alison Claire</given-names>
    </name>
    <aff id="aff1">
        <institution-wrap>
            <institution-id institution-id-type="Ringgold">1812</institution-id>
            <institution-id institution-id-type="ISNI">0000 0004 1754 9200</institution-id>
            <institution-id institution-id-type="GRID">grid.419082.6</institution-id>
            <institution content-type="university">Harvard University</institution>
        </institution-wrap>
    </aff>
    <aff id="aff2">
        <institution-wrap>
            <institution-id institution-id-type="FundRef">http://dx.doi.org/10.13039/100000002</institution-id>
            <institution>National Institutes of Health</institution>
        </institution-wrap>
    </aff>
</contrib>

[mfenner]

I agree with what was said about the need to support multiple affiliations and not worrying about language in input, but rather leave that to the output. GRID and thus ROR have multiple languages per institution, but the coverage varies.

I work at DataCite and we support multiple affiliations in DOI metadata. It is an important feature, but I don't see that used heavily - although we haven't looked systematically at the about 300,000 DataCite DOIs that have a ROR identifier (we launched functionality August 2019).

Multiple institutions is particularly important if you store this information per user and reuse it for additional submissions later. If you do that and it becomes a popular feature, you might consider adding start and end dates to simplify the user interface.

One issue that comes up a lot is what to do if the institution is not in ROR. In the web form for DOI registration at DataCite we don't allow the entry of free-text institution names, but some other organizations do. Our philosophy is that we don't want to clean up this optional information later, as users will inadvertently enter institutions that already exist in ROR, but under a different name or granularity.

Granularity is the other big issue. ROR is an identifier at the institution level and not department level at least for the foreseeable future. Journals typically want more granular information that not only includes the department but may also include the postal address. I suggest that you allow users to input that information in extra field(s).

Finally, there is significant overlap between ROR identifiers and Crossref Funder Registry (with a significant percentage of funder identifiers included in ROR) and over time they might be merged into one system. I would keep this in mind when implementing the ROR plugin, for example also storing the Crossref Funder ids (there are typically multiple for large funders) in addition to the ROR id.

[withanage]

@mfenner

Thanks a lot for your valuable input. I have added your suggestions in the ticket header so, we consider all those scenarios through the implementation process.

Some concrete questions to clarify further

• Would you also consider adding the start and end dates even if there is one institute ?
• Adding extra fields related to a contributor/author is easily possible. So we can have the community discussion and look into what fields are mostly needed. Therefore for any concrete suggestion, we are thankful.

Thanks for the information of the possibility of a merge of Crossref and ROR . This helps us to consider the technical implementation details.

[NateWr]

Thanks @mfenner, really appreciate your input here!

Journals typically want more granular information that not only includes the department but may also include the postal address. I suggest that you allow users to input that information in extra field(s).

Another aspect of this is that OJS is often used to import large back collections of a journal. We will run into many cases where an author is affiliated with an institution that is not in ROR (or any database).

From a UI perspective, I'd like to see this work in the browser with the editing user having final control over the affiliation text before it is saved. For example, selecting a ROR will update the affiliation field with a rendered text string based on the selected ROR, but the user can then edit this text field to conform with their own visual presentation, or to add departmental information.

Would you also consider adding the start and end dates even if there is one institute ?

The way that OJS handles author records at the moment shouldn't require start and end dates. A distinct author record is created for every submission, so when a user changes their affiliation details it will not effect previously published work.

[mfenner]

This all makes sense to me.

[ainulrafiq]

Dear project team,

The registry that you trying to connect with the OJS will bring a bright movement. As a journal publisher staff, I would like to join the plugin tester (if needed) :-).

[NateWr]

@withanage is preparing the plugin for release now and we expect OJS to support the ROR plugin out-of-the-box with the next major release, version 3.3, planned for January 2021.

[withanage]

Hi everyone,

If any of you would like to test the plugin in OJS 3.2, you can install it from until it goes into the plugin-gallery.

https://github.com/withanage/ror#installation.

I am thankful for any early-testing feedback.
https://github.com/withanage/ror/issues

[asmecher]

@withanage, this is exciting! We have tagged the OJS3.3 RC1 as 3.3.0.0 in the release (and will reserve 3.3.0.1 for RC2, and so on). This means you can add testing versions of the plugin to the plugin gallery by designating them as compatible with 3.3.0.0 if you like -- it'll make it easier for people to test with.

[jmacgreg]

Awesome news, Dulip! I'll let the PS team know.

[mjaoj]

This is great! When is this going to be available?

[withanage]

@mjaoj

This plugin will be available with OJS 3.3 with standard support.

But for OJS 3.2, if you would like to use it already you have to have a OJS 3.2.1 installation from the source code after 30.11 or you have to tweak the template.

Please have a look at the update instructions.
https://github.com/withanage/ror#installation.

@ainulrafiq did a test installation and you can see the plugin functionality in OJS 3.2

https://myjurnal.poltekkes-kdi.ac.id/index.php/HIJP/article/view/204/