-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Values returned by PFOCR as KP #838
Comments
To avoid confusion, this is distinct from the |
@everaldorodrigo put this to your plate. Feel free to create a new issue at |
Wait....I'm seeing multiple confusing points. Maybe some clarification would be useful?
|
Thanks @colleenXu. I will be the first to admit confusion. This is still not totally clear to me, so I'll rephrase my ask from scratch based on what I see today and what I hope to see. I see these two types of JSON snippets in TRAPI results containing PFOCR content, which I'm going to label 1. Analyses
Suggested:
Summary: addition of link to PFOCR website called "pfocrUrl" or whatever you like. I thought this was what we've been discussing for past few months and maybe it's already done? 2. Edge
Suggested:
Summary: Add structure to separate results as |
I think some of the prior confusion was likely caused by the fact that PFOCR result augmentation (or analyses, as you call it) is completely separate from edge lookup and doesn't involve x-bte annotation, I think maybe there was some unintended conflation of the two in prior discussion? Either way, I've added your part 1 ask to #837. BTW, result augmentation is handled by this code. |
Thanks. Yes, I thought the result augmentation was done (or decided) already and was referring to it as an example of the structure and fields we'd like to see in the edge lookup as well. |
Thanks @AlexanderPico, your post clarifies a lot! So "Part 1 Analyses" will be tracked/handled in the other issue since it's also "result augmentation". As for "Part 2 Edges"...let's discuss and track this in this issue. It'd then look like this (click to expand)
Notes to self: scattered notes in NCATS-Tangerine/translator-api-registry#132 (comment), #803 (comment), #811 (comment) However, I agree with your suggestion - that it'd be more useful/UI-friendly/organized to have a list of figure info objects, which each object including all info for 1 figure. The problem is that your suggestion isn't valid TRAPI/biolink-modeling. The So we'll need to figure out a format that is TRAPI/biolink-model compliant...which may involve discussions with UI/data-modeling/TRAPI teams. EDIT: some Slack convos happening. |
I can make the change mentioned above to add pfocrUrl to the TRAPI edge sources section, now that Translator Eel is in Prod. Would you like me to do this? Or pause/drop this effort? |
Yes, please! I think we'll want that long-term. Short-term, we might be stuffing this edge info into a support graph section so that the UI team can access it right away (i.e, before alt edge types are allowed). |
UI team is eager to work with the edge-level pathway information being returned by BTE via PFOCR as a KP. Currently, we just have a flat list of
values
including the figureUrl and PMCID. Ideally, these would be labeled more clearly or at least returned in sets per hit. And we should also include the pfocrUrl, e.g., https://pfocr.wikipathways.org/figures/PMC5463358__fnagi-09-00176-g003.htmlThe text was updated successfully, but these errors were encountered: