Conversation
Co-Authored-By: Neha Talluri <78840540+ntalluri@users.noreply.github.com> Co-Authored-By: Oliver Faulkner Anderson <112665860+oliverfanderson@users.noreply.github.com> Co-Authored-By: Altaf Barelvi <altafayyubibarelvi@gmail.com>
datasets/synthetic-data/Snakefile
Outdated
| @@ -0,0 +1,100 @@ | |||
| pathways = ["Apoptosis_signaling", "B_cell_activation", | |||
There was a problem hiding this comment.
Each of the files have this variable. I think we should have it only in the snakefile and send this list to each of the files that use this pathway list
|
A question I’d appreciate feedback on: Currently, we generate separate source, target, and prize files for each pathway, but we combine all pathways into each thresholded interactome. Should we also create a combined list of sources, targets, and prizes? Should we also combine the gold standard as well? Or would it be better to keep separate interactomes for each individual pathway (keep it the way it is)? |
|
We should have separate gold standards. |
|
When this is reviewed (or before) we should do tests to see how connected the networks are after thresholding, adding back the pathway data, and removing proteins that don't have uniprot ids. |
|
Also there is a chance we can use more panther pathways, we should look to see what else we can use from pathway commons. |
|
@oliverfanderson @ctrlaltaf For the gold standard nodes (and potentially the edges), should we exclude source, target, and prize nodes when defining it? Currently, it looks like we’re including these nodes in the gold standard for each pathway. These nodes overlap with the gold standard, but that overlap should happen naturally, not by construction/being predefined. I’m concerned this could inflate our precision and recall metrics, because of a form of data leakage. |
Plan to keep all of them in the gold standard. But update the evaluation code to deal with the sources/targets/prizes being in the gold standard and shown as a different baseline where those are all set as frequency 1.0. |
|
Should we also consider how sparse an interactome becomes after applying a threshold to the STRING interactome? When we filter by size, we implicitly accounting for the decrease in graph density as well. Would it make more sense to treat size and density as separate variables when evaluating performance? However, does testing for density even matter in this context; are there any interactomes that aren’t already highly connected? I’m thinking we should first threshold the interactomes, then select only those that are highly connected (e.g., density ≥ 0.85). From that subset, we could choose a few to represent different size scales. |
|
I will be updating how we create interactomes for the Panther pathways dataset. Current: New: For example, in the STRING interaction networks, when using only physical interactions and experimental edge scores, we could aim to keep 25% of all edges.
Now we will be construct new interactomes by removing X% of edges and then adding all edges from all chosen PANTHER pathways. We will only keep downsampled interacomes that satisfy specified properties for a given set of sources and targets. Proposed brute-force method for Panther pathways interactomes:
Randomly remove X edges from the full STRING interactome
Verify that the new network maintains the following properties:
If the properties above are not satisfied, repeat the process with a different random sample. |
|
For this dataset, we are planning on using it for all of the evaluations. I was deciding if we need to use all of the pathways, and I don't think we need to. I decided on a couple that we can use: Balanced Skewed Tiny When making the interactomes, I want to add all of these pathways on the thresholded interactomes and uphold the properties above. I need to double check if I used any of these will break the rules for pilot data/runs; but since we are making a new dataset that wasn't used for my thesis, I think we will be okay. |
|
Made minor changes to fix the interactome fetching - these shouldn't cause any conflicts, nor were the changes I wanted to make as mentioned in Slack. [If they do, feel free to force push.] |
ntalluri
left a comment
There was a problem hiding this comment.
I was looking over the current state of this dataset to help with the write-up for the registered report. As I looked over it, I left a few broad questions and reminders where what I was seeing didn’t fully match my understanding of the current planned approach for the dataset. This was not a full, in-depth review.
| edges_df = edges_df.sort_values(by=["NODE1", "NODE2", "Direction"], ascending=True, ignore_index=True) | ||
| edges_df = edges_df.drop_duplicates(keep="first", ignore_index=True) | ||
|
|
||
| edges_df.to_csv(out_folder / f"{pathway}_gs_edges.txt", sep="\t", index=False, header=False) |
There was a problem hiding this comment.
Reminder: This should be updated to make a gold standard of edges that are contained in both the pathway and the specific interactome.
| prizes_df["dummy"] = "" | ||
| prizes_df.rename(columns={"uniprot": "NODEID", "prizes": "prize"}, inplace=True) | ||
| result_df = prizes_df[["NODEID", "prize", "sources", "targets", "active", "dummy"]] | ||
| result_df.to_csv(out_folder / f"{pathway}_node_prizes.txt", sep="\t", index=False, header=True) |
There was a problem hiding this comment.
Reminder: This should be updated to make the input nodes to be those that are contained in both the pathway and the specific interactome.
| pathway_df = convert_undirected_to_directed(pathway_df) | ||
| pathway_df = pathway_df[['Interactor1', 'Interactor2']] | ||
|
|
||
| print(f'Merging {pathway} with interactome...') |
There was a problem hiding this comment.
I'm assuming this isn't finished, but will you be testing for the properties that X% of the pathway edges are reachable and that X% of the pathway is in one connected component after merging the pathway into the sampled interactome?
| interactome_df = interactome_df.iloc[list(full_set)] | ||
|
|
||
| pathway_df = pandas.read_csv( | ||
| current_directory / '..' / 'processed' / pathway / f'{pathway}_gs_edges.txt', sep='\t', |
There was a problem hiding this comment.
I'm assuming this isn't finished, but will you be updating the gold standards once we have the downsampled interactomes. I’m assuming we’ll have a separate gold standard for each interactome for each pathway. The current '{pathway}_gs_edges.txt' is all of the edges in a pathway; some may not be reachable in an interactome.
|
This isn't finished. I'm going to run this for longer, but if you see the pathway.txt file generation, I haven't been able to get a connected s/t component after a concerning amount of runs. [As for your gold standard comments, I'm specifically just worried about the interactome generation, and, if I can't get a valid sampled gs after 100 runs, I'm going to further optimize interactome sampling - gold standard thresholding can be easily finished with the inner join in sampling.py] |
|
I'll use that updated TF list 👍 |
for biopax -> extended sif conversion
|
As a textual tl;dr, I need to still add I'm going to make that trim utility, split this PR to add those utilities, and merge the EGFR interactome updates and sampling using those utility scripts, then jump back to doing the BioPAX parsing. |
There was a problem hiding this comment.
Would you be able to add to the README more information on how we are downsampling the interactomes + add the psuedo code?
There was a problem hiding this comment.
Why are we providing this functionality?
There was a problem hiding this comment.
As mentioned in the comment above, I want to stop downloading PathwayCommons SIF files individually and extract them from OWL. I originally added this file as a quick exploration tool of this data, but I'll drop it once you have your list of signaling pathways from PathwayCommons and the criteria you used to fetch them, and move it over to use said automated selection.
This does not add anything to
config/*.yaml.Co-Authored-By: Neha Talluri 78840540+ntalluri@users.noreply.github.com
Co-Authored-By: Oliver Faulkner Anderson 112665860+oliverfanderson@users.noreply.github.com
Co-Authored-By: Altaf Barelvi altafayyubibarelvi@gmail.com