| Table of Contents |
|---|
Background & Motivation
See Meredith Slota (Unlicensed)'s 1-pager and the epic issue:
...
- Be able to easily extend the metadata interface
- Submission of metadata can be extended to include optional fields
- DataCite occasionally updates their metadata schema. If we can easily adjust to newer schemas as they are released, then we can more easily avert the risk of using a deprecated schema.
Current API + Notes for change
We should consider deprecating the DOI creation calls.
URL | HTTP Type | Description | Response Object | Notes |
|---|---|---|---|---|
| /entity/{id}/doi | PUT | Creates a DOI for the specified entity. The DOI will associated with the most recent version where applicable. | Doi | Deprecate in favor of corresponding POST |
| /entity/{id}/version/{versionNumber}/doi | PUT | Creates a new DOI for the specified entity version. | Doi | Deprecate, ditto |
| /entity/{id}/doi | GET | Gets the DOI status for the specified entity. | Doi | Maintain, as this will not require a call to another service and should be relatively quick |
| /entity/{id}/version/{versionNumber}/doi | GET | Gets the DOI status for the specified entity version. | Doi | Maintain, ditto |
Proposed API Changes
Object changes:
- Creation of DoiMetadata object (and other child objects contained in DoiMetadata)
- This object is a direct mapping of the most recent version (v4.1) of DataCite's metadata schema, simplified to contain only required fields and a small amount of curated optional fields. This ensures that we don't need to deprecate our API if we wish to support more of their optional metadata fields. If we do wish to support new optional metadata fields, we can easily extend our object.
- Similarly, this is likely to simplify future transitions if DataCite deprecates the schema that we configure to use.
- The existing Doi object and DoiMetadata are proposed to be uncoupled because:
- We store the data in Doi DTOs; it allows us to quickly identify if a DOI has been registered and report that to the client
- We do NOT store the data in the DoiMetadata objects; this is stored by the DOI provider and retrieved when necessary
- Caching this data seems unintuitive; retrieving this data should only be expected when a user considers updating it (see notes for GET in table below), which requires the external service to be available anyways.
DataCite-imposed constraints:
- There cannot be more than 8000-10000 creators
- Publication year must be in 'YYYY' format (regex:
/[\d]{4}/) - There must be at least one creator
- Each creator must have a creatorName that is at least 1 character long
- nameIdentifier is not required, but if an identifier is provided, the scheme must also be provided
- There must be at least one title
- The title should be at least one character long
- There must be a resourceTypeGeneral
...
Note: the Doi object has a DoiStatus field, we need to evaluate how that should be handled with asynchronous workers (we would probably just deprecate that field in favor of using AsynchronousJobStatus).
Internal design notes
This section contains notes about how we plan to interface with DataCite, and what goes on under-the-hood to register/update a DOI
API Choice
DataCite has two APIs that we can use. They have a standard "MDS" API that they recommend for users, and they have a new (but also seemingly temporary) EZ API that is designed for orgs like us who are transitioning from EZID. For the sake of not having to do more work later, we are opting to not use DataCite's temporary EZ API that is designed to mock the EZID API. Instead, we will be using their standard MDS API, as we would need to transition to it eventually anyways.
HTTP Client
The current EZID client interfaces with EZID using now-deprecated implementations of Apache's HTTP client. We will replace this client with a new client that will use our SimpleHttpClient to make requests to the DataCite MDS API.
CRUD Workflows
With the MDS API the basic workflow to create a DOI is to
...
Simply updating the metadata requires just step 1. Both of the above calls are idempotent, so we can combine create and update calls and simply treat the implementation as a create. This would simplify the implementation, though an unnecessary outgoing PUT call would made when existing DOIs are updated.
Retrieval and Conversion of Metadata
DataCite requires that new DOIs have associated metadata that adheres to a schema that they revise occasionally. The current version of their schema is v4.1 (Oct 2017). Metadata that we have registered through EZID is adherent to v2.2 (June 2011), v3, and v4. It is unclear if/when DataCite will deprecate v2.2 and no longer accept it. In another attempt to future-proof our DOI minting service, we will only submit metadata adherent to v4.1.
As a result of this, we must be able to retrieve metadata adherent to schemas 2.2+ in order for the client to update it. We can create a translator tool to convert data from these schemas to an intermediate object (see DoiMetadata above) that can hold the appropriate metadata. This object can be translated into the most recent version of the schema. The client can retrieve and submit this object by interfacing with our API
Required Involvement and Timeline
Outside of our control
DataCite has yet to approve us and give us a registration account. This should happen soon, at which point we have ~3 months to shift to the new provider
Platform
- Create, test, and implement a Datacite Java client that simplifies creating/updating DOIs and their metadata.
- Should begin as soon as we agree upon the API
- This can be done without coordination if we preserve existing behavior, but it would be much easier if we create this client intending to only support proposed and agreed-upon behavior.
- Implementation can use test credentials until we are ready to switch to DataCite in prod
- Create and route new API changes
Clients
- Support asynchronous API + metadata submission
- Can begin as soon as we agree upon the API
- Can implement as soon as it is tested and implemented on backend
UX
- User-facing design of DOI minting process and metadata submission
Questions that need Input
- 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
TBD
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.
...