In conversations with the Traceability working group, Load as specified is problematic. In practice, it is simply the user or auto-generated load numbers from a combine. We've left it open to wider uses, however, and this conflicts with the a more fully-featured traceability model that may find its way into future versions of ADAPT.
As such, we want to keep the concept of combine loads, but remove anything beyond that. We don't want the future introduction of a traceability model to break Field Operations as we have specified it.
The Traceability WG and I discussed this initial proposal:
Remove Load Type from Load. Any Loads in ADAPT v.1 are combine hopper loads. When we track other things in future, we can build out the appropriate type enumerations.
Change "Load" to "CombineLoad". The intent is that these objects are simply the load numbers and quantities defined by combines in conventional usage today.
Move Loads from Documents into Operation, making the collection optional. This replaces LoadId.
When and if we have other types of loads, such as input product lots or truck loads, we can link these "CombineLoads" to the a future Traceable Resource Unit contruct.
However, when I looked at this in more detail, I had concerns about having an optional CombineLoads for any type of operations. E.g., Operations in a Plan. Therefore I think a better approach is to treat load ids and load quantities as Summary Values. In the current version of ADAPT, that is really all they are. As such, my revised proposal is as follows:
Remove the Load object from ADAPT v1.
Create a new Numeric Data Type Definition called "Combine Load Quantity" in kg.
Any combine loads should be logged as individual Summary Values on the Operation. A Summary Value already carries a Time Scopes object. The load quantity in kg is the value and the load number/name is the name of the Variable mapped to the Summary Value. That Variable may also specify a product id directly.
If in future we introduce a Traceability Resource Unit that encompasses more than combine loads, we start fully modeling the loads there, optionally linking to these Summary Values.
Agreement in the 24 April 2024 meeting on the following:
Remove the Load object from the current ADAPT Standard model.
Change Operation.LoadId to Operation.Harvest Load Identifier. It will no longer be a reference but instead the textual identifier of a given load. This will continue to enforce that each load must be a separate Operation.
Do not add a new Data Type Definition. YieldTotalWetMass or YieldTotalDryMass exist and may be used for any Summary Values.
In conversations with the Traceability working group, Load as specified is problematic. In practice, it is simply the user or auto-generated load numbers from a combine. We've left it open to wider uses, however, and this conflicts with the a more fully-featured traceability model that may find its way into future versions of ADAPT.
As such, we want to keep the concept of combine loads, but remove anything beyond that. We don't want the future introduction of a traceability model to break Field Operations as we have specified it.
The Traceability WG and I discussed this initial proposal:
However, when I looked at this in more detail, I had concerns about having an optional CombineLoads for any type of operations. E.g., Operations in a Plan. Therefore I think a better approach is to treat load ids and load quantities as Summary Values. In the current version of ADAPT, that is really all they are. As such, my revised proposal is as follows: