Technical Minutes 2020 10 09 - adewg/ICAR GitHub Wiki

ICAR Animal Data Exchange Working Group – Technical meeting 09 October 2020

  • In attendance: Andrew C, Anton H, Arjan L, Erwin S, Graham M, Thomas D, Thomas P.

Agenda:

  1. Feed Intake API - update from Thomas D and Erwin
  2. Semantics of POST Method - deferred to next meeting

1. Feed Intake API (#93)

Erwin and Thomas D have been working on this.

Feed Intake event

  • Allow multiple feeds in the event and one ration

Feed definitions

  • Prefer to keep the properties open, but define a set of common codes (code list) for things that are international.
  • Thomas showed a list of potential names and abbreviations. Some of the abbreviations seem to be international, others were German.
  • We discussed using a scheme (scheme + ID) approach if there are multiple standards.
  • Erwin has reviewed the UNSPC codelist, but this is very incomplete.

Group Level Feeding

  • Normal fields from an animal event
  • visit duration - or food available duration

Daily feed summary

This is a derived resource that summaries the feeds that an animal has received over a day.

  • Has multiple feeds (each with amount allowed and consumed and units)
  • Has multiple rations (each with amount entitlement and consumed and units)
  • Not an event and has no device ID because could be different devices
  • Discussion about "event date", duration, and timezone: Could the structure be used for aggregating for any time period? Yes, but it would mean different things on the server. A daily report would allow the records to be calculated and cached on the server. The same data structure could be used with different API semantics.
  • The API would specify both the period of data requested AND the aggregation period (e.g. daily summaries for a week)
  • Decided that there should be a start date time and end date time, must use UTC (Zulu).
  • Need a timezone for the location or the aggregating server so we know the basis of the aggregation. Ideally this should be part of the location resource.

Outcome Add an issue specifying all dates must be UTC.

Outcome Propose a change to the Location resource to add timezone.

Daily group level feed report/summary

This would cover multiple animals and have a set of animal IDs.

Daily feed recommendation event

  • Would be for a location
  • Would apply to a set of list of animals
  • Time specifier(s)
  • Lists of feeds (with entitlements and units)
  • Lists of rations (with entitlements and units)

We discussed how recommendations were generated and communicated. Does a newer/later recommendation replace an older recommendation? Do recommendations for a specific animal override a group, or should they be specified only for individuals?

  • We think it might be useful to decide if there are two message types: groups vs. individuals
  • Should we have valid from and valid to (the latter might be blank meaning "until further notice")
  • Should we be explicit about the intention of the event - what period does it cover?

Noted that Robert F has asked some of his United States contacts to review this issue and comment as well.

2. Meeting times

Next meeting at the planned time, but given the summer/winter time zone changes, and the late time in NZ, Andrew will send out a Doodle poll to see if other days or times could suit.

Next meeting scheduled for 22 October 2020 at 9am CET