[FEA] Hypergraph Interchange Format invitation

[colltoaction]

Hi!

I was pointed to this project by cugraph and I'm excited about the potential for collaborating with you rapidsai/cugraph#4853 (comment). Watching @lmeyerov on YouTube I understand there is high interest in Hypergraphs from Graphistry as well :).

I'm Martín and I'm a developer working in the HIF project, an effort to share hypergraphs across many libraries, developed by members of HyperNetX, XGI and other established libraries. We are looking to expand the community actively reaching out to higher-order network analysis, topological deep learning, applied category theory, and other relevant libraries.

I hope you would consider checking our repository where we provide the specification of a standard JSON format. This format is meant to support use cases such as the HyperNetX interop seen in this repo. There are so far 4 implementations, each one with its tutorial. I hope this standard will be a solid foundation for researchers to collaborate.

Let me know what you think and any way I can help make this happen!

[lmeyerov]

Hi @colltoaction !

1. The most immediate thing I can imagine is updating our existing hypernetx tutorial (3yr old) and porting the tutorial's to/from method to a natively supported one, and same for HIF files

• pygraphistry hypernet tutorial: https://github.com/graphistry/pygraphistry/blob/master/demos/demos_databases_apis/hypernetx/hypernetx.ipynb

• sample recent pr to expose methods natively: https://github.com/graphistry/pygraphistry/pull/622/files

If you or someone on your team can assist with updating the hypernetx tutorial / add a HIF one, we can help shepherd the follow-up of exposing bindings natively.

2. I can imagine additional interactions after, like tutorials showing analytical benefits in both directions for representative use cases. Whenever We talk about event data and log data, we often do have a hyper graph perspective, so I would be especially curious If there is something helpful we can show there!

3. Fwiw Longer term, a parquet/arrow serialization format variant of the same component in the spec would likely match up well to the performance goals of our users, or lacking that, jsonl. I think the overall spec would still stand. The hypernetx users of ours would care about the sort of thing As they already use such formats for this reason, and that would align well with the goal of interop for CPU and GPU acceleration.

[colltoaction]

Thank you for your interest and quick reply 🙏🏻

1. I will update the tutorial and get back to you.
2. Every integrated library has their own interesting features! I'm sure you will benefit the most from [Temporal Hypergraph Analysis].(https://arxiv.org/abs/2302.02857).
3. It sounds really interesting. Our approach is currently based on attributed nodes, edges and incidences, the documents are validated by a JSON schema, and it should be straightforward to provide serialization alternatives.

[lmeyerov]

Thanks, will look out for it

If it ends up HIF from/to is different enough from the hypernetx helper, I would not be surprised if we want to seperate to/from hypernetx (library binding to python object) from to/from hif (file IO)

[colltoaction]

That's something I've been thinking about a lot. Each library uses and needs a specific Python data structure, usually on Pandas, NetworkX, PyTorch. It seems to me it would be great to have a shared structure and I'm starting a HIF<->NetworkX library with that purpose. Our team has started a discussion with the NetworkX authors in this regard.

https://github.com/colltoaction/nx_hif

[colltoaction]

Minimal working example 🚀

• https://github.com/colltoaction/pygraphistry/blob/master/demos/demos_databases_apis/hypernetx/hypernetx.ipynb
• https://github.com/pszufe/HIF-standard/blob/main/tutorials/data/e-coli.json