ICAR Animal Data Exchange Working Group – Technical meeting 3 December 2020

• In attendance: Andrew C, Anton H, Arjan L, Beate M-F, Erwin S, Graham M, Kor O, Lars K, Michael L, Thomas D, Thomas P.

Agenda:

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

1. Pull Requests

• It is great to see some PRs coming through
• Still some work to be done on Feed PR, but feedback wanted.

2. Schemes and Schemata (#109)

This issue proposes a standardised way to discover a) the themes that a service supports and b) the identifiers available for a scheme (e.g. breeds)

• The schemes that a service supports will be a subset of everything available.
• We intend to maintain a list of known schemes. This is currently at location_scheme.md

Proposal was:

• /schemata Return a list of schemata (e.g. ["locations", "animals", "breeds", "trait-labels", ...])

• /schemata/locations return the schemes for a particular schemata ("locations" in this example) OR just

• /schemata return a list of all schemes and schematas supported by the service.

• There was a discussion about retrieving the set of valid values for a scheme. /schemata/breeds/{icar.interbull}

• We discussed the feasibility of returning large lists (for instance, all animals). There are already APIs for getting the locations to which a user has access, and the animals at a location.

• We discussed build-time (for use by developers) and run-time (for finding what is supported for a specific instance)

• We noticed that some schemata may vary by location - especially given the country and species of animals at a location. From a run-time perspective, a query by location would be better.

New proposal from the meeting is:

• Get a list of scheme types for a location /locations/{location-scheme}/{location-id}/schemata
• Get a list of schemes for the scheme types /locations/{location-scheme}/{location-id}/schemasa/{scheme-type}
• Get a list of values for a scheme /locations/{location-scheme}/{location-id}/schemasa/{scheme-type}/{scheme}

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

A key enabler for distributed data sharing is how identity is managed and synchronised between services. We have avoided this to date by dealing with national identifiers allocated by a trusted organisation. However, some resources (e.g. events) may be created by many different sources.

• We discussed whether there should be a mechanism to deal with multiple identifiers and sharing them.
• We have alternative identifiers for animals - which can be both globally unique or in special cases some local identifiers, but no equivalent for other resources.
• We want to encourage organisations and devices creating new event messages to create and communicate a UUID for these.
• This would be achieveable even if the source system couldn't allocate true UUIDs but instead prefixed with a unique system or device namespace.
• Receiving systems might need to allocate their own internal "database Ids" (or whatever), but as long as they still stored and shared the source system UUID this could still be the unique identifier for the event.
• We could provide for event IDs to use a scheme+value approach (rather than just Event ID). This would make namespaces explicit. A "UUID" scheme would support UUID allocations.
• We could allow for events to have alternativeIdentifiers[] (array of schemes and IDs) just as animals and locations do.
• We also have an @self for every icarResource that provides a reference you can use to access that resource in the serving system (as opposed to the original device that allocated the device).
• In theory an event would never need to modified and hence could be referenced through data rather than a unique ID. However, events recorded by humans may need to be edited, some may have sub-events or related data, and some may need to be referenced (for instance, referencing a movement, or referencing a diagnosis from a treatment).

4. Agenda for next meeting

• Filtering proposal
• Herd-level (not individual animal) events and resources
• Milk recording result (resource)

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