Hypergraph Interchange Format invitation

[colltoaction]

Hi! 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, and applied category theory libraries.

I hope you consider checking our repository where we provide the specification of a standard JSON format. Reading your docs and code, I think it would be straightforward to add to_hif and from_hif methods in the IO package. 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!

[GiulioRossetti]

Hi Martin, we'll look into it!
Thanks for the heads-up.

We are working on an in-depth rewrite of ASH: introducing something like a standard format makes totally sense.

[colltoaction]

That's awesome! I met @andreafailla at NetSci2025 and we discussed the project a little bit. Andrea, I understand you have feedback, so feel free to reach out any time. I'm also happy to help in any way with your implementation.

CC @nwlandry @FraLotito

[andreafailla]

Hi @colltoaction, it was great to finally meet you! I am working on the next version of ASH, which is mostly finalized (just needs some docs) and I plan to include support for HIF.

However, ASH works with temporal data, specifically temporal edges and nodes, with the possibility of having time-changing node attributes. For instance, imagine a face-to-face interaction dataset where hyperedges are social media discussion threads and nodes are labeled by their political leanings. In ASH, we want ro be able to track how the opinion (node attribute) of a user (node) can change as the discussions on the platform unfold (dynamic hypergraph.

I understand this might be a limit case for HIF, but if we manage to find a way to integrate this without reimagining the standard from scratch we'll have a truly universal format for temporal hypergraphs! Here's my idea.

Representing time

The first challenge is how to adequately represent time. There are several ways to do that, each with strengths and weaknesses. For instance, one could use discrete timestamps, or continuous time intervals.

The best practical solution for me is to use time intervals, which require less memory in most cases (except for particularly bursty hypergraphs). For example, a node u can be enriched with [[1, 5], [7, 9]], indicating that it is active from time t=1 to t=5 inclusive, and from t=7 to t=9 inclusive.

Integration

We could introduce optional fields in the HIF schema to specify the active time intervals for nodes and hyperedges. For instance, nodes could be represented as:

{
  "nodes": [
    {
      "node": "u",
      "attrs": {
        "active_intervals": [[1, 5], [7, 9]],
      }
    }
  ]
}

Then we could have static node attributes...

 "attrs": {
        "active_intervals": [[1, 5], [7, 9]],
        "political_leaning": "Liberal"
      }

... or dynamic ones...

 "attrs": {
        "active_intervals": [[1, 5], [7, 9]],
        "political_leaning": {
          "1": "Liberal",
          "6": "Conservative"
        }
      }

Same goes for hyperedges.

This should be the solution that provides minimal disruption to HIF, and should be backwards compatible with previous versions.

There is however another option, i.e. to have a separate optional field with temporal information

{
  "nodes": [
    {
      "node": "u",
      "attrs": {
        "political_leaning": {
          "1": "Liberal",
          "6": "Conservative"
        }
      }
    }
  ],
  "temporal_presence": {
    "nodes": {
      "u": [[1, 5], [7, 9]]
    },
    "edges": {
      "e1": [[2, 6]]
    }
  }
}

Here we have a cleaner separation between structural presence and evolving properties. In this case, it should be easier to scan/query who is "present" without parsing unrelated attributes.

The first solution, however, seems more in line with HIF's philosophy to me.
What do you think?

[colltoaction]

Thanks for coming up with these ideas already! The first one leverages the openness of the standard using a regular hypergraph and custom attributes. Following this idea, to account for the temporal network type I would promote the active_intervals attribute to a property in the JSON schema, while the domain-specific attributes stay in the attrs:

"active_intervals": [[1, 5], [7, 9]],
"attrs": {
  "political_leaning": "Liberal"
}

The second one introduces information that is not directly part of any of the entities (nodes, edges, incidences) and I would consider if that is necessary. Maybe temporality needs its own entity, I don't know :).

I will give this a longer thought, but I wanted to ask if an incidence sounds like a good place to store dynamic attributes. Incidences have the information for a specific node and edge pair, and could be extended with the active interval in the same way.

{
  "incidences": [
    {
      "node": "u",
      "edge": "e1",
      "active_interval": [1, 5],
      "attrs": {
        "political_leaning": "Liberal"
      }
    }
  ]
}

Anyways, no rush and good luck with the upcoming release!

[andreafailla]

Sorry, just realized I wrote a reply but never sent it :)

I wanted to ask if an incidence sounds like a good place to store dynamic attributes

Hmmm, that could indeed be another conservative extension of the schema. Does the incidence keep track of disconnected nodes, though? If not, we would lose info on these nodes' attributes. Perhaps let's wait for feedback from someone in the temporal network field

(edited for formatting)