think through submission form to see if there is a better way to associate a vis with a dataset submission

[amzoss]

would only happen in the case where the basic metadata (creator, title, date, etc.) is the same for a dataset and the visualization based on it. otherwise, might as well make it two submissions and link between.

[cassws]

@amzoss @ejklein One proposal: From a user ease perspective, I think it would be worthwhile to allow for a "both" option under the question:

Is this a dataset or data visualization example? (If you have both, submit each separately.)

Instead of asking for separate submissions. That feels much friendlier - I feel like I'd be stressed having to add a bunch of metadata fields twice. In another possible scenario where the submitter is submitting something that builds off of a dataset or dataviz (or, say, posts the dataset the next way), we can ask a question like:

Is this submission directly related to a dataset or data visualization? If so, please add the URL here.

And use that at the basis of forming a link-like association.

To support all of that, we'd need:

2. A process whereby the submission reviewer can look for any link relationships and represent them in, eg, a simple links.csv file.
3. A representation of links within wax/jekyll in a data structure (not hard)
4. A parsing step that adds the appropriate URL to any "linked" collection items - whether as a rake task or otherwise (harder)

Even though this produces a little extra work, I think conceptualizing links as their own .csv and data structure will save us angst later on (such as remembering to go back and update the item to which the new item links). If this sounds reasonable from the survey-side, I can get working on that from the wax-tasks side!

[amzoss]

Hmm, interesting. I'd be tempted to talk a bit more about this before committing to a separate file that we need to remember to maintain. I could see it also working to have the submission form collect "link" information in something like plain text for something that has been submitted but isn't public yet or a link for something that is already public. Then, in the data curation workflow, that could be converted to a list of PIDs in a cell. We already know we're going to have to process lists in cells, so if those are lists of valid PIDs, presumably everything from there on can be automated. From a maintenance perspective, I think it might be more minimal to have the PIDs in the collection metadata .csv file directly, rather than matching to a separate file, but I could be missing something!

[amzoss]

We now support "both" if dataset and vis share the same metadata.