Expand download url capability within References field

[mradamcox]

current setup

The references field stores a key/value object. When saved in the metadata manager, it looks like this:

The text input form is designed to use this notation to make data entry easier:

Special handling of that field upon form submission converts this notation into the key/value dictionary. This works fine.

problem

In fact, the Aardvark schema allows for a nested list of multiple values whenever the key http://schema.org/downloadUrl is used. Currently, we have used this key with a single URL, but now that we have multiple types of download links, we should be listing them all in this value. (Our stop-gap solution has been to just use a custom key archive-url to point to a secondary download link. This list i

approaches

The way the metadata app is constructed, each field is paired with an HTML widget (and help text) to compose the overall data entry form. What I'm thinking we should do to address the needs described above is alter the references widget somehow to make it easier to enter a list of label/url pairs for multiple download links.

1. figure out a syntax within the existing text box

1a. Maybe we should have people write YAML for this? That can handle lists...

1b. Or come up with an extension on the existing custom syntax, like:

http://schema.org/url:: https://www.epa.gov/smartgrowth/smart-location-mapping#walkability
http://lccn.loc.gov/sh85035852:: https://www.epa.gov/sites/default/files/2014-03/documents/sld_trans45_ug_0.pdf
download:: <download label>:: <download url>

and then combine all lines that start with download into a list of label/urls and put them into the proper key upon validation/submission.

2. create a better widget

The existing text box could stay, and an additional one could be added underneath it that has an easier "label/url" entry for just download links. These could be combined upon form submission and the data cleaned as needed.

important notes

The Aardvark spec points out that this field is stringified JSON. Don't worry about that here, these should end stored as standard JSON, with a normal, non-stringified list of labels/urls for this particular download url key. We stringify things later if needed.

The frontend for the input form and data view for each record is composed in a modular way by iterating every field defined in the backend sdohplace.json schema file. It would be good to avoid building too many exceptions into this pattern, which makes me lean toward option 1b above.