Network Explorer: Interaction information

[jvwong]

Description

Q: What is the name of the feature?

A: Network Explorer: Interaction information

Q: What does this feature enable the user to do?

A: Identify "at a glance" what relevant interaction evidence an article contains; provide more context. Enable users to triage articles.

Q: What information must the user provide to use the feature?

A: Select element within the Explorer network.

Q: What are the applicable constraints, e.g. compatibility or performance?

A: We've got more experience with INDRA, so look out for edge cases:

• A large number of interactions (INDRA 'statements') are returned and must be triaged
• No interactions (statements) are returned
• A large amount of papers (evidence) is returned and must be triaged
• How to deal with two types of papers/evidence:
  • No text snippet available
  • Text snippet available

Q: How does this feature affect each class of user (persona)?

A: I considered this question from a biologists point of view. It was never clear to me why articles were being displayed for a selected interaction or participant. To find out exactly why, at least in a couple of cases I followed up on, would require perhaps a few hours. It also helps to know the type of article (review, research), for greater context.

From a wider perspective, its clear that we should strive to offer information that is unique and 'sticky'. There's really interesting stuff from INDRA we're already retrieving, its just a matter of using it. By the same token, we'll be able to judge more easily when the items we're offering are of poor quality (and so will users).

Specification

Mockup

I'm using Ben/John's entry (Sorger) as a worked example: Encoding Growth Factor Identity in the Temporal Dynamics of FOXO3 under the Combinatorial Control of ERK and AKT Kinases. Cell Syst 6 2018

Case I: Evidence for interaction

Notes:

• Tell me that its a review is important and can help contextualize a text snippet

Case II: No evidence

The point here really is that if its a truly novel interaction, we should be explicit about this, rather than "back-fill" other papers into this section or view it as some failure of the approach. Just say "nothing here to see".

Details

Getting data from INDRA is mostly the same, but the changes are downstream:

• Retrieve statements from INDRA by search via participant Uniprot ID (/statements/from_agents)
• Sort statements:
  • Interaction text (template, e.g. "AKT1 inhibits FOXO3 via phosphorylation") vs.
  • English version of statement (/assemblers/english, e.g. "AKT phosphorylates FOXO3 on T32.")
• Sort evidence
  • Interaction text (template, e.g. "AKT1 inhibits FOXO3 via phosphorylation") vs.
  • Case
    • text snippet (e.g. "Knockdown of either AKT1 or AKT2 in Hella cells seems to reduce FoxO3 phosphorylation equally well [43].”)
    • no snippet: Title/abstract

Future

• Document-level related snipppets/papers
• Deep linking to document text
• Shareable links for snipppets

[jvwong]

I created a prototype in https://github.com/PathwayCommons/factoid/tree/iss937_interaction-info.

Document-level

No data changes. I felt that if we're sticking to presenting paper text (rather than images/networks, which we initially intended for the grid-view) then we have the opportunity to cleanup a bit:

Network-level

Data - This has some major-changes to the 'relatedPapers' data. Rather than just paper info, the INDRA module gathers 'interactions' along with supporting papers (evidence), which includes text excerpts. I haven't done any additional ranking with semantic search (yet), so the results are how they come out of INDRA, i.e. statements ordered by decreasing amounts of evidence.

UI - There's some good, bad and ugly here:

• Good: The text, excerpts and 'Review' badge give explicit clues to a user the reasons they are being shown this paper and determine if they are interested in finding out more
• Bad: 'Show more articles' doesn't go anywhere yet
• Ugly: Repeated excerpts. I tried to aggregate these but you can see the one below (AKT1 inhibits FOXO3) has slightly different characters in the excerpt

[maxkfranz]

Ugly: Repeated excerpts. I tried to aggregate these but you can see the one below (AKT1 inhibits FOXO3) has slightly different characters in the excerpt

There are text similarity functions that could be reused from the grounding search service. If the text is very similar, then the duplicates could be discarded.

[jvwong]

@maxkfranz I used string-similarity to reduce the redundancy in text snippets. A couple more notes about the red box:

1. Experimenting with passing datasource (e.g. Pathway Commons; red box), when it is relevant (e.g. not NLP/REACH). Related to ideas around branding, connecting data that came up around search
2. Show more articles isn't implemented but I'm wondering if this PR (to be posted) is getting too big and this should just be cut for now?

I'm gonna post a PR...

[maxkfranz]

Looks interesting. Some points to consider:

• Mobile / small screen / touch device support. This design uses a lot of horizontal space. Is it responsive? What if I'm a desktop user who wants to put two windows side-by-side on a normal 13" macbook?
• Show more articles: As a user, I don't want to click just to see a few of the best results. I just want to see them. If I want to see more than the most important ones, then I don't mind clicking.

[jvwong]

Mobile / small screen / touch device support. This design uses a lot of horizontal space. Is it responsive? What if I'm a desktop user who wants to put two windows side-by-side on a normal 13" macbook?

iPhone-size screen

• in this case the flex box just goes from row to column:

side-by-side view

• two different elements of the same network selected

Show more articles: As a user, I don't want to click just to see a few of the best results. I just want to see them. If I want to see more than the most important ones, then I don't mind clicking.

• ok, gotta think about this more

[jvwong]

On a related note: Do we need to store all of the PubMed information for each article in the database in this case?

The underlying issue is the rather large size of Rethinkdb database dumps. I think there was an old issue where we looked at the reason for the size of the docs: #939

[maxkfranz]

If the results are cached, the user sees everything in the UI immediately (Pubmed metadata, related papers, etc.). If queries are slow or unreliable, then caching helps to alleviate those issues and improve UX. Might also some parts of the app assume that all submitted docs have full Pubmed metadata? For backups, I suppose we could specifically omit cached data. However, it could be slow or problematic to requery for that info in the event that we need to restore a backup. This may be an area to use varied backup levels over time: The most recent backup may contain everything, but older backups may omit the caches. For now, is this a high priority? Disk space is cheap. Complexity and time are expensive

…

On Aug 13, 2021, at 10:37, Jeffrey ***@***.***> wrote:  On a related note: Do we need to store all of the PubMed information for each article in the database in this case? The underlying issue is the rather large size of Rethinkdb database dumps. I think there was an old issue where we looked at the reason for the size of the docs: #939 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[gbader]

This is a low priority, but a first step would be to inventory the data stored and make sure it is real/important.