Update validation rules for DNA Well Number

[pvangay]

DNA Well Number should be required only if DNA Container Type is "plate". This dependency between columns might not be possible in data harmonizer--if it is not supported, I suggest making DNA Well Number not required.

Plate corresponds to a 96-well plate so the allowable values for DNA Well Number should be a letter followed by a number (e.g. A4, H7, B12), with possible values ranging from A-H and 1-12.

[turbomam]

DNA Well Number should be required only if DNA Container Type is "plate"

We don't have dependent validations in DH yet

[turbomam]

Validation is a good idea, as long as the plates are of the 96 well format.

I'm going to try the following. Please let me know whether it meets your expectations.

• string serialization: {96 well plate pos}
• regular expression: ^[A-H](0?[1-9]$)|(^1[0-2])$

[turbomam]

Also applying to RNA Well Number

[dehays]

This is more complicated than what is described here. Take a look at Plate Submission Guidelines

In addition to corner well locations being required to be empty (so A1, A12, H1 and H12 are invalid well locations) there can be no gaps in plate loading. We do this validation server-side at JGI at submission time. A consideration going forward is that with NMDC taking on the external researcher point-of-submission for sample metadata there comes inherent external researcher support responsibilities and resourcing. Just saying - in future when DH is dealing with real sample metadata submission, the validation needs to match what JGI provides now. A successful submission via NMDC that fails validation for JGI will require much manual effort to correct. (Thus the need for closer programmatic interaction with JGI systems.)

[pkalita-lbl]

Basic validation (including not using corner well locations) is currently encoded in the submission schema. I don't think there's a feasible way to encode "no gaps in plate loading" into the schema. That would presumably need to be custom validation code in nmdc-server. If we want to take that on, let's make a separate issue for it in the appropriate repo. cc @mslarae13