EventCore - Should events have optional management group

[graham83]

Trait observations are often in the context of a management group. Is it therefore worth having managementGroup as a field directly on icarEventCoreResource or is managementGroup and groupDateTime captured in a separate object?

[cookeac]

Thanks for this feedback Graham. I think managementGroup would be sensible as well, on the assumption that we mean the same thing. By managementGroup I mean an identifier that distinguishes animals under the same managment conditions - specifically as this influences environmental adjustments in genetic analyses.

For instance, animals that have been fed ad-lib can't be compared to those on a restricted diet -- those need to be in different management groups to remove the environmental effects from a performance analysis.

Management groups could be derived for performance analysis by:

1. Allowing farmers to identify different groups with some sort of identifier - a number or name. Adding managementGroup to the event would satisfy this.
2. Actively tracking the mobs animals were in (using mob entry and departure events - not yet specified). However, different paddock mobs may still have essentially the same treatment so not be in different management groups.
3. Doing fancy things with location, feeding or feed regime events, etc. A fantastic future option because it might allow genetic performance breeding across commercial farms.

So two questions:

• I would see managementGroup as a string field that the standard treated as effectively opaque - to be defined and used by systems at each end of an interchange.
• It would be added at least to a weight event, but might be an optional field in the Event Core for use in any event - what do people think?

[graham83]

This sounds good Andrew - an 'optional field in the Event Core for use in any event'. This would mean it can be applied to weight or other observations.

[cookeac]

I discussed this with the ICAR working group at their last meeting and they were confused by managementGroup - it was interpreted as a plan for managing animals. When I explained about contemporary groups, they wondered if there were other events that should be recorded which would drive contemporary groups.

The short answer is "Yes", but practically most of those would involve farmers recording much more data, probably manually (for instance, about mob changes, paddock moves, and feeding) and then software interpreting these to a contemporary group. For this reason, our explicit addition of management Group is, I believe, justified.

However, the name managementGroup still causes some confusion. Perhaps if it were called contemporaryGroup or something similar?

[anitanagaraj]

Submitted to ICAR as contemporaryGroup

[cookeac]

Accepted by ICAR in icarEventCoreResource.json "contemporaryGroup": { "type": "string", "description": "For manually recorded events, record any contemporary group code that would affect statistical analysis." }