Question - Best practice for a project with multiple extensions

[rhysrevans3]

I'm working on a project (CMIP) that expects to create multiple extensions (6 confirmed with several more expected). We would like to include them in the stac-extensions project if possible. Is there a recommended way of dealing with multiple linked extensions for a single project? Should we request a repo for each or would we be able to have multiple in one repo or would it be better to use a separate GitHub "organisation"?

[gadomski]

I'd love to see more information on the extensions, because it's surprising to me that you'd need six new ones. There's a lot of extensions out there already, and usually the pattern is "re-use what exists and create one new one for your new dataset".

If the extensions will only be used for your project, it's more common to host the extensions yourself ... e.g. the Humanitarian OpenStreetMap Team (HOT) has an extension for their OpenAerialMap project at https://github.com/hotosm/stactools-hotosm/tree/main/stac-extension.

[jsignell]

Also for CMIP6 I know there are at least downsampled versions available on Planetary Computer STAC (https://planetarycomputer.microsoft.com/dataset/nasa-nex-gddp-cmip6). It might be worth checking which extensions they are using to see if any of those would also be suitable for your group?

[rhysrevans3]

Within CMIP there are many sub projects that have their own vocabularies/meta data fields so we plan on having an extension for each sub project. I'll check with the team on if we think they'll be used externally but we should be able to host them ourselves if that's the recommended approach.

We've written a CMIP6 Extension extension to use for our testing that gives an example.

The Planetary Computer STAC does use fields with the cmip6 prefix but I can't see an extension in the stac_extensions field. I think it might be using this https://github.com/TomAugspurger/cmip6 extension but we were only made aware of this after we had made our extension and doesn't seem to be actively maintained.

[m-mohr]

With both CMIP6 extensions, that ideally will be aligned/combined in the future, I also see that the reuse of existing fields is potentially not fully pursued.

For example:

• cmip6:product -> product extension?
• cmip6:license -> license field and relation type
• cmip6:creation_date -> created?
• variable related fields -> datacube extension?
• cmip6:institution(_id) -> providers / contacts?
• cmip6:grid -> grid extension?
• cmip6:further_info_url -> links
• cmip6:data_specs_version -> version or processing:version?

...

People often just dump things into new extensions without actually making an effort to align, making their metadata less interoperable than needed. So I'm also sceptical with regards to the six new extensions, especially when not generalized enough.

[rhysrevans3]

Thanks @m-mohr appreciate the feedback! Some of those extension look very useful I'll feed this back into the project.