Re-populating metadata field on retrieval of metadata-only deposits

[mpadge]

Clients currently work by accepting input metadata which is converted to DCMI-compliant format and stored in the client's "metadata" field. If a metadata-only deposit is then created via deposit_new(), then subsequent retrieval of that deposit will populate the "hostdata" field, but the original "metadata" field remains empty.

This "metadata" field could only be repopulated through either:

1. Defining a system for reverse-translation from the JSON schemas for the hostdata to the DCMI schema; or
2. Uploading by default a "datapackage.json" file with no resources, but with the DCMI metadata.

Advantage of 1

No "hidden" generation and uploading of files with deposits; metadata-only deposits would remain truly metadata-only.

Advantage of 2

Much simpler and less error-prone.

---

Since the main point of deposits from the outset is to support deposition of data files, and since those are always associated (by default) with "datapackage.json" files anyway, then Option 2 will be pursued here. Future adaptation to Option 1 will still remain possible if desired at a later stage.

[mpadge]

One big glitch: Figshare does not allow automated downloading of files from private deposits. That means no "datapackage.json" file would be able to be retreived for Figshare, and so Option 2 would not work there. Figshare is nevertheless not a primary focus at present, so this issue will still proceed as planned, but will then exclude figshare.

[mpadge]

Even better solution: Embed the DCMI JSON data in one of the host metadata parameters.

• Zenodo: "notes"
• Figshare: "custom_fields" as key-val pairs, so "dcmi_metadata": "{...}"

[mpadge]

Re-opening for one further improvement:

TODO

• [x] Only use the metadata-in-hostdata-field where no "datapackage.json" file exists. If it exists, then use that instead.
• [x] Ensure that the moment a "datapackage.json" file is created, the metadata-in-hostdata fields are also cleared.