...
- Should we permit creating DOIs for any object? Or just entities?
- Shifting to support DOI non-entity objects is non-trivial but it would be easier to support them sooner than later
- Schema enforcement
- Should we force users to provide required metadata to mint a DOI?
- One required metadata field is ResourceTypeGeneral, which has specified categories for the type of resource a DOI refers to. Should we omit categories of resources that are likely not in Synapse? Like "Audiovisual" or "Physical Object". There is no technical benefit of excluding these fields.
- Future feature expansion: which recommended/optional metadata fields should we permit or require?
- Synapse could theoretically support all metadata fields, but for scope/UX reasons, maybe we shouldn't. Input from UX, users, anyone would be helpful.
- Should we force users to provide required metadata to mint a DOI?
- Which fields should be immutable?
- DOI ID (this can actually be retrieved from the API call rather than the request body, so the client doesn't need to worry about this)
- Publisher: "Synapse"
- Publication Year?
- Do we hide these from the client, or just automatically overwrite them if they try to change them?
Mockups
TBDMockup of what the DOI minting form could look like. This form could be presented when a user clicks "Mint DOI for this Project/File" (as they currently do)
Misc. Notes
When we retrieve DOI data for existing Synapse entities (published to Datacite through EZID), the metadata adheres to schemas as old as Datacite Schema 2.2 (the most recent version is 4.1). We can leave these alone, and force users to supply the metadata required to be compliant with 4.1 if they want to update the info. This way, we avoid running into issues if/when the old schema is deprecated.
...