No direct gene expression data for UBERON:0001264 (Pancreas) or UBERON:0002240 (Spinal cord)

[kevinschaper]

The two test queries in this Translator BTE issue look for direct gene expression to Pancreas and Spinal Cord, and we have don't currently have expression records for either. My guess is that this could be a difference in how we subset our bGee ingest, but we should look at the sourcing information that comes back from to compare

https://api.monarchinitiative.org/api/bioentity/anatomy/UBERON:0001264/genes?rows=-1&direct=true&taxon=NCBITaxon:9606

I'm also seeing expression for 139 UBERON terms right now, and it looks that expression is only for NCBITaxon:9913 and NCBITaxon:9823 - nothing for human.

[colleenXu]

Hmmm, in this query, the subject_taxon all appear to be mouse https://api-v3.monarchinitiative.org/v3/api/entity/UBERON%3A0001817/biolink%3AGeneToExpressionSiteAssociation?format=json&limit=50&offset=0

Here's the examples w/ human genes, that worked with the previous API:

• UBERON:0001817 (lacrimal gland) <-> HGNC:8548 (P4HB)
• UBERON:0002110 (gall bladder) <-> HGNC:8548 (P4HB)
• HGNC:8548 (P4HB) <-> UBERON:0000970 (eye)
• HGNC:11138 (SNCA) <-> UBERON:0001017 (central nervous system)

[colleenXu]

Querying with the base term anatomical structure (UBERON:0000061) , I only find mouse genes (taxon 10090). The response has a total of 737767.

I don't find any human genes (9606), cow genes (9913), or pig genes (9823).

[kevinschaper]

Hi @colleenXu,

I just pushed a new KG build to our development server, which also has the new ability to query by taxon & namespace, and I think it should be looking better. I'm realizing that exposing some faceting (and even pivot faceting) would really be nice to have in the api.

Here's what the new release will have for Human, Cow and Pig with predicate=biolink:expressed_in and subject_taxon=UBERON

[colleenXu]

Great! Thank you!

Will the /entity/{id}/{category} endpoint also have those querying changes? We are currently planning to use this endpoint because the hits/items have a direction field that's useful for our post-processing (knowing whether the input ID should match the subject or object fields). The association endpoint has similar responses but lacks that field.

However, being able to query by subject_namespace / object_namespace and by subject_taxon / object_taxon would also be helpful for us.

[kevinschaper]

The /entity/{id}/{category} endpoint is a little bit of a leftover from iterating on an endpoint that was intended for our UI, and I'm actually not sure that we're using it anymore - I know that we ended up not using the direction field. The good news is that everything needed to generate it is in the response.

This is he code that populates it:

def get_association_direction(entity: str, document: Dict) -> AssociationDirectionEnum:
    if document.get("subject") == entity or (
        document.get("subject_closure") and entity in document.get("subject_closure")
    ):
        direction = AssociationDirectionEnum.outgoing
    elif document.get("object") == entity or (
        document.get("object_closure") and entity in document.get("object_closure")
    ):
        direction = AssociationDirectionEnum.incoming
    else:
        raise ValueError(f"Entity {entity} not found in association {document}")
    return direction

It's a little bit of a bummer that it can't just use subject_closure/object_closure, the closure is reflexive when it's populated, but the field is only populated for nodes that come from an ontology. I'm going to be opening that code up this week for something else, so I'll see if I can address that too.

The other caveat is that the /entitiy/{id}/{category} endpoint is only intended for annotation edges, where an entity wouldn't be found in both closures, if this were used on subclass relationships, I think the entity could be in the closure for both and the directionality would come back as subject by default.

[colleenXu]

@kevinschaper

Thank you for your feedback. I looked over it again, and I think we can use the association endpoint instead.

[kevinschaper]

I just confirmed that we have expression records now for UBERON:0001264 & UBERON:0002240, so I'm closing this