search

integritysystemscompany / animal_schema

Collaborative definition of JSON Schema to support individual animal data exchange. Builds on ICAR standard and focuses on Australian red meat needs.
6 stars 6 forks source link

Arbitrary measurement events #31

Open graham83 opened 4 years ago

graham83 commented 4 years ago

I may be missing something here - but weights and scores are covered in the iCarEventCoreResource. What about other observation events on an animal e.g. Testicle Circumference? Where do other trait events involving measurement belong?

cookeac commented 4 years ago

Our recommendation would be that we define these as additional event types (ie, their own resource types).

In Issue #9 it was suggested that maybe the values for a measurement - value, units, resolution, and perhaps precision (how many places to display) could be encapsulated in a "type" that could be included by reference ($ref) wherever we needed a measurement. This would make it easier to create additional event types as envisaged here. My concern is that the "units" relate to the sort of measurement so it is harder to constrain them if this method is chosen.

@graham83 is it possible to get a list from you of other suggested measurements that are frequently used in Australian farm systems within your customer-base, and we could look at whether there is a way to add these fairly rapidly or in a generalised way?

graham83 commented 4 years ago

We think we need to address these in a generalised way. There is an extensive, and changing list of trait observations that our customer base use (hundreds / thousands). The most common are covered by the weights and score schema. An additional and generalised measurement schema will give sufficient coverage of the remaining observation events.

cookeac commented 4 years ago

A clear set of guidance from both ICAR and other members of this group was to avoid too many generalised messages that required interpretation to work out what they are - this makes filtering and other things more challenging. I do think there is room for generalised observations, but we should try to define specific types where it makes sense and supports innovation.

Here's my recommendation:

  1. Encapsulate measurements of different sorts into general types (such as an iscMassMeasureType) that include an appropriate Units enumeration, value, resolution and perhaps precision (Issue #9 ). This makes it easy to create new event resources.

  2. Address known commonly used event observations with their own types as we have been. These should be a smaller subset.

One example that affects ABRI is the Dairy Scores which are defined by ICAR. These are like the score types we worked on a few weeks ago, but are highly standardised - there is a known set with defined value range. Each could be a different event, or one event type could cover all. Defining an observation for these would hit a bunch of similar dairy scores used by a number of breed societies.

  1. Where we need to, define new "general" event types based on icarEventCoreResource and using the measure types, using traitLabel to distinguish them. This provides a route for transferring legacy data and handling uncommon events. We should still try to turn common events into their own resources, particularly if they might need additional fields other than just a name and value.