Topography

[knapply]

I originally planned to use the net_*() functions for topography metrics, but that now seems to turn the net-prefix into a bloated "catch-all". Thoughts on topo_*()?

Priorities w/ some proposed syntax:

• [ ] topo_*()
  • [x] order node_count() already exists... consider topo_order()
  • [x] size edge_count() already exists... consider topo_size()
  • [ ] E-I Index topo_ei_index() needs to be moved from knapply/snatools
  • [ ] density topo_density()
  • [ ] average distance topo_avg_distance()
  • [ ] diameter topo_diameter()
  • [ ] centralization topo_centralization()
  • [ ] average degree topo_avg_degree()
  • [ ] cohesion topo_cohesion()
  • [ ] compactness/breadth topo_compactness()
  • [ ] fragmentation topo_fragmentation()
  • [ ] reciprocity topo_reciprocity()
  • [ ] transitivity/clustering coefficient topo_transitivity()
  • [ ] Moran's I topo_morans_i()
  • [ ] Gerry's C topo_gerrys_c()

@cjcallag @rschroedy @dtcunning @philgroovy, feel free to chime in.

[cllghn]

I sort of like the net_* and vert_* prefixes for metrics (e.g., net_cent_degree() or vert_cent_degree()) . However, the topo_* prefix does reflect the vocabulary we use in our training/teaching, which would make it more intuitive for students that we work with.

In all honesty, I am ambivalent as all these terms make sense to me, but I do think we should take a look at how Gephi, ORA and other GUI driven platforms refer to these metrics. If the goal is to make this package intuitive, we should aim to use the most commonly used terms. Thoughts?

[knapply]

I placed a table in the README. The version on the site also links to documentation for most of the functions. It might give a better "global" perspective of my mindset.

I'm really trying to find a good balance in learn-ability/usability that avoids all the problems of the current tools... ideally before we're far enough along that changing a family of functions is really time-consuming.

I like some of the terms used in the GUIs (e.g. ORA's "fold"), but I haven't seen much else that will be useful, but I haven't looked very hard. The GUIs can just be so much more verbose.

We also have to sidestep the nightmare of network/igraph namespace issues. There doesn't seem to be any good solution to do this; If a user loads igraph after our package, it'll nuke any functions that we use... unless we violate CRAN's rules.