Closed saramsey closed 3 years ago
Makes me wonder if this is due to the merge step. So I did a grep:
grep -c NCBIGene:113839523 kg2-*.json
kg2-chembl.json:0
kg2-dgidb.json:0
kg2-disgenet.json:0
kg2-drugbank.json:0
kg2-ensembl.json:0
kg2-go-annotation.json:0
kg2-hmdb.json:0
kg2-intact.json:0
kg2-jensenlab.json:0
kg2-mirbase.json:0
kg2-ncbigene.json:1
kg2-reactome.json:0
kg2-repodb.json:0
kg2-smpdb.json:0
kg2-unichem.json:0
kg2-uniprotkb.json:0
Since the kg2 build hasn't finished yet, you don't have kg2-ont.json
in your grep. The Biolink category of that node is most likely being overwritten by this line:
https://github.com/RTXteam/RTX/blob/525c362b0a9fb4dcf82ad8f025a0e3fd0936bbd5/code/kg2/curies-to-categories.yaml#L19
Thank you, @ericawood!
Do you think it would be preferred to have multi_ont_to_kg_json.py
node categories favored least in the merge process?
Actually I think biolink:Gene
seems correct here. A record in NCBI Gene, I suppose, is documenting the gene. In the case of NCBIGene:113839523
, it so happens that the gene encodes a microRNA (hsa-miR-11400), and that can be encoded in various ways like using a has_gene_product
relationship to a separate node representing the microRNA. But I think maybe we should change L118 of ncbigene_tsv_to_kg_json.py
to hard-code the Biolink category in that case (a microRNA) to be biolink:Gene
. https://github.com/RTXteam/RTX/blob/525c362b0a9fb4dcf82ad8f025a0e3fd0936bbd5/code/kg2/ncbigene_tsv_to_kg_json.py#L118
That change should have no affect on KG2, since KG2 currently has no nodes in it with category biolink:MicroRNA
(I've checked). But it is better if we set it to the proper and accepted Biolink category in ncbigene_tsv_to_kg_json.py
, so we are not relying on the merge to overwrite the category with the "correct" category (which I guess should be biolink:Gene
). Does that make sense?
Clearly, this is not an urgent matter. It can absolutely be rolled into KG2.6.1.
Do you think it would be preferred to have
multi_ont_to_kg_json.py
node categories favored least in the merge process?
Good question. One could argue that via curies-to-categories.json
, we have fairly fine-grained control over the Biolink category assignments for concepts that arise as nodes in kg2-ont.json
, and furthermore, that the CURIE to category assignments in that file can in principle be validated against the Biolink metamodel. So I guess maybe it is good that kg2-ont.json
is loaded first. What do you think?
In the ETL script mirbase_dat_to_kg_json.py
, we may not want to use biolink:same_as
as the relation between an NCBIGene and a miRbase record. If the miRbase record is describing a microRNA, it might be better to use biolink:has_gene_product
with the NCBIGene as "subject" and the miRbase microRNA node as the "object".
That change should have no affect on KG2, since KG2 currently has no nodes in it with category biolink:MicroRNA (I've checked).
The original change to biolink:microRNA
was made after KG2.5.2 was rolled out. Thus, there may be some nodes in KG2.6.0 from NCBIGene that have the category microRNA
. (See https://github.com/RTXteam/RTX/issues/1220#issuecomment-801292107)
If the miRbase record is describing a microRNA, it might be better to use biolink:has_gene_product with the NCBIGene as "subject" and the miRbase microRNA node as the "object".
@saramsey Should we do the same for HGNC? Current edge example:
{
"id": "miRBase:MI0000060---biolink:same_as---HGNC:31476---identifiers_org_registry:mirbase",
"negated": false,
"object": "HGNC:31476",
"provided_by": "identifiers_org_registry:mirbase",
"publications": [],
"publications_info": {},
"relation": "biolink:same_as",
"relation_label": "same_as",
"subject": "miRBase:MI0000060",
"update_date": null
},
HGNC:31476
: https://www.genenames.org/data/gene-symbol-report/#!/hgnc_id/HGNC:31476
Thank you @ericawood for pointing this out.
Yes, I think so. At least in KG2.5.2, all HGNC nodes are of category biolink:Gene
.
So in the above example, if the node miRBase:MI0000060
has category biolink:MicroRNA
, then the edge should be changed so that the subject is HGNC:31476
, the object is miRBase:MI0000060
, and the relation is biolink:has_gene_product
.
As a general rule, I think, if two nodes in KG2 have different categories, they should probably (ideally?) not share a biolink:same_as
edge (I'm shuddering at the thought of someone running an empirical check for how many edges in KG2 violate that rule-of-thumb, however, LOL).
I couldn't help myself. I ran
match (n)-[r:`biolink:same_as`]->(m) where n.category <> m.category return count(*)
There's uh, a lot of them. Like, over 200k. Sigh.
For starters, looks like the DrugBank ETL is connecting a bunch of nodes of category MolecularEntity
to node of category ChemicalSubstance
:
match (n:`biolink:MolecularEntity`)-[r:`biolink:same_as`]->(m:`biolink:ChemicalSubstance`) where head(r.provided_by) = 'identifiers_org_registry:drugbank' and n.category <> m.category return count(*)
That might be worth checking out, and if you feel it is fixable, maybe opening an issue on.
In KG2.7.1:
match (n {provided_by: 'identifiers_org_registry:ncbigene'}) where n.full_name starts with "microRNA" return n.category, count(n)
n.category | count(n) |
---|---|
"biolink:Gene" | 1915 |
This issue appears to be fixed (and probably has been fixed for a while).
There is probably a simple explanation for this. Mostly likely I've just forgotten, in my old age. But I could use a refresher. So in
/home/ubuntu/kg2-build/kg2-ncbigene.json
onkg2lindsey.rtx.ai
I see the following JSON blob for the node with IDNCBIGene:113839523
:But somehow, in the KG2.5.2 Neo4j, the node's Biolink category has changed to
biolink:Gene
: