I've fiddled with this extensively. The problem isn't data representation; sure, "outlines" are "just" graphs. The question is, what on Earth does your UI look like? Editing "graphs" is hardly more structured than creating a "data editor"... ok, those are some nice English words you've got there, but how does it actually work?

At least by limiting it to text and stuff that looks a lot like text, you can produce a real application that does real things of real value. It may not be suitable for everything, but your thing that is suitable for "everything" is likely come out being suitable for nothing in practice.

That's a hard problem - I haven't done any "fiddle" but I've spent a lot of time doing Gedankenexperiment and haven't come up with anything I believe is remotely applicable. The genealogy example I gave is simpler but I'm not sure I've seen an editor for that use-case that's optimal either.

Maybe the problem just can't be simplified further? And as an aside, I wasn't trying to disparage Dave Winer's implementation of tree editing at all.

I wrote one. It might not be exactly what you had in mind. It works okay for me for brainstorming: github.com/andrewf/graphpaper

When folks stop talking about trees and start talking about graphs, they seem to forget that you usually want to have an order on the edges.

I think an outliner is a great way to explore a fully connected directed graph with sequenced edges; just don't hit "Expand everything" when the graph contains a cycle. Leo http://leoeditor.com/ expends a lot of effort to avoid cycles, which shows up in slow execution when adding edges ("cloning", in its terminology) to a node reaching a significant subgraph.

If the graph can contain cycles, a recursive expander needs to contain cycle recognition and terminate after a finite number of trips through the cycle (probably one).

What do you mean by an "order on the edges"? I'm only superficially familiar with graph theory.

In graph theory, one usually has a set of nodes (A, B, C, ...) and a set(!) of edges between the nodes, either directed ((A,B), (A,C), (B,A)) or undirected (in which edge (A,B) implies (B,A), (A,C) implies (C,A), etc.). Sets don't have an order; most graph theory doesn't distinguish between the set of directed edges ((A,B), (A,C), (B,A)) and ((A,C), (A,B), (B,A)).

On the other hand, when dealing with trees (aka outlines) it is almost always assumed that there is a significant order - a sequencing - on the edges between parent and child, and that it means something if you change the order of the children (outline subheads).

I'm interested in more general (directed) graphs that nonetheless have a sequence - an order - on the edges, and where operations on that sequence are explored, in addition to the more usually examined addition and removal of edges. Until holographic displays are cheap (and maybe even after) I think trees, aka outlines, are a great visualization technique for such graphs - just take precautions with "Expand All" when the edges contain ((A,A)) or ((A,B), (B,A)) or any other length cycle. Or, as an outline

    This is heading A
        This is heading A
            ....
    This is heading B
        This is heading A
            This is heading A
                ....
            This is heading B
                This is heading A
                    This is heading A
                        ....

Right, an ordering relation on the edge objects. facepalm That should have been obvious, but I usually think about trees in terms of vectors of children, not traditional graph theory.

I like trees too. I think that as long as computer memory is linear, our serializations are going to be linear, so even when we get holographic displays, our primary abstractions should be linearly serializable (so we don't get lost in leaky abstractions), which means trees. A graph structure built on that would have to be some form of "magic" layered on top, based on links embedded in the tree. Among other possibilities, you can make the "edges" be little independent trees that link to the "nodes".