ROR Plugin Improvements

Describe the problem you would like to solve
I highly welcome the ROR 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 as 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.

Crossref, PubMed, Scopus and other bibliographic data require detailed affiliation data. Especially NIH (PubMed) is very picky if the affiliation delivered in the metadata is not the same that is published on the PDF.

  1. 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

A much larger study of 22 million articles shows that multiple affiliations are extremely common, the trend is rising due to increased international scientific collaboration.

Both deficiencies could be solved using the following approach:

Describe the solution you’d like

Database

An affiliations table with the following columns:

affiliation id (primary key, sequential number)
author id (secondary key)
sequence (for reordering affiliations)
full affiliation (free text)
ROR Id (text, only for ROR Id, populated from ROR)
ROR display (ROR Id & organisation name, populated from ROR)

There is an 1:n relation between the authors and the affiliation table via author id.

A Json file (or schema) within the plugin, which can be extended e.g. by the OJS application admin. It contains matching rules (e.g. regex, in various languages) for organisation descriptors, such as
“universit.?”
“college.?”
“hochschule.?”
“hospital.?”
“spital.?”
“spitäler”

Such terms could be derived from carrying out a term analysis of the ROR organization names

Lookup Algorithm

An algorithm that tries to identify organization names in the full affiliation field, and uses the identified organization name to do a lookup at ROR (or for performance reasons, at a locally cached ROR dataset). It saves both ROR Id and the combined ROR display information.

Interface:

Author form

For the affiliations, a grid starting with 2 empty lines, having 2 columns
Full affiliation, ROR organisation (=ROR display)
Both columns are editable and non-mandatory.

When a full affiliation has been entered and upon leaving field, the lookup algorithm described is triggered and in case of a match the ROR organisation column is filled (and the ROR Id field in the background).

It’s also possible to:

  • edit the ROR organisation column after it has been pre-filled by the matching algorithm - then a direct lookup is done at ROR (via API or cached dataset)
  • to leave the full affiliation empty and to do the lookup in the ROR organisation column only

More lines can be added to the grid with a + or Add button. Lines can be ordered using an “Order” button and usual select drop ordering available in the OJS GUI.

Article details page

For every author, the article details page lists all full affiliations and if a ROR Id is available, for each affiliation the ROR icon with a link to the page of the ROR organisation record.

Export plugins (Crossref, …)

For every author, all full affiliations (and ROR IDs, if available) are sent to the receiving database.

Who is asking for this feature?
Journal Editors, Authors, Journal Administrators

Additional information
see ROR Plugin for OJS · Issue #5912 · pkp/pkp-lib · GitHub

Just a quick note on storing institutional data: from 3.4, there will be an institutions table in the database with a ror column. This will be used for institutional stats and subscriptions. But we also planned for it to be available for general use, like the author affiliations. So, hopefully it will be a little bit easier for the ROR plugin to adopt multiple affiliations drawn from this database once that is in place.

1 Like

Regarding this, I learned recently that this is actually a ROR policy rather than a plugin limitation. It’s ROR’s policy not to go much further other than the high level institution. I agree that it would be important to have a more granular approach, but perhaps discussion about this specific point should be taken over to ROR instead of this forum.

@alexxxmendonca - please read my Feature request carefully - it doesn’t conflict with the ROR policy.

The current plugin limitation is that you can’t enter a full affiliation anymore. One needs both - the full affiliation as indicated on the PDF, and the ROR affiliation which is top Organization only. My proposed scheme covers that.

As an example for a common scientific article:

https://www.chimia.ch/chimia/article/view/2022_748/5419
Here the full affiliation (only one in this example) is as footnote at the bottom left of the PDF, and it is a is also available in the metadata: https://www.chimia.ch/chimia/article/view/2022_748/

A ROR enhanced article would additionally carry to the ROR Id in the PDF for each full affiliation, and in the metadata. This is similar to enhancement of the article with ORCID Id , which complements the author name.

As the current plugin is made, it replaces the affiliation with ROR. However, it should enhance it.

I apologize if I misunderstood your feature description.

I re-read it but it’s hard for me to understand for lack of technical knowlegde.

For that reason, I will refrain myself from commenting further.

Amanda French here, Technical Community Manager for ROR. Definitely agree that the ROR plugin should support multiple affiliations per author, since that’s very common. And yes, @alexxxmendonca is right that ROR as a project doesn’t currently support department-level units and has no plans to – although ROR records do support hierarchies such as parent/child relationships, and there are many research institutes and hospitals and so on that do have their own ROR IDs even though they are affiliated with a university.

But yes: @mpbraendle’s proposal would allow both long affiliation strings that include departments and a ROR ID for just the top level organization. There definitely are ways to do it.

4 Likes

Yes, indeed. In my opinion, this is a major drawback of ROR.