SIGNOR 3.0 parser. Updated to map SIGNOR phenotypes to GO terms when …

[beasleyjonm]

Updated to map SIGNOR phenotypes to GO terms when available from their mappings. A similar mapping process can be repeated for the complexes, protein families, and stimuli terms if SIGNOR ever updates their mappings.

[matentzn]

Sorry just lurking but noticed the constants might be reversed (signor values in sgd and the other way around)

[beasleyjonm]

Oh my bad!! Thanks for catching this.

[matentzn]

Sorry I don't know enough about your project to review, I am a colleague of @DnlRKorn from an entirely different KG land.. 😂 good luck with your work!

[eKathleenCarter]

@beasleyjonm

Currently, it cannot be run as written.

1. SIGNOR-ST.csv, SIGNOR-PH.csv files are not included.
2. self.data_path not set.

Please add files and define variable

[EvanDietzMorris]

self.data_path is actually set in the init of the SourceDataLoader interface, which all parsers inherit from, and should call with super().init so that is not an issue. Maybe not the easiest to read code design but that's how it works for all them.

ORION/Common/loader_interface.py

Lines 32 to 37 in b124dfb

	if source_data_dir:
	self.data_path = os.path.join(source_data_dir, "source")
	if not os.path.exists(self.data_path):
	os.mkdir(self.data_path)
	else:
	self.data_path = os.environ.get("ORION_STORAGE")

[eKathleenCarter]

I'm not sure if we can really say "affects" here. This default predicate would be used for 3 edges in the data where the effect and mechanism are unknown (the values of which define all the predicates in the data). Therefore, we don't have any information except that these two entities are related. We could imply that they affect each other, but I was trying to avoid implications.

[beasleyjonm]

I'm not sure if we can really say "affects" here. This default predicate would be used for 3 edges in the data where the effect and mechanism are unknown (the values of which define all the predicates in the data). Therefore, we don't have any information except that these two entities are related. We could imply that they affect each other, but I was trying to avoid implications.

It's puzzling because I'm finding 979 edges that contain the "related_to" edge. I just picked one at random:
{"subject":"UniProtKB:Q8WXG6","predicate":"biolink:related_to","object":"UniProtKB:P20336","primary_knowledge_source":"infores:signor","knowledge_level":"knowledge_assertion","agent_type":"manual_agent","publications":["PMID:11809763"],"description":["Rab3A, a member of the Rab3 small G protein family, regulates Ca(2+)-dependent exocytosis of neurotransmitter. The cyclical activation and inactivation of Rab3A are essential for the Rab3A action in exocytosis. GDP-Rab3A is activated to GTP-Rab3A by Rab3 GDP/GTP exchange protein (Rab3 GEP), and GTP-Rab3A is inactivated to GDP-Rab3A by Rab3 GTPase-activating protein (Rab3 GAP)."],"species_context_qualifier":["NCBITaxon:10116"],"anatomical_context_qualifier":["BTO:0000142"],"subject_part_qualifier":null,"object_part_qualifier":null}

However, on the SIGNOR website, this interaction has the effect and mechanism listed:

Ultimately, I still prefer the "affects" predicate because it preserves the directionality of effect of the subject on the object that the original source specifies. The symmetric predicate "related_to" loses the information from directionality. This is mostly a concern for rule mining and path finding methods.

[eKathleenCarter]

I think you stumbled on a bigger problem. I completely agree with you on this example. But take a look at this:

{"subject": "UniProtKB:Q8WXG6", "predicate": "biolink:related_to", "object": "UniProtKB:P20336", "primary_knowledge_source": "infores:signor", "knowledge_level": "knowledge_assertion", "agent_type": "manual_agent", "publications": ["PMID:11809763"], "description": ["Rab3A, a member of the Rab3 small G protein family, regulates Ca(2+)-dependent exocytosis of neurotransmitter. The cyclical activation and inactivation of Rab3A are essential for the Rab3A action in exocytosis. GDP-Rab3A is activated to GTP-Rab3A by Rab3 GDP/GTP exchange protein (Rab3 GEP), and GTP-Rab3A is inactivated to GDP-Rab3A by Rab3 GTPase-activating protein (Rab3 GAP)."], "species_context_qualifier": ["NCBITaxon:10116"], "anatomical_context_qualifier": ["BTO:0000142"], "subject_part_qualifier": null, "object_part_qualifier": null}
{"subject": "UniProtKB:Q8WXG6", "predicate": "RO:0002448", "object": "UniProtKB:P20336", "primary_knowledge_source": "infores:signor", "object_direction_qualifier": "upregulates", "object_aspect_qualifier": "activity", "knowledge_level": "knowledge_assertion", "agent_type": "manual_agent", "publications": ["PMID:11809763"], "description": ["Rab3A, a member of the Rab3 small G protein family, regulates Ca(2+)-dependent exocytosis of neurotransmitter. The cyclical activation and inactivation of Rab3A are essential for the Rab3A action in exocytosis. GDP-Rab3A is activated to GTP-Rab3A by Rab3 GDP/GTP exchange protein (Rab3 GEP), and GTP-Rab3A is inactivated to GDP-Rab3A by Rab3 GTPase-activating protein (Rab3 GAP)."], "species_context_qualifier": ["NCBITaxon:10116"], "anatomical_context_qualifier": ["BTO:0000142"], "subject_part_qualifier": null, "object_part_qualifier": null}

Some how this row of data made two edges. Something else is going on here. The second edge is the one I would expect.

[EvanDietzMorris]

this looks like it has the potential to create multiple edges from the same row

[beasleyjonm]

I just submitted a commit that reverses the "related_to" -> "affects" change and also handles this section so that edges are not duplicated. Now when I parse the source it only creates 3 "biolink:related_to" edges and the duplicate case we found only creates 1 edge, as it should.

[beasleyjonm]

I think this source should be good to go for inclusion in the graph now.