Collections as common between standards

[ogc-leedahl]

So after the meetings this week, many of the APIs used collections as the root path element. Since processes are the root collection, would it make since to start with collections as we would for feature or WMTS. So {base url}/collections/{process id}/jobs ... Etc.

[christophenoel]

Discussions on that topic:

Spacebel sa (Christophe Noel) @spacebel Jun 20 12:08
Should we apply the principles of /collections, grouping processes into collections (optionally with a default /collections/default/processes) or do we keep the replacement of collections with processes. In OGC API Common, it is (currently) not documented as optional. A third solution, is considering processing a collection (of jobs). I'm in favor of solution 2: keep processes as the main resource of OGC Api Processing. What do you think ?

Matthias Mohr @m-mohr Jun 20 12:10
@spacebel I see collections as the point where I list all potential data sources. I could combine WPS with WFS and WCS and list all my WFS/WCS collections in /collections and the use the data for processing.

Benjamin Pross @bpross-52n Jun 20 12:11
@spacebel I also would prefer option 2

Spacebel sa (Christophe Noel) @spacebel Jun 20 12:11
So we don't need to modify all our implementations :)

Francesco Bartoli @francbartoli Jun 20 12:19
Should we apply the principles of /collections, grouping processes into collections (optionally with a default /collections/default/processes) or do we keep the replacement of collections with processes. In OGC API Common, it is (currently) not documented as optional. A third solution, is considering processing a collection (of jobs). I'm in favor of solution 2: keep processes as the main resource of OGC Api Processing. What do you think ?

What would it be the concept of collections for processes?

Spacebel sa (Christophe Noel) @spacebel Jun 20 12:24
@francbartoli We can imagine grouping processing by domain, or by type (workflows, containers) or any specific classification. The process identifier (ows:identifier) originally includes an optional "codeSpace" for "grouping" processes. Maybe the collections/ is a nice way for mapping the XML codespace to REST ?

Benjamin Pross @bpross-52n Jun 20 12:25
@spacebel I've added the server

Francesco Bartoli @francbartoli Jun 20 12:27
@spacebel the workflow IMHO should allow to chain processes but I would consider it as an extension

Brad Hards @bradh Jun 20 12:27
As a potential consumer, I have a weak preference for keeping /processes and /collections distinct.
The grouping is an orthogonal issue - user-meaningful grouping (a la OWS Context) should be separated from the resources.

Francesco Bartoli @francbartoli Jun 20 12:50
As a potential consumer, I have a weak preference for keeping /processes and /collections distinct.

One potential use for collections could be to aggregate processes from cloud providers like GEE from Google and GEOSCOPE from IBM just for giving some examples

Also the concept of remote processing are not considered in the current spec, I would open a ticket for that

[cmheazel]

Just a thought - the purpose of a process is to produce an output. So wouldn't you group processes by the type of output they produce? /collections/{collectionId}/coverage would form the root path for processes which produce coverages.

[pvretano]

@ogc-leedahl My preference would be to have a path that looks like this: /collections/{libraryId}/items/{processId}.
The idea is that processes could be grouped into libraries and we could have a special library (e.g. default) for ungrouped processes. So, one could imagine standing up a WPS that deploys the PROJ and GDAL libraries on the web and would thus have paths like:

/collections/proj/items/molodensky
/collections/proj/items/eqc
...
/collections/gdal/items/translate
/collections/gdal/items/rasterize
...

There would be no problem mixing feature and processes, for example, since the collection metadata (i.e. GET /collection/{libraryId}) includes and itemType key whose value would be "process" for WPS thus indicating that this is a collection of processes. WFS already uses this key (itemType="feature") to indicate a collection of features and other resource types would also use it to discriminate their resource types.

[m-mohr]

I see /collections more as collections of actual (geospatial) data (coverages, features, ...) and processes are not data for me. So having processes in collections feels not intuitive.

[bradh]

@pvretano I'm opposed to libraries - that feels like an implementation detail not something the user should see (i.e. it should not be visible in the API). Consider if you want to replace the rasterize mechanism with a different implementation that does the same thing - I don't want to modify my client to deal with that.

I'd like to see a grouping mechanism, but groups -> processes could be a many-to-many, where the groups are just a bunch of pointers to the related processes (and maybe data that is applicable). For example, a server might offer a "digital elevation data" group and a "weather" group, and some of the processes would be useful to users interested in either group.

[jerstlouis]

As per the resolution of opengeospatial/ogcapi-common#140, and the Common SWG decision to rename OGC API - Common - Part 2 to from Collections to Geospatial Data, an OGC API dataset's /collections/ path is specifically for (geospatial) data, as @m-mohr pointed out.

However this does not prevent either grouping list of processes, or even potentially organizing them in a hierarchy, but the Processes specifications now uses the term list instead to avoid the confusion.

Processes which do work with a specific data layer (aka collection) can be listed under a particular .../collections/{collectionId}/processes resource though.

Suggestion to close this issue, and open a new one if needed to discuss lists processes (/processes already provides a basic list of processes) and/or hierarchies of processes, avoiding the term collection.

For hierarchies, a similar concept could be used to organize both collections (data) and processes, e.g. could a : separator be used, such as dem:generateContours?