Skip to content
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

Workflow B problem #260

Closed
cbizon opened this issue Aug 27, 2021 · 5 comments
Closed

Workflow B problem #260

cbizon opened this issue Aug 27, 2021 · 5 comments

Comments

@cbizon
Copy link
Contributor

cbizon commented Aug 27, 2021

See ranking-agent/aragorn#26

@patrickkwang
Copy link
Contributor

We can take a look at this again after the ICEES KPs are registered at TRAPI 1.2.

@patrickkwang
Copy link
Contributor

This is the query in question:

{
    "message": {
        "query_graph": {
            "nodes": {
                "n0": {
                    "ids": [
                        "MESH:D056487"
                    ],
                    "categories": [
                        "biolink:DiseaseOrPhenotypicFeature"
                    ]
                },
                "n1": {
                    "categories": [
                        "biolink:DiseaseOrPhenotypicFeature"
                    ]
                }
            },
            "edges": {
                "e01": {
                    "subject": "n0",
                    "object": "n1",
                    "predicates": [
                        "biolink:has_real_world_evidence_of_association_with"
                    ]
                }
            }
        }
    }
}

It works when sent to ICEES DILI directly, but not through Strider.

@patrickkwang
Copy link
Contributor

The identifier that ICEES prefers for DILI is DOID:2044. It seems to accept both the DOID and the MESH just fine. The problem is that the node normalizer knows DILI as a biolink:Disease, and we replace the categories for n0 with ["biolink:Disease"]. ICEES returns 0 results when we do this, regardless of which CURIE we use. Sending both categories appears to work. So there are at least two possible solutions:

  1. Strider sending the provided category and/or all relevant biolink categories (all the way up the tree).
  2. ICEES handling biolink:Disease here the way we'd like it to.

I think we should definitely do 2, and perhaps 1 also. I will make an ICEES issue. What do folks think about how Strider handles qnode categories? Two specific questions:

  • What should we do about categories provided when ids are also present? Currently we ignore them and replace with node-norm results.
  • Should we provide upstream categories (e.g. biolink:DiseaseOrPhenotypicFeature for nodes with biolink:Disease)?

@cbizon
Copy link
Contributor Author

cbizon commented Oct 4, 2021

This is a good question. My feeling has been that if we're sending a curie then we should not (need to) send any categories at all. But I think that not all KPs were ok with that.

Fundamentally, this seems to be an ICEES problem, and I don't think sending parent categories should be done...

@patrickkwang
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants