Transparent API towards a common graph format

[iosonofabio]

Hi all,

I am trying to explore the possibility of adding an API layer that lets networkx/graph-tool/<your choice of tool> folks use igraph functions transparently, e.g.:

import networkx as nx
import igraph as ig

# Make a simple newtork in networkx
nw = nx.Graph()
nw.add_node('first')
nw.add_node('second')
nw.add_edge('first', 'second')

# Compute incidence and adhesion in igraph, and convert the result into networkx conventions if needed
ig.TransparentAPI.incident(nw, 'first')
--> [('first', 'second')]

ig.TransparentAPI.adhesion(nw)
--> 1

(The example above works on my laptop)

The vision is that this could be the first step towards a more consistent graph manipulation format as discussed with cytoscape and networkx folks online and as of Dexter's recent email.

This particular PR would not do much towards efficiency: the graph is converted into an igraph object, operated upon, and the result is converted back. However, it might lower the barrier towards an efficient shared protocol by exposing the rocky outcrops of various designs.

What do you guys think? If we are on the same page we can hear what external people are thinking from their end.

[dexterpratt]

This is an interesting concept. We have a slightly different set of use cases since the role of our CX format is network exchange and the "NiceCX" object is for convenient management but not for analysis. Our users typically want to get a network, create an Igraph or NetworkX graph, use it, and then save results in CX. The tricky parts are (1) managing the parts of the CX document that don't translate and (2) preserving the CX node and edge ids (which are supposed to be persistent).

The transparent API approach makes me think of something like this:

The CX from the server becomes a "portable graph"

pg = get_pg_from_ndex(url_of_a_public_network)

pg encapsulates the CX with an igraph object and/or networkx object.

ig.TransparentAPI.incident(pg) works. There is no back conversion until needed.

something like

ndex.upload(pg)

also works - converting the igraph at that time. All of the graphic style attributes, network metadata, etc. of the CX have been preserved.

ideally, the users can also perform networkx operations on the same portable object.

Does this make sense?
Dexter

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[iosonofabio]

This has been stale for a while, but a few things are happening in the background that are perhaps worth logging here:

• many igraph.Graph methods have been de facto delegated to functions in separate modules
• @ntamas is working on a new implementation of the whole Python interface that will hopefully be less centered around a monolithic Graph class

Those are relevant because once the functions that provide implementation are decoupled from the Graph class, one could in principle add a decorator to all of them along the lines of

def transparentAPI(function):
    def wrapper(graph, *args, **kwargs):
        # Universal input adapter
        graph_type = 'igraph'
        if isinstance(graph, nx.Graph):
            graph = ig.from_networkx(graph)
            graph_type = 'networkx'

        # Call function
        res = function(graph, *args, **kwargs)

        # Universal output adapter
        if isinstance(res, ig.Graph) and graph_type == 'networkx':
            res = res.to_networkx()
        return res

and one would then wrap any function that we want to be part of this API as:

@transparentAPI
def betweenness(graph, ...):
    ...

In practice, for now the actual functions are often hidden from the user because we do not want to confuse the user with two ways of performing each operation (method and function) without broadcasting about this shift in attitude beforehand. However, that is more of a decision making issue than a technical one by now, and we could start piloting this API anytime.

[szhorvat]

@iosonofabio Before you proceed with this, it should be discussed at the next meeting. There was in fact discussion about this in your absence.

[iosonofabio]

Sounds great, happy to hear things are moving and looking forward to rejoining the conversation!