Fix path? (before was: "Identifying")

[cmheazel]

API-Common identifies resources by the path to that resource (e.g. /api, /collections, etc.). This approach implies that the resources exposed though an OGC Web API must be organized according to the paths. However, we are dealing with a modular architecture. A modular architecture is incompatible with a fixed resource hierarchy. The result has been many long and circuitous discussions with no resolution.

Is there a better way?

Note that we do not have this problem with hypermedia associations. The underlying architecture appears to be sound. The issue lies in how we identify our resources.

[KathiSchleidt]

A related but relevant issues pertains to 2 (or more) different APIs providing data on the same real-world object (what SELFIE is trying to sort), but also 2 different APIs We're currently chewing on the conundrum of how to sanely provide the same spatial feature both as OGC API - Features (for normal Geo-Folks) AND via SensorThings (as we have measurements on this feature). We're currently experimenting with the approach of providing a neutral URL for the spatial object that returns a JSON document with links to all known implementations

[rob-metalinkage]

@KathiSchleidt this is a "solved problem" already implemented in the OGC definitions server for the same reasons.

you can review the implementation here (styling yet to be applied to this page - but should be functional)

https://defs-dev.opengis.net/def/schema/hy_features/hyf?_profile=alt

all these resources can be accessed via content negotiation from the URI base

see https://www.ogc.org/def-server for more details

As soon as I complete a couple of styling and testing processes we will ask for review - but this is the plan for delivering metadata according to multiple views and APIs, and applies equally to data.

note that a canonical form for the list of options (equivalent to a getcapabilities for a URI) is pretty much all that is being enforced here, however we will also maintain a register of useful profiles (descriptions of resources) that can be specialised.

I suggest proposing a "observations" profile for any set of observations on a feature, and maybe a few specialisations of this for common types - locus, timeseries, samples - these can be registered in the definitions server if some WG proposes, and can be linked to a range of resources for profile conformance.

(ps i have started a tool for automating some aspects of this publication process - see https://github.com/RDFLib/profilewiz

currently extracts "actual profile" constraints from a typical "cut and paste and hack" approach to modelling profiles and generates JSON-LD contexts. SHACL, profile declaration, JSON-schema and HTML documentation outputs on the radar. this is under active development as I explore best practices for data modelling - thinking how to apply to API definition processes would be a great next step.

[cmheazel]

Related issues: #71, #74 and #60

[joanma747]

The "required" paths for "conformance" and "/" and the optional /api was already discussed and agreed We believe this makes the live of the client developers easier.

We removed the [core] tag because it seems to affect more the future extensions.

[cmheazel]

This is an issue that will not die. I do not see this as a standards issue (but it may be a policy issue). Since there is a resolution, let's write it up in the API-Common Users Guide. Then we can argue about what is in the Users Guide, and the standards can move forward.

[jerstlouis]

Each OGC API standard can decide, for each individual resource, whether a particular path is required or only discoverable through links and the API definition.

This should be the guiding principle. Can we close this issue as resolved?

It is more of a policy / guidance issue for the SWGs than something that we need to state in the Common standard documents (or even the guide targeting the users).