[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] spring and force directed graphs


On Fri, 8 Mar 2002, Alex Shapiro wrote:    (01)

> So I take it that a similarity matrix has real numbers corresponding to the
> similarity between any of the two items.    (02)

Correct.    (03)

> This is actually quite a different problem then the one that TG's layout
> addresses.    (04)

The appeal of the TG stuff is twofold:    (05)

- TG's XML representation (is that in TG or Link Browser?) separates
  nodes from edges. The Spring implementation we are working from has
  an _extremely_ limited way of getting placement data and doesn't do
  much with other attributes.
- Those other attributes fit nicely into TG's bells and whistles.    (06)

The Spring implementation I've been working with is currently being
used for the similarity matrices but is generally useable for anything
that could use a kind of force directed placement. One of the reasons
it is being used for similarity matrices instead of something more
static is because people seem to get some meaningful joy out of
pulling a node and having it and its neighbors re-cluster.    (07)

> I think that if you are displaying a similarity matrices, then a Spring
> algorithm is Not the way to go.  There are lots of other ways to display
> them, for instance http://zing.ncsl.nist.gov/~cugini/uicd/viz.html is a
> link I found searching for "semantic document visualization" that displays
> some better techniques.  I would consider going for a 3d rather then 2d
> approach, since a lot of information would be lost by flattening the
> network out into 2d (unless you are interested in the degrees of similarity
> to a single document, in which case a radial graph is the way to go).    (08)

A quick browse of the systems at that URL seem to indicate semantic
comparisons between a vector reprsenting a query and vectors
representing documents ending up with a linear representation of
relevance. The similarity matrices are all documents versus all
documents: depending on how you trim the data, all nodes can be
connected to all others. You look at the resulting picture and see if
you can identify clusters.    (09)

I was going to use the archive of the unrev mailing list as a test
dataset, and then it would be possible to identify threads that are
semantically related to other threads. A possible result would be a
tool to access the messages themselves. Unfortunately the tools are
not yet mature enough to pull off that little stunt, so that's pending
some further work.    (010)

> Similarity matrices/clustering, huh?  Here is a paper that talks about
> this:  http://www.hpl.hp.com/techreports/2000/HPL-2000-160.pdf  I guess
> that this possibility could be further researched, but why would you not
> want to use maps instead?    (011)

That's a good reference, thank you.    (012)

> Check out
> http://www.cybergeography.org/atlas/info_maps.html  Maps allow you to show
> "clusters" of information at a top level, which can then be zoomed in to in
> order to see the info in depth.    (013)

Basically because different people need different tools to be able to
understanding. I, for example, do not like those maps. My own
conception of geography doesn't map well to information space. However
little nodes floating around in a connected fashion, does.    (014)

It's also completely arbitrary: This is one of the possible assignment
from which I may choose. The assignment is not to come up with a good
tool to visualize similarity matrices, but instead improve and
generalize the spring algorithm code to make it a valid part of
existing toolkit.    (015)

Thank you very much for the comments and pointers. They are helping to
get my brain moving.    (016)

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