Support dynamic level names

[SCYarnes]

DeltaBreed allows users to dynamically name levels when they are creating experimental datasets. DeltaBreed only requires that users specify what entity is being measured for different experimental datasets, and only validates that entity (level name) be unique within an experiment (trial).

Examples

Vine

• Cluster
• Berry biochemistry
• Berry imaging

Family

• Fish
• Sea lice imaging
• Flesh harvest quality

Tree

• Leaf disease imaging
• Branch architecture imaging
• Nut imaging
• Nut quality

[BrapiCoordinatorSelby]

The current BrAPI data structures will support this, but the documentation (and subsequent BrAPI implementations) recommend a controlled vocabulary for levelName. An excerpt from the BrAPI ReadTheDocs page:

"According to the current BrAPI spec, the accepted values for Observation Level are listed below. An implementation might use additional levels not listed here, but please try to conform to these accepted values whenever possible."

That said, I'm personally not a fan of this change. The ObservationLevel concept was meant to be a spacial and organizational concept of physical space. It was meant to indicate the granularity and hierarchy of Observation Units. Some of the examples you have above fit this concept, others look more like Traits to me. Plot -> Vine -> Cluster -> Berry makes some sense to me as a custom Observation Level Hierarchy, but Biochemistry and Imaging are definitely Traits or Trait Classes.

Custom levels makes sense in some contexts, but User Defined Levels makes me nervous. This tells me that your users need some extra layer of categorization to sort their ObservationUnits, and I don't think levelName is that place. @SCYarnes From your examples above, what do these levels mean conceptually to your users? how do they help? How/where are they displayed in your system?