| Table of Contents |
|---|
...
- Point the DOI to the web client URL. This type of DOI is good for human beings as the users. But it prevents the R and Python clients from using the DOI.
- Alternatively, we can point the DOI to the repo URL. The entity is fetched as an JSON object. This type of DOI favors the analytical clients. But the human users of the Synapse website will find it less appealing.
- Provide two separate sets of DOIs (doing both 1 and 2). Different client will pick the proper DOI to use.
If we choose the web URLs as the DOI redirect, the R/Python clients need to rewrite the URLs to repo service URLs. Now imagine the R/Python client calls dx.doi.org to resolve a DOI. The servers returns a 3XX response with a Synapse web URL (e.g. http://synapse.sagebase.org/#Synapse:syn12345.2). The R/Python client then rewrites the web client URL with the corresponding repo service URL (e.g. http://repo.sagebase.org/entity/syn12345/version/2) and proceeds to call the repo service to get the entity. The rewrite is the additional logic for the R/Python clients to use the Synapse DOIs. If we combine the idea with projects SWC-422 and SWC-423, the web and repo URLs will assume the same format, only the server part needs to swapped for the rewrite.
Another question about metadata is what else to include in the metadata. The EZID demo lists the author (who), the title (what), and the timestamp (when). As I was testing around, several fields were indeed required for generating DataCite DOIs. Here is the DataCite Schemas. The most recent schema requires Creator, Title, Publisher, PublicationYear besides DOI. Again, we need pay attention to the escaping, encoding specs here when supplying the data. Here is the proposed mapping of the required fields.
Creator – Entity CREATED_BY
Title – Entity NAME
Publisher – Sage Bionetworks
PublicationYear – The timestamp this DOI is being created
Granularity
What entity type? Project or data? Public or private? Which Version.
...