Add DOI to EML when publishing publicly to figshare about eml HOT 6 CLOSED

We also have a DOI service when publishing to the KNB (using the standard DataONE MN.reserveIdentifier() service), so it would be nice if the reml API calls were the same for the different repositories. In general, can we avoid having different API calls for uploading objects to the different repositories?

from eml.

I agree entirely.

My thought was that a user would always upload the eml_publish()
https://github.com/ropensci/reml/blob/master/R/eml_publish.R. I've tried
to make the eml_publish() API flexible enough to support different
metadata that we may need when pushing to different servers (it takes only
file, destination (e.g. figshare, knb) and "..." as arguments).

eml_figshare should probably be an internal function. I'm always a bit
uncertain what to expose in the NAMESPACE and what not to.

On Sat, Jun 29, 2013 at 1:58 PM, Matt Jones [email protected]:

We also have a DOI service when publishing to the KNB (using the standard
DataONE MN.reserveIdentifier() service), so it would be nice if the reml
API calls were the same for the different repositories. In general, can we
avoid having different API calls for uploading objects to the different
repositories?

—
Reply to this email directly or view it on GitHubhttps://github.com/ropensci/reml/issues/23#issuecomment-20237065
.

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

from eml.

reml currently generates a uuid identifier when writing out the XML. When publishing to the KNB, this identifier is used by default, and currently we don't have a mechanism in the API to request a DOI. (Likewise, when publishing to figshare the identifier in packageId remains the one generated and the DOI isn't added. Not sure what we should do when a user writes out an EML document and it receives a uuid for its packageId, and then is given a DOI on upload.

• Presumably we keep both identifiers? How do we structure that in the EML (both for the metadata file / packageId, and for the csv file)? Is there something that will indicate that the DOI is the canonical id?
• What should the workflow to request a DOI look like? (In figshare, this happens whenever a document is declared public. Presumably we don't want to enforce that behavior for KNB though, so I suppose we need a different option for getting a DOI through the KNB? Unsure how best to do this while keeping a consistent API for uploading to the different repositories (as @mbjones advises above).

from eml.

@mbjones Quick questions on reserving a DOI through KNB: Looks like from the documentation that identifiers other than uuid are not yet available through the dataone API? Is that still current? Is this method implemented in either version of the dataone R package?

A related question is I'm reluctant to test or document an example of reserving a DOI since we don't want to consume DOIs needlessly. Does KNB or dataone have guidelines in place for when / what kind of data to request a DOI for, as opposed to another identifier? What happens if I reserve a DOI using the development/testing servers instead?

from eml.

@cboettig Each MN can support different identifier types. If the MN does not support the id type you want, you'll get a Exceptions.InvalidRequest back. The KNB supports two identifier types: UUID and DOI.

You can reserve IDs on the development servers with impunity -- they come from the test DOI server and are not preserved.

On the KNB production server, please don't reserve any DOIs for testing. For real data packages, you can reserve DOIs and use them from whatever parts of the data package you'd like, but we've gotten pushback from DataCite for issuing lots of DOIs for the various components and revisions contained in a data package. So, more recently we have focused on publishing a DOI for the metadata document and using UUIDs for all of the components (data files, resource maps, etc), as the metadata document is the main visible entrypoint for the data package and is presumably what should be cited and linked to). But we leave this decision up to client tools as the service lets you generate and use DOIs how you wish.

from eml.

publish can be handled separately by dataone now

from eml.