ICAR Animal Data Exchange Working Group – Technical meeting 22 April 2021

• In attendance: Andreas S, Andrew C, Anton H, Beate MF, Craig V, Erwin S, Thomas D, Thomas P

Agenda:

Items were suggested by the attendees. The focus was on closing items to allow us to publish the new release.

1. icarFeedQuantityType mass unit codes (211)
2. Naming inconsistency in icarValidSampleFillingIndicatorType (210)
3. Handling batch POST methods (relates to 154)
4. Items for next meeting

1. Semantics for POST (#154)

We discussed three approaches to dealing with /batch/ POSTs

1. Create a wrapper around each collection item to provide its source identifier for matching
2. Use the ID field
3. Make use of the meta data source and sourceId fields

The group preferred the third option

• The client POSTing the data MUST fill in the metadata source and sourceId fields.
• The server MAY use the ID* field in the request if the client is using a UUID and it can use it, otherwise it should keep the client's source and sourceId and fill in the ID with its own generated identifier. This allows the client to track the identifiers that the server allocated, and also to match error responses.
• This approach is also suitable for single POST semantics
• We also recommended that the server should return in the response all the fields (single object post), or at least the necessary fields (Id, required fields and meta) for each object (batch case).

We documented our recommendation here: https://github.com/adewg/ICAR/issues/154#issuecomment-824586244

2. Error handling and HTTP Status codes (#203)

We discussed on 22 Apr 2021 that we should define a set of HTTP status codes for status and object-level errors. For instance: https://github.com/adewg/ICAR/issues/154#issuecomment-700411559 We noted RFC-7807 multi-part responses in https://github.com/adewg/ICAR/issues/154#issuecomment-701133516

We discussed the need to be able to also handle semantic problems, which would need standardised codes as well, or system specific. Here is the errors object proposed in the multi-part response

Attribute	Required	Type	Description
code	N	string	Application/service-specific error code (could we standardise these?).
errorDetail	Y	string	Detailed error message, e.g. "Required field 'ID' not specified."
collection	N	string	Name of the collection containing the error (We dont need/want this)
instance	N	string	Unique ID of the instance object with the problem (We would use sourceId)
pointer	N	string	RFC 6901 JSON Pointer to the error position within the request (e.g. to the offending attribute).

We recognised that a client could display the code and errorDetail to a user and ask them to fix it, but this would not work for automated systems.

We agreed to propose any standard codes or coding scheme.

3. Milk recording information on herd level (#184)

We discussed how a milk recording organisation could make available information at a herd or group level. It would be possible for systems to calculate this from the raw or test day information, but some calculations could be complex to reproduce or clients might want to use definitive calculations from the milk recording organisation.

These could include:

• Herd averages for a number of KPIs
• Group averages for a variety of pre-calculated groups
• Group averages for farmer-defined groups (Animal Sets?)

We agreed that Erwin would do more work on the data model and we will discuss at a future meeting.

4. Milk recording information on herd level (#171)

We discussed that we could just link milking visits and feed events, or we could defer to a future release and create a more generalised solution that allowed us to reference 1:1 or 1:many resources from a resource.

We liked the idea of being able to link one or many resources, and agreed this was not urgent so we would consider it for a future release (we removed the "this-release" label).

5. Build environment

As well as our JSON schema parsing, we should work on the code generation environment so that we can be sure releases will generate code properly. This could be done for a future release.

Next meeting scheduled for 06 May 2021 at 8:15am CET