Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add function to publish EML data through figshare #3

Closed
5 of 6 tasks
cboettig opened this issue Jun 26, 2013 · 1 comment
Closed
5 of 6 tasks

Add function to publish EML data through figshare #3

cboettig opened this issue Jun 26, 2013 · 1 comment
Assignees

Comments

@cboettig
Copy link
Member

Involves several steps:

  • Update the EML publisher information as figshare
  • Update the EML distributed online URL location with the figshare link
  • Update EML link of csv and other data files to their download URLs from figshare
  • package EML and all data files (CSV, images, code, etc) as figshare file object. (Will mean using fs_create to establish the figshare link metadata first. Files will need to be uploaded to get their URLs, then the EML file will need to be modified with those URLs.)
  • EML keywordLists for both the figshare tags and figshare categories (with categories reflecting figshare limited thesaurus).
  • Likewise figshare metadata should all come from the EML file.
@cboettig
Copy link
Member Author

Need to think out workflow issues here.

Option 1

Generate the EML first with eml_write. Then call eml_publish("file.eml", destination="figshare") to publish.

This approach would rely on the EML file to generate the minimal metadata required by figshare, along with any additional metadata we choose to supply.

This would create a problem for cases where the EML file (perhaps not generated by REML) did contain enough metadata for figshare publication (e.g. figshare category). I suppose we could warn in those cases, or include an argument where the user could provide a category, etc.

Option 2

Call eml_publish directly with data and metadata, avoiding the need to call eml_write explicitly (in this version, eml_publish would obviously call eml_write. In some ways this is easier to write, since the eml_publish just takes a list of all the arguments to fs_new_article (or the components thereof), along with all the arguments to eml_write (to which it could also append the figshare metadata).

The down-side of this approach is that the function call itself may be a bit more clumsy.

Both?

We might want to support both options, but providing a clean and intuitive API (function call) becomes tricky...

Additional strategies and things to look out for

  • Want to avoid re-writing metadata to the EML that already exists there.
  • Default settings probably want to include support for some figshare metadata, such as preferred category.
  • Maybe an id=figshare metadata node (with EML keywordList, etc) should be added? Would be the easiest way

@ghost ghost assigned cboettig Jul 1, 2013
cboettig added a commit that referenced this issue Feb 26, 2016
support repeating element defined by xs:choice (see #3)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant