Impacts of ROR's retirement of their v1 API
James Myers
Hi all,
I wanted to send out a note concerning ROR’s retirement of their v1 API which is supposed to happen in early/mid Dec 2025 (i.e. now). This is relevant for sites using the External vocabulary mechanism in Dataverse to allow search/display of RORs in the author affiliating, Grant Number Agency or other fields.
TLDR: For installations on Dataverse <=6.8, no change is needed (and updating to the latest configuration from the dataverse-external-vocab-support repo should not be done) but the change at ROR will mean that, for RORs that haven’t been used in your installation before, exports will only include the ROR number and not the name. When you update to v6.9+, you can update your configuration and it will be possible to re-export the metadata and update the metadata at DataCite to include the names. (names for RORs already used in your installation have been cached and should continue be included).
The longer saga – back at the end of July, ROR changed their API default to use v2 rather than v1 and anyone using RORs needed to explicitly use v1 in their :CVocConf setting for ROR to avoid a problem publishing datasets (reported later as #11941). I sent an email out to the group at that time. This was because ROR changed to sending an array of “names” rather than a single “name” in their v2 API and Dataverse a) did not handle the case where a service returned JSON but the expected key (“name”) was missing, and b) did not yet have the ability to pull a name from the “names” array.
Since the v1 API was still available, just using the v1 API for the “retrieval-uri” provided a work-around.
Now that the v1 API is being retired, calls to it will fail (with a 404/not found HTTP error), which means Dataverse will not be able to retrieve the organization name. Dataverse v6.8 and earlier will handle this problem, but will obviously not be able to include the org name in the DataCite XML or other metadata exports. However, accidentally updating to use the current v2 API based config will cause the same error as in August (see #11941 above) - because the response we get from v2 will not include a “name” entry.
Dataverse 6.9 includes several related fixes – better error checking to avoid #11941 by catching/ignoring the case where we get a response but can’t find a “name”, as well as new support for being able to parse the v2 response and find a valid name within the “names” array supplied by ROR v2. (The default config picks the name that ROR indicates that it uses as the primary name on the ROR page for that organization.).
The documentation for how to configure the author fields to use ORCID and ROR also tries to explain this.
Overall, this has been a “learning experience” – our first API change from any service we’ve been connecting with via the External Vocabulary mechanism – and that mechanism is becoming less “experimental” as we harden the code.
If any of this doesn’t make sense or you have specific questions, reach out through any of the usual Dataverse channels.
-- Jim
James Myers
I forgot to mention – adding to the fun, ROR appears to have a bug in their API/server config that is causing some responses (intermittently) to not have all of the CORS headers required for the Dataverse ROR script to work properly. This does not appear (so far) to impact their search API which means that lookup of RORs in Dataverse is working. It does affect display of RORs though, so when an author affiliation is a ROR and the bug occurs, the numeric ROR will be displayed instead of the organization name/ROR logo/link to the org’s ROR profile page. (Our script does try to cache responses in the browser which helps some – we only call their API if we don’t have a cached entry for that ROR.)
At this point, I’m not sure there’s much we can do from the Dataverse side (aside from getting the ROR database dump and setting up our own service), so I think we just have to wait for their fix. (I reported the problem to them yesterday, leading to the comment about Dataverse in the bug report above.) In the meantime, if you see raw numeric RORs when you are using the external vocabulary script, you can verify this is the issue by looking in the browser console and looking for a CORS error on the call to https://api.ror.org/v2/organizations/*.
-- Jim
--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dataverse-commu...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/dataverse-community/DM6PR07MB6252B60B885253AB22D4FA84BFA6A%40DM6PR07MB6252.namprd07.prod.outlook.com.
Philipp Conzett
James Myers
FYI: ROR says v1 is going away today: https://ror.readme.io/changelog/2025-12-04-version-1-of-the-ror-api-and-schema-is-sunsetting#/
Philipp,
I’m not sure I understand your use case. ROR v2 does provide multiple names for an organization now (including acronyms) and I assume those are included in the search. I haven’t checked thoroughly to see if their search API allows limiting by language (Just looked quickly and I think it does not: https://ror.readme.io/docs/api-query#technical-details ). In any case, the ROR v2 script should be picking the name they define as the “ror_display” value for the final display – that’s the name that is used as the main title on the ROR website profile page for the organization. I suspect those are generally in the home language of the organization.
With v2, it should be possible to update the script to try to find a value in the language currently being used in the Dataverse UI if that’s desirable. I’d expect there will be cases where a name in the language of interest doesn’t exist though.
-- Jim
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/8192c6f3-456b-4879-8486-2e1e342ca190n%40googlegroups.com.
Philipp Conzett
James Myers
OK – That’s due to the lines https://github.com/gdcc/dataverse-external-vocab-support/blob/c59a5fe56eb94536deb3fe61cf715e05864942fe/scripts/ror.js#L268, https://github.com/gdcc/dataverse-external-vocab-support/blob/c59a5fe56eb94536deb3fe61cf715e05864942fe/scripts/ror.js#L204 and https://github.com/gdcc/dataverse-external-vocab-support/blob/c59a5fe56eb94536deb3fe61cf715e05864942fe/scripts/ror.js#L67C67-L67C78 looking for a name in the v2 names array that has either a type label or type ror_display. There are labels in multiple languages for some entries, and we display the first one found. I think a work around would be to delete the || n.types.includes("label")
from those lines – ROR’s documentation says there will always be one entry with type ror_display (“UiT The Arctic University of Norway” in this case), so just looking for that would still be guaranteed to find a value. The better solution would be to update the script to look for the name in the language the Dataverse UI is using at the time (defaulting to the ror_display value if there is no match for the language).
Feel free to create an issue for either in the gdcc/dataverse-external-vocab-support repo.
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/ea58db02-6c0d-4684-a9c6-4c3d9184b74dn%40googlegroups.com.