Relationship with /collections/ and /collections/{collectionID} in the context of end-point serving and/or cataloging thousands of collections

[jerstlouis]

Since /collections/ lists all the collections available on a service (presumably thousands of these), this feels like the natural place where supplying some parameters such as geospatial and temporal extents, keywords, scale/resolution, representation type (e.g. vector features, coverage) would allow to filter such collections to get only relevant results.

By providing only a /collections/ resource with such filtering capabilities, linking to external collection elsewhere, a service effectively could act as a catalog.

Does this, and if not, how could this fit with, or be reconciled with, the vision for OGC API - Records?

[uvoges]

The main use case of OpenSearch-EO (https://portal.opengeospatial.org/files/?artifact_id=73994) is what we call 2-step-search: this is a very common use case of EO agencies and means, searching for a virtual/abstract collection and after having identified the right one, search for "materialized" files (aka products) (no dataCube) by getting offered the right search endpoint (collection resource). So searching for a collection is evident for us.

[uvoges]

Search on /collections would possibly not be necessary in case that the /collections provide the Record Types (e.g. series, dataset, service,..) and a search would then search either for items of series, dataset, service…

[cportele]

Meeting 2020-02-24:

• This is a separate capability from OGC API Records as it is a capability on the /collections resource. The issue should be closed here and moved to Common.

[jerstlouis]

@cportele OK, thank you, but how do we reconcile the Records capabilities with this capability in Common? Would that be in the scope of Records to do this?

[cportele]

Yes, there would be some overlap in a capability that allows querying the /collections resources with a catalogue that has metadata records about such collections, but I do not see how this could be avoided and it should not be a problem in general, if the SWGs coordinate so that building blocks are reused consistently.

Note that the scope of Records is much broader than just metadata about collections in a dataset.

[pvretano]

Closing as the discussion is continuing in issue #43.