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.
#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/

[withanage]

HI all,

ROR ID Plugin will support the upcoming OJS 3.3 and this issue will be closed after adding the plugin to the plugin gallery.

pkp/plugin-gallery#28

Next iteration of the developments are described in the Issue #6686

Please subscribe to that ticket, if you are interested in the updates.

[kmccurley]

I think it's a great idea to capture ROR IDs when they exist, but I would advise caution about the schema. It is crucial that authors be able to list multiple affiliations. It is very common for authors to have multiple affiliations, but it's also the case that on a paper the affiliations would be listed individually, and the relationship between author and affiliation is indicated by a footnote (superscript).
. By contrast, schema.org and crossref.org associate affiliations to authors, but then repeat them when authors share an affiliation. This would look silly on a paper to list all authors, but the structure of metadata need not align to how it is presented on a page. Perhaps for that reason, the Dublin Core section 5.1 asserts that affiliations are associated to the article rather than the Author.

When you ask for an affiliation, it is important to allow both a free text field and an identifier (with an identifier type, like GRID, ISNI, or ROR). Datacite supports this. This allows institutions that have not been assigned an identifier to be listed, but also allows authors to list departmental affiliations within a ROR institution (ROR does not identify departments). You may also wish to accept a URI for the affiliation in case they don't have a ROR ID (e.g., a small company, which is common in computer science).

There are some social implications of identifying "affiliations"

1. to give institutional credit for research (e.g., work done at Microsoft Research)
2. to provide institutional accountability for the credibility of the work (e.g., in case human subjects were mistreated)
3. to acknowledge financial support (e.g., Fulbright awards are paid directly to researchers, not institutions)
4. to provide contact information for readers wishing to contact the author. In this case, an affiliation may not be associated with the work itself, but rather with the human after they have moved on to another institution.
5. publication quality metrics are often associated to institutions as well as authors, and institutions may seek to inflate their importance by offering institutional affiliation without much involvement see page 5. Authors who list multiple affiliations end up diluting the credit given to them.

Because of these issues, it might be worthwhile to collect relationship information about an affiliation, in much the same way that authors may wish to be listed as equal or in separate classes (Elsevier has five classes of authorship). I would suggest at least distinguishing the "current affiliation" from the "site of research" or "funder of research".

You may wish to constrain the number of affiliations per author. JAMA places restrictions on how many affiliations an author may have, depending on the article type. (one for research letters and at most two for viewpoint). Authors may additionally supply a current address if it differs from the institutional affiliation(s) of the research.

[NateWr]

Thanks for your comment @kmccurley. I don't think we'll ever require a ROR. At the moment, we only support a single text field for affiliation, but we definitely plan to better support multiple affiliations eventually. We don't have any plans to support a taxonomy of affiliation types, and probably wouldn't support this unless a widely acknowledged third-party standard emerges, like the CRediT taxonomy for authorship.

[othwunrai]

Hello. Maybe you can help me. Is it possible to have more than one ROR ID (with icons on the articles page) for one author in one article? For authors with, for example 2 or more affiliations.

[withanage]

Currently no. But I have discussed this aspect with @NateWr and it is generally possible to have a list of comma sperated ids for one author and display them accordingly. I have not prioritized this, but surely look into it, when I build in the 3.4 support. This may also need a frontend change, therefore if you have the ids in database and like to display them already, you may have to write an iterator to display them using a theme plugin.

[othwunrai]

Thank you for your answer and advice. I realy hope it will be possible in the future (the list of comma sperated ids sounds great).

[mpbraendle]

Hi,
I highly welcome the plugin, but as it is implemented now, we can't recommend and use it for the moment.
There are two main problems:

1. Affiliations usually not only have the main organisation, but also cover details such das department, institute, lab, address, postal code, city and so on. The lookup prohibits to enter these details, which, however, are important for an author. The lookup should be able to identify the ROR iD from the full affiliation.
2. Missing support for multiple affiliations. These are not uncommon. Here some statistics from our publication repository ZORA, which covers essentially all UZH publications from 2008 and which collects affiliations via the Scopus API:

167738 publications
724880 creator names (not unique)
543945 affiliation records (authors) with 1-n affiliations per author (coverage 75%)

Out of 543945 affiliation records (=authors)
465859 (85.6%) have 1 affiliation
68421 (12.6%) have 2 affiliations
8241 (1.5%) have 3 affiliations
1424 (0.3%) have more than 3 affiliations

[alexxxmendonca]

Hi @mpbraendle

I fully support your comment. We've been using ROR for SciELO Preprints and we encounter the same issues. Unfortunately we can only add the top-level institution and only one per author.

[NateWr]

Hi @mpbraendle, thanks for your comment and especially for providing statistics on affiliations from a dataset. This issue is closed and won't be reopened. Would you please open a new feature request with a proposal, or one for each of your proposals? Please include the data you posted here with as much information as you can provide about your preferred solution.

[kmccurley]

I mentioned in the feature request issue 7135 that there is a much larger study of 22 million articles that shows multiple affiliations are extremely common. I will not be pursuing this feature request because we've decided to use a different platform. For us, there were simply too many things in OJS that didn't fit our workflow or metadata requirements.

[mpbraendle]

I have now opened a detailed feature request on https://forum.pkp.sfu.ca/t/ror-plugin-improvements/75125 - Please comment and vote.

[marcbria]

Just reporting that a some fellows from OJS-ES.network tell us they like to adopt the plugin when it includes:

• Second level affiliations.
• Multiple affiliations.
  I will forward them to the FR forum.

Dulip, thanks for sharing it!