stac-spec

stac-spec copied to clipboard

Can (and should, if applicable) a STAC entity have multiple parent links?

Example: We have (for better browsability) a static catalog where multiple catalogs (A, B) link to another collection C. From the folder structure there's a clear parent (A) in this case. Should C link to both A and B or just to (e.g.) A?

I think the spec should clarify this (as requirement or recommendation). I didn't find a clear answer in the spec, maybe I missed it. Right now I assume multiple parents are allowed and it's up to the implementation to decide whether they place one or more, depending on their usecase/requirements. BUT I think we might have meant to just have a single parent.

cc'ing some people for input: @matthewhanson @gadomski @cholmes @pvretano (any thoughts from the static Records perspective?)

A more specific example:

• Root (at /)
  • Product
    • S2
    • L8
    • S1
  • Domain
    • Multi-Spectral (links to /Product/S2 and /Product/L8 as "child")
      • (S2)
      • (L8)
    • SAR (links to /Product/S1 as "child")
      • (S1)
  • Provider
    • COPERNICUS (links to /Product/S1 and /Product/S2 as "child")
      • (S1)
      • (S2)
    • USGS (links to /Product/L8 as "child")
      • (L8)

Is the parent for "S2" required to only be "Product"? Can (or should) "S2" have the multiple parents (here: "COPERNICUS", "Multi-Spectral" and "Product")?

I'm 👎🏼 on multiple parents. My personal mental model of STAC is filesystem-like, where one file can't live in multiple folders. Any additional relationships should be "sibling" or "child" relationships, IMO. Complexity goes way up if we support multiple parents.

Yes, me too. I just want to clarify it in the spec. So the example above is fine to do, but only set one parent (ideally like in the filesystem, I guess).

@m-mohr I think I agree with @gadomski too ... complexity bad ;)

I want to add a voice FOR multiple parents! They are especially useful in dynamic catalogs rather than the traditional file-based approaches usually entertained.

The increase in complexity is somewhat mitigated by the collection field in the STAC Item which allows you to maintain a single-parent view if that is your preference. I would instead push for the 'collection' field to be added to STAC Collections so they too can take a single-parent view if that is what is required.

It might be valuable to have a best practices entry specific to dynamic catalogs. Does a dynamic catalog really need multiple parents if it is being generated on the fly? Is a dynamic catalog designed to be browsable via a hierarchy?

I am thinking the answers to your questions are:

1. Dynamic catalogs can be browsable by multiple hierarchies which I think requires multiple parents be supported at the storage level. I suppose if you had to have only single parents returned the API could dynamically remove the parents not in the traversal path... ?
2. I think a dynamic catalog is designed to be browsable via a hierarchy.

Discussed in STAC sprint.

• Decided to not support multiple parents. Dynamic catalogs can implement multiple parents through a dynamic browsing interface as they could dynamically create the parent link based on the desired browsing structure (though only 1 parent at a time).
• If multiple "parents" are desired the better approach is to use a different relational type (e.g., "related").
• We do not want to have to build support in the ecosystem for multiple parents.