Add edition to imprint and new thesis fields

[tmorrell]

❤️ Thank you for your contribution!

Description

This PR adds new fields to the imprint and thesis sections.

• Edition is important to characterize books
• The awarding department and type of thesis are both important to identify a specific thesis

This is a breaking change for thesis, since the thesis field was structured differently from the other publication custom fields and wasn't set up to support additional subfields. This change makes the thesis field consistent with the others, but will require current v12 users of this field to do an upgrade. I'm not sure what's needed to support that or if folks will think it's worth it.

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've added relevant test cases.
• I've added relevant documentation.
• I've marked translation strings (for relevant code).
• I've followed the CSS/JS and React guidelines (for relevant code).
• I've followed the web accessibility guidelines (for relevant code).
• I've followed the user interface guidelines (for relevant code).
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).

Third-party code

If you've added third-party code (copy/pasted or new dependencies), please reach out to an architect.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[lnielsen]

@tmorrell Can you bring it up in the next telecon? In principle I don't see issues with adding the fields. It might have some impact on the serializers to use the new fields (e.g. book edition in citation formats) but better let people agree on first if they want the fields.

[kpsherva]

was the change to mutable value done on purpose?

[tmorrell]

Good catch. Nope, just my copy of the code was older. I've fixed it.

[ntarocco]

@tmorrell thank you for this change. As briefly mentioned during our last discussion, we will also need to have the following fields:

• Date of submission to the university
• Thesis Defence Date

Do you think these are fields that can be added to the default implementation, as many might need the same? Or they are too specific and we should go for new custom fields instead?

[tmorrell]

We will definitely need Thesis Defense Date soon, but I'm not sure how best to implement it since I don't think there is custom field dates js widget. We basically need https://github.com/inveniosoftware/invenio-rdm-records/blob/12576835186dc837df7cdf20d905452eeab8291e/invenio_rdm_records/assets/semantic-ui/js/invenio_rdm_records/src/deposit/fields/PublicationDateField/PublicationDateField.js, but I'm not sure how to get that working within custom fields.

So if you've got some suggestions how to implement it, I think they would be good additions to the default.

[github-actions]

This PR was automatically marked as stale.

[github-actions]

This PR was automatically marked as stale.

[github-actions]

This PR was automatically marked as stale.

[egabancho]

I am also looking into this. Should the dates be added to the thesis:thesis custom field, or would it be enough to use the current dates field and add the two options to the vocabulary on our instances?

I guess from a UX point of view, it might be better to have all the thesis information together ... curious to know what you think ☺️

[ntarocco]

I am also looking into this. Should the dates be added to the thesis:thesis custom field, or would it be enough to use the current dates field and add the two options to the vocabulary on our instances?

I guess from a UX point of view, it might be better to have all the thesis information together ... curious to know what you think ☺️

We will also work on this in the iteration at CERN, and we also have other fields to migrate (@egabancho you might have memories https://cds.cern.ch/collection/CERN%20Theses :)).
We did not yet reach that point. To me, they should be all together when they are specific to thesis.

As a general thought, we will have to decide if we extend the data model, or have dedicated custom fields, maybe as a "Thesis pack", similar to Publishing/Journal fields.
It might be a good idea to have these packs in InvenioRDM and optionally add them, WDTY?

[tmorrell]

Yup, I'll propose a breakout for the next telecon to discuss the thesis fields. I'd lean toward having a specific thesis section....the only issue is if Zenodo/others are alright moving the v12 "thesis:university" into a dedicated thesis section. I think it would also be the first time RDM depreciates a metadata field.

[tmorrell]

This was presented at the telecon, and there was support for depreciating thesis:university and replacing it with thesis:thesis.

One suggestion was to support multiple universities. Having this field be a VocabularyCF would make the field work better and meet this use case, pulling from the existing affiliations vocabulary. Having department and thesis type also be VocabularyCF might also be good, and I'll try to implement that in an improved PR.

Other metadata fields that were discussed were:

• Dates (Approval, Defense) - Similar to existing date field
• Advisor and Committee - Similar to existing contributor field

It's not clear whether these would be better in the thesis block or whether we should reuse the existing fields with new types. It's also not clear how we could make these values mandatory if we use the existing fields, but work on per-community validation could be useful.

Other fields such as major, minor, approved for public release, and retracted could be added by individual sites as custom fields.

There was general discussion of having a state field, but it wasn't clear whether this was specifically tied to theses or should be more general. There was a concern raised about not mixing system and bibliographic metadata fields.

[github-actions]

This PR was automatically marked as stale.