ICAR Animal Data Exchange Working Group – Technical meeting 28 January 2021

• In attendance: Andrew C, Anton H, Erwin S, Graham M, Kor O, Thomas D, Thomas P.

Agenda:

1. Pull Requests
2. Schemes and schemata (109)
3. Unique and multiple identifiers for resources (153)

1. Referencing deleted feed resources (#178)

• An active flag was added to both icarFeedResource.json and icarRationResource.json. This allows a software system to communicate that a feed or ration was previously valid and referenced in an event, but is not presently available for use in new events.
• Encourage more generally that data should not be DELETED but that entities should be long lived, uniquely identified, able to be archived, and that instead the status objects should change (for instance, active or even a deleted event).
• We discussed that there was merit in long lived identifiers, and indeed long lived URI references for animals and events and other resources, which might be separate from temporal identifiers such as tags.
• Noted that some references are done by URL (e.g. icarMedicineReferenceType, derived from icarResourceReferenceType)

2. Feed attributes and categories (#172,#173)

These are still to be completed, but no work has been done on this recently.

3. Additional fields on Parturition Event (#183,#185)

We received feedback about the birth event resource (recorded on new animals if a registration event requires). This moved into the parturition event which describes the calving (or lambing or fawning) of animals. Previously this was left as a text field with no elaboration.

• Reviewed the potential lists that Andrew had found and Ditlev had provided.
• Agreed to use the enumeration from Interbeef.

"type": "string",

"enum": [
"1-EasyUnassisted",
"2-EasyAssisted",
"3-DifficultExtraAssistance",
"4-DifficultVeterinaryCare",
"5-CaesareanOrSurgery"
]

• Discussed other suggestions in #183 to capture stillborn progeny.

  • If you want to record as a feature of the dam, record number of live and dead progeny in the parturition record.
  • If you want to record as a feature of the progeny, use the status in the birth record for the progeny.

• Discussed the suggestion about weight categories (light, normal, heavy, etc). There is no international consistency of this with most people recording weight. Recommended that this be implemented as a local extension.

• We could do with more documentation on how to create local extensions - at present the Design Principles in the Wiki only requires fault-tolerant readers to allow for additional non-mandatory fields (https://github.com/adewg/ICAR/wiki/Design-Principles#fault-tolerance-and-extensibility)

4. Rank in insemination event (#180)

We discussed that Rank (order of insemination as known by operator - not necessarily just date) is missing from icarReproInseminationEventResource.

• For double insemination, guidance is to record two insemination events.
• This makes Rank even more important.
• Agreed that rank could be included even though it may be derived by a system - because it will be useful to clients or software that might not have all events.
• Anton will do some more research to identify whether in a double insemination, both inseminations would have the same rank or different.
• Suggested that it be called inseminationRank.

5. Unique Event Identifiers (#153)

Where systems might interchange data, particularly if they synchronise by using GET to retrieve collections from each other. How does one match idenfiers, if each system allocates its own identifier?

• Noted that previous discussions had proposed use of a UUID so that systems did not have to create their own identifiers.
• Recognised that systems would still create their own identifiers for a variety of historic reasons.
• One suggestion was just to add a sourceId to identify the source system's identifier.
• Noted that icarResource.json defines @self which is a useful hint from a system of the URL that can be used to GET (or PUT/PATCH) the individual object. This is an editorial URL and should ideally be in meta-data.
• Proposed that we should generally accept that everything could have multiple identifiers. For instance
  • Have an Ids[] collection, or call it sameAs[] (as used by schema.org) or otherIdentifiers[] or correlatedIds[]
  • Does not enforce all systems to track all possible Ids, just provides a mechanism to transfer Ids where it was useful.
  • Ideally provenance or source (where did this come from) should be in metadata (which it already is) - and sourceId should be in metadata too.
  • We talked about meta-data for provenance of properties, with each property of an object having its own URI and its own metadata. This is not currently in scope.
  • Our preference if maintaining an array of identifiers is to use icarResourceIdentifier which provides a scheme and Id combination, allowing users to understand the creator of each Id.
  • An array of identifiers would be particularly useful for data that is broadcast or shared with multiple systems.

We will try to finalise this at the next meeting.

6. Breed schemes and identifiers (#168)

Breeds are allowed to be defined using an icarBreedIdentifierType which is a scheme and Id combination. ICAR and Interbull define a set of 2- and 3- character codes which are "global standards" but only contain a subset of breeds, and only for cattle. Organisations may also define their own schemes.

• Could (and should) we define a standard scheme and list of identifiers?
• If we did so, how would we deal with proposals to add new breeds or correct mistakes? There are organisations that maintain lists of animal breeds, and we could simply defer to one of these, or refer people to the ICAR working groups.
• It is possible for organisations to share schemata with the proposal in #109
• Anton has started some work around schemata APIs and is looking at breeds, and will share some of his work his work.

4. Agenda for next meeting

• Herd-level (not individual animal) events and resources (#184)
• Finalise a decision on unique identifiers (#153)

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