(Note: This was previously posted in the API Common space in Agora, but it was probably a wrong forum, so reposting here rephrased as a discussion issue)

Has there been a previous discussion in some of the OGC API WGs on allowing statements of specification conformance at the OGC API collection level? With the API building block style pick-and-mix API specs and implementations I would see need to state that a particular resource collection within my API conforms to one or more specifications or conformance classes, while other collections within the same API do not.

My concrete use case:

When trying to come up with a suggestion for specifying OGC API endpoints for publishing the normative aviation meteorology observation, forecast and warning messages (METAR, TAF and SIGMET), I started to wonder if I could describe a set of requirements for dedicated OGC API collections for each of these message types, including particular semantics and temporal aspects for the collection items, as well as possibly a set of mandatory filtering operations and supported output formats.

I could certainly do this at the implementation level by leveraging collection description properties, but I would like to be able create a lightweight API specification, likely base on OGC API Features Core, that would contain Requirements/Conformance classes specifying the sets of specific requirements for the METAR, TAF and SIGMET resource collections, and nothing else. Then by declaring conformance to one of these Conformance classes (by using conformance URI reference) at API the implementation level, I could easily state that this collection (regardless of its collectionId) provides messages of particular kind (say TAF) with the well-specified semantics. Obviously the other collections provided by the same API would not have to have anything to do with the aviation or even meteorology. The conformance URI declaration within the individual Collection description, as well as as part of the collection descriptions inside the Collections resource of the entire API, would allow a simple way for client to distinguish these specific aviation message publishing endpoints from other collections.

I’m aware of (at least some of) the work done and in progress at OGC API EDR WG for supporting meteorological information, but for this particular need of predefined, identifiable weather information messages, profiling or extending the OGC API EDR seems using a sledge hammer to put a push pin on a map. It would seem much more natural to me to allow the implementers to publish these specific kind of resource collections as part of the APIs that feel most natural to them: Some might want to implement this with their existing EDR capable server and some a server just supporting API Features.

I do not see this kind of specification as a profile of any specific OGC API specification, but a specific kind of resource collection with guaranteed particular query mechanisms available.