ICAR Animal Data Exchange Working Group – Technical meeting 19 November 2020

• In attendance: Anton H, Arjan L, Erwin S, Thomas P, Thomas D, Lars K.

Agenda:

1. Feed Intake API
2. Timezone
3. Documentation about filtering (next meeting?)
4. Semantics of POST Method
5. Identifiers for POSTing resources (next meeting?)
6. Questions from Lars

1. Feed Intake API (#93)

• Erwin shows the feeds API in the develop branch.
• Small changes were suggested and approved
• Are the categories ok?
• What would bet he id? Recognisable for a developer
• Provide it also as a csv file
• Lars will propose the feed API’s within his team
• There is still time to give input and feedback …

2. Timezone (#164)

• locations end point - add the time zone id = text version "Europe/Brussels--> @thomasd-gea will change the location resource
• timestamps are always UTC
• has to be documented --> @alamers Arjan

3. Semantics of POST method (#154)

• Is the outcome of last meeting the final decision?
• Milking-visits/batch would not fit with milking-visits/{id}
• A discussion again about to treat a batch like an array of single posts.
• We could try to define response models for both options and see how to handle it (also about error)
• Probably for sensor data a single resource posting is probably not that suitable. For these data bulk data might be more apprioriate
• Technical evolution is going rapidly, there is a tendency to go more and more to real time systems with small requests
• We need to find a balance …
• Another option is instead of POSTing is to GET such information
• How compatible do we want to be with Rest json definitions
• We discussed some use cases to try to get this more clear

4. Questions from Lars

• A number of questions from Lars were handled during the meeting

Location scheme

To what exactly is it referring. Could it be a pen or a barn? In US because of large farms, most API’s are on pen level. Location, in the standard, is meant as the administrative number for a farm (assembly of pens and barns). We need something to identify a subset of the location, like pen or barn. One could also use a scheme for the barns. It depends which way one sets it up. With the locations end point one could request all pens on a location. But you can’t see which pen is connected to a location, so maybe combined ids (location-barn) is a possibility, or add a field like parent-location

Animal ids

An official id is in a number of countres not available, therefore a farm anima lid is used. To harnative ve a unique id in those case the technical key in the system is used. Next to that alternative identifiers are provided. Conclusion : Pick one scheme for the animal identifiers, use the animals endpoint to retrieve additional identifiers Next to that Lars would prefer a animal id object with only an identifier. where he can add more info about the animal. Possible solution, create such an animal object next to the identifier. Could be an option for 2.0 Lars is putting an animal identity in each object (animal number, management tag, iso, …) for easy use

Insemination

Sire – shouldn’t it be a seperate object within the insemination resource, the same as done for straw and embryo. Advantage is that more info can be added. The sire info is duplicated in the straw. Straw is an independent resource Additional info about the sire – if needed – can be retrieved by the uri. Why do we have a sire reference and not a straw reference - changing this would be a breaking change. If Lars has good ideas about this, he can start an issue.

We welcome Lars, we were lacking somebody from the US in this group. We invite hi mto use the issue functionality on the ICAR GitHub to raise questions, launch new ideas …

Next meeting scheduled for 03 December 2020 at 8:15am CET