OGC-API: Where to put the links to metadata of network services and the dataset

[PB-GNM]

Addressed TG

Technical Guidance for the implementation of INSPIRE Network Services

Issue faced

When implementing OGC-API-Services of different types on one landing page, It is unclear where to put the links to existing metadata of the services and the dataset.

This question was also asked at #23.
Is has led to an answer in #30 for the link to the dataset metadata but not for the link to the metadata of the network services and only in the case of OGC-API-Features.
The answer for the link to metadata of the dataset was at collections level.

There are also situations where there are more OGC-API services types than just Features for one dataset.
For instance: https://api.pdok.nl/lv/bgt/ogc/v1/ has both Features and Tiles.
Tiles don't use collections, so the dataprovider chose to set the links at the landingpage.
See also the three links at the bottom of https://api.pdok.nl/lv/bgt/ogc/v1/?f=json. One for the dataset, two for the Services (Tiles and Features).

What is the opinion on this approach?

Additional information

Linked issue

#23.
#92

References

Setting up an INSPIRE Download service based on the OGC API-Features standard. INSPIRE-MIF. V1.0. URL: https://github.com/INSPIRE-MIF/gp-ogc-api-features/blob/master/spec/oapif-inspire-download.md

[sMorrone]

@PB-GNM
the issue tracker of the techical-guidelines repository should only be used to submit and discuss change proposals to the TGs.
The Good Practice Issues should be opened in the dedicated repositories. Therefore I am moving this issue to the gp-ogc-api-features repository.

[armin11]

Hello together, in Germany we are also discussing this topic. The decision has not yet been made, but one option will be, that we use the same solution as for the OWS Capabilities-Documents and the INSPIRE ATOM-Feeds. The service metadata is linked at service-level and the dataset metadata at content level (e.g. layer/featuretype/coverage/...). In case of OAF this would lead to a solution similar to that, what we implemented here:

https://www.geoportal.rlp.de/spatial-objects/519/collections?f=json

We should use the option to define more than one link at content level ;-)