Skip to content
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

Closed
m-mohr opened this issue Apr 29, 2023 · 5 comments · Fixed by #1299
Closed

created / updated: Different meaning in assets and properties #1228

m-mohr opened this issue Apr 29, 2023 · 5 comments · Fixed by #1299
Assignees
Milestone

Comments

@m-mohr
Copy link
Collaborator

m-mohr commented Apr 29, 2023

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?

@m-mohr
Copy link
Collaborator Author

m-mohr commented Sep 5, 2023

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.

@m-mohr
Copy link
Collaborator Author

m-mohr commented Sep 26, 2023

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.

@m-mohr
Copy link
Collaborator Author

m-mohr commented Sep 27, 2023

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.

@emmanuelmathot
Copy link
Collaborator

Mention that the top-level metadata might be nominal.

@m-mohr Could you please recall me what you meant by nominal?

@m-mohr
Copy link
Collaborator Author

m-mohr commented Jul 4, 2024

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], ...)

@m-mohr m-mohr linked a pull request Jul 5, 2024 that will close this issue
4 tasks
@m-mohr m-mohr closed this as completed Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants