New : WIS2.0, how to define successful Transition?
Migration
Catalogue
SRU → OGC API - Records
Discovery metadata
WCMP 1.3 → WCMP 2.0
GTS
...
Plan for a short transition (3 to 5 years). Target D-Day (Start of migration): Jan. 1st, 2024
Reduce the costs for NMHSs:
Avoid the need for dual stack (GTS and WIS2) for as many sites as possible
Reduce the number of RTHs between now and D-Day → Identify “Transition Helpers RTH”
In each RA, identify RTHs willing to run GTS services until the end of the migration, so that others can cease GTS operation rapidly and act as WIS2 focal sites
Allow identified GISCs to stop the technical WIS1 role (cache and metadata catalog) in favour of “WIS2 Champion” role (training, communication, shared service,…)
Promote the use of “WIS2 in a box”
Identify WIS2 Champions
Monitoring WIS2 operations and KPI migration
Similar to WIS monitoring + follow GTS to WIS2 migration KPI
Global open broker
Allow any interested NC to publish/subscribe using these brokers
Training/communication/onboarding
Identify members within each RA acting as WIS2 Champion (GISC and others)
“WIS2 success story” portal (aka visual catalog)
Similar to GDPFS portal, follow WIS2 implementation and provide a visual communication tool to show WIS2 progress
Metadata
Proposals for WIS2 metadata and catalogues are here. This discusses protocols and formats, but does not address wider concerns about how we will operate and populate catalogues in WIS2. We have outstanding issues on topics like:
who "stands up" a catalogue
what granularity should we aim for with metadata records (e.g. what is the scope of a dataset that we want to discover via the catalogue)
During the ET-W2AT meeting (19-Nov-2021) we had a lengthy discussion on point (2). Key points are:
WIS Centres will be responsible for migrating their metadata.
We should provide automated tools to help WIS Centres translate from WIS1 metadata (WCMP1.3) to WIS2.
There are too many "fine-grained" metadata records in WIS1 catalogue, which means that discovery of information is compromised - a search may return hundreds of results. ~90% of metadata in WIS1 are for GTS data.
We want users to be able to discover datasets and then find the end-points where they can download the datasets (or sub-set that they're interested in) or subscribe to notifications about updates to the dataset (e.g. new observation data that can be downloaded).
For example: currently France has a metadata record for each SYNOP bulletin, the aim may be to create a one metadata record for a single dataset that includes all French SYNOPs.
The message-broker topic structure being developed by Peter Silva et al. relates to GTS AHLs in an aim to support migration from GTS. The topic structure defines the "end-points" where you can subscribe to get data - which is information that needs to be expressed in the metadata record.
There needs to be a link between the metadata records and the topic structure.
Legacy systems will need to be able to determine the AHL from metadata. There's no algorithmic way to determine the GTS filename
The topic structure is hierarchical - it may be possible to link a metadata record higher up the hierarchy.
Can we organise the topic structure to enable sensible grouping of GTS bulletins into datasets that users can discover?
Based on grouping, can we define systematic rules that can be applied to existing WIS1 metadata record collections to automatically generate "large-grained" WIS2 metadata.
ACTION (Peter Silva, Tom Kralidis, Baudouin Raoult, Jeremy Tandy): Review proposed topic structure. Identify opportunities to group GTS records.
Meeting 2021-12-17
Discovery Metadata
We will NOT have 1 to 1 lift and shift of discovery metadata from WIS1 to WIS2
Many organizations may still manage their metadata in WIS1/as ISO
We need to rethink discovery metadata for WIS2
granularity
codelists
KPIs