Open vanaukenk opened 4 years ago
Inferred hierarchy or asserted placement? I would think inferred would be more useful. Perhaps also add logical definition.
I agree that inferred would be preferred here.
Adding the logical definition could be very helpful for understanding relations to use for contextual information.
Here is a (rough) demo of the ZFIN term box : https://drive.google.com/file/d/1c2_DG0Z4hC35RiBpUmY6Oj-D9xmX8sYD/view?usp=sharing
the term synonym, definition, children and parents are available. I am sure it wouldn't be difficult to add the logical definition. Also, one can navigate and explore the ontology, and directly select the term to be used for annotation. Please let me know if you need more information or if you have questions. (note: curators LOVE this text box as it is easy to use and very practical when making annotations)
Prita would probably be the best person to talk to for technical questions.
@vanaukenk @ukemi @tmushayahama
Thank you so much @sabrinatoro for making the video. I really love this. Not only the definition, but the workflow too of exploring the ontology in an efficient way of drilling down/up the terms and swapping the term without leaving the page or multiple copying and pasting. Yes, this is awesome. I like that it shows the term with "do not annotate" note than removing/hiding it from the dropdown. What happens if you continue to annotate it? What does the obsolete terms say on the term box?
tag @vanaukenk @ukemi
@tmushayahama If you use the "do not annotate", you would not be able to save the annotation, and you get a message saying that annotations to this terms are not allowed. obsolete terms are the same: there is "obsolete" in the term name, and there is a "obsolete term" tag, and you are unable to save if you pick this term.
Probably of use for such a term box would be the taxon constraints ?
It's also at least partially similar to the go term page we wanted to introduce in the alliance.
@sabrinatoro could you ask if it is pure javascript or if it's a framework (angular/react/vue) component ? is there any published library (npm, GitHub) ?
[EDIT]: also which data endpoint are you accessing to populate the term box ?
we developed it internally using GWT. there is no published library yet
And which data endpoint are you using to fetch the data ? Is it updated at the same time as a go release ?
The gene ontology is updated daily in our local ZFIN database. so my answer would be yes!
That may actually be an issue as the public facing of GO rely on the monthly release, not on the snapshot - note those snapshots can be inaccurate as we use them to track errors during the month and before the release.
I have never seen problems with the ontology. For curation purposes, using snapshot seems ost appropriate.
I LOVE the zfin termbox!
(nit picking aside: it's good to show incoming links but choosing the inverse property is confusing, e.g it shows "hemopoiesis has-part myeloid cell differentiation". Formally there is a difference between all hemopoiesis has-part some MCD and all MCD part-of some hemopoiesis. While this is a constant source of confusion and it doesn't really affect 99% of curators, there will be situations in future when it is beneficial for being able to see the actual has-parts, eg building templates)
Yes, we should show inferred direct. E.g. exactly what we place in the release version of GO (the linked ticket above from Kimberly is about inferring the informative direct links for TCs)
We should be able to support anything that is expressible in obographjson format https://github.com/geneontology/obographs -- this includes TCs, and logical definitions that do not employ nesting (which is fine for GO). Rendering should be trivial.
It would be useful to have a standalone js lib that renders obographjson as html. We have a lib for rendering graphviz, that is not required here (yet?) but the lib should be part of the same suite https://github.com/cmungall/obographviz/
@tmushayahama - great to have the basic term info box available in the Noctua form! For future work, let's work out how to show a tree display more like what is visible in AmiGO or other ontology browsers, so the is_a hierarchy is preserved.
Here's an example:
@tmushayahama
Testing this one, I'm wondering if if would be possible to make each ontology term in the pop-up box a link that would open up that term in the window so curators could look at the information for another term before selecting which one to use.
The main idea here is that curators would like to browse the ontology terms to make sure they're selecting the right one, so we need to make that easy for them.
I'm not sure what you mean here @vanaukenk. I can scroll down the autocompletes and open up each term. Potential scope creep, but would this be a useful place to display a logical definition or maybe asserted relationships? I don't think it would add much more to the superclass report that's already there.
Never mind. I see what you are saying.
We are getting circular inference in some of the type of lists. Choose to create a BP and type limb morphogenesis. Expand the term info and it is listed as a type of limb morphogenesis.
Display of the logical definitions came up on the 2021-11-01 ontology call. I think @sierramoxon checked whether it was possible to get this via the API and the answer was yes? If that's true, let's discuss the feasibility of adding this info to the term box.
Moving this out of the current project. This feature needs some additional work, but we can discuss and map out requirements in future work.
We could make a new ticket strictly to deal with the ontology display.
Suggestion from the 2020-05-12 GOC meeting:
In addition to the link out to AmiGO, for example, display a window that shows a term definition and placement in hierarchy as part of the autocomplete functionality.
@sabrinatoro @tmushayahama