A URL from Reactome database

[codewarrior2000]

Question:
What is the appropriate Biolink Model slot for a URL associated with a node?

MolePro encountered a data item called "reaction_url" (e.g., https://reactome.org/PathwayBrowser/#/R-MMU-5655466) in the database of Reactome (https://reactome.org/). [EDIT: As a Knowledge Provider, MolePro ingested the "reaction_url" found in the Reactome database and is therefore compelled to submit it to Translator as relevant node information.]

That data item corresponds to the "here" link on https://reactome.org/content/detail/R-MMU-5655466, which leads to the Reactome Pathway Browser for displaying the pathway of a reaction.

Would the xref node property slot be appropriate for conveying the "reaction_url" in MolePro's knowledge graph?

[codewarrior2000]

The discussion group in Chemical Information Working Group meeting (4/2/2024), arrived at consensus to use "xref" node property to hold Reactome's "reaction_url" (it provides a link out to the reaction diagram in Reactome's Pathway Browser, e.g., https://reactome.org/PathwayBrowser/#/R-MMU-5655466).

[sierra-moxon]

closing as completed; please reopen if I got this wrong of course! :)

[cmungall]

I assume the xref will be used to hold the CURIE, i.e REACTOME:R-MMU-5655466. Standard CURIE expansion resolves to the reactome pathway view

…

On Tue, Apr 9, 2024 at 10:30 AM Sierra Moxon ***@***.***> wrote: closing as completed; please reopen if I got this wrong of course! :) — Reply to this email directly, view it on GitHub <#1486 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOPUNWAEPDEP3WWMBZDY4QQUXAVCNFSM6AAAAABFRZPLJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBVG42DMNBTHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[codewarrior2000]

Unfortunately, I believe the standard CURIE expansion would likely resolve to:
https://www.reactome.org/content/detail/R-MMU-5655466

instead of the pathway view:
https://reactome.org/PathwayBrowser/#/R-MMU-5655466

Consequently, our discussion in the Chemical Information Working Group meeting had centered on using the xref to hold that second URL for the pathway view.

[sierra-moxon]

adding a "dot extension" prefix at bioregistry: biopragmatics/bioregistry#1085

[sierra-moxon]

It looks like bioregistry is taking a different approach to this kind of cross reference, providing a resolution service that allows for a "provider" added in the bioregistry URL, to disambiguate expansions. (see the issue above).

I don't think this helps you much, @codewarrior2000, in terms of providing a CURIE instead of the full URL in the Biolink xref slot.

So I guess I am back to our original thoughts here: that we reuse xref for this purpose, and Larry submits a URL in place of a CURIE in this slot. For discussion in the DM call today.

[codewarrior2000]

@sierra-moxon Thank you for going through all bureaucratic steps to help me out.
I followed the thread of communications with Charles Hoyt of bioregistry and I gathered that he set it up so that we can hold in "xref", a CURIE that looks like this: REACTOME.BROWSER:R-MMU-5655466. It seemed fine to me if it resolves to the URL, similar to what @cmungall posted yesterday.

Did I make a mistake in taking an overly optimistic interpretation of Mr. Hoyt's suggestion?

[sierra-moxon]

I think it would still be the same CURIE, but with two possible URL expansions depending on what you sent bioregistry as metadata for the CURIE, instead of a new prefix for the secondary page at reactome.

e.g.:
CURIE: reactome:R-MMU-5655466 (the case of the prefix is a separate issue)
expansion_1: https://bioregistry.io/reactome:R-MMU-5655466
expansion_2:https://bioregistry.io/reactome:R-MMU-5655466?provider=browser

vs. (this will not be supported)
CURIEa: reactome:R-MMU-5655466 (the case of the prefix is a separate issue)
expansion_a: https://bioregistry.io/reactome:R-MMU-5655466
CURIEb: reactome.browser:R-MMU-5655466 (the case of the prefix is a separate issue)
expansion_b:https://bioregistry.io/reactome:R-MMU-5655466?provider=browser

so if you provided just "reactome:R-MMU-5655466" (or "REACTOME:R-MMU-5655466") as a biolink:xref, we wouldn't have enough information to know which expansion to use here (expansion_1 or expansion_2 above), which was the original point of your ticket, I think. :)

you could provide: https://bioregistry.io/reactome:R-MMU-5655466?provider=browser as the xref of this identifier, and it would redirect to the page you want, and is likely a more stable URL than the direct one at reactome, but this is a separate issue than the one Chris asked, which was: will you provide a CURIE that follows the default expansion? I think we're back to the answer, "no" -- you will have to provide a URL to specifically take the user to that secondary expansion (expansion_2) page.

[codewarrior2000]

So, the original point of the ticket was MolePro's need to report Reactome's https://reactome.org/PathwayBrowser/#/R-MMU-5655466 (which we called ""reaction_url") and it will be tagged by biolink:xref. According to Charles Hoyt, the CURIE would be reactome.browser:R-MMU-5655466 for that URL.

However, I don't foresee MolePro providing reactome:R-MMU-5655466 with the biolink:xref.

[sierra-moxon]

@codewarrior2000 - no. There will be no curie with a prefix of reactome.browser.

[sierra-moxon]

from DM call:

four options:

1. xref - just use this for a collection of URLs

• keep it simple for now, no Biolink changes
• difficult for UI to interpret where to put these on a page, and what info to give a user in order to click it with preference or at all.
• xref typically is slightly different, its usually a link to a page about that object at a different site, not several different views of a particular object at the same sight.

2. a new biolink property, something like "URLs" - a collection of non-curie, non-URI, URLs with no metadata

• avoid the cross purposing of "xref", create a parallel property so we don't cross streams
• still no metadata about the URL to help UI disambiguate location or usage of URLs for users.

3. conscript a field in a TRAPI attribute object that is used to describe more about the resource (e.g. what type of page is it going to) - necessary for a prettier display/modal in the UI, also create a URLs property to hold the URLs (same as requirement 2, but give more metadata to the URL via the TRAPI language instead of biolink)

• we could use description, or source to give UI a bit more context
• it might be difficult to formalize a requirement here, and validate it. it could be that we don't have consistency.

attribute_type_id: "biolink:additional_url" <but can have many attributes with this name> 
value:  "https://reactome.org/PathwayBrowser/#/R-MMU-5655466"
description: "Reactome Pathway"
attribute_source: "infores:reactome"

attribute_type_id: "biolink:additional_url" <but can have many attributes with this name> 
value:  "https://reactome.org/client/detail/#/R-MMU-5655466"
description: Reactome Detail"
attribute_source: "infores:reactome"

Note: we will just take the first one in the UI if there are multiples.

4. create an inlined, more detailed object that has metadata about the URL (field for URL, field for "type", field for "page content description") - necessary for a prettier display/modal in the UI

• describe the URL with necessary attributes to display them in the UI effectively
• makes a more complex representation, might again need to be an edge between a "thing" and something else.
• from UI (Andy) - we need "what shows in the button"

from Tyler: we want to avoid nodes for all pubs in PubMed - needs to be an attribute not a node.