The current MetOcean EDR Profile draft has two Requirements classes:
The Core Requirements class depends on the two mandatory OGC API EDR Core requirements classes: Core and Collections. It also contains additional requirements and recommendations, including additional requirements/restrictions related to the OGC API EDR Core Collections Requirements class, but also requirements related to other OGC API EDR Core Requirements classes, such as OpenAPI and Queries.
It seems a bit confusing to me to add requirements restricting the OGC API EDR Core Queries Requirements class to the MetOcean EDR Profile Core without adding dependency to the OGC API EDR Core Queries Requirements class. I'm assuming that the intention is that a compliant MetOcean EDR Profile Core implementation does not have to be compliant with all the requirements in the OGC API EDR Core Queries Requirements class, which is fine. However, by adding requirements like the "Collection radius data query" (/req/core/collection_radius_data_query) in Core without requiring conformance with the OGC EDR API radius data query (http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/queries/radius) seems odd.
One solution I see for clearing things up would be mimicking the OGC API EDR Requirements class structure in the MetOcean EDR Profile for the relevant Requirements classes, and cherry-picking OGC API EDR Requirements from those Requirements classes that we want to require from MetOcean EDR Profile implementations (if not all). Additionally we would add some MetOcean EDR Profile specific requirements in those Requirements classes. In case we still want to mandate all of these "MetOcean EDR Profile common" requirements for all MetOcean EDR Profile implementations, we would have to include a clause like the "2.1. Mandatory Requirements Classes" in the OGC API EDR, stating all the requirements classes that have to implemented.
So the Requirements class structure of the MetOcean EDR Profile could be something like this:
- MetOcean EDR Profile - Core
- MetOcean EDR Profile - Collections
- Dependency: OGC API EDR - Core / Collections (http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections)
- Requirement 2 /req/collections/collection_identifier
- Requirement 3 /req/collections/collection_title
- Requirement 4 /req/collections/collection_license
- Requirement 5 /req/collections/collection_temporal_extent
- Requirement 6 /req/collections/collection_spatial_extent
- Recommendation 2 /rec/collections/collection_vertical_extent
- Requirement 7 /req/collections/collection_parameter_names
- MetOcean EDR Profile - Basic Queries
- MetOcean EDR Profile - Insitu observations
- Dependency: OGC API EDR Core / Area Queries (http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/edr/rc-area
- Dependency: MetOcean EDR Profile - Core
- Dependency: MetOcean EDR Profile - Collections
- Dependency: MetOcean EDR Profile - Basic Queries
- Requirement 12 /req/insitu-observations/collection_parameter_names
- Requirement 13 /req/insitu-observations/collection_custom_dimensions
- Requirement 14 /req/insitu-observations/data_query_response_format
- Requirement 15 /req/insitu-observations/coveragejson_parameters
- Requirement 16 /req/insitu-observations/coveragejson_referencing
The current MetOcean EDR Profile draft has two Requirements classes:
The Core Requirements class depends on the two mandatory OGC API EDR Core requirements classes: Core and Collections. It also contains additional requirements and recommendations, including additional requirements/restrictions related to the OGC API EDR Core Collections Requirements class, but also requirements related to other OGC API EDR Core Requirements classes, such as OpenAPI and Queries.
It seems a bit confusing to me to add requirements restricting the OGC API EDR Core Queries Requirements class to the MetOcean EDR Profile Core without adding dependency to the OGC API EDR Core Queries Requirements class. I'm assuming that the intention is that a compliant MetOcean EDR Profile Core implementation does not have to be compliant with all the requirements in the OGC API EDR Core Queries Requirements class, which is fine. However, by adding requirements like the "Collection radius data query" (/req/core/collection_radius_data_query) in Core without requiring conformance with the OGC EDR API radius data query (http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/queries/radius) seems odd.
One solution I see for clearing things up would be mimicking the OGC API EDR Requirements class structure in the MetOcean EDR Profile for the relevant Requirements classes, and cherry-picking OGC API EDR Requirements from those Requirements classes that we want to require from MetOcean EDR Profile implementations (if not all). Additionally we would add some MetOcean EDR Profile specific requirements in those Requirements classes. In case we still want to mandate all of these "MetOcean EDR Profile common" requirements for all MetOcean EDR Profile implementations, we would have to include a clause like the "2.1. Mandatory Requirements Classes" in the OGC API EDR, stating all the requirements classes that have to implemented.
So the Requirements class structure of the MetOcean EDR Profile could be something like this: