This PR decreases the minimum cardinality for Pooling.has_input to 1

[turbomam]

• min_cardinality of Pooling's has_input in v7.7.0 incompatible with NEON data #1014

down from 2

[turbomam]

which do we really want?

[turbomam]

@aclum this will be an easy issue and PR for me to close, if you feel confident about the minimum and or maximum number of inputs into a Pooling process.

[aclum]

@turbomam Where is the example data driving this change? Conceptually sample does not go through pooling for a sequencing lab workflow unless there are at least two samples so I think we should leave the minimum cardinality as 2.

[turbomam]

@aclum this PR was opened at the end of August. I think we tried setting a minimum cardinality of three on Pooling.has_input and then found that there were some Neon Poolings with only two inputs, so we just completely removed the minimum cardinality constraint. We can leave it off, or change the minimum cardinality to 1 or 2.

But I don't have any motivating data and would be happy to close this PR without merging if you think that's best.

[aclum]

@turbomam Am i reading the schema incorrectly? I read this as the minimum cardinality for slot has_input is currently enforced as 2 in the main branch of the nmdc schema for class Pooling.

[turbomam]

Sorry for dragging you into this, @aclum. Yes, I see what you mean and suggest that we just close this PR without merging.

[aclum]

@turbomam agree