Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Transparent API towards a common graph format#373

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
iosonofabio wants to merge3 commits intoigraph:main
base:main
Choose a base branch
Loading
fromiosonofabio:transparentAPI

Conversation

@iosonofabio
Copy link
Member

@iosonofabioiosonofabio commentedMar 6, 2021
edited
Loading

Hi all,

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

importnetworkxasnximportigraphasig# Make a simple newtork in networkxnw=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 neededig.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 anigraph 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
Copy link

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
Copy link

stalebot commentedMay 22, 2021

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.

@stalestalebot added the stale labelMay 22, 2021
@ntamasntamas added todoTriaged for implementation in some unspecified future version and removed stale labelsMay 22, 2021
@iosonofabio
Copy link
MemberAuthor

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

  • manyigraph.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 monolithicGraph class

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

deftransparentAPI(function):defwrapper(graph,*args,**kwargs):# Universal input adaptergraph_type='igraph'ifisinstance(graph,nx.Graph):graph=ig.from_networkx(graph)graph_type='networkx'# Call functionres=function(graph,*args,**kwargs)# Universal output adapterifisinstance(res,ig.Graph)andgraph_type=='networkx':res=res.to_networkx()returnres

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

@transparentAPIdefbetweenness(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
Copy link
Member

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

@iosonofabioiosonofabio added the wishlistFeature request that has not been chosen for implementation yet; vote or comment to prioritize it! labelOct 15, 2022
@iosonofabio
Copy link
MemberAuthor

iosonofabio commentedOct 15, 2022
edited
Loading

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

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@vtraagvtraagAwaiting requested review from vtraag

@ntamasntamasAwaiting requested review from ntamas

@szhorvatszhorvatAwaiting requested review from szhorvat

Assignees

No one assigned

Labels

todoTriaged for implementation in some unspecified future versionwishlistFeature request that has not been chosen for implementation yet; vote or comment to prioritize it!

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@iosonofabio@dexterpratt@szhorvat@ntamas

[8]ページ先頭

©2009-2025 Movatter.jp