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