Could this "multi-graph" structure be a mechanism to implement version control in Leo? As you know, the fundamental data structure for Git and other version control systems is also a DAG. If, in addition to the existing tree representing the document structure, there is another tree defining the evolution in time of the document/each node, then Leo would be able to track the whole history of a project.
This could be a good foundation for collaborative document edition (merging modifications on the same Leo document by multiple users), which would make Leo even more powerful as a distributed tool for knowledge base management. If the functionality can be implemented in such a way that the new "history tree" can be fully mapped on top of an existing version control system such as git (i.e. mapping each edge -representing the transition from a particular version of a node to a newer one- to individual blobs in git commits), then Leo could probably reuse many of the existing tools/concepts from version control systems: diff visualization, synchronization between users (i.e. pull requests, remotes), tree management, etc Just my 2 cents Jose On Thursday, February 11, 2016 at 6:12:20 PM UTC-5, Edward K. Ream 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
