will OID help with defining topic trees?

[petersilva]

Use of OID: https://en.wikipedia.org/wiki/Object_identifier
has been suggested for topic tree definition, one reason being the governance model.

[eliot-christian]

If it is possible to use OIDs as topics, I would think their independence from human languages would be a major advantage. An OID is comprised entirely of numeric characters plus the dot (".") character. OIDs are used widely in ICT--apparently there are 1.5 million assigned currently. A free online service provides access to the descriptive text associated with each assigned OID.

[petersilva]

So far the committee has expressed the desire to escape encoded names, and try to find something human readable.
They wanted to replace TTAAii with human readable topics. In the English version of the OID document ( Rec. ITU-T X.660 | ISO/IEC 9834-1. ) Section A.2.2 (page 12) I see each integer value has a corresponding "Unicode Label", I imagine we would probably prefer the labels.

If we start at the first level, the exhaustive list of values is: 0- - administered by ITU-T, 1-administered by ISO, 2-joint ITU-ISO ... so we would need to approach one of those two groups to either be blessed as a new authority, or be administered by one of them.

Do you have a link for the free online service? I found this one: http://www.oid-info.com/ Is that what you meant?

http://www.oid-info.com/faq.htm#1

[petersilva]

I just had a look in Canadian CAP, and it has an OID to identify every alert, and it uses... 2.49.0.1.124.some random digits.YYYY. pasting that into the oid-info com gives an error. 2.49 yields a reference to ( https://www.itu.int/rec/T-REC-X.674-201102-I/en ) which is a delegation to WMO for Alerting... which yields alerting authorities ( https://alertingauthority.wmo.int/ ) and leads to ECCC being listed as 2.49.0.1.124 ...

[eliot-christian]

I set up the OID tree for alerts tied to the international Register of alerting Authorities, which is arc 2.49.0 <https://oidref.com/2.49.0> I imagine the same approach could be used for your topic trees. I recommend you check with ***@***.*** as he is the expert on use of OID's. I suppose you need to consider if you want your new OID trees to be part of a generalized tree for all Message Queue topic trees, and/or a generalized tree for all shared environmental data (e.g., allowing nodes for use by AWS other Big Data projects, GEO, OGC, Esri Living Atlas...), or a tree that is specific to WMO only. In any case, there will need to be a designated administrator for at least the WMO arc of this new OID tree.You might want to take a look at WMO/TD No. 1556 Administrative Procedure for Registering WMO Alerting Identifiers <https://library.wmo.int/pmb_ged/wmo-td_1556_en.pdf>.

…

On Thu, May 27, 2021 at 1:34 PM Peter Silva ***@***.***> wrote: So far the committee has expressed the desire to escape encoded names, and try to find something human readable. They wanted to replace TTAAii with human readable topics. In the English version of the OID document ( Rec. ITU-T X.660 | ISO/IEC 9834-1. ) Section A.2.2 (page 12) I see each integer value has a corresponding "Unicode Label", I imagine we would probably prefer the labels. If we start at the first level, the exhaustive list of values is: 0- - administered by ITU-T, 1-administered by ISO, 2-joint ITU-ISO ... so we would need to approach one of those two groups to either be blessed as a new authority, or be administered by one of them. Do you have a link for the free online service? I found this one: http://www.oid-info.com/ Is that what you meant? http://www.oid-info.com/faq.htm#1 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSZR3DVPNLI2Q5HO6FHER3TPZ7DJANCNFSM45NMDRTA> .

[eliot-christian]

You are correct. There are long-standing examples of rampant abuse of OIDs by WMO Members. MeteoAlarm is an especially irksome case. Olivier Dubuisson has brought this to the attention of WMO multiple times.

…

On Thu, May 27, 2021 at 2:40 PM Peter Silva ***@***.***> wrote: I just had a look in Canadian CAP, and it has an OID to identify every alert, and it uses... 2.49.0.1.124.some random digits.YYYY. pasting that into the oid-info com gives an error. 2.49 yields a reference to ( https://www.itu.int/rec/T-REC-X.674-201102-I/en ) which is a delegation to WMO for Alerting... which yields alerting authorities ( https://alertingauthority.wmo.int/ ) and leads to ECCC being listed as 2.49.0.1.124 ... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSZR3AE2FYALOFZS3GAWUDTP2GYJANCNFSM45NMDRTA> .

[antje-s]

The idea of using OID (to be OID conform) sounds good. Would it be possible to offer one exchange with the OID numbers as topic tree and one with the labels (current topic tree)?
But it would be important to get a WMO (sub)tree in which we can adjust (expand) independently, so that we don't have to organise official change requests every time . If it could be implemented this way, then the WMO subtree would be a node of the main tree and from here on independent in the sub-tree. Would that be the case?

[eliot-christian]

Regarding the OID labels and numbers, these are regarded as alternative "notations". For example, at http://www.oid-info.com/get/2.49.0 we see: {joint-iso-itu-t(2) alerting(49) wmo(0)} is the ASN.1 <http://oid-info.com/faq.htm#17> notation 2.49.0 is the dot <http://oid-info.com/faq.htm#14> notation /Alerting/WMO is the OID-IRI <http://oid-info.com/faq.htm#iri> notation WMO would manage its own "OID tree of topics" regardless of what node is designated as the root of that tree. Assuming WMO chooses its root node to be within the Joint-IOS-ITU root node (2), you can see the currently defined nodes at http://www.oid-info.com/cgi-bin/display?oid=2&submit=Tree+display As a purely hypothetical example, perhaps WIS would negotiate with others and decide to designate node 2.53 as "message-queue-topics", node 2.53.0 as "data-delivery", and 2.53.0.0 as "wmo-information-system". In that case, WIS would be the sole administrator of the tree rooted to node 2.53.0.0. Yet, WIS would be expected to participate with other organizations (e.g., UCAR, GEO, AWS, Esri...) in administration of node 2.53.0, and to participate with an even broader range of other organizations (potentially, every organization using OIDs with MQP) in administration of node 2.53. Eliot

…

On Fri, May 28, 2021 at 6:46 AM antje-s ***@***.***> wrote: The idea of using OID (to be OID conform) sounds good. Would it be possible to offer one exchange with the OID numbers as topic tree and one with the labels (current topic tree)? But it would be important to get a WMO (sub)tree in which we can adjust (expand) independently, so that we don't have to organise official change requests every time . If it could be implemented this way, then the WMO subtree would be a node of the main tree and from here on independent in the sub-tree. Would that be the case? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSZR3B7XPD57KOATVCFBNLTP5X77ANCNFSM45NMDRTA> .

[antje-s]

@eliot: many thanks

Then hypothetically we would map our previous topic-tree e.g.
v03/WIS/es/madrid_met_center/observation/upperair/land/fixed/temp/0-90n/0-90w/[filename].bufr
with OID-usage as
joint-iso-itu-t(2)/message-queuing-topics(53)/wmo-information-system(0)/version3(0)/es(52)/madrid_met_center(2793)/observation(8)/upperair(5)/land-fixed(5)/temp(0)/0-90n(0)/0-90w(0)/[filename].bufr

values got from
52 - line number in TableC1.json [-2 (leave out line with "{" and first OID number 0)]
2793 - line number TableCCCC.json
8 - TableA.json (key "I", position in alphabet minus 1)
5 - TableB.json (number subelements under key "I")

5 - TableC6.json values under key "IU" would have to be adjusted
e.g.
0 - single-level
1 - temp
2 - vertical
3 - satellite
4 - dispersal
5 - land-fixed
6 - land-mobile
7 - marine-ship
....

0 - TableC3.json values would have to be adjusted
e.g.
0 - 0-90n
1- tropics
2 - 0-90s
....

In addition to the adjustments, two exchanges would be necessary if we want to offer the users not only a number topic structure or an extended current topic tree. As far as I understand, it should go more in the direction of plain text, so that a pure OID number tree alone would not be an option.

That's why I'm now asking myself what benefits would we expect. Is it probable that with a pure OID number tree the processing in the broker is faster possible?

[eliot-christian]

I think we need to distinguish between an abstract identifier and any particular representation of that identifier. The tree of identifiers is abstract; various notations are only representations of identifiers in that tree. All OID notations are always available--ICT systems use whichever notation(s) are most useful for the particular situation. I cannot comment much on your example as I am not familiar with the tables you reference. It does strikes me as odd that a fundamental node of your tree would be a version number and a language designator, i.e., version3(0)/es(52) Also, I would guess that the file name is not part of the topic, i.e.,[filename].bufr, . I would also note that the numbering of your OIDs can be 0-based or 1-based at your choice.

…

On Fri, May 28, 2021 at 10:03 AM antje-s ***@***.***> wrote: @eliot <https://github.com/eliot>: many thanks Then hypothetically we would map our previous topic-tree e.g. v03/WIS/es/madrid_met_center/observation/upperair/land/fixed/temp/0-90n/0-90w/[filename].bufr with OID-usage as joint-iso-itu-t(2)/message-queuing-topics(53)/wmo-information-system(0)/version3(0)/es(52)/madrid_met_center(2793)/observation(8)/upperair(5)/land-fixed(5)/temp(0)/0-90n(0)/0-90w(0)/[filename].bufr values got from 52 - line number in TableC1.json [-2 (leave out line with "{" and first OID number 0)] 2793 - line number TableCCCC.json 8 - TableA.json (key "I", position in alphabet minus 1) 5 - TableB.json (number subelements under key "I") 5 - TableC6.json values under key "IU" would have to be adjusted e.g. 0 - single-level 1 - temp 2 - vertical 3 - satellite 4 - dispersal 5 - land-fixed 6 - land-mobile 7 - marine-ship .... 0 - TableC3.json values would have to be adjusted e.g. 0 - 0-90n 1- tropics 2 - 0-90s .... In addition to the adjustments, two exchanges would be necessary if we want to offer the users not only a number topic structure or an extended current topic tree. As far as I understand, it should go more in the direction of plain text, so that a pure OID number tree alone would not be an option. That's why I'm now asking myself what benefits would we expect. Is it probable that with a pure OID number tree the processing in the broker is faster possible? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSZR3EZXJ3JCQIHGILTV43TP6PCJANCNFSM45NMDRTA> .

[antje-s]

v03 represents the WMO message format version and gives information about the format of the pub/sub messages.
"es" is not used as language designator but as WMO country code (which country's MET products you want to have)

As the OID tree has abstract values and we need particular representation values for the topic tree for pub/sub, OIDs could be included only as supplementary information.
However, this additional information on the reference base could be helpful to increase the flexibility for possible further developments at a later stage.

OID for example
joint-iso-itu-t(2)/message-queuing-topics(53)/wmo-information-system(0)/wmo-message-format(0)/wmo-country-code(0)/wmo-center-name(0)/wmo-product-category(0)/wmo-data-area(0)

particular representation values
2/53/WIS(0)/v03(0)/es(0)/madrid_met_center(0)/observation(0)/upperair(0)/land(0)/fixed(0)/temp(0)/0-90n(0)/0-90w(0)/
|--> 0 for product category <--| |--> 0 for data area <--|
(It might make sense to merge the subtrees for the product category and the subtree for the data area into one value each (e.g. with "_"))

But first we should discuss in our group if the majority is for the inclusion of an OID number or not and if yes, all variants of the topic trees would have to be considered for a well-founded proposal for a possible OID message-queuing-topics subtree.

In any case, thank you for the pointer to the OIDs

[petersilva]

small clarification: The "es" country code near the top of the topic hierarchy is not about the coverage of the data, but rather about the country responsible for the issuing centre listed at the next level. "es/madrid_met_center" is logically equivalent to a CCCC on WMO 386. there could be data from anywhere in the world under a particular country code, especially with global nwp products. Most products encode their coverage area in the TTAAii, so there may be a second country code or other geo tags later.

The use of the country code at this level comes from Remy wanting to have a level at which authority for the tree below it to be delegated to. "es" would, in this scheme be delegated to the WMO member for Spain, and the spanish WMO member would hand out centre names for the next level.

This is similar to stipulations in the OID, where levels below a certain level are under the responsibility of a parent of some node in the tree.

[golfvert]

The use of the country code at this level comes from Remy wanting to have a level at which authority for the tree below it to be delegated to. "es" would, in this scheme be delegated to the WMO member for Spain, and the spanish WMO member would hand out centre names for the next level.

If having the country name and the organisation at this level leads to a risk of having different subtopics at immediate lower levels, then, there is something to re-consider. Maybe, as I am not anymore part of this discussion for quite some time I may have missed the point.
What we absolutely need is a unique tree structure and that "observation" is always called "observation" in all languages.
In that respect, using a number and avoiding using english terms for a worldwide service like WIS2 could be of interest...

This is similar to stipulations in the OID, where levels below a certain level are under the responsibility of a parent of some node in the tree.

Yes. I think we will this option. I would say as low as possible in the tree.

[eliot-christian]

If flexibility is desired, one could name an OID node something like "country-or-not" and assign to the "not arc" a value which is never an ISO 3166 country code, e.g., "0".

…

On Sat, Jun 5, 2021 at 2:55 PM Remy Giraud ***@***.***> wrote: The use of the country code at this level comes from Remy wanting to have a level at which authority for the tree below it to be delegated to. "es" would, in this scheme be delegated to the WMO member for Spain, and the spanish WMO member would hand out centre names for the next level. If having the country name and the organisation at this level leads to a risk of having different subtopics at immediate lower levels, then, there is something to re-consider. Maybe, as I am not anymore part of this discussion for quite some time I may have missed the point. What we *absolutely* need is a unique tree structure and that "observation" is always called "observation" in all languages. In that respect, using a number and avoiding using english terms for a worldwide service like WIS2 could be of interest... This is similar to stipulations in the OID, where levels below a certain level are under the responsibility of a parent of some node in the tree. Yes. I think we will this option. I would say as low as possible in the tree. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSZR3DGXI46I3JHLRILHXTTRJXKVANCNFSM45NMDRTA> .

[petersilva]

further discussion here: https://github.com/wmo-im/wis2-topic-hierarchy