Closed tomkralidis closed 9 months ago
PR in #86
Changes merged.
Only one question: Why adding new properties.producer to notification when metadata_id is included and all information could be found in metadata? If adding is needed, should we add a codelist or REQ for allowed values? (7.1.11 example includes "fra", country code or abbreviate organization name?)
We need properties.producer
in the case of notifications being sent by a single centre on behalf of multiple organizations / countries. Consider SWIC providing notifications of CAP messages for participating countries.
We intentionally do not define a codelist/enumeration at this time, we could consider for the future.
As a complement from me. At the moment, SWIC is adding the 3-letter country code at the end of the topic hierarchy.
We may (will ?) have another similar case with DCP (Data Collection Providers) where entities like EUMETSAT will publish data for many countries. How to know easily that something is for a particular country ?
Having a properties.producer
doesn't mess up with the TH while providing this filtering function.
Wouldn't it be better to have a separate center-id for each center that produces data in WIS2? Also then we could allow another center to take over the publication and data provision service. Then the centre could use for pub the center-id in the WTH that matches to the data. In my view, the advantages would be: 1) Checking whether notification is for own metadata (or metadata contained in the scope of condition) can still be done via mapping between center-id in WTH and metadata id included centre-id (what is needed to decide whether metadata adjustment is authorized and should be performed) 2) Filtering for data from a specific center is carried out uniformly via WTH at the same point - regardless of whether the data was published directly or via a supporting center 3) We always have a complete list of all data sources (centre-id) in WIS2
I also see as a disadvantage that the list could be very long and time-consuming to maintain, especially in the beginning.
But in the long term I think we would have more advantages than disadvantages to have the data directly under their own center-ids.
I don't think so... We are here talking about a DCPC function such as SWIC where it is useful to know quickly the data producer. We can't use the "native" data producer centre-id. As the original centre may need also to publish things by himself. Therefore, it would be an additional centre-id using, for example, part of the name of the DCPC and part of the "native" data producer. Eg. hk-hko-swic-fra for the French warning. On the GB that would mean one subscription per country to the same source (SWIC). So, it is super heavy, I think.
And, AFAIK, it will never be "directly under their own center-ids."
We have two similar cases here.
The additional properties.producer can be safely ignored by many while providing useful information to others.
For the subscription of many there would be the possibility of wildcards, but in the SWIC case, I would assume that, for example, SWIC also creates/updates/deletes the metadata. Then the responsibility for the metadata would also lie with SWIC and the solution via additional properties.producer is ok.
I addition creating 150 centre-id to be used by SWIC, X for each DCP,... is a good solution. So, OK for the properties.producer ? And we close ?
We are in a closed Issue ;-) OK for the properties.producer if we also use this center-id (e.g. SWIC) in the corresponding metadata-id (regardless of the respective country) -
add an optional
properties.producer
(same meaning as https://github.com/wmo-im/wcmp2-codelists/blob/main/codelists/contact-role.csv#L3) to support identifying the originator data producer for data distribution on behalf of other members@tomkralidis to update WNM
@6a6d74 to update guide
cc @golfvert