Technical Minutes 2021 10 21 - adewg/ICAR GitHub Wiki

ICAR Animal Data Exchange Working Group – Technical Meeting 21 October 2021

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

Agenda:

Items to discuss today are: remark attribute for all event resources; using Github project board for tracking; reason for DoNotBreed; linking/referencing related events; type classification; milk recording information; animal health status.

1. Add Animal Health Status to Animal Resource (#148)

There was no further discussion. The change request has been merged. Andrew C will check the pull request.

2. Validate with Spectral error message (Spectral)

Erwin reported a Spectral error message while merging a pull request for remarks. Andrew says it looks like something has changed in the configuration of how Spectral works rather than being an the issue in the code. Anton reported that the latest Spectral version changes now require the rule sets to be provided in the command line. Anton volunteered to fix the issue.

3. Add a remark attribute to all event resources (#255)

Andrew had created this issue to bring together the 2 issues (#250) and (#233) to make the change log more readable. Erwin merged the pull request to add a remark to event resources.

4. Principles, themes and threads

The question was raised whether there are flags or status fields on animals that are driven by events and the need to document it. This lead to a discussion on a second generation of the standard in which we might need to take account of an ontology of a decision. Formal semantics and meaning of what it actually means for a system to receive one of these messages. There are principles, themes and threads we could start talking about and align. Graham create a ticket

5. Using "GitHub Project Board" for an issue/task tracking when working on new releases (#251)

Anton explained his suggestion of having a Kanban-like board for managing the tasks for a new release and assigning a person to a task. This would provide more control of the tasks for the release. Andrew thought it would be good for a release with many tasks like for version 1.2 but might be overkill for a release with a small number of tasks. We agreed to create a new project board for a version. It could include the things we want included in the release. Andrew to look into use of a project board

6. Support linking or referencing related events (#248)

Andrew introduced his proposal to have a generalised method for referencing one event from another, and describing the relationship between the events.

  • One question is how the relationship type translates to our area. If we need to define relationship types, where do we define them?
  • Rather than contentType a better name for the property might be class. Graham explained that rather than defining what you are going to get back, the resource can be self-describing. You should be able to get any resource and ask "What are you?" rather than needing to know what you are going to get all of the time.
  • There was a discussion of the semantic web vs classic url construction. Andrew summarised saying we quite like the idea of the URI-based definition of the relationship and that the relationship itself defines what is at the other end, at least in a base class sense. So you don't need to specify anything like contentType or class in the instance. An @type property inside objects in the future would help us to make them self-describing, where people have described their own version of things.
  • Probably in the short term our related thing would actually be an ICAR identifier where the scheme and id is compatible with everything else but in the longer term it potentially wouldn't be. We could have a section called refs (or links in the proposal), where each key is the relationship and then the values are a list or a single value, which makes it clear that these point to other stuff.

7. Type classification (#247)

It had previously been commented that the conformation score event should be defined in a way that is consistent with the rest of the animal events - with each event being for an individual. There would be value in having a composite score which might also have a set of linear scores which are already defined. Erwin to consider the matter further.

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

No progress on this recently. Erwin will pick it up again.

9. Streaming API for bulk data sharing or update

Graham said he finds the current APIs are very chatty and single location based and they do not fit their use cases very well. He envisages something for the industry so they can stream great quantities of data between different partners and exchange data with a very simple protocol and API without all of the chattiness. Having datasets that you can just consume with continuation tokens would give a lot of utility for streaming messages between multiple players and partners. Some simple protocol for messaging would facilitate this. They see this as one of the biggest use cases and would open it up for a lot more people to use. If you have a very simple protocol and then deal with data types, it is a lot less work than having to implement many different endpoints. Graham will create an issue with a proposal.

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