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

RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")



> > A
> > |
> > |-x
> > |
> > B---A
> >   |
> >   y    (01)

Ok, I'm convinced!!!    (02)

I've also realized that I had something along these lines happening already.
One of the views I've been working on is a tree (based on JTree's
rendering), which when showing a graph soon gets into multiple occurences of
each node. If A -> B and B -> A you'd probably have a loop in a graph view,
but the tree goes    (03)

A
-> B
   -> A
      -> B
         ...    (04)

I was rather surprised, but after playing around with it a bit, it does look
like it should be useful.    (05)

> I think you're talking about different things. Danny is talking about
> users placing nodes explicitly on the screen, arranging them into
> spatial structures (as in Ideagraph). Toni is talking about automatic
> views as in Fenfire Loom (or Gzz/GZigZag), where the program
> automatically arranges nodes on the screen to convey the underlying RDF
> structure (or zzstructure).    (06)

There is automatic layout in Ideagraph as well... (currently only
embedded-spring on the graph view, though I played with a few other ideas in
the prototype)    (07)

> Indeed, in our Loom views, we regularly show the same node multiple
> times: say that "noteA seeAlso noteB" and "noteB isReasonFor noteA" for
> example; then, when we focus noteA, noteB is related to it in two ways,
> and we show it twice because of that. (Sorry, I don't have a screenshot
> program ready :-/ )    (08)

An interesting angle. I've been avoiding the issue of representing multiple
arcs between nodes, mostly because it'll be hard to manage on screen.
Showing nodes more than once would certainly make the layout easier,
although I suppose care would have to be taken to make it clear that node
A(1) is the same individual as node A(2).    (09)

> After reflection, I do think that placing the same node at two different
> locations can make sense, though. In Spatial Hypertext, the arrangement
> of nodes is used to convey structure as we would on e.g. a conventional
> blackboard or scratchpad etc.
>
> Let's say a user is making groups of people by placing person nodes
> together in different locations of the screen (spatial canvas). What if
> a person is in more than one group?    (010)

Well yes, but you could use a Venn diagram style, or just have a separate
canvas for each group...    (011)

> (Maybe these kinds of spatial structuring isn't what you're after in
> Ideagraph; but on the other hand, why allow the user to hand-structure
> the arrangement of the graph if not to have them make use of that
> spatial arrangement? In any case, it would be nice if the same
> vocabulary could be used by other tools that let users arrange things
> spatially...)    (012)

Oh, I agree entirely, the spatial stuff definitely has a lot of potential.
I'm quite looking forward to when I can move off the wiring side of
Ideagraph and play around with layout (inc. grouping).    (013)

Cheers,
Danny.    (014)