Soil Tests: Defining the Requested Tests

[knelson-farmbeltnorth]

Extending the discussion from #148 specific to test identification in this issue.

We've discussed examples where tests may be requested variously by package name, group of analytes or single analyte. Test package seems to me to fit well inside of the Product concept, but individual analytes are more of a stretch. @aferreyra and I discussed extending our Variable object with statuses (e.g., Requested/Reported) as in the example below.

Where Variable Status is Reported, there is a corresponding column in the Geoparquet. Where it is Requested, there is no accompanying data.

If the request is simply by package, we could render the same request as such. Omission of Variable Status would default to Reported:

In the past we've allowed multiple methods of modeling data when there is a varying degree of detail (e.g., Summary Values vs. Spatial Detail). I would ask the question whether there are ever workflow situations where the requesting party cannot define the constituent tests in a package, or if the receiving party requires requests by package name (perhaps there are different tests for the same analyte in different packages)? If so, we may want to consider supporting both methods.

[knelson-farmbeltnorth]

In the 4 September 2024 meeting we started to discuss the pros and cons of modeling a requested test as a product vs. collection of variables in a requested status.

Speaking for myself, I can see it both ways. One the one hand, an agronomic service is a product, and someone may wish to consider services as per-field investments alongside seed, fertilizer and crop protection costs. We can model a service's constituent attributes either on top of the existing ProductComponent object (really designed for tank mixes, but arguably extensible to seed treatments) or else make a new Product Type of "Service" and make a collection of "ServiceAttributes" on it. On the other hand, Product is already unwieldy. I anticipate confusion from some that we model seed, tank mixes and harvested produce on the same object. Also, machinery use carries measurable per-field costs, but to the extent we model that at all, it is not on Product.

Re putting a status on a variable, this correlates well to what we are already doing in Field Operations. Seed Singulation at a point on a field is a variable, so why wouldn't we handle soil Ph similarly? We've discussed that ISO11783-10 has both requested tasks and data log triggers on individual variables. Then again, how well are Data Log Triggers really supported in the industry; should we view that as a cautionary tale?