Soil Tests: Defining the Completed Tests

[knelson-farmbeltnorth]

In previous mockups in #148, I used the modus code to define the specific tests run. However, @daringary shared an example the cannot readily be mapped to a Modus code. I've used phosphorus in the mockups, and in his example P is reported as simply P-O, which I take to mean Phosphorus using the Olsen method. That cannot be mapped to a single test in either the case of Modus 1 or Modus 2.

If we don't have explicit detail on the test run, we can only report what we have. As such, Modus codes may not be a viable reporting mechanism in ADAPT. Rather, my proposal would instead be that we take the distinct analytes from the Modus vocabularies and use that as the required variable definition codes in ADAPT. E.g., SOIL_N, SOIL_P, SOIL_K, SOIL_PH. Where a modus code is known, we can include that as an optional attribute.

There is a further issue in that tests for the same analyte are not necessarily reported in units that are convertible to one another. Thus if we don't necessarily know the specific test, and we can't force conversion to a single UOM, we need to add UOM to the Variable object. In the past we have avoided this to force consistency of reporting. The only alternative would be to steer soil test variable definition to dataset-specific custom data type definitions and report the unit there.

If we add UOM to variable, we'll need to be explicit that it can only be set/honored in cases of data definitions of varying UOMs. Such data definitions would be new to the ADAPT standard, and if modeled as Numeric DTDS, would violate the UOM attribute's cardinality. Perhaps we could reuse the proposed Variable Context construct for this purpose. In the mockup below, OBSERVATIONUOM would be a required Variable Context on any SOIL* numeric data definition, and MODUS_CODE would be optional. Modeling as MODUS_CODE would allow either v1 or v2 codes to be used; the version is explicit in the code.

[knelson-farmbeltnorth]

Note from 4 September 2024 discussion. The Modus projects have already defined the distinct list of analytes. I believe this is the Modus1 listing. @crakerb-ship-it Is the Modus2 list completed?

[crakerb-ship-it]

Correct that is the Modus 1 list, there are working groups going through and updating the methods lists to the "version 2" structure. The new soil method list is at the link below, a manure list is going through final approvals and will be posted in the same folder soon, and a new Working Group on plant tissue was just announced.

Regarding an analyte part of the list, that has not been posted separately from the method lists at this point, we are working on making sure the manure analytes align where appropriate with the soil analyte list then we should be able to post.

https://github.com/AgGateway/Modus/tree/main/Method%20Lists/Modus%202

[knelson-farmbeltnorth]

I'm adding a mockup of what a request to sample, completed sampling with ids (bag labels), and completed tests might look like in ADAPT.

Several things to note -

Test packages, sampling service, etc. are mocked up as products:

"products": [
      {
        "id": {
          "referenceId": "11"
        },
        "name": "Soil Sampling",
        "productFormCode": "SERVICE",
        "productTypeCode": "SERVICE_SAMPLING"
      },
      {
        "id": {
          "referenceId": "14"
        },
        "name": "Soil Test Package 1",
        "productFormCode": "SERVICE",
        "productTypeCode": "SERVICE_TESTING"
      }
    ],

I'm reusing the DateContext enumeration for Timestamp variables in the Geoparquet, and ContextItems for what have been termed Code Components in the PAIL work

 "variables": [
              {
                "contextItems": [
                  {
                    "definitionCode": "DateContext",
                    "valueText": "PHENOMENON_TIME"
                  }
                ],
                "definitionCode": "Timestamp",
                "fileDataIndex": 1,
                "id": {
                  "referenceId": "17"
                },
                "name": "Sample Time"
              },
             {
                "contextItems": [
                  {
                    "definitionCode": "StartDepth",
                    "valueText": "0"
                  },
                  {
                    "definitionCode": "StopDepth",
                    "valueText": ".2"
                  }
                ],
                "definitionCode": "SampleId",
                "fileDataIndex": 2,
                "id": {
                  "referenceId": "18"
                },
                "name": "Topsoil Id"
              },
       ]

For the mockup, I've not specified a unit of measure on the lab return value. I'm wondering if we should really classify things that may have different units of measure as the same analyte. If the units are truly not convertible, are they really the same analyte?

           {
                "definitionCode": "P",
                "fileDataIndex": 4,
                "id": {
                  "referenceId": "25"
                },
                "name": "Phosphorus"
              }

Mockup.zip