<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Displaying Time in Link Graphs</title>
	<atom:link href="http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/feed/" rel="self" type="application/rss+xml" />
	<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/</link>
	<description>Log visualization and log management as seen by Raffael Marty</description>
	<lastBuildDate>Tue, 15 Jun 2010 07:44:14 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bob</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-16095</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Thu, 05 Feb 2009 03:00:56 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-16095</guid>
		<description>Here&#039;s a quick example using a single color showing initialization time.

http://img11.imageshack.us/img11/2064/testxn3.gif

And another showing start/end time.

http://img18.imageshack.us/img18/7630/testrg4.gif

Not perfect, but not bad either...16-20 is probably the max usable gradients.</description>
		<content:encoded><![CDATA[<p>Here&#8217;s a quick example using a single color showing initialization time.</p>
<p><a href="http://img11.imageshack.us/img11/2064/testxn3.gif" rel="nofollow">http://img11.imageshack.us/img11/2064/testxn3.gif</a></p>
<p>And another showing start/end time.</p>
<p><a href="http://img18.imageshack.us/img18/7630/testrg4.gif" rel="nofollow">http://img18.imageshack.us/img18/7630/testrg4.gif</a></p>
<p>Not perfect, but not bad either&#8230;16-20 is probably the max usable gradients.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-16094</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Thu, 05 Feb 2009 01:58:45 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-16094</guid>
		<description>A simple variation of what Cappella posted above makes sense to me.  Using a simple grayscale model with 16-32 levels would likely be usable without cluttering the graph.  The question is how to assign the colors...there seem to be several reasonable approaches that are likely to have widely different levels of implementation complexity.

1 - A simple linear scale, with time broken into n intervals and links colored based upon the interval in which they were started.  Black is most recent (freshest) and lighten over time.

2 - A logarithmic scale, like the above, with greater resolution for recent events.

1/2a - A variation of either of the above where duration of the link is encoded by a gradient in the line...the originating side encoded with the start time, and the destination side encoded with the end time (up to and including black for current).

3 - A &#039;node relative&#039; scale, with each node having links colored based upon the sequence/time that the link was established with the node relative to other links to the node.  Would be screwy to look at, but might provide good sequencing information when looking at things like outbreaks.  Gradients may be required here as well to properly encode the sequence.

This approach could be used for the node itself as well by coloring the border to indicate when it was introduced to the graph.

Great stuff.</description>
		<content:encoded><![CDATA[<p>A simple variation of what Cappella posted above makes sense to me.  Using a simple grayscale model with 16-32 levels would likely be usable without cluttering the graph.  The question is how to assign the colors&#8230;there seem to be several reasonable approaches that are likely to have widely different levels of implementation complexity.</p>
<p>1 &#8211; A simple linear scale, with time broken into n intervals and links colored based upon the interval in which they were started.  Black is most recent (freshest) and lighten over time.</p>
<p>2 &#8211; A logarithmic scale, like the above, with greater resolution for recent events.</p>
<p>1/2a &#8211; A variation of either of the above where duration of the link is encoded by a gradient in the line&#8230;the originating side encoded with the start time, and the destination side encoded with the end time (up to and including black for current).</p>
<p>3 &#8211; A &#8216;node relative&#8217; scale, with each node having links colored based upon the sequence/time that the link was established with the node relative to other links to the node.  Would be screwy to look at, but might provide good sequencing information when looking at things like outbreaks.  Gradients may be required here as well to properly encode the sequence.</p>
<p>This approach could be used for the node itself as well by coloring the border to indicate when it was introduced to the graph.</p>
<p>Great stuff.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dustin Burke</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-14097</link>
		<dc:creator>Dustin Burke</dc:creator>
		<pubDate>Tue, 09 Dec 2008 17:36:29 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-14097</guid>
		<description>For animation approach, checkout &lt;a href=&quot;http://en.wikipedia.org/wiki/Force-based_algorithms&quot; rel=&quot;nofollow&quot;&gt;Force-based Algorithms&lt;/a&gt; that address the issue you raised concerning the instability of incremental updates.  I&#039;d suggest you checkout &lt;a href=&quot;http://www.cs.princeton.edu/~traer/physics/&quot; rel=&quot;nofollow&quot;&gt;Traer Physics&lt;/a&gt; particle system engine for &lt;a href=&quot;http://processing.org&quot; rel=&quot;nofollow&quot;&gt;processing.org&lt;/a&gt; visualization language and environment.  If you are doing forensics on past data, then you can better position the addition of incremental updates because you&#039;ll know what the future connectivity of that node will be.  This will let you determine a better initial location that reduces the springiness of the animation.  Maybe this is what you meant by &quot;time-based layout&quot;?

The temporal coloring approach could work for showing long-term changes but you&#039;re right it isn&#039;t good for discerning between individual changes due to human visual &quot;just noticable difference&quot;.  Color could be used in an animation to highlight the new additions and then have the color fade away as time marches on.  

As for adding time-dimension, there are at least two things you might try.  Why confine yourself to 2d plot when you could visualize 3d plot with time as the z-component?  But sticking with 2-d, choosing a single node as the center of gravity, you could have concentric circles to show the propagation of time and incremental node additions would appear within a time band.  As you mention though, these only work well for smaller graphs as the edges will clutter the view (and look like a tangled spider web :)

A lot depends on the specific objective of what you&#039;re trying to visualize and the insights you&#039;re hoping to glean from such a visual.

Cheers.</description>
		<content:encoded><![CDATA[<p>For animation approach, checkout <a href="http://en.wikipedia.org/wiki/Force-based_algorithms" rel="nofollow">Force-based Algorithms</a> that address the issue you raised concerning the instability of incremental updates.  I&#8217;d suggest you checkout <a href="http://www.cs.princeton.edu/~traer/physics/" rel="nofollow">Traer Physics</a> particle system engine for <a href="http://processing.org" rel="nofollow">processing.org</a> visualization language and environment.  If you are doing forensics on past data, then you can better position the addition of incremental updates because you&#8217;ll know what the future connectivity of that node will be.  This will let you determine a better initial location that reduces the springiness of the animation.  Maybe this is what you meant by &#8220;time-based layout&#8221;?</p>
<p>The temporal coloring approach could work for showing long-term changes but you&#8217;re right it isn&#8217;t good for discerning between individual changes due to human visual &#8220;just noticable difference&#8221;.  Color could be used in an animation to highlight the new additions and then have the color fade away as time marches on.  </p>
<p>As for adding time-dimension, there are at least two things you might try.  Why confine yourself to 2d plot when you could visualize 3d plot with time as the z-component?  But sticking with 2-d, choosing a single node as the center of gravity, you could have concentric circles to show the propagation of time and incremental node additions would appear within a time band.  As you mention though, these only work well for smaller graphs as the edges will clutter the view (and look like a tangled spider web <img src='http://raffy.ch/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>A lot depends on the specific objective of what you&#8217;re trying to visualize and the insights you&#8217;re hoping to glean from such a visual.</p>
<p>Cheers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sp3ar0</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-14093</link>
		<dc:creator>Sp3ar0</dc:creator>
		<pubDate>Tue, 09 Dec 2008 17:02:34 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-14093</guid>
		<description>oops....
http://www-star.stanford.edu/projects/relay/images/rc1-2.gif</description>
		<content:encoded><![CDATA[<p>oops&#8230;.<br />
<a href="http://www-star.stanford.edu/projects/relay/images/rc1-2.gif" rel="nofollow">http://www-star.stanford.edu/projects/relay/images/rc1-2.gif</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sp3ar0</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-14092</link>
		<dc:creator>Sp3ar0</dc:creator>
		<pubDate>Tue, 09 Dec 2008 17:02:11 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-14092</guid>
		<description>I used to do some work with RF Spectral analysis and we had a tool that displayed a 3D plot with Amplitude over Frequency and the 3rd dimension was the timestamp. You could replay, reverse, spread, narrow, turn, etc. It was good for a large dataset from say 0Hz up to 10Ghz and any strange occurances are cleary seen. Apply the same concept to port over ip and time. The depth of the view allows you to see back in time or as you replay that line comes into the front view...not sure if I explained that clearly enough, but I&#039;ll try and code a demo to show what I mean. 

Similar to this but replay/interaction with data is a must:


Sp3ar0</description>
		<content:encoded><![CDATA[<p>I used to do some work with RF Spectral analysis and we had a tool that displayed a 3D plot with Amplitude over Frequency and the 3rd dimension was the timestamp. You could replay, reverse, spread, narrow, turn, etc. It was good for a large dataset from say 0Hz up to 10Ghz and any strange occurances are cleary seen. Apply the same concept to port over ip and time. The depth of the view allows you to see back in time or as you replay that line comes into the front view&#8230;not sure if I explained that clearly enough, but I&#8217;ll try and code a demo to show what I mean. </p>
<p>Similar to this but replay/interaction with data is a must:</p>
<p>Sp3ar0</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cappella</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-14015</link>
		<dc:creator>Cappella</dc:creator>
		<pubDate>Tue, 09 Dec 2008 00:53:04 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-14015</guid>
		<description>Just to throw off some thoughts, deriving from what I learnt in Ettercap.

1. Line thickness = Log (t).

   The thicker the line, the longer it has occurred.

2. Line colour. 8 hues for blocks of n hours to show last 8n hours. So if n=3 then last 24 hours.

I believe the above can be easily coded in without any change to top link graphs.

Cons: When there are &gt; 20 sub-nodes linking to one node it will get messy. Otherwise if it is less than 10 it should be pretty discernible.

3. Line type. Tight and loose dashed lines to indicate how recent or how long event has passed. Faint line for events that occur more than 24 hours, eg. Again can be used with 8 or less colours to depict blocks of time it has passed.

Cons: When too many event sub-nodes occur more than 24 hours, line can be too faint to be discerned in a congested area.

Bottomline: Almost every implementation is bad if there are too many nodes/sub-nodes squeezed in a small area. :P</description>
		<content:encoded><![CDATA[<p>Just to throw off some thoughts, deriving from what I learnt in Ettercap.</p>
<p>1. Line thickness = Log (t).</p>
<p>   The thicker the line, the longer it has occurred.</p>
<p>2. Line colour. 8 hues for blocks of n hours to show last 8n hours. So if n=3 then last 24 hours.</p>
<p>I believe the above can be easily coded in without any change to top link graphs.</p>
<p>Cons: When there are &gt; 20 sub-nodes linking to one node it will get messy. Otherwise if it is less than 10 it should be pretty discernible.</p>
<p>3. Line type. Tight and loose dashed lines to indicate how recent or how long event has passed. Faint line for events that occur more than 24 hours, eg. Again can be used with 8 or less colours to depict blocks of time it has passed.</p>
<p>Cons: When too many event sub-nodes occur more than 24 hours, line can be too faint to be discerned in a congested area.</p>
<p>Bottomline: Almost every implementation is bad if there are too many nodes/sub-nodes squeezed in a small area. <img src='http://raffy.ch/blog/wp-includes/images/smilies/icon_razz.gif' alt=':P' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sp3ar0</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-14005</link>
		<dc:creator>Sp3ar0</dc:creator>
		<pubDate>Mon, 08 Dec 2008 13:54:07 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-14005</guid>
		<description>Would a parse tree with the parent node being the timestamp be usable I wonder...</description>
		<content:encoded><![CDATA[<p>Would a parse tree with the parent node being the timestamp be usable I wonder&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Raffy - Security Data Visualization Â» Displaying Time in Link Graphs &#124; animesque.com</title>
		<link>http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/comment-page-1/#comment-13921</link>
		<dc:creator>Raffy - Security Data Visualization Â» Displaying Time in Link Graphs &#124; animesque.com</dc:creator>
		<pubDate>Mon, 08 Dec 2008 02:06:06 +0000</pubDate>
		<guid isPermaLink="false">http://raffy.ch/blog/2008/12/07/displaying-time-in-link-graphs/#comment-13921</guid>
		<description>[...] Raffy - Security Data Visualization Â» Displaying Time in Link Graphs [...]</description>
		<content:encoded><![CDATA[<p>[...] Raffy &#8211; Security Data Visualization Â» Displaying Time in Link Graphs [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
