Support for observationUnitLevelName for GET /variables API

[abatac]

Is it possible to filter the variables associated to study by observationUnitLevelName in GET /variables?

In the Breeding Management System, a study may comprise multiple datasets used to group observations/sub-observations based on their levels. For instance, a dataset named "plot" includes observations for plot-level units, while a dataset named "plant" contains sub-observation units within each plot.

The challenge is that, despite belonging to the same study, each dataset in BMS can have a different set of observation variables.

Therefore, if I wish to retrieve variables specific to the "plant" dataset (level), it is not feasible to utilize the GET /variables?studyDbId=xxx endpoint, as it retrieves all variables within a study without providing a way to filter variables based on the observationUnitLevelName.

I know that this is a limitation in the Brapi spec, but this blocks the interoperability of Field-book with BMS BrAPI 2.0 implementation.

For example, If I import a Field via BrAPI using "plot" observation level, the traits retrieved from GET /variables?studyDbId endpoint will return all the variables in a study for all datasets (levels). Ideally, it should only return the variables based on observationUnitLevelName.

[abatac]

Reply from Peter:

How many variables are there typically per data set or obs unit level?
If its typically 20 or less, then there are some shorter term, more manual solutions we can try while waiting for changes in the BrAPI spec.

Manual work around: have the user import all the variables with the study, then go to Field Book >> Traits and manually deselect the traits not relevant to that observation level.

Short term FB update: add better search filters to the Trait importer in FB. When the user goes to FB >> Traits >> menu dots >> Import, provide some filters just like the Field importer to list relevant variables. Then a user could select the study and manually select which vairiables they are interested in importing, instead of FB importing everything automatically.
This is similar to the manual work around, except it is additive instead of reductive. Depends on what the typical use case is, are there usually more variable to add manually, or remove manually. I don't know which would be generally more helpful, perhaps both options

In the long term, we can discuss adding observation level to the variables in BrAPI. If we want to filter variables by obs level, then the variable data model should also contain that metadata, like a targetObservationLevel or something like that. The potential down side to this would be another division in the definition of a variable. For example, one study is measuring Plant Height at the plot level, and another study is measuring Plant Height at the plant level, there would now need to be two different variables, both defining Plant Height. this could make things difficult if you try to compare the data between the two studies later. Or maybe perhaps these two different methods for measuring Plant Height should not be compared directly, and having separate variables is ok. Again I don't know, just thinking about possibilities.

[BrapiCoordinatorSelby]

linked to discussion PhenoApps/Field-Book#684

[SCYarnes]

DeltaBreed needs similar change to support data collection in Field Book. Each study and level are associated with a list of observation variables before data collection. It would be nice for these lists to persist in FB.