Can a top-level search using the /search resource search for anything in the resource tree?

[pvretano]

The purpose of this issue is just to stimulate discussion on the possibility of the /search resource being used to search all OGC API resources not just collection items (e.g. features, records). So you could run a full text top-level search (i.e. q=) and get back matching records, features, collection objects, styles, etc...

Just thinking out loud in OGC API Records.

[cportele]

In the current proposal, GET /search returns the list of stored queries and GET /search?q=foo could return the stored queries that match a keyword search for "foo".

Even if we change that: What would be the response media type and content? Records/features, collection objects, stylesheets are all different resource types with different media types. I guess, the idea is to simply return a list of links to the matching resources?

[m-mohr]

In STAC, /search returns a FeatureCollection. This means all search results must be GeoJSON Featues, which in STAC only applies to Items. If we want to not have conflicts between the OGC API and STAC specifications, we should check how we can solve this (e.g. via media types, which seems preferrable) or whether we can agree on a more general structure that is not based on GeoJSON FeatureCollections (would be breaking in STAC).

[cportele]

Meeting 2023-05-22: Yes, we want to avoid incompatibility with STAC. This should be discussed in a separate issue, @pvretano will open one. Probably we should split /search into two resources, one for stored queries and one for the ad-hoc queries.