inclusion of procession extension fields as a requirement and how to suggest use of processing extension

[rbavery]

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.

[fmigneault]

I don't think they need to be requirements, nor necessarily included in the same STAC document, especially since they come from another extension. I would simply add notes to the README of the extension specification to guide users about which parameters/values are recommended since they work well with the model extension. The more examples and guidance we provide, the more chances we have for users to apply them in a similar fashion.

[rbavery]

I agree! Maybe we could have a best-practices.md similar to the stac-spec repo that outlines how this interoperates with other extensions.

[rbavery]

I added a doc for best practices that references this processing extension with an example in #2 We can make new sections for other extensions that can be composed with this one.

[fmigneault]

Good addition for the best practices document.

Something about the STAC 1.1 "bands" (https://github.com/rbavery/dlm-extension/blob/validate/README.md#bands-and-statistics) vs raster:bands vs eo:bands vs mlm:bands (?) should definitely be mentioned, and specifically how they interact/complement each other.
I am slightly worried by the use of STAC 1.1 "bands" since 1.1 is not yet defined and released, and it will take even longer for implementations to support it natively. This could limit the use of MLM for a very long time if it depends on it. Realistically, we will need to support raster:bands/eo:bands for some time (notably in the pydantic utilities).

[fmigneault]

Defined in best practices document.
Fixed by #2