questions about dynamics specifications

Hi Skye,

Beforehand I have to say that the papers on SoNIA helped us directly to choose how to encode dynamical data. This is the most accurate work we found at this time, and it led to the GEXF specifications as well. Thank you again for the great work!

"Much of the dynamic network data I work with does not use actual dates for its time coordinates. Often it is simulation time ticks. SoNIA represents times as doubles. It would be possible to translate these to dates in an arbitrary way, but seems it might be a little odd for the data model to suggest to a user that the time coordinates are dates if they are not. Thoughts about the best way to encode this? Or if the spec could be extended to permit non-date time values?"

Doubles will be available on GEXF 1.2, which is currently on discussion here: http://forum.gephi.org/viewtopic.php?f=19&t=554
and there: http://forum.gephi.org/viewtopic.php?f=19&t=477
Your feedback and proposals are of course welcome!

"Do the viz attributes support dynamics?"

It will be the case on GEXF 1.2.

"Tho it may yield somewhat similar functionality, I think the "slice" concept as implemented in GEXF seems substantially different that what I used in SoNIA. In SoNIA a slice is a "bin" which contains nodes, edges, (and attributes). Slices are explicitly allowed to overlap, and entity durations effectively "expand" to match the duration of the slice. From what I understand about slices in GEXF, they sound more like what I would call "intervals" or "spells": non-overlapping bounded units of time which specify node or edge activity.

SoNIA was designed to facilitate two different ways of looking at time when aggregating events into a network:

a) events (nodes, edges) have durations, a "slice" is something close to an instant in time
b) events are instantaneous, and a "slice" has a duration, a window or bin of time to aggregate events into a network."

Yes we used the other approach because a network can be a hierarchy, and we wanted to preserve the readability of the graph structure when editing the XML by hand. If I remember well, the other reason was about parsing performances in Gephi.

"It is usually possible to translate from one representation to the other, but sometimes one approach seems more natural for the underlying data model. Since I'm trying to figure out how to store in GEXF, it would be great if you could point me to some more reference about Gephi's explicit or implicit data model for aggregating a static network from a dynamic one to create a view or perform analysis on a network."

Gephi's data model has no documentation but the Javadoc: http://www.gephi.org/docs/api/
This is a pity and we should fill in the related pages on the wiki. It is planned, but you know... :)
The data model was primarily designed to create a responsive Timeline component: http://forum.gephi.org/viewtopic.php?f=7&t=566
Anyway, don't hesitate to ask for it on the forum! This will motivate Mathieu or Julian to write them.

"On a slightly different topic, if I do use GEXF as SoNIA's storage framework, I'll need to be able to represent and store various parameter settings. Do you think the best way to do that would be to create a custom name space to add additional elements to the graph? Presumably other programs would then simply ignore the elements when they parse the file?"

Yes exactly. Private namespaces are just ignored by parsers. The "meta"tag is the right place to store the application settings.

"Again, thanks for all the great work, GEXF seems like one of the best XML specs I've seen so far."

Thanks again, you are always welcome to take part in the discussions about the GEXF and its evolutions!

Hi,

Thank you so much for coming and discuss GEXF here, the work done on SoNIA has greatly inspired us. Let me know if you have any code question regarding GEXF export, I would be happy to help.

The way how we implemented dynamics is indeed different from SoNIA. The main difference is that we attach the time information to the nodes and edges themselves instead of creating a container, a bin in your case. As you mentionned it, that results in having intervals for each element. This choice was oriented by implementation, as I tried to minimize the ammount of information. Moreover, the aim was to be able to know very fast, for each element, if it is included in a particular range of time to show or hide it. I found it easier to attach an Interval Tree to each element instead of looking into events. This choice was quite low-level and caused quite a lot of difficulties to implement, but from the low-level you get maximum flexibility, and as we wanted to support all cases, that was probably worthed.

In other words, there is no slice concept implemented in Gephi, everything is converted in intervals. However, the DynamicAPI is listening to all data change and keep a consistent index of all intervals, so it is able to keep the list of bounds, as well as min and max. I hope I'm clear, it's hard to explain I must say, if you prefer I could explain this through Skype :-)

If you didn't saw this, it has some info: http://wiki.gephi.org/index.php/Import_Dynamic_Data

The concept of intervals make good sense for storing attributes, for example a stock price attached to a node. What do you think?

Regarding viz attributes, though they are part of the 1.2 specification Sebastien is preparing, the feaure is not developed in Gephi yet. Thought it is extremely attractive feature for users, it requires to change quite a lot of things in the current Gephi code and risks to hurt performances too much. I also wanted to keep the core simple and have dynamic features as an add-on. Didn't found the best way to do that yet.

I found this discussion extremely relevant, it's really not easy to think what is the best solution to encode dynamic network and data and be able to read it and share it in the best way, so I'm really happy we get two different experience here.