Agreement as to the name of Part 2 resources (e.g. Table 2)

[jerstlouis]

Part 2 defines two main resources:

• Collections (list of all collections?)
• Collection (detailed collection resource?)

We need to agree on how to name these resources.

Additionally, /items is also included in Table 2.

The names currently used are wrong (Metadata for /collections, Description for /collections/{collectionId}, Collection for /collections/{collectionId}/items).

[cmheazel]

@jerstlouis I thought we finished with this in #105

[jerstlouis]

@cmheazel I believe you asked me to file this issue at the 21-05-07 SWG meeting because we agreed it still needed some work.

Looking at the Table 2 in the latest generated draft:

• I am happy with /collections/{collectionId} being called Collection Description . Is that OK with Features @cportele though? It could also be called the Collection itself, with the clarification that you do get a description of it when you ask for e.g. a JSON representation (and not its content)
• /collections is still called collection metadata, which does not sound right at all (also raised as an issue in #105, but if master is the latest it was not fully addressed by the March 16 PR: see here). /collections/{collectionId} could also be called metadata (since it is the same information for one particular collection, potentially with additional details, is contained there), and so could a dedicated ISO 19115 link following the agreed data-meta link relation (e.g. to /collections/{collectionId}/metadata. I suggest this should be called Collections list which mirrors the Processes list (/processes), Tilesets list (/tiles), TileMatrixSets list (/tileMatrixSets) resources (where list refers to multiple elements available without using the confusing collection term which has the special Part 2 OGC API Collection of (usually) Geospatial Data meaning).

I see that /items is gone from this table (I think that's a good thing). However I see a few left overs that probably needs to be fixed:

• A.2.2 and A.2.3 talks about Feature Collections ( http://docs.opengeospatial.org/DRAFTS/20-024.html#_feature_collections_rootcollections) -- Should probably remove Feature there
• A.2.4 talks about {root}/collections/{collectionId}/items -- the whole test should probably be removed

[cmheazel]

@jerstlouis Sorry, my mistake.
Carry on.

[cportele]

@jerstlouis

I am happy with /collections/{collectionId} being called Collection Description. Is that OK with Features @cportele though? It could also be called the Collection itself, with the clarification that you do get a description of it when you ask for e.g. a JSON representation (and not its content)

In Features the resource is called "Feature Collection" (http://docs.opengeospatial.org/DRAFTS/17-069r4.html#tldr) as a subtype of the more general "Collection" (http://docs.opengeospatial.org/DRAFTS/17-069r4.html#core-overview) that is not limited to items that are features.

It was Collection Metadata earlier in the draft phase of Features, but that was changed, because it did not work. The discussion is in opengeospatial/ogcapi-features#217. It would be good, if Common does not change the terminology or allows other specs to keep using their resource names.

[cmheazel]

June 15 2021 - return to the API Features convention of Collections and Collection. Make sure the terms are sufficiently well defined that they avoid confusion.

NOTUC

[cmheazel]

June 15 recommendation has been implemented except for the ATS.
Update of the ATS is covered by issue #178

[cmheazel]

June 26 2021 - Change resource collection to collection resource Change title of table 2 to Resources. Change "Description" column header on Table 2 to "Response"