Link relation types

[cportele]

See opengeospatial/ogcapi-common#76.

Since this is mainly a general OGC API topic, please add general discussion in the OGC API Common issue and not here.

This issue is mainly a placeholder for now. Once we have an agreement on the approach for new link relation types in OGC API standards, we can discuss here how we handle our three new link relation types in Core.

If the result is a name change for "conformance", "items" and/or "data", we could deprecate these types in a new version, require using of the new types, but still require for compatibility with existing clients that servers would also create duplicate links with the deprecated types.

[cportele]

Motion passed by the OGC Naming Authority (OGC-NA):

The OGC-NA recommends the establishment of the following guidelines and rules for the governance of link relations.

• Reuse existing link relation types registered with IANA wherever appropriate.
• If an OGC specific relation type is needed, it will be prefixed with an “ogc-”
• The OGC-NA will work with IANA to find a way to register these link relation types in the IANA register.

Impact on Features Core: Keep "conformance", "items" and "data" for backwards compatibility. Add the new link relation types prefixed with "ogc-" once the issue in OGC API Common has been resolved.

[cportele]

New OGC link relation types will be registered with the OGC-NA under http://www.opengis.net/def/rel.

• For backward compatibility, data, items and conformance will continue to be required for all OGC API Features implementations.
• Add recommendations to also provide http://www.opengis.net/def/rel/OGC/1.0/data, http://www.opengis.net/def/rel/OGC/1.0/items, http://www.opengis.net/def/rel/OGC/1.0/conformance.
• Mark data, items and conformance as deprecated.

This is related to #502.

[ghobona]

Correction: It should be http://www.opengis.net/def/rel and not https://www.opengis.net/def/rel

I see the 'Input Error' at http://www.opengis.net/def/rel/ and will fix it. We missed it during the recent upgrade.

[cportele]

Thanks @ghobona - I have corrected the URIs in my comment above.

[ghobona]

Thanks.

The register's URI has now also been fixed.

[pvretano]

A little late but I don't remember if we discussed this...
Shouldn't the link to the /collections/{collectionId}/items endpoint be indicated using the link relation search? The relationitem is reserved for pointing to individual items (i.e. features, records, whatever) of the collection which is why we changed the original item to items ... and also to alight with STAC I seem to recall because they were using item.

[cportele]

We did not really discuss this in the past. I considered it early and decided not to propose it, because the description in the (former) OpenSearch is quite closely tied to that spec. But the registered description isn't so with hindsight we should have used that instead of inventing our "items" link relation type.

But if we have to switch from "items" to something else anyhow, we could also switch to "search" instead of "http://www.opengis.net/def/rel/ogc/1.0/items".

[pvretano]

@cportele that would be my vote ... just to play kosher with IANA! ;)

[cportele]

Meeting 2021-08-02: Keep this open for decision for 1.1.0. Also wait for what is happening with Common.

On the use of item: Currently there is no need for use in the context of OGC API Features, but Records may need it to reference the records from a static catalog/collection.