The score observation is covering multiple score types, but some seem to be missing. Is the intention for this to be a single observation for any type of score?
For instance, processors in the UK can use different grid systems, with the more complex being a "15-point grid":
The proposed model doesn't support that.
The example of storing the range as a string doesn't feel like it will support these models. An alternative here could be to store an array of possible values. The order property is redundant in that case. The value could also potentially be an index into that array with that approach.
In the case of a numerical value, then the value could be stored as is.
For both of these it feels like a field indicating the type of the representation would be useful, either continuous (in the case of a numerical value) or discrete (in the case of an array lookup).
We're carefully avoiding carcase information at the moment, because MLA is doing other work in that space, and there are existing standards (in each country/zone!). However, its a good general question.
The score observation is covering multiple score types, but some seem to be missing. Is the intention for this to be a single observation for any type of score?
For instance, processors in the UK can use different grid systems, with the more complex being a "15-point grid":
The proposed model doesn't support that.
The example of storing the range as a string doesn't feel like it will support these models. An alternative here could be to store an array of possible values. The order property is redundant in that case. The value could also potentially be an index into that array with that approach.
In the case of a numerical value, then the value could be stored as is.
For both of these it feels like a field indicating the type of the representation would be useful, either continuous (in the case of a numerical value) or discrete (in the case of an array lookup).
Reference: http://beefandlamb.ahdb.org.uk/wp-content/uploads/2018/05/Marketing-prime-beef-cattle-for-better-returns.pdf