465 animal observation summary

[cookeac]

I tried to add proposed commits to #467 but didn't have permissions. This is a draft PR for review and comments. It addresses recommendations from the ADE meetings to address #465.

• The initial examples are (time-based) summaries of observations (e.g. the number of minutes in a day spent in an activity, or the number of steps in a day).
• The icarStatisticsType (used in group-based icarStatisticsResource) is close to what we need but we need to address time period or duration
• Address naming conventions - avoid the use of bare "type" and consider using "metric" as we use this for similar things elsewhere.
• Recognise that we don't need "DailyRuminationTime" and "24HourRuminationTime" - these are both different duration or period summaries for the same metric.

If we are on the right track, I will copy in the URL scheme that has already been defined for #467.

[erwinspeybroeck]

1) typo in the name of resources/icarlObservationSummaryResource.json

2) a lot of redundancy?

for each animal the location/dateFrom/dateTo --> is it possible that this changes within the same response?

for each statistic the startDateTime and duration --> is it possible that this changes within the same response?

I think the response will always contain data for the same location, dates, periods, so

{ location, date from, dateTo, startDateTime, duration (or you use dateFrom - dateTo, or you use startDateTime + duration) within this an array of animals within each animal an array of statistics

we also add an id on the main level - don't know if that is necessary

for the animal we alsi had a request to add the parity at the moment of the observation - i'm not 100% in favor, but ...

Of course a receiver will probably store this in a "flat" way on animal level: animal, location, date info, metric info --> so without any arrays. Don't know if we have to take that into account.

[cookeac]

1. typo in the name of resources/icarlObservationSummaryResource.json

Oops, will fix

2. a lot of redundancy?

Definitely there is redundancy in the icarObservationSummaryResource having location, dateFrom, and dateTo which will also be parameters to the API call. These could be removed entirely to my mind, but I am keen for other people's thoughts.

The statistics are an array of "daily" data (or whatever periods are provided), so startDateTime of a statistic will vary for every statistic for an animal. Similarly the duration may vary for each statistic, returning (for instance) "D" or the "H24" in the same API call. So there is no real redundancy for these.