Relation type to link to an OGC API - Processes instance

[m-mohr]

For #428 we'd like to link to an OGC API - Processes instance, i.e. it's landing page from an external context (e.g. openEO).
Could we define a standardized relation type that allows us to do so?

Something similar to http://www.opengis.net/def/rel/ogc/1.0/processes, but not specifically linking to the processes (because we need to read the conformance classes etc. first).

[pvretano]

@m-mhor the landing page is not specific to processes but can contain information about any number of OGC endpoints. I think the most appropriate rel would probably be service since what you are getting with the landing page is a service description document.

[m-mohr]

Yes, but it's similar to difference as between application/json and application/geo+json. Everything is JSON, but sometimes it's good to know in advance whether a link is expected to comply to certain requirements (e.g. GeoJSON in the example, or as in my request above: OGC API - Processes). Thus my request. A generic service is not very helpful for us.

We can of course define our own if OGC doesn't provide one (fine for us), but then don't complain later that we did our own thing and are not "OGC compliant" ;-) I guess we'd go with rel: ogcapi-processes then...

[pvretano]

19-AUG-2024 SWG meeting: To link directly to the processes endpoint (i.e. /processes) the rel would be http://www.opengis.net/def/rel/ogc/1.0/processes or as a CURIE [ogc-rel:processes]. However, this kinda bypasses the conformance section so you may need to link back to that to get that information. Since we have a fixed path (i.e. /processes) simply removing the "processes" part of the path gets you to the landing page if you need the conformance information.

There are a couple of issues ...

1. The casing of the CURRIE is not clear. Some OGC standard using upper case (e.g. [OGC:CRS84]) others use lower case so we need to get clarity on this point.
2. There is a question of whether CURIEs and URIs can be used interchangeably and whether that needs to be explicitly stated in the standard.

[m-mohr]

To link directly to the processes endpoint (i.e. /processes) the rel would be http://www.opengis.net/def/rel/ogc/1.0/processes or as a CURIE [ogc-rel:processes]. However, this kinda bypasses the conformance section so you may need to link back to that to get that information. Since we have a fixed path (i.e. /processes) simply removing the "processes" part of the path gets you to the landing page if you need the conformance information.

So that's the official way recommended by the standard? Will this be mentioned in the standard or do we need to point to this issue comment from other standards/specifications? Thanks.

[pvretano]

@m-mohr I think it is already in the specification since that is how you link from the landing page to the processes endpoint but I will verify and update if necessary.

[m-mohr]

I don't refer to linking from landing page -> processes endpoint. I'm asking for documentation how to link to a landing page. If the official way is to link to processes, then cut /processes from the path, then request that URL, extract the conformance link, request the conformance URL to make another request (i.e. 3 requests in sequence just to get conformance classes), this should be documented. I guess I could also just replace /processes with /conformance, but that all feels rather hacky to me. Having that said, I think the solution is not good due to the reasons above.

[fmigneault]

There is a http://www.opengis.net/def/rel/ogc/1.0/conformance in the registry. Couldn't this be simply listed in the links as well? OGC API - Processes standard would only need to add it to the list of required links to return by the /processes response.

[m-mohr]

Why make it all so difficult? Why not just define a relation type to link to the landing page of an OGC API - Processes?

[jerstlouis]

@m-mohr There is not really such a concept of a "landing page of an OGC API - Processes", because an OGC API landing page can offer processing capabilities and/or data access through various OGC APIs like Coverages, Features, Tiles... and/or additional APIs capabilities like OGC API - Routes routing calculations (which could also be considered processing and be implemented as such, but also have its own dedicated /routes which does not depends on Processes).

So I feel these are the two options:

• Have a generic service link to an OGC API landing page, which is self-describing through the links it provides and their own link relations + their conformance page that details everything it supports
• Link directly to /processes (using the same [ogc-rel:processes] link relation as from landing page -> /processes), optionally also linking to the landing page and/or conformance

Is that external context (openEO) actually part of the same API? If there are no conflicting resource end-points / methods then there could also be the possibility to share the same landing page.

[fmigneault]

This part of the standard (https://docs.ogc.org/is/18-062r2/18-062r2.html#sc_landing_page) list explicitly a landing page requirement, and the need to report links with relation types service-desc or service-doc, the http://www.opengis.net/def/rel/ogc/1.0/conformance and the http://www.opengis.net/def/rel/ogc/1.0/processes.

It seems logical to me that service should be added to https://docs.ogc.org/is/18-062r2/18-062r2.html#toc14 to indicate the relation type to use for the landing page URI. Additional recommendations could be added to some critical endpoints (/processes, etc.) to return this service link, but not necessarily a requirement.

The only drawback with service is when this link is used outside the context of OGC APIs, to point at their landing page. It can somewhat lose its meaning (or even be conflicting) when referenced by another service.