Abstract Model for Observations

[knelson-farmbeltnorth]

We omitted the Observations models that were in the ADAPT Framework from the ADAPT Standard 1.0 with an intent to come back to them toward an abstract implementation matched to the Operation models. Open questions:

Can we support anticipated types of observations with additions to the Operations models, or do we need to revert to what the ADAPT Framework started, that Observations are fundamentally different?

How can we reconcile Observations as defined in PAIL/7673 with the primary ADAPT Standard principle that there must be one documented method of modeling any use case for ease of data consumability?

[knelson-farmbeltnorth]

I made a small table to illustrate my understanding of how the Observations models may fit into existing ADAPT Standard objects:

[knelson-farmbeltnorth]

Here is a mockup showing how Observerations and Measurement data could fit into the existing WorkRecord model. A Variable can have its own "Variable Context" variables such as what was the measurement depth, what was the temperature, what was the method used, etc.

[knelson-farmbeltnorth]

Discussion in 17 July 2024 Meeting:

I proposed the assumption that there is an unmet need for consistent reporting of Observations data such as lab test results, weather data, and crop scouting data, and it makes sense for ADAPT to fill at least part of this need. There was general agreement.

I suggested that whatever we add to ADAPT is clean and clear. Specifically that there is a focus on consistency and ease of consumption vs. flexibility in modeling, and that we snap to existing ADAPT patterns as much as possible. This was agreed. @aferreyra proposed a second goal that we preserve as much meaning and accuracy as possible. Also generally agreed.

I asked the question if ADAPT's "Ultimate Features of Interest" (following ISO-19156) are limited to Fields and CropZones (i.e., agronomic data). Several participants said no, that there was a need for transferring farm management data relating to fleet management, commodity marketing, input procurement, etc.

Regarding the above mockup, we discussed the possibility that having a fixed set of variable contexts (value at 10cm, value at 20cm, etc.) may be insufficient for cases where measurement parameters are continuously changing. We agreed to table this until such time that we had a concrete use case to discuss.

@strhea proposed adding a 5th document type (as with the prior ADAPT Framework) for general Observations. It may not contain operations or be modeled in the same way as other document types. I suggested that we may want to classify the existing types as agronomic documents and add multiple additional types to organize into logical farm management activities.

Please add any corrections or clarifications.

[knelson-farmbeltnorth]

Some questions/comments for discussion:

Are in-field observations really separate document types from Work Records?

• If so, what is a Work Record?  (Currently defined as "A record of completed work, contemporaneous in nature and scoped to a single Field or Crop Zone"). Do we need to qualify that Work Records are only, e.g., mechanized activities across the field?   That crop scouting and soil testing are a different kind of work that doesn't fit?
• We've repeatedly discussed the premise that equipment-sensed values logged at intervals over the field are fundamentally observations, so separating out a general observations document feels like a hard left turn.

Since today we have multi crop/multi field documents (Plans & Recommendations) and single field documents (Work Orders & Work Records), why not extend that paradigm as needed with a multi-crop/multi-field observations document (weather, remote sensing, etc), perhaps a farm maintenance document (fleet, facilities, etc.) and additional types as needed structured along the lines of the scope/type of the feature of interest? As such, in-field scouting and sampling seem to fit into Work Order and Work Record.

With respect to additional types of observations, is there something unworkable about the.current shared document line item (Operation) with its lists of values and associated data files? Is a sticking point that it is called "Operation?"

[crakerb-ship-it]

As I was thinking about this to me the thing that differentiates an operation from an observation is the product - crop input or yield. In an operation I believe there would always be a product applied or collected from the field that is really what is being documented/planned by an operation(work record/work order). The amount of stuff that went to/came from different parts of the field/cropzone.

An observation does not have a product, it is about collecting information about an aspect of the field/cropzone. There is no quantity of stuff being applied or collected from the field as the primary purpose of the event. That distinction might be helpful to maintain?

Maybe to contradict myself, I was also thinking about examples where what I would consider observations are collected during a field operation, how would that work in either approach? e.g. a weather sensor on a sprayer, a soil EC sensor maybe attached to a tillage tool, the boom-height control sensor logging crop height, a seed firmer collecting soil temp, etc.

[knelson-farmbeltnorth]

@crakerb-ship-it Adding to your comments, tillage is an operation without a product, and although we categorize both inputs and commodities as products in our model, they are fundamentally different things. We can also observe things about products outside of the field.

[aferreyra]

I think that to nail down the difference between operations and observations it may help to go back to systems theory and the sensors and actuators pair of concepts. Sensors are things that turn some perceived physical phenomenon into a signal, and actuators do the exact opposite. Observations primarily involve sensors (there may be actuators involved, like when an automated insect trap advances its sticky roll), and Operations have a more actuator-heavy mix, from the mostly-actuator tillage, to a more balanced (and increasingly sensor-heavy) harvest, application, etc. Ben's reference to products seems like metadata of the actuator.

[knelson-farmbeltnorth]

In the 7 August 2024 meeting we agreed that observations should be modeled in Work Records so long as the feature of interest is at or within the Field. When we have other use cases, we will expand document types where needed.