[LDR] hubverse target_keys should contain a single value

[zkamvar]

I have added an LDR to reflect the decision made at the hubverse devteam meeting on 2024-12-11.

Here is the transcript of the discussion:

• In target_metadata, we allow for target_keys to be multiple fields. (Evan) E.g., if a hub has 4 targets given by “incident hospitalizations”, “cumulative hospitalizations”, “incident cases”, “cumulative cases”, these could be represented by two variables called inc_cum \in {“incident”, “cumulative”} and signal \in {“hospitalizations”, “cases”}. Is it worth the coding effort downstream to support this, or should we just ask hubs to provide 1 target in 1 column
  • E.g. 1 column with values like: (“incident hosps”) or (“incident cases”)
  • E.g. 2 columns with values like (“incident” and “hosps”) or (“incident” and “cases”)
  • Lucie: Are there any hubs that are using the two column targets?
  • Becky: as we start to play with dashboards and downstream data, having one column is great to use as a partitioning key.
  • Lucie: it’s also fairly easy to switch from two to one.
  • Nick: to clarify, we’ve made a decision to change this?
  • Anna: no.Tthe only thing that we want to specify is that each target would contain a single value.
  • Becky: is the work here to create a new version of the schema and update the documentation?
  • Becky will create a ticket.
  • Evan: should we check in with existing hubs before we go ahead with this?
  • Nick: the right thing to do would be to send this to the mailing list.

I am recording this as an LDR so I can refer to this decision for communications

PRs are already underway:

• Restrict target_keys object to contain only a single key value pair.  hubverse-org/schemas#118
• Only allow a single target_keys key value pair hubverse-org/hubAdmin#90
• Only show a single target_keys key value pair to conform to v4.0.1 schema hubverse-org/hubDocs#227

[elray1]

looks good, thanks for putting it together! had a question about version number. Am approving in case you believe the version number is correct.

[elray1]

Should this be regarded as a major version change, in the sense that if a hub previously had multiple target keys, they can't just update to the latest version and still have a working schema? (This is a real question, not a suggestion to change the version increment.)

[zkamvar]

I think that's a good question. My opinion is that it should be a major version change because of this reason.

It's one of the slightly frustrating things that happens with semantic versioning: major version changes often feel like they should be earth-shattering changes, but they can be as small as removing an argument or (in this case) restricting a previously boundless field.

[zkamvar]

That being said, given that I am recording a decision that was made in a meeting two weeks ago AND because the steps for implementation are already in progress, it's more appropriate to merge this in and then create another LDR to amend this decision if we think it's appropriate.

[annakrystalli]

I included this in the patch version I had already queued up because from what I understand no one was using this feature. It would not be a problem to bump to 5.0.0 for more semantic accuracy, would just need to change the version in the schema PR and a few snapshots in hubAdmin.

[elray1]

• Zhian and I looked back at our meeting notes, and we had basically said, "we don't think anyone is using this feature, but it would be good to send out an email to double check with existing hubs before going ahead with making this change"
• I don't recall having a specific discussion or decision about impact on version numbers when this first came up. If indeed no one is using this, I'd be ok with bending the semantic versioning rules.