Multiple author affiliations

[GaziYucel]

Related issues:

• Need to support multiple author affiliations #7135

Related pull requests:

• ojs: Multiple author affiliations ojs#4469
• pkp-lib: Multiple author affiliations #10460
• ui-library: Multiple author affiliations ui-library#417
• googleScholar: Multiple author affiliations googleScholar#23

[GaziYucel]

Hi,

Some notes.

• I have made some assumptions regarding business logic in several places. The ones I am uncertain about are the import/export classes:

  • plugins/importexport/native/filter/NativeXmlPKPAuthorFilter.php
  • plugins/importexport/native/filter/PKPAuthorNativeXmlFilter.php

• During an upgrade from an earlier version, the ROR cache is filled during the upgrade. After this a migration is done for all affiliations currently saved for the authors. First a match is searched for all ROR on an exact match for the names. After this all remaining is migrated as a non-ROR affiliation.

• There is an issue regarding the ROR data. Most affiliations have a name in one language, sometimes 2 -3 languages. Not all have a name in English. This is an issue regarding searching for a name in the backend.
  For now I look for an alternate name and show this if an English name is not there, with at the end the language. For example: "Technische Universiteit Delft [Dutch]".

• The class in "classes/task/UpdateRorRegistryDataset.php" is responsible for updating the ROR cache. There are a lot of records without a language code. These are marked with "no_lang_code". I replace these with the locale code 'en'.

• And a question regarding the class PKP\API\v1\submissions\PKPSubmissionController.
  If you look at the method getContributor, you see this at the end of this method.

  return response()->json(
  Repo::author()->getSchemaMap()->map($author),
  Response::HTTP_OK
  );
  

  I expected that the method "getSchemaMap()->map($author), also transforms "affiliations" to it's schema. But this is not happening, only author is mapped. Affiliations stays as in PHP, with "_data" and other keys still in it.

  I defined in the schema of author (schema/author.json) the following:

  "affiliations": {
  "type": "array",
  "description": "The scholarly institution this contributor is employed by or affiliated with.",
  "apiSummary": true,
  "readOnly": true,
  "items": {
      "type": "object",
      "$ref": "#/definitions/Affiliation"
  }
  },
  

  This is what I came up with, but this feels as a hack.

  $mappedAffiliations = [];
  foreach ($author->getAffiliations() as $key => $affiliation) {
  $mappedAffiliations[] = Repo::affiliations()->getSchemaMap()->map($affiliation);
  }
  
  $author->setAffiliations(new LazyCollection($mappedAffiliations));
  

  How should I do this to make affiliations also transform/map to it's schema?

[GaziYucel]

Hi @bozana. This PR is ready for review. Thanks.

[bozana]

Hi @GaziYucel, I am still reviewing the code and would also like to test it locally (also to understand some things better) but I wanted to already suggest something regarding the native import/export:
I think we could introduce the additional element rorAffiliation for the author, that could occur several times and that would contain the element ror and localized element name.
The existing localized element affiliation could be used for the authors affiliations without ROR.
The examples how multiple affiliations and an affiliated institution with its identifier are represented in JATS can be found here: https://jats.nlm.nih.gov/archiving/tag-library/1.3/element/aff.html

[bozana]

Hi @GaziYucel,
and maybe regarding your last question above -- "And a question regarding the class PKP\API\v1\submissions\PKPSubmissionController" -- regarding the mapping of affiliations to the author: I think you could take a look how this is solved for issues and articles, e.g. here https://github.com/pkp/ojs/blob/main/classes/issue/maps/Schema.php#L111. I think something like this could work for this case as well.

[bozana]

Hi @GaziYucel,
And regarding the replacing no_lang_code with en: I think we cannot do it -- this way the original en entry can be overridden. We just cannot map no_lang_code to anything correctly. We would need to leave it as is.

[bozana]

Hi @GaziYucel, I left some comments.
Because we decided not to copy ROR names to author_affiliation_settings table some things will change here, so I can take a look once that is done...
About a few things I would maybe also need to think a little bit more, but I left a comment -- maybe you would immediately have an idea...
And because I have not taken a look at the OJS PR yet i.e. I would need some time to see how such affiliations need to be exported into different formats, I will probably first then know what Affiliation::getLocalized... function are needed...
So I am already submitting this comments so that you can eventually already integrate some of them when working on the new version without copying...
I am wondering if we should keep this code version in case Alec has good arguments that we should proceed with copying -- because he has not said anything yet... although I do not think it will be the case...
Thanks a lot for this great work!

[bozana]

This function will maybe not be needed when we implement the native import/export with separate elements for each author affiliation

[GaziYucel]

Hi @bozana
I implemented validation for affiliations in this commit:

• f92025f
• 5b0ebd3

I had to remove Repo::affiliation()->saveAffiliations(..) from Repo::author()->dao->insert(..) and Repo::author()->dao->update(...) for this. I added Repo::affiliation()->saveAffiliations(..) to classes where the insert and update are called. Otherwise I can't check if an author exists.

To wrap up, I have done all your notes of your review. What's left now is the no-copy of ror names.

I will make a copy of this branch in my fork, to have a backup. After the copy, I will implement the no-copy in the current branch/PR.