Distribution variables don't exist yet in diverWeb/diverRPC

[Viqsi]

See subject. I've not yet incorporated distribution variables in diverRPC, and therefore they won't show up in diverWeb - mostly because I'm not entirely sure how we want them added in. As a completely separate variable type? Embedded within normal search results?

If they're meant to be completely separate from interview variables, that will require some UX work...

[Viqsi]

In discussing this on Skype @WValenti suggested the possibility of adding them as, in effect, a "giant additional interview", and prefixing variables with DIST_ or something to that effect (like CAPS and FLOW). This would be a "include with the interview variables" solution, and would neatly avoid UX design concerns (so it would make me happy :) ).

[Viqsi]

Discussed in a meeting and we have a general consensus to go with the "additional interview" approach.

[WValenti]

This will be integrated with the user group-specific "- ALL individuals -" approach, which is collection-release aware, i.e. there will be multiple distribution "instruments" corresponding to the collection and release. For example, a DiverWeb user who is authorized to access SZ r13 and BP r9 (yes, I'm making this up, and the 'r' prefix prevents confusion with study numbers), would have their "- ALL individuals -" linked to the set of ind_ids present in those two collection releases. As a consequence, the set of distribution "studies" that they could access from DIGS_cleaned.kibble would be only SZ r13 and BP r9. The upshot is that all accessible distribution variables are as available and treated identically to any actual study-specific interviews that the SZ r13 and BP r9 individuals are in.

[WValenti]

Veronica has noted that we need to retain the capability of displaying summary information that is not limited by the restriction to authorized collection releases. This can be achieved by explicitly using resultSetId 1 (truly all individuals) for summary statements and breaking the summary down by collection-release.

[Viqsi]

Veronica has noted that we need to retain the capability of displaying summary information that is not limited by the restriction to authorized collection releases. This can be achieved by explicitly using resultSetId 1 (truly all individuals) for summary statements and breaking the summary down by collection-release.

There's a part of me that would like (and attempted to suggest at the time) the idea of having "shadow individuals" that show up in place of folks that people don't have access to yet "but if only you signed up, you could have these people".

But that might be putting lots of effort into what's basically our marketing scheme for not enough return.

[WValenti]

I'm wondering if it makes sense to allow the user to query either 1) what they can access, or 2) everything we have, whether they have access or not, but re-deidentified to uselessness.

[Viqsi]

Has this been taken care of now? I had the impression that we'd put them in by means of adding Distribution Variables as another "instrument"; don't know if that work is done or not.

[WValenti]

I can be closed. We did add them as another set of instruments, one per collection.

On Mon, Sep 5, 2022 at 7:06 PM Jo Valentine-Cooper @.***> wrote:

Has this been taken care of now? I had the impression that we'd put them in by means of adding Distribution Variables as another "instrument"; don't know if that work is done or not.

— Reply to this email directly, view it on GitHub https://github.com/MathematicalMedicine/diverweb-issues/issues/19#issuecomment-1237515178, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA52M5EOHZ7V7QPXP6IF7WLV4Z4F7ANCNFSM5P3RJOKA . You are receiving this because you were assigned.Message ID: @.***>

[Viqsi]

So let it be written, so shall it be done. Closed as completed in the database.