Technical Minutes 2020 07 03

ICAR Animal Data Exchange Working Group – Technical meeting 3 July 2020

In attendance: Andrew C, Anton H, Arjan L, Beate M-F, Craig V, Erwin S, Marvin R, Kor O, Sven S, Thomas D, Thomas P.

Lely had noted that there was no location reference in an animal core resource, and raised that often it would be useful to know the location.

Discussed whether this could be a sub-resource, because this was a status that could potentially be obtained by analysing registration and movement events.
Noted that other meanings of location could be "the barn or field", or "latitude and longitude" but these are not the current concern (separate information).
Noted that movement events often have a location of departure and arrival - these are required for regulatory (I&R) purposes, even if location were part of an animal core resource.
We considered the idea of adding a "latest status" or "latest events" as a sub-resource for an animal, with various derived data - e.g. current location, last calving date, or last calving event...
Noted that there could be an argument to leave location out in some cases - e.g. research, where you might not want people to see location (although location would only be an ID).
Discussed owner vs. locations (farms). Ownership can be complex with multiple owners.
Decided that it would make sense for location to be an optional field within the animal core object.

Question: If we can't return a collection - just an array of objects are we still conforming to the standard?

A collection has an envelope that supports pagination, and then an array of objects. If you are not using pagination, the pagination section can be empty.
In one example (JoinData) a query might be proxied to a number of providers, which would return collections - but JoinData would then need to rewrite to combine these.

For example:

() = ICAR collection envelope

{} = JoinData envelope

A query across multiple providers would return:

{(a,b,c),(c,d,e)} rather than {(a,b,c,c,d,e)}

Another approach would be to create a parameter to request pagination - if this was false, you could return raw array with no envelope
It might be cleaner to have separate endpoints for pagination or non-paginated data. Then data sources might decide to only support one or another, which puts makes it hard for both clients and servers.
We will get more clarity about the use of pagination and envelopes as people start implementation.
Asked people to think about this, and discuss at a later meeting.

Marvin explained the need to be able to query the set of locations that a service handled (and a user had permission to access).

The object returned is simply the scheme, id, and name of each location.
Discussed examples from DataLinker and JoinData where there could also be an API that described the data available (for a location). This could be done later.
Suggested making Identifier the primary scheme/id combination, and optional alternativeIdentifiers as long as it was a one to one relationship (stress this in documentation).
Agreed that this should be implemented and Marvin will lead this, commit into Develop branch.

We would like to release 1.1 quite soon as it is additive and not breaking.

People are to comment on this issue with their preferences as to timeline and comment.

Next meeting scheduled for 17 July 2020 at 9am CET