inclusion of procession extension fields as a requirement and how to suggest use of processing extension #6
Description
continuing the discussion from #3 @fmigneault
I don't think processing should be removed. There are cases where only a simple arithmetic expression to combine bands or perform simple pixel-wise manipulations are applied. Using ML-model for such cases would be overkill and too verbose in comparison to the simple format it offers.
I'm down to suggest the processing extension as an alternative and briefly enumerate where that might make more sense than the ML model extension.
I'm wondering though if we should always require specifying the processing level of the input data?
NASA and ESA might use these processing levels and clearly report them in STAC or in their own documentation. But other imagery providers may not. If we make these fields a requirement, this puts more burden on the ml model metadata author to figure out the processing details to list in the ml model metadata. And ultimately I'm not sure including these fields in the ML Model metadata helps users find models and run model inference.
I'd expect this processing info to be in the STAC Item for the dataset and for this to be the responsibility of the data provider. And for the ML model extension to be associated with this dataset, like via a link object as discussed above. I'd be happy to have thee as optional fields, but am still a bit uneasy about making processing extension fields required here.