Create metadata form mocks

[franklin-feingold]

This form would populate the screen after the dataset upload. This form would capture the metadata of the dataset needed to add into the search database to allow it to be findable across a number of different metrics.

[WIP] determining the metrics to capture in this form and confirm that each dataset has. (what is required vs optional)

[franklin-feingold]

Update: determined the first iteration of useful metrics to search for datasets across. This is the form I am using to collect this data. If a similar version (capturing this metadata) can populate the screen in parallel to data uploading (through web browser). For CLI uploaders, the user would have to fill out form before data goes public. There would be an indiction (potentially a banner?) to help with this. The information may have its own tab so information can be amended (editable) by the DS admin/owner.

[trevor-squishy]

After confirming with @nellh, most of the form values can be derived from the dataset upload itself, which allows us to drastically reduce the length of the form. As a result, I have added the shorter form to Step 2 of the upload process since this is the step where information is entered/modified.

The form can be compact with multiple fields on one line or longer with one field per line with content flush left for easier scanning. Note, the two select/pull-down boxes currently have an 'Other' option, which will progressively disclose a text field below the select box, allowing the user to specify what 'other' is (see Dataset Form - Filled -Other Fields).

For CLI uploads, the dataset form can be presented on the Publish page before making the dataset public. This could be the case for uploads via the browser as well, which could eliminate step 2 in the browser upload process entirely.

So, chew on these designs for a little while and then we can determine which design(s) to iterate on and/or move forward with. Also, if any of the dataset form fields are required, please let me know.

Designs

[ckrountree]

Dataset name and species should be required dataset form fields. The other fields, that are required, come from the validator (i.e. number of subjects). So, they are captured by the validator and should be set there.

[ckrountree]

@trevor The client has reviewed this...

• Although CLI users still need to go to the OpenNeuro site to publish the data, it might be a good idea to provide a brief message on the CLI noting this (Add reminder to publish on openneuro.org after CLI upload #1186).
• The form currently only shows, on the "publish" display, the 'user input' figures. Can we also show the validator-captured numbers (in the possible case where the validator doesn't capture a figure correctly). This could provide additional information as to why the validator did not properly grab the correct data. (new ticket - Show validator-captured data on "Publish" display #1173)
• Can Franklin also be emailed new published DS, with the metadata, to update his tracking form? (Implement ability to email newly published ds, with metadata, for updating the tracking form #1174)

[trevor]

@ckrountree Hi.

[nellh]

The form currently only shows, on the "publish" display, the 'user input' figures. Can we also show the validator-captured numbers (in the possible case where the validator doesn't capture a figure correctly). This could provide additional information as to why the validator did not properly grab the correct data.

The summary output could be shown along with the input. Some of the proposed fields are not included in the summary output yet so that makes the bids-validator improvements a prerequisite.

One issue with including this on the publish tab is there is no way to see or edit these fields after a dataset is published.

@franklin-feingold How do you see this data relating to the a given snapshot? Is it saved at time of snapshot or is it outside of the history for the dataset? Validator summaries are per commit. We could write these new fields into datasets but we would need to decide on formats and location within the datasets.

[franklin-feingold]

I can see this data relating to a snapshot. I can see cases that metadata would be updated per snapshot (perhaps like what data is being offered or things the owner did with it the newly added data). That information could be elsewhere, but some can be captured in this form.

The draft could have the editable fields whereas the snapshots show what the metadata is? This form could go onto a different page to not conflict with not being able to see or edit once the dataset has been published. Can the missing information (not in validator output or input) be gathered after the upload is complete and as the dataset landing page is being rendered?

[nellh]

Well if we want the lifetime of the data to follow the history of the dataset (be preserved as it was in snapshots), I think we should add this to the contents of the dataset somehow. Maybe an OpenNeuro specific JSON file?

[franklin-feingold]

I think that sounds good! This json file would then become part of the dataset files and it would also be downloaded with the dataset?

[nellh]

I think that sounds good! This json file would then become part of the dataset files and it would also be downloaded with the dataset?

Yes. Is there a BIDS compliant way to do this?

[ckrountree]

@nellh @franklin-feingold

This last bit of conversation has been captured in a new ticket for better tracking (#1173).