Principles
A topic hierarchy provides a taxonomy structure to logically group concepts in support of lowering the barrier to finding data at varying granularity. Benefits include:
Easy aggregation across topic hierarchy levels
Easy to understand relationships (broad/narrow)
Fine grained filtering for search
Fine grained access control as required
Message queuing protocols and metadata benefit from topic hierarchy and organization
A single topic hierarchy which is interchangeable between discovery metadata, catalogues and message queuing protocols topic allows for consistent resource discovery, subscription to data and event driven notifications/workflow
Topic hierarchy built from GTS legacy will be temporary and used only to make GTS data available on WIS2
WIS2 hierarchy will be built gradually following the requirements of WMO domains
Observations
NWP
…
WIS2 topic hierarchy and filename
Core hierarchy
Level | Name | Description | Value(s) | Example | |
|---|---|---|---|---|---|
1 | scope | Scope | Scope of topic hierarchy (fixed to |
|
|
2 | resource-type | Resource type | Type of resource being identified |
|
|
3 | data-policy | Data Policy | WMO Unified Data Policy category, provides distinction in access control/permissions |
|
|
4 | data-type | Data Type | Top level data type |
|
|
Examples:
wis2.data.core.observations
wis2.discovery-metadata.recommended.nwp
wis2.data.other.observations
wis2.monitoring-report.gts
Data Type Hierarchies
Data Type hierarchies vary significantly across data types (e.g. different for observations and NWP), and will be built gradually following the requirements of WMO domains.
Each WMO domain will also define filename conventions (basename, extension)
Observation Data Type
Level | Name | Description | Value(s) | Example | |
|---|---|---|---|---|---|
1 | country | Country | ISO 3166-2 code of country |
| |
2 | station-type | Station type | Station/platform type |
| |
3 | message-type | Message type | The type of message sent by the observation station |
|
|
Examples:
wis2.data.core.observations.ca.landFixed.??
wis2.data.core.observations.gr.landMobile.??
wis2.data.core.observations.it.seaFixed.??
wis2.monitoring-reports.wis2.observations.de.??
Alternative Proposal
This alternative proposal has the country code and center name higher up in the hierarchie. Could be extended with data policy
Filename conventions
Observations
Filename: WIGOS_{wsi}_{datetime}.{extension}
where:
Name | Description | Value(s) | Example(s) |
|---|---|---|---|
wsi | WIGOS station identifier |
|
|
datetime | Datetime |
| |
extension | Filename extension |
|
|
Examples:
WIGOS_0-454-2-AWSNAMITAMBO_20001111.bufr4
NWP
TBD
data format: grib2, nc
GTS topic hierarchy and filename
This is the current output of the TT-Protocols team
https://github.com/wmo-im/GTStoWIS2
Question to be answered.
Given that GTS will be dismissed does it make sense to develop a topic hierarchy based on GTS headers?
Shall we make a topic structure directly with GTS headers (T/T/A/A/ii/CCCC )?
Related discussions
GTStoWIS2: https://github.com/wmo-im/GTStoWIS2/issues/9
0 Comments