sfisher
commented
1 year ago I don't have a problem giving him write access to the API, but the writeable items are mostly limited to creating new versions that will be submitted and/or curated. It's not meant for going back and changing old data. Existing data is mostly treated as immutable since we don't want to modify existing user data and to keep a fairly accurate history of author version changes.
If this is data that is going to be modified in place for published datasets then it's probably best to have him send it to us to manipulate directly in our database.
For related works we'd want to know:
- The DOI of the item in Dryad.
- The related identifier, something like:
https://doi.org/10.1002/cbic.201800592 - The related identifier type (probably DOI for all of them).
- The work type from
article,dataset,preprint,software,supplemental_information,primary_article,data_management_plan - We can generally derive the relationship type between the data and the other work based on the work type. The primary_article gets slightly different treatment (a primary article would likely have article and data from the same authors). However a standard article will set up the relationship and show the article as a related work if it's not known if it's really the "primary" one.
gibsonjen
mariapraetzellis
Ted Habermann has done an analysis of datasets published with Dryad in connection with the University of Chicago Press (a publisher partner for American Naturalist). He found that the information for related articles was missing for a good number of them, and will report on it next week at the community meeting.
He has the missing data – can we please add it to the system? He can deliver it, or we can give him write access to the API (would we?).
Filling in this type of gap, getting the article information that enables us to call on CrossRef metadata, will help us make the other connections we want.
Please let me know!