multiple affiliations

[jspaaks]

Related issues

Refs:

• Should the key "affiliation" in person objects accept a string or an entity object? #38
• Authors with multiple affiliations #268

Describe the changes made in this pull request

This PR changes the schema such that it can accommodate authors with multiple affiliations. Under this PR, the following would be valid:

# affiliation as string
authors:
  - affiliation: The affiliation name
    name: The author name
cff-version: "1.3.0"
message: The message
title: The title

# affiliation as strings
authors:
  - affiliation:
      - The first affiliation name
      - The second affiliation name
    name: The author name
cff-version: "1.3.0"
message: The message
title: The title

# affiliation as entity object
authors:
  - affiliation:
      name: The affiliation name
    name: The author name
cff-version: "1.3.0"
message: The message
title: The title

# affiliations as entity objects
authors:
  - affiliation:
      - name: The first affiliation name
      - name: The second affiliation name
    name: The author name
cff-version: "1.3.0"
message: The message
title: The title

# mix of strings and entity object
authors:
  - affiliation:
      - name: The first affiliation name
      - The second affiliation name
    name: The author name
cff-version: "1.3.0"
message: The message
title: The title

These examples are for an entity author, but it works the same for person authors.

For the record, I don't see much added value of allowing entity and array of entity and string and array of string, compared to allowing just string and array of string. But there is a real cost for implementers and maintainers of tooling (cffconvert, cffinit), which for a project that has been ran on fumes might not be a sustainable choice.

Review checklist

• Please check if the pull request is against the correct branch
  (format/schema/semantic documentation changes: develop; typos, meta files, etc.: main)
• Please check if all changes are recorded in CHANGELOG.md and adapt if necessary.
• Please run tests locally.

cd $(mktemp -d --tmpdir cff.XXXXXX)
git clone https://github.com/citation-file-format/citation-file-format .
git checkout <branch>
python3 -m venv env
source env/bin/activate
pip install --upgrade pip wheel setuptools
pip install -r requirements.txt
pytest
<do other things>

• <do other things>

[sdruskat]

Nice one, cheers!

[sdruskat]

Two ways to go with this pull request:

1. Accept the risk of misuse and safety issues (date-start being taken for the lifetime of the entity itself, not the affiliation; potentially infinite recursion into affiliations' affiliations, etc.) and merge as is.
2. Implement a dedicated affiliation (entity-like) object without: dates, affiliation, (orcid). In the context of such a new class, discussions around introducing insitutional levels (institute, dept., etc.) may be had, but aren't necessarily where we would want to go.

[alexlancaster]

Two ways to go with this pull request:

1. Accept the risk of misuse and safety issues (date-start being taken for the lifetime of the entity itself, not the affiliation; potentially infinite recursion into affiliations' affiliations, etc.) and merge as is.

2. Implement a dedicated affiliation (entity-like) object without: dates, affiliation, (orcid). In the context of such a new class, discussions around introducing insitutional levels (institute, dept., etc.) may be had, but aren't necessarily where we would want to go.

Would this new multiple affiliation class allow for ror identifier? This is import for Zenodo output where the ror is used to display organizations, for with something along the lines of the following CITATION.cff fragment:

 - family-names: Mariani
   given-names: Michael P.
   orcid: https://orcid.org/0000-0001-5852-0517
   affiliation: 
     - name: Mariani Systems LLC
     - name: University of Vermont
       ror: https://ror.org/0155zta11

(note that the first affiliation has no ror key).

I would expect cffconvert to be able to generate the following .zenodo.json:

    {
      "affiliations": [
        {
          "name": "Michael Mariani LLC"
        },
        {
          "id": "0155zta11",
          "name": "University of Vermont"
        }
      ],
      "name": "Mariani, Michael P.",
      "orcid": "0000-0001-5852-0517"
    },

see the full .zenodo.json:

https://github.com/alexlancaster/pypop/blob/b14d133dc5763a4118dc10dfff95703cba466b7f/.zenodo.json#L64-L76

See the rendered version on Zenodo: https://zenodo.org/records/10648000 which includes the ror IDs.

Currently this is impossible, so I have to maintain the data in two places at once. I am unsure as to whether this PR would support this. If not, I would say it's incomplete, as this is a major use case.

[sdruskat]

Thanks @alexlancaster for this input!

Would this new multiple affiliation class allow for ror identifier?

Yes, RORs for entities have been introduced into the schema with #484 and will be part of CFF 1.3.0.

I would expect cffconvert to be able to generate the following .zenodo.json:

    {
      "affiliations": [
        {
          "name": "Michael Mariani LLC"
        },
        {
          "id": "0155zta11",
          "name": "University of Vermont"
        }
      ],
      "name": "Mariani, Michael P.",
      "orcid": "0000-0001-5852-0517"
    },

see the full .zenodo.json:

https://github.com/alexlancaster/pypop/blob/b14d133dc5763a4118dc10dfff95703cba466b7f/.zenodo.json#L64-L76

See the rendered version on Zenodo: https://zenodo.org/records/10648000 which includes the ror IDs.

I suggest to track this in the cffconvert repo rather than here.

[alexlancaster]

Thanks @alexlancaster for this input!

Would this new multiple affiliation class allow for ror identifier?

Yes, RORs for entities have been introduced into the schema with #484 and will be part of CFF 1.3.0.

Yes I did see that, I just wanted to be sure that ror applied to multiple affiliation (as opposed to the examples, which only show multiple affiliation examples where name is repeated) would also work. I tried porting the schema change in this PR to my fork of cffconvert and it appeared to validate the CITATION.cff fragments like the above OK (even though it didn't output it correctly, because the support isn't there yet), which suggests that it should work.

see the full .zenodo.json:
https://github.com/alexlancaster/pypop/blob/b14d133dc5763a4118dc10dfff95703cba466b7f/.zenodo.json#L64-L76
See the rendered version on Zenodo: https://zenodo.org/records/10648000 which includes the ror IDs.

I suggest to track this in the cffconvert repo rather than here.

Will do.