Specify algorithm-level attributes (e.g., directed vs. undirected)

[annaritz]

In Pull Request #27, we changed the config file to include a directed label under each reconstruction algorithm. This is either true or false, and is used to determine whether to write summary statistics and graphspace JSON files for a directed graph or an undirected graph. This may not be the ideal way to handle algorithm-level attributes. A couple thoughts:

1. We may want to have a way to designate the input network files as directed or undirected as well. For example, the shortest-paths reconstruction algorithm could probably take either a directed or undirected graph. The algorithm's prepare-inputs would handle that according to the dataset.
2. There are cases where the output should be considered directed (e.g, visualizing a graph) and it should be considered undirected (e.g., we often compute precision-recall in an undirected manner, so if an algorithm returns (u,v) or (v,u) the two edges are counted the same way). This motivates some directed tag later under analysis -> precrec when we get that implemented.
3. There may be other algorithm-level attributes that we would want to consider. Output may be ranked or unranked (e.g., analysis should consider the set of edges, even for pathlinker, as a single subnetwork rather than a ranked list of edges). I do not know whether they should be algorithm-level or analysis-level labels, or some combination of both.

[agitter]

To add even more complexity, the input files, and possibly the output files as well, might be partially directed. Omics Integrator 1 supports PPI networks where each line is indicated as being directed or undirected. Likewise, its output can be considered partially directed if the input network was partially directed. It does not assign directions to previously undirected edges but it does retain the directionality of directed edges in the PPI network.

[agitter]

I made a branch directed-oi1 in my fork to explore supporting directed edges specifically for Omics Integrator 1. That wouldn't be the best way to do it in general, but it does give some ideas about what parts of the SPRAS code need to be modified. General support for directed edges is feasible.

We would need to agree on the input format for partially directed (mixed) graphs.

[agitter]

After the local neighborhood errors encountered in #85 (comment), I am reconsidering whether the config file is the right place to specify whether an algorithm is directed or not. The config file seems more appropriate for user-specified parameters that change during each run, like PathLinker's k. However, an algorithm producing directed or undirected outputs is a property of the algorithm. That should be tracked elsewhere and not exposed to the user or broken by the user when they change the config file.

Most likely, we want to track these properties as part of the wrapper and make it part of the PRM class.