add properties.metadata_id

[tomkralidis]

Implements #25

[antje-s]

Review ok, only for
standard/recommendations/core/REC_metadata_id.adoc
--> copy and paste error from integrity?
delete "...consisting of a +method+ property identifying the hashing method (md5, sha256, sha512) and a +value+ property of the hashing result, when it can be easily derived."

Metadata id concept change in examples from e.g.
old - urn:x-wmo:md:int.wmo.wis::ISMD01EDZW (...int.wmo.wis for international exchanged)
new - urn:x-wmo:md:fra:meteo-france:gap123 (...country:centre-id...)
In my opinion a useful change but I see it here for the first time consciously (so only intended as a comment)

[josusky]

When it concerns metadata_id, we have touched on such a possibility during the telco, but I do not think we have agreed on that. My concern is, that this is not lowering the barrier (to enter WIS) but heightening it. It is another element that needs to be appropriately maintained in the configuration of the notification publishing software and has little practical value. I think that the data_id (topicHierarchy) provides sufficient linkage between the data and the metadata.

[tomkralidis]

@antje-s thanks, fixed copy/paste typo. The metadata identifier definition is defined in WCMP2 in https://wmo-im.github.io/wcmp2/standard/wcmp2-DRAFT.html#_identifier

[tomkralidis]

When it concerns metadata_id, we have touched on such a possibility during the telco, but I do not think we have agreed on that. My concern is, that this is not lowering the barrier (to enter WIS) but heightening it. It is another element that needs to be appropriately maintained in the configuration of the notification publishing software and has little practical value. I think that the data_id (topicHierarchy) provides sufficient linkage between the data and the metadata.

@josusky will continue in #25

[antje-s]

Not sure...is "SHOULD" enough? (perhaps we need a SHALL)
If we want to enforce in the future that metadata for exchanged data is always created, there must be the possibility to check this in the notifications, because later the subscriber can automatically download the data (for core data). If metadata-id is always included this would allow to block messages on GB side that do not contain a valid metadata record id value (or contains a metadata id value not matching country and centre from topic value). The new metadata structure reduces the amount of metadata to be checked by limiting it to one country and one centre.
Of course, we need to be more relaxed in the transition phase, but we should not block these opportunities for operational phase.

[josusky]

I vote for "SHOULD" in this case. Quite a number of properties are optional, including geometry and date/time, to lower the barrier for entry into WIS 2.0. This is the same situation. The metadata already points to the service/broker, now if we imposed that each notification points back to the metadata record it would effectively become a double linkage - which is significantly more difficult to maintain. Links tend to "rot", and double linkages doubly so :-)

[tomkralidis]

Update: discussions with @golfvert indicate support for SHOULD. Let's move ahead w/ SHOULD and consider applying as a KPI.