-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
created / updated: Different meaning in assets and properties #1228
Comments
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.
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. |
@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], ...) |
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
andupdated
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?
The text was updated successfully, but these errors were encountered: