ADAPT / Standard

ADAPT Standard data model issue management
https://adaptstandard.org
MIT License
7 stars 1 forks source link

Revisiting the ADAPT Representation System #81

Open knelson-farmbeltnorth opened 1 year ago

knelson-farmbeltnorth commented 1 year ago

The existing ADAPT Representation System (https://github.com/ADAPT/ADAPT/blob/develop/source/Representation/Resources/RepresentationSystem.xml) contains standard descriptions of data points passed around in the model. It was donated by John Deere and has been extended with a few additional features (mapping to ISO11783-11 DDIs, 1-2 dozen new data representations). Some of the features (recommended units of measure, localization into 38 languages) are artifacts of Deere's implementation and are not necessarily kept current as new things are added.

Going forward, there is discussion of simplifying this system in parallel to the removal of detailed machinery awareness within ADAPT. The breakdown of numeric representations is based a different set of business needs and is not necessarily relevant for the ADAPT standard. E.g.s -Particularly in the yield Numeric Representations, there is confusion between Wet, Dry and Total representations, and separation of Forage and Cane (ostensibly simply to associate different default units).
-There is separation between "Setpoint" and "Target" values, conceivably representing the delta between machine capability and agronomic intention. -There are types defining things handled differently in ADAPT. E.g., vrABRowSpacing. Guidance Pattern has SwathWidth property that simply takes a number and unit of measure.
-There are numerous types for use cases that are, at best, at ADAPT's edges: E.g., vrMaxBestFitDrainCutDepth: Maximum cut depth for Best Fit Drain -There are types for specific business cases that are not a one-to-one fit into ADAPT. E.g., vrSeedsPerContainer, vrSeedsPerBag, vrSeedsPerSack

Issues for discussion -Should we simplify the Representation System in the forthcoming ADAPT Standard to start with a smaller subset of types for common use cases, defining a process to expand these types as new use cases emerge? -Do Numeric Representations and Enumerated Representations belong in the same system? -Should we require all data be passed in a common unit defined in each Numeric Representation?

strhea commented 1 year ago

-Should we simplify the Representation System in the forthcoming ADAPT Standard to start with a smaller subset of types for common use cases, defining a process to expand these types as new use cases emerge? In my opinion, yes.

-Do Numeric Representations and Enumerated Representations belong in the same system? This is a bit tricky. I think that we need to be able to handle variables that collect string, numeric, bool, and enumerated values. How those objects are modeled in a world that seems to be drifting away from strong typing - I don't know.

-Should we require all data be passed in a common unit defined in each Numeric Representation? Yes, though keep in mind that there are "unitless" numeric values we may want to capture. I fully support designating a default UoM that the data will be expressed in. If that UoM differs from what the producer or consumer uses internally, it becomes an exercise left to the implementer to do the proper conversions.