[epic manual datasets] Make sure researchers can add datasets manually, in line with publications

[mietcls]

Epic

Datasets: make sure researchers can add their datasets even without a DOI.

• [x] #904
• [x] #905
• [x] #907
• [x] #908
• [x] #909
• [x] Make sure "languages" is also added for manual input and DOI import #1063
• [x] https://github.com/ugent-library/biblio-backoffice/issues/1105

To be completed in a next issue

• [ ] Import via identifier
• [ ] Outstanding manual import via identifiers see https://github.com/ugent-library/biblio-backoffice/issues/904
• [ ] Validation of identifiers

Context

We chose not to implement the separate PIDs just yet, for the following reasons:

• This gives all researchers the possibility to enter their datasets, regardless of the accepted PIDs
• It gives us space to see which PIDs are used most often, which will help us prioritise
• If any dataset metadata aggregators come to life, we can integrate with them
• This gives non-standard PIDs the time to adapt to the current standards. Some PIDs are not grown nor stable enough to integrate with.
• It buys us time.

Gathered information from curators: improvements and structures

Critique

We want to adopt the "Never start from 0 approach." – and this is the opposite. However, doing that for each PID will take too much time. This approach will make sure we can be ahead of grants and expectations, and keeping the right information will keep our solutions flexible.

There is an opportunity being sketched out with the MVP for the bulk import UI that replaces the TUI / GRPC for librarians approach own ticket #1072

[netsensei]

The "more context" doc gives a 404 error.

[mietcls]

Fixed the link @netsensei

Edit: I chose to put it in the comments as it is old background information.

More context here about the different PIDs and discussions with the data steward team

[nics]

@miet we also need a field for the identifier itself that replaces the current "DOI" field at least 3 fields in total: identifier_type identifier url

Do we need to anticipate multiple identifiers?

Decided on a data structure that supports multiple identifiers and values to futureproof it.

[mietcls]

Thought process for later:

• We can't not allow manual links when we cannot autogenerate them, as we would not be able to use existing features (clicking on the link on the overview page etc)
• I would not allow to edit auto-generated links to keep it simple, and observe the behaviour
• Other links can be added to the link group below
• If researchers get stuck we can improve the behaviour.
• We will add extra identifiers later when we know more about our added identifiers and we've observed usage

[nics]

@mietcls work is happening here https://github.com/ugent-library/biblio-backoffice/tree/feature/identifier_type

[mietcls]

@nics thanks! If there's anything specific you'd like me to take a look at, please yell. When I have my new lappy I can perhaps test it locally 🙌