ICAR Animal Data Exchange Working Group – Technical meeting 11 February 2021

• In attendance: Andrew C, Anton H, Arjan L, Beate MF, Craig V, Erwin S, Sven S, Thomas D, Thomas P.

Agenda:

1. Milk recording on herd level (184)
2. Unique and multiple identifiers for resources (153)
3. Review of open items
4. Items for next meeting

1. Milk recording on herd level (#184)

We discussed the possibility of having derived or computed "herd summary" messages that summarised milking information for a season, year, or other period. While these are derived and not raw data, there is merit in systems being able to receive and display or process this data without having to recalculate from raw data, potentially with variations in the calculation method. We noted that:

• Standard approaches to season, year, or ideally time period covered (duration?) should be included
• Messages or APIs should be smaller and focused
• Calculations will likely be country-specific, although there will be a number of standard metrics, and some which are country-specific but analogous across countries. For example, average lactation value, average breeding value index, net earnings.

Agreed that Erwin will prototype some of these and we will discuss.

2.Unique and multiple identifiers for resources (#153)

This is a continuation of the discussion from the previous meeting, although with some different attendees. We reviewed the minutes from the previous meetings and discussions.

• Agreed we need to handle multiple identifiers to support various forms of data transport and synchronisation
• There is merit in identifying the original source of data and associated identifer as meta data about the resource
• We agreed that an array of alternativeIdentifiers as is done with animal identifiers would be the most flexible and scalable solution for the future, with the identifiers based on icarIdentifierType so that they have a scheme (identifying the system that created the ID) and an ID
• There is a strong preference to keep things simple, and avoid implying that systems must track all other identifiers for a resource.

Accordingly the meeting proposed these outcomes:

1. Document that the original creators of new resources SHOULD attempt to issue UUID or equivalently unique identifiers.
2. Add a sourceID property to icarMetaDataType and specify that original creators of new resources SHOULD fill in source and sourceId.
3. Recommend that systems storing and passing data SHOULD retain the source and sourceId in the meta-data.
4. If a multiple ID solution is required in the future, extend icarEventResource (or even icarResource), adding an alternativeIdentifiers[] array.
5. We identified two ideas for the future - alternativeIdentifiers as noted above, and making meta-data source/sourceId a combination an icarIdentifierType. These should be added as an idea issue tagged for future (breaking changes)

3. Review of open items

• Discussed #180 - agreed that Anton's change is fine.
• Discussed #179 - agreed that this has now been resolved
• Discussed #130 - covered below
• Noted that more work on the feed attributes and properties #173 - this work is ongoing
• Reviewed POST semantics #154 and decided to review this next week
• Reviewed Capabilities #156 and decided to review this week, and update into implementation guidance
• Reviewed Activity and Rumination data #166 and noted we should invite relevant hardware/device companies to assist (ask wider ADE and Sensor working groups)

4. Listing and filtering resources (#130)

There is a proposal in the issue based on previous meeting discussions, where filter parameters would match the field names, and filters in member objects would be preceeded by the member name and a ".". However, this conflicts with the as-implemented scheme that mainly uses a dash "-".

• Confirmed that we would use a dash. For instance member-scheme and member-id

Next meeting scheduled for 25 February 2021 at 8:15am CET