Provide policy on OGC API naming

[ghobona]

There have been multiple requests for OGC-NA to provide policy on the naming of OGC API standards, repositories etc.

opengeospatial/ogcapi-coverages#68

opengeospatial/ogcapi-coverages#64 (comment)

[cportele]

@ghobona - A couple of comments:

• Should we also add (straightforward) rules how resources are named and structures in the OGC schema repository under http://schemas.opengis.net/ogcapi/?
• For the requirements classes etc. it would be clearer, if the full URI template would be shown. E.g. http://www.opengis.net/spec/ogcapi-{resourceName}-{n}/{v}/req/{reqClass} for the requirements class or http://www.opengis.net/spec/ogcapi-{resourceName}-{n}/{v}/req/{reqClass}/{req} for a requirement.
• I don't think the 'paths to resources' is in scope of the naming authority. If the syntax of URIs in the API is constrained, that has to be done by an OGC API standard, not the NA policy. The NA policy should guide spec development, not put any additional requirements on implementations. In addition, it is also unclear to me, why the specific rule would be needed in the first place; there is no concept of qualified names in the OGC API standards, so what are qualified names in OGC API standards? Finally, let me also point out that the Features API SWG discussed lexical restrictions like these and decided against them, see Lexical restrictions on names/ids used in the URI path? ogcapi-features#156.

[ghobona]

From Scott (paraphrased).

The formal abbreviation pattern should also be added. For example, the convention having the least opposition last year was “OAResource” such as OAFeat, OAMap, OARecord, etc.

[ghobona]

@cportele Thanks for the feedback.

Regarding, the section on 'paths to resources', it is intended to address the issue opengeospatial/ogcapi-coverages#19 (comment)

It's possible that the solution I have put forward is not ideal. So alternative ideas of how to address opengeospatial/ogcapi-coverages#19 (comment) are welcome.

[cportele]

@ghobona - I do not understand why a special rule for colons is required? Colons are perfectly fine in path segments (except in relative URIs in the first segment). I would consider the coverages issue a non-issue. Or what am I missing?

In any case, even if such a restriction would be needed or desirable, it does not belong into the policy, but an OGC API standard. The "standardization target" for the policy is API standards, not APIs.

[ghobona]

@pebau @Schpidi

We have prepared a policy proposal for addressing opengeospatial/ogcapi-coverages#19 (comment) through the approach described under "Paths to resources" at 1a5be6f#diff-66baff1307e0290d79f5a14ff0bc5b84R59

Please see the comment above (#55 (comment)).

Could you please provide some clarification as @cportele has requested above?

[ghobona]

@cportele @pebau @Schpidi

Thinking about this further. I think @cportele is correct.

I have gone through the OGC-NA charter and the scope focuses on the assignment, registration and management of persistent URNs and URIs in the www.opengis.net domain.

Since the implementations of OGC APIs would not be in this domain, they would be outside of the remit of the OGC-NA.

So my recommendation during the OGC-NA session on Friday 19 June, will be that any restrictions on identifiers or paths to resources be designed and applied by the individual OGC API standards.

[rob-metalinkage]

removed original comment .. was referring to the issue of schema repo structure whereas the discussion seems to be focussed on resources in implementations now.

[ghobona]

2020-06-17 OGC API - Common SWG requested discussion of opengeospatial/ogcapi-common#42

[ghobona]

The TC and PC have approved the policy.