Priority: child links vs. collections

[m-mohr]

In client applications such as STAC Browser we have two sources for catalogs and collections:

1. /collections
2. child links

I've seen implementations where the implementors want different behavior for the client:

1. Only show collections
2. Only show child links
3. Merge child links and collections (which STAC Browser defaults to)

My first thought was to add a config option in STAC Browser to configure this, but on the other hand I'm wondering whether that's something that is of broader interest and may result in a new field or a set of conformance classes?

[iliion]

In the current implementation of STAC Browser is prioritizing to a default view., but since there are different approaches/implementations then the possibility to choose which way to go is the most sensible.

I believe this is connected with every discussion/issue concerning Browseable API

[m-mohr]

I think Browsable is something different, it doesn't say whether childs or collections are to be preferred, IMHO it just says that you can reach everything via links/collections that you can search for.

[iliion]

Exactly. My point was that no view should be prioritized over the other.

[chiarch84]

Well, but the browser and whatever other software attached to the APIs needs to know which view to prioritize or it won't know what to show.

I'm not sure that adding a new field would be the best way to go. It may be too specific for the specs.

From my point of view in this part of the specs it should be suggested to put mandatory one of the following options:

1. at least 1 child link and no data link
2. data link and no child links
3. data and child links together

This way it should be obvious what is the needed behavior.
Then there is also the problem of the /children conformance class which might complicate even more.

[iliion]

At this moment collection, catalog and subcatalog are equally "seen" by the API specs, so I dont get why in the landing page there should be a link to data (aka. collections) and I am not sure where should the (sub)catalogs reside. Calling /collections should return Collections and Catalogs?

[m-mohr]

STAC follows Hypermedia, which basically says you can explore everything just by following links.
Without having a data link you can't find the collections endpoint and as such it needs to be present (in addition to the requirement that OGC API - Features sets). If you implement OGC API - Features and STAC API - Features (or Collections) you need to have a data link. If you don't want to set it, you may need to implement another specification or extension such as the Children extension or something completely new.

The /collections endpoint can only return Collections.

What is your usecase around the (sub)catalogs? I don't quite get it, but I'm hearing it now for the second time (also from @chiarch84) and I'm somewhat confused. Could we discuss this in the next STAC community meeting? (27.2. 17:00 CET - @iliion @chiarch84 @philvarner )

[chiarch84]

Here the past discussion where our usecase was explianed and where it was suggested to use the same endpointfor both collections and catalogs.

[chiarch84]

To answer to this question in fact catalogs have a subset of fields of the collections, so in fact catalogs fields are also collections field.
Here an example of our subcatalogs.

[m-mohr]

The type field conflicts though! Otherwise, I've answered in the other issue.

[chiarch84]

by the way, happy to discuss it directly in a meeting.