Should sample_type be required?

[bmeluch]

We have a slot for sample_type, but it is "recommended" not "required" and is not consistently used. Its range is SampleTypeEnum which includes values similar to the options in the submission portal: soil, soil - water extract, plant associated, sediment, water

There have been instances recently where it would be really nice to know the type of a sample. (e.g. checking that depth values meet our standards by sample type, in process notebook to visualize NOM data )

The sample type can be derived from required slots that have information for all biosamples (yay!)
...but those slots are the environmental triad, so you have to comb through ENVO terms/IDs, which is really not user-friendly (boo)

I know there was reasoning for not having sample_type required, but I don't know what it is. Thoughts?

[bmeluch]

@mslarae13 as discussed last Thursday I think

[mslarae13]

Related to

• Multiple sample type metadata templates issues#766

Capturing sample type would be required for success.

[kheal]

If we can derive samp_type from the ENVO terms/IDs, I think it would be better if this population was done without human interference.

In other words, can we populate samp_type automatically from ENVO terms/IDs rather than requiring it upon submission (and therefore opening up the opportunity for error by mismatching the samp_type with ENVO terms/IDs)? I'm not sure how this could be implemented, but that is how I would approach it - make a set of rules or functions to populate it from already required fields.

[mslarae13]

If we can derive samp_type from the ENVO terms/IDs,

That's too risky IMO. What if we're wrong? It should come form the person... and the environmental triad terms are not peoples strong suit.
But for what's currently in Mongo, maybe we have to?

I think it would be better if this population was done without human interference.

I don't think we need additional human interference in the submission portal, we populate it with the extension they select.
The problem is data in mongo needs migrated to include that attribute, or it's invalid.

[bmeluch]

The problem is data in mongo needs migrated to include that attribute, or it's invalid.

@turbomam and I have both done sample type categorization by ENVO term recently, we can compare notes, this is doable

my very manual R code using only env_medium values currently in mongo: microbiomedata/issues#612 (comment)

(Mark do you have a link to the ENVO based sample typing you showed in the 1pm meeting yesterday? I can't find it)

[mslarae13]

It was a google sheet

[turbomam]

Could this be what you are talking about?

nmdc-production-biosamples-env_package-predictions

I suggest using the contents of the predicted_curated_env_package column to fill in each Biosample's env_package. I ahven't really thought about actions related to sample_type, but I will now.

[bmeluch]

more thoughts... once we get the environmental package auto importing from the submission portal, does it go into env_package and/or sample_type?

sample_type says "This can vary from 'environmental package' if the sample is an extraction." which I read as "these two slots are the same unless the sample is an extraction"

I know env_package comes from MIxS. It seems like our SampleTypeEnum currently captures some MIxS extensions, and our env_package is currently just a string. Seems like they should both be enums maybe?

I'm not fussed about which slot ends up being required. I just think at least one of them should be, so that it's easy to know for ALL biosamples, in a less subjective slot than the environmental triads, which are from soil or whatever.

[mslarae13]

sample_type says "This can vary from 'environmental package' if the sample is an extraction." which I read as "these two slots are the same unless the sample is an extraction"

This might be outdated since extractions are processed ssamples now.

I know env_package comes from MIxS. It seems like our SampleTypeEnum currently captures some MIxS extensions, and our env_package is currently just a string. Seems like they should both be enums maybe?

agreed

I'm not fussed about which slot ends up being required. I just think at least one of them should be, so that it's easy to know for ALL biosamples, in a less subjective slot than the environmental triads, which are from soil or whatever.

I advocate for making the env_package (should be extension) required.

[bmeluch]

#2167