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

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