Sounds very interesting. Might be worth a look at the backlinks plug-in, which provides a mechanism and gui for superimposing a general graph on the tree. Graphcanvas plug-in is just another gui for the same mechanism.
Bit entirely sure I follow the 'attribute' part vs nodes, and of course something more integral to Leo's core would be a lot more powerful than the backlinks overlay. Also long ago I did demo navigation of a cyclic graph using a tree, not sure if that's relevant. Also recalling the sea of nodes idea that's surfaced periodically. Interesting direction, for sure. Cheers -Terry On February 11, 2016 5:12:19 PM CST, "Edward K. Ream" <[email protected]> wrote: >John Lunzer's recent remarks has triggered one of the biggest Aha's in >Leo's history, one that was totally unexpected until this afternoon. > >Leo's fundamental data structure is a tree of nodes. More accurately, >it >is a Directed Acyclic Graph or dag. Links in such a graph can point >"down" >the tree, but never up, so there are no cycles. Leo's clones are well >defined just exactly because there are no cycles. Given a node, we >know >precisely *and* intuitively which nodes are descendants. Because of >clones, >a node may have more than one parent. > >Here's the Aha. Imagine this data structure as being linked with >*black* >thread. Now imagine another *completely independent* set of *red* >threads. The only requirement is that the links defined by the red >threads >must *also* be a tree/dag. That is, there is *absolutely no* necessary >relationship between the red and black threads. > >Now imagine that every Leo attribute creates its *own* sets of >links/threads. *We have a new view for every attribute.* Let's call >such a >data structure a *multi-threaded tree/dag*. Trees might actually be >enough, >but I'm not sure so I'll refer to tree/dag (tree or dag). *Important*: >some >nodes may not have any thread running them for some colored threads >(attributes). That's just fine. > >Alas, the term "multi-threaded data structure" is commonly used for >data >structures that can be accessed by independently running threads. >That's >not at all what I am talking about. > >I am not aware of anything like this in graph theory. Could this be a >truly >new idea? I really have no idea. > >Of course, you could call the resulting structure a general graph, and >technically it is, but how the data structure will be used inside Leo >is *very >*different. Instead of a single, unintuitive mess, we have a collection >of >easily traversed trees/dags. *We instantly have an arbitrary >dimensioned >graph*! Each color creates a new dimension. Of course, we only *see* >one >dimension at a time, but attributes may be the *composition* of other >attributes (unions, intersections or other relations), so this is no >real >restriction. > >And listen to this. *It is astoundingly easy to create this multi-dag >in >Leo*. At present, each vnode has a parents list and a children list. >All >we have to do is replace these two lists by dictionaries whose keys are > >attributes and whose values are the parents or children lists for those > >attributes. Finally, we add Python properties shield the dictionary >lookup >from the rest of Leo. We are talking about maybe 50 lines of code! As >far >as the rest of Leo is concerned, vnodes *still* have parents and >children >lists. The switcheroo happens totally invisibly, when the user wants >to >see another view. The attribute changes and that changes what the >vnode >dictionary/properties "deliver" to the rest of Leo. > >To recap: What we see depends only on the attribute that defines the >view. >This attribute determines what parents and children lists become >active. >So easy. So very powerful. > >Each *current view* will show only the nodes with the given attribute. >To >repeat, attributes can be composed of other attributes, so in effect >each >view can be associated with an *arbitrary set* of attributes. This is >an >*astoundingly* general data structure. > >The real challenge lies in assigning different colored links to nodes. >I'm >still trying to wrap my thoughts around all of this. > >As always with truly huge Ahas, it's already impossible to know exactly > >what thoughts lead to it. As soon as the Aha happened, the world >changed >so much that the past becomes hard to reconstruct. But for sure the >following factors were "in the air": > >1. Most importantly, the consensus has been building among the usual >suspects that attributes are a more intuitive, and perhaps more >powerful, >alternative to clones. > >2. For the last year I have been trying to ignore the fact that >sometimes >clones get in the way. This was the meaning of today's remark that "I >love >clones, I hate clones". > >3. John's remark about attributes and hoists certainly triggered the >avalanche. > >*Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes >complexity. In particular, both hoists and chapters are a (mildly >successful) attempt to make clones do the work of attribute-based >views. In >the new scheme, we simply re-thread nodes that we want to be part of >the >new view. > >*And notice*: when we require that views be made of clones we can *not* > >change any parent/child relationships. But that constraint completely >disappears when we use attributes to define views. > >*Summary* > >This is one of the most momentous Aha's in Leo's history. It was >completely >unexpected this morning. It is almost too easy to make it happen. I >may do >it this evening. > >There remain important user interface questions concerning how nodes >get >assigned various colored threads, but I have faith that the result will >be >truly amazing. > >This Aha will have a huge number of happy consequences. Just for >starters: > >1. Searches can be limited to a single view (thread color). If we >don't >use clones in a view, each search will find a node at most once. This >will >erase my biggest pet peeve about Leo! > >2. Every view (attribute) can define/create its own set of parent/child > >relationships, independently of all other views. Afaik, no other data >structure is this flexible while still remaining intuitive. > >3. It will be *very easy* for attribute editors to show nodes having >those >attributes in the most natural way *for that attribute* without being >constrained in any way by other organizations of the data. Yes, this >is >really just a restatement of 2, but it's different in practice. > >No way would this Aha have happened without the interesting >conversations >that have taken place in the last few months. Well done, all of us! > >Edward > >-- >You received this message because you are subscribed to the Google >Groups "leo-editor" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to [email protected]. >To post to this group, send email to [email protected]. >Visit this group at https://groups.google.com/group/leo-editor. >For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
