Create a new link relation like "parent-catalog" or "api-parent"

[philvarner]

Currently, we have two link relations that go "up" the tree -- root and parent. However, in deeply nested trees of catalogs that have varying support for conformance classes, these are not sufficient to express the "root" of a sub-Catalog.

Example:
CMR has a root that doesn't support search (https://cmr.earthdata.nasa.gov/stac), but links via child relations to catalogs that do (https://cmr.earthdata.nasa.gov/stac/LARC_ASDC) . An item from one of these catalogs should have "root" as the top level-root, an parent may only go up one level in a tree of catalogs, so there's a need to express the "search root".

[chiarch84]

Dear @philvarner I think that this issue is related to what you are saying here.
I guess that, if at each level of "deepness" of the catalog tree structure, you implement the /search method (and of course all the other methods) it will be then just an implementation problem (so how to create the query) to correctly search only on that specific tree branch.

Let's create a simple example made of catalogs, subcatalogs, subsubcatalogs and collections etc.:

Root
--- sub-catalog A
------- Collection A1
-------------- Item A1.1
-------------- Item A1.2
-------------- Item ...
------- Collection A2
------- subsub-catalog A1
-------------- Collection A1.1
------------------ Item A1.1.1
-------------- Collection A1.2
--- sub-catalog B
------- Collection B1
------- Collection B2

If the APIs implemented are:
/catalog/{catalogid}
/catalog/{catalogid}/collections
/catalog/{catalogid}/collections/{collectionid}
/catalog/{catalogid}/collections/{collectionid}/items
/catalog/{catalogid}/collections/{collectionid}/items/{itemid}
/catalog/{catalogid}/search
/catalog/{catalogid}/children

It would be like if I there were 4 different STAC API endpoints:
{baseurl}/catalogs/root.catalog
{baseurl}/catalogs/A.catalog
{baseurl}/catalogs/A1.catalog
{baseurl}/catalogs/B.catalog

Each of these ones should permit the /search (and all other methods) function.
It will be then the technical implementation that, in the case of {baseurl}/catalogs/A.catalog/search will have to search, not only in items A1.1 and A1.2, but also in item A.1.1.1.

I hope my comment makes sense in this issue, if it is not in the context please let me know.

[geospatial-jeff]

This would make implementation of children/browseable much easier in my opinion.