A queryable RDF dataset of the Julia package ecosystem

Tooling Package Management
, ,
1

I’ve been working on a project for work that has required me to learn about RDF (Resource Description Framework). As a part of that, I’ve been working on an RDF package for Julia and to help test it out I built an RDF dataset of the whole General registry. It includes every package, its dependency network, GitHub metadata (stars, licenses, topics, activity), download stats, and the people who commit to it. I created a couple of pages you can explore:

  • A short report of the findings: the most load-bearing packages (direct vs. transitive dependents), how GitHub stars line up against dependency importance (not much), where widely-depended-on packages have gone inactive, contributor reach, and the shape of the dependency core.
  • A live SPARQL explorer that runs entirely in your browser: the full ~864k-triple graph loads client-side, so you can run the example queries or write your own. Every result links straight to the JuliaHub, GitHub, and license page it came from.

It’s a single snapshot (July 2026) and fully open — the pipeline and dataset are in the repo. I don’t think there are really any surprising findings, but I thought I’d post this here in case anyone is interested in exploring this “knowledge graph” of Julia packages.

2

This looks really cool! However, you may want to consider renaming it as there is already an old, unmaintained package called RDF.jl on the Julia package registry. Perhaps SemanticWeb.jl?

Edit: Never mind, that package appears to be gone!

3

One question I have is: why did you go with the hexastore architecture, as opposed to a native graph architecture such as that used by GraSS? (Granted, that is for a persistent database which is not what you’re building… but perhaps a native graph implementation is still possible without permutations?)

The namespacing syntax for IRIs is very clever; nicely done! Feels very ergonomic. I will have to play with it.

4

One question I have is: why did you go with the hexastore architecture, as opposed to a native graph architecture such as that used by GraSS? (Granted, that is for a persistent database which is not what you’re building… but perhaps a native graph implementation is still possible without permutations?)

So I should start off by saying I had never even heard of an RDF triple just a couple of months ago :laughing:. As I alluded to above, I’ve been working on a data interoperability challenge at work (that I think RDF can solve) and I didn’t want to have to use Python’s rdflib, nor did I want to use Rust’s oxigraph just to learn/experiment/iterate. When looking at different options, it seemed like the hexastore approach would give me the most general-purpose/flexible library that could accommodate a wide variety of queries with O(\log n) time complexity. Also, my goal up front was a fully W3C compliant library with an integrated SPARQL engine, and to test against the thorough W3C test suite which contains a large variety of triple patterns, and the hexastore looked like a natural fit for that. I also have included Graphs.jl support, so if you need to run traditional graph algorithms or do deep traversals across the graph, you have that option too.

I tried to mitigate the memory cost of the hexastore by storing UInt32 term IDs rather than the full RDF terms in the six indexes, but this package is still very raw and there is a ton of room for optimizations. If anyone else becomes interested, or if I continue to use it regularly over the medium-/long-term, I’ll definitely continue working towards optimizations and then I might eventually register it!

5

This will still have to be renamed. We don’t accept 3-letter package names in the General registry anymore