POST /attention-events

[jdoemel]

@cookeac in the POST /attention-events endpoint there are fields for devices. Attentions or alert as far as I understand it are generated by a partner's algorithms. "deviceAttentionScore" I wonder if this should be "attentionScore"? The device didn't create the attention/alert, the partner's algorithms created the attention/alert? The devices are sending raw data to the partner's systems and that raw data is analyzed to create the attentions/alerts. Unless maybe "device" is supposed to be interpreted as a product and not the jewelry the animal is wearing? But it is the animal's attention score in the end. I am still stuck on calling it deviceAttentionScore

"deviceAttentionScore": 0,
 "device": {
   "@context": "string",
   "@id": "string",
   "@type": "Link",
   "identifier": {
     "id": "string",
     "scheme": "string"
   },
   "reltype": "string",
   "href": "string",
   "model": "string",
   "serial": "string",
   "manufacturerName": "string",
   "registration": {
     "id": "string",
     "scheme": "string"

[cookeac]

• device provides a place for a device/system/manufacturer to identify the device or algorithm or subsystem (which may be virtual) which generated or triggered the alert. It is a mechanism for the party creating the alert to identify the source. This attribute is common to many ICAR events which might be generated by some sort of system.
• deviceAttentionScore is an attempt to indicate that the score is not standardised -- because there is not yet an agreed standard for scores given that the scope of wearable and measurement devices is very wide. Instead, the score is "device specific" (or manufacturer specific, but a manufacturer might have various devices or subsystems which need to carry scores or measures). The name is an attempt to indicate to receivers that there is a score, but it needs to be interpreted in the context of the manufacturer/system/device/subsystem that generated it, not a set of values defined by ICAR.

[jdoemel]

Additionally, is "causes"=Activity intended to be used for heat attention/alert?

[jdoemel]

I am in the process of building the dev story for VAS' POST /attention-events endpoint which is why I have these questions. Trying to understand so we build the correct endpoint.
To cover heat attentions in the attention-events endpoint, I propose:

• Adding InEstrus to the causes. Her behavior has changed because of InEstrus, so partners could use the category of behavior, and we already have that category so we are good there.

Since the POST heat endpoint has this, VAS will include in the attention-events endpoint

• optimumInseminationWindow

VAS wants to support partners that use indexes or certainty/probability for the score. To plan for the future the deviceAttentionScore should be an index or a probability. So what I have for VAS is the deviceAttentionScore can be index (number) or a certainty (float)

VAS customers have asked to make sure that the custom lists in the activity monitoring match between VAS and the activity system. VAS will accomplish this is adding to the POST body the ability for the activity system to provide us with the names of worklists the animal appears for each particular alert.
VAS POST attentions-events.xlsx

Sample POST that VAS would accept
[ { "resourceType": "string", "meta": { "source": "string", "sourceId": "string", "isDeleted": true, "modified": "2024-04-30T14:54:07.609Z", "created": "2024-04-30T14:54:07.609Z", "creator": "string", "validFrom": "2024-04-30T14:54:07.609Z", "validTo": "2024-04-30T14:54:07.609Z" }, "location": { "id": "string", "scheme": "string" }, "id": "string", "eventDateTime": "2024-04-30T14:54:07.609Z", "animal": { "id": "string", "scheme": "string" }, "alertEndDateTime": "2024-04-30T14:54:07.609Z", "category": "Behaviour", "causes": [ "Activity" ], "priority": "Informational", "severity": "Light", "deviceAttentionScore": { "value": 8, "unit": "Index" }, "attentionList": [ "A", "B", "C" ], "optimumInseminationWindow": [ { "startDateTime": "2024-05-01T16:50:36.868Z", "endDateTime": "2024-05-01T16:50:36.868Z", "windowName": "string" } ], "device": { "identifier": { "id": "string", "scheme": "string" }, "reltype": "string", "href": "string", "model": "string", "serial": "string", "manufacturerName": "string", "registration": { "id": "string", "scheme": "string" } } } ]

[cookeac]

@jdoemel I have a couple of concerns about your extension to attentions events:

• We would want to wrap up widely used extensions into the formal definition in the specification so that it can be globally used - which is fine
• We still risk confounding the conversion of an activity alert from a system that indicates (for example, a potential heat) with the assessment of that heat and prediction of best mating window, and hence causing duplication, especially for the large number of systems that have already implemented the heat event. Let's discuss at the meetings, but I'd be recommending keeping these separate.

[jdoemel]

@cookeac by keeping them separate you're saying to have heat attentions/alerts in the POST /heats event endpoint and the POST /attention-events is only for health? Coming through the POST /heats option, we would treat those as heat attentions. We won't call that a traditionally entered heat in our system. The heat event would be entered by the dairy workers if they have confirmed the attention is a heat or they'll enter a bred event into the herd mgmt software program if they bred the animal off the heat attention. Looks like our next meeting is next week so that'll be good.

[cookeac]

Sort of. I'm suggesting "could be a heat" is an attention, while "its a heat, here's the insemination window" is a heat event. Otherwise there's a risk that everything becomes a variation on an attention, which means that attention grows and absorbs all the fields already built into other events.

[cookeac]

Great answer Andrew! In the meta section there is source, sourceId, and creator how would that be used? I guess really what I mean is when should source, sourceId, and creator be used instead of the fields on the device section. Appears we have multiple places that could identify the source of the information.

The meta source and sourceId fields are intended to identify the origin system and identifier of the event record. This is quite separate in meaning from the device or subsystem that triggered the observation -- though the two could be the same in some circumstances. For instance, a weight event might have the scale as the device, but the farm software as the source. An attention event might have a particular collar identified as the device (if the manufacturer so chooses), but the manufacturer's cloud system as the source.

[jdoemel]

Wow, you are full of knowledge and makes complete sense. Has ICAR thought of increasing the level of detail to the data fields and how they should be used? Use cases would be really helpful.

[cookeac]

Completely agree, on the to-do list!

[cookeac]

Linking this to #462 which is similar but different. It makes sense to me to indicate additional triggers - such as heat, weight, low battery - in an Attention, but do the details live in their own (existing) event types, or somehow get added to an Attention. What is the fit between device attentions and the wider range of animal recording activities and data?