I like the idea, and I was probably even to some extent thinking of that sort of usage when considering "leo as a PIM". But you see, this approach is likely asking for trouble in many ways. Just a few examples : - aren't you reinventing the wheel to a large extent ? Using your :key: syntax is Yet Another Way To Code Tags, but is not so different of a json approach or XML, vCard, ... The buzzwords and bad words here are "standard" or "registration", "support", "maintenance", etc. - leo's way of using XML cannot benefit of this if I understand correctly, as it won't code your keys as XML tags <parents id="tom.xxx."> etc. but <v> and plaintext. - the creation date is redondant with the ID. That's a feature of leo ! You could have :modified: though and :lastread:, and others - the last part of your example is supposed to contain notes. Why wouldn't place of birth be a tagged content. - when this becomes a large address book, managing your scripts to search in it will likely become a nightmare
Don't get me wrong, there is definitely something here. At the same time, I keep getting the feeling that I've seem that already so many times, when I looked at Anki cards, and the incredible discussion of formats for instant messaging back in ... 1998. Ward Cunningham invented the Wiki starting from Hypercard, so why not start from leo to invent ... the next big thing ? I agree that a SQLite format for leo internally might be a good idea. But apparently Edward won't, and he probably has good reasons. Maybe for leo 8 ? On Thursday, March 31, 2022 at 4:14:30 AM UTC+2 [email protected] wrote: > 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/f8ca9dd9-67ae-44a9-88d6-f2291946b23an%40googlegroups.com.
