Instances links with same "rel": "data" differing only by href?

[jerstlouis]

In the D.5. Instance Metadata Examples, the links array for the instances all have "rel": "data" and differ only by the href value. This does not support well the OGC API follow the links approach where the hrefs are supposed to be opaque (i.e. a client should not look and check whether the href ends with /position rather than /radius).

Couldn't there be a single link to the instance instead? The "data_queries" already provides a link to the individual queries (though some are templated).

Also note that there were previously strong arguments against extending OGC API links with additional properties so as to maximize compatibility with clients, and there is a lot of stuff inside "variables" (itself inside the data_queries links), couldn't that have been directly outside of the "link"? Especially since the link is singular, it seems that this would have worked just as well.

[m-burgoyne]

If this was implemented I suggest that we do the same at the collections level and only have links to /collections and /collections/{collectionid}/instances in the links array.

[chris-little]

EDR API SWG 69 agreed to the change and @m-burgoyne would add to the V1.0.1 PR

[chris-little]

Fixed by PR#349

[tomkralidis]

FYI this topic came up during the May 2022 OGC Space Partitions Code Sprint, i.e. being able to detect link relations in EDR. What would be valuable here is to define more explicit link relations in EDR. Example of this approach via OGC API - Coverages:

        {
            "type": "application/json",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-domainset",
            "title": "Coverage domain set of collection in JSON",
            "href": "https://example.org/collections/gdps-temperature/coverage/domainset?f=json"
        },
        {
            "type": "application/json",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-rangetype",
            "title": "Coverage range type of collection in JSON",
            "href": "https://example.org/collections/gdps-temperature/coverage/rangetype?f=json"
        },
        {
            "type": "application/prs.coverage+json",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
            "title": "Coverage data",
            "href": "https://example.org/collections/gdps-temperature/coverage?f=json"
        },
        {
            "type": "application/x-grib2",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
            "title": "Coverage data as GRIB",
            "href": "https://example.org/collections/gdps-temperature/coverage?f=GRIB"
        }

So in EDR, we could expand the existing relation types more explicitly like:

        {
            "type": "application/json",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/edr-queries-locations",
            "title": "locations query for this collection as JSON",
            "href": "https://example.org/collections/edr-surface-weather-observations/locations?f=json"
        },

cc @jerstlouis @ghobona

[ghobona]

This issue was discussed and potentially resolved in the OGC API Common SWG session of the June 2022 OGC Member Meeting.

opengeospatial/ogcapi-common#310 (comment)

Outcome was:

• Action for Naming Authority - establish a way of checking that two different API Standards are not using a rel in a manner which is inconsistent with other API Standards.

[jerstlouis]

@ghobona In this particular case, there was also a problem localized within the spec itself.

A check that links in an array differ either by rel and/or by type would have been able to detect the problem.
The links differed only by href.

[chris-little]

@jerstlouis , @ghobona Within in the spec this was an error. @m-burgoyne is checking that it has been fixed. If not, it will be fixed in a PR.

[dblodgett-usgs]

Examples do not contain the offending links anymore as of #390 -- will close again assuming that #390 merges eventually.