knelson-farmbeltnorth
commented
2 years ago From discussion with @aferreyra Re point 1, we've reworked the definitions for the standard. Re point 2, this is a template pattern. See #73.
Re point 3, we do mean Observation Code (fka OMCode)
Re point 4, for the same reasons we need ad-hoc context items, we need ad-hoc observation codes.
Re point 5, we've adopted the following unabbreviated terminology Observations Document Observations Dataset Observations Collection Observation
Re point 6, these are parts of the PAIL standard not otherwise reference (or currently needed) in ADAPT.
1.OMSourceId, OMCodeId, OMCode and CodeComponents are defined, but the definitions are abstract. Without a real-world example to cross reference, I suspect I'm not the only one who cannot make sense of them. We need to clarify these definitions.
In the case of OMSourceId and OMCodeId, the definitions say "mostly" this or that. Can we define the exceptions?
The above 4 properties, plus Grower, Place, SpatialExtent and TimeScopes are duplicated on Obs and ObsCollection.
a. Following the general issue defined in #38, does the duplication of the properties imply that an ObsCollection can only contain like values of its constituents, and all constituents must agree, or that when present, an OMCode, collection of CodeComponents or GrowerId on the Collection override the individual Obs? b. For TimeScopes and SpatialExtent, is the intent that the data publisher would summarize constituents into comprehensive values?
Obs.Value indicates that its meaning is described by OMCodeDefinition. There is no object by this name. Do we mean OMCode?
Following a similar issue in #52 relating to ContextItemDefinitions, does the OMCode definition belong in ADAPT, or is this intended to be used in a model of an external system for vocabularies? Does the presence of the entity in ADAPT convey that one may create these codes on demand, without any acknowledgement of a governing vocabulary, or that they are necessarily read-only copies of data in external systems included here for convenience?
As alluded to in #55 and #37, is the root Observations entity present only to conform to the existing Document base in ADAPT, or is there a use case for grouping ObsDatasets into a single entity. If so, can we change this to ObsDatasetCollection so that we may reserve the "Observation" name for Obs (see #55)?
3/4 of the OM enumerations are not used. OMSemanticResourceStatusEnum, OMSemanticResourceLevelEnum and OMCodeComponentPartEnum will be omitted going forward pending a place to use them. TelemetryMediumEnum is also present but unused.