Page Comparison

1

Review of actions from the last meetings

Hassan

Hassan summarized all the actions from the previous meetings on June 26 and September 4 and updated the progress on them.

• Notification mechanism on updated data

•  Action: (Hassan(to write an asciidoc describing why and how elements: wis2-guide/Notification-mechanism-updated-data.adoc at transition · wmo-im/wis2-guide · GitHub
•  Tom presented an alternative solution discussed in the WIS metadata task team using the relation link rather than the properties.
•  Tom will present more details and all to think about and the decision will be taken in a next meeting

• Clarify broker protocol elements

•  Action: (Remy): to check with VerneMQ for their advice to selecting the parameters: Mr André from VerneMQ presented the MQTT basics and QoS ET-W2AT meeting-20230904_150114-Meeting Recording.mp4 (sharepoint.com)
•  Action:(Peng): to discuss with EMQX experts for possible suggestions about the parameter’s selection
•  Remy summarize the presentation made in two weeks by the boss of VerneMQ.
•  an asciidoc to be prepared on the MQTT features
•  all are requested to view the presentation record to decide on that in the next meeting
•  the link of the presentation will be shared with the participants

• GTS to WIS2 Gateway

•  Action (Kenji) : JMA to check internally if JMA will provide the GTS2WIS2 Gateway
•  Action (Hassan): to develop an asciidoc: wis2-guide/GTS2WIS2-Gateway.adoc at transition · wmo-im/wis2-guide · GitHub
•  Tom propose to have this details on transition document not in guide to WIS
•  Tom informed that the GTS in WIS2 impact the MQTT Explorer (difficult to show all the topics)
•  Remy, dislike to change a decision made in a previous meeting except if there is a good reason of that. A limitation of a tool like MQTT Explorer is not a good reason
•  Kai, we need to consider the need of subscribing to everything under cache/a/ WIS2/# and if GTS should be a part of that or not
•   Remy, I don’t think that someone is subscribing to cache/a/wis2/#, and if it’s the case they will get the messages and then skip them
•  the decision is to keep this as we agreed in the previous meeting and include the gts properties in the asciidoc

• WIS2 to GTS Gateway

•  Action (Hassan): to develop asciidoc: wis2-guide/WIS2-to-GTS-Gateway.adoc at transition · wmo-im/wis2-guide · GitHub
•  Action (Secretariat) to identify some RTHs to run the gateway: Brazil, China and UK announce their intention to provide this gateway

discussion

• GTS to WIS2 Gateway

  • (Tom) it is good to keep this specification in the transition document, in the notification message specification document. MQTT explorer gets flooded by GTS to WIS2 gateway. Propose: to have a option , gts_to_wis2_gateway to be at higher level of topic hierarchy, e.g, in parallel to wis2 or higher

    • (Kai) gts_to_wis2_gateway can be set at any level as needed

    • (Rémy) Prefers the current proposal. When it is not possible to deal with the large amount of message notification by MQTT explorer, we need to consider changing the architecture.

    • Action: (Hassan) Merge GTS property and GTS to WIS2 Gateway provider jobs into one ascii doc as a transition document

• KPIS

  • Tom will share the experience for the metadata KPIs

2

"merging" country and centre-id into one unique name

All

Tom gave an overview of this topic discussed in TT-WISMD on proposal for adapting WTH to merge country and centre-id.

He presented the issues with the country as follow:

• ambiguous meaning/role

  • issuing centre? PR representation/member? location of data?

• ambiguous coupling / relationship of centres and countries (one to many)

• can create numerous permutations of topics

• increase the difficulty to find the datasets users are interested in as they first have to understand from which country and then centre it comes from. For instance, the country code for international organizations is really not obvious for non-knowledgeable users.

the proposal is to remove country and define the centre-id on reverse hostname notation (starting with TLD) into a single compound level. In other words, the citation authority based on the Internet domain name of the issuing centre.

Discussions raised about countries not having their proper domain

Kai, proposed to not use the domain name, it’s a centre-ID not domain name

Baudouin asked about how users will know the provider of data

Tom, they will get it from the discovery metadata

Kai, asked about the possibility of reuse of the WMO country profile database

Maaike, the registration of WIS2 has been discussed and as option will consider the option of using the CPDB

Kai proposed, when a member asked for WIS2 registration, secretariat will propose the center-ID

Remy, need to have a sort of agreement between WMO and a Centre. If the center had a domain name it will be used as proposed by Tom, if not an agreement with Secretariat is needed to agree on the center-ID ( the Centre name used at national level can be used)

Remy, the use of dot (fr.meteo) is it a problem? or shall we go for dash (fr-meteo)

Kai, it’s better to go to a safe solution, dash is a good alternative and will remove the ambiguity with the domain name

Baudouin, if we are not using the domain shall we go for ECMWF without int nor gov

Remy, to ease the meaning when defining the center-ID, if a Centre have a domain we will use it for example int-gov-ecmwf

Simon, mentioned that a similar nomenclature has been used in the manual on GTS

Tom, we will review that and if we found it as valuable notation we will reuse it

Action: Tom to open a issue on the TH to come up with a convention to discuss in the next meeting

3

Lifecycle management of discovery metadata in WIS2 https://github.com/wmo-im/wis2pilot/issues/85

Tom presented the issue concerning the lifecycle management of discovery metadata and presented two options

1. GDC Unpublish workflow

• a GDC is subscribed to a GB with origin/a/wis2/+/+/metadata/#

• WIS2 Nodes issue a WNM with rel=http://def.wmo.int/def/rel/wnm/-/deletion notifying the GDC that this is a discovery metadata deletion workflow

• GDC archives the metadata to, say, a GitHub (or WMO/other) repository for long term archival/perusal (I'm not sure such an archive would need to be "searchable" vs. simply accessible)

Impacts:

• WIS2 Nodes need to announce the above with a WNM providing a "delete" action

• GDC workflow to "move" the discovery metadata to an archive

2. Mark as "archived" workflow

• a GDC is subscribed to a GB with origin/a/wis2/+/+/metadata/#

• WIS2 Nodes update discovery metadata with, say, properties.status=archived

• WIS2 Nodes issue a WNM with rel=http://def.wmo.int/def/rel/wnm/-/update, notifying the GDC that this is a discovery metadata update workflow

• discovery metadata is updated in GDC

Impacts:

• implies metadata curation

• discovery metadata is never removed, but the content is updated (properties.status)

• GDC searches would ALWAYS show all metadata regardless of status (i.e. a user would have to filter on properties.status

  • a GDC could be configured to only show non-archived discovery metadata by default, but this is an implementation detail

Discussion

• we need to start focus on getting more discovery metadata in GDCs

• the specifications (WCMP2, WNM) would ensure options 1 and 2 could be realized

• When we decide on the issue concerning the updated data using the relation link this one of metadata will follow

• Tom, we need to decide if are we going to delete the metadata from the catalogue or are to be archived and marked as archived in the catalogue

• Remy, according to the fair principles, the metadata should be archived not deleted

• Tom, in this case shall we archive it in a separate server or keeping it in the same catalogue and marked it as archived inside the catalogue

• ET agrees to defer to later phase

WIS2 node backup

Hassan introduced the request from Members of having a backup WIS2 node for sustainability.

Et agreed to discuss this topic in the next FTF meeting in Washington