Names of resource types

[cportele]

This issue has been created as part of the public review and is based on document 19-072. See in particular the Abstract and sections 9.2.1, 9.2.2, and 9.2.3.

• Use "Conformance declaration" instead of "Conformance classes" as the name of the resource at /conformance, which is more precise.
• Use "Collections" instead of "Collections metadata" for the resource at /collections. The resource is not metadata, it is the collection(s) themselves.
• Use "Collection" instead of "Collection Information" for the resource at /collections/{collectionId}. The resource is not metadata/information, it is the collection. Add the resource to the table in the abstract.
• Rename "Collection" in 9.2.3 to "Items" or remove the section; if it is kept add it to the table in the abstract.

[jerstlouis]

Use "Collection" instead of "Collection Information" for the resource at /collections/{collectionId}. The resource is not metadata/information, it is the collection. Add the resource to the table in the abstract.

I disagree with this... This contains metadata such as the geospatial / temporal extents, and links to the actual representation...
The actual data of the collection (e.g. the items) is not present e.g. in the JSON representation of that resource.

[pvretano]

@jerstlouis One person's metadata is another person's data! From the perspective of the /collections/{collectionId}/items resource the content of the /collections/{collectionId} resource is metadata but from the perspective of the /collections/{collectionId} resource itself, it is the data ... or as @cportele says it is "the collection".

[jerstlouis]

@pvretano That is true in general, but I believe we can objectively say that when we deal with a vector dataset, the vector features are the data, and the 'collection' resource contains metadata about those features, some of which being specifically the kind of key information described within ISO 19115 (e.g. spatio-temporal extent).
What the specification is trying to say is that the collection resource contains such information about the geospatial data within that collection (metadata in relation to the features themselves, but even in relation to the collection of features... the extent is that of the whole collection, and it isn't itself the collection).

[dr-shorthair]

Is it (i) 'collection set' or 'list of collections', and (ii) 'collection description' that is intended?

[heidivanparys]

This issue has been created as part of the public review and is based on document 19-072. See in particular the Abstract and sections 9.2.1, 9.2.2, and 9.2.3.

* Use "Conformance declaration" instead of "Conformance classes" as the name of the resource at `/conformance`, which is more precise.

* Use "Collections" instead of "Collections metadata" for the resource at `/collections`. The resource is not metadata, it is the collection(s) themselves.

* Use "Collection" instead of "Collection Information" for the resource at `/collections/{collectionId}`. The resource is not metadata/information, it is the collection. Add the resource to the table in the abstract.

* Rename "Collection" in 9.2.3 to "Items" or remove the section; if it is kept add it to the table in the abstract.

When following this proposal, the naming would be similar to the table and heading OGC API - Features (that were adjusted after the discussion in opengeospatial/ogcapi-features#217 ):

[cmheazel]

@heidivanparys I agree on the use on the use of "conformance declaration"

[cmheazel]

The terminology used in API-Features has led us to frequently talk past each other. There are three resource types in play:

• collections: a collection of collections
• collection: information about a collection of resources
• collection: the collection of resources

This is particularly evident when discussing coverages:
/collections = a set of metadata about each of the coverages
/collections/{collectionId} = metadata about a specific coverage
/collections/{collectionId}/{*} = the coverage itself
The terms used to identify these concepts must be clear, even over a poor connection. The terms used in API-Common were selected with this objective in mind.

[dblodgett-usgs]

I think we have what we need now to tease this apart. Specifically, since we are saying:

A (OGC-API) Collection is:
"A geospatial data resource that may be available as one or more sub-resource distributions that conform to one or more OGC API standards."

Re: the semantics of "is the resource a resource or what you get when you dereference it?" I think it's clear that we need to treat a resource as a resource and NOT what you get. But in general, when we refer to "a collection" we should maybe be more precise and say "a collection of data" or a "collection of ..."

/collections = a set of metadata about a collection of geospatial* data
/collections/{collectionId} = metadata about a specific collection of geospatial* data with links to distribution
/collections/{collectionId}/{} = a specific distribution of geospatial data

• noting that we are probably going to remain open to non-geospatial collections of data but most will be geospatial.

[joanma747]

Change conformance classes by conformance declaration in the name of the resource in table 1 and in the schema title (not need to change the URI) and remove the "core tag". Agreed on 2020-09-28 telecon.

[cmheazel]

Corrected in Core 9/28/20

[cmheazel]

As of the March 16 Pull Request:
/collections = Information which describes the set of supported Collections
/collections/{collectionId} = Information about a specific collection of geospatial data with links to distribution
/collections/{collectionId}/items = A specific distribution of geospatial data

[jerstlouis]

@cmheazel the set of available Collections instead of supported?

Supported might make someone think collection IDs are standardized somewhere.

[cmheazel]

Changed supported to available.