Skip to content
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

replace cases by confirm for API consistency #131

Open
avallecam opened this issue Mar 19, 2024 · 7 comments
Open

replace cases by confirm for API consistency #131

avallecam opened this issue Mar 19, 2024 · 7 comments

Comments

@avallecam
Copy link
Member

Wondering if for consistency across the ecosystem, {cfr} and {EpiNow2} should use a similar column name. Data from {cfr} can also be used for {EpiNow2} right?

library(EpiNow2)
library(cfr)

head(EpiNow2::example_confirmed)
#>          date confirm
#>        <Date>   <num>
#> 1: 2020-02-22      14
#> 2: 2020-02-23      62
#> 3: 2020-02-24      53
#> 4: 2020-02-25      97
#> 5: 2020-02-26      93
#> 6: 2020-02-27      78
head(cfr::ebola1976)
#>         date cases deaths
#> 1 1976-08-25     1      0
#> 2 1976-08-26     0      0
#> 3 1976-08-27     0      0
#> 4 1976-08-28     0      0
#> 5 1976-08-29     0      0
#> 6 1976-08-30     0      0

Created on 2024-03-19 with reprex v2.1.0

@pratikunterwegs
Copy link
Collaborator

In principle having common names makes sense. I think {EpiNow2} should change its requirements for column names as 'cases' alongside 'deaths' is IMO clearer to users; 'confirm' is ambiguous. In practice, changing requirements in either package would be a breaking change, and therefore difficult to justify for uniformity's sake.

@sbfnk
Copy link
Contributor

sbfnk commented Mar 20, 2024

See epiforecasts/EpiNow2#505

@pratikunterwegs
Copy link
Collaborator

Thanks, I hadn't seen that issue! Again, in practice, if we do decide to standardise, it does make make sense for {cfr} to change its requirement to match {EpiNow2} - if the new name makes sense - as there are far fewer {cfr} users (I imagine) so lower impact overall.

@pratikunterwegs
Copy link
Collaborator

Hi @avallecam - could I get an idea if this issue is still relevant or if it can be closed?

@avallecam
Copy link
Member Author

Hi @avallecam - could I get an idea if this issue is still relevant or if it can be closed?

I'll look at this at the end of this week again.

@avallecam
Copy link
Member Author

avallecam commented Jun 7, 2024

Hi @avallecam - could I get an idea if this issue is still relevant or if it can be closed?

May {cfr} and {EpiNow2} be facing a similar situation? the count column of their input data could contain many types of observation, always linked with the corresponding delay.

  • {cfr} from observation to death,
  • {EpiNow2} from infection to observation.

Following Gosnic et al., Fig 4, observation can be any "observed data" between infection and death.

The column name of cases for {cfr} and confirm for {EpiNow2} are defined given the most immediate and memorable need that each of these packages satisfy. But they reduce the visibility of alternative observation-delay combinations.

From a learning point of view:

  • For the novice learner, keeping the names as they are minimize the effort to learn.
  • Then, for the competent practicioner, we can expect them to rename columns to the type of observation they have available (as mentioned in this EpiNow2 comment)

I suggest to keep this issue open and wait for {EpiNow2} to see how they generalize the column name and evaluate to replicate in {cfr}. A similar column name may facilitate to visualize the relationship and flexibility of these two packages.

In the meantime, we may want to increase the visibility of the alternative observation-delay combinations. For {cfr}, IFR and HFR are only mentioned at the end of the first vignette. This can be in an exclusive vignette or howto entry. As a reference, we have a PR to include how to reconstruct the infection curve from deaths using {EpiNow2}.

@pratikunterwegs
Copy link
Collaborator

Thanks @avallecam, I'll keep this issue open for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants