ORCID contributor affiliation selected randomly

[ZenoLC]

Describe the bug At the moment contributors added over ORCID have a list of all their affiliations attached to them. This list contains the affiliation title only and is not sorted. We should be able to choose the newest/current affiliation only. ORCID does save dates for the affiliation. The API should be expanded to also perceive this information and use it as criteria for choosing which affiliation to show.

Is this a regression? No.

Steps to Reproduce

1. Add contributor over ORCID which has several affiliations assigned to them.
2. See error

Expected behavior Onyl the current/most recent affiliation should show up.

Environment

• Damap version 2.4.0

[rekt-hard]

A request/response to/from the current expanded search API looks like this: Request:

await fetch("https://pub.orcid.org/v3.0/expanded-search?q=%220000-0001-8968-6405%22", {
    "credentials": "include",
    "headers": {
        "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0",
        "Accept": "application/json",
        "Accept-Language": "en-GB,en;q=0.5",
        "Upgrade-Insecure-Requests": "1",
        "Sec-Fetch-Dest": "document",
        "Sec-Fetch-Mode": "navigate",
        "Sec-Fetch-Site": "same-origin",
        "Sec-Fetch-User": "?1",
        "Sec-GPC": "1",
        "Pragma": "no-cache",
        "Cache-Control": "no-cache"
    },
    "method": "GET",
    "mode": "cors"
});

Response:

{
  "expanded-result": [
    {
      "orcid-id": "0000-0001-8968-6405",
      "given-names": "Mauro",
      "family-names": "Cortez Huerta",
      "credit-name": null,
      "other-name": ["Mauro Cortez-Huerta", "Cortez-Huerta Mauro"],
      "email": [
        "maurocortezhuerta@gmail.com",
        "mauro.cortez@comunidad.unam.mx"
      ],
      "institution-name": [
        "Benemérita Universidad Autónoma de Puebla",
        "Universidad Francisco de Paula Santander",
        "Universidad Nacional Autónoma de México",
        "Universidad de Guadalajara"
      ]
    }
  ],
  "num-found": 1
}

Fetching extra information about the institution or email (which has the same issue regarding which one to choose (though we can select the one marked as primary: true)), would require another request. Doing this for every contributor found will result in quite a few extra requests. If a user has several current affiliations/institues, which one shall we choose?

@ZenoLC if we fetch extra information, we might have to implement this at the stage where we add/select a contributor. What do you think?

[ZenoLC]

I agree, that fetching when loading the list is not elegant for performance. and yes, adding the info after selecting the contributor would be the more elegant solution!

I believe the frontend has no use for the affiliation info. My sugestion would be therefore to get it on save/update of the DMP. The save already triggers the collection of additional information when certain data is selected. This would just be an additional check, that gathers the most recent (or primary) affiliation data for ORCID users, that have none assigned yet.

[rekt-hard]

@ZenoLC Yeah, that would work!

For a detailed ORCID entry, there are education and employment affiliations. Each has attributes for start-date and end-date. If end-dateis null or end-date is before the current date, it means that it is a current affiliation. However, there might be more than one current affiliation - for education as well as for employment.

Solutions:

• There is exactly one current affiliation in either education or employment, so this one is chosen
• If there is more than one current affiliation
  • Take the one with the most current start date?
  • Rank education or employments higher?
• If there are affiliations but none is current, shall we not take one at all?

[TomMiksa]

Would it be the easiest (in terms of not having to make assumptions) to display the list of affiliations to the user and they could select from it?

[rekt-hard]

That would be an option. The affiliation is not used in the front end anywhere else yet, so we would have to check how it can be integrated. However, a general implementation would be great, to allow adding an affiliation for manually added contributors as well. All of this will require some more changes though

[ZenoLC]

Would it be the easiest (in terms of not having to make assumptions) to display the list of affiliations to the user and they could select from it?

I do not think it would be easier. Currently we have the same implementation for orcid as well as any other person service. To make this change happen we would have to undo this unification, which we did in order to standardize person services within damap, as well as making it easy to replace them with custom ones without changing the code. Instead orcid would have its own implementation in both backend and frontend and have several additions in order to make the selection happen in the UI.

So we end up giving up on the nice unified/standardized person services feature, which is regrettable on both tecnical as well as ease of customization level. But also we add a new TODO for the user, who now has to select an affiliation for each contributor added. This last point I think is contrary to the core idea of damap, where we want the users to do less and not have to know.

[TomMiksa]

We could still argue that ORCID is pretty special type of identifier and it is worth the special treatment. The generic implementation would be common for all other person services, e.g. for each university CRIS connecting DAMAP.

Yet, I agree with your argumentation, especially the last paragraph convinced me. I think we still have many other things to fix that are more important than this. For the time being I would suggest that we "Take the one with the most current start date". If we see that people use ORCID and actually the problem of the wrong affiliation comes up regularly, then we may get back to this. For the time being, most of users are anyway our own researchers.