How to visualize dynamics on/of networks
SPaTo Visual Explorer allows to define multiple “versions” of the same data, which can be browsed using a slider. This can be used to explore dynamical processes on networks (by providing a series of snapshots of data to be used for node coloring), but also to visualize dynamical processes of networks (by providing multiple weight matrices). The following text briefly describes how to define these snapshots in the data file. Please make sure you know how to prepare data files before proceeding.
Snapshot series (dynamic node coloring data)
Let's assume we have a food web (the nodes are different species and the links tell us who eats, or gets eaten by, whom) and data on the abundance of all the species in some area which we choose to use for node coloring:
<data name="Population Size"> <values>800 14000 350 120 ...</values> </data>
Now, if we happen to have time-resolved population data, we can add multiple values elements to data, each wrapped into a snapshot element:
<data name="Population Size"> <snapshot label="May 2005"><values>800 14000 350 120 ...</values></snapshot> <snapshot label="Nov 2005"><values>750 18000 340 125 ...</values></snapshot> <snapshot label="May 2006"><values>775 15000 330 75 ...</values></snapshot> <!-- ... omitted ... --> </data>
When this data is selected for node coloring, SPaTo will display a slider that can be used to browse through the different snapshots. The label attribute is used to identify the currently displayed snapshot. We can also use keyboard shortcuts to browse through the snapshot series.
Snapshot albums (dynamic network structure)
To visualize a dynamic network we need to define multiple snapshots of the weight matrix. However, the naive approach of just supplying multiple snapshot elements within links would not work since different weight matrices produce different shortest-path trees and thus the data in slices has to be organized into corresponding snapshots as well. Furthermore, node coloring data might also depend on the weight matrix (e.g., node degree or strength). Thus, there needs to be a mechanism to link snapshots of the different data types together. That's where snapshot albums come into play. Let's look at the document.xml of a data file that, rather than supplying a dynamical network, provides two different views on the aviation system:
<?xml version="1.0" ?> <document> <title>US Aviation Network (seats or flights)</title> <description> Network is symmetrized Self-links have been removed Reduced to largest connected component (containing 459 of 467 nodes) </description> <album id="wf" name="Weight Matrix"> <snapshot id="w" label="Scheduled Seats" /> <snapshot id="f" label="Scheduled Flights" selected="true" /> </album> <nodes src="nodes.xml" /> <links src="links.xml" /> <slices name="SPT"> <snapshot album="wf" id="w" blob="spt_w" /> <snapshot album="wf" id="f" blob="spt_f" /> </slices> <dataset src="nodeprops.xml" selected="true" /> <dataset src="dist.xml" /> </document>
Note the album element in the middle. The value of the id attribute will be used to refer to this album from within the data file, and the name attribute is used to label a slider that SPaTo will display for this album. The album element must contain a number of snapshot elements, which also have an id attribute that allows to refer to them later. Note that all snapshot elements are empty: no data is defined in album, just the available snapshots.
The actual data is specified in their usual location, wrapped inside snapshot elements that refer to those inside the album. Here is the links.xml:
<?xml version="1.0" ?> <links> <snapshot album="wf" id="w"> <source index="1"> <target index="14" weight="5947" /> <target index="25" weight="73226.6" /> <!-- ... omitted ... --> </source> <!-- ... omitted ... --> </snapshot> <snapshot album="wf" id="f"> <source index="1"> <target index="14" weight="313" /> <target index="25" weight="1367.33" /> <!-- ... omitted ... --> </source> <!-- ... omitted ... --> </snapshot> </links>
As we can see, the contents of the links element (multiple source elements) have been duplicated for each available snapshot and wrapped into a snapshot element, which identifies itself with one of the snapshots defined in the album using the album and id attributes. If you scroll up, you'll see that the same happens inside the slices element in document.xml, where the data for different snapshots is provided in different binary files:
<slices name="SPT"> <snapshot album="wf" id="w" blob="spt_w" /> <snapshot album="wf" id="f" blob="spt_f" /> </slices>
Finally, the album is also referenced in nodeprops.xml:
<?xml version="1.0" ?> <dataset name="Node Properties"> <data name="Node Degree"> <colormap log="true" /> <values>16 4 48 ... 2 4 3</values> </data> <data name="Node Strength"> <colormap log="true" /> <snapshot album="wf" id="w"><values>664815 143073 4926070 ... 82972 13237 115232</values></snapshot> <snapshot album="wf" id="f"><values>13722 3513 47322 ... 2238 86 3379</values></snapshot> </data> </dataset>
The “Node Degree” is unmodified, as in this example only the link weights happen to differ between the two snapshots, but not the link structure. The “Node Strength” does define different data for the two snapshots however, again by wrapping the values element into a snapshot element that identifies itself with the correct snapshot in the album.
As you may have guessed already, when the user changes the slider displayed for the album, all data elements (links, slices, node coloring data) that define snapshots for this album will update their data accordingly. In theory it is possible to define multiple albums (for example, one album “passengers vs. flights” and another album “pre-9/11 vs. post-9/11”), but this is currently not supported by the user interface (i.e., there will only be one slider for the first album).