Unlikely

Last 10 changes

peermore
peermore
peermore
aboutchris
augury
socialtext
pictures
socialtext
socialtext
aboutchris

122 words
253 defs

springdatamodel

[ Prev ] [ Next ]

Revision:
2002-03-26 19:17:48 ]
2002-03-25 21:55:17 ]


Some ideas for a data model for an improved spring. This is,
again, unverified, and potentially totally wack. But maybe not.

This is part of Project4


-- 
Chris Dent  <cdent@burningchrome.com>  http://www.burningchrome.com/~cdent/


---------- Forwarded message ----------
Date: Mon, 25 Mar 2002 21:50:36 -0500 (EST)
From: cdent@burningchrome.com
To: jlbaumga@indiana.edu
Cc: katy@indiana.edu
Subject: data model thoughts



Some thoughts about the data model. These need some development,
which is why I'm passing them out to you both. Same deal,
especially notable sections are marked with * in the left margin.

As discussed already, Spring is a manifestation of nodes and
edges. We are discussing changes that allow for hierarchies of
nodes.

To me that suggests there remain, still, two objects, but with
some adjustments. The crux here is that I'm not sure this model
is a good way to represent an incoming cluster hierarchy, but it
seems fairly easy to program.

It's entirely possible these ideas are completely bogus, as I'm
somewhat out of my depth here, but hey, why not take some
risks...

Nodes

  Nodes exist in a hiearichical structure: a node can contain a
  a list of nodes. A display of nodes would start at level zero,
  which is the one single parent node. Moving down the hierarchy
  would display the nodes contained therin. Those nodes may be
  leaves or not.

  Nodes have:

    label
    color
    text attachment of some kind
    url of some kind
    x pos
    y pos
    delta x
    delta y
    anti-gravity (repulsion)
    size (a sense of diameter)
    display boolean
*   level in hiearchy
*     (I'm not sure if this should be here or outside)
*    list of children nodes
*    object containing the xml attrs (presumably this is a
*      necessary carry over from the existing code)

Edges

  Edges connect nodes, at whatever level they may exist, but
  endpoints are always at the same level. They are non
  hiearchical, just a list of edges.

  They have:

  color
  thickness
  length
*   What is the relationship between length and strength? Is
*   length really only strength and not length at all?
  text attachment
  reference to from node
  reference to to node
  boolean representing whether this edge should be on, in effect

>From outside nodes and edges it would be handy to be able to
adjust:

  The repulsion power of the nodes
  The attraction power of the springs/edges
  The threshold of edges being "on"
  The level of hiearchy we are currently viewing

With this model I imagine being able to start at an arbitrary
level in the clustering hiearchy (even if is only 2 levels thick)
and zoom up and down the hierarchy. Every time we re-structure
the model of the nodes and edges, we first check where we are in
the hiearchy and display the right nodes.

Ideally I think all of this processing would be separated from
the graphical model. That is we can play games with nodes and
objects in a spring data model that doesn't care about pictures.
Node and Edge object could be extended to be drawable, perhaps,
instead of being drawn from within Spring?

I imagine an XML representation something like this. In this case
this is a way to a pathfinder network of some sort:

<graph>
<node id="1" label="top of hiearchy">
  <node id="2" label="leaf1"/>
  <node id="3" label="leaf2"/>
  <node id="4" label="leaf3"/>
  <node id="5" label="leaf4"/>
</node>
<edge from="2" to="3" strength="1"/>
<edge from="2" to="4" strength="1"/>
<edge from="4" to="5" strength="1"/>
</graph>

resulting in something like the following, when viewed at hiearchy level 1
(start counting at 0):

       3
       |
       |
       2
       |
       |
       4
       |
       |
       5

Some looking at the GXL spec led to something called GraphXML
which might be easier to deal with. Neither, though, to me, does
nesting of nodes in an easy fashion (this may indicate that my
nesting idea is flawed). GraphXML is here:

  http://www.cwi.nl/InfoVisu/

with a short white paper here:

  http://www.cwi.nl/I
nfoVisu/GraphXML/GraphXMLShort.pdf

What are your thoughts, what are the problems with this model?
[ Contact ] [ Old Blog ] [ New Blog ] [ Write ] [ AboutWarp ] [ Resume ] [ Search ] [ List Words ] [ Login ]