Technical Minutes 2020 09 25 - adewg/ICAR GitHub Wiki

ICAR Animal Data Exchange Working Group – Technical meeting 25 September 2020

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

Agenda:

  1. Feed Intake API
  2. Semantics of POST Method
  3. Release of ADE 1.1
  4. RDF Description of the core data model
  5. Collaboration with the EU Demeter project

1. Feed Intake API (#93)

Erwin and Kor have been working on this.

  1. Feed resource
  2. Ration resource with multiple feeds
  3. Individual feed intake event
  4. Daily feed report on individual level
  5. Daily feed report on group level (incl. animal IDs)
  6. Feed recommendation event

So:

Feeds (on a location)

  • id
  • name
  • type - this would be an enumeration of the main types - e.g. concentrate, fresh roughage, silage roughage, minerals, other
  • dry matter %
  • properties - array of properties such as digestible protein, starch, metabolisable energy, neutral detergent fibre, etc. Each having:
    • name
    • value
    • unit

We discussed the benefits and complexities of making the type list more fine-grained vs. keeping it general. The issue was raised of using the UNSPC code list - this will be investigated. We discussed how to allow for expansion or expression of more feed characteristics. Should the "type" define the properties we expect a feed to have? Are there a number of standard properties for feeds? An extensible code-list. ** Outcome ** Andrew to ask wider working group about standard properties for animal feeds.

Ration (defined for a location)

  • id
  • name
  • contents: an array of:
    • feed ID
    • percentage in the ration

Feed Intake (individual event)

This is for individual feedings where a device monitors the amount fed and measures or approximates the feed each animal eats.

  • all standard event fields
  • device Id
  • visit duration
  • consumed feed id
  • consumed ration id

For each (feed or ration)

  • entitlement
  • entitlement units
  • consumed
  • consumed units

Noted that it would be possible to have a ration and then add a feed (e.g. a mineral mix)

Outcome: Work on this to continue

2. Semantics for POST Method ([#154]https://github.com/adewg/ICAR/issues/154)

Andrew had documented goals from our previous meeting and made some suggestions

  1. Use standard HTTP POST as per RFC-2616
  2. Use the URL where you would expect to GET a collection of resources
  3. Post a Collection, with one or many resources in the Members array.
  4. Use HTTP status codes
  5. Return 201 when resources are added (Created), URL of collection, resources in the body with IDs filled in if blank previously
  6. Some sort of error response

We discussed the potential for posting an atomic "transaction" to which you could post a collection of collections. This would need a special end-point. It would be a lot more work for the server, but easier for the client (otherwise the client needs to know how the server will behave when it is sending different sets of data).

We discussed error handling and whether simple (failed) responses should be given or detailed error collections. This would be even more important with complex functionality such as the transactions discussed above.

We discussed the idea of a capabilities API or functionality so that clients know what a server supports. There are some examples in ODATA and Semantic Web examples.

Outcome We agreed that there are a number of use cases - some simpler such as the "post a message" or slightly more complex "post a collection of the same message" and some more complex (transactions).

Outcome Andrew to log an issue for Capabilities, and Graham to make some suggestions.

3. Release of ADE 1.1

The change log has been updated and a draft release prepared. Andrew needs to get credentials/2FA to finish this.

4. Description of the core data models

Graham asked if there was also a semantic RDF-based version of the data model as opposed to the JSON Schemas.

  • Suggested looking at the Wiki with a "class hierarchy", types, resources, and resource collections.
  • We had decided to work in JSON because we were skilled in this rather than RDF, would welcome RDF assistance.

5. Collaboration with DEMETER EU project

  • Graham offered to set up a meeting or shared discussion with the Demeter EU
  • Would be interesting to see how our APIs could plug in.

Next meeting scheduled for 9 October 2020 at 9am CET