'conformance' relation type in OGC API - Coverages Landing Page

[ghobona]

Requirement 14 B of OGC API - Common says.

The content of that response SHALL be based upon the schema landingPage.json and include links to the following resources:

• /api (relation type 'service-desc' or 'service-doc')
• /conformance (relation type 'http://www.opengis.net/def/rel/ogc/1.0/conformance')

However, the Landing Page response example in Clause 7.3.1.2 of OGC API - Common - Part 1 shows the relation type as 'conformance'.

@cmheazel @jerstlouis Does the Landing Page response example in OGC API - Coverages need to be updated OR is the typo in OGC API - Common?

[jerstlouis]

@ghobona The examples in https://docs.opengeospatial.org/DRAFTS/19-087.html#_response should be updated to use the full URIs, since they are not IANA-registered (for data as well).

Unless the on-going discussion related to CRS in https://github.com/opengeospatial/NamingAuthority/issues/92 / https://github.com/opengeospatial/NamingAuthority/pull/119 has an impact in also allowing short-form link relation types?

The issue with short forms is that now clients would ten have to string-compare against multiple versions, and therefore couldn't use e.g. a mapping lookup...

[jerstlouis]

Fixed in https://github.com/opengeospatial/ogcapi-coverages/blob/master/standard/examples/JSON/landingPage_example.json

[ghobona]

https://github.com/opengeospatial/NamingAuthority/issues/92 should not have an impact on Link Relation Types, because it is specifically about CRS.

Thanks for fixing landingPage_example.json

[jerstlouis]

@ghobona but the recent discussion was precisely that we should not have a special policy for CRS but a general solution.

[ghobona]

@jerstlouis You are right. The recent discussion has included suggestions to expand the policy to offer a general solution.

[cportele]

I do not see how this could work for link relation types. RFC 8288 is clear that any non-registered link relation type must be a URI.

Applications that don't wish to register a relation type can use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type.

[ghobona]

@cportele That's great! Given that any non-registered link relation type must be a URI, that means that OGC API - Coverages should be using http://www.opengis.net/def/rel/ogc/1.0/conformance

@jerstlouis I think this addresses the Issue. Do you agree?

[jerstlouis]

@cportele You are right. I'm not sure what this means for a "general solution" to short forms of URI when a context is known. Maybe it's just that in this case the context is not known (the OGC scope not being implied by default)?

But even the possibility to have either a short or long form complicates the process of identifying these URIs, having to first detect whether they should be expanded before comparison.

[jerstlouis]

@ghobona I agree about the relation type, I'm just wondering what https://github.com/opengeospatial/NamingAuthority/issues/92 means for where other kinds of URIs are expected where we have a known context (e.g. CRS, TileMatrixSets, data records semantic definitions, etc.), where we could decide that a short form is valid.

[cportele]

I just had a look at the wording in the PR and the whole notion of "shortened form of a URI" is unclear at best. It seems to imply that the shortened form is a URI, too, and can be used in its place. But that is not the case.

That said, I think that we can define a better solution, at least in those cases where OGC controls the resources in which the URI is used. I am writing a comment in the PR with a proposal. Let's continue to discuss this when I am done.

[cportele]

@jerstlouis @ghobona - have a look at https://github.com/opengeospatial/NamingAuthority/pull/119#issuecomment-885577694 and let me know what you think.

[jerstlouis]

SWG 2022-03-30: This has already been applied.