-
Notifications
You must be signed in to change notification settings - Fork 27
Technical Minutes 2020 10 09
- In attendance: Andrew C, Anton H, Arjan L, Erwin S, Graham M, Thomas D, Thomas P.
- Feed Intake API - update from Thomas D and Erwin
- Semantics of POST Method - deferred to next meeting
1. Feed Intake API (#93)
Erwin and Thomas D have been working on this.
- Allow multiple feeds in the event and one ration
- 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.
- Normal fields from an animal event
- visit duration - or food available duration
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.
This would cover multiple animals and have a set of animal IDs.
- 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.
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