Always show the landing box with "Interactions" button

[IgorRodchenkov]

As you might know, we're in process of submitting Pathway Commons links to UniProt (linkout).
We want them use our search app URL template: http://apps.pathwaycommons.org/search?q=%u that will be soon pointing to the new landing page with the gene info box (see appsbeta/pathwaycommons.org).

The problem is that there are cases when we have some data for a UniProt ID, but it does not match any pathways (and this is normal); so, the result is empty:

http://appsbeta.pathwaycommons.org/search?q=A0A075B6K4&type=Pathway
(though there are matching BioPAX entities: http://www.pathwaycommons.org/pc2/search?q=xrefid:A0A075B6K4)

Also, &type=Pathway parameter seems to matter not at all (which is in fact great for the linkout).

I suggest we always show the landing box with "Interactions" button, regardless any pathways found or not. UniProt team, as a rule, do not want to link to search pages or no-data pages...

@logmosier @d2fong @jvwong @gbader

[IgorRodchenkov]

Refs #695

[jvwong]

@logmosier correct me if I am wrong, but isn't this the intended behaviour of the current (development branch) info box?

By the way, the above example breaks the search in the latest dev #703.

[logmosier]

This is not the intended behavior but the reason the box is not showing up is because A0A075B6K4 does not have a NCBI id not that there are no search results. The landing box with display if there are no search results .

To fix this I could add a fall back so that if there is no NCBI id we fetch the data from Uniport but there would still be cases where Uniprot ids would not get caught as it looks like g:profiler does not recognize them:

[jvwong]

Using the validator service (api/gene-query/), I can map from A0A075B6K4 to HGNC:5897, but not to NCBI Gene from either point.

[IgorRodchenkov]

One could use physical_entities.json <http://www.pathwaycommons.org/archives/PC2/v9/physical_entities.json.gz> file which we use in the apps already I suppose to find HGNC Symbols by UniProt IDs and vice versa, given a physical entity from PC9. The other way, using PC web services, one could find a EntityReference (URI) by ID: http://www.pathwaycommons.org/pc2/search?q=xrefid:A0A075B6K4&type=entityreference and then use a traverse PC query such as: http://www.pathwaycommons.org/pc2/traverse?path=XReferrable/xref/id&uri=http://identifiers.org/uniprot/A0A075B6K4 or http://www.pathwaycommons.org/pc2/traverse?path=XReferrable/xref&uri=http://identifiers.org/uniprot/A0A075B6K4 PS: This is not a general-purpose ID-mapping but the "mapping" hack, based on our actual BioPAX model, pathway data out there. Igor R.

…

On Mon, Apr 23, 2018 at 3:13 PM, Jeffrey ***@***.***> wrote: Using the validator service (api/gene-query/), I can map from A0A075B6K4 to HGNC:5897, but not to NCBI Gene from either point. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#702 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8fwbJNr9vD5MH40ij7IV9_EnB5mcvfks5trifsgaJpZM4TgMy5> .

[jvwong]

Proposing this fall-back strategy for query parameter that is a single token:

1. Try app-ui validator service for NCBI Gene or UniProt
2. Try PC webservice search/traverse

[IgorRodchenkov]

Interesting. I have one concern/doubt (perhaps somewhat off-topic) and a suggestion. Concern: let's make sure we keep it simple and nothing "too smart" stays between user query strings and PC search web service (full-text search); so we don't fool ourselves and loose search power trying to improve it... I believe this has not yet become problem. Suggestion (idea): what if we simply make the app (apps/search) understand special single ID queries like 'q=uniprot:P12345' or 'hgnc:NOG'? This could much simplify all the troubles and help integrate PC links into UniProt, NCBI, GeneCards. IR.

…

On Tue, Apr 24, 2018 at 1:28 PM, Jeffrey ***@***.***> wrote: Proposing this fall-back strategy for query parameter that is a single token: 1. Try app-ui validator service for NCBI Gene or UniProt 2. Try PC webservice search/traverse [image: smart search 1] <https://user-images.githubusercontent.com/4706307/39203484-eb7e81b6-47c2-11e8-8639-237363bf1332.png> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#702 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8fwfd3NdXB5U6wR92bkWWXiJq9pA7Vks5tr2CsgaJpZM4TgMy5> .

[jvwong]

Re: Suggestions. That would make life easy.

Re: Concern. As far as I understand, we only use the id-mapping for the purposes of setting the lucene prefix (i.e. xrefid). It was my suggestion to always use the original user's input for the query to PC for pathways. The interactions is another story - @logmosier ?

[logmosier]

Re: Concern. That is correct the id for the search is only used for the purpose of the lucene prefix (i.e. xrefid) for the search. For the interactions currently the id used for fetching the information for the landing box is used though that is mainly to make it easier to get information for the additional information panel the interaction viewer itself can use any id that would return a result from PC graph.

[jvwong]

From discussion this morn:

[logmosier]

The only issue I could see with this is that right now we only fetch from uniprot or ncbi so even if it has the db:id format if the db is neither of those then we would still need to get an id to use to fetch the data.

[jvwong]

Let's think about these for now:

1. NCBI Gene
2. UniProt
3. HGNC

As far as I know, HGNC and NCBI Gene are generally well coordinated.