SVGs are pretty cool - vector graphics in a simple XML format. They are supported on just about every device and platform, are crisp on every display, and can have embedded scripts in to make them interactive. They're way more capable than many people realise, and I think we can capitalise on some of that unrealised potential.

Anil's recent post Four Ps for Building Massive Collective Knowledge Systems got me thinking about the permanence of the experimentation that underlies our scientific papers. In my idealistic vision of how scientific publishing should work, each paper would be accompanied by a fully interactive environment where the reader could explore the data, rerun the experiments, tweak the parameters, and see how the results changed. Obviously we can't do this in the general case - some experiments are just too expensive or time-consuming to rerun on demand. But for many papers, especially in computer science, this is entirely feasible.

That line of thought reminded me of a project I tackled as a post-doc in the Department of Plant Sciences here in Cambridge. I was writing a paper on synergy in fungal networks and built a tiny SVG visualisation tool that let readers wander through the raw data captured from a real fungal network growing in a petri dish. I dug it up recently and was surprised (and delighted) to see that it still works perfectly in modern browsers - even though the original “cover page” suggested Firefox 1.5 or the Adobe SVG plug-in (!). Give it a spin; click the 'forward', 'back' and other buttons below the petri dish!

And that, dear reader, is literally all you need. A completely self-contained SVG file can either fetch data from a versioned repository or embed the data directly, as the example does. It can process that data, generate visualisations, and render knobs and sliders for interactive exploration. No server-side magic required - everything runs client-side in the browser, served by a plain static web server, and very easily to share.

How does it fit in with Anil's four Ps?

• Permanence: SVGs can be assigned DOIs just like papers, blog posts, or datasets. The fact that the above SVG still works after two decades is a testament to the durability of the format.

• Provenance: Because SVG is plain text, it plays nicely with version control systems such as Git. When an SVG pulls in external data, the same provenance-tracking strategies Anil describes for datasets apply here as well.

• Permission: Once again, with the separation between the processing in the SVG and that data that it works on, the same permissioning models apply as for data in general.

• Placement: SVGs are inherently spatial; it's very easy, for example, to make beautiful world maps with SVG.

The SVG above is only a visualisation tool for data; it doesn't really do any processing, but it certainly could. The biggest change that's happened over the 20 years since I wrote this is the massive increase in the computation power available in the browser. If would be entirely feasible to implement the entire data analysis pipeline for that paper in an SVG today, probably without even spinning up the fans on my laptop!

So this is yet another tool in our ongoing effort to be able to effortlessly share and remix our work - added to the pile of Jupyter notebooks, Marimo botebooks, the slipshow/x-ocaml combination, Patrick's take on Jon Sterling's Forester, my own notebooks, and many others - and this is a subset of what we're using just in our own group!