ICAR Animal Data Exchange Working Group – Technical Meeting 4 November 2021

• In attendance: Andrew C, Andreas S, Anton H, Erwin S, Graham M, Thomas P

Agenda:

Items to discuss today are: API and model change compliance; use of URNs instead of scheme structures; formal abstract data model definition; a streaming API for bulk data sharing or update; type classification; milk recording information; how to use UTC time when only date is needed.

1. How to use UTC time when only date is needed

Anton raised the question that he had been asked of how to use UTC time when only the date is needed.

Andrew noted that ISO8601 has a number of time representations and expected any of the representations should be valid. If there are still issues remaining after talking to the client, then it would be worth raising as an issue. It might be a documentation issue.

2. Type classification (#247)

Erwin introduced what he had done with conformation scores. He has some developers who want to use API for type classification.

In the ICAR guidelines there are a number of linear scores that are each measured separately, they are combined to composite scores and a weighted combination is produced to give the final score. The calculated combinations may be overridden.

Linear scores can be used for other purposes than just the ICAR linear scores, so it makes sense to keep the current Conformation Score event.

However, an inspector may capture a number of linear scores and from this calculate (or override) a number of composite scores.

A way to achieve this might be to:

• Define a new type that contains the trait, trait group, and trait score
• Include that type into icarConformationScoreEventResource using allOf so that the attributes remain the same (non-breaking change)
• Create a new icarCompositeScoresEventResource or icarInspectionScoresEventResource which has an array of these types (or even two arrays - one for linear scores and one for composite scores).

This would avoid replicating the animal and other event details.
Action: Erwin create a draft pull request into Develop so we can comment.

3. Graham gave an overview to explain the four issues he had posted:

• API and model change compliance;
• use of URNs instead of scheme structures;
• formal abstract data model definition;
• a streaming API for bulk data sharing or update.

4. The use of URNs instead of scheme structures (#259)

There was support for Graham's proposal for the use of URNs instead of scheme structures.

We noted that this could be a substantial and breaking change. It would be possible for this to be introduced as a new element in the APIs and mark the previous one as obsolete and live in harmony with both. However, this makes conformance difficult.

Recommended that we phase out the scheme structures over time. We need to provide examples and do some education emphasising the benefits.

Having a registry of schemes improves things and is best practice. There is a partial registry of the current schemes here: https://github.com/adewg/ICAR/wiki/Schemes

5. A streaming API for bulk data sharing or update (#257)

Graham described the concept and there was interest from the participants. This proposal does not cause breaking changes, so it could work in parallel.

We note that it would be nice to see a practical example. This is meant to be a complementary way to do things rather than a replacement of the location-based APIs already defined.

The proposal addresses how to share or synchronise changes in bulk between organisations (rather than just between an organisation and an on-farm system where location makes sense).

It supports synchronisation as the objects change and events occur, so that a client may consume the resources that have changed (at a complete resource level). The client can get everything or just the stuff that has changed.

New data types could be implemented without having to define new APIs.

We noted that this would depend on adding to a resource:

• The concept of a resources own type
• Robust unique resource identifiers (as indicated above)
• Location details (currently not in resources, but should be).

Action: Graham to do a draft pull request with a trivial prototype so that people can understand and comment on it.

Next meeting scheduled for 18 November 2021 at 8:15am CET