Feature Request: Allow bind_ard to account for context.

[kieranjmartin]

What's the feature?

Currently if you try binding two "identical" (same groups, variable and stat name) ards using bind_ard you get an error unless you use .update=TRUE and then you end up with just the first one.

But there are situations where I may want to bind ARD's which are "identical".

For example; two regressions with different covariates or even just two summaries with different filters. E.g.

library(cards)
library(dplyr)

ard <- ard_tabulate(ADSL, by = "ARM", variables = "AGEGR1")
ard_filter <- ADSL |> filter(SEX == "M") |> 
  ard_tabulate(by = "ARM", variables = "AGEGR1") |> 
  mutate(
    context = "Filtered on SEX == M"
  )

bind_ard(ard, ard_filter, .update = TRUE)

I could use the grouping level in this example, although this could be a pain and maybe even an abuse of the system in some cases (imagine I filter on 4 or more variables).

Imagine where I have a piece of code where I derive a bunch of identical ARDs for different subgroups. I could of course save them as different ARDs, but then imagine I am doing this for say 30 different outputs, I end up with 30*subgroups ards to go through!

In the ARS specification there is an additional column which covers the filter I am creating, but I think the simplest thing here might be to allow bind_ard to have a new argument like consider_context=FALSE where if set to TRUE it will consider two otherwise identical ARDs with different contexts to be considered distinct.

[ddsjoberg]

Let me think on this before we make an update. I think these arguments could be more clear and more flexible.

In the interim, you can just use dplyr::bind_rows()?

[ddsjoberg]

Whether data set info is something we ever include in the ARD is something yet to be decided. The full ARS model does not place it in the ARD, but I feel the appetite for the full ARS metadata model is less compared to ARDs and I could see a bit of shuffling happening in the future.

[kieranjmartin]

"In the interim, you can just use dplyr::bind_rows()?"

Yes absolutely. I do think this situation is common enough that it might be useful (e.g. I exclude/include strata variables as part of a sensitivity analysis)

Yes at the moment I am mainly looking at ARD (partially because I find the ARS quite hard to parse fully anyway) and finding these kinds of limitations.

[ddsjoberg]

The context column is just something I added to provide, well, more context about the ARD; it's not a part of the ARS model FYI. For that reason, I am more reluctant to begin building infrastructure around it this added column. I think we'd all be better served to come together on a solution that is perhaps more comprehensive than that added column. My feeling at the moment is that a better solution would be including some kind of information about the data set and any filtering.

A couple of other thoughts

1. ARDs don't need to be stacked. They can exist in unstacked data frames or lists quite nicely.
2. We provide helper functions for common tasks, e.g. stacking ARDs and checking that we have not lost identifyabilty while stacking. These are primarily simple wrappers for dplyr or tidyr operations. Since we are just working with data frames here, I often find myself using tidyverse functions over the helpers when my needs are slightly different.
3. If you'd like to join our collaboration and attend our biweekly meetings, please shoot me an email and I can get you added to the list.

[kieranjmartin]

That makes sense. I guess I am looking for a solution beyond the context for sure.

I understand the ARS model but I am not sure I completely agree with it; in particular from my understanding it calls for each ARD to have a unique output id associated with it, but I'm not sure that should be the case; I might expect a particular output to be a combination of multiple different ARDs in practice, which is why I like embedding the information in the ARD itself.

You are right that probably the context column may not be sufficient. In particular I think that I would like to include both the filtering information and the model context. I know you currently capture the latter as additional rows but I don't find that completely satisfying as a solution.

Finally to your note on ARDs not needing to be combined, you are right of course but then I am essentially relying on the name of the object to provide this additional information when I need to select something programmatically. I am also imagining saving these ARDs to disk in which case I might want to collate at least some of them to avoid having hundreds of the things littering my file space. It's true I suppose I could save them as a list, but then I would be tying myself to an R specific data format which I don't know if I want to do.