Introduce Contributor record

[bussec]

Fixes #552

Introducing the changes only in the v3 Schema for now, we can adapt them for v2 once we are finished with the discussion.

[bussec]

It is nearly two years since we discussed this in #552 . In general, the PR should address all the issues raised there, however some of my decisions are noted below:

Contributor record

• I decided against requiring an ORCID iD, which creates some redundancy between the name and the orcid_id.label properties. IMO the information from the ORCID record should take precedence, but this seems to be mainly a question of the user interface.
• The ROR catalog appears to be very comprehensive by now, therefore this is the only way to provide an institutional affiliation.
• As RORs are only assigned to research performing organizations as a whole, there is a free text property affiliation_department to provide more fine-grained information, e.g., institute, division, department, etc.

ContributorContribution record

• This record follows the CRediT taxonomy as far as possible. While we also discussed other, more comprehensive ontologies before, CRediT has in my perception gained a good amount of traction in the last two years.

Study record

• All previous contact or affiliation fields have been replaced with a single contributors property, which is an array of Contributor records. IMO the mapping from the old fields should be as follows:

  • study_contact -> Supervision
  • collected_by -> Investigation
  • submitted_by -> Data curation

  There is no direct replacement for lab_name and lab_address as now all contributors have their own affiliation information.

[bcorrie]

I like it...

[javh]

From the call:

• No objections. Finalize by next meeting.

[bussec]

@bcorrie @schristley @williamdlees please review. The problem with the R package check not running through will be handled by #761.

[schristley]

From looking at the nullable flags, is it worthwhile to list a contributor when only have their name, but no info on their contribution? I'm trying to think of a scenario when that might happen. Maybe curating a publication where it doesn't list contributions so all you know is the person is an author.

[bcorrie]

@bussec I like it, it looks good, but........ 8-)

The fields that got removed I think need to be left in and marked as deprecated, no?

[bussec]

@bcorrie

The fields that got removed I think need to be left in and marked as deprecated, no?

Yes are probably right, but it was so much fun deleting them ;-) I will put them back in ASAP.

On a side note: I guess now it will become more important that our validator functions actually check for the deprecated mark.

[bcorrie]

Yes are probably right, but it was so much fun deleting them ;-)

I figured as much... 8-)

[bussec]

@bcorrie Ok, deprecated fields in Study are now back in place with a deprecated tag. I did not re-add the field from other objects, as those are part of "experimental" schemas and my interpretation of that status is "User beware, things will change without explicit notice". Does that sound right to you?

[bussec]

From looking at the nullable flags, is it worthwhile to list a contributor when only have their name, but no info on their contribution? I'm trying to think of a scenario when that might happen. Maybe curating a publication where it doesn't list contributions so all you know is the person is an author.

@schristley You are correct that ContributorContribution.role is not nullable, however Contributor.contributions (which is an array of ContributorContribution records is. So if the contribution is unknown, you can have an empty array here. On the other hand, it does not make much sense to me to have a ContributorContribution record in which role is not specified.

[schristley]

@schristley You are correct that ContributorContribution.role is not nullable, however Contributor.contributions (which is an array of ContributorContribution records is. So if the contribution is unknown, you can have an empty array here. On the other hand, it does not make much sense to me to have a ContributorContribution record in which role is not specified.

Right, I wasn't sure which way I was leaning but I think I settled on that it's more important to list somebody as a contributor even if we don't know their exact contribution versus being forced to leave them off as contributors.