Identifier representation.

[jmcmurry]

Not sure if this is a back end or front end issue, but OMIM:105830 is not listed amongst the refs or IDs here, but only in the URL. https://iimpulse.github.io/monarch-ui/disease/OMIM:105830

Generally speaking, the identifiers are too prominent a feature of the page and too easily confused with content.

• [x] IDs need to be a smaller font size and grey
• [x] The primary ID should be called ID rather than reference
• [x] All of the other IDs should be listed (see OMIM issue above)
• [x] Links out where appropriate, should be shown with a linkout icon, rather than hyperlink
• [x] All IDs should redirect to clique leader
• [x] Have the neighbors panel be closable

[monicacecilia]

A few additional observations:

Synonyms

• Question: @iimpulse, @kshefchek do we know how are synonyms organized? By ‘most used?’ – if so, can/should we indicate that?

IDs

• Primary ID is listed as part of the ‘References’ (at the beginning) in the production site, which I am considering ‘source of truth.’ @jmcmurry - would you like for there to be a new field titled 'ID' and a different one with 'References?' And if so, how do we discern which terms go there? --> I imagine the term in the URI?
• It seems that the ‘References’ and ‘Equivalent IDs’ fields were transposed at some point during the process of building these pages in the beta site.
  • 'References’ should be replaced with ‘Equivalent IDs.’
  • Should have title ‘References’ instead of ‘Equivalent IDs:’ we are referencing these sources of data to assert the relation between this entry and its equivalent entry in Mondo.
• Adding @kshefchek to this conversation so he can please comment with his data perspective hat on.

Neighbours

• What happened to the 'Neighbours?' When looking at the OMIM entry, they are visible in production, but not on beta. However, when looking at the Mondo entry, the ‘Neighbours’ are visible. At some point there was a suggestion (from @mellybelly) to implement the Ontology Lookup Service (OLS) within Monarch. Can we do that? Or implement something similar to the shades and branches that are visible in the 'Neighbourhood view' in the HPO site? @iimpulse - do you have any suggestions?

[monicacecilia]

@deepakunni3 @cmungall Hi BioLink Team! We noticed a problem with the way IDs are displayed and referenced on the term pages. Please see our comments in this ticket. We had a chance to share details with @deepakunni3 during a call earlier today (thanks for joining us!).

Also, there seems to be information missing, comparing what the production site looks like, and what the latest version of beta site. Could you please help us shed some light here as well?

Compare https://monarchinitiative.org/disease/MONDO:0007113 and https://iimpulse.github.io/monarch-ui/disease/MONDO:0007113

Compare https://monarchinitiative.org/disease/OMIM:105830 and https://iimpulse.github.io/monarch-ui/disease/OMIM:105830

(please note I've used @iimpulse's ongoing commits to his build as reference - the PR is still in progress. this should be visible in beta in the next day or two)

[deepakunni3]

Things to note:

• xrefs were originally missing, and hence the 'References' entry in the new Beta page seems sparse. This will be fixed via https://github.com/biolink/biolink-api/pull/311
• There is the question of identifying what the input ID was (in this case OMIM:105830) vs the clique leader thats sent back by the API (MONDO:0007113). I am not sure what terminology to use to differentiate between the two. @kshefchek suggested input_identifier, but this needs to be handled in a generic way such that it is generalizable across all implementations.

[cmungall]

how about redirecting to the clique leader

See for example what happens if you go to https://en.wikipedia.org/wiki/TP53

[jmcmurry]

I agree that the UI should be redirecting to the clique leader regardless. I will update the ticket to include this. The neighbors panel also needs to be closeable.

[jmcmurry]

I've confirmed that the team is clear on what needs to be done.

[monicacecilia]

@deepakunni3 - do the comments here make things clearer for you?

[deepakunni3]

@monicacecilia Yes, it is clear and will definitely reduce the confusion to the users.

Only request is that there be some tooltip or some description in the page or even highlight that the user's input identifier is an Equivalent ID to the current entity page. This would explain why the user ended up on a redirected page instead of their original entity page.

[monicacecilia]

Problem:

• In description pages for disease, genes, etc., identifiers are too prominent a feature of the page and too easily confused with content.

Solutions and assignments:

• [x] IDs need to be a smaller font size and grey(@iimpulse)
• [x] The primary ID should be called ID rather than reference (@iimpulse)
• [x] All of the other IDs should be listed (see OMIM issue above) (@kshefchek ?)
• [x] Links out where appropriate, should be shown with a linkout icon, rather than hyperlink (@iimpulse)
• [x] Make the neighbors panel closable (@iimpulse)
• [x] Add one of the following: a tooltip, a description in the page, or a highlight that the user's input identifier is an Equivalent ID to the current entity page (@kshefchek or @iimpulse).
• [ ] All IDs should redirect to clique leader (@deepakunni3)

@iimpulse, @deepakunni3, @kshefchek - is it possible to move forward now?

[deepakunni3]

@monicacecilia All IDs should redirect to clique leader - this would be more of the UI redirecting to the proper clique leader. BioLink API does yields the clique leader when querying with a CURIE that is not a leader. (Unless I am missing something here)

[jmcmurry]

BioLink should have a service whereby the clique leader can be returned in response to any ID, right?

[deepakunni3]

Yes, we have a route api/bioentity/<id> that would return the clique leader as the response along with relevant metadata about the bioentity.

For example, https://api.monarchinitiative.org/api/bioentity/NCBIGene%3A84570?rows=100&facet=false&unselect_evidence=false&exclude_automatic_assertions=false&fetch_objects=false&use_compact_associations=false

gives HGNC:18603 as a response.

[monicacecilia]

We need to make a decision on whether or not we get rid of Equivalent classes and just keep References (which are actually xrefs). This needs to consider how this affects ClinGen - see monarch-app ticket https://github.com/monarch-initiative/monarch-app/issues/1632 @cmungall

[cmungall]

This is what is being shown now on beta:

References: MONDO:0007113 NCIT:C75462 ICD10:Q93.51 ICD10:Q93.5 MESH:D017204 Orphanet:72 ICD9:759.89 DOID:1932 OMIM:105830 MedDRA:10049004 GARD:0005810 SCTID:76880004 UMLS:C0162635 MESH:C531619

Equivalent IDs: UMLS:C0162635 DOID:1932 OBO:ICD10_Q93.51 GARD:0005810 MONDO:0007113 MESH:D017204 SCTID:76880004 NCIT:C75462 MESH:C531

The former are hyperlinked, the latter are not.

I suspect the former come from xrefs (represented as node properties in scigraph) the latter from owl equivalence axioms (represented as edges in SG)

I don't know why there is a self reference. Bug. Should be reported upstream. For now filter.

Clearly should only be one list. @nicolevasilevsky will write docs in mondo docs about why we provide xrefs, skos, and owl. You can also read my blog post

ACTIONS:

• [x] Keep 'References' (xrefs) field for now (as curies are correct and are hyperlinked. simple.)
• [x] Call it mappings instead (I don't know why we say "references.")
• [x] Delete 'Equivalent IDs' field.
• Report bug about self-reference on the list of entries for 'references.'

[iimpulse]

turns out there was UI code inserting the duplicate id... (didn't write it)..

Has been removed in #218 so no bug there.

[kshefchek]

@cmungall is "Mappings" meant to be disease page specific, or are you recommending we always call our xrefs mappings? I think the naming is confusing outside of the mondo context, cross references or external resources/references/links is more typical

[cmungall]

Different communities use different terms. I think mappings is pretty common but I don't have that strong an opinion.

[kshefchek]

This is potentially closable with https://github.com/monarch-initiative/monarch-ui/pull/224 merged

[monicacecilia]

Before we close:

• [x] Do we still need to do this? Add one of the following: a tooltip, a description in the page, or a highlight that the user's input identifier is an Equivalent ID to the current entity page
• [x] Is this done? All IDs should redirect to clique leader (@deepakunni3) (@kshefchek thinks this is now working).
• [x] We need to update this ticket "Understanding Equivalent Ids between Monarch & EBI OLS version of records" to let others know we got rid of the 'Equivalent ID' field.

[monicacecilia]

Done. and. done. :bowtie: