Add a trialType descriptor to Trial entity

[tyrwh]

Many breeding programs have different phases to them: 1st year / 2nd year / 3rd year, Preliminary Yield Trial / Advanced Yield Trial / Area Trial, etc. Adding a trialType descriptor to a Trial entity would be a good way to capture these top-level categories.

In annuals, entries from one phase are selected and advanced to the next phase in the following growing season. While check lines often remain consistent, the entries tested in a given trial phase/type will typically be completely different each year. The entries in the 2024 Advanced Yield Trial (AYT24) are different from those in the 2023 Advanced Yield Trial (AYT23).

The Study entities of a given type could be grouped into a single Trial entity (all Advanced Yield Trial studies become a single AYT Trial) or into separate Trial entities (there is an AYT22 Trial, an AYT23, an AYT24, etc.).

In either case, a user would need to parse names, descriptions, or dates in order to either separate the data (e.g. pull only the most recent year of data from a Trial containing multiple years of AYT Studies) or combine it (e.g. merge multiple AYT Trial entities in order to look at trends over time).

If you had a trialType descriptor you could create a unique Trial for each year's unique phase, keeping them distinct for easier access to only a specific cycle, while having a quick way to group them into top-level categories.

This would be similar to the existing studyType descriptor in the Study entity. Having both studyType and trialType would also give users the ability to contain multiple studyTypes in a single trialType.

For instance, many programs evaluate a given phase of breeding lines in separate yield trials and disease trials. You could now have a Trial entity with a trialType of "1st-year evaluation" that contained some Studies with studyType "Small-plot yield trial" and some with studyType "Headrow stem rust nursery"

It would also simplify the process of labeling finite (non-cyclical) experiments. For example, say a breeder runs a GWAS experiment across ten unique site-years, forming ten Studies grouped into a single Trial. They wish to label this "GWAS" somehow, so they can pull it along with data from other GWAS experiments. Instead of doing this ten times, adding it to each studyType field, they could add it once to the overall Trial entity.

[daveneti]

@tyrwh note that you have already trialStage : The current stage of this trial. Example include Advance, Elite, EPT, EST, Prelim, PST.

Much of what you describe can be considered implementation (breeding program) specific. You could still have some documented guidelines / examples. Perhaps some documented example use cases is required.

[tyrwh]

@daveneti Is trialStage a descriptor for Trial entities already you mean? I don't see that on the 2.1 release specifications. If that exists already, then that works perfectly

[daveneti]

AHHHH! Yes you are right, I was looking at our internal extensions to BrAPI. In that case, can I propose to call the descriptor 'trialStage'. I think that trialType is too generic and that what you are proposing above is more a stage?

[daveneti]

PS, you can have a trialType, which is like a studyType. This would be things like 'Yield Trial', 'Nursery' etc. Whereas 1st year / 2nd year / 3rd year, Preliminary Yield Trial / Advanced Yield Trial etc would be stages in a 'Yield Trial'.

[tyrwh]

Haha ok great, I was worried I just didn't actually read the docs before posting

Adding the specific trialStage would valuable I think. It's a close to universal concept, if not universal, in annual crop breeding. I think it would be hard to find a diagrammatic representation of annual crop breeding scheme where you could not say "the rows, columns, or boxes represent stage in the sense that we're using the term here"

If it's applicable to a significant chunk of breeding program activities, that seems like grounds to think about inclusion, even if it may be broadly not applicable to some types of trial.

Applied breeding programs may not have a publication tied to many of their trials (if any), but it's important metadata to enough research programs that it warrants inclusion as part of the universal Trials spec. Same with GPS - if you're in annuals and don't own an RTK planter, you probably won't have observation-level GPS coords. But it's useful in enough cases that it makes sense to be a part of the universal Observations spec.

I think adding the more generic trialType would still be useful even if trialStage is added, for a few reasons-

Having both trialType and studyType allows you to capture two meanings of "type"
If you perform 3 Studies, grouped in one Trial, to evaluate drought resistance for an eventual GWAS, and you have a single Type descriptor, is it more important to capture the type of experiment - "GWAS" or "diversity panel screening"- or the type of trait examined- "drought screening"?
There are cases where you may want to query on either, and it's hard to have both with studyType alone. You could concatenate them and call it "Drought GWAS", but then you're trying to parse substrings

Having both trialType and studyType allows you to capture two granularity levels of "type"
Most cereal programs I have seen run separate yield trials and disease evaluations on at least one phase of breeding lines. Often the disease evaluations themselves are subdivided, with different diseases evaluated in separate trials so they can each be inoculated singly.
So say you have three disease Studies on distinct diseases from a single evaluation phase, forming a single Trial to capture all your disease ratings from that germplasm set.
On a Study level, the studyType could just be "disease evaluation", but if could be very useful to differentiate using studyType of "Northern leaf blight evaluation", "Gray leaf spot evaluation", and "Smut evaluation" and have the trialType be "disease evaluation".
You would have the ability to easily query either to find data on any particular disease or on any diseases, whereas with studyType alone you'd have to choose one and find a workaround for the other.