Fixing ror v2 api access for cvoc

[ffritze]

What this PR does / why we need it:
The ROR-API has changed during the last weeks. In the future ROR API v1 will be deprecated.

The old search path for the termName in the old CVOC ROR script was "/value"
In version 2 of the ROR API this will no longer work. So the new search path in the cvocConf.json should be
""termName": {
"pattern": "{0}",
"params": [
"/names/0/value"
]
},"

Unfortunately the current implementation in DV 6.7.1 cannot handle the "0" index. It reads it as a String but it must be an Integer number regarding the JSON output from ROR V2.

This pull request provides a fix the specific implementation and it can handle now both String and Number as values for the ROR JSON output.

In cvocJson.conf after applying this pull request. Your can use the new ROR API endpoint: "https://api.ror.org/organizations/{0}"

Which issue(s) this PR closes:

• Closes #

Special notes for your reviewer:

Suggestions on how to test this:

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?:

Additional documentation:

This pull request is only necessary for the ROR API V2.

[qqmyers]

Is it worth handling the case where "0" is returned as a string too? This code assumes anything that can be a number is one.

[ffritze]

I would say a number is a number. If you construct a JSON object then you shouldn't use a number as a string value for a key.

[qqmyers]

Let me rephrase - the code currently assumes that if the value is interpretable as a number, we must be parsing an array, whereas if the value is a json object, the keys would have to be strings. I don't know how often we'll encounter such things (objects with keys "1", "2", "3"), but it seems like it might be cleaner/safer to see if the value can be a number && the curPath is a json array, you're new code is invoked, otherwise it tries to deal with it as an object with a string key.

[qqmyers]

@ffritze - apologies for letting this sit. I'm suggesting the following change: 5cd4ecf . If that's acceptable to you, can you include it, and update your branch from IQSS/develop (as done in develop...GlobalDataverseCommunityConsortium:dataverse:fix_ror-v2_api_cvoc) so our build system will be able to run it and we can plan on including it in Dataverse 6.9? (FWIW: I wasn't able to make a commit or PR against your branch)

[ffritze]

@qqmyers Thanks a lot. I will test it in our infrastructure. Currently we have a maintenance phase so I will postpone it until the beginning of next week.

[ffritze]

@qqmyers I can now confirm that your additional code in this branch is working as expected. This pull request is ready for production

[pdurbin]

@ffritze great! We were leaving you assigned to this PR until you confirmed this. I'll remove you. Have a good weekend!

[qqmyers]

I think this is a useful update but I'm not sure that ROR v2 needs it: in gdcc/dataverse-external-vocab-support#46 I'm suggesting that we just get the whole array with "params": ["/name"]

This is consistent with what we do with Skosmos, etc. where we get all the variants and names in different languages if they exist.

[qqmyers]

Another ROR specific note - I'm not sure 0 is always the best to display )if you do want only one name) - in the PR the new ror.js script looks for the entry with the "ror_display" tag, which is what shows on their website.

[ffritze]

I think the solution in ror.js is exactly what we need.
But the "params" configuration in cvocConf.json is a little bit different.
I would like to draw the attention to the case that if you specify "/names/0/value" then you will get the following database entries (First attachment)

But If you specify only "/names" you will get a whole JSON array in the database. Is that what you want (second attachment)?

[qqmyers]

Yes, having the array was my intent. That means in the exports like OAI_ORE, you'll see:```
"author": [
{
"citation:authorName": "Myers, Jim",
"citation:authorAffiliation": {
"scheme": "http://www.grid.ac/ontology/",
"termName": [
{
"lang": null,
"types": [
"acronym"
],
"value": "QDR"
},
{
"lang": "en",
"types": [
"ror_display",
"label"
],
"value": "Qualitative Data Repository"
}
],
"@type": "https://schema.org/Organization",
"@id": "https://ror.org/014trz974"
},

[stevenwinship]

Waiting on conflict resolution

[coveralls]

coverage: 23.456%. remained the same
when pulling 223461d on TIK-NFL:fix_ror-v2_api_cvoc
into 2e65650 on IQSS:develop.

[qqmyers]

FWIW: I'm reconsidering where using /names and retrieving the array is the best option here. While I think some export formats would benefit from being able to show all the options, our current DataCiteXML assumes that the value is a string, and, prior to #11782, getting an array would break things.
While I think this PR is useful, for this case, I'm looking at making our parsing slightly more flexible such that we can look within the array for the object with the type "ror_display" - the value ROR shows in their UI, rather than picking the first array element (which would be supported by this PR). We have the rigth syntax for this already from our SkosMos examples, e.g. /names/types=ror_display/value but with that syntax, we assume the "types" key has a string value (that would match "ror_display") whereas in ROR, the types key is an array of strings, one of which has the value ror_display. I'll be putting in a PR for that - hopefully both PRs will have general utility.

[qqmyers]

FYI: I created #11793 and added a generic release note that says there are enhancements to the ext. vocab mechanism, which should cover this PR as well (assuming both go into Dataverse 6.9 (which we want so that the additions are available before ROR's v1 API gets shut off).

[qqmyers]

OK - I'll approve this so it moves to Ready for QA. @ofahimIQSS - make sure @ffritze has completed his testing before you merge.