Follow up comments from Jeremy

[mortenwh]

On 9th June, to Morten:

Thanks for the session today. Here are those additional comments I promised. And a few more points that we didn’t have time to cover.

Jeremy

2.1.2 Landscape Diagram

• "WIS2.0 Shared Services" should be "WIS2.0 Global Services"
• WIS 2.0 Message Broker is considered to be part of FEMDI
• FEMDI Shared Catalogue may be an instance of the WIS2.0 Global Discovery Catalogue for European region
• WIS 2.0 doesn't provide "BUFR to GTS forwarding" as a shared service; WIS 2.0 will retrieve resources (e.g., BUFR files) from a WIS2 Node (aka. FEMDI "Data Supply Capability" -- which is the "E-SOH Local Instance") and re-publish them via the WIS2.0 Global Cache. FEMDI does not use the WIS2.0 Global Cache.
• "All local E-SOH instances get data from Observation collection systems and metadata from Oscar" -- worth distinguishing between discovery metadata (for finding the dataset and associated data access mechanisms) which is managed in WIS2.0/FEMDI and the station metadata which is managed in OSCAR Surface. For reference, WMO INFCOM Expert Teams are determining where the master copy of metadata elements will be held (e.g., WIS2 or OSCAR) with intent to remove double-management of the same metadata.

3.2.1 Metadata specification

• Controlled vocabularies from ACDD and CF-conventions are a reasonable choice.
• However, these terms are not standalone. To support data discovery, they need to be presented in a structured record. My recommendation is to use OGC-API Records structure (and possibly the API too) for this. This is what WIS2.0 and FEMDI have specified. OGC-API Records derives from DCAT2 and can trace roots to ISO19115. … (Section Create C4 landscape diagram (federated model) #4.2.2 OGC-API Records discusses this further but does not make a clear recommendation on its use)
• Although OGC-API Records is inferred as the choice, the doc doesn’t clearly communicate that
• CC-BY-4.0 is a good choice for license.

3.2.5 MQTT message payload

• "the WIS2 Notification Message Encoding. The standard is an extension of the OGC API - Features standard" -- I think it’s better to say the WIS2 notification message encoding is a profile (i.e., extension) of GeoJSON. … (Note: GeoJSON is used extensively in OGC-API Features)

4.1.1 GTS

• "If we are using WIS2, which has a gateway to GTS, do we need to concern about GTS anymore?" -- I think not. Probably. WIS2 will provide a WIS2 to GTS gateway. Design of the gateway is work in progress. At time of writing, the design requires the TTAAii header to be included in the WIS2 notification message enabling the gateway to correctly republish onto GTS without needing to analyse the data content.
• You will also need to encode the data using the appropriate BUFR template.
• Note that both GeoJSON and BUFR encoded data could be provided in parallel.
• I say probably because. The WIS2 to GTS gateway will only publish content that has a TTAAii header. After 2024 new TTAAii headers won't be allocated. This is to encourage the community to move to WIS2.0. Summary: old data will still be available on GTS, new data won't. Will the E-SOH datasets have TTAAii headers???

4.3 API Authentication and Authorization

"For API Authentication and Authorization E-SOH will be relying on the FEMDI implementation. FEMDI will implement these techniques on later iterations." -- Noted. FEMDI API Gateway will provide:

• Anonymous usage (with user 'fingerprinting' as a basis to enforce fair usage policies)
• Authenticated usage (e.g., using an API key) -- this may provide an enhanced QoS compared with Anonymous usage
• Authorized usage -- authenticated users who validated as belonging to specific categories (e.g., NMHS, safety critical service provider, research/non-commercial user); they must accept additional T&Cs at time of registration and may be subject to out-of-band verification

4.4 API Rate Limiting and Throttling

• FEMDI Gateway will provide this functionality

5.3 Auditing and Logging

• WIS2.0 will be using OpenMetrics https://openmetrics.io/ -- this should be suitable for E-SOH and provides ready integration with many open-source and commercial components.