Redirect IDs to clique leader

Question

Redirect IDs to clique leader

Opened this issue 7 years ago · 4 comments

Per @jmcmurry, for example https://monarchinitiative.org/disease/OMIM:154700 would redirect to https://monarchinitiative.org/disease/MONDO:0007947

Answer 1 · 2017-12-19T00:55:27.000Z

Just thinking out loud here...

I assume that monarch users have been sharing and bookmarking and perhaps even citing our URLs for a while, so we are under some obligation (IMHO) to maintain our URL structure. There is more than one way to solve this, I think.

A redirect (full resolve) is the easiest way for us to solve this, and get it off our back. But not necessarily the most user-friendly.
Retaining the original info that we no longer ingest, and displaying it the way we used to, has pros and cons, but mostly cons (it is not DRY). Users might never bother discovering MONDO if they can get usable info from the DOID/OMIM pages.
We could build something I'll call a 'partial resolve', where we avoid changing the URL like in a full resolve, but we deliver the user to the resolve target (e.g., MONDO). But we observe the URL and highlight (to the user via some UI styling) that they arrived at the One True MONDO page via a non-MONDO route, and we give them the option of completing the resolve (changing the URL bar and removing the 'highlight'), or they can just get the info they need from the MONDO page that has the pre-resolved URL.

The last option is pretty easy to do, but I'm not sure it would be valuable, or even worth further discussion. It's just a different way to get across the idea of multiple names/IDs for the same thing, which will forever be a part of our problem space (no matter how many times we try to unify on a bigger ontology).

Answer 2 · 2017-12-19T00:58:05.000Z

These are good points. But I would want to ask if we think a lot of users are relying on URLs for individual items as a part of their processes or are just relying on the main URL? I do not have a sense of the scale of the problem ?

…

-Peter Peter Robinson Professor and Donald A. Roux Chair, Genomics and Computational Biology The Jackson Laboratory for Genomic Medicine 10 Discovery Drive Farmington, CT 06032 860.837.2095 t | 860.990.3130 m peter.robinson@jax.org<mailto:peter.robinson@jax.org> www.jax.org Robinson lab: https://robinsongroup.github.io/ New Book: Computational Exome and Genome Analysis<https://www.crcpress.com/Computational-Exome-and-Genome-Analysis/Robinson-Piro-Jager/p/book/9781498775984> The Jackson Laboratory: Leading the search for tomorrow's cures

________________________________ From: Dan Keith <notifications@github.com> Sent: Monday, December 18, 2017 7:55 PM To: monarch-initiative/monarch-app Cc: Subscribed Subject: Re: [monarch-initiative/monarch-app] Redirect IDs to clique leader (#1530) Just thinking out loud here... I assume that monarch users have been sharing and bookmarking and perhaps even citing our URLs for a while, so we are under some obligation (IMHO) to maintain our URL structure. There is more than one way to solve this, I think. * A redirect (full resolve) is the easiest way for us to solve this, and get it off our back. But not necessarily the most user-friendly. * Retaining the original info that we no longer ingest, and displaying it the way we used to, has pros and cons, but mostly cons (it is not DRY). Users might never bother discovering MONDO if they can get usable info from the DOID/OMIM pages. * We could build something I'll call a 'partial resolve', where we avoid changing the URL like in a full resolve, but we deliver the user to the resolve target (e.g., MONDO). But we observe the URL and highlight (to the user via some UI styling) that they arrived at the One True MONDO page via a non-MONDO route, and we give them the option of completing the resolve (changing the URL bar and removing the 'highlight'), or they can just get the info they need from the MONDO page that has the pre-resolved URL. The last option is pretty easy to do, but I'm not sure it would be valuable, or even worth further discussion. It's just a different way to get across the idea of multiple names/IDs for the same thing, which will forever be a part of our problem space (no matter how many times we try to unify on a bigger ontology). - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://github.com/monarch-initiative/monarch-app/issues/1530#issuecomment-352605733>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEtuPDe6uA54q42Cbv1sYdJlVwOIx0u6ks5tBwmAgaJpZM4RCc3T>. --- The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible.

Answer 3 · 2017-12-19T02:00:47.000Z

I think I implemented the redirect originally, following wikipedia's lead, e.g. https://en.wikipedia.org/wiki/Telencephalon

I like the partial resolve. It feels more RESTful, I don't think we'd have an API call redirect, we would just explain in the packet that this is what you queried for, this is what we're giving you, and this is our justification.

Answer 4 · 2018-02-26T19:10:35.000Z

Any updates on this? I think it would be great if the overview page info was the same. I like this example: https://monarchinitiative.org/gene/HGNC:1101 vs https://monarchinitiative.org/gene/NCBIGene:675