2022-06-08 ET-W2AT Meeting

1. Opening

Rémy Giraud

Rémy welcomed Mark Burgoyne and Antje Kerstin SCHREMMER, and informed the key achievements of ET-W2AT:

• design of the foundation of WIS 2.0 architecture

• the reference implementation “WIS2 in a box”: We have version 0.X and we plan to have the version 1.0 by the end of 2022

He reminded the purpose of the meeting and emphasized the importance of this meeting for the preparation of the document for next INFCOM, and the plan of the work for next months

2. Discussion

All

Tom> provided he information on the last meeting on WIS2 box: functions, pub-sub capabilities, download services, option capabilities…

Rémy>The goals of WIS2 box are:

1. The reference implementation

2. provide a “Turn-key” or “Swiss knife” for small countries

Tom> It’s a Docker based solution with a very lower barrier

Enrico> We have already some implementation of WIS2 box. Need to decide on the features what is core and recommended. The APIs is some thing what we need to have as recommendation. Need to clarify that to avoid the features not aligned with WIS2 architecture

Tom>Need also to specify which APIs we are talking about

Rémy> We are building the foundation of WIS2. What we are discussing here is finishing works. I think the APIs is the 4th floor works

Tom> We need to consider the APIs as it’s the case of the data formats and provide some specification

Rémy>Need to be clear when we communicate WIS2 to other programmes. To add the APIs it will be very complicated

Jeremy> Are we talking specifically about the data sharing API

Tom> yes, trough the web

Jeremy> A web based data sharing API. Remy said: in WIS2 haven’t made any specification around these APIs and will not do it this year and may do it in the future. What I propose is just to say that it should be web based to be aligned with the principles and also should be a self describing and use the openAPI version 3.1 to discover and understand without any need for additional documentation Agreed

Tom> That does mean that we are exposing OpenAPI? If it’s the case we can talk about OpenAPI 3.X. There a number running the first generation OGC web service implementation including us, there others running ERDAPs everywhere. If we specify the OpenAPI that means that folks have to do some upgrades

Jeremy>the OGC web services are not self describing, you have to read the manual first. In terms of ERDAP they are leveraging OPeNDAP. If we specify only the OpenAPI it can include OGC

Tom> Yes if specify OpenAPI without saying OGC API is an umbrella ?

Jeremy> As Remy says, we start from the browed foundations and we are building layers on top. We said web based first and we specify the OpenAPI version 3.x and then OGC API and may be some particular specifications

Kai> I agree with your suggestion

Mark>If we are talking about making self documenting, need to explain how to interface with these APIs

Antje>is there any documentation for the core functions? Need to decide on the minimum functions for the APIs on the box and how they are separate the different containers. It’s good to start with a small core functions and to grow in the future

Jeremy> The core functions are defined by the development team and today we are talking of a new one related to the APIs

Remy> The core features are: publishing, subscribing and downloading

and nothing else. We have two actions with the team and Mark and Antje: 1. work on the foundation to make sure that they are solid to the need of the year 2. the shining part as it’s the case in Malawi project. The APIs are not in the same level as the shinning part. If we need to add the APIs as a part of WIS2 we need to be precise as we have done for the message structure

Tom> we are talking about the tree core functions: publish, subscribe and download. the API can be a part of publishing (publishing to an API). If we take the proposal from Jeremy building blocs we can provide some overarching guidance and in overtime will see how that evolves

Kai> question: which API we are talking about?

Tom> It’s Web API for dissemination of the data

Kai> In this case we allow also the box to download data using the web services or API…

Tom> It could be a future capability

Remy> If we say that the information is available through an API, we need to have a detailed description of the APIs

Tom> If we follow the standards, no need for detailed information. I like the Jeremy’s proposal we start browed and overtime will evolve

Kai> If a user needs to access data, the first thing to do is to visit the catalogue and discover data. These metadata will inform about the API and which standards …. If the user doesn’t understand the API it’s not a problem of WIS2

Remy> referring to some discussion we had with Hydrology, it’s not so easy to understand the WIS2 compliance. If we add the APIs it will be more complicated.

Jeremy> If we talk about the real time data, you have the URL link in the GeoJSON messages to get the data. The URL is pointing to a file on the disc. If you are publishing data through interactive API, you can steel publish a data availability message with a URL link pointing to a server taking the request and provide you the information requested.

Tom> Agree, links are opaque in that way, You can access data as you access a file. We will use this for metadata. If you can’t access via the web services you have the link to access to file on the Disk

Remy> It will be an issue If we don’t specify the API structure. If we need to have the API as part of the foundation we need to specify the API structure

Jeremy> I don’t think that WMO is ready to specify a particular API for NWP exchange. what we suggest is to start to provide these kind of services and get feedback and see how it works by providing some web services today

Antje> In my perspective, we need to provide also in addition to the file access for core data, access through the API as a minimum service

Jeremy> Good point for core data access via a simple link

Remy> We can call it as a endpoint

Tom> Let’s talk about a link providing a direct access to the data which not required no further interaction Agreed

Remy> the way to implement that as a data producer may be through web accessible folder, or a web server or an API

Tom> provide some examples:

i.e. opaque link, a GeoJSON coming from an API https://api.weather.gc.ca/collections/swob-realtime/items/2022-05-10-0010-CAVA-AUTO-minute-swob.xml?f=json

vs. the API itself of the dataset: https://api.weather.gc.ca/collections/swob-realtime/

Tom> direct access with no further interaction

Enrico>at the moment we have the WIS2 principles indicating the use of API in WIS2. If we narrow down a bit some lines on top of that justifying that we have the API in the box it will be a step forward

Jeremy> we talked about tree things:

1. on the Web

2. need to be self describing with a strong recommendation for openAPI

3. provide an opaque URL for core data no requiring any further knowledge

Jeremy> in terms of how we move forward from here, we have the WIS2 in a box implementation, and because it build on OGC API you can publish data from a web service endpoint OGC API feature. We can begin deploying some WIS2 box publishing notification messages and pointing to an interactive API endpoint rather than creating predefined files and pushing them on Disk, and see how people using them

Tom> agree, It’s an option in the box

Remy>Publish the link for an API is not an AIP. If we will provide the API services without giving the full picture it can be ambiguity

Tom> We can provide a recommendation, If you provide API you shall provide some minimum requirements. We need to provide the API because users are always asking about it

Remy> the question is how not provide more details but also not have few description. I think to focus more on the foundations publish, subscribe and download and as perspective we show that we are working with communities to provides some web services

Jeremy>publish, subscribe and download is WIS2 compliance. The WMO programmes may choose to develop more specific APIs to meet their needs, We can begin providing some examples what could practice looks like to encourage them in the right direction

Tom> In term of publishing we need to specify also through the API

Remy> No, what we are publishing is the data. The way you implement that is the choice of the center. This is what we can have on the manual. We can have a separate document “technical guidance” or on the guide to WIS we can have a chapter for the API

Jeremy> Why not to have in the manual or in the guide a box saying that you may implement a opaque URL to access the data in a number ways: predefined file on the Disk, Web Accessible Folder and interactive API

Enrico> We are going to write the manual. It will be short, simple and consolidated. The guide will not writing it now, we don’t have time. We are writing some guidance, to be simple and this guidance we may use this document to develop simple and flexible description to not be dramatically change in the future for the API Agree