dynamic graphs and time formats

[duncdrum]

@mbastian wrote

• Add a “timerepresentation” enum in : The value would either be “interval” or “timestamp”. Interval would the default so we’re backward compatible. This configures the way the time is represented and we choose not to mix the two so it's needs to be explicitly set.
• Add a “timestamp” attribute to : This allows to define a timestamp for the entire graph. That’s the corner stone of supporting collections of GEXF files where each is a slice with a timestamp value. Essentially, it means that each element in the graph exists at this timestamp. If the attribute columns are dynamic we would also set values at that time.
• As we want a “timestamp” attribute for we should revisit the meaning of the “start” and “end” attributes in as well. Right now, they define the dynamics' bounds but that could be inferred from the data as well by taking the min and max so I don't think it's very useful. Instead, it could define the interval for the entire graph like the new "timestamp" would do.
• Add a “timestamps” attribute to node/edge: Add an array of timestamps. Each of the element in the list should follow the format agreed on in "timeformat".
• Add “timestamp” to : Defines a unique time 't' for this attribute value.
• Add "timezone" configuration: Timezone can be defined as part of the timestamps themselves (e.g. 2015-01-01T13) but it should be possible to define a global timezone if this is omitted. By default, we would use the local user timestamp.
• consistency between intervals and timestamps: Both time representation should have the same feature. If we allow to define "timestamps" on elements we should also allow "intervals". Similarly if we keep the concept for intervals we should add support for timestamp spells as well.

[duncdrum]

@mbastian I have a few questions about this:

• Slices should be defined by timestamps only? or do you want to allow grouping separate files by something like semantic versioning as well?
• I m not sure what you mean by "unique time 't' for this attribute value" could you post an xml example and explain what the schema is supposed to do, or what it represents in the graph?
• I would leave "start" and "end" alone, especially with the new possibilities for multi-graphs they are a straight forward but fine-grained way of controlling the temporal dynamics of individual elements
• just to be clear we force the user to choose either stamp or interval within the scope of "timerepresentation". Does this mean we allow for nested graphs to have different timerepresentations, or not?
  • is the idea here that timestamp is exclusive so that elements only exist if explicitly defined at a certain timestamp, and that intervals continue to be inclusive so that for missing values we assume +inf?
• after thinking about it I m now more inclined to follow the spells paradigm. Arrays actually get to messy

[mbastian]

• Slices can be defined by a unique timestamp but also by a unique interval, represented by two bounds start and end. One of these start or end can be omitted and if that's the case start becomes -inf and end becomes +inf. Then, I'm not sure what you mean be grouping separate files.
• For attribute values, I meant something like this:

<node id="n0" label="Bob">
    <attvalue for="0" value="true" timestamp="2000" />
</node>

As you can see, the value true is set for a unique timestamp with value 2000.

• What exactly do you mean with "I would leave "start" and "end" alone", can you clarify?
• Yes we don't allow intervals and timestamps to be mixed and the user has to explicitly define what representation is used. By nested graphs you mean hierarchical graphs? If yes, we can't allow any interval+timestamp mixing here either.
• Yes intervals always allow the user to omit one bound, either start or end, which is then replaced with -inf or +inf. Also, note the parser can also recognizes -inf, -infinity, inf and infinity for these bounds so start=-inf works for instance.

[duncdrum]

Ok I have a few more days before crazy starts again, I'll reference commits in my branch in here.