GUI updates, collected.

[emmetaobrien]

• Validate against list of valid values, or offer list of suggested values, for keywords, formats, type (more specific discussion required)

• when specifying taxonomic data in the interface, to be stored in the isAbout fields, a dummy option should be offered in cases where a species identifier does not apply (e.g. phantoms or other imaging calibration data, in vitro gene expression)

• validate subfields of extraProperties->origin according to the logic specified in https://github.com/CONP-PCNO/conp-documentation/blob/master/CONP_DATS_fields.md (in summary, extraProperties->origin must contain a value for at least one of the institution or consortium subfields)

• validate format of identifier as a DOI (or an ARK when that is implemented).

[jarmoza]

@cmadjar

when specifying taxonomic data in the interface, to be stored in the isAbout fields, a dummy option should be offered in cases where a species identifier does not apply (e.g. phantoms or other imaging calibration data, in vitro gene expression)

There is currently an "Other Entity" option in the "Is About" section. Does that satisfy this request?

[cmadjar]

@jarmoza the "Other Entity" type refers to any other descriptor that is not a species (example: "Alzheimer's Disease")

I think at the. moment, we require that a species should be provided, but it does not really make sense for phantom datasets or calibration data, as you mention.

Should we add a "Not Applicable" option in the species drop down? And for the DATS, if "Not Applicable" is selected, do no save any taxonomy entry in isAbout. @emmetaobrien thoughts on this?

[emmetaobrien]

I definitely favour a "not applicable" value, we want to be able to mark "this dataset has been confirmed as a special case that does not need to have the standard taxonomical values" as distinct from an incoming dataset turning out not to have taxonomic data, which we still want to catch as a genuine error. I have no strong feelings about where in the system we catch this, so long as it is easy to establish and easy for the validators to check - I don't think the DATS schema has a good option for representing this, so leaving no taxonomic entry in DATS.json makes sense, but wherever we do store that information needs to reliably be in synch with the DATS.json file.