Add network methods

[asizemore]

Resolves #232

Added methods for networks and versions for bipartite networks where appropriate. Required for getting data into a network.

[d-callan]

what all are we trying to accomplish w this pr?

Ill say this.. it seems some things that still need doing, here or somewhere else, are:

1. an easy way to get data from tab or json into these classes
2. an easy way to write them to json
3. a way to generate x and y coords for nodes where needed
4. probably other stuffs

does that list make sense? is that what this pr is for?

[asizemore]

I think 1 and 2 fits into this PR. 3 is a can of worms that i'm not sure i'm ready to open yet. 4 also yes - this PR was originally about creating methods that help validate a network and get it into/out of good formats. So in addition to what you have, i'd say things like

• removing duplicate links. This should be an optional check because sometimes duplicate links are intentional
• removing duplicate nodes. I can't imagine us ever wanting duplicate nodes
• I think i alreayd have one for pruning isolated nodes
• we should have a converter into/out of whatever format igraph, etc, wants
• we also talked about converting into/out of matrix or df format for this PR a long while back.

That's a long list so breaking it up into a few PRs is also cool.

[d-callan]

do we want to remove duplicate links and nodes? or just validate for them? the nodes at least it seems we just shouldnt allow that case, and then wed never need to remove them. for the links, i think id like to hear more about when wed intentionally include dups

[asizemore]

yeah validating makes sense for nodes.
For links we could also do validation and leave incorporating of multiple links as a growth area. The someday use case is let's make a network with genes as nodes and links based on coexpression values. Two genes may be coexpressed at the same level in two different experiments. That suggests two edges between the links, each with the same edge weight. In that situation one could argue that we'd find a way to also encode the two different experiments as metadata on the edge. That's possible but that info could get thrown away because it doesn't matter for whatever the question is. So there's a possibility we have two edges that are the same but we don't want to combine them, we want to consider them as two edges.

[asizemore]

My most pressing questions are around the api - how much do we want to change, and how much can we reasonably change before the release?

Additionally, I think we need to give the linkColorSchemes a bit more thought on how we protect someone from making something nonsensical with link colors that are any float but the color scheme says "posneg" for example.

Finally, we added a bunch of methods but i think the coverage on testing is pretty low. Given how much testing we'd really want to add it's probably better if we make a separate PR to increase coverage.

If we do decide to push for the api change before 67, i'm okay with making new issues for the other changes and starting those after the api change is done

[d-callan]

ill make a separate issue for test coverage, and we can make a list of things wed like to test there and decide whats a good time to do that. everything else i think i addressed today.

im also in process of updating the api here to match the data service, and write bipartitenetwork explicitly if we know we have two partitions for the kpartite network. thatll be in here as well.

[asizemore]

I can't approve a PR i co-authored but if i could i would! 🎉