-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle round_id
s other than dates?
#81
Comments
I would be in favor of not adding support for non-date round-ids for now, and only supporting round-ids that are in the format of dates. Are there clear usecases where supporting non-date round-ids would be useful? |
@LucieContamin wrote in https://github.com/orgs/Infectious-Disease-Modeling-Hubs/discussions/7#discussioncomment-9236827
Could you share an example of what such Additionally, in the rounds where Would be super curious to see an example of both the |
The
So, the filename follow the "usual" format, for example: I am happy to provide more information and example, if necessary. I can also give you the link to the repository link to these rounds: https://github.com/midas-network/covid19-smh-research |
Thank you @LucieContamin ! OK so it still is a date so still not an example of a non date round_id! 😜 Out of curiosity, what made you configure some rounds one way and some the other? |
Ah yes, still a date but as I use it only for tracking files, it could have been anything I guess. It's not use for anything else. We decided to configure it like this, because we have two rounds with the same |
Very useful context, thanks. I guess if we were to support non-date round ids, so long as they conformed to using round id that only contain alphanumerics and And you still have |
fixed in #133 |
Background
Since the beginning of the project we have discussed and in general planned for supporting
round_id
s other than dates. So far this has not been necessary and our validations have focused on the assumption thatround_id
s will be dates, largely because all known hubs do indeed use dates as round IDs. Some discussing around this topic during development of the validation framework can be found here: #13However, the push to convert historical hubs to hubverse style hubs has resurfaced the question of supporting non-date round ids and the need to assess implementation implications and weigh them against the benefits of supporting this feature.
Implications of using non-dates as round ids
Use of a non-date round id has some important implications, most importantly on how submission windows are configured:
start
andend
date for each round id. For example, if the following simplified flusighttasks.json
config is changed to use epiweek (in the formatYYYY-EPIWEEK
) instead of ISO date, for just specifying 3 rounds, the size of the config triples containing primarily repeated information (only the submission window specification changes:date round id
epiweek code round id
Work Required
If we do choose to go ahead and support non-date round IDs, the main work would be in modifying
hubValidations::parse_file_name()
to recognise and match non date round IDs.If we decide we will not support non-date round IDs, we need to update
hubDocs
to reflect that.The text was updated successfully, but these errors were encountered: