Multi valued library selection

[PMenges]

Is your feature request related to a problem? Please describe.
High number of smilar-ish methods for library selection leads maintenance overhead + high granularity. With too similar values the CV has little value over free text.

Describe the solution you'd like
Multi instead of single value, meaningful selection of terms that can be combined to describe the used library selection method

Describe alternatives you've considered

• Free text, not ideal
• Steadily expanded CV, not scalable

[M-casado]

May I suggest using EFO's ontology (either directly for validation, or by copying their terms)

[mauerk]

Hi @M-casado , thanks for the suggestion. That would definitely be a suitable candidate for our library preparation property.
Is this ontology term also part of the EGA schema? If yes, how do you handle the varying granularity between the terms (86 subterms for single cell library construction, none for cDNA or DNA library construction)?

[M-casado]

Hi @mauerk, for what I remember, it's not yet included in the library preparation, but it will definitely be at some point. In similar cases of varying granularity we either:

• Only registered a "high" hierarchy term (e.g., the 6 terms right below the library preparation)
• Allowed for any term "below" another term to be provided. For example, if given EFO:0030009, we would simply check (through Biovalidator) if that CURIE is encompassed by the library preparation term (OBI:0000711). This was done through the graphRestriction constraint.

This way, if we wanted to know just an overarching classification, we did the former; but if more granularity was available or expected, we choose the latter.