stac-spec
stac-spec copied to clipboard
radiantearth
created / updated: Different meaning in assets and properties
In general, we seem to move forward towards the "common metadata" model, which means that if a keyword is present in Item properties, it applies to all assets if not overridden in assets. This works for many properties, but for examples created and updated have different meanings. In properties it applies to the metadata and in assets it applies to the data. This also applies for the timestamp extension.
Is this fine and clients need to handle it based individually for fields or should this be changed in STAC 2.0? This would probably mean that the metadata for the STAC Item needs to move from the properties to the top-level?
Related: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#common-use-cases-of-additional-fields-for-assets
When do we need properties in Item Properties, when in Assets? How's the hierarchy working? Is falling back from Assets to Item Properties valid it the asset is missing properties? We need much of this called out more specifically.
When do we need properties in Item Properties, when in Assets?
For Search usually in Item properties, for working with individual assets usually in Assets.
STAC sprint:
Also applies to eo:bands, gsd, most timestamps, ... which we would need to blacklist in inheritance. Alternative could be to whitelist depending on the extension, e.g. just for proj.
If you interhit you need to be able to overrride it, but most fields can't be "nulled". On the other hand, if you whitelist per extension specifically, you'd need to allow null specifically for all proj fields.
STAC sprint, day 2:
State in the spec that the assets inherit values from the "top-level" metadata (e.g. from Item Properties, in top-level collection properties). Mention that the top-level metadata might be nominal.
Mention that the top-level metadata might be nominal.
@m-mohr Could you please recall me what you meant by nominal?
I'm not 100% sure either, I think the term is not so good as it's unintuitive here.
I think what we want to say here that in some cases the inheritance doesn't necessarily make sense if other semantics have been defined for the fields (gsd [best resolution], updated, created [metadata vs data], eo:bands [union of bands in assets], ...)