...
We should strongly consider deprecating these calls in favor of the new API, below
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. | DoiDeprecate 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. | DoiMaintain, ditto |
Proposed Changes
Object changes:
- Creation of new Doi (v2) object that implements new interfaces DataciteMetadata and DoiAssociation
- DataciteMetadata
- Separates DOI metadata (that is stored by DataCite) from Synapse-associated metadata
- The client never uses this object, but it clearly delineates metadata that DataCite stores from metadata Synapse stores
- DoiAssociation
- Stores Synapse-associated metadata of a DOI object (like the object ID, etag, etc.)
- Client can request this object to quickly get a DOI without relying on DataCite service availability to collect additional metadata.
- We can return the DOI URI and URL to the client (currently, the URI is "guessed" by the client)
- By using Doi (v2):
- The client can supply and update metadata
- We have the option to extend support to additional metadata fields
- We decouple our API URI from /entity/{id}
- We have the option to extend support to mint DOIs for non-entity objects in Synapse
- DataciteMetadata
- Creation of DoiRequest object to retrieve a DOI and all of its metadata
The new fields in 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 optional fields that we curate. 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.
DataCite-imposed constraints for implementing clients to consider:
- 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
...