Soil Tests: Defining the Completed Tests #151
Description
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, OBSERVATION_UOM 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.
