clickable stack bricks

[RLC-DCPPC]

On the dashboard bar charts, the individual bricks should be clickable and take the user to the relevant slice of the deriva catalog.

So it would behave more like the 4DN interface.

[RLC-DCPPC]

Joshua is working on this and Victor will integrate his work. Based on what is done in Chaise.

Queries are currently only counts. ERMrest queries grouping by column in catalog. Need machine-readable parts (namespace, project ids, vocabulary terms) rather than human-readable terms for the dashboard code so it can build query URLs.

will need iterate and double-check the counts (dashbaord vs. chaise) to fine-tune the queries.

• - Bob to add link to 4DN.

[jrchudy]

Link for 4DN:
https://data.4dnucleome.org/

[RLC-DCPPC]

From Karl on Slack:

Karl Czajkowski 4:49 PM
@mike Schor @victor @josh Chudy @Arthur Brady Regarding the dashboard query integration topic from today's call, it looks to me like we have a special case for project. Here are the query result fields we want to pass back to Josh's chaise URL builder:

• anatomy axis: anatomy_id field contains the URI-like key
• assay type axis: assay_type_id field contains the URI-like key
• data type axis: data_type_id field contains the URI-like key
• species axis: species_id field contains the URI-like key
• project axis: project_RID field contains the base64-like key (Edit: I was wrong to say this is URI-like)

this avoids having to juggle those other "namespace" fields since project is the only one of the axes that actually has namespace-qualification on its regular id column. (edited)

The fields named above are part of the query results generated from my library. If they are lost before you see the results, we need to revisit any intermediate steps that Arthur and Mike might have added between my code and the dashboard...

if Josh's api knows about these 5 axes, I think it can then combine these actual group (i.e. chart-element) specific values with the additional model-specific syntax that Chaise requires to parameterize the recordset app.

[RLC-DCPPC]

Waiting for @victor73 to start digging in to this.

[jrchudy]

@ACharbonneau is this a feature we still want to consider for the future?

It was originally opened as a "wishlist" item to include as part of epic 1 but the changes never got implemented for other technical reasons. Should we move this to epic 3 or push it to the back burner for now?

[ACharbonneau]

I think it goes on the back burner, I could see it fitting in with the personalized dashboard epic, but I don't want to overload the epic either. If you think it is small enough to go in epic 3 without being feature creep, lets do it. If not, lets back burner it.

Assuming we back burner, I don't really know that we have a place to put it/way to keep track of it. I think @lliming wants to keep the roadmap repo tracking higher level epic type stuff rather than individual features, which seems reasonable, but I'm not sure what happens to all the little orphan features

[lliming]

A bit of a side issue here, but re: tracking minor feature requests, my concern about the roadmap repo a few weeks ago had to do with my small brain not being able to filter out the smaller issues when trying to prioritize the bigger ones. It makes sense to use the roadmap repo for everything, but let's apply some consistent tags (e.g., "epic" vs "feature request") so we can use them to filter the view. I'd also love to set Zenhub up with a separate pipeline (or maybe project?) for minor feature requests so they can be tracked semi-independently from epic work.

[jrchudy]

From our discussion in the UX meeting this morning we talked more about how this might be affected when the core facts are added. The idea is that core facts would change how deriva runs a query for a facet that deriva currently can't handle.

@karlcz @ACharbonneau can either of you expand on this more from our conversation this morning.

[karlcz]

The change with core_fact is that the dimensional labels are sets of term IDs stored as an array to represent a particular combination of terms. So depending on the visualization and how much fidelity it preseves, you might have visual elements representing a set of files/biosamples/subjects with a particular combination of terms on each selected axis. E.g. anatomy terms [A, B, C] and data-type terms [X, Y].

For such a chart element, the link back would need to express a facet based on an array column being an exact match for a specific array. This is easy enough to state in the abstract, but it runs into obstacles at multiple layers of the stack:

1. ermrest does not provide an array-column = array-value operator
2. postgres and ermrest do not provide a concept of "array contains foreign keys"
3. ermrest does not provide any concept of joining records by elements of an array, e.g. to expand the set of term IDs and join each vocab term separately
4. we also don't have a UX design for showing arrays of identifiers as arrays of display values, i.e. term IDs vs term names

[jrchudy]

Related issue:
#70