Principles
Mapping 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 topic hierarchy shall allow message queuing protocols topic allows for consistent resource discovery, subscription to the data described in the metadata item. data and event driven notifications/workflow
Topic hierarchy built from GTS is going to 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
scope/ data policy / data type
wis2/[core | recommended | other]/[ obs | nwp ]
Starts with WIS2 to mark the scope and syntax.
data policy will be high in the hierarchy because it imposes a distinction in access permissions
At the moment we have observations and nwp data, but we will add climate statistics and possibly other data types.
The hierarchy under this level is significantly different for obs and nwp.
obs/country/station-type/message-type/
For observations, the topic hierarchy and the associated metadata shall be consistent with OSCAR metadata.
Country where the observing station is located. This is sometimes a problem with the sea stations.
station-type is about the location of the station (land, air, sea) and whether it is fixed or mobile: OSCAR surface
message-type is about the type of message sent out by the observing station
Filename: WSI_[WSI value]_[timestamp].[data format]
...
WSI as shown in OSCAR surface
...
timestamp in the following format
...
Core hierarchy
Level | Name | Description | Value(s) | Example | |
|---|---|---|---|---|---|
1 | scope | Scope | fixed to |
|
|
2 | data-policy | Data Policy | articulates the WMO Unified Data Policy, provides distinction in access control/permissions |
|
|
3 | data-type | Data Type | Category |
|
|
Examples:
wis2.core.observations
wis2.recommended.nwp
wis2.other.observations
Level 3 Data Type Hierarchies
Level 3 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 | category | Category | Data category |
|
|
2 | country | Country | ISO 3166-2 code of country |
| |
3 | station-type | Station type | Station/platform type |
| |
4 | message-type | Message type | The type of message sent by the observation station | ? | ? |
Examples:
wis2.core.observations.ca.landFixed.??
wis2.core.observations.gr.landMobile.??
wis2.core.observations.it.seaFixed.??
Filename conventions
Observations
Filename: WIGOS_{wsi}_{datetime}.{extension}
where:
Name | Description | Value(s) | Example(s) |
|---|---|---|---|
wsi | WIGOS station identifier |
|
|
datetime | Datetime |
| |
extension | Filename extension |
|
|
NWP
TBD
data format: grib2, nc
GTS topic hierarchy and filename
...
Shall we make a topic structure directly with GTS headers (T/T/A/A/ii/CCCC )?