If you look at it right, Leo can be thought of - and used - as a database. I don't really mean just the tree-and-body organization and data. I mean a database in a more geneal and organized sense.
A year or two ago, we had in another thread a presentation of how @Edward's brother Speed uses Leo "as a database" in his business. That was so complicated and so woven into his business practices that I never fully grasped how it works. And yes, I know that a Leo outline can be written as a SqlLite database file. I don't mean that, either. That's structured so that the outline can be reliably extracted from it, but it's not in a form that's suitable for being a more general data store. In a Leo outline we have basically only a few kinds of data elements: 1. Nodes with their identifiers (gnxes), headlines, and bodies; 2. The arrangement of these nodes into their current trees. 3. Possibly we could consider external files as additional data elements. The node arrangement is ephemeral - most of us keep changing the structure to some degree. The identifiers are unique to their specific node, much like primary keys. The rest of the data is essentially in the form of blobs, to use a database term. It's not differentiated. To search out particular bits of information would take a natural language processor, and probably would not be very successful anyway. To be able to do more, we need to be able to differentiate bits of data we think we'll be interested in. Leo as it exists now does have an ability to recognize certain special kinds of strings: a CTRL-click on one of them performs useful actions: - on a URL, opens that address in the system browser; - on a UNL, navigates to that location in a Leo outline; - coming soon, on a gnx navigates to that gnx; - on a method invocation, navigates to the node where it is defined; - also coming soon, on a Python filename, navigates to the @file or @clean node for that file. These abilities are fantastically useful, depending on what kind of work you do with Leo. I have devised a simple way to provide Leo nodes with what are essentially key-value pairs, which are the foundation of most data stores. It requires no programming - though programming can help you find them and move around the data bits. It is fairly readable and easy to type. This idea come from two projects I've been working on (on and off) for the last year or so. 1. Each key-value pair take a single line (which could be wordwrapped on the display); 2. Keys are marked using the "Field List" syntax from ReStructured text. For example (all on one line): :ref: https://nyuscholars.nyu.edu/en/publications/atreegrep-approximate-searching-in-unordered-trees-2 Here the key is "ref". Using this syntax has some advantages: it's readable, intuitively clear, easy to type, and easy for code to parses out from the body text. In addition, it renders very nicely in RsT. I've attached an image of this "card" and its rendered version as seen in a Freewin detached window. Another card image I've attached is from a family history data set. It has more keys: :id: tom.20210606085913.1 :created: 2021-06-06 08:59 :type: person :born: ~1571 :died: 1635 :marriage: tom.20210522091147.1 Collins-Unknown [1] :parents: tom.20210606131436.1 `Weeks-Poole`_ You can see that you can make up any key you like. You can also see how this card could be translated to a relational database. However, relational databases are not well suited to capturing hierarchical information (though it can be done). The "marriage" and "parents" lines include the gnx of their respective nodes. They can be navigated to by pressing CTRL-F9 (an added script) or soon by CTRL-clicking. So it is very easy to move around the data In this case, the "id" of the card is its gnx, which is a permanent part of Leo's node structure. It's appears on the card as a convenience for the viewer. There is a script that makes it easy to insert a backlink in the target node. When the keys are chosen with some consistency, scripts can be written to help with searching and navigation. With this kind of structure, a Leo outline becomes a flexible data store, easy to extend, to adapt to changing needs, and to reorganize. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/df0db42e-3cd9-41e4-a530-c99637eb1e27n%40googlegroups.com.
