updates to browseable #377
Conversation
core/README.md
Outdated
| to advertise that all Items in the Catalog presented by a STAC API may be reached by following `child` and | ||
| `item` link relations. In a non-API STAC Catalog, all items must be reachable via these relations to be | ||
| considered in the catalog. With a STAC API Catalog, items are considered to be in the catalog if they are | ||
| accessible via search operations. However, a STAC API Catalog may also have child and item link relations. |
There was a problem hiding this comment.
I have a couple of questions:
- While I like this way of thinking, but what about APIs that don't support item search?
- Would it in this case mean that all items can be reached via item/child links that are part of STAC API - Features?
- Should Browsable be used if an API only implements STAC API - Collections and Collection Search and exposes all Collections via child links (but has no items at all)?
There was a problem hiding this comment.
* While I like this way of thinking, but what about APIs that don't support item search?
Good point. I'll clarify this language, since it should be considered in the catalog of it's accessible via link relations or search via /search or /items
* Would it in this case mean that all items can be reached via item/child links that are part of STAC API - Features?
Yes -- I clarified that search includes both /search and /items
* Should Browsable be used if an API only implements STAC API - Collections and Collection Search and exposes all Collections via child links (but has no items at all)?
Yes, I think so. I'm reluctant to add this as an example because it seems like a very uncommon case.
…h#381) * link to STAC API Extensions site instead of listing them * Apply suggestions from code review --------- Co-authored-by: Matthias Mohr <webmaster@mamo-net.de>
|
@m-mohr did you have any other issues you wanted addressed, or is this ok to merge? |
|
The PR itself is good. I have general concerns about this conformance class as part of Core as it's not implemented anywhere yet (afaik). Even the newly mentioned clients like STAC Browser, pystac-client and stac-nb don't implement it, right? I also don't really know how I could implement it in STAC Browser so that it's beneficial for users. Thoughts? What were your ideas when you mentioned it? @philvarner |
|
I think that's a reasonable concern. I think originally it was part of Core instead of an Extension when all of the extensions were still in this repo, but now that they're separate, I would be in favor of separating it out into an extension that can be versioned and matured independently. This would also align with some of the concerns I have about how much "best practices" text we have in the spec, and this conformance class has a lot of explanatory text for being effectively one sentence of semantics. Maybe we merge this PR, and then I'll move it to an extension before rc.3? |
|
@philvarner Makes sense to me. Go ahead. |
Related Issue(s):
Proposed Changes:
PR Checklist:
stac-specdirectory (these are included as a subtree and should be updated directly in radiantearth/stac-spec)