Add data integrations

[nwlandry]

This pull request

• Adds support for directly loading datasets from AHORN and Hypergraphx-Data.
• Breaking change: Removes the read option from load_xgi_data
• Breaking change: Removes support for the old XGI JSON format.
• Breaking change: renames request_json_from_url to request_from_url and request_json_from_url_cached to request_from_url_cached to handle more cases.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[nwlandry]

Hey @leotrs, @kaiser-dan, @maximelucas --- before I invest time into making tests pass, etc., does something like this make sense to add to XGI?

[leotrs]

@nwlandry direction-wise, yes, I think this makes sense and matches where we've been heading in general (v1.0 pushes XGI as the hub, ecosystem packages around it). AHORN and Hypergraphx-Data are the two most obvious external hubs to first-class support, so this is the right pair to start with.

A few things worth thinking about before you dig in on tests:

1. Maintenance contract. Each external-service reader is a coupling point: if AHORN or hgx-data change their URL structure, index format, or dataset schema, we break. Worth pinging their maintainers to (a) confirm they'll keep the current interface stable or at least tell us before changing it, and (b) offer to add a mention to their READMEs that we load from them. That gets the relationship into their heads for future changes.

2. Failure mode when hosts are down. These readers should fail loudly at call time, never at import time. Quick to check but easy to accidentally get wrong.

3. Coordination with refactor: mark read_json/write_json as internal helpers (#697) #738. refactor: mark read_json/write_json as internal helpers (#697) #738 marks the public read_json/write_json as internal (rename to _read_json/_write_json). This PR still imports write_json in download_xgi_data and doesn't touch the public functions themselves. Whichever merges second will need a small rebase. Not blocking, worth flagging.

4. Scope of the "old XGI JSON format" removal. I read this as "stop supporting the pre-HIF format in the load path", which is consistent with everything we've been doing. Just want to confirm we're not also removing read_json/write_json as public functions here (that's refactor: mark read_json/write_json as internal helpers (#697) #738's job and there's a separate deprecation story around it).

5. Renaming request_json_from_url → request_from_url. Straightforward and better. If it was ever public, worth a deprecation shim; if it's underscored/internal-by-convention, just rename.

So: green light on the direction, worth thinking about 1 and 2 as part of the "make tests pass" work, and 3-5 are easy tactical items.

[nwlandry]

Thanks @leotrs! I think I will close this and then split off two separate PRs: one for removing support for the old JSON format and read capability in load_xgi_data and one for these integrations.

[nwlandry]

This is addressed with #759 and #757.